BASILES: A common simulation platform to promote model and simulation reuse

Transcription

1 SpaceOps Conferences 5-9 May 2014, Pasadena, CA SpaceOps 2014 Conference / BASILES: A common simulation platform to promote model and simulation reuse S.Salas Solano 1, J.Marigo, F.Manon and A. Strzepek Centre National d Etudes Spatiales (CNES), Toulouse, France F.Quartier 2, S.Deschamps and M.Joubert Spacebel, Labège, France Simulators have become essential for space systems; from study to operational phases many different simulators are used (to dimension equipment, to validate the control center, to train the operators, etc). However, the requirements of each of these simulators are very distinct. In order to centralize CNES (Centre National d'études Spatiales) knowledge on simulation topics and to reduce costs, efforts have been focused on the development of one single platform for all sorts of simulator; this platform is BASILES (BAncs SImulateurs et Logiciels d'etudes de Satellites). Nonetheless, each company has its own simulation framework; with the aim of exchanging models with partners, BASILES shall be compliant with SMP2 (Simulation Model Portability v1.2) standard. This paper will describe the BASILES approach as well as the main principles and services available to implement a new simulator. At present, BASILES is widely used; several application examples will be presented. I. Introduction HE Centre National d Etudes Spatiales (CNES), and in particular the simulation department, has since several Tyears now the goal of promoting model and simulation reuse among space programs and among the different simulators that are created during the lifecycle of a project. To cope with this aim, a common simulation platform named BASILES (Bancs SImulateurs et Logiciels d Etude de Satellite) has been implemented. More than a simple tool, BASILES provides a methodology and a standard for CNES simulation. The BASILES approach allows sharing knowledge, reducing costs and improving development and maintenance efficiency. II. Background In the past, each new project at CNES developed its own simulator. Even within the same project, the simulator used in A-phase was completely independent from the simulator used in D-E phases. In 2004, after the simulation department was created, there was a strong drive in order to share tools and methods between departments and projects. The first step was to analyze the existing needs and implementations in order to compile the best of each approach to lead to one single platform: BASILES. A. Study simulator During the design phase, simulators are used to dimension equipment, to test prototypes, to conceive and implement algorithms as well as to evaluate performance and robustness. For this purpose, study simulators must be compliant with the following requirements: Model development/modification must be simple and quick (basic computing knowledge shall be required) Execution as fast as possible Hundreds of runs with sweeping variables 1 Test Bench and System Simulator Engineer, Ground to Space Department, Silvia.Salas@cnes.fr. 2 Technologist, Modeling & Simulation Business Unit, Fernand.Quartier@spacebel.be. 1 Copyright 2014 by CNES. Published by the, Inc., with permission.

