Variability management in safety-critical systems design and dependability analysis

Safety-criticalsystems are of paramountimportance formany application domains, where safety properties are a key driverto engineercritical aspects and avoid system failures. Forthe benefits of large-scale reuse, software product lines (SPL) have been adopted in critical systems industry. However, the integration of safety analysis in the SPL development process is nontrivial. Also, the different usage contexts of safety-critical systems complicates component fault modeling tasks and the identification of potential hazards. In this light, better methods become necessary to estimate the impact of dependability properties during Hazard Analysis and Risk Assessment. Existing methods incorporating the analysis of safety properties in SPL are limited as they do not include hazard analysis and component fault modeling. In this paper, we present the novel DEPendable Software Product Line Engineering (DEPendable-SPLE) approach, which extends traditional SPL processes to support the reuse of safety assets. We also present a detailed analysis of the impact of product and context features on the SPL design, safety analysis, and safety requirements. We applied DEPendable-SPLE to a realistic case study from the aerospace domain to illustrate how to model and reuse safety properties. DEPendable-SPLE reduced the effort of safety analysis for certifying system variants.

the system model). Thus, the dependability model should be included in the SPL core assets to enable the systematic reuse of dependability information together with other SPL assets (eg, requirements and design).
The management of variability in dependability models can contribute to reducing the costs of generating safety assets for a larger number of system variants built upon the SPL core assets. Although existing variant management techniques, eg, Base Variability Resolution (BVR), 36 were not designed to support variability in the dependability model, they can be adapted to enable support for variability management and derivation of product-specific system models enhanced with dependability information.

3.2
Adapting conventional SPL approaches to support dependability engineering Software Product Line Engineering for critical systems is distinguished from conventional SPL approaches [18][19][20]31 as they consider the impact of design choices and usage context 26 on system dependability properties throughout the SPL life cycle (see Figure 2), in compliance with safety standards/considerations. [2][3][4] In Figure 2, related conventional SPLE and dependability engineering activities are grouped into labeled boxes.
Modified SPLE sub-sub-phases are highlighted, and dependability activities added to conventional product line processes are filled with gray.
Dotted activities represent issues outside the scope of this paper. In the problem space domain definition, ie, during SPL requirements engineering, dependable/safety-related features and their relationships with system/design features should be identified and specified, together with design and usage context features. This results in the product line feature model, as highlighted in Figure 2 (i).
From the perspective of safety-critical SPLs, interactions among different types of features (eg, dependable-related, system/design, and usage context) can be used to establish safety certification criteria that might impact on SPL architectural/design decisions aiming at achieving a target safety level and dependability properties. After specifying a preliminary SPL design, we perform an analysis of interactions between dependable, system, and context features to derive candidate scenarios (see Figure 2 (i)) to guide engineers during hazard analysis for identifying potential threats (hazards) and estimating their risk for the overall safety across a set of system variants. In addition to conventional SPLE processes, we should include Hazard Analysis and Risk Assessment (HARA), along with allocation/identification of safety requirements, dependability engineering activities between SPL requirements and initial stages from the design in the domain engineering phase (see Figure 2 (ii)).
In the SPL architecture and implementation, ie, in the solution space, we should specify the realization of dependable-related system features, eg, redundancy, and their relationships with other features in the product line architectural and/or behavioural models and component implementations.
Later, dependable-related architecture and component assets should be added to the SPL core assets. Additionally, we should incorporate component fault modeling dependability engineering activity into the SPL architecture subphase (see Figure 2 (ii)). the SPL design and component implementation with the support of compositional techniques. [7][8][9] It is important to highlight that domain-specific hazard analyses and component fault models are part of full-up safety considerations, ie, safety/dependability assumptions valid for a set of targeted system variants (scenarios).
Still in the domain engineering phase, in order to achieve the systematic reuse of SPL core assets, conventional SPL processes demand the specification of mappings linking system design features to their realization in the SPL architecture along with components in the variability model, during integration of variability information shown in Figure 2 (ii). A variability model or application variability model establishes traceability links between application requirements, specified in the feature model, and domain artefacts such as architectural components and test cases. 31 Moreover, safety-critical SPL processes also demand the specification of mappings in the SPL variability model that link dependable-related features to their realization in the dependability model (ie, HARA information and component fault models). This is necessary to enable support for the systematic reuse of dependability information in the application engineering phase.
Dependable-related features also impact on the development of test cases for testing dependable SPL components. Thus, in the safety-critical SPLE, we should add dependability engineering activities to the domain engineering phase. Variability management and other traditional SPLE activities, eg, domain modeling, should be extended for considering the impact of SPL variation on system safety/dependability properties.
In the safety-critical SPL application engineering phase, we need to extend product-specific requirements, ie, product feature modeling in the problem space, by considering the specification and selection of dependable-related features, which impact on both design and dependability assets, together with the specification and selection of system and usage context features. Still in the application engineering phase, we need to modify the variability resolution process of a safety-critical SPL by considering mappings linking dependable-related features to their realization in both SPL design and dependability assets defined in the variability model. This is required to enable the generation/derivation of both design, HARA information, and component fault model safety assets, ie, solution space, for a specific system variant according to the feature selection. The goal is to achieve the systematic reuse of both HARA information and component fault models, reducing potential effort and costs for achieving product certification ‖ and component approval in compliance with domain-specific safety standards 2,4 and/or considerations. 3 Finally, we should add the same dependability engineering activities from the domain engineering phase, eg, hazard analysis and component fault modeling, together with Fault Tree Analysis and FMEA Synthesis, to the application engineering phase (see Figure 2 (iii), (iv), and (v)). This is necessary to enable support for the analysis of dependability properties of a specific system variant obtained after product derivation (ie, PL Architecture Customization).

