Message Abstraction Layer

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.

The CCSDS Message Abstraction Layer (MAL) provides message abstraction and generic service patterns to the Mission Operation (MO) services defined in the CCSDS Mission Operations Services Concept.[1]

Service Layering

A key feature of the MO 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 MO 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) Layer
  • The Common Services Layer
  • 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.

Message Abstraction

To provide implementation language and message transport independence all operations of a service must be defined by a language/platform/encoding agnostic specification. The MAL defines this set of basic data types and how they must be used to build up the messages that make up the operations of a service. This only then has to be mapped once, in an MO standard, to a specific implementation language or transport encoding to apply to all services that are defined in terms of the MAL. In addition to the patterns of interaction and the abstract API the MAL provides support for the following: – generic concepts, such as domain, session and zone; – generic facilities such as access control (authentication and authorisation) and Quality of Service.

Patterns of interaction

An operation of a service can be decomposed to a set of messages exchanged between a service provider and consumer and form a pattern of interaction. Analysis of the services given in reference[1] shows that there are a limited number of these patterns of interaction that can be applied to all currently identified services. Standardising a pattern of interaction, which defines the sequence of messages passed between consumer and provider, makes it possible to define a generic template for an operation of a service. The MAL defines this limited set of generic interaction patterns (templates) that must be used by services defined in the MO service framework. Each operation of a service is defined in terms of one of the MAL interaction patterns. By defining a pattern and stating that a given operation is an example of that pattern, the operation definition can focus on the specifics of that operation and rely on the standard pattern to facilitate this. For example, an operation ‘doFoo’ may be defined that is an example of a pattern called ‘SUBMIT’. This operation has two parts, the pattern of messages that are exchanged (the ‘SUBMIT’ pattern) and the meaning of those messages and what ‘doFoo’ does. By defining the pattern as a standard (‘SUBMIT’) the service specification that defines ‘doFoo’ only need define the meaning of the messages and what the operation does. The MAL defines this set of patterns.

Advantages

A benefit of implementing multiple services over a message abstraction layer is that it is easier to bind these to different underlying technologies and protocol encodings. All that is required is an ‘adapter’ layer between the MAL and the underlying protocol to enable all services over that technology. Hence the same service can be implemented over ground-based network technologies and middleware, or it could even be carried across the space link itself. The services themselves provide the ‘plug-and-play’ interface for applications, allowing them to be integrated and deployed wherever is appropriate for the mission.

There are no performance overheads as the MAL layer is conceptual and can be optimized out using code generators.[2]

Disadvantages

The MAL will not support features of the underlying protocol beyond the "least common denominator" defined in the MAL. Messaging features (e.g. threading model, QoS, etc.) are limited to a simpler subset that represent the intersection of all of the underlying middleware options. However, feature of an underlying protocol may be selected through configuration.

An adapter layer between MAL and the underlying protocol, plus specifications for language bindings, are still required. Implementations must adhere to these specifications for interoperability. Thus MAL takes on the characteristics of becoming new middleware standard in itself.

The MAL adapters and the MAL language binding specifications must be maintained as the underlying middleware standards for the plug-ins evolve. However, the use of the MAL removes any direct dependence of the application on the protocol technologies and therefore it is possible to isolate any evolution to lower adapter layers.

MAL precludes the use of service contracts as the centerpiece defining a data-driven service architecture.

Implementations

Two independent implementations are required by CCSDS procedures, these have been implemented by ESA and CNES. Both Agencies are working towards releasing under open source licences.

gollark: Of course you can.
gollark: If you randomly tweak some code until it works, that's... an example of that.
gollark: You totally can.
gollark: Microcrafting is where you need to make an excessive amount of subcomponents to make an item.
gollark: If, of course, you can actually place liquids with drones...

References
  1. Mission Operations Services Concept Archived 2013-05-31 at the Wayback Machine, CCSDS 520.0-G-3. Green Book. Issue 3. December 2010
  2. Mission Operations Future Trends


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.