ISO 18202:2013

INTERNATIONAL ISO
STANDARD 18202
First edition
2013-06-01
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 2013
©  ISO 2013
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
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – 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.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2. www.iso.org/directives
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. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
ISO 18202 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 521.0-B-1, September 2010) 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.

INTERNATIONAL STANDARD ISO 18202:2013(E)

Space data and information transfer systems — Mission
operations message abstraction layer
1 Scope
This International Standard defines the Mission Operations (MO) Message Abstraction Layer (MAL) in
conformance with the service framework specified in Mission Operations Services Concept, CCSDS 520.0-
G-3, Mission Operations Services Concept.
The MO MAL is a framework that provides generic service patterns to the Mission Operation services defined
in Mission Operations Services Concept, CCSDS 520.0-G-3. These Mission Operations services are defined
in terms of the MAL.
This International 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.
The scope and field of application are furthermore detailed in subclause 1.3 of the enclosed CCSDS
publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 521.0-B-1, September 2010, Mission operations message abstraction layer.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 521.0-B-1.
Pages i to vi
This part is information which is relevant to the CCSDS publication only.
Page 1-4
Add the following information to the reference indicated:
[1] Document CCSDS 520.1-M-1, July 2010, is equivalent to ISO 18201:2013.
3 Revision of publication CCSDS 521.0-M-1
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication CCSDS 521.0-
M-1. To this end, NASA will act as a liaison body between CCSDS and ISO.

2 © ISO 2013 – All rights reserved

Recommendation for Space Data System Standards
MISSION OPERATIONS
MESSAGE ABSTRACTION
LAYER
RECOMMENDED STANDARD
CCSDS 521.0-B-1
BLUE BOOK
September 2010
(Blank page)
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
AUTHORITY
Issue: Recommended Standard, Issue 1
Date: September 2010
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 the Procedures Manual 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-1 Page i October 2010
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 five 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-1 Page ii October 2010
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
FOREWORD
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 the
Procedures Manual for the Consultative Committee for Space Data Systems. 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-1 Page iii October 2010
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.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– Russian Federal Space Agency (RFSA)/Russian Federation.
– 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-1 Page iv October 2010
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
DOCUMENT CONTROL
Document Title Date Status
CCSDS Mission Operations Message October Current issue
521.0-B-1 Abstraction Layer, Recommended 2010
Standard, Issue 1
CCSDS 521.0-B-1 Page v October 2010
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  GENERAL . 3-1
3.2  TRANSACTION HANDLING . 3-1
3.3  STATE TRANSITIONS . 3-2
3.4  MESSAGE HEADER FIELD VALUES . 3-2
3.5  MAL SERVICE INTERFACE . 3-3
3.6  ACCESS CONTROL INTERFACE . 3-100
3.7  TRANSPORT INTERFACE . 3-105

4  MAL DATA TYPES . 4-1

4.1  OVERVIEW . 4-1
4.2  FUNDAMENTALS . 4-7
4.3  ATTRIBUTES . 4-8
4.4  DATA STRUCTURES . 4-12

5  MAL ERRORS . 5-1

6  SERVICE SPECIFICATION XML . 6-1

6.1  GENERAL . 6-1
6.2  SCHEMA RULES. 6-1
6.3  SERVICE XML SCHEMA . 6-1
6.4  MAL SERVICE XML . 6-9

