1 CCSDS SOIS Application Support Services
1.1 Meeting Objectives
The May 2011 CCSDS meeting of the SOIS Application Support Services group had the
To add more detail to the SOIS plug-and-play architecture in the context of real
technologies and real devices.
To understand the requirements on electronic data sheets based on real devices.
To understand the role and relationship of DAS, DVS, DDPS and DES in the plug-
and-play architecture and the deployment of electronic data sheets.
To progress work on the MTS and FPSS Red Books and the SOIS Green Book,
working towards publication.
1.2 Progress Summary
1.2.1 Position of DDPS
It was proposed in Fall 2010 meeting that the interface to DVS have similar semantics to
the DAS interface. This permits the position of DDPS to be more flexible. The WG
decided that DDPS should sit above DAS and DVS, permitting the pooling of virtual, as
well as device specific, parameters. Whilst the contents of DVS and DAS are defined for
a particular device, the role of DDPS is determined by the mission, as well as by the
device. This arrangement places the mission-specific entity (DDPS) on top of the device-
specific entities (DVS and DAS) rather than in the middle, as it was for the prior
arrangement. See diagram below.
Data Acquisition Services
DDPS at the top of the stack also makes the task of electronic data sheets (EDSs) much
easier as they must describe the mappings from the virtual interface (DVS) to the device-
specific interface (DAS). If DDPS were inserted between these two interfaces then the
EDS would have to change to accommodate this as the DDPS and DAS interfaces are
significantly different. As the decision to use DDPS should be made for a given mission,
this would have caused problems for the portability of EDSs.
This requires minor changes to:
the Green Book (as part of PnP updates);
the diagram in section 2 of the DAS, DVS and DDPS Red Books (none yet
published so no problem);
the description in section 2 of the DDPS Red Book (the corresponding descriptions
in DAS and DVS should be reviewed) (none yet published so no problem);
the DDPS_ADD_ACQUISITION_ORDER.request primitive may need an
additional parameter to define whether DVS or DAS should be used to acquire the
Additionally, the DDPS_ADD_ACQUISITION_ORDER.request primitive is missing a
ValueID parameter, which should be added.
NOTE: Changes to DDPS_ADD_ACQUISITION_ORDER.request are not covered in
1.2.2 Role of DAS
The tasks that must be performed by the Command and Data Acquisition Services
(CDAS) were discussed and can be summarised as:
using subnetwork services to communicate with the device using some device-
specific access protocol (DSAP), this typically involves the creation of packets (or
memory-mapped register values) and the management of exchange patterns (such as
acknowledgements, timeouts etc.);
using the DSAP to manage device functions, this typically involves acquiring
parameters and commanding attributes in device specific forms and encodings;
mapping the device functions onto the „idealised‟ functions of a virtual device.
These steps are shown in the diagram below.
Whilst the position of the DVS service interface in this stack is clear, the position of DAS
is less clear. The WG discussed the role of DAS and its potential use as a service
interface for direct functional interaction with a device, perhaps by ground-based
operators. For this reason it was decided that the DAS service interface is most
appropriately mapped onto the device functional interface (the “Functional Device” in the
diagram); the DSAP then becomes part of DAS. This alignment is shown below.
Virtual Device DVS
On inspection of the DAS Red Book, this definition seems to align with the information
that is already there. Clarification of this position will be added to the Green Book as
part of the current updates.
1.2.3 EDS Structure and Content
The structure of an EDS, in terms of the information it must provide rather than its
syntax, was discussed by the WG. It is difficult to propose a concrete definition for the
structure of an EDS without the analysis of a wide variety of devices; however, a
structure was proposed as a starting the point. A data sheet shall contain three major
sections, aligned to the tasks discussed above:
Each section is split into two parts:
An interface, which specifies the operations/parameters that the sections supports.
An implementation, which specifies the mapping rules from the interface provided
by that section to the interface of the underlying section. These mapping rules may
These sections are shown below. The interfaces are the dark blue lines; the
implementations are the pale blue boxes.
Types with machine
General principles were discussed:
The interface to the virtual device is the only place with well-defined semantics.
The terms used at this interface will come from a shared data dictionary that is
universal for all data sheets. This is equivalent to part of the SPA CDD.
The interfaces to types of virtual devices can (and should) also be standardised in a
common dictionary. The SPA CDD also defines standard interface types.
The only place that needs to connect data types with machine representations (e.g.
32-bit, LSB first, little-endian etc.) is in the DSAP.
It should be possible to construct a SOIS EDS out of snippets in multiple files. This
allows standard snippets to be constructed to, for example, describe standard
protocols or device behaviours and therefore allowing an EDS distributed with a
device to reference standard EDS snippets rather than be fully self describing.
The implementations may have to be stateful. However, a declarative approach
should be taken where possible, i.e. the EDS should describe how the device
functions and what DVS/DAS need to do, not necessarily how to do it.
The SOIS EDS must be agnostic to execution patterns (such as get/set vs. pub/sub)
and error reporting patterns (such as returning a result vs. a separate status
The support for IEEE 1451 devices is required. Therefore it must be possible to
capture the semantics of a 1451 TEDS in a SOIS EDS, even if the syntax is different
(e.g. XML rather than binary/text TLV).
It may be possible to come to an agreement with the AFRL to define a core xTEDS
schema which could be common between SOIS and SPA. Some work was done on
understanding and defining such a schema.
1.2.4 Relationship between Devices and Messaging
In the AFRL/AIAA SAP and NASA GSFC CFE systems, virtualised devices
communicate with the rest of the system via a standardised messaging bus. On these
systems there is a requirement not just to define the operation of the virtual device in
standard terms, but also to define the content of the messages used to communicate with
the virtual device. This involves mapping message content, exchange pattern (protocol)
and operation onto a standard virtual device interface. This process involves the same
basic tasks as the stack described above which is necessary for communicating with
devices. There are a few differences:
the mappings are likely to be considerably simpler, but the language necessary to
describe them could be the same;
the underlying “transport” is MTS rather than a subnetwork services such as PS;
GSFC, and potentially AFRL/AIAA, would like to see the ability to describe
software components in an identical fashion to smart device components. The only
difference between software and device components is that software components
may require interfaces as well as providing them. The description of software
components is out of scope for the SOIS group; however, GSFC may want the
feature of required interfaces for hardware components also.
The diagram below shows the logical structure of a system using messaging. A SOIS
EDS describes the physical device stack and permits the generation of the device driver
stack. This is the normal use case for SOIS EDSs as previously discussed. In addition to
this, a device driver may be shared over a messaging system, exposed as MTS. This type
of device is effectively a “smart device” which integrates into the messaging system. A
SOIS EDS may be used in an identical manner to describe the smart device messaging
stack – that is the manner in which a device is exposed to the messaging system. This
description should allow the generation of the corresponding services in the application
stack on the far left. As the messaging stack maps to a virtual device, it is possible that,
for a given virtual device or device type, the messaging stack will be identical. This
would result in identical messaging datasheets.
Device Messaging Physical Device
Application Stack Stack Device Driver Stack Stack
Application Physical Process
DVS DVS DVS Device
Virtual Device Virtual Device Virtual Device Idealised Device
DAS DAS DAS
Functional Device Functional Device Functional Device
Device-Specific Device-Specific Device-Specific Device-Specific
Access Protocol Access Protocol Access Protocol Access Protocol
Subnetwork Subnetwork Subnetwork Subnetwork
1.2.5 Relationship with SPA
Like the NASA/GSFC CFE, the AIAA SPA architecture is based on messaging. As
such, the AIAA xTEDS describes the concrete messaging interface, bound to machine
representations and standard protocols. This is why, in xTEDS, the semantics are not
separable from the messaging interface. A core xTEDS/SEDS schema could resolve this
issue by separating out the semantic parts from the message descriptions. The xTEDS
schema also does not have a rigorous data model. Such a data model has been proposed
for SEDS; it may be that this could be adopted by xTEDS without too much difficulty.
The intention is that a common core schema can be used by SPA and SOIS to describe
the virtual device interface. It may be difficult to affect the messaging part of xTEDS;
however, as the purpose of this datasheet is similar to a SEDS being used to describe a
messaging interface, it will be possible to translate between the two, making SPA devices
fully portable to a SOIS system.
1.2.6 SOIS and Remote Terminal Units
Remote Terminal Units (RTUs) are devices which attach to a main subnetwork and
provide access to multiple simple devices on other subnetworks. As such they are
usually a data concentrator. An RTU could expose the virtual, or functional, interface to
each of its devices via an independently-defined RTU protocol. The RTU protocol is
effectively a tunnelling protocol, independent of the content required for the attached
devices. The best approach to use with SOIS is to create an RTU datasheet which
combines a description of the RTU protocol with the functional (and potentially virtual)
elements of the datasheets for each of the devices it is providing access to (removing the
DSAP for each of the devices as this is handled by the RTU). This creates a single
datasheet for the RTU describing all of the functions it provides. The diagram below
depicts the process of combining datasheet elements to create an RTU datasheet.
Device EDS RTU
EDS Processing EDS
The objectives of the meeting were largely met, with a great deal of detail being added to
the plug-and-play architecture and Green Book contents. The understanding of SOIS
electronic data sheets was advanced significantly. Worked examples for real devices
were talked through but not documented in detail due to a lack of shared understanding of
basic requirements. The documentation of requirements has been added to the beginning
of the work plan. A comprehensive work plan has been drawn up, leading towards a
SOIS electronic data sheet standard and a full completement of published books.
1.4 Work Plan
The following work plan captures activities on the Green Book and SOIS electronic
datasheets. DFI refers to the “Device Functional Interface”, i.e. the “Functional Device”
1. Draft of GB with actions completed [next teleconference – 07/06/2011]
2. Draft GB issue [21/06/2011]
3. SOIS EDS Requirements (First draft PDM – to WG for review) [21/06/2011]
4. Descriptive (English) versions of devices in a structured form (PDM to provide
document template, GPR/JJW/AVS/RWK to provide examples – JJW to include
5. Generate DVS interface xml schema – aligned to xTEDS (PDM/RWK)
6. Extend DVS interface xml schema for DFI and DSAP interfaces (PDM)
7. Generate interfaces for existing devices in xml using the schema
(PDM/GPR/JJW/RWK/AVS – JJW to provide message-level example)
8. Revise SEDS interface schema (PDM/RWK)
9. Add DSAP implementation schema (GSFC-GPR/PDM/RWK)
10. Generate DSAP implementations for existing devices (PDM/GPR/JJW/AVS)
11. Review DSAP implementations (all in WG)
12. Revise SEDS DSAP schema if necessary (PDM/GSFC-GPR /RWK)
13. Tutorial on 1451 standards organised by GPR
14. Read and understand 1451.0/1451.2/1451.4 TEDS standards and extract
necessary terms for SEDS (?)
15. Add DFI and DVS implementation elements to SEDS xml schema (?)
16. Generate DFI/DVS implementations for existing devices (PDM/GPR/JJW/AVS)
17. Review complete EDS implementations (all in WG)
18. Revise SEDS schema as necessary (PDM/GSFC-GPR /RWK)
The Green Book updates are largely documented as comments in the current working
copy of the Green Book. However, it was agreed that a number of examples would be
inserted to help put the SOIS architecture into context:
1. JJW to put SOIS into the context of the NASA/GSFC CFE
2. RWK to put SOIS into the context of AFRL/AIAA SPA
3. Felice Torelli/CT to put SOIS into the context of SAVOIR/SAVOIR-FAIRE
4. GPR to check LANL SOIS mappings to see if there is relevant information for the
5. CT to generate section for GB on RTUs.
The following work plan captures the updates necessary to Application Support Services
books in order to release them.
1. Confirm changes to DDPS diagram and section on requirements for underlying
services with SDF and update, also need to include ValueID in
DDPS_ADD_ACQUISITION_ORDER (PDM/SDF) [21/06/2011]
2. Review DAS according to the updated GB and agreements at the Spring Meeting,
modify as necessary and put out for CESG review (all) [Comments by
21/06/2011, updated ready for issue to CESG by 05/07/2011]
3. Initial update of DVS prepared according to GB updates and issued for WG
4. Review DES according to updated GB, modify as necessary and put out for
5. RID dispositions on MTS collated by 21/06/2011 (CT, also CT to check
availability) ready for publication
6. RID dispositions on FPSS to be reviewed by WG by 07/06/2011 ready for
1.5 Forthcoming Teleconference Agendas
This gives rise to the following teleconference schedule:
Green Book updates review
FPSS RID closure
FPSS ready for publication
EDS requirements review
MTS comments review
DAS comments review
DDPS update review
MTS update review
DAS update review
DES comments review
DVS initial update issue
EDS requirements issue (WG internal)
DDPS ready for CESG
DVS comments review
DES updates review
Issue of English version of EDS for SSoC
MTS ready for publication
DAS ready for CESG
DVS update issue
DES ready for CESG
DVS ready for CESG