The Geostationary Operational Environmental Satellite R-Series Program (GOES-R, S, T, and U) mission is a joint program between National Oceanic & Atmospheric Administration (NOAA) and National Aeronautics & Space Administration (NASA) Goddard Space Flight Center (GSFC). SpaceWire was selected as the science data bus as well as command and telemetry for the GOES instruments. GOES-R, S, T, and U spacecraft have a mission data loss requirement for all data transfers between the instruments and spacecraft requiring error detection and correction at the packet level. The GOES-R Reliable Data Delivery Protocol (GRDDP) [1] was developed in house to provide a means of reliably delivering data among various on board sources and sinks. The GRDDP was presented to and accepted by the European Cooperation for Space Standardization (ECSS) and is part of the ECSS Protocol Identification Standard [2]. GOES-R development and integration is complete and the observatory is scheduled for launch November 2016. Now that instrument to spacecraft integration is complete, GOES-R Project reviewed lessons learned to determine how the GRDDP could be revised to improve the integration process. Based on knowledge gained during the instrument to spacecraft integration process the following is presented to help potential GRDDP users improve their system designs and implementation.
Direct Current (DC) line balanced SpaceWire is attractive for a number of reasons. Firstly, a DC line balanced interface provides the ability to isolate the physical layer with either a transformer or capacitor to achieve higher common mode voltage rejection and/or the complete galvanic isolation in the case of a transformer. Secondly, it provides the possibility to reduce the number of conductors and transceivers in the classical SpaceWire interface by half by eliminating the Strobe line. Depending on the modulator scheme - the clock data recovery frequency requirements may be only twice that of the transmit clock, or even match the transmit clock: depending on a Field Programmable Gate Array (FPGA) decoder design. In this paper, several different implementation scenarios will be discussed. Two of these scenarios are backward compatible with the existing SpaceWire hardware standards except for changes at the character level. Three other scenarios, while decreasing by half the standard SpaceWire hardware components, will require changes at both the character and signal levels and work with fixed rates. Other scenarios with variable data rates will require an additional SpaceWire interface handshake initialization sequence.
SpaceWire is valuable because it facilitates the development of spacecraft subsystems such as payload instruments, mass memory, and onboard computers. On the other hand, it takes much time and effort for developers to configure an initiator of the SpaceWire network because they have to take account of the entire SpaceWire network in a spacecraft. As the target network becomes larger, the path addressing and the packet collision-free timeslot allocation are harder for the developers to configure. Furthermore, the configuration tables of the initiator should satisfy various constraints, such as the bandwidth limitation and priority of specific packets. These constraints are different in each spacecraft. In order that the developers can design the large-scale SpaceWire network efficiently, automatic configuration table generation under the constraints is indispensable. This paper presents a constraint-based configuration table generator (CTG) that automatically provides reliable redundant path routing and collision-free timeslot allocation for required transactions in the target topology. We apply a constraint solver to the CTG to set many kinds of user-defined constraints in the network. For example, the bandwidth limitation, priority of the packets, and other various constraints can be easily inputted into the CTG. The CTG automatically generates configuration tables satisfying these constraints. Additionally, the CTG reports network topology views with bandwidth utilization ratios. This helps developers to verify whether a generated configuration is just as designed. The CTG can also notify developers that their requirements cannot be solved. In this paper, we show the feasibility and effectiveness of this tool through evaluation using a large-scale SpaceWire network case.
In many networks there is a necessity to transmit data packets flows, the intensity of which exceeds the throughput of one channel SpaceWire, GigaSpaceWire, SpaceFibre. This flow can be a packet flow from a single source to a single destination, for example, from a camera to a monitor. Also, a packet flow can include packets from different sources to different destinations that goes via two neighboring routers. An example is transmission of packets between two routers located on the boundaries of neighboring regions. The packets, belonging to one flow can have almost same length (transmission of uncompressed video), or quite different length (transmission of compressed video, transmission of packets with different content between two regions). The adaptive routing can be used for transmission of such packet flows. This mechanism includes in SpaceWire standard. A set of alternative output ports (a group of ports) can be determined in routing table for the logical (or regional address). Any output port from this group (if connection for this port is established and port is not occupied by other packet) may be used for transmission of packet with this address. Thus, the summary throughput of all ports belongs to the group can be used for transmission of data packets with this address. However, the possibility of parallel transmission of packets from this flow to different output ports belongs to the group is required for effective utilization of this summary throughput. If the length of packets may be different or if the quantity of input ports for considered flows is not equal to the quantity of output ports in the group, the router should include special mechanisms to ensure efficient parallel transmission of packets to all ports belongs to the group. Adaptive routing for intensive data flows transmission can be implemented not only in SpaceWire/GigaSpaceWire networks, but also in SpaceFibre networks. We consider the specific of its implementation taking into account the features of data link layer (virtual channels with a fairly large buffers, retry mechanism) In this paper we discuss possible implementations of these mechanisms for SpaceWire, GigaSpaceWire and SpaceFibre, estimate achievable bandwidth utilization of port's group, the overhead of the implementation of these mechanisms for packets flows with different characteristics. A side effect of adaptive routing is a possible mismatch of the order in which packets are sent to the network form the source and the order of their receipt by destination. We evaluate the packet's window size that required in the destination node for recovery order of packets and the associated delays. The ports of router belonging to the same group may be connected to one or several different routers (according to the standard). In the first case all packets from the flow will be transmitted via one chain of routers (via one path via network). In the second case, they will be transmitted through the network in different ways. The reordering of packets is possible in both cases. However, in the first case, the mechanisms, that prevent the packets reordering, can be implement in routers. But its implementation can lead to decrease of throughput utilization, to additional hardware costs and to increase of packet's transmission time. In the paper we estimate these overheads for data packets flows with different parameters.
Cobham Gaisler presents the SpaceFibre Port IP Core implementation GRSPFI. A fully validated VHDL implementation is readily available.
For those responsible for the design and implementation of a SpaceFibre network it is essential to be able to capture and view the traffic on a SpaceFibre link in order to help validate the link is operating as expected and debug the link should any unexpected behaviour be observed. STAR-Dundee Ltd have developed hardware independent SpaceFibre Link Analyser software for this purpose. This paper describes how the software views, combined with the traffic capture capabilities of the STAR Fire unit, can be used to perform SpaceFibre link analysis.
SOI-SOC3 is a radiation hardened space-grade SOC implementing reliable SpaceWire protocol such as SpaceWire-R and SpaceWire-D. SOI-SOC3 realizes high performance in SpaceWire link speed, reliable communication technology such as data division, retransmission control, and real-time communication using time synchronization and scheduling system. These technologies are based on SOI-SOC2 technology that realized high throughput, radiation hardened, and low power consumption using commercial SOI process technology. Since such reliable SpaceWire communications are realized by various middleware, users can use reliable SpaceWire protocols just by calling specific APIs. Due to its reliability, SOI-SOC3 is applicable to not only space-grade products but also wide range of fields requiring high reliability and environment resistance such as power plants and medical devices. We have been planning to port cFE/cFS (Core Flight Executive/Core Flight System) to SOI-SOC3. Before manufacturing ASIC, we have evaluated basic function of SpaceWire on SOI-SOC3 implemented on FPGA. In this paper we describe the evaluation results of SpaceWire function of SOI-SOC3 evaluation board and its software including middleware.
We developed a rewritable field programmable gate array (FPGA) using NanoBridge® that exploits atom switch technology. NanoBridge® is newly developed copper wiring technology with dynamic connection capability. Programmable circuitry with SpaceWire interface is realized without configuration memory cells for storing circuit connection information. It prevents single event effect caused by radiation and provides remarkably low power consumption. The first demonstration of the NanoBridge® FPGA on orbit by JAXA's program is planned in 2018.
The GR740 is a quad-core space-grade processor that includes a SpaceWire router with eight external ports. The validation results are presented to show effects of the integration of a SpaceWire router in a microprocessor system and the validation methodology is described to show one way of characterize timing performances SpaceWire links during production tests.
Cobham Gaisler presents a network layer implementation for easy integration of SpaceFibre and Serial RapidIO into modern System-on-Chips.
In 2006, we developed SpaceWire platform named SpaceCube cooperation with JAXA and NEC. After the success of SpaceCube project, we developed number of SpaceWire products. Some examples of this innovation include several kinds of the SpaceWire interface boards, SpaceWire router and SpaceWire-to-GigabitEtherR2. These developments included the support and cooperation of JAXA, OSAKA University, Japan Space Systems and NEC. However, there are the big step into the Space market for the small high tech companies. In this paper we describe Renewed SpaceWire Test Center in Japan.
SOISOC3 is our new space-grade system-on-chip processor which is currently being developed by MHI in partnership with JAXA. The chip is implemented on a 200 nm radiation hardened process based on the commercial SOI (Silicon On Insulator), so that can apply to the Space missions. This is the next generation system-on-chip processor upgraded from the currentSOISOC2 chip already used for ASTRO-H, ERG satellites, etc. SOISOC3 has a high-reliability SpaceWire engine, which MHI has developed, supporting for incoming SpaceWire standards for deterministic data delivery (SpaceWire-D), reliable data transfer service (SpaceWire-R), as well as high performance Remote Memory Access Protocol (RMAP) with Direct Memory Access (DMA) engine through a SpaceWire router. The SpaceWire engine is capable of acting as an RMAP initiator, target, or as a general purpose packet transmitter and receiver. Our developed SpaceWire-D and SpaceWire-R engine is mainly performed on hardware, and can achieve high accuracy scheduling and high performance, with less CPU load. We'll introduce the outline and current status of our development with an prototype evaluation board exhibited at MHI booth.
This paper presents the architecture, functionality, and performance of the SpW Interface Node IP which constitutes a configurable IP Core from which non-SpW experts can tailor a customized SpW interface for integration into their developments. The IP core offers numerous configurability options and is also expandable to include additional blocks as the SpW protocol family evolves.
The common DPU platform for ESA JUICE mission instruments is a hardware and software platform developed by Cobham Gaisler for the scientific instrument payloads of the European Space Agency Jupiter Icy Moons spacecraft. The hardware is based around the GR712RC dual-core LEON3-FT processor with GRSPW2 SpaceWire interfaces. To accompany the JUICE instrument hardware, a flight quality SpaceWire software package has been developed, compliant with ESA ECSS standards for Space Software engineering. The software includes SpaceWire device drivers and protocol support for the SpaceWire CCSDS Packet Transfer Protocol, the Packet Utilization Standard and the SpaceWire Time Distribution protocol.
This paper presents hardware and software solution for simulation of a group of cameras used by the PLATO satellite. The simulator can be configured either to work with the scientific processing unit or as the complementary loop attitude control processing unit. Configuration and monitoring can be performed remotely, which caters to cooperatively work and guarantees traceability for quality purposes. Because the system operates with database and configurable architecture, its performance can be modified to operate as standard generation element (CCSDS, e.g.) traveling via SpaceWire. Eight SpaceWire links for feeding processing system compose the simulator. The links may route data in real time rate configurable to 200Mbits/s, with representative images, using the RMAP protocol, it can run continuously up to two days of satellite operation. The information database is stored in two solid-state drives with 500 GBytes capacity each one. Access for configuration and monitoring are made using TCP-IP protocol. Each simulator has a unique ID and is automatically recognized when connected to the Ethernet network. The software layer has graphical interface compatible but offers component for integration with other EGSE systems. The system has own housekeeping, which enables diagnosis operation and viewing by the operator. The system will be used by European groups: LESIA (France), DLR (Germany) and IWF (Austria).
This paper presents the main outcomes of the ESA funded project entitled: “SPACEMAN - A SpaceWire Network Management Tool” that was jointly carried out by ITTI Sp. z o.o. and TELETEL SA., and dealt with SpaceWire Network Discovery and Configuration Protocol (SpW-NDCP). We give a brief overview of the SpW-NDCP, present the main features of the SPACEMAN tool for discovering and configuring SpaceWire networks, and introduce a novel XML representation of SpaceWire networks, implemented in the tool.
The Geostationary Operational Environmental Satellite R-Series Program (GOES-R) mission is a joint program between National Oceanic & Atmospheric Administration (NOAA) and National Aeronautics & Space Administration (NASA) Goddard Space Flight Center (GSFC). GOES-R project selected SpaceWire as the best solution to satisfy the desire for simple and flexible instrument to spacecraft command and telemetry communications. GOES-R development and integration is complete and the observatory is scheduled for launch October 2016.The spacecraft design was required to support redundant SpaceWire links for each instrument side, as well as to route the fewest number of connections through a Slip Ring Assembly necessary to support Solar pointing instruments. The final design utilized two different router designs.The SpaceWire standard alone does not ensure the most practical or reliable network. On GOES-R a few key hardware capabilities were identified that merit serious consideration for future designs. Primarily these capabilities address persistent port stalls and the prevention of receive buffer overflows. Workarounds were necessary to overcome shortcomings that could be avoided in future designs if they utilize the capabilities, discussed in this paper, above and beyond the requirements of the SpaceWire standard.
This paper will describe the various modules and daughter cards under development. Interconnects between these modules will be highlighted with special emphasis on SpaceWire ports, routers and backplane routings. Performance of the modules and their interconnects will be summarized. SpaceVPX Backplanes, cabling and test equipment for bringing up and testing these modules will be described highlighting leveraging of COTS elements 1 .
This paper will describe high performance interface building blocks, compare their networking features and show how they may be used in small and large systems especially as they apply to SpaceVPX modules. Emphasis will be placed on their SpaceWire and other networking capabilities.
This paper will briefly review the SpaceVPX standard with special emphasis on the interconnect planes between the modules. Comparisons to other form factor standards will be included. SpaceWire and its usage as the control plane in a SpaceVPX system or as a medium speed data plane will be discussed. A summary and status of any updates or future efforts involving the SpaceVPX standard will be included 1 .
