EADS - SWARN - EGSE Specifications: Requirements

SWARM
Doc-No: SW-RS-EAD-EG-0001 Issue: 0 Date: 25.02.2006
Title: EGSE Specification - Global EGSE Requirements -

CI - No: 0000
DRL Refs : D-AV12
Prepared by: T.Schuler Date:
Checked by:
Product Assurance:
Project Management:
Distribution: See Distribution List last page
Copying of this document, and giving it to others and the use or communication of the
contents there-of, are forbidden without express authority. Offenders are liable to the EADS Astrium GmbH
payment of damages. All rights are reserved in the event of the grant of a patent or the D-88039 Friedrichshafen
registration of a utility model or design.
EADS Astrium ENS, Friedrichshafen Page 1

File: SW-RS-EAD-EG-0001_issue-0_EGSE_Spec.doc
SWARM
Issue Date Sheet Description of Change Release

Draft-0 25.02.2005 all initial issue
0 xx.xx.2006 all first formal issue

SWARM Doc. No: SW-RS-EAD-EG-0001
Issue: 0
EGSE Specification
Date: 25.02.2006
Table of Contents
Page
1. Introduction ..................................................................................................2
1.1. Scope .......................................................................................................................... 2
1.2. Purpose ....................................................................................................................... 2
1.3. Terms and Definitions ................................................................................................ 3
1.4. References .................................................................................................................. 4
1.4.1. Applicable Documents .................................................................................... 4
1.4.2. Reference Document ....................................................................................... 4
1.4.3. Standards ......................................................................................................... 4
1.5. List of Acronyms ........................................................................................................ 5
2. EGSE Configurations and Usage ................................................................7

2.1. EGSE Configurations ................................................................................................. 7
2.1.1. Software Verification Facility (SVF) .............................................................. 7
2.1.2. Real-Time Testbed (RTB)............................................................................... 8
2.1.3. Satellite Testbed (STB) or Flat-Sat ............................................................... 10
2.1.4. Satellite EGSE............................................................................................... 11
2.1.5. Launch Site EGSE......................................................................................... 12
2.1.6. RF-Suitcase ................................................................................................... 13
2.2. EGSE Usage ............................................................................................................. 14
2.2.1. Use of EGSE Components ............................................................................ 14
2.2.2. Number of EGSE Sets / Simultaneous S/C Operation .................................. 14
2.2.3. EGSE Evolution ............................................................................................ 16
3. EGSE Building Blocks / EGSE Components ...........................................18

3.1. Central Check-out System (CCS) / Core EGSE ....................................................... 18
3.2. Satellite Reference Database (SRDB) ...................................................................... 20
3.3. TM/TC Front End..................................................................................................... 20
3.4. Power Front-End Equipment .................................................................................... 21
3.5. S-Band SCOE ........................................................................................................... 21
3.6. Power SCOE............................................................................................................. 23
3.6.1. Solar Array Simulator (SAS) SCOE ............................................................. 23
3.6.2. Launch Power Supply (LPS) SCOE.............................................................. 24
3.7. O/B S/W Load & Dump Station............................................................................... 25
3.8. Simulation Front End................................................................................................ 26
3.9. Spacecraft Environment Simulator / Real-Time Simulator ...................................... 26
3.10. OBC Simulator ......................................................................................................... 26
4. Communication Requirements .................................................................27

4.1. Function Requirements............................................................................................. 27
EADS Astrium ENS, Friedrichshafen Page B-i

Issue: 0
EGSE Specification
Date: 25.02.2006
4.1.1. Command and Control .................................................................................. 27

4.1.2. Requirements for Communication with CCS ................................................ 28
4.1.3. Log Files Management .................................................................................. 30
4.1.4. HK TM Archive Files Management.............................................................. 31
4.2. Interface Requirements............................................................................................. 32
5. Implementation Requirements..................................................................34
5.1. General ..................................................................................................................... 34
5.2. Lifetime .................................................................................................................... 34
5.3. Safety........................................................................................................................ 34
5.4. Cleanliness................................................................................................................ 35
5.5. Parts & Materials ...................................................................................................... 35
5.6. Maintainability & Reliability.................................................................................... 35
5.7. Interchangeability & Replaceability ......................................................................... 36
5.8. Transportation & Container...................................................................................... 36
5.9. Environment ............................................................................................................. 37
5.10. Ergonomy ................................................................................................................. 38
5.11. Mechanical & Thermal Design................................................................................. 39
5.12. Electrical & EMC ..................................................................................................... 40
5.13. Software Design & Development............................................................................. 44
5.14. Workmanship ........................................................................................................... 45
5.15. Identification & Marketing ....................................................................................... 45
6. Verification Requirements.........................................................................47
EADS Astrium ENS, Friedrichshafen Page B-ii

Issue: 0
EGSE Specification
Date: 25.02.2006
ToC - Figures & Tables
Page
Figure 2-1 SVF............................................................................................................................. 7
Figure 2-2 RTB ............................................................................................................................ 8
Figure 2-3 extended RTB ............................................................................................................. 9
Figure 2-4 STB........................................................................................................................... 10
Figure 2-5 Satellite EGSE .......................................................................................................... 11
Figure 2-6 Launch Site EGSE .................................................................................................... 12
Figure 2-7 RF Suitcase ............................................................................................................... 13
Figure 2-8 static SVF configurations ......................................................................................... 16
Figure 2-9 EGSE evolution ........................................................................................................ 17
Figure 3-1 CCS Schematic ......................................................................................................... 18
Figure 3-2 CCS Links ................................................................................................................ 19
Figure 3-3 TM/TC Front End Equipment Block Diagram ......................................................... 20
Figure 3-4 S-Band SCOE Blockdiagram ................................................................................... 22
Figure 3-5 Power SCOE basics .................................................................................................. 23
Figure 3-6 Solar Array Simulator (SAS) SCOE......................................................................... 24
Figure 3-7 LPS SCOE ................................................................................................................ 25
Figure 4-1 EGSE LAN Topology using unshielded Cable ........................................................ 32
Figure 4-2 EGSE LAN Topology using Fibre Optics ................................................................ 32
Figure 5-1 EGSE Grounding Schematics................................................................................... 41
Figure 5-2 Software Layers........................................................................................................ 44
Figure 5-3 Harness Identification - Example ............................................................................. 46
Table 2-1 EGSE Components Usage ........................................................................................ 14

Table 2-2 EGSE Components to procure.................................................................................. 15
Table 4-1 EGSE LAN IP Addresses ......................................................................................... 33
EADS Astrium ENS, Friedrichshafen Page B-iii

Issue: 0
EGSE Specification
Date: 25.02.2006
1. Introduction
1.1. Scope
This specification establishes a baseline for the Swarm Electrical Ground Support Equipment (EGSE).
1.2. Purpose
The purpose of this specification is to define the common requirements applicable to all Electrical Ground Support
Equipment (EGSE) used in the various configurations constituted during Swarm development, AIT and AIV. Thus,
this specification is conceived as a higher level applicable document to all EGSE items, the CCS, the Front Ends /
SCOEs and instrument specific EGSE.
Unless explicitly expressed by name, all requirements outlined in the dedicated requirement sections below belong
to any SCOE and Front End Equipment as well as any Instrument EGSE1. Both, SCOE and Instrument EGSE are
referred to as Front End Equipment (FEE) as they are both considered front ends from the CCS point of view.
The requirements also apply to the CCS in so far as the CCS interfaces the functions / capabilities required by the
Front End Equipment.
Chapter 1 this chapter, referenced project documents and referenced standards.

Chapter 2 gives an overview on the various EGSE configurations to be set up to support the different Swarm
simulation, AIT / AIV and Launch Site configurations and highlights the number of items required to
establish all these configurations.
Chapter 3 introduces the basic configurations and requirements of the different EGSE components.
Chapter 4 identifies global EGSE functional and interface requirements subject to the communication with the CCS.
Chapter 5 specifies global EGSE implementation and design requirements.
Requirements Identification:
Technical requirements given in this specification which are to be subjected to compliance statement and formal
verification control are identified within the text by using a formal formatting scheme. Each requirement has a
headline identifying the requirement ba a paragraph number , a keyword or short description and a proposed /
preferred verification method. Underneath this headline the requirement wording (and figures) are given. In some
cases the requirement is complemented by a comment or descriptive text. A comment is separated by horizontal
lines and has italic letters.
<para-n> <keyword> / [<verification method>]

<para-n> a consecutive number related to the current paragraph
<keyword> requirement short description
[Ref:] optional ident. to be used, if the requirement is a pointer to an applicable document
<verification method> optional verification method
TE Test,
AN Analysis,
RoD Review of Design,
INS Inspection,
nt not to be tracked.
Not to be tracked means that this requirement shall not be subject to formal verification
control. Nevertheless it shall be understood as contractually binding requirement. The
texts marked as comment or descriptive are not contractually binding but for information
only.
1 for term definition see 1.3 below.

Issue: 0
EGSE Specification
Date: 25.02.2006
1.3. Terms and Definitions
AIT/AIV Data Base Database containing all definitions for all data structures (TM/TC packets,
TM/TC parameters, monitoring definitions, calibration curves, limit sets, e.t.c)
subject to the spacecraft and all EGSE Front End / SCOE units.
Automated Procedure Test program (application) written by the user in a high level command
language to control the execution of a test. Contains statements to send
commands to the spacecraft and to other EGSE items and to process the
telemetry and other data coming from the S/C and other EGSE items.
(synonym: Test Sequence, Control File)
C&C Message ASCII data structure replacing the entire source packet "Application Data
Field" of a standard TC Source Packet. These packets are used to exchange
commands and feedback data between the CCS and SCOEs / Front End
Equipment.
Feedback Data Data from a SCOE representing either measurement data from the spacecraft
or data directly measured at a dedicated spacecraft interface.
Instrument EGSE is defined to be an instrument science data acquisition and processing unit
usually derived from the dedicated instrument unit test equipment re-used at
higher level EGSE configurations, commanded and controlled via the CCS.
MDVE constituted by development configurations in their early stages using pure S/W
simulation models for the S/C and the unit(s) under test (e.g. the SVF having
no hardware in the loop). In a next step hardware in the loop is used (e.g. the
on-board processor) whereas other units are still represented by software
simulation models (e.g. the RTB operating at least the real on-board processor
hardware connecting its real physical and electrical interfaces via the
Simulation FE and simulating the spacecraft environment by means of the
RTS). S/C EGSE not involving simulators (i.e. not making use of "models"
and not used for "Development" of on-board SW) are not considered member
of the MDVE philosophy.
SCOE Set of (electronic, magnetic, optical, etc.) equipment to stimulate and/or
simulate the S/Cs interfaces like sensors and actuators and/or other units (e.g.
sun, batteries, ...)
Script A list of procedure language commands stored in an ASCII disk file. During a
Test Session a script can be called by file name and the commands contained
are interpreted and executed sequentially (similar to DOS batch file).
Stimuli Commands Command to a SCOE to execute a stimulation of a spacecraft interface.
Structure Identifier Field within the "Application Data Field" of a TM/TC Source Packet
identifying the data structure provided with this packet.
TC Source Packet Packet according to \SD1\ "ESA Packet Telecommand Standard" for
commanding the spacecraft.
Test Environment Contains the executables of all (user-) data to conduct a test. It mainly
comprises a configuration specific sub-set of AIT/AIV Data Base data for the
spacecrafts actual as-built-configuration, the relevant automated procedures
and synoptics.
Test Session running a test at "Run-Time" using a dedicated Test Environment.
TM Source Packet Packet according to \SD2\ "ESA Packet Telemetry Standard" providing
housekeeping data either from the spacecraft or from any other SCOE / Front
End Equipment.

Issue: 0
EGSE Specification
Date: 25.02.2006
1.4. References
1.4.1. Applicable Documents
\AD1\ EGSE Interface Control Document SW-ID-EAD-EG-0001
1.4.2. Reference Document
\RD1\ Swarm Packet Utilisation Standard SW-ID-EAD-SY-000x

\RD2\ CGS V6 Specification CGS-RIBRE-SPE-0001
\RD3\ CCS Requirements Specification SW-RS-EAD-EG-0002
\RD4\ GMFE Requirements Specification SW-RS-EAD-EG-0003
\RD5\ S-Band SCOE Requirements Specification SW-RS-EAD-EG-0007
\RD6\ Solar Array Simulator (SAS) Power SCOE SW-RS-EAD-EG-0005
Requirements Specification
\RD7\ Launch Power Supply (LPS) SCOE SW-RS-EAD-EG-0006
Requirements Specification
1.4.3. Standards
\SD1\ ESA Packet Telecommand Standard ESA PSS-04-107

\SD2\ ESA Packet Telemetry Standard ESA PSS-04-106
\SD3\ Ground Systems and Operations ECSS-E-70-41
Telemetry and Telecommand Packet Utilization
\SD4\ Space Engineering - Verification ECSS-E-10-02A

Issue: 0
EGSE Specification
Date: 25.02.2006
1.5. List of Acronyms

