ISO 18202:2015

Space data and information transfer systems — Mission operations message abstraction layer

ISO 18202:2015 defines, in an abstract manner, the MAL in terms of: a) the concepts that it builds upon; b) the basic types it provides; c) the message headers required by the layer; d) the relationship between, and the valid sequence of, the messages and resulting behaviours. It does not specify: a) individual implementations or products; b) the implementation of entities or interfaces within real systems; c) the methods or technologies required for communications.

Systèmes de transfert des informations et données spatiales — Couche d'abstraction des messages des opérations de mission

General Information

• Status: Published
• Publication Date: 23-Nov-2015
• ICS: 49.140 - Space systems and operations
• Technical Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Drafting Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 14-Nov-2023
• Completion Date: 13-Dec-2025

Relations

• Consolidated By: ISO 11608-4:2022 - Needle-based injection systems for medical use — Requirements and test methods — Part 4: Needle-based injection systems containing electronics
• Effective Date: 06-Jun-2022
• Revises: ISO 18202:2013 - Space data and information transfer systems — Mission operations message abstraction layer
• Effective Date: 05-Nov-2015

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 18202
Second edition
2015-12-15
Space data and information transfer
systems — Mission operations message
abstraction layer
Systèmes de transfert des informations et données spatiales — Couche
d'abstraction des messages des opérations de mission

Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 18202 was prepared by the Consultative Committee for Space Data Systems (CCSDS) as
CCSDS 521.0-B-2, March 2013 and was adopted without modifications except those stated in Clause 2 of this
International Standard by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee SC 13,
Space data and information transfer systems.

Recommendation for Space Data System Standards
MISSION OPERATIONS
MESSAGE
ABSTRACTION LAYER
RECOMMENDED STANDARD
CCSDS 521.0-B-2
BLUE BOOK
March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
AUTHORITY
Issue: Recommended Standard, Issue 2
Date: March 2013
Location: Washington, DC, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS documents is detailed in Organization and Processes for
the Consultative Committee for Space Data Systems, and the record of Agency participation
in the authorization of this document can be obtained from the CCSDS Secretariat at the
address below.
This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 521.0-B-2 Page i March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommended Standards and are
not considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither
this Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than three years from its date of issuance, this Recommended Standard will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be
non-CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 521.0-B-2 Page ii March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
FOREWORD
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS shall not be held responsible for identifying any or all such
patent rights.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-3). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 521.0-B-2 Page iii March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking
and Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 521.0-B-2 Page iv March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
DOCUMENT CONTROL
Document Title Date Status
CCSDS Mission Operations Message October Original issue
521.0-B-1 Abstraction Layer, Recommended 2010 (superseded)
Standard, Issue 1
CCSDS Mission Operations Message March 2013 Current issue (note):
521.0-B-2 Abstraction Layer, Recommended – addresses the request
Standard, Issue 2 to add a slight
restriction to the MAL
data model regarding
polymorphism;
– adds ability to use
external data type
specifications such as
XML Schemas;
– moves XML to the
SANA registry;
– changes type short
forms to integers rather
than strings;
– shows optional fields
in composites;
– changes lists to a
template rather than
explicit types;
– adds unsigned integer
and File data types.
NOTE – Changes from the original issue are too numerous to permit markup.

CCSDS 521.0-B-2 Page v March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS
Section Page
1 INTRODUCTION . 1-1

1.1 GENERAL . 1-1
1.2 PURPOSE AND SCOPE . 1-1
1.3 DOCUMENT STRUCTURE . 1-1
1.4 DEFINITION OF TERMS . 1-2
1.5 NOMENCLATURE . 1-4
1.6 REFERENCES . 1-4

2 OVERVIEW . 2-1

2.1 GENERAL . 2-1
2.2 ABSTRACT INTERFACE SPECIFICATIONS . 2-1
2.3 ABSTRACT SERVICE SPECIFICATIONS . 2-8

3 ABSTRACT SERVICE SPECIFICATIONS . 3-1

