egse interface control...

GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00

Date: 11/01/2007 of 52

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

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

EGSE INTERFACE CONTROL DOCUMENT

CI CODE: 13000 DRL REFS:

DTI EXPORT CONTROL RATING: Not Listed Rated by:

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 / S.J. Amos 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


Date: 11/01/2007 of 52

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


Date: 11/01/2007 of 52



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.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 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 ..................................................................................18

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

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

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


Date: 11/01/2007 of 52



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

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

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

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

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

8 EGSE TO EGSE INTERFACES .........................................................................................................39 8.1 TMTC SCOE to TTC SCOE Interface .............................................................................................39

8.1.1 TMTC SCOE to TTC SCOE Cable Design..........................................................................39 8.1.2 Cable Signal Details ............................................................................................................40

8.2 TMTC SCOE to Power SCOE Interface..........................................................................................45 8.2.1 TM/TC Bypass cable design................................................................................................45 8.2.2 Cable Signal Details ............................................................................................................46

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

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


Date: 11/01/2007 of 52



TABLES

Table 3.1-1 OSI Reference Model.................................................................................................................10 Table 3.4-1 Primary Header Packet Identification.........................................................................................18 Table 3.4-2 TM Application Data Field for "TC ACK/NACK & TC Verification Report"...................................19 Table 3.4-3 Packet Data Field - Examples.....................................................................................................21 Table 3.4-4 Command and Control Message Structure..................................................................................22 Table 3.4-5 List of Keywords .........................................................................................................................26 Table 8.1-1 Telemetry Interface Electrical Characteristics..............................................................................41 Table 8.1-2 Telecommand Interface Electrical Characteristics.....................................................................42 Table 8.2-1 SBDL Driver Specification............................................................................................................47 Table 8.2-2: SBDL Receiver specification.......................................................................................................47

FIGURES

Figure 2.1-1 Generic GAIA EGSE Configuration .............................................................................................9 Figure 3.2-1 TC Handshake Mechanism.......................................................................................................16 Figure 8.1-1 Timing Diagram of Clock, Data and Enable signal ...................................................................43 Figure 8.1-2 TMTC SCOE to TTC SCOE Cable .............................................................................................44 Figure 8.2-1 SBDL Link ...................................................................................................................................46 Figure 8.2-2 TM/TC Bypass to Power SCOE Cable .......................................................................................48


Date: 11/01/2007 of 52



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.

• 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 ESA Packet Telemetry Standard ESA-PSS-04-106

RD2 ESA Packet Telecommand Standard ESA-PSS-04-107

RD3 Ground Systems and Operations – TM & TC PUS ECSS-E-70-41, Draft 5.1


Date: 11/01/2007 of 52



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

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

MMI Man-Machine Interface

N/A Not Applicable

NAK Not-Acknowledge

NDIU Network Data Interchange Unit

NTP Network Time Protocol

OGSE Optical Ground Support Equipment

PC Personal Computer


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



2 GENERAL DESCRIPTION

All units forming the GAIA EGSE interface with each other via the EGSE Local Area Network (LAN).

2.1 Generic EGSE Configuration

The diagram in Figure 2.1-1 shows all EGSE elements and front end units and how they are interconnected. The diagram shows a generic EGSE configuration, which may be amended according to the needs of the actual test phase.

FPASpacecraftInterfaceB

racket

CDMUTTL

TRIG

EGSEREAL-TIMENETWORKCN1002

Power/PyroSCOE

PCDU

Avi

onic

s S

CO

E

PDHU

STR1

STR2

Battery Power Prime

Cen

tral

Che

ckou

tS

yste

m (C

CS

)

PowerController

DynamicFPA

Simulator

AvionicsModel TestBench(AVM)

VPU1-7

CDU

CPS nom

LGA-2

LGA-1

STR1

STR2

GYRO 1

CDUSCOE

OpticalStim SCOE

PLM

155

3

EGSELAN

