gaia.asu.sp.esm.00005 rts requirements...

Gaia

GAIA.ASU.SP.ESM.00005 Issue 1

of 94

Document Autogenerated from DOORS Module : /GAIA Prime/Level 4/4_60 EGSE/4_60_1 RTS Simulator/RTS Requirements Specification GAIA.ASU.SP.ESM.00005 (RTS Requirements Specification).doc

Real Time Simulator Requirements Specification

CI CODE: 13000 DRL Refs :

UK EXPORT CONTROL RATING : Not Listed

Rated By :

Prepared by: Date:

Checked by: Date:

Approved by: Date:

Authorised by: Date:

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

© EADS Astrium Limited 2006

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

communicated to any person without written permission from the owner.

EADS Astrium Limited, Registered in England and Wales No. 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

Gaia


of 94

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

GAIA.ASU.SP.ESM.00005 (RTS Requirements Specification).doc

INTENTIONALLY BLANK

Gaia


of 94



CONTENTS 1 INTRODUCTION AND SCOPE..................................................................................................................6

1.1 Introduction..........................................................................................................................................6 1.2 Scope ..................................................................................................................................................6 1.3 Summary Description..........................................................................................................................7 1.4 Real Time Simulator Test Benches ....................................................................................................7

1.4.1 Functional Validation Bench ........................................................................................................7 1.4.2 Software Verification Facility........................................................................................................8 1.4.3 Avionics Model Bench..................................................................................................................9 1.4.4 Spacecraft PFM AIT.....................................................................................................................9 1.4.5 Simulated AIT (SimAIT) .............................................................................................................10 1.4.6 Operational Verification Facility (OVF) ......................................................................................10

1.5 Terminology ......................................................................................................................................10 1.5.1 Data Terminology.......................................................................................................................10

2 DOCUMENTS ..........................................................................................................................................11 2.1 Project Documents............................................................................................................................11

2.1.1 Applicable Documents ...............................................................................................................11 2.1.2 Reference Documents ...............................................................................................................11 2.1.3 Standards...................................................................................................................................11

3 RTS REQUIREMENTS ............................................................................................................................12 3.1 System Level Definition.....................................................................................................................13 3.2 Performance Requirements ..............................................................................................................14

3.2.1 Timing and Synchronization ......................................................................................................14 3.2.2 Simulation Performance. ...........................................................................................................15

3.3 Functional Requirements ..................................................................................................................16 3.3.1 RTS Core Application ................................................................................................................16 3.3.2 Simulated Spacecraft Model Layer............................................................................................19 3.3.3 ERC32 Emulator ........................................................................................................................59 3.3.4 Emulator Interface Layer ...........................................................................................................60 3.3.5 Simulated CDMU Model Layer ..................................................................................................61 3.3.6 TM/TC SCOE Simulator.............................................................................................................62 3.3.7 Initialization ................................................................................................................................63 3.3.8 Memory Mapping .......................................................................................................................67 3.3.9 Command and Control Interface................................................................................................68 3.3.10 SimAIT Model Layer ..................................................................................................................71 3.3.11 Data Logging Cycle....................................................................................................................72 3.3.12 Error Detection...........................................................................................................................74 3.3.13 RTS Man Machine Interface (MMI)............................................................................................75 3.3.14 RTS to EGSE Real-time Network Interface ...............................................................................78

3.4 Phased Delivery Requirements ........................................................................................................82 3.4.1 Delivery Phase 1........................................................................................................................82 3.4.2 Delivery Phase 2........................................................................................................................83 3.4.3 Delivery Phase 3........................................................................................................................83 3.4.4 Delivery Phase 4........................................................................................................................84

4 PA REQUIREMENTS...............................................................................................................................85 5 VERIFICATION REQUIREMENTS ..........................................................................................................86

5.1 General..............................................................................................................................................86 5.2 Test Equipment .................................................................................................................................86 5.3 Verification Program..........................................................................................................................86 5.4 Verification Process ..........................................................................................................................87 5.5 Project Specific Verification Requirements .......................................................................................87 5.6 Specific Requirements On Tests ......................................................................................................88

5.6.1 General ......................................................................................................................................88 5.6.2 RTS Functional Tests ................................................................................................................88 5.6.3 RTS Performance Tests ............................................................................................................88 5.6.4 RTS to EGSE Interface Tests....................................................................................................89

Gaia


of 94



6 MAINTENANCE & SPARES ....................................................................................................................90 7 List of Acronyms.......................................................................................................................................91

TABLES Table 3.3-1: Model Execution and I/O Timing .................................................................................................20

FIGURES Figure 1.4-1: Real Time Simulator (SVF Configuration) ...................................................................................8 Figure 1.4-2: Real Time Simulator (Avionics Model Bench Configuration) .......................................................9 Figure 3.3-1: RTS Core Application State Diagram ........................................................................................16 Figure 3.3-2: Real Time Network Usage .........................................................................................................79 Figure 3.3-3: Real Time Network Timing.........................................................................................................81

Gaia


of 94



INTENTIONALLY BLANK

Gaia


of 94



1 INTRODUCTION AND SCOPE

1.1 Introduction

This document establishes the design, performance, interface and verification requirements of the Real Time Simulator (RTS) for the Gaia Project.

The RTS is a primary element of a model-based architecture capable of modelling the satellite mission environment.

Gaia is a scientific mission of the European Space Agency (ESA) which will rely on the proven principles of the previous Hipparcos mission to create an extraordinarily precise three-dimensional map of about one billion stars throughout our galaxy and beyond.

Gaia will provide astrometric measurements of all objects to 20 mag, with multicolour multi-epoch photometry and radial velocities for objects brighter than 16-17 mag. Accuracy's are better than 10 microarcsec at 15 mag. The envisaged experimental operations principle is a continuous scanning of the sky on great-circles with constant inclination to the Sun. Mainly because of the high thermal stability requirements, the current orbit baseline, a Lissajous orbit around the L2 Libration point in the Earth-sun system has been selected.

1.2 Scope

The document in hand comprises the contractually relevant technical requirements and constraints for the Gaia Real Time Simulator. This includes:

• The performance, design and interface requirements.

• The testing and verification requirements.

Requirements within this document are shown in an italic font. Each requirement is preceded by a summary line that contains:

• The Doors Requirement Number, in the form 'RTS-xxx/', where xxx is a unique number.

• A link to the upper level user requirements document, in the form 'RTS_URD,xxx/', where applicable, or 'CREATED/' if not.

• The Verification Method(s) to be applied for the requirement, using codes as follows: (where more than one method is listed, all shall apply)

• T - Test

• A - Analysis

• R - Review

• I - Inspection

• S - Similarity

The requirement text follows the summary line. If tables are considered as part of requirement they are referenced clearly in the text and inserted after and separated from the requirement and are managed as free text attached to the identifier requirement.

All document elements, which are not presented in the format explained above are not requirements and will not be verified or tracked.

Gaia


of 94



1.3 Summary Description

The RTS is used during various stages of build to allow testing of the onboard software through closed-loop testing of the AOCS units. It comprises the following test features:

Simulation of the mission environment. Simulation of the Spacecraft thermal and dynamic systems. Simulation of Spacecraft units, except the on-board computer (CDMU). Simulation of the CDMU peripheral components. Emulation of the CDMU Processor on which the Central Software (CSW) can be loaded and executed. Simulation of the Spacecraft EGSE

1.4 Real Time Simulator Test Benches

Using a model-based test philosophy, the following Test Benches are identified:

• Functional Validation Bench (FVB).

• Software Verification Facility (SVF) - see Figure 1.4-1.

• Avionics Model Bench (AVM) - see Figure 1.4-2.

• Spacecraft PFM AIT.

• Simulated AIT (SimAIT) - see Figure 1.4-1.

• Operations Verification Facility (OVF) - see Figure 1.4-1.

The RTS is used as whole (or in part) of each of these Test Benches (with the exception of the FVB) as discussed below.

1.4.1 Functional Validation Bench

The FVB is a pure numerical simulation facility primarily used for initial validation of AOCS algorithms, developed as part of the Central Software (CSW), and initial integration of the AOCS Models.

Note: The FVB does not utilize the Real Time Simulator but it is intended that AOCS Models used by the FVB facility are reused by the Real Time Simulator.

Gaia


of 94



1.4.2 Software Verification Facility

The SVF is a pure numerical simulation facility primarily used for - but not restricted to - central software (CSW) verification and validation using the ERC32 Emulator.

It allows for execution, test and debugging of the CSW within a simulated CDMU connected to a simulated Spacecraft and Environment.

The fidelity of the Models included in the SVF environment is such that these Models, as a minimum, must simulate all functions which are addressed by the CSW.

The SVF is used for SW/SW integration and the (simulated) HW/SW integration of the CSW, followed by extensive system simulation, S/W verification, procedure debugging, etc.

In this configuration, the RTS may be controlled remotely using the Central Checkout System (CCS), or using the RTS MMI.

SharedMemory Area

Simulated CDMU Model Layer(redundancy not shown)

Simulated SpacecraftModel Layer

ThrustersLatch Valves

HPCPress TDRsThermistorsSep Straps

uProps

InitModule:1. Configure Models2. Init Model Parameters3. Configure Internal TM4. Initialise Internal TM5. Default Housekeeping (HK)

LAN

ModelIni

HKIni

SimTMIni

Command&Control Interface (C&C):1. Simulator Control (Start/Stop ...)2. Re-configure Init Parameters3. Set Model Parameters4. Set SimTM5. Schedule SimTM Logging

Control ?Local

Rem

oteIniConfig Editor

Env

ironm

ent

Power(PCDU)

Thermal

Dynamics

TM/TC Interface(CCSDS-Source

Packet Level withTCP/IP Protocol)

TMTC SCOESimulator

Safe GuardMemory EEPROM

MPEs

STRs

Mem

ory

Map

ped

Mod

el In

terfa

ce L

ayer

FSSs

Gyros

EIUs

FPA VPU1-7

PDHUs

Dire

ct I/

OM

appi

ngHPCs

Alarms

Command &Control

ReconfigurationUnit

RAM

REAL TIMESIMULATOR

OnB

oard

TM

/TC

TM, X-Band10MBbps

TM, X-Band62.5kBbps

TC, X-Band4kBbps

Control ?Local RemoteTM/TC Local Interface:

1. Archive2. Send TC3. Display TM

Central Checkout System (CCS)

Arrays

Battery

LAN

ERC32 Emulator

CSW

Heaters

TRSPsRFDULGAs

PAA

Dire

ct I/

OM

appi

ng

Transponder Interface Unit

TCDecoder

TM FrameGenerator

DirectTM/TC

MemoryMapping

Sequence Exec

Local

Sequence Files

SeqEditor

Timing & SyncModule (SCET)

ERRORHANDLER

LogCycle:1. Log SimTM2. Error/Message Log

CDUs 1553

Bus

PLM

Mod

el15

53 B

us A

/BE

FM M

odel

RTS CoreApplication

1PPS

TimeSynchModule

1PPSpS_64Hz

EEPROM

Mass Memory

Mem

ory

Map

ped

Mod

el In

terfa

ce L

ayer

PLM

155

3B

US

I/F

Emulator Interface Layer

EFM

155

3B

US

I/F

SCET

sTime

SimAIT Model Layer:1. TM/TC FEE2. Sim FEE3. Power SCOE4. X-Band RF SCOE5. PLM EGSE6. CDU EGSE7. FPA Simulator

TM/TCDatabase

OBSWLoader

OBSWFiles

EmulatorDebugger

PLM

Spa

ceW

ire B

USPLM SpaceWire BUS Models

SpaceWireBus (EIU)

AB

CD

SpaceWireBus (EIU)

MMI

MMI

MMI

MMI

ArchiveMedia

pS_64Hz

pS_64Hz

PROM

Figure 1.4-1: Real Time Simulator (SVF Configuration)

Gaia


of 94



1.4.3 Avionics Model Bench

The AVM is a hybrid test bed consisting of the Real Time Simulator (without CDMU Simulation and ERC32 Processor Emulation) providing a closed-loop test interface to the Spacecraft Avionics and Instrumentation.

As a minimum in this configuration, the Avionics SCOE provides the interface between the RTS and the CDMU (breadboard, EM or PFM unit), with all other Spacecraft Units simulated by the RTS.

As Spacecraft units progressively become available, RTS Models are replaced with real hardware and dedicated EGSE, until the RTS need only simulate the Environment, Dynamics and some of the AOCS sensors and actuators - which remain simulated throughout.

The AVM is used first for the initial HW/SW integration of the CDMU with the CSW, followed by extensive system simulation, S/W verification, procedure debugging, etc.

For full AVM testing, the RTS must provide rate and attitude data to the Dynamic FPA Simulator and Star Tracker SCOE to maintain closed-loop test capability.

In this configuration, the RTS is controlled remotely from the CCS. Test Procedures developed during AVM testing are intended for use throughout the Spacecraft AIT campaign.

Avionics SCOE

Simulated SpacecraftModel Layer

Central CheckoutSystem (CCS)

TM/TC Interface(CCSDS-SourcePacket Level withTCP/IP Protocol)

TM/TC FEE

Command & Control Interface (C&C)

TM, X-Band10MBbps

TM, X-Band62.5kBbps

TC, X-Band4kBbps

CD

MU

High Power Commands

Alarms

PLM 1553B BUS-A/B

EFM 1553B BUS-A/B

PLM SpaceWire BUS

Inst

rum

ent I

nter

face

LAN

TM/TC FEEController

LAN

LAN

Timing & Synch

EIU

AvionicsSCOE

Controller

Inst

rum

ent

Inte

rface

Thrusters

Press TDR

FSS

LAN

Latch Valves

uPropulsion MPE

InitModule:1. Configure Models2. Init Model Parameters3. Configure Internal TM4. Initialise Internal TM5. Default Housekeeping (HK)

LAN

ModelIni

HKIni

TMIni Control ?

Local

Rem

oteIniConfig Editor

MemoryMapping

MMI

REAL TIMESIMULATOR

LogCycle:1. Log Sim TM2. Log Parameters3. Messages

Dis

tribu

ted

Sha

red

Mem

ory

(DS

M)

Dynamics

ExtSync

StarTrackerSCOE

ArchiveMedia

ERROR HANDLER

pS_64Hz

pS_64Hz

pS_64Hz

TimeSynchModule

RTS CoreApplication

Command&Control Interface (C&C):1. Simulator Control (Start/Stop ...)2. Re-configure Init Parameters3. Set Model Parameters4. Set SimTM5. Schedule SimTM Logging

EIU SpaceWire BUS

STR

Env

ironm

ent

EGSEInterface

DS

M

EGSELAN

FPASimulator VPUs

LAN

LAN

DS

MD

SM

Thrusters

Latch Valves

uPropulsion

FSS

Gyros

Figure 1.4-2: Real Time Simulator (Avionics Model Bench Configuration)

1.4.4 Spacecraft PFM AIT

During the Spacecraft PFM AIT test campaign, the RTS is used to Model the Spacecraft Mission Environment and Dynamics and the AOCS Actuators and Sensors (which remain simulated throughout). In addition, any missing Spacecraft units may be modelled. Using direct electronic stimulation and measurement provided by the Avionics SCOE and other EGSE, it allows closed-loop testing of the Spacecraft Avionics.

Gaia


of 94



1.4.5 Simulated AIT (SimAIT)

The SimAIT configuration of the RTS is a pure numerical simulation facility, based on the SVF, primarily used for early development of test procedures for the Spacecraft PFM AIT test campaign. In this configuration, the Simulation includes simple Models of the Spacecraft EGSE (to prevent communication errors with the CCS).

1.4.6 Operational Verification Facility (OVF)

The OVF configuration of the RTS is a pure numerical simulation facility, based on the SVF, primarily used for development of test procedures for Spacecraft Operations.

1.5 Terminology

The Real Time description of the RTS is not to be understood as a stringent requirement to an absolute real-time behaviour, but is related to the fact that the RTS will in all cases be synchronized to an external time signal.

As a consequence the RTS architecture will be independent of its target application and usage. From a performance point of view the RTS shall be designed such that operations with all simulation tasks can be run faster than real-time.

The time synchronization requirements of the RTS are defined later in this document.

1.5.1 Data Terminology

Throughout this document, requirements are put in place for handling various forms of data. The data forms and the terms used to define them are discussed below:

• Model I/O: are variables input to, or output from, Simulated Model functions. Model Inputs can exist as pure software variables or can be derived from a real hardware inputs mapped from the Avionics SCOE. Model Outputs can exist as pure software variables or can be used to drive real hardware outputs mapped to the Avionics SCOE.

• Model Characterization Parameters are variables used by Simulated Model functions to determine operational aspects of internal functionality or algorithmic operation.

• Model Internal Parameters are variables derived within Simulated Model functions (for instance interim results as part of the computation process), but are not defined as I/O.

• Emulation Parameters are any variables internal to the ERC32 Emulation process.

• All the above parameters are exposed to the Simulation process and known collectively as Simulation Parameters.