3.1 OVERVIEW . 3-1
3.2 TRANSACTION HANDLING . 3-1
3.3 STATE TRANSITIONS . 3-1
3.4 MESSAGE COMPOSITION . 3-2
3.5 MAL SERVICE INTERFACE . 3-4
3.6 ACCESS CONTROL INTERFACE. 3-100
3.7 TRANSPORT INTERFACE . 3-104

4 MAL DATA TYPE SPECIFICATION. 4-1

4.1 OVERVIEW . 4-1
4.2 FUNDAMENTALS . 4-8
4.3 ATTRIBUTES . 4-9
4.4 DATA STRUCTURES . 4-14

5 MAL ERRORS . 5-1

6 SERVICE SPECIFICATION XML . 6-1

7 CONFORMANCE MATRIX . 7-1

ANNEX A SECURITY, SANA AND PATENT
CONSIDERATIONS (NORMATIVE) . A-1
ANNEX B DEFINITION OF ACRONYMS (INFORMATIVE) .B-1
ANNEX C INFORMATIVE REFERENCES (INFORMATIVE) . C-1
CCSDS 521.0-B-2 Page vi March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS (continued)
Figure Page
2-1 Message Exchange Sequence Example . 2-2
2-2 Request, Indication, and Message Relationship . 2-4
2-3 Consumer State Diagram Example . 2-5
2-4 Message Decomposition Key . 2-7
2-5 Message Header Decomposition Example . 2-7
2-6 Message Body Decomposition Example . 2-7
3-1 SEND Interaction Pattern Message Sequence . 3-4
3-2 SUBMIT Interaction Pattern Message Sequence . 3-8
3-3 SUBMIT Interaction Pattern Error Sequence . 3-9
3-4 SUBMIT Consumer State Chart . 3-10
3-5 SUBMIT Provider State Chart . 3-11
3-6 REQUEST Interaction Pattern Message Sequence . 3-16
3-7 REQUEST Interaction Pattern Error Sequence . 3-17
3-8 REQUEST Consumer State Chart . 3-18
3-9 REQUEST Provider State Chart . 3-19
3-10 INVOKE Interaction Pattern Message Sequence . 3-24
3-11 INVOKE Interaction Pattern Error Sequence . 3-25
3-12 INVOKE Consumer State Chart . 3-27
3-13 INVOKE Provider State Chart . 3-28
3-14 PROGRESS Interaction Pattern Message Sequence . 3-36
3-15 PROGRESS Interaction Pattern Error Sequence . 3-37
3-16 PROGRESS Consumer State Chart . 3-39
3-17 PROGRESS Provider State Chart . 3-41
3-18 PUBLISH-SUBSCRIBE Interaction Pattern Message Sequence . 3-53
3-19 PUBLISH-SUBSCRIBE Pattern Alternative Message Sequence . 3-54
3-20 PUBLISH-SUBSCRIBE Interaction Pattern Consumer Error Sequence . 3-59
3-21 PUBLISH-SUBSCRIBE Interaction Pattern Provider Error Sequence . 3-60
3-22 PUBLISH-SUBSCRIBE Consumer State Chart . 3-67
3-23 PUBLISH-SUBSCRIBE Broker to Consumer State Chart . 3-70
3-24 PUBLISH-SUBSCRIBE Provider State Chart . 3-72
3-25 PUBLISH-SUBSCRIBE Broker to Provider State Chart . 3-74
3-26 CHECK Access Control Pattern Message Sequence . 3-100
3-27 CHECK Access Control Pattern Error Sequence . 3-101
3-28 SUPPORTEDQOS Transport Pattern Message Sequence . 3-105
3-29 SUPPORTEDIP Transport Pattern Message Sequence . 3-108
3-30 TRANSMIT Transport Pattern Message Sequence . 3-111
3-31 TRANSMIT Transport Pattern Error Sequence . 3-112
3-32 TRANSMITMULTIPLE Transport Pattern Message Sequence . 3-115
3-33 TRANSMITMULTIPLE Transport Pattern Error Sequence . 3-116
3-34 RECEIVE Transport Pattern Message Sequence . 3-119
3-35 RECEIVEMULTIPLE Transport Pattern Message Sequence . 3-122

