Operational and System Hazard Analysis in a Safe Systems Requirement Engineering Process – Application to automotive industry

Safety Science 87 (2016) 256–268

Contents lists available at ScienceDirect

Safety Science journal homepage: www.elsevier.com/locate/ssci

Operational and System Hazard Analysis in a Safe Systems Requirement Engineering Process – Application to automotive industry Pierre Mauborgne a,b, Samuel Deniaud c, Eric Levrat d, Eric Bonjour b,⇑, Jean-Pierre Micaëlli e, Dominique Loise a a

PSA Peugeot Citroën, Route de Gisy, 78140 Vélizy-Villacoublay, France Université de Lorraine/ENSGSI, ERPI, EA no 3767, 8, rue Bastien Lepage, Nancy 54010, France IRTES-M3M, UTBM/UBFC, 90010 Belfort Cedex, France d Université de Lorraine, Centre de Recherche en Automatique de Nancy (CRAN) – CNRS, UMR 7039, Campus Sciences, BP 239, 54506 Vandoeuvre-lès-Nancy Cedex, France e Centre de Recherche Magellan, IAE de Lyon, Université Jean Moulin Lyon 3, 6 cours Albert Thomas, 69008 Lyon, France b c

a r t i c l e

i n f o

Article history: Received 23 September 2015 Received in revised form 27 February 2016 Accepted 13 April 2016

Keywords: Safety Systems engineering Hazard analysis Safety requirements MBSE ISO 26262

a b s t r a c t Automotive engineers have to meet evolving customer expectations, particularly growing concerns for safety, by introducing new sophisticated devices like Line Keeping Assistance, Collision Mitigation Braking System or Pedestrian Detection. These devices are composed of electrical components. They are likely to be subject to failures that may impact automobile safety, which means the safety of the vehicle occupants or pedestrians. Recent standards like ISO 26262 aim at mitigating these safety problems. Automobile engineers must prove that they perform safety studies along the design process. Meanwhile, they have to cope with other changes in their engineering practices. Due to the goals of verifying the satisfaction of all requirements, the design offices have introduced new practices based on Systems Engineering (SE) which are based on models. SE tools or processes are based on a functional approach of the system in which dysfunctional aspects are missing. Thus, there is a need to integrate the safety domain into the SE framework in order to improve safety studies and the collaboration between systems engineers and safety specialists. This paper analyzes this issue by focusing on the definition of high-level (or vehicle-level) safety requirements. It proposes a Safe Systems Requirement Engineering Process and a method named Operational and System Hazard Analysis (O&SHA) that helps to specify the high-level safety requirements (called safety goals in ISO 26262). It is based on a Model-Based Systems Engineering approach (MBSE) which integrates safety aspects. The added value of the proposed method is illustrated by applying it to two case studies. Ó 2016 Elsevier Ltd. All rights reserved.

1. Introduction Due to stakeholders’ greater demands for safety, automotive engineers have to take into account stringent safety requirements by using specific methods, tools or standards, and performing safety-focused processes or activities. Since 2011, some of them have been also adopting ISO 26262 standard (ISO 26262, 2009) that deals with functional safety of road vehicles. This standard

⇑ Corresponding author. E-mail addresses: [email protected], pierre.mauborgne@ univ-lorraine.fr (P. Mauborgne), [email protected] (S. Deniaud), eric.levrat@ univ-lorraine.fr (E. Levrat), [email protected] (E. Bonjour), jean-pierre. [email protected] (J.-P. Micaëlli), [email protected] (D. Loise). http://dx.doi.org/10.1016/j.ssci.2016.04.011 0925-7535/Ó 2016 Elsevier Ltd. All rights reserved.

states that car designers perform safety assessment activities and produce specific safety deliverables. Safety activities related to the external view of the system correspond to a rough system definition (‘‘item definition” in ISO 26262) and a definition of high-level safety requirements based on hazard analysis (‘‘Hazard Analysis and Risk Assessment” in ISO 26262). These requirements are called safety goals in the automotive sector. They are evaluated with a criterion called Automotive Safety Integrity Level (ASIL) being defined as ‘‘one of the four levels to specify the item’s or element’s necessary requirements of ISO 26262 and safety measures for avoiding an unreasonable residual risk, with D representing the most stringent and A the least stringent level”. In ISO 26262 (2009), a key phase is the ‘‘Concept phase”. It is composed of the ‘‘Hazard Analysis and Risk Assessment” activity that concludes with the definition of Safety Goals and the Functional Safety

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

