EGSE INTERFACE CONTROL DOCUMENT - ESAemits.sso.esa.int/emits-doc/ASTRIUMLIM/GAIA_DynFS/GAIA... ·...

GAIA.ASU.ICD.ESM.00001 Issue 7 Revision 00

of 49

Company Registration No. 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, UK

GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss7).doc

EGSE INTERFACE CONTROL DOCUMENT

CI CODE: 13000 DRL REFS:

DTI EXPORT CONTROL RATING: Not Listed Rated by: D. Perkins

This document is produced under ESA contract 19750/06/NL/FG, ESA export exemptions may therefore apply. These Technologies may require an export licence if exported from the EU

Prepared by: C.G. Catley Date:

Verified by: M.Ali / C. Gabilan Date:

Approved by: S. King / D. Perkins Date:

Authorised by: A. Whitehouse Date:

© Astrium Limited 2007

Astrium Limited owns the copyright of this document which is supplied in confidence and which shall not be used for any purpose other than that for which it is supplied and shall not in whole or in part be reproduced, copied, or communicated

to any person without written permission from the owner.

Astrium Limited Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England


of 49

Astrium Limited owns the copyright of this document which is supplied in confidence and which shall not be used for any purpose other than that for which it is supplied and shall not in whole or in part be reproduced, copied, or communicated to any person without written permission from the owner.


INTENTIONALLY BLANK


of 49



CONTENTS

1 INTRODUCTION AND SCOPE ............................................................................................................6 1.1 Purpose and Scope ...........................................................................................................................6 1.2 References ........................................................................................................................................6

1.2.1 Applicable Documents ...........................................................................................................6 1.2.2 Reference Documents ...........................................................................................................6 1.2.3 Standards Documents ...........................................................................................................6

1.3 Acronyms...........................................................................................................................................7

2 GENERAL DESCRIPTION....................................................................................................................9 2.1 Generic EGSE Configuration.............................................................................................................9

3 EGSE LAN NETWORKING AND COMMUNICATION .......................................................................10 3.1 EGSE General Network Definitions.................................................................................................10

3.1.1 Networking Concepts...........................................................................................................10 3.1.2 Physical Layer .....................................................................................................................11 3.1.3 Data Link Layer....................................................................................................................11 3.1.4 Network and Transport Layer ..............................................................................................11 3.1.5 Session and Presentation Layer..........................................................................................12 3.1.6 Application Layer .................................................................................................................12

3.2 TCP-IP Application Protocol Specification.......................................................................................12 3.2.1 The Server Process .............................................................................................................13 3.2.2 The Client Process ..............................................................................................................14 3.2.3 Message Handshake ...........................................................................................................15 3.2.4 Remote Communication Control .........................................................................................17

3.3 Transport Sample Protocol (TSP) ...................................................................................................18 3.4 Application Message Structure Specification ..................................................................................19

3.4.1 Spacecraft TM and TC Source Packets ..............................................................................20 3.4.2 TM Packet for TC Verification Report (TMTC SCOE) .........................................................20 3.4.3 EGSE internal House-Keeping TM Source Packet .............................................................21 3.4.4 Command and Control Messages .......................................................................................23

3.5 Additional Interface Requirements ..................................................................................................28 3.5.1 IP address configuration ......................................................................................................28 3.5.2 LAN Load.............................................................................................................................28 3.5.3 Network Access ...................................................................................................................28

4 COMMON C&C MESSAGE DEFINITION...........................................................................................29 4.1 Remote Mode Transition Control.....................................................................................................29 4.2 EGSE Equipment RESET ...............................................................................................................29 4.3 EGSE Equipment RESTART...........................................................................................................30 4.4 Automated Sequence Control .........................................................................................................30 4.5 Apply Stimuli ....................................................................................................................................31


of 49



4.6 Set Parameter on EGSE .................................................................................................................31 4.7 Report Request to EGSE and Reply from EGSE............................................................................32 4.8 C&C Message of Type ERROR and Message................................................................................32 4.9 EGSE Self-Test Request .................................................................................................................33 4.10 EGSE Internal HK TM Source Packet Distribution Control .........................................................34

5 EGSE SYNCHRONISATION ..............................................................................................................35 5.1 Time Reference (TREF) .....................................................................................................................35 5.2 Time Synchronisation Methods .......................................................................................................35

5.2.1 Synchronisation by Time Code Signal.................................................................................35 5.2.2 Synchronisation by NTP. .....................................................................................................35

6 EGSE REAL TIME NETWORK...........................................................................................................36 6.1 Network Operation...........................................................................................................................36 6.2 Network Synchronisation.................................................................................................................37

7 SYNCHRONOUS DATA ARCHIVE FILE FORMAT (RES) ................................................................38

8 EGSE TO EGSE INTERFACES .........................................................................................................40 8.1 TMTC SCOE to TTC SCOE Interface Specification........................................................................40

8.1.1 TMTC SCOE to TTC SCOE Cable Design..........................................................................40 8.2 TMTC SCOE to Spacecraft Interface Bracket.................................................................................43

8.2.1 TMTC SCOE to Spacecraft Interface Bracket Cable Design ..............................................43

9 APPENDIX 1: CONVENTIONS...........................................................................................................46 9.1 Bit Numbering and Byte Order Conventions ...................................................................................46 9.2 Representation of Floating Point Numbers .....................................................................................46

10 APPENDIX 2: PROJECT SPECIFIC PARAMETERS.........................................................................47


of 49



TABLES

Table 3.1-1 OSI Reference Model.................................................................................................................10 Table 3.4-1 Primary Header Packet Identification.........................................................................................19 Table 3.4-2 TM Application Data Field for "TC ACK/NACK & TC Verification Report"...................................20 Table 3.4-3 Packet Data Field - Examples.....................................................................................................22 Table 3.4-4 Command and Control Message Structure..................................................................................23 Table 3.4-5 List of Keywords .........................................................................................................................27

FIGURES

Figure 2.1-1 GAIA EGSE Configuration ...........................................................................................................9 Figure 3.2-1 TC Handshake Mechanism.......................................................................................................16 Figure 8.1-1 TMTC SCOE to TTC SCOE Cable .............................................................................................42 Figure 8.2-1 TM/TC Bypass to Power SCOE Cable .......................................................................................45


of 49



1 INTRODUCTION AND SCOPE

1.1 Purpose and Scope

This interface control document defines common architectures and interfaces used by the Gaia Electrical Ground Support Equipment (EGSE).

The following EGSE architectures are defined for use in Gaia:

• Network communication protocols to be used between the Central Checkout System (CCS) and all EGSE that are connected to it on the EGSE LAN.

• Command and Control Message formats for asynchronous communication between the CCS and all EGSE connected to it on the EGSE LAN.

• Communication formats for synchronous data exchange between EGSE and the CCS on the EGSE LAN.

• A Real Time (Distributed Memory) Network interface between EGSE.

• Synchronous Data File Archive formats. This ICD also defines the details of the Gaia specific EGSE to EGSE interfaces, including pin functions, connector types and cable lengths.

1.2 References

1.2.1 Applicable Documents

AD1 GAIA Generic TM/TC ICD GAIA.ASF.ICD.SAT.00003

1.2.2 Reference Documents

RD1 TSP: Transport Sample Protocol User’s Requirements Document

Issue 1 Revision 1

24/12/2002

1.2.3 Standards Documents

SD1 ANSI Standard for Low Voltage Differential Signalling (LVDS) ANSI/TIA/EIA-644-A


of 49



1.3 Acronyms

ACK Acknowledge

AIT Assembly Integration and Test

AIV Assembly, Integration and Verification

AOCS Attitude and Orbit Control System

API Application Programming Interface

APID Application Process Identifier

ATP Automated Test Procedure

BNF Backus Naur Form

C&C Command and Control

CADU Channel Access Data Unit

CCS Central Checkout System

CLCW Command Link Control Word

CLTU Command Link Transmission Unit

CMD Command

CCSDS Consultative Committee for Space Data Systems

COTS Commercial Off The Shelf

CPU Central Processor Unit

DFH Data Field Header

EGSE Electrical Ground Support Equipment

EM Engineering Model

ESA European Space Agency

FID Failure Identifier / Failure Code

FM Flight Model

GSE Ground Support Equipment

HK House-Keeping

HWIL Hardware in the Loop

I/F Interface

I/O Input/Output

ICD Interface Control Document

ID Identifier

LAN Local Area Network

LVDS Low Voltage Differential Signalling

MMI Man-Machine Interface

N/A Not Applicable

NAK Not-Acknowledge

NDIU Network Data Interchange Unit

NTP Network Time Protocol


of 49



OGSE Optical Ground Support Equipment

PC Personal Computer

PFM Proto-Flight Model

PID Process Identifier

PLM Payload Module

PPS Pulse per second

PUS Packet Utilisation Standard

RD Reference Document

SCOE Special Check-Out Equipment

SRDB Satellite Reference Data Base

SDE Software Development Environment

SID Structure Identification

SIF Service Interface

SRD Software Requirements Document

SVM SerVice Module

TBC To be confirmed

TBD To be defined

TC Telecommand

TCP/IP Transmission Control Protocol/ Internet Protocol

TM Telemetry

TS Test Sequence

TTC Tracking, Telemetry & Command

UTC Universal Time Coordinated

VC Virtual Channel

VCDU Virtual Channel Data Unit

VCID Virtual Channel Identifier

XML Extensible Mark-up Language


of 49



2 GENERAL DESCRIPTION

All EGSE requiring control by the CCS interface to it via the EGSE Local Area Network (LAN).

