ISO 20106:2015

INTERNATIONAL ISO
STANDARD 20106
First edition
2015-08-15
Space data and information transfer
systems — Mission operations
common object model
Systèmes de transfert des informations et données spatiales — Modèle
d’objet commun 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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
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 20106 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 521.1-B-1, November 2012) 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
COMMON OBJECT
MODEL
RECOMMENDED STANDARD
CCSDS 521.1-B-1
BLUE BOOK
February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
AUTHORITY
Issue: Recommended Standard, Issue 1
Date: February 2014
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 (CCSDS A02.1-Y-3), 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.1-B-1 Page i February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
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.1-B-1 Page ii February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
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.1-B-1 Page iii February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
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 (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.
– 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.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 521.1-B-1 Page iv February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
DOCUMENT CONTROL
Document Title Date Status
CCSDS Mission Operations Common Object February Original issue
521.1-B-1 Model, Recommended Standard, 2014
Issue 1
CCSDS 521.1-B-1 Page v February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
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 CONVENTIONS . 1-3
1.6 REFERENCES . 1-4

2 OVERVIEW . 2-1

2.1 GENERAL . 2-1
2.2 COMMON OBJECT MODEL . 2-2
2.3 THE SUPPORT SERVICES . 2-3
2.4 EVENT SERVICE . 2-4
2.5 ARCHIVE SERVICE . 2-4
2.6 ACTIVITY TRACKING SERVICE . 2-6
2.7 COM SERVICE SPECIFICATIONS . 2-15

3 SPECIFICATION: COM . 3-1

3.1 GENERAL . 3-1
3.2 REQUIREMENTS . 3-1
3.3 SERVICE: EVENT . 3-1
3.4 SERVICE: ARCHIVE . 3-4
3.5 SERVICE: ACTIVITYTRACKING . 3-17

4 DATA TYPES . 4-1

4.1 AREA DATA TYPES: COM . 4-1
4.2 SERVICE DATA TYPES: ARCHIVE . 4-4
4.3 SERVICE DATA TYPES: ACTIVITYTRACKING . 4-10

5 ERROR CODES . 5-1

6 SERVICE SPECIFICATION XML . 6-1

ANNEX A SECURITY, SANA, AND PATENT
CONSIDERATIONS (INFORMATIVE) . A-1
ANNEX B DEFINITION OF ACRONYMS (INFORMATIVE) .B-1
ANNEX C INFORMATIVE REFERENCES (INFORMATIVE) . C-1
CCSDS 521.1-B-1 Page vi February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
CONTENTS (continued)
Figure Page
2-1 Mission Operations Services Concept Document Set . 2-1
2-2 COM Structure . 2-2
2-3 Activity Relay Example . 2-6
2-4 Activity Chaining Example . 2-9
2-5 Activity Proxy Example . 2-10
2-6 Activity Single-Hop Example . 2-11
2-7 Activity Single-Hop Sequence . 2-12
2-8 Activity Multi-Hop Example . 2-13
2-9 Activity Multi-Hop Sequence . 2-15

Table
2-1  MAL Interaction Activity Mapping . 2-8
3-1  Event Service Operations . 3-2
3-2  Archive Service Operations . 3-5
3-3  Archive Service Events . 3-6
3-4  ActivityTracking Service Operations . 3-17
3-5  ActivityTracking Service Object Types . 3-18
3-6  ActivityTracking Service Events . 3-19
5-1  COM Error Codes . 5-1

CCSDS 521.1-B-1 Page vii February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
1 INTRODUCTION
1.1 GENERAL
This Recommended Standard defines the Mission Operations (MO) Common Object Model
(COM) in conformance with the service framework specified in annex B of Mission
Operations Services Concept (reference [C1]).
The MO COM is a generic service template that provides a Common Object Model to the
Mission Operation services defined in reference [C1]. These Mission Operations services are
defined in terms of the COM and the Message Abstraction Layer (MAL) (reference [2]).
1.2 PURPOSE AND SCOPE
This Recommended Standard defines, in an abstract manner, the COM in terms of:
a) the operations necessary to provide the service;
b) the parameter data associated with each operation;
c) the required behaviour of each operation;
d) the use of the model.
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 presents the COM specification;
d) section 4 is a formal specification of the COM data structures;
e) section 5 is a formal specification of the COM errors;
f) section 6 details the location of the formal service specification Extensible Markup
Language (XML) schema.
CCSDS 521.1-B-1 Page 1-1 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
1.4 DEFINITION OF TERMS
Software Component (component): A software unit supporting 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 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.1-B-1 Page 1-2 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
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.
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.
Object: A thing which is recognised as being capable of an independent existence and which
can be uniquely identified. An object may be a physical object such as a spacecraft or a
ground station, an event such as an eclipse, or a concept such as telemetry parameter. It
forms the fundamental part of a service specification, e.g., a parameter definition, a
parameter value at a given point in time, a command. There are no requirements on what an
object may be except that it must be possible to uniquely identify an instance of it.
Event: A specific object representing ‘something that happens in the system at a given point
in time’.
Activity: Anything that has a measurable period of time (a command, a remote procedure, a
schedule, etc.).
1.5 CONVENTIONS
1.5.1 NOMENCLATURE
The following conventions apply for the normative specifications in 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.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
CCSDS 521.1-B-1 Page 1-3 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
1.5.2 INFORMATIVE TEXT
In the normative sections of this document sections (3-6), informative text is set off from the
normative specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
1.5.3 DRAWING CONVENTIONS
In figures illustrating this document, UML modelling diagrams are used. (See reference [1]
for further information regarding diagrams types and their meaning.)
1.6 REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated
were valid. All publications are subject to revision, and users of this document are
encouraged to investigate the possibility of applying the most recent editions of the
publications indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS publications.
[1] Mission Operations Reference Model. Issue 1. Recommendation for Space Data
System Practices (Magenta Book), CCSDS 520.1-M-1. Washington, D.C.: CCSDS,
July 2010.
[2] Mission Operations Message Abstraction Layer. Issue 2. Recommendation for Space
Data System Standards (Blue Book), CCSDS 521.0-B-2. Washington, D.C.: CCSDS,
March 2013.
NOTE – Informative references are listed in annex C.

