System Safety Program (SSP-Task 100)

1
System Safety Program(SSP-Task 100)

• Establishing the foundation of a systematic
  process

2
Managements Responsibility

• Plan, Organize, and Implement an effective System
  Safety Program
• Integrate System Safety into all phases of the
  life cycle
• Planned approach to task accomplishment
• Responsibilities and Functions clearly defined
• Establish a safety organization and provide
  qualified safety personnel
• Assurances (Accountability) that safety
  recommendations will be reconciled
• Compliance insured by a System Safety Program
  Plan (SSPP) A contractual requirement

3
System Safety Program Plan(SSPP Task 101)

• Fail to plan and you plan to fail

4
SSPP Objectives

• Brief description of the proposed system
• May be speculative during initial program plan
  preparation
• Defines systematic approach that will insure
• Safe design consistent with system requirements
• Timely delivery
• Cost-effective manner

5
SSPP Objective (cont)

• Hazards are identified, evaluated, eliminated or
  controlled to an acceptable level throughout LC
• Minimum risk is involved in design, testing,
  production
• Supporting safety data from other systems are
  considered
• Retrofit/Change to improve safety minimized
• Operational safety and maintainability
  demonstrated
• System termination established with clear methods
  and procedures

6
System Safety Working Group(SSWG Task 104)

• Multi-disciplinary team
• Normally comprised of
• Project Managers
• Design Engineers
• Safety Engineers
• End Users (customer)
• Project Management provides overall direction and
  decision-making authority
• Project Manager is chairman of the SSWG and
  provides liaison with higher levels of management

7
Excellent Example of SSPP

• MIL-STD 882D

8
Hazard Tracking and Risk Resolution (Task 105)

• Establish and maintain a single closed-loop
  tracking system
• Define methods to identify, document , and track
  hazards establish an audit trail
• Deliver a Hazard Log as part of engineering
  reports

9
Hazard Identification
10
Systematic Processes
11
What Constitutes a Hazard?

• A real or potential condition that, when
  activated, can transform into a series of
  interrelated events that result in damage to
  equipment or property and or injury to people.

12
Find the Hazards
13
Safety Managers View

• Hazard
• An implied threat or danger, a potential
  condition waiting to become a loss
• Stimulus
• Required to initiate action from potential to
  kinetic
• May be a
• Component out of tolerance
• Maintenance failure
• Operator failure
• Any combination of other events and conditions

14
When Do We Look for Hazards?

• The 5 Common Phases of a Systems Life Cycle
• Conceptual - Research
• Design (Validation Verification)
• Development (Full-scale engineering production)
• Operational Deployment
• Termination Disposal

15
Primary Objective

• The first major undertakings of a systematic
  safety effort must be to identify, analyze and
  control hazards
• Review operational goals, objectives
  constraints Before the fact process
• Resources (people, time money) must be
  considered
• Preliminary Hazard List (PHL) developed by
  experts from multiple areas of expertise

16
PHL Purpose

• The SSPP will seek this input
• List of hazards prepared and analyzed during the
  concept/definition phase (PHA)
• Handoff to System Safety Hazard Analysis (SSHA)
  effort
• Update list as the system matures and changes

17
PHA Purpose

• Identify and evaluate hazards
• Eliminate
• Mitigate
• Identify need to control those which cant be
  eliminated
• Determine Establish severity
• System Safety personnel should be prepared to
  compete with other priorities
• Cost, Performance, Schedule, etc.

18
Hazard Severity

• A key factor in establishing a common
  understanding of a safety programs goal
• MIL-STD 882 suggests four categories
• Cat 1 Catastrophic
• Cat 2 Critical
• Cat 3 Marginal
• Cat 4 Negligible

19
Category Definitions

• Catastrophic
• Death or total system loss
• Critical
• Severe injury, illness or major system damage
• Marginal
• Minor Injury or system damage
• Negligible
• Less than minor injury or system damage

20
Analysis of the System Tasking

• SSWG efforts would focus on the most critical
  components of the mission
• Expert review of
• Mission statement
• Previous accident/incident reports
• Operator reports
• All available historical data

21
3 Basic Sources of Historical Information

• Expert Opinion (published peer reviewed)
• Traditional Techniques (Inspections, Mishap
  Reports, Interviews, Audits)
• Previously developed Hazard Analysis Tools (PHLs
  and PHAs)

