If Europe’s Automated Transfer Vehicle (ATV) encounters difficulties during rendezvous with the International Space Station (ISS), some highly sophisticated software will be on-hand to take over operations and avoid a potentially dangerous situation.
The ATV is a multi-functional spaceship that makes great use of flight software in order to combine both the full automatic capabilities of an unmanned vehicle, and the human spacecraft safety requirements. During its automated rendezvous with the manned Space Station, the software responsible for the ultimate safety of the crew is critical and cannot accept a failure probability at the same rate as non-critical software. For that purpose, the most stringent requirements, gathered under the label ‘Category A’, are imposed on the design and development of such software to make it reach an exceptional level of robustness in order to avoid any catastrophic situation or loss of human life.
The ATV, even in the case of malfunction, does not rely on human intervention to take over manual control of the vehicle to ensure mission success and ISS safety. The spaceship, even after two possible failures on board, must still be safe for the ISS crew and for the Space Station itself. The main risk resides in the critical phase of rendezvous and docking. Because of its 20.7-tonne mass, the ATV must, by all possible means, avoid a collision with the Station during the docking and de-docking operations. If control is lost at this critical phase of the mission, it could result in severe damage to the ISS.
For this purpose, the ATV relies on several automatic layers (1) of software and hardware redundancies, which provide a high level of autonomy to the spaceship. This autonomy allows the ATV to fulfil the entire mission on its own – including recovering from two independent failures without crew input.
In the classification used by ESA’s Directorate of Human Spaceflight, Microgravity and Exploration (D/HME), there are four categories of software from ‘A’ to ‘D’. All the requirements are specific to manned flights. The ‘D’ category is applied to all the ground software that has no direct impact on the mission objectives. At the other end of the scale, the ‘A Category’ software is the most critical since it is the last resort available to save the crew and the space habitat in case of major failure of the main system. Other ISS related human spaceflight projects already use this software classification scheme; however ‘Category A’ software has never been applied before.
“NASA has monitored the MSU progress by being involved in many reviews and has always been impressed by the professionalism exhibited by ESA during the development of this critical component”, said Jerry Clubb, NASA manager of the International Partner Avionics Integration for the ISS at Johnson Space Center, in Houston, Texas, in the United States.
Prime and backup pilots
On board the ATV, the Fault Tolerant Computer (FTC), which is the main computer, and its Flight Application Software (FAS), plays the role of a pilot that navigates the ATV mission. The FTC actually comprises three identical computers that monitor each other during the flight; each hosts identical software that manages the main vehicle functions — in nominal mode – according to predefined on board mission plans.
In the event the FTC fails during the approach phase, or the ATV manoeuvres endanger the ISS, a dedicated backup computer, the Monitoring and Safing Unit, or MSU, enters into play. This is the only computer unit on board that executes the ‘Category A’ software. Already during nominal approach to the ISS, the MSU, a completely independent computer, constantly monitors the position of the ATV and the performance of the main computer (FTC) by comparing it to a pre-programmed set of data.
Upon detection of a critical failure or an unsafe situation, the MSU isolates the ATV’s nominal system and commands a Collision Avoidance Manoeuvre (CAM). This brings the ATV on a safe trajectory within the monitoring corridor towards the ISS. Once the Collision Avoidance Manoeuvre is completed, the MSU points the vehicle towards the Sun, thus ensuring sufficient power from the solar panels during the ‘survival’ mode that the vehicle enters. The MSU works with its own hardware chains and avionics lanes built independently, in order to keep the ATV functioning in case of main hardware failure.
The MSU can also be activated to execute a Collision Avoidance Manoeuvre from within the ATV Control Centre (ATV-CC) in Toulouse, France, or by the ISS crew in orbit.
A master-slave relationship
“The MSU and its associated systems – hardware and software – are so segregated from the main ATV systems, that we can compare it to a satellite inside a satellite – like a pilot responsible for safety, hidden inside the automated spaceship responsible for the mission”, says ESA astronaut Jean-François Clervoy, the senior advisor to the ATV programme. “This independent mode relies on separate computers, separate software, separate batteries, separate trajectory monitoring sensors and separate thrusters. The only item shared with the ATV’s main system is propellant.”
The MSU itself features two identical computers, the ‘master’ and the ‘slave’. The slave monitors the health status of the master, ready to take over in case the latter should fail. The slave works in fact like a backup. Once the lead computer activates a Collision Avoidance Manoeuvre, the other computer – the slave – inhibits itself.
MSU : A small and robust last resort
Since the MSU is the last barrier to prevent catastrophic consequences, its software has been subject to ESA’s most stringent software development rules and quality assurance measures. In addition to the analyses, code inspections and tests performed by the developer – EADS SPACE Transportation in Les Mureaux, France – a separate contractor – the Danish firm ROVSING A/S – has been appointed to perform ‘independent software validation and verification’ or ISVV for short.
The MSU software has been developed with the objective of extreme robustness. To achieve this objective, reduced complexity, 100% determinism, and maximum capability to be tested, were directly built in its design.
“In accordance with the Category A software requirements, the MSU software has been 100% tested on target, which means on a computer architecture similar to the flight model. The test has also reproduced all possible conditions the software may have to cope with, including running stress and long duration tests,” says Eric Zekri, ESA ATV programme software engineer, in charge of MSU development.
The failure tolerance requirements of ATV, which add to the complexity of the ATV spaceship, mean a large amount of software: there are about one million lines of code in the various computers on the vehicle, with about half that total in the FTC alone. The MSU software, on the contrary, has been kept extremely compact and implements navigation, monitoring, and the Collision Avoidance Manoeuvre, with just 15 000 lines of code. “This software is small on purpose; the smaller it is, the better you can test it and such a size is needed for our ambitious verification approach”, says Klaus Ludwig, ESA software manager on the ATV programme.
Software under scrutiny
To obtain the best and most reliable software quality, special design and implementation rules had to be developed and have been applied in the development of code and algorithms for the software. (2)
Unlike any other space programs, the entire MSU software – line by line – has been through a meticulous numerical analysis to guarantee its ‘computational stability’, in order to avoid any error.
In terms of validation and verification tests, a very rigorous scheme has been put into place to validate the MSU software.
The independent software validation and verification (ISVV) team has been involved as an independent player from the very beginning of the software development, and has actively participated in all major software reviews. In addition, the ISVV team has performed independent unit and integration level testing at a dedicated ISVV test facility.
Finally, the so-called ‘stress test’ has been performed in parallel to the developer’s qualification tests. Contrary to the qualification test objectives, which prove the correctness and completeness of the software, the only goal of a ‘stress test’ is to break the software. “These stress tests have been conducted on carefully selected parts of the software, which have been identified during code inspections as potentially critical. And all stress test results have confirmed the robustness of the MSU software”, says Klaus Ludwig.
A fruitful collaboration
The MSU software has been designed and developed within a tight collaboration between the ESA and EADS-ST technical teams, gathered in the so-called ‘MSU team’ which consists of a dozen flight control and software specialists. From the early development stages, ROVSING A/S has been involved in the development and test campaign of the MSU software, providing feedback on the results of their own independent assessment to the MSU team.
This successful collaboration started in 2001, and the qualification of the ‘Category A’ software was achieved in March 2006. “This development is a premiere in Europe, and is, above all, the result of the successful day-to-day collaboration”, underlines Eric Zekri.
For the ESA ATV team and EADS SPACE Transportation, being collocated on the same site of Les Mureaux (50 km west of Paris) has been a great help for this software development.
“The working relationship we had with our ESA partner is much more than contractual. A real process of emulation and mutual confidence has been built up between us for five years”, said David Berthelier, the MSU project manager at EADS SPACE Transportation in Les Mureaux, “Within our EADS integrated team, everyone was proud and motivated to develop a whole software from top to bottom with this exceptional level of criticality. This Category A software is a first in Europe”.
Important lessons could be learned from this unique experience, in terms of design, and testing, but also in terms of interaction between the teams and the involvement of the ISVV team.
“If the Jules Verne mission is nominal and successful as we expect it to be, this state of the art MSU software will never be used for active control of the ATV. The MSU will just be limited to its monitoring role”, says Klaus Ludwig.
Footnotes:
(1) The ATV relies on a primary layer of automated Failure Detection, Isolation, and Recovery (FDIR) giving the spaceship the necessary level of autonomy to fulfil the entire mission on its own, up to docking with the ISS. In case a contingency situation on board the ATV would be such that the primary FDIR is defeated, the MSU comes into play as the last safety barrier, taking over the nominal system, and bringing the ATV on a safe trajectory in relation to the ISS.
(2) For example, the software has been modelled with a special mathematical tool – called SCADE – which allows to visualize the internal logics of the software and to verify it. Furthermore, another step has been taken to guarantee an additional robustness. “The MSU software is built around a data flow driven design. This means that the operations inside the software are triggered by the availability of the data (such as sensor input) and sequenced in order to have the data available when needed (in case of a sensor input) and to have meet the deadlines to produce an effect (such as starting a manoeuvre),” explains Erik Zekri. “Furthermore, we took care that all internal software components are interacting within a unique context or ‘state’, over each time slice of 100 milliseconds. The result is a cyclic and 100% deterministic software, which greatly simplifies the verification process. We can compare it to a working group of people speaking the same language, sharing the same environment, the same information needed and producing reliable and recurrent conclusions.”