All EGSE utilised in the real-time domain for closed-loop AOCS testing interface with each other via the Real Time Network (RTN).

2.1 Generic EGSE Configuration

The diagram in Figure 2.1-1 shows all EGSE elements and how they are interconnected. The cable and Spacecraft skin connector details shown should be considered as TBC at this issue of the document.

Spacecraft Interface Bracket

Power/PyroSCOE

Um

bilic

al R

ack

AutoBackup

CentralArchive

Disc

Avi

onic

s S

CO

E

IRIG-B

Dat

atio

n IR

IG-B

IRIG-B

AVM Bench Test Interface Bracket

FPACDMUTTLTRIG

EGSEREAL-TIMENETWORK

PCDU

PDHU

Battery Power/AIT Prime

Cen

tral C

heck

out

Sys

tem

(CC

S)

Ser

ver

PowerController

DynamicFPA

Simulator

VPU1-7

CDU

LGA-1

STR1

STR2

GYRO 1A/2A

CDUSCOE

OpticalStim SCOE

PLM

155

3

SA111

SolarArray

Simulator

Majority VoterTest Interface

TMTCSCOE

Star TrackerSCOE #1

Real-TimeSimulator (RTS)

CDMUSimulator

ERC32Emulation

CSW

SVM/PLMMIL-STD-1553B

BUS (A/B)

SREM

OSE

MDE

SA107

Test Cap

EGSE SupplierFurnished Cables

AstriumFurnished Cables

BatterySimulator

Battery ChargePower Supply Offline Battery Charge/

Discharge Interface

Star TrackerSCOE #2

Battery Power/AIT Redundant

SA108

Pyro Signals Prime

Pyro Signals Redundant

MV Test Interface

SAS FSA PrimeSAS FSA Redundant

SAS DSA PrimeSAS DSA Redundant

Umbilical #1

Umbilical #2

SA103SA104SA105SA106

SA101

SA102

SA801

SA802

PAA-Test Port Inputs (28x)

SV

M 1

553

Transponder #1

Transponder #2

PAA

PacketWire

SA805-

SA832

GYRO 5B/6B

T T

BCBC

RT

RT

RT

RT

RT

RT

RT

RT

RT

RT

RT

RT

RT

CLO

CK

S

PYRO/NED

GYRO 3A/4B RT

BATTERY

LoadSimulator #1

LoadSimulator #2

Umbilical SupportPower Supply

Umbilical Monitor

BDR Auto-restart INH

Separation Strap Sim

PWSpW

SA109SA110

NED Signals Prime

NED Signals Redundant

BATTERY

BUS Performance Test InterfaceSA112

SA209

FSS 1

FSS 2

FSS 3

TTCSCOE

PowerSimulation

FCV-ACQLV-ACQ

EGSE 1Hz I/F

Pyro/NEDSimulator

TM/TC X-Band

Spa

ceW

ireS

pace

Wire SpaceWire

SCOE(Link &

Monitor)

SA803

T

T

RT

LGA-2

LGA-3

AB228AB229AB230

SA216

AN3-SIM

RS-422

CMOS

RSA-SIM

AN2-SIMAN1-SIMSHP-ACQSHP-GEN

BLD-TM

SA210SA211SA212

SA205SA206SA207SA208

uPropulsion PRIME

uPropulsion RDNT

MPE-A RT

MPE-B RT

CPS PRIME

CPS RDNT

EIU-A

EIU-B

SA213

SA214SA215SA217SA218RSA SIMULATION 1 (DSA/BIPODS)

AB219RSA SIMULATION 2AB220RSA SIMULATION 3AB221AN2/AN3 SIMULATIONAB222AN1 SIMULATIONAB223SHP Type-2 ACQAB224SHP Type-3 ACQ/GENAB225SHP Type-3 ACQ/GEN

SA302

SA301

AB227BI-LEVEL TM SIMULATIONAVM TEST HARNESS

LCL Sim#1LCL Sim#2

PPS (EGSE 1Hz)

CPS-Prime-1 (LV/Status)

LCL Sim#3

CPS-Prime-2 (FCV/PT)CPS-Redundant-1 (LV/Status)

CPS-Redundant-2 (FCV/PT)

MPS-Prime-2 (FCV/FLOW/PT)MPS-Redundant-1 (LV/Status)

MPS-Redundant-2 (FCV/FLOW/PT)

MPS-Prime-1 (LV/Status)

GYRO HWIL STIMULATION

FSS HWIL STIMULATIONFSS SIMULATION

SREM SIMULATION

SA201

STR1

STR2

LGA-2 Test

LGA-1 Test

SVM/PLM 1553 BUS (A/B)

LGA-3 Test

CDMU-EIUSpaceWire

CDMU-PDHUPacketWire

CDMU-EIU SpW (A/B)

CDMU-PDHU PW (VC1/VC3 A/B) SA202

SA203

SpaceWire

AvionicsSCOE

Controller

IRIG-B TIMEREFERENCE

Real-timeNetwork HUB

EGSELAN

TTL

TMTC SCOEController

CC

S U

ser

Wor

ksta

tion

CC

S U

ser

Wor

ksta

tion

CC

S U

ser

Wor

ksta

tion

CC

S U

ser

Wor

ksta

tion

DSA/BIPODS

Title: EGSE CONFIGURATION & INTERFACES

CHECKED BY:

APPROVED BY:

DWG NODRAWN BY: DATE SHEET

DT-0000000 19/06/07 1 of 1

DATE:Modification Status

ISS:DATE:DATE:DATE:DATE:

ISS:ISS:ISS:ISS:

29/06/07 1A

TM/TC Bypass SA113SA114

TMTC TEST

Figure 2.1-1 GAIA EGSE Configuration


of 49



3 EGSE LAN NETWORKING AND COMMUNICATION

3.1 EGSE General Network Definitions

3.1.1 Networking Concepts

For all EGSE Local Area Networks (LAN), the implementation is based upon the “Open Systems Interconnection“ (OSI) Seven Layer Reference Model briefly presented below. The OSI Reference Model partitions networking functions into seven layers as depicted in Table 3.1-1.

Layer 7 APPLICATION

Layer 6 PRESENTATION

Layer 5 SESSION

Layer 4 TRANSPORT

Layer 3 NETWORK

Layer 2 DATA LINK

Layer 1 PHYSICAL

Table 3.1-1 OSI Reference Model

Layer 7: The application layer serves as the window between corresponding application processes that are exchanging information.

Layer 6: The presentation layer manages the representation of information that application layer entities either communicate or reference in their communication.

Layer 5: The session layer provides the services needed by presentation layer entities that enable them to organize and synchronize their dialogue and manage their data exchange.

Layer 4: The transport layer provides transparent data transfer services between session layer entities by relieving them from concerns of how reliable and cost-effective transfer of data is achieved.

Layer 3: The network layer manages the operation of the network. In particular, it is responsible for the routing and management of data exchange between transport layer entities within the network.

Layer 2: The data link layer provides the exchange of data between network layer entities. It detects and corrects any errors that may occur in the physical layer transmission.

Layer 1: The physical layer is responsible for the transmission of raw data over a communication medium.

A basic principle of the OSI Reference Model is that each layer provides services needed by the next higher layer, in a way that frees the upper layer from concern about how these services are provided. This approach simplifies the design of each particular layer.


of 49



3.1.2 Physical Layer

The physical layer is defined to be Gigabit Ethernet over copper.

Ethernet adapters supporting 1000BASE-T specification have to be used for all computers connected to the EGSE LAN.

To achieve Network speeds approaching 1Gb/s, any Gigabit Ethernet Network Interface Cards must be specified for the PCI-Express BUS.

The 1000BASE-T specification describes a process called Auto-Negotiation, which allows devices at each end of a network link to automatically exchange information about their capabilities and perform the configuration necessary to operate together at their maximum common level.

LAN connections are made using a Gigabit Switch.

3.1.3 Data Link Layer

The data link layer is defined to be Gigabyte Ethernet according to IEEE 802.3z.

3.1.4 Network and Transport Layer

The network layer is defined to be implemented by the Internet Protocol (IP) and the transport layer is defined to be implemented by the Transmission Control Protocol (TCP) both conforming to TCP/IP protocol.

A unique IP Address must be defined and associated to every host interface, or node, on a TCP/IP network. This address is used to identify a node on a network; it also specifies routing information in an inter-network. The IP address identifies a node as a 32-bit address that is unique across a TCP/IP network. An address is usually represented in dotted decimal notation, which depicts each byte of an IP address as its decimal value and separates each byte with a period. An IP address looks like:

w.x.y.z (e.g. 130.201.8.99)

For all EGSE configuration networks Class-C type IP addresses are recommended assigning a value from 192 through 255 to the first byte “w“. The host-id allocates the 4th byte “z” of the IP address having up to 254 nodes (values 0 and 255 cannot be assigned to a host-id; 0 is allocated to the subnet mask and 255 is used as broadcast address). Optionally the range of host-ids can be expanded to the 3rd byte “y” by modifying the subnet mask accordingly (e.g. host-id extended to 1022 nodes by two least significant bits of “y”, subnet mask = 255.255.252.0)

This leads to the following IP address definition recommended:

IP address fields w x y z

Class-C address network address host id

Subnet Mask 255 255 255 0

Broadcast Mask network address 255

Table 3.1-2 IP Address definition


of 49



3.1.5 Session and Presentation Layer

Not applicable to end-to-end inter-process communication.

The transport layer is the lowest layer in the Reference Model that provides the basic services of reliable, end-to-end data transfer needed by applications.

3.1.6 Application Layer

