Mission Operation (MO) Services SM&C-MIA Joint Meeting ESTEC, 27 October 2009 Mario Merri, ESA

Distributable Mission Operations Functions Spacecraft M&C (Status, Control) On-board Software Automation (Procedures, Timelines) Planning (Tasks, Goals) Mission Data (Products) Flight Dynamics (Orbit, Attitude) Payload/Science Team Mission Control Centre Payload Data Centre Mission Operations Services: Organisational Boundaries Functional Boundaries System Boundaries Long-Term Data Persistence Mission Operations are achieved by orchestrating a number of distributed functions in order to achieve the desired results. In the most simple configuration, a space mission consists of a Spacecraft and a Mission Control Centre <CLICK>In the classical configuration, the functions for operating the spacecraft reside in the Mission Control Centre and they typically include <READ LIST> <CLICK>Of course, some of these functions must interact with their counterpart on-board to properly functions. For instance, the M&C function receives HK TM from the S/C and send TC to the S/C, Mission data handling function needs payload data that are collected on-board and on-board SW may be managed via dump and upload of new SW. <CLICK>In the future, with the advent of more advance technology and more challenging missions, some functions that traditionally reside on the ground will migrate on-board. For instance, for deep space missions will more and more need planning/scheduling/automation function on-board, or missions carrying location devices such as GPS will be able to estimate Flight Dynamics information such as their orbits. These functions would also automatically extend to landers in case of more complex missions. <4 CLICKS>Similarly, some of these functions are also used in other parts of the ground segment, for instance by the S/C Manufacturer, by the Payload/Science Teams, by the Payload Data Centre and by the Scientific community. For instance, the Mission Control Centre may act as a provider of HK TM in pretty much the same manner as it acts as consumer of HK TM from the S/C. <CLICK>The SM&C WG has recognised that these interfaces are common to most missions and has devised a number of Mission Operations services that need standardisation. As also shown in the picture, these services goes across organisation and system boundaries and as such require to be specified in a way that is not bound to a particular technology, maybe used only by a single organisation. Additionally, most organisation do have already systems that perform many of these functions and therefore it is necessary to identify means to be able to re-use these systems. Finally, I would like to point out that all the proposed services are application-level services, i.e. the information that is transferred between provider and consumer contains the semantic of the service. To operate a mission it is not enough to enable the communication between elements. Spacecraft Manufacturer 27/10/2009 CCSDS SM&C-MIA Joint Meeting

Candidate Services: Information Classes Operationally Meaningful Information Exchange: Status [Monitoring Parameter] Control Directive Event Notification Operator Interaction Automated Activity Scheduled Timeline or Activity List Planning Request: Task or Goal Trajectory and Pointing Predicted Events Mission Product Time On-board Software Image M&C Automation Planning Flight Dynamics From the previous chart, one can easily identify some operationally meaningful information exchanges. For instance, TM parameters are exchanged to know the Status of the S/C, TCs are uploaded to provide Control Directive, Events are exchange to notify that something has happened, for instance that a parameter went OOL, and maybe an alarm is raised to alert the Operator. <CLICK>All these operationally meaningful information exchanges could be grouped into a service that we call M&C Service. <CLICK>Similarly, other operationally meaningful information exchanges could be grouped in other services … Mission Products Time On-board Software 27/10/2009 CCSDS SM&C-MIA Joint Meeting

MO Services Architecture (an example) Mission Exploitation User Tracking & Ranging Mission Planning Mission Data Processing External User Station M&C Station Scheduling Products M&C Reports Interact. Time Location Flt. Dyn. Planning OCC Operations Planning Flight Dynamics Operations Automation Operator Interaction Analysis & Reporting OB Software Management SLE-Man Schedule Software Autom. Spacecraft M&C Proxy OB Schedule Proxy OB Procedure Proxy OB Data Product Proxy OB Software Proxy The figure illustrates the concept of a set of end-to-end application level MO services for the monitoring and control of spacecraft. The core set of operational functions shown as ovals are the ones that exist, or may exist, in many current and future spacecraft control systems. The S/C is a provider of M&C service (usually this is done via a proxy which is the MCS in the OCC) while other fucntions such as Operation Interaction, Analysis & Reporting, … are consumer of this service. NOTES Interconnecting lines represent services that provide the end-to-end interface between functions. The Mission Operations services are shown as horizontal lines, each service in a different colour. The vertical connections to functions show those functions which are potential providers (line ends in a circle) or consumers of the service. Note that there can be multiple providers within the system, and functions can act as both provider and consumer. Other connections may be present in some systems. <2 CLICKS>These functions may be distributed between physical locations, organisations and systems in many different ways. Increasingly, part or all of these functions are being deployed on-board spacecraft. Ground Station Spacecraft OB Data Product Storage Spacecraft M&C OB Procedure Execution OB Schedule Execution OB Software 27/10/2009 CCSDS SM&C-MIA Joint Meeting

MO Framework Layers Consumer/Provider Common Services Application Layer Consumer/Provider Mapping to implementation language MO Services Layer Common Services Directory, Login, … Functional Services M&C, Planning, Scheduling, Time, … Abstract service specification defined in terms of the COM &M AL Common Object Model (COM) Identify, Definition, Occurrence, Status Generic service specification defined in terms of the MAL Message Abstraction Layer Messaging Abstraction Layer (MAL) Generic Interaction Patterns, Access Control, Quality of Service This slides provides some technical details on the engineering of the MO framework, which is one of the strong points. Functional services and Common services such as the Service Directory are exposed to applications. Services are implemented as extensions to a generic service template provided by the Common Object Model. The Common Object Model is defined in terms of the MAL which provides generic Messaging and interaction methods. Not all aspects of a Common/Functional Service are required to use the COM and therefore the service may bind to the MAL directly for certain operations. The Message Abstraction Layer provides interoperability between dissimilar implementations of the Mission Operations Service Framework because of the software language, and isolation from the underlying deployment technology. Abstract messaging infrastructure Transport Layer Mapping of the MAL to encoding and transport Messaging Technology 27/10/2009 CCSDS SM&C-MIA Joint Meeting

MAL Generic Interaction Patterns Services defined in terms of a set of Operations: Each defined by a “conversation” between Consumer and Provider Messages are specific to Service and Operation but the Pattern of Message Exchange is common across many Operations By defining Generic Interaction Patterns, specification and implementation of individual services is simplified MAL identifies 6 Interaction Patterns: SEND SUBMIT REQUEST INVOKE PROGRESS PUBLISH-SUBSCRIBE 27/10/2009 CCSDS SM&C-MIA Joint Meeting

Service-Oriented Architecture: Plug-in Components Services Components Our claim is that SOA will stop this mess. In fact, if we define a framework which allows different applications to exchange data and participate in business processes. These components are loosely coupled with the operating systems and programming languages underlying them. SOA groups functions into distinct services, which can be distributed over a network and can be combined and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. The proper definition of service interfaces implies that new component can be plugged-in into the infrastructure without re-engineering. MO Framework 27/10/2009 CCSDS SM&C-MIA Joint Meeting