First Draft Schema Overview CCSDS Spring Meeting 2013

First Draft Schema Overview CCSDS Spring Meeting 2013 Peter Mendham, Richard Melvin, Ivan Dankiewicz, Stuart Fowell 2013 -04 -16

Overview • • • Design drivers and goals Schema/EDS architecture Specifying device behaviour Limitations of the current draft Presenter 1 & Presenter 2 Alternative approaches Tuesday 9 April 2013 Example data sheet walk-through 2013 -0416 SOIS EDS 2

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 – 2013 -0416 Units, dimensions, meanings etc. SOIS EDS 3

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 – – – 2013 -0416 Less to understand, parse, validate Less complexity in code generation Con: constructs are quite abstract SOIS EDS 4

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 2013 -0416 SOIS EDS 5

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 2013 -0416 SOIS EDS 6

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” – – 2013 -0416 A packet is a container with a specified encoding Container specification is inherited from XTCE SOIS EDS 7

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 – 2013 -0416 Not a problem for use with a tool SOIS EDS 8

Documentation • Documentation inherited from XTCE • Each major element can have – – A short description attribute A long description child element • Long descriptions may contain HTML 2013 -0416 SOIS EDS 9

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 – 2013 -0416 Difference is in whether types have representation information SOIS EDS 10

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 • – 2013 -0416 Packets, memory (register) formats etc. How the container formats are used (patterns) SOIS EDS 11

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 transitions • Each transition has (all optional) – – – A trigger event A guard condition An activity to invoke • Each state has (all optional) – – – 2013 -0416 An entry activity An exit activity A “do” activity SOIS EDS 12

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 – – – 2013 -0416 More declarative Easier to analyse Easier to generate analysable code from (e. g. Ravenscar compliant) SOIS EDS 13

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 2013 -0416 SOIS EDS 14

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 – 2013 -0416 Good candidate for simplification. . . SOIS EDS 15

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” – – – 2013 -0416 Places where the device itself can be configured e. g. by DIP switch Need to be exposed as “configuration parameters” SOIS EDS 16

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 2013 -0416 SOIS EDS 17

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 – – – 2013 -0416 Permits activities to be called from multiple places Could also permit in-line definition May shorten XML but little functional impact SOIS EDS 18

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 – – – 2013 -0416 Larger schema Less flexible Less extensible SOIS EDS 19

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 reinventing 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 2013 -0416 SOIS EDS 20

Example Data Sheet 2013 -0416 SOIS EDS 21

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 2013 -0416 SOIS EDS 22

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 <seds: Device> <seds: Component. Set> <seds: DAS name="Demo. Device. DAS" type="/Demo. Device. DASType"> </seds: DAS> </seds: Component. Set> </seds: Device> • The component interface and function is defined by the component type – “Demo. Device. DASType” – In the namespace “Demo” • Shows that XTCE naming conventions are used by schema 2013 -0416 SOIS EDS 23

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: Component. Type. Set> <seds: Component. Type name="Demo. Device. DASType"> <xtce: Long. Description> This is the component describing DAS (i. e. the DSAP) </xtce: Long. Description> <seds: Provided. Interface. Set > <seds: Interface name="Device. Interface" type="Demo. Device. DASInterface. Type "/> </seds: Provided. Interface. Set > <seds: Required. Interface. Set > <seds: Interface name="Subnetwork. PS" type="/CCSDS/SOIS/Subnetwork/PSInterface. Type "/> <seds: Interface name="Subnetwork. MAS" type="/CCSDS/SOIS/Subnetwork/MASInterface. Type "/> </seds: Required. Interface. Set > <seds: Implementation> … </seds: Implementation> </seds: Component. Type. Set> </seds: Namespace> 2013 -0416 SOIS EDS 24

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: Interface. Type. Set> <seds: Interface. Type name="Demo. Device. DASInterface. Type "> <seds: Parameter. Set> <!-- Information acquired over the MAS interface to the device --> <seds: Parameter name="status" type="Status. Type" read. Only="true"/> <seds: Parameter name="query. Count" type="Query. Count. Type" read. Only="true"/> <seds: Parameter name="extended. Status" type="Extended. Status. Type" read. Only="true"/> <seds: Parameter name="extended. Mode" type="Extended. Mode. Type" read. Only="true"/> <!-- Information acquired over the PS interface to the device --> <!-- These are updated asyncronously, i. e. asynchronously issue indications --> <seds: Parameter name="telemetry. Set 1" type="Telemetry. Set 1 Type" mode="async" read. Only="true"/> <seds: Parameter name="telemetry. Set 2" type="Telemetry. Set 2 Type" mode="async" read. Only="true"/> </seds: Parameter. Set> <seds: Command. Set> … </seds: Command. Set> </seds: Interface. Type. Set> … </seds: Namespace> 2013 -0416 SOIS EDS 25