DEPendable-SPLE: An overview
Here, we present the DEPendable-SPLE approach, which extends traditional SPLE methods [18][19][20]31 with the provision of support for safety/dependability engineering and variability management in dependability assets (dependability model).
The DEPendable-SPLE approach activities and their associated work products, in both domain and application engineering phases, are illustrated in Figure 2. In this paper, we focus on dependability engineering for safety-critical SPL architectures, so modifications in traditional SPLE activities such as domain and application requirements engineering, design, and testing are not detailed. Instead, we have added four dependability engineering activities to the domain engineering phase, and we have extended traditional SPLE variability management to enable support for the management and resolution of variability in the dependability model. In the application engineering phase, the product derivation process (ie, PL architecture customization) was extended to allow the resolution of variability on the SPL dependability model. This supports the generation of variant-specific design and dependability assets according to chosen features defined in the application feature model.
Although existing variant management techniques 11,[32][33][34][35][36] were not originally designed to support variability in a system model enhanced with dependability information, we have developed an adapter to the BVR toolset 36 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. The detail about the AADL-BVR adapter is outside the scope of this paper.
The DEPendable-SPLE approach is structured to comply with safety assessment processes established in cross-domain standards/considerations. [2][3][4] Enhancing SPLE processes with safety engineering life cycle activities may contribute to reducing the effort and costs of achieving certification of critical systems along with componentapproval in compliance with standards/considerations, eg, ISO 26262 2 Parts 3 and 4 for automotive, and SAE ARP 4754A 4 safety process for avionics. In our approach, SAE ARP 4754A safety processes or ISO 26262 Parts 3 and 4 activities, ie, PL Architecture box in Figure 2 (ii), are conducted after feature modeling and identification of scenarios for hazard analysis (Domain Modeling and Requirements Engineering box in Figure 2 (i)). It is important to highlight that there is a two-way process between the standards and domain analysis: The choice of the standards constrains the domain model and vice versa. State-of-the-art model-based and compositional dependability analysis techniques [7][8][9] can be used to support engineers performing dependability activities through the SPL life cycle.
The DEPendable-SPLE approach is applicable independently from the underlying variant management and compositional safety/dependability analysis techniques. Each of the activities is described in the following sections.
‖ It means compliance to regulations in avionics, since there is no safety certification in aviation.

DEPendable-SPLE: Domain engineering phase
In the first step of the domain engineering phase, dependability analysis scenarios are defined from the analysis of interactions among product/system and usage context features specified in the SPL domain model. After scoping SPL dependability analysis to a set of targeted scenarios, dependable-related steps such as hazard analysis, along with the allocation of safety requirements, and component fault modeling, are iteratively and incrementally performed for each scenario. Finally, features are linked to their realization in architectural and behavioral models, plus their dependability artefacts as part of safety-critical SPL variability modeling. Each domain engineering approach step is detailed in terms of its inputs, purpose, and outputs.

Domain modeling and requirements engineering
In this subphase, we describe the elicitation of safety/dependability requirements, how we can model the variability of these requirements and other system features, and how we perform the identification of scenarios for hazard analysis. The elicitation of safety/dependability requirements is not the main goal of our approach. The purpose of this subphase is to analyze different system configurations belonging to the target safety-critical system's domain, eg, avionics, to identify common requirements. However, it is not possible to guarantee that these common requirements belong to safety aspects of the system before performing hazard analysis. After this activity, we perform the feature modeling task.

Feature modeling
In feature modeling, we specify system and usage context commonality and variability in both SPL feature and context models. Usage context features in isolation or when combined with system features can impact on the product line design and dependability analysis in the domain engineering phase. Thus, variation in the selection of system and usage context features may lead to different design choices, resulting in different system and component-level failures during SPL dependability analysis. We can use combinations among system and usage context features to propagate/specify variation in safety information in the feature model. A detailed description of an approach to support the specification of safety-related features and their interactions on feature modeling is outside the scope of this paper.

Identification of scenarios for product line hazard analysis
The last step of the domain modeling subphase is the identification of scenarios for hazard analysis. The inputs for this activity are the SPL feature and context models, containing the specification of system and usage context features and their interactions; a preliminary SPL design, produced during earlier stages of SPL architecture subphase (see Figure 2 (ii)); and analysts' domain knowledge. The purpose of this activity is identifying, from the analysis of interactions among system/product and usage context features, a set of system variants (scenarios) relevant for the stakeholders by combining system and usage context features. These scenarios can be further considered to guide engineers during SPL dependability analysis.
The identification of scenarios encompasses the following tasks: (a) identifying combinations among system/product features, which represent system functions, and their relationships with elements from architectural and behavioral models, to derive system/product variants; (b) for each identified system variant, we analyze combinations among features to establish potential usage contexts in which the given system variant can operate; and finally, (c) we derive different scenarios by combining the identified system and usage context variants. However, since it would be prohibitive to perform such analyses covering all system/usage context variants, we can use the analysts' domain knowledge and relevant product variants for the stakeholders as criteria to assess candidate scenarios to be considered when performing SPL dependability analysis. 6,24,37 The outputs of this activity are combinations of system and usage context variants, ie, scenarios, relevant for the stakeholders. Thus, considering the SPL feature model (FM) with F1 mandatory and F2 optional system features, and a context model (CM) with CX1 and CX2 mutually exclusive features, and a relation CX2 includes F2, we have the following scenarios: SC1 = F1, CX1, and SC2 = F1, CX2, F2. We can further consider these scenarios during SPL hazard analysis.

Product line architecture
In the safety-critical SPL development process, system and usage context features and their interactions define constraints that may impact on design decisions aimed at achieving safety certification. Thus, different design choices must be taken according to the selection of system and usage context features. In both non-critical and safety-critical software product lines, variation points and their variants defined in the SPL feature and context models have a direct impact on the derivation of product-specific architectural and behavioral models. In the development of critical systems, the system architecture is often expressed in data-flow 7 optional state, and a set of transitions (T): t1, t2, and t3 encapsulating common and variable behaviors. After that, still in the second subphase of domain engineering, we will use as input the scenarios relevant for the stakeholders together with the system architecture, composed of different subsystems and components, and we will identify potential failures both in subsystems and components that can be found in each scenario. Finally, we will integrate the variability information produced in the domain modeling with the SPL design and dependability model elements.

