SMP04. Preliminary Hazard Identification and Analysis

System Revision ID ASEMS Document Version Effective From State
3922 3.2 26/06/2017 - 00:15 Extant

4.1. Overview

4.1.0.1.

Hazard Identification is defined in Def Stan 00-056 as:

“The process of identifying and listing the hazards and accidents associated with a system.”

4.1.0.2.

Hazard Analysis is defined in Def Stan 00-056 as:

“The process of analysing in detail the hazards and accidents associated with a system.”

4.1.0.3.

Preliminary Hazard Identification and Analysis (PHIA) is intended to assist projects in determining the scope of the safety activities and requirements. It identifies the main Hazards likely to arise from the capability and functionality being provided. It is carried out as early as possible in the project life cycle, providing an important early input to setting Safety requirements and refining the Project Safety Management Plan (SMP).

4.1.0.4.

Preliminary Hazard Identification and Analysis seeks to answer, at an early stage of the project, the question:

“What Hazards and Accidents might affect this system and how could they happen?”

4.2. Procedure

4.2.1. Objectives

4.2.1.1.

The objective of the PHIA is to identify, as early as possible, the main hazards and
accidents that may arise during the life of the system. It provides input to:

  1. Identifying any critical areas of Safety Risk inherent in the User’s requirement, as input to Initial Gate submission.
  2. Providing the basis for the Safety Case Report for Initial Gate.
  3. Scoping the subsequent Safety activities required in the Safety Management Plan. A successful PHIA will help to gauge the effort that is likely to be required to produce an effective Safety Case, proportionate to risks.
  4. Selecting or eliminating options for subsequent Assessment
  5. Setting the initial Safety Requirements and criteria in the outline System Requirements Document (SRD),
  6. Provides the starting point for subsequent Hazard Analysis (see Procedure SMP05 – Hazard Identification and Analysis).
  7. Initiate Hazard Log (see Procedure SMP11-Hazard Log).

4.2.1.2.

PHIA is an important part of Risk Management, project planning and requirements definition as it helps to identify the main system hazards and helps target where more thorough analysis should be undertaken.

4.2.1.3.

Usually PHIA is based on a structured brainstorming exercise using Hazard Analysis techniques such as Structured What-If Technique (SWIFT), supported by Hazard Checklists. A structured approach is necessary to minimise the possibility of missing an important hazard, and to demonstrate that a thorough and comprehensive approach has been applied. More information can be found in the ASEMS Toolkit.

4.2.2. Method

4.2.2.1.

The Concept of Use (CONUSE) as set out in the User Requirements Document (URD) must be reviewed, and potential Hazards identified. This preliminary list of hazards should then be assessed for likely impact. From this, the regulatory requirements as well as any standards with which the capability will have to comply, can be determined. A level of tolerability against which risks identified in the subsequent phases might then be judged.

4.2.2.2.

The form, nature and depth of the PHIA should be proportionate to the complexity and significance of the project, considering any Safety-related functionality. There are a number of Hazard Analysis/Identification techniques that may be used:

  1. Hazard Checklist;
  2. Accident and History Review;
  3. Functional Failure Mode and Effects Analysis (FMEA);
  4. Structured What If Technique (SWIFT);
  5. Hazard and Operability Study (HAZOP).

4.2.2.3.

Different approaches and techniques are more suited to different systems and no single approach is likely to be sufficient on its own. Usually a combination of complementary techniques will be used in order to maximise the proportion of hazards identified.

4.3. Responsibilities

4.3.1. Accountability

4.3.1.1.

The Team Leader is accountable for the completion of this procedure. 

4.3.2. Procedure Management

4.3.2.1.

The Team Leader may delegate the management of this procedure to a SQEP member or members of the Delivery Team.

4.3.3. Procedure Completion

4.3.3.1.

The Project Safety Manager will be responsible for the completion of the procedure.  However, for complex projects the Delivery Team may choose to commission advisor's or contractors to complete the procedure.  In either case, Project Safety Committee (PSC) members and other stakeholders will be involved in providing input.  

4.4. When

4.4.1. Initial Production

4.4.1.1.

PHIA should be performed as early as in the project life cycle as possible in order to obtain maximum benefit by understanding what the hazards and accidents are, why and how they might be realised.  The PHIA should be conducted during the Concept stage as an input to Initial Gate and outline Statement of requirement Documentation Production, based on the CONUSE defined in the URD.

4.4.2. Review, Development and Acceptance

4.4.2.1.

In principle, PHIA is a one off analysis.  However, in a complex project with an extended Concept Phase, the PHIA will be reviewed if there are major changes to the requirements or options being identified.

4.4.2.2.

