OPS Forum: Extension of Operational Simulator for Flight Dynamics - 04122009

Extension of the Operational Simulator for Flight Dynamics

OPS-G ForumDaniel Werner, Vemund Reggestad (OPS-GD)

Nuno Sebastião (OPS-GI)

Susanne Kasten-Coors (OPS-GF)

ESOC - 04.12.2009

Extension of an Operational Simulator for Flight Dynamics | OPS-G Forum | ESOC | 04.12.2009 | Pag. 2

Background

– The Operational Simulator and the HPTDG

– The Working Group

Commonalities

– Adoption & Goals

– Issue Analysis & Solutions

Development Approach

– Problematics and Concerns

– Current Status

– Other Missions

Conclusion

OutlineOutline


Two separated simulators

HPTDG (Flight Dynamics) & Operational Simulator (Flight Control Team)

BackgroundBackground


The Operational Simulator used by the Flight Control Team

Interfaces: to the Mission Control System (SLE)

Goal:

– Ground software system testing, – Mission Control team training, – Operational validation of the OBSW,– Spacecraft operation procedure validation.

Models:

– Entire Spacecraft (S/C) & environment, – Ground Station Network

Allows:

- Full On-Board Software (OBSW) emulation,- Accepts all TCs as the real S/C and responds accordingly,- Realistic TM generation from all equipments,– Failure Injection, – Breakpointing,– Running AOCS in closed loop (satisfying OBSW FDIR checks).

The OperationalThe OperationalSimulatorSimulator


HPTDG Flight Dynamic’s High Precision Test Data Generator

Interfaces: to FD systems (proprietary)

Goal:

– Performance and functional validation of AOCS related FD applications & systems,– of procedures, data-products and timelines,– training of FD teams (although most of it achieved via the operational simulator).

Models:

– S/C dynamics & environment, – high fidelity Sensors and Actuators,– Focus on AOCS parts of the OBSW

Allows:

– Telemetry generation (relevant to FD),– TPF execution (generated by FD systems)– Failure Injection, – Breakpointing, – Faster than real-time simulation (up to 50 times).

The HPTDGThe HPTDG


Working GroupTo assess the feasibility of sharing an Operational Simulator with Flight Dynamics

When?

– Mid-2008

Who?

– Composed of various experts from:– Flight Dynamics,– Mission Data Systems,– Infrastructure,– Gaia Flight Control Team.

Goals:

– Assess the suitability of the Operational Simulator extension for FD usage,– Identify and address any programmatic and technical issues,– Provide different options and recommendations on the way forward.

Outcome Report:

– Fidelity of AOCS models and Environmental models – Performance requirements,– Interface between Operational Simulator and FD Systems requirements

Working GroupWorking Group


CommonalitiesCommonalities

HPTDG and Operational Simulator Comparison

HPTDG functionalities supported by the Operational Simulator

Interface: to FD Systems

Models:

– S/C dynamics & environment model,

– high fidelity Sensors and Actuators,

– AOCS Parts of the OBSW

Other Features:

– Telemetry generation,

– TPF execution (generated by FD systems)

– Failure Injection,

– Breakpointing,

– Faster than real-time simulation.


HPTDG: adopting the Operational Simulator

The HPTDG has evident commonalities with Operational Simulators

The Goal:

– Exploring synergies in expensive and risky areas:– Emulation of On-board processor– High fidelity Data Handling System– Execution of real OBSW inducing AOCS part.

– Harmonising ESOC simulation tools and environments.– Eliminating development duplications– Concentrating validation efforts

– Reduce risks.– Reduce costs

Use-case Target:

– The HPTDG use cases related to AOCS models– Command generation and AOCS monitoring– i.e. not Orbit determination and prediction.

Adoption & GoalsAdoption & Goals


Addressing and Analysing the Issues

Drivers to the suitability of the Simulator for FD usage

Analysis of Issues:

– Accuracy requirements for infrastructure & mission specific models

