The following papers have been presented by 4Links, to various conferences and exhibitions and though some of them were written several years ago the information within these papers are still very much relevant today. You can find information about Spacewire as defined by ESA here>>
Presented to the International SpaceWire Symposium 2003
SpaceWire is a new standard being published in January this year (2003). The technologies in SpaceWire can, however, be traced back to the era of the minicomputer in the 1960s and ‘70s, and this paper traces the evolution since then. It can be seen that, throughout this evolution, the principles have been maintained, such as symmetry, asynchronous point to point links, scalability and modularity.
Presented in the Standardization Session
The IEEE 1355 standard (1) was broader than SpaceWire standard (2) in terms of variety,and transmission speeds and distances covered and encoding and physical layers to achieve these speeds and distances. 1355 was less deep then SpaceWire, in that it did not include the network layer. What is really important in both 1355 and SpaceWire is the common character alphabet and the separation of the link layer (initialization and flow-control) from the ‘exchange’ and packet layers.
Presented at the 20th Annual AIAA/USU Conference on Small Satellites
Early versions of it (SpaceWire) are flying on several missions, and it is planned for use on many missions worldwide. As a simple interface that can be used for a wide variety of different purposes, SpaceWire appears to offer an enabling technology for the “Building Block Architecture” of the Vision for Space Exploration. While recently standardized, SpaceWire has evolved over many years, following a few key principles and concepts that are the foundations of its wide application and use.
SpaceWire is a data transmission standard that defines communication links and networks. Fault-tolerant, redundant systems of high performance can be built. Link speeds currently available in products exceed 400Mb/s and system speeds are a large multiple of this. N + 1 or N = M redundancy can be provided, as can point-to-point bandwidth multiplication by grouping links.
SpaceWire is characterized by transmission on two signal lines that encode both the data and clock. Clock recovery and design of the receiver appears to be simple but presents two distinct implementation issues, both presenting serious challenges for FPGA implementation (and non-trivial challenges for ASIC implementation).
Presented in a Test and Verification Session
This paper presents a variety of measurement techniques that give information about how a device or system behaves with respect to time. We show how these techniques can be used to measure different parameters of SpaceWire, such as the receive link speed, the times of arrival of Time Codes, the duration and latencies of packets, and the operating margins of the SpaceWire receiver.
Time codes are globally transmitted - broadcast, from a single source to all nodes in the network. SpaceWire networks are permitted to have multiple connections in order to provide redundancy and fault tolerance. These alternative paths form loops that can lead to livelock with a simple broadcast mechanism, SpaceWire routing switches may receive a time code already sent and must only selectively transmit new values. A time code, therefore, contains a sequence number in support of this requirement.
We consider the opportunities for combining the best of SpaceWire, such as modularity, high speed, low latency, fault-tolerance, and ease of implementation, with the vast experience of protocol design that has been implemented on Ethernet. We consider how existing Ethernet-based designs can be implemented on SpaceWire networks.
Issues that will be addressed here, to allow Ethernet to work over SpaceWire, include: converting Ethernet addressing into SpaceWire routing; behavior in the event of faults (which may create a need to re-route); handling broadcast; and considering whether the network topology is static (as in conventional large spacecraft) or dynamic with plug and play (as suggested for responsive space on small satellites, or for the Shuttle/CEV).
We consider the precise source of emissions and show that simple techniques can be used to mitigate these undesired effects. Measurements of SpaceWire signals with and without mitigation allow the achievable reduction to be quantified.
In the early days of SpaceWire, 4Links built a demonstration SpaceWire network that could provide a level of fault-tolerance, through redundancy, unmatched by any other technology, yet with a performance some two orders of magnitude greater than previously offered. This was done with a Plug-and-Play system that could be assembled in an arbitrary fashion and continued to work by reconfiguring itself as faults were introduced and spare units brought on line.
In contrast to other ‘bus’ standards, SpaceWire offers unprecedented flexibility in the choice of network topology. Choice can be made to optimize parameters such as performance, harness mass, cost, or fault-tolerance, or to provide an optimum balance of these, for a particular mission. This paper discusses some simple topologies and how they affect these parameters.
This paper quantifies typical latency requirements and describes a simple technique that uses virtualization and priorities with dynamic, on-demand segmentation, to provide deterministic, low latency delivery of packets whilst allowing high utilization of the network.
Virtual Networks – two or more independent networks sharing common hardware – offer Real-Time performance whilst maximizing use of existing SpaceWire software and interfaces. The only component needing to be changed is the routing switch. All existing nodes and software can be re-used without change.