Hazard analysis and risk assessment
The inputs for this activity are a targeted scenario, ie, product/usage context variant, relevant for the stakeholders, along with SPL architectural and behavioral models. After choosing a given scenario earlier identified in the previous step, HARA is carried out aimed at identifying combinations of contributing component failures/faults that may lead to the occurrence of system-level failures named hazards. We can specify hazards by means of logical expressions, such as AND, OR, and NOT operators, involving potential failures in SPL architectural subsystems/components that might lead to system failures. These failures are generally stated in terms of failure types that typically include omission, commission, value, early, or late failure modes. Firstly, we analyze interactions among core architectural components to identify potential hazards that can emerge from these interactions. Later, optional, alternative, and mutually inclusive/exclusive architectural components, representing variability defined in the targeted scenario, are analyzed to identify potential hazards that can emerge in such scenarios. This step results in a list of variant-specific hazards.
Considering PLA, a hypothetical aerospace SPL architecture model comprising S1 and S2 mandatory subsystems and a C1 optional component, an omission of S1.out1 AND omission of S2.out1 can cause the Omission of commands hazard in the SC1 scenario. In the next step, still at the system level, we estimate and classify the risk posed by each identified hazard in each scenario using the probabilistic risk tolerability criteria defined in the targeted domain standards. DO-178C 3 and SAE ARP 4754A 4 aerospace safety considerations establish five software levels, DAL A to DAL E, and prescribe that risk assessment should be performed on the basis of severity and probability levels to classify a system hazard at a given software level. Aerospace MIL-STD-882E 38 standard practice for system safety provides a hazard/mishap risk matrix that relates range values for severity and probability attributes with software levels. Thus, engineers estimate the risk posed by a system hazard by assigning values to reliability attributes, eg, severity and likelihood, and later on by checking the corresponding software level in the risk matrix during safety assessment. For example, if the severity of the occurrence of Omission of commands is Catastrophic with probability of occurrence of 10e-3 per hour of operation, then, its risk level is DAL A according to DO-178C and MIL-STD-882E mishap risk matrix.
The risk assigned to a hazard at the system level is inherited by software that contributes to the occurrence of that hazard, to address the targeted software level, eg, DO-178C DAL A. The assignment of software levels to components is modified via architecture. Architectural strategies may contribute to reducing the impact of failures. Thus, different architectural choices may change the assignment of software levels to components. Considering the Omission of commands hazard, the addition of C1 optional component to the architecture may change the software levels assigned to S1 and S2 mandatory subsystems comply with DAL A. This is detailed in the allocation and decomposition of safety requirements, which is also part of the system safety assessment process. The outputs of this activity are a list of identified hazards and their risk classification for each analyzed scenario.

Allocation and decomposition of safety requirements
This activity is part of product line hazard analysis and risk assessment. From the analysis of product line hazards, we specify system and functional safety requirements and allocate Safety Integrity Levels (SILs) for eliminating or minimizing hazard and/or component failure effects on the overall safety. A system safety requirement is the risk reduction measure to mitigate hazard effects. A functional safety requirement relates to design and implementation decisions, stated in the form of system functions, intended for eliminating or minimizing the effects of failures on the overall system dependability. An SIL or safety integrity requirement represents the reliability, eg, in terms of probability and severity attributes, The allocation of SILs to mitigate the effects of hazards or component failures may impact on the system development costs, since achieving a given SIL demands addressing objectives, by performing system engineering activities for producing a set of development artefacts established in the targeted standard/consideration to achieve safety approval according to the level of integrity. The assignment of standard-related objectives to be addressed, activities to be performed, and artefacts to be produced to achieve a given level of integrity (certification level) may change from one domain-specific standard to another. 39,40 In this step, we specify system and functional safety requirements and SILs that should be allocated to each identified hazard according to its risk classification. For example, when considering the values assigned to severity and probability of occurrence of Omission of Commands in the given SC1 scenario, as part of the SAE ARP risk assessment process, we should assign DAL A to mitigate the effects of this hazard. On the other hand, the addition of the C1 component to the product architecture in SC2 increases the system reliability, assuming that this component demonstrably share, with other components, the responsibility of keeping the system operating in a healthy state. Thus, a less stringent DAL B is sufficient to mitigate the effects of Omission of commands. It is important to highlight that the addition of a component in the architecture does not necessarily increase the system reliability. This can happen only if the addition is in such a way to demonstrably share the responsibility with other components to addressing a given software level. However, to ensure the safe usage of SPL subsystems and components, which contribute to the occurrence of this hazard, across a set of system variants, we should still assign the more stringent DAL A. Moreover, it is possible to further decompose the SILs allocated to system hazards throughout contributing components and their associated failure modes.
Allocating stringent SILs to mitigate hazard effects may impact on the definition of stringent standard's objectives and development activities for producing expensive artefacts to achieve safety approval. This can result in increasing both system development and production costs. Higher SILs generally means higher costs, as meeting most stringent objectives typically require more safety measures, and development effort to deliver higher-quality components. SIL decomposition allows a safety-critical system architecture to meet a particular SIL assigned to a system-level failure without all contributing software components having to meet that SIL. For example, if a system failure is raised only when two independent components fail together, these componentsshare the responsibility of meeting the SIL allocated to mitigate the effects of the given system failure.
Prescriptive and process-oriented safety standards and regulations 2 results. 6 Performed early in the design, it can support engineers in the specification of a cost-effective SPL development process. The support for decomposing SILs in SPL architectures is outside the scope of this paper.
Finally, the allocation of functional safety requirements aims to identify system functions that should be added to the system architecture for eliminating or minimizing the effects of the occurrence of a hazard or component failure on the overall safety. Redundancy is an example of a functional safety requirement. When a new functional safety requirement is added to the safety-critical product line architecture, we should perform dependability analysis again to evaluate the impact of the newer functionality on overall safety in the context of the targeted scenarios.
The outputs of this activity are functional safety requirements, stated in terms of system functions added to the system architecture, and a set of SILs assigned to mitigate the effects of hazards and/or component failures on the overall safety.

Component fault modeling
The inputs for this activity are an SPL architecture model and HARA information. From the analysis of the identified hazards that can be raised in a particular scenario, we make assumptions about how architectural components can fail and contribute to the occurrence of each identified hazard.
In this activity, firstly, we choose a particular architectural component and identify potential output deviations, ie, failures in component outputs, that can contribute to the occurrence of each identified hazard. We then specify the potential causes for the occurrence of each identified

Integration of variability information
The inputs for this activity are the SPL feature and context models, along with the SPL architectural, behavioral, and dependability models. This activity extends the variability modeling (application variability modeling) step defined in traditional SPLE methods, [18][19][20]42 aimed at establishing mapping links between features and their realization in the architecture model. This is to enable support for variability management in dependability artefacts.
In this step, we define mappings linking system and usage context features to their realization in both architectural, behavioral, and dependability model elements. It is important to highlight that mapping links in the application variability model are useful to indicate which versions of components and their associated dependability information should be included in each system variant or in each version of a given variant.
Design and dependability base models can be specified with the support of compositional modeling languages and techniques. [7][8][9] 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, 11,32,35 eg, BVR toolset. 36 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.
A mapping link in an orthogonal variability model, which is the modeling technique adopted by the most variant management tools, 11,32,36 comprises the tuple M = (V, F, ME). V represents a variant, which provides a concrete instantiation of variable domain artefacts, e.g., architectural models, specified in a variation point (i.e. a place in the base model where variation can arise). F is a reference to a feature or a feature set specified in the SPL feature model (variability specification model). Finally, ME is a set of base model elements, e.g. architectural, behavioral and/or dependability model elements, which represent the realization of an SPL system/usage context feature or a feature set (F) in the base model.