Inter-process communication between any EGSE element / subsystem takes place by means of Host-to-Host / end-to-end communication between two processes; each process executed on a different node. Any process that offers a service over the network to another process is known as a server. Servers accept requests from other processes, which are known as clients. A client sends a request and waits for the result from the server.

Inter-process communication is based on a connection-oriented Transport Level Interface stream socket mechanism. A stream socket supports bi-directional, reliable, sequenced, and unduplicated flow of data without record boundaries. The receiving processes are guaranteed to receive the messages, in order, without a duplicated message.

Connection-mode stream socket is circuit-oriented and enables data to be transmitted over an established connection in a reliable, sequenced manner. It also provides an identification mechanism that avoids the overhead of address resolution and transmission during the data transfer phase. This service supports long-lived data-stream-oriented interactions as required for all EGSE inter-process communication.

The connection-mode transport service is characterized by four phases: local management, connection establishment, data transfer, and connection release.

3.2 TCP-IP Application Protocol Specification

A server or client process has to be implemented on each network node while participating in inter-process communications. A pair of server / client processes shall be implemented for each host-to-host communication link between any two EGSE network nodes. Two logical links (i.e. two stream sockets) are mandatory /are required for each host-to-host link routing:

One bi-directional link is dedicated to the client process sending messages (i.e. commands) to the server process and receiving its corresponding acknowledgement from the server, if any.

Client process server process

One unidirectional link is dedicated to the server process sending messages (i.e. S/C TM, server TM, status messages, etc.) to the client process and receiving its corresponding acknowledgement from the client, if any.

client process server process

Thus, each network partner is able to send its unsolicited messages on its „send-link“ concurrently awaiting unsolicited input messages on its „receive-link“

Stream socket based inter-process communication is to be implemented for server and client processes as outlined below. Stream socket services are provided by the TCP/IP protocol implementation and are supported by operating system calls on e.g. UNIX-based systems. For details on stream socket services refer to dedicated TCP/IP / operating system documentation belonging to dedicated machines.

send-link receive-link

messages acknowledgement

send-link receive-link

messages


of 49



As a server will act on all EGSE elements providing network services, waiting for network operations by the connecting host, thus a server is always passive, being controlled by the client. Therefore the host (e.g. the CCS) will be the client, as it is the active partner.

Once sockets are established they will only be released upon specific command sent by the client or shutdown of either side. Availability of a socket link does NOT imply the server being remote controlled by the client - see § 3.2.4.

3.2.1 The Server Process

Local Management:

server process initialization

Create / Open stream socket

Bind stream socket to an address of a data structure

repeat infinite until server process terminated (local command or system shutdown)

Connection Establishment:

while not connected do listen on socket for request -> wait for connection request from client

accept connection request

Data Transfer:

while connection established do

if data to be sent to client

then get data buffer to be sent

send message buffer to socket

if message received from client

then read message buffer received on socket

process data received

if connection release by either local command or client disconnect request

Connection Release:

then disconnect socket

until server process terminated (local command or system shutdown)

Unbind and Close stream socket

end of server process


of 49



3.2.2 The Client Process

Local Management:

client process initialization

Create / Open stream socket

Bind stream socket to an address of a data structure

repeat infinite until client process terminated (local command or system shutdown)

Connection Establishment:

if local connection request command

then issue socket connection request to target server process

Data Transfer:

while connection established do

if data to be sent to server

then get data buffer to be sent

send message buffer to socket

if message received from server

then read message buffer received on socket

process data received

if connection release by either local command or server disconnect request

Connection Release:

then disconnect socket

until client process terminated (local command or system shutdown)

Unbind and Close stream socket

end of client process


of 49



3.2.3 Message Handshake

3.2.3.1 Command and Control Message Handshake

An acknowledge / not-acknowledge (ACK/NAK) handshake is used for command and control messages issued by the client.

Every command and control message is to be acknowledged by the server, sending an acknowledgement control message (keyword = ACK; see next section) to the client, with arguments if appropriate, to indicate that the requested action has been taken. A negative acknowledgement (keyword = NAK) is issued in the event of an error or any condition preventing the requested action from being taken.

The acknowledgement is to be given immediately after syntax check and recipient mode verification (i.e. is the command requested actually allowed).

Command execution is to be performed after sending the acknowledgement. This allows a unique command /acknowledgement time-out setting by the client to be applied to all C&C messages irrespective of their execution duration at destination.

Command execution verification is expected to be done by means of equipment status reporting either via dedicated report request (ref. § 3.4.3.1) or via cyclical equipment telemetry data transfer (ref. §3.4.2).

The first argument of each ACK or NAK message is defined to be the command keyword the acknowledgement belongs to. No other information is mandatory. Additional arguments may be repeated by extraction from the command itself. Also an acknowledgement status may be added. However, the ACK/NAK message arguments are for information only, forming part of the message logging not processed by the ACK/NAK receiver.

Arguments of the ACK/NAK message:

1st argument: command keyword of the message the acknowledgement belongs to

2nd argument: 1st argument of command message, if available

3rd argument: optional; only used in case of NAK: -> NAK reason return status

The ACK/NAK message arguments are for information only, subject to message logging and display by the client.


of 49



3.2.3.2 Telecommand Source Packet Acknowledgement

To control the routing of telecommand source packets, through the TMTC SCOE TC Front End equipment, for up-link to the on-board telecommand receiver (via RF or TC bypass link), a TC handshake / acknowledgement mechanism is required.

This protocol has to take into account the fact that TC decoding by the TC Front End equipment for generating the TC Source Packet Echo message to the command issuer is independent from the TC encoding w.r.t. timing and command to command echo correlation.

The basic TMTC SCOE TC Front End architecture and the resulting data-flow is shown in the Figure 3.2-1 below.

Figure 3.2-1 TC Handshake Mechanism

The CCS, after having issued a TC Source Packet to the TMTC SCOE, shall instantly receive a TC acknowledgement message from the TMTC SCOE TC Front End indicating that the TC has been successfully (ACK) or not (NAK) queued into the front end TC processing buffer.

The CCS has to synchronize on this TC acknowledgement to release the next telecommand for sending to the TMTC SCOE.

The TC Source Packet Echo, obtained by the TMTC SCOE TC Front End equipment after decoding, is sent to the CCS completely asynchronously to the TC send and TC acknowledgement. No correlation to the TC sending by the CCS is required.

The echo message is to be used by the CCS for logging purposes only, indicating that the TC has left the TMTC SCOE for up-link. In addition the TC echo message, providing the complete binary TC Source Packet, may be used by the CCS for command issuing notification of connected supplementary test equipment such as instrument EGSE.

In case of TC retransmission by the TC Front End to the on-board system, multiple TC Echoes are generated by the TC Decoder of the TC Front End. Consequently, the command sequence indicated by the sequence of TC Echoes may not be identical to the on-ground commanded and on-board executed sequence.

Because at TC Source Packet level there is no correlation possible to the TC up-link at CLTU level, neither the TC Front End nor the CCS are able to indicate whether or not a TC Echo corresponds to a successful

TC Encoding TC Decoding

CCS

TC Buffer TMTC

SCOE TC Source Pkt

TC Source Pkt

Encoded TC

TC Ack/ Nak

TC Source Pkt Echo

TC Bypass

TTC SCOE


of 49



up-link or a retransmission. Therefore the CCS is requested to archive all TC Echoes received and - if distribution is enabled - distribute all TC Echoes to instrument EGSE.

The message data structure dedicated to the TC acknowledgement is outlined below.

The TC Source Packet Echo data structure that is sent by the TC Front End equipment to the CCS is identical to the TC Source Packet that was issued by the CCS.

Based on a two socket communication between the CCS and the TMTC SCOE, the TC acknowledgement message is returned by the TC Front End on the same link (i.e. TMTC SCOE receive link) as the TC Source Packet was received as it is an immediate handshake. Whereas the TC echo is an unsolicited message sent to the CCS on the TMTC SCOE send link.

Receipt of a TC echo message is NOT acknowledged by the CCS.

3.2.3.3 Telemetry Source Packet Acknowledgment

For telemetry source packet distribution, acknowledgement is neither foreseen nor needed.

Data transmission on the network is assured by the TCP/IP protocol and processing of received telemetry packets is up to the receiving node; in worst case the packets received will be discarded. The only constraint to every telemetry packet sink is that reading from the network port (socket) is never stopped or blocked as long as the communication link is established.

If packets cannot be processed for any reason this must be notified to the operator and/or the telemetry source.

3.2.4 Remote Communication Control

At any time after establishing the network logical link (socket) connections, the client may start remote communication, taking over command authority from the server local command instance by sending the C&C message "TRANSFER remote".

If the server is ready to start communication and to hand over command authority to the server, the acknowledge message returned will repeat the remote request (i.e. C&C: “ACK TRANSFER remote”) and the server will change its internal operating mode from LOCAL to REMOTE. Otherwise a not-acknowledge message is returned by the server indicating that the server will remain in LOCAL operation mode (i.e. C&C: “NAK TRANSFER remote”).

The server decision for transferring communication mode to REMOTE has to be derived from the internal application software status (i.e. ready or not-ready).

Once the server is in REMOTE communication mode, messages can be exchanged in both directions: The client can command the server by sending messages on the client send link / server receive link, the server may send unsolicited (status) messages to the client on the server send link / client receive link.

Note: The server may send unsolicited (status) messages to the client on the server send link / client receive link even in LOCAL mode (i.e. prior to any TRANSFER remote or after TRANSFER local transition).

Mode transition from REMOTE back to LOCAL, performed by means of the C&C message "TRANSFER local", may be requested either by the server or by the client. Subsequent transition from local to remote has to be re-initiated by a "TRANSFER remote" request from the client.

