CCSDS Standardisation Support
CCSDS MAL and SEDS
SSL/08540/TN/001
Issue 1.0 draft b, 23/02/2017
SCISYS UK Limited, Clothier Road, Bristol, BS4 5SS, UK
[email protected] | +44 (0)117 916 5165 | www.scisys.co.uk
Intentionally Blank
Project:
Doc Type:
Title:
CCSDS Standardisation Support
Technical Note
CCSDS MAL and SEDS
Document Control Information
SCISYS Reference
SSL/08540/TN/001
Issue
1.0 draft b
Issue Date
26/04/2017
Classification
NOT PROTECTIVELY MARKED
Role
Name(s)
Author
Richard Melvin
Reviewed
Alan Pascoe
Authorised for Release
Spencer Ziegler
Signature(s)
NOTICE
The contents of this document are the copyright of SCISYS UK Limited and shall not be copied in whole, in part or
otherwise reproduced (whether by photographic, reprographic or any other method) and the contents thereof shall
not be divulged to any other person or organisation without the prior written consent of SCISYS UK Limited.
© SCISYS UK Limited 2017
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
ISSUE RECORD
Issue
Issue Date
Sections Affected
Relevant Information
1.0
26/04/2017
All
Not Yet
Commercial-in-Confidence
ii
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
TABLE OF CONTENTS
ISSUE RECORD ................................................................................................................................................ II
TABLE OF CONTENTS ...................................................................................................................................... III
TABLE OF FIGURES ......................................................................................................................................... III
1.
INTRODUCTION .................................................................................................................................. 4
1.1
DOCUMENT REFERENCES ................................................................................................................... 5
1.2
DEFINITIONS ....................................................................................................................................... 5
1.2.1 Acronyms ..................................................................................................................................... 5
2.
2.1
2.2
INTRODUCTION TO SOIS EDS .......................................................................................................... 6
SOIS EDS DATASHEET ...................................................................................................................... 8
SIMPLE EXAMPLE OF DATASHEET USE ............................................................................................... 10
3.
INTRODUCTION TO MO SERVICES ................................................................................................ 11
4.
ANALYSIS .......................................................................................................................................... 13
4.1
4.2
4.3
4.4
4.5
5.
AREAS OF OVERLAP BETWEEN THE STANDARDS ................................................................................ 13
SPECIFYING INTERFACES .................................................................................................................. 15
DETAILED COMPARATIVE ANALYSIS ................................................................................................... 16
MAPPING BETWEEN SOIS EDS AND A BESPOKE MO SERVICE ............................................................ 18
USING STANDARD MO SERVICES WITH EDS ....................................................................................... 19
RECOMMENDATIONS AND CONCLUSION .................................................................................... 21
TABLE OF FIGURES
FIGURE 1 TWO HYPOTHETICAL MISSIONS USING CCSDS STANDARDS ............................................4
FIGURE 2-1 CCSDS EDS CONCEPT ..........................................................................................................6
FIGURE 2-2 SOIS REFERENCE COMMUNICATIONS ARCHITECTURE .................................................7
FIGURE 2-3 SOIS EDS DEVICE DATASHEET CONTENTS ......................................................................8
FIGURE 2-4 PARAMETERS AND COMMANDS ON AN INTERFACE .......................................................9
FIGURE 2-5 ROLE OF SOIS EDS WITHIN SOIS-BASED OBSW ........................................................... 10
FIGURE 7 CCSDS MO SCOPE ................................................................................................................. 11
FIGURE 8 DETAILS OF A MO SERVICE .................................................................................................. 12
FIGURE 9 TRANSFORMATION OF MAL INTO TECHNOLOGY-DEPENDENT INTERFACE
SPECIFICATIONS .............................................................................................................................. 12
FIGURE 10 OVERLAP BETWEEN STANDARDS ..................................................................................... 13
FIGURE 11 BINARY INTERFACE TO THE DEVICE EXPRESSED AS A CCSDS EDS .......................... 13
FIGURE 12 SEQUENCE DIAGRAM: ADJUSTING A SETTING ON A DEVICE AT THE REQUEST OF
THE END USER ................................................................................................................................. 14
FIGURE 13 INTERFACE FORMALISM PROPERTIES ............................................................................. 15
FIGURE 14 XML STRUCTURE OF EDS AND MAL .................................................................................. 16
FIGURE 15 MAL INTERACTION PATTERNS ........................................................................................... 17
FIGURE 16 EDS INTERACTION PATTERNS ........................................................................................... 17
FIGURE 17 MO ACTION SERVICE IMPLEMENTED USING THE ACTION PROVIDER API ON-BOARD
............................................................................................................................................................ 19
FIGURE 18 MO ACTION SERVICE IMPLEMENTED USING THE ACTION PROVIDER API ON
GROUND ............................................................................................................................................ 20
Commercial-in-Confidence
iii
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
1. INTRODUCTION
Founded in 1982 by the major space agencies of the world, the CCSDS is a multi-national
forum for the development of communications and data systems standards for spaceflight, with
the goal of enhancing governmental and commercial interoperability and cross-support, while
also reducing risk, development time and project costs. Within that organisation, working groups
have been tasked with looking at different areas of interoperability, specifically:


Mission Operations and Information Management Services (MOIMS), covering the
interface between operations teams and the spacecraft.
Spacecraft On-board Interface Services (SOIS), covering the interface between
spacecraft and on-board systems or devices.
This division of responsibility can be illustrated by an example whereby a hypothetical university
designs, builds and is involved in the operation1 of a simple on-board instrument.


SOIS is responsible for the information the university supplies to the agency in order to
integrate the instrument into the overall on-board platform.
MOIMS is responsible for the information the university supplies to the agency in order
to operate the instrument during the mission lifecycle.
SOIS
SOIS
NASA
ESA
Specifies,
builds,
operates
SPACELINK
MOIMS
SPACELINK
MOIMS
Figure 1 Two hypothetical missions using CCSDS Standards
If two copies of similar devices fly on different spacecraft operated by different agencies, then, if
the CCSDS standards are applied in all cases, the result is minimal extra work for the university.
The same principles apply in more complex cases where the client, designer, manufacturer and
operator are not the same, or where there are multiples of each.
This technical note is aimed at examining the CCSDS standards produced for these two areas,
with an eye to looking for opportunities to transfer lessons learned between them.
1
This involvement could potentially take the form of real-time commanding, requests for planning the scheduling of
an activity, or be entirely delegated to the agency. In general, the more delegation that occurs, the more information
will need to be transferred to the agency in order to support it in making decisions on behalf of the client.
Commercial-in-Confidence
4
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
1.1 Document References
ID
Reference Document
Reference
Version
Date
[SEDS]
XML Specification for Electronic Data
Sheets
876x0
2016 draft
19/08/2016
1.2 Definitions
1.2.1 Acronyms
Acronym
Definition
API
Application programming Interface
CCSDS
Consultative Committee for Space Data Systems
ECSS
European Cooperation for Space Standardization
EDS
Electronic Data Sheet
EGSE
Electronic Ground Support Equipment
MAL
Message Abstraction Layer
MCS
Mission Control System
MO
Mission Operations
OBSW
Onboard Software
PDU
Protocol Data Uint
RMI
Remote Method Invocation
SAP
Service Access Point
SDU
Service Data Unit
SOIS
Spacecraft Onboard Interface Services
SVF
Software Verification Facility
UML
Universal Modelling Language
XML
eXtensible Markup Language
Commercial-in-Confidence
5
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
2. INTRODUCTION TO SOIS EDS
Electronic Data Sheets (EDS) is a concept that has been proposed to allow the capture of the
relevant information about a piece of equipment. This should capture the relevant aspects not
just to enable an efficient exchange of information (easing its maintainability, enforcing
consistency, etc.), but also enabling the development process of related software to be
supported by the use of model-based software engineering techniques.
Figure 2-1 CCSDS EDS Concept
In the course of the mission lifecycle, many category of system will need to represent or interact
with an onboard device, including:






Tools used for the design and validation of the device itself
System design and analysis tools modelling a system using the device, for example to
check bus bandwidth and schedulability.
Mission Control and EGSE systems, in cases where the device contributes to the
definition of some portion of the spacecraft TM/TC.
System Verification Facilities and Operational Simulators that model device behaviour in
order to validate the interaction of the OBSW and the device.
Tools uses for the design and implementation of the OBSW, including code generators.
Tools that generate portions of the system documentation.
This wide range of usages means that no one tool could plausibly meet them all; hence the
need for a standardised data format. Consequently, the SOIS standard for Electronic Data
Sheets [SEDS] takes the form of an XML schema2 designed for tool interchange, i.e.
exchanging device data between two software systems.
2
Supplemented by additional constraints not representable using the XML schema language.
Commercial-in-Confidence
6
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
Electronic Data Sheets
Execution Platform
Application
Layer
Subnetwork
Layer
DeviceSpecific
Services
Communication
Management
(MIB)
Packet
Services
Applications
Application
Support
Services
Memory
Access
Service
Network
Discovery
Service
Test
Service
Synchronization
Service
Datalink Convergence Protocols
Wireless*
CAN
Milbus
TTP
TTE
Ethernet
Serial
RapidIO
(SRIO)
Space
Wire
Space
Fibre
ARINC
653
Figure 2-2 SOIS Reference Communications Architecture
It forms part of the SOIS Reference Communication Architecture, as shown above. In that:



An architecture-specific execution platform schedules and connects components
according to their service access points. ASAP, or port, is an abstract concept that can
be realised by static function calls, dynamic routing of messages, a software bus, or any
other implementation technique suitable for a given execution platform.
The subnetwork layer provides a standardised set of access points to a wide variety of
networking protocols. These access points are defined in terms of raw data (i.e. arrays
of bytes). This layer covers sending and receiving discrete packets, accessing remote
memory, synchronising with the subnetwork, and also the discovery and test of devices
on the subnetwork.
The application layer contains mission specific applications, common support
services to those applications, and device-specific services that represent the
functionality of the device.
The role of the EDS for a device is to specify the logical mapping between the universal binarylevel subnetwork SAP and higher-level device-specific SAPs usable by applications and other
services.
Such a device datasheet defines the interpretation and contents of the messages exchanged by
applications and devices across the subnetwork layer, and the state machines required to check
and feed this information up to higher layers. By specifying the device data interface in terms of
this abstract model, it becomes possible to determine the correctness and completeness of a
device datasheet in isolation from the actual OBSW that will be used to communicate with the
device in any particular case. This validated datasheet can then be used as an input to the
development and testing of those systems that interact with the device (i.e. the spacecraft
OBSW, checkout systems, etc.).
Commercial-in-Confidence
7
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
2.1 SOIS EDS Datasheet
A SOIS EDS Datasheet is a package that can contain definitions of:

Interfaces that allow two-way data interchange, within the scope of a single device.

Components that map a set of provided interfaces to a set of required interfaces.
Together, these components and interfaces specify the Device-Specific Services for a
particular type of onboard device.
cmp Datasheet
DeviceSpecificFunctionalInterface
DeviceAbstractionControlProcedure
DeviceSpecificAccessInterface
DeviceSpecificAccessProtocol
SubnetworkServiceInterface
Figure 2-3 SOIS EDS Device Datasheet Contents
By convention, a complete datasheet for a device should contain at least two interfaces:

The Device-Specific Access Interface; the lowest-level access to all raw decoded data
transmitted to and from the device.

The Device-Specific Functional Interface; higher-level access to calibrated or derived
data.
Both of these interfaces are device-specific because different devices support different sets of
data. These are split to allow missions the option of supporting either one, or both3.
In the typical case, there will be a single component providing each interface, and the
component implementing the higher-level interface will be defined in terms of the lower-level
one. The lowest-level component will require one or more subnetwork-level interfaces.
Interfaces in a datasheet can be defined in multiple parts, and collected together using
inheritance. This allows a part of the interface of a device to be standardised, or pre-specified,
while other parts are manufacturer additions or customisations.
Mapping the device-specific interfaces defined in the datasheet to actual APIs or messaging
interfaces used by a specific OBSW architecture is explicitly not the concern of a datasheet;
otherwise the same device datasheet could not be used when the same hardware device is
used for missions of different software architectures.
3
It is common for there to be no requirement to perform calibration on-board .In such cases the OBSW uses only the
access-level interface, while the datasheet still contains calibration data for the sake of ground systems, simulators,
etc.
Commercial-in-Confidence
8
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
All interfaces provided and required are explicitly defined within a datasheet; there is no
privileged treatment or special-casing for standardised interfaces. The datasheet construct used
to define interfaces can be used to specify both high-level functional interfaces (e.g. an API, or
messaging interface with regular encoding) and low-level binary interfaces containing arbitrarilyencoded data, as commonly produced by device hardware.
As a consequence of the above, SEDS interfaces are able to not only specify a new interface (a
capability shared by many other similar component systems) but to capture an existing
interface. This includes cases where that interface was designed and implemented without
knowledge of the SEDS or SOIS. In other words, SEDS allows wrapping an existing, welltested and certified legacy device in a component-level interface. This avoids the costs and
risks associated with producing custom variants of a device containing support for the
technology stack of a particular agency.
A key characteristic of SEDS interfaces is that while they support 2-way data exchange, they
are partitioned into:

Parameters4; messages coming from the device, plus those 2-way exchanges whose
sole purpose is to get or set a discrete value on a device.

Commands; messages sent to a device, plus 2-way exchanges with any purpose other
than reading or writing a single parameter.
Figure 2-4 Parameters and Commands on an interface
4
Note that SEDS parameters are commonly aggregates of primitive values; as such they arguably more resemble
packets than the individual parameters of typical datapool-based software architectures.
Commercial-in-Confidence
9
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
2.2 Simple Example of Datasheet Use
Figure 2-5 Role of SOIS EDS within SOIS-based OBSW
The above diagram shows the information specified by a datasheet being directly used5 to
communicate with a device. In it:

The Device Specific Access Protocol takes an arbitrary set of encoded binary
messages from the subnetwork level and rearranges them into a known and finite set of
raw commands and parameters.

The Device Abstraction Control Procedure further maps those access-level
commands and parameters them into calibrated parameters and commands, which have
semantically meaningful values in terms of engineering units.

The Subnetwork Implementation is a thin software layer implementing a standardised
subnetwork protocol (e.g. ECSS SpaceWire) referenced, but not specified, in the
datasheet.
5
Commonly this will involves some form of code generation; the principles are the same for manual coding, or even
run-time interpretation.
Commercial-in-Confidence
10
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
3. INTRODUCTION TO MO SERVICES
Monitor and Control
Common Infrastructure
Data Product Distribution
Telerobotics
Planning
Scheduling and Automation
Navigation
Software Management
File Transfer and Management
Figure 6 CCSDS MO Scope
CCSDS is standardising a set of services for Mission Operations. These services define a single
specification for the exchange of similar information.
To support these standardised services CCSDS has also defined an open architecture and
framework that is:





Independent from technology
Able to integrate new and legacy systems of different organisations
Designed to support the long lifetimes of space missions
Based on a Service Orientated Architecture (SOA)
Allows defining new bespoke services for a mission-specific need.
Commercial-in-Confidence
11
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
Consumer
Provider
Service
Operation
Figure 7 Details of a MO Service
Each MO service, whether standardised or bespoke, is defined by a set of operations that the
provider of the service makes available to be invoked by the service consumer. Each
operation is defined from a template specified by an interaction pattern; one of
send/submit/request/invoke/progress/pubsub. Each such pattern has a list of the messages that
must be specified (e.g. request and response for the request pattern).
The MO concept is supported by the MO framework, which defines the structure of an MO
application, provides a generic model for data, supports generic facilities such as archiving, and
provides separation from technology
At the core of the framework is the Message Abstraction Layer (MAL), which defines a
standard XML notation for service specifications. These abstract specifications then get
transformed into the appropriate representation for whatever underlying technology is used at
implementation time (e.g. Interface Definition Language for Corba).
Figure 8 Transformation of MAL into technology-dependent interface specifications
Commercial-in-Confidence
12
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
4. ANALYSIS
4.1 Areas of Overlap Between the Standards
Interfaces
Types
Components
Encodings
Hardware
Onboard
EDS
MAL
Mappings
Ground
Segment
MAL
Figure 9 Overlap Between Standards
The two standards have different scopes and purposes, but do have two areas of overlap:


Interfaces, which describe the set of possible message exchanges between two or
more communicating entities.
Types, which describe and constrain the contents of those messages.
In the case of the hypothetical mission shown in Figure 1, suppose that the hardware device
produced by the university has a certain number of configurable settings and modes. The
spacecraft OBSW can adjust those settings according to an interface specified in the EDS
datasheet for the device.
Figure 10 Binary interface to the Device expressed as a CCSDS EDS
The above formatted EDS extract shows how the Protocol Data Units exchanged with the device are split
into fields with associated encodings, types and semantics.
Commercial-in-Confidence
13
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
Figure 11 Sequence diagram: adjusting a setting on a device at the request of the end
user
The above sequence diagram shows a request being made by an end user, going through a representative
range of services on the ground and space, and ultimately resulting in a data exchange of binary words
across a MILBUS that conforms to the description specified in a CCSDS EDS.
In effect, a subset of the hardware device interface, as defined in the CCSDS EDS, is made
available, via CCSDS MO services, to the end user. Ideally, it would be technically possible to
expose every such hardware interface in this way, leaving the decision as to which interfaces
should be so exposed to be based on the operations concept for the mission.
Commercial-in-Confidence
14
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
4.2 Specifying Interfaces
IEEE defines the verb interface as ‘To connect two or more components for the purpose of
passing information from one to the other’. The noun form, ‘an interface’, is a specification of
how this is done, exactly what categories of data can be exchanged in what sequences.
Between programming languages, standards, middleware tooling, etc. there is a large variety of
ways to formally specify an interface. Each such specification makes certain assumptions about
what an interface is, in order to describe it.
For our purposes, we can categorise these formalisms according to the following set of
properties:




Message Encoding: how the data in the messages passing across the interface is
represented in terms of octets and bits. Can be:
o Implicit: left to a tool to work out according to a set of defined ‘encoding rules’.
o Explicit: specified as part of the interface.
o Optional: a choice of either of the above.
Cardinality: the number of components connected. Can be 1:1,1:Many or Many:Many
Directions: From which of the ends of the interface message groups can be initiated.
Can be one-way or two-way
Message Grouping: whether the messages are entirely standalone, or implicitly
grouped together by some underlying mechanism. Can be:
o none: each message is standalone.
o Paired: each message can have a single reply.
o Patterned: messages are organised into arbitrarily-large groups according to a
set of predefined interaction patterns
Formalism
Terminology
Encodi
ng
Cardinality
Direction
s
Message Grouping
C family6
PUS9
RASDS10
EDS
MAL
set of functions
service
port
interface
service
implicit7
explicit
explicit
optional
implicit
1:many
many:many
1:1
1:1
1:111
one-way
two-way
two-way
two-way
one-way
paired8
none
none
paired
patterned
Figure 12 Interface Formalism properties
6
The programming language C is included because of its historical influence on both other languages like C++ and
Java, on middleware targeted at those languages like Corba, RMI and ESA’s SMP2, and also on formalisms
designed largely to generate code in such languages, such as UML and SysML Some of those have an explicit
‘interface’ construct corresponding to a set of functions.
7
The compiler selects the actual layout of data in memory, according to properties of the target CPU.
8
The return value of a function is inherently associated with the corresponding call.
9
ESA packet Utilisation Standard, ECSS-E-ST-70-41C.
10
Reference Architecture for Space Data Systems (RASDS), CCSDS 311.0-M-1
11
Except a PubSup operation, which has 3 participants.
Commercial-in-Confidence
15
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
4.3 Detailed Comparative Analysis
Figure 13 XML structure of EDS and MAL
Areas marked with ‘A’ are abstract, hiding further detail.
When an EDS is used to define an interface:





A datasheet contains several namespaces.
Namespaces define data types and interfaces.
Interfaces use inheritance, and contain parameters and commands.
Commands have arguments.
Arguments and parameters have a data type.
When MAL is used to define a service:







A specification contains several areas.
Areas define data types and services.
A service can define data types, and consists of several capability sets.
Each capability set defines a number of operations
Each operation has a sequence of message, organised by interaction pattern
Each message has a number of named fields
Each field has a data type.
Commercial-in-Confidence
16
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
Figure 14 MAL Interaction Patterns
The six supported MAL interaction patterns can be associated with any operation, governing which
messages must be specified to define the operation
Figure 15 EDS Interaction Patterns
EDS has 4 distinct interaction patterns for commands, based on whether the command mode is async or
sync, and whether it has only input arguments, only output arguments, or both.
Three of the EDS interaction patterns map directly to the MAL patterns Send, Submit, and
Request. The other, async + outArgsOnly, corresponds to a partial PubSub pattern with no
filter.
Commercial-in-Confidence
17
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
4.4 Mapping between SOIS EDS and a bespoke MO Service
An interface specified in EDS can be mapped to MAL by the following algorithm.