DEPendable-SPLE: Application engineering phase
During the application engineering phase, both the SPL design and dependability artefacts, stored in an SPL assets repository following the previous steps, can be reused in the development of system variants that address customer-specific requirements. Thus, from the analysis of the product line feature/context models and customer-specific application requirements, SPL system and dependable-related features are chosen according to the targeted application requirements to derive the product/application feature model (ie, variability resolution or instance model).
Additional customer-specific system/product and usage context features, not predicted in the SPL domain modeling and design, can also be added to the application feature model, and to the SPL core assets repository. During the product derivation process, customer-specific design and dependability assets are generated, with the support of a variability management tool, eg, BVR toolset, 36 from the choices specified in the application/product feature model. Customer-specific system functions can be added to the generated variant-specific design.
The addition of customer-specific system functions and usage contexts may impact on the dependability analysis. Thus, variant-specific hazards and component failures can be identified during application of HARA and component fault modeling, and we can allocate application-specific safety requirements to mitigate their effects on the overall system safety/dependability. Finally, variant-specific fault trees and FMEA results can be generated, with the support of compositional dependability analysis techniques, 7-9 from the reused HARA information and component fault models. With the exception of fault trees and FMEA synthesis, dependability analysis in the application engineering phase can be seen as iterations of the domain engineering phase. Thus, we only provide a brief description of product hazard analysis and component fault modeling to support the reader in better understanding our approach. We detail each DEPendable-SPLE application engineering approach activity in the following subsections.

Application-specific requirements
Product-specific requirements The inputs for this activity are the product line feature and context models and application requirements. In this activity, design and dependable-related variants defined in the SPL feature and context models that address application requirements are chosen, and in some cases, application-specific requirements, not provided by the SPL, are added to the product feature and context models. The end of this activity yieldsproduct feature and context models. It is important to highlight that the addition of product-specific features may impact on both product design (Figure 2 (iv) -PL architectural customization) and dependability analysis (Figures 2 (iii), (iv), and (v)).

Identification of candidate scenarios for product HARA
The product feature/context models, product/application architectural and behavioral models, and the analysts' domain knowledge are inputs for this activity. After product derivation (ie, PL architectural customization), we perform an analysis of interactions among chosen SPL system and usage context features, application-specific system and usage contexts, and application-specific functions added to the reused product architectural and behavioral models after product derivation. Such analysis is focused on identifying potential scenarios, not predicted in the domain engineering phase, that may impact on the overall system safety/dependability, eg, with the emergence of application-specific system hazards and/or component failures. These scenarios can be used to guide engineers during product hazard analysis and component fault modeling activities by following the same steps defined in the domain engineering phase. It is important to highlight that the addition of application-specific system functions to the SPL design (architectural and behavioral models) can result in the emergence of different scenarios that may impact on the overall safety. These scenarios should be considered for guiding engineers through iterations of dependability analysis activities in the SPL domain engineering phase.
The output of this activity is a set of application-specific scenarios that may impact on overall safety. Emergent application-specific scenarios may cause disruption to the previous assumptions about hazards and component failures made by engineers in the domain engineering phase.
There is little that can be done in these cases beyond storing emergent assumptions about hazards, component faults, and safety requirements in the SPL core assets, together with previous assumptions about dependability.

Subsystem and component selection
The SPL feature and context models, the enhanced SPL variability model with mapping links between features and their realization in HARA information and component failure data, the product feature model, and SPL assets, in this case, architectural, behavioral, and dependability models are inputs for this activity. The purpose of this activity is resolving, with the support of extensions of existing variability management tools, eg, the BVR toolset, the variability specified in SPL architectural, behavioral, and dependability base models, and thus, deriving a product/variant-specific system model with dependability information. After deriving a product system model, functions intended to address application-specific requirements (stated in the product feature and context models) not provided by the SPL architecture can be added to the reused product design. These functions can be specified in the form of subsystems and/or components. The output of this activity is a product system model with dependability information that is in some cases enhanced with application-specific system functions.
The addition of specific functions to the reused product design can result in different scenarios emerging that may impact on the product dependability. These scenarios should be considered by engineers during product dependability analysis. Application-specific functions can also provide feedback to the SPLE processes, enhancing the SPL architectural and/or behavioral models. The addition of application-specific system functions to the SPL design core assets may cause the emergence of different scenarios that may impact on the overall system dependability.
These scenarios should be considered further by engineers in iterations of dependability analyses in the SPL domain engineering phase.
Application-specific scenarios should be identified after the selection of SPL subsystems and components and architectural customization.

Product hazard analysis
Application-specific scenarios, product feature and usage context models, product architectural and behavioral models, and analyst's domain knowledge are inputs for product hazard analysis. This activity should be performed by following the same steps defined for HARA in the domain engineering phase. Thus, we should perform product HARA for each identified application-specific scenario, which comprises application-specific product and usage context feature interactions, to identify combinations among component failures that may lead to the occurrence of system-level failures, which were not earlier identified in the domain engineering phase. Next, the risk for the overall safety posed by each application-specific hazard, in different usage scenarios, is estimated, based on the risk tolerability criteria defined in the targeted safety standard/considerations, eg, SAE ARP 4754A severity and likelihood. The output of this activity is a list of product/application-specific hazards and their associated risk classification. Application-specific HARA information can be added to the SPL repository to be further available for reuse in the development (derivation) of other system variants from SPL core assets.

Allocation of product safety requirements
Application-specific scenarios and HARA information, along with analysts' domain knowledge, are inputs for this activity. Thus, from the analysis of product HARA, functional safety requirements, eg, redundancy, can be added to a variant-specific architecture model, and SILs can be allocated to eliminate or minimize hazard effects on overall safety. In the same way as in the domain engineering phase, SILs should be allocated to each product-specific hazard according to their risk classification. A set of application-specific functional safety requirements, ie, system functions aiming at mitigating system-level failures, and SILs allocated to system hazards are the outputs of this activity. Additionally, SILs allocated to application-specific hazards are further decomposed to contributing component failure modes. SIL decomposition can be performed for a particular system variant with automated support of SIL decomposition genetic and metaheuristic algorithms. 8,41 The decomposition of SILs, allocated to application-specific hazards, to contributing components and their failure modes early in the design, can support engineers on the specification of cost-effective application/product development processes according to the level of integrity assigned to subsystem components. Thus, the development process of two different variant-specific subsystem components with different levels of integrity do not need to address the requirements posed by the most stringent level of integrity assigned to a given component. Application-specific functions and allocated safety integrity levels can be added to the SPL repository to refine the SPL design and ensuring the safe operation of components across a range of different system variants not predicted in the product line design.

