ENGINEERING FOR HUMANS STPA ANALYSIS OF AN AUTOMATED PARKING SYSTEM

ENGINEERING FOR HUMANS STPA ANALYSIS OF AN AUTOMATED PARKING SYSTEM Massachusetts Institute of Technology John Thomas Megan France General Motors Charles A. Green Mark A. Vernacchia Padma Sundaram Joseph D Ambrosio

PROJECT GOALS To examine the role of humans in the safety of complex, automated human machine systems from a systems-theoretic perspective To develop a human engineering extension to STPA that assists us in understanding human process models and capturing additional causal scenarios To use automated parking as a test case for an STPA analysis to validate our human engineering extension ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 2

MOTIVATION Why use automated parking as a case study for interactions in complex human machine systems? Interactions between driver and automation Changes in driver role, increased complexity Importance of human process model Complexity of the parking task Rich environment Requires multiple driver control types ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 3

AUTOMATED PARKING ASSIST ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 4

CONTROL LOOP 5

CONTROL LOOP Existing systemstheoretic controller model Generic Not specific to humans 6

HUMAN CONTROL MODEL Human Controller Control Actions Inputs 7

HUMAN CONTROL MODEL Human Controller Process Model Control Actions Devise control actions Process states Process behaviors Environment PM Update Inputs 8

NEW HUMAN ENGINEERING APPROACH Identify UCAs Identify Process Model variables Identify Process Model Flaws Identify flaws in Process Model Updates Identify unsafe decisions (Control Action Selections) Human Controller Process Model Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 9

NEW HUMAN ENGINEERING PROCESS Identify UCAs Identify Process Model variables Identify Process Model Flaws Identify flaws in Process Model Updates Identify unsafe decisions (Control Action Selections) 10

UNSAFE CONTROL ACTIONS Brake Not Provided Provided Too early, too late, out of order UCA-1: Driver does not brake when auto-parking and computer doesn t react to an obstacle Stopped too soon, applied too long Driver APA Vehicle 11

NEW HUMAN ENGINEERING PROCESS Identify UCAs UCA-1: Driver does not brake when auto-parking and computer doesn t react to an obstacle Identify Process Model variables PM-1: APA is enabled/disabled PM-2: APA computer reacting appropriately/inappropriately PM-3: Obstacle on collision path Identify Process Model Flaws Identify flaws in Process Model Updates Identify unsafe Control Action Selections 13

NEW HUMAN ENGINEERING PROCESS Identify UCAs Identify Process Model variables PM-1: APA is enabled/disabled PM-2: APA computer reacting appropriately/inappropriately PM-3: Obstacle on collision path Identify Process Model Flaws Identify unsafe decisions (Control Action Selections) Identify inadequate Process Model Updates Process Model Process states Process behaviors Environment Type of PM flaw Incorrect beliefs about process state (including modes) Incorrect beliefs about process behaviors Incorrect beliefs about environment Examples Driver thinks APA is enabled when APA is really disabled Driver thinks APA is reacting properly and will brake automatically Driver thinks there is no obstacle when there is one Driver knows there is an obstacle but doesn t 16 know it s on a collision path

NEW HUMAN ENGINEERING PROCESS Identifying Process Model Flaws Incorrect beliefs about process state Consider modes, automatic mode changes, phases of operation Incorrect beliefs about Process behaviors Consider perceived effect of control actions, behavior in other modes, past experiences, etc. Incorrect beliefs about environment Consider changes to environment, similar past environments, etc. Known Unknown and Unknown Unknowns Believes there is a pedestrian in the way Believes there is no pedestrian Believes they don t know if there is a pedestrian (may trigger a check) Consider inadequate feedback, driver may know something changed but doesn t know the new state, etc. Providing guidance to ensure coverage Process Model Process states Process behaviors Environment 17

NEW HUMAN ENGINEERING PROCESS Driver does not brake when auto-parking and computer doesn t react to an obstacle (UCA-1) Driver thinks APA is enabled when APA is really disabled (PM-1) APA automatically disabled itself but driver didn t notice the change Human Controller Process Model Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 19

NEW HUMAN ENGINEERING PROCESS Driver does not brake when auto-parking and computer doesn t react to an obstacle (UCA-1) Driver thinks APA is enabled when APA is really disabled (PM-1) APA automatically disabled itself, driver noticed the change but didn t understand it Human Controller Process Model Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 20

NEW HUMAN ENGINEERING PROCESS Identify UCAs UCA-1: Driver does not brake for an obstacle when computer does not react appropriately to the obstacle Identify Process Model variables PM-1: APA reacting appropriately/inappropriately PM-2: Obstacle on collision path Identify Process Model Flaws Identify flaws in Process Model Updates Identify unsafe Control Action Selections Human Controller Process Model Control Actions Devise control actions Process states Process behaviors Environment PM Update 21 Inputs