Payload Module (PLM)Service Module (SVM)

111

SolarArray

Simulator

Majority VoterTest Interface

TMTCSCOE

Star TrackerSCOE #1

Real-TimeSimulator

CDMUSim

ERC32Emulation

CSW

SpaceWire x2(A/B)

MIL-STD-1553B x2

(A/B) RT/BM

EIU nom

uPropulsion nom

SREM

SpW

OSE

MDE

107

Um

bilic

al R

ack

X807

DR0101

DR0102

DR0111

DR0103DR0104DR0105DR0106

DR0402

DR0604

DR0607

DR0701

DR0702

DR0801

DR0802

DR1101

DR1102

DR1701

DR1702

DR1801

DR1802

Test Cap

EGSE SupplierFurnished Cables

AstriumFurnished Cables

BatterySimulator

Battery ChargePower Supply DR0117

Offline Battery Charge/Discharge Interface

Star TrackerSCOE #2

Battery Power RedundantBattery Signals (Prime/Redundant/AIV)

108

Pyro Signals Prime

Pyro Signals Redundant

MV Test Interface

SAS FSA PrimeSAS FSA Redundant

SAS DSA PrimeSAS DSA Redundant

Umbilical #1

Umbilical #2

103104105106

101

102

615

624-625

634

637

701

702

801

802

EGSE Configuration for GAIA

Issue: 9

Date: 10th January 2007

LCL Sim#1LCL Sim#2

DR0605 616-619DR0606 620-623

DR0608 626-627

CDMU (ALARMS/PPS)

EIU (SHP ACQ/GEN)

DR0803 DR1803803

DR

0804

LGA-2 Test

LGA-1 Test

PAA-Reference

PAA-Test Port Inputs (24x)

EIU Discrete (RSA)

629DR0610

FSS HWIL

635636

DR0620

DR0625DR0624

DR0626

DR0622

DR0627

SV

M 1

553

Transponder #1

Transponder #2

PAA

PacketWire

SpW

SpaceWire

DR1625

DR1627

DR1624

DR1626

CDMU/EIUCDMU/PDHS

SVM PrimeSVM Redundant

PLM PrimePLM Redundant

804 -827

CentralArchive

Disc

PacketWire x4(A/B)

PPS (EGSE 1Hz)

Dat

atio

n IR

IG-B

GYRO 3

MPE red

uPropulsion red

EIU red

CPS red

Gyro HWILSREM Simulation

T T

T

T

BCBC

RT

RT

RT

RT

RT

RT

RT

RT

RT

RT

RT RT

RT

RT

RT

CLO

CK

S

Test Cap

Test Cap

PYRO/NED

GYRO 1 RT

BATTERY

DR0107

DR0114DR0115DR0116

DR0108

LoadSimulator #1

LoadSimulator #2

DR0112

DR0113

DR1111

DR1103DR1104DR1105DR1106

DR1107DR1108

BUS SupportPower Supply #1

Umbilical Monitor

BUS SupportPower Supply #2

BDR Auto-restart INH

Separation Strap Sim

TMTC BypassPW

SpW

DR0109DR0110

109110

NED Signals Prime

NED Signals RedundantDR1109DR1110

BATTERY

BUS Performance Test Interface112 DR1112

DR0607

DR0609

DR0605

DR0606

DR0608631

633

628

630

632

DR0604 610

612-614DR0605 611DR0605

DR0604DR0605DR0604

604-607608609

DR0604 603

MPS-rdt (FCV/PT/Gaz Flow)

MPS-rdt (LV/Status)MPS-nom (FCV/PT/Gaz Flow)

MPS-nom (LV/Status)

CPS-rdt (FCV/PT)CPS-rdt (LV/Status)CPS-nom (FCV/PT)

CPS-nom (LV/Status)

MPE nom RT

CDMU (SHP)

FSS 1

FSS 2

FSS 3

FSS SIM

TTCSCOE