A FEE Front End Equipment
ACK Acknowledge FID Failure Identifier / Failure Code
AD Applicable Document FM Flight Model
AFT Abbreviated Functional Test FMECA Failure Modes Effects & Criticality
AIT Assembly Integration and Test Analysis
AIV Assembly, Integration and Verification FPT Full Performance Test
AOCS Attitude and Orbit Control Subsystem
G
API Application Programming Interface
GSE Ground Support Equipment
APID Application Process Identifier ->
GUI Graphical User Interface
CCSDS Packet Primary Header Field
H
B
H/W Hardware
BER Bit Error Rate
HCI Human Computer Interface (-> MMI)
BNF Backus-Naur Form
HK House-Keeping
bps bits per second
BPSK Binary Phase Shift Keying I
I/F Interface
C
ICD Interface Control Document
CADU Channel Access Data Unit
ID Identifier
C&C Command and Control
IP Internet Protocol
CCS Central Checkout System == Core
IST Integrated System Test
EGSE
CCSDS Consultative Committee for Space J
Data Systems
K
CDR Critical Design Review
kbps 210 Bits per second
CFE Customer Furnished Equipment
CLCW Command Link Control Word L
CLTU Command Link Transmission Unit LAN Local Area Network
CMD Command LCL Latch Current Limiter
COP Command Operation Procedure LPS Launch Power Supply
COTS Commercial Of The Shelf LOL Limit of Liability
CPDU Command Pulse Distribution Unit LSB Least Significant Bit
CPU Central Processor Unit
CRC Cyclic Redundancy Check M
CUC CCSDS Unsegmented time Code Mbps 220 Bits per second
CVCDU Coded VCDU MDVE Model based Development and
Verification Environment
D MGSE Mechanical Ground Support
DBMS DataBase Management System Equipment
DC Direct Current MLI Multi-Layer Insulation
dB deci Bel MMI Man-Machine Interface (-> HCI)
dBc dB related to center frequency MSB Most Significant Bit
dBm dB related to 1 mW MTBF Mean Time between Failure
DFH Data Field Header
DSU Data Switching Unit N
N/A Not Applicable
E NAK Not-Acknowledge
ECSS European Cooperation for Space NDIU Network Data Interchange Unit
Standardization NRZ Non Return to Zero
EGSE Electrical Ground Support Equipment NTP Network Time Protocol
EID Error or Event Identifier
EM Engineering Model O
EMC Electromagnetic Compatibility OBC On-Board Computer
ESA European Space Agency OBDH On-Board Data Handling
OCOE Overall Checkout Environment ==
Core EGSE
F
FCL Foldback Current Limiter P

Issue: 0
EGSE Specification
Date: 25.02.2006
P/L Payload SRR System Requirements Review

PA Product Assurance STM Structural/Thermal Model
PCB Printed Circuit Board SVF Software Verification Facility
PCM Pulse Code Modulation
T
PCU Power Control Unit
TBC To be confirmed
PDU Power Distribution Unit
TBD To be defined
PFM Proto-Flight Model
TC Telecommand
PID Process Identifier
TCP Transmission Control Protocol
PLL Phase Lock Loop
TCS Thermal Control Subsystem
PLM Payload Module
TES Test Execution System
PUS Packet Utilisation Standard
TM Telemetry
Q TTC Tracking, Telemetry & Command
QM Qualification Model TX Transmitter
QPSK Quadrature Phase Shift Keying
U
QR Qualification Review
UART Universal Asynchronous Receiver
R Transmitter
RD Reference Document UQPSK Unbalanced Quadrature Phase Shift
RF Radio Frequency Keying
RHCP Right Hand Circular Polarisation USO Ultra Stable Oscillator
RID Report Identifier UTC Universal Time Coordinated
RID Review Item Discrepancy
V
RMS Root Mean Square
VC Virtual Channel
RS Reed-Solomon
VCDU Virtual Channel Data Unit
RX Receiver
VCID Virtual Channel Identifier
S VCO Voltage Controlled Oscillator
S/C Spacecraft
W
S/S Subsystem
w/o without
S/W Software
SAS Solar Array Simulator X
SCOE Special Check-Out Equipment
Y
SDR System Design Review
SFT System Functional Test Z
SOL Switch-Off Line
SRDB Satellite Reference Database

Issue: 0
EGSE Specification
Date: 25.02.2006
2. EGSE Configurations and Usage
2.1. EGSE Configurations
2.1.1. Software Verification Facility (SVF)

The Software Verification Facility (SVF) is the initial configuration constituted by the Modelbased Development
and Verification Environment (MDVE) which can be regarded as a substitute for a satellite Engineering Model.
The SVF consists of the following components as shown in Figure 2-1 below.
the S/C Environment Simulator which simulates all satellite equipment - with the exception of the OBC and
its Application Software - as well as the satellite dynamics and environment,
the On-Board Processor Simulator having integrated the current version of the OBC Application Software
the CCS acting as major test processor in the MDVE configurations as in satellite AIT configurations.
The SVF is capable to perform closed-loop tests in simulated real time. In addition it provides software debugging
features like breakpoints.
On-Board Computer Simulator
On-Board SW
(incl. AOCS SW)
Equipment Models
OBC HW
Model
Simulator I/F
S/C & Environment Simulator

Simulator I/F
Environment Models
Space S/C
e.t.c.
Simulation Environment Dynamics
Models
DB Equipment Models
Sensor Actuator Subsystem
e.t.c.
Models Models Models
LAN
CCS
Satellite I/F Handler
Reference CCS
Database AIT CCS MMI
(SRDB) DB Kernel
Test Result Database EGSE_Configurations.vsd/SVF
Figure 2-1 SVF

Issue: 0
EGSE Specification
Date: 25.02.2006
2.1.2. Real-Time Testbed (RTB)

In the RTB the On-Board Processor Simulator is replaced by the real on-board processor hardware, usually a OBC
breadboard or the OBC EM (see Figure 2-2 below). This hardware is linked to the Spacecraft Environment
Simulator /Real-Time Simulator (RTS) via the Simulator Front End. All harness lines signals to/from the OBC are
converted to interface data for the RTS. On the OBC hardware the current version of OBC basic software and OBC
Application software are integrated. The RTB is capable to do real time testing but provides not debugging
features.
OBC BB -> EM
Telecommand Mass
Decoder Memory
DC/DC Telemetry RS422, UART, SW Load

RS422 Discrete I/O A/D, D/A
Converter Encoder I/F
PL Science Data
TM Bypass
TC Bypass
Power
external I/F Unit &

LCL/FCL
TM/TC Baseband S/C (Avionics)
Emulation
Processor HW Interfaces
Simulator I/F
S/C / Avionics
Simulation FE
Power FE TM/TC FE Simulator I/F
Environment Models
Equipment Models O/B SW
Load & Dump
S/C & Environment / Real-Time Station (TE)
Simulator
EGSE LAN
CCS
Reference CCS
(SRDB) DB Kernel
EGSE_Configurations.vsd/RTB Test Result Database
Figure 2-2 RTB

An evolution of the RTB having additional spacecraft EM units integrated is called "extended RTB" (eRTB) and it
supports the functions specified for the "Software Development and Verification Environment" (SDVE). The basic
layout of the eRTB is outlined in Figure 2-3 below.

Issue: 0
EGSE Specification
Date: 25.02.2006
Test Harness
OBC BB -> EM
tbd. Telecommand Mass
STR
Decoder Memory
tbd. Electronics
GPS
Heads DC/DC Telemetry RS422, UART, SW Load
RS422 Discrete I/O A/D, D/A
Converter Encoder I/F
PL Science Data
TM Bypass
TC Bypass
Power
STR LCL/FCL
external I/F Unit &
TM/TC Baseband
S/C (Avionics)
Emulation
OGSE Processor HW Interfaces
Simulator I/F S/C / Avionics
Simulation FE
Power FE TM/TC FE Simulator I/F
Environment Models
Equipment Models O/B SW
Load & Dump
S/C & Environment / Real-Time Station (TE)
Simulator
LAN
CCS
Reference CCS
MMI
Database AIT CCS
DB Kernel
(SRDB)
EGSE_Configurations.vsd/eRTB Test Result Database
Figure 2-3 extended RTB

Issue: 0
EGSE Specification
Date: 25.02.2006
2.1.3. Satellite Testbed (STB) or Flat-Sat

The satellite PFM AIT starts with the test configuration called Satellite Test Bed (STB) or Flat-Sat. In the STB the
satellite equipment and subsystems hardware is on a table-top setup not mechanically integrated. A test harness and
the satellite EGSE are in use. This configuration provides convenient access to electrical connectors. The STB
develops successively when more flight equipment is integrated. The final STB setup having all spacecraft units
integrated is outlined in Figure 2-4 below.
table-top-setup / Test-Harness GPS
ACC
EFI
STR ASM
Battery AOCS Electronics ASC
PCDU S-Band OBC Sensors
(EM) VFM
Heads
Power
S-Band RF
TM Bypass
TC Bypass
Measurement &
Sense Lines
PL Science
Data
TC
TM
external OVP / OCP

RF Matching Unit STR
Solar-Array
TX RX
OGSE
Simulation external I/F Unit &
Modulator Demod.
28V TM/TC Baseband
28V
Battery Test & Measurement Processor
Main-Bus
Charge Equipment
Power Supply Instr.
Power Supply
EGSE
O/B SW
Power S-Band Load & Dump
Station (TE) Instrument EGSE
SCOE SCOE Equipment
TM/TC FE details t.b.d.
C&C
C&C
C&C
TM
C&C
TC
LAN
CCS
Reference CCS
(SRDB) DB Kernel
EGSE_Configurations.vsd/STB Test Result Database
Figure 2-4 STB

Issue: 0
EGSE Specification
Date: 25.02.2006
2.1.4. Satellite EGSE

After having the spacecrafts integrated on the S/C structure with the flight harness, the Satellite EGSE evolves from
the STB. The EGSE configuration remains unchanged as shown in Figure 2-5 whereas the spacecraft flight units are
moved to the S/C structure forming the integrated satellite.
Spacecraft GPS
ACC
EFI
STR ASM
AOCS Electronics ASC
Battery PCDU S-Band OBC Sensors VFM
Heads
TM Bypass
TC Bypass
S-Band RF
Measurement &
Sense Lines
PL Science
Power
Data
TC
TM
O/B SW
Load & Dump
external OVP / OCP
RF Matching Unit Station (TE)
Solar-Array
Simulation TX RX STR
Modulator Demod. external I/F Unit &
28V
28V TM/TC Baseband OGSE
Battery Test & Measurement Processor
Main-Bus
Charge Equipment
Power Supply Instr.
Power Supply
EGSE
TC TM
Power S-Band I/F to NDIU Instrument EGSE
SCOE SCOE (provided by ESOC) Equipment
TM/TC FE details t.b.d.
C&C
C&C
C&C
TM
C&C
TC
LAN
CCS
Reference CCS
(SRDB) DB Kernel
EGSE_Configurations.vsd/SAT Test Result Database
Figure 2-5 Satellite EGSE

Issue: 0
EGSE Specification
Date: 25.02.2006
2.1.5. Launch Site EGSE

For the launch the Launch Power Supply (LPS) SCOE and the TM/TC Front End will be placed close to the
satellites in an under-table room. They are controlled from the CCS located in far distance via extended EGSE
LAN. These three EGSE building blocks form the so-called "Launch Site EGSE". Depending on the launch site
capabilities, fibre optic links may be used to connect the CCS and the EGSE equipment located in the under-table
room. The NDIU, which also will be located in the under-table room, will allow ESOC to listen-in TM. Provided all
three Swarm satellites are launched with a single launcher, three sets of the Launch Configuration EGSE as shown
in Figure 2-6 below will be required.
Spacecraft
Battery PCDU OBC
TM Bypass
TC Bypass
Measurement &
Power
Sense Lines
Umbilical
Interfaces
external OVP / OCP external I/F Unit &

28V TM/TC Baseband
28V Processor
Battery
Main-Bus
Charge
Power Supply
Power Supply
TM
Power I/F to NDIU
(provided by ESOC)
SCOE
TM/TC FE
C&C
TM
C&C
TC
LAN
CCS
Reference CCS
(SRDB) DB Kernel
EGSE_Configurations.vsd/LEG Test Result Database
Figure 2-6 Launch Site EGSE

Issue: 0
EGSE Specification
Date: 25.02.2006
2.1.6. RF-Suitcase
For ground system S-Band transmitter and receiver verification a RF Suitcase configuration will be provided as
shown in Figure 2-7 below.
Payload
TM S-Band
S-Band RF-Link Ground
HK TM
OBC (EM) Station
Transponder RX / TX
TC
TM Bypass
TC Bypass
Power
Power
external I/F Unit &
LCL/FCL
TM/TC Baseband
Emulation
Processor
Power FE TM/TC FE
C&C
C&C
TM
TC
LAN
CCS
Reference CCS
CCS MMI
Database AIT
(SRDB) DB Kernel
EGSE_Configurations.vsd/RFS Test Result Database
Figure 2-7 RF Suitcase

