Access the full text.
Sign up today, get DeepDyve free for 14 days.
Loading next page...
/lp/multidisciplinary-digital-publishing-institute/a-novel-hazard-analysis-and-risk-assessment-approach-for-road-vehicle-Xg2EFu5700
- Publisher
- Multidisciplinary Digital Publishing Institute
- Copyright
- © 1996-2020 MDPI (Basel, Switzerland) unless otherwise stated Disclaimer The statements, opinions and data contained in the journals are solely those of the individual authors and contributors and not of the publisher and the editor(s). MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. Terms and Conditions Privacy Policy
- ISSN
- 2076-3417
- DOI
- 10.3390/app10217400
- Publisher site
- See Article on Publisher Site
Abstract
applied sciences Article A Novel Hazard Analysis and Risk Assessment Approach for Road Vehicle Functional Safety through Integrating STPA with FMEA 1 , 2 1 1 , Lei Chen , Jian Jiao and Tingdi Zhao * School of Reliability and Systems Engineering, Beihang University, Beijing 100191, China; zheermao1005@163.com (L.C.); jiaojian@buaa.edu.cn (J.J.) School of Safety Engineering, Shenyang Aerospace University, Shenyang 110136, China * Correspondence: ztd@buaa.edu.cn Received: 20 September 2020; Accepted: 18 October 2020; Published: 22 October 2020 Featured Application: The novel method obtained by integrating STPA into FMEA template in this paper has the advantages of both, so it is suitable for the hazard analysis and risk assessment, and generation of safety requirements of modern software intensive complex safety critical systems, one of which is the electrical and/or electronic (E/E) systems within road vehicles. Abstract: ISO26262: 2018 is an international functional safety standard for electrical and/or electronic (E/E) systems within road vehicles. It provides appropriate safety requirements for road vehicles to avoid unreasonable residual risk according to automotive safety integrity levels (ASILs) derived from hazard analysis and risk assessment (HARA) required in the ISO26262 concept phase. Systems theoretic process analysis (STPA) seems to be designed specifically to deal with hazard analysis of modern complex systems, but it does not include risk evaluation required by most safety related international standards. So we integrated STPA into Failure Mode and E ect Analysis (FMEA) template to form a new method called system theoretic process analysis based on an FMEA template, STPAFT for shot, which could not only meet all the requirements of the concept phase in ISO26262, but also make full use of the advantages of the two methods. Through the focus of FMEA on low-level components, STPAFT can obtain more detailed causal factors (CFs), which is very helpful for derivation of safety goals (SGs) and the functional safety requirements (FSRs) in the concept phase of ISO26262. The application of STPAFT is described by the case study of fuel level estimation and display system (FLEDS) to show how the concept phase of ISO26262 could be supported by STPAFT. Keywords: hazard analysis and risk assessment; STPA; FMEA; ISO26262; ASIL; safety goal; functional safety requirement 1. Introduction Nowadays, the intensive use of software and the increase in functional requirements have significantly increased the complexity of road vehicle systems. Therefore, developing safety requirements for road vehicle electrical and/or electronic (E/E) systems is challenging. First, in the early conceptual phase, engineers need to consider not only safety-related goals, but also other system-level goals, such as performance and information security, which determines whether stakeholders’ will be satisfied with the new product [1,2]. Second, traditional safety analysis methods focusing on component failures are dicult to be used alone in safety analysis of software-intensive modern complex systems [3–5]. ISO26262, as a domain-specific standard for functional safety of road vehicles, Appl. Sci. 2020, 10, 7400; doi:10.3390/app10217400 www.mdpi.com/journal/applsci Appl. Sci. 2020, 10, 7400 2 of 23 was born to deal with these challenges [6]. It has developed various procedures and processes to ensure functional safety, but does not restrict type of methods for hazard and safety analysis. Systems theoretic process analysis (STPA) [3–5] is a relatively new hazard analysis technology for software intensive complex systems, which views safety as a control problem. In STPA, accidents result from inadequate control of component failures, dysfunctional interaction of components, external disturbance, etc. Since the implementation of ISO26262, STPA has attracted growing attention in the automotive industry [7–14]. Although STPA does have advantages in hazards analysis, which traditional methods do not have, the key obstacle for STPA to satisfy the requirements of the hazard analysis and risk assessment (HARA) process of ISO26262 is that STPA does not directly consider hazards qualification as some traditional hazard analysis methods do. Therefore, we proposed a new method named STPAFT. Through integrating STPA into a failure mode and e ect analysis (FMEA) technique, STPAFT could not only give full play to the two methods, but could also meet all the requirements of the concept phase in ISO26262. In STPAFT, STPA is still responsible for hazard analysis and FMEA is responsible for risk assessment according to ISO26262. FMEA technology can also help STPA to analyze causal factors more systematically by focusing on the lowest level components, and more safety constraints (SCs) could be generated here, which could provide more guidance for the derivation of functional safety requirements (FSRs). In fact, through the integration of STPA and FMEA, STPAFT not only has a complete risk assessment process, but also is superior in the identification of causal factors. Therefore, using STPAFT instead of some single method will satisfy the requirements of HARA process in ISO26262 concept phase and handle the increasing complexity of systems. The primary purpose of our study is to show how the work products required by ISO26262 concept phase could be generated by STPAFT. The safety constraints generated by STPAFT could provide strong support for the derivation of ISO26262 safety goals (SGs) and FSRs. In addition, with the rapid improvement of vehicle automation, ISO26262 may one day need to include causes of hazards other than malfunctioning behavior due to component failures to keep up to date with technological trends and STPAF as a hazard analysis method with the functions of risk assessment and constraints derivation, is especially in line with this development trend. Our paper is organized as follows: Section 2 provides the background of our study. Section 3 represents a brief overview of ISO26262, STPA and FMEA. In addition, foundations and key terms of STPA and ISO26262 concept phase are analyzed to prove that STPA is suitable for ISO26262 concept phase. Section 4 represents how our proposed method formed and how to apply STPAFT in compliance with ISO26262. At last, we demonstrate an application of STPAFT in the case study of fuel level estimation and display system (FLEDS) to show how the concept phase of ISO26262 could be supported by STPAFT in Section 5. Sections 6 and 7 are the discussion, and conclusion and future work of our research, respectively. 2. Background In this section, some clauses of ISO26262 concept phase relevant to this paper, STPA and FMEA technology are briefly introduced. Additionally, we provide a detailed comparative analysis on the theoretical foundations and key terms of STPA and ISO262626 concept phase. 2.1. ISO26262 for Road Vehicle Functional Safety ISO26262, published in late 2011, is an international standard concerned with functional safety of safety-related E/E systems within the automotive systems. The purpose of this standard is to constructs a framework to integrate functional safety activities into the development of safety-related E/E systems through providing guidance, recommendation and argumentation [6]. The stipulation of each new product to be state-of-the-art could be helped by putting forward suggestions on specific safety development processes and safety classifications. Appl. Sci. 2020, 10, 7400 3 of 23 ISO26262 consists of 10 parts and the safety activities are mainly described in seven parts (from Part 3 to Part 9). Part 3 gives a clear explanation of the specific contents of the concept phase [6]: 1. Item definition: the object of this process is to describe the functionality, interfaces between other items, the driver and the environment of an item. This step is the input of the HARA process. 2. The HARA process is made up of three steps: (1) Determine the hazardous events according to identified vehicle-level hazards, corresponding operational situations and operating modes. Appl. Sci. 2020, 10, x FOR PEER REVIEW 3 of 23 (2) For each identified vehicle-level hazard, the risk assessment framework of ISO26262 is applied: (1) Determine the hazardous events according to identified vehicle-level hazards, corresponding The probability of exposure (E) to the operational situation is assessed. operational situations and operating modes. Identify potential scenarios which can cause a crash. The severity (S) of the harm to the (2) For each identified vehicle-level hazard, the risk assessment framework of ISO26262 is persons involved is assessed if the crash happened. applied: The controllability (C) of the vehicle and the operational situations is assessed. The probability of exposure (E) to the operational situation is assessed. Determine the automotive safety integrity level (ASIL) based on E, S and C according Identify potential scenarios which can cause a crash. The severity (S) of the harm to the to ISO 26262 as shown in Figure 1. persons involved is assessed if the crash happened. (3) The worst-case ASIL is assigned to the hazardous event. The controllability (C) of the vehicle and the operational situations is assessed. 3. SGs shall be determined for each identified hazardous event with its ASIL. Determine the automotive safety integrity level (ASIL) based on E, S and C according to 4. Functional safety concept: the most important objective of this step is the derivation of FSRs from ISO 26262 as shown in Figure 1. the SGs, considering the system architectural design. (3) The worst-case ASIL is assigned to the hazardous event. (a) (b) (c) Figure 1. Cont. (d) Figure 1. The determination of automotive safety integrity levels (ASILs) according to severity (S), controllability (C), and exposure (E): (a) classes of the impact factor S; (b) classes of the impact factor E; (c) classes of the impact factor C; (d) determination of ASILs. 3. SGs shall be determined for each identified hazardous event with its ASIL. Appl. Sci. 2020, 10, x FOR PEER REVIEW 3 of 23 (1) Determine the hazardous events according to identified vehicle-level hazards, corresponding operational situations and operating modes. (2) For each identified vehicle-level hazard, the risk assessment framework of ISO26262 is applied: The probability of exposure (E) to the operational situation is assessed. Identify potential scenarios which can cause a crash. The severity (S) of the harm to the persons involved is assessed if the crash happened. The controllability (C) of the vehicle and the operational situations is assessed. Determine the automotive safety integrity level (ASIL) based on E, S and C according to ISO 26262 as shown in Figure 1. (3) The worst-case ASIL is assigned to the hazardous event. (a) (b) Appl. Sci. 2020, 10, 7400 4 of 23 (c) (d) Figure 1. The determination of automotive safety integrity levels (ASILs) according to severity (S), Figure 1. The determination of automotive safety integrity levels (ASILs) according to severity (S), controllability (C), and exposure (E): (a) classes of the impact factor S; (b) classes of the impact factor E; controllability (C), and exposure (E): (a) classes of the impact factor S; (b) classes of the impact factor (c) classes of the impact factor C; (d) determination of ASILs. E; (c) classes of the impact factor C; (d) determination of ASILs. 2.2. System Theoretic Process Analysis 3. SGs shall be determined for each identified hazardous event with its ASIL. STPA is a hazard analysis technique based on the STAMP framework, which was developed by Leveson in 2004 [5]. STPA regards safety as a control problem, and uses hierarchical safety control structures to describe systems. Accidents occur when unsafe interactions among components, external disturbance, and/or component failures are inadequately controlled. Analysis of the safety control structure could determine why inadequate control and enforcement of safety related constraints occurred [3–5]. There are mainly three steps in STPA: 1. The first is to establish the engineering fundamentals, including the determination of accidents, identification of system-level hazards leading to accidents, and the contribution of the system safety control structure. 2. Identify potential unsafe control actions (UCAs) leading to hazards using the safety control structure constructed in the previous step. 3. Identified causal factors leading to UCAs or a violation of SCs by examining each part in the control structure. In recent years, STPA has been successfully used in various safety-critical systems of many fields [7–33], such as STPA for automotive systems [2,7–14], STPA for defense system [15], for medical devices such as a radiation therapy system [16], for nuclear industry [17] and for aerospace related systems [18–22], etc. 2.3. Failure Mode and E ect Analysis FMEA is an inductive analysis method, which is used in the early development process to identify the potential failure modes and their causes of all components in the system [34,35]. FMEA calculates the e ects of the identified failure modes through measurement of the severity, occurrence and detection probability. The analysis starts with the lowest level components and goes on to the e ect of the failures on the whole system. At last, countermeasures will be proposed to reduce or minimize the negative e ects of the identified failure modes. The steps in usual FMEA are shown in Figure 2. 2.4. Related Work Due to the advantages of STPA in safety analysis, some scholars used it in the HARA process of ISO26262. Hanneet [8] applied STPA to a lane keeping assist system to derive safety-driven design constraints and requirements. Abdulkhaleq [9] developed a dependable architecture for fully automated driving vehicles based on STPA. Abdulkhaleq also compared the results of STAMP/STPA with the safety case on the same system [10]. Then, safety engineering and software engineering are Appl. Sci. 2020, 10, x FOR PEER REVIEW 4 of 23 4. Functional safety concept: the most important objective of this step is the derivation of FSRs from the SGs, considering the system architectural design. 2.2. System Theoretic Process Analysis STPA is a hazard analysis technique based on the STAMP framework, which was developed by Leveson in 2004 [5]. STPA regards safety as a control problem, and uses hierarchical safety control structures to describe systems. Accidents occur when unsafe interactions among components, external disturbance, and/or component failures are inadequately controlled. Analysis of the safety control structure could determine why inadequate control and enforcement of safety related constraints occurred [3–5]. There are mainly three steps in STPA: 1. The first is to establish the engineering fundamentals, including the determination of accidents, identification of system-level hazards leading to accidents, and the contribution of the system safety control structure. 2. Identify potential unsafe control actions (UCAs) leading to hazards using the safety control structure constructed in the previous step. 3. Identified causal factors leading to UCAs or a violation of SCs by examining each part in the control structure. In recent years, STPA has been successfully used in various safety-critical systems of many fields [7–33], such as STPA for automotive systems [2,7–14], STPA for defense system [15], for medical devices such as a radiation therapy system [16], for nuclear industry [17] and for aerospace related Appl. Sci. 2020, 10, 7400 5 of 23 systems [18–22], etc. combined 2.3. Failurin e M [11 od,e12 and ] thr Eff ough ect Analy a STP sis A-based approach for software-intensive systems. Suo [2] proposed a method using a meta-model based on System Model Language (SysML) to support the integration of FMEA is an inductive analysis method, which is used in the early development process to STPA into ISO26262. identify the potential failure modes and their causes of all components in the system [34,35]. FMEA In [13,14], Hommes pointed out the hazard analysis methods recommended in ISO26262 are not calculates the effects of the identified failure modes through measurement of the severity, occurrence sucient in dealing with the rapidly increasing complexity of modern software-intensive systems and detection probability. The analysis starts with the lowest level components and goes on to the through an assessment and emphasized the advantages of using STPA as a hazard analysis technology effect of the failures on the whole system. At last, countermeasures will be proposed to reduce or in the concept phase of ISO26262. This is a strong motivation for us to develop a new method based on minimize the negative effects of the identified failure modes. The steps in usual FMEA are shown in STPA which can keep the superiority of STPA and assess risk at the same time. Figure 2. Figure 2. Steps of implementation process of failure mode and effect analysis (FMEA). Figure 2. Steps of implementation process of failure mode and e ect analysis (FMEA). 2.4. Related Work 3. Hazard Analysis Foundations and Key Terms of STPA and ISO26262 Due to the advantages of STPA in safety analysis, some scholars used it in the HARA process of STPA is the core of our proposed method, so it is important to prove that STPA is suitable as a ISO26262. Hanneet [8] applied STPA to a lane keeping assist system to derive safety-driven design hazard analysis method for the ISO26262 concept phase. For this purpose, we first analyze the hazard constraints and requirements. Abdulkhaleq [9] developed a dependable architecture for fully analysis foundations of ISO26262 and STPA. Then, the key terms used in ISO26262 concept phase and automated driving vehicles based on STPA. Abdulkhaleq also compared the results of STAMP/STPA STPA are compared to prove that STAP is applicable for ISO26262 from another view. with the safety case on the same system [10]. Then, safety engineering and software engineering are 3.1. com Hazard bined Analysis in [11,12 Foundations ] through of a the STPA HARA -based Pr ocess apprin oaISO26262 ch for soand ftwa STP re-iA ntensive systems. Suo [2] proposed a method using a meta-model based on System Model Language (SysML) to support the First of all, both STPA and ISO26262 are based on the system engineering framework which views integration of STPA into ISO26262. a system as an integrated whole. They both aim to embed safety into a system engineering process and to design safety into the system from the very beginning of a development process. Another thing in common is that both the STPA and HARA process are top-down processes. The HARA process of ISO26262 only focuses on hazards caused by component failures, while hazards in STPA may result from dysfunctional interactions among components, design flaws, human factors and external disturbance, beyond component failures. Activities in the HARA process are mainly divided into three parts as mentioned above. The most important di erence between the HARA and STPA processes here is that the HARA process requires risk assessment according to the classification of hazardous events and determination of ASIL, while STPA does not intend to estimate risk. We list foundations of STPA and ISO26262 in Table 1. Table 1. The foundations of ISO26262 hazard analysis and risk assessment and systems theoretic process analysis (STPA). Foundations ISO26262 HARA STPA Have a broader scope of hazards causes. Focus hazards on only component failures. View safety as a control problem. Use an Characteristics HARA and determination of ASIL are hierarchical safety structure to describe a used to determine SGs for the item. system and explain why accidents occur. Do not estimate risk. Assumed to be used in any stages within Applicable in the development stage a the whole life cycle of a system, especially Application Phase system, with little known about the detail in the early stage of the design. development process. Appl. Sci. 2020, 10, 7400 6 of 23 Table 1. Cont. Foundations ISO26262 HARA STPA Identify and classify hazardous events. Identify reasons for inadequate control or Objectives Formulate SGs and corresponding ASIL, enforcement of safety related constraints. for each hazardous event Hazardous events and their classifications, Accidents and associated hazards of a Output Results SGs and associated ASILs system, UCAs, SCs to be enforced 3.2. Key Terms of ISO26262 Concept Phase and STPA Key terms of STPA and ISO26262 HARA process are listed in Table 2. We could see the conceptual di erences between the two from the table. Taking the definitions of hazard as an example, firstly, the scope of a hazard in STPA is much broader than the scope of a hazard in the HARA process as mentioned above. Next, the definition of hazard in STPA includes both “a system state or condition” and “a specific set of worst-case environmental conditions” which describe the contexts of “a system state or condition”, while in ISO26262 hazards are only “potential source” of harm [3–6]. The meaning of “harm” in ISO26262 is similar to what “loss” means in STPA, but “harm” only means “injuries or damage to the health of person”, while “loss” includes damage of property, pollution of environment, loss of mission, etc., besides human injuries or death. Although there is no definition of “operating mode and operational situation” in STPA, according to the description of these two concepts in ISO26262, we can infer that these two concepts can be included in the definition of hazard in STPA. So, if we limit the scope of “loss” in an “accident” in STPA to “harms” in ISO26262, an “accident” in STPA could be equivalent to a “consequence of hazardous events” in our study. As for safety goals in ISO26262, they could be equivalent to the system-level SCs in STPA, because they are similar in definition. Table 2. Key terminologies of STPA and ISO26262 concept phase. Terminologies STPA ISO26262 Events leading to loss result from Accident lack of enough control and Not specifically defined enforcement of SCs The combination of a system state Potential source of physical injury or or set of conditions and a specific damage to the health of persons Hazard set of worst-case environmental caused by malfunctioning behavior of conditions, will lead to an accident the item Physical injury or damage to the Harm Not specifically defined health of person A component’s (or system’s) Termination of an intended behavior Failure non-performance or inability to of an element or an item due to a fault perform as expected or designed. manifestation Scenarios that may occur within the Operation Situations Not specifically defined life of a vehicle Perceivable functional state of an item Operating modes Not specifically defined or element The result of integrating a hazard with Hazardous event Not specifically defined an operational situation Levels used to specify safety measures and necessary requirements of an ASILs Not specifically defined element or item for avoiding unreasonable residual risk Appl. Sci. 2020, 10, 7400 7 of 23 Table 2. Cont. Terminologies STPA ISO26262 System-level safety requirements Safety Constraints to prevent hazards from leading to Not specifically defined (System Level) accidents and ensure safety Top-level safety requirements for an Safety Goals Not specifically defined item as a result of vehicle-level HARA, expressed as functional objectives An item’s failure or unintended Malfunctioning Behavior Not specifically defined behavior with respect to its design intent Inadequate control actions within Unsafe control actions (UCAs) Not specifically defined four types leading to hazards Scenarios that could explain how Causal Factors inadequate control actions Not specifically defined might occur Safety requirements derived from SCs for UCAs and the identified UCAs and Not specifically defined Causal Factors corresponding causal factors According to the analysis above, the di erences between STPA and ISO26262 are mainly reflected in the fact that STPA covers a wider scope than ISO26262 in many key factors, such as hazard, accident, etc. Therefore, if STPA is to be used for hazard analysis in ISO26262, it is necessary for STPA to adapt to the current requirements of the concept phase of ISO26262. In this paper, certain key terms in STPA will be limited to the scope of ISO26262 requirements, such as “loss” in STPA and “harm” in ISO26262, and some could be equivalent in this paper, such as “accident” in STPA and “consequence of hazardous event” in ISO26262. So that the work products required by the concept phase of ISO26262 can be obtained through the analysis of STPA. Moreover, we will explain how to map corresponding key terms of STPA and ISO26262 in Section 5. In a word, all the distinctions are understandable, since STPA is a general safety analysis method, and ISO26262 only serves road vehicles. So, if we make some appropriate adjustments to STPA, it can fully meet the requirements of ISO26262 for hazard analysis. 4. The Proposed Method In order to generate (or support) the relevant work products required in the concept phase of ISO26262, we proposed an improved approach called STPAFT, which integrates STPA into the FMEA technique to conduct both hazard analysis and risk assessment. STPA could also be supported by the FMEA technique in the systematic identification of causal factors through the focus of FMEA on associated components of the system, and more SCs could be formulated here which means the proposed method will provide more information for the FSRs determination. 4.1. Integrating STPA into FMEA Although STPA and FMEA are two di erent methods, from the analysis process of the two methods, FMEA first identifies the failure mode after assigning functions to subsystems and components, and then determines the causes of the failure modes. This process is similar to the process of identifying unsafe control actions and then confirming the causal factors after establishing the safety control model of STPA. Therefore, in order to make full use of FMEA templates for causal factors analysis and risk assessment, some concepts of STPA are corresponding to FMEA in this paper. This is not to say that their essence is the same, but to enable STPA to make full use of the FMEA template in the analysis process. Figure 3 illustrates the correspondence between key concepts of STPA and FMEA. Appl. Sci. 2020, 10, x FOR PEER REVIEW 7 of 23 4. The Proposed Method In order to generate (or support) the relevant work products required in the concept phase of ISO26262, we proposed an improved approach called STPAFT, which integrates STPA into the FMEA technique to conduct both hazard analysis and risk assessment. STPA could also be supported by the FMEA technique in the systematic identification of causal factors through the focus of FMEA on associated components of the system, and more SCs could be formulated here which means the proposed method will provide more information for the FSRs determination. 4.1. Integrating STPA into FMEA Although STPA and FMEA are two different methods, from the analysis process of the two methods, FMEA first identifies the failure mode after assigning functions to subsystems and components, and then determines the causes of the failure modes. This process is similar to the process of identifying unsafe control actions and then confirming the causal factors after establishing the safety control model of STPA. Therefore, in order to make full use of FMEA templates for causal factors analysis and risk assessment, some concepts of STPA are corresponding to FMEA in this paper. This is not to say that their essence is the same, but to enable STPA to make full use of the FMEA template in the analysis process. Figure 3 illustrates the correspondence between key concepts of Appl. Sci. 2020, 10, 7400 8 of 23 STPA and FMEA. Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 23 4.2.1. System Engineering Fundamentals Establishment As mentioned in Section 3, the consequences of hazardous events in ISO26262 could be determined by integrating accidents in STPA with operating modes and operational situations. A “hazard” of STPA could be mapped to a “hazardous event” of ISO26262. In order to distinguish the “hazard” of STPA from the “hazard” of ISO26262, we use “ the system-level hazard” here to present the “hazard” of STPA, and the “vehicle-level hazard” to present the ”hazard” of ISO26262 in the rest part of this paper. The first step of STPA includes: Define the “loss” of the system accident in STPA with limitation to the scope of harm defined by Figure Figure 3. Corr 3. Coespondence rrespondence between between k key ey cconcepts oncepts of of STP STP A A and and FME FMEA. A. ISO26262 to be analyzed. Befor Be efthe ore integration the integratioof n o the f the two twomethods, methods, we wewi will ll co complete mplete Step Step 1 a1 nd and 2 of2 Sof TPA STP first, A first, that ithat s, is, Identify system-level hazards leading to the accidents and corresponding operating modes and to determine an accident, identify the system-level hazards and the unsafe UCAs. Here, as shown in operational situations from the descriptions of identified system-level hazards. to determine an accident, identify the system-level hazards and the unsafe UCAs. Here, as shown Figure 3, a control action in STPA can be equivalent to a function in FMEA, while a UCA can be Determine corresponding vehicle-level SCs which could be used to support the SGs in Figure 3, a control action in STPA can be equivalent to a function in FMEA, while a UCA can be equivalent to a failure mode in our paper. Combine Step 3 of STAP and Step 3 of FMEA to determine determination subclause of ISO26262, as the SGs are high-level requirements too. However, the equivalent to a failure mode in our paper. Combine Step 3 of STAP and Step 3 of FMEA to determine the causal factors (causes) of UCAs (failure modes), and Step 4 of FMEA can be used to assess risk SGs in ISO26262 are more specific than the SCs of the same level in STPA [9]. the causal factors (causes) of UCAs (failure modes), and Step 4 of FMEA can be used to assess risk a ccord Dra inw g to th e ISs O2 afety 6262 co . The ntrolgenera structure l step of s th ofe osy ur stpr em opto osed identi metho fy th de apo re tenti shown al U in CA Fis gure lead 4 in , g anto d t th he e according to ISO26262. The general steps of our proposed method are shown in Figure 4, and the specific steps of STPAF are described in detail below. system-level hazards. The control structure diagram shows the boundary of the system under specific steps of STPAF are described in detail below. analysis and its interface, and information it contains can be used to define an item. 4.2. Step 1: System Engineering Fundamentals Establishment and UCAs Identification STPAFT begins with the establishment of system engineering fundamentals which is similar to the first step of STPA, including system-level accidents and hazards identification, corresponding SCs determination and safety control structure establishment. Figure 4. General steps of the proposed method with the implementation steps of STPAFT on the left Figure 4. General steps of the proposed method with the implementation steps of STPAFT on the left hand side and the outputs of STPAFT required in ISO26262 concept phase on the right hand side. hand side and the outputs of STPAFT required in ISO26262 concept phase on the right hand side. 4.2.2. UCAs Identification Identify the UCAs leading to system-level hazards identified in the last step according to the four categories [3] (a control action not provided, a control action provided incorrectly, a control action provided at wrong timing/order, and a control action stopped too soon/applied too long) Appl. Sci. 2020, 10, 7400 9 of 23 4.2. Step 1: System Engineering Fundamentals Establishment and UCAs Identification STPAFT begins with the establishment of system engineering fundamentals which is similar to the first step of STPA, including system-level accidents and hazards identification, corresponding SCs determination and safety control structure establishment. 4.2.1. System Engineering Fundamentals Establishment As mentioned in Section 3, the consequences of hazardous events in ISO26262 could be determined by integrating accidents in STPA with operating modes and operational situations. A “hazard” of STPA could be mapped to a “hazardous event” of ISO26262. In order to distinguish the “hazard” of STPA from the “hazard” of ISO26262, we use “ the system-level hazard” here to present the “hazard” of STPA, and the “vehicle-level hazard” to present the ”hazard” of ISO26262 in the rest part of this paper. The first step of STPA includes: Define the “loss” of the system accident in STPA with limitation to the scope of harm defined by ISO26262 to be analyzed. Identify system-level hazards leading to the accidents and corresponding operating modes and operational situations from the descriptions of identified system-level hazards. Determine corresponding vehicle-level SCs which could be used to support the SGs determination subclause of ISO26262, as the SGs are high-level requirements too. However, the SGs in ISO26262 are more specific than the SCs of the same level in STPA [9]. Draw the safety control structure of the system to identify the potential UCAs leading to the system-level hazards. The control structure diagram shows the boundary of the system under analysis and its interface, and information it contains can be used to define an item. 4.2.2. UCAs Identification Identify the UCAs leading to system-level hazards identified in the last step according to the four categories [3] (a control action not provided, a control action provided incorrectly, a control action provided at wrong timing/order, and a control action stopped too soon/applied too long) by examining the safety control structure. Information of UCAs could be helpful in the determination of operating modes, operational situations and the controllability for each hazardous event. Corresponding SCs could be determined by adding leading words like “should” or “must” in the description of UCAs. 4.3. Step 2: Hazardous Events Classification and SGs Determination In this step, the FMEA technique is integrated for risk assessment. Each hazard identified could be classified with two factors (S and E) [9]. The controllability for each hazardous event to assess whether a situation is usually controllable [36] could be determined by the identified operational situations and UCAs. Turn the SCs for system-level hazards determined above into the SGs for each hazardous event corresponding to their ASILs. 4.4. Step 3: Causal Factors Identification and FSRs Creation With the help of the FMEA technique and the guide words provided by STPA [37], the identification of possible causal factors becomes more detailed at the components level. In order to make better use of FMEA, a functional structure with more details of the system under analysis should be created. Generate corresponding SCs for causal factors identified. Since SCs for UCAs and causal factors are all used to describe how to avoid or mitigate hazards, they could be mapped with FSRs of ISO26262. Appl. Sci. 2020, 10, 7400 10 of 23 Turn the SCs into corresponding FSRs according to the requirements in the 7.4 subclause in ISO26262 Part 3 [6]. 5. Case Study In this section, we will use the FLEDS in the Scania trucks [38] as a case study to show how STPAFT performs analysis and how to generate/support all work products required/recommended in the concept phase of ISO26262. The FLEDS is one of the safety-critical E/E system in Scania trucks. Dysfunctional behaviors of such system could result in hazards, such as stop of the engine and loss of power-assisted steering [38]. 5.1. The FLEDS In this section, we will show how the FLEDS works and what components it consists of. There are Appl. Sci. 2020, 10, x FOR PEER REVIEW 10 of 23 two major functions in the FLEDS: FC1: Low fuel level warning and FC2: Fuel level estimation and display. FC1 is responsible for warning a driver that the fuel level is below a measurable limit of the Coordinator ECU system (COO) is the core ECU of FLEDS and responsible for all functions tank capacity, even if the driver does not often check the fuel gauge. FC2 is to measure and present the related to the fuel level calculation. Three inputs are required by COO. They are: fuel level in the instrument cluster to meet the need of the driver to know the current fuel level in the fuel tank. − The Fuel estimated level signfuel al fro level m fuel and lev the el sen warning sor (FLS ar)e both presented in the instrument cluster. Thr − ee electr Fuel ra onic te sicontr gnal ol frounit m EM (ECU) S systems make up the FLEDS, which are engine management − Parking brake status from parking brake switch (PBS) system, instrument cluster, and coordinator. Each ECU system contains several allocation elements (AEs) which are pieces of code responsible for realizing user functions. There are two AEs allocated in AE01 is the allocation element responsible for the fuel level estimation. The fuel level measured the coordinator ECU system (COO) used to estimate and display the fuel level: AE01 and AE02. Other by the FLS is first converted to a voltage value and then converted to a percentage of the total capacity. parts of the FLEDS include a fuel level sensor (FLS) placed in the tank to estimate and check the fuel The result and the fuel consumption rate calculated by EMS are used as the input of Kalman filter level, a parking brake switch (PBS) to provide parking brake status which is required for the purposes algorithm, and the current fuel level is finally obtained. This result will be sent to ICL to display the of refuel detection, and a battery to supply power to ECU systems. We show the components and current fuel level. Then AE02 compares the calculation results from AE01 with the tank capacity to functional structure of the FLEDS in Figure 5. determine whether to activate a low fuel level warning. Figure 5. Functional structure composed of electronic control unit (ECU) systems of fuel level Figure 5. Functional structure composed of electronic control unit (ECU) systems of fuel level estimation and estdisplay imation system and disp (FLEDS). lay system (FLEDS). Engine management system ECU (EMS) is responsible for all the engine related functions. 5.2. Applying STPAFT The function of instrument cluster ECU system (ICL) is to display indications to the driver, such as Figure 6 presents the results of STPAFT process which could support the generation of the work warning lamps. products required by the concept phase of ISO26262, described with one of the results of our analysis. Coordinator ECU system (COO) is the core ECU of FLEDS and responsible for all functions related The blue arrows between the boxes, such as S1, S2 to I5, S2 to I2, I3, I4, and SF1 to I6, SF2 to I7, indicate to the fuel level calculation. Three inputs are required by COO. They are: that the work products of ISO26262 can be directly obtained from the results of STPAFT. The gray arrows between the boxes, such as S3, S5 to I8, S4 to I1, indicate that the products required by - Fuel level signal from fuel level sensor (FLS) ISO26262 can be derived from the analysis results of STPAFT. The orange blocks from SF1 to SF3 are - Fuel rate signal from EMS resul - ts o Parking btainedbrake by integr status atin fr g om FM parking EA. SF1 brake and Sswitch F2 presen (PBS) t the hazardous event classification and the ASIL determination results. SF3 is an example of the causal factors and corresponding SC identified. STPAFT realizes the classification of hazardous events and the determination of ASILs through the integration of FMEA technique. Another reason for integrating FMEA is that FMEA could help STPA with the identification of causal factors by focusing on the lowest level components. More detailed information about the whole process of applying STPAFT will be covered in the following sections. Appl. Sci. 2020, 10, 7400 11 of 23 AE01 is the allocation element responsible for the fuel level estimation. The fuel level measured by the FLS is first converted to a voltage value and then converted to a percentage of the total capacity. The result and the fuel consumption rate calculated by EMS are used as the input of Kalman filter algorithm, and the current fuel level is finally obtained. This result will be sent to ICL to display the current fuel level. Then AE02 compares the calculation results from AE01 with the tank capacity to determine whether to activate a low fuel level warning. 5.2. Applying STPAFT Figure 6 presents the results of STPAFT process which could support the generation of the work products required by the concept phase of ISO26262, described with one of the results of our analysis. The blue arrows between the boxes, such as S1, S2 to I5, S2 to I2, I3, I4, and SF1 to I6, SF2 to I7, indicate that the work products of ISO26262 can be directly obtained from the results of STPAFT. The gray arrows between the boxes, such as S3, S5 to I8, S4 to I1, indicate that the products required by ISO26262 can be derived from the analysis results of STPAFT. The orange blocks from SF1 to SF3 are results obtained by integrating FMEA. SF1 and SF2 present the hazardous event classification and the ASIL determination results. SF3 is an example of the causal factors and corresponding SC identified. STPAFT realizes the classification of hazardous events and the determination of ASILs through the integration of FMEA technique. Another reason for integrating FMEA is that FMEA could help STPA with the identification of causal factors by focusing on the lowest level components. More detailed information about the whole process of applying STPAFT will be covered in the following sections. 5.2.1. System Engineering Foundations Establishment As mentioned in Section 4, the first step begins with determining vehicle-level accidents, associated hazards, corresponding system-level SCs, and drawing a safety control structure. An example of vehicle-level accidents related to the FLEDS could be defined as AC1: The vehicle has a rear-end collision. One of the system-level hazards that could result in AC1 is determined as H1 (an example): The vehicle has an unintended deceleration or stop because no more fuel could be collected from the tank when driving on a highway with wet roads. The safety constraint for H1 is SC-1: The vehicle must always have enough fuel to avoid unintended deceleration or stop when driving on a highway with wet road. In STPAFT, system-level SCs as top-level safety requirements are used to mitigate hazards, which is similar to the role of SGs in ISO26262. Therefore, system-level SCs in STPAFT could correspond to SGs in ISO26262. The vehicle-level hazard VH1 for ISO26262 could be derived as: The vehicle has an unintended deceleration or stop because no more fuel could be collected in the tank. The particular worst-case environmental condition here is “driving on a highway with wet roads” which is represented in S2 in Figure 6. Therefore, the operating mode and operational situation can be determined as O1: Driving on a highway with wet roads. More possible operational situations are represented in Section 5.2.3. Then the corresponding hazardous event HE1 could be determined by combining VH1 with O1: The vehicle has an unintended deceleration or stop because no more fuel could be collected in the tank when driving on a highway with wet roads and the consequence of hazardous events could also be derived as CHE1: The vehicle has a rear-end collision with the following vehicle travelling at high speed when driving on a highway with wet roads. The next step in STPAFT is to establish a safety control structure to identify potentially hazardous control actions that could violate the SCs and lead to H1. The information from safety control structure could be taken to conduct the item definition. So, S4 in STPAFT is mapped to I1 in ISO26262 in Figure 6. Figure 7 shows the control structure diagram of the FLEDS at the architectural design level. In this structure, FLEDS is considered as a controller, the fuel tank is a controlled process and the driver is treated as an actuator to refuel the tank according to the FLEDS’s commands. Appl. Sci. 2020, 10, 7400 12 of 23 Appl. Sci. 2020, 10, x FOR PEER REVIEW 11 of 23 Figure 6. The analysis process of STPAFT and the corresponding relationship between the analysis Figure 6. The analysis process of STPAFT and the corresponding relationship between the analysis results and the work products required by ISO26262-Part 3: Concept phase. results and the work products required by ISO26262-Part 3: Concept phase. 5.2.1. System Engineering Foundations Establishment As mentioned in Section 4, the first step begins with determining vehicle-level accidents, associated hazards, corresponding system-level SCs, and drawing a safety control structure. An example of vehicle-level accidents related to the FLEDS could be defined as AC1: The vehicle has a rear-end collision. One of the system-level hazards that could result in AC1 is determined as H1 (an example): The vehicle has an unintended deceleration or stop because no more fuel could be collected from the tank when driving on a highway with wet roads. The safety constraint for H1 is SC-1: The vehicle must always have enough fuel to avoid unintended deceleration or stop when driving on a highway with wet road. In STPAFT, system-level SCs as top-level safety requirements are used to mitigate hazards, which is similar to the role of SGs in ISO26262. Therefore, system-level SCs in STPAFT could correspond to SGs in ISO26262. The vehicle-level hazard VH1 for ISO26262 could be derived as: The vehicle has an unintended deceleration or stop because no more fuel could be collected in the tank. The particular worst-case environmental condition here is “driving on a highway with wet roads” which is represented in S2 Appl. Sci. 2020, 10, x FOR PEER REVIEW 12 of 23 in Figure 6. Therefore, the operating mode and operational situation can be determined as O1: Driving on a highway with wet roads. More possible operational situations are represented in Section 5.2.3. Then the corresponding hazardous event HE1 could be determined by combining VH1 with O1: The vehicle has an unintended deceleration or stop because no more fuel could be collected in the tank when driving on a highway with wet roads and the consequence of hazardous events could also be derived as CHE1: The vehicle has a rear-end collision with the following vehicle travelling at high speed when driving on a highway with wet roads. The next step in STPAFT is to establish a safety control structure to identify potentially hazardous control actions that could violate the SCs and lead to H1. The information from safety control structure could be taken to conduct the item definition. So, S4 in STPAFT is mapped to I1 in ISO26262 in Figure 6. Figure 7 shows the control structure diagram of the FLEDS at the architectural design level. In this structure, FLEDS is considered as a controller, the fuel tank is a controlled process Appl. Sci. 2020, 10, 7400 13 of 23 and the driver is treated as an actuator to refuel the tank according to the FLEDS’s commands. Figure 7. STPA high level control structure for the identification of unsafe control actions. Figure 7. STPA high level control structure for the identification of unsafe control actions. 5.2.2. UCAs Identification 5.2.2. UCAs Identification As mentioned above, the FLEDS has two main functions: FC1 and FC2. For FC1, the control action As mentioned above, the FLEDS has two main functions: FC1 and FC2. For FC1, the control is CA1: Provide a warning to indicate the driver when there is a low fuel level. For FC2, the control action is CA1: Provide a warning to indicate the driver when there is a low fuel level. For FC2, the action is CA2: Supply the current fuel level to the driver. Therefore, according to three of the four UCA control action is CA2: Supply the current fuel level to the driver. Therefore, according to three of the types (the control actions in our study do not have a duration problem), the unsafe control actions four UCA types (the control actions in our study do not have a duration problem), the unsafe control UCA1 for CA1, the unsafe control actions UCA2-1 and UCA2-2 of CA2 could be identified, as shown actions UCA1 for CA1, the unsafe control actions UCA2-1 and UCA2-2 of CA2 could be identified, in Table 3. For further exploration of causal factors and determination of ASIL for HE1, the control as shown in Table 3. For further exploration of causal factors and determination of ASIL for HE1, the actions and the UCAs identified here will correspond to functions and failure modes in the following control actions and the UCAs identified here will correspond to functions and failure modes in the FMEA analysis. following FMEA analysis. We transform the description of unsafe control actions into corresponding security constraints Table 3. Possible unsafe control actions leading to H1. by adding guide words, such as “should” and “must”, as shown in Table 4. Provide at Wrong Control Action Not Provide Provide But Incorrect Time/Order UCA1: No warning Provide a warning signal : : : signal provided Supply the current fuel UCA2-1: No fuel UCA2-2: Supplied but : : : level value level supplied too high We transform the description of unsafe control actions into corresponding security constraints by adding guide words, such as “should” and “must”, as shown in Table 4. Table 4. Safety constraints for UCAs. The FLEDS should activate a warning to indicate the driver when there is a low fuel level in SC.UCA1 the tank SC.UCA2-1 The FLEDS shall always indicate the total fuel level in the tank when driving. The deviation of the fuel level estimation by FLEDS shall not exceed the preset allowable SC.UCA2-2 deviation from the actual volume in the tank. Appl. Sci. 2020, 10, 7400 14 of 23 5.2.3. Classification of Hazardous Events and Determination of ASIL FMEA now could be used for the classification of HE1 according to ISO26262. Steps will be performed as follows: Fill CA1, CA2, UCA1, VH1, AC1 and possible operational situations into corresponding columns of FMEA in Table 5. Determine the ASIL for each hazardous event identified, taking HE1 as an example. As mentioned above, HE1 identified could be classified with two factors (S and E). The controllability for each hazardous event could be determined by the operational situations together with UCAs identified. The hazard events HE1 is a rear end collision on a highway with wet roads, which could cause fatal injuries, so the severity is determined as S3. Probability of exposure could be E3, medium probability. According to the operating modes and operational situation O1: driving on a highway with wet roads, and the unsafe control action UCA1: The FLEDS does not provide a warning signal when there is a low fuel level; the situation is dicult to control or uncontrollable, so the controllability is assigned as C3. Therefore, the ASIL of the hazardous event HE1 could be determined as ASIL C. The ASILs for VH1 under di erent operational situations are represented in Table 5. Formulate SGs according to each corresponding ASIL, still taking HE1 as an example. The SG for HE1 could be formulated according to SC-1 as SG.1: The vehicle must always provide correct information about the current fuel level in the tank to avoid unintended deceleration or stop when driving on a highway with wet roads. 5.2.4. Causal Factors Identification and FSRs Creation In order to determine how each UCA could happen using FMES, a detailed structure of the FLEDS is illustrated in Figure 8. We use Figure 8 and the guide words for causal factors in Figure 9 [39] to identify possible causal factors leading to UCAs. With the focus of FMEA on the lowest level components, we can identify the causal factors more systematically, so more detailed safety constraints could be derived, which is conducive to the refinement of FSR. We use a hierarchical structure to describe the identified causal factors for each UCA in Table 6, in 1 5 which “O” represents the highest level and “O” represents the lowest. This hierarchical structure presents how unsafe interactions, errors and failures propagate through the system and lead to UCAs. The most important thing is that the hierarchical structure of causal factors would be of great benefit for the allocation of FSRs to the system architecture design. Next, the SCs for causal factors are generated and the results of this step will be used to build the functional safety concept and determine the FSRs. The primary intention of the presentation of all the SGs and FSRs derived from SCs in this section are to illustrate how a comprehensive set of requirements could be derived from STPAFT analysis results. According to the causal factors identified in Table 6, related SCs could be identified: SC.CF.1: The input signals for estimating the total fuel level shall be good status (meaning the signals are in the range and correct). SC.CF.1-1: The FLS shall always keep running normally, and measure fuel level data accurately. SC.CF.1-2: The EMS shall always calculate the fuel rate correct. SC.CF.2: The input parameters used for estimation of the total fuel level shall be of good status; a replacement value shall be considered and kept. SC.CF.2-1: The correct parameters of FLS shall be set. SC.CF.2-2: The correct parameters of the fuel tank shall be set. Appl. Sci. 2020, 10, 7400 15 of 23 SC.CF.3: The measured fuel level signal shall be filtered to avoid the fuel level changing rapidly in some situations, such as driving in long curves, hills and slopes. SC.CF.4: The algorithm for total fuel level estimation shall be designed appropriately and a feedback should be set to avoid the deviation of more or less than a permissible error when there are erroneous or unavailable input signals or parameters. SC.CF.4-1: The mapping of voltage to volume shall be correct. SC.CF.5: When the estimated fuel level reaches a limit of the measurable volume in the tank, the low fuel level warning shall be provided one time. SC.CF.6: The ICL shall always function properly, including the gauge and the lamp. SC.CF.7: Stability and reliability of Controller Area Network (CAN) buses and communication cables shall be guaranteed through certain approaches, such as redundancies of the CAN buses and communication cables. SC.CF.8: The battery shall have enough capacity and ensure power supply continuous and reliable. The electrical connections between the battery and ECUs shall be stable. Then, the corresponding FSRs could be derived from these SCs according to the requirements that FSR shall specify strategies for fault avoidance, fault detection and control of faults or the resulting of malfunctioning behaviors, etc. in ISO26262 Part 3. FSR1: The input signals for estimating the total fuel level shall be good status (meaning the signals are in the range and correct). Considered input signals are: fuel level, fuel rate, and parking brake applied. In case input signals are not of good status, a replacement value shall be considered. FSR2: The input parameters used for estimation of the total fuel level shall be of good status; a replacement value shall be considered and kept. Considered input parameters are sensor parameters and tank parameters. FSR3: The measured fuel level signal shall be filtered to avoid rapid fuel level changes in some situations, such as driving in long curves, hills and slopes. FSR4: The algorithm for total fuel level estimation shall be designed appropriately and use feedback to gain information that should be adjusted in a way that will not result in a deviation of more or less than a permissible error when there are erroneous or unavailable input signals or parameters. FSR5: Stability and reliability of CAN buses and communication cables shall be guaranteed through certain approaches, such as redundancies of the CAN buses and communication cables. FSR6: When the estimated fuel level reaches below the predetermined limit value, the low fuel level warning should warn one time. FSR7: There shall be fault detection strategies for hardware in the FLEDS such as the lamp, gauge, and the battery, etc., and shall active warnings when they go wrong. If the FLEDS lose its function, there shall be certain approaches for the driver to obtain the fuel level value. Appl. Sci. 2020, 10, 7400 16 of 23 Table 5. Hazardous events classification and ASIL determination using FMEA. Cause Actions E ect Failure Modes Function (UCAs) (CFs) (SCs) System-Level Accident Operational Situations S E C ASIL Hazard Provide a warning to indicate The FLEDS does not provide a warning to Highway with wet roads 3 3 3 C the driver when there is a low indicate the driver when there is a low fuel City driving, snow and fuel level level in the tank. 3 2 3 B AC1 H1 Shown in ice driving speed 50km/h The FLEDS does not supply a fuel level to a Section 5.2.4 driver. Supply the current fuel level to City driving slippery 2 2 A the driver road, high trac The fuel level supplied by FLEDS is much higher than the actual level. 1Free way 3 2 2 A Appl. Sci. 2020, 10, x FOR PEER REVIEW 15 of 23 5.2.4. Causal Factors Identification and FSRs Creation In order to determine how each UCA could happen using FMES, a detailed structure of the FLEDS is illustrated in Figure 8. We use Figure 8 and the guide words for causal factors in Figure 9 [39] to identify possible causal factors leading to UCAs. With the focus of FMEA on the lowest level components, we can identify the causal factors more systematically, so more detailed safety constraints could be derived, which is conducive to the refinement of FSR. We use a hierarchical structure to describe the identified causal factors for each UCA in Table 6, in which “①” represents the highest level and “⑤” represents the lowest. This hierarchical structure presents how unsafe interactions, errors and failures propagate through the system and lead to UCAs. The most important thing is that the hierarchical structure of causal factors would be of great benefit for the allocation of FSRs to the system architecture design. Next, the SCs for causal factors are generated and the results of this step will be used to build Appl. Sci. 2020, 10, x FOR PEER REVIEW 16 of 23 the functional safety concept and determine the FSRs. The primary intention of the presentation of all the SGs and FSRs derived from SCs in this section are to illustrate how a comprehensive Appl. Sci. 2020, 10, 7400 17 of 23 SC.CF.4: The algorithm for total fuel level estimation shall be designed appropriately and a set of requirements could be derived from STPAFT analysis results. feedback should be set to avoid the deviation of more or less than a permissible error when there are erroneous or unavailable input signals or parameters. SC.CF.4-1: The mapping of voltage to volume shall be correct. SC.CF.5: When the estimated fuel level reaches a limit of the measurable volume in the tank, the low fuel level warning shall be provided one time. SC.CF.6: The ICL shall always function properly, including the gauge and the lamp. SC.CF.7: Stability and reliability of Controller Area Network (CAN) buses and communication cables shall be guaranteed through certain approaches, such as redundancies of the CAN buses and communication cables. SC.CF.8: The battery shall have enough capacity and ensure power supply continuous and reliable. The electrical connections between the battery and ECUs shall be stable. Then, the corresponding FSRs could be derived from these SCs according to the requirements that FSR shall specify strategies for fault avoidance, fault detection and control of faults or the resulting of malfunctioning behaviors, etc. in ISO26262 Part 3. FSR1: The input signals for estimating the total fuel level shall be good status (meaning the signals are in the range and correct). Considered input signals are: fuel level, fuel rate, and parking brake applied. In case input signals are not of good status, a replacement value shall be coFig nsiure der 8 ed. . Det ailed function structure of FLEDS with ECU systems and allocation elements (AEs). Figure 8. Detailed function structure of FLEDS with ECU systems and allocation elements (AEs). According to the causal factors identified in Table 6, related SCs could be identified: SC.CF.1: The input signals for estimating the total fuel level shall be good status (meaning the signals are in the range and correct). SC.CF.1-1: The FLS shall always keep running normally, and measure fuel level data accurately. SC.CF.1-2: The EMS shall always calculate the fuel rate correct. SC.CF.2: The input parameters used for estimation of the total fuel level shall be of good status; a replacement value shall be considered and kept. SC.CF.2-1: The correct parameters of FLS shall be set. SC.CF.2-2: The correct parameters of the fuel tank shall be set. SC.CF.3: The measured fuel level signal shall be filtered to avoid the fuel level changing rapidly in some situations, such as driving in long curves, hills and slopes. Figure 9. Causal factors of UCAs to be considered in each part of the safety control structure. Figure 9. Causal factors of UCAs to be considered in each part of the safety control structure. Appl. Sci. 2020, 10, 7400 18 of 23 Table 6. Causal factors analysis for unsafe control actions of FLEDs. UCAs Causal Factors O 1 The gauge has a mechanical fault O 1 The gauge function in ICL has bugs O 4 Electrical fault in FLS O Incorrect FLS value The fuel level supplied by O 4 Mechanical fault in FLS FLEDS is much higher O 4 Tank parameter set incorrectly O 2 Incorrect fuel level than the actual level. O 3 Incorrect calculation of O 1 Incorrect estimation of tank capacity O 4 Incorrect FLS parameters fuel level by Kalman filter O 3 Incorrect mapping of O Fault in mapping look up table voltage to volume % O 2 Incorrect fuel rate O 3 The calculations of fuel rate by EMS is incorrect 2460 The gauge function in ICL has bugs O 3 Hardware fault in COO O 4 Fault in the power supply O Problems in COO O 3 No power supply fed O 4 There is a fault in the power cable between COO and to COO O 1 No total fuel level The FLEDS does not power supply received by ICL supply a fuel level to a O Cut in communication cable driver. O 2 Communication problem between COO O CAN message that has O 4 Fault in CAN bus and ICL total fuel level lost O 1 Hardware fault in ICL O 1 The gauge has a mechanical fault Appl. Sci. 2020, 10, 7400 19 of 23 Table 6. Cont. UCAs Causal Factors O 2 Cut in communication cable O Communication O 2 Message that contains problem between COO the activation of warning O 3 Fault in CAN bus and ICL is lost O 1 Fault in warning lamp O 1 Bug in warning lamp function in ICL O 2 Erroneous value of tank size O 4 Incorrect mapping of O 5 Fault in mapping look The FLEDS does not voltage to volume % up table provide a warning to indicate the driver when 4 5 O The fuel level value is O Low pass filter there is a low fuel level in filtered incorrectly equation has faults the tank. O 5 Electrical fault in O 1 The low fuel level fuel sensor O Erroneous fuel level O Incorrect FLS value warning function in COO O 2 Kalman filter estimates O 5 Mechanical fault in outputs incorrectly fuel level erroneously fuel sensor O The tank parameters set incorrectly O 4 Errors in the calculation of tank capacity O 5 Incorrect FLS parameters O 3 Fuel rate errors O 4 The calculations of fuel rate by EMS is incorrect Appl. Sci. 2020, 10, 7400 20 of 23 6. Discussion Although ISO26262 Part 3 has stated in its scope of application that the hazards addressed in this document refer to the hazards caused by malfunctioning behaviors of items and their interaction, the HARA process only focuses on hazards caused by malfunctioning behaviors, and if every other system in the vehicle is suciently independent, they are assumed to be functioning correctly. However, it would be a bit arbitrary to conclude that HARA is only aimed at the hazards caused by item failures, because malfunctioning behavior refers to failure or unintended behaviors related to the design intent, but ISO26262 does not specify what “unintended behavior” exactly includes. While for STPA, accidents result from inadequate control of component failures, dysfunctional interaction of components, external disturbance, etc. In addition, STPA does not deal with risk assessment and only focuses on the causes of inadequate control or enforcement of safety constraints leading to accidents. In order to meet all the requirements of ISO26262 in the concept phase, we combine STPA and FMEA to form a new analysis method STPAFT. STPA and FMEA can complement each other, so STPAFT not only has the advantages of STPA in hazard analysis, but also can evaluate risk. Through the focus of FMEA on low-level components, STPAFT can obtain more detailed causal factors, which is very helpful for the functional safety requirements derivation in the concept stage of ISO26262. Another point worthy of note is that ISO26262 does not seem to make systematic requirements for the definition of an item. Therefore, we can use information of STPA on safety control structure to clearly describe an item in terms of system function and system boundary. In the area of the rapidly developing automotive domain, the increasing implementation of advanced functions and intelligence in vehicles greatly improves the degree of vehicle automation. In order to ensure functional safety, factors leading to hazards other than component failure must be taken into account. Therefore, it may be a trend to integrate STPA into the functional safety standards. 7. Conclusions and Future Work For automotive systems, which could be described as a safety-critical system, they must fully satisfy the safety requirements as well as the functional requirements. Safety requirements describe the characteristics that a system must have in order to remain safe, and also key attributes that must be ensured to mitigate or avoid potentially unacceptable hazards. Violation of safety requirements will expose the system to various possible risks. Therefore, safety requirements must be considered to reduce risk in the design and development process of automotive systems. Nowadays, the intensive use of software and the increase in functional requirements have significantly increased the complexity of automotive systems. Therefore, the traditional safety analysis technology based on reliability theory will have certain limitations in the safety analysis of a modern complex safety-critical system, so it is not suitable to be used alone. In this paper, we combined STPA and FMEA to obtain a new method called STPAFT, which has the advantages of both STPA and FMEA. It not only expands the scope of causes of hazards, but also could assess risk. Taking the FLEDS system as a case study, we described in detail the analysis process of STPAFT and the corresponding relationship between the analysis results and work products required in the ISO26262 concept phase. It is found that the analysis results of STPAF can fully meet the requirements of ISO26262. In addition, through the analysis process, the information used to establish safety control structure can make up for the lack of systematic requirements of an item in ISO26262. Then, through the focus of FMEA on related components level, we created more targeted safety constraints, which is conducive to the derivation of safety goals and functional safety requirements. Appl. Sci. 2020, 10, 7400 21 of 23 So, the use of STPAFT will be helpful to give recommendations for the early development and design process of automotive systems. In our future work, we plan to explore the role of STPAFT in the safety analysis of fully automated vehicles with a higher proportion of software, and further understand the advantages and limitations of using STPA to support the ISO26262 concept phase. In addition, we plan to introduce the model-based safety analysis technique into the implementation process of STPAF, and strive to abstract STPAFT into a standard architecture, so as to facilitate its automatic implementation, and improve the analysis eciency, correctness, consistency and traceability. Author Contributions: Conceptualization, L.C. and J.J.; methodology, L.C. and T.Z.; writing—original draft preparation, L.C.; writing—review and editing, L.C. and T.Z.; project administration, J.J.; funding acquisition, T.Z. and J.J. All authors have read and agreed to the published version of the manuscript. Funding: This research received no external funding. Conflicts of Interest: The authors declare no conflict of interest. References 1. Flemming, C. Safety-Driven Early Concept Analysis and Development. Ph.D. Thesis, Massachusetts Institute of Technology, Cambridge, MA, USA, 2015. 2. Suo, D.; Yako, S.; Boesch, M.; Post, K. Integrating STPA into ISO26262 Process for Requirement Development; Safety of the Intended Functionality; SAE: Washington, DC, USA, 2017. [CrossRef] 3. Leveson, N. Engineering a Safer World; MIT Press: Cambridge, MA, USA, 2012. 4. Leveson, N. Completeness in formal specification language design for process-control systems. In Proceedings of the Third Workshop on Formal Methods in Software Practice, Portland, OR, USA, August 2000; pp. 75–87. 5. Leveson, N. A new accident model for engineering safer systems. Saf. Sci. 2004, 42, 237–270. [CrossRef] 6. ISO. 26262: Road Vehicles—Functional Safety, International Organization for Standardization; ISO: Geneva, Switzerland, 2018. 7. Sundaram, D.; Vernacchia, P.; Wagner, M.S.; Thomas, J.; Placke, S. Application of STPA to an Automotive Shift-by-Wire System; STAMP Workshop: Cambridge, MA, USA, 2014. 8. Haneet, S.M.; Thomas, B.; Sudeep, P. Application of systems theoretic process analysis to a lane keeping assist system. Reliab. Eng. Syst. Saf. 2017, 167, 177–183. 9. Abdulkhaleq, A.; Daniel, L.; Stefan, W.; Jürgen, R.; Norbert, B.; Ludwig, R.; Thomas, R.; Hagen, B. A Systematic Approach Based on STPA for Developing a Dependable Architecture for Fully Automated Driving Vehicles. Procedia Eng. 2017, 179, 41–51. [CrossRef] 10. Abdulkhaleq, A.; Wagner, S. Experiences with Applying STPA to Software-Intensive Systems in the Automotive Domain. In Proceedings of the 2013 STAMP Conference at MIT, Boston, MA, USA, 26–28 March 2013. 11. Abdulkhaleq, A.; Wagner, S. A software safety verifification method based on system-theoretic process analysis. In Proceedings of the International Conference on Computer Safety, Reliability, and Security, Delft, the Netherlands, 22–25 September 2014; Springer: Berlin/Heidelberg, Germany, 2014; pp. 401–412. 12. Abdulkhaleq, A.; Wagner, S.; Leveson, N. A Comprehensive Safety Engineering Approach for Software-Intensive Systems Based on STPA. Procedia Eng. 2015, 128, 2–11. [CrossRef] 13. Hommes, Q.V.E. Review and Assessment of the ISO26262 Draft Road Vehicle—Functional Safety; SAE Technical Paper 2012-01-0025; ISO: Geneva, Switzerland, 2012. [CrossRef] 14. Hommes, Q.V.E. Safety Analysis Approaches for Automotive Electronic Control Systems. 2015. Available online: https://www.nhtsa.gov/sites/nhtsa.dot.gov/files/2015sae-hommes-safetyanalysisapproach es.pdf/2015SAE-Hommes-SafetyAnalysisApproaches.pdf (accessed on 22 January 2015). 15. Periera, S.; Grady, L.; Howard, J. A system-theoretic hazard analysis methodology for a non-advocate safety assessment of the ballistic missile defense system. In Proceedings of the 2006 AIAA Missile Sciences Conference, Monterey, CA, USA, 14–16 November 2006. 16. Bladine, A. Systems Theoretic Hazard Analysis (STPA) Applied to the Risk Review of Complex Systems: An Example from the Medical Device Industry. Ph.D. Thesis, MIT, Cambridge, MA, USA, 2013. Appl. Sci. 2020, 10, 7400 22 of 23 17. Martin, R.; Christian, H. Use of STPA as a diverse analysis method for optimization and design verification of digital instrumentation and control systems in nuclear power plants. Nucl. Eng. Des. 2018, 331, 125–135. 18. Fleming, C.H.; Spencer, M.; Thomas, J.; Leveson, N.; Wilkinson, C. Safety assurance in NextGen and complex transportation systems. Saf. Sci. 2013, 55, 173–187. [CrossRef] 19. Hu, J.; Zheng, L.; Xu, S. Safety analysis of wheel brake system based on STAMP/STPA and Monte Carlo simulation. J. Syst. Eng. Electron. 2018, 29, 1327–1339. 20. Mogles, N.; Padget, J.; Bosse, T. Systemic approaches to incident analysis in aviation: Comparison of STAMP, agent-based modelling and institutions. Saf. Sci. 2018, 108, 59–71. [CrossRef] 21. Wang, Y.; Sun, Y.; Li, C. Aircraft flight safety analysis and evaluation based on IDAC-STPA model. Syst. Eng. Electron. 2019, 41, 1056–1062. 22. Wang, Y.; Wang, L.; Hu, J.; Zhou, Y. Modeling and analysis of IMA inter-partition communication safety requirement based on STPA. In Proceedings of the 2017 8th IEEE International Conference on Software Engineering and Service Science (ICSESS), Beijing, China, 24–26 November 2017; pp. 284–287. 23. Yang, Z.; Lim, Y.; Tan, Y. An Accident Model with Considering Physical Processes for Indoor Environment Safety. Appl. Sci. 2019, 9, 4732. [CrossRef] 24. Bolbot, V.; Theotokatos, G.; Boulougouris, E.; Psarros, G.; Hamann, R. A Novel Method for Safety Analysis of Cyber-Physical Systems—Application to a Ship Exhaust Gas Scrubber System. Safety 2020, 6, 26. [CrossRef] 25. Banda, O.A.V.; Goerlandt, F.; Salokannel, J.; van Gelder, P.H. An initial evaluation framework for the design and operational use of maritime STAMP-based safety management systems. WMU J. Marit. A . 2019, 18, 451–476. [CrossRef] 26. Zhou, Z.; Zi, Y.; Chen, J.; An, T. Hazard Analysis for Escalator Emergency Braking System via System Safety Analysis Method Based on STAMP. Appl. Sci. 2019, 9, 4530. [CrossRef] 27. Nan, Q.; Liang, M. Safety Requirements Analysis for a Launching Control System Based on STPA. In Proceedings of the 2019 IEEE International Conference on Mechatronics and Automation (ICMA), Tianjin, China, 4–7 August 2019; pp. 1201–1205. 28. Jiang, W.; Han, W.; Zhou, J.; Huang, Z. Analysis of Human Factors Relationship in Hazardous Chemical Storage Accidents. Int. J. Environ. Res. Public Health 2020, 17, 6217. [CrossRef] [PubMed] 29. Feng, T.; Wang, L.; Hu, J.; Chen, M. A Safety Analysis Method for FGS Based on STPA. In Advances in Intelligent, Interactive Systems and Applications. IISA 2018. Advances in Intelligent Systems and Computing; Xhafa, F., Patnaik, S., Tavana, M., Eds.; Springer: Cham, Switzerland, 2018; Volume 885, pp. 936–944. 30. Schmid, D. Pilot Homicide-Suicide: A System-Theoretic Process Analysis (STPA) of Germanwings GWI18G. In Advances in Human Aspects of Transportation. AHFE 2018. Advances in Intelligent Systems and Computing; Stanton, N., Ed.; Springer: Cham, Switzerland, 2019; Volume 786. 31. Hardy, K.; Guarnieri, F. Using STAMP in the Risk Analysis of a Contaminated Sediment Treatment Process. In Safety Dynamics. Advanced Sciences and Technologies for Security Applications; Guarnieri, F., Garbolino, E., Eds.; Springer: Cham, Switzerland, 2019. 32. Samadi, J.; Garbolino, E. Systemic Risk Management Approach for CTSC Projects. In Safety Dynamics. Advanced Sciences and Technologies for Security Applications; Guarnieri, F., Garbolino, E., Eds.; Springer: Cham, Switzerland, 2019. 33. Yang, P.; Karashima, R.; Okano, K. Automated inspection method for an STAMP/STPA-fallen barrier trap at railroad crossing. Procedia Comput. Sci. 2019, 159, 1165–1174. [CrossRef] 34. MIL-STD-1629A. Procedures for Performing a Failure Mode, E ects and Criticality Analysis; U.S. Department of Defense: Washington, DC, USA, 1980. 35. I.E.C. 60812: 2018. Analysis Techniques for System Reliability-Procedure for Failure Mode and E ects Analysis (FMEA). Available online: http://www.iec.ch (accessed on 10 August 2018). 36. Monkhouse, H.; Habli, I.; Mcdermid, J. The Notion of Controllability in an autonmous vehicle context. In CARS 2015-Critical Automotive applications; Robustness & Safety: Paris, France, 2015. 37. Thomas, J. Extending and Automating a Systems-Theoretic Hazard Analysis for Requirements Generation and Analysis. Ph.D. Thesis, Massachusetts Inst. Technol., Cambridge, MA, USA, 2013. Appl. Sci. 2020, 10, 7400 23 of 23 38. Dardar, R. Building a Safety Case in Compliance with ISO26262 for Fuel Level Estimation and Display System. Master ’s Thesis, Mälardalen University, School of Innovation, Design and Engineering, Västerås, Sweden, 2014. 39. Rastayesh, S.; Bahrebar, S.; Blaabjerg, F.; Zhou, D.; Wang, H.; Dalsgaard Sørensen, J. A System Engineering Approach Using FMEA and Bayesian Network for Risk Analysis—A Case Study. Sustainability 2020, 12, 77. [CrossRef] Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional aliations. © 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Journal
Applied Sciences – Multidisciplinary Digital Publishing Institute
Published: Oct 22, 2020