22
Other Available Sources

• Operational Front Line personnel
• An existing data base of lessons learned
• An accident/incident (mishap) report file
• An outside agency review
• A previous self critical safety review
• OSHA reports
• EPA (HAZMAT) reports

23
List the Hazards

• PHL reviewed developed
• Preliminary Hazard Analysis (PHA) is the initial
  look at the entire system
• PHA may be used in lieu of a PHL
• As systems and sub-systems are developed a more
  detailed Systems Hazard Analysis (SHA or SSHA)
  will provide more detailed risk assessment
  information

24
Hazard Analysis Methods

• Failure Modes Effects Analysis (FMEA)
• Systematic look at hardware piece by piece
• Review of how each component could fail
• Considers how a failure effects other components,
  sub-systems and systems as a whole
• Risk assessment accomplished (severity
  probability)
• Risk Assessment Code (RAC) assigned

25
Hazard Analysis Methods

• Fault Tree Analysis (FTA)
• Detailed review of a specific undesirable event
• Deductive in nature
• Top-down effort
• Normally reserved for critical failures or
  mishaps
• May be qualitative or quantitative

26
Risk Assessment Codes

• The effort in System Safety is to provide
  accurate, meaningful analysis of hazards
• Objective review of useful data should promote
  enlightened choices by decision makers
• Data Information Knowledge
• The RAC is used to prioritize hazards and
  determine acceptability
• The quality of the RAC determines the credibility
  of the system safety effort

27
MIL-STD 882 Risk Acceptance Criteria

• RAC 1 Unacceptable
• RAC - 2 Undesirable
• RAC 3 Acceptable with controls
• RAC 4 Acceptable

28
Hazard Analysis Methods

• Operating Hazard Analysis (OHA)
• Also known as Operating Support Hazard Analysis
  (OSHA)
• What if tool brings user into the loop
• Integrates people and procedures into the system
• Diagrams the flow or sequence of events
• Project Evaluation Tree (PET) may be used for OHA
  accomplishment
• Systematic evaluation of man, machine,
  procedures

29
Hazard Analysis Logic

• Inductive Reasoning
• Bottom Up Review --Asks What if?
• PHA, SSHA, FMEA
• Deductive Reasoning
• Top Down Review Asks How can?
• SHA, FTA
• Intuitive-Experiential
• Based on historical experience
• Lessons Learned and/or Change Analysis
• Composite
• Combination of all (systems approach)

30
The Tool Box

• Preliminary Hazard Analysis (PHA)
• Concept Phase
• Sub-System Hazard Analysis (SHA)
• Design and Development Phase
• System Hazard Analysis (SSHA)
• Design, Development and early Operations Phase
• Operating Support Hazard Analysis (OSHA)
• Operations and Disposal

31
More Hazard Identification Tools

• The 5 M model helps the SSWG to systematically
  review the interrelationships of the various
  composites in a system and their interacting
  mishap causal factors
• Brainstorming or what if session with
  operational personnel provides valuable insight
  and lessons learned that may or may not be part
  of the historical data

32
5 M model
33
Man
34
Man as a Root Cause

• Generally accepted to be causal in 70-80 of
  mishaps
• Incident review should question Is he involved
  or did he induce?
• Areas to consider
• Selection Is he capable?
• Training Does he understand?
• Motivation Does he care?

35
HFACs

• Efforts to integrate human factors into safety
  designs focus on 4 specific areas
• Behavioral Stereotypes
• Human Engineering
• Man-Machine Interface ( Tradeoffs)
• Misuse Analysis

36
Behavioral Stereotypes

• Habit patterns compel us to act in a predictable
  manner
• Learned behavior varies by groups
• Law of Primacy
• Designs that do not consider the users behavior
  patterns may be ERROR-INDUCING

37
Error-Inducing Exemplar(Have you driven a Ford
lately?)

• First vehicle you drove most likely had the horn
  activated by pushing in the middle of the
  steering wheel
• Ford Motor Company design co-located horn switch
  on the turn signal lever
• In a time compressed situation most operators
  push the center of the wheel looking for a horn
  if needed

38
QUESTION ???

• Would an accident that occurred as a result of a
  GM owner/driver failing to alert someone to an
  upcoming conflict because they fumbled
  unsuccessfully to activate a horn on a Ford they
  were using be an operator involved or induced
  error?

39
Human Engineering