NEW HUMAN ENGINEERING PROCESS Identify unsafe Control Action Selections Driver does not intervene to brake (UCA-1) Human Controller Process Model Driver knows APA is on Driver knows APA hasn t reacted yet Driver knows there is an obstacle in the way Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 22

NEW HUMAN ENGINEERING PROCESS Identify unsafe Control Action Selections Driver does not intervene to brake (UCA-1) Maybe driver does not know they can control brake with APA on Human Controller Process Model Driver knows APA is on Driver knows APA hasn t reacted yet Driver knows there is an obstacle in the way Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 23

NEW HUMAN ENGINEERING PROCESS Identify unsafe Control Action Selections Driver does not intervene to brake (UCA-1) Human Controller Maybe driver decides to disable APA instead Process Model Driver knows APA is on Driver knows APA hasn t reacted yet Driver knows there is an obstacle in the way Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 24

NEW HUMAN ENGINEERING PROCESS Identify unsafe Control Action Selections Driver does not intervene to brake (UCA-1) Human Controller Driver may still be waiting for APA to act Process Model Driver knows APA is on Driver knows APA hasn t reacted yet Driver knows there is an obstacle in the way Control Actions Devise control actions Process states Process behaviors PM Update Inputs Environment 25

NEW HUMAN ENGINEERING PROCESS Identify unsafe Control Action Selections Consider whether the driver is aware they can control X Consider alternative driver controls/actions Consider other driver goals Driver does not intervene to brake (UCA-1) Control Actions Human Controller Devise control actions Goals Process Model Driver knows APA is on Driver knows APA hasn t reacted yet Driver knows there is an obstacle in the way Process states Process behaviors Environment PM Update Inputs 26

STPA for Automated Parking Presented by Megan France ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 29

INITIAL CONTROL STRUCTURE Operator nable auto park mode isable auto park mode Steer Brake Park mode on or off Instructions Parking status APA computer Vehicle speed/position Steering angle Directional signal Range Proximity Brake Accelerate Steer Select range Turn signal Rear view came Path prediction Proximity Speed Vehicle ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 32

AUTOMATED PARKING TEST CASES Summary of features of each system considered for this analysis. Manual Operation Level 1 Driver Assistance Level 2a Partial Automation Level 2b Partial Automation Level 3 Conditional Automation Steering - Braking - - Shifting and Accelerati on Object/Eve nt Detection & Response - - - - - - - *System numbering is consistent with SAE definitions for levels of automation; a and b indicate different implementations which are classified within the same SAE level. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 33

UNSAFE CONTROL ACTIONS OVERVIEW Number of UCAs identified for the driver for steering, braking, shifting, and accelerating. Note: number of UCAs does not indicate how safe each system is! Level 1 Level 2a Level 2b Level 3 Driver Assistance Partial Automation Partial Automation Conditional Automation Driver UCAs 26 24 20 17 Computer UCAs 5 12 25 25 Total UCAs 31 36 45 42 ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 34

EXAMPLE SYSTEM OVERVIEW Automation is responsible for steering, braking, shifting & acceleration Does not actively monitor the environment Driver is responsible for monitoring the environment and responding to unexpected events Driver may override the actions of the automation by braking, steering, etc. Key assumption: while automation is on Driver can brake for <2 seconds in contributory mode Braking >2s will shut off the automation ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 35

DETAILED SAFETY CONTROL STRUCTURE Steering angle Throttle input Braking input Gear selection Brake Module Enable/Disable APA Directional Signal Controllers Driver Enabled/disabled status Parking maneuver status Rear camera / Path prediction Proximity alerts Instructions to take over Steering Parking Automation Steering angle Throttle input Braking input Gear selection EPS angle Brake status Throttle status Gear position Override(s) PCM Vehicle speedspeed Position Gear Proximity Environment & Other Drivers Environment al conditions and influences Steering angle Throttle input Braking input Gear selection Actuators Vehicle Steering angle Brake status Throttle status Gear position Override(s) Sensors 36

DRIVER UNSAFE CONTROL ACTIONS Control Action Not Providing Causes Hazard Providing Causes Hazard Incorrect Timing or Order Stopped Too Soon or Applied Too Long Braking Driver does not brake when the computer does not react appropriately to an obstacle [UCA-1]. Driver provides insufficient brake command when computer does not react appropriately to the obstacle. Driver provides too much brake when doing so puts other traffic on collision course or causes passenger injury. Driver brakes for long enough to disable automation when doing so puts the vehicle on a collision path. Driver waits too long to brake after the automation does not react appropriately to an obstacle. Driver continues override braking for too long and disables automation when doing so puts the vehicle on a collision path. Driver does not brake for long enough to avoid collision when automation is not reacting appropriately to an obstacle. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 37

