An array of software glitches that failed a space mission
Rockets are overwhelming but not without software. We all write software that somehow impacts mankind at large. We cannot agree more about how the software is running the world today. Yet we often fail to recognize the importance of software in the space industry.
Rockets are complex so much so that we can even say they are the most complex machines ever built by mankind. They may seem like a huge cylinder. But they got so many individual components that must work the right way to make it to the orbit.
There is a maxim in the space fraternity: “Space is hard.” We have defied the gravity many a time and reached the final frontier. Besides the robust hardware that is on board a rocket, the software is the heart of the vehicle. Precision is the heart of everything in space travel. Everything must happen precisely at the right moment for the right duration. That’s where software comes into play.
There have been many failures in space but let me tell an interesting story of a recent failure. You might have heard about the recent Crew Dragon Demo 2, a commercial mission by a private space company SpaceX, which ferried two NASA astronauts to the International Space Station (ISS) and brought them back home to the earth. This is indeed a first for a private entity to do so. If not for the software issues, other company named Boeing could have been the first. Let’s see what really went bad with the Boeing Starliner, the test mission to the ISS.
It’s December 20, 2019. Starliner, the Boeing’s spacecraft with no human on board was sitting atop the Atlas V rocket. When the countdown hit zero, the rocket blasted off into the clear blue sky. All good so far. After fifteen minutes into the flight, the spacecraft separated from the rocket. Now it should perform a precise orbital insertion burn to be on the ideal path to dock with the Space Station, which orbits the earth at an astronomical speed of 7.66 km/sec. But nothing happened.
For some time, the mission control on earth estimated it was just delayed as the entire process is to be performed autonomously by the flight computer on Starliner. It didn’t take much time to debug it. The primary error is a bit surprising.
The spacecraft’s system clock was set prematurely. In simple terms, the onboard computer time is wrong. The Starliner computer should fetch the time from the rocket just before liftoff. Unfortunately, it pulled time eleven hours earlier than the expected. This led to the thrusters firing at the wrong time and put the Starliner in the wrong orbit. For starters, thrusters are as simple as engines that burn fuel and exhaust the thrust to manoeuvre the spacecraft as required.
So, the spacecraft lost most of its fuel beyond a point of orbit correction to dock with the ISS. Space is unforgiving. Once a vehicle is off orbit, it is almost unfixable. However, the mission control got the spacecraft ride back to the earth, although without achieving the mission objective of docking to the ISS.
Besides this timing error, there are other two major problems. One that is fixed with a software patch delivered from the ground control which if not could have led to the collision of the spacecraft’s two different modules namely Crew module and Service module while separating from each other. The other was the problem in Space to Ground communication link which troubled the ground control to command the vehicle.
These software issues are so profound that Boeing is not yet ready for a test flight and may give an attempt no earlier than December 2020. The codebase and the flight data are so huge that it counts to one million lines of code. So, it’s better we test our code well before we push it to production.