Product component fault modeling
The inputs for this activity are application-specific scenarios and HARA information. From the analysis of the identified hazards that can be raised in a specific system variant and its associated usage contexts, assumptions can be made about how application-specific architectural components, ie, reused and application-specific assets, can fail and contribute to the occurrence of each emergent hazard (identified during application HARA).
In this step, we analyze each application-specific component to identify potential output deviations that can contribute to the occurrence of each with product-specific dependability information. Thus, the outputs of Product Dependability Analysis are enhanced application-specific design and dependability models and, in some cases, feedback to the safety-critical SPLE processes. Thus, enhancing the SPL architectural, behavioral, and dependability (ie, HARA information and component fault models) models stored in the DEPendable-SPLE repository (see Figure 2).

Product testing
Fault trees and FMEA synthesis The reused product-specific architectural and behavioral models, enhanced with specific dependability information, are the inputs for performing the synthesis of fault trees and FMEA results with the support of compositional techniques. [7][8][9] Fault trees and FMEA results can be automatically generated, with the support of compositional techniques, from the reused and product-specific dependability information produced during domain and application engineering phases. The accuracy of the generated product-specific fault trees and FMEA results is dependent on whether both domain and application dependability analysis activities were performed with awareness of the impact of design and usage contextvariations on overall safety. The end of this activity yields application-specific fault trees and FMEA results that can be used to demonstrate that the architecture of a particular system/product variant addresses safety/dependability requirements.

CASE STUDY
This section presents the application of the DEPendable-SPLE approach in the Tiriba Flight Control System and Software Product Line (TFC-SPL).
In Section 4.1, we present an overview of the TFC-SPL, with focus on domain modeling and design, without going into details concerning dependability aspects. In Section 4.2, we illustrate the dependability approach steps and integration of variability information in the domain engineering phase. Finally, in Section 4.3, we present dependability steps regarding the application engineering phase.

Tiriba product line domain modeling
TFC-SPL was designed following an extractive strategy by analyzing the original Tiriba Flight Control subsystem 25 Simulink model. Figure 3 shows the interconnected TFC-SPL feature and context models. We created TFC-SPL domain models by following Lee and Kang 26 and Hartman and Trew 28 multiperspective feature modeling approaches and their refinements. 29,30 These modeling approaches allow separating the specification of system features from usage context features and a more clear understanding of their relationships. TFC-SPL system feature model (Figure 3 (left)) comprises the Pilot Mode, the Landing Type, and Navigation Services variation points. Landing Type variation point encapsulates variation on the UAV landing capability, which can be via activation of a Parachute to smooth the impact on the ground   Variability in the selection of Tiriba mission-related features specified in Figure 3 (left) are propagated throughout the Tiriba mission controller state machine shown in Figure 5, which defines the mission controller configuration using a mechanism of state transitions conditioned to state variable values that define variability. Thus, when the Entry Segment Simulation mission-related system/functional feature is chosen, a simulation is performed whenever the UAV starts a new mission segment (see Figure 5 (left)), in order to find out the suitable approach for switching between two mission segments. When the Route Correction (ie, Feather Threshold) functional feature is selected, the UAV route is adjusted whenever the aircraft deviates more than a certain threshold (limit) from the planned mission route. The realization of this feature is expressed by the correction start state transition in the Tiriba FSM from Figure 5 (left). Finally, when the Route Tracking (ie, Failure Handler) feature is selected, the UAV is able to return to specific positions where a picture was not taken during the mission, which is dispatched by the good simulation state transition in Figure 5 (left).
The activation or deactivation of Tiriba mission controller functional features is defined by alternative flows with Boolean conditional variables (see Figure 5 (right)), which allow enabling or disabling FSM flows and states according to the feature selection. Thus, for each one of the aforementioned mission-related features, there is a variable whose value defines which FSM states and transitions will take place in the final product.
The SimEnableBoolean variable controls the activation/deactivation of the behaviour related to the Entry Segment Simulation feature. When this feature is selected, i.e., when the TFC-ALL (all pilot modes) system variant and uncontrolled airspace context variant are chosen, the SimEnable variable is set true (see Figure 5 (right)). On the other hand, SimEnable is set false when the Entry Segment Simulation feature is not selected. The same is valid for selection/activation and deselection/deactivation of the Route Correction and Route Tracking functional features.
It is important to highlight that usage context features may have influence in the selection of system/design features that impact on the Finite State Machines, changing the system behavior. Thus, when uncontrolled airspace usage context and TFC-ALL system variants are chosen, the

TFC-SPL: Dependability in domain engineering
In this phase, we initially analyzed interactions between Tiriba system and usage context features to identify scenarios to guide dependability analysis. On the basis of the identified scenarios, we performed TFC-SPL hazard analysis and component fault modeling. Finally, we linked Tiriba domain variants to their realization in both Tiriba SPL design and dependability model elements in the Tiriba application variability model.

Identification of scenarios and Tiriba hazard analysis
From the analysis of the TFC-SPL system and usage context variants specified in the feature and context models shown in Figure 3 Table 1 shows an excerpt of TFC-SPL hazard analysis and risk assessment. Variation in the causes of the No pilot commands and Value pilot commands hazards, and in the risks that they pose for overall safety, were identified in both of the two aforementioned system variants (see Table 1) and PWMDecoder component outputs are the causes for the occurrence of the same hazard when the TFC-ALL system variant and uncontrolled airspace usage context are selected. Such variation can also be found in the causes of incorrect value of pilot commands, ie, value pilot commands hazard, which may change according to the targeted system and usage context variants (see Table 1). Variation in the TFC-SPL hazard analysis further propagates throughout the risk assessment.
In the TFC-SPL risk assessment, different values for likelihood (probability of occurrence) and severity reliability attributes were assigned to classify the risk posed by the no pilot commands and value pilot commands hazards, according to the targeted system and usage context variants.
Thus, the probability of occurrence of both omission of pilot commands (ie, no pilot commands hazard) and incorrect pilot commands (ie, value pilot commands) are respectively 10e-9 and 10e-7 per hour of operation with catastrophic and hazardous severity when the TFC-MAT system and controlled airspace usage context variants are chosen. On the other hand, the probability of occurrence of both hazards are respectively 10e-7 and