Issue: 0
EGSE Specification
Date: 25.02.2006
2.2. EGSE Usage
2.2.1. Use of EGSE Components
SVF RTB STB SAT Launch RF-

& EGSE Site Suit-
eRTB EGSE case
2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6
CCS X X X X X X
TM/TC FE - X X X X X
Power FE - X - - - X
S-Band SCOE - - X X - -
Power SCOE - SAS - - X X - -
Power SCOE - LPS - - X X X -
O/B S/W Load Station - X X X - -
S/C Simulation FE - X - - - -
S/C Environment Sim / RTS X X - - - -
On-Board Computer Sim X - - - - -
Instrument EGSEs - - X X - -
STR OGSE - - X X - -
Table 2-1 EGSE Components Usage
2.2.2. Number of EGSE Sets / Simultaneous S/C Operation

The number of EGSE identified below and the resulting number of EGSE building blocks needed to constitute them
is based on the assumption that at the utmost two spacecraft have to be operated in parallel at different locations or
during simultaneous S/C operation.
Depending on the launch scenario (i.e. "hot launch" - S/Cs powered at launch / "cold launch" - S/Cs off at launch) a
different number of Launch Site EGSE is required. In case of "hot launch", which is the baseline, three sets of
Launch Site EGSE are required to power and supervise all three satellites on the launcher simultaneously. In case of
"cold launch" one Launch Site EGSE could be considered sufficient maintaining and powering the spacecrafts
sequentially. (Note: two sets of Launch Site EGSE are available anyway).
Config # Remark
SVF 3 SVF #1 - located at O/B S/W developer / sub-contractor
SVF #2 - located at ISVV sub-contractor
SVF #3 - located with RTB
RTB & eRTB 1 generic EGSE configuration
RF Suitcase 1 no dedicated hardware; temporary use of RTB and CCS from SVF-3
STB 1 generic EGSE configuration
SAT-EGSE 3 Satellite EGSE #1 - constituted by STB
Satellite EGSE #2 - integrate at different location, operate two S/C simultaneously
Satellite EGSE #3 - reduced EGSE, S-Band SCOE shared, No SAS SCOE

Launch Site EGSE 3 derived from Satellite EGSE #1 to #3
For simultaneous S/C operation it has to be clarified with ESOC whether or not one NDIU can interface up to three
TM/TC FE. If this is not the case, two NDIU would be required for simulataneous S/C operation and up to three
NDIU in Launch Site configuration.
The Table 2-1 below identifies the number of EGSE components needed to constitute the EGSE configurations
identified above taking into account their need during development, test and integration.

Issue: 0
EGSE Specification
Date: 25.02.2006
On-Board Computer Simulator

S/C Environ Simulator / RTS
O/B S/W Load Station
EGSE
S/C Simulation FE
Pwr SCOE - SAS
Instrument EGSE
Pwr SCOE - LPS
Components
S-Band SCOE
STR OGSE
TM/TC FE
Power FE
CCS
EGSE
Configurations
SVF-1 1 0 0 0 0 0 0 0 1 1 0 0
SVF-2 1 0 0 0 0 0 0 0 1 1 0 0
SVF-3 1 0 0 0 0 0 0 0 1 1 0 0
RTB 1 1 1 0 0 0 1 1 1 0 0 0
recruited from RTB
eRTB X X X 0 0 0 X X X 0 0 tbd. + GPS + STR + tbd.
recruited from RTB & SVF-x
RF-Suitcase X X X 0 0 0 0 0 0 0 0 0 (SVF CCS used for launch support)
STB 1 1 0 1 1 1 1 0 0 0 tbd. 1
Satellite-EGSE-1 X X 0 X X X X 0 0 0 X X recruited from STB
Satellite-EGSE-2 1 1 0 1 1 1 1 0 0 0 tbd. 1
reduced EGSE configuration:
S-Band SCOE & O/B S/W Load PC shared
Satellite EGSE 3 1 1 0 X 0 1 X 0 0 0 0 0 with Sat EGSE-1 or -2 as needed
no SAS SCOE will be provided for this
configuration
Launch Site EGSE-
X X 0 0 0 X 0 0 0 0 0 0 recruited from Sat-EGSE-1
1
Launch Site EGSE-
2
Launch Site EGSE-
3
total 7 4 1 2 2 3 3 1 4 3 0 2
Legende: 1 EGSE item to procure

EGSE item re-used from other
X configuration
0 EGSE item NOT used in configuration
Table 2-2 EGSE Components to procure

Issue: 0
EGSE Specification
Date: 25.02.2006
2.2.3. EGSE Evolution

Some of the EGSE configurations identified above are established once and exist for the whole project duration.
These are mainly the SVF configurations SVF-1, SVF-2 and SVF-3 outlined in Figure 2-8.
CCS SVF-1 CCS SVF-2

(SVF Config.) (SVF Config.)
OBC Sim SVF-1 OBC Sim SVF-2
(Gaisler ERC32) (Gaisler ERC32)
Simulation PC 1 Simulation PC 2
(Linux PC) (Linux PC)
S/C Environment S/C Environment
/ Real-Time Sim / Real-Time Sim
CCS SVF-3
(SVF Config.)
OBC Sim SVF-3
(Gaisler ERC32)
Simulation PC 3
(Linux PC)
S/C Environment
/ Real-Time Sim
Figure 2-8 static SVF configurations

Other configurations are subject to evolution. In particular this applies to the RTB. From the RTB the RF Suitcase is
derived and the RTB evolves to the "extended RTB" (eRTB) supporting the "Software Development and
Verification Environment" (SDVE) running additional spacecraft hardware in the loop. Together with the SVF-3
associated to the RTB it will provide SVF, RTB, as well as RF Suitcase capabilities during S/C launch preparation
activities taking place at ESOC.
The Satellite EGSE configuration "Sat EGSE 3" will not be fully equipped with SCOEs. Its main purpose will be
to form a third Launch Site EGSE. S-Band SCOE and auxiliary equipment such as the S/W load PC will have to be
shared with other EGSE configurations, mainly "Sat EGSE 1" and "Sat EGSE 2", as needed. A SAS SCOE will not
be available in this configuration. The evolution of these EGSE configurations is shown in Figure 2-9.

Issue: 0
EGSE Specification
Date: 25.02.2006
CCS Sat-0
(Satellite Config.)
CCS Sat-0 CCS Sat-0 CDMU
(Satellite Config.) CDMU (Satellite Config.) CDMU TM/TC FE EM
EM EM Set-0
TM/TC FE TM/TC FE
Set-0 Set-0 RTB &
Power FE
eRTB
Launch
RTB &
Power FE RF-Suitcase Support
eRTB
EGSE
Simulation FE RF-Suitcase
Power FE
Simulation FE
tbd Real-Time Sim
S-Band
HW in the VME / VXworks tbd
Real-Time Sim Transponder
loop HW in the S-Band
VME / VXworks
loop Transponder
OBC S/W Load
OBC S/W Load PC Set-3
PC Set-3
CCS Sat-1 CCS Sat-1 CCS Sat-2 CCS Sat-2

(Satellite Config.) (Satellite Config.) (Satellite Config.) (Satellite Config.)
TM/TC FE TM/TC FE TM/TC FE TM/TC FE

Set-1 Set-1 Set-2 Set-2
S-Band SCOE S-Band SCOE

Set-1 STB & Set-2
Launch Site Sat Launch Site
Sat
EGSE 1 EGSE 2 EGSE 2
LPS SCOE EGSE 1 LPS SCOE
LPS SCOE LPS SCOE
Set-1 Set-1 Set-2 Set-2
SAS SCOE SAS SCOE

Set-1 Set-2
OBC S/W Load OBC S/W Load

PC Set-1 PC Set-2
CCS Sat-3 CCS Sat-3

(Satellite Config.) (Satellite Config.)
TM/TC FE TM/TC FE
Set-3 Set-3
Sat Launch Site
EGSE 3 EGSE 3
S-Band SCOE
Set-1 or Set-2
Usage shared between
Satellite EGSE Set-1 or Set-2 LPS SCOE LPS SCOE
and Satellite EGSE Set-3 as Set-3 Set-3
needed
OBC S/W Load
PC Set-1 or 2
Figure 2-9 EGSE evolution

Issue: 0
EGSE Specification
Date: 25.02.2006
3. EGSE Building Blocks / EGSE Components

The sections below outline the basic capabilities applied to the EGSE building blocks identified ba the various
configurations above. The exhaustive requirements specifying functional, performance, operational, and interface
needs are given within the dedicated equipment requirements specifications referenced in 1.4.2 (this document).
3.1. Central Checkout System (CCS) / Core EGSE

The Central Checkout System (CCS) is conceived as a standard element for integration and testing of various
different scenarios. Its main constituents are:
the computer hardware
the commercial of the shelf software
the checkout kernel software
the interface software
The latter two elements form the kernel checkout system where the CCS kernel is specified in \RD2\ and the EGSE
communication protocol is defined in \AD1\. Requirements subject to Swarm specific hardware and performance
issues are defined in \RD3\. A sketch of a CCS is outlined in Figure 3-1.
CCS
DB
AIT/AIV C&C Pkt exchange
TM/TC
Population DB
EGSE LAN to FE / SCOE / Instr. EGSE

FE HK TM Pkts
S/C TM Pkts
Site LAN
CCS TC Echo Pkts

Kernel
Operator
Workstation S/C TC Pkts
Engineering Data
TRDB Control
Test Data
retrieved
TRDB S/C TM Pkts
forwarding to Instrument EGSE
Raw Data
Test Data TC Echo Pkts

forwarding to Instrument EGSE
Archive
Figure 3-1 CCS Schematic
The CCS is suited to command and monitor in real-time the test specimen (S/C- unit, subsystem or system) and all
EGSE elements for the real or simulated space segment (MDVE / SVF) during all relevant steps of the specimen
integration and testing.
The CCS generates and process TM and TC data in compliance to the following standards:
ESA Packet Telecommand Standard
ESA Packet Telemetry Standard
ESA ECSS PUS Standard tailored to Swarm
The CCS allows to perform the following main functions in parallel
Test preparation functions
Structuring and populating the satellite/mission database
Generating and editing Automated Procedures
Preparing Synoptic Pictures

Issue: 0
EGSE Specification
Date: 25.02.2006
Test Environment Definition functions

Configuration Reporting and Control
Test Execution functions
Start-up of a Test Session
Execution of Automated Procedures
Generation and sending of telecommands
Continuous monitoring of S/C telemetry
Provision of system parameters for monitoring of the CCS
Commanding and monitoring of other EGSE elements
Distribution of TM/TC packets to other EGSE elements
Archiving of all test relevant data
Test retrieval and evaluation functions
The CCS includes at least the following components:
the spacecraft AIT/AIV database application
the synoptic picture preparation environment
the automated procedure preparation environment
the test environment definition utility
the test execution software
the archive subsystem
the timing services
the test evaluation software
the Interface Software
The CCS provides configuration information to preview, select and record the test configuration for all S/W items
and test environment data (APs, Synoptics and CCS AIT DB) at start-up.
The communication between the CCS and any front end equipment (SCOEs, Front Ends, Instrument EGSE) is
accomplished via a local area network (LAN) called EGSE LAN. In order to ensure a deterministic traffic, the
EGSE LAN is realised by a dedicated physical Ethernet segment. The protocol which is the same for all interfaces,
uses the CCSDS source packets as the standard protocol data unit for both the spacecraft telemetry/telecommand
packet routing and the EGSE internal data traffic. All layers of this protocol are defined in \AD1\. The logical
communication links are shown in Figure 3-2.
TM/TC FE
Controller
C&C Msg
EGSE HK TM
S/C TM Pkts
S/C TC Pkts
TM/TC FE TC Echo Pkts
S-Band C&C Msg
I/F Handler
SCOE EGSE HK TM
Controller S-Band SCOE

I/F Handler
C&C Msg
EGSE HK TM
[S/C TM Pkts]
C&C Msg
[TC Echo Pkts]
EGSE HK TM
LPS SCOE LPS SCOE CCS Instr. EGSE Instr. EGSE
Controller I/F Handler Kernel I/F Handler Controller
SAS SCOE
I/F Handler
SAS SCOE
C&C Msg
Controller EGSE HK TM CCS_logical_links.vsd
Figure 3-2 CCS Links
Legende: C&C Msg : Command and Control messages for remote control from CCS
EGSE HK TM : FEE / SCOE specific House-Keeping Telemetry Source Packet(s)
[] : optional these kind of packets can be provided to Instrument EGSE upon request

Issue: 0
EGSE Specification
Date: 25.02.2006
3.2. Satellite Reference Database (SRDB)

