Delivering Safety Through Design Using Early Analysis Methods. Mark A. Vernacchia, MSES, PE General Motors Company; Milford, Michigan, USA

Transcription

1 Delivering Safety Through Design Using Early Analysis Methods Mark A. Vernacchia, MSES, PE General Motors Company; Milford, Michigan, USA Keywords: systems engineering, SEFA, STPA, interactions, safety, emergent behavior Abstract This paper describes two system analysis methods used in the GM Systems Safety Process to initiate the process of delivering safety directly through the design process. These analyses facilitate the safety team as an integrated part of design teams early in the design process, a key factor in successful hazard identification, risk assessment, and determination of appropriate content to eliminate or manage potential risk to an acceptable level. Analyses results are used to identify possible revisions to the system content necessary to ensure adequate diagnostic capability and mitigation management prior to design freeze. In addition, these methods determine initial system requirements necessary to support management/mitigation of resulting unintended or unwanted system behavior caused by system element failures. The paper first summarizes how results from a SEFA/STPA analysis are used to identify content revisions to the system architecture necessary to ensure adequate diagnostic capability for mitigation management prior to design freeze. Second, the paper reviews how SEFA/STPA processes identify initial system requirements necessary to support the management/mitigation of unintended or unwanted system behavior caused by system element functional failures. Finally, the paper summarizes how STPA requirements were integrated into the production-released button-based design of the 2018 GMC Terrain shift-by-wire shifter. Introduction Effective safety analysis methods provide value through the entire engineering design, development, testing and manufacturing phases of a system s implementation process. These analysis methods have a significant impact on system content in early phases of a program as major expenditures for critical component procurements and manufacturing tooling have yet to be committed. There is much less cost associated with design changes at this point in the process than there are with changes that occur later in the process (e.g., it is much cheaper to move lines on paper than it is to move/change actual physical tooling lines in a manufacturing environment). Early in the design process, exploration of various design concepts is conducted to determine the optimized balance between system imperatives such as cost, timing, mass, performance, and safety acceptable risk requirements. This system architecture balance phase typically contains tasks such as the ones shown here in Table 1, with some tasks having an iterative nature between them. Of course, if an optimal balance cannot be achieved the iterative nature would be extended to early tasks for modification of Stakeholder Expectations and Initial Requirements.

2 Table 1 System Concept / Architecture Tasks Involving Early Safety Analysis Methods An underlying assumption in Table 1 is that system safety is an integrated part of the system engineering process to be optimally effective. The iterative loop shown in Table 1 above may be further illustrated by a systems engineering cascading conic depiction shown in Figures 1, 2, 3, 4 and 5 below. Figure 1 shows the initial allocation of system imperatives to major systems. Figure 2 shows the interactions between these major systems during the balance, tradeoff and optimizations steps. Figure 3 shows the rebalance and optimization at the top system level leading to an initial concept / architecture and Figure 4 depicts the concept / architecture selection. Figure 1 Initial Allocation to Major Systems Figure 2 Interactions between Major Systems Figure 3 Rebalance and Optimize Initial Concept Figure 4 Selected Concept / Architecture

3 Figure 5 Multiple Level Balancing and Optimization for Continued Concept / Architecture Improvement Figure 5 illustrates the allocation to the major subsystems of each major system where the balance, tradeoff and optimization process repeats at this lower level and updates are transposed back up to the top level. Two levels of evaluation tend to be sufficient for initial safety task activities. Deeper levels of the engineering process are very well served by familiar evaluations methodologies such as DFMEAs, FTAs, and FIAs. Within this systems engineering process framework, safety tasks performed early in the design process support the balance and optimization tasks by identifying what hazardous conditions potentially could arise due to system element misbehavior and assessing the risk associated with such hazards. This effort defines the required system content and the detection and mitigation strategies necessary to eliminate or manage the assigned risk to acceptable levels. Within the GM System Safety Process safety tasks such as Preliminary Hazard Analysis (PHA), Hazard Analysis and Risk Assessment (HARA), SEFA (System Element Fault Analysis) and STPA (Systems-Theoretic Process Analysis) are utilized at this time. It is the latter two tasks that the remainder of this paper describes. This paper focused on two early analysis methodologies used within this system engineering context. The first method is the SEFA technique. The second method is the STPA approach, developed at MIT by Professor Nancy Leveson, which is used to evaluate failures associated with functions assigned to system elements and the impact of these failures on system behaviors during expected operating scenarios. (Leveson & Thomas, 2018)

