Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OPS Forum Swarm simulator development 08.05.2009


Published on

An explanation and illustration of what SMP-2, REFA and EGOS-MF are - and how these can be used to facilitate and streamline the production of spacecraft simulators.

It is well known that spacecraft simulators are complex systems. It is probably less well known what mysterious terms like 'SMP2', 'REFA' or 'MF/UMF' really mean.

To facilitate and streamline the production of future simulators, ESOC has invested in the definition and the application of software standards (SMP2), architecture (REFA) and methodologies (EGOS-MF/UMF).

This forum will reveal the meaning of these terms, focusing on their concrete usage and advantages in the development process, via a case study of the Swarm Constellation Simulator development. A number of animated slides will illustrate the simulator development process, starting with the key concepts to be applied throughout and finishing with the actual source code production.

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

OPS Forum Swarm simulator development 08.05.2009

  1. 1. 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
  2. 2. What this presentation is about… <ul><li>Why attempting a new approach in making simulator software ? </li></ul><ul><li>Explanation of what SMP2, REFA and EGOS-MF are </li></ul><ul><li>Illustration of how SMP2, REFA and EGOS-MF are applied for the Swarm Simulator development in the SIMSAT 4 environment </li></ul><ul><li>Conclusions -- then Q&A </li></ul>
  3. 3. Rationale -- Background <ul><li>Recognition that development strategies better than mere reuse should be explored </li></ul><ul><li>Take advantage of new technologies and of ESA most recent standards </li></ul><ul><li>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 </li></ul><ul><ul><li>m ore details available at swarm .html </li></ul></ul>
  4. 4. Why do we need a reference architecture ? <ul><li>No clear interface between models </li></ul><ul><li>Difficult to isolate models for reuse </li></ul><ul><li>Transforming a working simulator into a new one can result in a faulty simulator and cause much unneeded code to stay </li></ul><ul><li>Reuse potential mostly only via “copy&paste” </li></ul>Example of what a simulator software architecture may look like: <ul><li>How about if we … </li></ul><ul><ul><li>defined clear interfaces between the different elements in a spacecraft ? </li></ul></ul><ul><ul><li>defined some suitable breakdown of a whole simulator into models ? </li></ul></ul><ul><ul><li>improved reusability at model level in a “plug&play” fashion ? </li></ul></ul>CDMU SDB Power RFCS AOCS Generic Models Payloads Thermal
  5. 5. “Operationally responsive” technologies <ul><li>The SMP2 Standard … </li></ul><ul><ul><li>promotes portability of models among different simulation environments and operating systems </li></ul></ul><ul><ul><li>promotes the reuse of simulation models </li></ul></ul><ul><ul><li>fulfills these objectives by providing a standard interface between the simulation environment and the models </li></ul></ul><ul><li>The Reference Architecture ( REFA ) … </li></ul><ul><ul><li>identifies, using SMP2, a reference spacecraft simulator architecture which can be used as the basis for simulators design and development </li></ul></ul><ul><ul><li>achieves shorter development cycles by reuse relying extensively on a common architecture </li></ul></ul><ul><ul><li>fulfills these objectives by specifying interfaces between spacecraft subsystems and by identifying models which can be developed in a generic fashion </li></ul></ul>
  6. 6. SMP2 architecture SMP2 second component : a Simulation ENVIRONMENT (and its services) ` 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 first component : a SIMULATION (with its model instances) Model.1 Model.2 Model.n Model.i … … Mandatory services: Information logging Entry point scheduling Times provision Events manager Mandatory interfaces: Access to simulator state Access to simulator services Publication mechanism
  7. 7. SMP2 simulation services and interfaces <ul><li>Simulation services are … </li></ul><ul><ul><li>provided by the simulation environment </li></ul></ul><ul><ul><li>consumed by the models </li></ul></ul><ul><ul><li>based on standardised interfaces </li></ul></ul><ul><li>Every model must implement the IModel interface </li></ul><ul><li>Every simulation service must implement the IService interface </li></ul>Connect Run Hold Restore GetState GetTimeKeeper GetModel … etc… Connect Configure Publish GetName GetParent … etc… ISimulator Model Simulation Environment IModel Scheduler IScheduler Time Keeper ITimeKeeper Logger ILogger Event Manager IEventManager IService
  8. 8. SMP2 hierarchy -- the main parts 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 Catalogue C1 Model M1 Fields .. Operation .. Association .. Model M2 Field .. Associations .. Entry Point .. Model M3 Fields .. Entry Points .. Schedule S1 Assembly A3 Assembly A1 Assembly A2 Model-Instance C Model M2 Assembly A1 Model-Instance A Model M1 Model M3 Model-Instance B Model M1 Model M4 Model M3
  9. 9. SMP2 key benefits <ul><li>SMP2 avoids developing models which use the operating system or hardware specific dependencies -- Platform Independent Model (PIM) </li></ul><ul><li>SMP2 promotes the use of modern software engineering techniques -- in particular component based design </li></ul><ul><li>SMP2 makes reuse easier via breaking dependencies between simulator models </li></ul><ul><li>SMP2 allows dynamic configuration -- for example the user may at “runtime”: </li></ul><ul><ul><li>select different orbit propagators depending on the required accuracy </li></ul></ul><ul><ul><li>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) </li></ul></ul>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)
  10. 10. REFA onset <ul><li>REFA started with investigating what would be worth being standardised for all satellite subsystems across simulators </li></ul><ul><ul><li>-- via the actual screening of 4 different space missions </li></ul></ul><ul><li>As a result REFA identified … </li></ul><ul><ul><li>what should the “reference spacecraft simulator” requirements be </li></ul></ul><ul><ul><li>all interfaces between the different elements in a spacecraft simulator </li></ul></ul><ul><ul><li>the models which can be developed </li></ul></ul><ul><ul><ul><li>in a generic fashion (e.g. satellite dynamics, orbital environment modelling , satellite thermal control, communications subsystem, …) </li></ul></ul></ul><ul><ul><ul><li>those other models which need to be developed specifically for each mission </li></ul></ul></ul><ul><li>This is a system architecture -- some work remains to be done ... </li></ul><ul><li>Use this architecture as the basis for future simulators development ! </li></ul>
  11. 11. 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 REFA utilities REFA subsystems: Generic Units Failures Messages Events Parameters AOCS Payloads Radio Frequency Reaction Control Data Handling Data Links Thermal Control Electrical Power Parameter Mapper Simulation Monitor Configurator Aligned Unit Magnetic Torquer Head Simulation Model Portability 2 (SMP2) Component Model Logger Scheduler Time Keeper Resolver Events Manager
  12. 12. REFA output <ul><li>Illustrated via the AOCS example of the Magnetic Torquer Head … </li></ul>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 Interface allowing to set the dipole momentum and to read the produced torque Generic Models (SMP2) PEM SIMDYN External Force Earth Magnetic Field Aligned Unit External Force Interface Earth Magnetic Field Interface Magnetic Torquer Interface Magnetic Torquer Head
  13. 13. REFA actual use in a project <ul><li>Example of … </li></ul><ul><li>Swarm ::Aocs::MagneticTorquerHead inherited directly from … </li></ul><ul><li>REFA ::Aocs::MagneticTorquerHead </li></ul>REFA model -- shown in previous slide … Swarm model -- derived from a REFA model to provide the mission required implementation
  14. 14. REFA for building a new simulator ... EPS Battery PCDU Solar Array TCS Thermistor Thermostat Solar Surface AOCS STR CESS FGM MTQ GPSR RCS Tank Pipe Merge Pipe Branch Mass Flow Sensor Pressure Transducer Latch Valve Flow Control Valve Thruster RFCS Antenna Combiner Transfer Switch Transmitter Receiver Ground Uplink Downlink Data Links 1553 ACARO UART ML16 DS16 Payloads ASM VFM C-EFI ACC Deployable DBA DHS OBT PM RM TM Multi UART TCD CPDU RU MM Colour Scheme Fully REFA Defined Partially REFA Defined Not REFA Defined
  15. 15. REFA benefits <ul><li>Models developed based on REFA are potential candidates for later reuse in other simulators. Therefore … </li></ul><ul><ul><li>all components need a complete documentation of their interfaces </li></ul></ul><ul><ul><li>and this documentation must be always synchronised with the actual implementation </li></ul></ul><ul><ul><li>hence source code and documentation must originate from a single source </li></ul></ul><ul><li>The reuse of existing mechanisms, infrastructure components and base models will result in a more harmonised behaviour of operational simulators, such as … </li></ul><ul><ul><li>same user commands between simulators </li></ul></ul><ul><ul><li>identical tracing, logging, reporting characteristics on different simulators </li></ul></ul><ul><li>Overall increased productivity in the development of new simulators </li></ul>
  16. 16. EGOS Modelling Framework (EGOS-MF) <ul><li>Eclipse based IDE extension for developing SMP2 simulators and for increasing software development efficiency </li></ul><ul><ul><li>EGOS-MF is a collection of Eclipse Plug-ins. </li></ul></ul><ul><ul><li>It uses MagicDraw integrated into Eclipse. </li></ul></ul><ul><li>Supports the full life cycle of simulator development </li></ul><ul><ul><li>design of models -- systematically (re-)start at the UML design stage ! </li></ul></ul><ul><ul><li>code generation by SIMSAT MIE (including code merge) </li></ul></ul><ul><ul><li>document generation (with customisation of generation templates) </li></ul></ul><ul><ul><li>model execution and debugging </li></ul></ul><ul><li>The answer for managing simulators complexity efficiently is … </li></ul><ul><ul><li>to model ! -- and the model is the single source of information </li></ul></ul><ul><ul><li>to automate ! </li></ul></ul><ul><ul><li>and not to repeat yourself ! </li></ul></ul><ul><li>Hence: Model Driven Software Development (MDSD) supported by the EGOS-MF suite </li></ul>
  17. 17. <ul><li>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. </li></ul><ul><li>Import the simulator requirements in EGOS-MF </li></ul><ul><li>With the requirements in place, the design of mission specific models can be started: </li></ul><ul><ul><li>Example: new disk mapped memory model, using the UML modules from REFA </li></ul></ul><ul><li>Create a new SMP2 Model named “DiskMappedMemory”: this will create a UML Component with the <<SMP2model>> stereotype </li></ul><ul><li>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 </li></ul>How to apply MDSD using UML and EGOS-MF ?
  18. 18. EGOS-MF overall development workflow Requirements Engineering .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++ Compiler Requirements Engineering .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++ Compiler .... Catalogue Validator (MIE) C++ Code Generator (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
  19. 19. EGOS-MF code generation process <ul><li>This systematic code generation process is illustrated next, proceeding from the previous UML example </li></ul><ul><ul><li><<SMP2model>> MagneticTorquerHead </li></ul></ul>Development Design UML Model SMP2 Catalogue Catalogue Generation Tool Catalogue Validator C++ Code Code Generator Makefile Catalogue Editor SMP2 Package Package Editor Object File Compiler Shared Object Linker Editor Templates Models are essentially source code Platform Specific Model (PSM)
  20. 20. EGOS-MF example: Catalogue Generation <ul><li>The Catalogue Generator translates UML Design into SMP2 Catalogue (XML File) </li></ul>
  21. 21. EGOS-MF example: C++ Code Generation <ul><li>The Code Generator generates C++ Source Code for each SMP2 Model wih SIMSAT MIE </li></ul><ul><ul><li>it converts the types defined in the Catalogue into C++ source code (header files and skeleton implementation files) </li></ul></ul><ul><ul><li>various methods (e.g. for publication and dynamic invocation) are auto generated </li></ul></ul>
  22. 22. EGOS-MF: use of the C++ Code Merger <ul><li>The user-defined methods are empty and need to be completed using an external C++ development environment. </li></ul><ul><ul><li>the Code Merger can merge an existing implementation into newly generated skeleton code. Therefore, all operations that already have an implementation maintain their implementation </li></ul></ul><ul><ul><li>“ manual” changes do not have to be re-applied after each merge </li></ul></ul><ul><ul><li>neither SIMSAT nor EGOS-MF support implementation of model specific functionality -- beyond auto generated SMP2 code </li></ul></ul>
  23. 23. EGOS-MF example: C++ Code Merger output <ul><li>Illustration of the merging of the “manual” code of the “setter” for the magnetic dipole momentum which causes an update of the produced torque … </li></ul><ul><ul><li>portion of auto generated code without implementation -- before merging </li></ul></ul><ul><ul><li>portion of source code of the MagneticTorquerHead -- after merging </li></ul></ul>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-- <ul><ul><li>portion of source code of the MagneticTorquerHead -- after merging </li></ul></ul>
  24. 24. EGOS-MF example: Document Generation <ul><li>The Document Generator generates Design Documentation for each SMP2 Model </li></ul>REFA SDD SWARM SDD SWARM SDD
  25. 25. Users common views across simulators <ul><li>Users have identical views on … (for example): </li></ul><ul><ul><li>Message logging filtering </li></ul></ul><ul><ul><li>Model failures </li></ul></ul><ul><ul><li>Parameter limits </li></ul></ul><ul><ul><li>Simulation tree (defined in the Assembly) </li></ul></ul><ul><li>Users have identical views (for example) on failed or forced parameters: </li></ul><ul><ul><li>The magnetic torquer head has Analogue Parameters (e.g. the global magnetic field) -- hence they have limits and they can be forced </li></ul></ul><ul><ul><li>The magnetic torquer head can be failed because it is a Generic Unit </li></ul></ul>Drag and drop directly from tree to display window
  26. 26. Conclusions <ul><li>Building the ESA operational simulators is “better, faster, cheaper” with: </li></ul><ul><ul><li>SMP2 -- interfaces enabling reuse and exchange of satellite models </li></ul></ul><ul><ul><li>REFA -- structured reuse of past acquired simulators knowledge </li></ul></ul><ul><ul><li>EGOS-MF -- automatised component based development </li></ul></ul><ul><ul><li>SIMSAT -- solid software infrastructure on linux platforms </li></ul></ul><ul><li>From the users perspective </li></ul><ul><ul><li>These advanced technologies respond to project needs and schedules </li></ul></ul><ul><ul><li>Demonstrated potential for reduced costs in producing future simulators </li></ul></ul><ul><ul><li>Requirements for multi-satellite systems are satisfied </li></ul></ul>
  27. 27. 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