Message Abstraction Layer

From Wikipedia, the free encyclopedia

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 services defined in reference [1].

Contents

[edit] 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) 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.

[edit] 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 SM&C 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.

[edit] 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 SM&C 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.

[edit] 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.

[edit] References

[1] Mission Operations Services Concept. CCSDS 520.0-G-2. Green Book. Issue 2. August 2006 http://public.ccsds.org/publications/archive/520x0g2.pdf