[American Institute of Aeronautics and Astronautics SpaceOps 2002 Conference - Houston, Texas (10 October 2002 - 19 October 2002)] SpaceOps 2002 Conference - A New World for the Generic

1

A new world for the Generic Mission Planning kernel Ian Shaw

Anite Systems GmbH Robert Bosch Strasse 7, D-64293 Darmstadt, Germany

Fax +49 (0) 6151 8725151, E-mail [email protected]

Marc Niézette

Anite Systems GmbH Fax +49 (0) 6151 8725151, E-mail [email protected]

Fabienne Delhaise

European Space Operations Centre Robert Bosch Strasse 5, D-64293 Darmstadt, Germany

Fax +49 (0) 6151 902292, E-mail [email protected]

1 Abstract Rather than aiming to achieve a Mission Planning System (MPS) so configurable that it can be tailored to suit any ground segment configuration, Anite Systems has taken the approach of identifying and developing a “kernel” of functionality deemed to be appropriate for a wide spectrum of space Mission Planning Systems. This kernel then forms the heart of individual MPS developments, such that only the “mission-specific” elements need to be addressed. This approach gives each development a head-start by providing a base upon which the new work can be built – with the possibility of appropriate elements of the new software “migrating” into the kernel.

The starting point for this train of development began in 1995, with an ESOC study (undertaken by Anite Systems) entitled “Generic Mission Planning Facilities” (or GMPF). The study identified those elements common to many planning systems, and implemented a simple prototype for the planning of the ERS-2 mission to “prove the concept”.

A further step was taken a few years later, with the development of the MPS for the Envisat-1 mission. Using the output of the GMPF work as a starting point, the planning system for this extremely complex Earth Observation mission (10 instruments, with complex data-handling subsystems) was developed over a period of several years. During this time, the original ideas were modified slightly, but the essential items ( instruments and their configuration, resources, etc) remained. The migration of new software developed for Envisat resulted in an “operational kernel”, wider in scope than that devised by the original study.

Now, the approach is to be applied to a new mission - ESA’s “Mars Express” to the red planet. This orbiter (known as “MEX”) is the first of the so-called “Flexible” missions of the ESA long-term Scientific Programme “Horizons 2000”.

The mission is a test case for new working methods to speed up spacecraft production, and to minimise costs, whilst maintaining a high level of quality in all aspects of the mission - this philosophy extending to the Ground Segment. The Mission Control System (MCS) is essentially a reconfigured version of the MCS developed for the “Rosetta” mission (based on the ESA SCOS-2000 infrastructure), whilst the MPS will be based upon the operational kernel achieved during the course of the Envisat development. The production of these systems will demonstrate the strengths of this approach.

This paper will discuss how the development of the Mars-Express MPS will benefit from the GMPF approach, particularly with regard to the relatively short timescales available. In addition, the improvements and extensions that are expected to result in the operational kernel following this particular development will be addressed.

2

2 Introduction The paper is organised as follows :

• An overview of the changes made to the mission planning kernel in the course of the Envisat planning system development, and lessons learnt.

• A summary of the next target mission – ESA’s “Mars Express”

• A detailed description of the key differences between these two missions, and how the kernel software has been updated to handle these differences.

• A listing of other key changes made to the kernel in order to improve the flexibility of the system – many of these aspects coming to light in the course of the operational useage of the Envisat mission planning system.

• As the target environment has been upgraded for the Mars Express Mission Planning System, a brief description is given of the changes made to support this environment

• A list of possible future improvements to the kernel

• Conclusions

3 Lessons learnt during Envisat MPS development The Envisat FOS Mission Planning system has been put in operation at ESOC since the beginning of March 2002, following the successful launch of Envisat 1 by Ariane 5 on March 1st. The lessons learned from the system development and early operation are summarised hereafter.

• The module-based approach to mission planning is well suited for this kind of application.

