(Update 17:45 – scroll down) If you use a Mac or a Windows machine, or an iPhone or an Android device, you’ve likely been involved at one time or another with updating your operating system – the basic software that makes any computer run (and don’t forget Linux! – Ed.).

Artist’s impression depicting the separation of the ExoMars 2016 entry, descent and landing demonstrator module, named Schiaparelli, from the Trace Gas Orbiter, and heading for Mars. Credit: ESA/ATG medialab

Artist’s impression depicting the separation of the ExoMars 2016 entry, descent and landing demonstrator module, named Schiaparelli, from the Trace Gas Orbiter, and heading for Mars. Credit: ESA/ATG medialab

Software makers routinely roll out OS updates, which typically add new features as well as fixing bugs, glitches or other issues identified in the current OS. This week, ESA’s ExoMars Trace Gas Orbiter (TGO) spacecraft is also getting a fresh install, but, unlike with your phone or computer, this one’s happening 12 million km from Earth. And while the procedure for updating the on-board software is well known, it’s still complex – there are two separate processors (prime and back up) and there are four different memory areas where the OS is stored – meaning that the mission operations team at ESOC are keeping a very close eye on progress.

Team preparing to send the REBOOT command Credit: ESA

Team preparing to send the REBOOT command Credit: ESA

The new software will fix a number of issues that were known prior to lift off – but fixing them prior to launch would have introduced unacceptable delays. And we should add: these fixes mostly address possible degraded situations that have not occurred in flight and that have a low probability, rather than fixing issues with regularly used functions.

“We are increasing the robustness in case of transient events in space or on-board the spacecraft,” says Flight Director Michel Denis. “These could occur due to  cosmic radiation or space weather – solar activity – which all mostly have a low probability of actually occurring, but the longer a ship stays  in space, the more likely it may suffer a glitch due to these.”

One example of an issue to be fixed by the upload is how the two star trackers, used for navigation, are switched on and off (see more details below).

“Our spacecraft was specifically designed to enable such updates, and it’s a very powerful and flexible option,” says Michel.

To begin, overnight between Monday and Tuesday, the new software image was uploaded – this comprised a file 3MB in size and it was uplinked at just 4 kbps; the slow speed was deliberately set so as to reduce any potential packet losses and ensure the entire file arrives on board as sent.

(ExoMars/TGO is using ESA’s 35m deep-space tracking stations at New Norcia and Malargüe for communications this week.)

On Tuesday, engineers downloaded the stored image, and compared what came down to the original file sent up. They were checking to ensure that the new image stored on board is identical, bit for bit, with the original version on ground.

“It checked out fine,” says Spacecraft Operations Engineer Johannes Bauer. “We can’t afford that a single bit is wrong – in space there is no shop to bring your device in case it would get locked upon a software update.”

Wednesday was quiet, with nothing scheduled in case any corrections had to be sent up. Today, Thursday, in a procedure starting just after 06:30 UTC, the backup processor was rebooted, and it started just fine. “This is precisely what you do when you restart your computer after updating the OS,” says Deputy Spacecraft Operations Manager Silvia Sangiorgi.

With TGO operating on the new OS, the software will now be copied on board into the other memory locations and the prime processor will also be restarted.

This week, the team also continued working on commissioning of the EDM lander and checking out the payloads. Starting on 25 April, the mission will have just three ground station passes per week, as the pace of post-launch check-outs level off and the craft and team settle in for the cruise phase. This is not a period as relaxed as the name may suggest: the somehow reduced spacecraft activities will allow the teams to already start preparing the details for the upcoming manoeuvres and phases – more on this in future posts!

UPDATE 17:45

 

We knew some of you might want some additional technical details on the ExoMars/TGO software update, so we sent a few questions to our colleagues at Thales Alenia Space (France; TAS-F), the makers of this fabulous machine! Raphaël Zecchini, responsible for TGO avionics, kindly sent in the replies below. Raphaël also wrote:

“I’m very proud of the efforts and performances achieved by TAS-F CSW (Central SoftWare) and FCV (Functional Chain Validation) teams who have developed and validated this new binary in a very short time compatible with the operational windows to upload it.”

Thanks, Raphaël!

  • In general terms, what is the name/version of the operating system installed on TGO? Which company/teams developed the TGO OS? Which language does it use?

The TGO CSW (Central SoftWare) 05.02.01 has been loaded on the TGO; this CSW has been developed and validated by TAS-F using the ADA language.

  • What are some of the issues being fixed by the update?

The previous version loaded on TGO before the launch was the 05.02.00, so only minor modifications have been added so as to increase the robustness of the TGO in case of SGM (Safe Guard Memory) failure. These evolutions consist in having SGM status located inside both SGM and retrieval of SGM data in both SGM, which are in hot redundancy. We also used the occasion of this new CSW upload to update some action sequences (ACSEQ) in order to fully protect the TGO in case of silent failure in the redundant units, which are OFF.

  • Can this sort of update be done on any spacecraft? Is this a new capability/feature only found on modern satellites?

This capability of CSW uploading in a full and secure environment is new, using the capability to embed two images inside one processor module and to have the capability to communicate between both processor modules that can be set in hot redundancy. With this mechanism, uploading a new CSW is no more at risk because up to the acknowledgement from ground that the new CSW uploaded is correct, the satellite is protected using the second image stored in EEPROM processor module. On previous satellites, the capability to upload a new binary was present but not with a two-image capability in each processor module and with the processor module in hot redundancy with a direct link between both for communication.