The Satellite Reference Database (SRDB) will contain a comprehensive set of satellite technical data and will be
based on the ESA SCOS2000 database management system. Verification of the SRDB will be performed on an
ongoing basis starting at the MDVE stage, and culminating in a full verification at spacecraft FM level.
The SRDB is designed to hold definitions of spacecraft relevant TM/TC packet, TM/TC parameter, calibration
curves, monitoring limits and conditions, e.t.c.
All spacecraft TM/TC definitions are exported from the SRDB and imported into the CCS AIT/AIV database for
spacecraft integration and check-out purposes. Any modification to the spacecraft TM/TC definitions will be
executed on the SRDB as the SRDB forms the master database for configuration management.
The SRDB will be delivered to the ground operation station (i.e. ESOC) providing spacecraft TM/TC
data/definitions validated during spacecraft AIT/AIV.
3.3. TM/TC Front End

The TM/TC Front End is responsible for the complete handling of Telemetry and Telecommand exchange between
the on-board computer (OBT) and the CCS or NDIU. The data processing by the TM/TC FE includes TM
processing from bitstream to frame level (incl. Error detection/correction) and TC processing from packet to CLTU
bitstream and echo decoding from CLTU to Segment level. (incl. COP-1 support). The Figure 3-3 shows the block
diagram of the TM/TC FE. Detailed requirements specification is given in \RD4\.
On-Board Computer (OBC)

TM Bypass B / Redundant
TC Bypass B /Redundant
S-Band
TM Bypass A / Nominal
TC Bypass A / Nominal
Transponder
S-Band RF-Link
S-Band SCOE
TM/TC Front End
Switch Unit
TC (RF)
TC TC Echo TM
Encoder Decoder Decoder
TM (RF)
TM/TC FE GUI
EGSE LAN to Core EGSE
S/C TM & FE HK TM Pkts

Workstation
TC from NDIU
TC Echo Pkts
TM to NDIU
S/C TC Pkts
TM
Archiving
C&C Pkt exchange
Figure 3-3 TM/TC Front End Equipment Block Diagram

The TM/TC FE is constituted by the following parts:
1. the TM/TC FE Workstation responsible for:
Overall system control
TC Packet Handling/Generation/Verification etc.
TM Packet Handling
Local GUI
Packet monitoring/displays
Parameter extraction

Issue: 0
EGSE Specification
Date: 25.02.2006
TM & TC Simulation
TM Transfer Frames and / or TM Packets archiving
Remote Interface to the Core EGSE via the EGSE LAN (Ethernet using TCP/IP protocol). This
connection is used to enable the Core EGSE to command and monitor the TM/TC Front End unit.
the TM/TC Front End responsible for:
Recovering TM Transfer Frames from a serial bit stream
TC packets encoding and transmitting CLTUs in the correct serial format
Receiving serial CLTUs and decoding to retrieve TC pakets
the Switch Unit responsible for the interfacing, isolation and proper routing of TM/TC signals from
all sources/destinations. It interfaces the spacecraft, the S-Band SCOE as well as the NDIU:
The interface with the spacecraft consists of Nominal and Redundant TM NRZ-L (Clock and
Data), plus Nominal and Redundant TC NRZ-L (Enable, Clock and Data).
The interfaces with the S-Band SCOE are:
- TM NRZ-L (Clock and Data) from the S-Band SCOE,
- TC NRZ-L (Clock, Data & Enable) to the S-Band SCOE, and
- TC NRZ-L (external Clock) from the S-Band SCOE
Note: TC external clock is provided to fulfill ESA RF Modulation Standard requiring bit
change on sub-carrier frequency zero-crossing.
The interfaces with the NDIU are: TM NRZ-L (Clock and Data) and TC video.
3.4. Power Front-End Equipment

In the absence of the real power sub-system (PCDU), the Power Front-End equipment provides power to individual
spacecraft components / sub-systems emulating dedicated LCL and FCL on-board power sub-system (PCDU)
output lines. This applies to the following EGSE configurations to power the OBC EM:
The Real-Time Testbed (RTB)
The extended RTB (eRTB)
The RF-Suitcase
To power the OBC EM the following power output lines are provided:
2 LCLs, class 2 (2A) - tbc.
2 FCLs, class 2 (2A) - tbc.
To power additional S/C sub-systems in extended RTB configuration by the following power output lines:
tbd. LCLs, class 2 (2A) - tbc.
tbd. FCLs, class 2 (2A) - tbc.
A total power demand of up to 100W (tbc) at 28V shall be supported. Over-current and over-voltage protection
shall be adjustable per output line.
A controller PC provides the remote interfaces to the Core EGSE via the EGSE LAN (Ethernet using TCP/IP
protocol). This connection is used to enable the Core EGSE to command and monitor the Power FE unit. Detailed
requirements specification is given in \RD4\.
3.5. S-Band SCOE

The S-Band SCOE is constituted of the following functional blocks as outlined in Figure 3-4 below:
RF Matching Unit
S-Band Transmitter
S-Band Receiver
Measurement Equipment
S-Band SCOE Controller
Detailed requirements for each component listed are given in \RD5\.

Issue: 0
EGSE Specification
Date: 25.02.2006
Receiver
TM/TC RF
FE Matching S/C
Unit
Transmitter
Command
& Control
S-Band Measurement
EGSE LAN Devices
(to CCS) SCOE Controller
S-Band SCOE
Figure 3-4 S-Band SCOE Blockdiagram

The transmitter receives the TC signal from the TC Front End equipment and generates the RF uplink signal.
The S-Band SCOE receives from the satellite the RF downlink antenna signal, demodulates the TM signal and
provide it to the TM Front End Equipment.
RF measurements are performed providing appropriate the Measurement Devices:
spectrum analysis on the up-link or down-link S-band signal.
RF power measurement on the up-link and down-link S-Band signal to deduce the actual output power or
input power at cable end.
frequency measurement on the up-link and down-link S-Band signal.
The RF Matching Unit establishes all the connections between the different access points of the equipment and all
the different measurement devices.
The S-Band SCOE Controller supports local operation via a local GUI as well as remote operation by the CCS via
Local Area Network. The S-Band SCOE controller operated in local or remote mode provides functions for
controlling and monitoring of the RF equipment as follows:
Connection of test equipment to RF path within the RF matching unit
Setting / configuration of the RF test equipment
(e.g. spectrum analyser, power meter, frequency counter, attenuator settings, switch positions, ...)
Read out of parameters from RF test equipment
Control of receiver and transmitter
set carrier frequency
set carrier power level
switch carrier ON/OFF
sweep carrier frequency
switch ON/OFF signal modulation
set modulation index
Read out of parameters from the receiver and transmitter
Switch control of the RF matching unit

Issue: 0
EGSE Specification
Date: 25.02.2006
3.6. Power SCOE

The Power SCOE as outlined in Figure 3-5 below consists of
the Solar Array Simulator (SAS) SCOE
the Main Bus Power Supply unit
the Battery Charge Power Supply unit
Detailed requirements specifications are given in \RD6\ (SAS SCOE) and \RD7\ (LPS SCOE).
A dedicated Battery Simulator will not be used, instead a real (EM) battery is intended to be used for PCDU tesing.
- tbc
Under the assumption that LI-Ion battery will be used - tbc, no battery conditioning will be required. LI-Ion
batteries only require storage at a certain temperature level (i.e. tbd degree Celcius) after being charged to a certain
voltage level (i.e. tbd V). The required temperature may be ensured by a COTS refrigerator.
STB-2
LPS SCOE Bracket PCDU
FCL
30 m LPS cable
Mainbus
Power Supply OVP sense lines FCL
to S/C consumers
BBPS
Battery Power
Supply OVP sense lines
BAPS
FCL
Mainbus Voltage HK
TM Battery Voltage HK
Acquisition Battery Current HK FCL
Battery Battery
Relay
SAS SCOE
30 m SAS cable
SAS
SAS Power
Power Sequential
SAS Power
Supply Shunt Shunt
Supply OVP sense lines
Supply
PSxx Stage x Regulation
PSxx
PSxx 11 stages
11 Sections Shunt Stage

Controller
Figure 3-5 Power SCOE basics
3.6.1. Solar Array Simulator (SAS) SCOE

The Solar Array Simulator is used to support the electrical tests of the spacecraft on ground by simulating the solar
arrays. A solar array is composed of several sections connected to the PCDU. Each section is an assembly of solar
cells. The Solar Array Simulator simulates each section, which is in fact a controlled current source with the same
dynamic impedance as the onboard section.
The Solar Array Simulator supports the following functions outlined in Figure 3-6 below:

Issue: 0
EGSE Specification
Date: 25.02.2006
simulation of the solar array sections by individual current sources

simulation of the solar array in different phases of the spacecraft flight like sunlight or eclipse
individually adjustable source current and open loop voltage per section
over-voltage and over-current protection to avoid any damage to the spacecraft
The Solar Array Simulator is be composed of tbd # of sections simulating the real spacecraft solar array. Each of
them is composed of a current source and an impedance adaptation.
The SAS SCOE Controller supports local operation via a local GUI as well as remote operation by the CCS via
Local Area Network. The SAS SCOE controller operated in local or remote mode provides functions for controlling
and monitoring of the power equipment.
external U
OVP/OCP
I
Module
SAS 01 SAS 01 Power Line

Power Supply Safety Switch
SAS 01 Voltage sense
SAS 02
SAS Data
SAS 03
Power Supply
SCOE Acquisition SAS 04
Power Supply
Controller and Power Supply
Commanding
SAS 10
SAS 11
Power Supply
Power Supply U
external
OVP/OCP
Module I
GPIB SAS 12 SAS 12 Power Line

SAS 12 Voltage sense
Figure 3-6 Solar Array Simulator (SAS) SCOE
3.6.2. Launch Power Supply (LPS) SCOE

The Main Bus Power Supply unit provides power to the unit under test (i.e. PCDU, spacecraft) due to the absence
of the solar arrays and SAS SCOE. The Battery Charge Power Supply unit is used to charge the battery due to the
absence of the solar arrays and SAS SCOE. The power characteristics of the battery supply shall be suitable for the
Taper Charge Mode (TCM). Taper charging means a combination of constant voltage and current limitation mode -
constant voltage / current limiting (CV/CL).
For battery charging the power supply will provide the maximum current (CL) until the battery voltage is increased
to the predefined voltage level. From this point in time the current is decreasing on a constant output voltage (CV)
depending on the battery charge state.
The Main Bus Power Supply unit together with the Battery Charge Power Supply unit are intended to power the
spacecraft at launch configuration, thus this ensemble will be called the Launch Power Supply (LPS) SCOE.
In addition to the power supplies the LPS SCOE shall provide the following functions:
over-voltage / over-current protection to avoid any damage to the spacecraft
sense and display battery currents and voltages
provide High Power Command Interfaces for direct commanding of the PCDU
provide main bus conditioning to allow the switching of the battery relays

Issue: 0
EGSE Specification
Date: 25.02.2006
A block diagram of the LPS SCOE is outlined in Figure 3-7 below.

The LPS SCOE Controller supports local operation via a local GUI as well as remote operation by the CCS via
Local Area Network. The LPS SCOE controller operated in local or remote mode provides functions for controlling
and monitoring of the power equipment.
external U
OVP/OCP
Module I
Battery Battery Power

Batt. Voltage sense
external U
OVP/OCP
Module I
Mainbus Mainbus Power

internal LAN / GPIB

Mainbus Voltage sense
Battery current HK
current
comparator 500 mA
ref.
Mainbus voltage HK
voltage
comparator
LPS Battery voltage HK
SCOE
Controller under-
voltage (UV)
Data protect analog measurement
5 channels
Acquisition
and analog Thermistor
6 measurement channels
Commanding
6
Power Supply
S/C relay
6 Relay Status channels contact
Bipolar High Power
4 Pulse Command lines
BHP / SHP
Standard High Power
Pulse Cmd
6 Pulse Command lines
Modules
10
Simulated
10 Separation Switches
Figure 3-7 LPS SCOE
3.7. O/B S/W Load & Dump Station

To load and dump on-board software to and from the OBC a COTS PC/Notebook will be used interfaceing the
OBC via a dedicated test connector (i.e. RS422 serial line tbc.).

Issue: 0
EGSE Specification
Date: 25.02.2006
3.8. Simulation Front End

The Simulation Front End defines the interfaces towards the OBC/Satellite to substitute by simulations the
subsystem or payload communicating with the OBC. The logical simulation (e.g. generation of stimuli data or
processing of feedback data) is provided by the S/C and Environment (i.e. real-time) simulator. The Simulation
Front End is the interface in-between providing the electrical interface, low-level protocol and on some response
channels it is necessary to perform measurements like pulse duration, amplitude, etc..
For the VME Bus architecture of the Simulation Front End the S/C and Environment / Real-Time Simulator will act
as the bus master. All interface cards inside the Simulation Front End will be slave modules.
The Simulation Front End stimulation of payload/subsystems interfaces towards the OBC will be based on a VME
bus architecture and COTS VME I/O boards, as far as possible. It has to support a VME master slave architecture.
The Bus Master shall be able to transfer data to and from the modules called slaves.
For the integration of the S/C and Environment / Real-time Simulator the Simulation Front End will implement a
standard VME bus interface supporting VME Bus coupling and VME Bus extension in order to connect the VME-
busses of both systems.
3.9. Spacecraft Environment Simulator / Real-Time Simulator