Remote / local mode only indicates the status of the server (i.e. front-end equipment) with respect to the communication mode to the client (i.e. the CCS). The server internal processing state (called „on-line“ / „off-line“) with respect to the data processing and / or connection to the peripherals (i.e. instrument or satellite subsystem) is not affected by a TRANSFER C&C message.

As a consequence on an EGSE element, there may exist four mode states derived from the combination of internal processing state ONLINE / OFFLINE and command authority site LOCAL / REMOTE.


of 49



3.3 Transport Sample Protocol (TSP)

The Gaia EGSE architecture, for AVM Bench Testing and AIV, implements a Central Archive system for archiving of data acquired by all EGSE.

This allows centralised management of archived data and implementation of an automated backup system (LT03) for permanent data storage.

All data acquisitions are available at near real-time from the CCS Central Archive Disc for post processing and analysis using common tools.

Where high volumes of data are acquired by EGSE for Central Archive, the Gaia OpenCentre Version 6.1 (or later) implements special EIF interfaces for data acquisition using the Transport Sample Protocol (TSP).

The TSP implementation allows transfer of large volumes (thousands of samples transferred at rates of up to >100Hz) of synchronous data.

TSP uses standard TCP-IP client-server links between the Gaia EGSE and CCS-EIF.

All Gaia EGSE acquiring data synchronously shall implement the TSP Protocol, acting as the TSP provider, with the CCS as the TSP consumer, for transferring data to the CCS.

TSP is an OpenSource development. RD1 identifies the TSP specification. TSP source drivers, user and programming manuals for TSP can be located at:

http://savannah.nongnu.org/projects/tsp For Gaia, EGSE required to transfer (archive) large volumes of synchronous data to the CCS shall implement the TSP protocol to Version 0.8.2.

The TSP protocol implements an individual TSP provider-consumer (TCP-IP) link for each defined rate of synchronous data transfer (that is, one for data collected at 1Hz rate, one for 8Hz rate etc.)

Using TSP the Consumer (CCS) defines the data to be archived. The TSP Provider (EGSE) defines the order in which the data is transferred, when negotiating the TSP link.

As requested by the TSP consumer, each TSP sample provider shall provide a sample representing the sampled data time (the TREF for each sample rate). This sample (TREF) shall be the first data sample transferred for each sample rate.

The format for TREF shall be a 64-bit Integer corresponding to the number of microseconds since the beginning of the current year.

The delta time between the first sample acquisition and the last for any one point of TREF time, for an individual TSP link, shall be <1us. This is to ensure coherency between the sampled data and the reported sampled data time. Where samples need only be time-stamped relative to a simulation cycle (such as the Real Time Simulator) this requirement may be ignored.

The TSP provider shall assign a “provider_global_index” equal to zero to the sample representing the sampled data time (first position in the sampled data list).


of 49



3.4 Application Message Structure Specification

For EGSE network inter-process communication, consisting of command and control message distribution and TM/TC packet routing, it is defined to use messages in the form of CCSDS source packets (Note: This does not include inter-process communications utilising Transport Sample Protocol).

This enables all EGSE nodes to look for a single type of incoming data structure and direct the processing of the packet on the basis of the socket name on which the message was received and the APID value.

TM source packets and TC source packets are routed on the EGSE networks as native onboard source packets (i.e. without any additional envelope). There is no need to identify message source or destination with respect to EGSE network nodes because the inter-process communication is performed via dedicated logical point-to-point links as discussed above.

Source packets are distinguished through specific field assignments to the packet primary header as depicted in Table 3.4-1 below:

Primary Header Packet Identification Fields: Version # Type Data Field Header

APID

TM Source Packet 000 0 S/C specific

TC Source Packet 000 1 S/C specific

C&C Message - Source Packet 011 1 0 (see Appendix 2)

EGSE internal House-Keeping TM Source Pkt 011 0 1 (see Appendix 2)

Table 3.4-1 Primary Header Packet Identification


of 49



3.4.1 Spacecraft TM and TC Source Packets

Telemetry source packets down-linked by the spacecraft on various physical links are to be distributed and processed by the EGSE. Source and destination for telemetry packet distribution may vary on the different EGSE configurations.

Spacecraft specific telemetry source packets shall be according to [AD1] Section 4.1.

Spacecraft specific telecommand source packets shall be according to [AD1] Section 5.1.

3.4.2 TM Packet for TC Verification Report (TMTC SCOE)

The TMTC SCOE TC acknowledgement and verification report message is a Telemetry Source Packet, conforming to [AD1] Section 4.1, identifying the TMTC SCOE as the service providing application process (by APID).

The purpose of this TM Source Packet is to provide the TC processing status from the TMTC SCOE TC front end.

The TMTC SCOE TC Verification Report implementation is similar to that defined in [AD1], Appendix A2.1 "SERVICE 1: TELECOMMAND VERIFICATION".

This message has to be generated independently from the "ACK flags" within the TC Packet DFH as these ACK flags only request on-board TC acknowledgement to be applied to a telecommand.

For specific TC Verification at the Ground System level the TMTC SCOE shall use Service Type 1, Sub-Type 129 for an Acknowledge (ACK) and Service Type 1, Sub-Type 130 for a Not-Acknowledge (NACK).

As shown in Table 3.4-2, the application data field provides the identification of the TC Source Packet acknowledged, by repeating the first four bytes of the command packet Primary Header and the Source ID field from the Secondary Header. Where no Secondary Header is included in the TC Source Packet (such as for CPDU (Direct) commands), the TC Source ID Field of the TM Verification Packet shall be set to zero.

In the case of not acknowledge (NAK service (1,130)) an error code is added giving the reason for the failure.

TC Packet ID

TC Sequence Control

TC Source ID Error Code

NAK only

2 byte 2 byte 1 byte 2 byte

Unsigned Int Unsigned Int Enumerated Enumerated

Table 3.4-2 TM Application Data Field for "TC ACK/NACK & TC Verification Report"

In the event of a NAK service (1,130) the additional error code reports the reason of TM/TC front end ‘not acknowledge’ (NAK). The following Error codes have been identified:

Error code : 1 = TC processing OFF 2 = Invalid Mode 3 = Inconsistent Packet 4 = TC Buffer Full 5 = forbidden TC etc. … additional ID's may be identified


of 49



3.4.3 EGSE internal House-Keeping TM Source Packet

The TM Source Packet specification as defined in [AD1] Section 4.1 is to be applied to the EGSE internal HK TM Source Packet data structure definition.

HK TM Source Packets shall use Service Type 3, Sub-Type 25.

The EGSE internal HK TM Source Packet can be created by any EGSE element which is required to report its operational status and/or configuration and return any on-board monitored parameter data, similar to spacecraft telemetry data packets.

Once enabled, such packets can be sent to the CCS autonomously and periodically and can be treated by the CCS as nominal telemetry packets for archiving, monitoring and display.

As for spacecraft TM packets, acknowledgement by the receiving CCS is not foreseen for EGSE internal HK TM packets.

According to PUS service (3,25), a Structure Identifier (SID) is prefixed to the HK data in the Packet Data Field, unambiguously identifying the contents of the packet in terms of parameters reported and their location within the packet data field. The SID is an 8 bit field and the assigned SID values have to be in the range of 1..255; the value zero is not used.

The Packet Data Field holds EGSE measurements as defined by the dedicated Structure Identifier (SID). A measurement is required to start at byte boundaries having a maximum size of 32 bits.

To enable the CCS to specify, within the database, the measurements engineering representation and physical unit and to perform house-keeping data monitoring on EGSE parameters, a packet contents description dedicated to each defined SID has to provide at least the information as follows (see also Table 3.4-3 below):


of 49



Location of measurement inside the data field as byte offset value (i.e. first measurement starts at location 0) Length of measurement in number of bits.

Range: 32 bits max. for analog and digital parameters; 2040 bits max. (255 chars) for character strings Type of measurement (e.g. counter, signed/unsigned integer, real, digital status, etc.) Calibration law for real measurements or status text conversion for digital status Limits (high/low) for real measurements The table below, in its header lines, defines the information required, whereas the table lines show examples especially w.r.t. columns "parameter position", and explain the required information w.r.t. columns "parameter attributes".

Packet Data Field

DFH SID Para-1 Para-2 Para-3 .... Para-n

byte offset 0

SID = n

Parameter Position Parameter Attributes Para-meter Name

(Mnemo)

Byt

e of

fset

Sta

rt b

it (0

..7)

# of

bits

(1

..32)

or

(1…

2040

) Type Calibration Value Range

Limits Description

<Para-1> 1 0 8 UINT Calibration point pairs

<Para-2> 2 0 16 INT Calibration point pairs

<Para-3> 4 0 32 REAL Real number according to

Annex 1

range of raw values and/or

engineering values

engineering values low and high limits the

parameter shall be checked against

un-used 8 0 6

<Para-4> 8 6 2 STATUS status-text 0 := OFF 1 := ON

<Para-5> 9 0 8 COUNT or REGISTER

no calibration range of raw values

raw value limits to check

<Para-6> 10 0 - CHAR(x) ASCII Text

textual short

description of

parameter purpose

30 chars max

Table 3.4-3 Packet Data Field - Examples

For character string fields defined in the HK TM Source Packet an absolute fixed length has to be allocated in the packet data field as shown in example <Para-6> of Table 3.4-3 above. The ASCII text inserted at run-time may be of variable length, with a maximum number of characters as defined by the allocated field length. A text string shorter than the reserved field length must be terminated by a binary zero byte. The remaining character field, up to the maximum length defined, shall be padded out with binary zero bytes in order to overwrite the contents from the preceding packet.


