SPACE PACEWIRE STANDARD AND RELATED PRODUCTS FOR THE PAYLOAD DATA HANDLING SYSTEM OF BEPI

Transcription

1 f D document title/ titre du document D O C U M E N T SPACE PACEWIRE STANDARD AND RELATED PRODUCTS FOR THE PAYLOAD DATA HANDLING SYSTEM OF BEPI EPICOLOMBO prepared by/préparé par TOS-EDP reference/réference SpW_BC issue/édition 1 revision/révision D date of issue/date d édition status/état Document type/type de document Technical note Distribution/distribution ESTEC Keplerlaan AZ Noordwijk - The Netherlands Tel. (31) Fax (31) SpW_BC_Iss1_Rev_D.doc

2 page 2 of 21 APPROVAL Title titre SpaceWire standard and related products for the payload processing system of BepiColombo issue issue 1 revision revision D author auteur W.Gasti P.Armbruster date 3rd of february 2004 approved by approuvé by date date CHANGE LOG reason for change /raison du changement issue/issue revision/rev date/date ision 1 D 3 February 2004 CHANGE RECORD Issue: 1 Revision D reason for change/raison du changement page(s)/page(s) paragraph(s)/paragraph(s)

3 page 3 of 21 Table Of Contents Table of Acronyms Applicable and Reference Documents Applicable documents Reference Documents Introduction Scope Layout of the document SpaceWire standard and technology Introduction Physical level Signal level Character level & Exchange level Packet level & Network level SpaceWire Link Interface SpaceWire Link SpaceWire Nodes SpaceWire Routing Switches Component based on SpaceWire Scalable Multi-channel Communication Sub-System (SMCS) and IEEE 1355 Std SMCS and SpaceWire Router Remote Terminal interface BepiColombo Command & Payload Data Handling BepiColombo command and data handling baseline Instrument I/F definition for a the SpaceWire Network/Router Benefits of SpW I/F use at instrument level Introduction At test level SpaceWire PCI Card SpaceWire USB Router box SpaceWire Link Monitor SpaceWire Conformance Tester Ethernet-to-SpaceWire bridge At AIV level... 21

4 page 4 of 21 Table of Acronyms ADC ASIC BB CoDec DAC DPU DSP EGSE EMC ESA FIFO FM FPGA HW I/O ISO JTAG LI LVDS Mbps OHMA OSI LI PC PCB PDHS RAM ROM RTI SLI SMCS SnP SoC SpW Std SW UART VHDL VHSIC Analog Digital Converter Application Specific Integrated Circuit Breadboard Coder/Decoder Digital Analog Converter Data Processing Unit Digital Signal Processor Electrical Ground Support Equipment Electro-Magnetic Compatibility European Space Agency First In First Out Flight Model Field Programmable Gate Array Hardware Input / Output. International Standard Organisation Joint Test Access Group Link Interface Low Voltage Differential Signalling Mega bits per second. Open Heterogeneous Multi-Processor Architecture Open Systems Interconnect Link Interface Personal Computer Printed Circuit Board Payload Data Handling System Random Access Memory Read Only Memory Remote Terminal Interface SpaceWire Link Interface Scalable Multi-channel Communication Sub-System SpaceWire Networking Protocol System on Chip SpaceWire Standard SoftWare Universal Asynchronous Receiver Transceiver VHSIC Hardware Description Language Very High Speed Integrated Circuit

5 page 5 of Applicable and Reference Documents 1.1 Applicable documents [AD1]: SpaceWire Standard: ECSS-E50-12A [AD2]: Cable, SpaceWire, round, quad using symmetric cables, flexible, -200 o C to o C. ECSS detail specification No 3902/003 issue 1, January [AD3]: Connectors, Electrical, Rectangular, Microminiature, Solder contacts, with EMI backshell based on type MDM ECSS detail specification No 3401/071, issue1, draft C, June [AD4]: ANSI/TIA/EIA Telecommunications Industry Association, Reference Documents [RD1] Specification of the Open Heterogeneous Multiprocessor Architecture (OHMA), DSPM-DAS-1402-E, dated on April 1998 [RD2] SpaceWire coder/decoder core cell [RD3] SMCS Data Sheets,

