2013-10-29

Updated Draft Schema Overview

CCSDS Fall Meeting 2013

Peter Mendham, Richard Melvin, Stuart Fowell

SOIS EDS2013-10-29

2

Presenter 1 & Presenter 2Tuesday 9 April 2013

Overview

• Design drivers and goals• Schema/EDS architecture• Specifying device behaviour• Limitations of the current draft• Alternative approaches• Example data sheet walk-through

• Includes work in progress

SOIS EDS2013-10-29

3

Design Drivers

• Requirements as captured by the activity• Outputs of the technology survey• Reuse XTCE as much as possible

– Data model has been simplified

• Align with UML state machine semantics– Allows tool interaction with XMI

• Roughly align with UML class/interface semantics– Again, aimed at easing tool interaction– Not entirely possible given other requirements

• Use RDF/OWL for ontological information– Units, dimensions, meanings etc.

SOIS EDS2013-10-29

4

Design Goals

• Enable reuse as much as possible

• Permit reuse of various data sheet elements

• Reuse of interfaces and data types– Permits definitions of standard interfaces

– Permits reuse of vendor-specific interfaces across devices (“vendor standards”)

• Reuse of protocols– e.g. PUS Service 1

– Reuse of packet formats + state machine

• Reuse of algorithms/procedures– Not necessarily stateless

• Define a minimal set of constructs that can be used for everything– Less to understand, parse, validate

– Less complexity in code generation

– Con: constructs are quite abstract

SOIS EDS2013-10-29

5

High-Level View

• DVS and DAS are components

• A component has– Provided interfaces (one or more)

– Required interfaces (one or more)

– An implementation (one)

• The subnetwork is a component with provided interfaces only

– No implementation in data sheet

• Interfaces are instances of an interface type

• Interface types could be standardised

• As far as the schema is concerned the subnetwork is just another component

– Code generator would know otherwise

SOIS EDS2013-10-29

6

Interfaces

• An interface type defines an interface in terms of– Parameters (attributes)

– Commands (operations)

• Parameters– Have a specified data type

– Can be acquired

– Could be set if DVS/DAS interface was extended

• Commands– Can have zero or more arguments

– Each argument is typed

– Arguments can have in/out/inout modes

– Can be invoked

• Parameters can be marked as “async”– Asynchronous “publishing” of parameters

– Corresponds to unmatched or many indications for one request

SOIS EDS2013-10-29

7

Data Types

• Type system inherited from XTCE– Heavily simplified

• A few basic types– Integer, float, string, boolean etc.

• Valid ranges can be specified– e.g. for integer– Appropriate for functional (DVS-level) interfaces

• Encodings can be specified– Appropriate for DACP and DAS-level interfaces

• Semantics are attached to types via– Terms set as attributes included from the core DoT– A link to a custom ontology (a URI)

• Structures/records are specified as “containers”– A packet is a container with a specified encoding– Container specification is inherited from XTCE

SOIS EDS2013-10-29

8

Namespaces

• All types are specified in namespaces• Avoids name clashes• Makes type naming easier• Makes type naming more self-explanatory• Does add visual complexity to the XML file itself

– Not a problem for use with a tool

SOIS EDS2013-10-29

9

Documentation

• Documentation inherited from XTCE• Each major element can have

– A short description attribute– A long description child element

• Long descriptions may contain HTML

SOIS EDS2013-10-29

10

Component Types

• Components are instances of component types

• Component type has– Provided interfaces

– Required interfaces

– Implementation

• Implementation has– Data types used internally

– Parameters used internally

– State machines

– Activities

• No difference between schema for DVS-level and DAS-level component types

– Difference is in whether types have representation information

SOIS EDS2013-10-29

11

Component Implementations and Protocols

• A protocol is defined by– Communications container formats (e.g. packets)– State machines

• The schema is designed to make the specification of protocols easy

– And other interactions, processes etc.

• It is easy to extract from a schema– What container formats are used on which service

• Packets, memory (register) formats etc.

– How the container formats are used (patterns)

SOIS EDS2013-10-29

12

State Machines

