OPS Forum Simulations Evolution 15.02.08

Nuno Sebastião (OPS-GIC), Vemund Reggestad (OPS-GDA), David Verrier (OPS-GDS)

ESOC SimulatorsPast, Present and Future

OPS-G Forum 15 January 2008 Slide 2@ Copyright European Space Agency, 2008

Outline of this Presentation

• The way we got here– Current Operational Simulators– Simulation Model Portability

Standard (SMI/SMP2/ECSS)

• Infrastructure – Current and planned activates

• Cooperation with Partners and ESTEC

• The Future of Operational Simulator Development

– What Technology can do

• Summary


Future of ESOC Simulators

The way we got here


Simulator development evolution

• Old Spacecraft– Little OBSW– Processor not running,

TM still generated– easy to generate fixed

format telemetry– TM and TC hard-wired– Few changes in AIT

• New spacecraft– Lots of OBSW, FPGA etc..– If processor not running,

no telemetry generated– Packet telemetry and

telecommands– Defined late, defined in

software– Consequently, Many

late changes


Operational Simulator Costs

• Cost have decreased.

• Previously Large cost overruns.– Up to 100%

01000000200000030000004000000500000060000007000000

EN

VIS

AT

XM

M

Inte

gra

l

MS

G

Rose

tta

ME

X

Cry

osa

t

VE

X

Goce HP

Simulator cost at completion (2001-Euro)


Cost Drivers

• Changes after Kick-Off

• No on-board standardization.

• Length of development – Changes & delays on the spacecraft lead

to changes and costs on the simulator

• Starting too early

• Number of emulators

• Starting from scratch



Reducing costs

(Current measures)


Avoiding concurrent development: sim & MCS

• Historically:– The simulator used as data source/sink during

MCS development and testing.– Parallel development of Simulator and MCS

Difficult to isolate problems.

• Solution: – Develop data source/sink infrastructure

configurable via database to be used for MCS validation. (i.e. GSTVi)

– Models based on PUS standard instead of S/C documentation.

• Second advantage: – Permits delay to simulator development


Avoid concurrent development: sim & spacecraft

• Historically:– Dependency between simulator and mission

schedules for the ICDs, OBSW, SDB– Provision of the OBSW typically end up on the

critical path for the simulator– Impossible to perform end-to-end test without

OBSW• Solution:

– Delay K/O of Simulator.– Use GETS instead of OBSW for Simulator

integration.• GETS: Generic Onboard software.

– Better tools to isolate SDB.


Controlling development cost• Measures taken:

– No OBSW in first delivery– Integration testing via limited functional model of OBSW.– Late kick-off– Provision for 10 versions of flight software in FFP– Full responsibility by contractor:

• No excuses• No recourse • No CCNs driven by developer

• Example: HP only 5% increase despite 18 month delay in launch


Simulation Model Portability 2 Standard Outline

• SMP2 Objectives• CCB Members• Status


Simulation Model Portability Standard - Objectives

• Enable the reuse of simulation models between: – different project phases– different projects– different simulation platforms

• Reduce cost of simulator development– Use modern software technologies– Improve support for model reuse– Improve model integration support – code generation

• Support integration of system engineering data• Support of dynamic simulations• Support for meta-data (Units, Limits)• Make use of open standards (XML, UML)• Decrease sensitivity to platform change (C++, Java,

Windows, Linux)


• 1999 – Sees the birth of SMP1• SMP1 has been applied to a number of projects:

– Generic Project Test Bed (GPTB) at ESTEC– Rosetta/Mars Express/Venus Express/Cryosat/GOCE/HP

Operational Spacecraft Simulators– Galileo System Simulator Facility for ESTEC

• However, a number of issues identified:– No support for OO/Interfaces/Components i.e. modern

methodologies to support software reuse.– Large amount of “glue” code has to be hand written to support

the integration i.e. effort required and error prone.– Does not support self descriptive models i.e. model meta-data.– Platform specific - only one “platform” supported (C)

SMP Evolution

Michael Jones

First say what SMP is.Possibly put slide 14 first.


SMP Evolution

1999 20092004SMP2 CCB

2006ECSS Work Approved

2008ECSS-E40-07

12/2005SMP2 1.2 Out

1999SMP1


CCB Members


SMP2 - Status

• ECSS-E-40-07 Standard being finalised for public review (Oct 2008)• Fully supported by Simsat 4 (Version 1.2)• Partially supported by Eurosim, Basiles, SimTG

• Industrial validation conducted by:– CNES (Prime)– Spacebel– Thales Alenia Space– EADS Astrium– Ellidiss