6 2. Introduction 2.1 Scope SpaceWire standard page 6 of 21 At the turn of this century, science missions that have demonstrated the feasibility of many space applications, enter in a new era. Indeed, the amount of data produced by instruments exceeds the downlink capability, leading to the unavoidable need of implementing a compression mechanism on-board. On the same line, for observatory type of science missions, on board autonomy can bring significant advantages. With respect to the point outlined here above, on-board Payload Data Processing Systems can provide a suitable solution. Furthermore, this new sub-system will offer the necessary autonomy or intelligence in relation to the spacecraft that is also facing new challenge in terms of AOCS, FDIR and autonomy as well. Nodes in a system need to be interconnected. Taking into account the fact that back plane busses can be bottlenecks, networks of point-to-point links offer an attractive alternative. This trend is fully endorsed by ground computing infrastructures relying more and more on switch fabrics for data routing. Taking into account that space applications have specific requirements, no commercially available networking infrastructure could be directly used for on-board applications, a network based on a point-to-point links, has been standardized and adapted to space use. This new space standard is called SpaceWire links, nodes, routers and networks [AD1]. The on-board network approach promoted by the Agency is relying deeply on this SpaceWire standard. The scope of this document is to provide guidelines for the implementation of this SpaceWire on-board network. Moreover, Payload Data Processing Systems and in particular their implementation based on SpaceWire networks are also presented. 2.2 Layout of the document This document is based on 4 main sections, which are:! The first one, provided in section 3, gives information on how SpaceWire levels have been implanted successfully! The second one, provided in section 4, presents a set of devices conformant with the SpaceWire standard protocol and that are fully supported by the European Agency since developed through internal activities.! The third one, provided in section5, specifies a SpaceWire interface at instrument level. Possible implementations are presented as well.! Finally, the last but not least section 6 is devoted to the presentation of equipments that are of great importance in terms of tools for the test, assembly and verification phases when using a SpaceWire I/F. 3. SpaceWire standard and technology 3.1 Introduction The ISO (International Standards Organization) has created a layered model, called the OSI (Open Systems Interconnect) model, to define and describe layers in a network operating system. The purpose of the layers is to provide clearly defined functions that can improve inter-network connectivity between "computing nodes". Each layer has a standardised input and a standardised output. Understanding the function of each layer is instrumental in understanding data communication within the network. For the on-board payload network, point-to-point links based on the SpaceWire standard, are used to interface modules (processors, mass memories, etc) and units (payload system, platform system) either directly or via SpaceWire packet routers. The SpaceWire On-Board network correspondence with OSI one is presented in figure 3.1. The SpaceWire level naming is taking legacy from the IEEE Std. The mapping of these levels can also be derived from the figure 3.1.