Allocation and decomposition of safety requirements in the Tiriba SPL
After estimating the risk posed by each identified hazard, functional safety requirements, and safety integrity requirements, in terms of DALs, were allocated to mitigate Tiriba hazard effects. Following the analysis of the TFC-SPL risk assessment, we allocated different functional safety requirements, expressed in terms of architectural decisions, according to the chosen Tiriba flight control system and usage context variants. A Redundant Tiriba control system architecture should be adopted when the controlled airspace usage context is chosen. On the other hand, a nonredundant architecture is sufficient to address the safety requirements when the Tiriba UAV is intended to operate in an uncontrolled airspace. 43 Based on the analysis of the risk assessment (Table 1), DALs with different degrees of stringency were also assigned to mitigate hazard effects in different TFC system variants (see column DAL in Table 1). Thus, we assigned DAL B to mitigate the effects of the occurrence of the value pilot commands hazard in the TFC-MAT system variant operating in a controlled airspace. On the other hand, DAL C is sufficient to mitigate the effects of this hazard when the TFC-ALL system variant operating in an uncontrolled airspace is chosen.
Variation in the DALs allocated to mitigate hazard effects in both Tiriba system variants has a direct impact on the development processes to be enacted to comply † † with safety standards/considerations in order to achieve the safety certification 3 of an individual system variant.
Thus, expensive objectives, eg, performing the aircraft/system functional hazard assessment with independence, ‡ ‡ prescribed by SAE ARP 4754A to achieve DAL A, should be enacted to mitigate the effects of the occurrence of the value pilot commands hazard when the TFC-MAT system variant operating in a controlled airspace is chosen. On the other hand, when the TFC-ALL system variant operating in an uncontrolled airspace is chosen, performing the aircraft/system functional hazard assessment without independence is sufficient to mitigate the effects of the same hazard. This reduces development costs in comparison with the costs and effort for producing safety assets to certify the TFC-MAT system variant.
The DALs allocated to mitigate the effects of the occurrence of TFC hazards can be further decomposed to contributing components and their associated failure modes identified during component fault modeling. We performed DAL decomposition for each Tiriba system variant with the automated support of metaheuristic optimization algorithms. 8 These algorithms implement aerospace SAE ARP 4754A 4 rules for allocating DALs to functions and decomposing them throughout the items. Rules allow downgrading the DALs assigned to functions (at the system level) to the items (at the component level) based on the independence at requirements, implementation, or hardware deployment levels. 41 In the allocation and decomposition of DALs for the Tiriba case study, we assumed that the components are isolated and protected in the architecture. Table 2 shows the decomposition of DALs allocated to the No pilot commands and Value pilot commands hazards (see Table 1  activities should be performed to produce artefacts to ensure the safety of the different components in a given system variant. By analyzing the DALs allocated to mitigate component failures in the TFC-MAT system variant (see Table 2), it can be seen that the PWM Decoder is a highly

MAT-MSW-Fault-Model
assets, ie, HARA information and component fault models, we manage the impact of design and usage context variations on dependability information during variability modeling.

Integration of dependability information into TFC-SPL variability model
We specified the TFC-SPL domain feature and context models, and the application variability model with the support of the BVR 36 variability management toolset, and AADL Error Annex enabler adapter for the BVR toolset developed by the authors. Whereas variability management techniques available in the literature do not provide native support for managing variability in dependability base models (ie, system models enhanced with dependability information), in this paper, the authors built an adapter to the BVR toolset 36     The final TFC-SPL variability model comprises eight fragment substitutions, one empty placement, and eight replacement elements. We defined four fragment substitutions to specify the realization of system features in both the Tiriba SPL architectural and behavioral models, and four fragment substitutions were defined to specify the realization of dependable-related and usage context features in the SPL dependability model specified as dependability annotations in the TFC-SPL AADL design.

TFC-SPL: Application engineering
In this phase, we defined application feature and context models for two different Tiriba system variants. We input these models to the BVR toolset supporting the derivation of variant-specific system models enhanced with dependability information. We performed iterations of dependability analysis steps defined in the domain engineering phase for identifying application-specific scenarios that may impact on system dependability, along with potential hazards and component failures that can emerge from these scenarios.

Tiriba product requirements engineering and architecture customization
We performed product requirements engineering from requirements for agriculture and environment monitoring applications. For each application, we have chosen the Tiriba flight control system and usage context features (see Figure 3) that addresses its requirements. Thus, we have chosen manual, autonomous, assisted, and automatic pilot system features, and the uncontrolled airspace context feature that address agriculture application requirements (TFC-ALL system variant). We also selected manual and autonomous pilot system features and the controlled airspace context feature to address environment monitoring application requirements (TFC-MAT system variant). During the specification of feature and context models for these two applications, we identified Weather Conditions variant-specific usage context features such as rainy, stormy, wind, and visibility, which can be cloud or sunny that may impact on the system dependability properties. Since weather conditions features may impact on dependability properties of other system variants, we updated the Tiriba product line context model with these features (see Figure 3 (right)). The addition of these features may impact on both the Tiriba application design and dependability analysis. The addition of an application-specific function, eg, redundant autonomous pilot, not available in the Tiriba SPL core assets, to a system variant may also impact on design and dependability properties.
After specifying feature and context models for agriculture (TFC-ALL) and environment monitoring (TFC-MAT) applications, by choosing system and usage context features defined in the Tiriba SPL domain model, we started the product derivation process. For each TFC system variant, the following artefacts were input to the BVR toolset: the TFC-SPL feature and context models, the product feature and context models, the TFC-SPL variability model, and Tiriba Flight Controll AADL design enhanced with AADL Error Annex dependability annotations. 7 Thus, we obtained TFC-MAT and TFC-ALL variant-specific AADL design and error models. Variability management in the TFC-SPL enabled the systematic reuse of almost 80% of HARA and component fault modeling dependability information, produced during the domain engineering phase, in the derivation of each Tiriba system variant.

Synthesis of fault trees and FMEA results for Tiriba system variants
Product/variant-specific TFC AADL design and error models were input to generate fault trees for 10 product-specific hazards (for four different TFC system variants), and FMEA results were synthesized from the generated fault trees. Figure 6 shows excerpts of the

DISCUSSION
In this section, we present an analysis of the impact of variation in system and usage context features on both design and dependability analysis, ie, on hazard analysis and risk assessment, allocation and decomposition of safety requirements, and component fault modeling and propagation. 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. 47 door controller, 48 Tiriba UAV, 24,35 and automotive braking system 37 software product lines.
Their architecture models were specified in AADL 7 and Simulink, 44 and dependability annotations with the support of AADL Error Annex, 7 and HiP-HOPS 8 compositional dependability analysis techniques.

The impact of variability on system design
In data-flow oriented architectural models, structural/architectural variability can be found in systems, subsystems, components, their ports, and  (Figure 5 [right]), activating the transition to the Simulating state (see Figure 5 [left]). In addition to the impact of system and usage context feature variations on architectural and behavioral models in conventional SPLs, such variation may be further propagated to dependability analysis in safety-critical SPL development processes. The production of safety/dependability artefacts contributes to increases in the development costs of safety-critical systems. Understanding how SPL product/system and usage context variation impact on dependability analyses may help to achieve the systematic reuse of both system design and dependability artefacts, reducing the certification costs of individual system variants. Combinations among system and usage context variants may be useful to derive scenarios, which can be used to guide engineers in performing system dependability analysis/modeling in safety-critical SPL architectures. In a safety-critical SPL, different failure conditions can be raised, leading to different system-level failures (ie, hazards), with different probability, severity, and criticality levels. Different safety requirements, in terms of functions or SILs, can be allocated to avoid or minimize hazard and/or component failure effects on overall safety according to design choices and targeted usage contexts. We present a detailed description of a set of identified variability types that can be found when performing dependability analysis for a safety-critical system and software product line in the following section.

Variability in hazard analysis and risk assessment
During hazard analysis, different hazards and hazard causes can emerge according to the targeted product/system and usage context variants.
Examples of such variation can be found in the causes of the No pilot commands and Value pilot commands hazards that may change according to the selection of Tiriba system variants (see Table 1). Variation in hazard definition and hazard causes, identified during hazard analysis, can be further propagated throughout the risk assessment. In the risk assessment, variation can be found in the values assigned to reliability attributes, eg, SAE ARP 4754A likelihood and severity, used to classify the risk posed by each system hazard for overall safety (see Risk Assessment columns from Table 1 An example of variation in the assignment of safety integrity levels can be seen in the allocation of DALs with different degrees of stringency to mitigate the effects of the occurrence of the value pilot commands hazard identified during the Tiriba SPL dependability analysis (see Table 1).
DAL B was assigned to mitigate the effects of this hazard in the TFC-MAT system variant operating in a controlled airspace. On the other hand, a less stringent DAL C is sufficient to mitigate the effects of this hazard in the TFC-ALL system variant.
Variation can also be found in functional safety requirements, expressed in terms of architectural decisions that must be taken to eliminate or minimize the effects of system or component failures, which might change according to the targeted system and usage context variants. In the Tiriba product line, the control system architecture should be Redundant when the controlled airspace 27 usage context is chosen. 24 On the other hand, a non-Redundant control system architecture is sufficient to ensure the safety of the Tiriba UAV operating in an uncontrolled airspace.

Variation and its impact on allocation and decomposition of safety requirements
Variability in the allocation and decomposition of SILs relates to the variation on the mitigation mechanisms for handling the risk posed by a given  Table 2 shows an example of variation in the decomposition of safety requirements, stated in terms of DALs, assigned to mitigate the effects of hazards in different variants (see Table 1 Table 2). Variation in the assignment of SILs to mitigate failure effects of a given component in different variants can be further propagated to the assignment of SILs to ensure the safety of an SPL component across different system variants, ie, across the SPL. We can perform an analysis of the safety requirements that should be allocated to ensure the safe use of an SPL across a set of targeted variants on the basis of the following principle: the most stringent safety requirements, expressed in terms of SILs, assigned to a failure mode of a component across multiple system variants must be the SIL to be assigned to ensure its safe use across the SPL. From the analysis of Thus, instead of allocating the most stringent DAL A assigned to a component failure to ensure the dependability of all components in a given system variant or across the SPL, the decomposition of safety requirements may support engineers on structuring cost-effective Tiriba system and software product line development processes.
The SIL decomposition process allows engineers to assign objectives to a given component or a subset of components according to their level of integrity, instead of allocating highly stringent objectives to all subsystems/components of a system variant. Thus, the assignment of less stringent safety objectives to less critical components means less effort and costs need be considered for developing system components, addressing the safety requirements without incurring unnecessary costs and without compromising safety.
By analyzing the DALs allocated to mitigate the failure effects of components in the TFC-MAT system variant (see Table 2), we noted that the PWM Decoder is a highly critical component with DAL A. Thus, expensive objectives with independence, eg, SAE ARP 4754A -aircraft functional hazard assessment, and DO-178C -verification of additional code, should be addressed. Less critical components, eg, the Barometric Processor DAL C subsystem, demand less stringent objectives that do not require independence 4 (see Table 2). Thus, the definition of development processes according to the level of integrity of each system component contributes to avoiding unnecessary costs for achieving compliance with standards without compromising safety.
Finally, it is important to highlight that when developing reusable system/software components, all variability aspects of each component should be considered from the initial stages of the SPL life cycle, and the most stringent SIL assigned to a given component in different usage contexts should be assigned/allocated to that component to ensure its safe use across the SPL, ie, across a range of system variants/configurations. Thus, product/system and contextual variability will not change the mitigation mechanisms for components in specific system variants.

Component fault modeling and propagation and product line variation
In the safety engineering life cycle, component fault analysis and modeling is intended to identify how software components contribute to the occurrence of potential system-level failures identified during hazard analysis and estimating the reliability, eg, in terms of failure and repair rates of hardware components. Variation in the system hazards and their causes can be further propagated to how components contribute to the occurrence of system hazards.
Variability in component fault modeling can be found in component output deviations that may contribute, in some way, to the occurrence of system-level failures, which might change from one targeted system and usage context variant to another (see column Output Deviation from   Finally, variation in hazard analysis, safety requirements, component fault modeling, FTA, and FMEA further propagate to the structure of product assurance cases. We can automatically generate Assurance Cases, with the support of model-based techniques, 49 for a specific system variant from design and dependability assets. An Assurance Case is a defensible, comprehensive, and justifiable argument supported by a body evidence, which demonstrate that the system is acceptably safe to operate in a particular context. 50 Automotive 2 and aerospace 4 standards and considerations and regulations recommend the production of an Assurance Case for certification of critical systems. The automatic generation and the analysis of the impact of variability on the structure of product assurance cases are outside the scope of this paper.

RELATED WORK
Research on variability management with dependability artefacts is split into extensions of traditional safety and dependability analysis techniques, eg, Fault Tree Analysis and Failure Modes and Effects Analysis, to suit Software Product Line Engineering processes, 13,14,16 and model-based techniques 10,11,51,52 to support dependability analysis integrated with the system design. The most notable work in the first category is the extension of Software Fault Tree Analysis (SFTA), named Product Line SFTA, 13,14 to address the impact of SPL variation on system dependability analysis. In the Product Line SFTA approach, each leaf node of a software fault tree is labeled with commonality or variability associated with that leaf node. The Product Line SFTA approach is built upon a technique for developing a product line SFTA in the domain engineering phase and a pruning technique for reusing the SFTA in the application engineering phase.
The Product Line SFTA approach is further extended to integrate SFTA results with state-based models. 16 This extension allows the mapping of software fault tree leaf nodes into components and modeling the behavior of each component in a state chart. The Product Line SFTA and its state-based modeling extension considers Fault Tree Analysis as a reusable asset. However, fault trees can be automatically generated from dependability information produced during hazard analysis and component fault modeling in the domain engineering phase. Thus, earliervariability management of dependability properties on FTA and FMEA synthesis, as we presented in this paper, enables the systematic reuse of dependability information and traceability of dependable-related variation throughout the SPL safety life cycle. Fault trees and FMEA artefacts can be automatically generated for a particular system variant, with the support of compositional dependability analysis techniques, 7-9 from the reused dependability information produced in the DEPendable-SPLE application engineering phase.
In the second category, Schulze et al 11 have proposed an approach that integrates commercial Medini ISO 26262 compliant safety analysis and pure::variants tools, to enable support for variability management in functional safety-related assets, evaluated in an automotive case study. The Schulze et al approach 11 is based on a referencing model, which maps problem-domain features with artefacts in the solution space, in this case, requirements, fault trees, and safety goals. The Schulze et al approach was further extended with a process to support model-based change impact analysis of variability in automotive functional safety. 51 This process combines variability management techniques with safety engineering and software configuration management activities to achieve a complete safety assessment. The proposed process supports change impact analysis in the following scenarios: (a) when a specific variant shows undesired behavior and it needs to be fixed, (b) in cases where an innovative function requires an extension of an existing system function, and (c) when the function behavior is changed, and it should be analyzed, or when a newer optional function is developed.
Similar to the approach of Schulze et al and its extension, the approach proposed by the authors in this paper is built upon an SPL variability model, linking problem-domain context and system features with artefacts from the solution space, eg, components and their failure data.
Although the Schulze et al 11 approach provides support for variability management in functional safety assets, they did not emphasize the management of the impact of contextual variation on architectural and behavioral models, HARA and component fault modeling, as we presented in this paper. In addition, the author's approach is applicable to domains other than automotive, eg, aerospace, and it is independent, from underlying dependability analysis and variability management tooling support. Nevertheless, the Schulze et al approach 11 and its extension 51 also provides a good and efficient solution for variability and change management on functional safety.
Kaßmeyer et al 52 proposed a systematic model-based approach integrated with a change impact analysis approach. 51 The Kaßmeyer et al tool-supported approach combines requirements engineering and architectural design, safety analysis, and variability management tools, allowing seamless safety engineering across product variants by representing safety artefacts in a homogeneous UML-compliant modeling notation. In their approach, HARA and component fault modeling is performed by annotating the UML model in the same way as in the DEPendable-SPLE approach.
As part of Kaßmeyer et al approach, 52 Domis et al 10

CONCLUSION
In this paper, we presented the DEPendable-SPLE approach that extends conventional SPLE processes with support for variability management in both design and dependability analysis. The DEPendable-SPLE approach enables the systematic reuse of both SPL archictural, behavioral, and dependability models in the application engineering phase. DEPendable-SPLE is also applicable independently from underlying variability management and dependability analysis techniques and tools. In this paper, we performed DEPendable-SPLE approach steps with the support of OSATE AADL and Error Annex system modeling and compositional dependability analysis toolset, BVR variabiity mangement toolset, and OSATE AADL adapter for BVR toolset developed by the authors.
The AADL adapter to the BVR tool was developed to enable BVR to communicate with OSATE model editors for managing variability in AADL design and dependability/error models. We used these tools to support both dependability analysis and variability management steps in the Tiriba flight control SPL. DEPendable-SPLE supports the analysis of the impact of design and usage context variations on dependability analysis artefacts. Thus, we linked the Tiriba Flight Control SPL system and usage context variants to their realization in both architecture, behavioral, and dependability models. Further, we generated, with the support of the BVR toolset, multiple variant-specific design and dependability models, during the product derivation process. Thus, we achieved the systematic reuse of architectural, behavioral, and dependability models early in the SPL safety process.
DEPendable-SPLE enabled the systematic reuse of almost 80% of TFC dependability information, produced in the domain engineering phase, in the derivation of each one of the four TFC system variants. This reduces the effort and costs for performing dependability analysis activities for a specific system variant. With the support of compositional techniques, in this case, OSATE AADL and Error Annex, 7 fault trees, and FMEA were generated from the reused AADL design and AADL Error Annex dependability/error models. We also presented a detailed analysis of the impact of design and usage context variations on both design and dependability analysis (ie, hazard analysis and safety requirements and component fault propagation). Such analysis enables the systematic reuse of dependability assets produced during the domain engineering phase. Additionally, we presented a preliminary analysis of the impact of variation on allocation of safety requirements, expressed in terms of safety integrity levels, and their decomposition throughout components and their failure modes that may support engineers on structuring cost-effective development processes for both SPL and/or specific system variants.
In further work on this topic, we intend to focus on detailing how variability in AADL design and error models is specified and managed, and performing a user study of the BVR tool and AADL adapter developed by the authors and a comparison with existing variant management techniques. We also intend to perform a deeper investigation about the impact of design and usage context variations on SIL decomposition and development processes, and time-dependent, failure and repair behaviors of reconfigurable critical systems and software product lines. We intend to investigate the implications of SPL and system version/configuration variability on both safety and security analysis. Finally, we intend to investigate the use of model-driven techniques to generate variant-specific assurance cases, and the potential of SIL decomposition techniques in supporting engineers to take architectural decisions in the design of reconfigurable systems and safety-critical SPLs.