• State machine semantics match those of UML

• Each state machine has– One or more entry states

– Zero or more exit states

– One or more states

– One or more transitions

• Each transition has (all optional)– A trigger event

– A guard condition

– An activity to invoke

• Each state has (all optional)– An entry activity

– An exit activity

– A “do” activity

SOIS EDS2013-10-29

13

Activities

• Activities are invoked by state machines

• Activities contain a procedural sequence of steps

• Can include mathematical algorithms

• Can send service primitives– As described by the SOIS books

– xxx.request to a required interface

– xxx.indication to a provided interface

• Cannot wait on the receipt of a service primitive– This is the job of the state machine

• Activities are therefore non-blocking

• This makes activities– More declarative

– Easier to analyse and optimise

– Easier to generate analysable code from (e.g. Ravenscar compliant)

SOIS EDS2013-10-29

14

State Machine Event Model

• Events are processed as per UML semantics

• Events are actually service primitives– As described by the SOIS books

• A xxx.indication primitive from a required interface

• A xxx.request primitive from a provided interface

• In summary:– State machines sink primitives– Activities source primitives

SOIS EDS2013-10-29

15

Shorthand for Mappings

• Where a parameter on a provided interface maps onto a parameter on a required interface

• Via some kind of stateless transformation • Such as a calibration

• Normally requires (per parameter)• A two-state state machine• One activity for read-only• Two activities for read-write

• Common in DVS components

• Leads to long data sheets

• Current schema contains a short hand construct• Removes state machine and abbreviates activity/activities

SOIS EDS2013-10-29

16

Component Types and Reuse

• Components (DVS, DAS) are defined as instances of component types

• Component implementations may also contain component instances

– Sub-components– Allows re-use of elements e.g. protocols

• It is possible to delegate interfaces to sub-components

SOIS EDS2013-10-29

17

Generic Interface and Component Types

• The current schema introduces the concept of generic interface types

• Like generics in Java, C#, Ada etc.

• A bit like (a very simple version of) C++ templates

• This means that interfaces can be defined independently of their data types

• Good for creating strongly-typed subnetwork interfaces• When a subnetwork interface is used the types used across the

subnetwork must be identified

• Good for re-use• Can easily create protocols independent of data type

• Very much a work in progress• May yet be heavily modified or dropped altogether

SOIS EDS2013-10-29

18

Subnetwork Constraints

• Specific subnetworks have specific variability points• Address(es)• Communications speeds• Valid operating states• etc.

• Devices will constrain the possible range of these variability points

• Specific address• Limited link speed support• Subnetwork protocol support• etc.

• Current draft schema includes support for specifying the subnetwork constraints

• For SpaceWire only• Other subnetworks should be analysed and added

SOIS EDS2013-10-29

19

Non-Functional Data

• Need a mechanism for specifying non-functional data• Mass• Physical dimensions• Pinouts• etc.

• Current schema includes a straightforward and extensible mechanism

• Can add typed, constant data items with semantic tags• A constant value (number or string) can be added• It can be associated with a semantic concept• Semantics could be from core or custom ontology

• Can also group data items into categories• Categories can be semantically tagged

• Both categories and data items can have associated documentation

SOIS EDS2013-10-29

20

Conclusions

• The draft schema defines a simple but very flexible set of constructs

• The schema is defined to promote standardisation and reuse

• Re-use from XTCE is a design principle

• The design is intended to make it easier for tooling to– Work with existing MDE/CASE tools (avoid re-

inventing the wheel)– Generate code for a wide range of devices from

relatively few linguistic constructs (simplify code generators)

• A number of simplification strategies have been identified– De-scope schema features– Specialise the subnetwork interface

SOIS EDS2013-10-29

21

Example Data Sheet

SOIS EDS2013-10-29

22

Example – Overview

• Very simple example intended to explore and demonstrate the schema

• Not based on any existing device

• Covers DAS only– Very simple DVS included to show short hand only

• Provides one vendor-specific DAS interface

• Uses both MAS and PS interfaces– Interfaces required from subnetwork component(s)

• The example includes a component definition for the subnetwork