The PHIA and any updates shall be endorsed by the PSC, through endorsement of the Hazard Log and Safety Case Reports for Main Gate.  An endorsed PHIA shall be available as an input to outline the Statement of Requirement Document development, Safety Case generation and the subsequent Hazard Analysis (in later phases).  If the PHIA is updated, management measures will ensure that these dependent activities are also updated.

4.5. Required Inputs

4.5.0.1.

This procedure for PHIA requires inputs from:

  1. Outputs from Procedure SMP01 – Safety Initiation;
  2. Outputs from Procedure SMP02 – Safety Committee;
  3. Outputs from Procedure SMP03 – Safety Planning.

4.5.0.2.

The PHIA method and timing will be defined in the Project SMP.

4.5.0.3.

The PHIA may use the following reference inputs, as available:

  1. User Requirements Document;
  2. Hazard Checklists ;
  3. Relevant Previous Hazard Logs/Analysis;
  4. Accident and incident history from relevant existing systems in service.

4.6. Required Outputs

4.6.0.1.

The primary outputs of the PHIA are the initial Hazards, Accidents and Accident sequences recorded in the Hazard Log for the project.

4.6.0.2.

These results form part of the Safety Case body of evidence and may be recorded in a standalone report or as part of a wider report on safety (e.g. Safety Case Report).

4.6.0.3.

Detailed information on tools and techniques is provided in the ASEMS Toolkit.

4.6.1. Records and Project Documentation

4.6.1.1.

Where relevant, the outputs from this procedure should feed into the following:

  1. System Requirements Document – for any specific safety requirements;
  2. Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Initial Gate and Main Gate submissions.

4.6.1.2.

The Hazard Log is the primary mechanism for recording all hazards identified through PHIA. It is a live database or document, updated with the results of each Hazard Analysis as they become available. See Procedure SMP11 – Hazard Log, for more details.

4.6.1.3.

The results of the PHIA should be reported in a form which records the following:

  1. The input information used (e.g. User Requirements Document version, design standard);
  2. The approach adopted (e.g. checklist used);
  3. The people consulted;
  4. The Hazards, Accidents and Accident Sequences identified.

4.6.1.4.

The Safety Case Report (Procedure SMP12 – Safety Case and Safety Case Report) is where the project will demonstrate the adequacy of the Hazard Analysis process and the suitability of the techniques employed.

4.7. Further Guidance

4.7.0.1.

PHIA is fundamental to System Safety Management. If you do not identify a hazard, you can take no specific action to remove it, or reduce the risk of the accident(s) associated with it. Absence of a systematic and comprehensive PHIA activity can thus severely undermine the Risk Evaluation process.

4.7.0.2.

Hazards are diverse, and many different techniques are available for PHIA. While some techniques have become standard for particular applications, it is not be necessary or desirable to specify which approach can be adopted in particular cases. The mix of techniques should be chosen to meet the objectives as efficiently as possible given the available information and expertise.

4.7.0.3.

PHIA will usually be a qualitative exercise based primarily on expert judgement.  Most PHIA exercises involve a group of experts, since few individuals have expertise on all hazards, and group interactions are more likely to stimulate consideration of hazards that even well-informed individuals might overlook. The techniques most suitable for group PHIA are:

  1. SWIFT;
  2. HAZOP.

4.7.0.4.

In either case Hazard Checklists and history of similar systems will be available as inputs.

4.7.0.5.

Although both the SWIFT and HAZOP methods are systematic, creative examinations made by a multi-disciplinary team, they are dependent on different levels of system information. As such, the most appropriate technique will be selected for any particular system, in order that the PHIA activity is effective.

4.7.1. Alignment with Environment

4.7.1.1.

The opportunity to align safety and environmental analysis should be used to cross reference Environmental Features against Safety Hazards, so that common issues are identified and where possible assessed together. This should ensure that the potential environmental impact of a Safety Hazard or a safety impact of an environmental aspect are not overlooked.

4.7.1.2.

It is also important to plan and conduct assessment studies which can meet both safety and environmental evaluation requirements. Where this is not possible, alignment will help ensure that results of Safety Assessments are reviewed for environmental implications and vice versa.

4.7.2. Guidance for Different Acquisition Strategies

4.7.2.1.

The requirements for PHIA do not change for Acquisition conducted through intergovernmental agreements, Organisation Conjointe de Cooperation en matiere d'ARmement (OCCAR), multilateral or collaborative programmes. It is MOD policy that the same standards are met, and that assurance that these standards have been met can be demonstrated.

4.7.2.2.

Where the project involves a mid-life update, existing history will obviously provide a major input to the process. Similarly, where the project is likely to involve Commercial Off-The-Shelf or Military Off-The-Shelf solutions (including non-UK solutions) the existing history of these solutions provides a starting point. However, in all these cases there is still a need to carry out PHIA to determine if any new Hazards are introduced by the proposed use in a UK context, through particular safety-related functionality, new interfaces, different support and usage environments, different operational employments, etc.

