What software runs robots on Mars
Space software needs to overcome obstacles far more significant than regular end-users face.
Image by NASA.
Almost all human-made machines sent to orbit Earth and other Solar objects alike run computer software. There are hardly any other options to hold communications or perform science. Space software, however, needs to overcome obstacles far more significant than the ever anxious end-user regular developers have to deal with.
Software glitches are an inevitable part of a computerized world. Some errors might cause a mild panic attack when a spreadsheet editor crashes out of the blue. Others, like one in 2014 affecting the US emergency call system, might prevent thousands of people from getting vital help.
In most cases, troubled systems are located here on Earth. However, humanity runs imperfect machines that computers are outside the planet, too. For example, this March, a software glitch in the Hubble Space Telescope had briefly shut down its operations. The machine went into safe mode, putting a $4.7 billion wonder of engineering at risk.
Admittedly, the Hubble is over 30 years old. Newer crafts, however, are not immune to glitches either. The Ingenuity helicopter, carried to Mars by the Perseverance rover this February, suffered from a glitch that delayed the first powered, controlled flight by an aircraft on a planet besides Earth until NASA engineers sent necessary updates to the red planet.
To avoid billion-dollar spacecraft or an invaluable satellite crashing, software that runs space-bound crafts differs from code meant to operate down to Earth computers. To find out what’s the difference, we've talked to people who oversee software development for space missions.
Failure's not an option
Large satellites and space exploration missions do not run controls on Microsoft Windows, Linux, or other popular general-purpose operating systems (GPOS).
According to Mark Dean, an expert at the Software Engineer Directorate of Technical & Quality Management Flight Software Systems Section of the European Space Agency (ESA), satellite control software is similar to other safety-critical embedded software used in the medical, automotive, or avionics industries.
"A hard real-time embedded operating system is used because the control of the spacecraft itself has to be guaranteed to ensure the safety of the spacecraft, the science instruments, and potentially any crew on-board, so you have to be certain of its behavior and reliability," Dean told CyberNews.
A hard real-time embedded operating system is used because the control of the spacecraft itself has to be guaranteed to ensure the safety of the spacecraft,Mark Dean.
A real-time operating system (RTOS) is far from something most of us would recognize as an operating system. Whereas GPOS considers a task complete after the computation is done correctly, RTOS has an additional criterion - a time-specific deadline.
If the software upholds the deadline as not met, the task is considered failed. There is a good reason RTOS are usually used in spaceflight, since a failed task means that a spacecraft is either burnt in orbit, fried by radiation, or otherwise dead.
A time frame for a set task is also an exact number. Meaning that it has to take the same amount of time to complete a task each time, whereas a GPOS might produce different results. That's called a deterministic RTOS, or hard real-time OS. Software used in missions needs to be predictable and complete tasks within a specific deadline, down to milliseconds.
Another crucial difference between RTOS and GPOS is that the former executes processes in order of their priority while the latter executes processes on a time-shared basis. RTOS usually executes one program at a time, but it rapidly switches between programming tasks to execute multiple tasks 'simultaneously.' There's a strict hierarchy of tasks the system completes. Failure to adhere might mean mission failure.
Unusual OSs
Open-source OSs like Linux might be a lucrative choice for nanosatellite missions due to their low cost and accessibility. However, the open-source approach to software under Linux also means that the OS itself and applications running on it are less stringently tested.
That's not to say that all open-source software is banned from space systems. Far from it. According to Dean, The Real-Time Executive for Multiprocessor Systems (RTEMS) is a popular RTOS for space missions at the ESA. Developed in 1993 by the OAR corporation, RTEMS is free, open-source software.
Parts of ESA's Trace Gas Orbiter, currently in orbit around Mars, use RTEM to carry out some operations.
Another popular RTOS frequently used in deep space missions is VxWorks. Released by Wind River as early as 1987, VxWorks has been a part of Spirit, Opportunity, and Perseverance Mars rovers and Juno space probe sent to Jupiter.
ESA's Jupiter-bound mission, Jupiter Icy moons Explorer or JUICE for short, is planned for launch next year and reach its destination in 2029. Dean explained that core software in near-Earth and deep-space missions is usually the same, yet some functions might differ due to mission-specific requirements.
"For example, functionality could depend on how often and how reliable contact is with the ground and whether the satellite has to travel for a long time to reach its destination - such as a mission to Jupiter where the spacecraft could need to hibernate for a long period during its long trip," he told CyberNews.
Spacecraft, however, is just a part of a space mission. All the human labor is done on Earth. According to James Eggleston, ESAs Head of Data Systems Infrastructure Section (OPS-GDI), a more usual mix of operating systems is used on the ground.
The output is decided by voting. If two of them think that we should go right, then we go right. If at least two decide to go left, we go left. It's just the majority way,Rick Koeleman.
"Perhaps, the unusual aspect is that traditionally mission design produced bespoke systems, so we are still using some very old (and famous) OSes. We have systems used on the ground for operations using Vax/VMS, Sun Solaris, various Linux distros plus Microsoft Windows," he told CyberNews.
From the ground controls' point of view, there's little difference whether a mission is far away from Earth or in our planet's orbit. Eggleston explained that the only difference lies in the way systems are put together to deal with different mission scenarios and designs where the location in the Solar system is a factor for running a piece of software.
Democratic approach
Risk aversion is not reserved for far Earth missions. According to Rick Koeleman, a senior software architect for space, air, and ground systems at Cosine measurement systems, a company with a presence in low-Earth orbit, safety is a crucial aspect for machinery on nanosatellites as well.
"Our main task is not to destroy the satellite. This means that we should not allow the system to do anything that would mess with the power system. In that sense, interfaces are quite strong, bounded, and described," he told CyberNews.
Interestingly, one way to minimize system failure risk is a multiprocessor approach that employs voting by several systems to decide on the best course of action. For example, a craft uses three processors that run the same programs simultaneously.
"The output is decided by voting. If two of them think that we should go right, then we go right. If at least two decide to go left, we go left. It's just the majority way," Koeleman explained.
According to him, with that in mind, a developer focuses on writing a program in a fault-tolerant way. That's meant to help create processes within the satellite that are disjointed as much as possible. That is a necessity to minimize interference between ongoing operations.
More great CyberNews stories:
Is Roblox secure? Static analysis reveals subpar security practices on Roblox Android app
Careless love? 15% of people use pet names as password
Brittany Kaiser: big tech executives should be held criminally liable for their companies’ mischiefs
Subscribe to our monthly newsletter