– Faster than real-time performance requirements on emulation & downlink

– Updates to simulator infrastructure

– Connection between FD systems and S/C model

– Availability of representative test data

– Flight Dynamics Database and configuration

– Provision of suitable Hardware for FD

Issue AnalysesIssue Analyses


Accuracy requirements for infrastructure & mission specific models Spacecraft Model, Environment and Dynamics Accuracy

Model accuracy needs:

– For Operational Simulators the models must allow correct functional behaviour of the OBSW

– dynamic modelling capable of satisfying the OBSW FDIR checks

– No attempt to validate against Spacecraft system level AOCS related accuracy requirements

– Flight Dynamics require higher accuracy than FCT for some models:

– sensors & actuators (mission specific), environment & dynamics (infrastructure)

Way forward:

Sensor & Actuator Models

– Functional and Performance needs were expressed in FD requirements

– Provision of Mathematical Description was considered (responsibility issue)

– Review of detailed algorithm definitions shall be done

– FD involvement in Acceptance & Validation of the operational Simulator

Updates to Environment & Dynamics (PEM & SIMDYN) Infrastructure Models

– addressed as part of a separate GaiaSim D0 delivery

– separate team working on these updates



Faster than real-time performance requirements

Performance requirements

– Driver is the support of simulations (command validation) of 7 day operations within a few hours

– 5 times faster then real-time has been specified by the WG as acceptable.

– Requirements lined-out as part of the GaiaSim RFP (Request For Proposal):

– 5 times real-time mandatory

– 10 times real-time highly desirable

Way forward:

– Dynamic code translation on the Emulator

– Disabling memory scrubbing

– Disabling effect of high rate downlink commands and SPID filter

– By-passing Ground Models (RFCS, frame encoding, TTC Streams etc.)

– Disabling models not required by FD (thermal network, payloads etc.)


Infrastructure Infrastructure A new EmulatorA new Emulator

A new Emulator

Current processor emulators are 50-100 times slower than host– Work for older generation of space processors– Relied on increasing clock-speed to keep pace– Mainly serial in nature - multi-core machines little help

LEON2

– 3-5 times ERC32 performance

Need for new approaches

– Hardware– Software

Align to TSIM, the de facto standard


Infrastructure Infrastructure QERx - Dynamic QERx - Dynamic TranslationTranslation

Dynamic Translation

– Traditional emulators read each target instruction and translate to the equivalent host instruction(s) every single time they are encountered

– Dynamic translation compiles blocks of target instructions to host instructions

– Blocks typically between branches, ~5-10 instructions long

– Blocks compiled on the fly and stored in memory

– When a block is encountered again it is retrieved from memory and executed.

This is the where the performance gain comes from.

But:

– Execution at block level raises issues with the processor clock and I/O timing.


Infrastructure Infrastructure QEMU => QERxQEMU => QERx

QEMU Dynamic Translation Emulator

– Open Source

– Supports many target processors including SPARC

– Supports emulation of the complete machine

– FAST

But:

– Mainly used to emulate complete machine

(not just a processor)

– No support for ERC32

– No support for LEON

– No shared library

– No TSIM interfaceIntel Pentium 4 EM64T @ 3.6 GHz


Infrastructure Infrastructure QERx ConclusionsQERx Conclusions

Derived from open source QEMU (LGPL Licence)

Alignment with QEMU now maintained

– Allows improvements to QEMU to be incorporated

Performance is ~4-8x that of conventional emulators

– Provides the ability to run OBSW in a simulated ERC32 or LEON2 faster than real-time

“Real-time” clock much improved

– Floating point instruction counting needs better estimation

– Trade-off in performance vs. timing accuracy

Allows multiple processor emulations on a single machine

– But TSIM interface would need to be extended to allow a processor instance to be specified



Batch mode

To allow running Simsat in a fully automated way from start to end, it shall be possible to start and

operate Simsat via the so called “batch mode".

– Comment: The objective is to allow the control of the simulation (including starting and stopping) from the command line.

