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

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

EDS study overview

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

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

Interface description

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

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.

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.

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 IEEE754-1985 encoding Size expressed in bits, but only 32 or 64 bits allowed Support for endianness

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

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

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

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

Process description

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

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>

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

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> 

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> 

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> 

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

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> 

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

Software framework and toolchain

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

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.

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

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

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

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.

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

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

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)

Recap and open points

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

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

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?