2 Results analysis in differed time Reusable models (study simulators tend to be developed in an incremental and iterative way starting with few and relatively basic models) For many years at CNES, MACSIM (Moyens d'accueil pour la Conception de SIMulateurs) and Simulink have been used for this kind of simulator. MACSIM infrastructure has been conceived for AOCS simulators, focusing on an easy way to develop models and on the execution and analysis of hundreds of tests. B. Operational simulator During the qualification phase of space systems, it is necessary to have satellite simulators in order to validate the ground segment, to validate the operational procedures, to train operators, etc. Operational simulators must fulfill the following key requirements: From the operators point of view, the simulator should be indistinguishable from the real satellite Real time execution Causality must be respected and all runs must be reproducible Failure, fault and reproducible noise injection must be possible without model modifications Fine control and inward visibility (introspection) Formal and automated procedures for model and simulator validation Save/restore of context to allow bypassing operational lead-in times of many days Perennity guarantees for 15+ years The following infrastructures have been used at CNES for this kind of simulator (still in use): SINUS (SImulateur NUmerique Satellite): full numerical platform used in SPOT, HELIOS and PLEIADES projects. SINUS simulators include an emulator of the on-board processor running the real-onboard central software. PRESTO (PRoteus Engineering Simulator for Tests and Operations): full numerical platform used for CNES mini-satellites. It is a SINUS variant. BVSS (Banc de Validation Système et SCAO): simulation bench with software and hardware components used for CNES micro-satellites. The software component simulates equipment and satellite environment. The hardware devices are in charge of the electrical interfaces and the communication protocols between the equipment and the on-board central software. C. BASILES solution It can be noticed that the needs and user profiles associated to each phase are very different; the challenge was to provide a product which could answer to all needs without challenging users habits. In order to achieve all these requirements, BASILES core has been based on that of SINUS. However user first approach and simulator architecture are closer to MACSIM concepts. Hence, both SINUS and MACSIM models are almost plug-and-play in BASILES which is determining to allow the reuse of CNES simulation model patrimony. In addition, user interfaces have been developed to make BASILES first contact user-friendly. Figure 1. BASILES: One platform for all kind of simulator 2

3 III. BASILES overview First of all, BASILES is a simulation framework to develop, configure and run simulators. It allows representing complex systems within discrete event simulation. It contains the simulation kernel in charge of time and event handling, logger service, integrators, processor emulator management, distributed simulation handling, etc. But BASILES is also a model library in order to share and reuse models and simulators among space programs. A. BASILES framework BASILES operating system is Linux Red Hat 6.3 (32 and 64 bits); however it is possible to use it from Windows via a virtual machine. There are several steps in a simulator implementation: 1) Model development: a. Interface definition b. Source code generation 2) Simulator definition: Set of models and libraries 3) Simulator compilation: Executable generation 4) Simulator configuration: The result is a variant, which corresponds to a set of models, instances and connections. A model can be instantiated several times (e.g. GPS model instantiated twice with different characteristics). In the same way, a simulator can be instantiated several times (e.g. one variant containing just the payload, another variant containing the AOCS loop and a third one representing the whole satellite). 5) Simulator execution: a. Test definition b. Test execution 6) Simulation results analysis For all these phases, BASILES framework guides users to properly achieve each task. BASILES is a vast toolbox covering each of these steps. 1. BASILES: A toolbox to develop models and simulators Concerning the development of a new simulator, BASILES features help to easily develop prototypes with basic programming knowledge in a short period of time and with a good level of accuracy; among the functionalities: Model definition (inputs, outputs, configuration parameters, etc) Framework generation (e.g. source code from a model) Simulator visualization Compilation Model documentation generation The possibility of easily implementing new models is really important for study simulators in order to focus on thematic aspects rather than programming problems. Figure 2. Simulator Development MMI 3

4 2. BASILES: A toolbox to configure simulators Simulators are simply configurable thanks to BASILES devices for : Model configuration (instance): parameter configuration Simulator configuration (variant): instance order control, frequencies, connections between instances, integrator, etc Importing parameters from the project data base As a standard simulator includes more than 100 instances, it is essential to be able to connect/ configure them in an easy way. This task is done once for operational simulators but it is done several times for study simulators. 3. BASILES: A toolbox to run simulators In relation to the execution of a simulator, BASILES provides a large collection of selffunctionalities to interact with the simulation. In addition, it helps with: Test definition and generation (including sweeping variables for statistical analysis) Simulation distribution Failure injection Variable sampling/monitoring The introspection and failure injection functions are really essential for operational simulators. 4. BASILES: A toolbox to analyze results BASILES simulators can be connected to other CNES plotting tools in order to analyze the behaviour in real or deferred time. The plotting tools used are : PrestoPlot: Tool to display and manipulate graphs from sets of data in 2-Dimensions. PrestoPlot was developed for the PRESTO simulator project to help analyse and graphically compare test results. VTS (Visualization Tool for Space Data): Its principal functionality is to display satellite environments in 2 and 3- Dimensions. Additionally, there are also tools to ease examining the results of a group of tests for statistical analysis (mainly used in study simulators). Figure 3. Instance connection MMI Figure 4. CDT: Execution MMI Figure 5. Simulator visualization 4

5 B. BASILES components BASILES platform main components are: MMIs: Most functionality is available via BASILES MMIs; this issue is fundamental in order to reach a large public. We have tried to simplify them as much as possible, but it is difficult to keep a generic simple MMI with all features available; furthermore, the different users are not focused on the same functions. For instance, the CDT (Conduite De Test, MMI for simulation tests management) is fundamental for operational simulators, but it is less useful in a study simulator context. The programming language used for MMIs is Tcl/Tk. Commands: All functionalities to develop and implement a simulator are available via commands through the terminal. This guarantees the independence of BASILES functions from MMIs and facilitates the creation/modification of an MMI for a specific project. Modules: The programming language used is C/C++ and the principal modules are: o Executable generation software: In charge of the simulator executable creation by recovering the different modules, compiling them, etc. The modules must respect the interfaces imposed by the executable generation software. o Modules for the simulator execution: Integrator: 2 integrators are available, Runge-Kutta 4 (largely used) and Dormand-Prince 4(5) (ongoing validation). HLA (High Level Architecture) module: For distributed simulations (more details in III.D). SMP (Simulation Model Portability) module: To adapt SMP2 interfaces into BASILES interfaces (more details in IV). Kernel: BASILES execution core, in charge of time management, synchronization, event handling, logger service, etc. It is the most important module and indispensable for the simulator execution. It is a discreet event kernel where the event scheduling is extremely determining. It is an interface between the different modules and the test scenario. Tcl commands interpreter: Interface with the different modules and models. All these components are available in BASILES platform and are generic to all simulators using BASILES. Each new BASILES simulator will have access to these components and it will just be necessary to develop its own physical models (from BASILES models library or from scratch). BASILES INFRASTRUCTURE MMIs Commands to implement the simulator MAIN MODULES KERNEL (scheduler, time manager, etc) INTEGRATOR HLA SMP2 Executable Generation Software BASILES SIMULATOR USER MD (elementary or complete models) EXECUTABLE KERNEL DEVELOPMENT EXTERNAL CODES MD (complete models) SET OF VARIANTS, INSTANCES AND CONNECTIONS CONFIGURATION SET OF SCENARIOS AND TEST RESULTS EXECUTION Figure 6. BASILES infrastructure and simulator components 5

