Evolving ESA Mars Express Mission Capability with Onboard Control Procedures

Abstract

For missions significantly remote from Earth, two important operational constraints are the round-trip travel time of the radio signal to the spacecraft, and the coverage available from heavily booked deep space stations. The use of On-Board Control Procedures (OBCPs) offers one means to alleviate those constraints: The OBCP can be seen as an on-board operator capable of performing dedicated tasks in real-time. For this reason, OBCPs are increasingly becoming a de-facto standard in operations of interplanetary spacecraft. Since January 2004, ESA’s Mars Express has been executing its routine science mission around Mars. For the majority of that time, the operations of platform sub-systems and payloads were undertaken only via direct commanding, time-tagged commands (in a fixed capacity mission timeline) and time-delayed execution of command groups. Specifically, the use of OBCPs was avoided by mission design: autonomous operations were only performed via the on-board software. Indeed, on-board software modifications in 2006 to allow power monitoring during critical power seasons resulted in the loss of OBCP processing capability, a capability which had been inherited from the common architecture with Rosetta. However, in 2008 it was decided to evolve the mission capability by introducing the use of OBCPs. A detailed study was initiated to evaluate the possibility to re-acquire the OBCP processing capability, to build an infra-structure to support OBCP development, and to train the team to code and test them. This decision was taken to extend the potential recovery mechanisms available for an ageing spacecraft, and also allow the possibility to reduce the commanding load during routine science operations. Specifically, OBCPs offer the possibility to modify the operations concept whilst avoiding complex on-board software modifications. After the end of the Industry support contract in May 2009, the flight control team has also built up the capability to develop and validate internally on-board software patches, albeit on a limited scope which can be complemented by the OBCPs. After a brief summary of OBCP functionality, this paper will identify the reasons to evolve the mission capability, as outlined above and discuss the software modifications necessary to re-establish the use of this functionality. Although OBCPs offer the potential for very complex on-board autonomy, their complexity and areas of application on Mars Express have consciously been limited in the initial phase of their development. Our paper will identify how such boundaries were defined on the mission, and the rationale behind such decisions, including on-board performance factors and operational safety requirements. We will also outline the benefits gained on Mars Express by the use of OBCPs, citing specific examples of procedures