4.7.3. Warnings and Potential Project Risks

4.7.3.1.

It is essential the appropriate team of experts are used in the PHIA process, who together can provide a sound understanding of:

  1. The System description, its boundaries, together with its interactions with its Environment, including systems with which it interfaces and is dependent upon;
  2. Operational profiles, maintenance, operator competencies within a given Functional Environment;
  3. The application and limitations of the selected Hazard Identification (HAZID) techniques;
  4. The existing and/or commonly known hazards of this or similar systems;
  5. Validity of historical data adjusted to account for its context;
  6. If the team contributing to the PHIA do not contain this expertise, then it is likely that some significant hazards will be missed.

4.7.3.2.

A Hazard Checklist is useful for most Risk Evaluations, but should not be the only PHIA method, except for standard installations whose hazards have been studied in more detail elsewhere.

4.7.3.3.

When identifying hazards, the scope should not be restricted to the steady-state operational scenario, but consider all aspects of the Systems Lifecycle, from installation to final decommissioning and disposal, including Maintenance and Upgrades (i.e. CADMID). Emergency scenarios and associated Contingency Modes of Operation will also be considered.

4.7.3.4.

If the PHIA is not carried out early enough, there is a risk that unrecognised hazards or requirements will be discovered later in the project, by which time it may be more difficult to eliminate or mitigate them.

4.7.4. Hazard Checklists

4.7.4.1.

This guidance contains information which should be used to generate Hazard Checklists for use in the conduct of PHIA to identify possible Hazards and Accidents which might be associated with a system. Any Hazard checklist should be used in a “brainstorming”, imaginative way to stimulate discussions between stakeholders who have a good understanding of the system, its context and usage/maintenance environment. Checklist application in a narrow way or by those with a vague appreciation of the system will be very much less effective.

4.7.5. General Hazard Checklist

4.7.5.1.

The following headings should be used as a basis for the compilation of checklists to assist Preliminary Hazard Listing and PHIA. The contents of the annex are not exhaustive. The objective is to identify hazards, their direct and indirect causes, and significant contributing factors.

4.7.5.2.

Hazardous components:

  1. Flammable substances; e.g. solid, liquid or gaseous;
  2. Lasers;
  3. Explosives;
  4. Asphyxiants, toxic or corrosive substances;
  5. High temperature or cryogenic fluids;
  6. Hazardous construction materials;
  7. Pressure systems;
  8. Electrical sources;
  9. Ionising and non-ionising radiation sources;
  10. Hydraulic arms or rotational machinery;
  11. Other energy sources including those due to motion;
  12. Exhaust gases;
  13. Passive obstacles;
  14. Hazardous surfaces;
  15. Cut and puncture projections.

4.7.5.3.

Safety related interfaces between the various elements of the system, e.g.:

  1. Material compatibilities;
  2. Electromagnetic interference and compatibility;
  3. Inadvertent activation;
  4. Fire and explosion initiation and propagation;
  5. Hardware and software controls.

4.7.5.4.

Factors due to the operating domain, or that the system may add to the operating domain, e.g.:

  1. Drop;
  2. Shock and vibration, including seismic;
  3. Extreme temperatures, pressures and climatic conditions;
  4. Noise;
  5. Exposure to toxic or corrosive substances;
  6. Fire or explosion;
  7. Insect, rodent or mould damage;
  8. Foreign bodies and dust;
  9. Electrostatic discharge including lightning;
  10. Electromagnetic interference;
  11. Ionising and non-ionising radiation, including laser radiation;
  12. Faults in supporting systems; e.g. power supplies, hydraulic systems;
  13. Exhaust gases.

4.7.5.5.

Operating, test, maintenance and emergency procedures, e.g. :

  1. Operation under peace, exercise, war;
  2. Human factors considerations;
  3. Adequacy and effectiveness of instruction, training and rehearsal;
  4. Health hazards;
  5. User error, including failure to activate;
  6. Effect of factors such as equipment layout, ergonomics and lighting;
  7. Potential exposure to toxic materials, noise and radiation;
  8. Life support systems;
  9. Crash safety, egress, rescue and survival;
  10. Repair and salvage.

4.7.5.6.

Enemy action, e.g. :

  1. Hostile acts;
  2. Inaction of active protective systems;
  3. Ineffectiveness of passive protective systems;
  4. Damage containment.

4.7.5.7.

Damage control measures, e.g. :

  1. Damage containment;
  2. Damage repair;
  3. Hazard containment;
  4. Egress, rescue and survival.

4.7.5.8.

