Transcript 04 First Draft Schema Overview

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”
2013-0416
–
Asynchronous “publishing” of parameters
–
Asynchronous “return” of commands
–
Corresponds to unmatched or many indications for one request
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 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:ComponentSet>
<seds:DAS name="DemoDeviceDAS" type="/Demo/DemoDeviceDASType">
</seds:DAS>
</seds:ComponentSet>
</seds:Device>
• 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
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: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>
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: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>
2013-0416
SOIS EDS
25
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>
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: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>
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:ContainerParameterType name="TelecommandModeType">
<seds:BaseContainer type="TelecommandType">
<seds:RestrictionCriteria>
<xtce:Comparison parameterRef="type" value="Mode"/>
</seds:RestrictionCriteria>
</seds:BaseContainer>
</seds:ContainerParameterType>
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 extendedMode or
extendedStatus parameters on the device interface
2013-0416
SOIS EDS
30
Example – Activities
• State machine for extended status/mode acquisition
• Initially responds to primitives acquiring extendedMode or
extendedStatus parameters on the device interface
2013-0416
SOIS EDS
31
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>
2013-0416
SOIS EDS
32
Example – Activity XML (1)
• This is the “GetExtendedMode” activity
• Directly follows the UML semantics
<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>
2013-0416
SOIS EDS
33
Example – Activity XML (2)
• This is the “ReturnExtendedStatusMode” activity
• Uses an XTCE conditional
<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>
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