https://c4d.lias-lab.fr/api.php?action=feedcontributions&feedformat=atom&user=Raulgv 2026-04-07T01:07:06Z User contributions MediaWiki 1.37.1 https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=853 2023-02-17T10:08:39Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-25<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04, Eclipse EMF<br /> |-<br /> | Provide || System-of-Systems Modeling<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || XML system description &amp; functional code<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5-6<br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-26-D-01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> 1. System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems).<br /> <br /> 2. System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> <br /> 3. Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> <br /> 4. IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> <br /> 5&amp;7. SW Analysis &amp; Design and SW Detailed Design. During this stages, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> <br /> 6. HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> <br /> 8. SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> <br /> 9. SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> <br /> In the rest of stages:<br /> <br /> 10. SW Integration &amp; Verification.<br /> <br /> 11. HW Integration &amp; Verification.<br /> <br /> 12 Mechanical Integration &amp; Verification.<br /> <br /> 13. IT Integration &amp; Verification.<br /> <br /> 14. System Integration &amp; Verification.<br /> <br /> 15. System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=852 2023-02-17T10:05:52Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> [[File:wp6-26-D-01.png|frame|raight|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> 2. System Design<br /> <br /> 3. Mechanical Analysis and Design<br /> <br /> 4. IT Analysis and Design<br /> <br /> 5. SW Analysis and Design<br /> <br /> 6. HW Analysis and Design<br /> <br /> 7. SW Detailed Design<br /> <br /> 9. SW Component Verification<br /> <br /> 10. SW Integration and Verification<br /> <br /> 11. HW Integration and Verification<br /> <br /> 12. Mechanic Integration and Verification<br /> <br /> 13. IT Integration and Verification<br /> <br /> 14. System Integration and Verification<br /> <br /> 15. System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=851 2023-02-17T10:04:32Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> 2. System Design<br /> <br /> 3. Mechanical Analysis and Design<br /> <br /> 4. IT Analysis and Design<br /> <br /> 5. SW Analysis and Design<br /> <br /> 6. HW Analysis and Design<br /> <br /> 7. SW Detailed Design<br /> <br /> 9. SW Component Verification<br /> <br /> 10. SW Integration and Verification<br /> <br /> 11. HW Integration and Verification<br /> <br /> 12. Mechanic Integration and Verification<br /> <br /> 13. IT Integration and Verification<br /> <br /> 14. System Integration and Verification<br /> <br /> 15. System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=850 2023-02-17T09:19:31Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> 2. System Design<br /> <br /> 3. Mechanical Analysis and Design<br /> <br /> 4. IT Analysis and Design<br /> <br /> 5. SW Analysis and Design<br /> <br /> 6. HW Analysis and Design<br /> <br /> 7. SW Detailed Design<br /> <br /> 9. SW Component Verification<br /> <br /> 10. SW Integration and Verification<br /> <br /> 11. HW Integration and Verification<br /> <br /> 12. Mechanic Integration and Verification<br /> <br /> 13. IT Integration and Verification<br /> <br /> 14. System Integration and Verification<br /> <br /> 15. System Acceptance Verification<br /> <br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=849 2023-02-17T09:08:57Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-25<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04, Eclipse EMF<br /> |-<br /> | Provide || System-of-Systems Modeling<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || XML system description &amp; functional code<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5-6<br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-26-D-01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> 1. System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems).<br /> <br /> 2. System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> <br /> 3. Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> <br /> 4. IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> <br /> 5&amp;7. SW Analysis &amp; Design and SW Detailed Design. During this stages, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> <br /> 6. HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> <br /> 8. SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> <br /> 9. SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> <br /> 10. In the rest of stages:<br /> 1. SW Integration &amp; Verification.<br /> 2. HW Integration &amp; Verification.<br /> 3. IT Integration &amp; Verification.<br /> 4. Mechanical Integration &amp; Verification.<br /> 5. System Integration &amp; Verification.<br /> 6. System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=848 2023-02-17T08:48:33Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=847 2023-01-16T11:45:29Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-25<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04, Eclipse EMF<br /> |-<br /> | Provide || System-of-Systems Modeling<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || XML system description &amp; functional code<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5-6<br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-26-D-01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stages, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=846 2023-01-12T10:58:26Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-25<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04, Eclipse EMF<br /> |-<br /> | Provide || System-of-Systems Modeling<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || XML system description &amp; functional code<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5-6<br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-26-D-01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=845 2023-01-12T10:57:41Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=844 2023-01-12T08:27:21Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-25_DD_01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=843 2023-01-11T15:46:07Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-25<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04, Eclipse EMF<br /> |-<br /> | Provide || System-of-Systems Modeling<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || XML system description &amp; functional code<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5-6<br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=842 2023-01-11T15:45:44Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=841 2023-01-11T14:15:48Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-26<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04 LTE<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=840 2023-01-11T14:15:34Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-25<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04 LTE, Eclipse EMF<br /> |-<br /> | Provide || System-of-Systems Modeling<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || XML system description &amp; functional code<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5-6<br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=839 2023-01-11T14:14:12Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04 LTE<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || XML system description &amp; functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=838 2023-01-11T14:08:37Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04 LTE<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || 5<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=837 2023-01-11T14:06:58Z

<p>Raulgv: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux Ubuntu 18.04 LTE<br /> |-<br /> | Provide || Timing/Energy Simulation<br /> |-<br /> | Input || Platform Independent Model, Platform Description Model, Functional code<br /> |-<br /> | Output || Functional &amp; performance simulation results<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=Component_repository&diff=836 2023-01-11T13:59:25Z

