CCSDS Mission Operations

Last updated

The Spacecraft Monitoring & Control (SM&C) Working Group of the Consultative Committee for Space Data Systems (CCSDS), which sees the active participation of the main http://www.space.bas.bg/bg/procurement/files/pravilnik%20OP.PDF agencies, 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.

Contents

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

SM&C Components.JPG

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

CCSDS SM&C layer diagram.png

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.

See also

Related Research Articles

In software engineering, multitier architecture is a client–server architecture in which presentation, application processing and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.

<span class="mw-page-title-main">Interplanetary Internet</span> Model of Internet between planets

The interplanetary Internet is a conceived computer network in space, consisting of a set of network nodes that can communicate with each other. These nodes are the planet's orbiters and landers, and the Earth ground stations. For example, the orbiters collect the scientific data from the Curiosity rover on Mars through near-Mars communication links, transmit the data to Earth through direct links from the Mars orbiters to the Earth ground stations via the NASA Deep Space Network, and finally the data routed through Earth's internal internet.

<span class="mw-page-title-main">Department of Defense Architecture Framework</span> Enterprise architecture framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

The Satellite Control and Operation System 2000 (SCOS-2000) is the generic satellite Mission Control System (MCS) software infrastructure developed and maintained by the European Space Agency (ESA/ESOC) in collaboration with European industry and deployed for missions such as Radarsat 2, XMM-Newton, INTEGRAL, Cryosat, Mars Express, Venus Express, GOCE, Herschel, Planck, Rosetta, Cryosat-2, Galileo, MetOp, LISA Pathfinder, SWARM, Gaia, SENTINEL spacecraft, EXOMARS orbiters, METEOSAT Third Generation, Aeolus, BepiColombo, SOLO or EUCLID. Upcoming missions that will deploy SCOS-2000 include MetOp-SG and EarthCARE.

Frameworx is an enterprise architecture framework geared towards communications service providers.

The Spacecraft Monitoring & Control (SM&C) Working Group of the Consultative Committee for Space Data Systems, which sees the active participation of 10 space agencies and of the Space Domain Task Force of the Object Management Group, 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.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

<span class="mw-page-title-main">TAFIM</span>

Technical Architecture Framework for Information Management (TAFIM) was a 1990s reference model for enterprise architecture by and for the United States Department of Defense (DoD).

<span class="mw-page-title-main">NIST Enterprise Architecture Model</span> Reference model of enterprise architecture

NIST Enterprise Architecture Model is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments.

<span class="mw-page-title-main">Treasury Information System Architecture Framework</span>

The Treasury Information System Architecture Framework (TISAF) is an early 1990s Enterprise Architecture framework to assist US Treasury Bureaus to develop their Enterprise Information System Architectures (EISAs).

Operations support systems (OSS), operational support systems in British usage, or Operation System (OpS) in NTT, are computer systems used by telecommunications service providers to manage their networks. They support management functions such as network inventory, service provisioning, network configuration and fault management.

Network functions virtualization (NFV) is a network architecture concept that leverages IT virtualization technologies to virtualize entire classes of network node functions into building blocks that may connect, or chain together, to create and deliver communication services.

The Spacecraft Monitoring & Control (SM&C) Working Group of the Consultative Committee for Space Data Systems, which sees the active participation of 10 space agencies and of the Space Domain Task Force of the Object Management Group, 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.

In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users. As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. So, you should use microservice architecture only if your application is too complex to manage as a monolith. Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

<span class="mw-page-title-main">OPS-SAT</span>

OPS-SAT was a CubeSat by the European Space Agency (ESA), intended to demonstrate the improvements in mission control capabilities that will arise when satellites can fly more powerful on-board computers. The mission had the objective to break the cycle of "has never flown, will never fly" in the area of satellite control. It was the first CubeSat operated directly by ESA.

The NanoSat MO Framework (NMF) is an open-source software framework for small satellites based on CCSDS Mission Operations services.

oneM2M

oneM2M is a global partnership project founded in 2012 and constituted by 8 of the world's leading ICT standards development organizations, notably: ARIB (Japan), ATIS, CCSA (China), ETSI (Europe), TIA (USA), TSDSI (India), TTA (Korea) and TTC (Japan). The goal of the organization is to create a global technical standard for interoperability concerning the architecture, API specifications, security and enrolment solutions for Machine-to-Machine and IoT technologies based on requirements contributed by its members.

References

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