6 C. BASILES principles BASILES framework is based on the modularity and the independence of the different components. Here below are the main principles: Simulator compilation vs instantiation: It is important to distinguish the simulator creation from the simulator configuration which are two completely separated phases: o The simulator creation means the design/definition of models and in the end, the simulator compilation. o The simulator instantiation or configuration implies the definition of the connections and the configuration parameters of model instances. This part is interpreted by the BASILES kernel. Therefore it is not required to recompile the simulator when a connection or a configuration parameter is changed. Same matter when a new instance of an existing model is included or deleted in the simulator (e.g. 2 GPS instead of 1). This ability is useful for study simulators avoiding recompiling each time that a new instance is added. Interfaces between models: Models do not know each other, therefore, to exchange the information between them there are two mechanisms handled by the kernel: o Input-output: To share the variables values in a direct way, models use the input-output mechanism. o Activation-activation point: Models do not directly call subroutines (activations) of another model in order to ensure their independency. If a model needs to trigger another models subroutine, it will use the activation mechanism; the triggering model will prompt an activation point (without knowing what is going to be prompted) which will be caught by the kernel. Through the configuration files in which the activation point connection is described, the kernel will trigger the associated activation. Interfaces between user and models instances: o Commands: The simulation is initiated by Tcl commands through a client-server mechanism. All configuration files are converted into commands interpretable by the kernel. This same mechanism is adopted by the user to interact with the ongoing simulation (simulation pause, simulation speed control, instances failure injection, etc). Consequently, we can speak of three kind of commands: Intrinsic commands to BASILES platform and available for all simulators: Commands to initiate the test execution: connections and instance declaration, instance initialisation, etc. These kinds of commands are user hidden and are activated by BASILES execution module. Commands to interact with the ongoing simulation: variable value modification/overloading, simulation break, etc. These commands are activated by the user. Intrinsic commands to a simulator/model (e.g. equipment activation, failure injection, etc). These commands are activated by the user. o User s routines and programmable modules (advanced interface): This mechanism allows a generic interaction between the user and the model instance. The model forecasts calling a user s routine through a programmable module. The user s routine could be trace generation, archiving activation, a way to introspect model behaviour, etc. Elementary vs Complete models: Two kinds of models are accepted by BASILES framework: o Elementary models: This kind of model is easy to develop (helping tools), basic programming knowledge is required and source code is not specific to BASILES kernel. However there are several constraints to take into account. The programming languages used are Fortran, C, C++ and Java. During the executable generation this sort of model is automatically converted into complete models. o Complete models: There are no helping tools to develop this kind of model. They are more flexible than elementary models; in exchange, programming and BASILES kernel knowledge are required. The programming languages used are C and C++. In addition, models are also characterized by the use or not of the integrator (continuous vs discreet models). Continuous models can use BASILES integrator or a specific integrator. In the case of BASILES integrator, all continuous models are updated at the same frequency, this frequency must be higher or equal to the frequency of discreet models; each discreet model can have a different updating frequency. Discreet events kernel: Two types of events are possible: o Cyclical events: Periodic occurrence according to a defined frequency. This sort of event is used either to simulate in a discreet way a continuous process in time (orbit and dynamic models ) or to sample variables. o Non-cyclical events: Used to punctually activate a process, to simulate the arrival of a stimulus or a failure, to treat a telecommand, etc. 6