<p>Raulgv: /* Components list */</p> <hr /> <div>This repository aims at providing common components usable in different application domains, in particular those covered by project use-cases.<br /> <br /> The requirements for using a components will be listed, as well as a documentation on how to use it. The component itself will be hosted by the partner who provides it.<br /> <br /> <br /> ==Components list==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |ID <br /> |Contributor <br /> |Title<br /> |-<br /> |[[WP3-01]]<br /> |IKERLAN<br /> |Safety function - Pre-Certified SOM<br /> |- <br /> |[[WP3-02]] <br /> |EDI <br /> |Modular SoC-based embedded reference architecture<br /> |- <br /> |[[WP3-03]]<br /> |BUT <br /> |Sensor information algorithms<br /> |- <br /> |[[WP3-04]] <br /> |HIB <br /> |Computer Vision Components for drones<br /> |- <br /> |[[WP3-10]] <br /> |IFAT <br /> |Component for trusted communication establishment<br /> |- <br /> |[[WP3-13]] <br /> |ENAC <br /> |Paparazzi UAV<br /> |- <br /> |[[WP3-14_1]] <br /> |ENSMA <br /> |Collision avoidance and geo-fencing<br /> |- <br /> |[[WP3-14_2]] <br /> |ENSMA <br /> |Distributed control of multi-drone system<br /> |- <br /> |[[WP3-15_1]] <br /> |ACORDE <br /> |UWB based indoor positioning<br /> |- <br /> |[[WP3-15_2]]<br /> |ACORDE <br /> |Multi-antenna GNSS/INS based navigation<br /> |- <br /> |[[WP3-16]] <br /> |SCALIAN <br /> |EZ_Chains Fleet Architecture<br /> |- <br /> |[[WP3-19_1]] <br /> |IMEC <br /> |Hyperspectral payload<br /> |- <br /> |[[WP3-19_2]] <br /> |IMEC <br /> |Hyperspectral image processing<br /> |- <br /> |[[WP3-20]] <br /> |MODIS <br /> |Multi-sensor positioning<br /> |- <br /> |[[WP3-22]] <br /> |UNIMORE <br /> |Onboard Compute Platform Desing Methodology<br /> |- <br /> |[[WP3-24]] <br /> |UNIVAQ <br /> |Efficient digital implementation of controllers<br /> |- <br /> |[[WP3-26]] <br /> |UWB <br /> |Droneport: an autonomous drone battery management system<br /> |- <br /> |[[WP3-28]] <br /> |UNISS <br /> |Accelerator Design Methodology for OOCP<br /> |- <br /> |[[WP3-36_1]] <br /> |UDANET <br /> |Smart and predictive energy management system<br /> |- <br /> |[[WP3-36_2]]<br /> |UDANET <br /> |AI drone system modules<br /> |- <br /> |[[WP3-37]] <br /> |Aitek <br /> |Video and data analytics<br /> |- <br /> |[[WP4-2]] <br /> |SCALIAN <br /> |EZ_Land Precision landing<br /> |- <br /> |[[WP4-5]] <br /> |SCALIAN <br /> |AI detection for clearance<br /> |- <br /> |[[WP4-07]] <br /> |ROT<br /> |Run-Time Safety Checker<br /> |- <br /> |[[WP4-10]] <br /> |ALM<br /> |Cooperative Planner<br /> |- <br /> |[[WP4-14]] <br /> |ALM<br /> |Map Enhancement Service<br /> |- <br /> |[[WP4-15]] <br /> |ALM<br /> |Visual Analytics<br /> |- <br /> |[[WP4-16]] <br /> |ACORDE<br /> |Enhanced Navigation Software<br /> |- <br /> |[[WP4-17]] <br /> |ACORDE<br /> |Anchor&amp;Tag firmware of the Indoor Positioning System <br /> |- <br /> |[[WP4-18_A]] <br /> |TEKNE <br /> |Drone-Rover Transponder<br /> |- <br /> |[[WP4-20]] <br /> |ALM<br /> |Attractor-based Navigation<br /> |- <br /> |[[WP4-22]] <br /> |ALM<br /> |Shared Reference Frame<br /> |- <br /> |[[WP4-32]] <br /> |SHERPA<br /> |Dynamic control development for navigation and precision landing<br /> |-<br /> |[[WP4-33]] <br /> |UNIVAQ <br /> |Autonomy, cooperation, and awareness<br /> |-<br /> |[[WP4-36]] <br /> |IMCS<br /> |Autonomous Decision Making in Critical Situations<br /> |-<br /> |[[WP4-37]] <br /> |IMCS<br /> |Algorithms for Runtime Safety Monitoring<br /> |- <br /> |[[WP4-39]] <br /> |HIB<br /> |Simulated data aggregator supporting intelligent decision in computer vision components<br /> |- <br /> |[[WP4-42]] <br /> |SCALIAN <br /> |AI Stabilization<br /> |- <br /> |[[WP5-02]] <br /> |IKERLAN<br /> |Security Management Toolchain<br /> |- <br /> |[[WP5-03]] <br /> |SCALIAN <br /> |EZ_Com Safe fleet communication<br /> |- <br /> |[[WP5-08]] <br /> |ROT<br /> |Lightweight Cryptography<br /> |- <br /> |[[WP5-09]] <br /> |ABI <br /> |Communication scheme for unified system management<br /> |- <br /> |[[WP5-05_A]] <br /> |TEKNE <br /> |LP-WAN for UAV identification and monitoring<br /> |- <br /> <br /> |[[WP5-11_ACO]] <br /> |ACORDE<br /> |Navigation system with anti-jamming and anti-spoofing features<br /> |- <br /> |[[WP5-16-AIT]] <br /> |AIT<br /> |Cryptographic algorithms adapted for drones<br /> |- <br /> |[[WP5-19_ACO]] <br /> |ACORDE<br /> |Robust communication for an improved Indoor Positioning System<br /> |- <br /> |[[WP6-P4R]] <br /> |CEA <br /> |Model driven engineering<br /> |- <br /> |[[WP6-20]]<br /> |ACORDE<br /> |ESL embedded SW Design Environment (ESDE)<br /> |- <br /> |[[WP6-21]] <br /> |ACORDE<br /> |Indoor Positioning System Modelling&amp;Analysis Framework (IPS-MAF)<br /> |- <br /> |[[WP6-17]] <br /> |UNIVAQ<br /> |HW/SW CO-DEsign of HEterogeneous Parallel dedicated SYstems (HEPSYCODE)<br /> |- <br /> |[[WP6-34]] <br /> |UNIVAQ<br /> |HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2)<br /> |-<br /> |[[WP6-25]]<br /> |UNICAN<br /> |S3D - Model-Driven Analysis and Design Framework<br /> |-<br /> |[[WP6-26]]<br /> |UNICAN<br /> |SoSIM - System-of-Systems Simulation &amp; Performance Analysis<br /> |}</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=835 2023-01-11T13:40:09Z