Concept activity. This latter activity derives the functional safety requirements, from the safety goals, and ‘‘allocate them to the preliminary architectural elements of the item or to external risk reduction measures in order to ensure the required functional safety”. To comply with the safety goals, the functional safety concept specifies the safety mechanisms and safety measures in the form of functional safety requirements. To cope with safety requirements and with the complexity of the electronic systems they induce, car manufacturers also adapt their Systems Engineering (SE) practices defined in standards like ISO 15288 (2002) or IEEE 1220 (2005). The main technical upstream design processes that are identified in ISO 15288 are: the Stakeholder Requirement Definition (SRD), and the System Requirement Analysis (SRA). These processes are focused on an operational view of the system. They aim at providing system requirements to the following architectural design processes. Current SRA and SRD processes include very limited safety activities. For example, they do not take into account any preliminary hazard analysis (PHA), which consists in identifying, assessing and classifying dysfunctional scenarios related to hazardous events (Vincoli, 2014). SRA, SRD, and safety analysis processes and activities are usually performed with silo mentality. Thus safety engineers may misunderstand the system definition and even perform a redundant functional analysis. These issues may induce design errors. Moreover, the safety analysis is not immediate. Hence results may not be applicable by systems engineers. Furthermore, according to Alexander and Maiden (2005), it is necessary during the system design to jointly determine operational scenarios and ‘‘negative scenarios and misuse case”. The unsatisfactory situation we have depicted shows that there is a need for a better integration of safety activities and SE activities. Our conception of Safe Systems Engineering (SSE) is that system engineers should perform safety activities that do not require expertise whereas safety engineers should lead thorough safety assessments requiring specialized expertise. To bridge the gap toward a SSE, we aim at defining a framework composed of a conceptual model and SE processes. A current trend in SE is to develop Model-Based approaches representing the system from operational, functional, physical ‘‘views” (defined in (IEEE 1471, 2000)). Model Based Systems Engineering (MBSE) enables designers to define and to simulate the system structure and behavior with interrelated models. Therefore, MBSE could be a relevant basis to integrate safety activities into SE models and processes. It enables to perform traceability of safety requirements, improve safety requirements justification and integrate safety recommendations into system models. In this paper, the focus is then on Hazard Analysis and Risk Assessment concerning the definition of high-level safety requirements (safety goals) that should be performed by system engineers. This paper deals with a method to determine and classify dysfunctional scenarios in order to define the safety goals based on models compliant with ISO 26262 standard. This method is called Operational and System Hazard Analysis (O&SHA), instead of PHA because there is no determination of requirements and no model-based approach in PHA. After a state-of-art of approaches aiming at linking SE and Safety domains, this paper proposes a conceptual model integrating concepts relevant to Safe Systems Requirement Engineering (SSRE). Then SRD and SRA processes are refined in order to integrate safety aspects. Based on these enriched processes, we shall propose the O&SHA compliant to ISO 26262 and ISO 15288 standards. Then the proposed method is applied to two cases that concern a dysfunctional behavior of the car, i.e. the unintended acceleration of the vehicle and the loss of brake. Finally the value of the proposed method is discussed.

257

2. Safety and systems engineering, a missing link The first safety analysis of the system that aims at defining and classifying critical dysfunctional scenarios is known as PHA. Vincoli (2014) sets out three steps to achieve it: identifying dysfunctional scenarios, assessing them and proposing a risk coverage (or mitigation) that could be avoidance scenarios. We can retrieve occurrences of this activity as Hazard and Risk Analysis in the functional safety standards (IEC 61508, 1998), as ‘‘Aircraft (or System) PHA” in aeronautical standards (ARP 4761, 1996), as ‘‘Risk assessment” in machinery standards” (Hiettiko et al., 2011) or as ‘‘Hazard Analysis and Risk Assessment” in automotive standards (ISO 26262, 2009). Even if these standards give specifications that are more detailed than the usual PHA, they do not propose any specific framework and methodology to precisely identify dysfunctional scenarios. This activity remains based on engineers’ empirical knowledge and projects feedback. IEC 61508 and ISO 26262 standards provide a framework to implement methodically PHA. The automotive functional safety standard (ISO 26262, 2009) specifies inputs (item definition), a sub-process and deliverables. Unfortunately it does not clarify the links between functional analysis and the hazard analysis. In ISO 26262 (2009), this latter activity is subsequent to the functional analysis. But, as Jang et al. exposed in (Jang et al., 2015), there is no method to fulfill this activity framework. These authors only proposed a method to determine ASIL of a safety. de Oliveira et al. (2014) presented a safety analysis process based on the HipHops software, which takes into account architecture design. The drawback of this process is the weak integration of safety activities which are still performed separately from the mainstream design activities. Another PHA process is proposed by Sinha (2011). Compliant with ISO 26262 (2009), this process includes design activities and may be a relevant basis concerning the determination of dysfunctional scenarios. Kemmann (2015) elaborated a structured approach of Hazard Analysis and Risk Assessment based on the formalization and the assessment of operational situations. However there is no proposal in the related literature concerning the assessment of dysfunctional scenarios and the way of avoiding many analyses of non-critical dysfunctional scenarios. Since there is no formal process to generate the safety goals of the vehicle functions, another answer would be to adapt a method performed at another stage of the design process or to instantiate a more global approach. Two types of approaches dealing with safety and SE are then distinguished: model transformation-focused ones (Yakymets et al., 2012), (Papadopoulos and McDermid, 1999) vs. process-focused ones (David et al., 2010). About model transformation approaches, Yakymets et al. (2012) selected several target safety languages as AltaRica (Kloul et al., 2013) or NuSMV (Cimatti et al., 2002) to perform safety analysis. After annotating SysML diagrams (Block Definition Diagram, Internal Block Diagram or IBD, and State Machines), the authors carried out a transformation of SysML models (OMG, 2012) to the target model. Papadopoulos and McDermid (1999) chose to focus on the generation of fault trees and Failure Mode and Effects Analysis (FMEA) from IBD. The enrichment of a component by analysis of its logical dysfunctional behavior and the links between these components enables to propagate failures and to get reports. The authors applied their method for automotive embedded systems with EAST-ADL for functional safety (Chen et al., 2011). However, there are deficiencies with SE standards and there is no method to determine Safety Goals. About process approaches, ISO 15288 (2002) or IEEE 1220 (2005) standards add activities regarding safety. However these activities are performed in parallel of other activities of the main-

258

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

