Download Presentation - International Spacewire Conference 2008

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Computer network wikipedia , lookup

Distributed operating system wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

CAN bus wikipedia , lookup

Low Pin Count wikipedia , lookup

Zigbee wikipedia , lookup

Network tap wikipedia , lookup

RS-232 wikipedia , lookup

Universal Plug and Play wikipedia , lookup

Airborne Networking wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Zero-configuration networking wikipedia , lookup

IEEE 1355 wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Transcript
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