$ SimHost.exe -i [other parameters...]simsat> ScriptHost.AddCorbaObjectByName(‘MyCounter’,’SMP2/ClassBased/Counter1’)simsat> Counter.step1Simsat> Kernel.Exit()Simsat Simulation Completed.$

Infrastructure Infrastructure SIMSAT UpgradesSIMSAT Upgrades


Run as Fast as Possible

– A fast forward mechanism shall be added to the SIMSAT scheduler allowing the scheduler to progress SimTime at the maximum speed.

This implies:

– Disabling the Real-Time slip checking

– Skipping all wait statements in the scheduler aiming at maintaining a selected Speed Factor

External Data Access

It shall be possible to access data recorded and saved to file

by the SIMSAT Recorder from any source while it is still being

recorded and/or saved.

Infrastructure Infrastructure SIMSAT UpgradesSIMSAT Upgrades

Infrastructure Infrastructure FDS-DIFFDS-DIF

SIMSAT

Operational S/C Simulator

Flight Dynamics SystemsSimulated Systems/HPTDG

FDSDIF

SimDIFSimDIFLANData

HandlingOBSW

TC FilesTC Files

TC Path

TM Path

ParameterRecorder


Positioning Model (PEM) Accuracy

Rigid Body Dynamics (SIMDYN)

Packet Handling Toolkit (SIMPACK)

Thermal Network (TNET)

Electrical Network (SENSE)

– Validated against Flight Dynamics Infrastructure

– Fulfilling Flight Dynamics Accuracy Requirements

– Ported to SMP2


Infrastructure Infrastructure Generic ModelsGeneric Models

ITEM STATUS

5x Real-Time (New Emulator, Free Running Mode)

Flight Dynamics Direct Interface

Batch Mode

Offline External Data Access

Generic Models Precision


Infrastructure Infrastructure Support to FDSupport to FD


Availability of representative reference test data

One of the major issues related to the development and integration of AOCS systems is for both systems:– Availability of data to perform unit and system level testing against

Traditional sources are:

- Previous missions

- Dynamics simulations from the Mission real-time Simulator

- AOCS validation reports from the S/C prime contractor

Way forward:

– RTS and AOCS validation output from the prime contractor,

– Run acceptance of the simulator against SVT data,

– FD to provide validation methods for each requirement,

– related to algorithm specifications,

– to cover AOCS subsystem tests

Common Common Issues Issues


Flight Dynamics Database (FDDB) and Configuration

Let’s do it right

The FDDB contains configuration data relevant for the spacecraft

– information is also needed to have the Simulator configuration consistent

Problems:

– FDDB formats differ from one mission to the other

– For similar information, formats even changed during a same mission

Way forward:

– FDDB ICD

– Usable format that can be parsed for loading (e.g. excel format)

Advantage:

– FDDB remains a deliverable from prime

– Consistent format during the entire mission (simplifies handling of updates)

Long term goal:

– Define a FDDB ICD that can be standardized across missions (maybe even international agencies)

– used by FD, FCT, Sim Developers and Prime

Common Common Issues Issues


Provision of suitable Hardware for Flight Dynamics

Server platforms are purchased and deployed by OPS-GD/OPS-EC– Avoid divergence in the simulator runtime environment between FD and FCT

Suitable platform compatible with:– Simulator infrastructure needs,– Performance requirements

Specification of the Gaia Simulator Servers:– DL380 G5 servers– SLES 9 Operating System (migration to SLES 11 foreseen)

5 Simulator Servers foreseen for the Gaia MissionCurrently:– FCT & development server

– 1 Xeon 5470 (quad core) processor each,– 16GB RAM each.

– FD server– 2 Xeon 5470 (quad core) processors,– 32GB RAM.

Common Common H/W Platform H/W Platform


Development ApproachSingle development targeted for two user communities

Request for Proposal:

– Single set of requirements and single contract– FD Delta developments as option in RFP

