*** Welcome to piglix ***

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.

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.

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.


...
Wikipedia

...