Simulation platform and method for configuring real-time and non-real-time simulators for performing different simulation programs within a common simulation environment using the simulation platform

Abstract

The invention relates to a simulation platform and method for configuring real-time and non-real-time simulators for performing different simulation programs within a common simulation environment using a simulation platform for testing control devices, preferably from the automotive or aerospace sector.

Description

[0001] Simulation platform and method for

[0002] Configuration of real-time and non-real-time capable simulators for the execution of different simulation programs within a common simulation environment using the simulation platform

[0003] Simulation platform and method for configuring real-time and / or non-real-time capable simulators for executing different simulation programs within a common simulation environment using a simulation platform for testing control units, preferably from the automotive or aerospace sector.

[0004] Testing control units before their use in production vehicles is essential. However, the complexity of this process is constantly increasing, as the number of control units and their tasks in vehicles is growing, particularly for assisted driving and autonomous driving. Development tools are also widely available, and prototypes are at various stages of development. For example, a control unit may initially exist only as a software model (e.g., a Simulink model or, in a later stage, as a virtual control unit (VECU)), but should be tested in conjunction with a real control unit.

[0005] Several problems can arise, for example, the reuse of simulation artifacts (by which we mean simulation models, configuration files, etc.) may not be possible or desired. The simulation model may not be exportable from the simulator on which it originally ran; it may be compiled for a specific target processor. A user may have created their configuration files or simulation models for or with a specific tool and would like to continue using these. Combining different simulation artifacts to test ECUs by simulating an overall model is a complex and laborious task, as it requires a lot of manual configuration. It is made more difficult when some of the simulation artifacts exhibit real-time conditions while others do not. The use of real-time simulators is also expensive.

[0006] The object of the invention is to further develop the state of the art.

[0007] This object is achieved by a simulation platform according to the invention and a method for configuring real-time and non-real-time capable simulators

[0008] The simulation platform has interfaces to a data storage (i.e. a repository, a database or another suitable source) with configuration information (in particular regarding storage space, runtime, operating system, processor functionalities, synchronization properties, etc.) for the respective simulators.

[0009] In a first step, various simulation artifacts are provided in the form of 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 overall system with logical connections for simulating the overall system.

[0010] The meta descriptions are also used to ensure the overall quality of the subsequent simulation environment. The meta descriptions also track the maturity level or, if applicable, certification level of an input artifact. The simulation environment can then be used to certify a test if, among other things, all input artifacts exhibit the required quality or certification level. 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 Bus Simulation Containers (BSCs)), and much more.

[0011] In a second step, information about the simulators is provided (whereby the simulators can be provided in the form of hardware or pure software simulators) and the simulation models are assigned to individual simulators in a deployment description based on simulation requirements (e.g. regarding memory space, runtime, operating system, processor functionalities, synchronization properties, real-time requirements,...).

[0012] In a third step, executable programs and application descriptions (i.e., binaries for execution and JSON files, XML or YAML files for descriptions) are generated for the simulation models using the information contained in the data repository for the individual simulators, whereby this information can also be provided by the respective simulator.

[0013] The executable programs are simulator-specific. If necessary, meta-information is also provided for these executable programs, which allows for optimizing communication and, if necessary, other parameters between the various simulators using simulator-specific (proprietary, unknown to the simulation platform) instructions.

[0014] In this step, the previously simulator-independently defined artifacts must be converted into configuration formats understandable by the target simulator, or specific executable models must be created. Furthermore, the simulator returns its own specific information and constraints to the overall process so that this information can be considered in the co-simulation.

[0015] This step makes it possible to support any input artifacts and any simulators. The simulator-specific aspects of converting the system-independent artifacts are abstracted and, above all, automated to the greatest extent possible. The user no longer needs to worry about the specifics of the respective simulators (e.g., the ConfigurationDesk configuration tool for dSPACE GmbH's SCALEXIO HIL systems and the VEOS Player configuration tool for dSPACE GmbH's VEOS offline simulator are automated for the configuration process).

[0016] In a fourth step, a communication configuration is created according to a given simulation platform communication protocol, incorporating the simulator-specific executable programs and application descriptions, whereby the communication configuration is used to configure simulation agents for the respective simulators.

[0017] Based on the individual simulator-specific configurations, the previously described connections in the system description, and the deployment, the final configuration of the simulation system can then be created (i.e., which simulator with which model sends which data via the platform protocol and when). This configuration is then distributed to the individual simulators.