of 49



3.4.3.1 EGSE internal Event Packets

EGSE elements may issue unsolicited telemetry event packets, e.g. to communicate equipment problems / errors / warnings to the CCS. If used, event TM Source Packets issued by the EGSE have to have the same data structure as for EGSE internal HK TM Packets:

Primary Header: same APID as for EGSE internal HK TM packets Data Field Header: using "Service Type" = 5; "Service Sub-Type" = 1 Structure ID: called Report ID (RID), length = 16 bits (2 byte)

The RID is a 16 bit field and the assigned RID values have to be in the range of 1..65535; the value zero is not used.

Event Data: fixed measurement allocation defined by dedicated RID according to the rules given above for measurement/parameter definition within the Packet Data Field.

Generation of such packets is considered driven by events and therefore not controlled by the routine CCS TM/TC interrogation.

3.4.4 Command and Control Messages

Command and Control Messages (C&C Messages) are the EGSE equivalent to telecommands (TC) sent to the on-board system.

The CCSDS Source Packet specification, as defined in [AD1] Section 5.1, is to be applied to the EGSE Command and Control Message data structure definition. The Source packet format shown in Table 3.4-4 consists of the following fields:

1. Primary Header 6 byte

2. Data Field variable - 1024 byte (i.e. characters) maximum

7 4 11

Version Number

Command & Control Message

Packet Data Field (variable) Source Packet Primary Header (48 bits)

Packet Id Packet

Sequence Control

Packet Length Data

Field Header

Flag

Application Process Id

Process Id

Packet Category

Source Sequence

Count

Type

3 1 1 2 14 16 N * 8

Segmen tation Flags

Table 3.4-4 Command and Control Message Structure


of 49



The C&C ACK/NAK message has the same source packet primary header as the originating C&C message, with the exception of a different APID.

A unique application process identifier (APID) is allocated to all command and control (C&C) messages and a separate APID is used for the corresponding acknowledgement message (C&C ACK/NACK). The source of every control message is known by the socket through which it is received. The APID for EGSE command and control messages must be configurable in order to fit into the on-board equipment APID range defined in [AD1] Appendix 3. The Process Identifier and Packet Category shall be initially set to the values defined in Appendix 2 of this document, for each EGSE element

One Source Sequence Counter is maintained by each command issuing instance (i.e. on each point-to-point connection). The command receiving instance has to return this Source Sequence Counter within the command acknowledgement source packet allowing easy correlation between the C&C ACK/NAK message received and the C&C message issued.

No Data Field Header (DFH) is provided with the Command and Control Message data structure.

No Packet Error Control (PEC) field is used in the Command and Control Message data structure.

The C&C message has to be logged and archived by the generating node as well as by the receiving node and stamped with the creation date and time information and receipt date and time information, respectively. Thus the C&C message itself is not intended to carry time and date information for this purpose.


of 49



3.4.4.1 Source Packet Data Field Definition

Command and control (C&C) messages are in the form of ASCII text, consisting of a statement followed by a semicolon, and optionally followed by free commentary text for up to a total source packet data field of 1024 characters. A statement is one of several keywords separated by a space, and followed by one or more optional arguments. One command and control message can hold only one command (i.e. one command per line).

The syntax of a command and control message expressed in BNF notation is as follows:

c&c_message ::= <command> [<space><argument_list>] [;] Legend: - repetition operator

| - OR operator [ ] - optional < > - placeholder

<command> ::= <letter> <underscore> | <letter> | <digit>

(mandatory) a keyword (containing no spaces) from a set of keywords selecting the action requested. A not exhaustive list of keywords is given below.

<space> ::= ASCII character 20hex

<underscore> ::= ASCII character 5Fhex

<letter> ::= A..Z | a..z

<digit> ::= 0..9

<hex_digit> ::= <digit> | A..F | a..f

<argument_list> ::= <argument> , <argument> <argument> ::= <command_option> | <parameter_assignment> | <value>

(optional) list of command options, parameter assignments and values. List items are separated by comma. The syntax for argument types is:

<command_option> ::= <letter> <underscore> | - | . | <letter> | <digit>

<parameter_assignment> ::= <parameter_identifier> = <value>

<parameter_identifier> ::= <letter> <underscore> | <letter> | <digit>

<value> ::= <numeric_literal> | <character_string> | <identifier>

<numeric_literal> ::= <decimal_number> | <hexa_number>

<decimal_number> ::= [ + | - ] <integer> [. <integer>] [<exponent>]

<integer> ::= <digit> <digit>

<exponent> ::= E | e [+] <integer> | E | e - <integer>

<hexa_number> ::= 0X | 0x <hex_digit> <hex_digit>

<character_string> ::= “ASCII character“ Note: ASCII char “ (22hex) excluded

<identifier> ::= <letter> <underscore> | <letter> | <digit>

Parameters are names / mnemonics to identify internal processing arguments (e.g. telemetry items as specified in a database) that have significance to a particular command keyword. Values may be numeric, strings or Boolean identifiers.


of 49



Numeric values: decimal or hexadecimal integer value or real value in ASCII representation (e.g. 123 / -987680 / 0XA05F / 1.25 / 4.8e-3 )

Character string: string of characters delimited by double-quotes (e.g. “Select Channel 2“ )

Boolean identifiers: unquoted string (e.g. ON / OFF or TRUE / FALSE )

The different argument types - cmd options, parameters, values - may be mutual exclusive within one control message string or all types may be allowed, subject to dedicated interface requirement specification.

In the first instance the maximum number of arguments is not limited while not exceeding the maximum string length of the data field. However, implementation may require to limit maximum number of arguments allowed, subject to dedicated interface requirement specification.

; (semicolon) (optional) command termination - only used for compatibility to former implementations.

In addition the C&C ASCII string may be terminated by binary zero byte allowing C&C type TM Source Packets longer than the real C&C character string, padded out with zeros up to the length indicated by the packet primary header length field.

Keywords belonging to commands and arguments shall NOT be case-sensitive, thus it is allowed to use uppercase as well as lower case letters.


of 49



3.4.4.2 Keyword List

Identical actions defined upon various interfaces have to have assigned identical keywords. A list of common keywords is proposed to all C&C message network communications. The keywords listed - if applicable to a dedicated EGSE element - have to be used on all interfaces according to their definition given below. Or - alternatively - if a function listed below is required by an EGSE element, it has to be implemented using the command keyword specified. However, it is NOT mandatory to implement all listed keywords, if the function is not required in the EGSE element.

Keyword Description / Function

ACK command and control message acknowledge

APPLY request the FEE to apply a stimuli signal or pulse to a dedicated on-board unit signal line

CONTINUE continue/resume previously halted process / automated test sequence

ERROR error message displayed to the operator for information or requesting special action (to be displayed with different attributes than the nominal MESSAGE type)

GETTM specify APID and sample rate for EGSE Internal HK TM packets generated by the EGSE Front End to be routed to the command issuer

HALT halt/suspend previously started process / automated test sequence

MESSAGE message string to be displayed to the operator

NAK command and control message not-acknowledge

REPLY provides parameter value / status report requested by preceding REPORT command or other commands resulting in a response from the front end

REPORT request sending of parameter value / status report to the command issuer

RESET reset the commanded equipment to its initial status. This implies a state transition equivalent to TRANSFER local and a logical communication link (i.e. stream socket) disconnect

RESTART restart the commanded equipment, all or dedicated process

SET set parameter to value

START start a process / automated test sequence

STOP stop previously started process / automated test sequence

TEST perform EGSE self-test

TRANSFER remote partner mode transition control - arguments: remote, local

Table 3.4-5 List of Keywords


of 49



3.5 Additional Interface Requirements

3.5.1 IP address configuration

All IP addresses and socket / port numbers shall be configurable by the user. A step-by-step procedure describing IP address and port number settings shall be provided in the EGSE element user manual.

3.5.2 LAN Load

SCOE feedback data rates (EGSE TM/TC packets, C&C Messages, …) for asynchronous (non-TSP) communications over the LAN shall not be higher than 20 kbps for each SCOE.

3.5.3 Network Access

All SCOE having a controller shall support NFS (Network File System) and FTP to allow direct access from the CCS into the hard disks of the controller itself for files transfer purposes.


of 49



4 COMMON C&C MESSAGE DEFINITION

This section specifies the C&C message source packet data field contents belonging to common C&C messages according to keyword list given in section 3.4.4.2 above. The C&C source packet structure has to be implemented as defined in Section 3.4.2 above and the command syntax according to Section 3.4.4.1.

The messages outlined below belong to the CCS as well as to any EGSE.

Note: "Unsolicited C&C message issued by the EGSE" in the sections below means: the EGSE issues the C&C message on the unidirectional link (see Section 3.2) and there is no acknowledgement by the receiving side.

4.1 Remote Mode Transition Control

issued by Keyword Argument-1 Argument-2 Argument-3

CCS TRANSFER REMOTE

LOCAL

EGSE ACK

NAK

TRANSFER argument-1 as provided by command

[<NAK return status>]

"TRANSFER LOCAL" may also be issued by the EGSE.

Unsolicited C&C message issued by the EGSE:


EGSE TRANSFER LOCAL

4.2 EGSE Equipment RESET


CCS RESET

EGSE ACK

NAK

RESET


No argument to the EGSE can be provided with this command as the CCS acts on the RESET keyword by closing the TCP logical communication links. In case selective EGSE unit reset is needed, EGSE specific keyword has to be introduced (e.g. < EGSE >_RESET <unit>).


of 49