• Simulated Telemetry: is any of the data mentioned above, defined in configuration files, for transmission to the CCS. The data is formatted in such a way that it can be processed by the CCS in the same way as any other archived data (Spacecraft Telemetry, EGSE Housekeeping Data, etc.)

• Spacecraft Telemetry: Is data generated by the CDMU (TM Frame Generator) - actual hardware or simulated Model thereof - representing the status of the Spacecraft Systems.

• Spacecraft Telecommands: Are data generated by the CCS or internally by the RTS (by command line or from within a Test Sequence), to the CDMU (TC Decoder) - actual hardware or simulated Model thereof - to command the Spacecraft Systems.

• Control Commands are any commands received from the CCS or generated internally by RTS (by command line or from within a Test Sequence), to setup, configure and control the Simulation Process.

Gaia


of 94



2 DOCUMENTS

The following documents are applicable documents to this specification. Those parts of the documents that are specifically applicable for the subcontractor's product design, test, and manufacturing, are clearly defined by references within this specification.

2.1 Project Documents

2.1.1 Applicable Documents

AD01 GAIA EGSE System Requirements GAIA.ASF.SP.SAT.00048 AD02 GAIA RTS System User Requirement Document GAIA.ASF.SP.SAT.00053 AD03 GAIA EGSE Interface Control Document GAIA.ASU.ICD.ESM.00001 AD04 GAIA EGSE GDIR GAIA.ASF.SP.SAT.00007 AD05 GAIA PA Requirements for GSE GAIA.ASG.SP.SAT.00037 AD06 GAIA SW PA Requirements for EGSE Software GAIA.ASF.SP.SAT.00046 AD07 GAIA CDMU Requirement Specification GAIA.ASU.SP.ESM.00004 AD08 GAIA MIL-STD-1553B Bus Protocol Specification GAIA.ASF.SP.SAT.00059

2.1.2 Reference Documents

RD01 Gaia CDMU (OBC) HW/SW Interface Control Document TBD RD02 Gaia CDMU Design report TBD RD03 Gaia CDMU User Manual TBD RD04 Gaia TMTC SCOE Interface Control Document TBD

2.1.3 Standards

SD01 SpaceWire - Links, nodes, routers and networks ECSS-E-50-12A

Gaia


of 94



3 RTS REQUIREMENTS

RTS-333/RTS_URD-24,25/R

The RTS shall comprise the major elements listed below:

RTS Core Application. Core start-up application to initialize processes, synchronize modules and schedule the application layers (simulation sequencing) Simulated Spacecraft Model Layer. Provides configurable software simulation of the Spacecraft Mission Environment, Dynamics and Electrical Units (with the exception of CDMU) Simulated EGSE Model Layer. Provides simple (TM/TC) models of the Spacecraft EGSE for use on the Simulated AIT Test Bench (SimAIT) ERC32 Processor Emulator. Software emulation of the Spacecraft CDMU ERC32 Processor on which the unmodified Central Software (CSW) is executed Emulator Interface Layer. Provides the interface function between the ERC32 Processor Emulator, the CDMU Model Layer and the Command and Control Interface Simulated CDMU Model Layer. Provides configurable software simulation of the Spacecraft CDMU peripheral components Interface Applications. Handles the ancillary interfaces required for Test realization, such as:

• Data/Message logging. • Command and Control interface (C&C). • File I/O. • CCS Interface.

Man-Machine Interfaces (RTS MMI): Comprises a complete test preparation, execution and control facility. EGSE Interface Layer: For the hybrid bench, provides the interface between simulated data and the Spacecraft EGSE (Avionics SCOE, Star tracker SCOE and Dynamic FPA Simulator).

RTS-3141/RTS_URD-26/R

The hybrid bench version of the RTS shall be the same as the numerical bench version, with the exception that the Simulated CDMU Models and ERC32 Emulation are disabled and the Real Time Network interface to the Avionics SCOE is included.

Descriptive block diagrams of the RTS (in the SVF and AVM configurations) are supplied in Figures 1.4-1 and 1.4-2 respectively. These diagrams, and the elements described therein, are referred to throughout this document. The diagrams are provided for illustrative purposes only.

To simplify the understanding of the Requirements herein supplied, the diagrams are used as an aid to subdivide the Requirements into subsystem blocks.

The diagrams themselves, and the blocks herein described, should not be taken as an imposition on the subcontractor of the implementation method to be used.

RTS-1981/CREATED/R

All RTS files shall be placed under configuration control, using a Configuration Management Tool to be chosen by the RTS subcontractor. This shall include as a minimum:

RTS Source Code Model Source Code Configuration files Initialization files Runtime files (i.e. Model Stimulation files) Test Sequences Any tools provided as part of the RTS MMI


An Installation Disc (on CD-ROM or DVD-ROM) and Installation Procedure shall be provided for installation of the RTS application on new hardware without RTS supplier support.

Gaia


of 94




The Installation shall define the minimum hardware configuration required.

RTS-2397/RTS_URD-130/T

Installation of the RTS Application Software shall take no longer than 5 minutes.

3.1 System Level Definition

RTS-453/CREATED/I

The RTS Numerical Bench shall comprise of:

The Hardware platform based on a COTS PC or Workstation unit A base Operating System (OS) (i.e. UNIX, Linux, Windows XP or RTOS such as RTLinux, VxWorks) An OS disc drive with minimum 100GB storage size An RTS Application disc drive with minimum 100GB storage size A data archive disc drive with minimum 500GB storage size A CDROM/DVD writer One 19" LCD Flat Panel Monitor (DVI), minimum (1280*1024) resolution A Configuration Management Tool (as defined by RTS-1981) RTS Simulator Application software ERC32 Processor Software Emulator (including debug tool) - based on a standard COTS or in-house developed tool A data backup system (such as DAT DDS5) for data archive storage and retrieval 1 PCI-Express Gigabit ETHERNET Network Interface Card (for CCS Interface) Note: PCI-Express is required to meet the Gigabit ETHERNET speed requirements)

RTS-7262/CREATED/I

The RTS Hybrid Bench shall comprise of the Numerical Bench elements identified above, plus:

1 Real-time Network device and star hub for external EGSE Interfaces - see Section 3.3.14

RTS-7086/CREATED/I

A stand-alone Performance Monitor application shall be included with the RTS (possibly based on standard OS applications) for monitoring host CPU load/application and memory usage.

Gaia


of 94



3.2 Performance Requirements

3.2.1 Timing and Synchronization

RTS-5365/CREATED/T

In accordance with the requirements of Section 3.4.2 of the EGSE ICD [AD03], when connected to the CCS the RTS shall synchronize its system clock to the CCS system clock using Network Time Protocols.

RTS-464/RTS_URD-35,47/T

RTS Simulation Cycle synchronization shall conform to the following requirements (depending on Simulator configuration):

In the numerical bench configuration (SVF): • The CDMU Simulated Timing & Sync Model (SCET) produces a nominal PPS (Pulse-Per-

Second) reference timing signal as a function of the ERC32 Emulator processor clock. • The PPS timing signal is mapped through shared memory to the TimeSynch Module. • The TimeSynch Module produces a Simulation Cycle timing signal (simCycle) - synchronized to

the PPS input - which is the scheduler for the Simulated Spacecraft Model computation. In the hybrid test bench configuration:

• The Avionics SCOE provides an external reference timing signal (SynchScoe) to the RTS (TimeSynch Module) mapped across the Real-time Network Interface.

• The Simulation Cycle timing (simCycle) shall be synchronized to this signal using a method to be determined by the RTS subcontractor (i.e. event polling, interrupt driven).


The Simulation Cycle timing signal (simCycle) shall be 1/64 of PPS.

RTS-1650/CREATED/T

The RTS shall maintain a Simulation Clock (hereinafter referred to as sTime) starting at zero when the Simulation is STARTED and incrementing every Simulation Cycle.

Gaia


of 94



3.2.2 Simulation Performance.

RTS-472/RTS_URD-34/T,A

In the numerical bench configuration it shall be possible to run a Simulation for up to 5 days without loss of data, under all the following conditions:

Simulation speed set to twice real-time CDMU Model Layer fully configured Spacecraft Model Layer fully configured Simultaneous processing of:

• 5000 Spacecraft TM parameters/second (data logging/local archive and transfer to CCS) • 20 Spacecraft Telecommands/second (generated locally or by CCS) • 500 Simulation Parameters/simulation cycle (data logging/local archive) • 500 Simulated Telemetry parameters/second (transfer to CCS) • 5 Command and Control packets/second (from CCS) • traffic on 2 independent 1553 BUS (spy and data logging/local archive) • traffic on 2 independent SpaceWire BUS (spy and data logging/local archive)


In the hybrid bench configuration it shall be possible to run a Simulation for up to 5 days without loss of data, under all the following conditions:

Simulation speed set to nominal Spacecraft Model Layer fully configured Simultaneous processing of:

• 5000 Spacecraft TM parameters/second (transfer to CCS) • 20 Spacecraft TC packets/second (generated by CCS) • 500 Simulation Parameters/simulation cycle (data logging/local archive) • 500 Simulated Telemetry parameters/second (transfer to CCS) • 5 Command and Control packets/second (from CCS) • traffic on 2 independent 1553 BUS (spy and data logging/local archive) • traffic on 2 independent SpaceWire BUS (spy and data logging/local archive)

RTS-7083/CREATED/T,A

In the numeric bench configuration, simulation performance requirements shall be based on a simulated processor capability of 15 MIPS / 3 Mflops when executing the CSW from simulated RAM.

Gaia


of 94



3.3 Functional Requirements

3.3.1 RTS Core Application

This section describes typical processes defined by the RTS Core Application. For information purposes, refer to the RTS Core Application state diagram given below:

Start CSW

Synchronize

Initialise

Free-run

Interrogate(CCS/MMI cmd)

ExitInit Start

Simulation

Synchronize 1/64 PPSsTime = 0

SimCycle

DMA Read

SpacecraftModel

Computation

DMA Write

Data Logging

Interrogate(CCS/MMI cmd)

sTime++

PAUSE

SuspendCSW

SynchronizeInterrogate(MMI cmd)

Free-run

Open Logs

RESTART

Restart CSW

Synchronize1/64 PPSsTime = 0

Stop CSW

STOP

SimulatedCDMU

ComputationClose Logs

STOP

Color Key: Numerical Bench only

Hybrid Bench only Figure 3.3-1: RTS Core Application State Diagram

Gaia


of 94




During start-up, and prior to Simulation START, the RTS Core Application shall:

Initialize the Simulation - see Section 3.3.7 Initialize the TimeSynch Module (free-run mode with locally generated simCycle signal) Routinely interrogate the C&C and MMI for command requests


On receipt of a Simulation START, the RTS Core Application shall:

Start data log files Start the ERC32 Emulation process (if configured for the numerical bench configurations) Synchronize timing (configuration dependent, see Section 3.2.1)

RTS-1042/CREATED/T,I

Every Simulation cycle (simCycle), the RTS Core Application shall:

In the hybrid bench configuration: Perform the DMA data-read cycle from the Avionics SCOE. Schedule the Simulated Spacecraft Model Layer computation - see Section 3.3.2 In the hybrid bench configuration: Perform the DMA data-write cycle to the Avionics SCOE (and other EGSE as required). Schedule the data logging - see Section 3.3.11. Schedule the Command and Control Interface (C&C) - see Section 3.3.10


When a Simulation is paused, by RTS MMI Test Sequence or GUI Command Line, the RTS Core Application shall:

Suspend CSW execution Suspend the Simulated CDMU Model Layer computation. Suspend the Simulated Spacecraft Model Layer computation. Suspend the Simulation Clock at current Simulation Time (sTime). Maintain a pseudo-synchronization of the Simulation Cycle rate for cyclic housekeeping purposes (routine monitoring of the CCS and MMI interfaces) Continue to schedule the Command and Control Interface (C&C) at (simCycle) to process commands from the CCS or local (MMI and Test Sequence).


When a Simulation is restarted, by RTS MMI Test Sequence or GUI Command Line, the RTS Core Application shall:

Restart CSW execution Restart the Simulated CDMU Model Layer computation. Restart the Simulated Spacecraft Model Layer computation. Restart the Simulation Clock from the point at which the Simulation was paused.


On receipt of a STOP command, the RTS Core Application shall:

Stop CSW execution (if configured in the numerical bench configuration) Stop the Simulation Cycle Close out data logging - see Section 3.3.12 Routinely interrogate the C&C and MMI for command requests

Gaia


of 94




Message event logs shall be output by the application for scheduled distribution by the LogCycle for the following events (as a minimum):

Simulation process events (i.e. START/STOP/PAUSE/RESTART) Detected ERRORS and Warnings

Gaia


of 94



3.3.2 Simulated Spacecraft Model Layer

The Simulated Spacecraft Model Layer comprises software Model functions for the Environment, Spacecraft at system level (Thermal, Dynamics) and Models for each individual Spacecraft unit (with the exception of the CDMU).

RTS-506/RTS_URD-73,90/T,A

Model functions shall be scheduled by the RTS Core Application every Simulation Cycle (simCycle).


The subcontractor shall produce the Spacecraft Model functions from Model Specifications provided by EADS Astrium Ltd.

RTS-7290/CREATED/R

It is important to recognise that equipment Model detail will develop as the hardware design itself develops. The RTS supplier shall accommodate incremental release of Models of increasing detail.

Model Specifications will include as a minimum:

• Functional description

• Performance Model from the FVB (where appropriate - see RTS-2717)

• Reference Test Cases for the Performance Models from the FVB (where appropriate - see RTS-2717)

• Electrical ICD

• TM/TC ICD

• Failure Modes


Unit Simulation Models shall be representative at the functional level.


Unit Simulation Models shall be representative of the equipment interfaces at functional level.

Note: There is no need to be representative at Electrical ICD and Harness level).


Unit Simulation Models shall be representative of all redundancies available within the unit.

The system level Models and most of the AOCS Performance Models (developed by Astrium for use in the Functional Validation Bench) will be provided for reuse by the RTS subcontractor, in the format TBD.

RTS-2717/RTS_URD-95,108/T,A,R

For the reuse Models (marked thus ** in the table given below), the detailed performance behaviour Model will be developed by Astrium LTD and delivered to the RTS supplier as part of the full Model Specification.

The functional aspects of the Model (such as the TM/TC interface, power & thermal responses, introduction of failure states, etc.) shall be developed by the RTS subcontractor according to the Model Specification supplied by EADS Astrium Ltd.

Detailed Model Specifications will be provided to the subcontractor in accordance with the schedule defined in the Statement of Work.

Gaia


of 94



RTS-513/CREATED/T,R

The subcontractor shall provide simple tools to allow Model functions to be up-issued by the end user (to allow updates without the intervention of the subcontractor at the end-user site).


The RTS shall comprise the following Models. For scoping purposes, Sections 3.3.2.x provide an overview of each Model at functional and I/O level to help define the Model complexity. These descriptions are not intended to go into detail and are descriptive only. Detailed requirements for each Model will be provided incrementally after contract award in line with the SOW.

Environment ** Dynamics ** Thermal Star Tracker (STR) ** Gyros ** Fine Sun Sensors ** Combined CPS ** SREM Separation Switches Electrical Interface Unit (EIU) Battery PCDU Micropropulsion System MPS ** Transponders (TRSP) RF Distribution (RFDU) Phased Array Antenna (PAA) ** Clock Distribution Unit (CDU) Mechanism Drive Electronics (MDE) Optical Source Electronics (OSE) Focal Plane Array (FPA) Video Processing Units (VPU) ** Payload Data Handling Unit (PDHU) Deployable Sunshield (DSA) Bipods

Note: ** see RTS-2717

RTS-2901/RTS_URD-90/T,A,R

Execution timing for each individual Model shall be as defined in the initialization file for each Model (see Section 3.3.7) The table below identifies a typical scenario for Model execution and I/O rates.

Model Timing PPS/64 PPS/32 PPS/16 PPS/8 PPS/4 PPS/2 PPS Environment ♦ Dynamics ♦ Thermal ♦ STR ♦ ⇐⇐⇐⇐ Gyro ♦ ⇐⇐⇐⇐ Fine Sun Sensor ♦⇐⇐⇐⇐ Combined CPS ♦�� ⇐⇐⇐⇐ SREM ♦⇐⇐⇐⇐ Separation Straps ♦⇐⇐⇐⇐ EIU ♦⇐⇐⇐⇐ Battery ♦⇐⇐⇐⇐ PCDU ♦⇐⇐⇐⇐ MPS ♦�� ⇐⇐⇐⇐ TRSP ♦⇐⇐⇐⇐ PAA ♦⇐⇐⇐⇐ CDU ♦⇐⇐⇐⇐ MDE ♦⇐⇐⇐⇐ OSE ♦⇐⇐⇐⇐ FPA ♦⇐⇐⇐⇐ VPU ♦⇐⇐⇐⇐ PDHS ♦⇐⇐⇐⇐ DSA ♦⇐⇐⇐⇐ Bipods ♦⇐⇐⇐⇐

Key: Execution: ♦ Input: � Output: ⇐

Table 3.3-1: Model Execution and I/O Timing

Gaia


of 94



RTS-7047/CREATED/T,A,R