“We have developed a initial CMM implementation inspired by Simulation Model Definition Language (SMDL) of Simulation Model Portability 2 (SMP2) standards”School of Information System and Management National University of Defense Technology, China


SMP2 – Industrial Validation Results• Objectives

– Validation of SMP2 in an industrial process

• SMP2 tools support aspects: design, development, integration and code generation

– SIMSAT4 MIE (ESOC), STOOD

• Distributed development (multi-sites)– Source and binary code sharing

• Integration on multiple simulator infrastructures– SIMSAT4 (ESOC), BASILES (CNES), SimTG (Astrium)

• Simulation implemented and run successfully on SIMSAT4, BASILES

• SMP2 is a valid approach for development since it allows focusing on engineering rather than on infrastructure

• Development: real benefit (SMP2 serves as a common language among all development parties)

• Lack of a graphical visualization of models and Assemblies

• Tools need further improvements for industry adoption.



Simulator

infrastructure:

Paving the way

to the future.


Infrastructure Evolution

1999 2009

2005Simsat 3 Linux

(SMI)

1999Simsat Windows

(SMI)

2008Simsat 4 Linux

(SMI/SMP2)

2008Reference S/C

Simulator Architecture

2008GSTVi

2004PSS – Portable

Satellite Simulator


SIMSAT 4

SMP2 Support MMI Migration to EclipseCommunity Requests

SIMSAT 4


SIMSAT – Supporting the Full Simulation Life cycle

The Big picture


User-Requested Improvements

• Schedule Analyzer

• Parameter Recording

• Logger improvements (Filtering, Search, User Comments)

• Model Failure

• Parameter Forcing

• Parameter Limits

• Conditional and Scheduled Commanding

• Simulation Tree Search


Universal Modelling Framework

• IDE like (Eclipse based) environment for the development of SMP2 based simulators. Supporting the full life cycle of Simulator development from design of models, code generation (including code merge), model execution and debugging.

• Will address most of the concerns expressed in the SMP2 industrial Validation study

• First version available Q2 this year.


MC

S

NIS

TM

TC

S

IFM

S/T

CD

SE

GS

E/F

EE

Sp

acecraft

TM/TC Spacecraft Model

MCS Model

NIS Model

TIF

EGSE / FEE I/F

Ground System under Test

GSTVi Component

Space/Ground I/F

SGM

MCS DIF

IMBU (H/W)

IMBU I/FAIV System

Real Systems Simulated Systems

The big picture

Ground Segment Test and Validation Infrastructure

Available to missions Q2 2008


MC

S

NIS

TM

TC

S

IFM

S/T

CD

SE

GS

E/F

EE

Sp

acecraft

TM/TC Spacecraft Model

MCS Model

NIS Model

TIF

EGSE / FEE I/F

Ground System under Test

GSTVi Component

Space/Ground I/F

MCS DIF

IMBU (H/W)

IMBU I/FAIV System

Real Systems Simulated Systems

SLE Ground Model

SGM

Very fruitful collaboration with the Aeolus team for the validation of the model.


Porting of Generic Models to SMP2• Positioning and Environment Model (PEM)

• Spacecraft Dynamics Simulation (SIMDYN)

• Spacecraft Thermal Network (TNET)

• Spacecraft Electrical Network (SENSE)

• Spacecraft TM/TC Toolkit (SIMPACK)

• First delivery accepted by ESOC.

• Negligible delay (One week) over a project life of 9 months.

• This might tells us something about the efficiency of SMP2


2008 Simulator Activities

• Spacecraft Simulator Reference Architecture – Kick off Q1

• EGOS-MF and SIMSAT MIE merge into a single product supporting the SMP-2 models development (UMF) - Q2

• SIMSAT 4 Upgrades (migration to EUD, Scheduler Improvements, Win support?, 3D Adapter) – Kick Off – Q3

• Support OBSW White-Box testing – Kick off Q3

• Ground Station Simulator (GSTP study):

– Simulate the M&C Aspects of the Elements that surround the STC2

– Used in the training of Operators without the real Station.


OBSW White Box

• More user friendly troubleshooting of On Board Software in the Simulator

• View and control the details of software execution in a "symbolic debugger" mode.

• Capability to execute the software in a realistic "mission environment“ `

Simulator KernelSimulator KernelSimulator KernelSimulator Kernel

Ground Ground ModelsModels

Simsat MMISimsat MMI

Emulator

S/C Model

MCS/NCTRS

