Simulation platform and method for configuring real-time and non-real-time simulators in order to execute different simulation programs within common simulation environment by means of simulation platform

Abstract

The invention relates to a simulation platform and a method for configuring a real-time and / or non-real-time simulator in order to execute different simulation programs in a common simulation environment by means of the simulation platform for testing a controller, preferably for the automotive or aeronautical field.

Description

Technical Field

[0001] This invention relates to a simulation platform and a method for configuring real-time and / or non-real-time simulators to execute different simulation programs within a common simulation environment to test controllers, preferably for use in the automotive or aerospace fields. Background Technology

[0002] Testing controllers before they are used in mass-produced vehicles is essential. However, the complexity of this testing is constantly increasing due to the growing number of controllers and their tasks in vehicles, especially in the areas of driver assistance or autonomous driving. Furthermore, there is a wide variety of development tools and prototypes at different stages of development. For example, a controller may initially exist only as a software model (such as a Simulink model or as a virtual controller (VECU) in a further structural hierarchy), but it still needs to be tested in combination with an actual controller.

[0003] Several issues may arise here, such as the inability or unwillingness to reuse simulation artifacts (referring to simulation models, configuration files, etc.). The simulation model may not have been exported from the simulator it was initially running; it may have been compiled for a specific target processor. Users may also have generated their configuration files or simulation models for a specific tool or using a specific tool and wish to continue using that tool. Integrating different simulation artifacts to test the controller by simulating the entire model is a complex and laborious task, requiring significant manual configuration, and becoming even more difficult when some simulation artifacts have real-time requirements while others do not. Furthermore, using a real-time simulator is also expensive. Summary of the Invention

[0004] The objective of this invention is to improve upon existing technologies.

[0005] This task is solved by a simulation platform according to the invention and a method for configuring real-time and non-real-time simulators.

[0006] The simulation platform has an interface with a data repository (i.e., a resource library, database, or other suitable source) containing configuration information about the corresponding simulator (especially about storage space, runtime, operating system, processor capabilities, synchronization features, etc.).

[0007] The first step provides simulation artifacts in various forms, including simulation models and meta-descriptions and / or configuration information for the simulation models (communication matrices, AUTOSAR descriptions, etc.). The meta-descriptions are used to create a description of the entire system with logical connections for use in the overall system simulation. Furthermore, the meta-descriptions ensure the overall quality of the subsequent simulation environment, as the maturity or potential certification level of the input artifacts is also recorded in the meta-descriptions. When all input artifacts possess the required quality or certification level, the simulation environment can be used for testing and certification.

[0008] Input artifacts can be abstract, technology-independent artifacts, such as interface descriptions; but they can also be concrete artifacts, such as models, bus information (e.g., in the form of a Bus Simulation Container (BSC)).

[0009] In the second step, information about the simulator (which can be a hardware or pure software simulator) is provided, and the simulation model is assigned to each simulator in the deployment description according to the simulation requirements (such as storage space, runtime, operating system, processor capabilities, synchronization characteristics, real-time requirements, etc.).

[0010] In the third step, the information about each simulator contained in the data repository is used to generate executable programs and application descriptions for the simulation models (i.e., binary files for execution and, for example, JSON files, XML files, or YAML files for description), which can also be provided by the corresponding simulator.

[0011] The executables are emulator-specific. If necessary, metadata is also provided to these executables, which enables optimization of communication between different emulators and other parameters as needed, through emulator-specific (proprietary, emulation platform unknown) instructions.

[0012] In this step, artifacts previously defined independently of the simulator need to be converted into a configuration format understandable by the target simulator, or a specific executable model needs to be generated. Furthermore, the simulator returns its own specific information and limitations to the entire process so that this information can be taken into account in the co-simulation.