The Spacecraft Environment Simulator / Real-Time Simulator (RTS) simulates the functional satellite equipment,
instruments and subsystem except the OBC and its software. Satellite environment and dynamics will be simulated.
This simulator will run in real-time in order to stimulate the OBC EM. It will be configured, characterised and
initialised by use of a file-interface with data retrieved from databases. During simulation it generates periodic
telemetry like satellite or EGSE. In addition selected variables values are logged during simulation.
Two different implementations of this simulator will be used:
PC implementation running on a Linux environment communicating with the OBC Simulator
VME-Bus implementation running on a VXworks environment communicating with the Simulation Front
End.
3.10. OBC Simulator

The OBC Simulator consists of
ERC32 processor emulator,
OBC hardware simulation including RU Simulator,
OBC OnBoard Software of the current version.
This simulator allows to run the OBC On-Board Software in emulated environment independent from the flight
hardware. It provides debugging functions. This simulator will run in simulated real-time where the processes are
scheduled within PPS periods, which can have duration longer than 1 sec.
The OBC simulator interfaces the S/C & Environment Simulator (i.e. RTS).

Issue: 0
EGSE Specification
Date: 25.02.2006
4. Communication Requirements
This chapter establishes requirements for all FEE which shall be operated by the CCS in any EGSE configuration
(i.e. instrument EGSE, MDVE, test bed, platform EGSE, satellite EGSE, e.t.c.).
4.1. Function Requirements
4.1.1. Command and Control
4.1.1.1.1 Standard Functions, Ref.: \AD1\, 3 / TE

The FEE shall execute standard functions called by keyword as defined in \AD1\.
Below the keywords are listed representing C&C messages from the CCS identifying mandatory and optional
standard functions by the FEE. Functions defined by these keywords shall only be used according to the syntax
defined in \AD1\, 3.
Keyword AD1, 3.x
TRANSFER mandatory 1
RESET mandatory 2
RESTART optional 3
START / STOP optional 4
HALT / CONTINUE
APPLY optional 5
SET optional 6
REPORT / REPLY mandatory 7
ERROR mandatory 8
MESSAGE mandatory 8
TEST mandatory 9
GETTM mandatory 10
Specific requirements in case of remote commanding by the CCS are given in the section below.
4.1.1.1.2 Specific Functions, Ref.: \AD1\, 2.3.5 / TE

Specific functions executed in the FEE may be defined in addition to the standard functions. Syntax and structure of
the C&C messages calling such specific function shall be in accordance to the C&C message definition in \AD1\,
2.3.5. Keywords and command syntax shall be described in detail in the equipment ICD and users manual.
4.1.1.1.3 Configurable C&C Packet header / TE

The first two bytes of the C&C message source packet primary header as defined by \AD1\, 2.3.5, shall be
configurable by the user.
4.1.1.1.4 C&C NOT case-sensitive / TE

C&C message and command keywords and arguments shall NOT be case-sensitive.
4.1.1.1.5 Local/remote functions / TE

All functions executed on the FEE shall be called either from the local MMI or by remote command from the CCS.
A complete description of command and control functions available on a FEE shall be defined in the related
equipment Interface Control Document and users manual.

Issue: 0
EGSE Specification
Date: 25.02.2006
4.1.2. Requirements for Communication with CCS
4.1.2.1.1 application protocol - client & server, Ref: \AD1\, 2.2 / TE

The application protocol shall be implemented as specified in \AD1\, chapter 2.2, with the FEE providing server
services and the CCS acting as client to all sockets established.
4.1.2.1.2 two TCP/IP sockets / TE

By each FEE two TCP/IP stream sockets shall be established for communication to the CCS. One socket (the
receive-link or TC-link) for receiving messages from the CCS and performing the corresponding handshake, if any.
The other socket (the send-link or TM-link) for all messages autonomously sent by the FEE to the CCS (ref. \AD1\,
2.2)
If a command from the Core EGSE obtained via the receive-link requests data transmission then this transmission
shall be performed using the send-link.
4.1.2.1.3 provide service during startup / TE

During startup of the application software system at the FEE the network communication services shall be provided
automatically without any manual intervention needed.
4.1.2.1.4 Initial status / TE

After mains power on or after reset, the FEE shall assume a local / off-line operation mode with following
characteristics:
remote operation mode inactive (i.e. socket disconnected & off-line - ref \AD1\, 2.2.4)
commanding from the FEE local console enabled
all stimulus to the instrument inactive
remote interface to CCS ready to receive socket connection request
4.1.2.1.5 Ref.: \AD1\, 2.3.5 => Accept command messages / TE

The FEE shall accept and execute command messages (called C&C) from the CCS embedded into command source
packets as defined in above reference.
4.1.2.1.6 On-line command / TE

The FEE shall accept a Transfer remote C&C command from the CCS via LAN if the logical link was previously
established by a connection request. This command shall bring the FEE into the following configuration:
remote operation active (ref. \AD1\, 2.2.4)
commanding from the FEE local console disabled, except "switch to local mode"
no change to processes running at the time of switching to on-line
4.1.2.1.7 Off-line command / TE

The FEE shall accept an off-line command from the FEE local console or a Transfer local C&C command from
the CCS via LAN. This command shall bring the FEE into the following configuration:
remote operation inactive (ref. \AD1\, 2.2.4) / logical link is not disconnected
commanding from the FEE local console enabled
if enabled FEE internal HKTM packets generation and transmission to the CCS continues
no change to processes running at the time of switching to off-line
the SCOE shall assume a operation safe mode not causing any hazard to the instrument
remote interface to CCS ready to receive commands
4.1.2.1.8 Ref.: \AD1\, 2.3.5 => Issue messages / TE

Issue: 0
EGSE Specification
Date: 25.02.2006
The FEE shall issue status and error messages to the CCS in the form of C&C messages as defined in above
reference. Keywords and message syntax shall be described in detail in the equipment ICD and users manual.
The detailed definition of command and status messages shall be defined based on the actual design implementation
of the FEE. As a minimum, messages related to the FEE elements served by the controller shall be processed in
accordance to the requirements defined above.
4.1.2.1.9 Message to CCS on Status Change / TE

Message, Error, Warning C&C shall be sent to the CCS on FEE status change, only. Such C&C shall be sent only
once upon detection of the relevant status. Cyclic repetition of the same error C&C shall be prohibited. E.g. one
single error C&C shall be sent upon error situation detection. A message C&C chall be sent if the relevant status
returns to nominal.
For cyclic reporting binary HK TM packet shall be used; see requirement below.
4.1.2.1.10 Ref.: \AD1\, 2.3.3 => EGSE internal HK TM Packet / TE

For cyclical report of FEE house-keeping data to the CCS specific EGSE Internal HK TM Source Packet(s) shall be
provided by the FEE conforming to above reference.
4.1.2.1.11 HK TM detailed Description / RoD

Packet Structure and parameter details shall be described in detail in the equipment ICD and users manual as
outlined in \AD1\, 2.3.3 - Packet Data Field.
4.1.2.1.12 HK TM Description in electronic Form / INS

Detailed description of the HK TM Packets and their contents, i.e. each individual measurement / parameter, shall
be delivered in electronic form (e.g. Excel Spreadsheet or MS Access DB).
Note: a template - either Excel or Access - will be provided by Astrium and populated by the supplier.
4.1.2.1.13 Reset command / TE

The FEE shall accept a reset command via FEE local console or LAN in on-line mode and via FEE local console in
off-line mode. The reset shall bring the complete FEE into the default setting corresponding to the initial status,
including disconnect of logical link to the CCS.
4.1.2.1.14 Operation during switch-over / TE

Switching between local and remote operation shall be possible in any operation mode without affecting the
operation conditions.
4.1.2.1.15 Switch over communication / TE

Upon switching from local to remote, the FEE shall communicate its operation status to the CCS.
Due to manual intervention during local operation, the CCS software may find the FEE in an operation status when
switched back to remote other then has been commanded before. The implementation of this requirement shall
avoid unnecessary error messages.
4.1.2.1.16 Self-test mode / TE

It shall be possible to initiate a self-test mode either locally on the FEE console or from the CCS via the LAN
interface depending on the control status.
Self-test may be executed only, if the FEE application software is in "offline" mode, i.e. no processing with the on-
board system / instrument.
4.1.2.1.17 Self-test diagnostic support / TE

The detailed results of the self-test shall be available at the CCS and at the local console as an OK / not OK message
including error reporting (type of error, diagnostic message) for investigation if the self test was not OK.

Issue: 0
EGSE Specification
Date: 25.02.2006
4.1.2.1.18 Interfaces during selftests / TE

Self-tests shall be possible with the EGSE connected and disconnected to the on-board equipment.
Special attention shall be paid to the interfaces connecting the EGSE with the on-board equipment. The self-test
shall prove that those interfaces are in a well defined status such that no hazard is caused to the instrument or other
on-board equipment.
4.1.2.1.19 Instrument EGSE: Accept Instrument HK TM Source Packets / TE

Instrument EGSE shall accept instrument related HK TM Source Packets at the nominal data rate from the CCS.
The TM Source Packets will be provided on the "receive-link" via the EGSE LAN in the form of native spacecraft
telemetry packets as outlined in /AD1/, 2.3.1.1. Spacecraft HK TM Source Packets shall not be acknowledged by
the Instrument EGSE.
4.1.2.1.20 Instrument EGSE: Accept command data from the CCS / TE

Instrument EGSE shall accept copies of the TC Source Packets which have been sent to the instrument from the
CCS. This command notification will be provided by the CCS on the "receive-link" via the EGSE LAN in the form
of native spacecraft TC Source Packets as outlined in /AD1/, 3.3.1.2. Spacecraft TC Source Packets shall not
acknowledged by the Instrument EGSE.
The purpose of distributing sent commands and HK TM data to the Instrument EGSE is to enable data processing
and other instrument specific operations, if required by the instrument in close relation to the actual commanded
and achieved instrument status.
As command notification the "TC Echo" from the TM/TC FEE is routed to Instrument EGSE (see /AD1/, fig. 2-4).
4.1.3. Log Files Management
4.1.3.1.1 Log file generation / TE

During operations in local mode as well as in remote mode the following information shall be recorded in ASCII
log files:
Instructions, commands, and messages received from the CCS
keyboard entries during local operation
all events, messages, errors etc. occuring during operations (sent to the CCS in remote mode)
(Note: on the local log file error situation might be reported cyclically in contrary to requirement above)
operator messages to the local display generated during local mode operation
4.1.3.1.2 Log files management / TE

a. Log files shall be created on the FEE controller local disk on a folder dedicated to log files, only.
b. Unambiguous file names shall be provided indicating the test by name (if applicable) and the creation time.
c. The size of a log file shall be limited to a reasonable file size. File size criteria shall be number of lines and/or
number of bytes (e.g. <500 lines / <1Mbyte). If this size is reached the current log file shall automatically be
closed and new file shall be opened.
d. Log files size criteria shall be configurable by the user.
e. New log file shall be forced to be opened at the beginning of a new day (i.e. time = 00:00).
f. Log files closed shall be accessible by the operator.
g. Log files shall not be automatically deleted or overwritten.
4.1.3.1.3 Log entry time stamp / TE

Each entry to a log file shall be preceeded by a time stamp indicating date and time obtained from the controller
system time in the format " jjjj.mm.dd hh:mm:ss".
4.1.3.1.4 Log Entry Visualisation / TE

Issue: 0
EGSE Specification
Date: 25.02.2006
All events subject to log file entry shall be able to be visualised on-line (i.e. at time of occurence) in a display
window on the controller local console. Filters shall be able to be applied to allow the operator to only display
selected entry types (i.e. Error, Warning, Message, e.t.c.) or all entries.
4.1.3.1.5 Log file browsing and retrieval / TE

It shall be possible to browse through the log files directory by means of standard (i.e. operating system utility) file
manager and to retrieve a log file corresponding to time and date of a test and to display / print the selected log file
contents.
4.1.3.1.6 Log files remote access / TE

The log files shall be accessible from any LAN connected computer (e.g. the CCS or the global archiving) via FTP.
4.1.4. HK TM Archive Files Management
4.1.4.1.1 HK TM re-direction to file / TE

In case HK TM Packet generation has been started either locally or by remote command from CCS and the TM link
to the CCS is not established, these HK TM Packets shall be recorded locally by the FEE controller in a telemetry
archive file in the form of binary EGSE internal HK TM Source packets as generated for transfer to the CCS (see
/AD2/, 3.3.3). -> Re-direction of the HK TM packets datastream to file, if the socket is not established.
While the TM link is established from the CCS such local archiving is not required as all HK TM packets are
transferred to the CCS and are subject to central archiving by the CCS.
4.1.4.1.2 Archive files management / TE

a. Archive files shall be created on the FEE controller local disk on a folder dedicated to archive files, only.
b. Unambiguous file names shall be provided indicating the test by name (if applicable) and the creation time.
c. The size of an archive file shall be limited to a reasonable file size. File size criteria shall be number of packets
and/or number of bytes (e.g. <500 packets / <1Mbyte). If this size is reached the current archive file shall
automatically be closed and new file shall be opened.
d. Archive files size criteria shall be configurable by the user.
e. New archive file shall be forced to be opened at the beginning of a new day (i.e. time = 00:00).
f. Archive files shall not be automatically deleted or overwritten.
4.1.4.1.3 Archive file browsing and retrieval / TE