It provides a framework in which rule-based modules can be combined with procedural modules (e.g. encapsulating external routines provided by the customer), allows for a simplified configuration of the system, and for the modularity needed to effectively distribute the implementation of the system between the developers.

• The development of rules in C++ provides a high-level of flexibility to the developers

The MPS planning rules are written by the developers, and are expressed in C++, using libraries of components for querying and acting on the plan. This approach has the great advantage to provide the developer with the full expressiveness of C++ to write the rule code.

• Fully configurable scheduling layer

The fully configurable scheduling layer, allowing mapping of activities and parameters to actual command or command sequence calls is perceived by the users as a definite improvement compared to former systems used at ESOC such as ERS.

• Input file parsers do not rely on specific tools

Although most of the MPS input file parsers are written using bison++ and flex++, the system design decouples the file handlers from the tools used to generate a specific file parser, giving to the developer the flexibility of using other tools for file parsing.

• Successful re-use of the ERS HCI layouts

Although based on new technologies and completely different HCI model, the Envisat MPS HCI tries to borrow as much as possible from the HCI of the ERS MPS. This has greatly helped the operators, used to an ERS environment, when familiarising with the new system.

3

4 Possible improvements following Envisat operational useage A number of points have emerged during the many months of testing and operational useage, these items are listed below:

• High dependency of boundary conditions on planning rules and individual timelines

The MPS kernel keeps the history of all plans implemented in operation in a Master Plan. At creation of a new plan, boundary conditions at start and end of the new plan range are extracted from the Master Plan, and used as initial conditions for planning. The kernel originally implemented a fully generic mechanism to decide which condition to extract from the Master. This approach had to be partly revisited.

• High level of flexibility (C++ rules) may lead to lack of structure in rule modules

As already mentioned, the MPS planning rules are written in C++ by the development team. This approach does not constraint the developer to actually follow the rule-based approach when writing the code, and has led to complex functionality that should have been decomposed in the module design to be concentrated in a few rule action components. The maintainability of the rule module is in this case greatly affected. The development of a higher-level rule language, with direct use of C++ in dedicated case only, would hinder this.

• Database issues are still essential (performance for huge plan databases, cost, portability)

As already mentioned, the full planning history is kept in the Master Plan, which is queried for initial conditions at the beginning of each planning session. It was originally thought that these queries would only involve a fraction of the most recent history, but it has been demonstrated in operations that they can require to accessing information stored at a very early stage of the mission. The query mechanism, that was trying to take advantage of the distribution of the plan over time, will therefore be revisited to take this element into consideration.

The OODBMS selected for the development has also shown some performance limitations when accessing huge plan databases. These performance issues, together with its significant cost, and problems of portability to other platforms, will probably lead to its replacement in the long term.

5 The next target mission .. Mars Express (MEX) The next step of this process is to take the “operational kernel” achieved during the course of the Envisat development, and to use it as the heart of the next target mission.

Together with its Mars lander “Beagle 2”, MEX will be launched in June 2003 on a nominal 2 (Martian) year mission with the following scientific objectives

• Global high-resolution photo-geology

• Global spatial high-resolution mineralogical mapping of the surface

• Global atmospheric circulation and high-resolution mapping of atmospheric composition

• Subsurface structure at Km down to permafrost

• Interactions between the atmosphere and the subsurface

• Interaction of atmosphere with interplanetary medium

• Radio Science

• Lander data relay

4

The planning of all Orbiter activities must be done within the available budgets such as data and power – the latter being particularly critical for this mission, with the available margins being tight.

In addition, the lander will have the following objectives :

• Meteorology and climatology

• Geology, mineralogy and geochemistry

• Physical properties of atmosphere, surface layers and Exobiology

The main objectives of the Mission Planning System (MPS) are as follows :

• To check that external requests for observations, generated by Principal Investigators, and communicated (via the Science Operations Centre) in the form of Payload Operations Requests, do not exceed the resources ( e.g. power, data ) available to the spacecraft.

