System Safety Program (SSP-Task 100) - PowerPoint PPT Presentation

1 / 60
About This Presentation
Title:

System Safety Program (SSP-Task 100)

Description:

Title: Hazard Identification Author: Unknown User Last modified by: Brenda Johnson Created Date: 1/24/2003 10:10:38 PM Document presentation format – PowerPoint PPT presentation

Number of Views:115
Avg rating:3.0/5.0
Slides: 61
Provided by: Unkn51
Category:
Tags: ssp | program | safety | seek | system | task

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com