This paper describes how an infrastructure that was not initially designed for automation has evolved to support it The starting point is SCOS-2000, a mature mission control system used today at ESOC and elsewhere, and the MOIS Toolkit which was developed to write and manage operations procedures in a controlled way and submit them to SCOS as command sequences, usually for on-board schedule execution. Ground-based automation was not considered at first, largely because of the nature of the missions flown by ESOC and its overall operations concept. Automation in other control systems is usually achieved by the execution of Operations Language (OL) scripts written by operations staff. Conversely, MOIS procedures are stored as formal data structures without any language syntax. The structure of MOIS procedures is quite restrictive compared to what can be achieved with an OL, but this makes them more standard and easier to test. Storing procedure data in this way also makes it easier to transform them into language scripts. MOIS procedures can be exported to several OLs including td-tk/TOPE (for SCOS), UCL (for CGS), Elisa (for OpenCenter), STOL (for ISI/EPOCH) and two very different forms of PLUTO (also for SCOS). Automation of space segment procedures has been possible for some time, ever since SCOS exposed its EXIF CORBA interface. Clients of this interface include the tcl-tk/TOPE engine and the MOIS Executor which executes MOIS procedures directly without going via an intermediate OL. The tendency at ESOC has been to introduce MOIS automation late on in a mission to help with routine tasks and to deal with well characterised anomalies, although it has also been used more extensively on smaller missions such as SMART-1. The EXIF has since been superseded by the Service Management Framework (SMF) which has a wider scope. Ground-based services, such as the Network Interface Service (NIS) offer their services via the SMF. The Mission Automation System MATIS was the first to use the SMF for ESOC automation. Its focus is primarily on schedules capable of executing a customised form of PLUTO procedure. The PLUTO standard (ECSS-E-ST-70-32C) was tailored to include a syntax capable of making direct SMF calls within the script. This was necessary in the absence of a space system model abstraction (to standard Activities, Reporting Data and Events) but made the scripts difficult to write, understand and test. A MOIS export was developed using templates to shield this complication from the user, but it didn't solve the underlying system level design problem. More recently the IDEA project has managed to rationalise this by introducing a space system model based on ECSS-E-ST-70-31C to support PLUTO procedures properly compliant to the standard enabling the SMF programming interface to be hidden from user view. A PLUTO DSL editor was also developed for direct script creation. To close the loop, it is now possible to export PLUTO in this much cleaner standard form from MOIS which itself interacts directly with the space system model, storing its procedures in this structure (as foreseen by the standard). This paper will detail this history and describe the current system, identifying new ways to simplify the system and improve the user experience.
展开▼
