OPS Forum Simulations Evolution 15.02.08

  • 1,498 views
Uploaded on

Recent years have seen major technological developments in the area of simulation, including the ESA-developed ECSS Simulator Model Portability Standard (SMP-2). Recent years have seen major …

Recent years have seen major technological developments in the area of simulation, including the ESA-developed ECSS Simulator Model Portability Standard (SMP-2). Recent years have seen major technological developments in the simulation domain. Many of these development, notably the development of the ECSS Simulator Model Portability Standard (SMP-2), have been led by ESA, in the frame of a close cooperation between OPS-G and TEC-S. This OPs-G Forum will provide a general overview of the new developments, including the expected impact on overall space simulation activities, and will describe the effort being made within ESA - and OPS-G in particular - to support further technological advancements.

More in: Technology , Spiritual
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,498
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
20
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ESOC Simulators Past, Present and Future Nuno Sebastião (OPS-GIC), Vemund Reggestad (OPS-GDA), David Verrier (OPS-GDS)
  • 2. 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
  • 3. Future of ESOC Simulators
    • The way we got here
  • 4. 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
  • 5. Operational Simulator Costs
    • Cost have decreased.
    • Previously Large cost overruns.
      • Up to 100%
  • 6. 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
  • 7. Future of ESOC Simulators
    • Reducing costs
    • (Current measures)
  • 8. 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
  • 9. 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.
  • 10. 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
  • 11. Simulation Model Portability 2 Standard Outline
    • SMP2 Objectives
    • CCB Members
    • Status
  • 12. 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)
  • 13. SMP Evolution
    • 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)
  • 14. SMP Evolution
  • 15. CCB Members
  • 16. 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
  • 17. 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.
  • 18. Future of ESOC Simulators
    • Simulator
    • infrastructure:
    • Paving the way
    • to the future.
  • 19. Infrastructure Evolution
  • 20. SIMSAT 4 SIMSAT 4 SMP2 Support MMI Migration to Eclipse Community Requests
  • 21. SIMSAT – Supporting the Full Simulation Life cycle The Big picture
  • 22. 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
  • 23. 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.
  • 24. MCS NIS TMTCS IFMS/TCDS EGSE/FEE Spacecraft 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/F AIV System Real Systems Simulated Systems The big picture Ground Segment Test and Validation Infrastructure Available to missions Q2 2008
  • 25. MCS NIS TMTCS IFMS/TCDS EGSE/FEE Spacecraft 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/F AIV System Real Systems Simulated Systems SLE Ground Model SGM Very fruitful collaboration with the Aeolus team for the validation of the model.
  • 26. 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
  • 27. 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.
  • 28. 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 Kernel Emulator S/C Model MCS/NCTRS ` WHITE-BOX Kernel Ground Models Simsat MMI WHITE-BOX MMIPlugin
  • 29. Future of ESOC Simulators
    • Cooperation
    • with ESTEC
    • (TEC-SW)
  • 30. 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
  • 31. 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?
  • 32. Reference Simulator Architecture Phase A Horizontal Approach Rosetta Aeolus Vertical Approach Mars Express Phase B Phase C Phase D TEC-SW OPS-GI/GD
  • 33. 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
  • 34. Future of ESOC Simulators
    • Cooperation
    • with partners
  • 35. 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.
  • 36. 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
  • 37. Future of ESOC Simulators
    • Towards model integration
  • 38. Reference Simulator Architecture. Why do we need one?
    • 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)
  • 39. 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.
  • 40. Reference Architecture
    • 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
  • 41. Future of ESOC Simulators
    • The Future of Operational Simulator Development
  • 42. 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.
  • 43. Step 1: Simulator Assembly If developed according to a Reference Architecture, this is feasible:
  • 44. Step 2: Customization
    • TX_A
    • Monitoring:
    • 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
  • 45. Step 3: Runtime
  • 46. Future of ESOC Simulators
    • Summary
  • 47. 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.
  • 48. Future of ESOC Simulators
    • 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
  • 49. Thank you for your attention ! Let’s build the future
    • Let’s continue to build the future