4 GM System Safety Process with SEFA and STPA The SEFA and STPA are two analysis tasks within the Concept Phase of the GM System Safety Process, leveraging the output of the Preliminary Hazard Analysis (PHA) (e.g., list of system-level hazards), the HARA, and the physical or functional architecture of the system. There may be times where the system design is not fully mature or that allocation documents are not in their final form. Under this condition, the SEFA and STPA evaluations can still be started and then subsequently refined and updated as the system design matures. Once the system concept / architecture is determined, final versions of the SEFA and STPA analyses would be completed for the Safety Concept, shown at the end of Figure 6. Figure 6 - Location of SEFA and STPA in Concept Phase of GM System Safety Process SEFA and STPA evaluations are performed by one or more subject matter experts for the given system, function or component, with subsequent review by a cross-section of engineers with expertise pertinent to the scope of the system under study. The number of subject matter experts performing the SEFA or its subsequent review is dependent on the maturity and complexity of the system, e.g., high-risk designs or those involving significant invention will require additional participants. In addition, inclusion of a cross-section of experienced individuals aids in ensuring that any questions about the system can be resolved efficiently, thus reducing the tendency for making inaccurate assumptions, generating significant action items resulting from inadequate information, etc. Depending on the system content, the list of engineers participating in the analyses may include: System Engineer(s) (SE)** System Safety Engineer(s) (SSE)** Controls Architecture Engineer(s)** Control Algorithm Engineer(s)** Control Diagnostic Engineer(s)** Driver Performance Specialist(s)** Design Release Engineer(s) (DRE) Controls Product Design Team (PDT) Leader Component Supplier Engineer(s) ** These engineers are key participants for SEFA and STPA development.

5 System Element Fault Analysis (SEFA) The first method to discuss is the System Element Fault Analysis (SEFA) technique. It is system-level, top-down, exploratory analysis technique to evaluate the impact of system element faults upon the system as a whole and to determine if the system has sufficient content to detect and mitigate potential hazardous states created due to the fault. In the SEFA, a methodical review of the faults of system elements is conducted from which the consequences of each fault are identified. The analysis is performed based on a system s physical architecture design and assists in understanding flaws within the design or inadequacies in the design s ability to prevent, detect or respond appropriately to the impact of the faults of system elements. The SEFA uses a binary assessment approach where system elements are either <ON> or <OFF>; <WORKING> or <NOT WORKING>; < 0 POSITION> or < 1 POSITION>; etc. and takes into account the scenarios in which the system is expected to operate. The NORMAL state of all system elements is defined first for each scenario. The analysis proceeds to have each element (one by one) enter a state where that element experiences an abnormal behavior or attains a defective state versus its normal state. System elements may be items such as actuators, motors, sensors, etc. Controllers are included in a SEFA and typically are treated as one system element. SEFA Electric Vehicle Propulsion Example A System Block Diagram propulsion system for an electric vehicle is provided in Figure 7 below. This system contains two electric machines (EMs) that function either as a motor or a generator depending on driving conditions. These EMs are controlled by dedicated control processors (MCPA and MCPB) that use feedback from EM mounted resolvers. EM torque commands are determined by a hybrid control processor (HCP) that receives accelerator and brake pedal information from an engine control module (ECM) and an electric brake control module (EBCM) respectively. A transmission control module (TCM) selects different gear ratios based on ECM and transmission output speed sensor (TOSS) input. An internal mode switch (IMS) tells the system what range (Park, Reverse, Neutral, or Drive) the driver has selected. All of these entities constitute the system s elements.

6 Figure 7 - Hybrid Propulsion System Concept / Architecture System Block Diagram The SEFA utilizes a standard template within the GM Safety Process that contains cells for each system element s assigned or expected responsibilities. The template provides an area to fail each element, one at a time, and then record the resulting system behavior. These resulting system behaviors are then evaluated for potential safety hazards. If a hazard is possible, detection and mitigation strategies are recorded. The final system state after any mitigation action is evaluated to be sure new/different hazardous states are not created. At the end of the template is a column to record initial safety requirements to ensure the system is capable of performing the specified diagnostics and executing the defined mitigation strategies. Table 2 below shows the template. Table 2 - SEFA Template Table 3 shows the SEFA filled out for ECM and HCP element faults. Notice there is a way to record primary (yellow filled cell) and resulting (magenta filled cell) faults. One will see that when the HCP has failed (yellow cell with 0 ), Directional IMS information (magenta cell with 0 ) is not available any more. The Directional IMS itself has not failed, but the ability to