Facilities, e.g. :

  1. Support equipment;
  2. Training;
  3. Provisions for storage of hazardous materiel;
  4. Provisions for assembly of hazardous materiel;
  5. Provisions for proof testing of hazardous materiel.

4.7.5.9.

The adequacy of safety related equipment, safeguards and failure containment measures, e.g. :

  1. Fire suppression systems;
  2. Relief valves;
  3. Energy containment vessels;
  4. Electrical protection;
  5. Toxic substance control;
  6. Electrical, air and hydraulic supplies;
  7. Personal protective equipment;
  8. Ventilation;
  9. Noise or radiation barriers;
  10. Alarms and warnings.

4.7.5.10.

The defences against common mode failure, e.g. :

  1. Systems redundancy and diversity;
  2. Interlocks;
  3. Fail safe design.

4.7.5.11.

Compliance with systems safety guidelines and standards, e.g. :

  1. Understanding of systems by personnel;
  2. Incident recording and monitoring, including near misses;
  3. Operator deviation;
  4. Design deviation;
  5. Deviation in supervision and checking;
  6. Component substitution.

4.7.5.12.

Threats to programmable electronic systems, e.g. :

  1. Viruses;
  2. Security breaches.
4.7.6. Land Systems Hazard Checklist

4.7.6.1.

If there are no domain-specific hazard checklists, use generic checklists.

4.7.7. Sea Systems Hazard Checklist

4.7.7.1.

Naval Authority Key Hazards:

  1. Surface Ship Stability;
  2. Surface Ship Structural Strength;
  3. Surface Ship Escape and Evacuation;
  4. Fire Safety (Ship and Submarine);
  5. Propulsion and Manoeuvring Systems (Ship and Submarine);
  6. Submarine Stability;
  7. Submarine Structural Strength;
  8. Submarine Manoeuvring and Control;
  9. Submarine Atmosphere Control;
  10. Submarine Watertight Integrity.
4.7.8. Aviation Hazard Categories

4.7.8.1.

Hazard category Key hazards assigned to hazard category
1. Fire
  • Fire
2. Explosion
  • Explosion
3. Disruption
  • Structural break up
  • EMC
  • Deliberate 3rd party
  • Incompatibilites (procedures/interoperability)
4. Human performance
  • Design performance and handling characteristics of aircraft and systems in the air or on the ground.
  • Crew incapacitation
  • Congestion
  • Inappropriate competence
  • Inexperience
  • Inappropriate/Inadequate communication
  • Inadequate procedure
  • Unfit for duty
  • Lack of currency
  • In-discipline
  • Inadequate supervision
  • Human capacity Workload
5. Operating hazard
  • Natural operating hazards
  • Man-made operating hazards
  • Inadvertent 3rd party
6. Survival
  • Post-accident survival
7. Environment*
  • Noise
  • Vibration
  • Hazardous materials
  • Pollution
  • Emissions

* Assessment of environmental impacts should take place through the application of POEMS.

4.7.9. Ordnance, Munitions & Explosives Hazard Checklist

4.8. Version Control

4.8.1. Version 2.3 to 3.0 uplift

4.8.1.1.

Major uplift from the Acquisition System Guidance (ASG) to online version. POEMS has undergone major revision. Refer to the POEMS Transition Document for details.

4.8.2. Version 3.0 to 3.1 uplift

4.8.2.1.

A minor uplift to correct spelling, grammar, and to remove some duplication of text

4.8.3. Version 3.1 to 3.2 uplift

4.8.3.1.

Reference to 'Safety Manager's Toolkit' amended to 'ASEMS Toolkit' following the release of the Sustainable Procurement Tool. 

Subject to Policy Clauses

1.7

Learning From Experience

Operating Centres, Project Teams or equivalents shall ensure accidents and incidents are investigated to identify opportunities to reduce the likelihood and impact of reccurrence. Lessons learned shall be shared amongst all relevant stakeholders to maximise benefit.

4.6

Safety Hazard Identification

Operating Centres, Project Teams or equivalent shall establish, implement and maintain a procedure for the on-going proactive identification of safety hazards.

5.1

Risk and Impact Assessment

All foreseeable Safety Risks and Environmental impacts shall be identified, assessed, prioritised and managed.

5.4

Consultation

Operating Centres, Project Teams or equivalent shall ensure that all stakeholders are identified and consulted so that their views and responsibilities are considered when managing safety and environmental risks.

Process Maps

SMP C1
Concept Phase Activities

Click here to view

Covered by Audit Question Sets

1.7

Audit Question Set Section 1.7 Learning From Experience

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 1.7.

4.6

Audit Question Set Section 4.6 Safety Hazard Identification

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.6.

5.1

Audit Question Set Section 5.1 Risk and Impact Assessment

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.1.

5.4

Audit Question Set Section 5.4 Consultation

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.4.