[0013] It is through this step that arbitrary input artifacts and arbitrary simulators can be supported. Simulator-specific aspects when converting system-independent artifacts are abstracted and, in particular, automated to the highest possible degree. Users no longer need to concern themselves with the specific details of the corresponding simulator (e.g., the ConfigurationDesk tool from dSPACE GmbH for the SCALEXIO HIL system and the VEOS-Player tool from dSPACE GmbH for the offline simulator VEOS, which automate the configuration method according to the invention).

[0014] In the fourth step, a communication configuration is created according to the given simulation platform communication protocol, which includes simulator-specific executable programs and application descriptions. The communication configuration is used to configure simulation agents for the corresponding simulator.

[0015] Then, based on the individual simulator-specific configurations and the connections and deployments described in the preceding system description, a final configuration of the simulation system can be created (i.e., which simulator uses which model and when to send which data via the platform protocol). This final configuration is then redeployed to the individual simulators.

[0016] In the fifth step, the corresponding simulation agent is configured on the simulator according to the communication configuration for the simulation of the entire system, thereby establishing the simulation of the entire system by using the collaborative simulation of different simulators.

[0017] For each step, there exists a rule set consisting of a set of validation rules (as a script or program if necessary). Based on this rule set, at least several, but as many as possible, of the mock artifacts and configuration artifacts used in that step are checked at the beginning, and the correctness (regarding semantics, syntax, port connections, interfaces, etc.) and consistency of as many mock artifacts and configuration artifacts created in that step as possible are automatically checked after each step is executed. The rules in the rule set can be adjusted by the user using a rule language. When a rule violation is detected, at least one warning is issued.

[0018] The method according to the invention enables quasi-standardized, message-based data exchange to achieve a shared simulation environment with multiple real-time and non-real-time / hybrid simulators. This includes simulation data exchange as well as time synchronization, simulator control (start / stop / pause), etc. By combining a unified configuration (which describes how all simulators uniformly exchange data) with a predetermined communication protocol (e.g., a Data Distribution Service (DDS) protocol), data can be exchanged arbitrarily between simulators, thus enabling collaborative simulation.