stream design process. Leveson (2011) proposed safety processes based on systems theory with STAMP. It is essentially based on constraints and control loops, which is a partial view of the system model. It does not concern system as a black box with deviation of flows. David et al. (2010) proposed a method to perform FMEA by determining the necessary information either in the functional model or in a specific database (i.e. generic failure modes). Cressent et al. (2012) integrated this method into a mainstream design process, clarifying the links between safety and SE. Nevertheless, the proposed method does not integrate some safety activities which can be performed by systems engineers. We agree with Ericson (2005) concerning the fact that ‘‘experience with, or a good working of, the particular type of system and subsystem is necessary in order to identify and analyze all hazards.” So, the engineer who has greater knowledge about the system should perform hazard analysis. Moreover, when Ericson wrote that ‘‘The PHA methodology is uncomplicated and easily learned”, he underlines the fact that a safety expert is not required to perform this activity. According to Leveson (2004), the selection of hazardous events is subjective. So, it is very important to have a method that leads to an objective choice of dysfunctional scenarios based on specific criteria. Moreover, a promising way is to integrate some safety activities into a SSRE process based on the enrichment of shared models. Thus, the proposed O&SHA method supports SSRE because it enriches PHA and concerns the operational view at the system level. 3. A Safe Systems Requirement Engineering (SSRE) conceptual model In this section, we identify the key requirements for SSRE conceptual models, and then we propose a view depicting the concepts related to the definition of system requirements and Safety Goals. This view should be a basis to explicit relations between SE concepts and safety concepts and so to define Safety Goals with enriched SE models. 3.1. Key requirements of the conceptual model According to Rausand (2004), there is no systematic methodology to implement PHA. Each concerned domain (like safety or systems engineering) has its own concepts and standards. Therefore, there are different definitions for the same concept. These conceptual weaknesses motivate the elaboration of the below SSRE Conceptual Model. Table 1 defines five key requirements for this model. This list of requirements has been defined after debates with systems engineers and safety engineers of an automaker design office. Existing conceptual models do not satisfy these requirements. The one proposed in (Pfister et al., 2011) depicts precisely SE concepts, but there is a lack of safety concepts. Chalé et al. (2011) model deals with links between SE and ISO 26262 (2009), but it

Table 1 Requirements for the SSRE Conceptual Model. Reference

Content

Req1

The model shall be compliant with the state-of-the-art methods of safety analysis and systems engineering It identifies key concepts for each safe systems engineering process It shows the links between system engineering and safety It is simple (less than 20 concepts) (parsimony) It provides a common language among the different designers (systems architects, safety engineers) It shall be validated by the definition of a Safe Systems Engineering process

Req2 Req3 Req4 Req5 Req6

is too generic to satisfy Req1, Req2 and Req5 (see Table 1). Moreover, key safety concepts are not identified, for instance: hazard, dysfunctional scenario, harmful event. There is a unique view: concepts are not gathered according to their use in each process. The conceptual model proposed by Deniaud et al. (2010) contains relevant SE and safety concepts and its structure separates concepts according to each SE process. However it does not mention any SSRE process. Thus, Req6 is not satisfied. 3.2. Structure of the proposed SSRE conceptual model As in the models elaborated by Chalé et al. (2011) and Deniaud et al. (2010), the proposed conceptual model is based on the analysis of key standards, i.e. IEEE 1220 (2005), ISO 15288 (2002) and SEBoK (Pyster and Olwell, 2013) for SE concepts, and ISO 26262 (2009) for safety concepts. In order to satisfy the above requirements, the structure of models is divided into different views corresponding to SE processes. Fig. 1 depicts the SSRE conceptual model that corresponds to an operational view of systems engineering. The diagram can be divided into two groups of concepts. The first group (on the left side of the dotted line) is associated to SE domain. The second group (on the right side) is related to safety concepts that will enable to elaborate and assess dysfunctional scenarios. 3.2.1. Concepts related to the operational view of SE A system satisfies stakeholder needs and constraints that are expressed with stakeholder requirements. It fulfills a mission in an environment (or context) during a life cycle. This last one can be refined in operational situations in which system is in an operational mode. An operational situation is defined as a stationary state composed of a state of the system and conditions of the environment. To design it, stakeholder requirements will be translated into technical requirements thanks to system analysis. 3.2.2. Concepts related to dysfunctional scenarios and safety goals According to ISO 26262 (2009), hazard is a ‘‘potential source of harm caused by a malfunctioning behavior” of the system and hazardous event is the ‘‘combination of a hazard and an operational situation”. ISO 26262 defines an operational situation as a ‘‘scenario that can occur during a vehicle’s life”. As mentioned above, we define an operational situation as a stationary state composed of a state of the system and conditions of the environment. This definition clearly separates situation and scenario. Situation is related to a stationary state, in which operational scenarios describe interactions between the system and its environment. This proposal is consistent with ISO 15288 (2002). Moreover, we consider hazard as deviations of nominal output flows (flow deviation) of the system under analysis. The environment and vehicle occupants may generate Environmental Conditions Favorable to Hazard (ECFH), which are not explicitly defined in ISO 26262 standard. The apparition of hazard with ECFH corresponds to a hazardous event that generates a hazardous situation. A hazardous situation is a specific operational situation in which the system is in a degraded mode with ECFH. A safe state is another specific operational situation where the state of the system is safe for the environment. A harmful event (such as a shock) triggers the transition from a hazardous situation to a harmful situation which is a situation with harm (damage associated with severity) for at least one element of the environment. In order to reduce risk associated to this hazard, it is possible to define a Safety Goal associated with an ASIL characterized by a combination of three criteria: Exposure, Controllability and Severity. The probability of Exposure of hazardous situation is determined either qualitatively or quantitatively. If the qualitative criterion is used, the probability of Exposure is defined by 4 classes in automotive domain (E1 – low, E2, E3, E4 – high probability). The

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

259

Fig. 1. Proposal of a safe systems engineering conceptual model structure.

Severity of harm is evaluated for each situation. Thus a Severity level can be associated (S0 – no harm, S1, S2, S3 – severe harm). Finally, in the automotive field, the Controllability determines whether the driver can control the vehicle once he/she perceives the hazardous event. There are 4 levels to characterize this criterion (C0 – controllable, C1, C2, and C3 – uncontrollable). The combination of these three criteria enables to define an ASIL (ISO 26262, 2009). There are five levels of ASIL which are QM (for quality management when it is non-critical), A, B, C, and D (most critical scenarios). There are similar ‘‘Safety Integrity Levels” in IEC 61508 (1998) or DAL in ARP 4761 (1996) but there are different criteria to determine it. From this analysis, it is possible to specify a high-level safety requirement. The safety integrity level is associated to the requirement. In automotive domain, these requirements are called safety goals in ISO 26262 (2009) associated with ASIL. Fig. 2 chains the concepts required for creating and assessing dysfunctional scenarios. It can be considered as a design pattern. The previous models depict concepts related to the SSRE. The next sections will explain how to integrate them into a SSRE process.

