WP6-26
Introduction
| ID | WP6- |
| Contributor | UNICAN |
| Levels | Tool, Platform |
| Require | Linux, C/C++ code |
| Provide | Timing/Energy Co-Simulation |
| Input | Platform model |
| Output | Functional and time performance validation |
| C4D tooling | n.a. |
| TRL |
SoSIM is a new System-of-Systems Simulation tool developed in Comp4Drones. Its background technology is VIPPE. From the Single-Source System Design (S3D) model, the specific information required to perform a certain simulation and performance analysis task (e.g. performance simulation of a solution in a design-space exploration) is extracted and the corresponding simulation model, synthesized. This Model-to-Model generation is performed by the mSSYN tool.
In order to extend SoSIM to mechatronic systems, several improvements have been carried out. The basic infrastructure allowing to simulate multiple drones and combining different levels for the different system components including ROS was described in [1]. The architecture of the complete simulation environment is shown in Figure 1. The arrows represent the control flow in the simulator. Depending on the simulation level, some of the functional blocks may be inactive. So, at the functional level ROS is not used. Thus, neither the ROS core and the MAVROS block, nor the Sync.Clock ROS node are required. The functional drone simulator (now to be extended to several drones) interacts directly with the ROScpp components. This is kept even when the ROS core is included. The synchronization clock will also be needed. Only when any of the drones is modeled with a detailed autopilot and physics, the MAVROS block is added in order to support the communication with the drone through MAVLink.
Detailed Description
SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:
- System Design
- Mechanical Analysis and Design
- IT Analysis and Design
- SW Analysis and Design
- HW Analysis and Design
- SW Detailed Design
- SW Component Verification
- SW Integration and Verification
- HW Integration and Verification
- IT Integration and Verification
- Mechanic Integration and Verification
- System Integration and Verification
- System Acceptance Verification
The improvement provided by SoSIM comes from the fact that the use of virtual models of the system simplifies simulation-based DSE, which greatly reduces the time required to select the most appropriate solution [2]. However, as the information about the system and its components evolve along the design process, so should their models and, in general, the infrastructure required for their simulation. As a result, different simulation levels must be considered during the different steps of the design and verification process. Table 1 shows the four simulation levels considered for the functional components:
Table 1 - Abstraction levels for functional components simulation
| Level | Code | Timing/Energy | ROS MW |
|---|---|---|---|
| MN | minimal | no | yes/no |
| MC | minimal | constant | |
| FC | full code | constant | |
| FD | full code | data dependent |
In MN (minimal/no), no model of time/energy is provided so that the code is supposed to be executed infinitely fast and without consuming any energy. In MC (minimal/constant) and FC (functional/constant), a constant time/energy is assumed each time the function is executed. These can be estimated or observed worst-case, mean-case or best case figures. In FC, the simulation time would be higher than in MC, as the actual code is executed. In the FD (functional/data dependent) model, both time and energy must be estimated over the actual code, using a state of the art technique, such as native simulation technology or binary translation.
Additionally, not all the system components need to have the same level of detail in a single simulation. Different system components can require simulation at different abstraction levels, resulting in heterogeneous simulations, depending on the focus of each simulation. For example, components under development usually require the most accurate simulation level (FD) when verifying their correctness while library components may only require FC simulation.
This multi-level capability is also applicable to the simulation infrastructure. For example, in robotic-based systems considered in this paper, at any of these levels it should be possible to include in the simulation the ROS infrastructure or not. The latter case would allow designers to focus on the functionality of the distributed, heterogeneous functionality. Once this is verified, the former would include the actual ROS infrastructure in order to confirm that the application functionality behaves correctly when the actual communication middleware (MW) is included.
Regarding the simulation of the drones, four different models are considered. Let’s consider the command “move to X/Y/Z”. A minimal implementation will estimate the path and the movement time considering constant horizontal and vertical speed values, the power consumption, and will perform the movement in a single step (FN). In many cases, a more detailed model for the drone(s) is required. An autopilot and a physical simulator are needed.
