CCSDS Mission Operations

The Spacecraft Monitoring & Control (SM&C) Working Group of the Consultative Committee for Space Data Systems (CCSDS), which sees the active participation of 10 space agencies and of the Space Domain Task Force of the Object Management Group (OMG), is defining a service-oriented architecture consisting of a set of standard end-to-end services between functions resident on board a spacecraft or based on the ground, that are responsible for mission operations.

Identification of the problem

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:

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

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:

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.

References

[1] Mission Operations Services Concept. CCSDS 520.0-G-3. Green Book. Issue 3. December 2010 http://public.ccsds.org/publications/archive/520x0g3.pdf

This article is issued from Wikipedia - version of the 1/12/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.