Software making space missions smarter

Where does this embedded intelligence come from? As with all the other smart hardware in our daily lives, it ultimately comes down to the coded instruction sets we call software, telling a system what to do in any given situation.

ESA’s Software Systems Division, made up of about 70 people, is tasked with responding to this drive for ever greater autonomy, across all areas of space exploration and applications.

“There are basically two types of mission problem that autonomy addresses,” remarks division head Joachim Fuchs. “One is in critical mission-enabling phases where humans absolutely cannot intervene, such as the ExoMars rover landing, or the Juice mission inserting itself into Jupiter orbit – in both cases the inherent signal delay due to distance leaves them on their own.

“With something like a rocket launch we pretty much know what’s happening, but with a Mars landing there’s many more unknowns, such as the precise dynamics of the atmosphere, so there’s a wide range of potential conditions to cope with. For these situations, it comes down a lot of software testing to take account of all possibilities. If there’s a thruster failure, or just a memory ‘bit-flip’, can the system respond, and still implement what it needs to do?

“The second mission problem where autonomy plays a role is in a performance-driven situation where adding intelligence helps get around system limitations, such as restricted bandwidth or onboard memory. Take the Ф-sat-1 payload on FSSCat, which uses vision-based AI to perform its own onboard processing, so only the most useful data needs sending to users. If that fails that’s not immediately going to lose the mission. It’s an approach that’s going to be important in scenarios where the user interacts directly with the Earth observation or communication satellite payloads, sparking a trend towards onboard intelligence.”

Autonomy is most often achieved by moving beyond basic command instruction to a higher level of complexity and abstraction. Joachim adds: “Think of writing a document on your laptop; it could all be done through direct control coding, but it’s much easier and better to do it with an operating system and bespoke software. On the other side that increases complexity – each new layer adds an extra bit of size, time and resources.”

One way to allow that is actually to add dedicated hardware for extra autonomy, the equivalent of adding a graphics card to a gamer’s PC. Phi-Sat makes use of Intel’s Movidius Myriad 2 chip, optimised for high-performance low-power vision processing.

Other options include customised application specific integrated circuits, ASICs, or else field-programmable gate arrays, FPGAs, which have the added advantage of being remotely reprogrammable after launch, so that lessons learned could be incorporated into their operation.

The challenge for the Software Systems team is that processor speed and memory size for space-based computers lag several generations behind their terrestrial equivalent. Space is awash in radiation that can disrupt unshielded Earthly hardware –while ‘rad-hardened’ systems are both basic and costly.

“The platform memory has grown two to three times from 15 years ago,” explains Maria Hernek, leading the division’s Flight Software section. “That allows operating software to grow in size compared to what we had before, but’s it still tiny compared to that of an ordinary smartphone.”

To give an idea, the first generation of Spot Earth-observing satellites ran on 16 KB of memory, while the next generation of telecom satellites advanced to 1 or 2 MB. Missions about to fly today typically have a comparatively luxurious 512 MB, running on multicore versions of the space-qualified LEON processor family developed by ESA and its industrial partners.

“The software running the mission platform – or ‘bus’ – is pretty conservative in nature, in the same way that a Volvo lorry looks much the same generation after generation,” notes Maria. “Any innovation on the tried and tested building blocks would inject risk, which mission planners are never keen on doing.”

There’s more openness to software innovation on the payload side – the instruments or systems which gather the data or perform the services for which the mission was built in the first place. Plus any single payload failure does not typically doom the entire mission.

“So encouraging experimentation on the platform side is important,” Maria comments. “For instance ESA’s Proba series of satellites opened people’s minds to the value of increased onboard autonomy, starting with Proba-1 back in 2001 – which is still operating to this day – and advancing to the formation-flying Proba-3 in 2023, which will demonstrate autonomous rendezvous and collision-avoidance operations between a pair of satellites.

“And now we have a great deal of in-orbit demonstration CubeSats often making use of small but powerful terrestrial computer hardware – being small and cheap enough to take extra risks.”

Christophe Honvault heads ESA’s Software Technology section, which develops new software technologies and methods: “Today’s tendency is to generate more and more of the code automatically. For instance the attitude and orbital control software is often generated through running a system level model of the spacecraft to identify all the necessary functionalities, and we’re looking into doing the same with data handling.”

Proba-1 was pioneering in this way, an early demonstration of the use of what is called ‘autocoding’, short for automatic code generation – using software to write software.

Fast forward to today, and mission modelling on simulators and avionics test benches has become essential to test the software itself, with very highest level of verification and validation for mission-critical functions.

Maria adds: “For instance the switching of a satellite into safe mode needs to happen reliably, keeping basic functions running to buy time to investigate and fix the problem.”

Getting stuck on the equivalent of a blue screen of death should never happen in orbit. Solar Orbiter offers another example of mission-critical functionality: at any time its software has only 50 seconds to swivel its radiator out of view of direct sunlight, otherwise its instruments will overheat irreparably.

“We’ve got pretty good at testing software,” comments Joachim. “When things do go wrong – from the infamous inaugural Ariane 5 failure in 1996 to the Schiaparelli crash landing on Mars – it usually comes down to the wrong parameter being defined at the outset, rather than the software itself.”

Today the division is working on a range of different missions where autonomy is an indispensable element: the European Large Logistic Lander will navigate itself down onto the surface of the Moon, while the Hera mission will estimate its position in space by tracking its target asteroid. The international Mars Sample Return initiative will rely on a chain of autonomous robotic systems to first select promising Martian rocks, then return them to Earth via a demanding orbital rendezvous. 

A comparable autonomous meeting in orbit will be key to the ClearSpace-1 mission, removing a derelict ESA-owned satellite, and subsequent In-Orbit Servicing missions.

As Maria concludes: “Today’s spacecraft and missions demand a high level of autonomy as an enabler for exploration or for efficiency reasons, to lower operational costs. And in the future machine learning may allow spacecraft to make their own intelligent decisions. Software will play an important and crucial part of such coming technology solutions so we are looking ahead at interesting and challenging work.”