<p>Raulgv: /* References */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> ==References==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=834 2023-01-11T13:39:36Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]<br /> <br /> == References ==<br /> <br /> [1] J . Merino, R. Gomez, H. Posadas &amp; E. Villar: &quot;Multilevel host-compiled simulation framework for ROS-based UAV services using ArduCopter&quot;, proc. of the XXXVI Conference on Design of Circuits and Integrated Systems (DCIS), IEEE, 2021.<br /> <br /> [2] F. Herrera, J. Medina, E. Villar: &quot;Modeling Hardware/Software Embedded Systems with UML/MARTE: A Single-Source Design approach&quot;, in S. Ha and J. Teich (Eds): &quot;Handbook of Hardware/Software Codesign&quot;, Springer. 2017.<br /> <br /> [3] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, R. Valencia and G. Palermo. “The COMPLEX methodology for UML/MARTE Modeling and design space exploration of embedded systems”, Journal of Systems Architecture, V.60, I.1, 2014.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=833 2023-01-11T12:49:38Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables 1 and 2. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=832 2023-01-11T09:56:42Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> <br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=Component_repository&diff=831 2023-01-11T09:56:00Z

<p>Raulgv: /* Components list */</p> <hr /> <div>This repository aims at providing common components usable in different application domains, in particular those covered by project use-cases.<br /> <br /> The requirements for using a components will be listed, as well as a documentation on how to use it. The component itself will be hosted by the partner who provides it.<br /> <br /> <br /> ==Components list==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |ID <br /> |Contributor <br /> |Title<br /> |-<br /> |[[WP3-01]]<br /> |IKERLAN<br /> |Safety function - Pre-Certified SOM<br /> |- <br /> |[[WP3-02]] <br /> |EDI <br /> |Modular SoC-based embedded reference architecture<br /> |- <br /> |[[WP3-03]]<br /> |BUT <br /> |Sensor information algorithms<br /> |- <br /> |[[WP3-04]] <br /> |HIB <br /> |Computer Vision Components for drones<br /> |- <br /> |[[WP3-10]] <br /> |IFAT <br /> |Component for trusted communication establishment<br /> |- <br /> |[[WP3-13]] <br /> |ENAC <br /> |Paparazzi UAV<br /> |- <br /> |[[WP3-14_1]] <br /> |ENSMA <br /> |Collision avoidance and geo-fencing<br /> |- <br /> |[[WP3-14_2]] <br /> |ENSMA <br /> |Distributed control of multi-drone system<br /> |- <br /> |[[WP3-15_1]] <br /> |ACORDE <br /> |UWB based indoor positioning<br /> |- <br /> |[[WP3-15_2]]<br /> |ACORDE <br /> |Multi-antenna GNSS/INS based navigation<br /> |- <br /> |[[WP3-16]] <br /> |SCALIAN <br /> |EZ_Chains Fleet Architecture<br /> |- <br /> |[[WP3-19_1]] <br /> |IMEC <br /> |Hyperspectral payload<br /> |- <br /> |[[WP3-19_2]] <br /> |IMEC <br /> |Hyperspectral image processing<br /> |- <br /> |[[WP3-20]] <br /> |MODIS <br /> |Multi-sensor positioning<br /> |- <br /> |[[WP3-22]] <br /> |UNIMORE <br /> |Onboard Compute Platform Desing Methodology<br /> |- <br /> |[[WP3-24]] <br /> |UNIVAQ <br /> |Efficient digital implementation of controllers<br /> |- <br /> |[[WP3-26]] <br /> |UWB <br /> |Droneport: an autonomous drone battery management system<br /> |- <br /> |[[WP3-28]] <br /> |UNISS <br /> |Accelerator Design Methodology for OOCP<br /> |- <br /> |[[WP3-36_1]] <br /> |UDANET <br /> |Smart and predictive energy management system<br /> |- <br /> |[[WP3-36_2]]<br /> |UDANET <br /> |AI drone system modules<br /> |- <br /> |[[WP3-37]] <br /> |Aitek <br /> |Video and data analytics<br /> |- <br /> |[[WP4-2]] <br /> |SCALIAN <br /> |EZ_Land Precision landing<br /> |- <br /> |[[WP4-5]] <br /> |SCALIAN <br /> |AI detection for clearance<br /> |- <br /> |[[WP4-07]] <br /> |ROT<br /> |Run-Time Safety Checker<br /> |- <br /> |[[WP4-10]] <br /> |ALM<br /> |Cooperative Planner<br /> |- <br /> |[[WP4-14]] <br /> |ALM<br /> |Map Enhancement Service<br /> |- <br /> |[[WP4-15]] <br /> |ALM<br /> |Visual Analytics<br /> |- <br /> |[[WP4-16]] <br /> |ACORDE<br /> |Enhanced Navigation Software<br /> |- <br /> |[[WP4-17]] <br /> |ACORDE<br /> |Anchor&amp;Tag firmware of the Indoor Positioning System <br /> |- <br /> |[[WP4-18_A]] <br /> |TEKNE <br /> |Drone-Rover Transponder<br /> |- <br /> |[[WP4-20]] <br /> |ALM<br /> |Attractor-based Navigation<br /> |- <br /> |[[WP4-22]] <br /> |ALM<br /> |Shared Reference Frame<br /> |- <br /> |[[WP4-32]] <br /> |SHERPA<br /> |Dynamic control development for navigation and precision landing<br /> |-<br /> |[[WP4-33]] <br /> |UNIVAQ <br /> |Autonomy, cooperation, and awareness<br /> |-<br /> |[[WP4-36]] <br /> |IMCS<br /> |Autonomous Decision Making in Critical Situations<br /> |-<br /> |[[WP4-37]] <br /> |IMCS<br /> |Algorithms for Runtime Safety Monitoring<br /> |- <br /> |[[WP4-39]] <br /> |HIB<br /> |Simulated data aggregator supporting intelligent decision in computer vision components<br /> |- <br /> |[[WP4-42]] <br /> |SCALIAN <br /> |AI Stabilization<br /> |- <br /> |[[WP5-02]] <br /> |IKERLAN<br /> |Security Management Toolchain<br /> |- <br /> |[[WP5-03]] <br /> |SCALIAN <br /> |EZ_Com Safe fleet communication<br /> |- <br /> |[[WP5-08]] <br /> |ROT<br /> |Lightweight Cryptography<br /> |- <br /> |[[WP5-09]] <br /> |ABI <br /> |Communication scheme for unified system management<br /> |- <br /> |[[WP5-05_A]] <br /> |TEKNE <br /> |LP-WAN for UAV identification and monitoring<br /> |- <br /> <br /> |[[WP5-11_ACO]] <br /> |ACORDE<br /> |Navigation system with anti-jamming and anti-spoofing features<br /> |- <br /> |[[WP5-16-AIT]] <br /> |AIT<br /> |Cryptographic algorithms adapted for drones<br /> |- <br /> |[[WP5-19_ACO]] <br /> |ACORDE<br /> |Robust communication for an improved Indoor Positioning System<br /> |- <br /> |[[WP6-P4R]] <br /> |CEA <br /> |Model driven engineering<br /> |- <br /> |[[WP6-20]]<br /> |ACORDE<br /> |ESL embedded SW Design Environment (ESDE)<br /> |- <br /> |[[WP6-21]] <br /> |ACORDE<br /> |Indoor Positioning System Modelling&amp;Analysis Framework (IPS-MAF)<br /> |- <br /> |[[WP6-17]] <br /> |UNIVAQ<br /> |HW/SW CO-DEsign of HEterogeneous Parallel dedicated SYstems (HEPSYCODE)<br /> |- <br /> |[[WP6-34]] <br /> |UNIVAQ<br /> |HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2)<br /> |-<br /> |[[WP6-25]]<br /> |UNICAN<br /> |S3D - Model-Driven Analysis and Design Framework<br /> |-<br /> |[[WP6-26]]<br /> |UNICAN<br /> |SoSIM<br /> |}</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-26_IO_01.png&diff=830 2023-01-11T09:53:09Z

