Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 1 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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 2 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
INTENTIONALLY BLANK
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 3 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 4 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 5 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 6 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 7 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 8 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 9 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 10 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 11 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 12 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 13 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 14 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 15 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 16 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 17 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 18 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 19 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 20 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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):
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 21 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 22 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 23 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 24 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 25 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 26 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 27 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 28 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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:
issued by Keyword Argument-1 Argument-2 Argument-3
EGSE TRANSFER LOCAL
4.2 EGSE Equipment RESET
issued by Keyword Argument-1 Argument-2 Argument-3
CCS RESET
EGSE ACK
NAK
RESET
[<NAK return status>]
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>).
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 29 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
4.3 EGSE Equipment RESTART
issued by Keyword Argument-1 Argument-2 Argument-3
CCS RESTART [<unit>]
EGSE ACK
NAK
RESTART [<unit>]
[<NAK return status>]
4.4 Automated Sequence Control
issued by Keyword Argument-1 Argument-2 Argument-3
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
<test sequence name>
or
<test session name>
- none - - none -
EGSE ACK
NAK
START
HALT
CONTINUE
STOP
<test sequence name>
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 30 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
4.5 Apply Stimuli
issued by Keyword Argument-1 Argument-2 Argument-3
CCS
APPLY <stimuli name> ON or OFF
<pulse duration>
- none -
EGSE ACK
NAK
APPLY <stimuli name>
[<NAK return status>]
4.6 Set Parameter on EGSE
issued by Keyword Argument-1 Argument-2 Argument-3
CCS SET <parameter-assign-1> [<parameter-assign-2>] [<parameter-assign-3>]
EGSE ACK
NAK
SET
[<NAK return status>]
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>
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 31 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
4.7 Report Request to EGSE and Reply from EGSE
issued by Keyword Argument-1 Argument-2 Argument-3
CCS REPORT <parameter-id> [<parameter-id>] [<parameter-id>]
EGSE ACK
NAK
REPORT
[<NAK return status>]
An argument list separated by comma can be provided according to BNF notation (see also § 3.4.4.1 for detailed BNF):
Note: the number of arguments supplied with the command is recommended not to exceed 10
<parameter-id> ::= <letter> <underscore> | <letter> | <digit>
issued by Keyword Argument-1 Argument-2 Argument-3
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):
Note: the number of arguments supplied with the command is recommended not to exceed 10
<parameter_assig> ::= <parameter_id> = <value>
4.8 C&C Message of Type ERROR and Message
issued by Keyword Argument-1 Argument-2 Argument-3
CCS MESSAGE text string to be displayed to the operator - 80 char. maximum
EGSE ACK
NAK
MESSAGE
[<NAK return status>]
<message text> = text string to be displayed to the operator - 80 characters maximum;
Unsolicited C&C message issued by the FEE:
issued by Keyword Argument-1 Argument-2 Argument-3
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 32 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
4.9 EGSE Self-Test Request
issued by Keyword Argument-1 Argument-2 Argument-3
CCS TEST [<unit to test>]
EGSE ACK
NAK
TEST [<unit to test>]
[<NAK return status>]
Self-test results can be requested for report to the CCS by REPORT TEST command:
issued by Keyword Argument-1 Argument-2 Argument-3
CCS REPORT TEST <unit>
EGSE ACK
NAK
REPORT TEST <unit> or
[<NAK return status>]
issued by Keyword Argument-1 Argument-2 Argument-3
EGSE REPLY TEST <unit> <test result>
CCS ACK
NAK
REPLY TEST <unit> or
[<NAK return status>]
Unsolicited C&C message issued by the EGSE:
issued by Keyword Argument-1 Argument-2 Argument-3
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 33 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
issued by Keyword Argument-1 Argument-2 Argument-3
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).
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 34 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 35 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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).
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 36 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 37 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 38 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 39 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 40 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 41 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 42 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
Maximum Fault Voltage Tolerance: -1V to +8V Emission: 0V to +5V
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%
Maximum Fault Voltage Tolerance: -1V to +8V Emission: 0V to +5V
Table 8.1-2 Telecommand Interface Electrical Characteristics
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 43 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
Figure 8.1-1 Timing Diagram of Clock, Data and Enable signal
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 44 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
Figure 8.1-2 TMTC SCOE to TTC SCOE Cable
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 45 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 46 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 47 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 48 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
Figure 8.2-2 TM/TC Bypass to Power SCOE Cable
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 49 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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.
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 50 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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
784 120 04 TM Not allocated 3.4.3
794 121 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
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 51 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
INTENTIONALLY BLANK
GAIA.ASU.SP.ESM.00001 Issue 4 Revision 00
Date: 11/01/2007 Page 52 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.
GAIA-ASU-ICD-ESM-00001 (EGSE ICD Iss4).doc
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