The swarm constellation simulator
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

The Swarm constellation simulator PowerPoint PPT Presentation


  • 165 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

The Swarm constellation simulator

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The swarm constellation simulator

TheSwarmconstellation 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


What this presentation is about

What this presentation is about…

  • Why attempting a new approach in making simulator software ?

  • Explanation of what SMP2, REFA and EGOS-MF are

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

  • Conclusions -- then Q&A

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide2


Rationale background

Rationale -- Background

  • Recognition that development strategies better than mere reuse should be explored

  • Take advantage of new technologies and of ESA most recent standards

  • 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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide3


Why do we need a reference architecture

CDMU

AOCS

SDB

Generic Models

Power

Payloads

RFCS

Thermal

Why do we need a reference architecture ?

Example of what a simulator software architecture may look like:

  • No clear interface between models

  • Difficult to isolate models for reuse

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

  • Reuse potential mostly only via “copy&paste”

How about if we …

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

  • defined some suitable breakdown of a whole simulator into models ?

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide4


Operationally responsive technologies

“Operationally responsive” technologies

  • The SMP2 Standard …

    • promotes portability of models among different simulation environments and operating systems

    • promotes the reuse of simulation models

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

  • The Reference Architecture (REFA) …

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

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

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide5


Smp2 architecture

SMP2 architecture

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

Model.1

Model.2

Model.i

Model.n

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

Models interact with each other

Schedule calls model entry points

Models call any simulation service

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

