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).
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?”
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:
- Identifying any critical areas of Safety Risk inherent in the User’s requirement, as input to Initial Gate submission.
- Providing the basis for the Safety Case Report for Initial Gate.
- 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.
- Selecting or eliminating options for subsequent Assessment
- Setting the initial Safety Requirements and criteria in the outline System Requirements Document (SRD),
- Provides the starting point for subsequent Hazard Analysis (see Procedure SMP05 – Hazard Identification and Analysis).
- Initiate Hazard Log (see Procedure SMP11-Hazard Log).
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.
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.
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.
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:
- Hazard Checklist;
- Accident and History Review;
- Functional Failure Mode and Effects Analysis (FMEA);
- Structured What If Technique (SWIFT);
- Hazard and Operability Study (HAZOP).
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.
The Team Leader is accountable for the completion of this procedure.
4.3.2. Procedure Management
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
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.1. Initial Production
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
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.
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
The PHIA method and timing will be defined in the Project SMP.
The PHIA may use the following reference inputs, as available:
- User Requirements Document;
- Hazard Checklists ;
- Relevant Previous Hazard Logs/Analysis;
- Accident and incident history from relevant existing systems in service.
4.6. Required Outputs
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).
Detailed information on tools and techniques is provided in the ASEMS Toolkit.
4.6.1. Records and Project Documentation
Where relevant, the outputs from this procedure should feed into the following:
- System Requirements Document – for any specific safety requirements;
- Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
- Through Life Management Plan;
- Safety elements of Initial Gate and Main Gate submissions.
The results of the PHIA should be reported in a form which records the following:
- The input information used (e.g. User Requirements Document version, design standard);
- The approach adopted (e.g. checklist used);
- The people consulted;
- The Hazards, Accidents and Accident Sequences identified.
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
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.
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.
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:
In either case Hazard Checklists and history of similar systems will be available as inputs.
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
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.
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
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.
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
It is essential the appropriate team of experts are used in the PHIA process, who together can provide a sound understanding of:
- The System description, its boundaries, together with its interactions with its Environment, including systems with which it interfaces and is dependent upon;
- Operational profiles, maintenance, operator competencies within a given Functional Environment;
- The application and limitations of the selected Hazard Identification (HAZID) techniques;
- The existing and/or commonly known hazards of this or similar systems;
- Validity of historical data adjusted to account for its context;
- If the team contributing to the PHIA do not contain this expertise, then it is likely that some significant hazards will be missed.
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.
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
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
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.
- Flammable substances; e.g. solid, liquid or gaseous;
- Asphyxiants, toxic or corrosive substances;
- High temperature or cryogenic fluids;
- Hazardous construction materials;
- Pressure systems;
- Electrical sources;
- Ionising and non-ionising radiation sources;
- Hydraulic arms or rotational machinery;
- Other energy sources including those due to motion;
- Exhaust gases;
- Passive obstacles;
- Hazardous surfaces;
- Cut and puncture projections.
Safety related interfaces between the various elements of the system, e.g.:
- Material compatibilities;
- Electromagnetic interference and compatibility;
- Inadvertent activation;
- Fire and explosion initiation and propagation;
- Hardware and software controls.
Factors due to the operating domain, or that the system may add to the operating domain, e.g.:
- Shock and vibration, including seismic;
- Extreme temperatures, pressures and climatic conditions;
- Exposure to toxic or corrosive substances;
- Fire or explosion;
- Insect, rodent or mould damage;
- Foreign bodies and dust;
- Electrostatic discharge including lightning;
- Electromagnetic interference;
- Ionising and non-ionising radiation, including laser radiation;
- Faults in supporting systems; e.g. power supplies, hydraulic systems;
- Exhaust gases.
Operating, test, maintenance and emergency procedures, e.g. :
- Operation under peace, exercise, war;
- Human factors considerations;
- Adequacy and effectiveness of instruction, training and rehearsal;
- Health hazards;
- User error, including failure to activate;
- Effect of factors such as equipment layout, ergonomics and lighting;
- Potential exposure to toxic materials, noise and radiation;
- Life support systems;
- Crash safety, egress, rescue and survival;
- Repair and salvage.
Enemy action, e.g. :
- Hostile acts;
- Inaction of active protective systems;
- Ineffectiveness of passive protective systems;
- Damage containment.
Damage control measures, e.g. :
- Damage containment;
- Damage repair;
- Hazard containment;
- Egress, rescue and survival.
Facilities, e.g. :
- Support equipment;
- Provisions for storage of hazardous materiel;
- Provisions for assembly of hazardous materiel;
- Provisions for proof testing of hazardous materiel.
The adequacy of safety related equipment, safeguards and failure containment measures, e.g. :
- Fire suppression systems;
- Relief valves;
- Energy containment vessels;
- Electrical protection;
- Toxic substance control;
- Electrical, air and hydraulic supplies;
- Personal protective equipment;
- Noise or radiation barriers;
- Alarms and warnings.
The defences against common mode failure, e.g. :
- Systems redundancy and diversity;
- Fail safe design.
Compliance with systems safety guidelines and standards, e.g. :
- Understanding of systems by personnel;
- Incident recording and monitoring, including near misses;
- Operator deviation;
- Design deviation;
- Deviation in supervision and checking;
- Component substitution.
Threats to programmable electronic systems, e.g. :
- Security breaches.
4.7.6. Land Systems Hazard Checklist
If there are no domain-specific hazard checklists, use generic checklists.
4.7.7. Sea Systems Hazard Checklist
Naval Authority Key Hazards:
- Surface Ship Stability;
- Surface Ship Structural Strength;
- Surface Ship Escape and Evacuation;
- Fire Safety (Ship and Submarine);
- Propulsion and Manoeuvring Systems (Ship and Submarine);
- Submarine Stability;
- Submarine Structural Strength;
- Submarine Manoeuvring and Control;
- Submarine Atmosphere Control;
- Submarine Watertight Integrity.
4.7.8. Aviation Hazard Categories
|Hazard category||Key hazards assigned to hazard category|
|4. Human performance||
|5. Operating hazard||
* 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
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
A minor uplift to correct spelling, grammar, and to remove some duplication of text
4.8.3. Version 3.1 to 3.2 uplift
Reference to 'Safety Manager's Toolkit' amended to 'ASEMS Toolkit' following the release of the Sustainable Procurement Tool.