– Uses XInclude to pull this into the data sheet

SOIS EDS2013-10-29

23

Example – DAS and DVS Components

• First section of data sheet declares the component instances used for DVS and DAS

• One for each, connected together

• The component interface and function is defined by the component type

– “DemoDeviceDASType”– In the namespace “Demo”

• Shows that XTCE naming conventions are used by schema

<seds:Device><seds:DVS name="DemoDeviceDVS" type="/Demo/DemoDeviceDVSType">

<seds:Connection interface="DeviceInterface" connector="DeviceInterfaceConnector"/></seds:DVS><seds:DAS name="DemoDeviceDAS" type="/Demo/DemoDeviceDASType">

<seds:Connection interface="DeviceInterface" connector="DeviceInterfaceConnector"/></seds:DAS>

</seds:Device>

SOIS EDS2013-10-29

24

Example – DAS Component Type (PS Usage)

• This is the definitions of the DAS implementation

• Shows which interfaces it provides and requires<seds:Namespace name="Demo"> … <seds:ComponentTypeSet> <seds:ComponentType name="DemoDeviceDASType"> <xtce:LongDescription> This is the component describing DAS (i.e. the DSAP) </xtce:LongDescription> <seds:ProvidedInterfaceSet> <seds:Interface name="DeviceInterface" type="DemoDeviceDASInterfaceType"/> </seds:ProvidedInterfaceSet> <seds:RequiredInterfaceSet> <seds:Interface name="SubnetworkPS" type="/CCSDS/SOIS/Subnetwork/MASInterfaceType"> <seds:GenericTypeMapSet> <seds:GenericTypeMap name="sendDataType" type="TelecommandType"/> <seds:GenericTypeMap name="receiveDataType" type="TelemetryType"/> </seds:GenericTypeMapSet> </seds:Interface> … </seds:RequiredInterfaceSet> <seds:Implementation> … </seds:Implementation> </seds:ComponentType> </seds:ComponentTypeSet></seds:Namespace>

SOIS EDS2013-10-29

25

Example – DAS Component Type (MAS usage)<seds:Namespace name="Demo"> … <seds:ComponentTypeSet> <seds:ComponentType name="DemoDeviceDASType"> <xtce:LongDescription> This is the component describing DAS (i.e. the DSAP) </xtce:LongDescription> <seds:ProvidedInterfaceSet> <seds:Interface name="DeviceInterface" type="DemoDeviceDASInterfaceType"/> </seds:ProvidedInterfaceSet> <seds:RequiredInterfaceSet> … <seds:Interface name="SubnetworkMAS_Status" type="/CCSDS/SOIS/Subnetwork/MASInterfaceType"> <seds:GenericTypeMapSet> <seds:GenericTypeMap name="readDataType" type="StatusType"/> </seds:GenericTypeMapSet> </seds:Interface> <seds:Interface name="SubnetworkMAS_ExtendedStatusMode" type="/CCSDS/SOIS/Subnetwork/MASInterfaceType"> <seds:GenericTypeMapSet> <seds:GenericTypeMap name="readDataType" type="ExtendedStatusModeType"/> <seds:GenericTypeMap name="writeDataType" type="ReadStatusModeCommandType"/> </seds:GenericTypeMapSet> </seds:Interface> </seds:RequiredInterfaceSet> <seds:Implementation> … </seds:Implementation> </seds:ComponentType> </seds:ComponentTypeSet></seds:Namespace>

SOIS EDS2013-10-29

26

Example – DAS Interface Type (Parameters)

• The interface to the DAS device contains both parameters and commands

– Snippet shows parameters only<seds:Namespace name="Demo"> … <seds:InterfaceTypeSet> <seds:InterfaceType name="DemoDeviceDASInterfaceType"> <seds:ParameterSet> <!-- Information acquired over the MAS interface to the device --> <seds:Parameter name="status" type="StatusType" readOnly="true"/> <seds:Parameter name="queryCount" type="QueryCountType" readOnly="true"/> <seds:Parameter name="extendedStatus" type="ExtendedStatusType" readOnly="true"/> <seds:Parameter name="extendedMode" type="ExtendedModeType" readOnly="true"/> <!-- Information acquired over the PS interface to the device --> <!-- These are updated asyncronously, i.e. asynchronously issue indications --> <seds:Parameter name="telemetrySet1" type="TelemetrySet1Type" mode="async" readOnly="true"/> <seds:Parameter name="telemetrySet2" type="TelemetrySet2Type" mode="async" readOnly="true"/> <seds:Parameter name="deviceEvent" type="EventType" mode="async" readOnly="true"/> </seds:ParameterSet> <seds:CommandSet> … </seds:CommandSet> </seds:InterfaceType> </seds:InterfaceTypeSet> …</seds:Namespace>

SOIS EDS2013-10-29

27

Example – DAS Interface Type (Commands)

• This snippet shows commands only<seds:Namespace name="Demo"> … <seds:InterfaceTypeSet> <seds:InterfaceType name="DemoDeviceDASInterfaceType"> <seds:ParameterSet> … </seds:ParameterSet> <seds:CommandSet> <!-- Commands issued over the PS interface to the device --> <seds:Command name="setMode"> <seds:Argument name="mode" type="ModeType" mode="in"/> <seds:Argument name="status" type="CommandStatusType" mode="out"/> </seds:Command> <seds:Command name="setUserData"> <seds:Argument name="data" type="UserDataType" mode="in"/> <seds:Argument name="status" type="CommandStatusType" mode="out"/> </seds:Command> </seds:CommandSet> </seds:InterfaceType> </seds:InterfaceTypeSet> …</seds:Namespace>

SOIS EDS2013-10-29

28

Example – Defining a packet

• A packet is just a container with encoding information

• This packet has variable structure<seds:ContainerParameterType name="TelecommandType">

<seds:EntryList><seds:Entry name="type" type="TelecommandTypeEnumType"/><seds:Entry name="mode" type="ModeType">

<seds:IncludeCondition><seds:Comparison parameterRef="type" value="Mode"/>

</seds:IncludeCondition></seds:Entry><seds:Entry name="length" type="UserDataLengthType">

<seds:IncludeCondition><seds:Comparison parameterRef="type" value="UserData"/>

</seds:IncludeCondition></seds:Entry><seds:Entry name="userData" type="/CCSDS/SOIS/Subnetwork/Octet">

<seds:RepeatEntry><seds:Count>

<seds:DynamicValue><seds:ParameterRef>length</seds:ParameterRef>

</seds:DynamicValue></seds:Count>

</seds:RepeatEntry></seds:Entry>

</seds:EntryList></seds:ContainerParameterType>

SOIS EDS2013-10-29

29

Example – Packets and Memory Locations

• Packets and memory locations defined the same way

• Containers with encoding

• Inheritance supported– Permits specialisation of generic packet definitions

• This is a specialisation of the telecommand on the last slide

• Defining a type makes it easier to match against in state machines

<seds:ContainerParameterType name="TelecommandModeType" baseType="TelecommandType"> <seds:BaseTypeRestrictionCriteria> <seds:Comparison parameterRef="type" value="Mode"/> </seds:BaseTypeRestrictionCriteria></seds:ContainerParameterType>

SOIS EDS2013-10-29

30

Example – MAS Interface

• MAS interface has three memory locations– A command register– A status register– An extended status/mode register

• The contents of the extended status/mode register depend on the command written to the command register

– Shows a realistic device-specific access protocol with more than one state

SOIS EDS2013-10-29

31

Example – State Machine

• State machine for extended status/mode acquisition

• Initially responds to primitives acquiring extendedMode or extendedStatus parameters on the device interface

SOIS EDS2013-10-29

32

Example – Activities

• State machine for extended status/mode acquisition

• Initially responds to primitives acquiring extendedMode or extendedStatus parameters on the device interface

SOIS EDS2013-10-29

33

Example – State Machine XML

