Space Wire PlugandPlay A Roadmap Peter Mendham Albert

Space. Wire Plug-and-Play: A Roadmap Peter Mendham, Albert Ferrer Florit, Steve Parkes Space Technology Centre, University of Dundee 1

Overview 2 Background Principles and approach Overview of Space. Wire-Pn. P services Service descriptions Legacy support and implementation Relationship with Space. Wire-RT Conclusions

Background Plug-and-Play for Space. Wire – 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 3

Principles Interoperability – Promote hardware and software reuse – Create more potential for off-the-shelf components – Permit network discovery and verification Services for Space. Wire networks – Discovery – Identification – Configuration Provide support for features defined in the Space. Wire standard If it is optional in the Space. Wire standard it should be optional in plug-and-play 4

Perspective Pn. P views the network like the Space. Wire standard – Links – Nodes – Routers Devices 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 Pn. P transactions In a running system, every device can have one owner node which is responsible for that device 5

Space. Wire Protocol Stack User Applications User Application Sp. W Pn. P PTP RMAP Pn. P User memory control Sp. W-RT Qo. S Space. Wire Sp. W Space. Wire-Pn. P Service Interface

Space. Wire-Pn. P 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 7

Device Identification and Status Node or router and number of links Vendor and device ID Optional plain text device and vendor descriptions Instance identifier Space. Wire-Pn. P feature support Active ports Device level parameters – Overall device errors/status – Protocol ID error reporting – Pn. P error reporting Standardised discovery algorithm 8

Capability Discovery Space. Wire-Pn. P only considers things relevant to Space. Wire “Capabilities” = Protocols Lists protocol IDs supported Electronic data sheets also supported – Just a mechanism for accessing – Vendor defined format(s) – Permits support for x. TEDS 9

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 Pn. P router must offer at least one routing table entry – No race condition A device may lose ownership to a new owner with higher priority 10 – Priority is pre-defined or based on physical port

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 Pn. P address space Allows full control of all requests in a standardised manner with owner intervention 11

Owner Proxy Example 60 N R Router responds Owner Node responds decides to to original access request Access routing ofpermit “router” LA = 60 Owner of table Router has LA =at 60 Accesses real with proxy ID = 10 Proxy ID = router 10 12

Link and Router Configuration Link configuration (all devices) – – Link state Check/reset status Query Max speed Set speed Router configuration (routers only) – – 13 Set routing tables Control arbitration Configure timeouts Control time-code propagation

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 Pn. P 14

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 15

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) 16

Space. Wire-Pn. P and RMAP User Applications User Application Sp. W Pn. P PTP RMAP Pn. P User memory control Sp. W-RT Qo. S Space. Wire Sp. W Space. Wire-Pn. P RMAP Interface

Use of RMAP and Legacy Support Specific implementation of RMAP Fully compliant with RMAP standard – Except for unique protocol ID to identify Space. Wire-Pn. P Support for some legacy devices is possible – If the active nodes/managers are aware Sp. W-10 X supports all core services – But using RMAP rather than Space. Wire-Pn. P – Some special timeouts necessary in ownership algorithms – Can be used on a Space. Wire-Pn. P network with special support Can be supported on other devices 18 – e. g. On the RTC using a software implementation

Integration with Space. Wire-RT Could have a close relationship with Space. Wire-RT Pn. P can be used to configure and manage RT channels RT can be used to provide Qo. S for Pn. P RT service offered by Pn. P – – – 19 Service status Open channel Close channel Channel status Channel open requests

Conclusions Space. Wire-Pn. P proposal intends to be – Highly flexible – Extensible Leverages existing technology Legacy support considered Potential for including support for new features such as interrupts Basis for interoperability Lower development. . . – Time – Costs – Risk 20