EGSE Specification - Global EGSE Requirementsemits.sso.esa.int/emits-doc/ASTRIUMLIM/SWARM_S... · SWARM © EADS Astrium ENS ... Title: EGSE Specification - Global EGSE Requirements

SWARM

© EADS Astrium ENS, Friedrichshafen Page 1 File: SW-RS-EAD-EG-0001_issue-0_EGSE_Spec.doc

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 payment of damages. All rights are reserved in the event of the grant of a patent or the

registration of a utility model or design.

EADS Astrium GmbH D-88039 Friedrichshafen

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

© EADS Astrium ENS, Friedrichshafen Page B-i File: SW-RS-EAD-EG-0001_issue-0_EGSE_Spec.doc

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


Issue: 0

EGSE Specification

Date: 25.02.2006

© EADS Astrium ENS, Friedrichshafen Page B-ii File: SW-RS-EAD-EG-0001_issue-0_EGSE_Spec.doc

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


Issue: 0

EGSE Specification

Date: 25.02.2006

© EADS Astrium ENS, Friedrichshafen Page B-iii File: SW-RS-EAD-EG-0001_issue-0_EGSE_Spec.doc

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


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 End´s / SCOE´s 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 SCOE´s / 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/C’s 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 ACK Acknowledge AD Applicable Document AFT Abbreviated Functional Test AIT Assembly Integration and Test AIV Assembly, Integration and Verification AOCS Attitude and Orbit Control Subsystem API Application Programming Interface APID Application Process Identifier ->

CCSDS Packet Primary Header Field

B BER Bit Error Rate BNF Backus-Naur Form bps bits per second BPSK Binary Phase Shift Keying

C CADU Channel Access Data Unit C&C Command and Control CCS Central Checkout System == Core

EGSE CCSDS Consultative Committee for Space

Data Systems CDR Critical Design Review CFE Customer Furnished Equipment CLCW Command Link Control Word CLTU Command Link Transmission Unit CMD Command COP Command Operation Procedure COTS Commercial Of The Shelf CPDU Command Pulse Distribution Unit CPU Central Processor Unit CRC Cyclic Redundancy Check CUC CCSDS Unsegmented time Code CVCDU Coded VCDU

D DBMS DataBase Management System DC Direct Current dB deci Bel dBc dB related to center frequency dBm dB related to 1 mW DFH Data Field Header DSU Data Switching Unit

E ECSS European Cooperation for Space

Standardization EGSE Electrical Ground Support Equipment EID Error or Event Identifier EM Engineering Model EMC Electromagnetic Compatibility ESA European Space Agency

F FCL Foldback Current Limiter

FEE Front End Equipment FID Failure Identifier / Failure Code FM Flight Model FMECA Failure Modes Effects & Criticality

Analysis FPT Full Performance Test

G GSE Ground Support Equipment GUI Graphical User Interface

H H/W Hardware HCI Human Computer Interface (-> MMI) HK House-Keeping

I I/F Interface ICD Interface Control Document ID Identifier IP Internet Protocol IST Integrated System Test

J

K kbps 210 Bits per second

L LAN Local Area Network LCL Latch Current Limiter LPS Launch Power Supply LOL Limit of Liability LSB Least Significant Bit

M Mbps 220 Bits per second MDVE Model based Development and

Verification Environment MGSE Mechanical Ground Support

Equipment MLI Multi-Layer Insulation MMI Man-Machine Interface (-> HCI) MSB Most Significant Bit MTBF Mean Time between Failure

N N/A Not Applicable NAK Not-Acknowledge NDIU Network Data Interchange Unit NRZ Non Return to Zero NTP Network Time Protocol

O OBC On-Board Computer OBDH On-Board Data Handling OCOE Overall Checkout Environment ==

Core EGSE

P


Issue: 0

EGSE Specification

Date: 25.02.2006


P/L Payload PA Product Assurance PCB Printed Circuit Board PCM Pulse Code Modulation PCU Power Control Unit PDU Power Distribution Unit PFM Proto-Flight Model PID Process Identifier PLL Phase Lock Loop PLM Payload Module PUS Packet Utilisation Standard

Q QM Qualification Model QPSK Quadrature Phase Shift Keying QR Qualification Review