• Ergonomics are the most developed human
  performance discipline
• Range and motion of equipment designed for
  average man
• A compromise for majority of operators
• MIL-STD-1472D
• Basic human design criteria standards

40
Man-Machine Interface

• Not to be confused with physical interface
• Functional control whose got it?
• Human (manual) control with automated response
  should certain conditions be present
• Automated controls with human monitors
• Optimizing the system to do what each does best
  is the challenge in design

41
Who Does What Best ???
42
Misuse AnalysisAKA Corollaries to Murphys Law

• What can be used will be misused
• Future Darwin Award winners epitaph
• New systems generate new problems
• SSWG should systematically review what-why
  relationships to ID potential hazards
• Proper analysis of information and implementation
  of controls demonstrate Due Diligence on behalf
  of management

43
Are Humans a Hazard?

• Human life support requirements are fairly
  intolerant of variation
• Environmental factors must be maintained within a
  fairly narrow set of parameters
• Lack of a temperate climate, light, soundproofing
  and other creature comfortscan induce
  psychological and physiological stress thus
  causing errors
• Human capabilities are relatively static compared
  to machines
• Machine capabilities continue to expand at high
  rates

44
Compensating for Human Error

• Error-Tolerant designs are necessary to mitigate
  known human deficiencies
• Frequency of errors generally known by situation
• Consider how your design compares
• Rates expressed in events per number of exposures
  or task accomplishments
• Upper limit of unaided human performance is one
  error for every 100,000 attempts

45
Machines
46
Machine as a Root Cause

• System safety process analyzes each component and
  operational procedure for its hazard
  contribution
• Poor design
• Inadequate operating procedures
• Ill defined limitations
• Improper Maintenance
• Known component hazards as well as Design-Induced
  maintenance and personnel errors are part of the
  hazard identification process

47
Hierarchy of Hardware Terms

• System
• Sub-System
• Assemblies
• Sub-assemblies
• Component
• Interconnected to perform a specific function
• Interaction creates a series of logical and
  sequential outputs

48
Medium
49
Medium as a Root cause

• System safety processes should analyze each
  component and their intended or potential
  interrelation with their operating environment
  for hazards
• Natural acts of God -- A phenomena?
• Temperature variations
• Earth Quake
• Volcano
• Hurricane
• Known environmental hazards as well as
  Design-Induced limitations should be part of the
  Hazard ID process

50
Even with properly identified hazards someone may
chose to operation outside design limitations
That is a gamble at best
51
Managing Threats
52
Management as a Root Cause

• Lack of genuine commitment to safety
• Example Failure to adequately resource a SSP
• Failure to act on safety recommendations
• Severity Probability quibbling or gambling
  Playing the Numbers game
• Inadequate SOPs
• Poorly developed PHA through OSHA
• Poor standards and controls
• Inadequate design wished into operation

53
Murphys Law for Management

• Technology is dominated by those who manage what
  they dont understand

54
The lowest temperature the system had previously
experienced was 53 degrees F and both the primary
and secondary component had failed to function as
designed. The predicted temperature for operation
was approximately 26 degrees F. data below 53
degrees F was not available and my department
could not prove it was unsafe to launch.

• Morton-Thiokol VP of Engineering, STS-51L
  Accident Investigation
• 1986

55
Mission
56
Mission as a Root Cause

• Some missions are higher in risk
• Combat Rescue
• Poorly developed or ill-conceived
• Operation Eagle Claw
• Incompatibilities
• Unfamiliar organizations combined to operate in
  new and complex role with erroneous assumptions
• Poorly defined
• Desert One (Now what?)

57
Predictable Preventable Mission Results
58
Senate Testimony

• The Commander of the operation blamed the
  helicopter pilots immediately after the mission.
  However, in his critique to the Senate Armed
  Services Committee, he later attributed the
  failure to Murphy's Law and the use of an ad hoc
  organization for such a difficult mission.
• We went out and found bits and pieces, people
  and equipment, brought them together
  occasionally, and then asked them to perform a
  highly complex mission," he said. "The parts all
  performed, but they didn't necessarily perform as
  a team."

59
Hazard ID -- First, Last and Always! (Because
what you dont know can hurt you)
60
Pitts Premise (PP) 1 No matter how good it
might look -- Sometimes it just doesnt pay to be
on the ground floor of a new design

• Murphys New Improved Two Story Outhouse