CCSDS 521.0-B-2 Page vii March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS (continued)
Table Page
2-1 Example Operation Template . 2-3
2-2 Example Primitive List . 2-4
2-3 Service Overview Table . 2-8
3-1 MAL Message Header Fields . 3-3
3-2 SEND Operation Template . 3-5
3-3 SEND Primitive List . 3-5
3-4 SEND Message Header Fields . 3-7
3-5 SUBMIT Operation Template . 3-9
3-6 SUBMIT Primitive List . 3-10
3-7 SUBMIT Message Header Fields . 3-13
3-8 Submit ACK Message Header Fields . 3-14
3-9 REQUEST Operation Template . 3-17
3-10 REQUEST Primitive List . 3-18
3-11 REQUEST Message Header Fields . 3-21
3-12 Request RESPONSE Message Header Fields . 3-22
3-13 INVOKE Operation Template . 3-26
3-14 INVOKE Primitive List . 3-26
3-15 INVOKE Message Header Fields . 3-30
3-16 Invoke ACK Message Header Fields . 3-31
3-17 Invoke RESPONSE Message Header Fields . 3-33
3-18 PROGRESS Operation Template . 3-38
3-19 PROGRESS Primitive List . 3-38
3-20 PROGRESS Message Header Fields . 3-44
3-21 Progress ACK Message Header Fields . 3-45
3-22 Progress UPDATE Message Header Fields . 3-47
3-23 Progress RESPONSE Message Header Fields . 3-50
3-24 PUBLISH-SUBSCRIBE Operation Template . 3-61
3-25 PUBLISH-SUBSCRIBE Register Operation Template . 3-61
3-26 PUBLISH-SUBSCRIBE Publish Register Operation Template . 3-62
3-27 PUBLISH-SUBSCRIBE Publish Operation Template . 3-62
3-28 PUBLISH-SUBSCRIBE Publish Error Operation Template . 3-62
3-29 PUBLISH-SUBSCRIBE Notify Operation Template . 3-62
3-30 PUBLISH-SUBSCRIBE Notify Error Operation Template . 3-63
3-31 PUBLISH-SUBSCRIBE Deregister Operation Template . 3-63
3-32 PUBLISH-SUBSCRIBE Publish Deregister Operation Template . 3-63
3-33 PUBLISH-SUBSCRIBE Primitive List . 3-66
3-34 REGISTER Message Header Fields . 3-77
3-35 REGISTER_ACK Message Header Fields. 3-78
3-36 PUBLISH_REGISTER Message Header Fields . 3-81
3-37 PUBLISH_REGISTER_ACK Message Header Fields . 3-82
3-38 PUBLISH Message Header Fields . 3-86
CCSDS 521.0-B-2 Page viii March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS (continued)
Table Page
3-39 PUBLISH_ERROR Message Header Fields . 3-87
3-40 NOTIFY Message Header Fields . 3-89
3-41 DEREGISTER Message Header Fields . 3-92
3-42 DEREGISTER_ACK Message Header Fields . 3-94
3-43 PUBLISH_DEREGISTER Message Header Fields . 3-95
3-44 PUBLISH_DEREGISTER_ACK Message Header Fields . 3-97
3-45 CHECK Operation Template . 3-101
3-46 CHECK Primitive List . 3-102
3-47 SUPPORTEDQOS Operation Template . 3-106
3-48 SUPPORTEDQOS Primitive List . 3-106
3-49 SUPPORTEDIP Operation Template . 3-109
3-50 SUPPORTEDIP Primitive List . 3-109
3-51 TRANSMIT Operation Template . 3-112
3-52 TRANSMIT Primitive List . 3-113
3-53 TRANSMITMULTIPLE Operation Template . 3-116
3-54 TRANSMITMULTIPLE Primitive List . 3-117
3-55 RECEIVE Operation Template . 3-120
3-56 RECEIVE Primitive List . 3-120
3-57 RECEIVEMULTIPLE Operation Template . 3-123
3-58 RECEIVEMULTIPLE Primitive List . 3-123
5-1 Standard MAL Error Codes . 5-1
7-1 Conformance Matrix . 7-1

