April 19, 2023

Peter Mendham

The SpaceWire-PnP Protocol: Status and Relationship with SOIS

SpaceWire-PnP2

Agenda

The plug-and-play conceptA little historyKey concepts and terminologySpaceWire-PnP servicesOne service in detailCapability services: data sources and sinksSummary

SpaceWire-PnP3

Plug-and-Play

Refers toDiscoveryConfiguration(Adaptation)

ofDevicesAnd the services those devices provide

SpaceWire-PnP4

A Little History

Recent developments (since 2006) spurred on by ORSAFRL, NRL, GSFC

Contributions from ESA, 4Links, UoDNew protocol proposed meeting the needs of ORS

Implemented and utilised in SPA-SUoD propose the use of RMAP packet format to permit reuse of existing IP (proposed late 2006 early 2007)

Fitted with existing semanticsOther drivers for UoD proposals:

Cover cases other than ORS; fix bugs; ensure wider applicability; provide mechanisms for using existing hardware and software

SpaceWire-PnP5

SOIS Subnetwork Requirements

Network discoveryDevice discovery (polled/notified)Topology discovery

Device identificationUnique identificationType/class

Configuration of subnetwork-specific device features

e.g. address, link speed

Configuration of subnetwork resourcese.g. bus controllers, routers

Sourcing of electronic data sheet

SpaceWire-PnP6

What SpaceWire-PnP Provides

Network discoveryDevice discovery (polled/notified)Topology discovery

Device identificationUnique identificationType/class

Configuration of subnetwork-specific device features

e.g. link speeds

Configuration of subnetwork resourcese.g. routers

Sourcing of electronic data sheet

…and basically nothing else

SpaceWire-PnP7

SpaceWire-PnP: Guiding Principles

UoD working document: SpaceWire-PnPProvide a standard way to discover and configure the standard features of SpaceWire devices

i.e. the features of SpaceWire devices which are identified in the SpaceWire standard

As interoperable as possibleDo not require any extra SpaceWire featuresProvide hooks for service discovery and configuration

But do not implement this: beyond scope

Consider the application to common use cases

SpaceWire-PnP8

SpaceWire-PnP: Protocol

Semantics associated with plug-and-play are mostly get and set

Correspond well to read and write

Why not use an existing, well-defined protocol?

Remote Memory Access Protocol (RMAP)Already well documentedPermits re-use of existing IP

SpaceWire-PnP9

RMAP Utilisation

SpaceWire-PnP uses the packet format and semantics of RMAPStandardises on a well-defined implementation of RMAP

32-bit wide addressing and alignmentBig endianIncrementing addressingAcknowledged, verified writesPre-defined keyRMW implementation (optional) is a conditional write

Uses a different protocol IDTo distinguish from generic RMAP trafficE.g. Mass memory device

SpaceWire-PnP10

Perspective

PnP views the network like the SpaceWire standard

LinksNodesRouters

No topology restrictionsBoth nodes and routers have links

Nodes have 1 or more linksRouters have 2 or more links

Every device on the network has a port zeroThis is the target for PnP transactions

Devices

SpaceWire-PnP11

Levels of Support

Managed NetworksImportant role for system designerCompetition during discovery process removed by designCompetition for configuration of devices removed by designSimplest case

Open NetworksNetwork handles all competition issuesDeals with networks where design is not known a prioriMore flexible but more complicated

Level 1

Level 2

SpaceWire-PnP12

Services

A set of parameters on the targetThis is a standardised RMAP address space

A service interface at the initiatorA description of how the initiator and target will both behave

Initiator Target

SpaceWire

Standardised Interface

Standardised Interface

Standardised Packet Format

Standardised Behaviour

SpaceWire-PnP13

Target Parameters

Follow a regular formParameters are made up of fields

Each field is 32-bitOptionally, a parameter may have multiple entries

This is to permit tables, such as routing tablesThe root entry has one set of fieldsEvery other non-root entry has a different but identical set of fields

For example, the port configuration parameterHas a root entry with one field giving the number of portsHas a non-root entry for each port, each of which has the same fields

