Message Abstraction Layer

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

Contents

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

CCSDS SM&C layer diagram.png

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

Related Research Articles

The Internet protocol suite is the conceptual model and set of communications protocols used in the Internet and similar computer networks. It is commonly known as TCP/IP because the foundational protocols in the suite are the Transmission Control Protocol (TCP) and the Internet Protocol (IP). During its development, versions of it were known as the Department of Defense (DoD) model because the development of the networking method was funded by the United States Department of Defense through DARPA. Its implementation is a protocol stack.

OSI model Model of communication of seven abstraction layers

The Open Systems Interconnection model is a conceptual model that characterises and standardises the communication functions of a telecommunication or computing system without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols.

SOAP Messaging protocol for web services

SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to provide extensibility, neutrality, verbosity and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

The Jakarta Messaging API is a Java application programming interface (API) for message-oriented middleware. It provides generic messaging models, able to handle the producer–consumer problem, that can be used to facilitate the sending and receiving of messages between software systems. Jakarta Messaging is a part of Jakarta EE and was originally defined by a specification developed at Sun Microsystems before being guided by the Java Community Process.

In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.

Enterprise application integration (EAI) is the use of software and computer systems' architectural principles to integrate a set of enterprise computer applications.

Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services, provide interoperability between computer systems on the internet. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations. Other kinds of Web services, such as SOAP Web services, expose their own arbitrary sets of operations.

In object-oriented design, the dependency inversion principle is a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:

Open service interface definitions (OSIDs) are programmatic interface specifications describing services. These interfaces are specified by the Open Knowledge Initiative (O.K.I.) to implement a service-oriented architecture (SOA) to achieve interoperability among applications across a varied base of underlying and changing technologies.

In telecommunications, Multi-Technology Operations System Interface (MTOSI) is a standard for implementing interfaces between OSSs. Service providers (carriers) use multiple Operational Support Systems (OSS) to manage complex networks. Since the various parts of the network must interact, so must the OSSs. It is standardized by the Telemanagement ForuM . The TMF Frameworx provides a set of reference models that aid in analyzing and designing next generation BSS and OSS solutions that may utilize the MTOSI interface specifications.

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing, reliability and security.

Lightstreamer is a web-based asynchronous messaging project, implementing the WebSocket protocol, the Comet model, the push technology paradigm, and the real-time web practices.

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 space 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.

In intelligent networks (IN) and cellular networks, service layer is a conceptual layer within a network service provider architecture. It aims at providing middleware that serves third-party value-added services and applications at a higher application layer. The service layer provides capability servers owned by a telecommunication network service provider, accessed through open and secure Application Programming Interfaces (APIs) by application layer servers owned by third-party content providers. The service layer also provides an interface to core networks at a lower resource layer. The lower layers may also be named control layer and transport layer.

A communication protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules, syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

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.

WAMP is a WebSocket subprotocol registered at IANA, specified to offer routed RPC and PubSub. Its design goal is to provide an open standard for soft real-time message exchange between application components and ease the creation of loosely coupled architectures based on microservices. Because of this, it is a suitable enterprise service bus (ESB), fit for developing responsive Web applications or to coordinate multiple connected devices in the IoT.

The NanoSat MO Framework (NMF) is a software framework for nanosatellites based on CCSDS Mission Operations services. It facilitates not only the monitoring and control of the nanosatellite software applications, but also the interaction with the nanosatellite platform. This is achieved by using the latest CCSDS standards for monitoring and control, and by exposing services for common peripherals among nanosatellite platforms. Furthermore, it is capable of managing the software on-board by exposing a set of services for software management.

UAVCAN

UAVCAN is a lightweight protocol designed for reliable intra-vehicle communications using various communications transports, originally destined for CAN bus but targeting various network types in subsequent revisions.

References

  1. 1 2 3 4 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 [ permanent dead link ]


This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.