4. A SSRE processes This section proposes a SSRE process that should be carried out to specify a safe system. In this paper we are focused on SRD and SRA processes. These SE processes can be decomposed into activities according to the ISO 15288 standard (ISO 15288, 2002): elicit, define, analyze and maintain stakeholder requirements; define, analyze and maintain system requirements. In Table 2, these activities have been enriched and decomposed into two types of subactivities: MBSE sub-activities and safety-related sub-activities.

The former sub-activities are present in the ISO 15288 standard but the latter are new. SRD identifies the operational requirements of the vehicle, which is the stakeholders’ point of view. During the definition of life cycle, taking into account non-nominal phases is critical. This includes degraded modes (limp-home for example) and dysfunctional uses (for instance, accident of the vehicle, and attack of the vehicle). Thanks to these non-nominal modes, it is easier to determine actors and scenarios during these phases. Moreover, during the definition of actors, it will not be limited to users but also to other actors who may attack the system (aggressors) or who may be threatened by the system (threatened actors). Taking them into account upstream is very important for design choices because it may result in defining key requirements. SRA identifies the intended behavior of the system which responds to stakeholder requirements. The additional safety-related sub-activity will help to perform the activity ‘‘Define Safety Goals” which is supported by O&SHA. The next section will describe this proposed method.

5. Proposal of an O&SHA This section aims at showing how these concepts and activities can be used to perform an O&SHA in order to carry out the activity ‘‘Define Safety Goals”. O&SHA provides inputs for the downstream process, that is, the architectural design process. A flowchart of the proposed O&SHA is presented in Fig. 3. This figure has three columns related to systems engineering sub-activities (left part), safety sub-activities (central part), and output data or models (right part). It clearly points out that these sub-activities are closely linked in the proposed safety system requirement analysis process. Now we will explain the steps of the proposed method.

260

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

Fig. 2. Rough dysfunctional scenario pattern.

Table 2 Proposal of Safe Systems Requirement Engineering Process (SSRE). Activities according to ISO 15288 Stakeholder Requirements Definition (SRD) Elicit stakeholder requirements Define stakeholder requirements

Analyze and maintain stakeholder requirements System Requirements Analysis (SRA) Define system requirements

Analyze and maintain system requirements

SSRE activities Collect needs and constraints, also declinable in terms of safety requirements Define system context (nominal and degraded lifecycle phases, actors including aggressors and threatened) Identify required system services by stakeholders Define system interactions (nominal and dysfunctional uses) Analyze and maintain stakeholder requirements Define system functions and flow deviations (potential hazard) Define system functional boundaries and interactions including potential harm Define operational modes and states, operational and dysfunctional scenarios Specify then refine system requirements Define Safety Goals Analyze and maintain system requirements

First of all, it is necessary to find the key elements of the dysfunctional scenario which are hazards of the system and harm of the environment. According to Vincoli (2014), ‘‘the PHA may be preceded with the preparation of a Preliminary Hazard List (PHL)”. This list includes all hazards of the system. In SSE, this list has to be linked to the model of the system by defining output flow deviations. In order to properly qualify flow deviations, guidewords like ‘‘MORE” or ‘‘MISSING” can be used (Kennedy and Kirwan, 1998). Then, all potential harms of each entity of the environment are listed. In the case of a car, potential harms for a pedestrian are injured, safe or burnt. It is thus possible to evaluate them with two of the three ASIL criteria which are severity for the harm and probability of exposure of hazard in a defined environment. Estimating ‘‘probability of exposure” is based on safety experts’ decisions or standards tables. More accurate methods could be used as proposed in (Jang et al., 2015). Moreover, a formal ontology

of operational situations with ASIL can be a good knowledge database for safety experts as it is mentioned in (Kemmann, 2015). This database could be shared and enriched by each new project by automotive manufacturers, being then a common. Rough dysfunctional scenarios can then be defined by instantiating the diagram presented in Fig. 2 for each flow deviation. By analyzing these rough scenarios, the third ASIL criterion (controllability) is assessed. The choice has been made to determine this criterion in two steps in order to eliminate non-critical scenarios as soon as possible. Hazards which lead to a controllable situation (C0) are eliminated in order to remove non critical scenarios. In a second phase, controllability of scenarios (C1 ? C3) is examined. So, as it is shown in Fig. 2, it is possible to characterize ASIL (see Table 6 in Appendix A). Critical ones (ASIL > B) are identified and selected for further analysis. By refining these critical scenarios, it is then possible to determine avoidance scenarios and safe states.

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

261

Fig. 3. Flowchart of the proposed method.