• To process the Lander (Beagle 2) operations according to requests for operations generated by the Lander Operations Centre in the form of Lander Operations Requests.

• To plan the Mars Express Lander Communications Package (MELACOM) according to the requests for operations in the form of Lander Contact Requests.

• To plan the Mars Express spacecraft operations according to the requests for operations generated by the Flight Control Team (FCT) in the form of Spacecraft Operations Requests

• To plan Mars Express Flight Dynamics Operations according to the requests for operations generated by the Flight Dynamics Team in the form of Flight Dynamics Requests

• To provide the Detailed Mission Operations Plan (DMOP) to inform all concerned parties of the Mars Express operations planned in response to their requests. In addition, a subset of planned operations will be reported via the Detailed Science Operations Plan (DSOP)

• To generate the command schedule for both the spacecraft and the ground station in accordance with the generated planning

• To generate timeline event information (“Operations Lists”) for use by the operators of the Mission Operation Centre (MOC) in accordance with the plan.

• To provide the Restituted Detailed Mission Operations Plan (RDMOP) to inform all request originators of the operations actually executed on-board the spacecraft with respect to the planned platform and payload operations (i.e. was planned event executed as expected, delayed, or failed to execute for some reason).

5

A diagram summarising the key interfaces to the MPS is shown below :

Note that the NCTRS (Network Controller and Telemetry Routing System) is responsible for transferring certain MPS outputs (Ground Station schedule) to the station at New Norcia.

Mars ExpressMission Control

System (MEMCS)

Mars Express Mission Operations Centre(MEMOC)

Transfers involving MPS directly Transfers not involving MPS directly

Systems external to the MEMOC

Generic Data DispositionSystem (GDDS)

MarsExpress

MissionPlanning

Subsystem(MPS)

FlightDynamicsSystem(FDS)

NCTRS

New Norcia

Figure 1 : key external interfaces to MEX MPS

6

6 Key differences with the new target mission There are a number of crucial differences between the new target mission, and the previous host planning system.

Each of these factors is discussed in the following sections:

6.1 Operational Requests to the system

Description of the change

As for all observation type missions, the concept exists whereby requests may be submitted in some form to the ground segment, for a particular instrument to be switched into a certain mode at a given time. The duration of the request will typically also be supplied, along with any key parameters that need to be specified (precise start or within a supplied bandwidth, swath information, downlink specification, etc).

For the Envisat mission, the Preferred Exploitation Plan (or PEP) requests are tied very closely to the actual instrument modes that are required. As an example :

Request type “ASA_IM” requests that the instrument “ASAR” is switched into “Image” mode at the given time, the supplied parameters defining further the required imaging. Under this scheme, the planning system translates the incoming requests into activities via the Service mechanism (all mappings being held within the configuration database). These activities are attached to the plan object that the user is currently working with.

However, for Mars Express, the so-called “Operational Requests” arrive in the form of actual command sequences that are known to the Mission Control System. Under this configuration, it is possible to pass the request files directly to the Control System – the so-called Direct Operations Request (DOR) file does just this, being sent to the Telecommanding subsystems of the Mission Control System.

The Command Request Interface Document (CRID) also allows requests to specify ground station jobs, such requests being destined for the schedule file sent by the planning system to the Ground Station.

The Mission Planning System takes these requests in, translates them into activities that are attached to the current “plan”, and then proceeds to modify the various resource profiles that are also associated to the current plan. Once all requests have been serviced, the actual resource profile may be checked for any violations.

Impact on the kernel

The Service subsystem of the kernel has therefore been updated to allow for input requests in this form, the planning system retaining (within its own configuration database) a snapshot of the current Mars Express Operational Database (MEODB) being used to populate the “Service” aspects of the configuration database, such that only valid command sequences are allowed as requests.

Furthermore, the ability to create service definitions that, in turn, refer to an existing service definition, will be added. In this way, sequences may be decomposed to commands, which in turn result in activities.

7

6.2 Operational Requests supplying resource information


