From Drawing-Board to On-Board: A New Mission Timeline on Mars Express via OBCP

Abstract

Mars Express has been orbiting Mars since December 2003, utilising the Solid State MassMemory (SSMM) to store commanding, telemetry and science data. Following an anomaly with the SSMM in August 2011, the Mars Express team developed a new operations concept to work around the problem, using a smaller in-memory Mission Time-Line (MTL) that is unaffected by transient SSMM errors, whilst using the SSMM to store command files to refill the in-memory MTL in a just-in-time manner with a transaction-like approach that ensures operational safety. The "File-based Activity with Short Timeline" (FAST) concept enabled Mars Express to return to full operations within a matter of months. The technique of using command files to refill the MTL required the scheduling of "Execute TC File" commands ("triggers") within the MTL itself, blocking around 30 to 40 of the 117 command slots available. Furthermore, the FAST concept meant that the MTL only contained the bare minimum number of commands for the upcoming operations and gave no visibility for the longer weekly "commanding period" (CP), which is the basis of the mission planning concept. Mars Express is an "offline" mission with no real-time commanded operations in routine flight and while FAST allowed the whole CP to be loaded in one go, the upload of triggers remained a daily operation, requiring a delicate balance between "not too many" and "not too few loaded in advance", sensitive to the schedule of ground station passes during the day. Managing the uplink of these trigger commands gave rise to an operations overhead to ensure sufficient margin to deal with anomalies during station passes and various on-board constraints. An On-board Control Procedure (OBCP) was written to act as an additional MTL, to be tasked with the scheduling of the triggers. It provides a File Execution Scheduler, with which a CP's worth of files can be managed, freeing up the reserved space in the MTL and separating the CP schedule from the low-level contents of the activities: the actual unit commands themselves. This requires an OBCP to be running all the time, and of a greater complexity than had been tried before, with tight performance constraints determined by its role as the "mission activities scheduler". Implementation required four distinct strands of development: mission planning; mission control system; on- SpaceOps Conferences board software; and flight control procedures and rules. The mission planning system was required to plan at two distinct levels; the spacecraft activities and the schedule for executing the files. Changes to the MCS were required to implement a parallel On-board Queue Model and to trap and process the specific OBCP management commands. The biggest challenge was the OBCP itself and the management of associated changes to telemetry modes and system resources that accompanied it. Finally, new flight control procedures needed to be written and validated for the installation and use of the new OBCP; routine operational rules were redefined to enforce the revised conc...