Definition 11-3: Language component
13.2 Interaction of Different Simulations
13.2 Interaction of Different Simulations 271
together to provide the functionality of the system under test (SUT) within its context. These include:
Environment models (e.g., city with streets and collaborative traffic lights)
Behavior models (e.g., CACC, platooning control)
Sensor models (e.g., distance sensor)
Dynamic models (e.g., vehicle physics)
Models for the timing behavior of the execution platforms, the implementation, and the communication
CES/CSG interface models
Communication models (e.g., wireless car communication)
Uncertainty models (e.g., sensor and communication uncertainty) All these models must be interoperable to enable information exchange and time-synchronized execution. Each simulation tool can execute one or multiple of the models listed.
Let us consider the vehicle platooning use case by way of explanation. A platoon is a collaborative vehicle convoy that uses car- to-car communication based on ad-hoc networks for collaboration.
The system that will be used for the platoon control is called Collaborative Adaptive Cruise Control (CACC). This system enables the distance between vehicles to be reduced. The vehicles following the lead vehicle use the data transferred to calculate their relative acceleration.
The simulation of complete scenarios can be realized by a co- simulation of different tools and model. While these building blocks apply to CESs and CSGs in general, the concrete types of environment and physics models are typically specific to the use case. To evaluate the behavior of the co-simulation participants, it is important that co- simulation results can be reproduced reliably. In general, there is a set of scenarios that are used repeatedly to compare the results of different co-simulations. Since many embedded systems operate in a safety-critical environment, test scenarios might also be prescribed by safety standards. The scenarios and the focus of the analysis will determine which simulated component parts are necessary to meet the test goals. Only some parts of the functional behavior of the target systems need to be included in the specific co-simulation execution and therefore in the underlying models. Other parts can be either substituted (for example, the pre-processing of sensor data) or omitted entirely if they are not needed for the test execution. The selected level of detail for the different model parts will also depend on the test goals. For parts developed by suppliers, the level of detail
Platooning use case
Analysis
available for the simulation models can also be limited. More abstract models will increase the test performance and allow test and validation in earlier phases of the development process. On the other hand, the significance and the quality of the test results can be limited for abstract models.
The first building block in Figure 13-1 includes tools capable of simulating the context and environment of the systems under test (SUT), such as the roads on which the vehicles are driving and the interfering traffic. For the example use case, the simulation must cover the individual vehicles of the platoon with their specific movements and distances to each other. It should provide input sensor information from the viewpoint of the systems, such as generated camera images or radar vectors; alternatively, depending on the goal of the simulation and the available or desired degree of detail, the simulation should provide pre-processed data such as distances to objects.
An ad-hoc approach is to use simple step-by-step instructions that give the exact sequence of events in simulation scenarios. However, in a co-simulation with numerous simulation models and simulators interacting with each other, this approach is not very well suited to modeling parallel events that might occur. Another common approach is to use statecharts that are more suited for modeling the interaction and collaboration of the models involved (Section 5.2). Tools that support statecharts for test modeling include the YAKINDU Statechart Tools (YSCT) [Yakindu 2020] and Time Partition Testing (TPT) [PikeTec 2020].
Interactive 3D co-simulations support rapid prototyping scenarios for the development of CESs and CSGs. Therefore, the CESs and CSGs are visualized directly within their environment and interactive changes of system behavior models, as well as environment models, are supported in real time. CARLA [Carla 2020] is a vehicle and
Environment simulation
timing
function
YAKINDU Statechart Tools .c.c
C++ code
co-simulation platform MESSINA implementationcustom
environment
YAKINDU Statechar t Tools
physics
Fig. 13-1: Co-simulation model platforms and tools
13.2 Interaction of Different Simulations 273
environment simulator tailored for evaluating automated driving functions and therefore especially addresses the vehicle platooning use case. It visualizes the environment, the vehicles and their movements, and the complete traffic scenarios based on Unreal Engine [Unreal 2020]. The view of the environment can be captured by multiple sensors attached to different vehicles. The behavior of vehicles can be influenced and set from other simulation tools. CARLA supports interactive changes to objects of the virtual world in real time to create various scenarios and directly visualize the impact on CESs and CSGs in these varying contexts.
The functional behavior of the CSG can be modeled and simulated with various approaches. MATLAB/Simulink [MathWorks 2020]
provides the ability to model and simulate many functions based on sensor, image, or radar data processing. Toolboxes for image processing and autonomous driving functions are available. An exchange with other simulation tools can be provided using co- simulation toolboxes such as the Functional Mock-up Interface (FMI) slave interface. For other scenarios, especially for decision algorithms, modeling the behavior with one or a set of statecharts can be a more suitable approach, and this can be simulated with the YAKINDU Statechart Tools, for example. Another possibility is to include either implemented or generated target code (for example, in C++) in the co- simulation.
Special simulation tools, such as chronSIM [INCHRON 2020a], augment the co-simulation by incorporating the timing behavior of the software, the execution platforms, the scheduling effects, and the communication between and within systems. In particular, timing effects and delays of the complete event chain, from the sensors, through the processing, to the actuators are derived (see Figure 13- 2). The timing simulation replicates the timing of CESs implementing the CSG. Based on the models of the systems and the software, the simulator calculates resulting delays, end-to-end delays for the data processing, as well as potential data losses and more.
Functional simulation
Timing simulation
Uncertainties resulting from the data propagation, also in wireless communication networks, are therefore incorporated in the overall simulation. Additional uncertainties are part of other models and can arise from inaccurate sensor measurement and processing of sensor data, which should be reflected by the overall simulation. Fault tolerance of the system under test (SUT) with respect to context changes can be considered with predefined configuration parameters for the tool platform, such as typical uncertainty distributions.
Therefore, multiple varying configurations could be derived (semi- automatically) from rule sets or automata [PikeTec 2020b] defined in test and scenario models.
Another relevant aspect is the physical, dynamic model of CESs.
For the vehicle platooning and autonomous transport robots use cases, for example, the speed reduction by braking under various conditions, the steering capabilities for trajectory planning, and so on are part of these models. There are multiple solutions available with various levels of complexity and accuracy. Again, MATLAB/Simulink provides solutions and CARLA also includes a simplified dynamic model.
The simulation of the physics and environment, together with other co-simulation participants, must be executed in a time- synchronized fashion. Usually, 3D visualization and physics engines have their own timing and try to update the environment for rendering new images as quickly as possible to provide a real-time visualization. The joint execution of the simulation models and tools involved requires a co-simulation platform. Examples are MESSINA
Physical dynamic simulation
Co-simulation platforms
Fig. 13-2: An event chain in the timing simulator chronSIM