Managing SPL Variabilities in UAV Simulink Models with Pure::variants and Hephaestus

Abstract

Unmanned Aerial Vehicles (UAV) are vehicles that y without a pilot and are able to execute dierent types of missions, such as surveillance, topographical data collection, and environment monitoring. This motivates some degree of variability in the controlling software of UAV (usually specied using Simulink models), even though it is also possible to reuse software in this domain using systematic approaches such as Software Product Lines (SPLs). In this paper we present a catalog of patterns to represent variable features in Simulink and show how to construct a simple software product line for an UAV. We also show mechanisms and an infrastructure for conguring Simulink assets, using two tools to manage variabilities: Pure::variants and Hephaestus. These tools are also compared according to a set of characteristics.

Variability management in safety‐critical systems design and dependability analysis

“…We performed such analysis, which is one of the contributions of this paper, by considering the following system architecture models enhanced with dependability information: aircraft braking system . door controller , Tiriba UAV , and automotive braking system software product lines. Their architecture models were specified in AADL and Simulink, and dependability annotations with the support of AADL Error Annex, and HiP‐HOPS compositional dependability analysis techniques.…”

“…In data‐flow oriented architectural models, structural/architectural variability can be found in systems , subsystems , components , their ports , and connections expressed by flows from input to output ports and vice versa , which may change according to the chosen system and usage context features. By considering the TFC‐SPL developed with Simulink model blocks , the selection of the TFC‐MAT system variant from the Pilot Mode variation point, by choosing Manual and Autonomous Pilot system features shown in Figure (left), drives the selection of the PWM Decoder component and the BCP subsystem, their ports , and connections (see Figure ) during the product derivation process . It is important to highlight that variation in usage context features combined with variation in system features, and isolated variation in the usage context may also impact on the derivation of variant‐specific architectural and behavioral models.…”

“…Existing variant management techniques provide support for managing variability of requirements, architecture, components, source code, and test case assets. However, these techniques were not originally designed or used for supporting variability management in system models enhanced with dependability information, such as those specified with the support of compositional modeling techniques like OSATE AADL, HiP‐HOPS, or CHESS…”

“…Although existing variant management techniques were not originally designed to support variability in a system model enhanced with dependability information, we have developed an adapter to the BVR toolset to enable support for managing variability in AADL system models enhanced with AADL error annex dependability annotations. This adapter allows BVR to communicate with OSATE model editors.…”

“…Thus, to select design and dependability model elements and linking them to abstract representations defined in the SPL feature and context models, variant management tools have to communicate with compositional modeling tools. We can manage variability in system models enhanced with dependability information with the support of extensions to existing variant management techniques, eg, BVR toolset . This activity encompasses the following tasks: (a) specifying design and dependable‐related variation points and their variants from the analysis of interactions between system and usage context features, and scenarios used to guide engineers during dependability analysis; (b) mapping design variants (defined in the SPL feature model) to their realization in the SPL architectural and behavioral models by defining model elements to be included ( replacement ) and/or excluded ( placement ) when each design variant is resolved during the product derivation process; and finally, (c) mapping dependable‐related variants (specified in the SPL feature and context models) to their realization in the dependability model by linking each variant scenario considered during dependability analysis to the corresponding information about HARA , the Allocation of Safety Requirements , and failure data (fault model) associated with each variant‐specific component.…”