It must be possible to browse through the archive files directory by means of standard (i.e. operating system utility,
for PC: Windows Explorer) file manager and to retrieve an archive file corresponding to time and date of a test and
to display / print the selected file contents.
For visualisation (i.e. display and print) of binary information such as archived HK TM packets commercial off-the-
shelf tools (e.g. "Hex-Editor" by the operating system; UltraEdit-32 are considered sufficient. Dedicated
application is NOT mandatory. Interpreting specific data structure, such as the "TM Source Packet", is NOT
required.
4.1.4.1.4 Archive files remote access / TE

The archive files shall be accessible from any LAN connected computer (e.g. the CCS or the global archiving) via
FTP.

Issue: 0
EGSE Specification
Date: 25.02.2006
4.2. Interface Requirements

The only interface used for FEEs to communicate to the CCS is the Ethernet network. The topology of such
network is driven by the FEEs grounding needs to avoid ground loops. As the CCS is constituted of commercial
computer equipment and not necessarily operated through an isolation transformer two different approaches to fulfil
the grounding requirements are considered as shown in Figure 2-1 and Figure 4-2 below.
Cat.5 RJ45 Patch Cable UTP
FEE / SCOE A
Cat.5 RJ45 Patch Cable UTP
EGSE LAN Switch

FEE / SCOE B
CCS
FEE / SCOE C
Figure 4-1 EGSE LAN Topology using unshielded Cable
Cat.5 RJ45 Patch Cable STP

Cat.5
RJ45
Patch FEE / SCOE A
Cable STP
Multi-Mode FO Cable
TX <-> FX TX <-> FX
Media- Media-
Converter Converter
EGSE LAN Switch

FEE / SCOE B
CCS
FEE / SCOE C
Figure 4-2 EGSE LAN Topology using Fibre Optics
4.2.1.1.1 Communication Interface to CCS / INS

Issue: 0
EGSE Specification
Date: 25.02.2006
The communication between Front End Equipment (FEE) and the CCS shall be performed by means of a Local
Area Network (LAN) as follows (ref. \AD1\, 3.2):
the physical network is referenced / named "EGSE LAN"
Ethernet according to IEEE 802.3
10/100-Base-T RJ45; Category 5 shielded twisted pair (STP) or unshielded twisted pair (UTP)
TCP/IP stream socket peer-to-peer connections
4.2.1.1.2 Ethernet Adapter /RoD

According to \AD1\, 2.1, Ethernet adapter supporting 100BaseT shall be provided with galvanic isolated line
drivers in order to ensure no ground loops induced via the network cabling.
4.2.1.1.3 Unique Addressing /TE

In order to allow exchange of a specific type of FEE (e.g. TM/TC FE or S-Band SCOE) between different EGSE
setups / configurations one single alias node name and one unique IP Address shall be assigned to one type of FEE
(e.g. considering all EGSE configurations within the project a total amount of 3 to 4 TM/TC FEs are required. Each
individual TM/TC FE unit shall have assigned the alias name "tmtc-fe" and the unique IP Address). For example
see Table 4-1 below with the first three bytes of the IP address fixed to e.g. "198.165.200.x" for all EGSE
configurations.
Node-Name IP-Address Description
4th byte = x
swarm-tn 1 CCS
tmtc-fe 11 TM/TC FE Controller
sband-fe 12 S-Band SCOE Controller
lps-fe 13 Launch Power Supply (LPS) SCOE Controller
sas-fe 14 Solar Array Simulator (SAS) SCOE Controller
pwr-fe 19 Power FE Controller (RTB item only)
Table 4-1 EGSE LAN IP Addresses
4.2.1.1.4 IP Address Assignment /TE

IP Addresses in the EGSE LAN shall be fix assigned. No dynamic address allocation used (i.e. no DHCP).
4.2.1.1.5 IP Address Configuration / TE

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 equipment users manual.
4.2.1.1.6 EGSE Synchronisation / TE

Time synchronisation of EGSE computers shall be achieved via the EGSE LAN by means of UNIX standard
Network Time Protocol (NTP) with the CCS acting as the time server.
Windows-based FEE controllers may use freeware tools such as "AboutTime" or "Dimension 4" supporting NTP
clients on SNTP protocol.
4.2.1.1.7 Remote Desktop Service / TE

The FE controller shall support remote desktop service allowing the local desktop environment to be accessed from
a remote computer.
On WinXP professional the "Remotedesktop" utility may be used. Unix/Linux based systems may be accessed from
remote via "Exceed".
A tool common across Windows and Linux platforms is "VNC" (URL: http://www.realvnc.com/download.html)
requiring the VNC Server process being installed on the FE controller.

Issue: 0
EGSE Specification
Date: 25.02.2006
5. Implementation Requirements
This section provides general design, implementation, manufacturing and environmental requirements. These
requirements are applicable for the implementation, as well as for selection of commercial equipment. Justification
shall be given in the case of deviation from the guidelines below.
5.1. General
5.1.1.1.1 Product Liability / RoD

All equipment supplied against this order, where applicable, shall be CE marked and in accordance with European
legislation. A copy of the "Declaration of Conformance" shall be supplied.
5.1.1.1.2 General design approach / RoD

EGSE shall be based on commercially available and supported hardware and software as far as possible.
5.1.1.1.3 Metric Standards / RoD

Design, manufacture and assembly shall be consistent with the ISO metric standard and shall satisfy EU standards.
5.1.1.1.4 Standard Interface /RoD

For communication of stand-alone COTS FEE controller to the FEE equipment an Ethernet network interface shall
be used. No specific hardware shall be required to be installed on the FEE controller to operate the FEE equipment
through the FEE application Software. Thus, the FEE application Software shall be easy portable on different / new
hardware.
a) a second LAN adapter may be used not to interfere the FEE internal communication with the EGSE LAN
communication.
b) in particular, no IEEE488/HPIB-Bus controller shall be required on a PC PCI-Bus, instead an external LAN -
HPIB Gateway (e.g. Agilent E5810A) shall be used.
5.2. Lifetime
5.2.1.1.1 Continuous Operation / AN

The EGSE shall generally be designed for continuous operation. Test periods of up to 20 days shall be supported
without the need for interruptions due to resource limitations such as disk space or storage medium exchange or
routine maintenance activities.
5.2.1.1.2 Design lifetime / AN

EGSE shall be designed for an operational lifetime extending at least 6 years after acceptance.
5.2.1.1.3 Assembly Cycles / AN

EGSE shall be designed to withstand at least 10 cycles of packing, transport, storage, unpacking and preparation for
use, tbc.
5.3. Safety
5.3.1.1.1 Design safety / RoD

GSE shall be designed avoiding sharp corners and edges.
5.3.1.1.2 Material safety / RoD

Issue: 0
EGSE Specification
Date: 25.02.2006
No material shall be used which may constitute a risk to the health of personnel.
5.3.1.1.3 Locking brake devices / RoD

All movable equipment shall have locking brake devices.
5.3.1.1.4 Fail-safe design / RoD

GSE shall in no way be able to endanger the spacecraft system and / or operating personnel. Fail-safe design shall
be built in to ensure, that any single point failure in the GSE does not propagate and cause damage to the on-board
equipment.
5.3.1.1.5 Failure tolerant design / RoD

The GSE elements shall be designed for tolerance to failures in interfacing equipment (i. e. the onboard equipment
or other GSE elements).
5.3.1.1.6 Inclined GSE / AN
GSE shall stand stable when standing inclined by up to 15.
5.3.1.1.7 National Safety Standards / RoD

All GSE shall be designed taking into account the applicable national safety standards.
5.3.1.1.8 Launch Site Safety Requirements / RoD

All GSE to be used at the launch site shall meet the Launch Site Safety Requirements.
5.4. Cleanliness
5.4.1.1.1 Cleanability / RoD

All GSE shall be designed for easy cleanability, i.e. flat surfaces, no sensivity to cleaning agents.
5.4.1.1.2 Surface treatment / RoD

All GSE to be used in the cleanroom or are in contact to flight hardware shall be surface treated as far as possible in
order to meet the cleanroom and instrument specific cleanliness requirements.
5.5. Parts & Materials
5.5.1.1.1 Corrosion Resistance / RoD

Metals shall be of a corrosion-resistant type or suitably treated to resist corrosive conditions.
5.5.1.1.2 Material compatibility to flight hardware / RoD

All GSE to flight hardware interface shall be examined for their material compatibility i. e. electrolytic and / or
fretting shall not occur.
5.5.1.1.3 Forebidden materials / RoD

The following material shall not be used:
Polyvinyl Chloride (PVC) for items used in cleanrooms
(this does not apply to commercial off-the-shelf computer equipment!)
Cadmium Plating
5.6. Maintainability & Reliability

Issue: 0
EGSE Specification
Date: 25.02.2006
5.6.1.1.1 minimum Maintenance / RoD

GSE shall be designed for minimum scheduled maintenance.
5.6.1.1.2 Easy accessibility / RoD

Components requiring scheduled maintenance shall be easily accessible.
5.6.1.1.3 Description of Maintenance Procedure / RoD

Components shall be identified and maintenance procedures described within the equipment users manual dedicated
maintenance chapter.
5.6.1.1.4 Manufacturing & Assembly Standards / RoD
The GSE shall be manufactured and assembled to the usual standards of ground based electronic instrumentation
and engineering practice of spacecraft testing. Judgement and acceptance of GSE shall be based on design margin
applied, possible failure modes and their effect, and soundness of the design.
5.6.1.1.5 GSE Downtime / RoD

The GSE shall be designed for a minimum downtime including routine maintenance in order not to jeopardize the
overall satellite AIV program schedule.
For GSE, a maximum reliability shall be attained by a combination of the following services to be provided by GSE
suppliers:
24 hours response service for "first aid" trouble shooting support.
spare parts, maintenance, and repair service which guarantees a down time of not more than 48 hours.
5.7. Interchangeability & Replaceability
5.7.1.1.1 Interchangeability / RoD

GSE sub-assemblies, parts and components bearing the same part number shall be both physically and functionally
interchangeable.
5.7.1.1.2 Replaceability / RoD

Equipment design tolerances shall not be more stringent than necessary to achieve the performance and replace
ability required throughout the operational life of the equipment.
5.8. Transportation & Container
5.8.1.1.1 Transport capability / INS

All GSE shall be designed for road, air (including helicopter), and ship transportation by normal commercial
facilities readily available in Europe.
As far as not specified otherwise herein, EGSE design shall meet the requirements from PSS-01-202, Preservation,
storage, handling and transportation of ESA spacecraft hardware.
Transportation of EGSE within Europe will be mainly by road.
5.8.1.1.2 Centre of Gravity / INS

Its centre of gravity shall be as low as possible and the wheels shall be attached at the utmost points of the edges to
prevent tilting during movement. ??????????
5.8.1.1.3 Containers for transport and storage / INS

All GSE items shall be provided with re-useable containers to comply with the transport and storage environments
given herein.
5.8.1.1.4 Container environmental protection / INS

Issue: 0
EGSE Specification
Date: 25.02.2006
Containers shall be designed to protect GSE from the worst case transportation environment as specified above. If
the GSE inside does not comply with the specified environmental conditions, the containers shall provide adequate
protective measures.
5.8.1.1.5 Minimum packing preparation / INS

GSE containers shall be designed such that the GSE item preparation for packing and the packing process are kept
to a minimum.
5.8.1.1.6 Containers with forklift provisions / INS

GSE containers with a mass > 30 kg when loaded shall be equipped with forklift provisions (e.g. mounted on a
pallet) of dimensions as sketched below:
11 cm + 1cm
60 cm 1 cm
5.8.1.1.7 Containers with crane sling attachments / INS

GSE containers with a mass > 30 kg when loaded shall be equipped with provisions for crane sling attachments.
5.8.1.1.8 Containers with handholds / INS

GSE containers shall be equipped with handholds at least at 2 opposite faces.
5.8.1.1.9 Containers Shock recording / INS

GSE containers shall be equipped with shock recording equipment (peak level sufficient).
5.8.1.1.10 Containers easy closing & opening / INS

GSE containers shall be equipped with protected clamps or countersunk butterfly nuts for closing and opening.
5.8.1.1.11 Containers with ramps / INS

GSE containers for racks shall be equipped with ramps including guidances for safe rack loading and unloading.
5.8.1.1.12 Containers height / INS

GSE containers maximum height (outside dimension) shall be 2.25m.
5.9. Environment
For commercial off-the-shelp equipment individual requirements below may be waived, if justified by the sub-
contractor.
5.9.1.1.1 Transportation environment / RoD

The GSE shall meet the following transportation athmospheric environment conditions:
Temperature: -50C to +60C
Humidity: up to 100% RH
Pressure: equivalent to 15 km altitude
Pressure change rate: < 20 hPa/s
5.9.1.1.2 Normal operational environment / RoD

