Presentation - International Spacewire Conference 2008
Download
Report
Transcript Presentation - International Spacewire Conference 2008
SpaceWire 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 SpaceWire-PnP services
Service descriptions
Legacy support and implementation
Relationship with SpaceWire-RT
Conclusions
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
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
Perspective
PnP views the network like the SpaceWire
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 PnP transactions
In a running system, every device can have
one owner node which is responsible for that
device
5
SpaceWire Protocol Stack
User
Applications
User Application
SpW PnP
PTP
RMAP
PnP
User memory
control
SpW-RT
QoS
SpaceWire
SpW
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
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
SpaceWire-PnP feature support
Active ports
Device level parameters
– Overall device errors/status
– Protocol ID error reporting
– PnP error reporting
Standardised discovery algorithm
8
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
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
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 PnP
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
=at60
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 PnP
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
SpaceWire-PnP and RMAP
User
Applications
User Application
SpW PnP
PTP
RMAP
PnP
User memory
control
SpW-RT
QoS
SpaceWire
SpW
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
18
– e.g. On the RTC using a software implementation
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
–
–
–
–
–
19
Service status
Open channel
Close channel
Channel status
Channel open requests
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