By Grace Peng
Software, and lots of it!
The issue of Toyota's sudden acceleration problem came up at both the last PTA meeting I attended and at my mother-in-law's dinner table last weekend. Perhaps this digression about real-time software is of general interest.
Software has become embedded into so many things we use every day that it has become invisible to us. Because of its ubiquity, we are not using independent pieces of software, but rather systems made up of smaller interacting subsystems, each with their own software. Because of this complexity, it can be difficult to trace a root cause when a problem arises.
In grad school, I wrote and worked with computer models that try to describe physical processes. That led to numerical weather prediction (NWP), which led to satellite data processing -- how the signal off a satellite sensor gets turned into bits which flow down to a groundstation and get turned into information that helps NWP do a better job of predicting the weather.
That's all software. But there is a fundamental difference between the type of software I have written and real-time systems.
No one cares how long it takes for a grad student's model to run, except for the grad student that wants to finish up and graduate.
NWP predictions have to run faster than elapsed model time or else it would be a hindcast instead of a forecast.
Real-time software must run at the same speed as elapsed time. When they are inseparably installed in a machine to control or take readings from it, they are called real-time embedded software. So the answer to the title question should have been that both automobiles and spacecraft contain large amounts of embedded real-time software.
The similarities don't stop there. Both are complex systems of subsystems, each with their own computer and software. The manufacturer of the automobile or spacecraft likely did not build all of the subsystems. So they become an integrator of subsystems and software. The system becomes very complex, and difficult to test robustly. That is, it is difficult to design tests that cover all possible scenarios or paths down a decision tree.
In the satellite software world, the standard is to "test like we fly." (I imagine the automotive industry does the same.) All of the software in the system will be tested together for weeks or months at a time, with all manner of monkey wrenches thrown in the mix, to make sure everything behaves in the intended manner.
Toyota's engineers didn't find a sudden acceleration problem before the cars went to market. Even after the accidents, they tried to simulate the events the motorists described and they still couldn't find a software root cause. What were they missing?
When you can't find what you are looking for, it is logical to ask someone with fresh eyes to look for it. You can't hand over your software to a competitor to test. That's too much temptation. It's better to ask a neutral party, perhaps someone in government for help. In case there is an industry-wide myopia to the root cause, it helps to ask someone in a different industry who does the same functional task.
Hence, NASA Goddard Space Flight Center was called in. GSFC integrates many satellites and has both the laboratory capability and the human expertise to perform that kind of testing and analysis.
[Speaking as a private individual and not as a representative of my employer or any of the government agencies that fund us, I would like to make an appeal. Those scientists, engineers and technicians need to get paid so they don't drift into other industries that do pay. If they weren't there, who would be there for us when a problem arises? It pains me when our politicians spout off about "killing the beast" and "getting government off the backs of industry." I think we should send them on a fact-finding mission to Somalia so they can see what a country without a functioning government looks like. Perhaps they want to move there?]