A further change to the input request mechanism was introduced by the fact that a given input request may specify the effect of that request on a given resource, using a special parameter (the so-called ‘Z’ parameter). Within the current scope of the interface, the resources that are affected are power consumption and generated data. This facility available within the previous version of the kernel (the so-called “resource effects”) fell slightly short of what was needed here, as the resource effects associated with a given request may not necessarily be determined from the state information (typically duration) as specified by the request, as is the case for Envisat.


The planning kernel has been updated to allow for certain input parameters being recognised as “resource effect” parameters, whose value must be extracted and used to modify the given resource profile. However, the existing arrangement whereby a resource effect may be associated to the “state” of one of the Mission Elements remains, to allow for resource modelling due to events not originating from an input request. As an example, the state “Sunlight” has an effect on the power resource, due to the action of the Solar Array.

6.3 Date and time conventions


A new time date convention has been adopted by the Mars Express mission, the so-called “ONOP” format (for Orbit Number & Offset to Pericentre). Under this convention, the orbit number is counted from the orbit apogee, the offset being specified with respect to the perigee. In this way, the offset may be positive or negative. Furthermore, the source of orbital event data used for conversions to / from UTC has also changed – this item typically being mission dependent.


The time and date classes of the kernel have been updated to handle the “ONOP” type arrangement. In addition, a level of indirection has been introduced into the time conversion routines, with special handler classes being created as the interface with the mission orbital event information, rather than embedding the specifics within the date classes.

6.4 ‘Event based’ times, orbital corrections


The concept of ‘event based’ times has a stronger role in the Ground Segment for Mars Express. Times (for example, the time of a given request) may be tied to a particular event, with an associated offset. This concept does exist within the kernel, but limited in that the reference event can only be the Ascending Node Crossing (ANX) point, the start of the orbit. In the new scheme, any event that can be defined in the master ‘Event’ file may be referred to by another time. Furthermore, in order to allow for the specification of a single event, an ‘event count’ is associated to each incoming event.

This concept also comes to the fore in the area of “orbital timing” corrections. For the Envisat system, a set of discrete delta values are determined which are to be applied to the command timings already generated. For Mars Express, the original reference event is stored with each time, such that the time may be refreshed at any point in time by referring to the time of the event within the (regularly updated) event files. Within the envisaged planning cycle, the times will be refreshed shortly prior to the creation of the output Detailed Agenda Files (DAFs).

8


The software has been updated to support this mechanism, whereby a given instance (count) of an event may be specified as a time reference. Alternatively, all occurrences of a given type may be specified.

6.5 Change of Interface to the Mission Control System (MCS)


For the Envisat-1 mission, the Flight Operations Control Centre (FOCC) is based on the SCOS-1B infrastructure software, this infrastructure being developed by ESA/ESOC for the purpose of supporting multiple missions. However, for some years now, the control systems being developed for new ESA missions make use of the new SCOS-2000 infrastructure. Developed with object-oriented techniques and modern languages, many changes are brought in by the use of the new infrastructure.

The MCS for the Mars Express mission is based on the corresponding system being developed for the Rosetta mission - which is, in turn, based on the SCOS-2000 infrastructure. From the point of view of the MPS, there are a number of important changes.

• The (ASCII) database files respresenting the content of the operational runtime database have a different format compared with the SCOS-1 version. The kernel has been upgraded such that the so-called Mission Information Base (MIB) files can be imported into the planning system configuration database.

• The format of the files containing scheduling information, created by the MPS and sent to the MCS, has changed. The MPS now creates so-called “Detailed Agenda Files” (or DAFs), which are to be loaded onto the command stacks of the MCS.


The software responsible for the import of the ASCII files (as exported by the MCS) into the MPS configuration database has been revised to support the Mission Information Base (MIB) files of SCOS-2000. In addition, although currently implemented for SCOS-2000, changes have been made to facilitate the import of information from other Mission Control Systems (where ASCII files used to implement the interface).

