1. SOIS EDS & Toolchain ESA YGT Study
F. Torelli & P. Skrzypek CCSDS Fall Meeting /10/2013

2. Outline EDS study overview Interface description Process description
Software framework and toolchain
Recap and open points
Credit for the onion diagram: S. Fowell

3. EDS study overview

4. EDS study timeline SOIS WG MEETING TASTE TRAINING MID-TERM
PRESENTATION
SOIS WG
MEETING
FINAL
PRESENTATION
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jul
Aug
IMPLEMENT
EDS TO SDL
TRANSLATOR
RESEARCHING
DRIVER
GENERATION
IMPLEMENTING
DVS SERVICE IN ADA
TRYING TO LINK
EVERYTHING TOGETHER
LEARNING
ASN.1 AND SDL
EXTENSIVE TESTING OF
ASN1SCC TOOL
IMPLEMENTING
EDS TO ASN.1
TRANSLATOR
ANALYSIS
OF NPAL ICD
UPDATE SCHEMA
AND MAPPING
MAPPING BETWEEN
EDS AND SDL
DEFINING EDS
REQUIREMENTS
SEARCHING FOR
SUITABLE CODE
GENERATORS
IMPLEMENTING
NPAL EDS
EXTENDING
EDS TO ASN.1
TRANSLATOR
INTRODUCTION TO ATB
FIRST EDS SCHEMA
MAPPING BETWEEN
EDS AND ASN.1
STUDY VARIOUS
DESCRIPTION
FORMATS
INTRODUCTION TO SOIS
PREPARATION FOR
SOIS WG MEETING

5. Overview & key features
SOIS EDS
EDS
Interface data types based on ASN.1
Protocol description based on SDL
Transactions connecting service primitives between layers
Different service models
Software framework & toolchain
Threads and queues
Code generation based on intermediate formats to leverage existing open source tools
SOIS Services
DVS Service Interface
DVS Interface
DACP Description
DACP Implementation
DAS Service Interface
DAS Interface
DAP Description
DAP Implementation
SubNet Service Interface
SubNet Interface

6. Interface description

7. Data types Integer number Enumeration field Floating point number
value constraints
binary encoding rules
Enumeration field
Floating point number
Bit string
value constraints
binary encoding rules
dynamic length
Array
Sequence
up to one component of dynamic length
can put additional constraints on member types

8. Integer Value constraints: Interval with open or closed boundaries
<int name="MyInt">   
   
  <constraints>       
    <interval lbound="closed" lvalue="-10"     
              rbound="open" rvalue="10"/>      
    <const value="15"/>      
  </constraints>      
  <encoding representation="positive"     
            size="16" endianness="big"/>     
</int>  
Value constraints:
Interval with open or closed boundaries
Constant value
Multiple constraints result in an union
Binary encoding rules:
Required if the type is used as a packet or memory field
Supported representations: positive and two’s-complement
Size expressed in bits
Little-endian encoding available only for sizes: 16b, 32b, 64b, etc.

9. Enumeration Value constraints: Finite set of options
<enum name="MyEnum">     
  <constraints>    
    <option name="run">    
      <const value="0"/>    
    </option>    
    <option name="stop">    
      <const value="1"/>    
  </constraints>   
  <encoding size="2" endianness="big"/>   
</enum>  
Value constraints:
Finite set of options
It is possible to assign integer number to the option if necessary
Binary encoding rules:
Required if the type is used as a packet or memory field
Assumed positive encoding
Size expressed in bits
Little-endian encoding available only for sizes: 16b, 32b, 64b, etc.

10. Floating point number Value constraints:
<float name="MyFloat">     
  <constraints>    
    <interval lbound="closed" lvalue="0"    
              rbound="open" rvalue="3.14"/>    
  </constraints>   
  <encoding size="32" endianness="big"/>
    
</float>  
Value constraints:
Interval with open or closed boundaries
Multiple constraints result in an union
Binary encoding rules:
Required if the type is used as a packet or memory field
Assumed IEEE encoding
Size expressed in bits, but only 32 or 64 bits allowed
Support for endianness

11. Bit string Value constraints: Not required
<bit_string name="MyBitString"> 
   
  <constraints>    
    <const bin="1010"/>    
  </constraints>    
  <encoding dynamic="false" size="4"    
            word_size="4" endianness="big"/> 
</bit_string> 
Value constraints:
Not required
Useful to describe a constant bit pattern within a packet
Binary encoding rules:
Support for endianness
For little-endian encoding, word_size attribute is required
Dynamic length:
For variable length, min and max attributes should be provided
For static length, only size attribute is required

