Engineering a safer world
Download
1 / 82

Engineering a Safer World - PowerPoint PPT Presentation


  • 137 Views
  • Uploaded on

Engineering a Safer World. Traditional Approach to Safety. Traditionally view safety as a failure problem Chain of random, directly related failure events leads to loss Establish barriers between events or try to prevent individual component failures

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Engineering a Safer World' - caelan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Traditional approach to safety
Traditional Approach to Safety

  • Traditionally view safety as a failure problem

    • Chain of random, directly related failure events leads to loss

    • Establish barriers between events or try to prevent individual component failures

      e.g., redundancy, overdesign, safety margins, punishment and training for operators, defense in depth

  • Analysis techniques

    • Focus on probability of component failures and combinations of component failures

    • Where do they get the probabilities?

      • Historical failure rates

      • Make up numbers for human error and software error or ignore these in the analysis




It’s only a random

failure, sir! It will

never happen again.


Limitations of traditional approach
Limitations of Traditional Approach

  • Systems are becoming more complex

    • Accidents often result from interactions among components, not just component failures

    • Too complex to anticipate all potential interactions

      • By designers

      • By operators

    • Indirect and non-linear interactions

    • Can no longer exhaustively test and get out design errors

  • Omits or oversimplifies important factors

    • Human error

    • New technology, particularly software

    • Culture and management

    • Evolution and adaptation



Types of accidents
Types of Accidents

Component Failure Accidents

Single or multiple component failures

Usually assume random failure

Component Interaction Accidents

Arise in interactions among components

Complexity getting to point where cannot anticipate or guard against all potential interactions

Exacerbated by introduction of computers and software


Interactive complexity
Interactive Complexity

  • Arises in interactions among system components

    • Software allows us to build highly coupled and interactively complex systems

    • Coupling causes interdependence

    • Increases number of interfaces and potential interactions

  • Too complex to anticipate all potential interactions

    • By designers

    • By operators

  • May lead to accidents even when no individual component failures


Non linear complexity
Non-Linear Complexity

  • Cause and effect not related in an obvious way

  • Systemic factors in accidents, e.g., safety culture, work environment, production pressures, etc.

    • Our safety engineering techniques assume linearity

    • Systemic factors affect events in non-linear and indirect ways


Dynamic complexity
Dynamic Complexity

  • Related to changes over time

    • Systems are not static, but we often assume they are

    • Systems migrate toward states of high risk under competitive and financial pressures [Rasmussen]

    • Need to control and identify unsafe changes


Software related accidents
Software-Related Accidents

Are usually caused by flawed requirements

Incomplete or wrong assumptions about operation of controlled system or required operation of computer

Unhandled controlled-system states and environmental conditions

Merely trying to get the software “correct” or to make it reliable will not make it safer under these conditions.


Software related accidents 2
Software-Related Accidents (2)

Software may be highly reliable and “correct” and still be unsafe:

Correctly implements requirements but specified behavior unsafe from a system perspective.

Requirements do not specify some particular behavior required for system safety (incomplete)

Software has unintended (and unsafe) behavior beyond what is specified in requirements.


Event-based

Thinking

Systems Thinking


Stamp system theoretic accident model and processes
STAMP:System-Theoretic Accident Model and Processes

Based on Systems Theory

(vs. Reliability Theory)


Applying systems thinking to safety
Applying Systems Thinking to Safety

  • Accidents involve a complex, dynamic “process”

    • Not simply chains of failure events

    • Arise in interactions among humans, machines and the environment

  • Treat safety as a dynamic control problem

    • Safety requires enforcing a set of constraints on system behavior

    • Accidents occur when interactions among system components violate those constraints

    • Safety becomes a control problem rather than just a reliability problem


Safety as a dynamic control problem
Safety as a Dynamic Control Problem

  • Examples

    • O-ring did not control propellant gas release by sealing gap in field joint of Challenger Space Shuttle

    • Software did not adequately control descent speed of Mars Polar Lander

    • At Texas City, did not control the level of liquids in the ISOM tower;

    • In DWH, did not control the pressure in the well;

    • Financial system did not adequately control the use of financial instruments