R RD Reference Document RF Radio Frequency RHCP Right Hand Circular Polarisation RID Report Identifier RID Review Item Discrepancy RMS Root Mean Square RS Reed-Solomon RX Receiver

S S/C Spacecraft S/S Subsystem S/W Software SAS Solar Array Simulator SCOE Special Check-Out Equipment SDR System Design Review SFT System Functional Test SOL Switch-Off Line SRDB Satellite Reference Database

SRR System Requirements Review STM Structural/Thermal Model SVF Software Verification Facility

T TBC To be confirmed TBD To be defined TC Telecommand TCP Transmission Control Protocol TCS Thermal Control Subsystem TES Test Execution System TM Telemetry TTC Tracking, Telemetry & Command TX Transmitter

U UART Universal Asynchronous Receiver

Transmitter UQPSK Unbalanced Quadrature Phase Shift

Keying USO Ultra Stable Oscillator UTC Universal Time Coordinated

V VC Virtual Channel VCDU Virtual Channel Data Unit VCID Virtual Channel Identifier VCO Voltage Controlled Oscillator

W w/o without

X

Y

Z


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.

Figure 2-1 SVF

Simulator I/F

Environment Models

Equipment Models

SpaceEnvironment

S/CDynamics e.t.c.

ActuatorModels

SensorModels

SubsystemModels e.t.c.

SimulationModels

DB

S/C & Environment SimulatorSimulator I/F

On-Board SW(incl. AOCS SW)

Equipment ModelsOBC HW

Model

On-Board Computer Simulator

EGSE_Configurations.vsd/SVF

SatelliteReferenceDatabase(SRDB)

Test Result Database

CCSKernel

I/F Handler

MMICCSAITDB

CCS

LAN


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.

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.

EGSE_Configurations.vsd/RTB

Environment Models

Equipment Models

S/C & Environment / Real-TimeSimulator

Simulator I/F

OBC BB -> EM

DC/DCConverter

TelecommandDecoder

TelemetryEncoder

Discrete I/O RS422, UART,A/D, D/A

SW LoadI/F

Simulator I/F

S/C (Avionics)HW Interfaces

S/C / AvionicsSimulation FE

O/B SWLoad & DumpStation (TE)

Pow

er

TC B

ypass

TM B

ypass



CCSKernel

I/F Handler

MMICCSAITDB

CCS

external I/F Unit &TM/TC Baseband

Processor

TM/TC FE

EGSE LAN

MassMemory

PL S

cience Data

RS422

LCL/FCLEmulation

Power FE


Issue: 0

EGSE Specification

Date: 25.02.2006


Figure 2-3 extended RTB

LCL/FCLEmulation

Power FE

EGSE_Configurations.vsd/eRTB

Environment Models

Equipment Models

S/C & Environment / Real-TimeSimulator

Simulator I/F

OBC BB -> EM

DC/DCConverter

TelecommandDecoder

TelemetryEncoder

Discrete I/O RS422, UART,A/D, D/A

SW LoadI/F

Simulator I/F

S/C (Avionics)HW Interfaces

S/C / AvionicsSimulation FE


Pow

er

TC B

ypass

TM B

ypass



CCSKernel

I/F Handler

MMICCSAITDB

CCS


Processor

TM/TC FE

LAN

MassMemory

PL S

cience Data

RS422

Electronics

Heads

STR

STROGSE

GPS

tbd.

tbd.

Test Harness


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.

Figure 2-4 STB

GPSACC

EFIASM

EGSE_Configurations.vsd/STB

OBC


Pow

er

TC B

ypass

TM B

ypass

TC

TM

C&

C

C&

C

C&

C TC

TM

S-B

and RF



CCSKernel

I/F Handler

MMICCSAITDB

CCS

PowerSCOE

28VMain-Bus

Power Supply

28VBatteryCharge

Power Supply

external OVP / OCP

Solar-ArraySimulation

C&

C

Instr.EGSE

PL ScienceData

S-BandSCOE

Test & MeasurementEquipment

TXModulator

RXDemod.

RF Matching Unit


Processor

TM/TC FE

LAN

PCDU

Measurem

ent &S

ense Lines

S-Band AOCSSensors

Electronics

Heads

STR

STROGSE

ASCVFM