CCSDS 521.0-B-1 Page vi October 2010
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS (continued)
Section Page
ANNEX A DEFINITION OF ACRONYMS (INFORMATIVE) . A-1
ANNEX B INFORMATIVE REFERENCES (INFORMATIVE) . B-1
Figure
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-3
3-2  SUBMIT Interaction Pattern Message Sequence . 3-7
3-3  SUBMIT Interaction Pattern Error Sequence . 3-8
3-4  SUBMIT Consumer State Chart . 3-9
3-5  SUBMIT Provider State Chart . 3-10
3-6  REQUEST Interaction Pattern Message Sequence . 3-15
3-7  REQUEST Interaction Pattern Error Sequence . 3-16
3-8  REQUEST Consumer State Chart . 3-17
3-9  REQUEST Provider State Chart . 3-18
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-54
3-19  PUBLISH-SUBSCRIBE Pattern Alternative Message Sequence . 3-55
3-20  PUBLISH-SUBSCRIBE Interaction Pattern Consumer Error Sequence . 3-60
3-21  PUBLISH-SUBSCRIBE Interaction Pattern Provider Error Sequence . 3-61
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-106
3-29  SUPPORTEDIP Transport Pattern Message Sequence . 3-109
CCSDS 521.0-B-1 Page vii October 2010
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS (continued)
Figure Page
3-30  TRANSMIT Transport Pattern Message Sequence . 3-112
3-31  TRANSMIT Transport Pattern Error Sequence . 3-113
3-32  TRANSMITMULTIPLE Transport Pattern Message Sequence . 3-116
3-33  TRANSMITMULTIPLE Transport Pattern Error Sequence . 3-117
3-34  RECEIVE Transport Pattern Message Sequence . 3-120
3-35  RECEIVEMULTIPLE Transport Pattern Message Sequence . 3-123

Table
2-1  Example Operation Template . 2-3
2-2  Example Primitive List . 2-3
2-3  Service Overview Table . 2-8
3-1  MAL Message Header Fields . 3-2
3-2  SEND Operation Template . 3-4
3-3  SEND Primitive List . 3-4
3-4  SEND Message Header Fields . 3-6
3-5  SUBMIT Operation Template . 3-8
3-6  SUBMIT Primitive List . 3-9
3-7  SUBMIT Message Header Fields . 3-12
3-8  Submit ACK Message Header Fields . 3-13
3-9  REQUEST Operation Template . 3-16
3-10  REQUEST Primitive List . 3-17
3-11  REQUEST Message Header Fields . 3-20
3-12  Request RESPONSE Message Header Fields . 3-21
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-48
3-23  Progress RESPONSE Message Header Fields . 3-50
3-24  PUBLISH-SUBSCRIBE Operation Template . 3-62
3-25  PUBLISH-SUBSCRIBE Register Operation Template . 3-62
3-26  PUBLISH-SUBSCRIBE Publish Register Operation Template . 3-62
3-27  PUBLISH-SUBSCRIBE Publish Operation Template . 3-63
3-28  PUBLISH-SUBSCRIBE Publish Error Operation Template . 3-63
CCSDS 521.0-B-1 Page viii October 2010
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
CONTENTS (continued)
Table Page
3-29  PUBLISH-SUBSCRIBE Notify Operation Template . 3-63
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-64
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-82
3-37  PUBLISH_REGISTER_ACK Message Header Fields . 3-83
3-38  PUBLISH Message Header Fields . 3-86
3-39  PUBLISH_ERROR Message Header Fields . 3-88
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-107
3-48  SUPPORTEDQOS Primitive List . 3-107
3-49  SUPPORTEDIP Operation Template . 3-110
3-50  SUPPORTEDIP Primitive List . 3-110
3-51  TRANSMIT Operation Template . 3-113
3-52  TRANSMIT Primitive List . 3-114
3-53  TRANSMITMULTIPLE Operation Template . 3-117
3-54  TRANSMITMULTIPLE Primitive List . 3-118
3-55  RECEIVE Operation Template . 3-121
3-56  RECEIVE Primitive List . 3-121
3-57  RECEIVEMULTIPLE Operation Template . 3-124
3-58  RECEIVEMULTIPLE Primitive List . 3-124
5-1  Standard MAL Error Codes . 5-1

CCSDS 521.0-B-1 Page ix October 2010
(Blank page)
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 [B1],
Mission Operations Services Concept.
The MO MAL is a framework that provides generic service patterns to the Mission Operation
services defined in reference [B1]. 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-1 Page 1-1 October 2010
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-1 Page 1-2 October 2010
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-1 Page 1-3 October 2010
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.
NOTE – Informative references are listed in annex B.

CCSDS 521.0-B-1 Page 1-4 October 2010
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. For further
information about the MO Concept see reference [B1], and for the Reference Model see
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-1 Page 2-1 October 2010
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-1 Page 2-2 October 2010
CCSDS RECOMMENDED STANDARD FOR
MISSION OPERATIONS MESSAGE ABSTRACTION LAYER
2.2.4 ERROR HANDLING
The Error Handling section defines the positions in the pattern that 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
...