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

2. Overview  Background  Principles and approach  Overview of SpaceWire-PnP services  Service descriptions  Legacy support and implementation  Relationship with SpaceWire-RT  Conclusions 2

3. 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 3

4. 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 4

5. 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 5 Devices

6. SpaceWire PTPRMAP SpW-RT User Application SpW QoS User Applications SpaceWire Protocol Stack SpW PnP PnP User memory control SpaceWire PTPRMAP SpW-RT User Application SpW QoS User Applications SpaceWire-PnP Service Interface

7. 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 7

8. 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 algorithm 8

9. 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 9

10. 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 10

11. 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 11

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

13. 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 13

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

15. 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

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

17. SpaceWire-PnP and RMAP User memory control SpaceWire PTPRMAP SpW-RT User Application SpW QoS User Applications SpW PnP PnP SpaceWire-PnP RMAP Interface

18. 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 implementation 18

19. 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 19

20. Conclusions  SpaceWire-PnP 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