SpaceWire Plug-and-Play:A Roadmap
Peter Mendham, Albert Ferrer Florit, Steve Parkes Space Technology Centre,
University of Dundee
11
Overview
Background Principles and approach Overview of SpaceWire-PnP services Service descriptions Legacy support and implementation Relationship with SpaceWire-RT Conclusions
22
Background
Plug-and-Play for SpaceWire– Need for rapid integration of subsystems– Ease of use for development and EGSE
Automatic discovery of devices Configuration of devices Adapt to changes in running network
Automatic discovery of services Configuration of services Adapt to changes in running network
33
Principles
Interoperability– Promote hardware and software reuse– Create more potential for off-the-shelf components– Permit network discovery and verification
Services for SpaceWire networks– Discovery– Identification– Configuration
Provide support for features defined in the SpaceWire standard
If it is optional in the SpaceWire standard it should be optional in plug-and-play
44
Perspective
PnP views the network like the SpaceWire standard– Links– Nodes– Routers
Both nodes and routers have links– Nodes have 1 or more links– Routers have 2 or more links
Every device on the network has a port zero– This is the target for PnP transactions
In a running system, every device can have one owner node which is responsible for that device
55
Devices
SpaceWire
PTP RMAP
SpW-RT
User Application
SpW
QoS
User Applications
SpaceWire Protocol Stack
SpW PnP PnP
User memory control
SpaceWire
PTP RMAP
SpW-RT
User Application
SpW
QoS
User Applications
SpaceWire-PnP Service Interface
SpaceWire-PnP Services
Device identification and status Capability discovery Device ownership Owner proxy service Link configuration Router configuration
– Routing tables– Time-code handling
Time-code source Generic data sources Generic data sinks
77
Device Identification and Status
Node or router and number of links Vendor and device ID Optional plain text device and vendor
descriptions Instance identifier SpaceWire-PnP feature support Active ports Device level parameters
– Overall device errors/status– Protocol ID error reporting– PnP error reporting
Standardised discovery algorithm88
Capability Discovery
SpaceWire-PnP only considers things relevant to SpaceWire
“Capabilities” = Protocols Lists protocol IDs supported Electronic data sheets also supported
– Just a mechanism for accessing– Vendor defined format(s)– Permits support for xTEDS
99
Device Ownership
Atomic mechanism for claiming devices Based on RMW Identifies how to contact owner (by LA or PA)
– Also identifies proxy ID (see next slide)– PAs of up to 4 hops may be specified
For routers, also atomically sets routing table entry if LA is used– Ensures that as soon as router is claimed, owner is
contactable– A PnP router must offer at least one routing table entry– No race condition
A device may lose ownership to a new owner with higher priority– Priority is pre-defined or based on physical port
1010
Owner Proxy Service
Device owners offer access to the devices they own via proxy address spaces
An owner may provide up to 255 proxies A device identifies its owner and the proxy
space ID All access to that device go via the proxy
space on the owner A proxy address space is a standard PnP
address space Allows full control of all requests in a
standardised manner with owner intervention
1111
Owner Proxy Example
1212
N
R
60
Owner of Router has LA = 60Proxy ID = 10
Access routing table of “router” at LA = 60with proxy ID = 10
Node decides to permit accessAccesses real router
Router respondsOwner responds to original request
Link and Router Configuration
Link configuration (all devices)– Link state– Check/reset status– Query Max speed– Set speed
Router configuration (routers only)– Set routing tables– Control arbitration– Configure timeouts– Control time-code propagation
1313
Time-Code Source
Optional for any node or router Configure
– Starting count– Frequency
Start and stop as required Manually generate ticks of a specified value
If a device is a time-code source it does not have to expose an interface through PnP
1414
Generic Data Sources
Device may have zero or more data sources Each is identified by a type Each will source packets of a bounded size
(could be smaller) Source data can be accessed using:
– Reads (ready status provided)– Delayed response read (with timeouts)– Initiated RMAP writes
1515
Generic Data Sinks
Device may have zero or more data sinks Each is identified by type Each will sink packets of a specified size
– Size can be specified as applying to all packets– Or as a maximum (permitting smaller packets)
Sink data can be set using:– Unacknowledged writes (ready status provided)– Queued writes with acknowledge (queue of 1 or more)
1616
SpaceWire-PnP and RMAP
User memory control
SpaceWire
PTP RMAP
SpW-RT
User Application
SpW
QoS
User Applications
SpW PnP PnP
SpaceWire-PnP RMAP Interface
Use of RMAP and Legacy Support
Specific implementation of RMAP Fully compliant with RMAP standard
– Except for unique protocol ID to identify SpaceWire-PnP
Support for some legacy devices is possible– If the active nodes/managers are aware
SpW-10X supports all core services– But using RMAP rather than SpaceWire-PnP– Some special timeouts necessary in ownership algorithms– Can be used on a SpaceWire-PnP network with special
support
Can be supported on other devices– e.g. On the RTC using a software implementation1818
Integration with SpaceWire-RT
Could have a close relationship with SpaceWire-RT
PnP can be used to configure and manage RT channels
RT can be used to provide QoS for PnP RT service offered by PnP
– Service status– Open channel– Close channel– Channel status– Channel open requests
1919