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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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