OPS Forum Swarm simulator development 08.05.2009

The Swarm constellation simulator

The Swarm Simulator development: an explanation and an illustration of what SMP2, REFA and EGOS-MF are -- and how these can be used…

OPS-G forum -- 08th May 2009

Max Pignède [presenter], Nuno Sebastiao, Vemund Reggestad

European Space Agency (ESA) / European Space Operations Centre (ESOC)

Peter Fritzen, Michael Irvine, Peter Ellsiepen

VEGA Deutschland GmbH & Co. KG / A Finmeccanica Company

OPS-G forum | The Swarm constellation simulator development | 08th May 2009 | Slide 2

What this presentation is about…

1. Why attempting a new approach in making simulator software ?

2. Explanation of what SMP2, REFA and EGOS-MF are

3. Illustration of how SMP2, REFA and EGOS-MF are applied for the Swarm Simulator development in the SIMSAT 4 environment

4. Conclusions -- then Q&A


Rationale -- Background

1.Recognition that development strategies better than mere reuse should be explored

2.Take advantage of new technologies and of ESA most recent standards

3.ESOC is preparing the first deployment of a new generation of operational simulators in the context of the Swarm mission, a constellation of three satellites

more details available at http://www.esa.int/esaLP/LPswarm.html


Why do we need a reference architecture ?

1. No clear interface between models

2. Difficult to isolate models for reuse

3. Transforming a working simulator into a new one can result in a faulty simulator and cause much unneeded code to stay

4. Reuse potential mostly only via “copy&paste”

CDMUSDBPowerRFCS

AOCSGeneric ModelsPayloadsThermal

Example of what a simulator software architecture may look like:

How about if we …

a. defined clear interfaces between the different elements in a spacecraft ?

b. defined some suitable breakdown of a whole simulator into models ?

c. improved reusability at model level in a “plug&play” fashion ?


“Operationally responsive” technologies

1. The SMP2 Standard …

a. promotes portability of models among different simulation environments and operating systems

b. promotes the reuse of simulation models

c. fulfills these objectives by providing a standard interface between the simulation environment and the models

2. The Reference Architecture (REFA) …

a. identifies, using SMP2, a reference spacecraft simulator architecture which can be used as the basis for simulators design and development

b. achieves shorter development cycles by reuse relying extensively on a common architecture

c. fulfills these objectives by specifying interfaces between spacecraft subsystems and by identifying models which can be developed in a generic fashion


SMP2 architecture

SMP2 first component: a SIMULATION (with its model instances)

Model.1Model.1 Model.2Model.2 Model.nModel.nModel.iModel.i… …

SMP2 second component: a Simulation ENVIRONMENT (and its services)