12. Array
<array name="MyArray">    
  <element type="MyType"/>    
  <length dynamic="false" count="28"/>    
</array>    
Dynamic length:
For variable length, min and max attributes should be provided
For static length, only count attribute is required

13. Sequence Dynamic length:
<sequence name="MessageComplexMatch">    
  <members> 
   
    <member name="header" type="MyHeader">    
      <sequence_subconstraints>    
        <member name="sync">    
          <subconstraints>    
            <const hex="BEEF"/>    
          </subconstraints>    
        </member>    
        <member name="id">    
           <const value="0"/>    
           <interval lbound="closed" lvalue="2"  
                 rbound="closed" rvalue="255"/>  
        <member name="alarm">    
            <option name="red"/>    
            <option name="yellow"/>    
      </sequence_subconstraints>    
    </member> 
    <member name="altitude" type="SomeFloat"/>   
  </members>    
  <encoding word_size="16" endianness="big"/>  
</sequence>  
Dynamic length:
Sequence may have maximum one member of dynamic size
Constraints on member types:
Constraints given here will be intersected with type’s original constraints
Great tool for packet decoding!
Binary encoding rules:
Support for endianness
For little-endian, word_size attribute is required

14. Example of functional interface
<functional_interface class="thermistor">       
  <interface>    
    <acquire>    
      <value_id type="temperature_reading_t"/>    
      <value type="temperature_t"/>    
      <metadata type="bivalent_t"/>    
    </acquire>     
    <command>    
      <value_id type="alter_refresh_rate_t"/>    
      <value type="interval_t"/>    
    </command>    
  </interface>    
  <data_types>    
    <sequence name="temperature_reading_t">    
      <declare name="header" type="value_id_header_t">    
        <constraint field="service">    
          <option name="read_temperature"/>    
        </constraint>    
      </declare>    
      <declare name="unit" type="thermistor_unit_t"/>    
    </sequence>    
    <!-- temperature_t, bivalent_t, thermistor_unit_t  -->  
    <!-- alter_refresh_rate_t, interval_t, ... -->  
  </data_types>    
</functional_interface>  
this section lists all possible relations
relation which can be aquired
relation is identified by value_id type
relation which can be commanded
structure of exchanged data
structure of associated metadata
this section defines all data types used
value_id may contain many fields

15. Process description

16. Instructions Data handling immediate values aliases
variables: declaring, accessing
moving data
arithmetic operations
Calibration
linear calibration
Flow control
loops
conditional statements
Using SOIS services
Device Access Service
Packet Service
Memory Access Service

17. Data handling Immediate values Moving data Aliases Declaring variables
<const value="7"/>
<copy>    
  <source>    
    <!-- constant or variable -->    
  </source>    
Aliases
  <destination>    
    <!-- variable -->    
  </destination>    
<alias name="reaction_wheel_address"/>
</copy>
Declaring variables
Arithmetic operations
<declare name="battery_temp" type="temperature_t"/> 
<addition>      
  <result>      
    <variable name="sum"/>      
  </result>      
Accessing variables
  <addend>      
    <variable name="term1"/>      
<variable name="battery_temp"/>
  </addend>          
    <const value="17"/>      
  </addend>      
</addition>

18. Calibration Linear calibration More calibrations could be supported
  <slope>    
    <const value="1"/>    
  </slope>    
  <bias>    
    <const value="-100"/>    
  </bias>    
  <input>    
    <variable name="temperature_raw"/>    
  </input>    
  <output>    
    <variable name="temperature_kelvin"/>    
  </output>    
</linear_calibration>  
More calibrations could be supported

19. Flow control Loops Conditional statements <loop> <compare>
  <interval>    
  <subject>    
    <left bound="closed" value="1"/>    
    <variable name="result"/>    
    <right bound="closed" value="10"/>    
  </subject>    
  </interval>    
  <reference>    
  <iterator>    
    <variable name="threshold"/>    
    <variable name="i"/>    
  </reference>    
  </iterator>    
  <lower_than>    
  <process>    
    <!-- process code A -->    
    <!-- process code -->    
  </lower_than>    
  </process>    
  <greater_than>    
</loop>  
    <!-- process code B -->    
  </greater_than>    
  <equal>    
    <!-- process code C -->    
  </equal>    
  <not_equal>    
    <!-- process code D -->    
  </not_equal>    
</compare> 

