Software didn’t just eat the world; it ate space, too.
Computing and the US space program are inextricably linked. The Apollo Flight Computer was famously the first built around silicon chips, as NASA engineers realized that the breadth of calculations required to hurl people to the moon demanded a high-speed electronic solution.
Today, computer decision-making is even more tightly integrated into space activities, and that means the software is even more important. Boeing learned that to its detriment last year after its Starliner spacecraft failed to reach the International Space Station during an uncrewed test mission. The problems were coding errors that should have been caught in testing.
This week, NASA announced that it had completed two major reviews of the close call, issuing eighty recommendations to the troubled aerospace giant as well as new guidelines to improve oversight over its contractors’ software engineering. NASA human exploration chief Kathy Leuders said that one important factor was understanding Boeing’s approach to systems engineering and integration—essentially, how it envisioned the software and hardware for its spacecraft coming together as one.
“If we would have understood what that structure was, we would have been better able to plug into their decision-making process,” she said. “We thought we understood it; over time, it had kind of changed.”
For example, some code was tested on hardware mock-ups that were different than the final designs used in the spacecraft, and engineers never performed a full test from launch to docking, which might have caught the timing error that caused the spacecraft to miss the station.
Boeing built Starliner for NASA’s commercial crew program, which also hired SpaceX to develop a vehicle to carry astronauts to low-earth orbit. SpaceX’s crew Dragon is now docked at the ISS after delivering two astronauts in May. It is expected to complete its final test flight by achieving a safe return in August. Reporters asked NASA officials why SpaceX seemed to go so well compared to Boeing, and they suggested that perhaps they had taken Boeing’s systems engineering chops for granted and focused more of their oversight on the newer firm.
But the question of extra supervision may miss the real difference in how these companies make their spacecraft. SpaceX’s engineering approach grows from a Silicon Valley-inflected style of product development, while Boeing’s is based on the way complex machines were designed in the era before high-powered computing.
NASA’s safety advisory panel described the two companies (pdf) thusly in 2019: “SpaceX focuses on rapidly iterating through a build-test-learn approach that drives modifications toward design maturity. Boeing utilizes a well-established systems engineering methodology targeted at an initial investment in engineering studies and analysis to mature the system design prior to building and testing the hardware.”
Another way to say it is that Boeing relies on “waterfall” system engineering, while SpaceX relies on “agile” systems engineering. These are broad and debated terms that don’t totally capture either company’s culture, but the basic thrust is that Boeing moves linearly from requirements, to design, to test, to build, while SpaceX begins testing earlier, allowing it to modify its design as it moves forward.
This latter approach lends itself well to software development, where iteration doesn’t require physically reassembling a machine, as in engine testing. But it seems to work there, too. In 2018, the NASA safety advisory panel found SpaceX’s novel-to-aerospace approach worth investigating, and documented how the company (pdf) developed an internal tool to track hardware design that could catch human data entry errors and flag anomalous test results across relevant engineering teams.
“SpaceX has allowed NASA almost complete access to this system, and NASA engineers can gain virtually immediate information and insight into the current configuration…[though it] differs somewhat from traditional systems engineering, there is no question that it provides much the same data and does so more quickly,” the outside safety advisors wrote.
The space world gives a lot of credence to “heritage” hardware and methods—if it worked before, it will work again. That idea may need a refresh.
“Software people are kind of strange, over in the corner, and kind of viewed as a service,” Leuders said. “But as we know nowadays, your system is very integrated. Your software capability really drives the capability of the overall system.”