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 can’t 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 (PHL’s and PHA’s)

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 Code’s • 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 (O&SHA) • “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 (O&SHA) • 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. Management Man Mission Machine Medium 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. HFAC’s • 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 Analysis:AKA Corollaries to Murphy’s 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 Diligenceon 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 comforts”can 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 it’s 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