7 D. BASILES and the distributed simulations HLA has been conceived to connect or federate different computer simulations. The HLA architecture is constituted by several federates connected by HLA RTI (Run Time Interface) software. The RTI provides a group of services necessary to support federates to coordinate their operations and data exchange during a runtime execution. The HLA RTI software used in BASILES is an open source developed by ONERA (CERTI). Relying on this rule, BASILES provides the possibility of models communicating when executed in different BASILES kernels; the HLA module is in charge of this task. The objective is to start from a mono-kernel simulator and to execute it by different processes or computers in order to improve the performance. The method is implemented in such a way that the original models need not be modified. A distributed simulation using the BASILES HLA module is based on several BASILES kernels. Each kernel is executed in a different process. These processes can be executed in the same or in different machines inside the same network. The simulator is configured into several parts called federates, each federate contains a subset of model instances and an instance of the HLA module. Every resulting federate is executed in a kernel. It must be noticed that the causality is fully preserved; the results are exactly the same between the mono-kernel and the multikernel executions. Mono-kernel simulation CDT (Execution MMI) A C Single kernel B D Full instance list CDT (Execution MMI) A C 2-federates distributed simulation Single kernel + HLA_services This same method can be used to connect a BASILES simulator to simulators developed in other platforms. It has been tested with an electrical simulator called SABER as well as with a control center simulator. E. BASILES with hardware in the loop Ideally, even if it implies significant constraints, many of the models should be replaceable by hardware equipment. The use of real equipment allows raising the level of representativity and exposing the used models to a broader range of environments. Such operations have been successfully performed integrating real payloads with the numerical simulator via a 1553bus; this action was just a demonstration. The first time that in operational context hardware equipment has been used in a BASILES simulator has been in NOSYCA (New Operational SYstem for the Control of Aerostats) project. The new NOSYCA balloon on-board computer has been integrated within BASILES numerical simulator via a number of interfaces. B D Federate A: partial instance list HLA_ services Figure 7. Simulator distribution Communicator Communicator CDT (Execution MMI) HLA_ services Single kernel + HLA_services A C Federate B: partial instance list B D F. BASILES: A model library Another BASILES goal is to centralize all models in a common library to be able to use them in different projects and to avoid development from scratch each time a new simulator is needed. It is essential to share and perpetuate CNES expertise and to reduce costs and development period. Furthermore, some models are completely reusable from one project to another (e.g. environment models). IV. BASILES and model exchange with partners For several years now, the European Cooperation for Space Standardization (ECSS) has taken the initiative to develop the SMP standard (Simulation Model Portability). The aim of this standard is to allow models to be portable 7

8 among different simulation infrastructures. Interfaces are specified by SMP independently of simulation infrastructures. BASILES has its own standard for the simulator development and execution. However, in order to be able to reuse models developed by different partners, a software component has been developed in BASILES to provide adaptation of the SMP2 interfaces (version 1.2 of the SMP Standard) to the BASILES interfaces. The role of this component is to hide SMP2 specifics from the BASILES infrastructure. In addition to that, to encourage model exchange and to promote the reuse of simulation models between the various test facilities of one space project, BASILES also includes a wrapper to adapt auto generated code from Simulink simulators often used in 0-A phases into BASILES simulators. V. BASILES use cases BASILES has already been used in many different contexts, from study simulators to system/operation simulators, full numerical or hybrid simulators, among them: 1) In ARGOS simulator (worldwide tracking and environmental monitoring by satellite) a good level of performance has been achieved taking into account the great number of objects used (around ARGOS beacons are simulated). 2) In the CSO project (observation satellites for image provision and processing), there are two numerical simulators using BASILES, the AOCS simulator and the operational simulator, which favors model sharing. 3) In the context of NOSYCA, a full numerical simulator and a hybrid simulator have been developed to train the operators and to validate the new balloon system. This is the first BASILES operational application with hardware in the loop. In addition, thanks to the functionalities offered by BASILES, both simulators have been developed in record time. Although at the beginning BASILES has been particularly used for space programs, it is now being used in other application fields. In fact BASILES approach is not specific to aerospace and it can be reused in other domains. To prove this issue, a prototype of a road network simulator has been developed within BASILES. This simulator bears a great similarity to the ARGOS one. On one side, ARGOS 4 allows estimating the saturation level of ARGOS instruments by feigning the traffic of several tens of thousands of beacon messages towards the satellites. On the other side, the road network simulator models every vehicle (microscopic scale) in order to simulate the road traffic; this allows observing different macroscopic phenomena such as the accordion effect in traffic jams. The figure below shows the correspondence between ARGOS and the road network simulator. SATELLITES SCRAMBLERS BEACONS SPACE LINK BEACO NS GENERATO R BEACO N LO GIQ UE RO AD O BSTACLES VEHICLES TRAFFIC STATE TRAFFIC GENERATO R DRIVER S BEHAVIO UR Figure 8. Similarity between ARGOS and road network simulator VI. BASILES evolutions So far, several R&D efforts were focusing on BASILES integration with external simulators and equipment, while still running on mainstream Linux and computers to satisfy the 15+ years perennity requirements. It has been demonstrated that in many situations, BASILES combined with HLA can provide timely responses over several machines with a jitter below 100 µs, opening the door for more modular distributed test benches and simulation systems. BASILES is a natural target for SMP2 compatible models generated by the various actors of the space industry. The goal is to be able to design and integrate SMP2 models and to handle any of the SMP2 artifacts (catalogues, assemblies, schedule, packages and model code). CNES is an active actor in the SMP2 standard settings, and 8

