Does this matter? Software has never played a more critical role in spaceflight. It has made it safer and more efficient, allowing a spacecraft to automatically adjust to changing conditions. According to Darrel Raines, a NASA engineer leading software development for the Orion deep space capsule, autonomy is particularly key for areas of “critical response time”–like the ascent of a rocket after liftoff, when a problem might require initiating an abort sequence in just a matter of seconds. Or in instances where the crew might be incapacitated for some reason.
And increased autonomy is practically essential to making some forms of spaceflight even work. Ad Astra is a Houston-based company that’s looking to make plasma rocket propulsion technology viable. The experimental engine uses plasma made out of argon gas, which is heated using electromagnetic waves. A “tuning” process overseen by the system’s software automatically figures out the optimal frequencies for this heating. The engine comes to full power in just a few milliseconds. “There’s no way for a human to respond to something like that in time,” says CEO Franklin Chang Diaz, a former astronaut who flew on several space shuttle missions from 1986 to 2002. Algorithms in the control system are used to recognize changing conditions in the rocket as it’s moving through the startup sequence–and act accordingly. “We wouldn’t be able to do any of this well without software,” he says.
But overrelying on software and autonomous systems in spaceflight creates new opportunities for problems to arise. That’s especially a concern for many of the space industry’s new contenders, who aren’t necessarily used to the kind of aggressive and comprehensive testing needed to weed out problems in software and are still trying to strike a good balance between automation and manual control.
-
The Space Shuttle Atlantis had a more traditional dashboard for its pilots to utilize. -
The Crew Dragon capsule replaces the knobs and switches with large touchscreens.
Nowadays, a few errors in over one million lines of code could spell the difference between mission success and mission failure. We saw that late last year, when Boeing’s Starliner capsule (the other vehicle NASA is counting on to send American astronauts into space) failed to make it to the ISS because of a glitch in its internal timer. A human pilot could have overridden the glitch that ended up burning Starliner’s thrusters prematurely. NASA administrator Jim Bridenstine remarked soon after Starliner’s problems arose: “Had we had an astronaut on board, we very well may be at the International Space Station right now.”
But it was later revealed that many other errors in the software had not been caught before launch, including one that could have led to the destruction of the spacecraft. And that was something human crew members could easily have overridden.
Boeing is certainly no stranger to building and testing spaceflight technologies, so it was a surprise to see the company fail to catch these problems before the Starliner test flight. “Software defects, particularly in complex spacecraft code, are not unexpected,” NASA said when the second glitch was made public. “However, there were numerous instances where the Boeing software quality processes either should have or could have uncovered the defects.” Boeing declined a request for comment.
According to Luke Schreier, the vice president and general manager of aerospace at NI (formerly National Instruments), problems in software are inevitable, whether in autonomous vehicles or in spacecraft. “That’s just life,” he says. The only real solution is to aggressively test ahead of time to find those issues and fix them: “You have to have a really rigorous software testing program to find those mistakes that will inevitably be there.”
Enter AI
Space, however, is a unique environment to test for. The conditions a spacecraft will encounter aren’t easy to emulate on the ground. While an autonomous vehicle can be taken out of the simulator and eased into lighter real-world conditions to refine the software little by little, you can’t really do the same thing for a launch vehicle. Launch, spaceflight, and a return to Earth are actions that either happen or they don’t–there is no “light” version.
This, says Schreier, is why AI is such a big deal in spaceflight nowadays–you can develop an autonomous system that is capable of anticipating those conditions, rather than requiring the conditions to be learned during a specific simulation. “You couldn’t possibly simulate on your own all the corner cases of the new hardware you’re designing,” he says.
So for some groups, testing software isn’t just a matter of finding and fixing errors in the code; it’s also a way to train AI-driven software. Take Virgin Orbit, for example, which recently tried to send its LauncherOne vehicle into space for the first time. The company worked with NI to develop a test bench that looped together all the vehicle’s sensors and avionics with the software meant to run a mission into orbit (down to the exact length of wiring used within the vehicle). By the time LauncherOne was ready to fly, it believed it had already been in space thousands of times thanks to the testing, and it had already faced many different kinds of scenarios.
Of course, the LauncherOne’s first test flight ended in failure, for reasons that have still not been disclosed. If it was due to software limitations, the attempt is yet another sign there’s a limit to how much an AI can be trained to face real-world conditions.
Raines adds that in contrast to the slower approach NASA takes for testing, private companies are able to move much more rapidly. For some, like SpaceX, this works out well. For others, like Boeing, it can lead to some surprising hiccups.
Ultimately, “the worst thing you can do is make something fully manual or fully autonomous,” says Nathan Uitenbroek, another NASA engineer working on Orion’s software development. Humans have to be able to intervene if the software is glitching up or if the computer’s memory is destroyed by an unanticipated event (like a blast of cosmic rays). But they also rely on the software to inform them when other problems arise.
NASA is used to figuring out this balance, and it has redundancy built into its crewed vehicles. The space shuttle operated on multiple computers using the same software, and if one had a problem, the others could take over. A separate computer ran on entirely different software, so it could take over the entire spacecraft if a systemic glitch was affecting the others. Raines and Uitenbroek say the same redundancy is used on Orion, which also includes a layer of automatic function that bypasses the software entirely for critical functions like parachute release.
On the Crew Dragon, there are instances where astronauts can manually initiate abort sequences, and where they can override software on the basis of new inputs. But the design of these vehicles means it’s more difficult now for the human to take complete control. The touch-screen console is still tied to the spacecraft’s software, and you can’t just bypass it entirely when you want to take over the spacecraft, even in an emergency.
There’s no consensus on how much further the human role in spaceflight will–or should–shrink. Uitenbroek thinks trying to develop software that can account for every possible contingency is simply impractical, especially when you have deadlines to make.
Chang Diaz disagrees, saying the world is shifting “to a point where eventually the human is going to be taken out of the equation.”
Which approach wins out may depend on the level of success achieved by the different parties sending people into space. NASA has no intention of taking humans out of the equation, but if commercial companies find they have an easier time minimizing the human pilot’s role and letting the AI take charge, than touch screens and pilotless flight to the ISS are only a taste of what’s to come.