The modules responsible for generating the outputs of the planning system have been updated to match the characteristics of the new mission. Although some aspects are mission specific, efforts have been made within the kernel to ensure that the output of the planing system is highly configurable.

7 Refinements made for the new kernel As well as those changes enforced by the new target mission, a number of further updates have been made to to the kernel. Some of these are the result of extensive experience of using the system in an operational context, others have been made to take advantage of “state of the art” techniques.

7.1 Tools to assist repeated System Testing

In order to assist the Mission Planner with the testing of new deliveries of the system, the kernel will provide test tools that run pre-defined test scenarios using a set of input data, the output of the test tool being compared against a set of known “good” test results, to ensure that the new delivery has not introduced changes to the results obtained with the previous release.

9

7.2 Configuration database default population

The original kernel was designed for flexibility, the resulting planning system for Envisat taking advantage of these features, in order to provide a system with a high degree of user configurability.

However, a number of shortcomings were identified in the course of the first months of operational testing and usage, efforts have been made to to address these limitations.

The first of these shortcomings was the “core” database configuration, it not being possible (with the provided tools) to modify all objects of the database without software support (to modify the initialisation code). Under the new scheme, all objects entering the configuration database are held in ‘XML’ files, these files to be ingested at the database population stage.

An example file is shown below : 

<systemElement name = "HRSC">



<mode name = "Break">

&minParam;

</mode>

<mode name = "Standby">

&minParam;

</mode>

<startMode>off</startMode>

<endMode>off</endMode>



<transition from = "on" to = "initialise" duration = "2000">

<mapping cmdName = "AHRF002A" />

</transition>

<transition from = "STATE_WILDCARD" to = "heater" duration = "10000">

<mapping cmdName = "AHRF007A" />

</transition>

<parameter name = "conversionFactor" valueType = "int">

<value type = "EUTILintValue" value = "24" />

</parameter>

</systemElement>

The ‘xerces’ XML (SAX) compiler has been integrated into the kernel in support of this functionality.

10

7.3 Improved graphical timeline displays

The Ganntt displays used for the visualisation of the planning timelines are to be expanded, such that the Resource profiles can be displayed alongside the basic “Activities” that are currently represented on the display. In this way, the profile of a given resource ( power, data, etc ) can be viewed alongside the activities that actually affect the given profile.

7.4 Move to 64 bit application under Solaris 8

As a new development, the project is being targeted at the Solaris 8 platform. In order to maximise the benefit of this operating environment, the decision has also been taken to move to a 64 bit application, to increase the addressing range available to the planning system.

7.5 Move to new ANSI C++ standard

In connection with the previous point, the new operating system comes with the latest compilers and development tools (Forte C++ 6 with compiler version 5.3). The kernel is being transitioned to the new ANSI C++ standard, as opposed to being built using the available compatibility mode.

7.6 Move away from commercial database

A major shift has taken place in the area of the database management system, the kernel previously utilising a commercial database offering. However, it has been decided that the benefits to the MPS provided by this tool did not justify its cost, bearing in mind that only a subset of its capabilities were actually being used by the MPS. Therefore, a freeware offering that supports the handling of persistent objects has been taken on board (the same software that is now being used as part of the SCOS-2000 control system infrastructure).

In addition, the kernel software has been revised to provide a better interface to the database subsystem, such that future changes to the chosen DBMS can be implemented more quickly.

8 Ideas for future expansion to the kernel Discussed below are a number of further improvements that could be integrated into the kernel :

• Development of high-level Query language to improve system configurability

A high-level Query language will allow the mission planners to express constraints that they want fulfilled by the generated plan. These constraints can then be used in generic rules to ensure the global consistency of the plan after refinement. It will also make easier the development and integration of new rule-based modules, and can be the basis for an actual rule language for planning. The query language will especially concentrate on the temporal dependencies and that can have to be checked between activities and events.

• Improved planning of Ground Segment activities (independent on-board/on-ground planning windows)