[0018] In a fifth step, the respective simulation agents on the simulators are configured based on the communication configuration for the simulation of the overall system, so that the simulation of the overall system is set up by means of a co-simulation using the different simulators.

[0019] For each step, a rule set consisting of a set of validation rules (possibly as a script or program) is available. These rules are used to initially check at least a large number of, but ideally all, simulation artifacts and configuration artifacts used in the step. After each step has been executed, all simulation artifacts and configuration artifacts created in that step are automatically checked for correctness (regarding semantics, syntax, port connections, interfaces, etc.) and consistency. The rules of the rule sets can be customized by the user using a rule language.

[0020] At least one warning is issued when a rule violation is detected.

[0021] The method according to the invention enables a quasi-standardized, message-based data exchange for implementing 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. Through the uniform configuration, which describes how all simulators exchange data uniformly, in conjunction with a predetermined communication protocol (e.g., the Data Distribution Service (DDS) protocol), data can be exchanged arbitrarily between simulators, thus implementing co-simulation.

[0022] The minimum requirement for the simulators is that non-real-time simulators (such as the VEOS simulator from dSPACE GmbH) must also be able to calculate in quasi-real-time in order to participate in an overall simulation with real-time simulators (HIL simulators such as SCALEXIO from dSPACE). An alternative is to connect the non-real-time simulators via data-driven scheduling. Here, the real-time simulator sets the clock speed, while the non-real-time simulator(s) advance to the next clock cycle as soon as they have all the required inputs. An alternative embodiment is loose coupling with unsynchronized clocks. This can be used whenever the clock rate of the applications on the non-real-time simulator is considerably higher than that of the real-time simulator (e.g. 10 ps real-time and 10 ms non-real-time). All of these embodiments can occur simultaneously in a simulation environment.

[0023] The configuration process according to the invention enables the coupling of the real-time simulators and non-real-time simulators by ensuring that all steps support the generation of a stable simulation system, for example, by creating the deployment in such a way that sufficient performance buffers are available on all simulators and that communication is carried out in such a way that data is always available on the corresponding simulator in a timely manner (e.g., by grouping data / signals, co-simulation algorithms, etc.).

[0024] After each configuration step, previously specified checks are performed using a mechanism. Based on the respective step, artifacts (i.e., files or programs created in a step) can be specifically checked for consistency. Specific checks are performed according to formal criteria and the specific requirements of the respective simulators. They are defined by the rule set. For example, a check is performed to determine whether the AUTOSAR syntax of an AUTOSAR file is correct or whether a model also corresponds to the attached metamodel. Logical connections and port connections are also checked. Such quality checks enable meaningful automation of the configuration process.

[0025] The simulation platform features interfaces to the respective simulators, allowing the integration of both real and virtual control units. Furthermore, the simulation platform features interfaces to test and monitoring tools, such as tools for parameterizing the simulation and displaying signals. Thus, the simulation platform serves as a test and integration platform.

[0026] Preferably, the simulation of the entire system is used to test control units, whereby after the fifth step the test is started by synchronous simulation of the entire system using the respective simulators.

[0027] Thanks to the ability to co-simulate different simulation programs, a system of ECUs can be tested even when the ECUs are still at different stages of development. For example, some ECUs exist only in the form of a virtual ECU, i.e., only in software. Simulation of the ECU environment, for example, using Simulink models, can also be easily integrated.

[0028] Preferably, the simulation agents are provided by software programs hosted on the respective simulators. The simulation agents manage various simulator services and transmit corresponding signals and data via interfaces. Through their interfaces, they enable these data and signals to be transmitted to other simulation agents in the system according to a protocol defined for the simulation platform.

[0029] Simulation models here are provided by functional models, especially Simulink models, FMUs, or virtual control units. This is an example. In principle, this refers to any model that represents the calculation rules for a process to be simulated.

[0030] In one embodiment, in step 4, for communication between the simulators, the signals defined in the communication configuration are grouped in such a way that the exchange via message packets is as effective and consistent as possible, thus avoiding redundancies and ensuring that the signal data changes essentially simultaneously, making them temporally up-to-date and consistent. This is done using appropriate information from the corresponding configuration artifacts.

[0031] In general, configuration artifacts refer to artifacts / files that arise during the configuration process and are generated or manually created in stages, starting with the logical connection of individual artifacts, through the distribution (deployment) of the models to the simulators and the generation of simulator-specific configuration and simulation models, to downloading them to the target platform (the simulator). Artifacts such as communication matrices, FMUs, Simulink models, etc., serve as input artifacts in the configuration process. Input artifacts, as well as intermediate results generated during the process, are checked for errors at an early stage using quality checks / quality gates.