4.3 EGSE Equipment RESTART


CCS RESTART [<unit>]

EGSE ACK

NAK

RESTART [<unit>]


4.4 Automated Sequence Control


CCS

START

<test sequence name>

or

<test session name>

optional arg.2 through arg.n

Note: The number (n-1) of args supplied with the START command is recommended not to exceed 10.

The maximum length of each argument is proposed to be limited to 32 characters .

CCS

HALT

CONTINUE

STOP


or

<test session name>

- none - - none -

EGSE ACK

NAK

START

HALT

CONTINUE

STOP


or

<test session name>

<NAK return status>

The NAK status returned is an ASCII string as follows:

„not found“ - sequence specified in arg.1 does not exist „wrong argument - <arg>“ - only on START „already active“ - only on START or CONTINUE „not running“ - only on HALT or STOP „already held“ - only on HALT


of 49



4.5 Apply Stimuli


CCS

APPLY <stimuli name> ON or OFF

<pulse duration>

- none -

EGSE ACK

NAK

APPLY <stimuli name>


4.6 Set Parameter on EGSE


CCS SET <parameter-assign-1> [<parameter-assign-2>] [<parameter-assign-3>]

EGSE ACK

NAK

SET


An argument list separated by comma can be provided according to BNF notation (see also § 3.4.4.1for detailed BNF):

Note: the number of arguments supplied with the command is recommended not to exceed 10

<parameter_assig> ::= <parameter_id> = <value>


of 49



4.7 Report Request to EGSE and Reply from EGSE


CCS REPORT <parameter-id> [<parameter-id>] [<parameter-id>]

EGSE ACK

NAK

REPORT


An argument list separated by comma can be provided according to BNF notation (see also § 3.4.4.1 for detailed BNF):


<parameter-id> ::= <letter> <underscore> | <letter> | <digit>


EGSE REPLY <parameter-assign> [<parameter-assign>] [<parameter-assign>]

CCS ACK

NAK

REPLY

Responding the preceding report request an argument list separated by comma can be provided according to BNF notation (see also § 3.4.4.1for detailed BNF):


<parameter_assig> ::= <parameter_id> = <value>

4.8 C&C Message of Type ERROR and Message


CCS MESSAGE text string to be displayed to the operator - 80 char. maximum

EGSE ACK

NAK

MESSAGE


<message text> = text string to be displayed to the operator - 80 characters maximum;

Unsolicited C&C message issued by the FEE:


EGSE ERROR <unit reporting error> <error type> <error description>

EGSE Message text string to be displayed to the operator - 80 char. Maximum

<unit reporting error> = indicate the source of the ERROR message;

<error type> = dependent on the EGSE;

<error description> = text string; 80 characters maximum


of 49



4.9 EGSE Self-Test Request


CCS TEST [<unit to test>]

EGSE ACK

NAK

TEST [<unit to test>]


Self-test results can be requested for report to the CCS by REPORT TEST command:


CCS REPORT TEST <unit>

EGSE ACK

NAK

REPORT TEST <unit> or



EGSE REPLY TEST <unit> <test result>

CCS ACK

NAK

REPLY TEST <unit> or


Unsolicited C&C message issued by the EGSE:


EGSE REPLY TEST <unit> <test result>

<unit to test> = TBD by EGSE | ALL Note: ALL is default and may be omitted

In case of command from CCS is “REPORT TEST ALL“, the REPLY from the EGSE only contains one global test result indication for each unit inside the front end equipment , e.g.

"unit-1=OK,unit-2=OK,unit-3=NOK" ...etc. ( TBC. - if applicable - )

Detailed unit test reports are provided by means of unit specific REPORT requests. The contents reported within the REPLY message starting from argument-3 is to be defined by the specific equipment ICD to be provided by the EGSE supplier.


of 49



4.10 EGSE Internal HK TM Source Packet Distribution Control

EGSE internal HK TM Source Packet acquisition (see § 3.4.3) from EGSE is controlled through the CCS by means of C&C command GETTM.


CCS GETTM ON <SID> [<sample-rate>]

CCS GETTM OFF <SID>

EGSE ACK

NAK

GETTM ON

OFF

<SID> or [<NAK return status>]

<SID> = Packet Structure Identifier (see § 3.4.3 above) - value range TBD by EGSE

<sample-rate> = seconds in time - optional parameter for ON command if omitted the packet is distributed cyclically on a default time base (e.g. 10 sec).


of 49



5 EGSE SYNCHRONISATION

This section of the ICD details the methods and protocols used to synchronise Gaia EGSE times and to correlate EGSE time with the Spacecraft Elapsed Time (SCET).

5.1 Time Reference (TREF)

For Avionics Model Bench Testing (AVM) and Spacecraft AIV, the Gaia EGSE shall be synchronised to a single Time Reference (TREF). The EGSE identified for AVM and AIV includes:

• Central Checkout System (CCS)

• Avionics SCOE

• Real Time Simulator (RTS)

• TMTC SCOE

• TTC SCOE

• Power SCOE

• Star Tracker SCOE

• Dynamic FPA Simulator

• SpaceWire SCOE

• CDU SCOE The source for the Time Reference (TREF) shall be provided by the Avionics SCOE. The precision time source shall have a granularity of better than 1 us.

The Avionics SCOE shall make available IRIG-B time-coded signals to those EGSE and sub-units requiring direct synchronisation to TREF.

5.2 Time Synchronisation Methods

Two methods of time synchronisation to TREF are identified for Gaia:

1. Synchronisation by direct reception of IRIG-B time code signal.

2. Synchronisation by standard Network Time Protocol (NTP).

5.2.1 Synchronisation by Time Code Signal.

Those EGSE requiring precise (microsecond) synchronisation to TREF shall provide an interface for reception of an IRIG-B Time Coded Signal from the Avionics SCOE.

The EGSE shall accept and decode the provided IRIG-B signal and synchronise its local time to it.

5.2.2 Synchronisation by NTP.

Those EGSE requiring less-precise (sub-milliseconds) synchronisation to TREF, shall synchronise to TREF using the Network Time Protocol (NTP) service on the EGSE LAN.

The Avionics SCOE shall act as the NTP Time Server.


of 49



6 EGSE REAL TIME NETWORK

To achieve real-time performance for AOCS closed-loop testing, Gaia will implement a distributed architecture using a Real Time Network (RTN) for interconnection of the following EGSE:

• Real Time Simulator (RTS)

• Avionics SCOE

• Star Tracker SCOE (2 off)

• Dynamic FPA Simulator The Real Time Network is made up of interface cards fitted in each EGSE, connected together in a Star topology using high-speed fibre-optic links.

For Gaia, the Real Time Simulator implements the RTN using the GE Fanuc Reflective Memory Series 5565 PCI Card coupled to a GE Fanuc AC-5595 Hub.

All EGSE on the RTN shall interface to the RTN using one of the GE Fanuc Series 5565 cards available on the following form factors:

Part Number Form Factor Memory Type Capacity

PCI-5565 PCI SDRAM 64 MByte

PMC-5565 PMC SDRAM 64 MByte

VME-5565 VME SDRAM 64 MByte

CLB-5565 PCI SDRAM 64 MByte

Further details on the GE Fanuc Reflective Memory cards can be found at :

http://www.gefanucembedded.com/products/family/135/

6.1 Network Operation

Real Time Networks consist of interface cards fitted in each EGSE with an area of SDRAM (known as ReFlective Memory - RFM). Data written to one address of RFM of one card is “automatically” reflected to the corresponding RFM address of the other cards using high-speed fibre-optic connection.

The ‘Reflection’ process is automatic (requiring no software overhead) and offers typically sub-microsecond latency node-node.

The ‘Reflection’ process can be configured to operate in two ways:

• Fully automatic (on-demand) – as an RFM address on one node is written, it is immediately reflected to all other nodes.

• DMA driven – the transfer of data between nodes can be achieved using DMA transfers. This offers superior data latency performance when large areas of RFM need to be transferred.

The RTN cards can also be configured to operate an Interrupt-driven system for non-polling synchronisation.

The RTN cards support multi-platforms (PCI, PXI, VME, PMC) and multi-OS (Windows, Linux, Unix, VxWorks).


of 49



6.2 Network Synchronisation

Overall synchronisation of the RTN shall be achieved using an interrupt-driven process initiated by the Avionics SCOE.

The Avionics SCOE receives timing signals from the GAIA CDMU in the form of synchronisation mode codes transmitted on the Service Module MIL-STD-1553B data bus.

The Avionics SCOE provides synchronisation to the other EGSE on the RTN by global interrupts synchronised to the 1553 mode codes at the Central Software (CSW) Major Frame and Minor Frame control cycle rates (nominally 1Hz and 8Hz respectively).

Any EGSE requiring synchronisation to the CSW control cycle shall synchronise its timing to the RTN interrupts.


of 49



7 SYNCHRONOUS DATA ARCHIVE FILE FORMAT (RES)

This section of the ICD identifies the common file format (known as ‘RES’ file format) that shall be used by all Gaia EGSE that acquires synchronous data and archives such data to file.

Synchronous data acquisition is that data which is acquired periodically in accordance with fixed timing cycles. Such data may include:

• Data acquired by the Real Time Simulator at Simulation Cycle frequencies or multiples thereof.

• Data acquired by the Avionics SCOE synchronised to CDMU timing (PPS). It should be noted that the ‘RES’ file format may also be used for archiving asynchronous data.

The purpose of the ‘RES’ file format is to provide a means of storing large volumes of data in an efficient manner. The format relies on the fact that as data is acquired synchronously, then only limited information need be added to the file to define the time stamp of the archived data (as the data update rates are known).