9 naturally, BASILES shall remain compliant with current and future SMP standards. BASILES is currently used by several companies, even outside the space domain, as it has been shown that a wider user community generates more feedback and new ideas. This results in a faster system evolution and maturation to the benefit of all users. The PLEIADES operational simulator can run five simultaneous ERC32 processor emulators, but starts to hit the performance ceiling of modern systems. Newer satellites use faster and more processors, so several R&D programs in collaboration with industry specialists have been put in place to anticipate future generation systems. The Leon3 GR712 Multi-core program targets the switch to the multi-core Leon 3 and 4 processors, such as the GR712 and the upcoming LEON4 NGMP processors from Aeroflex Gaisler. Those processors contain several cores, which brings new challenges all along the life cycle: from software design, development and validation till operational simulators. First simulation tools have already proven very useful in investigating problems associated with the multi-core flight software design, interference and validation. Emulator performance is critical, so R&D efforts to investigate Just in Time compilation and Dynamic Translation of flight software have shown the needed perspective to reach 500 MHz target CPU emulation performance. The need to correctly support flight software patches and memory corruption does not simplify matters. Time and Space Partitioning (IMA, Integrated Modular Avionics, the space variant of ARINC 653) allows a better exploitation of more modern processors by improved isolation of payloads and instrument processing from the trusted platform software. This new approach however adds a number of challenges in the validation and simulation domain that are currently being addressed by R&D projects. The use of a MMU (Memory Management Unit) helps in flight software isolation and validation but brings its own problems. While, through its sequential nature, BASILES can handle up to half a million events per second, this is not enough when several (multi-core) emulators and ever more sophisticated models, such as precise thermal models, have to be integrated in the operational simulator. So R&D is going on to facilitate simulation of parallel flight cores and models taking full profit of the several cores currently available on mainstream PCs. The challenge here is to improve the performance while keeping reproducible systems and without impacting the model complexity and portability. VII. Conclusion Currently, BASILES is successfully used in many space programs, inside CNES but also outside. There are BASILES simulators in all project phases (the best example is CSO). However its main application remains the operational simulators; study simulators tend to use Simulink more and more. In the near future, BASILES shall remain compliant with current and future SMP standards to promote model exchanges and shall try to improve the simulation performance in order to cope with the frequency increase of on-board CPUs. AOCS/SCAO BASILES BVSS CNES CPU CSO ECSS HLA IMA MACSIM MMI NOSYCA ONERA PRESTO RTI SMP Appendix Acronym list Attitude & Orbit Control Subsystem/Système de Commande d'attitude et d'orbite BAncs SImulateurs et Logiciels d'etudes de Satellites Banc de Validation Système et SCAO Centre National d'études Spatiales Central Processing Unit Composante Spatiale Optique European Cooperation for Space Standardization High Level Architecture Integrated Modular Avionics Moyens d'accueil pour la Conception de SIMulateurs Man Machine Interface New Operational SYstem for the Control of Aerostats Office National d'etudes et de Recherches Aérospatiales PRoteus Engineering Simulator for Tests and Operations Run Time Interface Simulation Model Portability 9

10 SINUS TSP VTS SImulateur NUmerique Satellite Time and Space Partitioning Visualization Tool for Space Data Acknowledgments S.S.S. author thanks whole simulation department at CNES and Spacebel for their active contributions to this work and this paper. References 1 CERTI, HLA RTI Software Package, Ver , ONERA, Toulouse. 2 PrestoPlot, tool to display and manipulate graphs from sets of data in 2-Dimensions, Ver , CNES, Toulouse. 3 VTS, Visualization Tool for Space Data in 3-Dimensions, Ver. 2.5, CNES, Toulouse. 10