[0032] Preferably, the simulation platform communication protocol is provided by a publish-subscribe protocol, in particular by the Real-Time Publish-Subscribe (RTPS) protocol using DDS.

[0033] Based on the deployment description and the description of the overall system, the protocol is implemented in the configuration process according to the invention by including the corresponding information and instructions in the application description and in the communication configuration for the simulation agents.

[0034] In one embodiment, in step 4, on the basis of the signals defined in the communication configuration, specific topics are created for the publish-subscribe communication with respect to specific sets of signals, so that the simulators that process these specific signals can register on the corresponding topics in order to receive the required signals.

[0035] With the help of such topics, communication between the simulators can be implemented efficiently.

[0036] Preferably, each simulator has at least two interfaces to the simulation platform, so that the data traffic for the simulation of the entire model can be transmitted via one interface and a status or control signal to a test tool via the second interface.

[0037] In one embodiment, the rule set is stored in a memory area accessible to the simulation platform, and the rule set is modifiable, particularly extensible. Thus, a user can use a rule language to specify which quality checks or checks should be performed prior to the simulation.

[0038] Preferably, at least one simulator runs in a virtual machine (VM) or a container, wherein the virtual machine or the container is executed in a cloud and wherein at least one of the configuration tools required in step 3 (ie a program for configuring the simulators or at least a part of such a program) runs in the virtual machine or the container.

[0039] Furthermore, the object is achieved by a simulation platform according to the invention for carrying out the method according to the invention.

[0040] In one embodiment, the simulation platform with its corresponding programs is maintained in a cloud, on at least one local computer, or distributed across the cloud and the at least one computer.

[0041] The invention is explained in more detail below with reference to the drawings, in which:

[0042] Figure 1 is a schematic view of a control unit test setup with a simulation platform according to the invention,

[0043] Figure 2 shows a schematic flow of the method according to the invention with quality check for each process step (1, 2, 3, 4, 5)

[0044] Figure 3 an overview of artifacts of the process Figure 4 a schematic representation of the relationships between steps 3 and 5

[0045] Figure 5 shows a schematic representation of the simulation agents (SimAgent)

[0046] Figure 6 is a schematic view of the structure of an interface of the simulation platform according to the invention with the corresponding protocols for the communication platform

[0047] Figure 7 shows a schematic structure of the simulation platform and its interfaces

[0048] Figure 8 a meta-model for the configuration of the communication model

[0049] Figure 9 Code for the communication according to the meta-model from Figure 8