SpaceWire-PnP14

Core Services

Four core services definedDevice IdentificationNetwork ManagementLink ConfigurationRouter Configuration (routers only)

Optionally, there is also a time-code sourceThese correspond closely with the SOIS subnetwork requirements

SpaceWire-PnP15

Device Identification and Status

Identifies the deviceVendor ID and Product ID (like PCI, USB etc.)Type (node/router)Number of portsOptional static device IDOptional vendor and product strings

Provides current statusActive portsDevice ID (non-static)Return port

SpaceWire-PnP16

Example Parameter Fields

Table 5‑3: Device Information Parameter Fields

ID Name Summary

0 Vendor ID/ Product ID Contains 16-bit vendor and product IDs

1 Region/Number of Ports Indicates preferred device region gives port count

2 Static Device ID High High 32 bits of the 64-bit static device ID (if present)

3 Static Device ID Low Low 32 bits of the 64-bit static device ID (if present)

4 Version/Instance ID Version and System instance of this device type

5 Operation/String Lengths

Length of the vendor a product strings (can be zero)

6-31 Reserved Reserved for future use

SpaceWire-PnP17

Example Initiator Primitive

DIDS_READ_INFO.requestRMAP_Parameters

DIDS_READ_INFO.indicationResultVendor_IDProduct_IDPreferred_RegionRouter_NodeSupport_LevelPort_CountDevice_IDVersionInstance_ID

SpaceWire-PnP18

Example Behaviour

Simple example:Network discovery is specified as being a breadth-first searchDevices assigned network IDs if they do not already have them

SpaceWire-PnP19

Capabilities

Device can provide a list of capabilitiesCapabilities based on protocol ID

A protocol which is supportedOptionally transported over another protocolSupports nesting of transports

Each capability can define a serviceJust like the core servicesDefines target parameters, initiator primitives etc.Flexible and extensible

An example protocol would be RMAPPredefined capability services to permit use of RMAPData source service and data sink service

SpaceWire-PnP20

Data Source and Sink Capability Services

Provide a standard way to permit a device to:

Source data (such as a sensor)Sink data (such as an actuator)

Detection and configuration of data source/sink is down using SpaceWire-PnPActual data is handled by RMAPPermits the description of existing RMAP address spaces

RMAP already used for sourcing/sinking data on some spacecraft

SpaceWire-PnP21

Data Source/Sink Types

Target data source/sinkAn initiator addresses the target to read from it (source) or write to it (sink)Polled or delayed response

Initiator data source/sinkThe device initiates writes commands (source) or read commands (sink)

SpaceWire-PnP22

Target Data Sources

Initiator (such as OBC) reads from deviceDevice may be able to queue reads until data is available

If not read reply is issued immediately

When data is available, device issues replyA timeout is also available (watchdog)

SpaceWire-PnP information describes what types of read command are valid

SpaceWire-PnP23

Initiator Data Sources

Use SpaceWire-PnP to configure the write commands to be initiatedWhen data is available it is writtenA queue may be supported

Write commands sent but awaiting replySupports re-tries

SpaceWire-PnP24

Uses for the Data Source

Electronic data sheetsStandard type for (e.g. xTEDS) data sheetsDescribes where to read for the data sheetResponds immediately

Router status change notificationStandard type for router statusEither delayed response readOr initiated writeBoth completely configurable

SpaceWire-PnP25

Summarising SpaceWire-PnP

Protocol utilising packet format and semantics of RMAPDefines

Target parametersInitiator primitives (service interface)Behaviours (algorithms) where necessary

SimpleDoes not require extra feature support

Flexible and extensibleCan use capability services to extend support

SpaceWire-PnP26

SpaceWire-PnP and SOIS

SpaceWire-PnP meets all of the requirements for SOIS subnetwork plug-and-play

But only mechanismsNo policy (that was deliberate)

There are a number of small things missing/wrong

e.g. type/class do not match SOIS definitionsSupport for GAR on physical addresses

Only level 1 support is necessary for SOISLevel 2 should be ignored

SpaceWire-PnP27

Questions?