The MPS kernel currently concentrates on spacecraft and ground station planning within a given time window. Ground Segment planning in for the time being limited and in a way decoupled from the spacecraft activities planning. More elaborated Ground Segment planning is foreseen, enabling the automated generation of on-ground schedules maintaining mapping between on-board / on-ground planning windows and references to spacecraft and ground-station scheduling products in Ground Segment schedules.

• Integration of Constraint Satisfaction Problem (CSP) resolution layer

A limited CSP layer will be integrated to the MPS kernel in order to provide the basics for the development of optimisation algorithms for observation planning.

• Porting of the software to other platforms and environments (e.g. LINUX)

11

9 Conclusions A Generic Mission Planning Kernel has emerged from the reuse of the Generic Mission Planning Facility study results in the development of the Envisat Mission Planning System. This kernel has been successfully used in the production of the MEX Mission Planning System, allowing for the development of the system within very tight schedule and budget constraints.

The specific needs of the MEX Mission Planning System have led to extending the kernel in the course of development to generalise concepts such as time references or the interface to the Mission Control System, which is now compatible with SCOS-2000. The re-use of the kernel on a platform different from the Envisat one has resulted in a general improvement of the portability of the system.

Lessons learned from the Envisat Mission Planning System development have been taken as input to the MEX Mission Planning System development, leading to revisiting the database concept and implementation.

The application of GMPK to the MEX mission has extended its capability outside the specific area of Earth Observation mission planning, for which it was originally designed. New areas of improvement or extension to the kernel have been identified, which will be addressed in the course of future developments.

From an operational perspective, building the MEX MPS on top of the Generic Mission Planning Kernel provides the MEX mission planners with a tool whose Man-Machine Interface is very similar to the Envisat MPS one, and which is based largely on the same concepts. This will ensure a simple transition to MEX Mission Planning for the ESOC mission planners familiar with Envisat planning, and simplify the training and assignment of operational staff to the missions.

We can therefore conclude that the approach taken of a kernel of Mission Planning functionality maintaining in the course of successive specific developments has proven successful, with development times and costs needed to produce mission planning systems for new missions being considerably reduced.

10 Bibliography [1] R.Monk et al., Study on Generic Mission Planning Facilities for Operations (GMPF) Final

Report, Ref. GMPF-FR-01, Issue 1.0, January 1997.

[2] J.Wheadon et al., ATOS-4, Advanced Technology in Spacecraft Mission Operations, Proc. Int. Sym. Ground Systems for Space Mission Operations. SPACEOPS ‘98, Tokyo, June 1998.

[3] M.Niézette, Mission Planning for Earth Observation Missions, Proceedings of the Second NASA International Workshop on Planning and Scheduling for Space, San Francisco, March 2000.

[4] I.Shaw, M.Niézette et al., Mission Planning for Europe's latest earth observer, Proc. Int. Sym. Ground Systems for Space Mission Operations. SPACEOPS 2000, Toulouse, June 2000.

[5] M.Niézette, I.Shaw, et al., Envisat FOS Mission Planning System Architectural Design Document, Issue 2 Revision 0, May 15th 1998.

[6] I.Shaw, Erik Noréus, Mars Express Mission Planning System Architectural Design Document, Issue 1 Revision 1, April 30th 2002.

[7] Object Oriented Modelling and Design, J Rumbaugh, M Blaha, W Premerlani, F Eddy & W Lorensen, Prentice Hall International, 1991.

[8] The Unified Method, Issue 1.0, Rational Software Corporation, presented to Object Management Group (OMG) January 1997.

[9] Guide to applying the ESA software engineering standards to projects using Object-Oriented Methods, BSSC(97)2, Issue 1.3, September 1997.

Documents

[American Institute of Aeronautics and Astronautics SpaceOps 2002 Conference - Houston, Texas (10 October 2002 - 19 October 2002)] SpaceOps 2002 Conference - A New World for the Generic