`

Mandatory services:

Information logging Entry point scheduling Times provision Events manager

Mandatory interfaces:

Access to simulator state Access to simulator services Publication mechanism

The interface offered by the simulation environment to the

model does not change

The interface offered by the model to the simulation environment

does not change

Schedule calls model entry points

Models interact with each other

Models call any simulation service


SMP2 simulation services and interfaces

1. Simulation services are …

a. provided by the simulation environment

b. consumed by the models

c. based on standardised interfaces

2. Every model must implement the IModel interface

3. Every simulation service must implement the IService interface

ISimulator

Model

Simulation Environment

IModel

SchedulerIScheduler

Time KeeperITimeKeeper

LoggerILogger

Event ManagerIEventManager

IService

Connect

Run

Hold

Restore

GetState

GetTimeKeeper

GetModel

…etc…

Connect

Configure

Publish

GetName

GetParent

…etc…


SMP2 hierarchy -- the main parts

Catalogue C1

Model M1Fields ..Operation ..Association ..

Model M2Field ..Associations ..Entry Point ..

Model M3Fields ..Entry Points ..

Schedule S1

Assembly A3

Assembly A1

Assembly A2

Model-Instance C

Model M2

Assembly A1Model-Instance A

Model M1

Model M3

Model-Instance BModel M1

Model M4

Model M3

Catalogues define SMP2 models library

Assemblies specify how model instances are integrated

Schedules define the scheduling of the entry points of model

instances

The Simulation Model Definition Language (SMDL) defines the format of all these XML

files

For example, if the Schedule calls an <<SMP2entryPoint>>+Update() of a

Thermistor model, a temperature will be retrieved from some thermal node

and this will result in an update of the temperature measured by the

Thermistor

The Assembly translates into the

Simulation tree at the MMI and

can hold the initial values of fields


SMP2 key benefits

1. SMP2 avoids developing models which use the operating system or hardware specific dependencies -- Platform Independent Model (PIM)

2. SMP2 promotes the use of modern software engineering techniques -- in particular component based design

3. SMP2 makes reuse easier via breaking dependencies between simulator models

4. SMP2 allows dynamic configuration -- for example the user may at “runtime”:

a. select different orbit propagators depending on the required accuracy

b. switch a component that simulates a hardware equipment with a component that interfaces with the real equipment (e.g. when moving from models to real checkout devices)

SMP2 is a ESA standard evolving into an ECSS standard

to standardise SMP2 more widely under the ECSS umbrella

to take this opportunity for enhancing SMP2 version 1.2 (e.g.

support of dynamic models, initialisation of model parameter

values)


REFA onset

1. REFA started with investigating what would be worth being standardised for all satellite subsystems across simulators

-- via the actual screening of 4 different space missions

2. As a result REFA identified …

a. what should the “reference spacecraft simulator” requirements be

b. all interfaces between the different elements in a spacecraft simulator

c. the models which can be developed

– in a generic fashion (e.g. satellite dynamics, orbital environment modelling, satellite thermal control, communications subsystem, …)

– those other models which need to be developed specifically for each mission

3. This is a system architecture -- some work remains to be done ...

4. Use this architecture as the basis for future simulators development !


REFA logical model

REFA utilities

REFA subsystems:

Generic Units Failures MessagesEventsParameters

AOCSPayloads

Radio Frequency Reaction Control

Data Handling

Data LinksThermal Control

Electrical Power

Parameter MapperSimulation Monitor Configurator

Aligned Unit

Magnetic Torquer Head Simulation Model Portability 2 (SMP2) Component Model

Logger Scheduler Time Keeper Resolver Events Manager

REFA …

is a system architecture (only) and not a reusable implementation of satellite models

provides also a generic implementation for some models, e.g. Powered Units, Model

parameters


REFA output

Generic Models (SMP2)

PEM

SIMDYN

External Force

Earth Magnetic Field

Aligned Unit

External Force Interface

Earth Magnetic FieldInterface

Magnetic Torquer Interface

Magnetic Torquer

HeadThe Magnetic Torquer Head

requires an interface to read the Earth Magnetic Field

The Magnetic Torquer Head requires an interface to

provide an External Torque

Illustrated via the AOCS example of the Magnetic Torquer Head …

Interface allowing to set the dipole momentum and to read the produced

torque


REFA actual use in a project

Example of …

Swarm::Aocs::MagneticTorquerHead inherited directly from …

REFA::Aocs::MagneticTorquerHead

REFA model -- shown in previous slide …

Swarm model -- derived from a REFA model to provide the

mission required implementation


REFA for building a new simulator ...

EPS

Battery PCDUSolarArray

TCS

Thermistor ThermostatSolar

Surface

AOCS

STR CESS FGM MTQ GPSR

RCS

Tank

PipeMerge

PipeBranch

Mass FlowSensor

PressureTransducer

LatchValve

Flow ControlValve

Thruster

RFCS

Antenna CombinerTransferSwitch

Transmitter ReceiverGround

Uplink Downlink

Data Links

1553 ACARO UART ML16 DS16

Payloads

ASM VFM C-EFI ACC

Deployable

DBA

DHS

OBT PM RM TMMulti

UARTTCD CPDU RUMM

Colour Scheme

Fully REFA Defined

Partially REFA Defined

Not REFA Defined


REFA benefits

1. Models developed based on REFA are potential candidates for later reuse in other simulators. Therefore …

a. all components need a complete documentation of their interfaces

b. and this documentation must be always synchronised with the actual implementation

c. hence source code and documentation must originate from a single source

2. The reuse of existing mechanisms, infrastructure components and base models will result in a more harmonised behaviour of operational simulators, such as …

a. same user commands between simulators

b. identical tracing, logging, reporting characteristics on different simulators

3. Overall increased productivity in the development of new simulators


EGOS Modelling Framework (EGOS-MF)

1. Eclipse based IDE extension for developing SMP2 simulators and for increasing software development efficiency

a. EGOS-MF is a collection of Eclipse Plug-ins.

b. It uses MagicDraw integrated into Eclipse.

2. Supports the full life cycle of simulator development

a. design of models -- systematically (re-)start at the UML design stage !

b. code generation by SIMSAT MIE (including code merge)

c. document generation (with customisation of generation templates)

d. model execution and debugging

3. The answer for managing simulators complexity efficiently is …

a. to model ! -- and the model is the single source of information

b. to automate !

c. and not to repeat yourself !

4. Hence: Model Driven Software Development (MDSD) supported by the EGOS-MF suite


1. This process will be updated based on the Universal Modelling Framework (UMF) once it is available: UMF will replace EGOS-MF and SIMSAT Model Integration Environment (MIE) by a single Integrated Development Environment (IDE) which further integrates the Eclipse C++ Development Tools (CDT) and which does not need to be run within SIMSAT.

2. Import the simulator requirements in EGOS-MF

3. With the requirements in place, the design of mission specific models can be started:

Example: new disk mapped memory model, using the UML modules from REFA

4. Create a new SMP2 Model named “DiskMappedMemory”: this will create a UML Component with the <<SMP2model>> stereotype

5. Drag & Drop the “Memory” model and the “IMemory” interface from “REFA/Generic/Units” onto the diagram and make the new model derive from the existing REFA model -- using the “Generalization” button

How to apply MDSD using UML and EGOS-MF ?


EGOS-MF overall development workflow

RequirementsEngineering

.csv

Requirements Editor

Requirements Import Tool

Architecture and

UML Model

Model Validation Tool

Document Generation Tool

XML Schema Generation Tool

Catalogue Generation Tool

CORBA IDL Generation Tool

.doc.html

.idl

.xsd

.cat

Interface Design

Catalogue Import Tool

.cat

.cpp

doxygen

Development

C+

+ C

omp

iler

RequirementsEngineering

.csv

Requirements Editor

Requirements Import Tool

Architecture and

UML Model

Model Validation Tool

Document Generation Tool

XML Schema Generation Tool

Catalogue Generation Tool

CORBA IDL Generation Tool

.doc.html

.idl

.xsd

.cat

Interface Design

Catalogue Import Tool

.cat

.cpp

doxygen

Development

C+

+ C

omp

iler

....

Catalogue Validator (MIE)

C++ CodeGenerator (MIE)

EGOS-MF profile

SDD, ICD, SUM

UML Editor

for REFA defined formats, such as Log Messages file format or TM/TC database file format (read in by the SCOS MIB Reader)

validation violation messages trace back to the violation location within the UML model

when a design has been entered, it is typically needed to create a SMP2 Catalogue

for it this Catalogue can then be used to generate C++ source

code


EGOS-MF code generation process

DevelopmentDesign

UML Model SMP2

Catalogue

Catalogue Generation

Tool

Catalogue Validator

C++Code

Code Generator

Makefile

Catalogue Editor

SMP2Package

Package Editor

ObjectFile

Compiler

SharedObject

Linker

Editor

Templates

This systematic code generation process is illustrated next, proceeding from the previous UML example

<<SMP2model>>MagneticTorquerHead

Models are essentially source code

Platform Specific Model (PSM)


EGOS-MF example: Catalogue Generation

1. The Catalogue Generator translates UML Design into SMP2 Catalogue (XML File)


EGOS-MF example: C++ Code Generation

2. The Code Generator generates C++ Source Code for each SMP2 Model wih SIMSAT MIE

a. it converts the types defined in the Catalogue into C++ source code (header files and skeleton implementation files)

b. various methods (e.g. for publication and dynamic invocation) are auto generated


EGOS-MF: use of the C++ Code Merger

3. The user-defined methods are empty and need to be completed using an external C++ development environment.

a. the Code Merger can merge an existing implementation into newly generated skeleton code. Therefore, all operations that already have an implementation maintain their implementation

b. “manual” changes do not have to be re-applied after each merge

c. neither SIMSAT nor EGOS-MF support implementation of model specific functionality -- beyond auto generated SMP2 code


EGOS-MF example: C++ Code Merger output

3. Illustration of the merging of the “manual” code of the “setter” for the magnetic dipole momentum which causes an update of the produced torque …

a. portion of auto generated code without implementation -- before merging

b. portion of source code of the MagneticTorquerHead -- after mergingvoid MagneticTorquerHead::set_DipoleMomentum( ::Smp::Float64 value ) { // MARKER: OPERATION BODY: START // INSERT HERE OPERATION BODY // TODO: set the field value (the attached field was not defined in the catalogue model) //TBD = value; // MARKER: OPERATION BODY: END }

// --OPENING ELEMENT--MagneticTorquerHead::set_DipoleMomentum-- /// The setter for the magnetic dipole momentum. This causes an update of the produced torque /// The produced torque is computed as cross product of the magnetic dipole momentum /// per Earth magnetic field. The produced torque is then set into SIMDYN void MagneticTorquerHead::set_DipoleMomentum( ::Smp::Float64 value ) { // MARKER: OPERATION BODY: START // Setup the coordinate systems used in the computations ::Common::Direction earthMagneticField(this->coordinateSystem); ::Common::Direction dipoleMomentumVector(this->coordinateSystem); ::Common::Direction torqeDirection(this->bodyCoordinateSystem); this->dipoleMomentum = value; dipoleMomentumVector = this->pointing * this->dipoleMomentum; earthMagneticField = _EarthField->At(0)->get_MagneticField(); torqeDirection = dipoleMomentumVector.CrossProduct(earthMagneticField); this->torque = torqeDirection.GetAsArray(); _ExternalForce->At(0)->set_Torque(this->torque); // MARKER: OPERATION BODY: END }// --CLOSING ELEMENT--MagneticTorquerHead::set_DipoleMomentum--

b. portion of source code of the MagneticTorquerHead -- after merging


EGOS-MF example: Document Generation

1. The Document Generator generates Design Documentation for each SMP2 Model

REFA SDD

SWARM SDD

SWARM SDD


Users common views across simulators

1. Users have identical views on … (for example):

a. Message logging filtering

b. Model failures

c. Parameter limits

d. Simulation tree (defined in the Assembly)

2. Users have identical views (for example) on failed or forced parameters:

a. The magnetic torquer head has Analogue Parameters (e.g. the global magnetic field) -- hence they have limits and they can be forced

b. The magnetic torquer head can be failed because it is a Generic Unit

Drag and drop directly from tree to display window


Conclusions

1. Building the ESA operational simulators is “better, faster, cheaper” with:

a. SMP2 -- interfaces enabling reuse and exchange of satellite models

b. REFA -- structured reuse of past acquired simulators knowledge

c. EGOS-MF -- automatised component based development

d. SIMSAT -- solid software infrastructure on linux platforms

2. From the users perspective

a. These advanced technologies respond to project needs and schedules

b. Demonstrated potential for reduced costs in producing future simulators

c. Requirements for multi-satellite systems are satisfied

Thank you for your attention

Any questions ?

Max Pignède [presenter], Nuno Sebastiao, Vemund Reggestad

European Space Agency (ESA) / European Space Operations Centre (ESOC)

Peter Fritzen, Michael Irvine, Peter Ellsiepen

VEGA Deutschland GmbH & Co. KG / A Finmeccanica Company

Date post:	22-May-2015
Category:	Technology
Upload:	esaesoc-darmstadt-germany
View:	1,966 times
Download:	3 times

OPS Forum Swarm simulator development 08.05.2009

Technology