Hazard Identification is defined in Def Stan 00-056 as:
“The process of identifying and listing the hazards and accidents associated with a system.”
Hazard Analysis is defined in Def Stan 00-056 as:
“The process of analysing in detail the hazards and accidents associated with a system.”
The objective of HIA is to identify in detail all credible hazards and accidents that may arise during the life of the system so that the associated risks can be managed. It provides input to:
- Refining the Safety requirements and criteria in the Systems Requirements Document (SRD);
- Identification of Regulatory requirements;
- Design decision making;
- Risk evaluation;
- Option selection;
- Hazard Log;
- Safety Case Reports for Full Buisness Case and subsequent System Acceptance and Introduction to Service;
- Identifying any critical areas of safety risk as input to Full Business Case.
HIA provides the basis for all other safety activities on the project. This information then provides the basis for assessing risks and ultimately the acceptability of the system.
The project shall carry out HIA to identify credible hazards and accidents associated with the system and to determine the related accident sequences. The HIA shall be reviewed and revised through the life of the project, as the design changes or as more information becomes available. The project shall demonstrate the adequacy of the HIA process and the suitability of the techniques employed.
Hazard Identification and Analysis (HIA) is the ongoing process of identifying credible Hazards, Accidents and Accident Sequences through the project lifecycle. It confirms and extends the Preliminary Hazard Identification and Analysis (PHIA(see Procedure SMP04 – Preliminary Hazard Identification and Analysis)) by including consideration of system design aspects and by developing more details of hazards as the design develops. Hazard Identification and Hazard Analysis are parts of the Risk Management process and they are often conducted together or in direct sequence.
At successive stages of the project and in progressively greater detail, HIA seeks to answer the question:
“What Hazards and Accidents might affect this system and how could they happen?”
The form, nature and depth of the HIA should be proportionate to the complexity and significance of the project, considering any safety-related functionality. There are a number of techniques that may be used to assist in the identification of hazards and accidents and in understanding accident sequences:
Different approaches and techniques are best suited to different systems or technologies 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 adequacy of the technique/s adopted will be justified in the Safety Case. The project should ensure that any HIA carried out by contractors uses appropriate techniques and is consistent across the project.
The project should ensure that the techniques selected are suitable for identifying hazards and accidents arising from:
- Systematic and random failures;
- Credible failures arising from normal and abnormal use in all operational scenarios;
- Predictable misuse and erroneous operation;
- Common cause and common mode failures;
- Interactions between systems, sub-systems or components;
- The defined operating environment;
- Procedural, managerial and cultural activities;
- Storage, transportation, disposal and other such activities.
The project will ensure that HIA is carried out in a planned and structured manner throughout the project. In a major project this will involve multiple Analyses for different sub-systems as well as the complete system, and at different stages of design or demonstration. The planning of this must ensure that:
- Hazards and Accidents are identified at times where action can be taken to mitigate or eliminate them most efficiently (i.e. at an appropriate point in the design cycle);
- Comprehensive, up to date Hazard Analysis is available to support development of the Safety Case Reports;
- Adequate operational experience (see below) and historical data is available to support HIA sessions.
HIA will be undertaken using a combination of techniques with the aim of providing confidence that the greatest number of credible hazards and accidents have been identified taking into account the nature and complexity of the system. This should include the anticipated use in wartime or other operational scenarios. However, an appropriate and proportionate approach should be adopted and the operational scenarios agreed with the Customer.
All available, relevant data should be considered, including accident and incident data from similar systems. Reasonable effort should be made to ensure that all possible Hazards are examined. It is essential that the appropriate team of experts is used in the HIA process, providing a sound understanding of:
- The system description;
- Operational profiles, maintenance, operator and maintainer competencies;
- The application and limitations of selected HIA techniques;
- The existing and/or commonly known Hazards of this or similar types of system;
- Validity of historical data adjusted to account for its context.
Justification that the selected techniques are sufficient to identify the full range of credible hazards and accidents should be provided in the Safety Case and summarised in the Safety Case Report. The project should ensure that there is sufficient communication of design, technical and operational information to allow HIA to be carried out effectively. In addition, the credibility of hazards identified should be discussed, together with the possibility of resultant accidents and the consequences of such accidents; it is important that realism is taken into account whilst still ensuring the widest coverage of potential accident sequences. This should include identifying and involving individuals with expertise in specialist areas, where necessary.
The identification of Hazards and their associated accident sequences should be a continual, iterative process. Inevitably, new safety requirements will be derived as the system evolves. This highlights the importance of the Hazard Log in tracking the management of hazard-related activities and why the Hazard Log should be created at project inception. (Based on Def Stan 00-056).
5.2.2. 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 Outline Business Case and Full Business Case submissions.
The Hazard Log is the primary mechanism for recording all Hazards, Accidents and Accident Sequences identified through HIA. It is a live document, updated with the results of each HIA as they become available. See Procedure SMP11 – Hazard Log, for more details.
The results of the HIA should be reported in a form which records the following:
- The input information used (e.g. User Requirements Document version, Concept of Use document, design standard);
- The approach adopted (e.g. tools and techniques used);
- The people consulted;
- The Hazards, Accidents and Accident Sequences identified.
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 Assessment Report or Safety Case Report).
The Safety Case Report (Procedure SMP12 – Safety Case and Safety Case Report) is where the project will demonstrate the adequacy of the HIA process and the suitability of the techniques employed.
5.2.3. Warnings and Potential Project Risks
If inadequate operational and domain knowledge is available for HIA, it is likely that important hazards will be missed or that unrealistic hazards will be included in the Hazard Log. It can be difficult to correct these errors later in the programme, when important Requirements and design decisions have been implemented.
If Delivery Teams do not ensure a controlled and effective exchange of information on hazards throughout the project, it is likely that there will be areas of design and implementation where lack of awareness will result in higher risk solutions.
A Hazard Checklist is useful for most HIA, but should not be the only method used (except for standard installations whose hazards have been studied in more detail elsewhere). In all other cases some form of structured brainstorming (e.g. Structured What if Technique or Hazard Operability Study) is highly desirable.
When identifying hazards, the scope should not be restricted to the steady-state operational scenario, but must consider all aspects of the system’s life cycle, from installation to final decommissioning and disposal, including maintenance and upgrades (i.e. the acquisition lifecycle). Emergency scenarios and associated Contingency modes of Operation should also be considered.
An absence of a systematic and comprehensive HIA activity could severely undermine the Risk Management process. In the worst case, this can create an illusion of safety and a false sense of confidence, and can miss opportunities to eliminate a hazard in the earliest stages of a project when the greatest range of options still exist.
5.3.1. Initial Production
HIA is an iterative process, commencing in Assessment and continuing through Demonstration and Manufacture as the design is refined. At each phase the HIA will be a major input to the Safety Case Report.
In addition, any significant changes in use or application identified during the In-Service phase will require HIA, and HIA for the Disposal phase should be updated with latest information in preparation and planning for disposal.
5.3.2. Review, Development and Acceptance
Each major update to the HIA should be endorsed by the Independent Safety Auditor (where the project appoints an Independent Safety Auditor) and the PSC, through endorsement of the Hazard Log and Safety Case Reports for Full Business Case, System Acceptance and Introduction to Service.
As HIA is updated, management measures will ensure that the Hazard Log, Safety Case and other dependent activities are also updated.
5.4. Required Inputs
This procedure for HIA requires inputs from:
- Outputs from Procedure SMP03 – Safety Planning;
- Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
- Outputs from Procedure SMP11 – Hazard Log;
- Outputs from Procedure SMP12 – Safety Case and Safety Case Report.
The HIA methods and timing will be defined in the Project Safety Management Plan (SMP), if appropriate by reference to the contractor’s SMP.
The HIA may use the following reference inputs, as available:
- Design Description;
- Preliminary HIA;
- User Requirements Document and Outline System Requirements Document;
- Hazard Checklists (e.g. appended to Procedure SMP04 – Preliminary Hazard Identification and Analysis or from individual Operating Centre Programme Management Offices);
- Relevant Previous Hazard Logs/Analysis;
- Accident and incident history from relevant existing systems in service.
5.5. Required Outputs
The primary outputs of the HIAs are the initial Hazards, Accidents and Accident Sequences recorded in the Hazard Log for the project.
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.
5.6. Version Control
5.6.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.
5.6.2. Version 3.0 to 3.1 uplift
Minor amendments to include removal of spelling mistakes, poor grammar and duplicated text.
5.6.3. Version 3.1 to 3.2 uplift
Reference to 'Safety Managers Toolkit' amended to 'ASEMS Toolkit' following the release of the SP Tool.
5.6.4. Version 3.2 to 4.0 uplift
The content of this SMP has been standardised and duplication of such items as Responsibilities has been removed.
5.6.5. Version 4.0 to 4.1 Uplift
Minor amendment to replace reference to Initial Gate and Main Gate and change these to Strategic Outline case, Outline Business Case and Full Business Case. This change brings terminology in line with JSP 655.