DRIVER UNSAFE CONTROL ACTIONS Control Action Not Providing Causes Hazard Providing Causes Hazard Incorrect Timing or Order Stopped Too Soon or Applied Too Long Steering Driver does not steer when auto park is disabled. Driver does not steer when the vehicle is on a collision path. Driver attempts to steer when wheel is turning quickly. Driver provides steering override that puts vehicle on a collision path. Driver takes control of the wheel too late after disabling auto park. - Accelerati ng Driver does not provide accelerate command when necessary to override the automation and avoid an approaching vehicle. Driver does not resume accelerating after braking long enough to disable automation [UCA-2]. Driver provides accelerate command to override automation when doing so puts the vehicle on a collision path. Driver accelerates too quickly, subjecting driver to extreme forces. Driver accelerates before shifting into the proper gear, putting the vehicle on a collision path. Driver provides accelerate command to override automation too late to avoid obstacles. Driver continues accelerating too long, putting the vehicle is on a collision path. Driver does not accelerate long enough to clear an obstacle safely. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 38

CAUSAL SCENARIOS USING NEW EXTENSION UCA-1: Driver does not brake for an obstacle when the APA computer does not react appropriately to the obstacle. Scenario 1-1: The driver does not brake for the obstacle because the driver incorrectly believes that the computer detects and will brake for the obstacle ahead. This belief stems from past experience in which she has seen the computer apply the brakes to avoid hitting other parked vehicles. She does not receive any feedback that the computer is unaware of the obstacle. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 39

CAUSAL SCENARIOS USING NEW EXTENSION UCA-1: Driver does not brake for an obstacle when the APA computer does not react appropriately to the obstacle. When APA is on, I don t need to brake. Driver believes the computer detected the obstacle Driver believes the computer will brake In the past, driver has seen the computer detect obstacles and apply brakes ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 40

CAUSAL SCENARIOS USING NEW EXTENSION UCA-1: Driver does not brake for an obstacle when the APA computer does not react appropriately to the obstacle. Scenario 1-2: The driver does not brake for an obstacle because the driver incorrectly believes that the computer detects and will brake for the obstacle ahead. She is concerned that if she brakes unnecessarily, she will cancel the automation and need to restart the parking maneuver. She does not receive any feedback that the computer is unaware of the obstacle. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 41

CAUSAL SCENARIOS USING NEW EXTENSION UCA-1: Driver does not brake for an obstacle when the APA computer does not react appropriately to the obstacle. When APA is on, avoid unnecessary braking Driver knows that braking can disable APA, can t be resumed Driver believes the computer detected the obstacle Driver is not given feedback that the APA computer will not brake. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 42

Scenario details: STARTING POINTS FOR SOLUTIONS The driver is concerned that braking would cancel the automation and require her to restart the parking maneuver. The driver incorrectly believes that the computer detects and will brake for the obstacle ahead. She does not receive any feedback that the computer is unaware of the obstacle. Some possible solutions: Make it easy to resume auto parking with minimal steps for the driver. Provide feedback about automation s status (obstacles detected or not) and next actions in the form of a prominent display. Consider whether it is appropriate to require driver monitoring of the system or whether automation should be designed to handle such events. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 43

CAUSAL SCENARIOS USING NEW EXTENSION UCA-2: Driver does not resume accelerating after braking long enough to disable automation. Scenario 2-1: The driver does not resume accelerating after braking long enough to disable the automation because the driver incorrectly believes that APA is on. She incorrectly believes that braking will not disable the automation because in the past, she has not applied the brakes for long enough to trigger automation to shut off. The driver is not given feedback that automation is about to be disabled. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 44

CAUSAL SCENARIOS USING NEW EXTENSION UCA-2: Driver does not resume accelerating after braking long enough to disable automation. If APA is on, I do not need to accelerate Driver incorrectly believes that braking will only temporarily override the automation. Driver incorrectly believes APA is still on In the past driver has only braked for durations of less than two seconds while auto parking. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 45

STARTING POINTS FOR SOLUTIONS Scenario details: Driver expected to cause a temporary override. Driver incorrectly believes that braking will not disable the automation, since in the past she has only braked for durations of less than two seconds while auto parking. Some possible solutions: Provide explicit feedback when APA is disabled during a driver override warn the driver to monitor the environment and continue manual driving. Avoid situations where the same control is used for multiple control actions do not use brake pedal for both contributory braking and APA shutoffs. ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 46

SUMMARY OF NEW MODEL BENEFITS The new model scenarios incorporate additional context to explain why the driver may have certain beliefs and how those beliefs influence the driver s control actions. Captures goals and prioritization; how UCAs are selected based on PM Captures specific types of flaws which may call for different solutions Captures influence of past experience and expectations on processing of inputs ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 47

CONCLUSIONS New human engineering extension strengths: Provides additional guidance for human process model flaws Can help suggest engineering solutions, not just human problems Can be used earlier in design process than detailed simulations or prototypes ENGINEERING FOR HUMANS - MIT STAMP WORKSHOP 2016 48