Quantitative and stochastic analyses of these safe states may be fulfilled if necessary by safety engineers, as it is explained by Cherfi et al. (2014). At the end of O&SHA, Safety Goals are defined. They can be considered as input data for the downstream design process (e.g. architectural design). The whole framework of O&SHA being presented, the next section will show two cases related to automotive industry. 6. Applications We chose two emblematic cases. With the first case (unintended acceleration), we give details on the SysML diagrams that are useful to support the different steps of our method. For the second case (loss of brake), we sum up the results. This latter case is interesting because it has been already dealt with by other authors (Chen et al., 2011). 6.1. Unintended acceleration of the vehicle Over the last decade, several press articles have been published concerning Sudden Unintended Acceleration of vehicles with dramatic consequences (89 deaths and 52 injuries have been attributed to this cause), as it is reported in (Safety Research & Strategies, Inc., 2010). Recent studies reported potential causes of unintended acceleration that caused serious incidents. They provided possible explanations for each case: failure of the accelerator pedal (Toyota, 2010); wrong size tires (due to the electronic stability control system on a rear wheel drive vehicle increasing the speed of the rear

wheels) (Belt, 2015a); errors in battery-operated vehicle control systems (due to variations of battery state of charge and to CPU errors) (Belt, 2012); a runaway condition in the traction motor controller in an all-electric vehicle (due to a negative voltage spike on the battery supply line) (Belt, 2015b). This last explanation is similar to this author’s explanation concerning ‘‘a runaway condition in the electronic throttle controller of gasoline engines, which explains the cause of sudden unintended acceleration in vehicles having electronic throttles”. According to this expert, without any specific investigation, the new electronic functions will increase the incident rate for sudden unintended acceleration in the future. So, it is useful to determine the safety goal for this hazard. First of all, it is necessary to define hazards (Fig. 3, A1 and A2). In this example, the flow ‘‘Torque” is the considered between the vehicle and the road for the system function called ‘‘Accelerate”. A deviation of the output flow corresponds to ‘‘MORE Acceleration than intended”, summarized in ‘‘Unintended Acceleration”. Moreover, in the present case, driving is one of the main phases of the vehicle life cycle. Accelerate is one of the main system functions of the vehicle. So, by using the table in ISO 26262 (2009) we can define the ‘‘probability of exposure” and the unintended acceleration during driving is E4. Then it is necessary to analyze whether there are potential harm due to this hazard (Fig. 3, A3 and A4). Thanks to the system context diagram in Fig. 4, it is possible to determine that the worst case of harm is critical injuries of the vehicle occupants (driver and passengers) or pedestrian due to a collision. Since harm may be severe, the level for Severity is S3 (3 is the highest severity level) (see Fig. 5). A rough dysfunctional scenario can be elaborated thanks to information obtained in A2 and A4 (Fig. 3, A5). In order to have rel-

262

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

Fig. 4. Context diagram.

Fig. 5. Rough dysfunctional scenario of unintended acceleration.

evant data, this scenario is an instantiation of the pattern presented in Fig. 2. There is a representative Environmental Condition Favorable to Hazard which is ‘‘presence of an obstacle”. This obstacle should be a static obstacle on the road, a followed vehicle or a pedestrian. There are other ECFH (in a bend for example) which lead to same conclusions. It is useless to deal with these cases that

will create unnecessary models because they would result in defining the same safety goal. This scenario covers the case that has been described in (Belt, 2014) and judged in the USA. By analyzing operational scenarios associated to the system function ‘‘Accelerate”, this rough dysfunctional scenario can be linked to some operational scenarios. Moreover, the one which

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

has the worst consequences has been chosen, i.e. critical injuries for driver (or pedestrian) as it has been analyzed previously. In this case, the operational scenario is obstacle avoidance during driving in normal operation. It could be considered that 90% or more of all drivers can react by braking if there is an unintended acceleration, so the level of Controllability is C2 (2 is the medium controllability level). In the present case, ASIL associated to the rough scenario is ASIL C (Combination of E4, S3 and C2 – Cf Table 6 in Appendix A) and it could be considered that it is a critical scenario that should be refined. In order to refine the dysfunctional scenario, the analysis of associated operational scenarios is necessary (Fig. 3, A6). For this

263

example, ‘‘obstacle avoidance” scenario is chosen and described in more details by a sequence diagram in Fig. 6. A sequence diagram is chosen because interactions between the system and its environment are well represented. Through feedback, it is possible to achieve an analysis of the previous operational scenario. Then, the rough dysfunctional scenario can be refined as shown in Fig. 7. Thanks to this refined scenario, more detailed data are now available in order to determine an avoidance scenario and a safety goal. In the present case, the hazard corresponds to a flow deviation of an output of the vehicle. So, possible avoidance scenario is to either limit or reduce the performance of the vehicle. It leads

Fig. 6. Operational scenario of obstacle avoidance in normal operation.

Fig. 7. Refined dysfunctional scenario of unintended acceleration.

264

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

to a safe state ‘‘with a reasonable level of risk” (ISO 26262, 2009) (Fig. 3, A7). Fig. 8 represents the avoidance scenario. This scenario covers the recommendation provided by R. Belt (Belt, 2014). If the hazard is not detected by the vehicle, another safety requirement is that the braking torque should be greater than the engine torque in order to enable the driver to stop the vehicle by braking. The results can be synthesized for the corresponding Safety Goal (see Table 3). For readability reasons, it is presented in 2 parts. In the above one, the dysfunctional scenario is described as well as the assessment of the scenario and the risk coverage proposal. If necessary, refinements can be achieved by a thorough safety analysis. In this case, simulation of dysfunctional scenarios and avoidance will give the value of Y% in the safety goal.

the first case and so, the criterion of severity is also S3. A rough dysfunctional scenario can be elaborated. There is a representative Environmental Condition Favorable to Hazard which is ‘‘presence of obstacle”. Given the rough dysfunctional scenario (Fig. 9), it is possible to determine that the criterion Controllability is C3. Therefore, ASIL is D. So, it is possible to refine this scenario by analyzing operational scenarios. For the sake of conciseness, the operational, refined dysfunctional and avoidance scenarios are not presented since they are similar to the scenarios of the first case. Thanks to their analysis, a Safety Goal can be determined. It is synthesized in Table 4.

6.2. Loss of brake of the vehicle

