1. 2013-10-29 Updated Draft Schema Overview CCSDS Fall Meeting 2013 Peter Mendham, Richard Melvin, Stuart Fowell

2. SOIS EDS 2013-10- 29 2 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 Includes work in progress

3. SOIS EDS 2013-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.

4. SOIS EDS 2013-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

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

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

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

8. SOIS EDS 2013-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

9. SOIS EDS 2013-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

10. SOIS EDS 2013-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

11. SOIS EDS 2013-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)

12. SOIS EDS 2013-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

13. SOIS EDS 2013-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)

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

15. SOIS EDS 2013-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

16. SOIS EDS 2013-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

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

18. SOIS EDS 2013-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

19. SOIS EDS 2013-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

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

21. SOIS EDS 2013-10- 29 21 Example Data Sheet

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

23. SOIS EDS 2013-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

24. SOIS EDS 2013-10- 29 24 Example – DAS Component Type (PS Usage) This is the definitions of the DAS implementation Shows which interfaces it provides and requires … This is the component describing DAS (i.e. the DSAP) … …

25. SOIS EDS 2013-10- 29 25 Example – DAS Component Type (MAS usage) … This is the component describing DAS (i.e. the DSAP) … …

26. SOIS EDS 2013-10- 29 26 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"/> … …

27. SOIS EDS 2013-10- 29 27 Example – DAS Interface Type (Commands) This snippet shows commands only … … …

28. SOIS EDS 2013-10- 29 28 Example – Defining a packet A packet is just a container with encoding information This packet has variable structure length

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

30. SOIS EDS 2013-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

31. SOIS EDS 2013-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

32. SOIS EDS 2013-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

33. SOIS EDS 2013-10- 29 33 Example – State Machine XML <seds:OnEvent transaction="GetExtendedStatusModeParam" parameter="DeviceInterface/extendedMode" operation="get"/> <seds:OnEvent transaction="GetExtendedStatusModeParam" parameter="DeviceInterface/extendedStatus" operation="get"/>

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

35. SOIS EDS 2013-10- 29 35 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 a conditional (inherited from XTCE)

36. SOIS EDS 2013-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