table-top-setup / Test-Harness

Battery(EM)

Instrument EGSEEquipment

details t.b.d.


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.

Figure 2-5 Satellite EGSE

GPSACC

EFIASM

EGSE_Configurations.vsd/SAT

OBC


Pow

er

TC B

ypass

TM B

ypassTC

TMC

&C

C&

C

C&

C TC

TM

S-B

and RF



CCSKernel

I/F Handler

MMICCSAITDB

CCS

PowerSCOE

28VMain-Bus

Power Supply

28VBatteryCharge

Power Supply

external OVP / OCP

Solar-ArraySimulation

C&

C

Instr.EGSE

PL ScienceData

S-BandSCOE

Test & MeasurementEquipment

TXModulator

RXDemod.

RF Matching Unit


Processor

TM/TC FE

LAN

PCDU

Measurem

ent &S

ense Lines

S-Band AOCSSensors

Electronics

Heads

STR

STROGSE

ASCVFMBattery

Instrument EGSEEquipment

details t.b.d.

Spacecraft

TC TMI/F to NDIU

(provided by ESOC)


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.

Figure 2-6 Launch Site EGSE

EGSE_Configurations.vsd/LEG

OBC

Pow

er

TC B

ypass

TM B

ypass

C&

C

C&

C

TC

TM

UmbilicalInterfaces



CCSKernel

I/F Handler

MMICCSAITDB

CCS

PowerSCOE

28VMain-Bus

Power Supply

28VBatteryCharge

Power Supply

external OVP / OCP external I/F Unit &TM/TC Baseband

Processor

TM/TC FE

LAN

PCDU

Measurem

ent &S

ense Lines

Battery

Spacecraft

TMI/F to NDIU

(provided by ESOC)


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.

Figure 2-7 RF Suitcase

EGSE_Configurations.vsd/RFS

OBC (EM)

Pow

er

TC B

ypass

TM B

ypass

S-BandTransponder

Pow

er

C&

C

TC

TM

GroundStationRX / TX


CCSKernel

I/F Handler

MMICCSAITDB

CCS


Processor

TM/TC FE


LAN

PayloadTM

HK TM

TC

S-BandRF-Link

LCL/FCLEmulation

Power FE

C&

C


Issue: 0

EGSE Specification

Date: 25.02.2006


2.2. EGSE Usage

2.2.1. Use of EGSE Components

SVF RTB &

eRTB

STB SAT EGSE

Launch Site

EGSE

RF- Suit- 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 EGSE´s - - 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


EGSE Components

EGSE Configurations

CC

S

TM/TC

FE

Power FE

S-Band SC

OE

Pwr SC

OE - SA

S

Pwr SC

OE - LPS

O/B

S/W Load Station

S/C Sim

ulation FE

S/C Environ Sim

ulator / RTS

On-B

oard Com

puter Simulator

Instrument EG

SE

STR O

GSE

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

eRTB X X X 0 0 0 X X X 0 0 tbd. recruited from RTB + GPS + STR + tbd.