EIU Discrete (Analog Sim)EIU Discrete (Bi-level TM)

DR1604DR1605DR1606

DR1610

DR1603

DR1604

DR1607

DR1605DR1606

DR1603

DR1603DR1603DR1603

DR1603DR1603

DR1603

PowerSimulation

DR0601DR0602

DR1607DR1608D

iscr

ete

Dat

a I/O

MPS

EIU

EIU/CPS

CDMU

Timing &Synch

EIU/FSS

GyroSREM

DR

0804

Pyro/NEDSimulator

DR0401TM/TC Bypass

TM/TC X-Band

PLM

EG

SE

PowerFront End

SpaceWireFront EndEquipment

(Link & Monitor)

MIL-1553BFront End

BC/BMD

iscr

ete

Fron

t End

Equ

ipm

ent

AnalogInput

SHPGen

LVDS

Figure 2.1-1 Generic GAIA EGSE Configuration


Date: 11/01/2007 of 52



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 1: The physical layer is responsible for the transmission of raw data over a communication medium.

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 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 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 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 6: The presentation layer manages the representation of information that application layer entities either communicate or reference in their communication.

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

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.


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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 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 uni-directional 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


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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, will instantly receive a TC acknowledgement message from the 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 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


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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 on a Network Attached 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 at rates of >100Hz) of (mainly) synchronous data using 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. The specifications and source drivers for TSP can be located at:

http://savannah.nongnu.org/projects/tsp For Gaia, EGSE required to archive synchronous data shall implement the TSP protocol to Version 0.8.2.

All TSP providers shall provide sampled data values in the order at which they were requested by the TSP consumer.

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).

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

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


Date: 11/01/2007 of 52



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. In addition the TM/TC telecommand buffer status is reported and in case of not acknowledge (NAK service (1,130)) an error code gives the reason for the failure.

TC Packet Id

TC Sequence Control

Code only if NAK (1,130)

Source ID Error Code

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


Date: 11/01/2007 of 52



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):


Date: 11/01/2007 of 52



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 Descrip-tion

<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.


Date: 11/01/2007 of 52



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’s 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


Date: 11/01/2007 of 52



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’s 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.


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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 SCOEs 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.


Date: 11/01/2007 of 52



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 uni-directional 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>).


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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>


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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).


Date: 11/01/2007 of 52



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 Platform EGSE shall be synchronised to a single Time Reference (TREF). The Platform 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 (included as it is part of the AVM configuration) 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

Three 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.


Date: 11/01/2007 of 52



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).


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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 Power SCOE

EGSE Real-Time Network Interfaces (TBD)

8.1 TMTC SCOE to TTC SCOE Interface

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

The Telemetry and Telecommand signals are further detailed in the following paragraphs.

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-2

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-2.

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

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 Figure 8.1-2. 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.


Date: 11/01/2007 of 52



8.1.2 Cable Signal Details

The cable will be required to carry signals with the characteristics detailed in subsequent paragraphs. The relevant signal types are shown in Figure 8.1-2.

8.1.2.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.2.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 (EMD)

One Telemetry clock line which transmits the clock signal for the Telemetry data line (EMC)

8.1.2.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.2.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 (ETD or Data) One Telecommand clock line (issued by the TMTC SCOE) which transmits the clock signal for the

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

ignore any other Telecommand input except the Telecommand signal (ETE or Enable)

8.1.2.3 Signal Type A

Type A signals will be RFSCOE_TM, which have characteristics as detailed in Table 8.1-1

8.1.2.4 Signal Type B

Type B signals will be RFSCOE_TC, which have characteristics as detailed in Table 8.1-2

8.1.2.5 EGSE Telecommand Timing

The EGSE Telecommand timing shown in Figure 8.1-1, is not necessary for the cable design, but is included for information.


Date: 11/01/2007 of 52



INTERFACE DATA SHEET