`WHITE-BOX WHITE-BOX KernelKernel

WHITE-BOX WHITE-BOX KernelKernel

WHITE-BOX WHITE-BOX MMIPluginMMIPlugin



Cooperation

with ESTEC

(TEC-SW)


Converging SIMSAT and SIMVIZ

Linux MIE

SIMSAT 4

SIMULUS

SMP2

Ground GENM

Windows Designer

SIMSAT 2

SIMVIZ

SMP2

COM/Excel Models

Simsat validation under windows. One simulation platform for ESA


Software Emulators

• Current status– Novell is no longer supporting ADA (ESOC

Emulator core is done in ADA)

• Ways forward– Develop a new Emulator based on Qemu– Use TSIM as the baseline for all

simulation activities?


Reference Simulator Architecture

Phase A

Horizontal Approach

Rosetta

Aeolus

Vertical Approach

Mars Express

Phase B Phase C Phase D

TEC-SW OPS-GI/GD


Common Library of Models

A set of Simulator models that:– Includes both generic and specific models

– Would be used in the Reference S/C

– Could be used in isolation

– Serve the purposes of TEC-SW and OPS



Cooperation

with partners


The Industry

• A number of simulation platforms are available:– Simsat (ESA/ESOC)– Eurosim (ESA/NLR)– Basiles (CNES)– EcoSimPro– SimTG (Astrium)– etc

• Problem: too many platforms, so:– too much effort spent on infrastructure – no model share/reuse between platforms.


Cooperation with partners

• SMP2 levels the playing field.– Enables reuse of models across simulation kernels

• UMF Modelling Framework– A common Modelling environment to be used allowing

proprietary/specific runtime environments– The de facto tool for the modeling and assembling of

SMP2 elements.– Released under a open source license so that all

interested parties can contribute to its development (coordinated by ESA).

– Foster the community development around SMP2



Towards model integration


Reference Simulator Architecture. Why do we need one?

SimsatSMI Adapter

CDMUSDBPowerRFCS

AOCSGeneric ModelsPayloadsThermal

Current situation:• No clear interface between

models• Difficult to isolate models for

reuse• Tight coupling SDB and

models.• Reuse by cut&paste.

Objectives:• Definition of clear interfaces

between the different elements in a Spacecraft.

• Improved reusability at model level. (towards plug&play)


Improvement Step 1: GMPort

• Generic Models interfaces clearly defined

• Allow plug-and-play update of generic models.

• First part of infrastructure related to SDB handling added.

SimsatSMP2 Adapter

CDMUSDBPowerRFCS


PEM

SIMDYN

SENSE

SIMPACK

TNET SDB


Reference Architecture

CDMUSDBPowerRFCS


EmulatedPM Model

Buss Model

VC-0 FrameBuild

RAM

MemoryMapp

TM MOD

EmulatedPM Model

Buss Model

VC-0 FrameBuild

RAM

MemoryMapp

TM MOD

EmulatedPM Model

Buss Model

VC-0 FrameBuild

RAM

MemoryMapp

TM MOD

EmulatedPM Model

Buss Model

VC-0 FrameBuild

RAM

MemoryMapp

TM MOD

EmulatedPM Model

Buss Model

VC-0 FrameBuild

RAM

MemoryMapp

TM MOD

EmulatedPM Model

Buss Model

VC-0 FrameBuild

RAM

MemoryMapp

TM MOD

• Establish a suitable breakdown of simulators into models.

• Standardize on common generic interfaces between the models.

• Clear cut between TM/TC and engineering parameters

• Use the SMP2 assembly mechanism to allow different usage scenario



The Future of Operational Simulator Development


Model Library

• Library of Models to include:– All models developed at

ESOC.– Models developed at

ESTEC (*)– Phase-A models and SVF

models (*).

• All models to be easily available for future developments

(*) if developed according to SMP-2 and souce-code is provided.


Step 1: Simulator Assembly

If developed according to a Reference Architecture, this is feasible:


Step 2: Customization

TX_AMonitoring:• Bit Rate Mode• Coherent Mode•…

Actions:•Select Hi_bit_rate_mode•Select Low_bit_rate_mode•…

Configuration:•Polarization = [left, right]• …

SDB TM:•XYZ1000•XYZ1001•…

SDB TC:•XYZ0001•XYZ0002•…


Step 3: Runtime



Summary


The Way Forward

• Start with GSTVi for MCS development and testing– Consequence: Sim development can start later.

• Use the Reference Architecture to base the development of Operational Sims.

• Use GETS in D1 (replace OBSW)• Shorter development cycles through reuse

of models and reference architecture.



Summary

• ESA is a central player in the European Simulation Domain

– Cooperation between ESOC and TEC-SW

• Building the future with:– SMP2 – Improved development process

– Reference Architecture – More reuse

– Better infrastructure – Simsat 4, GSTVi, RefA

– More commonality – Library of Models


Thank you for your attention !

Let’s build the future

Let’s continue to build the future