20. Using SOIS Services 1/3 Device Access Service Memory Access Service
<das_acquire transaction="save">   
   
  <value_id>  
    <variable name="v_id"/>  
  </value_id>      
  <value>  
    <variable name="temp_data"/>  
  </value>       
  <metadata>  
    <variable name="meta"/>  
  </metadata>   
  <time_limit>  
    <const value="3"/>  
  </time_limit>     
  <on_success>      
    <!-- indication arrived before timeout -->      
  </on_success>  
    
  <on_timeout>      
    <!-- executed if timeout occurred -->      
  </on_timeout>    
</das_acquire>  
Memory Access Service
   
<read_memory>    
  <region name="uart1"/>    
  <data>    
    <variable name="uart_registers"/>    
  </data>    
  <metadata>    
    <variable name="result"/>    
  </metadata>   
  <time_limit>    
    <alias name="reasonable_time_limit"/>    
  </time_limit> 
  <on_success>    
    <!-- indication intercepted before time out -->    
  </on_success>   
  <on_timeout>    
    <!-- executed if time out occurred -->    
  </on_timeout>    
</read_memory> 

21. Using SOIS Services 2/3 Packet service - sending
Packet service – receiving multiple packets
<packet_send>    
<wait_for_packets>     
  <destination_address>    
  <scenario>    
    <alias name="reaction_wheel_addr"/>    
    <minterm>    
  </destination_address>    
      <!-- packet A receive -->   
  <data>    
      <!-- packet B receive -->  
    <variable name="tc_set_rotation"/>    
    </minterm>    
  </data>    
    <process>    
</packet_send>   
      <!-- Executed only if A and B received  -->    
    </process>    
  </scenario>     
Packet service - receiving
      <!-- packet C receive -->  
        
    </minterm>   
<packet_receive>    
  <source_address>    
      <!-- Executed only if A and C received  -->    
    </process>     
  </source_address>    
  </scenario>    
  <timeout>    
    <variable name="tm_ack"/>    
    <time_limit>    
      <alias name="reasonable_time_limit"/>    
</packet_receive>    
    </time_limit>    
   
      <!-- Executed only if timeout has passed  -->    
  </timeout>    
</wait_for_packets> 

22. Using SOIS Services 3/3 Transaction model 1:1 Transaction model Save
Transaction model Passthrough
DAS/DVS
request load
DAS/DVS
save save save
DAS/DVS

23. Example of DACP implementation
<compare>  
  <subject>  
    <variable name="das_meta"/>  
  </subject>  
  <reference>  
    <const value="success"/>  
  </reference>  
  <equal>  
    <linear_calibration>  
      <slope> <const value="1"/> </slope>  
      <bias> <const value="-100"/> </bias>  
      <input> <variable name="temperature_raw"/> </input>  
      <output> <variable name="temperature_kelvin"/> </output>  
    </linear_calibration>  
    <copy>  
      <destination>  
        <variable name="dvs_meta"/>  
      </destination>  
      <source>  
        <const value="success"/>  
      </source>  
    </copy>  
  </equal>  
  <not_equal>  
        <const value="failure"/>  
  </not_equal>  
</compare> 

24. Example of DACP attachment to service interface
<device_abstraction_control_procedure>     
  <request_handler>    
    <variables>    
      <declare name="id" type="temperature_reading_t"/>    
      <declare name="data" type="temperature_t"/>    
      <declare name="meta" type="bivalent_t"/>    
    </variables>    
    <value_id>    
      <variable name="id"/>    
    </value_id>    
    <value>    
      <variable name="data"/>    
    </value>    
    <metadata>    
      <variable name="meta"/>    
    </metadata>    
    <process>    
      <!-- instructions -->  
    </process>    
  </request_handler>    
</device_abstraction_control_procedure> 
Declares variables used inside process description
connects id variable to value_id contents
connects data variable to the value of relation
connects meta data variable to meta data information
description of the process

25. Software framework and toolchain

26. Software framework Queues for primitives Dispatcher thread
Low-level
High-level
System
Queues for primitives
Dispatcher thread
THREAD
Auto-generated DACP/DAP processes

27. Translation tools asn1Scc
Open source ASN.1 compiler developed by Semantix.
The compiler generates C and Ada source code with the proper data type declaration, encoding/decoding functions, initialization procedures and validation of constraints.
OpenGeode
Open source SDL editor developed by ESA.
The program also converts SDL process description into Ada source code.
Custom translator
Dedicated application developed within the EDS study to convert XML interface in ASN.1 sources.