The two cases have illustrated that an O&SHA that enables to generate model-based Safety Goals in the proposed SSRE process. This section develops a discussion about the interest of the obtained results. In the context of the automotive industry, and more generally complex systems design, it is relevant to use MBSE, and then Model-Based Safety Assessment (MBSA). One main expected advantage of MBSE (Friedenthal et al., 2011) is lead time reduction. Defining links as (Cressent et al., 2012) or a pivot language (Kloul

The second case is related to the loss of brake of the vehicle. This hazard has been studied by other authors (Chen et al., 2011). Therefore it should be a good example to compare and to discuss results. The hazard ‘‘Loss of brake” is associated with the system function ‘‘Brake”. By using the table of ISO 26262, the criterion of probability of exposure is E4. Potential Harm is the same as in

7. Discussions about results

Fig. 8. Avoidance scenario.

Table 3 PHA of ‘‘Unintended acceleration during driving‘‘. System

Phase

Output flow

Hazard

Hazardous event

Harmful event

Situation with harm

Vehicle

Driving

Torque to road

Unintended acceleration

Unintended acceleration during driving

Shock

Critical injuries of the driver

Prob. of exposure

Sev.

Control.

ASIL

Avoidance scenario

Safety Goal

E4

S3

C2

C

Reduction of performances

The difference between driver’s intend and the acceleration of the vehicle must be less than Y %

265

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

Fig. 9. Rough dysfunctional scenario of Loss of Brake.

Table 4 PHA of ‘‘Loss of Brake‘‘. System

Phase

Vehicle

Driving

Output flow Torque to road

Hazard

Hazardous event

Loss of brake

Loss of brake with near obstacle during driving

Harmful event

Situation with harm

Shock

Critical injuries of the driver

Prob. of exposure

Sev.

Control.

ASIL

Avoidance scenario

Safety Goal

E4

S3

C3

D

Reduction of performances

Driver shall be alerted and vehicle must maintain a way for driver to reduce speed

et al., 2013) is not in accordance with this MBSE objective. We have therefore chosen to integrate safety activities into SSE processes. A criticism for the integration of safety in mainstream design process is safety independence concerning design certification (apprehensions of overprotected systems). This criticism does not apply to the method we have proposed. Indeed, the safety activities integrated into the proposed SSRE process like hazard analysis do not require specific knowledge or skills and are more efficient. Note that quantitative or stochastic analyses of safety are not included in the proposed SSRE process. They remain performed by safety engineers because they require expertise. However, thanks to the proposed conceptual model, having a mutual understanding of the different concepts and processes for SSRE should be easier. On the one hand, a drawback of the MBSE approaches is the excessive number of useless models if processes are poorly addressed. On the other hand, a safety problem concerns the treatment of improbable events with severe injuries. This kind of events with very low probability may happen at the first use of a system. So the question is for their treatment and analysis. As it is proposed in (Sinha, 2011), for an output flow of the system, it is possible to determine different hazards, and then different dysfunctional scenarios. Thorough analyses of these scenarios would be very expensive and very lengthy. The method proposed in this paper enables to assess these dysfunctional scenarios (with ASIL) to determine

whether they are critical. As a consequence, improbable events are taken into account in our proposal but they will be analyzed thoroughly only if they are critical. Concerning ASIL criterion, it is true that determining ASIL remains subjective. As it is mentioned above, it is the combination of three criteria. Thanks to the dysfunctional scenario determination proposed in this article, it is simple to determine ‘‘Severity”. Concerning ‘‘Exposure”, some tables have been proposed in the standard ISO 26262 (2009). Given that they are not exhaustive, a database based on a situation ontology could be elaborated. So, it is easier to determine the exposure criterion thanks to ordering relations of the situation ontology proposed in (Kemmann, 2015). Another possibility is to adapt the risk estimation criterion from machinery. Indeed, as it is explained in (Hiettiko et al., 2011) or in (IEC 62061, 2005), there are risk parameters which are ‘‘severity” and ‘‘probability of the harm occurring” (addition of frequency and duration of exposure, probability of an event occurring and probability of avoiding or limiting harm). Probability of avoiding or limiting harm is similar to controllability. Severity is similar to automotive severity with a different scale due to the difference of analyzed systems. However, the estimation of exposure is more accurate and less fuzzy because machinery standards distinguish frequency and probability. Using this estimation could be an improvement of the proposed O&SHA method that could be

266

Table 5 Coverage of concepts of SSRE conceptual model in the SSRE process. SSRE process

Vehicle occupant

Stakeholder requirement

System

Environment

Mission

Life cycle

X

X X

X

X X X

X

X X

X

X

X

X X

X

Hazard

Harmful event

Operational mode

Operational situation

Hazardous event

Harm

Technical requirement

Safety Goal

X X

X

X

X

X

X

X X

X

X

X

X

X

X

X

X

X X

X

X

X

X

X

X X

X X

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

Collect needs and constraints. . . Define system context Identify required system services by stakeholders Define system interactions Analyze and maintain stakeholder requirements Define system functions and flow deviations Define system functional boundaries and interactions including potential harm Define operational modes, functional and dysfunctional scenarios Specify then refine system requirements Define Safety Goals Analyze and maintain System Requirements

SSRE conceptual model Stakeholder

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