7 read its output is gone. Table 3 goes on to illustrate where potential safety hazards are present due to the resulting system state. Table 3 - SEFA Evaluating ECM and HCP Faults for Hazards Table 4 is an extension of the SEFA rows from Table 3 and shows information in columns Potential Safety Hazard(s), Diagnostic Method(s) and Mitigation Action(s) that is critical for downstream Safety Process documents and activities. The information in the Diagnostic Method(s) and Mitigation Action(s) columns will be the starting point for detection and mitigation strategy discussions and the resulting safety requirements. Table 4 - SEFA Template Extension with Safety Requirements The requirements are written at this high level with the expectation that they will be expanded upon and rolled-down to sub-system and component levels as part of the Requirements Phase and Design Phase safety process activities. Systems-Theoretic Process Analysis (STPA) The second method is the Systems-Theoretic Process Analysis (STPA) technique that represents the system content from a controls perspective, not a reliability point of view, and treats the system failures as control problems. It is used to evaluate failures associated with functions

8 assigned to system elements and the impact of these failures on system behaviors during the defined operating scenarios. STPA determines unsafe controls actions created when each system element s functions fail according to a list of misbehavior guidewords; the possible causes that could lead to these unsafe control actions; and, finally, the constraints and/or requirements necessary to prevent or manage these causes to an acceptable risk level. The STPA analysis is used to evaluate the impact when system element functions experience failures. This approach enables an evaluation to be done on either physical or functional architectures of a system and allows a system with complex and multiple interactions to be evaluated methodically in a clear and concise manner. STPA is useful when evaluating systems that contain expected driver and machine interactions. The evaluation would focus on accidental and inadvertent interactions between the driver and particular system elements that could lead to potential safety hazards, including hazards associated with purposeful activation. STPA is a vital addition to the GM Safety Process as ISO26262 does not address the evaluation of human behavior as part of its process to the desired level of detail GM desires. STPA should also be used to evaluate the safety impact of emergent behaviors not seen at the system s element level. Emergent behavior is behavior of a system that does not depend on its individual elements, but on their interactive relationships to one another. Thus, emergent behavior is unplanned or unexpected and cannot be predicted by examination of a system's individual elements. It can only be predicted, managed, or controlled by understanding the elements and their interactive relationships. The impact of emergent behavior may be positive or negative (leading to a potential hazard) in nature and it is the negative impacts that are of interest from a safety perspective. STPA Human Machine Interaction Example The control structure for an ETRS shift-by-wire driver interaction system is presented in this example. The control structure shows the control flow of information, commands, actions, and feedback for a system comprising the driver, shifter interface device and the vehicle. The arrows illustrate the main control activities for this system.

9 Figure 8 - Human Machine Interaction Control Structure Example The next step, once the control structure has been created, is to evaluate each system element s functions against a series of misbehavior guidewords. Doing this results in a listing of unsafe (undesired/unexpected) control actions (UCAs). Table 5 shows one of the functions of the Driver system element and the resulting UCAs. The guidewords are shown to the right of the Driver Control Functions. Table 5 - Functions and Unsafe Control Actions Driver Control Functions (Actions or Responsibilities) Decide when to shift "NOT Providing" Cause Hazard UCA0.5: Driver does not put car in Park prior to exiting vehicle UCA0.7: Driver does not put car in Park remaining in vehicle Identify Unsafe Control Actions (UCAs) "Providing" Cause Hazard UCA5: Driver puts car in a Non- Park range when intending to go to Park UCA6: Driver decides to select Drive when Reverse is needed Incorrect Timing Incorrect Order UCA9: Driver selects Reverse at speed UCA10: Driver selects Park at speed Stopped Too Soon Applied Too Long UCA11: Driver quickly taps desried range UCA12: Driver holds desired range I/F for prolonged time With the control actions identified (or once any of the unsafe control actions are identified, i.e., the process does not have to be completely serial), the STPA progresses to identify the potential causes of scenarios leading to unsafe control. In this step, information is generated to assist designers in eliminating or mitigating the potential causes of the hazard. This step involves examining the control loop and its parts, and identifying how they could lead to an undesired control action. Table 6 illustrates potential causal scenarios for this example.

10 Table 6 - Unsafe Control Actions and Potential Causal Scenarios Once the causal scenarios are identified, the process begins to develop requirements and constraints necessary to eliminate or manage potential hazards. These requirements and constraints may start out at a high level during the concept phase of the project and become more detailed as the STPA methodology continues to evaluate more detailed levels of the design. Both requirements and constraints need to be accommodated in Human-Machine Interaction (HMI) design. Requirements provide component design teams with specific parameters, such as depression forces, toggle angles, and button-to-bezel interface dimensions. Constraints inform design studio teams that they need to design buttons or toggle levers in a manner that accommodates certain types of activation sequences, but not specify the exact look or feel of the interaction. Where necessary, requirements parameter values should be obtained from user clinics employing both static (bench) and dynamic (in vehicle) testing conducted by both GM and independent test groups. Table 7 shows requirements conveyed to the design studio to manage the HMI risk. Table 7 - Requirements to Prevent or Manage Causal Scenarios