Electrical Models of all equipment shall:

• Accept all CSW and Ground Commands,

• Be representative in timing and order of execution of the Commands,

• Be representative in generated responses (timing and format) to the Commands.

• Be representative for hot and cold redundancy requirements.

RTS-7048/CREATED/T

All Equipment Models receiving commands shall check the format and timing of received commands and log any detected errors.

Gaia


of 94



3.3.2.1 1553 BUS Models

Description:

This section describes the 1553 BUS interface requirements for each Model responding to the Spacecraft MIL-STD-1553B BUS as a Remote Terminal.

GAIA implements two separate dual-redundant 1553 BUS, one for the Service Module (SVM BUS) and one for the Payload Module (PLM BUS). For each BUS, only one side (BUS #A, BUS#B) shall be active at any time - the other side is in standby mode. The Gaia BUS topology is described in Figure 4-1 of [AD08]. The CDMU provides the Bus Controller (BC) functions for each.

Configuration of the BUS (which RT is active on which BUS) is determined by configuration commands (HPC) from the EIU or CDMU (Reconfiguration Module). RT activity shall also be determined by the ON/OFF state of each RT (status from the PCDU Model).

RT addressing is given in 7.1.3.1 of [AD08].

Each RT Model description given below indicates (for scoping purposes only) the expected TM/TC traffic on the BUS.

Each BUS (SVM, PLM) shall utilize shared memory for message exchange with the corresponding BC - either simulated in the numeric bench, or via the Avionics SCOE 1553 BUS card in the hybrid bench.

In the hybrid bench configuration, the BUS Models utilize shared-memory of the Real-time Network as an interface to the 1553 BUS Hardware cards provided by the Avionics SCOE - see Section 3.3.14.1.

The table below identifies the Models which connect to the Gaia SVM and PLM 1553 BUS.

SVM BUS Model PLM BUS Model TRSP#1 MDE#1 TRSP#2 MDE#2 PAA-A OSE#1 PAA-B OSE#2 MPE#1 CDU#1 MPE#2 CDU#2 PCDU-A PDHU-A PCDU-B PDHU-B STR#1 VPU#1-7 STR#2 GYRO# 1A & 1B GYRO# 2A & 2B GYRO# 3A & 3B

The RT Models shall implement the BUS protocols as defined in [AD08].

In the numeric bench configuration, it shall be possible to replace any 1553 equipment simulation by a 1553 Remote Terminal responder.

The 1553 Models shall provide the capability to program fixed or variable responses, based on a linear or circular profile of values, on each responder sub-address.

All 1553 Models shall provide BUS latency time as a Characterization Input parameter for user adaptation.

The 1553 BUS Models shall incorporate a range of commandable failure conditions. A subset of the failures defined in the 1553 BUS FMECA shall be selected by EADS Astrium LTD to be included in the model, but as a minimum shall include the following transient or permanent errors:

• no response on the RT

• parity error

• word count error

• all error bits of the status word

Gaia


of 94



3.3.2.2 Environment Model

Description:

This model represents the physical properties of the universe that have influence over the behaviour of the spacecraft from the AOCS point of view. The outputs of this model are used more widely within the RTS than just the specific AOCS-related models, but only features that have a specific contribution to the simulated AOCS behaviour are included.

The Environment Model shall derive and maintain all necessary physical environment properties, including

• Solar momentum flux

• Solar System Ephemeris (Sun, Earth, Moon positions in inertial reference frame)

• Spacecraft local gravity field

• Spacecraft local magnetic field

Configuration: Single Instance.

Timing: Execution rate PPS/4

Power Input: N/A

Power Output: N/A

Inputs: N/A

Simulation Inputs:

Description Source Solar Momentum Flux parameters Input File Solar System Ephemeris parameters Input File Gravity Model parameters Input File Magnetic Field Model parameters Input File Simulation Epoch Input File/RTS Data Load Command

Outputs: N/A

Simulation Outputs:

Description Destination Solar Momentum Flux Dynamics Model Gravity Field Dynamics Model Magnetic Field Dynamics Model 3-Axis Sun position in Inertial Frame Dynamics Model 3-Axis Earth position in Inertial Frame Dynamics Model 3-Axis Moon position in Inertial Frame Dynamics Model

Gaia


of 94



3.3.2.3 Thermal Model

Description:

This model represents a minimal simulation of the Spacecraft thermal behaviour.

The Thermal model shall simulate thermistor readings taking into account:

• Spacecraft unit power status, • Heater power status,

to which the thermistor responds. The Model shall not take into account Spacecraft attitude.

Final thermistor value (Tfinal) shall be calculated taking into account the status lines to which it responds.

Delta temperature changes shall be calculated, per cycle, as:

• Maximum temperature delta (as defined for each Thermistor), or, • Half of the difference between current temperature and Tfinal,

(whichever is the smallest)

Thermistor erroneous readings shall be simulated by dynamically overwriting the Thermistor value during Simulation.


Timing: Execution and data I/O rates PPS

Power Input:

Description Source (24+2 TBC) Payload LCL Heaters: bi-level PCDU Model (24 TBC) Platform LCL Heaters: bi-level PCDU Model

Power Output: N/A

Inputs: N/A

Simulation Inputs:

Description (LCL status lines) Source (19+5 TBC) Payload LCL Units: bi-level PCDU Model (29 TBC) Platform LCL Units: bi-level PCDU Model (4 TBC) Platform FCL Units: bi-level PCDU Model

Characterization Inputs:

Description Source PCDU status line control (per Thermistor) Input File/RTS Data Load Command Final temperature (Tfinal) (per Thermistor per PCDU control line)

Input File/RTS Data Load Command

Maximum temperature delta change (per Thermistor)


Outputs:

Description Source (200 TBC) Thermistor values: analog EIU Model (29 TBC) Platform LCL Units: bi-level PCDU Model (4 TBC) Platform FCL Units: bi-level PCDU Model

Simulation Outputs:

Description Source (24+2 TBC) Payload LCL currents: analog PCDU Model (24 TBC) Platform LCL currents: analog PCDU Model

Gaia


of 94



3.3.2.4 Dynamics Model

Description:

This model represents the physical properties of the spacecraft and calculates the spacecraft motion response to both internally and externally applied forces and torques. The principal output are state vectors representing the instantaneous Spacecraft Attitude and Orbit Dynamics / Kinematics (i.e. Spacecraft inertial attitude & body rates, orbital position & velocity).

The Dynamics Model shall derive and maintain all necessary spacecraft physical properties and disturbance effects, including

• Dry Spacecraft Mass properties (built up from a number of individual rigid body elements) • Fluid Slosh (variable according to selected propellant load) • Spacecraft flexure (principally due to the DSA and the PLM/SVM bipods), vibration modes (TBC) • Sun, Earth, Moon positions in S/C body frame • S/C Disturbance Forces and Torques (gravity gradient, solar radiation pressure, magnetic moment,

RF transmission force, micrometeoroid collision) • Spacecraft thrusters actuation (CPS and MPS)

It shall be possible to define a constant torque, or torque profile into the Model for test purposes.


Timing: Execution rate PPS/64

Power Input: N/A

Power Output: N/A

Inputs:

Description Source Rigid Body Elements Input File Flexure Model parameters Input File Slosh Model parameters Input File Propellant Load Input File/RTS Data Load Command Initial Orbit parameters Input File/RTS Data Load Command Initial Spacecraft Attitude & Body rates Input File/RTS Data Load Command Enable/Disable disturbance effects Input File/RTS Data Load Command

Simulation Inputs:

Description Source Gravity Field Environment Model Solar Momentum Flux Environment Model Magnetic Field Environment Model PAA RF Force PAA Model DSA Deployment State DSA Model CPS Thruster Forces CPS Model MPS Thruster Forces MPS Model

Outputs: N/A

Simulation Outputs:

Description Destination Spacecraft Attitude State Vector Various Spacecraft Orbital Parameters Various 3-Axis Sun position relative to Spacecraft Various 3-Axis Earth position relative to Spacecraft Various 3-Axis Moon position relative to Spacecraft Various

Gaia


of 94



3.3.2.5 Star Tracker (STR) Model

Description:

This model provides an accurate representation of the AOCS Star Tracker (STR) functional and performance behaviour.

The main function of the star tracker is to generate a quaternion output describing the instantaneous orientation of the star tracker in the J2000 Inertial Reference Frame. The output quaternion shall be derived by the STR model from the Spacecraft motion state vector received from the Dynamics model, taking into account all conditions and behaviours that will influence the quality of the output. These conditions and behaviours may include, but not be limited to:

• Power on status of the STR

• Occlusion of the STR by the stowed DSA

• Orientation of the STR with respect to the spacecraft body frame

• Variation in this orientation due to thermoelastic distortion

• Consequences of star smearing in the detector image due to spacecraft body rates

• Internal biases within the STR that are manifest in the output data

• Noise effects present in the STR measurement processes that are manifest in the output data

• Impact of blinding by Sun, Earth or Moon

• Relativistic effects due to spacecraft orbital velocity

To achieve the necessary accuracy in the output data characteristics, the STR model shall be updated at higher frequency than the required telemetry output rate. This is necessary in order that, for example, star smearing on the detector due to spacecraft body rate (and body rate variations) during the image capture process can be accurately modelled.

The STR model shall ensure properly representative behaviour of all STR operating modes and shall provide accurate housekeeping and measurement validity telemetry, as well as the as-measured attitude quaternion. The Star Tracker is likely to have several operating modes, and these modes (and both manual and automatic mode transitions) shall be modelled to the extent necessary to achieve correct output data signatures. This will include any mode-dependant variations in output data accuracy and availability (e.g., variations in time to first valid quaternion output according to whether the STR is configured for “lost in space” or “aided” attitude acquisition).

The STR model shall incorporate a range of commandable STR failure conditions. A subset of the failures defined in the STR FMECA shall be selected by Astrium to be included in the STR model. The STR model shall provide representative data output signatures for the selected failures (e.g., Status flags set in the TM output / corruption in the TM output / absence of TM output, etc.)

The STR model shall be configurable according to the extent to which there is real 'hardware in the loop.'

With CDMU hardware present, the STR model shall be connected to the 1553 interface hardware of the Avionics SCOE.

When real STR hardware is present (Star Tracker EGSE stimulating the Star Tracker Electronics which is interfaced directly to the CDMU hardware), the STR model shall provide a suitably pre-processed STR line of sight orientation in inertial space (either as attitude and rate state vector or as attitude quaternion, according to STR EGSE requirement). Any additional input data required to drive the STR EGSE (such as spacecraft velocity, potentially) shall also be provided by the STR model.

Configuration: Two Independent Instances.

Timing: Execution rate PPS/16. Data output rate PPS/2.

Gaia


of 94



Power Input:

Description Source LCL: bi-level PCDU Model

Power Output: N/A

Inputs:

Description Source PPS signal CDMU Model

Simulation Inputs:

Description Source Spacecraft Attitude State Vector Dynamics Model Spacecraft Orbital Parameters Dynamics Model 3-Axis Sun position relative to Spacecraft Dynamics Model 3-Axis Earth position relative to Spacecraft Dynamics Model 3-Axis Moon position relative to Spacecraft Dynamics Model DSA Deployment State DSA Model


Description Source STR line-of-sight orientation relative to the Spacecraft


STR Performance Parameters (Noise and Bias) Input File/RTS Data Load Command STR misalignment

Outputs:

Description Destination Dynamic Data (TBC) - for hybrid bench Star Tracker EGSE

Simulation Outputs:

Description Destination STR current: analog PCDU Model

1553 Bus Data: The 1553 BUS protocols and message exchange shall be managed by the SVM 1553 BUS Model (see Section 3.3.2.1). A preliminary indication of the TM/TC message exchange for this Model is given below:

TM List (TBC) TC List (TBC) As-measured Attitude Quaternion Mode Changes Measurement Validity Aided Acquisition Data Measured Stars Housekeeping Data

Fault modes:

Type: (TBC) Sensor Anomalies Internal Failures

Gaia


of 94



3.3.2.6 Gyro Model

Description:

This model provides an accurate representation of the AOCS Gyro functional and performance behaviour.

The main function of the Gyro(s) is to generate a digital measurement output describing the instantaneous angular rate experienced by the Gyro's sensing axis (or axes). The measurement output, which is expected to be in the form of an accumulated angle over a particular measurement period, shall be derived by the Gyro model from the Spacecraft motion state vector received from the Dynamics model, taking into account all conditions and behaviours that will influence the quality of the output. These conditions and behaviours may include, but not be limited to:

• Power on status of the Gyro,

• Orientation of the Gyro with respect to the spacecraft body frame,

• Gyro scale factor,

• Gyro drift,

• Variation in this orientation due to thermoelastic distortion,

• Internal biases within the Gyro that are manifest in the output data,

• Noise effects present in the Gyro measurement processes that are manifest in the output data,

Measured spacecraft body rates are calculated by the CDMU on-board software from the accumulated angle data provided by the Gyros.

To achieve the necessary accuracy in the output data characteristics, at least the rate integration element of the Gyro model shall be updated at the same frequency as the Dynamics model is updated. This is necessary in order that, for example, the effect of spacecraft body rate variations over the Gyro measurement interval can be accurately modelled.

Depending on the gyro that is selected for Gaia, there may be two sets of measurement output from the gyro that must be modelled, “raw” accumulated angle and “filtered” accumulated that has been passed through an internal anti-aliasing filter. Both sets of outputs will be used by the Gaia AOCS and both sets of outputs shall be provided by the Gyro model.

The Gyro model shall ensure properly representative behaviour of all Gyro operating modes and shall provide accurate housekeeping and measurement validity telemetry, as well as the as-measured accumulated angle data.

The Gyro model shall incorporate a range of commandable Gyro failure conditions. A subset of the failures defined in the Gyro FMECA shall be selected by EADS Astrium LTD to be included in the Gyro model. The Gyro model shall provide representative data output signatures for the selected failures (e.g., Status flags set in the TM output / corruption in the TM output / absence of TM output, etc.)

The Gyro model shall be configurable according to the extent to which there is real ‘hardware in the loop.’ When real Gyro hardware is present (Gyro EGSE stimulating the Gyro Electronics which is interfaced directly to the CDMU hardware), the Gyro model shall provide rate output(s) to the AOCS SCOE representing the instantaneous rotation rate apparent around the gyro sensing axis (axes). Any additional input data required to drive the AOCS SCOE (such as appropriate Gyro housekeeping data) shall also be provided by the Gyro model.

Configuration: 6 separate Model Instances..

Timing: Execution rate PPS/64. Data output rate PPS/8.

Gaia


of 94



Power Input:


Power Output: N/A

Inputs:

Description Source PPS signal CDMU Model

Simulation Inputs:

Description Source Spacecraft Attitude State Vector Dynamics Model


Description Source Gyro sensing axis orientation relative to the Spacecraft Body Frame


Gyro Scale Factor Input File/RTS Data Load Command Gyro Performance Parameters (Noise and Bias) Input File/RTS Data Load Command Gyro axis misalignment Input File/RTS Data Load Command

Outputs:

Description Destination Dynamic Data (TBC) - for hybrid bench Avionics SCOE

Simulation Outputs:

Description Destination Gyro current: analog PCDU Model


TM List (TBC) TC List (TBC) 'Raw' Accumulated Angle Data Mode Changes 'Filtered' Accumulated Angle Data Aided Acquisition Data Measurement Validity Housekeeping Data

Fault modes:


Gaia


of 94



3.3.2.7 Fine Sun Sensor Model

Description:

This model provides an accurate representation of the AOCS Fine Sun Sensor (FSS) functional and performance behaviour.

The FSS is an analogue device that is interfaced to the EIU. Each FSS consist of a 2x2 grid of photo diodes. Each of the photodiodes is sampled individually by the CDMU via the EIU, which returns a digitized voltage that represents the degree of solar illumination that is instantaneously being experienced by the photodiode. The relative illumination of these 4 sensing elements can be processed to derive a 2-axis sun position measurement by the CDMU software.

The main function of the FSS is to generate a digital measurement output describing the instantaneous solar illumination experienced by each of the four photodiodes. The measurement outputs shall be derived by the FSS model from the Sun position in Spacecraft Body Frame vector received from the Dynamics model, taking into account all conditions and behaviours that will influence the quality of the output. These conditions and behaviours may include, but not be limited to:

• Power on status of the FSS,

• Orientation of the FSS with respect to the spacecraft body frame,

• Earth/Moon albedo effect

• Modelling of the baffles (if any)


• Internal biases within the FSS that are manifest in the output data,

• Noise effects present in the FSS that are manifest in the output data,

The FSS model shall ensure properly representative behaviour of any FSS housekeeping telemetry, as well as the as-measured photo diode output data.

The FSS model shall incorporate a range of commandable FSS failure conditions. A subset of the failures defined in the FSS FMECA shall be selected by Astrium to be included in the FSS model. The FSS model shall provide representative data output signatures for the selected failures (e.g., corruption in the TM output / absence of TM output, etc.)

The FSS model shall be configurable according to the extent to which there is real ‘hardware in the loop.’ When real FSS and/or EIU hardware is present, the FSS model shall provide calibrated demand outputs to the AOCS SCOE representing the output signal voltages that would be produced by the FSS according to the instantaneous solar illumination of each of the photo diodes within the sensor.

Configuration: 3 (possibly 4) separate Model Instances.

Timing: Execution and data output rate PPS/4.

Gaia


of 94



Power Input:


Power Output: N/A

Inputs: N/A

Simulation Inputs:

Description Source Spacecraft Attitude State Vector Dynamics Model 3-Axis Sun position relative to Spacecraft Dynamics Model


Description Source FSS line-of-sight orientation relative to the Spacecraft Body Frame


FSS Performance Parameters (Noise and Bias) Input File/RTS Data Load Command FSS misalignment Input File/RTS Data Load Command

Outputs:

Description Destination Q1 - Q4 detector voltage representation relative to Sun illumination on the photodiode detectors

EIU Model

Q1 - Q4 demand voltages for direct FSS or EIU Stimulation - for the hybrid bench

Avionics SCOE

Simulation Outputs:

Description Destination FSS current: analog PCDU Model

1553 Bus Data: N/A

Fault modes:


Gaia


of 94



3.3.2.8 Combined CPS Model

Description:

This model provides an accurate representation of the combined Chemical Propulsion System (CPS) functional and performance behaviour.

The CPS provides coarse Spacecraft attitude control through the use of 2 redundant banks of 8 chemical 10N Thrusters, operated through a set of Pyro Control Valves (PCV), Flow Control Valves (FCV) and Thruster Latch Valves (TLV).

The CPS interface is provided by the EIU, under the control of commands generated by the CSW.

The main function of the CPS Model is to provide thrust vectors to the Dynamics Model dependent on CPS commanded operation. The outputs from the CPS model shall take into account all conditions and behaviours that will influence the quality of the output. These conditions and behaviours may include, but not be limited to:

• Thruster real performance values.

• Orientation of the Thruster with respect to the spacecraft body frame,


• Latch valve and flow control valve status,

The CPS model shall ensure properly representative behaviour of any CPS housekeeping telemetry.

The CPS model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the CPS FMECA shall be selected by Astrium to be included in the CPS model. The CPS model shall provide representative data output signatures for the selected failures (e.g., corruption in the TM output / absence of TM output, etc.)

The CPS model shall be configurable according to the extent to which there is real ‘hardware in the loop.’ When Thruster simulation is provided by the Avionics SCOE (connected to the EIU), the model shall respond to Thruster pulse measurement data provided in real-time by the SCOE.


Timing: Execution and data input rate PPS/64. Data output rate PPS/2.

Gaia


of 94



Power Input: N/A

Power Output: N/A

Inputs:

Description Source (TBC) Pyro Control Valves (ON/OFF) PCDU Model (16+16) Thruster Latch Valves (ON/OFF) EIU Model (8+8) Flow Control Valves (ON Time as a percentage of the Simulation Cycle)

EIU Model

Simulation Inputs: N/A


Description Source Line-of-sight orientation relative to the Spacecraft Body Frame for each Thruster


Individual Thruster performance characteristics Input File/RTS Data Load Command Individual propellant tank pressures Input File/RTS Data Load Command Thruster misalignment Input File/RTS Data Load Command

Outputs:

Description Destination (2+2 Propellant tank pressure transducer voltages (as a function of tank pressures)

EIU Model

(16+16) Thruster Latch Valve status EIU Model (8+8) Thermistor values (Thruster Chamber Temperatures)

EIU Model

(2+2) (TBC) Thermistor values EIU Model

Simulation Outputs:

Description Destination Thrust vectors for each thruster (as a function of ON time relative to Simulation Cycle)

Dynamics Model

Propellant Consumption Dynamics Model

1553 Bus Data: N/A

Fault modes:

Type: (TBC) FCV/TLV stuck open FCV/TLV stuck closed Erroneous TLV status

Gaia


of 94



3.3.2.9 SREM Model

Description:

This model provides a simple representation of the SREM functional and performance behaviour.

The SREM is an ESA-furnished unit for measuring radiation. It interfaces to the CDMU data handling system via the EIU.

The SREM model provides dummy telemetry values to the EIU, and dummy telecommand acquisition.


Timing: Execution and data I/O rates PPS/8.

Power Input:


Power Output: N/A

Inputs:

Description Source Serial bus commands (RS422) EIU Model


Characterization Inputs: N/A

Outputs:

Description Destination Serial bus telemetry (RS422) EIU Model DC-DC Converter status: bi-level EIU Model Thermistor value: analog EIU Model

Simulation Outputs:

Description Destination SREM current: analog PCDU Model

1553 Bus Data: N/A

Fault modes: N/A

Gaia


of 94



3.3.2.10 Separation Straps Model

Description:

This model represents the Separation Straps (5x) interface to the CDMU.


Timing: Execution rate and data input/output rates PPS.

Power Input: N/A

Power Output: N/A

Inputs: N/A



Outputs:

Description Destination 5 x Separation Strap status (bi-level) CDMU Model

Simulation Outputs: N/A

1553 Bus Data: N/A

Fault modes: N/A

Gaia


of 94



3.3.2.11 EIU Model

Description:

This model provides an accurate representation of the AOCS Electrical Interface Unit (EIU) functional and performance behaviour.

The main function of the EIU is to provide the I/O interfaces between the CDMU and those AOCS units and functions not controlled directly by the Service Module 1553 Bus, namely:

• Fine Sun Sensors

• Combined Chemical Propulsion System (CPS)

• SREM (ESA-furnished radiation monitor)

• Discrete analog and bi-level inputs (TM)

• Direct commanded outputs (TC)

• Thermistors

The EIU decodes commands/data requests received from the CDMU SpaceWire bus interface and manages the data I/O as appropriate.

Analog inputs to the EIU are acquired through A/D conversion for digital representation on the CDMU bus. The EIU model shall allow for measurement error introduction to affect the acquired signals.

The EIU Model shall model the data exchange with the CDMU (SpaceWire BUS Model) for the transfer of data with the CDMU.

The EIU Model shall implement sufficient shared-memory space with the corresponding CDMU SpaceWire interface (real or simulated) to provide data buffers for the receive and transmit data (determined by the Execution Cycle frequency). The data buffers shall be configured as FIFO memory.

In the hybrid bench configuration (with no EIU hardware available) the data buffers shall be mapped across the Real-Time Network (shared memory) as an interface to the SpaceWire BUS Hardware cards provided by the Avionics SCOE - see Section 3.3.14).

The EIU model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the EIU FMECA shall be selected by EADS Astrium Ltd to be included in the model.

Configuration: Single Instance, internally redundant, selectable by telecommand.

Timing: Execution rate PPS/8. Data I/O rates are dependent on the timing requirements of the Models to which it interfaces.

Gaia


of 94



Power Input:

Description Source (1+1) LCL: Unit power: bi-level PCDU Model (2+2) LCL: Thruster Drive Electronics: bi-level PCDU Model

Power Output: N/A

Inputs:

Description Source (2+2) Propellant tank pressure transducer voltages: analog

CPS Model

(16+16) Thruster Latch Valve status: bi-level CPS Model (8+8) Thermistor values (Thruster Chamber Temperatures): analog

CPS Model

(2+2) (TBC) Thermistor values: analog CPS Model (3/4 x) Sun Sensor Q1 - Q4 detector voltages: analog

FSS Models

(1+1) Serial bus telemetry data (RS422) SREM Models (1+1) DC-DC Converter Status: bi-level SREM Models (1+1) Thermistor: analog SREM Models 6 x Cell Voltage Monitors: analog Battery Models (1+1) Battery Charge Current: analog Battery Models (1+1) Battery Discharge Current: analog Battery Models (4+4) (TBC) MPS Acquisitions: analog MPS Model (6+6) (TBC) TRSP Acquisitions: analog TRSP Models TBC x RFDU Switch configuration: bi-level RFDU Model 200 TBC x Thermistor values: analog Thermal Model (24+24) (TBC) Deployment switches: bi-level DSA Model 6 x (TBC) Deployment switches: bi-level Bipods Model (TBC) Analog inputs TBC (TBC) Discrete TM: bi-level TBC (TBC) Direct TM: bi-level TBC (4+4) Direct TC: bi-level (1553 bus RT configuration)

CDMU (Reconfiguration Model)



Description Source A/D conversion errors Input File/RTS Data Load Command

Outputs:

Description Destination (16+16) Flow Control Valves: bi-level CPS Model (8+8) Thruster Latch Valves (ON Time as a percentage of the Simulation Cycle)

CPS Model

(1+1) Serial bus command data (RS422) SREM Models 24 x SHP commands: bi-level Battery Model TBC x HPC commands: bi-level RFDU Model (64+64) (TBC) HPC commands: bi-level Various (unit ON/OFF commands) (16+16) (TBC) EHPC commands: bi-level Various

Gaia


of 94



Simulation Outputs:

Description Destination EIU currents (per/LCL): analog PCDU Model

SpaceWire Bus Data: (Cross-strapped Prime/Redundant BUS)

TM List (TBC) TC List (TBC) Tank Pressures EIU Reconfiguration Latch Valve Status TLV control Thermistors FCV commands (as a function of time) FSS detector voltages SREM configuration SREM measurement & housekeeping data HPC/EHPC EIU Housekeeping Data Data Request Commands

Fault modes:

Type: (TBC) Bus anomalies Output Driver failure Input Receiver failure

Gaia


of 94



3.3.2.12 Battery Model

Description:

A single Lithium ION Battery is used mainly to provide the Spacecraft power requirements during launch and early operation phases. Once the Spacecraft is sun pointing with the DSA deployed, the Battery is recharged and only used in the operational phase in the case of a major attitude anomaly.

As the PCDU Model is not required to run any power-balancing algorithm, the Battery Model shall only need to model the data handling interfaces with the EIU.



Power Input: N/A

Power Output: N/A

Inputs:

Description Source 24 x SHP commands: bi-level (cell balancing) EIU Model



Outputs:

Description Destination 6 x Cell Voltage Monitors: analog EIU Model (1+1) Battery Charge Current: analog EIU Model (1+1) Battery Discharge Current: analog EIU Model


1553 Bus Data: N/A

Fault modes: N/A

Gaia


of 94



3.3.2.13 PCDU Model

Description:

This model provides a simplified representation of the Power Control & Distribution Unit (PCDU) functional and performance behaviour.

The main function of the PCDU is to balance the primary power inputs (Solar Array and Battery) to provide a regulated 28V supply to all Spacecraft Units via a mixture of LCL and FCL circuits.

It is not required to model the power balancing algorithms. In this case, the PCDU Model shall be considered as an 'always on' variable 28V power supply with commandable power distribution to Spacecraft Units. In addition, all data-handling functionality needs to be modelled.

The PCDU model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the PCDU FMECA shall be selected by EADS Astrium LTD to be included in the model, but shall include as a minimum:

• LCL switch off

• BCDR failures (as appropriate)

• Main Bus under/over voltage



Power Input: N/A

Power Output:

Description Destination (TBC) Pyro Initiators (Pyro Control Valves): bi-level

CPS Model

(TBC) Pyro Initiators: bi-level DSA Model (TBC) Pyro Initiators: bi-level Bipods Model (19+5 TBC) Payload LCL Units: bi-level Payload Unit Models (24+2 TBC) Payload LCL Heaters: bi-level Thermal Model (29 TBC) Platform LCL Units: bi-level Platform Unit Models (24 TBC) Platform LCL Heaters: bi-level Thermal Model (4 TBC) Platform FCL Units: bi-level TRSP/CDMU Models

Inputs:

Description Source (4+4) Direct TC: bi-level (1553 bus RT configuration)

CDMU (Reconfiguration Model)

Simulation Inputs:

Description Source Unit currents (per LCL/FCL): analog All Unit Models


Outputs:

Description Destination (TBC) Direct TM (Alarms) CDMU Reconfiguration Unit Model


Gaia


of 94




TM List (TBC) TC List (TBC) LCL/FCL currents (derived from the Simulation Inputs)

LCL/FCL control

LCL/FCL status Pyro ARM/FIRE commands Main BUS voltage/currents TLV (as a function of time) Thermistors SREM configuration APS status HPC/EHPC Pyro ARM/FIRE status Data Request Commands PCDU Housekeeping Data

Fault modes:

Type: (TBC) LCL/FCL failures Pyro Initiator failures MPPT failure Battery regulation failure Bus failures

Gaia


of 94



3.3.2.14 MPS Model

Description:

This model provides an accurate representation of the Micropropulsion System (MPS) functional and performance behaviour.

The MPS provides fine Spacecraft attitude control during the Gaia science mode operation.

The MPS interfaces to the EIU for direct TM/TC acquisition. Thruster operation is controlled via the Platform 1553 Bus.

The main function of the MPS Model is to provide thrust vectors to the Dynamics Model dependent on MPS commanded operation. The outputs from the MPS model shall take into account all conditions and behaviours that will influence the quality of the output. These conditions and behaviours may include, but not be limited to:

• Thruster real performance values.

• Orientation of the Thruster banks with respect to the spacecraft body frame,


The MPS model shall ensure properly representative behaviour of any MPS housekeeping telemetry.

The MPS model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the MPS FMECA shall be selected by Astrium to be included in the MPS model. The MPS model shall provide representative data output signatures for the selected failures (e.g., corruption in the TM output / absence of TM output, etc.)

The MPS model shall be configurable according to the extent to which there is real ‘hardware in the loop.’

When Thruster simulation is provided by the Avionics SCOE (the MPE hardware unit is available), the model shall respond to Thruster pulse measurement data provided in real-time by the SCOE (TBC).

Configuration: Two Instances acting in redundancy.

Timing: Execution and data input rate PPS/64. Data output rate PPS/8.

Power Input:


Power Output: N/A

Inputs:

Description Source HPC (Unit ON/OFF): bi-level EIU Model



Description Source Line-of-sight orientation relative to the Spacecraft Body Frame for each Thruster Bank


Individual Thruster performance characteristics Input File/RTS Data Load Command Individual propellant tank pressures Input File/RTS Data Load Command Thruster Bank misalignment Input File/RTS Data Load Command

Gaia


of 94



Outputs:

Description Destination 4 x (TBC) MPS Acquisitions: analog EIU Model 1 x (TBC) MPS status: bi-level EIU Model

Simulation Outputs:

Description Destination Thrust vectors for each thruster (as a function of ON time relative to Simulation Cycle)

Dynamics Model

MPS current PCDU Model Gas Consumption Dynamics Model


TM List (TBC) TC List (TBC) MPS Housekeeping Data Thruster Firing commands

Fault modes:

Type: (TBC) Thruster failures MPE failures Bus failures

Gaia


of 94



3.3.2.15 TRSP Model

Description:

This model provides a simplified representation of the X-Band Transponder (TRSP) functional and performance behaviour.

The Transponder (Transmitter) modulates an X-Band RF signal with Spacecraft Telemetry and/or GAIA Science data (from the CDMU TM Frame Generator) for transmission to the Ground Station. The transmission path is selectable in the RFDU, for either:

• LGA1 Antenna

• LGA2 Antenna

• Phased Array Antenna (PAA) - the nominal on-station path

The Transponder (Receiver) accepts a modulated X-Band RF signal from the Ground Station, routed through either of the LGA Antennas (selectable by the RFDU). The received signal is demodulated, and the recovered Spacecraft Telecommand signal is routed to the CDMU (TC Decoder) for processing.

In addition, the Transponder provides a Spacecraft Ranging facility by looping the received X-Band signal back through the Transmitter for retransmission to the Ground Station.

For Simulation purposes the Spacecraft Telemetry and Telecommand data interfaces to the CDMU are processed by the RTS (directly) or connected to the CCS. Thus the TRSP Model need not consider these.

The TRSP Model need only consider the on-board TM and TC data handling requirements and model transmitted RF power towards the RFDU Model.

The TRSP model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the TRSP FMECA shall be selected by EADS Astrium LTD to be included in the model.

Configuration: Two Instances operating in redundancy. For each Instance, the TRSP receivers are always ON, the Transmitters are selectable.


Power Input:

Description Source 1 LCL: Transmitter power: bi-level PCDU Model 1 FCL: Receiver power: bi-level (always ON) PCDU Model

Power Output: N/A

Inputs:

Description Source 1 x HPC: bi-level (TRSP ON/OFF) EIU Model



Description Source Nominal Transmit power level (at RFDU interface)


Outputs:

Description Destination RF Downlink Power RFDU Model 6 x (TBC) TRSP Acquisitions: analog EIU Model

Gaia


of 94



Simulation Outputs:

Description Destination TRSP currents (per LCL/FCL): analog PCDU Model


TM List (TBC) TC List (TBC) TRSP Housekeeping Data (10-20) TRSP Configuration (10-20)

Fault modes:

Type: (TBC) Transmitter failure Receiver failure

Gaia


of 94



3.3.2.16 RFDU Model

Description:

This model provides a simplified representation of the RF Distribution Unit (RFDU) functional and performance behaviour.

The RFDU switches the X-Band downlink path between the TRSPs (Transmitters) and LGA1, LGA2 or the PAA.

In addition, the RFDU switches the X-Band uplink path between LGA1 or LGA2 and the TRSPs (Receivers).

The RFDU Model need only consider the on-board TM and TC data handling requirements and model the commanded switching requirements. In addition the Model shall provide the transmitted RF Power value towards the PAA corrected for internal path losses.

The RFDU model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the RFDU FMECA shall be selected by EADS Astrium LTD to be included in the model.

Configuration: Single Instance (each internal Switch has redundancy).


Power Input: N/A

Power Output: N/A

Inputs:

Description Source TBC x HPC: bi-level (Switch configuration commands)

EIU Model

RF Downlink Power RFDU Model



Description Source Downlink path losses to the PAA Input File/RTS Data Load Command

Outputs:

Description Destination RF Downlink Power (corrected for path losses) PAA Model TBC x Direct TM: bi-level (Switch status) EIU Model


1553 Bus Data: N/A

Fault modes:

Type: (TBC) Switch failures

Gaia


of 94



3.3.2.17 PAA Model

Description:

This model provides a simplified representation of the Phased Array Antenna (PAA) functional and performance behaviour.

The PAA is a non-standard equipment developed specifically for Gaia.

The PAA takes the downlink signal from the RFDU and transmits it towards the Ground Station.

Due to the rotation of the Spacecraft in normal on-station mode, the PAA is electronically steered to enable constant Ground Station contact.

The main purpose of the PAA Model is to provide the transmitted RF Power Vector to the Dynamics Model.

The PAA model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the PAA FMECA shall be selected by EADS Astrium LTD to be included in the model.



Power Input:


Power Output: N/A

Inputs:

Description Source 1 x HPC: bi-level (PAA ON/OFF) EIU Model RF Input Power RFDU Model

Simulation Inputs:

Description Source 3-Axis Earth position relative to Spacecraft Body Frame

Dynamics Model


Description Source Nominal Transmit power level (at RFDU interface)


PAA line-of-sight orientation relative to the Spacecraft Body Frame


Outputs: N/A

Simulation Outputs:

Description Destination PAA current: analog PCDU Model RF Force Vector relative to Spacecraft Body Frame

Dynamics Model

Gaia


of 94




TM List (TBC) TC List (TBC) PAA Housekeeping Data (10-20) PAA pointing commands

Fault modes:

Type: (TBC) Bus anomalies SSPA failures

Gaia


of 94



3.3.2.18 CDU Model

Description:

This model provides a simplified representation of the Clock Distribution Unit (CDU) functional and performance behaviour.

The CDU provides a high stability clock for Gaia Instrument synchronization.

The CDU Model is not required to provide synchronization to the Simulated CDMU. Therefore the Model shall be limited to the simulation of its I/O.

The CDU model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the CDU FMECA shall be selected by EADS Astrium LTD to be included in the model.

Configuration: Two Instances in redundant operation.

Timing: Execution and Data I/O rates PPS/8.

Power Input:


Power Output: N/A

Inputs:

Description Source 1 x HPC: bi-level (CDU ON/OFF) EIU Model VC0 Time Strobe Synchro: pulse (TBC) CDMU (SCET Model)



Outputs:

Description Destination PPS: pulse (TBC) CDMU (SCET Model) TBC x CDU Acquisitions: analog EIU Model

Simulation Outputs:

Description Destination CDU current: analog PCDU Model

1553 Bus Data: The 1553 BUS protocols and message exchange shall be managed by the PLM 1553 BUS Model (see Section 3.3.2.1). A preliminary indication of the TM/TC message exchange for this Model is given below:

TM List (TBC) TC List (TBC) CDU Housekeeping Data

Fault modes:

Type: (TBC) Bus anomalies

Gaia


of 94



3.3.2.19 MDE Model

Description:

This model provides a simplified representation of the Mirror Drive Electronics (MDE) functional and performance behaviour.

The MDE provides the drive for a mechanism used to position the M2 Mirror with 5 degrees of freedom.

The MDE Model shall also simulate the M2 Mirror orientation.

The MDE model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the MDE FMECA shall be selected by EADS Astrium LTD to be included in the model.



Power Input:


Power Output: N/A

Inputs: N/A



Outputs: N/A

Simulation Outputs:

Description Destination MDE current: analog (may be MODE dependent - TBC)

PCDU Model


TM List (TBC) TC List (TBC) M2 Mirror Position ON/OFF (for each of 5 Motors) MDE Housekeeping Data (MODE & state) Position command (for each Motor)

Fault modes:

Type: (TBC) Bus anomalies Motor failure Incorrect Mirror position

Gaia


of 94



3.3.2.20 OSE Model

Description:

This model provides a simplified representation of the Optical Source Electronics (OSE) functional and performance behaviour.

The OSE provides the source to switch on the optical stimulation of a specific CCD of the FPA.

The OSE Model shall provide simple simulation of the OCE I/O interfaces.

The OSE model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the OSE FMECA shall be selected by EADS Astrium LTD to be included in the model.



Power Input:


Power Output: N/A

Inputs: N/A



Outputs: N/A

Simulation Outputs:

Description Destination OSE current: analog (may be MODE dependent - TBC)

PCDU Model


TM List (TBC) TC List (TBC) OSE Housekeeping Data (MODE & state) OSE ON/OFF Optical configuration commands

Fault modes:

Type: (TBC) Bus anomalies OSE failure

Gaia


of 94



3.3.2.21 FPA Model

Description:

This model provides a simplified representation of the Focal Plane Array (FPA) functional and performance behaviour.

The FPA provides observation data to each of 7 Video Processing Units (VDU) via SpaceWire links. The links are controlled through 7 Interface Modules (IM) provided as part of the FPA.

The FPA Model shall only simulate the IM status. No SpaceWire data simulation is required.

In addition the Model shall simulate the FPA Decontamination Heater.

The FPA model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the FPA FMECA shall be selected by EADS Astrium LTD to be included in the model.

Configuration: Single Instances.


Power Input:

Description Source 7 x LCL: bi-level (one for each IM) PCDU Model 1 x LCL: bi-level (one for the Heater) PCDU Model

Power Output: N/A

Inputs: N/A

Simulation Inputs:

Description Source FPA Temperature Thermal Model


Outputs:

Description Destination 7 x IM Status: bi-level (one for each IM) VPU Models

Simulation Outputs:

Description Destination FPA currents: analog (for each LCL) PCDU Model

1553 Bus Data: N/A

Fault modes:

Type: (TBC) IM failures Heater failure

Gaia


of 94



3.3.2.22 VPU Model

Description:

This model provides a simplified representation of the PLM Video Processing Unit (VPU) functional and performance behaviour.

The main function of the VPU is to calculate star positions and rates for each scan of both telescopes. Image data is transferred to the VPU using a SpaceWire BUS link from the FPA. Star calculations are transferred to the PDHU using a SpaceWire BUS link. In addition, the VPU provides star data to the CDMU via the PLM 1553 BUS for AOCS station keeping.

The VPU contains several different modes, commanded from the CDMU, which have different properties (timing and noise) for data output.

Each VPU measures 2 sets of 2D star speeds, with each speed from measurements made at different times using 2 separate CCDs in the FPA. The VPU outputs a star rate message to the CDMU at PPS frequency (TBC). The number of stars within a message varies up to 2 FOV x 30 stars/FOV (TBC). The star flow rate is modelled as a Poisson process, with the mean flow rate a simulation input (and different for different modes).

The star rates have different noise properties in different modes, modelled as Gaussian processes with variance, which is VPU mode (and possibly star) dependent.

Output of the star rate measurements is expected to be inhibited for several seconds after a commanded mode change.

The measurement message may also contain 'false stars' due to simulated cosmic ray effects, with different error properties to genuine star measurements. Different VPU may have different calibration error values (due to CCD row-dependent errors).

The VPU receives a 2D speed measurement from the CDMU which is used to drive some of its internal calculations (to model star confirmation process at CCD AF1). Under conditions of high-rate error the model will inhibit output of the star rates (equivalent to when AF1 confirmation fails, e.g., after a meteoroid strike).

The VPU model shall calculate star position and rate data relative to telescope scan position and rate, based on Spacecraft attitude and rate data from the Dynamics model for AOCS station keeping. Star positions and rates shall be provided as part of the Model functional code from the FVB bench.

The VPU shall model all data I/O transfer (telemetry and telecommands) with the CDMU on the PLM 1553 BUS.

The VPU shall not be required to model any data exchange on the SpaceWire BUS. It shall be limited to modelling SpaceWire BUS availability and status.

The VPU model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the VPU FMECA shall be selected by EADS Astrium LTD to be included in the model.

Up to 7 VPU Models can be simulated. The number required for any given simulation shall be determined by a characterization parameter.

Configuration: Seven Independent Instances.


Gaia


of 94



Power Input:

Description Source LCL: Unit power: bi-level PCDU Model

Power Output: N/A

Inputs: N/A

Description Source Input IM Status: bi-level FPA Model

Simulation Inputs:

Description Source Spacecraft Attitude State Vector Dynamics Model Star density (stars/s for both telescopes) - possibly for several magnitude ranges

Dynamics Model

Cosmic ray intensity (false stars) Dynamics Model


Description Source Number of simulated VPU: Integer Input File/RTS Data Load Command VPU initialization variables Input File/RTS Data Load Command

Outputs:

Description Destination Output IM Status: bi-level PDHU Model

Simulation Outputs:

Description Destination VPU current: analog PCDU Model


TM List (TBC) TC List (TBC) AOCS star data: VPU mode configuration

• Star position and rate (with reference to scan and telescope)

IM configuration

• Measurement time-stamp SpaceWire management • Number of stars acquired Data Request Commands

• Number of stars confirmed • Measurement quality

IM Housekeeping Data VPU Housekeeping Data

Fault modes:

Type: (TBC) 1553 Bus anomalies SpaceWire Bus anomalies IM failures

Gaia


of 94



3.3.2.23 PDHU Model

Description:

This model provides a simplified representation of the PLM Payload Data Handling Unit (PDHU) functional and performance behaviour.

The main function of the PDHU is to transfer star packet data collected from (up to) 7 VPUs to the CDMU (Transfer Frame Generator).

The PDHU collects data from the VPUs via individual SpaceWire links controlled by their own Interface Module (IM) and stores the data in PDHU internal memory. Data transfer to the CDMU from internal memory utilizes a separate SpaceWire link and IM.

The PDHU Model shall not be required to model any data exchange on the SpaceWire with the VPUs. It shall be limited to modelling SpaceWire BUS availability and status with the VPUs.

The PDHU model shall generate star packets internally to PDHU memory. Star packets shall be derived from one of the following sources:

• File. Contains star packet definition and data rate (one for each VPU).

• Star Density Profile Scenario. The scenario will be used to generate data in real time to fill memory in the PDHU.

The PDHU model shall model all data I/O transfer (telemetry and telecommands) with the CDMU on the PLM 1553 BUS. The 1553 BUS protocols and message exchange shall be managed by the PLM 1553 BUS Model (see Section 3.3.2.1).

Up to 7 VPU Models can be simulated as inputs to the PDHU model. The number required for any given simulation shall be determined by a characterization parameter.

Although not required to simulate the complete Mass Memory Module of the PDHU, the PDHU Model shall define a representative Mass Memory configuration with respect to register states defining Memory filling and availability.

The PDHU Model shall model the data exchange with the CDMU (SpaceWire BUS Model) for the transfer of Star Packet data with the CDMU.

The PDHU Model shall implement sufficient shared-memory space with the corresponding CDMU SpaceWire interface (real or simulated) to provide data buffers for the receive and transmit data (determined by the Execution Cycle frequency). The data buffers shall be configured as FIFO memory.

In the hybrid bench configuration, the data buffers shall be mapped across the Real-time Network (shared memory) as an interface to the SpaceWire BUS Hardware cards provided by the Avionics SCOE - see Section 3.3.14.

The PDHU model shall incorporate a range of commandable failure conditions. A subset of the failures defined in the PDHU FMECA shall be selected by EADS Astrium LTD to be included in the model.

Configuration: Two Instances operating in cold redundancy.


Gaia


of 94



Power Input:

Description Source LCL: Unit power: bi-level PCDU Model

Power Output: N/A

Inputs: N/A

Description Source Input IM Status: bi-level (per VPU) VPU Models

Simulation Inputs:

Description Source Spacecraft Attitude State Vector Dynamics Model


Description Source Number of simulated VPU: Integer Input File/RTS Data Load Command Star Packet Definition Files Input File Star Density Profile Scenario Input File

Outputs:

Description Destination Output IM Status: bi-level CDMU Model

Simulation Outputs:

Description Destination PDHU current: analog PCDU Model


TM List (TBC) TC List (TBC) PDHU Memory Management Report PDHU mode configuration IM Housekeeping Data SpaceWire management PDHU Housekeeping Data (mode, SpaceWire status)

PDHU Memory Management

SpaceWire Bus Data: (Cross-strapped Prime/Redundant BUS)

TM List (TBC) TC List (TBC) Star Packet Data (to CDMU)

Fault modes:

Type: (TBC) SpaceWire Bus anomalies Memory failures IM failures

Gaia


of 94



3.3.2.24 DSA Model

Description:

This model represents the Deployable Sunshield Assembly (DSA) model.

The DSA provides sun protection to the Gaia Instrument. The DSA is stowed during launch and early operations. Deployment of the shield is initiated either by Pyro or Thermal-Knife devices (TBD).

The DSA model shall be limited to the functional interfaces (deployment mechanisms and switch status). There is no need to model the dynamic disturbances during deployment.

DSA failures shall be simulated through setting characterization parameters (i.e., large deployment times for switches).



Power Input:

Description Source LCL: Unit power: bi-level PCDU Model either: (TBC) Pyro Initiators: bi-level, PCDU Model or, (TBC) Thermal Knife Initiators: bi-level PCDU Model

Power Output: N/A

Inputs: N/A



Description Destination Deployment time per deployment switch: bi-level Input File/RTS Data Load Command

Outputs:

Description Destination (24+24) (TBC) Deployment switch status: bi-level EIU Model

Simulation Outputs:

Description Destination DSA current: analog PCDU Model Thermal Knife device current: analog (TBD) PCDU Model

1553 Bus Data: N/A

Fault modes: N/A

Gaia


of 94



3.3.2.25 Bipods Model

Description:

This model represents the Bipods.

The Bipods provide Thermal and Mechanical isolation between the Service Module and Payload Module.

The Bipods model shall be limited to the functional interfaces (deployment mechanisms and switch status).

Bipod failures shall be simulated through setting characterization parameters (i.e., large deployment times for switches).



Power Input:

Description Source LCL: Unit power: bi-level PCDU Model (TBC) Pyro Initiators: bi-level, PCDU Model

Power Output: N/A

Inputs: N/A



Description Destination Deployment time per deployment switch: bi-level Input File/RTS Data Load Command

Outputs:

Description Destination 6 x (TBC) Deployment switch status: bi-level EIU Model

Simulation Outputs:

Description Destination Bipods current: analog PCDU Model

1553 Bus Data: N/A

Fault modes: N/A

Gaia


of 94



3.3.3 ERC32 Emulator

3.3.3.1 Basic Requirements

RTS-1113/RTS_URD-45,51-53,131/T,A,R

The ERC32 Emulator shall realize the following basic requirements:

-1 The emulator shall be based on a COTS (or previously developed in-house) tool consisting of a software library interface between the Simulation and the CSW.

-2 The full instruction set of the ERC32 processor shall be available for emulation. -3 The emulation shall be accurate and cycle true with respect to simulated execution time. -4 Memory accesses with respect to wait-states shall be modelled correctly - where a memory area is

split into several banks, an average wait-state is sufficient for each bank. -5 The emulator shall support the installation of callback functions which respond to:

• I/O Access • Interrupts • Trap Handling • Simulation time dependent events

-6 The emulation shall implement a time-based (SRT) event-generation mechanism for installation and de-installation of time dependent external modules.

-7 All processor registers shall be emulated accurately to support target-specific configurations. -8 It shall be possible to generate both level and edge based interrupts to the emulator. -9 It shall be possible to define the clocking frequency of the emulated processor by initialization

parameter. -10 The emulator shall control and increment a simulated real-time clock (SRT). -11 The SRT shall be based on the processor clock frequency and updated following each instruction

according to its processing time. -12 It shall be possible to halt emulation at any time, at which time the SRT shall be halted. -13 It shall be possible to debug the CSW source code. -14 The emulator shall provide a routine to save its actual state and context (memory, cache, registers ,

etc.) to file. -15 The dump file shall be up-loadable at a later date to allow a Simulation to continue from that state.


A debugging feature shall be available allowing control of the CSW instruction-by-instruction. These feature may be provided by an external debugger tool (such as GNU).

RTS-7065/CREATED/T

It shall be possible to configure dedicated memory areas (up to 128 octets) such that when a memory cell of the defined area is modified by the CSW, the contents of the modified cell are copied to a specified file.

Gaia


of 94



3.3.4 Emulator Interface Layer

The Emulator Interface Layer provides the link between the ERC32 Emulation process (Library) and the RTS Simulator Applications and Simulated CDMU Model Layer.

RTS-617/CREATED/T,A

At START of Simulation, the Emulator Interface Layer shall determine the ERC32 Emulation Processor speed from an initialization parameter (see Section 3.3.7), configure the ERC32 Emulator and start the Emulation process.


During Simulation, the Emulator Interface Layer shall transfer the ERC32 Emulator I/O interfaces to the Simulated CDMU Model layers with timing determined by the Emulation process.


The Emulator Interface Layer shall interpret the C&C Emulator command structure defined in Section 3.3.3.2 and utilize ERC32 Emulator Library functionality to implement the command requests.

Gaia


of 94



3.3.5 Simulated CDMU Model Layer


The Simulated CDMU Model Layer shall comprise software Models for all OBC Hardware (with the exception of the OBC Processor itself, which is modelled by the ERC32 Emulator).


The CDMU Simulation process shall provide a simulated time representative at 99.5% of the equivalent module run on the real CDMU Hardware.

RTS-1285/RTS_URD-43,50,131/T,A,R

The Simulated CDMU Model Layer shall comprise software Models (including their hot/cold redundancy requirements) for the following CDMU hardware elements:

RAM Memory Module PROM Memory Module EEPROM Memory Module Safe Guard Memory Module Reconfiguration Module TC Decoder (Transponder Interface) TM Frame Generator (Transponder Interface) Timing and Synch Module (SCET) 1553B BUS Controller Interface Modules SpaceWire BUS Controller Interface Modules Mass Memory Module


The software Models shall be designed in accordance with the supplied CDMU Documentation (RD1, RD2 and RD3).


All components around the OBC Processor shall be functionally Modelled with respect to:

Address space under which they are accessible from the CPU (Register Address) Time behaviour for carrying out the called function

Note: the internal behaviour of any such component (ASIC or FPGA , etc.) need not be modelled, only its functionality.

RTS-5370/CREATED/R

For scoping purposes, prior to release of the CDMU Documentation (RD1 - RD3), the RTS subcontractor shall refer to the CDMU Requirements Specification [AD07] for details of the Modelling requirements for the CDMU peripherals.

Gaia


of 94



3.3.6 TM/TC SCOE Simulator

RTS-1372/CREATED/R

In the numeric bench configuration, the RTS shall implement a TMTC SCOE Simulator.

Note: This guarantees the reuse and compatibility of CCS Test Procedures on the numerical and hybrid benches).


The TMTC SCOE Simulator shall support all relevant functionality (as defined in RD04) to generate the final Spacecraft Telecommands and de-commutate the Spacecraft Telemetry.


The TMTC SCOE Simulator shall support the transfer of TC and TM data between the CDMU TIF Simulation Models (transfer frame level) and the CCS Interface (Source Packet level) taking into account pre-commanded values for MAPID and VCID.

Gaia


of 94



3.3.7 Initialization

Initialization is the process by which the RTS is configured to a known state prior to start of a Simulation.

The process is scheduled by the RTS Core Application during start-up, or can be scheduled via the Command and Control interface by C&C Command or by Test Sequence (RESET).


Initialization data shall be provided in the form of human-readable files (such as XML).


Initialization files shall consist of:

One System Characterization File One Initialization File for each configured Model One Internal Datalog Schedule file One External Datalog Schedule file Simulated Telemetry definition files Spacecraft Telemetry and Telecommand definition files One Real-time Network Map File One I/O Calibration File

RTS-1929/RTS_URD-39/T,I

The System Characterization File shall define configuration requirements for the Simulation as follows:

Simulator configuration: • Whether CSW emulation is required (the numerical bench configuration), and if so:

• The file path of the CSW binary image • The destination of the CSW binary image (EEPROM, RAM or Mass Memory) • The file path of the Safe Guard Memory (SGM) content • The file path of the bootstrap PROM content • The ERC32 Emulator processor clock frequency

• Any other user-definable Simulation parameter not mentioned Model configuration:

• Which Models are to be executed • Model interface (simulated or real-time) • The order of Model execution

Data configuration: • The path of the Simulated Telemetry definition file to be loaded • The paths of the Spacecraft Telemetry and Telecommand definition files to be loaded (if required

under local RTS MMI control)

Gaia


of 94



RTS-2003/RTS_URD-39/T,I

Model Initialization Files (one for each configured Model) shall define initial configuration requirements for the Model as follows:

Input variable: Symbolic name, initialization value and from where derived (soft value from Simulation or 'real' value from Avionics SCOE) Output variables: Symbolic name, initialization value and destination (soft value to Simulation or 'real' value to Avionics SCOE) Characterization variables: Symbolic name and initialization value Note: These are parameters internal to the Model which define how the Model operates: these are made visible to the Simulation for adaptation and logging purposes Calibration variables: Symbolic name and initialization value Note: For those Models which may interface to the Avionics SCOE to provide real-time data to the Spacecraft hardware, these variables define the calibration to be applied to the outputs values for direct control of the Avionics SCOE output Internal parameters: Symbolic name Note: These are parameters internal to the Model (not part of the normal I/O) such as results from internal computation: these are made visible to the Simulation for adaptation and logging purposes Pre-execution strategy: Defines the number of times the Model function should be executed prior to start of Simulation. Note: It is recognized that some Models need to be executed a number of times prior to Simulation start for internal configuration purposes.


The Internal Datalog Schedule file shall:

Define the data logging requirements for local disc archive of all Simulation parameters (with the exception of Spacecraft Telemetry) List each parameter to be archived by Symbolic Name (as defined in the System and Model initialization files) Define the logging rate and offset (in terms of Simulation Cycles) and status (enabled/disabled) for each parameter identified A default Internal Datalog Schedule file shall be supplied (in a format to be determined by the subcontractor) listing: All currently known Simulation parameters, enabled, to log at a Simulation Cycle rate determined by their corresponding Model I/O rates


The External Datalog Schedule file shall:

Define the data logging requirements for Simulated Telemetry Define the logging rate and offset (in terms of Simulation Cycles) and status (enabled/disabled) for each parameter identified A default External Datalog Schedule file shall be supplied (in a format to be determined by the subcontractor) listing: • All identified Simulated TM parameters, logging enabled, to log at a Simulation Cycle rate determined

by their corresponding Model I/O rates


The Simulated Telemetry definition file shall define Simulation parameters for transmission to the CCS.

Gaia


of 94



RTS-2064/CREATED/I

A default Simulated Telemetry definition file shall be provided, in either the Open Centre ACID file or SCOS2000 MIB ICD Issue 6.1 formats, consisting of: All currently known Simulation parameters.

Note: The data logging schedule can be adapted at any time after initialization via the Command and Control Interface, by Command Line, Test Procedure or from the RTS MMI (see Section 3.3.11).

For the numerical bench configuration (SVF), when no CCS is connected to the RTS, the RTS must process Spacecraft Telemetry and Telecommands.

The Spacecraft Telemetry definition file defines the Telemetry format and structure produced by the (Simulated) CDMU.

The Spacecraft Telecommand definition file defines the Telecommand list and format for transmission to the (Simulated) CDMU.

The Spacecraft Telemetry and Telecommand definition files are an extraction from the Spacecraft Database. The files shall be configured and supplied by Astrium in either the OpenCentre ACID file format or SCOS2000 MIB ICD (Issue 6.1).


The Real-time Network Map file shall define Shared Memory allocation for data I/O between the RTS and the external EGSE - see Section 3.3.14.1 for details.

RTS-2708/CREATED/R

The Real-time Network Map file shall be provided to the external EGSE providers in a format to be specified by the RTS subcontractor.


Initialization files shall be interpreted at run-time without need for recompilation of the RTS executable.

Gaia


of 94




The initialization process shall:

Load the System Characterization file and initialize the Simulation parameters defined therein. For the hybrid bench configuration: • Load the Real-time Network Map file and configure the Real-time Network PCI card Load the Spacecraft Simulated Model Initialization File for each configured Model, map and initialize the Model variables as defined within (see Section 3.3.8). For the hybrid bench configuration: • Load the Real-time Network Map file and configure the Real-time Network PCI card mapping for

external EGSE data transfer • Load the I/O Calibration file and map the Calibration Values to those Models configured for real-time

operation with the external EGSE (Avionics SCOE). Link to (or load) the configured Model functions. If defined as part of the Pre-execution strategy, execute each Model the defined number of times. If configured for Emulation: • Load the CDMU Simulated Model files for each configured Model and map the Model variables and

register addressed as defined within (see Section 3.3.8). • Link to (or load) the Model functions. • Transfer the CSW binary image from file to the specified location (EEPROM, RAM or Mass Memory

Model). • Transfer the SGM contents binary image from file to SGM (Model). • Transfer the bootstrap PROM contents binary image from file to PROM (Model). • Configure the ERC32 processor clock frequency. Load the Simulated Telemetry definition file and configure the data logging schedule as defined therein. If operating under the RTS MMI (no CCS attached), load the Spacecraft Telemetry and Telecommand definition files


It shall be possible to load the CSW binary image (maximum 2MBytes) in less than 1 minute.


It shall be possible to load the SGM content binary image (maximum 256kBytes) in less than 15 seconds.

Gaia


of 94



3.3.8 Memory Mapping

Memory mapping provides the relationship between the Model parameters and the Onboard TM/TC (I/O) data exchange between the Simulators and/or the Avionics SCOE Interface (actual hardware channels) and the FPA Simulator and Star Tracker SCOE..

RTS-1401/CREATED/T,R

It is not a requirement that the RT Simulator implement a “Simulated Harness” structure to map the I/O. I/O mapping shall utilize the Symbolic Name applied to all Simulation parameters to provide interconnection detail.


During the initialization phase, failure reports shall be generated for any Model I/O variables which are left 'unconnected' or 'unmapped'.


During the initialization phase, failure reports shall be generated for any Model I/O variables which are inconsistently mapped, that is variables mapped to inconsistent data type.

Gaia


of 94



3.3.9 Command and Control Interface

The Command and Control Interface (C&C) provides the interface between the Simulation Process and the CCS and/or the RTS MMI.


The C&C shall accept, decode and execute commands from the following sources:

RTS MMI Command Line CCS Command Line CCS Test Sequence

RTS-1404/CREATED/T

The C&C data exchange with the CCS shall utilize the message protocols as defined below:

• Messages sent to the CCS shall utilize the EGSE Internal Housekeeping TM Source Packet structure defined in Section 3.3.3 of the EGSE ICD [AD03].

• Messages sent by the CCS shall utilize the EGSE Command and Control Source Packet structure defined in Section 3.3.4 of the EGSE ICD [AD03].

• Equipment specific Application IDs are given in Appendix 2 of the EGSE ICD [AD03].

RTS-1405/CREATED/T

All data received by the C&C shall be acknowledged by ACK/NAK reply in accordance with Section 3.3.4 of the EGSE ICD [AD03].

RTS-1406/CREATED/T

The C&C interface shall be interrogated on a routine basis by the Simulator applications when Simulation is suspended.

RTS-1407/CREATED/T

When a Simulation is in progress, the C&C Interface shall be serviced at every Simulation cycle.

RTS-2244/CREATED/T

The C&C shall generate Messages to the Event Log File detailing all commands received, decoded and executed.

RTS-2245/CREATED/T

All commands received which cannot be decoded (i.e. containing syntax errors, unrecognized or out of sequence commands) shall generate a Warning Message to the Event Log File (see Section 3.3.11).

RTS-7087/CREATED/T

Loss of the interface to the CCS shall not corrupt the Simulation Process.

RTS-7088/CREATED/T

If lost, the RTS shall re-establish the CCS interface automatically using the standard client/server protocols defined in Section 3.2 of [AD03].

Gaia


of 94



3.3.9.1 C&C Command Interpreter


The C&C shall provide a command structure and interpreter to provide the following features:

Simulation control: • Start a Simulation with current parameter settings (if issued from a Test Sequence, CCS or from the

RTS MMI, the Sequence name shall be defined by the user) • Stop the current Simulation (close out log files, reset Simulation time) • Reset the Simulator (reload default parameter values - run the Initialization process defined in 3.3.7) • Create a dump file of current settings:

The DUMP file shall contain all Simulation settings, configuration, current parameter values and Simulation time.

• Load Simulation settings saved by a previous dump command Note: the intention is to be able to start a Simulation from the same point at which a dump was executed. • Load the specified CSW binary image to a specified destination (EEPROM, RAM or Mass Memory) -

assume defaults from the Initialization process if not specified. • Load the SGM content binary image from the specified source file - assume default path from the

Initialization process if not specified. • Load the bootstrap PROM content binary image from the specified source file - assume default path

from the Initialization process if not specified.

RTS-1977/RTS_URD-88,128,132,134/T,A,R

It shall be possible to set Simulation parameters for adaptation purposes and fault injection. This shall include all parameters visible to the Simulation process: (see Section 1.5.1 for a definition of terms)

Model Input and Output parameters Model Characterization parameters Model Internal parameters Simulation settings (only available when Simulation is stopped)

RTS-1978/CREATED/T

Unless specifically stated, it shall be possible to set any Simulation Parameter on-the-fly (while the Simulation is running).

RTS-2111/CREATED/T

Parameter adaptation shall be user-definable as follows:

• One-shot (for a single simulation cycle only). • Timed (for a fixed period of time defined by ‘number of simulation cycles’). • Lock (freeze at current value). • Unlock • Ramp (with user-defined start/stop and step values). • Simulate (by explicit values from a user-defined file).

RTS-1423/CREATED/T

It shall be possible to read the current value of any Simulation parameter visible to the Simulation process, by command line or Test Procedure (including Spacecraft Telemetry).

RTS-2141/CREATED/T

It shall be possible to adapt the Data Logging schedule for all parameters visible to the Simulation process.

Gaia


of 94




The logging process command shall be user-defined as follows:

• One-shot (report value on next simulation cycle only) • Timed (one-shot but after a fixed period of time defined by ‘number of simulation cycles’). • Periodical (logged repetitively at a user-defined rate in simulation cycles). • Location (to local log file and/or to CCS and/or to RTS MMI display). Note: Only Spacecraft Telemetry, or parameters defined as Simulated Telemetry (see Section 3.3.7) can be logged to the CCS. • Disable (data logging for the parameter defined) • Enable (data logging for the parameter defined)


Where appropriate, commands shall reference Simulation Parameters by their Symbolic Name and Telemetry data by their Application Process Identifier APID - as defined in the Spacecraft Telemetry and Simulated Telemetry definition files (see Section 3.3.7).

Gaia


of 94



3.3.10 SimAIT Model Layer

In one special configuration, known as SimAIT, the RTS is used as part of a process for developing Test Procedures for AIT operations.

The SimAIT Test Bench is a pure numerical facility utilising the RTS connected to the CCS. In order for Test Procedures to be developed which interface to Spacecraft EGSE, and for those interfaces to be debugged without connection to the EGSE, the RTS provides simple Models of the Spacecraft EGSE.


The RTS supplier shall provide Software Models of the following Spacecraft EGSE:

TM/TC SCOE Avionics SCOE TT&C RF SCOE Power/Pyro SCOE Dynamic FPA Simulator CDU EGSE PLM EGSE


The EGSE Models shall be limited to replication of the EGSEs' CCS Command and Control Interface to prevent CCS triggering failures during Test Procedure development.

EGSE Model TMTC ICDs shall be provided to the Subcontractor in accordance with the schedule defined in the Statement of Work.

RTS-2394/CREATED/T

The EGSE Models shall implement the CCS interface in accordance with Sections 3.3.3 and 3.3.4 of the EGSE ICD [AD3].

RTS-6463/CREATED/T

It shall be possible to enable any of the SimAIT EGSE Models, in any configuration of the RTS, to allow Test Procedure development to take place when EGSE is unavailable (see Section 3.3.7).


EGSE Model execution shall be scheduled directly by the Command and Control Interface by commands from CCS Test Procedures (they are not executed routinely as part of the Simulation Cycle).

Gaia


of 94



3.3.11 Data Logging Cycle

Data logging is the process by which the RTS displays and archives data and information about the Simulation process.

Data Logging is scheduled every Simulation cycle (simCycle) following Model Computation ( see Section 3.3.1).


Data shall be logged to the local archive hard disc and/or the CCS in accordance with the current Datalog Schedule (defined during initialization and adapted via the Command and Control Interface).


The following separate and distinct log files shall be created and maintained throughout a Simulation:

Spacecraft Telemetry Log File (when under control of the RTS MMI - no CCS connected): • Spacecraft Telemetry and Telecommand data shall be archived in CCSDS packet format, as

defined in the Telemetry and Telecommand definition files (see Section 3.3.7), for direct archive to binary files

• Any Telemetry data not specified in Telemetry definition files shall be archived as raw data Simulation Parameter Data Log Files Log File for the SVM 1553 BUS Log File for the PLM 1553 BUS Log file for the CDMU/EIU SpaceWire BUS Log file for the CDMU/PDHS SpaceWire BUS Event Log File, to include: • Command Logs from the C&C Interface • Error and Warning Messages • Simulation Model Messages - those messages defined within and generated by Model functions

(such as MODE changes)

Simulation Parameter Log Files are used to archive simulated data. Simulated data archiving configuration is determined by the Internal Datalog Schedule file (see Section 3.3.7), which identifies the frequency at which each parameter is to be archived (from PPS/64, PPS/32 ... to PPS rate).


A separate Simulation Parameter Log File shall be created for each archive rate identified in the Internal Datalog Schedule file (i.e., one file for PPS/64 archiving, one for PPS/32 etc.).

Gaia


of 94




Simulation Parameter Log Files shall be constructed using the ".res" format identified below and saved in binary:

1st HEADER FIELD: (General information)

"data3" 0x00 "comment1" 0x00 "comment2" 0x00 ... "last_comment" 0x00 0x01

where: "data3" identifies that IEEE double format is used "comment..." fields are used to provide information about the test in progress 0x00 data byte is used to separate data within a field 0x01 data byte is used to separate fields

2nd HEADER FIELD: (Data structure information)

"Name1" 0x00 "Name1Units" 0x00 "Name2" 0x00 "Name2Units" ... "lastName" 0x00 0x01

where: "Name..." identifies the Symbolic Name of the data included in the archive "Name...Units" identifies the electrical units associated with each archived data

DATA FIELDS: (Archive data)

Value1 Value2 ... LastValue

where: "Value..." are the parameter values listed in the order specified in the 2nd Header Field coded as IEEE defined 8-Byte doubles with big-endianity


The first logged parameter ("Name1: Value1" using the convention identified above) of each Simulation Parameter Log File shall be the Simulated Time (sTime) relative to the data that follows.

Note: This helps to maintain synchronization with all other log files.

RTS-7066/CREATED/T

All simulation parameters (including CSW variables) shall be logged by Symbolic Name.

RTS-7068/CREATED/T

When initiated by Test Sequence (from the RTS MMI or CCS), log files shall be associated with the calling Sequence.


All Messages to the Event Log File shall be tagged with one of the classifications: MESSAGE, WARNING or ERROR.


All data and messages shall be time-stamped with both System clock time and the Simulation time (sTime) relative to the current Simulation cycle.

Note: When controlled by the CCS, System clock time is synchronized to the CCS System clock. This ensures coherence between the RTS and CCS logged data.


When connected to the CCS the RTS shall log the Simulation time (sTime) as a Simulated Telemetry parameter at least once per second while a Simulation is active.

Gaia


of 94



3.3.12 Error Detection

This section defines the Simulator response to errors and the reporting structures used to record these events.


The Simulators shall distinguish between the following two event types, and action them as defined:

High Severity Error (problems detected by the RTS which invalidate the Simulation) Low Severity Error (potentially unintended situations detected by the RTS which would not invalidate the Simulation)

RTS-1432/CREATED/T

On detection of a High Severity Error Event the RTS shall:

Schedule a message of classification ‘ERROR’, for logging during the current Simulation Cycle STOP the current Simulation(s) at the end of the current Simulation Cycle (unless a fatal error occurs)

RTS-1435/CREATED/T

On detection of a Low Severity Error Event the RTS shall:

Schedule a message of classification ‘WARNING’, for logging during the current Simulation Cycle Continue the current Simulation

RTS-1438/CREATED/A,R

High Severity Event detection shall include:

Segment violation Floating point exception Unrecoverable file violation CPU limit exceeded Illegal instruction Hang-up Interrupt (rubout) Quit Write on a pipe with no one to read

Gaia


of 94



3.3.13 RTS Man Machine Interface (MMI)


The RTS shall include an MMI providing the following functions:

A Graphical User Interface (GUI) providing control and display functions A Test Editor for the preparation of Test Sequences A Test Execution Engine for the execution of Test Sequences at run-time


The RTS MMI is used in part of the CSW debugging process. As such, generation, loading and running of the Test Sequence Executables shall be as short as possible.

3.3.13.1 GUI

RTS-1473/RTS_URD-136,129/T,A

The GUI shall provide the following functionality:

Simulation Control: • The user shall be able to execute any of the commands identified in Section 3.3.9.1 from within

the GUI. • The user shall be able to select any local Test Procedure for execution, either singly or in batch

mode (queued) • The user shall be able to suspend and restart the Simulation at any time (primarily to allow

adaptation of Simulation Parameters). The GUI shall provide separate window displays as follows:

• A Message Window displaying all messages as defined in Section 3.3.11 for the Event Log File • A Data Window displaying all data defined for display by the current Data Logging Schedule • A Test Window displaying the progress of local Test Execution

3.3.13.2 Test Editor

RTS-1474/RTS_URD-135,137/A,R

The Test Editor shall provide a JAVA test script language editor (to JAVA Version 1.4) for the preparation of Test Sequences and Subroutines.


The Test Editor shall impose no limitation on Test Sequence size, name-length, file breakdown or hierarchy.

RTS-1476/CREATED/R

Within the Test Editor the user shall only need to provide the name of the sequence and the source code, for example:

sequence_name {

source code ... ... ...

}

Gaia


of 94



RTS-2499/CREATED/T

From the sequence edit file the Test Editor shall automatically create a run-time version of the sequence file, adding all JAVA context (package, import and other declarations as necessary) such as would allow use of the sequence in an external JAVA interpreter (or JAVA Virtual Machine).

RTS-2597/RTS_URD-60,61,70,71,140/T,A

The Test Editor shall provide a set of classes implementing the protocol required for:

Controlling the Simulation Process (start, stop, power-down) Sending Spacecraft Telecommands - all options as defined in the TC definition file (see Section 3.3.7) Retrieving Spacecraft Telemetry (accessing directly TM values) Controlling the 1553 and SpaceWire bus spies (start/stop storage) Reading any occurrence of a specific 1553 BUS transfer Reading any occurrence of a specific SpaceWire BUS transfer Controlling the Simulation: for 'time steps' or 'number of cycles', for example:

sim.timeStep (seconds), sim.cycleStep (number of cycles) Control of parameter logging (enable, disable, single-shot or rate) Control of individual log files (start/stop/resume) Control of the CSW: image loading Debug of the CSW: adding/deleting instruction breakpoints and watches Redirection of CSW output to user-defined callback routines (prevents emulator response to standard I/O

RTS-2581/RTS_URD-67,68,69/R

Manipulation (read/write) of Simulation Parameters from within a Test Sequence shall be by reference to their Symbolic Name.

RTS-6664/RTS_URD-67,68,69/R

Manipulation (read/write) of CSW Parameters from within a Test Sequence shall be by reference to their Symbolic Name or by reference to their absolute address.

3.3.13.3 Test Execution Engine


The Test Execution Engine shall allow Test Sequences to be:

Executed Automatically - singly or in batch mode (queued) Started/Halted/Resumed Stopped Executed in debug mode: • stepped • jump to subroutine • breakpoints Watched (variables can be examined during stepped execution) Checked for syntax/semantic errors at runtime


The Test Execution Engine shall provide a complete JAVA Interpreter (to JAVA Version 1.4).

Note: That means one that can interpret calls within a Test Sequence to JAVA code compiled elsewhere.

RTS-2583/CREATED/T

The JAVA Interpreter shall interpret Test Sequence files line-by-line at the source code level (no need for recompilation of the RTS or any compilation of the Test Sequence).

Gaia


of 94




The Test Execution Engine shall maintain separate log files, dedicated to the Sequence Execution, for: (in the format defined in Data Logging Section 3.3.11 - RTS-2220)

Spacecraft Telemetry A predefined set of Simulation Parameters Simulation Event Log file


Test Execution overhead shall be no greater than 20 seconds. This includes:

Reset/Restart of the Simulation Opening Log Files Executing the Test Script Closing and archiving Log Files

Gaia


of 94



3.3.14 RTS to EGSE Real-time Network Interface

In the hybrid test bench configuration, the RTS must interface to the Avionics SCOE for application and acquisition of real Spacecraft data. The RTS must also supply Spacecraft Attitude and Rate data to the Dynamic FPA Simulator and Star Tracker SCOE to allow closed-loop testing of the AOCS.

For proper closed loop control of the AOCS, the data transfer between the RTS and the external EGSE must meet the following criteria:

Hard real-time Deterministic Low data latency


To meet these criteria the RTS shall form part of a Real-time Network (also known as a Reflective Memory or Distributed Shared Memory Network).

RTS-2465/CREATED/R

Examples of suitable Real-time Network devices are identified below. The RTS subcontractor shall identify the devices to be used, with final approval from Astrium:

Manufacture Device Support GE Fanuc Automation VMIPCI-5565 PCI Card

ACC-5595 Star Hub Linux, VxWorks, Windows

Systran SCRAMNet GT Linux, VxWorks, Windows, Solaris, Labview, RTX

ORION Technologies 9035 Series Linux, VxWorks, Windows

RTS-6617/CREATED/T

Data latency across the Real-time Network (that is the time data is transmitted by one process in the Network to the time the data is received by the corresponding process in the Network) shall be less than 4us.

3.3.14.1 Real-time Network Usage

For information purposes, Real-time Network usage is described below:

The following description assumes a typical Avionics SCOE configuration utilizing VME instrumentation as an arbitrary example to aid understanding. It describes a typical process whereby a Spacecraft Unit Model in the RTS is required to generate a stimulation voltage to the Spacecraft:

• The Simulation Process schedules the Spacecraft Unit Model execution during the Simulation Cycle.

• The Spacecraft Model computes the required voltage and calibrates the value required for 'real' output 'Vcal' based on a Calibration Factor (a Model Characterization variable defined by file input at RTS initialization).

• Following computation, the 'Vcal' updates address 'Add1' of the RTS Reflective Memory ('Vcal' is mapped to this address during the RTS initialization process).

• At a fixed point in the Simulation Cycle (after all scheduled Models are computed) the Simulation Process issues a 'DMA Write' instruction to the RTS Reflective Memory.

• On reception of the 'DMA Write', the value at 'Add1' is transferred automatically across the Real-time Network to the corresponding address in the Reflective Memory card connected to the VME BUS of the Avionics SCOE.

• The value at 'Add1' is transferred to address 'Add2' of VME Memory (this process is automatic, defined by a mapping process during initialization of the Avionics SCOE).

Gaia


of 94



• 'Add2' is the VME address reserved for the update register of the 'DAC Channel' of the VME DAC card. The VME DAC card converts this value to a real voltage output for Spacecraft stimulation.

• The transfer process from the Spacecraft Unit Model to the VME address space ‘Add2’ is transparent and deterministic (there is no API or software involved).

Note: This example assumes a simple data transfer. More complex transfers (such as 1553) may require I/O concerning both data and control registers mapped across the Real-time Network.

Ref

lect

ive

Mem

ory

SpacecraftUnitModel

Cal

ibra

tion

Fact

or

ModelOutput

Vcal

Ref

lect

ive

Mem

ory

RTNPCI

Card

RTS

Real-TimeNetwork

RTN VME Bus Card

Add1 Add1

VM

E M

emor

y

Add2

SimulationProcess DMA

Write

VME DAC Card

DACChannel

Vcal

Spacecraft Interface

VME Crate (Avionics SCOE)

Exe

cute

Figure 3.3-2: Real Time Network Usage

Gaia


of 94



3.3.14.2 Real-time Network Definition & Responsibility

Operation of the Real-time Network requires definition of the following processes:

Mapping of RTS Unit Model variables to the Real-time Network (Reflective Memory) Calibration Factors for conversion of Model I/O parameters from/to real values of the Avionics SCOE Algorithm required for conversion of Model I/O parameters from/to real values of the Avionics SCOE (i.e., mx+c) Mapping of RTS Unit Model variables from the Real-time Network (Reflective Memory) to the EGSE interface (Avionics SCOE, Dynamic FPA Simulator or Star Tracker SCOE)


Mapping of RTS Unit Model variables to the Real Time Network (Reflective Memory) shall be defined in a Real Time Network Map File provided by the RTS subcontractor to the various EGSE suppliers- see Section 3.3.7.

RTS-6675/CREATED/A

The Real Time Network Map File shall define the absolute address in Reflective Memory for each Unit Model variable by Symbolic Name.

Mapping of variables between the Reflective Memory of the Real Time Network and the specific addresses (i.e., VME, PCI, PXI) of the EGSE will be the responsibility of the EGSE provider.

The Calibration Factors for conversion of Model I/O parameters (defined by Symbolic Name) from/to real values of the Avionics SCOE will be provided in an I/O Calibration Initialization File defined by the Avionics SCOE provider, in a format defined by the RTS subcontractor.

The I/O Calibration File will define the Calibration Factors by Symbolic Name (as defined by the relevant Model Specification - characterization inputs).

RTS-2970/CREATED/

Algorithms required for conversion of Model I/O parameters from/to real values of the Avionics SCOE shall be defined by the Avionics SCOE provider as an input to the Spacecraft Unit Model Specifications (to include output format in terms of address space).

Gaia


of 94



3.3.14.3 Real-time Network Timing


Transfer of data between the RTS and the EGSE (Avionics SCOE, Dynamic FPA Simulator and Star Tracker SCOE) across the Real-time Network shall be achieved using interrupt-based DMA transfer (see Figure and explanation below):

PPS

1/64 PPS (simCycle)

(1)DMAReadData

(2)SpacecraftModelComputation

(3)Delay

(4)DMAWriteData

(5)DataLogCycle

(6)CommandAndControl

Read data from the Avionics SCOE (Hybrid Bench)

Write data to the Avionics SCOE (Hybrid Bench) & other EGSE

Execution time for the Spacecraft Model Computation is configuration dependent

Delay introduced to fix the time of the proceeding write cycle

Configuration dependent

Configuration dependent

Figure 3.3-3: Real Time Network Timing


The DMA read cycle (read from the EGSE) shall be performed at the start of the Simulation Cycle.


The DMA write cycle (write to the EGSE) shall be performed at a fixed time within the Simulation Cycle (after completion of Spacecraft Model computations).

Note: The intention of RTS-6613 and RTS-6614 is to minimize data jitter between the RTS and the Spacecraft hardware by setting the data transfer times relative to Simulation Cycle timing (rather than as a function of Model Computation timing).

Gaia


of 94



3.4 Phased Delivery Requirements

RTS-7101/RTS_URD-115,127/R

Deliveries shall consist of 8 RTS, 6 of the numerical bench variety and 2 of the hybrid bench variety.

RTS-7102/CREATED/R

The RTS deliveries shall be in a phased manner, with each phase of the delivery realising a distinct evolution of the RTS Software, from version V1 through V4.

RTS-7181/CREATED/R

The delivery schedule, including input schedules for detailed Model Specification provision to the RTS Subcontractor, shall be identified in the SOW.

3.4.1 Delivery Phase 1

RTS-7146/RTS_URD-115,116/R

In delivery Phase 1 each RTS shall comprise the following elements:

RTS of the numerical bench variety, each comprising the Hardware and Platform elements defined in Section 3.1, RTS-453 RTS Application Software version V1


RTS Software version V1 shall comprise, as a minimum, the following Software Modules, as defined in Section 3, RTS-333:

The RTS Core Application Simulated Spacecraft Model Layer ERC32 Processor Emulator Emulator Interface Layer Simulated CDMU Model Layer Interface Applications RTS MMI


The Simulated Spacecraft Model Layer shall comprise BUS Responder Models to answer on the 1553 and SpaceWire BUS with pre-loaded fixed values defined in configuration files.

Gaia


of 94




RTS-7104/RTS_URD-127,118/R

In delivery Phase 2 each RTS shall comprise the following elements:

RTS hardware of the hybrid bench variety, each comprising the Hardware and Platform elements defined in Section 3.1, RTS-7262 RTS Application Software version V2


RTS Software version V2 shall comprise, as a minimum, the Software Modules defined in version V1, the corrections identified by NCR against version V1, and the following additional Software Modules:

The EGSE Interface Layer (as defined in Section 3, RTS-333 and Section 3.3.14) Additional Models of the Simulated Spacecraft Model Layer:

The Environment Model (as defined in Section 3.3.3.2) The Thermal Model (as defined in Section 3.3.3.3) The Dynamics Model (as defined in Section 3.3.3.4) The Star Tracker Models (as defined in Section 3.3.3.5) The Gyro Models (as defined in Section 3.3.3.6) The Fine Sun Sensor Models (as defined in Section 3.3.3.7) The Combined CPS Model (as defined in Section 3.3.3.8) The Separation Strap Models (as defined in Section 3.3.3.10) The EIU Models (as defined in Section 3.3.3.11) The Battery Model (as defined in Section 3.3.3.12) The PCDU Models (as defined in Section 3.3.3.13) The DSA Model (as defined in Section 3.3.3.24) The Bipods Model (as defined in Section 3.3.3.25)



Phase 3 of the RTS delivery shall comprise the following elements:

RTS Application Software version V3


RTS Software version V3 shall comprise, as a minimum, the Software Modules defined in version V2, the corrections identified by NCR against version V2, and the following additions to the Simulated Spacecraft Model Layer:

The SREM Model (as defined in Section 3.3.3.9) The MPS Model (as defined in Section 3.3.3.14) The TRSP Models (as defined in Section 3.3.3.15) The RFDU Model (as defined in Section 3.3.3.16) The PAA Model (as defined in Section 3.3.3.17) The CDU Models (as defined in Section 3.3.3.18) The MDE Models (as defined in Section 3.3.3.19) The OSE Models (as defined in Section 3.3.3.20) The FPA Models (as defined in Section 3.3.3.21) The VPU Models (as defined in Section 3.3.3.22) The PDHU Models (as defined in Section 3.3.3.23)

Gaia


of 94





Phase 4 of the RTS delivery shall comprise the following elements:

RTS Application Software version V4


RTS Software version V4 shall comprise, as a minimum, the Software Modules defined in version V3, the corrections identified by NCR against version V3, and the remaining Software Modules identified below:

Final versions of the Environment, Thermal and Dynamics Models The Simulated EGSE Model Layer (as defined in Section 3, RTS-333), including all EGSE Models (as defined in Section 3.3.10, RTS-110)

Gaia


of 94



4 PA REQUIREMENTS

RTS-2976/CREATED/R

The RTS shall satisfy the applicable PA requirements as defined in the Gaia PA Requirements for GSE [AD-05] and the Gaia SW PA Requirements for GSE [AD-06].

Gaia


of 94



5 VERIFICATION REQUIREMENTS

5.1 General

RTS-2980/CREATED/R

The contractor shall propose the verification program which shall be subject to agreement by EADS Astrium Ltd..

RTS-2981/CREATED/R

The verification process shall demonstrate conformance to applicable requirements. A satisfactory completion of the verification process is the basis for a contractual acceptance of the product by the customer.

The requirements of this specification and of the specifications referenced therein shall be subject to formal verification close out.

As far as equipment or software is 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.

5.2 Test Equipment

RTS-2983/CREATED/R

Adequate test equipment and simulators shall be made available to support the verification process.

RTS-2984/CREATED/R

This test equipment need not necessarily be deliverable and may therefore be recruited from the suppliers laboratory inventory. Of particular importance is the simulation of the communication interface with the Avionics SCOE. These shall be fully representative on all protocol layers including the physical interface.

5.3 Verification Program

RTS-2986/CREATED/R

The subcontractor shall establish a verification program that assures that

The product is in compliance with the specified requirements. The design is qualified. The product 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 reused software modules / components acceptance test reports / qualification test reports may be used to demonstrate compliance with the requirements stated. The subcontractor shall not be required to rerun acceptance / qualification tests for existing, reused software. In case reference is made to already performed and existing acceptance / qualification in the frame of other space programs, requirements tracing of the above RTS requirements to the existing test procedures and test result has to be provided as well as the existing test procedures and test reports themselves.

Gaia


of 94



5.4 Verification Process

RTS-2992/CREATED/R

The verification process activities shall be incrementally performed at different levels and in different stages applying a coherent bottom-up concept and using a suitable combination of different verification methods.

RTS-2993/CREATED/R

The verification process flow shall be 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.

5.5 Project Specific Verification Requirements

RTS-3002/CREATED/R

Requirements verification shall be controlled in accordance with the following methods: (listed in order of preference)

Test Analysis Review of Design Inspection Similarity

RTS-3008/CREATED/R

The contractor shall apply the verification methods, as defined in this specification, for each requirement (see Section 1.2).

RTS-3013/CREATED/

The subcontractor shall establish the verification documentation as defined in the Document Delivery List of the RTS SOW.

RTS-3014/CREATED/R

The subcontractor shall report the verification status for each requirement.

Gaia


of 94



5.6 Specific Requirements On Tests

5.6.1 General

RTS-3017/CREATED/R

All specific support test equipment must be compliant with the intended purpose, within its useful life and calibration.

RTS-3018/CREATED/R

For tests performed with automated test scripts, batch files or generally with software, the test procedures and reports shall provide the relevant test-step information in the software source code or in the printout/protocol of each test software item. The test report shall include configuration control information (compilation date, checksum, version or revision number, etc.) for each software item used for the reported test.

5.6.2 RTS Functional Tests

RTS-3020/CREATED/R

The RTS functional tests shall verify the operation, connectivity and functionality of each supplied software Module, Interface and Model.

RTS-7297/CREATED/R

The RTS Functional tests shall include verification of the Simulation Cycle scheduler (as identified in Section 3.3.1, RTS-1042) including, but not limited to:

• Real-time data I/O.

• Spacecraft Model computation.

• Housekeeping functions (data logging/data archive, command and control interfaces etc.)

5.6.3 RTS Performance Tests

RTS-7092/CREATED/R

The RTS performance tests shall include verification of performance requirements of the RTS against reference test cases provided by EADS Astrium Ltd., based on the CSW running on real hardware.

RTS-7093/CREATED/R

Typical test scenarios shall include at least verification of the RTS processes under the following conditions:

• Full simulated CDMU loading requirements

• BUS Model responders configured for maximum expected BUS traffic loading.

• Up to twice nominal Simulation speed (Simulated processor clock speed).

RTS-7255/CREATED/R

In particular, performance tests shall verify the RTS correctly represents register access scheduling of the CDMU Processor under full load and BUS traffic conditions.

Gaia


of 94



5.6.4 RTS to EGSE Interface Tests

RTS-7292/CREATED/R

The proposed test schedule shall include verification of the RTS to EGSE Interfaces (Real Time Network data transfers).

For the RTS to Dynamic PFA Simulator and Star Tracker SCOE Interfaces, this may be achieved with the use of hardware stubs simulating the missing EGSE (and initially for the Avionics SCOE interfaces).

RTS-7294/CREATED/R

For the case of the Avionics SCOE, final testing of the RTS to SCOE interfaces shall include testing with the actual hardware (Avionics SCOE) in the loop.

RTS-7295/CREATED/R

As a minimum these tests shall verify the operation, and bench-mark the achieved latency times, of:

• RTS Models commanding Avionics SCOE outputs to the Spacecraft.

• Updates at the Avionics SCOE inputs being detected by the RTS Models.

• MIL-STD-1553B and SpaceWire BUS transfers.

Final testing of the RTS with the Avionics SCOE hardware maybe be conducted on site at the Avionics SCOE provider, or post-delivery at EADS Astrium Ltd.

Gaia


of 94



6 MAINTENANCE & SPARES

RTS-3029/CREATED/R

The subcontractor shall propose a maintenance and spares policy based on the number and possible location of the RTS to be supplied (as defined in the Statement of Work).

RTS-3030/CREATED/R

A maintenance and spares policy shall be proposed to ensure the requirements for 'Reliability and Availability' (Section 5.11) and 'Maintainability' (Section 5.12) of [AD-04]) are met.

Gaia


of 94



7 LIST OF ACRONYMS

AD Applicable Document AIT Assembly Integration and Test AOCS Attitude and Orbit Control Subsystem AP Application Program API Application Programming Interface STR Autonomous Star Tracker AVM Avionics Model BC Bus Controller C&C Command and Control CCS Central Checkout System CCSDS Consultative Committee for Space Data Systems CDU Clock Distribution Unit CDMU Central Data Management Unit CFE Customer Furnished Equipment CMD Command COTS Commercial Of The Shelf CPS Chemical Propulsion System CPU Central Processor Unit CSW Central Software DMA Direct Memory Access DSA Deployable Sunshield Assembly ECSS European Cooperation for Space Standardization EGSE Electrical Ground Support Equipment EIU Electrical Interface Unit EM Engineering Model EMC Electromagnetic Compatibility ESA European Space Agency FCL Fixed Current Limiter FM Flight Model FMECA Failure Modes Effects & Criticality Analysis FPA Focal Plane Array FSS Fine Sun Sensor FVB Functional Validation Bench GSE Ground Support Equipment H/W Hardware HK House-Keeping I/F Interface ICD Interface Control Document ID Identifier IP Internet Protocol LAN Local Area Network LCL Latching Current Limiter MDE Mechanism Drive Electronics MMI Man-Machine Interface MPS Micropropulsion Subsystem MSB Most Significant Bit MTBF Mean Time Between Failure N/A Not Applicable NTP Network Time Protocol OBC On-board Computer OS Operating System OVF Operational Validation Facility PA Product Assurance

Gaia


of 94



PAA Phased Array Antenna PCDU Power Control & Distribution Unit PCI Peripheral Component Interface PDHU Payload Data Handling Unit PFM Proto-Flight Model PLM Payload Module PUS Packet Utilisation Standard QM Qualification Model RD Reference Document RF Radio Frequency RID Report Identifier RT Remote Terminal RTS Real Time Simulator S/W Software SCOE Special Checkout Equipment SD Standards Document SOW Statement of Work SVF Software Verification Facility SVM Service Module TBC To be confirmed TBD To be defined TC Telecommand TCP Transmission Control Protocol TM Telemetry TRSP Transponder TTC Tracking, Telemetry & Command UTC Universal Time Coordinated VPU Video Processing Unit

Gaia


of 94



Requirement/Section Cross Reference Page numbers are the pages where the sections start

RTS-333 .............3 ......................12 RTS-453 .............3.1 ...................13 RTS-464 .............3.2.1 ................14 RTS-472 .............3.2.2 ................15 RTS-506 .............3.3.2 ................19 RTS-512 .............3.3.2 ................19 RTS-513 .............3.3.2 ................19 RTS-617 .............3.3.4 ................60 RTS-618 .............3.3.4 ................60 RTS-619 .............3.3.4 ................60 RTS-761 .............3.3.1 ................16 RTS-1036 ...........3.3.1 ................16 RTS-1042 ...........3.3.1 ................16 RTS-1054 ...........3.3.1 ................16 RTS-1064 ...........3.3.1 ................16 RTS-1065 ...........3.3.1 ................16 RTS-1073 ...........3.3.1 ................16 RTS-1113 ...........3.3.3.1 .............59 RTS-1284 ...........3.3.5 ................61 RTS-1285 ...........3.3.5 ................61 RTS-1292 ...........3.3.5 ................61 RTS-1339 ...........3.3.5 ................61 RTS-1372 ...........3.3.6 ................62 RTS-1397 ...........3.3.7 ................63 RTS-1401 ...........3.3.8 ................67 RTS-1403 ...........3.3.9 ................68 RTS-1404 ...........3.3.9 ................68 RTS-1405 ...........3.3.9 ................68 RTS-1406 ...........3.3.9 ................68 RTS-1407 ...........3.3.9 ................68 RTS-1409 ...........3.3.9.1 .............69 RTS-1423 ...........3.3.9.1 .............69 RTS-1427 ...........3.3.11 ..............72 RTS-1428 ...........3.3.11 ..............72 RTS-1431 ...........3.3.12 ..............74 RTS-1432 ...........3.3.12 ..............74 RTS-1435 ...........3.3.12 ..............74 RTS-1438 ...........3.3.12 ..............74 RTS-1472 ...........3.3.13 ..............75 RTS-1473 ...........3.3.13.1 ...........75 RTS-1474 ...........3.3.13.2 ...........75 RTS-1475 ...........3.3.13.2 ...........75 RTS-1476 ...........3.3.13.2 ...........75 RTS-1550 ...........3.3.10 ..............71 RTS-1576 ...........3.3.10 ..............71 RTS-1650 ...........3.2.1 ................14 RTS-1666 ...........3.3.2 ................19 RTS-1796 ...........3.3.8 ................67 RTS-1925 ...........3.3.7 ................63 RTS-1926 ...........3.3.7 ................63 RTS-1929 ...........3.3.7 ................63 RTS-1971 ...........3.2.1 ................14 RTS-1977 ...........3.3.9.1 .............69 RTS-1978 ...........3.3.9.1 .............69 RTS-1979 ...........3.3.7 ................63 RTS-1980 ...........3.3.7 ................63 RTS-1981 ...........3 ......................12

RTS-2003........... 3.3.7 ................ 63 RTS-2027........... 3.3.7 ................ 63 RTS-2063........... 3.3.7 ................ 63 RTS-2064........... 3.3.7 ................ 63 RTS-2075........... 3.3.8 ................ 67 RTS-2111........... 3.3.9.1 ............. 69 RTS-2141........... 3.3.9.1 ............. 69 RTS-2142........... 3.3.9.1 ............. 69 RTS-2158........... 3.3.11 .............. 72 RTS-2183........... 3.3.7 ................ 63 RTS-2213........... 3.3.9.1 ............. 69 RTS-2216........... 3.3.7 ................ 63 RTS-2220........... 3.3.11 .............. 72 RTS-2244........... 3.3.9 ................ 68 RTS-2245........... 3.3.9 ................ 68 RTS-2392........... 3.3.7 ................ 63 RTS-2394........... 3.3.10 .............. 71 RTS-2395........... 3 ...................... 12 RTS-2396........... 3 ...................... 12 RTS-2397........... 3 ...................... 12 RTS-2398........... 3.2.2 ................ 15 RTS-2463........... 3.3.14 .............. 78 RTS-2465........... 3.3.14 .............. 78 RTS-2499........... 3.3.13.2 ........... 75 RTS-2581........... 3.3.13.2 ........... 75 RTS-2582........... 3.3.13.3 ........... 76 RTS-2583........... 3.3.13.3 ........... 76 RTS-2584........... 3.3.13.3 ........... 76 RTS-2585........... 3.3.13.3 ........... 76 RTS-2597........... 3.3.13.2 ........... 75 RTS-2616........... 3.3.13.3 ........... 76 RTS-2683........... 3.3.13 .............. 75 RTS-2708........... 3.3.7 ................ 63 RTS-2717........... 3.3.2 ................ 19 RTS-2901........... 3.3.2 ................ 19 RTS-2970........... 3.3.14.2 ........... 80 RTS-2976........... 4 ...................... 85 RTS-2980........... 5.1 ................... 86 RTS-2981........... 5.1 ................... 86 RTS-2983........... 5.2 ................... 86 RTS-2984........... 5.2 ................... 86 RTS-2986........... 5.3 ................... 86 RTS-2992........... 5.4 ................... 87 RTS-2993........... 5.4 ................... 87 RTS-3002........... 5.5 ................... 87 RTS-3008........... 5.5 ................... 87 RTS-3013........... 5.5 ................... 87 RTS-3014........... 5.5 ................... 87 RTS-3017........... 5.6.1 ................ 88 RTS-3018........... 5.6.1 ................ 88 RTS-3020........... 5.6.2 ................ 88 RTS-3029........... 6 ...................... 90 RTS-3030........... 6 ...................... 90 RTS-3141........... 3 ...................... 12 RTS-3142........... 3.3.5 ................ 61 RTS-5365........... 3.2.1 ................ 14 RTS-5370........... 3.3.5 ................ 61

RTS-6463........... 3.3.10.............. 71 RTS-6484........... 3.3.11.............. 72 RTS-6485........... 3.3.11.............. 72 RTS-6541........... 3.3.11.............. 72 RTS-6608........... 3.3.14.3........... 81 RTS-6609........... 3.3.14.2........... 80 RTS-6613........... 3.3.14.3........... 81 RTS-6614........... 3.3.14.3........... 81 RTS-6617........... 3.3.14.............. 78 RTS-6664........... 3.3.13.2........... 75 RTS-6665........... 3.3.3.1............. 59 RTS-6666........... 3.3.10.............. 71 RTS-6675........... 3.3.14.2........... 80 RTS-6691........... 3.3.6................ 62 RTS-6692........... 3.3.6................ 62 RTS-7047........... 3.3.2................ 19 RTS-7048........... 3.3.2................ 19 RTS-7049........... 3.3.11.............. 72 RTS-7051........... 3.3.2................ 19 RTS-7052........... 3.3.2................ 19 RTS-7053........... 3.3.2................ 19 RTS-7065........... 3.3.3.1............. 59 RTS-7066........... 3.3.11.............. 72 RTS-7068........... 3.3.11.............. 72 RTS-7083........... 3.2.2................ 15 RTS-7086........... 3.1................... 13 RTS-7087........... 3.3.9................ 68 RTS-7088........... 3.3.9................ 68 RTS-7092........... 5.6.3................ 88 RTS-7093........... 5.6.3................ 88 RTS-7101........... 3.4................... 82 RTS-7102........... 3.4................... 82 RTS-7104........... 3.4.2................ 83 RTS-7113........... 3.4.2................ 83 RTS-7146........... 3.4.1................ 82 RTS-7152........... 3.4.1................ 82 RTS-7168........... 3.4.1................ 82 RTS-7181........... 3.4................... 82 RTS-7183........... 3.4.3................ 83 RTS-7189........... 3.4.3................ 83 RTS-7220........... 3.4.4................ 84 RTS-7224........... 3.4.4................ 84 RTS-7255........... 5.6.3................ 88 RTS-7262........... 3.1................... 13 RTS-7290........... 3.3.2................ 19 RTS-7292........... 5.6.4................ 89 RTS-7294........... 5.6.4................ 89 RTS-7295........... 5.6.4................ 89 RTS-7297........... 5.6.2................ 88

Gaia


of 94



DOCUMENT CHANGE DETAILS

ISSUE CHANGE AUTHORITY CLASS RELEVANT INFORMATION/INSTRUCTIONS

DISTRIBUTION LIST

INTERNAL EXTERNAL Configuration Management