introduced during the rough dysfunctional scenario analysis and integrated in the result with an additional column. Controllability is recognized as being the most subjective criterion (Jang et al., 2015). As for the other criteria, a safety expert may determine or modify this criterion thanks to feedbacks of other projects and simulations. In safety machinery standard (IEC 62061), the tables used to evaluate each criterion are interesting because they give a weight instead a rank as in ISO26262. So the impact of a minor undervaluation of the probability of avoiding or limiting harm is limited. The weight intervals used to deduce SIL from the table comparing the severity and the probability of the harm occurring can give the same SIL in the case the weight of the probability of avoiding or limiting harm varies a little. Thus the subjectivity is minimized. The method proposed in this article may be useful for the expert to verify ASIL determination. Indeed, thanks to the accurate description of the dysfunctional scenario, they could verify the traceability between elements of the scenario and the ASIL. For example, for the hazard investigated in this article, there are at least five possible harms (major or minor injuries either for a pedestrian or for the driver & passengers, destruction of a piece of environment. . .), at least seven ECFH (presence of obstacle, vehicle in a bend at low/medium/ high speed, vehicle on a wet road at low/medium/high speed. . .), that may result in 35 dysfunctional scenarios and Safety Goals that are equivalent (or with lower ASIL) than the safety goal presented in Table 3. With this proposal, there is one thorough dysfunctional scenario and one safety goal that covers the cases listed above. The solution proposed in this paper is to roughly define all the possible dysfunctional scenarios then thoroughly analyze the critical scenarios. Moreover, we have verified that the above mentioned avoidance scenario is applicable to the rough dysfunctional scenarios associated to the other cases. Consequently other cases are covered by the presented Safety Goal. In the first case study, we mentioned incidents and their possible causes that have been associated to unintended acceleration. The proposed dysfunctional scenarios cover these incidents described in Belt’s reports (Belt, 2012, 2014, 2015a,b) and the case of Toyota described in (Belt, 2014). In addition, possible solutions defined by Belt (2014) are in agreement with the Safety Goal and the avoidance scenario but in the SSRE process (external view of the system), detailed technical solutions and safety mechanisms should not be defined. Furthermore, the proposed model and method can be useful to extend ISO 26262 standard. A comparison between the results obtained by usual PHA vs. those produced by O&SHA method shows that the proposed description of the dysfunctional scenario gives more details and is based on models that could be easily reused in specialized safety activities or in architectural design activities. In usual PHA, there is often one line to describe the scenario. The proposed method produces a clear model-based specification by targeting necessary concepts (hazardous event, harmful event) which are compliant to safety standards, e.g. ISO 26262 or IEC 61508. It allows a more systematic description which is not user-dependent. In comparison with approaches proposed by other authors (Sinha, 2011) (Jang et al., 2015), O&SHA method is based on the same key concepts coming from the mentioned standards. The main interest of the proposed method is that it is integrated in a SSRE process and is based on MBSE. Moreover, it is possible to compare the proposed method with other approaches thanks to its application on the hazard ‘‘loss of brake”. The safety goal is the same as in (Chen et al., 2011) but these authors don’t present neither a model-based approach, nor a process to integrate safety and systems engineering. Our approach helps system architects to have a good integration of safety requirements in the system models and to better justify these requirements. As we mentioned in the introduction, new functions are present in vehicles with a large part of electronics. ISO 26262 doesn’t

267

demand automotive certification even if approval is done in some countries with independent organizations (Palin et al., 2011). In addition, given that there are new functions, it is not possible to use the argument of the proven in use. However, it could be possible to use Safety cases. Our method is based on a conceptual model defining the concepts useful to build Safety Cases. So it is possible to achieve the initialization of a Safety Case either in tabular form or as a Goal Structuring Notation (GSN). Lastly it is possible to verify that the concepts in the proposed SSRE conceptual model are relevant and well cover the SSRE process. This verification is shown in Table 5. The proposed SSRE process requires all these concepts and only these key concepts. For example, for the activity ‘‘Define system context”, Vehicle occupant, Stakeholder Requirement, System, Environment and Life Cycle are necessary to fulfill this activity. To conclude, Table 5 enables to verify Requirement 6 of the SSRE conceptual model (it shall be validated by the definition of a SSRE process) and to verify that activities of the SSRE process take into account all the concepts of the proposed SSRE conceptual model. 8. Conclusion and future work This article has proposed a method to perform an Operational and System Hazard Analysis (O&SHA) based on Systems Engineering (SE) processes and SysML diagrams integrated in MBSE approach and compliant with ISO 26262 standard. After a state of the art covering the existing weak links between SE and safety, we have proposed a Safe Systems Requirement Engineering (SSRE) conceptual model to determine the equivalences between the concepts of both domains in the operational view. SSRE process related to Stakeholder Requirement Definition (SRD) and System Requirement Analysis (SRA) has been then depicted. A method called O&SHA has been proposed to define Safety Goals. The proposed method has been applied to the case of the unintended acceleration and the loss of break of a vehicle. The proposed methodological framework is essentially focused on the automotive industry. However, it may be easily applicable to other sectors. The proposed O&SHA method is also valuable because the elements of the dysfunctional scenario can be elaborated in the system model. Future work consists in defining a methodological framework for the safe system architectural design. In fact, the definition of hazardous events linked to the output flow deviations will be essential to determine critical paths in the functional or physical architectures. It will allow defining Safety Mechanisms and refining Safety Goals in Functional Safety Requirements that are other key deliverables expected by ISO 26262. Thus the next step is to define a safe functional architecture based on safety methods such as failure propagation in order to define the functional safety concept according to ISO 26262. In the same way as ‘‘Hazard Analysis and Risk Assessment” activity, ISO 26262 does not provide any method to define this functional safety concept. This paper has presented operational views of the system with dysfunctional analysis. They should be a good basis to define safe functional architectures. It should help the system engineer to determine critical functions and to define safety functions or safety mechanisms during functional architecture design. Integration of safety and systems engineering will help to define the dysfunctional aspect of functions (including safety functions) as failure. Acknowledgments This work is carried out under the financial support of the French National Association of Research and Technology (ANRT in French – convention CIFRE N° 627/2012) as well as PSA Peugeot Citroën. We want to acknowledge PSA Peugeot Citroën and espe-

268

P. Mauborgne et al. / Safety Science 87 (2016) 256–268

Table 6 ASIL table (ISO 26262, 2009).

Each colour in Table 6 corresponds to specific ASIL (QM in green; A and B in yellow; C and D in pink). These colours help the reader to interpret this table. Critical ASIL (ASIL > B) are identified and selected for further analysis.

