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

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

2020