The GSE shall be designed for operation in a normal laboratory athmospheric environment which is conditioned to
the following:
Temperature: 16C to 27C
Humidity: 30% up to 60%
Cleanliness: at least visible clean

Issue: 0
EGSE Specification
Date: 25.02.2006
5.9.1.1.3 Launch pad environment / RoD

GSE installed into the launch table or the umbilical mast shall be compliant with operation under the following
conditions:
Temperature: 10C to 27C
Humidity: up to 90% RH (condensing)
Pressure 800 to 1050 mbar
Acoustic Noise: up to 138 dB for 10 sec. max. tbc.
5.9.1.1.4 Storage environment / RoD

The GSE shall meet the following storage athmospheric environment conditions:
Temperature: -40C to +60C
Humidity: up to 85% RH
Pressure 800 to 1050 mbar
Where storage environment conditions for EGSE are in conflict with the build standard of commercially available
equipment, this requirement may be waived.
5.9.1.1.5 Environmental test conditions / RoD

EGSE which must be operated in vicinity of the on-board equipment during the environmental test programme, and,
thus is exposed to the same environmental conditions as the item under test shall be design to withstand this test
environment without degradation of performance, and without deteriorating the represesentativity of test results.
5.10. Ergonomy
5.10.1.1.1 Equipment weight / INS

Equipment to be lifted by hand shall not be heavier than 25 kg.
5.10.1.1.2 Equipment hoisting provision / INS

Equipment with a mass higher than 25 kg shall have hoisting provisions.
5.10.1.1.3 Force for manual operation / TE

The maximum force necessary to operate a control or mechanism by hand shall be 120 N.
5.10.1.1.4 Accessability / INS

GSE design shall foresee adequate space and accessibility for the operating personnel for nominal and non-nominal
tasks.
5.10.1.1.5 Drawer sliding / INS

It shall be possible to slide a drawer to its full forward position without disconnecting a cable.
5.10.1.1.6 Accessibility at ergonomic height / INS

Panel which need frequent operator access shall be at an ergonomic height.
5.10.1.1.7 Adjustment during operation / INS

All adjustment during operation shall be carried out from the front panels.
5.10.1.1.8 Connections at rear / INS

All permanent connections shall be at the rear side.
5.10.1.1.9 Extended side walls / INS

The side walls shall be extended to protect the front panel elements from a crash during rack movement.

Issue: 0
EGSE Specification
Date: 25.02.2006
5.10.1.1.10 Front panel protection / INS

Critical front panel switches (as power ON / OFF, Remote/Local, Self-test ...) shall be protected against inadvertent
activation.
5.10.1.1.11 Red lamps / INS

Red lamps at front panels shall be reserved for alarm, no-go or failure indications.
5.10.1.1.12 TFT Screens / INS

Screens / Monitors for MMI application and local control shall be of type 19" TFT screen. In order to reduce
volume and weight of the equipment, use of CRT monitors is prohibited.
5.11. Mechanical & Thermal Design
5.11.1.1.1 Rack layout / AS

EGSE shall be housed in standard 19" racks or consoles to the extent practical; overall height not exceeding 2 m.
This does not apply to COTS computer equipment
5.11.1.1.2 Easy access for maintenance / RoD

The racks and drawers shall be of a modular concept, allowing easy access for maintenance, trouble shooting and
replacement.
5.11.1.1.3 Drawer mounting / RoD

The drawers shall be mounted on telescopic slides or angle bars and shall have locking handles or screw fastening at
the front.
5.11.1.1.4 Self-steering wheels / RoD

EGSE racks - and other GSE items with a mass > 40 kg - shall be mounted on self-steering wheels (castors) for
transport over short distances within a facility. Minimum diameter for these wheels shall be 80 mm.
Racks front wheels steerable. Ist is not recommended to have steerable wheels at the rear side of the rack, if the
weels are sticking out from the racks shape while turning.
5.11.1.1.5 crane hoisting rings / RoD

EGSE racks shall be equipped with crane hoisting rings.
5.11.1.1.6 Rack lifting by standard forlifts / RoD

EGSE racks shall be compatible with lifting by standard forlifts.
5.11.1.1.7 Castor block devices / RoD

EGSE racks shall be either firmly supported on the floor or have devices to block the castors.
5.11.1.1.8 Design for transportation / RoD

Provisions for transportation, handling, and maintenance shall be incorporated in each rack and major unit. The
EGSE mechanical design shall withstand repeated transportation between integration, test, and launch sites without
disassembly.
5.11.1.1.9 Thermal design / RoD

The equipment shall contain adequate cooling capabilities (air in/outlets and fans), to avoid overheating in the
operating environment.
5.11.1.1.10 Rack air outlets / RoD

Air in/outlets shall be on the bottom and top of the rack.

Issue: 0
EGSE Specification
Date: 25.02.2006
5.11.1.1.11 Temperature regulated Fans / RoD

Wherever possible, fans shall be on/off regulated by temperature sensors.
5.11.1.1.12 Connectors physical design / RoD

Electrical connections within the equipment shall be secured to prevent breakage or changes in the electrical
characteristics of outputs as a result of vibration, acceleration or shocks encountered under the specified
environment.
5.11.1.1.13 Connector locking / RoD
External connectors must be equipped with locking devices.
5.11.1.1.14 Connector access / RoD
The access to all connectors shall be such that any individual connector can be mated or demated without the need
to disconnect any other connector.
5.11.1.1.15 Connector mismating / RoD

Mismating of connectors must be physical impossible.
5.12. Electrical & EMC
Achtung: hier ist eine Design-Entscheidun g dringend ntig !

Falls wir wieder - wie bei CryoSat - einen zentralen Isolationstrafo einsetzen wollen, dann mssen wir diesen auch
beschaffen und wir bentigen zumindest 2 Stck davon.
Falls jede SCOE / FEE einen Trenntrafo enthalten soll - wie in anderen Projekten blich (GOCE) - dann mu das
gefordert werden oder wir als Prime schreiben diese "MITUs" aus und stellen diese dann den SCOE-Subcos bei.
During platform/satellite integration the EGSE as a whole will be supplied with power via single / three phase
mains isolation transformer unit according to the following capabilities:
high common mode noise rejection by physically separated primary/secondary windings and separate
shielding for each winding; capacitive coupling between primary and secondary windings shall be < 1pF
class II double/reinforced insulation
compliant with DIN/VDE 0551 / EN 60742 / EN 61010
protection earth at the output connectors
grounding stud for connecting the rack chassis and the protection earth
5.12.1.1.1 Mains power supply / AS

The EGSE interface with facility provided mains power shall be as follows:
One single connection via single phase or three phase power plug depending on the rack total power
consumption
Voltage: 230V( 10%), 16 A max., AC single phase
400V( 10 %), 25 A max., AC three phase
Frequency: 50 Hz 10 %
Connector Type: 230V European Standard
400V IEC 309 CEE 16A or 32 A
It needs to be decided whether all EGSE components shall provide their own "Mains Isolation Transformer Unit"
(MITU) or if there will be provided one single central "Mains Isolation Transformer" for all items in a configuration.
In case MITU requirements have to be added.
5.12.1.1.2 Electrical Isolation / Rod

The following interfaces shall be galvanically isolated:
The FEE crate (rack) main power input shall be double isolated according to EN60742/ EN61558 from rack
structure, crate and any electronics inside the FEE such that no external safety wire is required.

Issue: 0
EGSE Specification
Date: 25.02.2006
all signal interfaces towards the spacecraft shall be driven from earth free power supplies,
the signal ground / return lines shall have no permanent internal connection to drawer/ rack structure but
shall be available at a user defined interface for controlled grounding
LAN I/F card shall be galvanically isolated from drawer/ rack structure
In cases where this requirement cannot be completely fulfilled, all deviations (also partly deviations) shall be
brought to the attention of the customer.
5.12.1.1.3 EGSE rack grounding / TE

The EGSE grounding shall be supported according to the schematics outlined in Figure 5-1 below.
S/C
SCOE - A UNIT
PCDU
Mains POWER
L
PE
N
SIGNALS
SCOE - B
SIGNALS
SIGNALS
SIGNAL(HEATER SIM.)
Mains MAINS
L
PE
N
SCOE -C
OBDH/ TT&C
Signals Signals
Coax-line
Coax-line
Mains
MAINS
L
Facility GROUND BAR S/C GROUND BAR
Grounding_Concept.vsd
Figure 5-1 EGSE Grounding Schematics
5.12.1.1.4 Grounding of desktop EGSE / RoD

EGSE which from practical reasons cannot be installed in racks, shall be grounded as follows:
from a spare mains power outlet inside the rack or
from a facility mains power outlet, if the design provides galvanic isolation to all other EGSE.
5.12.1.1.5 Circuit grounding / RoD

Electrical circuit ground shall be insulated from equipment chassis ground wherever possible. In cases where this is
excluded due to technical / physical reasons (e.g. for RF equipment) an additional separation transformer or DC-
block or other shall be provided to exclude ground loops involving the on-board equipment.

Issue: 0
EGSE Specification
Date: 25.02.2006
5.12.1.1.6 Circuit ground access / RoD

The equipment circuit ground shall be accessible through a grounding stud at the equipment front or rear panel. The
grounding stud shall provide a M8 screw thread and a 13 mm hex-nut to onnect external grounding cable.
5.12.1.1.7 Harness electrical design / RoD

Signal deterioration due to resistive, inductive and capacitive behaviour of the interconnection lines or coax cables
shall be such that all relevant applicable signal specifications are met.
5.12.1.1.8 Isolation Resistrance / TE

The isolation resistance between loads, which are not connected together and between shields and centre conductor
and shield to shield shall be at least 10 MOhm at 500 V dc.
5.12.1.1.9 Shield routing / RoD

Shields shall be routed continuously through any connectors on separate pins.
5.12.1.1.10 Connector Shell Grounding / Rod

Connector shells and outer overall cable shields shall be connected to the drawer/ crate/ rack structure. They shall
not be connected to signal ground or return lines.
5.12.1.1.11 Termination of cable shields / RoD

Termination to ground shall be at one side only to avoid ground loops
This especially applies to EGSE harness connecting to the spacecraft / flight equipment where shields shall be
connected to ground at spacecraft side and shall be unconnected at EGSE side (see figure above). Deviations from
this baseline shall be subject to customer approval.
5.12.1.1.12 Hazardous voltages / RoD

The design shall ensure, that personnel cannot come into contact with exposed conducting surfaces carrying a
voltage > 24 V DC or > 24 V AC peak.
5.12.1.1.13 Test points / RoD

Test points shall be provided to allow easy isolation and identification of failed items without dismounting or
disconnecting other equipment. The test-points shall easy use of measurement probes (e.g. banana jacks or BNC test
points or similar conventional methods).
5.12.1.1.14 Test points short circuit / RoD

Test points shall be short circuit protected, to the extend practical or they shall be secured by other means.
5.12.1.1.15 EMC Design / RoD

The EGSE shall be designed to support EMC tests. Therefore, the EGSE generated background emissions during
EMC tests shall stay at least 10 dB below the level to be verified, and the EGSE shall be capable to withstand
system susceptibility tests without malfunction.
This implies, that equipment which must unavoidably be present in the EMC test chamber shall meet same emission
and susceptibility requirements as the on-board equipment, and, further the stimulus / feedback-cabling to be used
during system EMC tests shall be designed with proper shielding / twisting for a minimum field to cable coupling.
5.12.1.1.16 Bonding resistance / AS

Bonding of adjacent structure parts and equipment within MGSE and EGSE racks shall be accomplished by
metallic contacts providing an ohmic resistance of less than 50 mOhm.
5.12.1.1.17 Permanent open-circuit and short-circuit / Rod

All signal input/output interfaces (video, RF,) must support permanent open-circuit and short-circuit.
5.12.1.1.18 Short circuit stability / Rod

Issue: 0
EGSE Specification
Date: 25.02.2006
All data and signal interface drivers shall survive a short circuit to driver ground, receiver ground or structure
without permanent degradation.

Issue: 0
EGSE Specification
Date: 25.02.2006
5.13. Software Design & Development

The main software constituents for the various EGSE elements is shown in the graphic below.
Layer 3
Test S/W
Layer 2
Application S/W
Layer 1
System Software / Operating System
Figure 5-2 Software Layers

The responsibility for the software deliverance is strictly correlated with the layers as follows:
Layer 3 Test software produced by the Test / AIV team as part of the test and AIV preparation tasks.
All software that is specifically developed by the EGSE user to perform particular tests during the
different phases of the test and AIV program, e.g.: electrical Integration, Function and Performance
tests, Software Verification, Compatibility testing.
Below an overview is given of the test software to be prepared for the various stages of the test and
AIV program. Software in this context includes also the simulation and configuration data sets to be
defined and prepared by the checkout team.
CCS: local data base (TM, TC and EGSE parameter definitions), synoptic display
definitions, automated procedures (control files, test sequences)
FEE: configuration files
Simulators: simulation models
Layer 2 Application software is produced and delivered by the EGSE element suppliers according to the user
requirements. The detailed definition of this software for the various EGSE elements will be found in
the relevant equipment requirements specification.
Layer 1 System Software is commercial software delivered by the EGSE element suppliers as there is the
Operating System (e.g. Linux, Windows) and COTS tools as for example Editors, Interpreter,
Compiler, Graphical Systems, Database Management Systems, Communication Software.
5.13.1.1.1 Layer 2 - Application Software / RoD