CCSDS 521.1-B-1 Page 1-4 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
2 OVERVIEW
2.1 GENERAL
This document contains the formal specification for the Common Object Model (COM). The
COM provides a standard object model for MO Services to utilise. The following diagram
presents the set of standards documentation in support of the Mission Operations Services
Concept. The COM belongs to the Specifications documentation.
Mission Operations Services
Specifications Technology Language
Mappings Mappings
MO
Concept
Service Specific
Service
Encoding
Specifications
(optional)
Reference Java MAL
Model API
Common
Object Model
MAL
Encoding
Message
Abstraction
Layer (MAL)
Green Book
Application
Profile
Magenta Book
Blue Book
Figure 2-1: Mission Operations Services Concept Document Set
(For further information about the MO Concept, see reference [C1], and for the Reference
Model, see reference [1].)
The COM Specification is split into two parts. The first specifies the common object model,
and the second specifies the standard COM support services. The services and structures are
defined in terms of the MAL so it is possible to deploy them over any supported protocol and
message transport.
CCSDS 521.1-B-1 Page 2-1 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
2.2 COMMON OBJECT MODEL
2.2.1 GENERAL
The COM provides a standard data object model for MO Services to utilise. Whereas the
MAL provides the building blocks that can be used to define the operations of a MO service,
the COM provides the building blocks for the specification of the data objects of a service.
This builds upon the MAL to define a standard data model for an MO service.
An object is defined as a thing which is recognised as being capable of an independent
existence and which can be uniquely identified. An object may be a physical object such as a
spacecraft or a ground station, an event such as an eclipse, or a concept such as telemetry
parameter. It forms the fundamental part of a service specification, e.g., a parameter
definition, a parameter value at a given point in time, a command.
The object model is based on the principle of RESTful architectures; namely, each object can
be identified by a unique identifier. There are no requirements on what an object may be
except that it must be possible to uniquely identify an instance of it so that it can be
referenced.
Each service that utilises the COM must define the object, or set of objects, that form the
data model of the service.
2.2.2 COMMON MODEL OBJECT STRUCTURE
Whilst the COM does not limit what may be considered an object by a service specification,
it does define how objects are referenced and how they can reference each other. Each object
can link to up to two other objects as is shown in figure 2-2.
source
0.1
*
Object
related
0.1 *
Figure 2-2: COM Structure
CCSDS 521.1-B-1 Page 2-2 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
The two links have different roles, the related role is expected to be used to link to a related
object (for example a parameter value object could link to a parameter definition object), and
the source link would be used to link to an unrelated object (for example the operator who
requested its value change). It is service specific how these links are to be used.
Each linked object can define its links (so a parameter definition object could define a related
link to a parameter name object if this was required) and therefore provides the ability to
have ‘n’ levels of hierarchy.
2.2.3 COMMON MODEL OBJECT IDENTIFICATION
The identity of an object is composed of several parts, the domain of the object, the type of
the object, and then the object instance identifier. Objects in one session are conceptually
separate from objects in a different session (the rules of the MAL data model require this);
the network zone is ignored and does not form part of object identification.
Each service specification is required to list the objects it defines, the structure used to
represent the body of the object, and provide each object with a unique (to that service)
service object number. The type of an object is the combination of the area number, service
number, area version, and service object number. The combined parts are able to fit inside a
MAL::Long (for implementations that prefer to index on a single numeric field rather than a
structure).
The object instance identifier uniquely identifies an instance of an object for a given domain
and object type. The object instance identifier is just a MAL::Long.
2.3 THE SUPPORT SERVICES
The COM specification also includes some support services that build upon the basic object
model; these services are:
Event service: An event is a specific object representing ‘something that happens in the
system at a given point in time’. The event service provides a common mechanism for the
distribution of events and also defines how a service that creates events should interact with
the archive service.
Archive service: The archive service provides a generic means for persisting objects. It
follows the basic Create/Retrieve/Update/Delete (CRUD) principles and therefore fits with
most archiving systems. It provides a simple basic set of operations and a basic requirement
on the information required to persist service objects in it.
Activity tracking service: The activity tracking service provides the ability to track the
progress of activities; an activity is anything that has a measurable period of time (a
command, a remote procedure, a schedule, etc.). It defines an event pattern that supports the
tracking of activities from the initial consumer request, tracking its progress across a
transport link, to reception by the provider and execution in that provider.
CCSDS 521.1-B-1 Page 2-3 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
The following subsections cover the COM services in more detail, the actual specification of
each service is detailed in section 3.
2.4 EVENT SERVICE
An event is a specific object representing ‘something that happens in the system at a given
point in time’. The event service defines a single publish/subscribe operation that supports
the publishing of events and also the monitoring of events generated by other components.
An event, as it is a COM object, is identified by the normal object fields (domain, object
type, and object instance identifier) with the addition of a string name. The name provides a
more human friendly means to identify the event.
The body of an event object is assumed to be empty unless one is specified by the service
that declares the event.
The COM object links of the event object are used as follows unless stated differently by the
relevant service defining the event:
– the source links to the object that caused the event to be generated;
– the related link is service and event-type specific.
When a service implementation requires that the events it generates be persisted, upon event
emission, the event should be stored in the COM archive. As an event is just a COM object,
the normal archive mechanism (as defined in the archive service) is used to store the event.
2.5 ARCHIVE SERVICE
2.5.1 GENERAL
The archive service provides a basic archiving function for COM objects. It follows the
Create Retrieve Update Delete (CRUD) principles and allows simple querying of the archive
(more complex queries are supported but the specifications of these are outside this
standard).
As changes are made during the lifetime of an object, this information is distributed to
consumers using the service defined operations; as long as these updates follow the COM
standard for object identification they can also be stored in a COM archive.
By storing these updates in an archive, any historical replay/retrieval functions can correctly
reflect the history of the objects.
CCSDS 521.1-B-1 Page 2-4 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
2.5.2 ARCHIVE OBJECT IDENTIFICATION
As every COM object is uniquely identified by the set (domain, area, service, area version,
object type, object instance identifier) this provides the basic key for the storage of objects.
Additionally, each object may be tagged by a timestamp, the URI of the provider, a source
object (the fully qualified identifier of the object which is at the origin of this particular
object, if any) and a related object (the identifier of another object which gives additional
information on this particular object, if any).
2.5.3 RETRIEVAL OPERATIONS
The retrieval operations provide a consumer with the ability to request stored information
from the archive in bulk. There are three different retrieval scenarios that an MO consumer
function may use for archive access:
Count A count of objects existing at a given point or range in time is extracted in a
single transaction.
Retrieval A block of objects covering a period of time is extracted in a single
transaction. If no objects exist for the time period no value is returned.
Monitor A Publish/Subscribe subscription of events generated by the archive to allow
active monitoring of an archive for changes as they happen.
The count operation returns the count of objects that satisfy the request criteria and the bulk
retrieval returns the COM objects that satisfy the selection criteria. The events generated by
the archive allows a consumer to subscribe for changes to the archive.
2.5.4 STORE OPERATION
The store operation provides a consumer with the ability to populate an archive with
information. It provides a standard mechanism for a COM archive to be populated in bulk.
The following scenarios are foreseen:
Monitored A software component is monitoring information from one or more services
and storing this information in a COM archive.
Bulk storage A software component is moving information from one archive, most likely a
proprietary information store (possibly on-board), to a COM archive.
Consolidation A software component is consolidating information from one or more COM
archives (possibly separated by session) into a single COM archive. This is a
refinement of the bulk storage scenario where information is also being
retrieved from the COM archives.
CCSDS 521.1-B-1 Page 2-5 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
It is likely that in any deployed system-internal mechanisms would be available for storing
information as it is created; however, the COM archive service store operation provides an
MO compliant mechanism that allows an MO consumer to access the storage of the COM
archive. It allows the creation of components that are agnostic to storage implementations.
2.6 ACTIVITY TRACKING SERVICE
2.6.1 GENERAL
The activity tracking service, or activity service for short, provides the ability to track the
progress of activities; an activity is anything that has a measurable period of time (a
command, a remote procedure, a schedule, etc.). The basic service provides the ability to
track the progress of MAL operations, but it is expected to be used for other processes where
appropriate. It defines an event pattern that supports the reporting of the progress of activities
from the initial consumer request, tracking its progress across a transport link, to reception by
the provider and execution in that provider.
The service uses the event service to report the progress of activities which supports the
concept of external monitoring where one component is able to monitor the activities in the
system without requiring knowledge of what components are active. This permits the
implementation of a single component for the monitoring of activity in the system and also
for the archiving of this activity.
It also supports monitoring of activities that are passed via a chain of components to a
provider; these intermediate components are referred to as relays in this document. For
example, to control a Rover the chain in figure 2-3 may be envisioned.
Consumer Gateway Ground Station
X X AMS/IP AMS/IP AMS/DTN
Activity Activity Activity Activity Activity
Orbiter Rov er Provider
AMS/DTN AMS/DTN AMS/DTN AMS/MTS AMS/MTS
Activity Activity Activity Activity Activity