Safety as a dynamic control problem 2
Safety as a Dynamic Control Problem (2)

  • Most major accidents arise from a slow migration of the entire system toward a state of high-risk

    • Need to control and detect this migration

  • A change in emphasis:

    “prevent failures”

    “enforce safety constraints on system behavior”


  • Example

    Safety

    Control

    Structure



    Safety as a control problem 3
    Safety as a Control Problem (3)

    • Goal: Design an effective control structure that eliminates or reduces adverse events.

      • Need clear definition of expectations, responsibilities, authority, and accountability at all levels of safety control structure

      • Entire control structure must together enforce the system safety property (constraints)

        • Physical design (inherent safety)

        • Operations

        • Management

        • Social interactions and culture


    Role of Process Models in Control

    • Controllers use a process model to determine control actions

    • Accidents often occur when the process model is incorrect

    • Four types of hazardous control actions:

      • Control commands required for safety are not given

      • Unsafe ones are given

      • Potentially safe commands given too early, too late

      • Control stops too soon or applied too long

    Controller

    Control

    Algorithm

    Process

    Model

    Control

    Actions

    Feedback

    Controlled Process

    22

    (Leveson, 2003); (Leveson, 2011)


    Processes

    System Engineering

    (e.g.,Specification, Safety-Guided Design, Design Principles)

    Risk Management

    Management Principles/

    Organizational Design

    Operations

    Regulation

    Tools

    Accident/Event Analysis

    CAST

    Hazard Analysis

    STPA

    Specification Tools

    SpecTRM

    Organizational/Cultural

    Risk Analysis

    Identifying Leading

    Indicators

    STAMP: Theoretical Causality Model


    Learning from events
    Learning from Events

    • CAST: Causal Analysis based on System Theory

    • Goal: more complete causal analysis of accidents, incidents, and adverse events


    Facts about accidents
    Facts about Accidents

    • Almost never have single causes

      • “Root cause seduction”

      • Accidents are complex processes

    • Usually involve flaws in

      • Engineered equipment

      • Operator behavior

      • Management decision making

      • Safety culture

      • Regulatory oversight


    Root cause seduction
    Root Cause Seduction

    • Assuming there is a root cause gives us an illusion of control.

      • Usually focus on operator error or technical failures

      • Ignore systemic and management factors

      • Leads to a sophisticated “whack a mole” game

        • Fix symptoms but not process that led to those symptoms

        • In continual fire-fighting mode

        • Having the same accident over and over


    Three levels of analysis
    Three Levels of Analysis

    • What (events)

      • e.g., explosion

    • Who and how (conditions)

      • e.g., bad valve design, operator did not notice something

    • Why (systemic factors)

      • e.g., production pressures, cost concerns, flaws in design process, flaws in reporting process, etc.

      • Why was safety control structure ineffective in preventing the loss?


    Goals for an accident analysis technique
    Goals for an Accident Analysis Technique

    Minimize hindsight bias

    Provide a framework or process to assist in understanding entire accident process and identifying systemic factors

    Get away from blame (“who”) and shift focus to “why” and how to prevent in the future

    Goal is to determine

    Why people behaved the way they did

    Weaknesses in the safety control structure that allowed the loss to occur


    Hazard analysis
    Hazard Analysis

    • “Investigating an accident before it occurs”

    • Identify potential causal scenarios and try to eliminate them

    • Must be based on some model of how and why accidents occur

    • STPA (System-Theoretic Process Analysis)

      • Based on STAMP

      • Assumes accidents are more complex processes than just chains of component failure events


    Stpa system theoretic process analysis
    STPA (System-Theoretic Process Analysis)

    • A top-down, system engineering technique

    • Identifies safety constraints (system and component safety requirements)

    • Identifies scenarios leading to violation of safety constraints; use results to design or redesign system to be safer

    • Can be used on technical design and organizational design

    • Supports a safety-driven design process where

      • Hazard analysis influences and shapes early design decisions

      • Hazard analysis iterated and refined as design evolves


    Steps in stpa
    Steps in STPA

    • Establish fundamentals

      • Define “accident” for your system

      • Define hazards

      • Rewrite hazards as constraints on system design

      • Draw preliminary (high-level) safety control structure

    • Identify potentially unsafe control actions (high-level safety requirements and constraints)

    • Determine how each potentially hazardous control action could occur


    Steps in stpa1
    Steps in STPA

    • Establish foundation for analysis

      • Define “accident” for your system

      • Define hazards

      • Rewrite hazards as constraints on system design

      • Draw preliminary (high-level) safety control structure

    • Step 1: Identify potentially unsafe control actions (high-level safety requirements and constraints) [Step 1 STPA]

    • Step 2: Determine how each potentially hazardous control action could occur [Step 2 STPA]

    x


    Identifying accidents and hazards
    Identifying Accidents and Hazards

    • Accident (Loss): An undesired or unplanned event that results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Hazard: A system state or set of conditions that together with a worst-case set of environmental conditions, will lead to an accident (loss)


    • Accident (Loss): An undesired or unplanned event that results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Hazard: A system state or set of conditions that together with a worst-case set of environmental conditions, will lead to an accident (loss)


    Identify high level safety constraints requirements
    Identify High-Level Safety Constraints results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc. (Requirements)


    Safety constraints vs safety requirements
    Safety Constraints vs. Safety Requirements results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Design constraints:

      • ACC must not violate separation requirements with object ahead

      • ACC must not brake too abruptly

    • Design requirements

      • ACC shall maintain a TBD amount of distance between the vehicle and the object in front when engaged

      • ACC shall limit vehicle deceleration to no more than TBC m/s2


    In class example
    In-Class Example results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    In-Trail Procedure (ITP)

    A new passing procedure for oceanic flights


    In trail procedure itp
    In-Trail Procedure (ITP) results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Enables aircraft to achieve FL changes on a more frequent basis.

    Designed for oceanic and remote airspaces not covered by radar.

    Permits climb and descent using new reduced longitudinal separation standards.

    Potential Benefits

    Reduced fuel burn and CO2 emissions via more opportunities to reach the optimum FL or FL with more favorable winds.

    Increased safety via more opportunities to leave turbulent FL.

    But standard separation requirements not met during maneuver


    Itp procedure step by step
    ITP Procedure – Step by Step results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Check that ITP criteria are met.

    If ITP is possible, request ATC clearance

    Check that there are no blocking aircraft other than Reference Aircraft in the ITP request.

    Check that ITP request is applicable (i.e. standard request not sufficient) and compliant with ITP phraseology.

    Check that ITP criteria are met.

    If all checks are positive, issue ITP clearance.

    Air Traffic Controller

    Flight Crew

    • When ITP clearance is received, check that ITP criteria are still met.

    • If ITP criteria are still met, accept ITP clearance via CPDLC.

    • Execute ITP clearance without delay.

    • Report when established at the cleared FL.

    Involves multiple aircraft, crew, communications (ADS-B, GPS) , ATC


    Accident and hazard definition for itp
    Accident and Hazard Definition for ITP results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Accident: Two aircraft collide

    Hazard?:


    Accident and hazard definition for itp1
    Accident and Hazard Definition for ITP results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Accident: Two aircraft collide

    Hazard:Two aircraft violate minimum separation requirement


    Accident with no component failures1
    Accident with No Component Failures results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.


    Batch reactor in class exercise
    Batch Reactor In-Class Exercise results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • What is the accident?

    • What is the system-level hazard (associated with that accident)?

    • What is the high-level system safety requirement (safety constraint)?


    Steps in stpa2
    Steps in STPA results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Establish foundation for analysis

      • Define “accident” for your system

      • Define hazards

      • Rewrite hazards as constraints on system design

      • Draw preliminary (high-level) functional control structure

    • Step 1: Identify potentially unsafe control actions (high-level safety requirements and constraints)

    • Step 2: Determine how each potentially hazardous control action could occur


    Draw the functional control structure
    Draw the Functional Control Structure results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Identify major components and controllers

      (HINT: Start at very high level)

    • Label control and feedback arrows

    • Create the preliminary process models


    Itp high level control structure
    ITP High-Level Control Structure results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • What are the major components and controllers of the system?


    Itp high level control structure1
    ITP High-Level Control Structure results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • What are the major components and controllers of the system?

      ATC, pilot, aircraft

    • Who controls who or what?


    Itp high level control structure2
    ITP High-Level Control Structure results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • What are the major components and controllers of the system?

      ATC, pilot, aircraft

    • Who controls who or what?

    ATC

    Pilot

    Aircraft


    Itp high level control structure 2
    ITP High-Level Control Structure (2) results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • What commands are sent and feedback provided?

    ATC

    Pilot

    Aircraft


    Itp high level control structure 21
    ITP High-Level Control Structure (2) results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • What commands are sent and feedback provided?

    ATC

    Clearance

    to pass

    (to execute ITP)

    Requests

    Acknowledgements

    Pilot

    Execute ITP

    maneuver

    A/C status, position, etc.

    Aircraft


    High-Level Control Structure for ITP results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.


    Pilot responsibilities and process model
    Pilot Responsibilities and Process Model results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Responsibilities:

      • Assess whether ITP appropriate

      • Check if ITP criteria are met

      • Request ITP

      • Receive ITP approval

      • Recheck criteria

      • Execute flight level change

      • Confirm new flight level to ATC

    • Process Model

      • Own ship climb/descend capability

      • ADS-B data for nearby aircraft (velocity, position, orientation)

      • ITP criteria (speed, distance, relative attitude, similar track, data quality)

      • State of ITP request/approval

      • etc.


    For the batch reactor
    For the Batch Reactor results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Draw the functional control structure


    OPERATOR results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    PROCESS MODEL

    Plant state: OK, Not OK, unknown

    Reactor state: Operating, not operating,

    unknown

    Start process

    Stop process

    Status information

    Plant state alarm

    COMPUTER

    Status

    info

    PROCESS MODEL:

    Water valve: Open, closed, unknown Catalyst valve: Open, closed, unknown Plant state: OK, not OK, unknown

    Plant

    Open water

    Open catalyst

    Close water

    Close catalyst

    ???

    VALVES


    What are the responsibilities of the software controller
    What are the Responsibilities of the Software Controller? results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Not the requirements, simply the basic functions to be implemented


    What are the responsibilities of the software controller1
    What are the Responsibilities of the Software Controller? results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Open water valve

    • Open catalyst valve

    • Tell operators when get message about problem in plant state


    Steps in stpa3
    Steps in STPA results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Establish foundation for analysis

      • Define “accident” for your system

      • Define hazards

      • Rewrite hazards as constraints on system design

      • Draw preliminary (high-level) safety control structure

    • Step 1: Identify potentially unsafe control actions (high-level safety requirements and constraints)

    • Step 2: Determine how each potentially hazardous control action could occur


    Four ways unsafe control can occur
    Four Ways Unsafe Control Can Occur results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • A control action required for safety is not provided or is not followed

    • An unsafe control action is provided that leads to a hazard

    • A potentially safe control action provided too late, too early, or out of sequence

    • A safe control action is stopped too soon or applied too long (for a continuous or non-discrete control action)


    Step 1 for pilot
    Step 1 for Pilot results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Pilot

    Execute ITP

    maneuver

    A/C status, position, etc.

    Aircraft


    Potentially Hazardous Control Actions results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    by the Flight Crew


    High level constraints on flight crew
    High Level Constraints on Flight Crew results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • The flight crew must not execute the ITP when it has not been approved by ATC.

    • The flight crew must not execute an ITP when the ITP criteria are not satisfied.

    • The flight crew must execute the ITP with correct climb rate, flight levels, Mach number, and other associated performance criteria.

    • The flight crew must not continue the ITP maneuver when it would be dangerous to do so.

    • The flight crew must not abort the ITP unnecessarily. (Rationale: An abort may violate separation minimums)

    • When performing an abort, the flight crew must follow regional contingency procedures.

    • The flight crew must not execute the ITP before approval by ATC.

    • The flight crew must execute the ITP immediately when approved unless it would be dangerous to do so.

    • The crew shall be given positive notification of arrival at the requested FL


    Potentially Hazardous Control results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Actions for ATC


    High level constraints on atc
    High-Level Constraints on ATC results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    • Approval of an ITP request must be given only when the ITP criteria are met.

    • Approval must be given to the requesting aircraft only.

    • Approval must not be given too early or too late [needs to be clarified as to the actual time limits]

    • An abnormal termination instruction must be given when continuing the ITP would be unsafe.

    • An abnormal termination instruction must not be given when it is not required to maintain safety and would result in a loss of separation.

    • An abnormal termination instruction must be given immediately if an abort is required.


    For the Batch Reactor: results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    Hazard: Catalyst in reactor without reflux condenser

    operating (water flowing through it)

    Create this table for the computer controlling the valves

    loop in your control diagram


    Hazard: Catalyst in reactor without reflux condenser results in a loss, including a loss of human life or human injury, property damage, environmental pollution, mission loss, financial loss, etc.

    operating (water flowing through it)


    What are the safety requirements (constraints) on the software controller given this table?


    What are the safety requirements (constraints) on the software controller given this table?

    • Water valve must always be fully open before catalyst valve is opened.

      • Water valve must never be opened (complete opening) more than X seconds after catalyst valve opens

    • Catalyst valve must always be fully closed before water valve is closed.

      • Catalyst valve must never be closed more than X seconds after water valve has fully closed.


    Steps in stpa4
    Steps in STPA software controller given this table?

    • Establish foundation for analysis

      • Define “accident” for your system

      • Define hazards

      • Rewrite hazards as constraints on system design

      • Draw preliminary (high-level) safety control structure

    • Step 1: Identify potentially unsafe control actions (high-level safety requirements and constraints)

    • Step 2: Determine how each potentially hazardous control action could occur


    Stpa step 2
    STPA Step 2 software controller given this table?

    Control input or external information wrong or missing

    Missing or wrong communication with another controller

    Controller

    Controller

    Inadequate Control Algorithm

    (Flaws in creation, process changes, incorrect modification or adaptation)

    Process Model

    (inconsistent, incomplete, or incorrect)

    Inappropriate, ineffective, or missing control action

    Inadequate or missing feedback

    Feedback Delays

    Actuator

    Sensor

    Inadequate operation

    Inadequate operation

    Incorrect or no information provided

    Measurement inaccuracies

    Feedback delays

    Delayed operation

    Controller

    Controlled Process

    Component failures

    Changes over time

    Conflicting control actions

    Process output contributes to system hazard

    Process input missing or wrong

    Unidentified or out-of-range disturbance

    69


    Example software controller given this table?

    STPA

    Results


    Example causal analysis
    Example Causal Analysis software controller given this table?

    • Unsafe control action: Pilot executes maneuver when criteria not met

    • Possible Causes?


    Four ways unsafe control can occur1
    Four Ways Unsafe Control Can Occur software controller given this table?

    • A control action required for safety is not provided or is not followed

    • An unsafe control action is provided that leads to a hazard

    • A potentially safe control action provided too late, too early, or out of sequence

    • A safe control action is stopped too soon or applied too long (for a continuous or non-discrete control action)


    Safe control software controller given this table?

    action provided

    but not followed

    Control input or external information wrong or missing

    Missing or wrong communication with another controller

    Controller

    Controller

    Inadequate Control Algorithm

    (Flaws in creation, process changes, incorrect modification or adaptation)

    Process Model

    (inconsistent, incomplete, or incorrect)

    Inadequate or missing feedback

    Feedback Delays

    Actuator

    Sensor

    Inadequate operation

    Inadequate operation

    Incorrect or no information provided

    Measurement inaccuracies

    Feedback delays

    Delayed operation

    Controller

    Controlled Process

    Component failures

    Changes over time

    Conflicting control actions

    Process output contributes to system hazard

    Process input missing or wrong

    Unidentified or out-of-range disturbance


    Exercise continued batch reactor
    Exercise Continued (Batch Reactor) software controller given this table?

    • STEP 2: Identify some causes of the hazardous control action: Open catalyst valve when water valve not open

      • HINT: Consider how controller’s process model could identify that water valve is open when it is not.

    • What are some causes for a required control action (e.g., open water valve) being given by the software but not executed.

    • What design features (controls) might you use to protect the system from the scenarios you found?


    Results
    Results software controller given this table?

    • What did you find?

    • What “controls” did you add?

    • What about the actual scenario that occurred in the accident?


    Next steps
    Next Steps software controller given this table?

    • Use causal analysis to identify detailed safety design requirements and design options

    • If desired, iterate top-down

      • Refine into more detailed control structures

      • Refine safety constraints (requirements) into more detailed requirements for each component

    • Use STPA results to assure safety when use in different environment(s) than assumed for original certification

    • Use STPA results to evaluate other types of changes to system and environment


    Example controls for causal scenarios
    Example Controls for Causal Scenarios software controller given this table?

    • Scenario 1 - Operator was expecting patient to have been positioned, but table positioning was delayed compared to plan (e.g. because of delays in patient preparation or patient transfer to treatment area; because of unexpected delays in beam availability or technical issues being processed by other personnel without proper communication with the operator).

    • Controls:

      • Provide operator with direct visual feedback to the gantry coupling point, and require check that patient has been positioned before starting treatment (M1).

      • Provide a physical interlock that prevents beam-on unless table positioned according to plan


    Example controls for causal scenarios 2
    Example Controls for Causal Scenarios (2) software controller given this table?

    • Scenario 2 - Operator is asked to turn the beam on outside of a treatment sequence (e.g. because the design team wants to troubleshoot a problem) but inadvertently starts treatment and does not realize that the facility proceeds with reading the treatment plan.

    • Controls:

      • Reduce the likelihood that non-treatment activities have access to treatment-related input by creating a non-treatment mode to be used for QA and experiments, during which facility does not read treatment plans that may have been previously been loaded (M2);

      • Make procedures (including button design if pushing a button is what starts treatment) to start treatment sufficiently different from non-treatment beam on procedures that the confusion is unlikely.


    Additional things not covered today
    Additional Things Not Covered Today software controller given this table?

    • Rigorous method for performing Step 1

      • Much of it can be automated or assistance provided

      • Generate executable and analyzable model-based safety requirements

    • Multiple controller analysis


    Organizational aspects of risk
    Organizational Aspects of Risk software controller given this table?

    • Examples so far focus on physical level

    • Also requirements and control responsibilities at management level to satisfy system safety requirements

    • Can identify unsafe control actions and causal scenarios at higher levels of the control structure (perform a risk analysis) and build in controls to prevent them

    • Behavior and control structures change over time

      • Prevent migration to higher levels of risk

      • Detect when occurs


    Organizational aspects of risk 2
    Organizational Aspects of Risk (2) software controller given this table?

    • Can look at non-safety risks, including project risks, budget risks, schedule risks and tradeoffs

    • Goal may be to evaluate an existing control structure or to create a new one

    • Creating leading indicators

    • Current or past examples:

      • NASA safety management after Columbia

      • Radiation therapy at UCSD and UCLA hospitals (and maybe Boston Mass General)

      • CO2 capture, transport, and storage (Samadi, Ecole des Mines)

      • Product Development Process (Goerges, Cummins Engine)


    Current research projects
    Current Research Projects software controller given this table?

    • Human factors engineering

      • Design to reduce human error

      • Integrating sophisticated human factors into hazard analysis

    • Leading Indicators

    • Cyber Warfare and Nuclear Security

    • Organizational, Managerial, and Project Risk Analysis

    • More applications: high-speed rail, autos, medicine, aircraft, NextGen (TBO)

    • Application to Financial Systems

    • Other Emergent System Properties

    • Tools and formal assistance with analysis


    ad