<p>Raulgv: Raulgv uploaded a new version of File:Wp6-26 IO 01.png</p> <hr /> <div>== Summary ==<br /> Interoperability of SoSim with other tools</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-26_IO_01.png&diff=829 2023-01-11T09:52:13Z

<p>Raulgv: Raulgv reverted File:Wp6-26 IO 01.png to an old version</p> <hr /> <div>== Summary ==<br /> Interoperability of SoSim with other tools</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-26_IO_01.png&diff=828 2023-01-11T09:51:32Z

<p>Raulgv: Raulgv uploaded a new version of File:Wp6-26 IO 01.png</p> <hr /> <div>== Summary ==<br /> Interoperability of SoSim with other tools</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-26_IO_01.png&diff=827 2023-01-11T08:51:27Z

<p>Raulgv: Interoperability of SoSim with other tools</p> <hr /> <div>== Summary ==<br /> Interoperability of SoSim with other tools</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=826 2023-01-11T08:49:42Z

<p>Raulgv: /* Interoperability with other C4D tools */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables I and II. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==<br /> <br /> From the S3D model, the Model to Model (M2M) tool mSSYN generates the simulation model to be executed by SoSIM. As S3D may contain models from other simulators, so S3D is linked to them. Figure 3 describes the interoperability between SoSim and other simulators:<br /> <br /> [[File:wp6-26_IO_01.png|frame|center| Figure 3 - Interoperability of SoSim with other tools]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=825 2023-01-11T08:47:10Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables I and II. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.<br /> <br /> == Interoperability with other C4D tools ==</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=824 2023-01-11T08:44:31Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}<br /> <br /> The simulation framework should support mixing functional and detailed simulation models for the drones in a multi-drone service. It should enable the system engineer to decide the best combination of abstraction levels in Tables I and II. Supporting multi-level simulation requires that each component in the functional architecture is associated with models at several abstraction levels, each involving different accuracy/speed ratios.<br /> <br /> Finally, it is mandatory to consider that drone based-systems usually involve multiple drones, and these drones can even require different simulation levels, in order to achieve high accuracy in some of the drone models while maintaining enough speed for the whole simulation.<br /> <br /> The new verification tasks introduced in the V-Cycle of Figure 2 are the following:<br /> <br /> # '''Validation''': The goal of the System Design, Mechanical Analysis and Design, IT Analysis and Design, SW Analysis and Design, HW Analysis and Design and SW Detailed Design is to ensure that the hierarchical partitioning of the system in sub-systems and finally, mechanical and HW and SW components, keeps the functional and non-functional requirements stated at the beginning of the design process. As the domain restrictions such as inputs, outputs, rates and throughputs are usually defined in the system requirements analysis steps, the full test-bench can be developed. The test-benches developed at the system, subsystem and component levels during design validation can be reused for component, sub-system and final system verification. The system-level test-bench can be also largely re-used for DSE and HW/SW co-design. The test-benches may also help during component, sub-system and system testing when the test-bench or part of it is emulated via SW-in-the-Loop (SIL). In order to be able to verify the test-bench at such a high level, a minimal functionality implementing the fundamental features of the system, subsystems and/or the components in the final full system architecture, should be developed (MN). This initial code can also be combined with preliminary, predefined time/energy figures in order to enable a first performance analysis of the system (MC). Regarding the drone(s), a functional model (FN) is the most appropriate. This functional simulation is useful during system requirement analysis and system architectural design and partitioning. After this initial stage, the components to be reused are selected and the components to be developed from scratch are fully specified so that their development (i.e. programming) can start, in case of HW/SW components. In the case of robots (i.e. the drones), their modelling, simulation and design can start. Reusability does not affect only application components but also components in the test-bench (e.g. the drones in the context of this paper).<br /> # '''Verification''': Once the complete code has been developed, SW Component Verification, SW Integration and Verification, HW Integration and Verification, IT Integration and Verification, Mechanic Integration and Verification and System Integration and Verification can be performed. By verification, functional and non-functional verification is meant. Simulating the full code allows functional verification and debugging. Performance analysis enables non-functional verification. Any error detected, would require code optimization, platform re-configuration, platform re-design or even, a new architectural mapping of functional components to HW resources. The advantage provided by the co-design approach is that these design decisions are made at the same stage and only in a few cases it is required to backtrack to a previous stage. Among the different valid solutions during this Design-Space Exploration (DSE), the most appropriate Pareto point is selected [3]. As drones are basically real-time systems, consideration of timing (and potentially, energy) is usually mandatory. However, timing analysis is not an easy and fast task. To solve it, two different levels are proposed. In the first one, the full code is simulated but annotated with constant figures for the time/energy it consumes (FC). In a second level, once the component is mapped to a computing resource, native simulation is used so that accurate figures for execution times and energy can be obtained (FD). Although this is not covered in the paper, more detailed models for the SW can be used as virtualization or even an ISS. These simulation technologies may provide higher accuracy than native simulation at a lower simulation speed. These verification steps finish when the virtual model is accepted in the System Acceptance Verification stage so that its implementation can start.<br /> # '''Testing''' is the new name we give to the former “HW-in-the-loop” verification steps as they require a physical prototype of the components, sub-systems and, finally, the complete system. Those components with potential reusability will be stored in the ‘Library of Components’.<br /> <br /> Once the system is fully designed and accepted, the system can be produced and deployed in the field. Now, the system operation can be monitored and analysed so that it is possible to facilitate maintenance, reduce faults and minimize correction time, when needed.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=823 2023-01-10T16:14:50Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]<br /> <br /> In this case, the full code (FC/FD) will generate all the signals to the motors required by the physical simulator to reach the final destination, including the estimation of all the intermediate positions, the actual time to reach them, the corresponding power consumption, angles and orientations.<br /> <br /> However, these two abstraction levels can be not enough for certain components. As commented above, S3D is based on a service-provided communication paradigm. However, ROS is mostly based on a client/subscriber approach. Thus, an approach based on services that performs the required operation in a single step, such as the one proposed above for the drone model, is not adequate, since publishers typically require a continuous flow of data. To solve this, and considering that the drone model is the most critical element in the simulation of drone-based systems, this work proposes a third, intermediate abstraction level for this component, capable of providing intermediate values to be published. Following the previous example, the command “move to X/Y/Z” will result in a continuous flow of approximate positions and orientations to be published. As a summary, the proposed drone model levels proposed are those shown in Table 2:<br /> {| class=&quot;wikitable&quot;<br /> |+Table 2 - Abstraction levels for the drone simulators<br /> !Level<br /> !|Drones modeling<br /> !|ROS MW<br /> |-<br /> |FY/FN<br /> |Functional<br /> |yes/no<br /> |-<br /> |AP<br /> |Autopilot<br /> |yes<br /> |-<br /> |MP<br /> |Multi-Physics<br /> |yes<br /> |}</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=822 2023-01-10T16:11:11Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> {| class=&quot;wikitable&quot;<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |+Table 1 - Abstraction levels for functional components simulation<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-26-D-01.png&diff=821 2023-01-10T16:06:16Z