Responsibility sharing:

– OPS-GF staff co-TO for relevant parts of the Simulator,– Shared responsibilities for the entire Simulator s/w lifecycle

(requirement, architectural design, acceptance & review phases)

Synergies:

– Identical hardware platform (Hewlett-Packard / Linux)– Common simulation infrastructure

Upgrades of infrastructure models and new developments (I/F’s)

– Partial implementation under GaiaSim Contract– to be retrofitted into simulation infrastructure

Progressive increase in fidelity/accuracy of mission specific models:

– Reduce risk on development for FCT– Target FCT and FD schedule requirements

DevelopmentDevelopment Approach Approach


DevelopmentDevelopment Approach Approach

High / Low Fidelity approachRisk Mitigation


Tight Schedule versus Availability of Information

Availability of Information

– S/C Documentation

– Intellectual Property Rights

– Late availability

– Documentation Changes

– Availability of models, validation data and results

– Details of Operational Concepts and impact on early assumptions

– e.g. units that need calibration

Change in “working culture” for Flight Dynamics

– Early Requirements Definition,

– FFP contract (with FUP support),

– Offsite development,

– New infrastructure

Problematics Problematics and Concerns and Concerns

Current StatusCurrent Status

Gaia SimulatorCurrent Status

Infrastructure:

– SIMSAT 4.2 PA delivery Dec 2009, Final Delivery March 2010

– FDS-DIF Initial Delivery Delivered today, PA delivery February 22nd

– PEM & SIMDYN updates due in Q1/2010

GaiaSim Development Life Cycle:

– SWRR completed– Working towards PDR: end January 2010– D1 delivery foreseen Q2/2010



Trend for the future…

GAIA selected as pioneer mission

– Investments in infrastructure

– Exploring an unknown territory

– Investments only pay off if more missions are following

Currently Sentinel-1 is starting

- Requirement engineering ongoing

- Joint RFP under preparation

- Carry forward of experience is important

Setting a trend for future missions

- Each mission is different

- Not one solution for all problems

Other MissionsOther Missions

ConclusionConclusion

For each of the issues, suitable solutions have been identified

– to satisfy both the FCT and FD

– FD requirements can be taken on-board without any unacceptable risk to the FCT usage of the Simulator

Financial aspects and impacts on manpower allocation

– not addressed as part of the working-group

– although it is clear that the first mission (GaiaSim) will have a work overhead

– for Gaia, OPS-GI and OPS-GF contributed (financially and in terms of manpower)

– but a long term benefit and high reusability is expected from synergies

Earth-Observation missions also looked with interest to the outcome of this WG

– Sentinel-1 are currently considering this approach

Co-operation is essential

– Continuous commitment by all parties is required

FD Participation to all phases of the development cycle:

– Requirement Engineering

– Review of detailed algorithm definitions

– Software Delivery & Acceptance Process

Exploitation of expertise and experience gained with HPTDG developments

ConclusionConclusion

We work towards:

- Closer co-operation

- Common infrastructure

- Stronger Validation

- Reducing risks on the long term

- Sharing experience


THANK YOU

Daniel Werner & Nuno Sebastião (OPS-GDS) (OPS-GIC)

[email protected]@esa.int

Questions?

mailto:[email protected]

Enjoy the Santa Run!for those who participate…

V. Reggestad

(OPS-GD / Chair)

D. Werner

(OPS-GD)

N. Sebastiao

(OPS-GI)

G. Gienger

(OPS-GF / Co-chair)

A. O’Connell

(OPS-OA)

S. Karsten-Coors

(OPS-GF)

F. Dreger

(OPS-GF)

J. Schwartz

(OPS-GF)

X. Marc

(OPS-GF)

Working Group Composition

Involving Flight Dynamics, Mission Data Systems, Infrastructure & Operations

SupportingSupporting Slides (1) Slides (1)

Technology

OPS Forum: Extension of Operational Simulator for Flight Dynamics - 04122009