Example – DAS Interface Type (Commands) • This snippet shows commands only <seds: Namespace name="Demo"> … <seds: Interface. Type. Set> <seds: Interface. Type name="Demo. Device. DASInterface. Type "> <seds: Parameter. Set> … </seds: Parameter. Set> <seds: Command. Set> <!-- Commands issued over the PS interface to the device --> <seds: Command name="set. Mode"> <seds: Argument name="mode" type="Mode. Type" mode="in"/> <seds: Argument name="status" type="Command. Status. Type" mode="out"/> </seds: Command> <seds: Command name="set. User. Data"> <seds: Argument name="data" type="User. Data. Type" mode="in"/> <seds: Argument name="status" type="Command. Status. Type" mode="out"/> </seds: Command> <seds: Command name="device. Event" mode="async"> <seds: Argument name="event. Type" type="Event. Type"/> <seds: Argument name="event. Data" type="Event. Data. Type"/> </seds: Command. Set> </seds: Interface. Type. Set> … </seds: Namespace> 2013 -0416 SOIS EDS 26

Example – Defining a packet • A packet is just a container with encoding information • This packet has variable structure – Taken directly from XTCE <seds: Container. Parameter. Type name="Telecommand. Type"> <seds: Entry. List> <seds: Parameter. Member name="type" type="Telecommand. Type. Enum. Type"/> <seds: Parameter. Member name="mode" type="Mode. Type"> <seds: Include. Condition> <xtce: Comparison parameter. Ref="type" value="Mode"/> </seds: Include. Condition> </seds: Parameter. Member> <seds: Parameter. Member name="length" type="User. Data. Length. Type"> <seds: Include. Condition> <xtce: Comparison parameter. Ref="type" value="User. Data"/> </seds: Include. Condition> </seds: Parameter. Member> <seds: Array. Member name="user. Data" type="User. Data. Type"> <seds: Dimension. List><seds: Dimension> <seds: Starting. Index><xtce: Fixed. Value>0</xtce: Fixed. Value></seds: Starting. Index> <seds: Ending. Index><xtce: Dynamic. Value> <xtce: Parameter. Instance. Ref parameter. Ref="length"/> </xtce: Dynamic. Value></seds: Ending. Index> </seds: Dimension></seds: Dimension. List> </seds: Array. Member> </seds: Entry. List> </seds: Container. Parameter. Type > 2013 -0416 SOIS EDS 27

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: Container. Parameter. Type name="Telecommand. Mode. Type"> <seds: Base. Container type="Telecommand. Type"> <seds: Restriction. Criteria > <xtce: Comparison parameter. Ref="type" value="Mode"/> </seds: Restriction. Criteria > </seds: Base. Container> </seds: Container. Parameter. Type > 2013 -0416 SOIS EDS 28

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 2013 -0416 SOIS EDS 29

Example – State Machine • State machine for extended status/mode acquisition • Initially responds to primitives acquiring extended. Mode or extended. Status parameters on the device interface 2013 -0416 SOIS EDS 30

Example – Activities • State machine for extended status/mode acquisition • Initially responds to primitives acquiring extended. Mode or extended. Status parameters on the device interface 2013 -0416 SOIS EDS 31

