New manned spacecraft will use a flight computer adapted from jetliners for deep space missions to the asteroids and Mars.
IW: So you will have a second computer running in parallel?
Lemke: We're actually going to have a spare flight computer running the same software. Both computers will think they are flying the vehicle. Neither one knows if it's flying or not, but if one goes out the other just takes over seamlessly and keeps on flying while the other comes back up after being hit by radiation.
Throughout the design, there are a lot of themes like that.
IW: Are they comparing against each other to see if one has an error or the results from calculations are inconsistent?
Lemke: The shuttle computers used to compare -- they had four computers comparing every output against every other output, to make sure they were all saying the exact same thing. But once again, that was very custom, and it was expensive.
Each of our flight computers is actually a self-checking pair. We have two 750 processors [PowerPC 750 FX] on a single board within a computer. Those two are checking each other to make sure they are getting the same answer. If those two self-checking pairs ever find they're not getting the same answer, they just fail silently. They just don't do anything [for the current computing operation].
At the same time, we have a whole second computer doing that same self-checking on its own processing. The whole idea is we don't have to vote count on the two computers because they're internally doing that themselves to make sure they're consistent. Because if they're not, they just fail silently and reset themselves.
IW: I wouldn't think an airliner computer would be equipped to run a spacecraft -- or are the differences more at the level of software?
Lemke: Exactly, it's all about the software. You'd be surprised how similar an aircraft is to a spacecraft. You have engines you have to run. You have cooling and heating systems on the aircraft, and you have all the sensors. But in general to the flight computer, it's just a bunch of I/O - sensor inputs in and flight control signals out.
We're not just taking a commercial flight computer designed for an aircraft and putting it on our spacecraft, but it's based on that design.
IW: And part of the purpose of the December flight is to prove this all works?
Lemke: Kind of. We've done most of our avionics testing on the ground. Through simulation, we can test most of it. What the test flight is going to give us that we can't get anywhere else is all the environments at once -- vibration, shocks space, hot and cold and radiation -- all those at once.
IW: The published specs also say something about "algorithmic autocode generation" -- is that something new and exotic?
Lemke: It's new and exotic for NASA, but not for industry in general. Are you familiar with Matlab? With that software, you can very quickly develop algorithms and test them out, and it lets you see that graphically. What Matlab means for us is we can work with the control team and those guys can design all their flight algorithms, all their test algorithms in Matlab. They can test it and get it working perfectly. Then you push a button in Matlab and it automatically generates C code. Then you take that C code directly into the flight software, and there you have it -- no coding, no chance of misinterpreting something that the designer wanted in the software.
This is about designing the trajectory of the spacecraft, the maneuvering of the spacecraft, like how it's going to dock. It used to be they'd use a tool like Matlab to design all that - and then they'd write a set of requirements.
IW: So this is about how you're designing the software, as opposed to how it operates in space?
Lemke: Exactly. That's a big deal for us because it costs us a lot of money to prove that the software we're going to run in space is perfect, that it's not going to have a problem. The closer we can get to making that development time collapsed from having an engineer designing that and getting it right to having it run on the spacecraft -- that reduction of time saves us a lot of money.
IW: Isn't there also something new about the networking?
Lemke: That's actually one of the most unique things we're doing. It's never flown in space before. It's called Time Triggered Gigabit Ethernet.
It's your standard gigabit Ethernet that you could go buy for your home or your office, except that we've put this extra layer on top of it. By making it time triggered, that lets us guarantee timing of data coming in and going across the network. This design lets us use all the advantages of an Ethernet network, and it also gives us the reliability and the timing of a custom-built military or spacecraft network.
We're the first ones to use it. It came from a company called TTTech In Austria. They've actually turned it into an SAE standard and are trying to get other folks interested. It lets us use things like commercial hardware -- say, a a video camera that talks Ethernet -- onto the network as well as the flight computer that controls the engines. And the two won't interfere with each other.
IW: Aside from flight control, do you use more standard equipment like commodity laptops for other purposes the crew might have like doing their email?
Lemke: We're going to leverage off what shuttle did and what space station is now doing. Yes, we use commercial off the shelf -- just as you'd buy them at Best Buy -- laptops on space station. The thought is, yes, they are susceptible to radiation, so sometimes they reboot. And you have to expect that. And sometimes they break. The radiation hits the wrong part, and it breaks, it's no good anymore -- and you get another one. You can go buy a laptop for $1000 today. If we were to try to develop a radiation hardened one, it would be way too big and bulky -- and cost of tens of millions of dollars to develop it.
So it actually makes sense for us, for non-life-critical tech, where no one's life depends on it, to actually just use the commercial equipment as it is. You zccept that it could fail and fly a couple of extra ones.
One of the biggest issues is making sure that they're safe, like the glass on the display - we need to make sure that they never shatter.
That guides us on which commercial laptop to use. We'll buy a bunch of different brands and fly the ones that are safe, from a crew perspective.
Orion is going to do a lot of the same things.
IW: Whereas with the mission computer, you started with a commercial system and hardened it against radiation?
Lemke: What we do is select different parts. You might use a commercial memory part in computer, but NASA has tested a lot of memory chips. We've replaced the memory chips with ones that we know are radiation tolerant. We use transistors that are typically not affected by radiation. So it's the same basic design, but we've swapped out parts.
IW: So is the expense in the design, even more than the hardware?
Lemke: The hardware is this big recurring cost, but we don't fly it all that often. So that's not quite as important to us as it is to an airliner. The man hours to design it, and test it, and prove that it's going to work in all our situations -- that's where the true expense comes in.
IW: What would you say have been the most diff challenges to overcome?
Lemke: The number one problem has really been math and budget. We're trying to build the largest capsule that's ever been built. It looks a lot like Apollo, but if you put the two next to other, this is so much larger. You make it bigger, then it's heavier. Being able to keep it affordable, that's where the real challenge is.
IW: To be honest, when I heard about the test flight coming up, I thought "didn't they cancel that whole program?"
Lemke: That's why we're so eager to talk to people like you -- to show we're still here, we're still working on exploration.
(Transcript edited for length and clarity.)
Our new survey shows federal agencies focusing more on security, as they should, but they're still behind the times with cloud and overall innovation. Read InformationWeek's Government IT Priorities digital issue.
David F. Carr oversees InformationWeek's coverage of government and healthcare IT. He previously led coverage of social business and education technologies and continues to contribute in those areas. He is the editor of Social Collaboration for Dummies (Wiley, Oct. 2013) and ... View Full Bio
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.