11 Understanding the generated requirements and constraints linkage to potential hazardous states allows Design Center teams to accommodate safety requirements (data driven) directly into the system design components. Figure 9 Logic Flow for STPA Generated Requirements Resulting requirements are transposed to a System Safety Concept document (used during the Concept review) and/or to production specific collateral documenting requirements and constraints. Figure 10 illustrates the overall STPA process from control structure to requirement and constraints incorporation into appropriate production specifications. Figure 10 STPA Requirements Allocated to Requirements Documents A successful example where STPA generated requirements were incorporated into a production design is shown in Figure 11 where these requirements were captured for, and implemented on, the 2018 GMC Terrain.

12 Figure GMS Terrain Shift by Wire Example Safety Concept Requirements The SEFA and STPA help to determine the faults, failures and user interface issues that could result in potential safety hazards. The Safety Concept document will use SEFA/STPA results (as well as PHA and HARA information) to assess the system s capability to satisfy the stated safety goals. The requirements defined in the SEFA and the STPA are transposed into the Safety Concept document and appropriate system requirements documents where they will represent the initial set of safety critical system-level requirements. Feedback from the SEFA/STPA evaluations may drive changes to the system design necessary to satisfy the safety metric requirements before the system design matures beyond the concept phase. The SEFA/STPA content provides the rationale for such design changes in a clear and understandable manner. In addition, diagnostic and algorithm development teams may use the SEFA/STPA results as a starting point for diagnostic and fault mitigation strategy development. These teams can consult the requirements section of the SEFA/STPA and/or the Safety Concept to begin the diagnostic architecture and the mitigation action implementations. Summary The SEFA is a system-level, top-down, exploratory analysis technique to evaluate the impact of system element faults upon the system as a whole and to determine if the system has sufficient content to detect and mitigate potential hazardous states created due to the failure. The result of this evaluation provides constraints and requirements necessary to achieve the stated safety goals of the system. Application of STPA analysis should be used on systems that have complex, or numerous system element, functional interactions as well as any system that includes driver interactions as part of the system where accidental and inadvertent interactions between driver and system could lead to potential safety hazards.

13 An example of when both a SEFA and STPA evaluation should be conducted would be a hybrid system that has been specified to use ETRS. The various controllers of a system (e.g., ECM, TCM, HCP, MCP, etc.), CAN and LIN communications, door switches, seat belt switches, display devices, and internal transmission parts like Park-inhibit solenoids, and Park attainment switches, etc., would be included in the SEFA working, not-working evaluation. However, driver interactions with shifter devices and the driver recognition and internalization of feedback messages or system status messages are not easily covered by a SEFA approach. This is where the STPA approach may be linked to the system s SEFA effort, as it would take the next step to look at causal scenarios where inadvertent or accidental activation of shift-by-wire devices may lead to undesired system behaviors. Appropriate message content and presentation criteria for driver action and intervention requests or system status feedback then could be developed. The STPA methodology is extremely effective in these types of evaluations. For systems like shift-by-wire, the STPA process could evaluate specific portions of this complex system, or the whole system as the STPA process is hierarchical in nature. Engineers could perform a detailed evaluation of the potential causes of unsafe control actions based on the functions of those elements being assessed by the STPA guideword interaction testing. Therefore, a detailed set of requirements based on the STPA effort could be provided without first doing a SEFA. GM is in the process of evaluating potential overlap between SEFA and STPA evaluations. Results from SEFA/STPA analyses are useful for identifying possible content revisions to the system architecture necessary to ensure adequate diagnostic capability and mitigation management. This enables safety to be built into the design right from initial engineering efforts prior to freeze of the concept/architecture content. These methodologies identify initial system requirements necessary to eliminate, and/or manage and mitigate resulting unintended or unwanted system behavior caused by system element faults eliminating cost and timing impacts later. References Leveson, N., & Thomas, J. (2018). STPA Handbook. Cambridge MA: MIT. Biography Mark A. Vernacchia, BSME, MSES, P.E. - GM Technical Fellow, Principal System Safety Engineer Propulsion Systems (Worldwide) Mark is a GM Technical Fellow and the Principal Systems Safety Engineer for all propulsion systems at General Motors. Mark has extensive experience in systems engineering and systems safety processes. He is a registered Professional Engineer in the State of Michigan Mark holds a Master s Degree in Engineering Sciences from Rensselaer Polytechnic Institute and a Bachelor s of Science in Mechanical Engineering from Purdue University.