All information pertaining to the data (identifiers, timing etc.) are stored only once as headers. Once configured, the file is then updated only by the raw data at the synchronous rate.

Due to its synchronous nature, separate ‘RES’ archive files are maintained for each data rate, containing all data collected at that rate.

Each ‘RES’ file shall contain a primary header field in the following format:

Field Name HEADER 1 (General Information)

Data Format “data3” 0x00 “comment1” 0x00 “comment2” 0x00 … “commentn” 0x00 0x01

Description "data3" identifies that IEEE double format is used

"comment..." fields are used to provide information about the test in progress

0x00 data byte is used to separate data within a field

0x01 data byte is used to separate fields

Each ‘RES’ file shall contain a secondary header field in the following format:

Field Name HEADER 2 (Data structure Information)

Data Format “name1” 0x00 “units1” 0x00 “name2” 0x00 “units2” 0x00 … “namen” 0x00 “unitsn” 0x00 0x01

Description "name…" identifies the Symbolic name of the data included in the archive

"units..." identifies the electrical units associated with the archive data

0x00 data byte is used to separate data within a field

0x01 data byte is used to separate fields

Next and successive fields in the ‘RES’ file shall contain the data fields:

Field Name DATA FIELDS (Archive data)

Data Format data1 data2 … datan

Description "data…" are the parameter values in the order specified in the HEADER 2 field, coded as IEEE defined 8-Byte doubles with big-endianity


of 49



Each DATA FIELD contains all data relative to one acquisition cycle at the rate specified for the ‘RES’ file.

To maintain synchronisation with all “RES” files in the archive, the first parameter (name1: data1) in each DATA FIELD shall contain the time-stamp (TREF – see Section 5.1) relative to all data in that data field.

Where the ‘RES’ file format is used to archive asynchronous data, each parameter in the DATA FIELD shall be proceeded by its corresponding time-stamp parameter.


of 49



8 EGSE TO EGSE INTERFACES

This section of the ICD details the interfaces between the different elements of the Gaia EGSE.

The EGSE to EGSE interfaces which need to be considered in the frame of this ICD are listed below:

TMTC SCOE to TTC SCOE

TMTC SCOE to Spacecraft Interface Bracket

8.1 TMTC SCOE to TTC SCOE Interface Specification

The TMTC SCOE to TTC SCOE interface is used to transfer the digital PCM (NRZ-L) TM and TC data between the equipments, as shown in Figure 2.1-1, cable identity “TMTC Bypass”.

The interface specification for TMTC signals between the TMTC SCOE and TTC SCOE shall be LVDS, as defined in SD1.

8.1.1 TMTC SCOE to TTC SCOE Cable Design

The pin functions and general cable design that shall be adopted is shown in Figure 8.1-1

The following points should be adhered to when manufacturing the cable:-

The cable and connector identifications shall be indelibly part marked in accordance with Figure 8.1-1.

The cable shall be verified for pin to pin continuity of <0.5Ω.

The cable shall be verified for pin to pin and pin to screen insulation of >10MΩ at the maximum voltage rating of the cable.

Wire used in the manufacture of the cable shall be selected to best suit the signal types defined in Section Figure 8.1-1. Where different signal types are specified, the wire best suited to those individual types shall be used. The combined wires / cables shall be sleeved to construct the overall cable.

The cable construction shall be suitably robust in order to survive the rigours of a full AIV test campaign, involving several EGSE relocations.

The wire type used for the cable construction shall be suitably flexible at ambient temperatures in order to easily lay the cable between the EGSE elements.

If multiple preformed wires/cables are combined in the construction of the overall cable, they should be lay twisted between 150mm and 300mm (dependant on wire/cable type), in order to form a manageable cable.


of 49



8.1.1.1 Telemetry Interface from TTC SCOE to TMTC SCOE

The telemetry data interface is utilised for the transmission of Telemetry Channel Acquisition Data Units (CADUs) from the TTC SCOE to the TMTC SCOE. The telemetry CADU’s are received by the TTC SCOE from the on-board RF subsystem downlink. The RF downlink is demodulated by the TTC SCOE in order to recover the digital PCM (NRZ-L) TM data which is then transferred to the TMTC SCOE for further processing.

8.1.1.1.1 EGSE Telemetry Line

The cable telemetry interface shall consist of two Lines:

One Telemetry data line (issued by the Satellite) which transmits the encoded telemetry in serial form

One Telemetry clock line which transmits the clock signal for the Telemetry data line

8.1.1.2 Telecommand Interface from TMTC SCOE to TTC SCOE

The Telecommand data interface is utilised for the transmission of the Telecommand Command Link Transfer Units (CLTU) from the TMTC SCOE to the TTC SCOE. The Telecommand CLTU digital PCM (NRZ-L) data is received by the TTC SCOE where it is modulated on to the RF uplink for transmission to the on-board RF subsystem.

8.1.1.2.1 EGSE Telecommand Lines

The cable telecommand interface shall consist of three lines: One Telecommand data line (issued by the TMTC SCOE) which transmits the CLTU data in serial

form One Telecommand clock line (issued by the TMTC SCOE) which transmits the clock signal for the

Telecommand data line One Telecommand enable line (issued by the TMTC SCOE) which forces the command decoder to

ignore any other Telecommand input except the Telecommand signal


of 49



15m ± 100mm

1 1 HD44-male As defined by TMTC SCOE subcontractor2 1 HD44-female As defined by TMTC SCOE subcontractor

ITEM QTY. PART NO. DESCRIPTION

2

2423

TM_CLOCK_TTC.true

J-C

4 A/R TBC LVDS IMPEDANCE MATCHED CABLE

1

2019

4443

1514

1312

X-BandTTC

TM_CLOCK_TTC.comp

TM_DATA_TTC.trueTM_DATA_TTC.comp

TC_CLOCK_TTC.trueTC_CLOCK_TTC.comp

TC_DATA_TTC.trueTC_DATA_TTC.comp

TC_ENABLE_TTC.trueTC_ENABLE_TTC.comp

DA

TE:

Title: TMTC SCOE HARNESSTM/TC X-Band Interface Cable

(TMTC SCOE to TTC SCOE &TEST)

CHECKED BY:

APPROVED BY:

DWG NODRAWN BY:

Mod

ifica

tion

Sta

tus

ISS

:D

ATE

:

DATE SHEET

DA

TE:

DA

TE:

DA

TE:

ISS

:IS

S:

ISS

:IS

S:

05/0

6/07

1A

DT-0000000 29/06/07 1 of 2

98

TM_CLOCK_SIM_OUT.true 54

2625

3029

2827

TM_CLOCK_SIM_OUT.comp

TM_DATA_SIM_OUT.trueTM_DATA_SIM_OUT.comp

3216

CABLE_ID_2INTERFACE_GROUND

screen / backshell

Location: GAIA TTC SCOE

Location: TMTC SCOERear Panel Interface

4

EXT_TM_CLOCK_SIM_IN.trueEXT_TM_CLOCK_SIM_IN.comp

TC_CLOCK_ECHO.trueTC_CLOCK_ECHO.comp

TC_DATA_ECHO.trueTC_DATA_ECHO.comp

TC_ENABLE_ECHO.trueTC_ENABLE_ECHO.comp

4241

J-C X-BandTTC

TM/TC X-BandD0000000

3

1m ± 50mm

3 1 HD44-male As defined by TMTC SCOE subcontractor

2423

2019

4443

1514

1312

2423

2019

4443

1514

1312

16

16

2625

Figure 8.1-1 TMTC SCOE to TTC SCOE Cable


of 49



8.2 TMTC SCOE to Spacecraft Interface Bracket

The TMTC Digital Bypass cable is used to interface the digital PCM (NRZ-L) TM and TC signals between the TMTC SCOE and the Spacecraft Interface Bracket, as shown in Figure 2.1-1, cable identity “TM/TC Bypass”.

The digital TM/TC bypass signals are routed directly to the CDMU (bypassing the on-board RF subsystem) via the satellite umbilical interface.

8.2.1 TMTC SCOE to Spacecraft Interface Bracket Cable Design

The interface specification for TMTC signals between the TMTC SCOE and Spacecraft Interface Bracket shall be LVDS, as defined in SD1

The pin functions and general cable design that shall be adopted is shown in Figure 8.2-1.

The following points should be adhered to when manufacturing the cable:-

The cable and connector identifications shall be indelibly part marked in accordance with Figure 8.2-1.

The cable shall be verified for pin to pin continuity of <0.5Ω.

The cable shall be verified for pin to pin and pin to screen insulation of >10MΩ at the maximum voltage rating of the cable.

The cable construction shall be suitably robust in order to survive the rigours of a full AIV test campaign, involving several EGSE relocations.

The wire type used for the cable construction shall be suitably flexible at ambient temperatures in order to easily lay the cable between the EGSE elements.

If multiple preformed wires/cables are combined in the construction of the overall cable, they should be lay twisted between 150mm and 300mm (dependant on wire/cable type), in order to form a manageable cable.

8.2.1.1 Telemetry Interface from Spacecraft Interface Bracket to TMTC SCOE

The telemetry data interface is utilised for the transmission of Telemetry Channel Acquisition Data Units (CADUs) from the CDMU to the TMTC SCOE. The telemetry CADU’s are received from the CDMU as digital PCM (NRZ-L) TM data.

8.2.1.1.1 EGSE Telemetry Line

The cable telemetry interface shall consist of two Lines:

One Telemetry data line (issued by the Satellite) which transmits the encoded telemetry in serial form

One Telemetry clock line which transmits the clock signal for the Telemetry data line

