CCSDS SOIS Application Support Services Report v1.0

Document Sample
CCSDS SOIS Application Support Services Report v1.0 Powered By Docstoc
					1 CCSDS SOIS Application Support Services
1.1     Meeting Objectives
The May 2011 CCSDS meeting of the SOIS Application Support Services group had the
following objectives:

  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.

                                            Device Data
                                           Pooling Service


                           Device Access
                                                              Command and
                                                    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
published API.

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.

                                            Virtual Device

                                          Functional Device

                                    Device-Specific Access


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.

                            Application                       Application

                           Virtual Device                        DVS

                         Functional Device


                       Device-Specific Access

                            Subnetwork                       Subnetwork
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:

  Virtual Device
  Functional Device

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
   be stateful.

These sections are shown below. The interfaces are the dark blue lines; the
implementations are the pale blue boxes.


                Consistent semantics

                                            Virtual Device

                                          Functional Device

                                        Device-Specific Access
                 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

                                                                          Exposed Device
   Functional Device       Functional Device      Functional Device

    Device-Specific        Device-Specific         Device-Specific        Device-Specific
    Access Protocol        Access Protocol         Access Protocol        Access Protocol

           MTS                   MTS

        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

1.3       Conclusions
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”
described above.

      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
       message-level example)
   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
   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
      review 05/07/2011
   4. Review DES according to updated GB, modify as necessary and put out for
      CESG review
   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

Shared By: