Automatic Allocation of Safety Requirements to Components of a Software Product Line

9th IFAC IFAC Symposium Symposium on on Fault Fault Detection, Detection, Supervision Supervision and and 9th 9th IFAC on Fault Detection, Supervision Safety of Symposium Technical Processes Processes Safety of Technical Available online and at www.sciencedirect.com 9th IFAC Symposium on Fault Detection, Supervision and Safety of Technical Processes September 2-4, Arts September 2-4, 2015. 2015. Arts et et Métiers Métiers ParisTech, ParisTech, Paris, Paris, France France Safety of Technical Processes September 2-4, 2015. Arts et Métiers ParisTech, Paris, France September 2-4, 2015. Arts et Métiers ParisTech, Paris, France

ScienceDirect

IFAC-PapersOnLine 48-21 (2015) 1309–1314

Automatic Allocation of Safety Requirements to Components Automatic of Requirements Automatic Allocation Allocation of Safety Safety Product Requirements to Components Components of a Software Line to of a Software Product Line of a Software Product Line *1 ** ** **

André , Luís S. Azevedo**, David Parker**, Rosana T. V. Braga*, André L. L. de de Oliveira Oliveira*1,, Yiannis Yiannis Papadopoulos Papadopoulos** **, Luís S. Azevedo**, David Parker**, Rosana T. V. Braga*, *** André L. de Oliveira*1 Papadopoulos , Luís S. Azevedo , David Parker ***,** *** *1, Yiannis ** **, Rosana T. V. Braga*, Paulo C. Masiero*, Masiero*, Ibrahim Ibrahim Habli*** Tim Kelly Paulo C. Habli Kelly André L. de Oliveira , Yiannis Papadopoulos , Luís S. Azevedo , David Parker , Rosana T. V. Braga*, ***, Tim Paulo C. Masiero*, Ibrahim Habli***, Tim Kelly*** *** Paulo C. Masiero*, Ibrahim Habli , Tim Kelly

*Mathematics *Mathematics and and Computer Computer Science Science Institute, Institute, University University of of São São Paulo, Paulo, São São Carlos-SP, Carlos-SP, Brazil Brazil *Mathematics and Computer Science Institute, University of São Paulo, São Carlos-SP, **Department of Computer Science, University of Hull, Hull, United Kingdom **Department of Computer Science, University of of Hull, United Kingdom Brazil *Mathematics and Computer Science Institute, University SãoHull, Paulo, São Carlos-SP, Brazil **Department of Computer University Hull, Hull, United Kingdom ***Department of Science, University of Deramore Lane, York, United ***Department of Computer Computer Science,Science, University of York, York, of Deramore Lane, York, United Kingdom Kingdom **Department of Computer Science, University of Hull, Hull, United Kingdom ***Department of Computer Science, University of York, Deramore Lane, York, United Kingdom {andre_luiz, rtvb, {y.i.papadopoulos, d.j.parker}@hull.ac.uk, [email protected], {andre_luiz, rtvb, masiero}@icmc.usp.br, masiero}@icmc.usp.br, {y.i.papadopoulos, d.j.parker}@hull.ac.uk, [email protected], ***Department of Computer Science, University of York, Deramore Lane, York, United Kingdom {andre_luiz, rtvb, masiero}@icmc.usp.br, {y.i.papadopoulos, d.j.parker}@hull.ac.uk, [email protected], {ibrahim.habli, tim.kelly}@york.ac.uk {ibrahim.habli, tim.kelly}@york.ac.uk {andre_luiz, rtvb, masiero}@icmc.usp.br, {y.i.papadopoulos, d.j.parker}@hull.ac.uk, [email protected], {ibrahim.habli, tim.kelly}@york.ac.uk {ibrahim.habli, tim.kelly}@york.ac.uk Abstract: Safety Safety critical critical systems systems developed developed as as part part of of aa product product line line must must still still comply comply with with safety safety Abstract: Abstract: Safety critical systems developed as part ofLevels a product line must the stillassignment comply with safety standards. Standards use the concept of Safety Integrity Levels (SILs) to drive the assignment of system standards. Standards use the concept of Safety Integrity (SILs) to drive of system Abstract: Safety critical systems developed as part of a product line must still comply with safety standards. Standards to usecomponents the concept of of aaSafety Integrity to drive assignment of system safety requirements requirements system under Levels design. (SILs) However, for aathe Software Product Line safety system under design. However, for Product Line standards. Standards to usecomponents the concept of of Safety Integrity Levels (SILs) to drive theSoftware assignment of system safety requirements to components of a system under design. However, for a Software Product Line (SPL), the safety requirements that need to be allocated to a component may vary in different products. (SPL), the safety requirements that need be allocated to a component in different products. safety requirements to components of a to system under design. However,may for vary a Software Product Line (SPL), thein safety requirements needthe to possible be allocated to a incurred component may vary in different products. Variation design can indeed indeed that change hazards in each each product, their causes, causes, and Variation design can change hazards in product, their and (SPL), theinsafety requirements that needthe to possible be allocated to a incurred component may vary in different products. Variation in design can indeed change the possible hazards incurred in each product, their causes, and can alter the safety requirements placed on individual components in different SPL products. Establishing can alter the placed on components in different products. Variation in safety designrequirements can indeed change theindividual possible hazards incurred in eachSPL product, their Establishing causes, and can alter the safety on individual components in different SPL products. Establishing common SILs for requirements components placed of aa large large scale SPL SPL by considering considering all possible possible usage scenarios, scenarios, is common SILs for components of scale by all usage is can alter the safety requirements placed on individual components in different SPL products. Establishing common SILs for components of a large scale SPL by considering all possible usage scenarios, is desirable for economies of scale, but it also poses challenges to the safety engineering process. In this desirable SILs for economies of scale,ofbut it alsoscale posesSPL challenges to the safety engineering process. In this common for components a large by considering all possible usage scenarios, is desirable economies of scale, it also poses challenges safety engineering process. In The this paper, we wefor propose method for but automatic allocation of SILs SILsto tothe components of aa product product line. paper, propose aa method for automatic allocation of of line. desirable for economies of scale, but it also poses challenges to to thecomponents safety engineering process. In The this paper, weis propose a method automatic allocation of SILs to components of a product line. The approach applied to to Hybridfor Braking System SPL design. design. approach applied aa Hybrid Braking System SPL paper, weispropose a method for automatic allocation of SILs to components of a product line. The approach is applied to a Hybrid Braking System SPL design. approach is applied to a Hybrid Braking System SPL design. © 2015, IFAC (International Federation of Automatic Control) by Elsevier Ltd. All rights reserved. Keywords: safety-critical safety-critical product product lines; lines; safety safety requirements; requirements; Hosting SILs; requirements requirements allocation. Keywords: SILs; allocation. Keywords: safety-critical product lines; safety requirements; SILs; requirements allocation. Keywords: safety-critical product lines; safety requirements; SILs; requirements allocation.   

1. INTRODUCTION INTRODUCTION 1. 1. INTRODUCTION 1. INTRODUCTION The term term Software Software Product Product Line (SPL) (SPL) refers refers to to aa software software The Line The term Software Product Line (SPL) software refers to areuse software development approach that enables software reuse by development approach that enables by The term Software Product Line (SPL) refers to a software development approach that enables software reuse by allowing the creation of software applications through the allowing the creation of software applications through the development approach that enables software reuse by allowing the creation of software applications through the composition of common and variable features that that address composition common variable features address allowing the of creation of and software applications through the composition of common and variable features that address the of domain (Clements and the requirements requirements of aa particular particular domain (Clements and composition of common and variable features that address the requirements a particular domain and Northrop, 2001). Features represent desired functionality Northrop, 2001). of Features represent desired(Clements functionality the requirements of a particular domain (Clements and Northrop, 2001). Features represent desired functionality from the user point of view (Lee et al. 2002). Product line from the user pointFeatures of view represent (Lee et al. desired 2002). functionality Product line Northrop, 2001). from themaximizes user pointsoftware of view reuse (Lee etacross al. 2002). Product line design products but design products but must must from themaximizes user pointsoftware of view reuse (Lee etacross al. 2002). Product line design maximizes software reuse across products but must still yield safe individual products and this poses research still yield safe individual and this poses but research design maximizes softwareproducts reuse across products must still yield safe individual products and this poses research challenges. challenges. still yield safe individual products and this poses research challenges. challenges. Safety assessment assessment processes processes in in many many industries industries are are moving moving Safety Safety assessment in many are moving towards addressingprocesses safety from from the industries early stages. stages. Safety towards addressing safety the early Safety Safety assessment processes in many industries are moving towards addressing early early stages.and Safety requirements for system are captured are requirements for aa safety systemfrom are the captured are towards addressing safety from the early early stages.and Safety requirements for a system are captured early and are progressively allocated to subsystems and components of the progressively allocated to subsystems and components requirements for a system are captured early andof the are progressively allocated to subsystems and components of the architecture. The process must guarantee that, at the end, if architecture. The process must guarantee at the end, if progressively allocated to subsystems and that, components of the architecture. The process must guarantee that, at the end, if the component requirements are met, the system the component requirements are met, architecture. The process must guarantee that, atthethe system end, if the component requirements are met, the system requirements are also met. This type of allocation of requirements are also met. Thisaretypemet, of allocation of the component requirements the system requirements met. Thisbecause type it ofprovides allocation of requirements is isare seenalso as important important way requirements seen as aa way are also met. Thisbecause type itofprovides allocation of requirements is seen as important because it provides a way in which safety safety is controlled controlled throughout the process and and is in which is throughout process is requirements is seen as important becausethe it provides a way in controlled the process and is notwhich left to to safety emergeis (or not) at at the thethroughout end. The The question question of whether whether not left emerge not) end. of in which safety is(or controlled throughout the process and is notnot leftwe to can emerge (or not) theof end. The question of to whether or transfer this type top-down thinking safety or transfer this at type top-down thinking safety notnot leftwe to can emerge (or not) at theofend. The question of to whether or not we can transfer this type of top-down thinking to safety in SPL design is addressed in this paper. in design is addressed in this or SPL not we can transfer this type of paper. top-down thinking to safety in SPL design is addressed in this paper. in SPL design is addressed in this paper. Safety Safety standards standards use use the the concept concept of of Safety Safety Integrity Integrity Levels Levels Safety standards use the concept of Safety Integrity Levels (SILs) to assign safety requirements with (SILs) standards to assign requirements with different different Safety use safety the concept of Safety Integrity Levels (SILs) to assign safety requirements with different stringencies to components of a system. They take the form stringencies components a system. Theywith take the form (SILs) to to assign safety ofrequirements different stringencies to components of a system. They take the form stringencies to components of a system. They take the form 1 1Research 1Research 1Research

of of Automotive Automotive Safety Safety Integrity Integrity Levels Levels (ASILs) (ASILs) in in the the ISO ISO of Automotive Safety Integrity Levels (ASILs) in the ISO 26262 (ISO, 2011) standard for passenger cars, and 26262 (ISO, 2011) standard Levels for passenger and of Automotive Safety Integrity (ASILs) incars, the ISO 26262 (ISO, Assurance 2011) standard for passenger cars,safety and Development Assurance Levels (DALs) in aerospace safety Development Levels (DALs) in aerospace 26262 (ISO, 2011) standard for passenger cars, and Development Assurance Levels (DALs) in aerospace safety standards (EUROCAE, 2010). SILs are assigned assigned early safety in the the standards (EUROCAE, are early in Development Assurance2010). LevelsSILs (DALs) in aerospace standards (EUROCAE, 2010). SILs are just assigned in the system design design process at at system level, after early the system system system process system level, after the standards (EUROCAE, 2010). SILs are just assigned early in the system process at system level, just are aftergiven the system hazards have identified. These hazards higher hazards design have been been identified. These hazards higher system design process at system level, just are aftergiven the system hazards have been identified. These hazards are given higher or lower SILs depending on how high a risk they pose. As the or lowerhave SILs been depending on how highhazards a risk they pose. As the hazards identified. These are given higher or lower SILs depending on how high a risk they pose. As the system architecture is being refined, SILs assigned to systemsystem is being assigned to systemor lowerarchitecture SILs depending on refined, how highSILs a risk they pose. As the system architecture is being refined, SILs assigned to systemlevel hazards are iteratively allocated to subsystems and level hazards are iteratively allocated subsystems and system architecture is being refined, SILs to assigned to systemlevel hazardsASIL are iteratively allocated to subsystems and components. Decomposition is that components. Decomposition is aa process process that allows allows level hazardsASIL are iteratively allocated to subsystems and components. ASIL Decomposition is a process that allows for safety-critical architecture to to is meet particular target for aa safety-critical architecture meet aa particular target components. ASIL Decomposition a process that allows for a safety-critical to meet particular target ASIL assigned to to aaarchitecture hazard without without all aa components components that ASIL assigned hazard all that for a safety-critical architecture to meet particular target ASIL assigned to a hazard without all components contribute to the theto hazard hazard having to meet meet that target. target. that For contribute to having to that For ASIL assigned a hazard without all components that contribute if to thehazard hazardcan having to meet only that target. For example, be when example, be caused caused when two two contribute ifto aathehazard hazardcan having to meet only that target. For example, if a hazard can be caused only when two independent components fail together, these components can independentif components theseonly components can example, a hazard fail can together, be caused when two independent components fail together, these components can share the responsibility of meeting the ASIL allocated to that share the responsibility meeting the ASIL allocated to that independent componentsoffail together, these components can share the responsibility of meeting the ASIL allocated to that hazard, rather than each one having to meet the original ASIL hazard, than each of onemeeting having the to meet originaltoASIL share therather responsibility ASILthe allocated that hazard, than each one having to meet the original ASIL in full. in full. rather hazard, rather than each one having to meet the original ASIL in full. in full. 26262 defines an integer algebra for ASIL ISO ISO 26262 defines an integer algebra for ASIL ISO 26262 defines integer algebra for about ASIL decomposition which is is an loosely derived from rules rules decomposition which loosely derived from ISO 26262 defines an integer algebra for about ASIL decomposition which is loosely derived from rules about combining probabilities. probabilities. Each ASIL ASIL is from equivalent to an combining Each is equivalent an decomposition which is loosely derived rules to about combining probabilities. ASIL is equivalent to C= an integer QM Management)=0, A=1, integer value: value: QM (Quality (QualityEach Management)=0, A=1, B=2, B=2, combining probabilities. Each ASIL is equivalent to C= an integer value: QM (Quality Management)=0, A=1, B=2, C= 3, and D=4. The ASIL algebra defines that if n components 3, and D=4. algebra defines that if A=1, n components integer value:The QMASIL (Quality Management)=0, B=2, C= 3, andfail D=4. The ASIL algebra defines that hazard, if n components must simultaneously to aa given the must simultaneously to cause cause given the total total 3, andfail D=4. The ASIL algebra defines that hazard, if n components must fail simultaneously to cause a given hazard, theto total ASIL assigned to these n components must add up the ASIL fail assigned to these ntocomponents musthazard, add up the must simultaneously cause a given thetototal ASIL assigned to these n components must add up to the ASIL of the hazard they originate. So, two redundant ASIL assigned of the hazard originate. must So, two to thesethey n components add redundant up to the ASIL of the hazard they originate. So, two redundant components assuring function ofSo,ASIL ASIL D might components aa function might ASIL of the assuring hazard they originate.of two D redundant components assuring a function of ASIL ASIL B D because might individually only be required to meet ASIL B because individually only be required to meet components assuring a function of ASIL D might individually only be required to meet ASIL B because individually only be required to meet ASIL B because

supported supported by by CNPq CNPq grant: grant: 152693/2011-4, 152693/2011-4, and and CAPES CAPES Brazilian Brazilian research research agencies. agencies. supported by CNPq grant: 152693/2011-4, and CAPES Brazilian research agencies. Research supported by CNPq grant: 152693/2011-4, and CAPES Brazilian research agencies. 2405-8963 © 2015, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Copyright © 2015 IFAC 1309 Copyright 2015 responsibility IFAC 1309Control. Peer review©under of International Federation of Automatic Copyright © 2015 IFAC 1309 10.1016/j.ifacol.2015.09.706 Copyright © 2015 IFAC 1309

SAFEPROCESS 2015 1310 September 2-4, 2015. Paris, France

André L. de Oliveira et al. / IFAC-PapersOnLine 48-21 (2015) 1309–1314

together they produce the total required ASIL value (2 + 2 = 4). Higher ASILs mean higher costs, because meeting more stringent safety requirements typically requires additional safety measures, more effort, and components of higherquality. Therefore, the ASILs assigned to a component significantly affect its development and production costs. ASIL decomposition allows designers to efficiently allocate requirements so that they can meet the safety requirements without being unnecessarily stringent or expensive. Recent Model-Based Safety Assessment (MSBA) techniques provide frameworks for SILs allocation, by automatically identifying combinations of component failures that lead to system hazards, and therefore locating opportunities for SIL decomposition. HiP-HOPS (Hierarchically Performed Hazard Origin & Propagation Studies) (Papadopoulos et al. 2011) is an advanced MBSA technique that provides such an approach for the process defined in the ISO 26262 standard. HiP-HOPS implements a combination of model-based, automated Fault Tree Analysis (FTA) and Tabu Search (Azevedo et al. 2013) meta-heuristic optimization algorithm that facilitates optimal ASIL allocation and has shown to scale up to complex systems. Although application of the MBSA process to SPL design would be beneficial, this is not straightforward. As safety is context-dependent, hazards, their causes, and the requirements allocated to SPL components may change according to the selection of SPL variants in a particular product (Habli, 2009; Habli et al. 2007). Such variation may change the safety requirements (i.e., the SILs) placed on components in different products of the SPL. Thereby, establishing safety requirements for SPL components requires finding the SILs allocated to those components in different products. If a component is allocated different SILs in different products then the highest requirement must be met for the component to be safely used across these SPL products. This type of allocation would allow developers to meet their responsibilities in order to assure the safety of the SPL architecture, and to comply with safety standards, without incurring the unnecessary high costs of complete reanalysis and reallocation of safety requirements as traditionally demanded for each product. However, the establishment of product line component ASILs in a large scale SPL, like a family of automotive powertrain controllers with potentially hundreds of members, can be challenging. Safety standards do not show how this can be done on a large scale, e.g. via automation, and no framework has yet been developed to support the automatic allocation of SILs in the context of SPLs. Indeed, although emerging SIL allocation tools and techniques (Azevedo et al. 2014; Parker et al. 2013; Papadopoulos et al. 2010; Mader et al. 2012; Bieber et al. 2011; Zhang et al. 2010; Lee et al. 2009; Sallak et al. 2008; Dhouibi et al. 2014) provide the capability of automatic allocation to single SPL products, they do not address product lines. The novelty of this paper is a concept for allocation of SILs to components in product line design, and a method and tool to provide the automated support to apply that concept. The tool extends upon HiP-HOPS (Azevedo et al. 2014) and is

applied to the automotive domain. The paper is organized as follows. Section 2 provides an overview of HiP-HOPS and its Tabu Search ASIL allocation approach. Section 3 describes the method and tool to automatically allocate SILs to SPL components from the analysis of multi-product SILs allocations. Section 4 presents the case study and evaluation, and section 5 shows related work. Finally, section 6 presents the conclusion and future research. 2. HiP-HOPS AND TABU SEARCH HiP-HOPS (Papadopoulos et al. 2011) is a method and tool for Model-based Safety Analysis, in which system models showing components and material energy, and data transactions among them are augmented with local failure logic. These models are then analysed generating fault trees and Failure Modes and Effects Analysis (FMEAs). The HiPHOPS tool receives the system description as input in an XML schema, but the various implementations of the tool, e.g. its connection to MATLAB/Simulink, also provide a failure editor that can be used together with graphical interfaces to augment the model with safety information. Using this editor it is possible to specify hazards related to system malfunctions, and the failure logic of components described mainly as sets of output deviations and how they are caused by logical combinations of internal component failures and deviations of the component inputs. Once the system models have been annotated with hazards and local failure logic, HiP-HOPS synthesizes fault trees for each hazard, and then combines them to create an FMEA for the system. HiP-HOPS rationalizes the allocation and decomposition of ASILs to system components, by showing how combinations of component failures lead to system hazards. For allocation to happen, the potential fault propagation of the system must be defined, to determine which component(s) potentially contribute to each function failure. The rationale is that a component that contributes to a system failure only in conjunction with other components may receive a lower SIL than a component which directly causes the system failure. Thus, the design intention of components, and specifically their ability to detect, mask or propagate failures, influences SIL allocation across the architecture. For example, some components may have been designed to fail silent in response to failure, possibly transforming a severe failure mode into a less severe failure mode. The contribution of components to hazards can be established using the analysis capabilities of HiP-HOPS and the synthesized fault trees produced by the tool. A fault tree, for instance provides the minimal cut sets (i.e. combinations of basic events) that result in system-level hazards, and therefore can be used to identify ASIL Decomposition opportunities. It is often the case that the failure of the same component is present in multiple cut sets and all of them must be taken into account when finding the most advantageous allocation solutions. Furthermore, with the increase in the number of components within a system, the number of ASIL allocation possibilities increases exponentially. Early implementations of exhaustive algorithms (Papadopoulos et al. 2010) for allocation in HiP-HOPS were found inadequate in coping

1310

SAFEPROCESS 2015 September 2-4, 2015. Paris, France

André L. de Oliveira et al. / IFAC-PapersOnLine 48-21 (2015) 1309–1314

with the complexity of realistic models. Investigations were, therefore, directed towards meta-heuristics such as genetic algorithms. These optimization algorithms are known to find good solutions, through guided search of the design space. In addition, they are known to be robust in dealing with a variety of problems. Meta-heuristics do not guarantee finding optimal solutions; however, they are capable of providing near optimal allocations within acceptable time spans. Many metaheuristics exist, and recent research has applied some of the most popular ones to the ASIL Allocation optimization problem. Tabu Search (TS) (Azevedo et al. 2014) has shown promising results in both the quality of the solutions found as well as processing times. The TS extension of HiP-HOPS draws from the work of Hansen and Lih (1996) for reliability optimization and it goes by the name of Steepest Descent Mildest Ascent (SDMA). The method consists of iteratively finding the ASIL that by being decremented reduces the cost of a solution (the steepest descent direction). 3. AUTOMATIC ALLOCATION OF SAFETY INTEGRITY LEVELS TO PRODUCT LINE COMPONENTS In this work we extended the above capabilities to enable allocation of safety requirements to components of a product line. The concept extends the capabilities of the HiP-HOPS method and tool for application in SPL design. The key idea concerns the ability to automatically instantiate a large set of products from an SPL in a variable SPL model augmented with possible hazards and the local failure logic of components. Products are then sent in turn to HiP-HOPS, which performs ASIL allocation for each product. Components may receive different allocations in different products, so the ability to use safely a component across a range of products means selecting the highest allocation given by this analysis. This is the basis of the proposed method for automatic allocation of safety requirements to SPL components from the analysis of requirements allocation results performed in multiple SPL products. The method was implemented in a prototype tool developed using Java as a compliment to HiP-HOPS. The method requires a pre-processing step to support the augmentation of SPL architecture models with hazards and failure logic information, and the enumeration of all products of an SPL via resolution of variability (i.e. product derivation). The latter can be a selective manual process or an automated process. The automated implementation of this feature has been done in MATLAB/Simulink using a set of mechanisms to specify variability and with the support of the Hephaestus/Simulink (Steiner et al. 2013) SPL variability management tool. Alternative SPL tools such as Common Variability Language (CVL) implemented in Eclipse (Haugen et al. 2008) can also be used. Simulink variability patterns (Steiner et al. 2013; Botterweck et al. 2010) representing optional (Enabler subsystems), alternative (Switch blocks), and inclusive-or (Integration blocks) features have been used for modelling variation in the SPL architecture. The Hephaestus/Simulink tool was used in

1311

this approach to support the variability management in Simulink models described using these patterns. The automated derivation of the enumerated SPL product models augmented with hazards and failure logic requires the specification of the configuration knowledge. This provides a set of rules showing how SPL design assets, hazards, and failure logic can be composed in a product. Rules are specified according to feature model constraints. The feature model captures structural or conceptual relationships between common and variable functions of products of a domain (Lee et al. 2002). SPL configuration knowledge is specified by means of Hephaestus/Simulink by applying the following steps: 1) specify the feature expressions in the scope of the usage scenarios described in the feature model. A feature expression may include a single feature or a combination of two or more features; 2) for each feature expression, determine the SPL design elements to be included and excluded; and 3) specify the hazards, the allocated safety requirements, and the failure logic to be included/excluded in each feature expression. After performing these steps, the mapping between product line features, design elements, hazards, the allocated safety requirements, and component failure logic is obtained. Additional details on how to use SPL variability management tools to specify the configuration knowledge can be found in (Steiner et al. 2013). Finally, the variability management tool was adapted by implementing an instantiation script with the support of a feature model solver, in this case the T-wise covering arrays algorithm (Johansen et al. 2012), to automatically derive a set of SPL products according to the constraints specified in the feature model. Once a range of SPL products have been enumerated from a variable SPL architecture model, the products (i.e., system models annotated with failure information) are then provided to HiP-HOPS for analysis. The ASIL allocations generated by applying HiP-HOPS to the enumeration of the SPL products are the inputs to the method and tool developed in this paper. HiP-HOPS exports the ASIL allocation of each individual product in an XML file. In the proposed method, these files are parsed and the analysis is performed. Firstly, the XML files are analysed one by one to obtain the ASILs allocated to SPL components in each product. This is done by analysing the ASILs allocated to the failure modes associated to each SPL component in each individual product. The most stringent ASIL allocated to a failure mode associated with particular component is the component ASIL for that product. For each product, this is repeated for all components belonging to the product. After obtaining the ASILs allocated to product line components in each individual product, for each SPL component, the analysis is performed as follows: the ASILs allocated to a particular SPL component in different products are analysed in order to verify the most stringent ASIL allocated to that component across the SPL. Thus, the ASIL that each SPL component should meet is obtained, and the results, i.e. the ASILs allocated to all SPL components are exported in XML file format.

1311

SAFEPROCESS 2015 1312 September 2-4, 2015. Paris, France

André L. de Oliveira et al. / IFAC-PapersOnLine 48-21 (2015) 1309–1314

4. EVALUATION The method and tool were applied to a Hybrid Braking System (De Castro et al. 2011) automotive product line (HBS-SPL). Hazard analysis and the definition of local failure logic were performed based on the failure logic analysis technique supported by HiP-HOPS, and taking into account the interactions between HBS-SPL components expressed in the feature model. Three HBS-SPL products (i.e., usage scenarios) were considered in the evaluation of the proposed method: HBS four wheels braking (HBS-4WB), front wheels braking (HBS-FWB), and rear wheels braking (HBS-RWB). The HBS-SPL is a prototype automotive braking system SPL designed in MATLAB/Simulink. HBS-SPL is meant for electrical vehicles integration, in particular for propulsion architectures that integrate one electrical motor per wheel. The term hybrid comes from the fact that braking is achieved through the combined action of the electrical In-Wheel Motors (IWMs) and frictional Electromechanical Brakes (EMBs). One of the most important features of this system is that the integration of IWM in the braking process allows an increase in the vehicle’s range: while braking, IWMs work as generators and transform the vehicles kinetic energy into electrical energy that is fed into the powertrain battery. IWMs have, however, braking torque availability limitations at high wheel speeds or when the powertrain battery is close to full state of charge. EMBs are introduced to provide the torque needed to match the total braking demand. HBS-SPL components can be combined in different ways according to the constraints specified in the HBS-SPL feature model presented in Fig. 1. The feature model was designed using a cardinality-based notation (Czarnecki et al. 2004).

amount of braking torque to be produced by each actuator. Commands are generated accordingly and sent to the power converters to control the two braking devices. While braking, power flows from the IWMs to the Powertrain Battery and from the vehicle’s low voltage Auxiliary Battery to the EMBs. The elements of the vehicle’s power architecture should be regarded as subsystems that include multiple components – the Powertrain Battery, for example, integrates a Battery Management System (BMS) which is composed by complex hardware and software elements. Hazards can arise in this system from the interaction between design elements in a range of usage scenarios. Safety requirements placed to a particular HBS-SPL hazard may also change according to contextual elements such as operational environment, safety standards, and regulations. These elements can be represented in an SPL context model (Lee et al. 2002). In this paper we have limited ourselves to performing the HBS-SPL hazard analysis based only on the SPL feature model. Product line features stand for system functions implemented by design elements (e.g. system, subsystems, components). Performing a hazard analysis covering all possible scenarios for HBS-SPL would yield voluminous results. Nevertheless, scoping the hazard analysis to a set of products has shown some degree of reuse for safety analysis assets (e.g. fault trees, FMEA, ASIL allocation). The Wheel Braking variation point specified in the HBS-SPL feature model was considered in performing the hazard analysis. From the analysis of the Wheel Braking variation point and mandatory elements from HBS-SPL, as mentioned earlier, the following usage scenarios were established: HBS-4WB; HBS-FWB; and HBS-RWB. These scenarios were analysed from the safety perspective. Table 1 presents the identified hazards, their causes, and the allocated ASILs (Automotive Safety Integrity Levels). Table 1 also presents the association between the hazards and the usage scenarios by means of the column “Scenario”. Table 1. HBS-SPL hazards and ASIL allocation. Scenario HBS4WB

1312

Causes Omission of all brake unit actuators outputs.

ASIL D

No braking three wheels

Omission of brake unit1, and brake unit2, and brake unit3 actuators outputs. Omission of brake unit1 and brake unit2 actuators outputs. Omission of brake unit3 and brake_unit4 actuators outputs. Omission of brake unit1 and brake unit4 actuators outputs or Omission of brake unit2 and brake unit4 actuators outputs. Incorrect Value of all brake unit actuators outputs Omission of brake unit1 and brake unit2 actuators outputs. Incorrect Value of brake unit1 and brake unit2 actuators outputs. Omission of brake unit3 and brake unit4 actuators outputs. Incorrect Value of brake unit3 and brake unit4 actuators outputs.

D

No braking front No braking rear No braking diagonal

Fig. 1. HBS-SPL feature model. The HBS-SPL feature model includes wheel braking alternative features: Brake_Unit1, Brake_Unit2, Brake_Unit3, and Brake_Unit4 aimed to provide the braking for each wheel. The three HBS products earlier described have a common principle: a Mechanical Pedal is responsible for capturing the driver’s braking demands; an Electronic Pedal senses these actions and transforms them into braking requests for each wheel that is equipped with braking features; subsequently, it sends these requests via a duplex bus communication system to the Brake Units. Each Brake Unit integrates a Wheel Node Controller that calculates the

Hazard No braking four wheels

Value braking HBSFWB

No braking front Value braking

HBSRWB

No braking rear Value braking

D C C

D D D D D

SAFEPROCESS 2015 September 2-4, 2015. Paris, France

André L. de Oliveira et al. / IFAC-PapersOnLine 48-21 (2015) 1309–1314

It is considered that no braking is being produced in a wheel whenever both braking devices of that wheel (an IWM and an EMB) are omitting their outputs. Braking with an incorrect value happens when at least one of the braking actuators is providing braking torque that is higher or lower than the values demanded. In order to simplify the case study, we have only discussed the allocation of ASILs to product line hazards on the basis of the severity (rather than the full ISO 26262 risk assessment process). In a product line hazard analysis, different ASILs can be assigned to the same hazard considering different usage scenarios for SPL components. For example, the ASIL allocated to the “No braking rear” hazard is more stringent in HBS-RWB scenario and less stringent in HBS-4WB. Causes for a particular hazard may also change according to how product line components can be composed in a product. The causes for the “Value braking” hazard in HBS-FWB are different from the causes for that hazard in HBS-RWB. HBSSPL hazards and ASIL allocation information are stored by HiP-HOPS in the failure model. From the analysis of HBSSPL hazards (Table 1), 77 failure logic expressions were added to 30 HBS-SPL components; through different fault propagations, the causes described in these expressions combine and give rise to hazards in different product configurations. This process was automated as product models augmented with hazards and local failure logic were sent to HiP-HOPS which created fault trees, failure cut sets, and FMEA results for each HBS-SPL product. The cut sets generated for the HBS-SPL products are the inputs for the HiP-HOPS allocation algorithm. The allocation was performed for each HBS-SPL product based on the following example cost heuristic that expresses the relative cost jumps of developing a component according to the different ASILs: 0 (ASIL QM), 10 (ASIL A), 20 (ASIL B), 40 (ASIL C), and 50 (ASIL D). This expression was used for illustrative purposes, but any other that the system designer finds more suitable can be used instead. The HBS-4WB, HBS-FWB, and HBS-RWB ASIL allocations provided by HiP-HOPS analysis were the inputs for the proposed method and tool performing the analysis to allocate ASILs to SPL components. The ASILs allocated to 30 HBS-SPL components in three different products were analyzed and the process took 14 seconds to complete. Table 2 presents the ASILs allocated to HBS-SPL components in each product, and the final ASILs allocated to HBS-SPL components (column “ASIL”). Due to space limitations, Table 2 presents ASILs allocated to 16 HBS-SPL components. ASILs allocated to a particular HBS-SPL component may change according to the product. For example, the ASILs allocated to Brake_Unit1, Brake_Unit1.EMB, and Brake_Unit1.EMB_Power_Converter components are respectively “A”, “A”, and “A” in HBS-4WB, and “QM”, “B”, and “B” in HBS-FWB. The ASIL costs related to each HBS-SPL product ASIL allocation was also generated by the tool along with the ASIL cost for the HBS-SPL (cell “Cost for the MAX ASIL” on Table 2). It is higher than the product costs as it represents the worst case where any component of

1313

the SPL is designed to be safely used across all SPL products considered by the analysis. Table 2. HIP-HOPS Tabu Search ASIL decomposition results for HBS-SPL products. HBS-SPL Component Name Auxiliary_Battery Brake_Unit1 Brake_Unit1.EMB Brake_Unit1.EMB_ Power_Converter Brake_Unit1.IWM Brake_Unit1.IWM_ Power_Converter … Brake_Unit4 Brake_Unit4.EMB Brake_Unit4.EMB_ Power_Converter Brake_Unit4.IWM Brake_Unit4.IWM_ Power_Converter Communication_Bus1 Communication_Bus2 Electronic_Pedal Mechanical_Pedal Electronic_Pedal Cost

HBS4WB ASIL D (4) A (1) A (1) A (1)

HBSFWB ASIL D (4) QM (0) B (2) B (2)

HBSRWB ASIL D (4) -

MAX ASIL

A (1) A (1)

B (2) B (2)

-

B (2) B (2)

… A (1) A (1) D (4)

… -

… B (2) B (2) B (2)

… B (2) B (2) D (4)

QM (0) B (2)

-

B (2) B (2)

B (2) B (2)

B (2) B (2) D (4) D (4) D (4) 520

B (2) B (2) D (4) D (4) D (4) 460

B (2) B (2) D (4) D (4) D (4) 470

B (2) B (2) D (4) D (4) D (4) 730

D (4) A (1) B (2) B (2)

Analysis of the implications on safety requirements of possible usage of components provides useful feedback to the SPL development process, contributing to meeting safety requirements without incurring unnecessary costs. The tool developed for this work was tested against performance requirements in this case study. The processing time to analyze 72 hybrid braking system SPL products was reasonable, about 4 minute and 40 seconds, considering that the complexity of the analysis has increased substantially as the numbers of the products increased. 5. RELATED WORK In earlier work, Papadopoulos et al. (2010) proposed an approach to automatically allocate ASILs to subsystems and components of a hierarchical system model according to ISO 26262. The ASIL allocation and decomposition algorithm was implemented in HiP-HOPS (Papadopoulos et al. 2011). The HiP-HOPS ASIL allocation algorithm was further improved with optimization heuristics to reach an optimal allocation. A penalty-based genetic algorithm (Parker et al. 2013) and Tabu Search (Azevedo et al. 2014) algorithms were implemented to improve the performance of ASIL allocation in large scale systems. Mader et al. (2012) proposed an approach for ASIL allocation focused on finding optimal allocations; a linear programming optimization problem is formulated to discover a solution that minimizes the sum of ASILs assigned across the system architecture. Zhang et al. (2010) proposed a workflow for embedded system development, which includes fault trees, FMEA, and ASIL allocation based on a qualitative risk graph method. Dhouibi et al. (2014) introduced a method for ASIL allocation which is based on interpreting the allocation problem as a system of linear equations. Bieber et al. (2011) presented a theory to formalize the ARP 4754A DAL allocation rules (EUROCAE, 2010) and the

1313

SAFEPROCESS 2015 1314 September 2-4, 2015. Paris, France

André L. de Oliveira et al. / IFAC-PapersOnLine 48-21 (2015) 1309–1314

DALculator tool to support automatic DAL allocation. Lee et al. (2009) presented an approach based on fault trees and their top-events (i.e., probabilities for failure on demand) to derive SILs for system functions according to IEC 61508. A fuzzy probabilistic SILs allocation technique in compliance with IEC 61508 was also proposed by Sallak et al. (2008). Existing tools and techniques for automatic allocation of SILs were not designed to address product lines. These techniques can benefit from the concepts proposed in this paper. 6. CONCLUSION We described a method for allocation of SILs to components in product line design. A prototype tool was developed which performs automatic ASIL allocation for product line components taking into account their possible usage across the product line. We have discussed, both in theory and through an example, how the use of such a method and tool can potentially reduce the cost of SPL development by allocating less stringent ASILs to SPL components whilst meeting safety requirements. Through this technique, it is possible to specify safety requirements for components anticipating their possible use in a number of products. This work addresses an important issue and extends and automates principles enshrined in modern safety standards to address SPL design. Further work needs to be done to elucidate and explain the preparation and automatic resolution of variable models augmented with failure logic that can be used by this method. Additional research is also ongoing to validate this approach in different industrial context. REFERENCES Azevedo, L. S., Parker, D., Walker, m., Papadopoulos, Y., Araujo, R. (2014). Assisted Assignment of Automotive Safety Requirements. IEEE Software 31(1):62-68, IEEE. Azevedo L. S., Parker D., Walker M., Papadopoulos Y., Esteves, A. R. (2013). Automatic Decomposition of Safety Integrity Levels: Optimization by Tabu Search. In Proc. of 2nd Workshop on Critical Automotive applications : Robustness & Safety, of the 32nd SAFECOMP, Toulouse, France. Bieber, P., Delmas, R., Seguin, C. (2011). DALculus Theory and Tool for Development Assurance Level Allocation. In Computer Safety, Reliability, and Security. Springer Berlin Heidelberg, 43-56. Botterweck, G., Polzer, A., Kowalewski, S. (2009). Using higher-order transformations to derive variability mechanism for embedded systems. In 2nd Int. Workshop on Model-Based Architecting of Embedded Systems, MODELS, Denver, USA, pp. 68-82. Clements, P., Northrop, L. (2001). Software Product Lines: Practices and Patterns. Addison-Wesley. Czarnecki, K., Helsen, S., Eisenecker, U. (2004). Staged configuration using feature models. In 3rd Software Product-Line Conf., v. 3154, Boston, USA, Springer Verlag, pp. 266-283. De Castro, R., Araújo, R. E., Freitas, D., (2011). Hybrid ABS with Electric motor and friction Brakes. In 22nd International Symposium on Dynamics of Vehicles on Roads and Tracks, Manchester, UK. Dhouibi, M. S., Perquis, J. M., Saintis, L. Barreau, M. (2014). Automatic Decomposition and Allocation of Safety Integrity Level Using System of Linear Equations. In Proc. of the 4th Int. Conf. on Performance,

Safety and Robustness in Complex Systems and Applications, Nice, France. EUROCAE. (2010). ARP4754A/ED-79A - Guidelines for Development of Civil Aircraft and Systems. Glover, F. (1989). Tabu search-part I. ORSA Journal of Computing, vol. 1, no. 3, pp. 190-206. Glover, F. (1990). Tabu Search-part II. ORSA Journal of Computing, vol 2, pp. 4-32, 1990. Habli, I. (2009). Model-Based Assurance of Safety-Critical Product Lines. Ph.D thesis, Department of Computer Science, The University of York, York, UK. Habli, I., Kelly, T., Hopkins, I. (2007). Challenges of Establishing a Software Product Line for an Aerospace Engine Monitoring System. In Proc. of 11th Int. Software Product Line Conference, pp.193-202. Hansen, P., Lih, K. W. (1996). Heuristic reliability optimization by tabu search. Annals of Operations Research, vol. 63, pp. 321-336. Haugen, O., Moller-Pedersen, B., Oldevik, J., Olsen, G. K., Svendsen, A. (2008). Adding Standardized Variability to Domain Specific Languages. In Proc. 12th International Software Product Line Conference, pp.139,148. ISO. (2011). ISO 26262: Road Vehicles Functional Safety. Johansen, M. F., Haugen, O., Fleurey, F. (2012). An algorithm for generating t-wise covering arrays from large feature models. In Proc. of the 16th Int. Software Product Line Conf., vol. 1. ACM, NY, USA, 46-55. Lee, K., Kang, K. C., Lee, J. (2002). Concepts and Guidelines of Feature Modeling for Product Line Software Engineering. In Proc. of the 7th Int. Conf. on Software Reuse: Methods, Techniques, and Tools, Springer-Verlag, London, UK, 62-77. Lee, Y., Kim, J., Kim, J., Moon, I. (2009). A Verification of Fault Tree for Safety Integrity Level Evaluation. In Proceedings of the ICROS-SICE International Joint Conference, pp 5548-5551. Lin, M. H., Tsai, J. F., Yu, C. S. (2012). A Review of Deterministic Optimization Methods in Engineering and Management, Mathematical Problems in Engineering. Mader, R., Armengaud, E., Leitner, A., Steger, C. (2012). Automatic and optimal allocation of safety integrity levels. In Reliability and Maintainability Symposium (RAMS), Proceedings-Annual. IEEE, 1-6. Papadopoulos, Y., Walker, M., Parker, D., Rüde, E., Hamann, R., Uhlig, A., Grätz, U., Lien, R. (2011). Engineering failure analysis and design optimization with HIP-HOPS. Journal of Engineering Failure Analysis 18.2, 590-608. Papadopoulos, Y., Walker, M., Reiser, M. O., Weber, M., Chen, D., Torngren, M., Servat, D., Abele, A., Stappert, F., Lonn, H., Berntsson, L., Johansson, R., Tagliabo, F., Torchiato, S., Sandberg, A. (2010). Automatic allocation of safety integrity levels. In 1st workshop on critical automotive applications: robustness and safety, ACM. Parker, D., Walker, M., Azevedo, L., Papadopoulos, Y., Araujo, R. (2013). Automatic Decomposition and Allocation of Safety Integrity Levels Using a PenaltyBased Genetic Algorithm. Recent Trends in Applied Artificial Intelligence, Springer-Berlin, 449-459. Sallak, M., Simon, C., Aubry, J. F. (2008). A Fuzzy Probabilistic Approach for Determining Safety Integrity Level. IEEE Transactions on Fuzzy Systems, vol. 16, pp 239-248. Steiner, E. M., Masiero, P. C. (2013). Managing SPL Variabilities in UAV Simulink Models with Pure::variants and Hephaestus. CLEI Electronic Journal, v. 16, n. 1. Zhang, H., Li, W., Qin, J. (2010). Model-based Functional Safety Analysis Method for Automotive Embedded System Applications. In Proc. Int. Conf. on Intelligent Control and Information Processing, pp 761-765.

1314