2013-04-16

First Draft Schema Overview

CCSDS Spring Meeting 2013

Peter Mendham, Richard Melvin, Ivan Dankiewicz, Stuart Fowell

SOIS EDS2013-04-16

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

SOIS EDS2013-04-16

3

Design Drivers

• Requirements as captured by the activity• Outputs of the technology survey• Reuse XTCE as much as possible• 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-04-16

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-04-16

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-04-16

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 and commands can be marked as “async”– Asynchronous “publishing” of parameters

– Asynchronous “return” of commands

– Corresponds to unmatched or many indications for one request

SOIS EDS2013-04-16

7

Data Types

• Type system inherited from XTCE

• 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

• At the moment semantics are attached to types via a link to an 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-04-16

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-04-16

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-04-16

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-04-16

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-04-16

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-04-16

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

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

SOIS EDS2013-04-16

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-04-16

15

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

• This may be unnecessarily flexible– Good candidate for simplification...

SOIS EDS2013-04-16

16

Bits Missing from the Draft Schema

• Timed state transitions– Should be easy to add

• Subnetwork constraint specification– Specific properties for each subnetwork type– A bit harder to add

• “Configuration points”– Places where the device itself can be configured– e.g. by DIP switch– Need to be exposed as “configuration parameters”

SOIS EDS2013-04-16

17

Aside: Return Metadata from Service Primitives

• There are two types of data to return from a parameter/command access:

– The data associated with the parameter/command• Parameter value

• “out” parameters of command

– Error information

• Error information could be modelled as an exception

• Exceptions could be first class– Do not need a numeric representation or encoding

• This is done in a number of programming languages– e.g. Modula-2 and -3

• Encoding of exception is decided by tool chain

• In reality this is likely to just be an integer

SOIS EDS2013-04-16

18

Simplification Strategies

• Remove component types– DVS and DAS components defined as singletons– No sub-components– No component-level re-use

• Could remove namespaces• Make some simplifications to data type system?

– Array types?

• At the moment activities are always defined separately to state machines

– Permits activities to be called from multiple places– Could also permit in-line definition– May shorten XML but little functional impact

SOIS EDS2013-04-16

19

Subnetwork Interface Specialisation

• The schema does not treat the subnetwork interface specially

• Could also make the subnetwork interface more specific

• Follow an approach like Piotr's

• No change in information content– Could easily transform between the two

• Pros– Easier to understand

– Static device interface (i.e. exchange units) 'at-a-glance'

• Cons– Larger schema

– Less flexible

– Less extensible

SOIS EDS2013-04-16

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-04-16

21

Example Data Sheet

SOIS EDS2013-04-16

22

Example – Overview

• Very simple example intended to explore and demonstrate the schema

• Not based on any existing device

• Covers DAS only– DVS is not very different though

• 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-04-16

23

Example – DAS Component

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

• Normally there would be one for each, connected together

• Here there is just DAS

• 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:ComponentSet> <seds:DAS name="DemoDeviceDAS" type="/Demo/DemoDeviceDASType"> </seds:DAS> </seds:ComponentSet></seds:Device>

SOIS EDS2013-04-16

24

Example – DAS Component Type

• This is the definitions of the DAS implementation

• Shows which interfaces it provides and requires

• In this case clearly indicates use of both PS and MAS<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/PSInterfaceType"/> <seds:Interface name="SubnetworkMAS" type="/CCSDS/SOIS/Subnetwork/MASInterfaceType"/> </seds:RequiredInterfaceSet> <seds:Implementation> … </seds:Implementation> </seds:ComponentType> </seds:ComponentTypeSet></seds:Namespace>

SOIS EDS2013-04-16

25

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:ParameterSet> <seds:CommandSet> … </seds:CommandSet> </seds:InterfaceType> </seds:InterfaceTypeSet> …</seds:Namespace>

SOIS EDS2013-04-16

26

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:Command name="deviceEvent" mode="async"> <seds:Argument name="eventType" type="EventTypeType"/> <seds:Argument name="eventData" type="EventDataType"/> </seds:Command> </seds:CommandSet> </seds:InterfaceType> </seds:InterfaceTypeSet> …</seds:Namespace>

SOIS EDS2013-04-16

27

Example – Defining a packet

• A packet is just a container with encoding information

• This packet has variable structure– Taken directly from XTCE

<seds:ContainerParameterType name="TelecommandType"> <seds:EntryList> <seds:ParameterMember name="type" type="TelecommandTypeEnumType"/> <seds:ParameterMember name="mode" type="ModeType"> <seds:IncludeCondition> <xtce:Comparison parameterRef="type" value="Mode"/> </seds:IncludeCondition> </seds:ParameterMember> <seds:ParameterMember name="length" type="UserDataLengthType"> <seds:IncludeCondition> <xtce:Comparison parameterRef="type" value="UserData"/> </seds:IncludeCondition> </seds:ParameterMember> <seds:ArrayMember name="userData" type="UserDataType"> <seds:DimensionList><seds:Dimension> <seds:StartingIndex><xtce:FixedValue>0</xtce:FixedValue></seds:StartingIndex> <seds:EndingIndex><xtce:DynamicValue> <xtce:ParameterInstanceRef parameterRef="length"/> </xtce:DynamicValue></seds:EndingIndex> </seds:Dimension></seds:DimensionList> </seds:ArrayMember> </seds:EntryList></seds:ContainerParameterType>

SOIS EDS2013-04-16

28

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"> <seds:BaseContainer type="TelecommandType"> <seds:RestrictionCriteria> <xtce:Comparison parameterRef="type" value="Mode"/> </seds:RestrictionCriteria> </seds:BaseContainer></seds:ContainerParameterType>

SOIS EDS2013-04-16

29

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-04-16

30

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-04-16

31

Example – Activities

• State machine for extended status/mode acquisition

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

SOIS EDS2013-04-16

32

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-04-16

33

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-04-16

34

Example – Activity XML (2)

<seds:Activity name="ReturnExtendedStatusMode"><seds:Implementation> <seds:Conditional> <seds:Condition><xtce:Condition> <xtce:ParameterInstanceRef parameterRef="extendedQueryType"/> <xtce:ComparisonOperator>==</xtce:ComparisonOperator> <xtce:Value>Mode</xtce:Value> </xtce: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 an XTCE conditional

SOIS EDS2013-04-16

35

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