cially the ‘‘SE tools & Methods” Department for helping us to define the proposed method and for the interesting discussions. Appendix A See Table 6. References Alexander, I., Maiden, N., 2005. Scenarios, Stories, use Cases: Through the Systems Development Life-Cycle. John Wiley & Sons. ARP 4761, 1996. Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. Belt, R.A., 2012. An Electronic Cause for Sudden Unintended Acceleration. Retrieved January 26, 2016, from The Centre for Auto Safety: . Belt, R.A., 2014, January 6. Further Details on an Electronic Mechanism for Sudden Unintended Acceleration. Retrieved January 26, 2016, from The Centre for Auto Safety: . Belt, R.A., 2015. Unintended Acceleration with a Confirmed Cause. Retrieved January 26, 2016, from The Centre for Auto Safety: . Belt, R.A., 2015. Sudden Unintended Acceleration in an All-Electric Vehicle. Retrieved January 26, 2016, from The Centre for Auto Safety: . Chalé, H.G., Taofifenua, O., Gaudré, T., Topa, A., Lévy, N., Boulanger, J.-L., 2011. Reducing the gap between formal and informal worlds in automotive safetycritical systems. INCOSE Int. Sympos. 21 (1), 1306–1320. Chen, D., Johansson, R., Lönn, H., Blom, H., Walker, M., Papadopoulos, Y., Sandberg, A., 2011. Integrated safety and architecture modeling for automative embedded systems. Elektrotechnik Informationstechnik 128 (6), 196–202. Cherfi, A., Leeman, M., Meurville, F., Rauzy, A., 2014. Modeling automotive safety mechanisms: a Markovian approach. Reliab. Eng. Syst. Safety 130, 42–49. Cimatti, A., Clarke, E.M., Giunchiglia, E., Giunchiglia, F., Pistore, M., 2002. Nusmv 2: an opensource tool for symbolic model checking. Comput. Aided Verif., 359– 364

Cressent, R., David, P., Idaziak, V., Kratz, F., 2012. Designing the database for a reliability aware model-based system engineering process. Reliab. Eng. Syst. Safety 111, 171–182. David, P., Idasiak, V., Kratz, F., 2010. Reliability study of complex physical systems using SysML. Reliab. Eng. Syst. Safety 95 (4), 431–450. Deniaud, S., Bonjour, E., Micaëlli, J.-P., Loise, D., 2010, November 11–12. How to Integrate Reliability into Systems Engineering Framework. A Case From Automotive Industry. CRECOS Seminar. Ericson, C., 2005. Hazard Analysis Techniques for System Safety. John Wiley & Sons. Friedenthal, S., Moore, A., Steiner, R., 2011. A practical guide to SysML. In: Elsevier, T.M. (Ed.), second edition. The Systems Modeling Language, Burlington. Hiettiko, M., Malm, T., Alanen, J., 2011. Risk estimation studies in the context of a machine control function. Reliab. Eng. Syst. Safety 96, 767–774. IEC 61508, 1998. Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems. IEC 62061, 2005. Safety of Machinery – Functional Safety of Safety-Related Electrical, Electronic and Programmable Electronic Control Systems. IEEE 1220, 2005. Standard for Application and Management of the Systems Engineering Process. IEEE 1471, 2000. IEEE Recommended Practice for Architectural Description for Software-Intensive Systems. ISO 15288, 2002. Systems Engineering – System Life Cycle Processes. ISO 26262, 2009. Functional Safety for Road Vehicles. Jang, H.A., Kwon, H.M., Hong, S.-H., Lee, M.K., 2015. A study on situation analysis for ASIL determination. J. Ind. Intell. Inform. 3 (2), 152–157 (M. Othman, Ed.). Kemmann, S., 2015. SAHARA – A Structured Approach for Hazard Analysis and Risk Assessments. Kaiserslautern. Kennedy, R., Kirwan, B., 1998. Development of a hazard and operability-based method for identifying safety management vulnerabilities in high risk systems. Safety Sci. 30 (3), 249–274. Kloul, L., Prosvirnova, T., Rauzy, A., 2013. Modeling systems with mobile components: a comparison between AltaRica and PEPA nets. J. Risk Reliab. 227 (6), 599–613. Leveson, N., 2004. A new accident model for engineering safer systems. Safety Sci. 42 (4), 237–270 (April). Leveson, N., 2011. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press. de Oliveira, A.L., Braga, R.T., Masiero, P.C., Papadopoulos, Y., Habli, I., Kelly, T., 2014. A model-based approach to support the automatic safety analysis of multiple product line products. In: Brazilian Symposium on Computing Systems Engineering. Manaus, Brazil. OMG, 2012. OMG Systems Modeling Language (OMG SysML) V1.3. Palin, R., Ward, D., Habli, I., Rivett, R., 2011. ISO 26262 safety cases: compliance and assurance. In: 6th IET International Conference on System Safety, Birmingham, 20–22 September 2011, pp. 1–6. Papadopoulos, Y., McDermid, J.A., 1999. Hierarchically performed hazard origin and propagation studies. Computer Safety, Reliab. Security, 139–152. Pfister, F., Chapurlat, V., Huchard, M., Nebut, C., Wippler, J.-L., 2011. A proposed meta-model for formalizing systems engineering knowledge, based on functional architectural patterns. Syst. Eng. 15 (3), 321–332. Pyster, A., Olwell, D.H., 2013. The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 1.1.2. Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Rausand, M., 2004. Preliminary hazard analysis. System Reliability Theory. Wiley Interscience. Safety Research & Strategies, Inc., 2010. Toyota Sudden Unintended Acceleration. Sinha, P., 2011. Architectural design and reliability analysis of a fail-operational brake-by-wire system from ISO 26262 perspectives. Reliab. Eng. Syst. Safety 96, 1349–1359 (Elsevier, Ed.). Toyota, 2010. Certain Toyota Vehicle Accelerator Pedal Assembly Issue. Vincoli, J.W., 2014. Basic Guide to System Safety, third ed. John Wiley & Sons. Yakymets, N., Jaber, H., Lanusse, A., 2012. Model-based system engineering for safety analysis of complex systems. MBSAW Bordeaux.