7 page 7 of 21 On-Board Network Layers Application On-Board Network Layers Application SpaceWire Presentation Session Transport Transport Under Develop ment Network Network Network Data Link Physical Data Link Physical Packet Exchange Character SpaceWire Levels Naming legacy Signal Physical Figure 3.1. The SpaceWire standard [AD1] is based on six levels that are physical, signal, character, exchange, packet and network levels. The following sub-sections present each level and provide normative and informative references for their implementation. 3.2 Physical level This level defines connectors, cables, cable assemblies and printed circuit board tracks. The ECSS 3902/003 and the ECSS 3401/071 (issue1) have been considered for SpaceWire cables and connectors implementation. 9-way micro-miniature D-type connectors have been selected for SpaceWire connectors. The 2 specification documents are considered as applicable documents [AD2] and [AD3] for SpaceWire links implementation.! Potential supplier(*) for commercial twisted pair cables with 8 wires is Glenair ( Potential suppliers (*) can be Gore ( that provide cable-assemblies. (*): This list is not exhaustive and it is provided just as informative reference 3.3 Signal level This level defines signal encoding, voltage levels, noise margins, and data signalling rates. ANSI/TIA/EIA-644 specifying the electrical characteristics of Low Voltage Differential Signaling (LVDS) has been considered for the SpaceWire signal specifications. This specification is also considered as an applicable document [AD4] for the receivers and transceivers. Implementation. Potential suppliers (*) for transceivers and receivers based on LVDS technology can be either:

8 page 8 of 21! Aeroflex ( offers a set of quad drivers and quad receivers for either 5V power supply or 3.3V power supply: with radiation hardness levels ranging from 100K rads (Si) to 1 Meg rads (Si)! ATMEL ( LVDS cells in 0.5 micron and in 0.35 µm technology are under evaluation.! National Semiconductors ( Offers DS90C031 (driver) and DS90C032 (receiver)! Texas Instruments (TI) ( SN75LVDS81 (driver) and SN75LVDS82 (receiver) SN65LVDS31 (driver) and SN65LVDS32 (receiver (*): This list is not exhaustive and it is provided just as informative reference 3.4 Character level & Exchange level The character level defines the data and control characters used to manage the flow of data across a link. The exchange level defines the protocol for link initialisation, flow control, link error detection and link error recovery. These two levels are implemented in a Coder-Decoder (see figure 3.4) which VHDL core has been developed in the frame of an ESA activity. This VHDL core is made freely available for ESA missions [RD2]. SpaceWire Coder/Decoder Transmit Data Rate Data Strobe Out Transmitter Transmit Control/Status Receiver Control/Status Initialisation State Machine Transmit Data/Timecode Link Control Link Status Data Strobe In Receiver Received Data/Timecode Figure 3.4 The ultimate objective of the CoDec VHDL-core is:! To facilitate compatibility and re-use between SpaceWire nodes (e.g. chips, boards, etc) built by different manufacturers! To support the SpaceWire Standard document with the Hardware design in VHDL language! To facilitate portability into new-technologies (e.g micron or less) and interoperability with other on-board buses! To enlarge the community of SpaceWire users by facilitating new implementations on FPGAs / ASICs / SoCs In that respect, a SpaceWire CoDec has to be seen as a very simple 5000-gates design that if integrated in a chip offers two capabilities:! A bi-directional 8-bit parallel access from the host! A bi-directional asynchronous "serial" access via cable or via PCB tracks

9 3.5 Packet level & Network level SpaceWire standard page 9 of 21 The packet level defines how data for transmission over a SpaceWire link are split into packets. The network level defines the structure of a SpaceWire network and the way in which packets are transferred from a source node to a destination node across a network. It also defines how link errors and network level errors are handled. The Digital Interface Circuit Evaluation (DICE) study was initiated by ESTEC:! To assess the state of Open Interface Data Link for the SpaceWire Std components,! To identify what elements at node level of the communication system were missing or inadequate! To go on to develop those elements. To this end, building blocks for a node have been defined at functional level in order to assess up to which level an element is compatible with the SpaceWire Std. The foundation building block is the SpaceWire CoDec handling the character and the exchange levels. The upper building blocks are organized around this basic one and they are 4 of them:! SpaceWire Link Interface! SpaceWire Link! SpaceWire Node! SpaceWire Switching Matrix These 4 upper building blocks are presented in the following sub-sections SpaceWire Link Interface The SpaceWire Link Interface is responsible for making a connection with the SpaceWire interface at the other end of the link and managing the flow of data across the link. A block diagram of the SpaceWire Link Interface (SLI) is given in figure The white section corresponds to the CoDec, which can be used as an IP. Typically the receiver and transmitter FIFO are application/process dependent. Therefore, the CoDec has been designed to be easily interfaced with external buffers. The pair of FIFO memories provides the interface to the host electronic system. SpaceWire link Interface TRANSMITTER TRANSMITTER FIFO SpaceWire Link STATE MACHINE Interface to Host RECEIVER CoDec RECEIVER FIFO SpaceWire Link Figure A SpaceWire Link comprises a pair of SLI connected via a SpaceWire cable assembly or set of PCB tracks.

10 page 10 of 21 A Link Interface (LI) (see figure 3.5.2) takes packets of information from a host system or router at one end of the link and transmits it in a serial form across the link. The LI at the other end of the link receives the serial data and passes it on to the host system or router at that end as a complete packet of information. Since SpaceWire is full duplex, packets may be transmitted across the link in both directions simultaneously. SLI SpW Assembly cable SLI Figure SpaceWire Nodes A SpaceWire Node comprises one or more SLI together with an interface to some form of host system (e.g. processor, sensor) as illustrated by figure SpaceWire Nodes are the sources and destinations of packets in a SpaceWire network. The packet format is: <DESTINATION ADDRESS><CARGO><END_OF_PACKET> SpaceWire Node SpaceWire Network SLI SLI Host System Interface. Processor. Memory. Sensor. EGSE.etc Figure SpaceWire Routing Switches A SpaceWire router is a packet switch. It connects several SpaceWire interfaces to a switching matrix so that a packet arriving on one SpaceWire link can be sent out of one of the other inks attached to the router. The SpaceWire Router Switch block diagram is given in figure In a routing switch each link interface may be considered as comprising an input port (the link interface receiver) and an output port (the link interface transmitter). A SpaceWire routing switch transfers packets from the input port of the switch where the packet arrives, to a particular output port determined by the packet destination address. There is 2 ways of addressing SpaceWire packets over the network: Logical addressing: specify the route through a network indirectly via routing tables held in the routing switches.

11 page 11 of 21 Path addressing: specify the route through a network directly Routing switch addresses are given in the following table. Address Range Function 0 Internal Configuration Port 1-31 (01-1F hex) Physical Output Ports (20-FF hex) Logical Addresses, which are mapped on to the physical output ports. SpaceWire Routing Switch SLI SLI Routing matrix SLI SLI Figure Component based on SpaceWire 4.1 Scalable Multi-channel Communication Sub-System (SMCS) and IEEE 1355 Std Two type of SMCS have been developed and are presently available:! The first one called the SMCS332 is based on 3 SLI ensuring the management of 8, 16 and 32 bits words from the host into a serial SpaceWire link in both directions. The 3 channels share the same data protocol management entities and the host parallel bus. This chip needs the association of a host to handle the data packetisation (see figure 4.1.1). The radiation tolerant version of the SMCS332 is designed on Atmel MG1140E matrix and packaged into QFPL196. The Atmel catalogue reference for this chip is T7906E.! The second one called SMCSLite or SMCS116 is based on one single SLI associated to a µcontroller ensuring the data packetisation (see figure 4.1.2). The radiation tolerant version of the SMCSlite is designed on Atmel MG1090E sea of gates matrix and packaged into MQFPF100 technology. The Atmel catalogue reference for this chip is TSS901E. More information about these two components can be found in their related datasheets provided by Atmel [RD3]. One must be aware that these devices exhibits anomalies as documented by ASTRIM GmbH. These two components have not been developed by ESA and they use early versions of the Data- Strobe encoding and initialisation state machine part of the IEEE 1355 Standard. Link initialisation problems due to the IEEE Standard have been identified, work-arounds have been described in their respective User Manuals.

12 page 12 of 21 Figure SMCS3323 Block Diagram Figure SMCS116 Block Diagram

13 page 13 of SMCS and SpaceWire The initial SMCSLite and the SMCS332 components are largely used today in many missions. Their functional blocks are fully in line with an on-board network based on point-to-point links connections but they still suffer from the IEEE1355 legacy. Therefore, ESA has decided to upgrade them on the basis of the SpaceWire Codec VHDL core. Target technology for these updated component will be 0.5 µ and their naming will be respectively SMCSLite_SpW and SMCS332_SpW in order to avoid confusion with the previous ones. The new performances that can be expected for the SMCS332_SpW and the SMCS116_SpW are respectively provided by table and table SMCS332_SpW ASIC Radiation Tolerance Performance Power Package Schedule Implementation in Atmel MG2RT gate array Max gate count 480 kgates (max technology) 0. 5 µm CMOS process Up to 100 krad SEU free cells to 100 MeV Used for all memory cells Latch- up immunity to 70 Mev SpaceWire interface baud- rate 200 Mbits/ s max 190mA at 5.5V at maximum data rate 5 V and 3. 3 V supply voltage 196 pin ceramic Quad Flat Pack 25 mil pin spacing Availability of prototypes: Q (planned) Availability of flight parts: Q (planned) 4.3 Router Table SMCS116_SpW Implementation in Atmel MG2RT gate array ASIC Max gate count 270 kgates (max technology) 0. 5 µm CMOS process Radiation Tolerance Up to 300 krad SEU free cells to 100 MeV Used for all memory cells Latch- up immunity to 70 Mev Performance SpaceWire interface baud- rate 200 Mbits/ s Power max 80mA at 5.5V at maximum data rate 5 V and 3. 3 V supply voltage Package 100 pins ceramic Quad Flat Pack 25 Schedule Availability of prototypes: Q (planned) Availability of flight parts: Q (planned) Table A SpaceWire routing switch called Router_SpW is able to connect together many nodes, providing a means of routing packets between the nodes connected to it. It comprises a number of SpaceWire link interfaces and a routing matrix. The routing matrix enables packets arriving at one link interface to be transferred to and sent out of another link interface on the routing switch.

14 page 14 of 21 The routing switch is based on 8 SLI and a routing switch as presented in figure 4.3. This component is also handling time codes. It has the following features:! Eight SpaceWire input/output ports.! Two external parallel input/output ports each comprising an input FIFO and an output FIFO.! A non-blocking crossbar switch connecting any input port to any output port.! An internal configuration port accessible via the crossbar switch from the external parallel input/output port or the SpaceWire input/output ports.! A routing table accessible via the configuration port which holds the logical address to output port mapping.! Control logic to control the operation of the switch, performing arbitration and group adaptive routing.! Control registers than can be written and read by the configuration port and which hold control information e.g. link operating speed.! An external time-code interface comprising tick_in, tick_out and current tick count value! Internal status/error registers accessible via the configuration port! External status/error signals The performances that can be expected for the router are provided by table SpaceWire Interfaces Sp acewire Port 1 Sp acewire Port 2 Sp acewire Port 3 Sp acewire Port 4 Sp acewire Port 5 Sp acewire Port 6 Sp acewire Port 7 Sp acewire Port 8 Control Logic Non-blocking Crossbar Switch Routing Table Status/Error Registers Control Registers Configur ation Port Status Outputs External Input/Output Input FIFO Output FIFO External Port External Input/Output Input FIFO Output FIFO External Port Time-Code Interface Time-Code Inputs / Outputs Figure 4.3 Router ASIC Radiation Tolerance Implementation in Atmel MH1RT gate array Max gate count 519 kgates (typical) µm CMOS process Up to 300 krad SEU free cells to 100 MeV Used for all memory cells Latch- up immunity to 100 Mev

15 page 15 of 21 Performance Power Package Schedule SpaceWire interface baud- rate 200 Mbits/ s LVDS drivers/receivers integrated on chip 4W with all links at maximum rate 3. 3 V supply voltage 196 pins ceramic Quad Flat Pack 25 mil pin spacing Availability of prototypes: Q1, 2005 Availability of flight parts: Q3, 2005 Table Remote Terminal interface The Remote Terminal Interface (RTI) ASIC is developed for the connection of nodes (with or without local intelligence). It shall b:! Configurable by link (remote control)! Smart enough to work autonomously. It shall implement one Bridge from SpaceWire-to-CAN The block diagram of the RTI is given by figure 4.4. The RTI will have the following features:! Unit configurable and controlled by link (Remote Control)! SpaceWire I/F as high speed link(s)! FIFO buffering interface! RAM buffering interface! CAN I/F Controller (CANC)! RTI Manager embedded mcontroller (RTM)! GP-I/O configurable channels! Digital commands! Pulse commands! Digital status! ADC Interface for analogue acquisitions! DAC interface! Host bus I/F! Embedded UARTs! Embedded user s Timers! JTAG port for test purposes Today, since the development of this chip is not yet finished, the following trade-offs still remain:! Number of SpaceWire links (if more than one, power off mode has to be implemented for unused links)! Choice of CAN controller IP (HurriCANe, TBC)! Choice of embedded µcontroller (RTM)! Possibility to have embedded Data Memory RAM! Possibility to have embedded Program Memory ROM, to improve performance and integration (in this case, only external PROM needed, with download at power-on and in case of SEU). The performances that can be expected for the RTI are provided by table

16 page 16 of 21 Serial links Discrete commands & Status TIMER 1 TIMER 2 UART 1 UART 2 JT AG GP I/O RTM RTI Manager (µc) DM (Memory) PM (Memory) DAC I/F ADC I/F ADC DAC SpaceWire Interface FIFO/RAM I/F HOST I/F CANC SpaceWire Links FIFO/ RAM PROM µp CAN Bus Figure 4.4 ASIC Implementation in Atmel Rad Hard 0.18 µm CMOS Max gate count 7Mgates Standard-cell ATC 18RHA libraries Radiation Tolerance Functional TID up to 200 krad SEU free cells to > 100 MeV Used for all memory cells Latch- up immunity > 100 Mev Performance SpaceWire interface baud- rate 200 Mbits/ s CAN Bus up to 1 Mbit/s UARTs at Kbit/s 8 bit embedded µcontroller Power mw (TBC) 3. 3 V (2.5 V TBC) supply voltage Package MQFP, MCGA (TBC) Schedule Availability of prototypes: Q Availability of flight parts: Q (TBC) Table

17 page 17 of BepiColombo Command & Payload Data Handling 5.1 BepiColombo command and data handling baseline The MPO P/L consists of 11 instruments that are going to be commanded and controlled from the HICDS System. It is then necessary to devise a PDHS answering two basic constraints such as: 1. The most constrained resource for the mission is the mass of the MPO. Thus a mass minimised I/F solution is required. 2. Since some instruments (e.g. cameras) require a high data rate interface provided nowadays only by SpaceWire. Therefore, a SpaceWire link Interface is required at each instrument level. This solution allows a single (but redundant) SpaceWire System to all instruments with one redundant Node per Instrument for:! TC reception from and HK-TM transmission to the HICDS via a Router! Science data transmission to Mass Memory module via Router! Science data to be compressed to compression module via router! Broadcast Time reception at Instrument side via Router, initiated from HICDS SpaceWire links via network/packet Router are used for the command/control and the data acquisition of all instruments. Furthermore the specific implementation and therefore sharing of functionalities (i.e. data compression and data storage capability) between different instruments is a pre-requisite. This Network/Packet router is based on 2 modules (see figure 5.1.):! The first one, that must provide all the interfaces to the instruments, is located close to the instruments. Those instruments providing only a low data rate can also communicate via the Spacewire link with the advantage of having one common interface for all instruments.! The second one that communicates with the HICDS modules is located in the HICDS unit. Inst 1 Inst 2 Inst 3 Inst 4 SpW I/F SpW I/F SpW I/F SpW I/F Network/ Router module 1 Panel 1 Panel 2 Panel 3 Network/ Router module 2 HICDS Figure 5.1.

18 5.2 Instrument I/F definition SpaceWire standard page 18 of 21 At instrument level, a SpaceWire Link Interface building block must be implemented to interface with the network/packet router. The implementation must be compliant up to the packet & network levels of SpaceWire Std. The electrical specifications of a SpaceWire Link Interface have been detailed and are clearly covered by the ECSS-E document. As reminder, a SpaceWire Link Interface consists of:! Link assembly based on cables and connectors! LVDS drivers! SpaceWire Codec! FIFO instrument applicable dependant The general format of a SpaceWire packet is given in figure Destination address Cargo Figure EOP! Destination is a logical or a physical address, which is assigned by HICDS depending on the data type (HK, science data) and it is intended to the router. Destination is provided by an octet according to SpaceWire Std (ECSS-E-50-12).! Cargo is housing data (HK, science data). The format of the cargo is TBD.! EOP is clearly specified in the SpaceWire Std (ECSS-E-50-12). As indications, one can see 3 possible implementations of an SLI building block at instrument level as presented in figure These implementation take into account the redundancy of each SpaceWire Link at both instrument and router level. Instrument 1 Instrument 2 Instrument 3 Instrument 4 Host SMCS 332 SpW CoDec Host SpW CoDec SM CS Lite SM CS Lite SM CS Lite SM CS Lite Nominal Router 1 Redundant Router 1 Panel1 Figure

19 page 19 of 21 First option The first option is based on the use of one SMCS332_SpW chip ensuring the nominal and the redundant SpW interface. One must note, that this option necessitate a host to manage the SpaceWire packet generation. Second option The second option is based on the use of 2 SpaceWire CoDec ensuring the nominal and the redundant SpW interface. One must note, that this option necessitate a host to generate the SpaceWire packet. Third option The third option is based on the use of 2 SMCSLite_SpW chip ensuring the nominal and the redundant SpW interface. One must note, that this option does not necessitate a host to manage the SpaceWire packet genration, since the SMCSLite_SpW can generate packets on its own. 6. Benefits of SpW I/F use at instrument level 6.1 Introduction The mission development risks are reduced through a proven development methodology and infrastructure proposed by ESA that is detailed in the following sections in order to test and verify and integrate instruments. The use of SpaceWire standard protocols, related on-board pre-developed components that are supported by ESA and related EGSE will save a significant amount of cost and time that would have otherwise been invested in a custom design activity. Any instrument add-ons are based on node-in-the-loop that use an SLI. Their integration in the system can then be considered as following a Plug and Play approach. This Plug-and-Play concept can be made highly adaptable and reduce cost and time to retrofit a system. Special care should be taken for the overall payload and satellite design, integration and verification since all the instruments are not built in Europe. This can lead to possibly different work practices and standards of developments. Therefore, special care to increase the cost effectiveness of the overall system development process should be considered by not only decoupling properly sub-system developments but also by allowing collaborative engineering i.e. distributed concurrent developments, geographically distributed interactive simulations and satellite pre- integration. With the SpaceWire network, instruments can be easily integrated remotely using TCP/IP or other protocols to bridge test subsystems developed at different locations (see the TopNet conception in section 6.3). This produces a move towards new payload systems for which integration and testing can be highly automated. The extent and nature of testing is greatly reduced since prototyping and initial development are already accomplished. 6.2 At test level The inherent modularity in this approach allows entire subsystems to be assembled, iteratively tested, and seamlessly integrated with other subsystems without being impeded by slow progress elsewhere within the program. The well-defined interface standard and the ability to test compliance and functionality of subsystems via a simple PC interface, is low cost oriented and positively affects the design team. In previous projects, functional integration and test was often a somewhat mysterious exercise conducted by a core set of software developers responsible for implementing data interfaces ranging from debug signals all the way through to

20 page 20 of 21 the final command and telemetry interface. The well-defined ground computer's interfaces (PCI, CPCI, VME, ) has made this process far more accessible to the broad design team, thereby providing a significantly efficient work approach. Support tools have not been forgotten and activities are being launched to develop and have commercialised EGSE interface boards and network monitoring tools. This is further presented from section to section SpaceWire PCI Card The SpaceWire-PCI board provides three SpaceWire interfaces on a PCI board with Windows, Linux and VxWorks drivers available. Potential suppliers: 4 Links SpaceWire USB Router box The SpaceWire Router-USB comprises a SpaceWire router with eight SpaceWire ports and one external port connected to a USB2.0 interface. The router is functionally identical to the radiation tolerant router ASIC being developed, except that the Router-USB has only one external port which is used to provide the USB interface. This means that the Router-USB unit can act as an early development support tool for potential uses of the router chip. The USB2.0 interface also means that the Router-USB unit can act as an interface between a PC and a SpaceWire network. High-speed data transfer from SpaceWire directly into host PC main memory is possible. Currently a Linux driver is available and a Windows driver is under development. Potential suppliers: University of Dundee Applied Computing SpaceWire Link Monitor The SpaceWire link Monitor is a tool that monitors SpaceWire traffic flowing down a SpaceWire link. The state of the SpaceWire link and the data and control characters flowing along it can be observed on two banks of LEDs, one for each direction of the SpaceWire link, or on a logic analyzer attached to the SpaceWire Monitor. Potential suppliers: University of Dundee Applied Computing SpaceWire Conformance Tester The SpaceWire standard provides a set of conformance criteria to ensure that SpaceWire interfaces are compatible with one another. Conformance is specified in terms of the sections of the SpaceWire standard that must be adhered to in order to claim conformance to the standard. This paper explains the operation of a SpaceWire Conformance Tester developed for ESA and the level of conformance testing that can be achieved. The SpaceWire Conformance Tester performs the conformance testing of SpaceWire interfaces (Unit Under Test (UUT)) embedded in a range of components, from a simple SpaceWire interface, to a SpaceWire router, to a complete System-on-Chip with SpaceWire interfaces. The level to which conformance testing can be performed will depend upon the degree of cooperation of the SpaceWire interface under test. Potential suppliers: Austrian Aerospace Ethernet-to-SpaceWire bridge The EtherSpaceLink F201 bridge/portal from a TCP/IP socket via Ethernet to SpaceWire, with the TCP/IP implemented in hardware with raw throughput capability of 1.6Gbits/s; Potential suppliers: 4 Links

21 page 21 of At AIV level During development and integration, the distributed architecture will promote the rigorous and independent test/verification and the controlled, incrementally integration of each subsystem/component. Such an achievement will assist in de-coupling the reliance of one subsystem s development on the operation of another (e.g. such as the central processing unit in most centralized architectures). When exploited in a multi-satellite mission, the distributed architecture will allow components deployed across multiple satellites to interact in much the same manner as those within a single satellite. This has significant implications in the simplification of collaborative processing schemes at the conceptual, the implementation and the cost levels. The "TopNet" initiative concept allows easy and powerful decentralised system integration via heterogeneous networks, such as SpaceWire, Intranets and Internet (i.e Ethernet-to-SpaceWire bridge). TOPNET supports concurrent engineering to handle concurrent, multidisciplinary and geographically distributed tests for SpaceWire On-Board Systems Assembly Integration and Verification. Present development is related to developing intelligent systems for on-board usage based on smart sensors, data fusion and a configurable S/W approach called "TaskWare". Special emphasis shall be given to Fault Detection and Recovery management schemes and automatic code generation related to design patterns. It is worth mentioning here that the presence of a routing switch enables to introduce efficient reconfiguration mechanisms on which elaborated FDIR mechanisms can be built. Computer Unit SpaceWire Router SpaceWire links Instrument Instru Instru Instrument E Remote EGSE Remote Simulation Workstations or Engineering modules SpaceWire Network Network Internet Intranet Mass Memory Module Digital Processing Unit Check Up Processor EM Check up Computer Figure 6.3.