Figure 2-3: Activity Relay Example
Each component passes the operation message from the consumer to the provider with the
activity service providing notification of the current location of the message in the chain,
CCSDS 521.1-B-1 Page 2-6 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
where it is expected to move next, and when. This passing of messages from a consumer to a
provider via relays is referred to as multi-hop in this document.
NOTE – It is a deployment decision whether a component generates the activity events.
This allows for reporting to be configured depending on network topology or any
other criteria deemed suitable.
2.6.2 ACTIVITY EVENTS
2.6.2.1 General
The activity service defines a standard set of events and uses the COM event service for the
reporting of the progress of activities from the consumer to the provider and also for
execution in the provider.
Four transport events are defined:
– Release is release from source consumer;
– Reception is reception by an intermediate relay;
– Forward is release from an intermediate relay;
– Acceptance is reception and acceptance by the destination provider;
where Reception and Forward events are only used in a multi-hop situation.
Each event has a fixed structure and provides positive as well as negative feedback on the
transfer of the activity from consumer to provider (optionally via intermediate relays).
Once the activity has arrived successfully in the provider the execution progress of it is
reported using an Execution event. The Execution event may be reported many times
depending on the activity:
– Execution is used to report a stage in the execution of the activity.
In regular expression notation the event pattern is:
(Release (Reception Forward)* Acceptance (Execution)*)
The events are distributed using the COM event service, the events themselves link to the
activity being monitored (the source of the event) using the object source link.
2.6.2.2 MAL Operations
A MAL operation is an example of an activity and therefore the activity service can be used
to monitor MAL operations. The activity service defines a COM object, OperationActivity,
which is used to hold the details of a MAL operation. When an interaction is started the
CCSDS 521.1-B-1 Page 2-7 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
consumer publishes an OperationActivity which all activity reporting events for this
interaction use as their source object.
The activity transport events report the progress of the operation from the consumer to the
provider. The activity execution event is used to report the execution progress of the
interaction in the provider. Table 2-1 defines the mapping from the MAL interaction pattern
stages to the activity Execution event.
Table 2-1: MAL Interaction Activity Mapping
Activity MAL Interaction Pattern
Event
SEND SUBMIT REQUEST INVOKE PROGRESS
Release Yes Yes Yes Yes Yes
Reception* Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes
Forward*
Acceptance Yes Yes Yes Yes Yes
Yes for Yes for Yes for ACK Yes for ACK,
Execution†
ACK RESPONSE and RESPONSE PROGRESS and
stage stage stage RESPONSE stages
Stage count 1 1 2 Operation specific
* -- Reception and Forward events are only used in a multi-hop situation.
† -- Execution events generated are dependent on the MAL Interaction Pattern.
NOTE – The transport events will not be returned to the initiating application through the
MAL interaction, because as far as the MAL is concerned they are different
interactions.
If a negative event is being generated by one of the relays, then that relay is also
required to fail the MAL interaction that the consumer initiated.
2.6.3 ACTIVITY CHAINING
There are situations where the execution of one activity causes the execution of other
activities. For example an automated on-board procedure could trigger the execution of other
activities on-board such as other automated procedures or operations. Another example is
where one operation is used to load another operation for delayed execution (an on-board
command schedule).
In all of these cases there needs to be a link between the activity reporting of one activity and
the activity reporting of the other triggered activity. The source link of the COM object
model provides this facility, where the second activity uses the COM source link to point to
the first activity.
CCSDS 521.1-B-1 Page 2-8 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
For example, if the execution of one MAL operation causes the execution of another MAL
operation the set of activity objects, reporting events and links would be created as shown in
figure 2-4.
First Operation :
Release :
OperationActivity
Source
ActivityTransfer
Source
Acceptance :
ActivityAcceptance
Source
Source
Execution :
ActivityExecution
Second Operation :
Release :
OperationActivity
Source
ActivityTransfer
Source
Acceptance :
ActivityAcceptance
Source
Execution :
ActivityExecution
Figure 2-4: Activity Chaining Example
The sequence would be:
– First OperationActivity object is created to represent the operation and also an
activity event of type RELEASE that points to the first OperationActivity using the
source link.
– An activity event of type ACCEPTANCE is created upon reception and acceptance
that points to the first OperationActivity using the source link.
– The execution of the operation causes an activity event of type EXECUTION to be
created that points to the first OperationActivity using the source link.
CCSDS 521.1-B-1 Page 2-9 February 2014
RECOMMENDED STANDARD FOR MISSION OPERATIONS COMMON OBJECT MODEL
– During the execution of the first operation a second operation is triggered. Second
OperationActivity object is created to represent the operation and also an activity
event of type RELEASE that points to the second OperationActivity using the source
link.
– A second set of activity events are created during the execution of the second
operation that point to the second OperationActivity using the source link.
2.6.4 ACTIVITY SERVICE PROXY
In deployments that do n
...