CCSDS 521.0-B-2 Page ix March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
1 INTRODUCTION
1.1 GENERAL
This Recommended Standard defines the Mission Operations (MO) Message Abstraction
Layer (MAL) in conformance with the service framework specified in reference [C1],
Mission Operations Services Concept.
The MO MAL is a framework that provides generic service patterns to the Mission
Operation services defined in reference [C1]. These Mission Operations services are defined
in terms of the MAL.
1.2 PURPOSE AND SCOPE
This Recommended Standard defines, in an abstract manner, the MAL in terms of:
a) the concepts that it builds upon;
b) the basic types it provides;
c) the message headers required by the layer;
d) the relationship between, and the valid sequence of, the messages and resulting behaviours.
It does not specify:
a) individual implementations or products;
b) the implementation of entities or interfaces within real systems;
c) the methods or technologies required for communications.
1.3 DOCUMENT STRUCTURE
This Recommended Standard is organised as follows:
a) section 1 provides purpose and scope, and lists definitions, conventions, and
references used throughout the Recommended Standard;
b) section 2 presents an overview of the concepts;
c) section 3 specifies the interaction patterns used to define services;
d) section 4 is a formal specification of the MAL data structures;
e) section 5 is a formal specification of the MAL errors;
f) section 6 is the formal service specification Extensible Markup Language (XML) schema;
g) section 7 is the formal compliance requirements of the MAL.
CCSDS 521.0-B-2 Page 1-1 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
1.4 DEFINITION OF TERMS
Software Component (component): A software unit containing the business function.
Components offer their function as Services, which can either be used internally or which
can be made available for use outside the component through Provided Service Interfaces.
Components may also depend on services provided by other components through Consumed
Service Interfaces.
Hardware Component: A complex physical entity (such as a spacecraft, a tracking system,
or a control system) or an individual physical entity of a system (such as an instrument, a
computer, or a piece of communications equipment). A Hardware Component may be
composed from other Hardware Components. Each Hardware Component may host one or
more Software Components. Each Hardware Component has one or more ports where
connections to other Hardware Component are made. Any given Port on the Hardware
Component may expose one or more Service Interfaces.
Service: A set of capabilities that a component provides to another component via an
interface. A Service is defined in terms of the set of operations that can be invoked and
performed through the Service Interface. Service specifications define the capabilities,
behaviour, and external interfaces, but do not define the implementation.
Service Interface: A set of interactions provided by a component for participation with
another component for some purpose, along with constraints on how they can occur. A
Service Interface is an external interface of a Service where the behaviour of the Service
Provider Component is exposed. Each Service will have one defined ‘Provided Service
Interface’, and may have one or more ‘Consumed Service Interface’ and one ‘Management
Service Interface’.
Provided Service Interface: A Service Interface that exposes the Service function contained
in a component for use by Service Consumers. It receives the MAL messages from a
Consumed Service Interface and maps them into API calls on the Provider component.
Consumed Service Interface: The API presented to the consumer component that maps
from the Service operations to one or more Service Data Units(s) contained in MAL
messages that are transported to the Provided Service Interface.
Management Service Interface: A Service Interface that exposes management functions of
a Service function contained in a component for use by Service Consumers.
Service System: The set of Hardware and Software Components used to implement a
Service in a real system. Service Systems may be implemented using one or more Hardware
and Software Components.
Service Provider (provider): A component that offers a Service to another by means of one
of its Provided Service Interfaces.
CCSDS 521.0-B-2 Page 1-2 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
Service Consumer (consumer): A component that consumes or uses a Service provided by
another component. A component may be a provider of some Services and a consumer of
others.
Service Data Unit (SDU): A unit of data that is sent by a Service Interface, and is
transmitted semantically unchanged, to a peer Service Interface.
Binding: The access mechanism for a Service. Bindings are used to locate and access
Service Interfaces. Services use bindings to describe the access mechanisms that consumers
have to use to call the Service. The binding specifies unambiguously the protocol stack
required to access a Service Interface. Bindings may be defined statically at compile time or
they may use a variety of dynamic run-time mechanisms (DNS, ports, discovery).
Service Capability Set: A grouping of the service operations that remains sensible and
coherent, and also provides a Service Provider with an ability to communicate to a Consumer
its capability. The specification of services is based on the expectation that different
deployments require different levels of complexity and functionality from a service. To this
end a given service may be implementable at one of several distinct levels, corresponding to
the inclusion of one or more capability sets.
Service Connection (connection): A communications connection between a Consumed
Service Interface and a Provided Service Interface over a specific Binding. When a
component consumes the services of a provider component, this link is known as a Service
Connection (connection).
Service Extension: Addition of capabilities to a base Service. A Service may extend the
capabilities of another Service with additional operations. An extended Service is
indistinguishable from the base Service to consumers such that consumers of the base
Service can also be consumers of the extended Service without modification.
Protocol Stack: The stack of Protocol Layers required for communication.
Protocol Layer: The implementation of a specific Protocol. It provides a Protocol Service
Access Point to layers above and uses the Protocol Service Access Point of the layer below.
Protocol Service Access Point (SAP): The point at which one layer’s functions are provided
to the layer above. A layer may provide protocol services to one or more higher layers and
use the protocol services of one or more lower layers. A SAP defines unambiguously the
interface for a protocol that may be used as part of a Service Interface Binding specification.
Protocol: The set of rules and formats (semantic and syntactic) used to determine the
communication behaviour of a Protocol Layer in the performance of the layer functions. The
state machines that operate and the protocol data units that are exchanged specify a protocol.
Service directory: An entity that provides publish and lookup facilities to service providers
and consumers.
CCSDS 521.0-B-2 Page 1-3 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
NOTE – Strictly speaking, a directory is not required if a well-known service is to be
used; however, in most circumstances a directory provides required flexibility in
the location of services. Service location can be statically configured,
dynamically discovered through a service directory, or a combination of the two;
this is an implementation choice. The service directory is itself, by definition, a
service.
1.5 NOMENCLATURE
The following conventions apply throughout this Recommended Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.6 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
are encouraged to investigate the possibility of applying the most recent editions of the
documents indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommended Standards.
[1] Mission Operations Reference Model. Recommendation for Space Data System
Standards, CCSDS 520.1-M-1. Magenta Book. Issue 1. Washington, D.C.: CCSDS,
July 2010.
[2] “MIME Media Types.” Internet Assigned Numbers Authority.
http://www.iana.org/assignments/media-types.
NOTE – Informative references are listed in annex C.