28. Code generation from EDS
fi.asn1
Other devices .asn1 files
EDS Conv
ds.asn1
Documentation
ps.asn1
EDS Conv
mas.asn1
DataView.py
asn1Scc
sys.asn1
Ada source code for encoding, decoding, etc.
dacp.asn1
DVS framework
DAS framework
Supporting library
Generated code
device_fi.asn1
dap.asn1
device_dacp_iv.pr
device_dacp.pr
Man
EDS Conv
device_ds.asn1
device_dap_iv.pr
device_dap.pr
Man
Ada package with instantiation of all processes according to assembly information
EDS
device_ps.asn1
device_mas.asn1
OpenGeode
Man
Documentation
Man
Ada source code of the processes
Other devices .pr files
OpenGeode
assembly information

29. Toolchain – step 1 Translate XML file into series of:
ASN.1 files – interface view
PR files –SDL process
Translation is performed by a dedicated program developed for this purpose.
Translator also performs consistency-checks hard to implement in XSD file (e.g. that maximum one member of a sequence is dynamic).
device_fi.asn1
device_dacp_iv.pr
device_dacp.pr
device_ds.asn1
EDS
device_dap_iv.pr
device_dap.pr
device_ps.asn1
device_mas.asn1

30. Toolchain – step 2
device_fi.asn1
fi.asn1
device_dacp_iv.pr
device_dacp.pr
Create ASN.1 files describing complete interfaces:
fi – functional interface
ds – device-specific interface
ps – packet interface
mas – memory interface
Create ASN.1 files enumerating processes in the system:
dacp – device abstraction control procedures
dap – device-specific access protocols
device_ds.asn1
device_dap_iv.pr
device_dap.pr
device_ps.asn1
EDS
device_mas.asn1
ds.asn1
device_fi.asn1
device_dacp_iv.pr
device_dacp.pr
ps.asn1
device_ds.asn1
device_dap_iv.pr
device_dap.pr
EDS
device_ps.asn1
device_mas.asn1
mas.asn1
device_fi.asn1
device_dacp_iv.pr
device_dacp.pr
device_ds.asn1
sys.asn1
device_dap_iv.pr
device_dap.pr
EDS
device_ps.asn1
device_mas.asn1
dacp.asn1
dap.asn1
device_mas.asn1

31. Toolchain – step 3
Using asn1Scc program, process all ASN.1 files. On output, we get:
Documentation on data types in HTML format
Ada source code for handling those data types
DataView.py – a Python source code with all information on data types. This file is used by OpenGeode to validate the SDL code
Documentation
device_ds.asn1
ps.asn1
ds.asn1
device_fi.asn1
fi.asn1
device_ps.asn1
DataView.py
device_mas.asn1
sys.asn1
dacp.asn1
mas.asn1
dap.asn1
device_mas.asn1
Ada source code for encoding, decoding, etc.

32. Toolchain – step 4
Using OpenGeode program, process all PR files. On output, we get:
Documentation (SDL code expressed by grahpical blocks according to ITU-T Z.106 standard)
Ada source code
Documentation
DataView.py
device1_dap_iv.pr
device1_dap.pr
device2_dacp_iv.pr
device2_dacp.pr
device3_dap_iv.pr
device3_dap.pr
device1_dacp_iv.pr
device1_dacp.pr
device3_dacp_iv.pr
device3_dacp.pr
device2_dap_iv.pr
device2_dap.pr
Ada source code of a process

33. Toolchain – step 5
Using assembly information, another package is created. This package instantiates generic Ada processes. Each process is assigned with a process id. Each device is assigned with a value id. At the moment, this is done manually.
Ada process code
dacp.ads
Ada process code
Ada process code
dap.ads
Ada process code
Ada package with instantiation of all processes according to assembly information
assembly information
EDS
ADDR 48 49 50 51 52
EDS
EDS
EDS

34. Toolchain – step 6
Final step is to link together the generated code with the static source code of the services. DVS and DAS implementation can be considered as a framework, that handles primitive queueing and calls auto-generated processes.
Ada package with instantiation of all processes according to assembly information
Implementation of DVS service
Implementation of DAS service
Implementation of supporting procedures (e.g. calibration)

35. Recap and open points

36. Recap Achieved in the EDS study
Data types and interface definition based on ASN.1
Process description based on SDL
Transaction-level model for services
“Informal” EDS XML Schema
Mapping between XML and ASN.1
Translator from XML to ASN.1
Mapping between XML and SDL
Code generation using custom and open source tools
DVS service implementation

37. Future work? Potential future work
To implement the translator from XML to SDL
To convert EDS Schema to XSD file
To implement DAS service
To automation the assembly process
To test generated code in mission context

38. Open points Open Points Should EDS interface promote ASN.1?
State machines vs. transactional model
Service models as part of the EDS or of the framework?