Example – State Machine XML <seds: State. Machine name="Get. Extended. Status. Mode" default. Entry. State="Reset"> <seds: Entry. State name="Reset"/> <seds: Transition name="Startup" from. State="Reset" to. State="Idle"/> <seds: State name="Idle"/> <seds: Transition name="Command. Get. Mode" from. State="Idle" to. State="Wait. For. Command. Complete"> <seds: On. Event transaction="Get. Extended. Status. Mode. Param " parameter="Device. Interface/extended. Mode " operation="get"/> <seds: Do activity="Get. Extended. Mode"/> </seds: Transition> <seds: Transition name="Command. Get. Status" from. State="Idle" to. State="Wait. For. Command. Complete"> <seds: On. Event transaction="Get. Extended. Status. Mode. Param " parameter="Device. Interface/extended. Status " operation="get"/> <seds: Do activity="Get. Extended. Status"/> </seds: Transition> <seds: State name="Wait. For. Command. Complete"/> <seds: Transition name="Get. Status. Mode" from. State="Wait. For. Command. Complete" to. State="Wait. For. Reply"> <seds: On. Event transaction="Get. Extended. Status. Mode. Write " command="Subnetwork. MAS/write"/> <seds: Do activity="Get. Extended. Status. Mode"/> </seds: Transition> <seds: State name="Wait. For. Reply"/> <seds: Transition name="Get. Reply" from. State="Wait. For. Reply" to. State="Idle"> <seds: On. Event transaction="Get. Extended. Status. Mode. Read " command="Subnetwork. MAS/read"> <seds: Argument. Value name="data"> <seds: Parameter. Instance. Ref parameter. Ref="extended. Status. Mode"/> </seds: Argument. Value> </seds: On. Event> <seds: Do activity="Return. Extended. Status. Mode "/> </seds: Transition> </seds: State. Machine> 2013 -0416 SOIS EDS 32

Example – Activity XML (1) • This is the “Get. Extended. Mode” activity • Directly follows the UML semantics <seds: Activity name="Get. Extended. Mode"><seds: Implementation> <seds: Assignment output. Parameter. Ref="extended. Query. Type"> <seds: Value>Mode</seds: Value> </seds: Assignment> <seds: Command transaction="Get. Extended. Status. Mode. Write " command="Subnetwork. MAS/Write"> <seds: Argument. Value name="memory. ID"> <seds: Parameter. Instance. Ref parameter. Ref="Memory. ID"/> </seds: Argument. Value> <seds: Argument. Value name="memory. Address"> <seds: Parameter. Instance. Ref parameter. Ref="Command. Address"/> </seds: Argument. Value> <seds: Argument. Value name="data"> <seds: Value>Read. Status. Mode. Command. Type. Read. Mode </seds: Value> </seds: Argument. Value> </seds: Command> </seds: Implementation></seds: Activity> 2013 -0416 SOIS EDS 33

Example – Activity XML (2) • This is the “Return. Extended. Status. Mode” activity • Uses an XTCE conditional <seds: Activity name="Return. Extended. Status. Mode "><seds: Implementation> <seds: Conditional> <seds: Condition><xtce: Condition> <xtce: Parameter. Instance. Ref parameter. Ref="extended. Query. Type"/> <xtce: Comparison. Operator>==</xtce: Comparison. Operator> <xtce: Value>Mode</xtce: Value> </xtce: Condition></seds: Condition> <seds: On. Condition. True> <seds: Parameter transaction="Get. Extended. Status. Mode. Reply " parameter="Device. Interface/extended. Mode " operation="get"> <seds: Argument. Value> <seds: Parameter. Instance. Ref parameter. Ref="extended. Status. Mode"/> </seds: Argument. Value> </seds: Parameter> </seds: On. Condition. True> <seds: On. Condition. False> <seds: Parameter transaction="Get. Extended. Status. Mode. Reply " parameter="Device. Interface/extended. Status " operation="get"> <seds: Argument. Value> <seds: Parameter. Instance. Ref parameter. Ref="extended. Status. Mode. Status "/> </seds: Argument. Value> </seds: Parameter> </seds: On. Condition. False> </seds: Conditional> </seds: Implementation></seds: Activity> 2013 -0416 SOIS EDS 34

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 2013 -0416 SOIS EDS 35