CCSDS 521.0-B-2 Page 1-4 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
2 OVERVIEW
2.1 GENERAL
The MO service specifications detail a standard set of services. These services form a
contract between a consumer of a service and the provider of that service. Each operation of
a service has a set behaviour: a message is sent from the consumer to the provider to instigate
the operation, and zero or more messages can be exchanged thereafter depending on the
specific pattern and operation. This set of messages, and the pattern in which they are
exchanged, needs to be defined for each operation of each service.
An interaction pattern details a standard exchange pattern that removes the need for each
operation to detail its exchange pattern individually. By defining a pattern and stating that a
given operation is defined in terms of that pattern, the operation definition can focus on the
specifics of that operation and rely on the standard pattern to facilitate the interaction.
The MAL defines this set of standard interaction patterns as an abstract interface that is used
by the MO services. There are three abstract interfaces defined in the MAL specification: the
first is the abstract interface of the MAL that is presented to the higher layers, the second is
the abstract interface of the Access Control component, and the third is the abstract interface
that a Transport layer must provide to the MAL.
The MO service specifications and the MAL are abstract in their definition; they do not
contain any specific information on how to implement them for a particular programming
language or transport encoding. Moving from the abstract to the implemented system, two
other specifications are needed. One is the Language Mapping that states how the abstract
MAL and MO service specifications are to be realised in some specific language: this defines
the API in that language. The second is the transport mapping from the abstract MAL data
structures into a specific and unambiguous encoding of the messages and to a defined and
unambiguous mapping to a specific data transport. It is only when these mappings are
defined that is possible to implement services that use the MAL interface and use the
transport bindings to exchange data. (For further information on this, see reference [1].)
This document contains the formal specification for these abstract interfaces. More
information about the MO Concept can be found in reference [C1], and more information
about the Reference Model can be found in reference [1].
2.2 ABSTRACT INTERFACE SPECIFICATIONS
2.2.1 GENERAL
Each abstract interface is defined as a set of interaction patterns. For each pattern defined
there is a common layout of the document section.
The following subsections describe the sections and diagram formats specific to the
interaction patterns.
CCSDS 521.0-B-2 Page 2-1 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
2.2.2 PATTERN OVERVIEW
The overview section of the pattern contains a message exchange sequence, which shows the
interaction sequence between a source consumer and a destination provider.
The main aspects to note are the direction of the arrows (giving message direction) and the
order of the messages (top down). The bars under the consumer and provider show
synchronicity of the message exchange.
In the following example (figure 2-1) it can be seen that the consumer sends an initial
message to the provider, which responds with an acknowledgement. The acknowledgment is
in response to the initial message, as shown by the connected bars under the consumer and
provider.
At some time in the future the provider will send another response:
Consumer Provider
seq Message exchange example
initial message
some acknowledgment
asynchronous response
Figure 2-1: Message Exchange Sequence Example
Because the pattern shows the response, the consumer can expect it, but because the bars are
not connected it is considered to be indeterminate. This means that although the message
will arrive it cannot be determined when arrival will occur. It is important to note that any
synchronicity shown is concerned only with messages; it does not imply, or require, a
synchronous (blocking) behaviour in either the client or provider, as these are
implementation issues.
2.2.3 DESCRIPTION AND USAGE
The Description and Usage sections are used to describe the pattern and define the expected
usage respectively.
CCSDS 521.0-B-2 Page 2-2 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
2.2.4 ERROR HANDLING
The Error Handling section defines the positions in the pattern where errors are permitted to
be generated. It uses the same sequence diagram notation as the nominal pattern sequence
from the Overview section.
2.2.5 OPERATION TEMPLATE
Each interaction pattern definition contains a table that defines the template for operations
that use that pattern:
Table 2-1: Example Operation Template
Operation Identifier <>
Interaction Pattern <>
Pattern Sequence Message Body Type
<> <> <>
… … …
The message direction denotes the direction of the message relative to the provider of the
pattern and is either IN or OUT. So all messages directed towards the provider are IN
messages, and all messages directed away from the provider are OUT messages. It is
expected that message names match those defined in the Primitives section.
Blue cells (dark grey when printed on a monochrome printer) contain table headings, light
grey cells contain fields that are fixed for a pattern, and white cells contain values that must
be provided by the operation or structure.
The Body Type column contains the list of types that make up the Body of a particular
message. Zero to many types may be listed here and together define the body of the indicated
message.
This document defines a data type specification language in section 4 (referred to as the
MAL data types) that is expected to be the default data type specification language. The
Body Types are defined using the MAL data types to define the various base data types, the
notation used to describe them, and the rules for their combination into complex data
structures. This is separate from the encoding technology used which is responsible for
mapping the abstract data type notation from the data type specification into an actual ‘bits
and bytes’ representation.
CCSDS 521.0-B-2 Page 2-3 March 2013
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
Even though the Body Types in this specification are defined using the MAL data types, any
data type specification language (such as XML Schema) may be used in an actual service
specification.
2.2.6 PRIMITIVES
Each pattern defines a set of primitives in a table as below:
Table 2-2: Example Primitive List
Primitive
<>
For each listed primitive there exists a Request, Message and Indication of the same name.
The Requests and Indications are used by the following State Diagrams. Requests are
transitions t
...