<seds:StateMachine name="GetExtendedStatusMode" defaultEntryState="Reset"> <seds:EntryState name="Reset"/> <seds:Transition name="Startup" fromState="Reset" toState="Idle"/> <seds:State name="Idle"/> <seds:Transition name="CommandGetMode" fromState="Idle" toState="WaitForCommandComplete"> <seds:OnEvent transaction="GetExtendedStatusModeParam" parameter="DeviceInterface/extendedMode" operation="get"/> <seds:Do activity="GetExtendedMode"/> </seds:Transition> <seds:Transition name="CommandGetStatus" fromState="Idle" toState="WaitForCommandComplete"> <seds:OnEvent transaction="GetExtendedStatusModeParam" parameter="DeviceInterface/extendedStatus" operation="get"/> <seds:Do activity="GetExtendedStatus"/> </seds:Transition> <seds:State name="WaitForCommandComplete"/> <seds:Transition name="GetStatusMode" fromState="WaitForCommandComplete" toState="WaitForReply"> <seds:OnEvent transaction="GetExtendedStatusModeWrite" command="SubnetworkMAS/write"/> <seds:Do activity="GetExtendedStatusMode"/> </seds:Transition> <seds:State name="WaitForReply"/> <seds:Transition name="GetReply" fromState="WaitForReply" toState="Idle"> <seds:OnEvent transaction="GetExtendedStatusModeRead" command="SubnetworkMAS/read"> <seds:ArgumentValue name="data"> <seds:ParameterInstanceRef parameterRef="extendedStatusMode"/> </seds:ArgumentValue> </seds:OnEvent> <seds:Do activity="ReturnExtendedStatusMode"/> </seds:Transition></seds:StateMachine>

SOIS EDS2013-10-29

34

Example – Activity XML (1)

<seds:Activity name="GetExtendedMode"><seds:Implementation> <seds:Assignment outputParameterRef="extendedQueryType"> <seds:Value>Mode</seds:Value> </seds:Assignment> <seds:Command transaction="GetExtendedStatusModeWrite" command="SubnetworkMAS/Write"> <seds:ArgumentValue name="memoryID"> <seds:ParameterInstanceRef parameterRef="MemoryID"/> </seds:ArgumentValue> <seds:ArgumentValue name="memoryAddress"> <seds:ParameterInstanceRef parameterRef="CommandAddress"/> </seds:ArgumentValue> <seds:ArgumentValue name="data"> <seds:Value>ReadStatusModeCommandType.ReadMode</seds:Value> </seds:ArgumentValue> </seds:Command></seds:Implementation></seds:Activity>

• This is the “GetExtendedMode” activity

• Directly follows the UML semantics

SOIS EDS2013-10-29

35

Example – Activity XML (2)

<seds:Activity name="ReturnExtendedStatusMode"><seds:Implementation> <seds:Conditional> <seds:Condition><seds:Condition> <seds:ParameterInstanceRef parameterRef="extendedQueryType"/> <seds:ComparisonOperator>==</seds:ComparisonOperator> <seds:Value>Mode</seds:Value> </seds:Condition></seds:Condition> <seds:OnConditionTrue> <seds:Parameter transaction="GetExtendedStatusModeReply" parameter="DeviceInterface/extendedMode" operation="get"> <seds:ArgumentValue> <seds:ParameterInstanceRef parameterRef="extendedStatusMode.Mode"/> </seds:ArgumentValue> </seds:Parameter> </seds:OnConditionTrue> <seds:OnConditionFalse> <seds:Parameter transaction="GetExtendedStatusModeReply" parameter="DeviceInterface/extendedStatus" operation="get"> <seds:ArgumentValue> <seds:ParameterInstanceRef parameterRef="extendedStatusMode.Status"/> </seds:ArgumentValue> </seds:Parameter> </seds:OnConditionFalse> </seds:Conditional></seds:Implementation></seds:Activity>

• This is the “ReturnExtendedStatusMode” activity

• Uses a conditional (inherited from XTCE)

SOIS EDS2013-10-29

36

Example – Conclusion

• Relatively simple example

• Illustrates– Most major parts of the schema– A non-trivial DSAP– How XTCE is re-used– How UML semantics are used

• Does not cover– Error handling procedures– Addition of ontological semantics