[0050] Figure 10 shows a representation of communication via the RTPS protocol between a model running on a real-time simulator (Scalexio) and a model running on a non-real-time simulator (VEOS). Figure 1 shows a schematic view of an ECU test setup with a simulation platform according to the invention. Data is exchanged (for real-time data: signals and variables; for virtual buses: messages in raw format; and, if necessary, data injection / manipulation) between the simulators (both the real-time (RT) simulators (RT Simulator #1, RT Simulator #2) and the non-real-time simulators (Non-RT Simulator)), the test tools (Test & Experiment (e.g., ControlDesk), Monitoring & Control), and the data storage (Repo, or DB) via the simulation platform or the protocols defined for the simulation platform and an integration layer.Real control units for testing are connected to the real-time simulators via real bus connections (real bus, CAN, LIN). These can also be connected to the RT simulators via other technologies, such as automotive Ethernet. Status monitoring and test control (including charging configuration) are also managed via the simulation platform.

[0051] Figure 2 shows a schematic flow of the method according to the invention with a quality check 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 fed into the simulation platform (usually by a user, i.e., manually). These simulation artifacts are checked, preferably all of them, according to predefined rules, and subsequently a description of the overall system (system description) and, if necessary, further artifacts are created. The meta descriptions are used, for example, to create logical connections / links. Any further artifacts created are also checked, preferably all of them, for quality and consistency. The second step (2 component deployment) is then carried out on the basis of the description of the overall system (system description).In the second step, all incoming artifacts are reviewed at the beginning, if possible; the system description is also reviewed again. For example, additional artifacts with information can be added to the process, such as global I / O information. In this second step, the deployment description is generated, which determines the distribution of the models among the individual simulators based on the requirements in the system description. Simulator allocation is preferably automated. However, manual addition of simulators is also possible. The same applies to assigning components / simulation artifacts to the respective simulators.

[0052] In the third step (3 Simulator-specific configuration), which also involves checking as many incoming and outgoing artifacts as possible at the input and output, simulator-specific information and restrictions (constraints, e.g., regarding communication, synchronization, etc.) are also included, which therefore also depend on the simulator manufacturer. It is particularly important here that the rule set is adaptable and extensible so that a wide variety of simulators can be included in the process. The result of the third step is application descriptions and executable files, i.e., binaries (executables). The executable files are usually system-dependent, i.e., compiled for a specific simulator. This process is preferably automated using vendor-specific tools.

[0053] In the fourth step (4 Simulation System Creation), all input and output artifacts for this step are collected and reviewed again. The result of this step is essentially the communication configurations of simulation agents (SimAgentConfig). Using the simulator-specific artifacts, the communication of the individual simulators is defined via the uniform platform communication protocol and encoded in a corresponding configuration file or similar (SimAgentConfiguration).

[0054] These configuration files (=communication configurations) are collected in step 5 (5 Deployment to Simulators (SimAgents)) and loaded onto the respective simulators. This step also includes an initial quality check. After configuring the simulators or simulation agents, the simulation of the entire system can be started.

[0055] Figure 3 shows an overview of the artifacts of the procedure.

[0056] The file formats define, in a sense, the interfaces between the configuration steps. The simulation platform defines these formats using existing open standards, such as SSP (System Structure & Parameterization: https: / / ssp-tandard.org / ) or MIC (Model Identity Card: https: / / mic.irt-systemx.fr / mic), or by (possibly additionally) using new, open descriptions (quasi-standards).

[0057] Figure 4 shows a schematic representation of the relationships between steps 3 and 5 and illustrates that simulation artifacts from one step can be used in another step by referencing (Ref).

[0058] In the third step (3 Simulator-specific configuration), simulator-specific configuration tools are provided that support the inputs and outputs defined via the platform and can be automated.

[0059] In the fifth step (5 Deployment on Simulators), simulation agents (SimAgents) are deployed and configured, which represent the simulators and provide interfaces defined by the platform for the exchange of data and commands.

[0060] Figure 5 illustrates the tasks of the simulation agents (SimAgent). They essentially consist of a program hosted on the respective simulator, which enables the simulator to execute its simulation tasks (programs). In particular, the simulation agent enables management, synchronization, and communication via the simulation protocol standardized on the simulation platform. Furthermore, the simulation agents provide services such as co-simulation / multiprocessor simulation, data logging, synchronized times, simulation application and control, sensor simulation data, playback of recorded data, error recording, status monitoring, real-time testing, and much more.

[0061] The simulation agent (SimAgent) shown provides interfaces, e.g. to other simulation agents or directly to real hardware such as a bus system (see Figure 1).

[0062] Figure 6 shows a schematic view of the structure of an interface of the simulation platform according to the invention with the corresponding protocols for the communication platform. Enlarged here, a connection of a real-time simulator (RT Simulator #1) from Figure 1 to the simulation platform is shown. It can be seen that this connection actually consists of two interfaces, one of which is reserved for data exchange with the application (the simulation program or model), with communication taking place via the RTPS protocol using DDS (Data Distribution Service). Communication with the test tools takes place via a REST (Representational State Transfer) interface.

[0063] Optionally, additional APIs (platform APIs) are also offered here. Based on the platform's protocol stack, it is possible to offer such an interface (application programming interface (API)) in a variety of forms or for different providers.

[0064] Figure 7 shows a schematic structure of the simulation platform and its interfaces (platform interfaces) on the various communication layers. The simulation platform is used to support the so-called Vehicle Lifecycle Management (VLM) or the CI / CD pipeline (Continuous Integration / Continuous Deployment Pipeline). Data is uploaded from these processes (scenarios, configurations, models, soft ECUs, digital twins, etc.) or returned to these processes (e.g., test and simulation results). The core services of the simulation platform are simulator orchestration (simulator orchestration), interface routing (interface router), the communication functions (communication), synchronization (synchronization), and a timing watchdog (timing watchdog) for detecting timeouts.The interfaces are located on the one hand in the execution layer with the various "in-the-loop" environments (XIL, MIL, SIL, PIL, HIL, DIL, VIL) and on the other hand in the application layer for configuring and controlling the tests.

[0065] Figure 8 shows a metamodel for the communication configuration. Here, a data set (BulkDataItem, BulkDataInstance) is specified, which is linked to a specific topic as part of a publish-subscribe communication. The code for this communication is shown in Figure 9.

[0066] Figure 10 shows the communication between models, one running on a real-time simulator (SCALEXIO_001) and one on a non-real-time simulator (VEOS_001), using DDS over the RTPS protocol.

Claims

Patent claims:

1. Method for configuring real-time and / or non-real-time capable simulators (RT Simulator #1, RT Simulator #2, Non-RT Simulator) for executing different simulation programs within a common simulation environment using a simulation platform, wherein the simulation platform has interfaces to a data repository with configuration information for the respective simulators, wherein in a first step (1 component linking), different simulation artifacts in the form of simulation models and meta-descriptions and / or configuration information for the simulation models are made available and wherein the meta-descriptions are used to create a description of the overall system (system description) with logical connections for the simulation of the overall system,wherein in a second step (2 component deployment) information about the simulators is made available and wherein the simulation models are assigned to individual simulators in a deployment description based on simulation requirements, wherein in a third step (3 simulator-specific configuration) executable programs and application descriptions for the simulation models are generated using the information on the individual simulators contained in the data storage or wherein this information is made available by the respective simulator, wherein in a fourth step (4 simulation system generation) a communication configuration is created according to a given simulation platform communication protocol, wherein the simulator-specific executable programs and, Application descriptions are included, whereby the communication configuration is used to configure simulation agents (SimAgents) for the respective simulators, whereby in a fifth step (5 Deployment on Simulators), the respective simulation agents (SimAgents) on the simulators (RT Simulator #1, RT Simulator #2, Non-RT Simulator) are configured based on the communication configuration for the simulation of the overall system, so that the simulation of the overall system is set up by means of a co-simulation using the different simulators (RT Simulator #1, RT Simulator #2, Non-RT Simulator), whereby for each step there is a rule set consisting of a set of validation rules,by means of which a majority of the simulation artifacts and configuration artifacts used in the step are initially checked and, after the execution of each step, a majority of the simulation artifacts and configuration artifacts created in this step are automatically checked for correctness and consistency, and at least one warning is issued if a rule violation is detected.

2. The method according to claim 1, wherein the simulation platform has interfaces to the respective simulators (RT Simulator #1, RT Simulator #2, non-RT Simulator), via which both real and virtual control units can be integrated, and has interfaces to test and / or monitoring tools.

3. The method according to claim 2, wherein the simulation of the overall system serves to test control units and wherein after the fifth step the test is started by synchronous simulation of the overall system using the respective simulators.

4. Method according to one of the preceding claims, wherein the Simulation agents (SimAgent) given by software programs which are stored on the respective simulators and where the simulation agents (SimAgent) manage various services of the simulators and pass on corresponding signals and data via interfaces.

5. Method according to one of the preceding claims, wherein simulation models are given by functional models, in particular Simulink models, FMUs or virtual control units.

6. Method according to one of the preceding claims, wherein in the fourth step (4 simulation system generation) for the communication between the simulators, the signals defined in the communication configuration are grouped in such a way that redundancies are avoided during the exchange by means of message packets and the data of the signals change substantially simultaneously.

7. Method according to one of the preceding claims, wherein the simulation platform communication protocol is provided by a publish-subscribe protocol, in particular by the RTPS protocol using DDS.

8. The method according to claims 6 and 7, wherein in step 4 (4 simulation system generation) on the basis of the signals defined in the communication configuration, specific topics for the publish-subscribe communication with respect to specific quantities (bulk) of signals are created, so that the simulators (RT Simulator #1, RT Simulator #2, non-RT Simulator) that process these specific signals can register on the corresponding topics in order to receive the required signals.

9. Method according to one of the preceding claims, wherein each simulator (RT Simulator #1, RT Simulator #2, Non-RT Simulator) has at least two interfaces to the simulation platform, so that the data traffic for the Simulation of the overall model is transmitted and via the second interface a status or control signal is sent to a test tool.

10. Method according to one of the preceding claims, wherein the rule set is stored in a memory area accessible to the simulation platform and wherein the rule set is changeable, in particular expandable.

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

12. Simulation platform for carrying out the method according to one of the preceding claims, wherein the simulation platform has at least one program for configuring different simulators (RT Simulator #1, RT Simulator #2, non-RT Simulator) for co-simulation as well as corresponding service programs for synchronizing the simulators, orchestrating the simulators, user and access management, communication, managing the application programs as well as services for handling the data and simulation artifacts and wherein the simulation platform has interfaces to test tools and interfaces to the simulators.

13. Simulation platform according to claim 12, wherein the simulation platform with its corresponding programs is maintained in a cloud, on at least one local computer or distributed between the cloud and the at least one computer.

Images