CCSDS Mission Operations

There is a general trend toward increasing mission complexity at the same time as increasing pressure to reduce the cost of mission operations, both in terms of initial deployment and recurrent expenditure. Closed, or ‘monolithic’ mission operations system architectures do not allow the re-distribution of functionality between space and ground, or between nodes of the ground system. This lack of architectural openness leads to: • lack of interoperability between agencies; • lack of re-use between missions and ground systems; • increased cost of mission specific development and deployment; • unavailability of commercial generic tools; • inability to replace implementation technology without major system redesign; • lack of operational commonality between mission systems, increased training costs. The result is many parallel system infrastructures that are specific to a given family of spacecraft or operating agency, with little prospect of cross-fertilisation between them. == The service framework approach ==

Service-oriented architecture (SOA) is gradually replacing monolithic architecture as the main design principle for new applications in both private and distributed systems. It is one of the fundamental design principles of network distributed applications where the interfaces, both operations and data objects, must be well defined as the clients are often heterogeneous. SOA is an approach to system design that relies not on the specification of a monolithic integrated system, but instead on the identification of smaller, modular components that communicate only through open, published, service interfaces. The SM&C WG is defining a set of standard services, which constitutes a framework that enables many similar systems to be assembled from compliant ‘plug-in’ components. These components may be located anywhere, provided they are connected via a common infrastructure. This allows components to be re-used in different mission-specific deployments: between agencies, between missions, and between systems. If services are specified directly in terms of a specific infrastructure implementation, then they are tied to that technology. Instead, by layering the services themselves, the service specifications can be made independent of the underlying technology. Specific technology adapters enable the deployment of the service framework over that technology. This in turn makes it possible to replace the infrastructure implementation as well as component implementations. It is also possible to transparently bridge between different infrastructure implementations, where these are appropriate to different communications environments (e.g., space or ground) or simply reflect different agencies’ deployment choices. NOTE – Plug-in components communicate only via standard service interfaces through a common infrastructure. The service framework is itself layered and independent of the underlying infrastructure implementation. It is also important to note that the approach does not prescribe the components themselves or their implementation. Only the service interfaces between components are standardised. This allows for innovation, specialisation and differentiation in components, while ensuring they can be rapidly integrated into a system. However, for the service framework to be effective it must ensure that meaningful information associated with mission operations can be exchanged across the service interfaces, not merely data. The service framework must also respect legacy systems. Where an integrated legacy system performs the function of several service framework components, its internal architecture and implementation do not have to be changed. Only those interfaces it exposes to other systems need be ‘wrapped’ to make them compliant with the corresponding service interfaces. The service framework offers a range of interoperable interfaces, from which the most appropriate can be selected: compliance is not dependent on supporting them all. In this way legacy systems can be re-used in conjunction with other compliant components to build a mission specific system. The approach is intended to be Evolutionary and not Revolutionary. == Service layering ==

A key feature of the Mission Operations Service Framework [1] is the layering of services. While there are a range of potential services identified corresponding to different types of mission operations information that are exchanged within a system (status parameters, control actions, orbital data, mission timelines, etc.), these application level services are implemented in terms of a smaller set of generic interaction patterns that allow current status to be observed, operations to be invoked and bulk data transferred. This has two key benefits: it is inherently extensible, as new services can be overlaid on the existing common services; and the investment made in Mission Operations applications is further isolated from the implementation technology. Technology adapters allow the underlying communications infrastructure to be changed (or bridged) with minimal impact on the applications themselves. This improves long-term maintainability, as missions often outlive the ground technology used to deploy them initially. The layers of the Mission Operations Service Framework [1] are: • The Mission Operations (MO) Services Layer (which includes the MO Common Services) • The Message Abstraction Layer (MAL) • A message transport layer The interface between each layer is defined in the CCSDS standards and therefore implementations of the each layer can be replaced without change to other software. == Potential benefits ==

Standardisation of a Mission Operations Service Framework [1] offers a number of potential benefits for the development, deployment and maintenance of mission operations infrastructure: • increased interoperability between agencies, at the level of spacecraft, payloads, or ground segment infrastructure components • standardisation of infrastructure interfaces, even within agencies, leading to re-use between missions and the ability to establish common multi-mission infrastructure, therefore reducing training costs of operational teams and time to prepare new missions • standardisation of operational interfaces for spacecraft from different manufacturers • reduced cost of mission-specific deployment through the integration of re-usable components • ability to select the best product for a given task from a range of compatible components • greater flexibility in deployment boundaries: functions can be migrated more easily between ground segment sites or even from ground to space • standardisation of a limited number of services rather than a large number of specific inter-component interfaces • increased competition in the provision of commercial tools, leading to cost reduction and vendor independence • improved long-term maintainability, through system evolution over the mission lifetime through both component and infrastructure replacement. == Mission operations ==

The term mission operations (MO) is used to refer to the collection of activities required to operate spacecraft and their payloads. It includes: • monitoring and control of the spacecraft subsystems and payloads • spacecraft performance analysis and reporting • planning, scheduling and execution of mission operations • orbit and attitude determination, prediction and manoeuvre preparation • management of on-board software (load and dump) • delivery of mission data products. These are typically regarded as the functions of the Mission Control Centre (MCC) and are performed by the mission operations team, supported by the Mission Operations System. MO include the capability to archive and distribute mission operations data. While this may include the handling of mission data products, activities specifically concerned with the exploitation of mission data (such as mission specific data processing, archiving and distribution) are considered outside the scope of MO. Increasingly, MO functions may be distributed between collaborating agencies and ground segment sites, or partially delegated to autonomous functions on board the spacecraft itself. The MO Service Framework is concerned with end-to-end interaction between MO application software, wherever it may reside within the space system. It is specifically not concerned with the provision of services for data transport or persistence (storage). It is, however, a user of such services. == See also ==