WP6-26: Difference between revisions
Line 24: | Line 24: | ||
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. | 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. | ||
[[File:wp6-26-I-01.png]] | [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]] | ||
== 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 |
Revision as of 15:45, 10 January 2023
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