Within the EDS datasheet:
o replace each Parameter X with the equivalent list of getX, setX and/or updateX
commands, according to the read-only and mode attributes.
o replace any types defined inline with explicit named type definitions.
Create a MAL Specification corresponding to the EDS Datasheet.
For each EDS Namespace involved, create a corresponding MAL Area.
For each EDS Datatype involved, reference or create a corresponding MAL Datatype.
Create a MAL Service corresponding to the instantiated Interface specification as used
by a particular component.
Create a MAL Capability Set for each Interface Specification involved in defining that
interface.
Create a MAL Operation for each EDS Command, with interaction pattern set
according to:
o the value of the mode attribute
o the mode attributes of all arguments to the command.
Create a MAL Message for each slot in the selected interaction pattern
Create a MAL Field for each input or output argument of the command, using the
matching datatype.
The result of this will be the equivalent bespoke MO service.
However, while doing this mapping is possible, analysis of the target scenario suggests that it is
not likely to be actually helpful. Instead, it is more useful to investigate how the standardised MO
Action and Parameter services can be used to achieve the same affect.
Commercial-in-Confidence
18
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
4.5 Using standard MO services with EDS
Figure 16 MO Action Service implemented using the Action Provider API on-board
The parameter service is similar.
The University has the datasheet, which, in the EDS Device Access interface, gives it the set
of parameters and commands supported by the device. So logically at the peer-to-peer layer it
can talk to the Device.
To implement that logical link, it establishes a consumer link to the Action Service of the MO
ground segment using a prearranged domain id, e.g. mySc.payload.myDevice.prime.
The university sends an action ‘configureMode(STANDBY)’ using the MO Action Consumer
API. The action service in the ground segment can logically at the peer-to-peer layer talk to the
same layer onboard using the standard MO Action Provider API.
To implement this, it encodes those messages using the MO space packet encoding and sends
them to the Agency layer as a CCSDS TC packet. This physically sends the space packets up
to the satellitte.
Onboard, the implementation at that layer is the Device Handler. This, when it receives the
corresponding MAL-level message, use the subnetwork interface described by the datasheet to
talk to the device to physically send the command on the MILBUS, spacewire or whatever, and
determine its success or failure. This action status data is then relayed back to the ground.
A device datasheet contains all the information required to specify the behaviour of a device
handler using this model, meaning that part of the implementation can be automatically
generated.
Commercial-in-Confidence
19
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
Figure 17 MO Action Service implemented using the Action Provider API on ground
Again, the parameter service is similar
A straightforward adaptation of the above approach works in the case where MO is not
supported onboard. The Device Handler is now implemented using the same techniques as the
rest of the spacecraft platform, and supports arbitrary TM/TC, as defined in a spacecraft
database. A ground-side MO Adapter translates that TM/TC into the calls to the action provider
API that would have been made using the onboard approach.
In this case, not only the Device Handler, but the relevant portions of the spacecraft database
and the MO Adapter would be able to be generated from, and/or verified against, the device
datasheet.
Either implementation choice would be transparent to the end user.
Commercial-in-Confidence
20
CCSDS Standardisation Support:
CCSDS MAL and SEDS:
SSL/08540/TN/001, Issue 1.0 draft b, 26/04/2017
5. RECOMMENDATIONS AND CONCLUSION
The CCSDS MOIMS and SOIS working groups have different scopes, but have seen some
convergence in technical approach, with specifically SOIS EDS and MOIMS MAL having a
certain degree of overlap in capability.
However:



That overlap is limited to perhaps 15 to 20% of the scope of each specification
Analysis of a scenario where both MO services and SOIS EDS interfaces were in use
shows there is no need to translate between the two, as they operate on different levels
of abstraction.
Translating between the two representations is any case straightforward.
So attempting to create a common core specification, which the two usages would then
differently extend, would be unlikely to be a worthwhile exercise.
Instead, lessons learned from this analysis should be fed back into the corresponding
specification development processes, in order to improve areas where either is lacking in
capability or excessively complicated. For EDS, these could include:



Replacing the term ‘namespace’ with ‘area’, as that avoids confusion with XML
namespaces.
Replacing the term ‘interface instance’ with ‘port’, for better compatibility with UML2,
and avoiding the potential confusion between ‘interface definition’ and ‘interface
instance’.
Replacing the ‘mode’ SYNC/ASYNC flag on parameters and commands with a boolean
value ‘oneway’, by analogy with Corba. This avoids overloading the term ‘mode’ (also
used for arguments) and removes one of the two ways of specifying the same thing
(see Figure 15 EDS Interaction Patterns).
For MAL:


the concept of ‘semantics’ is currently missing; parameters and arguments have at most
an engineering unit, they do not have any other structured information required to
understand their meaning and role.
Greater clarity is needed on whether parameters and arguments could, or should, be
aggregate data types. This include interaction with other services such as the limit check
service; what does it mean to limit check a parameter that is a structure or array?
Commercial-in-Confidence
21