8.2.1.2 Telecommand Interface from TMTC SCOE to Spacecraft Interface Bracket

The Telecommand data interface is utilised for the transmission of the Telecommand Command Link Transfer Units (CLTU) from the TMTC SCOE to the CDMU as digital PCM (NRZ-L) data.


of 49



8.2.1.2.1 EGSE Telecommand Lines

The cable telecommand interface shall consist of three lines: One Telecommand data line (issued by the TMTC SCOE) which transmits the CLTU data in serial

form One Telecommand clock line (issued by the TMTC SCOE) which transmits the clock signal for the

Telecommand data line One Telecommand enable line (issued by the TMTC SCOE) which forces the command decoder to

ignore any other Telecommand input except the Telecommand signal


of 49



15m ± 100mm

1 2 HD44-male As defined by TMTC SCOE subcontractorITEM QTY. PART NO. DESCRIPTION

2

2423

TM_CLOCK_PRI.true

J-A

300 ±25mm

3 A/R TBC LVDS IMPEDANCE MATCHED CABLE

1

J-A

J-B

2019

4443

1514

1312

SA113

J-B

TM_CLOCK_PRI.comp

TM_DATA_PRI.trueTM_DATA_PRI.comp

TC_CLOCK_PRI.trueTC_CLOCK_PRI.comp

TC_DATA_PRI.trueTC_DATA_PRI.comp

TC_ENABLE_PRI.trueTC_ENABLE_PRI.comp

DA

TE:

Title: TMTC SCOE HARNESSTM/TC Bypass Interface Cable

(TMTC SCOE to Spacecraft Interface Bracket)

CHECKED BY:

APPROVED BY:

DWG NODRAWN BY:

Mod

ifica

tion

Sta

tus

ISS

:D

ATE

:

DATE SHEET

DA

TE:

DA

TE:

DA

TE:

ISS

:IS

S:

ISS

:IS

S:

05/0

6/07

1A

DT-0000000 29/06/07 1 of 2

116


2423

TM_CLOCK_RED.true 2019

4443

1514

1312

TM_CLOCK_RED.comp

TM_DATA_RED.trueTM_DATA_RED.comp

TC_CLOCK_RED.trueTC_CLOCK_RED.comp

TC_DATA_RED.trueTC_DATA_RED.comp

TC_ENABLE_RED.trueTC_ENABLE_RED.comp

3116


screen / backshell

screen / backshell

Location: GAIA SpacecraftAIT Interface Bracket

Location: TMTC SCOERear Panel Interface

3

TM/TC BypassD0000000

2423

2019

4443

1514

1312

2423

2019

4443

1514

1312

SA113TM/TC-P

SA114TM/TC-3

300 ±25mm

2 2 HD44-female As defined by TMTC SCOE subcontractor

16

16

Figure 8.2-1 TM/TC Bypass to Power SCOE Cable


of 49



9 APPENDIX 1: CONVENTIONS

9.1 Bit Numbering and Byte Order Conventions

If not specified otherwise within this document, the following bit numbering and byte order conventions shall apply:

Bit numbering convention according to ESA standards:

− The most significant bit (MSB) within a bit array is identified as Bit 0. − The least significant bit (LSB) within a bit array of length = n bits is identified as Bit n-1. − A byte defines an 8-bit data structure with the MSB = bit 0 and the LSB = bit 7. − A word defines a 16-bit data structure with the MSB = bit 0 and the LSB = bit 15. − If an n-bit field is to be interpreted as "Unsigned Integer" value, bit-0 is the MSB and bit n-1 is the LSB. − If an n-bit field is to be interpreted as "Signed Integer" value, bit-0 indicates the sign with bit-0 = 0

corresponding to a positive number and bit-0 = 1 corresponding to a negative number. The value of a negative number is represented by the two’s complement (e.g. minus one (-1) = 1 111 1111bin for an eight bit wide signed number field).

Byte order convention:

Within one word the most significant byte (i.e. bit 0 through bit 7) is stored on the lower memory byte address and is transmitted first, whereas the least significant byte of a word (i.e. bit 8 through bit 15) is stored on the higher memory byte address and is transmitted last. This definition is known as the „Big Endian“ implementation.

9.2 Representation of Floating Point Numbers

Floating point numbers provided within EGSE internal House-Keeping telemetry source packet for monitoring and processing within the TMTC SCOE system are expected to conform to 32-bit binary single precision floating point representation according to IEEE 754 briefly described below:

1 8 23 bits

Sign Exponent Mantissa

The sign is the sign of the number. The sign of the exponent is built into the representation of the exponent value. The mantissa is the detail of the number, while the exponent represents the magnitude. The IEEE standard specifies that the sign of the number is 1 for negative and 0 for positive. The sign of the exponent is integrated into the value of the exponent. The representation of the exponent involves "excess n" notation. That means that the value stored as the exponent is actually n + the true value of the exponent. This makes it easier to sort floating point numbers by forcing very negative exponents to have low values. In single precision floating point numbers, n is 127.

The mantissa stores the significant figures of the number. Since every normalized binary floating point number starts with a 1 (except for true zero), the 1 is redundant and need not appear. The arithmetic processing logic assumes a 1 in that position. Some very small numbers also do without the understood 1 before the mantissa bits.

An exponent of all 1 bits has special significance and is treated as the mathematical entity infinity.


of 49



10 APPENDIX 2: PROJECT SPECIFIC PARAMETERS

APID

(HEX)

Process ID

(decimal)

Pkt Category

(decimal)

Pkt

Type

Application Section

Reference

70C 112 12 TC Command and Control Message 3.4.4

701 112 01 TC Command and Control ACK/NAK Message 3.4.4

711 113 01 TM TC ACK/NAK Message & Verify by TMTC SCOE 3.4.2

714 113 04 TM Housekeeping TM from TMTC SCOE 3.4.3

724 114 04 TM Housekeeping TM Real Time Simulator 3.4.3

734 115 04 TM Housekeeping TM from Avionics SCOE 3.4.3

744 116 04 TM Housekeeping TM from Power/Pyro SCOE #1 3.4.3

754 117 04 TM Housekeeping TM from TTC SCOE 3.4.3

764 118 04 TM Housekeeping TM from Star Tracker SCOE #1 3.4.3

774 119 04 TM Housekeeping TM from Star Tracker SCOE #2 3.4.3

784 120 04 TM Housekeeping TM from Power/Pyro SCOE #2 3.4.3

794 121 04 TM Housekeeping TM from CDU SCOE 3.4.3

7A4 122 04 TM Housekeeping TM from Dynamic FPA Simulator 3.4.3

7BC 123 12 TC PLM EGSE: SpaceWireFE C&C Message 3.4.4

7B1 123 01 TC PLM EGSE: SpaceWireFE C&C ACK/NACK Message 3.4.4

7B4 123 04 TM PLM EGSE: SpaceWireFE Housekeeping TM 3.4.3

7CC 124 12 TC PLM EGSE: MIL/PFE/Discrete FE C&C Message 3.4.4

7C1 124 01 TC PLM EGSE: MIL/PFE/Discrete FE C&C ACK/NACK Message

3.4.4

7C4 124 04 TM PLM EGSE: MIL/PFE/Discrete FE Housekeeping TM 3.4.3

7D4 125 04 TM Not allocated 3.4.3

7E4 126 04 TM Not allocated 3.4.3


of 49



INTENTIONALLY BLANK


of 49



DOCUMENT CHANGE DETAILS

ISSUE CHANGE AUTHORITY CLASS RELEVANT INFORMATION/INSTRUCTIONS

1 - Initial Issue

2 - Added APID assignment in Appendix 2

3 - Added TSP to Section 3

Section 3.4.3 – Moved SID to byte-offset 0 in EGSE TM HK packet

Moved Section 3.4.2 – EGSE Synchronisation – to new Section 5 and updated to reflect Gaia Synchronisation architecture

Added Section 6 – Real Time Network Configuration

Added Section 7 – RES File Format

Added Section 8.1 and 8.2 (TMTC SCOE/EGSE Interfaces)

Updated APID assignments in Appendix 2

4 - Updated to Gaia Standard document format

Additions to the TSP specification

5

GAIA.ASU.ECO.ESM.00007

- Change to signatory list

Section 3.4: TM Verification Report for TC Acknowledgment from TMTC SCOE now includes Source ID for both ACK and NACK messages.

Updated Section 8.1 and 8.2 – TMTC Signals are now LVDS

6 GAIA.ASU.ECO.ESM.00022 - Figure 2.1-1 Updated to show connection of CDU SCOE to EGSE LAN and external IRIG-B time code.

Updated APID assignments in Appendix 2 (CDU SCOE added)

7 GAIA.ASU.ECO.ESM.00060 - Updates to TMTC SCOE interface cables (Section 8)

Added 2nd Power SCOE APID (Appendix 2)

DISTRIBUTION LIST

INTERNAL EXTERNAL

C.G. Catley (Stevenage) C. Bertona (Toulouse) Dutch Space (CADM)

M. Ali (Stevenage) F. Verges (Toulouse) SSBV (CADM)

S. King (Stevenage) C. Gabilan (Toulouse) Siemens Austria (CADM)

D. Perkins (Stevenage) Configuration Management

EGSE INTERFACE CONTROL DOCUMENT - ESAemits.sso.esa.int/emits-doc/ASTRIUMLIM/GAIA_DynFS/GAIA... ·...

Documents

Transcript of EGSE INTERFACE CONTROL DOCUMENT - ESAemits.sso.esa.int/emits-doc/ASTRIUMLIM/GAIA_DynFS/GAIA... ·...