I/F Designation: TTC SCOE Telemetry I/F Code: RFSCOE_TM

SOURCE CIRCUIT SPECIFICATION

Electrical Characteristics Complementary Driver (according to RS-422)

Transfer DC Coupled

Output Voltage Levels Low: 0V to 0.55V High: 2.45 to 5V (Values given for the ‘true’ line; the ‘complementary’ line shall have complementary levels

Rise/Fall Time <100ns when connected to a differential load of 3 kOhm paralleled with 30pF

Maximum Fault Voltage Tolerance: -1V to +8V Emission: 0V to +5V

RECEIVER CIRCUIT SPECIFICATION

Electrical Characteristics Receiver according to RS-422

Transfer DC Coupled

Differential Input Voltage Range Low: -1V High: +1V

Zero Reference Driver ground

Input Impedance 120 Ohm ± 5%

Maximum Fault Voltage Tolerance: -1V to +8V Emission: 0 to +5V

Table 8.1-1 Telemetry Interface Electrical Characteristics


Date: 11/01/2007 of 52



INTERFACE DATA SHEET

I/F Designation: TTC SCOE Telecommand I/F Code: RFSCOE_TC

SOURCE CIRCUIT SPECIFICATION

Electrical Characteristics Complementary Driver (according to RS-422)

Transfer DC Coupled

Bit Rate 4000 bps

Output Voltage Levels Low: 0V to 0.55V High: 2.45 to 5V

(Values given for the ‘true’ line; the ‘complementary’ line shall have complementary levels

Rise/Fall Time <100ns when connected to a differential load of 3

kOhm paralleled with 30pF


RECEIVER CURCUIT SPECIFICATION

Electrical Characteristics Receiver according to RS-422

Transfer DC Coupled

Differential Input Voltage Range Low: -1V

High: +1V

Zero Reference Driver ground

Input Impedance 120 Ohm ± 5%


Table 8.1-2 Telecommand Interface Electrical Characteristics


Date: 11/01/2007 of 52



Figure 8.1-1 Timing Diagram of Clock, Data and Enable signal


Date: 11/01/2007 of 52



Figure 8.1-2 TMTC SCOE to TTC SCOE Cable


Date: 11/01/2007 of 52



8.2 TMTC SCOE to Power SCOE Interface

The TMTC Digital Bypass cable is used to interface the digital PCM (NRZ-L or SPL) TM and TC signals between the TMTC SCOE and the Power SCOE, as shown in Figure 2.1-1, cable identity DR0401A.

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

The Power SCOE is utilised as the most convenient point to route the TM/TC bypass signals into the satellite Umbilical interface. No processing of the bypass signals is done by the Power SCOE.

8.2.1 TM/TC Bypass cable design

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

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-2.

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

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.


Date: 11/01/2007 of 52



8.2.2 Cable Signal Details

The cable will be required to carry signals with the characteristics detailed in subsequent paragraphs. The signal types are shown in.

8.2.2.1 Signal Type A

Type A signals will be SBDL, which have characteristics as detailed in Paragraph 8.2.2.2.

8.2.2.2 Standard Balanced Digital link (SBDL)

The SBDL link interface is dedicated to serial digital links or synchronisation signals. This link is based on the RS422 standard, with specific details given in Table 8.2-1 and Table 8.2-2. The SBDL Link interface is shown in Figure 8.2-1.

DRIVER RECEIVER

Signal GND Signal GND

TRUE

COMP

Vsupp Vsupp

Ros

Ros

Ris

Ris

Fault Volt. Prot. (as required)

Rp

Cp

Figure 8.2-1 SBDL Link

Although the line is symmetrical the two wires are identified as true line and complementary line.

The true line is the non-inverted output of the driver.

The complementary line is the inverted output of the driver.

The status (Vdiff = Vtrue - Vcomp) of the signal is defined High (Logic “1”) when the true line has a positive « 1 » level w.r.t the ground and the complementary line has a« 0 » level versus the ground.

The low level of the SBDL (logic “0”) is conversely when the true line has a « 0 » level and the complementary line has a « 1 » level.


Date: 11/01/2007 of 52



INTERFACE DATA SHEET Page 1 / 2

IF Designation: Standard Balanced Digital Link IF-Code: SBDL

Req Driver Circuit Specification Ver. Iss.

-1 Circuit type: CMOS RS422 line driver (complementary outputs) Recommendation : HS-26C/CT/CLV31 RH ESD class 1

-2 Transmission Type: Differential -3 Diff. output volt. Logic "0" (1): -5.5 V ≤ Vod ≤ -1.75 V -4 Diff. output volt. Logic "1" (1): +1.75 V ≤ Vod ≤ +5.5 V -5 Source impedance: 120 Ohm ± 5% incl. driver source impedance and

series resistors (for 120 Ohm line adaptation)

-6 Rise and Fall time (2): tr, tf ≤ 20 ns for Tb >200ns, otherwise 0.1xTb -7 Short circuit current: Short circuit proof, max: 150 mA (each terminal to ground) -8 Leakage current < 100 µA -9 Common mode output < 3V -10 Fault voltage emission (3): 0 V to + 7 V A -11 Fault voltage tolerance: -0.5 V to +7 V (through 1 KOhm) A -12 OFF state tolerance: OFF transmitter shall withstand an ON receiver even with

failure

-13 ON state tolerance: ON transmitter shall withstand an OFF receiver

Table 8.2-1 SBDL Driver Specification

INTERFACE DATA SHEET Page 2 / 2 IF Designation: Standard Balanced Digital Link IF - Code: SBDL Req Receiver Circuit Specification Ver. Iss. - 14 Circuit type: Differential CMOS RS422 line receiver

Recommendation : HS - 26C/CT/CLV32 RH ESD class 1

- 15 Fail - safe: Receiver shall detect a static logic “1” level when inputs are in open circuit condition

- 16 Input impedance (4): DC: > 6 KOhm incl. input series resistors

AC: 120 Ohm in series with 50 pF

- 17 Diff. input level Logic “0” - 10 V ≤ Vid ≤ - 0 .6 V - 18 Diff. input level Logic “1” +0.6V ≤ Vdiff ≤ +10V - 19 Common mode range: - 4V ≤ V ≤ +7V - 20 Fault voltage emission (3): - 0.5V to +7V (through 1 KOhm) A - 21 Fault voltage tolerance: - 12V ≤ Vdiff ≤ +12V A - 22 OFF - state tolerance: OFF receiver shall withstand an ON transmitter even with

failure

- 23 ON - state tolerance: ON receiver shall withstand an OFF transmitter Harness Specification - 24 Wiring Type (5): Twisted Shielded Pair (TSP) R - 25 Shielding: As detailed in Figure 1-3 R Notes:

(1) With load 6 KOhm; however, driver circuit shall provide +/ - 1.8V min when loaded with 100 Ohms assuming no output series resistors (2) With load 120 Ohm. (3) Special attention has to be paid to failure modes of the int erface circuit power supply. (4) Proposed input series resistors (Ris): 1 KOhm ± 1% (5) or TwinAx (TCX) (120 Ohm balanced shielded lines acc. ESA/SCC 3902/002)

Table 8.2-2: SBDL Receiver specification


Date: 11/01/2007 of 52



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


Date: 11/01/2007 of 52



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.


Date: 11/01/2007 of 52



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 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 3.4.3

774 119 04 TM Not allocated 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


Date: 11/01/2007 of 52



INTENTIONALLY BLANK


Date: 11/01/2007 of 52



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

DISTRIBUTION LIST

INTERNAL EXTERNAL

List Names

C.G. Catley (Stevenage)

M. Ali (Stevenage)

S.J. Amos (Stevenage)

S. King (Stevenage)

D. Perkins (Stevenage)

Configuration Management