`

The interface offered by the model to the simulation environment does not change

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide6


Smp2 simulation services and interfaces

Model

IModel

Simulation Environment

ISimulator

IService

IScheduler

Scheduler

ITimeKeeper

Time Keeper

ILogger

Logger

IEventManager

Event Manager

SMP2 simulation services and interfaces

  • Simulation services are …

    • provided by the simulation environment

    • consumed by the models

    • based on standardised interfaces

Connect

Run

Hold

Restore

GetState

GetTimeKeeper

GetModel

…etc…

Connect

Configure

Publish

GetName

GetParent

…etc…

  • Every model must implement the IModel interface

  • Every simulation service must implement the IService interface

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide7


Smp2 hierarchy the main parts

Catalogue C1

Assembly A2

Model M1

Model-Instance C

Fields ..

Operation ..

Association ..

Model M2

Assembly A1

Model-Instance A

Model M2

Schedule S1

Field ..

Associations ..

Entry Point ..

Model M1

Model M3

Assembly A3

Assembly A1

Model-Instance B

Model M3

Model M1

Model M4

Model M3

Fields ..

Entry Points ..

SMP2 hierarchy -- the main parts

The Assembly translates into the Simulation tree at the MMI and can hold the initial values of fields

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

Catalogues define SMP2 models library

Schedules define the scheduling of the entry points of model instances

Assemblies specify how model instances are integrated

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide8


Smp2 key benefits

SMP2 key benefits

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

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

  • SMP2 makes reuse easier via breaking dependencies between simulator models

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

    • select different orbit propagators depending on the required accuracy

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide9


Refa onset

REFA onset

  • 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

  • As a result REFA identified …

    • what should the “reference spacecraft simulator” requirements be

    • all interfaces between the different elements in a spacecraft simulator

    • 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

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

  • Use this architecture as the basis for future simulators development !

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide10


Refa logical model

REFA subsystems:

Payloads

Electrical Power

AOCS

Data Handling

Radio Frequency

Thermal Control

Reaction Control

Data Links

REFA utilities

Simulation Monitor

Parameter Mapper

Configurator

Generic Units

Parameters

Events

Failures

Messages

Aligned Unit

Simulation Model Portability 2 (SMP2) Component Model

Magnetic Torquer Head

Logger

Scheduler

Time Keeper

Resolver

Events Manager

REFA logical model

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide11


Refa output

Aligned Unit

Generic Models (SMP2)

Magnetic Torquer Interface

External Force Interface

SIMDYN

Magnetic Torquer Head

External Force

Earth Magnetic Field

Interface

PEM

Earth MagneticField

REFA output

Illustrated via the AOCS example of the Magnetic Torquer Head …

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

The Magnetic Torquer Head requires an interface to read the Earth Magnetic Field

The Magnetic Torquer Head requires an interface to provide an External Torque

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide12


Refa actual use in a project

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide13


Refa for building a new simulator

EPS

TCS

RFCS

Battery

PCDU

Solar

Array

Thermistor

Thermostat

Solar

Surface

Antenna

Combiner

Transfer

Switch

Transmitter

Receiver

AOCS

Ground

STR

CESS

FGM

MTQ

GPSR

Uplink

Downlink

RCS

Data Links

Mass Flow

Sensor

Tank

Latch

Valve

1553

ACARO

UART

ML16

DS16

Pressure

Transducer

Flow Control

Valve

Payloads

Deployable

ASM

VFM

C-EFI

ACC

DBA

Pipe

Branch

Thruster

Pipe

Merge

Colour Scheme

Fully REFA Defined

Partially REFA Defined

DHS

OBT

PM

RM

TM

MM

Multi

UART

TCD

CPDU

RU

Not REFA Defined

REFA for building a new simulator ...

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide14


Refa benefits

REFA benefits

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

    • all components need a complete documentation of their interfaces

    • and this documentation must be alwayssynchronisedwith the actual implementation

    • hence source code and documentation must originate from a single source

  • The reuse of existing mechanisms, infrastructurecomponents and base models will result in a more harmonisedbehaviour ofoperational simulators, such as …

    • same user commands between simulators

    • identical tracing, logging, reporting characteristics on different simulators

  • Overall increased productivity in the development of new simulators

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide15


Egos modelling framework egos mf

EGOS Modelling Framework (EGOS-MF)

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

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

    • It uses MagicDraw integrated into Eclipse.

  • Supports the full life cycle of simulator development

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

    • code generation by SIMSAT MIE (including code merge)

    • document generation (with customisation of generation templates)

    • model execution and debugging

  • The answer for managing simulators complexity efficiently is …

    • to model ! -- and the model is the single source of information

    • to automate !

    • and not to repeat yourself !

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide16


How to apply mdsd using uml and egos mf

How to apply MDSD using UML and EGOS-MF ?

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

  • Import the simulator requirements in EGOS-MF

  • 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

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

  • 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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide17


Egos mf overall development workflow

 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 overall development workflow

SDD, ICD, SUM

....

Architecture and

Architecture and

Interface Design

Interface Design

Requirements

Engineering

Requirements

Engineering

Development

Development

EGOS-MF profile

Requirements Editor

Requirements Editor

Document Generation Tool

Document Generation Tool

doxygen

doxygen

.doc

.html

.doc

.html

UML Editor

CORBA IDL Generation Tool

CORBA IDL Generation Tool

.idl

.idl

.csv

.csv

C++ Compiler

C++ Compiler

.cpp

.cpp

UML Model

UML Model

Requirements Import Tool

Requirements Import Tool

XML Schema Generation Tool

XML Schema Generation Tool

.xsd

.xsd

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

Catalogue Import Tool

Catalogue Import Tool

Catalogue Generation Tool

Catalogue Generation Tool

C++ CodeGenerator (MIE)

.cat

.cat

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

Model Validation Tool

Model Validation Tool

Catalogue Validator (MIE)

.cat

.cat

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide18


Egos mf code generation process

EGOS-MF code generation process

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

<<SMP2model>>MagneticTorquerHead

Models are essentially source code

Design

Development

Catalogue Editor

Editor

Templates

UML Model

Catalogue Generation

Tool

SMP2

Catalogue

C++

Code

Compiler

Object

File

Code Generator

Catalogue Validator

Package Editor

SMP2

Package

Makefile

Linker

Shared

Object

Platform Specific Model (PSM)

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide19


Egos mf example catalogue generation

EGOS-MF example: Catalogue Generation

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide20


Egos mf example c code generation

EGOS-MF example: C++ Code Generation

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

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

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide21


Egos mf use of the c code merger

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

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

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

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

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide22


Egos mf example c code merger output

EGOS-MF example: C++ Code Merger output

  • portion of source code of the MagneticTorquerHead -- after merging

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

    • portion of auto generated code without implementation -- before merging

    • portion of source code of the MagneticTorquerHead -- after merging

void 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--

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide23


Egos mf example document generation

SWARM SDD

REFA SDD

SWARM SDD

EGOS-MF example: Document Generation

  • The Document Generator generates Design Documentation for each SMP2 Model

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide24


Users common views across simulators

Drag and drop directly from tree to display window

Users common views across simulators

  • Users have identical views on … (for example):

    • Message logging filtering

    • Model failures

    • Parameter limits

    • Simulation tree (defined in the Assembly)

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

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

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

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide25


Conclusions

Conclusions

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

    • SMP2 -- interfaces enabling reuse and exchange of satellite models

    • REFA -- structured reuse of past acquired simulators knowledge

    • EGOS-MF -- automatised component based development

    • SIMSAT -- solid software infrastructure on linux platforms

  • From the users perspective

    • These advanced technologies respond to project needs and schedules

    • Demonstrated potential for reduced costs in producing future simulators

    • Requirements for multi-satellite systems are satisfied

OPS-G forum | The Swarmconstellation simulator development | 08th May 2009 | Slide26


Thank you for your attention

Thankyou 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


  • Login