<p>Raulgv: S3D-SoSIM V cycle coverage</p> <hr /> <div>== Summary ==<br /> S3D-SoSIM V cycle coverage</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=820 2023-01-10T16:05:16Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> Table 1 - Abstraction levels for functional components simulation<br /> {| class=&quot;wikitable&quot;<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> [[File:wp6-26-D-01.png|frame|center|Figure 2 - S3D-SoSIM V cycle coverage]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=819 2023-01-10T16:04:10Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> Table 1 - Abstraction levels for functional components simulation<br /> {| class=&quot;wikitable&quot;<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=818 2023-01-10T16:03:22Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> Table 1 - Abstraction levels for functional components simulation<br /> {| class=&quot;wikitable&quot;<br /> !Level<br /> !|Code<br /> !|Timing/Energy<br /> !|ROS MW<br /> |-<br /> |MN<br /> |minimal<br /> |no<br /> |rowspan=&quot;4&quot;|yes/no<br /> |-<br /> |MC<br /> |minimal<br /> |constant<br /> |-<br /> |FC<br /> |full code<br /> |constant<br /> |-<br /> |FD<br /> |full code<br /> |data dependent<br /> |}</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=817 2023-01-10T15:45:11Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png|frame|center|Figure 1 - VIPPE-ROS background simulation infrastructure]]<br /> <br /> == Detailed Description ==<br /> <br /> SoSIM covers the following states in the mechatronic V-Cycle of Figure 2:<br /> <br /> # System Design<br /> # Mechanical Analysis and Design<br /> # IT Analysis and Design<br /> # SW Analysis and Design<br /> # HW Analysis and Design<br /> # SW Detailed Design<br /> # SW Component Verification<br /> # SW Integration and Verification<br /> # HW Integration and Verification<br /> # IT Integration and Verification<br /> # Mechanic Integration and Verification<br /> # System Integration and Verification<br /> # System Acceptance Verification<br /> <br /> 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:<br /> <br /> Table 1 - Abstraction levels for functional components simulation</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-26-I-01.png&diff=816 2023-01-10T15:42:21Z

<p>Raulgv: VIPPE-ROS background simulation infrastructure</p> <hr /> <div>== Summary ==<br /> VIPPE-ROS background simulation infrastructure</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=815 2023-01-10T15:41:46Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> [[File:wp6-26-I-01.png]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-26&diff=814 2023-01-10T15:39:49Z

<p>Raulgv: Created page with &quot;== Introduction == {|class=&quot;wikitable&quot; | 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 || |}&quot;</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, C/C++ code<br /> |-<br /> | Provide || Timing/Energy Co-Simulation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Functional and time performance validation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=813 2023-01-10T15:33:10Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=Component_repository&diff=812 2023-01-10T14:54:24Z

<p>Raulgv: /* Components list */</p> <hr /> <div>This repository aims at providing common components usable in different application domains, in particular those covered by project use-cases.<br /> <br /> The requirements for using a components will be listed, as well as a documentation on how to use it. The component itself will be hosted by the partner who provides it.<br /> <br /> <br /> ==Components list==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |ID <br /> |Contributor <br /> |Title<br /> |-<br /> |[[WP3-01]]<br /> |IKERLAN<br /> |Safety function - Pre-Certified SOM<br /> |- <br /> |[[WP3-02]] <br /> |EDI <br /> |Modular SoC-based embedded reference architecture<br /> |- <br /> |[[WP3-03]]<br /> |BUT <br /> |Sensor information algorithms<br /> |- <br /> |[[WP3-04]] <br /> |HIB <br /> |Computer Vision Components for drones<br /> |- <br /> |[[WP3-10]] <br /> |IFAT <br /> |Component for trusted communication establishment<br /> |- <br /> |[[WP3-13]] <br /> |ENAC <br /> |Paparazzi UAV<br /> |- <br /> |[[WP3-14_1]] <br /> |ENSMA <br /> |Collision avoidance and geo-fencing<br /> |- <br /> |[[WP3-14_2]] <br /> |ENSMA <br /> |Distributed control of multi-drone system<br /> |- <br /> |[[WP3-15_1]] <br /> |ACORDE <br /> |UWB based indoor positioning<br /> |- <br /> |[[WP3-15_2]]<br /> |ACORDE <br /> |Multi-antenna GNSS/INS based navigation<br /> |- <br /> |[[WP3-16]] <br /> |SCALIAN <br /> |EZ_Chains Fleet Architecture<br /> |- <br /> |[[WP3-19_1]] <br /> |IMEC <br /> |Hyperspectral payload<br /> |- <br /> |[[WP3-19_2]] <br /> |IMEC <br /> |Hyperspectral image processing<br /> |- <br /> |[[WP3-20]] <br /> |MODIS <br /> |Multi-sensor positioning<br /> |- <br /> |[[WP3-22]] <br /> |UNIMORE <br /> |Onboard Compute Platform Desing Methodology<br /> |- <br /> |[[WP3-24]] <br /> |UNIVAQ <br /> |Efficient digital implementation of controllers<br /> |- <br /> |[[WP3-26]] <br /> |UWB <br /> |Droneport: an autonomous drone battery management system<br /> |- <br /> |[[WP3-28]] <br /> |UNISS <br /> |Accelerator Design Methodology for OOCP<br /> |- <br /> |[[WP3-36_1]] <br /> |UDANET <br /> |Smart and predictive energy management system<br /> |- <br /> |[[WP3-36_2]]<br /> |UDANET <br /> |AI drone system modules<br /> |- <br /> |[[WP3-37]] <br /> |Aitek <br /> |Video and data analytics<br /> |- <br /> |[[WP4-2]] <br /> |SCALIAN <br /> |EZ_Land Precision landing<br /> |- <br /> |[[WP4-5]] <br /> |SCALIAN <br /> |AI detection for clearance<br /> |- <br /> |[[WP4-07]] <br /> |ROT<br /> |Run-Time Safety Checker<br /> |- <br /> |[[WP4-10]] <br /> |ALM<br /> |Cooperative Planner<br /> |- <br /> |[[WP4-14]] <br /> |ALM<br /> |Map Enhancement Service<br /> |- <br /> |[[WP4-15]] <br /> |ALM<br /> |Visual Analytics<br /> |- <br /> |[[WP4-16]] <br /> |ACORDE<br /> |Enhanced Navigation Software<br /> |- <br /> |[[WP4-17]] <br /> |ACORDE<br /> |Anchor&amp;Tag firmware of the Indoor Positioning System <br /> |- <br /> |[[WP4-18_A]] <br /> |TEKNE <br /> |Drone-Rover Transponder<br /> |- <br /> |[[WP4-20]] <br /> |ALM<br /> |Attractor-based Navigation<br /> |- <br /> |[[WP4-22]] <br /> |ALM<br /> |Shared Reference Frame<br /> |- <br /> |[[WP4-32]] <br /> |SHERPA<br /> |Dynamic control development for navigation and precision landing<br /> |-<br /> |[[WP4-33]] <br /> |UNIVAQ <br /> |Autonomy, cooperation, and awareness<br /> |-<br /> |[[WP4-36]] <br /> |IMCS<br /> |Autonomous Decision Making in Critical Situations<br /> |-<br /> |[[WP4-37]] <br /> |IMCS<br /> |Algorithms for Runtime Safety Monitoring<br /> |- <br /> |[[WP4-39]] <br /> |HIB<br /> |Simulated data aggregator supporting intelligent decision in computer vision components<br /> |- <br /> |[[WP4-42]] <br /> |SCALIAN <br /> |AI Stabilization<br /> |- <br /> |[[WP5-02]] <br /> |IKERLAN<br /> |Security Management Toolchain<br /> |- <br /> |[[WP5-03]] <br /> |SCALIAN <br /> |EZ_Com Safe fleet communication<br /> |- <br /> |[[WP5-08]] <br /> |ROT<br /> |Lightweight Cryptography<br /> |- <br /> |[[WP5-09]] <br /> |ABI <br /> |Communication scheme for unified system management<br /> |- <br /> |[[WP5-05_A]] <br /> |TEKNE <br /> |LP-WAN for UAV identification and monitoring<br /> |- <br /> <br /> |[[WP5-11_ACO]] <br /> |ACORDE<br /> |Navigation system with anti-jamming and anti-spoofing features<br /> |- <br /> |[[WP5-16-AIT]] <br /> |AIT<br /> |Cryptographic algorithms adapted for drones<br /> |- <br /> |[[WP5-19_ACO]] <br /> |ACORDE<br /> |Robust communication for an improved Indoor Positioning System<br /> |- <br /> |[[WP6-P4R]] <br /> |CEA <br /> |Model driven engineering<br /> |- <br /> |[[WP6-20]]<br /> |ACORDE<br /> |ESL embedded SW Design Environment (ESDE)<br /> |- <br /> |[[WP6-21]] <br /> |ACORDE<br /> |Indoor Positioning System Modelling&amp;Analysis Framework (IPS-MAF)<br /> |- <br /> |[[WP6-17]] <br /> |UNIVAQ<br /> |HW/SW CO-DEsign of HEterogeneous Parallel dedicated SYstems (HEPSYCODE)<br /> |- <br /> |[[WP6-34]] <br /> |UNIVAQ<br /> |HEPSYCODE SystemC SIMulator Version 2.0 (HEPSIM2)<br /> |-<br /> |[[WP6-25]]<br /> |UNICAN<br /> |S3D - Model-Driven Analysis and Design Framework<br /> |}</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=811 2023-01-10T13:14:36Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-HEPSIM2<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]<br /> <br /> ==References==<br /> [1] E. Villar, J. Merino, H. Posadas, R. Henia &amp; L. Rioux: “Mega-modeling of complex, distributed, heterogeneous CPS systems”, Microprocessors and Microsystems, V.78, 2020.<br /> <br /> [2] J. Merino, R. Gomez, H. Posadas and E. Villar: &quot;Modeling and Performance Estimation of Robotic Systems using ROS: Application to drone-based Services,&quot; in proc. of the Forum on specification &amp; Design Languages (FDL), IEEE, 2021.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-25_IO_01.png&diff=810 2023-01-10T13:12:42Z

