To help venture further into space, or to gather ever more data, space missions keep on getting smarter. The latest Earth-observing satellites decide which images need sending to users, while planetary probes or rovers located beyond the limits of real-time oversight are able to set and follow their own course.
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 also pioneering in this way, demonstrating the use of ‘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 the instrument will overheat irreparably.
“We’ve got pretty good at testing software,” comments Joachim. “When things do go wrong – from the famous 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.”
Courtesy of ESA