Layer 2 software as far as it is not already existing shall generally be designed and developed in accordance to the
Space Engineering Standard for Software (ECSS-E-40B).
5.13.1.1.2 Layer 3 - Test software / RoD

Layer 3 software shall be developed according to the project test software development plan.
5.13.1.1.3 Configuration Control / RoD

Configuration control shall be applied to all three software layers.
5.13.1.1.4 Software Layer organisation / RoD

All three software layers installed on any EGSE computer shall be strictly separated from each other by appropriate
disk and folder organisation.
Layer 1 and layer 2 software shall be installed on a dedicated physical disk, the system disk, where
appropriate, or at least on a dedicated logical disk partition.
For storing Layer 3 software, configuration files and the test data logs a root / home path shall be provided
whos further sub-folder organisation shall be allowed to the user.
No layer 1 and layer 2 items shall be contained in the layer 3 path.

Issue: 0
EGSE Specification
Date: 25.02.2006
5.13.1.1.5 Portable Layer 2 / TE

Layer 2 software shall be easy portable to different hardware of similar type running the same layer 1 - at least the
operating system - software. To achive this:
All layer 2 software shall be located on the system disk / partition on a dedicated root / home path.
Layer 2 software shall NOT be subject to hardware bound licence keys
By copying the contents of the a.m. root / home path layer 2 software shall be portable to another computer.
If required, a copy of drivers and DLL-files shall be provided within this layer 2 directory and a
procedure/manual shall be provided if such files have to be installed on operating system level. A
"ReadMe.Txt" file might be sufficient.
5.13.1.1.6 Backup capability / TE

Backup shall be provided in terms of appropriate backup tool (operating system capability or COTS tool) and
backup storage media (DVD Writer recommended). By means of this utility a bootable system disk image backup
shall be created in order be able to restore the complete system environment as a whole in one go in case of a disk
crash.
5.13.1.1.7 Backup upon delivery / INS

A bootable system disk image backup reflecting the layer 1 and layer 2 software delivery status shall be created and
delivered by the EGSE unit supplier upon equipment delivery.
5.13.1.1.8 Software delivery / INS

All layer 1 and layer 2 software shall be deliverable items. For COTS items the installation media shall be delivered
or a CD/DVD shall be created and delivered in case of installation files without media delivery by the tool supplier.
5.14. Workmanship
5.14.1.1.1 Workmanship / AS
The GSE shall be designed, fabricated and finished to a high quality of fit and finish and for adherence to the
specified requirements. Particular attention shall be given to the absence of burrs and sharp edges which might
cause injury to personnel or damage to flight or ground hardware. Paint finish shall be free of runs, voids, dirt, over-
spray and subsurface voids or contamination. Attention shall be paid to neatness and thoroughness of soldering and
wiring.
5.15. Identification & Marketing
5.15.1.1.1 EGSE identification label / AS

The EGSE identification plates shall be visible, when installed, and their locations shall be defined in the assembly
drawings. If the label size is such that all identifiable criteria cannot be specified, the order of precedence for
identification data shall be as follows, but the part number, serial number and configuration number are mandatory
on all configuration items:
Part number
Serial number
Configuration Item (CI) number
Nomenclature of the item
Contract number
5.15.1.1.2 Container identification label / AS

Each container shall in addition to the above be marked with:
project name
Item All-up-weight

Issue: 0
EGSE Specification
Date: 25.02.2006
Item CoG
Safe Working Load
Bonding point identification
Hoisting point identification
Special safety instructions
Re-usable container marking
content identification / nomenclature with S/N
5.15.1.1.3 Location of identification label / AS

The identification labels of EGSE drawers shall be located such that removal of the drawers is not necessary in
order to ascertain their part number. All Printed Circuit Boards (PCB) and other removable items shall be clearly
marked with their part number. All part numbers shall include their relevant change / revision index.
Instruction plates shall be securely fastened to enclosures instrument panels and shall be placed in positions where
they can easily be read.
Precautionary markings shall be provided as necessary to warn personnel of hazardous conditions and precautions
to be observed.
5.15.1.1.4 Harness identification / AS

A numbering system shall be used for identification of cables, plugs and connectors of all EGSE components. These
ID numbers shall appear on all relevant diagrams, drawings and associated parts lists and manuals. Labeling the
cable itself is outlined in Figure 5-3 below.
max 1 m max 1 m
FPA SCOE *) FPA SCOE *) P08 *)

P05 *) PTI: 715100 PTI: 715100 XMM
FPA SCOE S/N: 006 S/N: 006 RFC 2
Cable Cable S/C Connector

- unit name - unit name - identifier
- PTI no. - PTI no. - S/C name
EGSE Connector - serial no. - serial no. - connected S/S or Bracket
- identifier ...one lable
- connected unit for each connector
Cable_Labels.dsf
P02 *)
FPA SCOE
*) example
Figure 5-3 Harness Identification - Example

Issue: 0
EGSE Specification
Date: 25.02.2006
6. Verification Requirements
The verification process is that part of the subcontractor's task, which demonstrates conformance to applicable
requirements. A satisfactory completion of the verification process is the basis for a contractual acceptance of the
product by the customer.
Requirements in this specification as well as requirements in the dedicated and applicable equipment requirements
specification indicated by the identification and numbering scheme explained in section 1.2 above shall be subjected
to formal verification close out.
As far as the equipment or S/W is a rebuilt from lower level test equipment (e.g. unit tester), the formal verification
of the corresponding functions may be achieved by demonstration of successful use in lower level integration and
testing.
6.1.1.1.1 Test Equipment / nt

Adequate test equipment and simulators shall be made available to support the equipment verification process. This
test equipment is not deliverable and may therefore be recruited from the suppliers laboratory inventory.
Of particular importance are the simulation of the communication interface with the CCS (Core EGSE) and the
simulation of the interfaces with the on-board systems. These shall be fully representative on all protocol layers
including the physical interface. Software test stubs used for such tests are deliverable in source code to the
customer.
6.1.1.1.2 Verification programme / nt

The subcontractor shall establish a verification program that assures that:
The product (H/W and S/W) is in compliance with the specified requirements.
The design is qualified.
The product (H/W and S/W) is in agreement with the qualified design, free from workmanship defects and
acceptable for use.
Qualification is defined as the proof that a design fulfils the requirements with adequate margin.
For re-used software modules / components acceptance test reports / qualification test reports may be used to
demonstrate compliance with the requirements stated. The sub-contractor shall not be required to re-run acceptance
/ qualification tests for existing, re-used software.
In case reference is made to already performed and existing acceptance / qualification in the frame of other space
programs, requirements tracing of the relevant requirements to the existing test procedures and test result has to be
provided as well as the existing test procedures and test reports themselves.
6.1.1.1.3 Verification process / nt

The verification process activities shall be incrementally performed at different levels and in different stages
applying a coherent bottom-up concept and utilizing a suitable combination of different verification methods. The
verification process flow shall be basically subdivided into the following steps:
Identification and classification of all the requirements to be verified
Selection of verification criteria (methods/levels/stages) against identified requirements
Establishing the planning for the associated verification activities
Obtain customer concurrence
Performance of verification tasks and verification control
Completion of verification control and evidence for verification close-out
Customer review and final approval.
All above tasks shall be executed in accordance to \SD4\.
6.1.1.1.4 Test Conditions and Tolerances / nt

All specific support test equipment must be compliant with the intended purpose, within its useful life and
calibration.
The test tolerances quoted in the specifications shall be applied to the nominal test values specified. The tolerance of
test parameters specifies the maximum allowable range within which the specified test level (input level) may vary
and does not take into account instrument accuracy.

Issue: 0
EGSE Specification
Date: 25.02.2006
All instruments and measurement equipment used in conducting the tests shall have an accuracy of better than one
third of the tolerance for the variable to be measured unless otherwise specified.
Note: This is to be recorded in as-run-test procedure/test report
6.1.1.1.5 Test Data Documentation / nt

For tests performed using automated test equipment running scripts, batch files or generally S/W the test procedures
and -reports shall provide the relevant test-step information in the S/W source code or in the print-out/protocol of
each test S/W item.
Test Report shall include configuration control information (compilation date, check-sum, version/revision-number,
etc.) for each test S/W item used for the reported test.
6.1.1.1.6 Incremental Test Program / nt

The specified item shall undergo a incremental test program, starting at module level up to system level.
Objectives of these tests shall be at least:
Function
Performance
Interface
Failure Tolerance
6.1.1.1.7 Definition of Tests / nt

Details of the tests, test planning, test requirements and test procedures shall be defined/specified by the
subcontractor in accordance with the verification method given in this specification and shall be approved by the
customer in advance.
6.1.1.1.8 Failure Tolerance Testing /nt

Module level testing shall include testing of tolerance against erroneous input data and signals. This shall include as
a minimum:
User input error
Corrupted input data from external sources
6.1.1.1.9 Functional Performance Test / nt

The product functional performance test shall include at least:
all interfaces
all system functions
all system command functions
all telecommand and telemetry functions
all I/F board functions
all operational modes and
all transitions applicable.
under the specified performance loads.
6.1.1.1.10 Objectives / nt
The objective of the functional performance test shall not only be the verification of the user requirements but also
the verification of the correct and consistent system behavior.
6.1.1.1.11 Performance / nt
The functional performance test shall include testing of the quantifiable functions and parameters of the product
(performance, accuracy, etc.) in all operational modes specified.


EADS - SWARN - EGSE Specifications: Requirements

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

EADS - SWARN - EGSE Specifications: Requirements

Caricato da

Copyright:

Formati disponibili

SWARM

Doc-No: SW-RS-EAD-EG-0001 Issue: 0 Date: 25.02.2006

Title: EGSE Specification - Global EGSE Requirements -

Prepared by: T.Schuler Date:

Distribution: See Distribution List last page

EADS Astrium ENS, Friedrichshafen Page 1

Issue Date Sheet Description of Change Release

EADS Astrium ENS, Friedrichshafen Page 2

2. EGSE Configurations and Usage ................................................................7

3. EGSE Building Blocks / EGSE Components ...........................................18

4. Communication Requirements .................................................................27

EADS Astrium ENS, Friedrichshafen Page B-i

4.1.1. Command and Control .................................................................................. 27

EADS Astrium ENS, Friedrichshafen Page B-ii

ToC - Figures & Tables

Table 2-1 EGSE Components Usage ........................................................................................ 14

EADS Astrium ENS, Friedrichshafen Page B-iii

Chapter 1 this chapter, referenced project documents and referenced standards.

<para-n> <keyword> / [<verification method>]

1 for term definition see 1.3 below.

EADS Astrium ENS, Friedrichshafen Page 2

1.3. Terms and Definitions

EADS Astrium ENS, Friedrichshafen Page 3

1.4.1. Applicable Documents

\AD1\ EGSE Interface Control Document SW-ID-EAD-EG-0001

1.4.2. Reference Document

\RD1\ Swarm Packet Utilisation Standard SW-ID-EAD-SY-000x

\SD1\ ESA Packet Telecommand Standard ESA PSS-04-107

EADS Astrium ENS, Friedrichshafen Page 4

1.5. List of Acronyms

EADS Astrium ENS, Friedrichshafen Page 5

P/L Payload SRR System Requirements Review

EADS Astrium ENS, Friedrichshafen Page 6

2. EGSE Configurations and Usage

2.1. EGSE Configurations

2.1.1. Software Verification Facility (SVF)

S/C & Environment Simulator

Figure 2-1 SVF

EADS Astrium ENS, Friedrichshafen Page 7

2.1.2. Real-Time Testbed (RTB)

DC/DC Telemetry RS422, UART, SW Load

external I/F Unit &

Power FE TM/TC FE Simulator I/F

Figure 2-2 RTB

EADS Astrium ENS, Friedrichshafen Page 8

Power FE TM/TC FE Simulator I/F

Figure 2-3 extended RTB

EADS Astrium ENS, Friedrichshafen Page 9

2.1.3. Satellite Testbed (STB) or Flat-Sat

external OVP / OCP

Figure 2-4 STB

EADS Astrium ENS, Friedrichshafen Page 10

2.1.4. Satellite EGSE

Figure 2-5 Satellite EGSE

EADS Astrium ENS, Friedrichshafen Page 11

2.1.5. Launch Site EGSE

Battery PCDU OBC

external OVP / OCP external I/F Unit &

Figure 2-6 Launch Site EGSE

EADS Astrium ENS, Friedrichshafen Page 12

Figure 2-7 RF Suitcase

EADS Astrium ENS, Friedrichshafen Page 13

2.2. EGSE Usage