RF-Suitcase X X X 0 0 0 0 0 0 0 0 0 recruited from RTB & SVF-x (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

Satellite EGSE 3 1 1 0 X 0 1 X 0 0 0 0 0

reduced EGSE configuration: S-Band SCOE & O/B S/W Load PC shared with Sat EGSE-1 or -2 as needed no SAS SCOE will be provided for this configuration

Launch Site EGSE-1 X X 0 0 0 X 0 0 0 0 0 0 recruited from Sat-EGSE-1



total 7 4 1 2 2 3 3 1 4 3 0 2 Legende: 1 EGSE item to procure

X EGSE item re-used from other 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.

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 SCOE´s. 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.

CCS SVF-2(SVF Config.)

SVF-2

Simulation PC 2(Linux PC)

OBC Sim(Gaisler ERC32)

S/C Environment/ Real-Time Sim


SVF-1





SVF-3





Issue: 0

EGSE Specification

Date: 25.02.2006


Figure 2-9 EGSE evolution

CDMUEM

CCS Sat-0(Satellite Config.)

TM/TC FESet-0

Power FE

Simulation FE

Real-Time SimVME / VXworks

RTB &eRTB

tbdHW in the

loop

CDMUEM


TM/TC FESet-0

Power FE

RF-Suitcase

S-BandTransponder

CDMUEM

Power FE

Simulation FE

Real-Time SimVME / VXworks

LaunchSupportEGSE

tbdHW in the

loop

RF-Suitcase

RTB &eRTB

S-BandTransponder


TM/TC FESet-0

S-Band SCOESet-1 or Set-2

LPS SCOESet-3

SatEGSE 3

Launch SiteEGSE 3


TM/TC FESet-1

S-Band SCOESet-1

LPS SCOESet-1

STB &Sat

EGSE 1

Launch SiteEGSE 1

SAS SCOESet-1


TM/TC FESet-1

LPS SCOESet-1


TM/TC FESet-3

LPS SCOESet-3


TM/TC FESet-2

S-Band SCOESet-2

LPS SCOESet-2

SatEGSE 2

Launch SiteEGSE 2

SAS SCOESet-2


TM/TC FESet-2

LPS SCOESet-2

OBC S/W LoadPC Set-3




OBC S/W LoadPC Set-1 or 2


TM/TC FESet-3

Usage shared betweenSatellite EGSE Set-1 or Set-2and Satellite EGSE Set-3 as

needed


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.

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

C&C Pkt exchange

CCSKernel

AIT/AIVDB

S/C TC Pkts

S/C TM Pkts

TC Echo Pkts

EG

SE

LA

N to

FE

/ S

CO

E /

Inst

r. E

GS

EFE HK TM Pkts

S/C TM Pktsforwarding to Instrument EGSE

TC Echo Pktsforwarding to Instrument EGSE

TM/TC

Raw Data

Engineering Data

OperatorWorkstation

DBPopulation

TRDB Control

Site

LA

N

CCS

TRDBTest Dataretrieved

Test DataArchive


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 (AP´s, Synoptic’s and CCS AIT DB) at start-up.

The communication between the CCS and any front end equipment (SCOE´s, 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.

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

CCSKernel

TM/TC FEI/F Handler

TM/TC FEController

C&C MsgEGSE HK TMS/C TM PktsS/C TC Pkts

TC Echo Pkts

CCS_logical_links.vsd

S-Band SCOEI/F Handler

C&C MsgEGSE HK TM

S-BandSCOE

Controller

LPS SCOEI/F Handler

LPS SCOEController

SAS SCOEI/F Handler

SAS SCOEController

C&C MsgEGSE HK TM

C&C MsgEGSE HK TM

Instr. EGSEI/F Handler

Instr. EGSEController

C&C MsgEGSE HK TM[S/C TM Pkts][TC Echo Pkts]


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

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

TC (RF)

On-Board Computer (OBC)

S-Band SCOE

S-BandTransponder

S-B

and

RF-

Link

TC B

ypas

s A

/ N

omin

al

TM B

ypas

s A

/ N

omin

al

TC B

ypas

s B

/Red

unda

nt

TM B

ypas

s B

/ R

edun

dant

TM (RF)

TC fr

om N

DIU

TM to

ND

IU

C&C Pkt exchange

TM/TC FE GUIWorkstation

TMArchiving

S/C TC Pkts

S/C TM & FE HK TM Pkts

TC Echo Pkts

EG

SE

LA

N to

Cor

e E

GS

E

TM/TC Front EndSwitch Unit

TCEncoder

TC EchoDecoder

TMDecoder


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 LCL´s, class 2 (2A) - tbc. • 2 FCL´s, class 2 (2A) - tbc.

To power additional S/C sub-systems in extended RTB configuration by the following power output lines: • tbd. LCL´s, class 2 (2A) - tbc. • tbd. FCL´s, 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


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

TM/TCFE

Receiver

Transmitter

RFMatching

UnitS/C

S-BandSCOE Controller

MeasurementDevices

Command& Control

EGSE LAN(to CCS)

S-Band SCOE


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.

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:

30 m SAS cable

SAS PowerSupplyPSxx

SAS PowerSupplyPSxx

MainbusPower Supply

BBPS

Battery PowerSupplyBAPS

LPS SCOE

FCL

FCL

FCL

FCL to S

/C c

onsu

mer

s

sense lines

sense lines

STB-2Bracket

30 m LPS cable

Battery BatteryRelay

SAS PowerSupplyPSxx

sense lines

11 Sections

OVP

OVP

OVP

ShuntStage x

Shunt StageController

SequentialShunt

Regulation11 stages

SAS SCOE

PCDU

TMAcquisition

Battery Voltage HKMainbus Voltage HK

Battery Current HK


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.

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

SAS 01Power Supply Safety Switch

externalOVP/OCP

Module

SAS 01 Power Line

SAS 01 Voltage sense

I

U

SAS 12Power Supply

externalOVP/OCP

Module I

U

Safety Switch

SASSCOE

Controller

GPIB

DataAcquisition

andCommanding

SAS 12 Power Line

SAS 12 Voltage sense

SAS 02Power SupplySAS 03

Power SupplySAS 04Power Supply

SAS 10Power SupplySAS 11

Power Supply


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.

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

BatteryPower Supply Safety Switch

externalOVP/OCP

Module

Battery Power

Batt. Voltage sense

I

U

MainbusPower Supply

externalOVP/OCP

Module

Mainbus Power

Mainbus Voltage sense

I

U

currentcomparator

Battery current HK

500 mAref.

voltagecomparator

Battery voltage HK

Mainbus voltage HK

5analog measurement

channels

6analog Thermistor

measurement channels

Power Supply

6S/C relaycontactRelay Status channels

BHP / SHPPulse CmdModules

4

6

Bipolar High PowerPulse Command lines

Standard High PowerPulse Command lines

SimulatedSeparation Switches

10

10

Safety Switch

LPSSCOE

Controller

inte

rnal

LA

N /

GP

IB

6

DataAcquisition

andCommanding

under-voltage (UV)

protect


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.xTRANSFER mandatory 1 RESET mandatory 2 RESTART optional 3 START / STOP HALT / CONTINUE

optional 4

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 FEE´s to communicate to the CCS is the Ethernet network. The topology of such network is driven by the FEE´s 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.

Figure 4-1 EGSE LAN Topology using unshielded Cable

Figure 4-2 EGSE LAN Topology using Fibre Optics

4.2.1.1.1 Communication Interface to CCS / INS

CCS

EGSE LAN Switch

FEE / SCOE A

FEE / SCOE B

FEE / SCOE C

Cat.5 RJ45 Patch Cable UTP

Cat.5 RJ45 Patch Cable UTP

TX <-> FXMedia-

Converter

CCS

EGSE LAN Switch

FEE / SCOE A

FEE / SCOE B

FEE / SCOE C

Cat.5 RJ45 Patch Cable STPCat.5RJ45Patch

Cable STP

TX <-> FXMedia-

Converter

Multi-Mode FO Cable


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 FE´s 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 4th byte = x

Description

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: -50°C to +60°C • 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: 16°C to 27°C • 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: 10°C to 27°C • 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: -40°C to +60°C • 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 nötig ! Falls wir wieder - wie bei CryoSat - einen zentralen Isolationstrafo einsetzen wollen, dann müssen wir diesen auch beschaffen und wir benötigen zumindest 2 Stück 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-Subco´s 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.

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.

S/C

PCDU UNIT

SIGNALS

POWER

SCOE - A

Grounding_Concept.vsd

MainsLPEN

MAINS

SCOE -C

MAINS

SIGNAL(HEATER SIM.)

SCOE - B

SIGNALS

SIGNALS

LPEN

Mains

Facility GROUND BAR

MainsL

N

OBDH/ TT&C

Signals

Coax-line

Signals

Coax-line

S/C GROUND BAR


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.

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 who´s 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.

Layer 2Application S/W

Layer 3Test S/W

Layer 1System Software / Operating System


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.

Figure 5-3 Harness Identification - Example

...one lablefor each connector

Cable- unit name- PTI no.- serial no.

FPA SCOE *)PTI: 715100S/N: 006

EGSE Connector- identifier- connected unit

P05 *)FPA SCOE

S/C Connector- identifier- S/C name- connected S/S or Bracket

P02 *)FPA SCOE

P08 *)XMMRFC 2

FPA SCOE *)PTI: 715100S/N: 006

max 1 m max 1 m

*) example

Cable- unit name- PTI no.- serial no.

Cable_Labels.dsf


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.