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

SOIS EDS Presenter 1 & Presenter 2 Tuesday 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS 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 EDS Example Data Sheet

SOIS EDS 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 EDS 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

SOIS EDS 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 … This is the component describing DAS (i.e. the DSAP) …

SOIS EDS Example – DAS Interface Type (Parameters) The interface to the DAS device contains both parameters and commands – Snippet shows parameters only … <seds:Parameter name="telemetrySet1" type="TelemetrySet1Type" mode="async" readOnly="true"/> <seds:Parameter name="telemetrySet2" type="TelemetrySet2Type" mode="async" readOnly="true"/> … …

SOIS EDS Example – DAS Interface Type (Commands) This snippet shows commands only … … …

SOIS EDS Example – Defining a packet A packet is just a container with encoding information This packet has variable structure – Taken directly from XTCE 0

SOIS EDS 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

SOIS EDS 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 EDS Example – State Machine State machine for extended status/mode acquisition Initially responds to primitives acquiring extendedMode or extendedStatus parameters on the device interface

SOIS EDS Example – Activities State machine for extended status/mode acquisition Initially responds to primitives acquiring extendedMode or extendedStatus parameters on the device interface

SOIS EDS Example – State Machine XML <seds:OnEvent transaction="GetExtendedStatusModeParam" parameter="DeviceInterface/extendedMode" operation="get"/> <seds:OnEvent transaction="GetExtendedStatusModeParam" parameter="DeviceInterface/extendedStatus" operation="get"/>

SOIS EDS Example – Activity XML (1) Mode ReadStatusModeCommandType.ReadMode This is the “GetExtendedMode” activity Directly follows the UML semantics

SOIS EDS Example – Activity XML (2) == Mode <seds:Parameter transaction="GetExtendedStatusModeReply" parameter="DeviceInterface/extendedMode" operation="get"> <seds:Parameter transaction="GetExtendedStatusModeReply" parameter="DeviceInterface/extendedStatus" operation="get"> This is the “ReturnExtendedStatusMode” activity Uses an XTCE conditional

SOIS EDS 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