<p>Raulgv: Raulgv uploaded a new version of File:Wp6-25 IO 01.png</p> <hr /> <div></div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=809 2023-01-10T13:05:06Z

<p>Raulgv: /* Interoperability with other C4D tools */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-HEPSIM2<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> <br /> [[File:wp6-25_IO_01.png]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-25_IO_01.png&diff=808 2023-01-10T13:04:43Z

<p>Raulgv: </p> <hr /> <div></div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=807 2023-01-10T13:04:27Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-HEPSIM2<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.<br /> <br /> == Interoperability with other C4D tools ==<br /> S3D is based on fundamental Model-Driven, Component-Based computational concepts. As a consequence, it keeps interoperability with many other system modeling environments. The following picture shows the interoperability of S3D with other tools in the C4D design and Verification environment:<br /> [[File:wp6-25_IO_01.png]]</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=806 2023-01-10T13:02:13Z

<p>Raulgv: /* Detailed Description */</p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-HEPSIM2<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> # System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> # System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> # Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> # IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> # HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> # SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> # SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> # SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> # In the rest of stages:<br /> ## SW Integration &amp; Verification.<br /> ## HW Integration &amp; Verification.<br /> ## IT Integration &amp; Verification.<br /> ## Mechanical Integration &amp; Verification.<br /> ## System Integration &amp; Verification.<br /> ## System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=WP6-25&diff=805 2023-01-10T12:49:19Z

<p>Raulgv: </p> <hr /> <div>== Introduction ==<br /> {|class=&quot;wikitable&quot;<br /> | ID|| WP6-HEPSIM2<br /> |-<br /> | Contributor || UNICAN<br /> |-<br /> | Levels || Tool, Platform<br /> |-<br /> | Require || Linux, Eclipse EMF<br /> |-<br /> | Provide || Executable system level modeling, automated generation of embedded software, native execution based validation<br /> |-<br /> | Input || Platform model<br /> |-<br /> | Output || Code generation<br /> |-<br /> | C4D tooling || n.a.<br /> |-<br /> | TRL || <br /> |}<br /> <br /> S3D (s3d.unican.es) is a model-driven, system design framework around a single UML/MARTE model [1]. The model is used as a centralized repository of all the information about the system which is relevant for the design. From the 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. The model is simulated by the VIPPE tool. It is worth mentioning that the M2M technology used to generate the simulation models automatically from the system model can be extended to synthesize the SW stack to be executed in each computational node. The corresponding synthesis tool is eSSYN (essyn.unican.es).<br /> <br /> [[File:wp6-25_I_01.png]]<br /> <br /> ==Contribution and Improvements==<br /> <br /> The fundamental S3D modeling methodology based on required-provided services has been extended in order to support components using ROS, a publish-subscribe communication middleware [2]. In this paper, Model-Driven Design (MDD) is proposed for modeling, simulation and performance analysis of SW intensive robot-based services. The work shows that robots can be integrated into a system engineering framework without affecting their modeling, design and development features. In order to seamlessly integrate these additional kinds of electro-mechanical components, a platform-based approach is proposed. The large number of different robots available makes it very difficult to reuse the same functional components from one project to another if the robots are changed. For certain kinds of robots with many similar functions, such as drones, a common list of methods can be defined so that the same code is valid for all of them simply by associating the functions with the appropriate code. An additional advantage of this common language is a significant reduction in the programming effort which can be reduced around 30%. The cost to be paid is a drop in simulation speed. In the use case of the paper, this reduction can be as high as 16% when a code intensive in ROS calls is used.<br /> <br /> Another interesting result is that if the MDD modeling methodology is general enough, no extension is needed in order to support ROS. Identifying which components make use of ROS is sufficient. In this case, the ROS infrastructure is automatically integrated in the system and used by those ports requiring it. A methodology for rough estimation of execution time of the ROS code has been proposed. Although the error can be as high as 45%, the impact is small as the ROS code will be only a fraction of the total executable. In any case, an improvement over not annotating any execution time for ROS is achieved and this improvement is higher when it is more needed, that is, when the percentage of ROS code is higher. The improvement can be as high as 83.5% with only 2.55% of ROS code.<br /> <br /> The proposed framework enables the seamless integration of robots into a MDD framework so that the whole service can be modelled, simulated and its performance analyzed, fully supporting essential stages of the V-Cycle as explained below.<br /> <br /> == Detailed Description ==<br /> <br /> S3D covers the modelling and automatic generation of the multi-level executable models used to validate and verify the system at the different abstraction levels. S3D supports the modelling activities at each stage of the V-Cycle for mechatronic systems as explained below:<br /> [[File:wp6-25_DD_01.png]]<br /> <br /> In all these stages, S3D supports reusability from previous projects as both functional and test-bench components can be imported from libraries:<br /> <br /> 1. System Requirement Analysis. Based on Papyrus and the UML/MARTE standard, S3D can help in analysing and finally, specify the functional and non-functional requirements to be satisfied by the System (or System of Systems),<br /> 2. System Design. Once the requirements have been specified, the system and its environment are fully specified in terms of the interface among them, the domain constraints (input rates, types and constraints among them) and the system functional and non-functional requirements (output rates, input/output delays, energy, etc.). As part of the System Design stage, partitioning of the system in the mechanical and the IT (digital) parts is performed. In S3D, the mechanical part will be incorporated to the Test-Bench (TB) of the (digital) system. As its functionality and performance is fully specified, the TB, including the model of the robots, can be developed.<br /> 3. Mechanical Analysis and Design. The inclusion of the robots as TB components allows the analysis of their constraints and the design of the mechanical part (number and type of robots, design requirements to each one and among them, etc.).<br /> 4. IT Analysis and Design. At this stage, the analysis and specification of the Platform-Description Model (PDM) can be performed. On the other side, the Platform-Independent Model can be specified.<br /> 5. HW Analysis &amp; Design. At this stage, the design of the initial Platform-Description Model (PDM), can be performed and an initial architecture of nodes and their internal HW architecture can be proposed. The final PDM will be decided later during architectural mapping as part of the System Integration &amp; Verification stage.<br /> 6. SW Analysis &amp; Design and SW Detailed Design. During this stage, the hierarchical partitioning of the PIM in sub-systems and finally, components fully specified in their interfaces and functional and non-functional constraints, is decided.<br /> 7. SW Development. The goal of this stage is to develop the code implementing the functional constraints. Papyrus supports both the Modelling and the Development Views and S3D links one with the other by annotating the components with their implementation files using the file’s paths as properties.<br /> 8. SW Component Verification. S3D links each component with their Test-Benches so that the component can be verified both in the host (verification) and the target platform (testing) in case it has been decided already and it is available.<br /> 9. In the rest of stages:<br /> <br /> a. SW Integration &amp; Verification.<br /> b. HW Integration &amp; Verification.<br /> c. IT Integration &amp; Verification.<br /> d. Mechanical Integration &amp; Verification.<br /> e. System Integration &amp; Verification.<br /> f. System Acceptance Verification.<br /> <br /> S3D helps in supporting the improvement of the model through the different stages and the automatic generation of the executables models so that the functional and non-functional constraints can be verified. Architectural mapping, that is, the final mapping of functional components in the PIM to execution resources in the PDM is fixed during System Integration and Verification when an accurate simulation and performance analysis model including the actual code can be generated. This model can provide accurate metrics ensuring final satisfaction of the implementation decided after Design-Space Exploration of as many possibilities as required.</div>

Raulgv https://c4d.lias-lab.fr/index.php?title=File:Wp6-25_DD_01.png&diff=804 2023-01-10T12:48:36Z

<p>Raulgv: </p> <hr /> <div></div>

Raulgv