[0019] The minimum requirement for a simulator is that the non-real-time simulator (e.g., the VEOS simulator from dSPACE GmbH) must be capable of near real-time computation to participate in the overall simulation with a real-time simulator (e.g., the HIL simulator such as dSPACE's SCALEXIO). An alternative is to connect the non-real-time simulator via data-driven scheduling. In this scenario, the real-time simulator pre-clocks, while the non-real-time simulator advances a time step immediately after receiving all necessary inputs. Another alternative implementation is loose coupling using unsynchronized clocks. This implementation can be used when the clock rate of the application on the non-real-time simulator is significantly higher than that of the real-time simulator (e.g., 10 µs for real-time versus 10 ms for non-real-time). All these implementations can coexist within a single simulation environment.

[0020] The configuration process according to the present invention enables coupling between real-time simulators and non-real-time simulators in such a way that all steps support the generation of a stable simulation system, for example, by generating a deployment such that all simulators have sufficient performance buffers and by communicating in such a way that data is always available on the corresponding simulator in a timely manner (e.g., through data / signal grouping, cooperative simulation algorithms, etc.).

[0021] After each configuration step, a mechanism performs pre-specified checks. Based on the corresponding step, the consistency of artifacts (i.e., files or programs created in a step) can be specifically checked. Specific checks are performed according to the formal standards and specific requirements of the corresponding simulator. They are defined through a set of rules. For example, checking whether the AUTOSAR syntax of the AUTOSAR file is correct or whether the model corresponds to the attached meta-model. Logical connections and port connections are also checked in particular. These quality checks allow for the reasonable automation of the configuration process.

[0022] The simulation platform has an interface with a corresponding simulator, through which real and virtual controllers can be connected. Furthermore, the simulation platform has an interface with testing and monitoring tools, such as those for simulation parameterization and signal display. In this way, the simulation platform serves as a testing and integration platform.

[0023] The simulation of the entire system is preferred for testing the controller. After step five, the test is initiated by synchronously simulating the entire system using a corresponding simulator.

[0024] By leveraging the collaborative simulation capabilities of different simulation programs, controller systems can be tested even when controllers are still at different stages of development (some controllers may exist only as virtual controllers, i.e., solely in software form). Simulations of the controller environment can also be seamlessly integrated, for example, using Simulink models.

[0025] The preferred simulation agent is provided by a software program on the corresponding simulator. This simulation agent manages different services of the simulator and transmits corresponding signals and data via an interface. The simulation agent can also transmit this data and signals to other simulation agents in the system according to the protocol defined for the simulation platform through its interface.

[0026] The simulation model here is provided by a functional model, specifically a Simulink model, an FMU, or a virtual controller. This is exemplary. In principle, this refers to any model that represents the computational rules used for the process to be simulated.

[0027] In one implementation, in step 4, for communication between simulators, signals defined in the communication configuration are grouped in such a way that the exchange is performed as efficiently and consistently as possible using message packets, thereby avoiding redundancy and ensuring that the signal data changes substantially simultaneously, making the data up-to-date and consistent in time. This is achieved using relevant information in the corresponding configuration artifacts.

[0028] Generally speaking, configuration artifacts here refer to the artifacts / files generated during the configuration process and progressively—from the logical connections of the various artifacts, to the deployment of the model on the simulator, to the generation of simulator-specific configurations and simulation models, and finally to downloading to the target platform (simulator)—either generated or manually created. Artifacts such as communication matrices, FMUs, and Simulink models are used as input artifacts in the configuration process.

[0029] Error checks should be performed as early as possible on input workpieces and intermediate results generated during the process using quality inspection / quality gating.

[0030] The preferred simulation platform communication protocol is given through a publish-subscribe protocol, especially through the use of the Real-Time Publish-Subscribe (RTPS) protocol of DDS.

[0031] Based on the deployment description and the overall system description, the protocol is implemented in the configuration process according to the present invention by receiving the corresponding information and instructions into the application description and the communication configuration for simulating the agent.

[0032] In one implementation, in step 4, a specific topic for publish-subscribe communication is created for a specific set of signals based on signals defined in the communication configuration, so that simulators that process these specific signals can register to the corresponding topic to obtain the desired signals.

[0033] Such topics can be used to efficiently enable communication between simulators.

[0034] Preferably, each simulator has at least two interfaces with the simulation platform, so that data flow for simulating the entire model can be transmitted through one interface and status or control signals can be transmitted to the test tool through the second interface.

[0035] In one implementation, the rule set is stored in a storage area accessible to the simulation platform, and the rule set is mutable, and in particular scalable. This allows users to define, using a rule language, which quality checks or tests should be performed before simulation.

[0036] Preferably, at least one emulator runs in a virtual machine (VM) or container implemented in the cloud, and at least one configuration tool required in step 3 (i.e., a program for configuring the emulator or at least a portion thereof) runs in the virtual machine or container.

[0037] Furthermore, the task is solved by a simulation platform according to the invention for performing the method according to the invention.

[0038] In one implementation, the simulation platform and its corresponding programs are deployed in the cloud, at least one local computer, or distributed across the cloud and the at least one computer. Attached Figure Description

[0039] The present invention will now be described in detail with reference to the accompanying drawings. The drawings are as follows:

[0040] Figure 1 A schematic diagram of a controller test structure having a simulation platform according to the present invention is shown;

[0041] Figure 2 An illustrative flow diagram of the method according to the present invention is shown, which includes quality checks for each method step (1, 2, 3, 4, 5);

[0042] Figure 3 This provides an overview of the workpiece related to the method;

[0043] Figure 4 A schematic diagram showing the relationship between steps 3 and 5;

[0044] Figure 5 A schematic diagram of a SimAgent is shown;

[0045] Figure 6 A schematic diagram showing the structure of the interface of the simulation platform according to the present invention, together with the corresponding protocol for the communication platform;

[0046] Figure 7 A schematic diagram of the simulation platform and its interfaces is shown.

[0047] Figure 8 This illustrates a meta-model for configuring the communication model;

[0048] Figure 9 Showing with Figure 8 The code corresponding to the communication in the meta-model;

[0049] Figure 10 This diagram illustrates the communication between a model running on a real-time simulator (Scalexio) and a model running on a non-real-time simulator (VEOS) via the RTPS protocol. Detailed Implementation

[0050] Figure 1A schematic diagram of a controller test structure with a simulation platform according to the present invention is shown. Data exchange occurs between the simulator (including real-time (RT) simulators (RT Simulator #1, RT Simulator #2) and non-real-time simulators (non-RT Simulator)), test tools (testing and experimentation (e.g., ControlDesk), monitoring and control), and data repository (Repo. or DB) via the simulation platform or via protocols and integration layers defined for the simulation platform. For real-time data: signals and variables; for virtual buses: raw format messages; and, if necessary, injected / manipulated data. The real controller is connected to the real-time simulator for testing via a real bus connection (real bus, CAN, LIN). These controllers can also be connected to the real-time simulator via other technologies, such as automotive Ethernet. Management for status monitoring and management for test control (control, including loading configuration) are also performed through the simulation platform.

[0051] Figure 2 The diagram illustrates a schematic flow of the method according to the invention, including quality checks for each method step (1, 2, 3, 4, 5). First, the simulation artifacts / components required for step 1 (1-component linking), such as models, meta-descriptions, and configuration information, are input into the simulation platform (typically by the user, i.e., manually). These simulation artifacts (preferably all simulation artifacts) are checked according to predetermined rules, and then a description of the entire system (system description) and other artifacts, if necessary, are created. The meta-description is used, for example, to create logical connections / links. The other artifacts created, if necessary (preferably all artifacts), are also checked for quality and consistency again. The second step (2-component deployment) is then performed based on the description of the entire system (system description). In the second step, all input artifacts are checked again at the beginning, preferably the system description as well. For example, other artifacts containing information, such as global I / O information, can be added to the process. Then, in this second step, a deployment description is generated, which determines the deployment of the model on each simulator based on the requirements in the system description. Simulator allocation is preferably automatic. However, simulators can also be added manually. This also applies to the allocation of components / simulation artifacts to their respective simulators.

[0052] In the third step (3. Simulator-Specific Configuration), where all input and output artifacts are checked as much as possible at the start and end, simulator-specific information and constraints (such as constraints regarding communication, synchronization, etc.) are also incorporated. These information and constraints therefore also depend on the simulator manufacturer. It is particularly important here that the rule set is adjustable and extensible, enabling the acceptance of various different simulators into the process. The result of the third step is the application description and executable files, i.e., binary files (Executables). Executables are typically system-dependent, i.e., compiled for a specific simulator. Preferably, this process is automated using vendor-specific tools.

[0053] In the fourth step (4. Simulation System Generation), all input and output artifacts for this step are summarized and checked again as much as possible. The result of this step is essentially the communication configuration of the simulation agent (SimAgentConfig). Using simulator-specific artifacts, the communication of each simulator is defined through a unified platform communication protocol, and the communication is encoded into corresponding configuration files (SimAgentConfiguration).

[0054] In step five (5. Deployment on the Simulator (SimAgent)), these configuration files (=communication configuration) are collected and loaded onto the appropriate emulator. A quality check is also performed at the start of this step. After configuring the emulator or simulation agent, the simulation of the entire system can be started.

[0055] Figure 3 This provides an overview of the products of the method.

[0056] The file format defines the interface between the various configuration steps in some way. The simulation platform uses existing open standards such as SSP (System Architecture and Parametrics: https: / / ssp-standard.org / ) or MIC (Model Identity Card: https: / / mic.irt-systemx.fr / mic) or also defines these formats by (possibly additionally) using new open descriptions (quasi-standards).

[0057] Figure 4 A diagram illustrating the relationship between steps 3 and 5 is provided, and it shows that a simulated workpiece from one step can be used in another step via a reference.

[0058] The third step (3. Emulator-Specific Configuration) provides emulator-specific configuration tools that support platform-defined inputs and outputs and can be automated.

[0059] In step 5 (5 Deployment on the simulator), SimAgents are provided and configured. They represent the simulator and provide platform-defined interfaces for exchanging data and commands.

[0060] Figure 5 This section describes the tasks of a SimAgent. A SimAgent essentially consists of a program stored on a corresponding simulator, enabling the simulator to execute its simulation tasks. Specifically, the SimAgent enables management, synchronization, and communication through a unified simulation protocol on the simulation platform. Furthermore, the SimAgent provides various services such as collaborative simulation / multiprocessor simulation, data logging, time synchronization, simulation execution and control, data for sensor simulation, playback of logged data, error logging, status monitoring, and real-time testing.

[0061] The SimAgent shown in the diagram provides interfaces, such as interfaces with other SimAgents or directly with real hardware such as bus systems (see Figure 1).

[0062] Figure 6 A schematic diagram showing the structure of the interface of the simulation platform according to the present invention, along with the corresponding protocol for the communication platform, is shown here in enlarged view. Figure 1 The diagram shows the connection between a real-time simulator (RT Simulator #1) and the simulation platform. It can be seen that this connection actually consists of two interfaces: one for data exchange with the application (simulation program or model), which is conducted via the RTPS protocol using DDS (Data Distribution Service). Communication with the testing tools is conducted through a REST (Representation State Transition) interface.

[0063] Optionally, additional APIs (platform APIs) are also provided here. Based on the platform's protocol stack, such interfaces (application programming interfaces (APIs) can be provided in various different forms or for different providers.

[0064] Figure 7This diagram illustrates the structure of a simulation platform and its interface (platform interface) across different communication layers. The simulation platform supports what is known as Vehicle Lifecycle Management (VLM) or CI / CD pipelines (Continuous Integration / Continuous Deployment pipelines). Data (such as scenarios, configurations, models, Soft ECUs, digital twins, etc.) is loaded from or returned to these processes (e.g., test and simulation results). The core services of the simulation platform include: Simulator Orchestrierung, Interface Router, Communication Functionality, Synchronization, and a Timing Watchdog for identifying timeouts. The interface connects to different "in-the-loop" environments (XIL, MIL, SIL, PIL, HIL, DIL, VIL) at the Execution Layer and is used for test configuration and control at the Application Layer.

[0065] Figure 8 This section presents a metamodel for configuring the communication model (CommunicationConfiguration). A dataset (BulkDataltem, BulkDataInstance) is specified here, which is associated with a specific topic within the scope of publish-subscribe communication. The code for this communication is... Figure 9 As shown in the image.

[0066] Figure 10 The diagram illustrates the communication between the models running on the real-time simulator (SCALEXIO_001) and the non-real-time simulator (VEOS_001), which is conducted via the RTPS protocol using DDS.

Claims

1. A method for configuring real-time and / or non-real-time simulators (RT Simulator #1, RT Simulator #2, and non-RTSimulator) to execute different simulation programs within a common simulation environment using a simulation platform, wherein, The simulation platform has an interface with a data repository, which contains configuration information about the corresponding simulator, wherein... In the first step (component linking), different simulation artifacts are provided in the form of simulation models and meta-descriptions and / or configuration information for the simulation models, and the meta-descriptions are used to create a description of the entire system with logical connections (system description) for the simulation of the entire system. In the second step (2-component deployment), information about the simulator is provided, and the simulation model is assigned to each simulator in the deployment description according to the simulation requirements. In the third step (3. Simulator-specific configuration), executables and application descriptions are generated for the simulation model using information about each simulator contained in the data repository, or this information is provided by the corresponding simulator. In the fourth step (4. Simulation System Generation), a communication configuration is created according to the given simulation platform communication protocol, which includes an executable program and application description specific to the simulator. The communication configuration is used to configure a SimAgent for the corresponding simulator. In step 5 (5 Deployment on the simulator), the corresponding simulation agent (SimAgent) is configured on the simulators (RT Simulator #1, RTSimulator #2, and non-RT Simulator) according to the communication configuration for the simulation of the entire system. This allows the simulation of the entire system to be established through collaborative simulation using different simulators (RT Simulator #1, RT Simulator #2, and non-RT Simulator). For each step, there exists a rule set consisting of a set of verification rules. At the beginning of the step, multiple simulated artifacts and configuration artifacts used in the step are checked according to the rule set. After each step is executed, the correctness and consistency of multiple simulated artifacts and configuration artifacts created in the step are automatically checked. If a rule violation is detected, at least one warning is issued.

2. The method according to claim 1, wherein, The simulation platform has an interface with the corresponding simulator (RT Simulator #1, RT Simulator #2, non-RT Simulator), through which it can connect not only to real controllers but also to virtual controllers, and the simulation platform has an interface with testing and / or monitoring tools.

3. The method according to claim 2, wherein, The simulation of the entire system is used to test the controller, and the test is initiated after step five by synchronously simulating the entire system using the appropriate simulator.

4. The method according to any one of the preceding claims, wherein, The SimAgent is provided by a software program on the corresponding emulator and manages different services of the emulator and transmits corresponding signals and data via an interface.

5. The method according to any one of the preceding claims, wherein, The simulation model is given by the functional model, especially the Simulink model, FMU or virtual controller.

6. The method according to any one of the preceding claims, wherein, In the fourth step (4 Simulation system generation), for communication between simulators, the signals defined in the communication configuration are grouped such that redundancy is avoided when exchanging messages and the data of the signals changes substantially simultaneously.

7. The method according to any one of the preceding claims, wherein, The communication protocol of the simulation platform is given through a publish-subscribe protocol, and in particular through an RTPS protocol in the case of using DDS.

8. The method according to claims 6 and 7, wherein, In step 4 (4 Simulation System Generation), specific topics for publish-subscribe communication are created for a specific set (Bulk) of signals defined in the communication configuration, so that simulators (RT Simulator #1, RT Simulator #2, and non-RT Simulator) that handle these specific signals can register to the corresponding topics in order to obtain the desired signals.

9. The method according to any one of the preceding claims, wherein, Each simulator (RT Simulator #1, RTSimulator #2, and non-RT Simulator) has at least two interfaces with the simulation platform, allowing data flow for simulating the entire model to be transmitted through one interface and status or control signals to the test tool through a second interface.

10. The method according to any one of the preceding claims, wherein, The rule set is stored in a storage area accessible to the simulation platform, and the rule set can be changed, and in particular, expanded.

11. The method according to any one of the preceding claims, wherein, At least one emulator (non-RT emulator) runs in a virtual machine (VM) or container and said virtual machine or container is implemented in the cloud and at least one configuration tool required in step 3 runs in said virtual machine or container.

12. A simulation platform for performing the method according to any one of the preceding claims, wherein, The simulation platform has at least one program for configuring different simulators (RT Simulator #1, RT Simulator #2, and non-RTSimulator) for collaborative simulation, as well as corresponding service programs for simulator synchronization, simulator orchestration, user and access management, communication, and application management, and services for processing data and simulation artifacts. The simulation platform also has interfaces with testing tools and interfaces with simulators.

13. The simulation platform according to claim 12, wherein, The simulation platform and its corresponding programs are deployed in the cloud, on at least one local computer, or distributed across the cloud and the at least one computer.

Images