HAZOP – So what benefits does a HAZOP have and why have guidelines. HAZOP has been around from the 60s and for me personally I’ve been doing HAZOP for more than 20 years now. HAZOPs are a structured approach to identify the possible hazards in process system. HAZOP stands for Hazard and operability, it covers from design till operations. The concept of HAZOP is to break down a complex system into smaller and more manageable nodes, then the team will examine every variation and parameters using a structured brainstorm/ what-if method, applying it on each node. This article is intended to provide guidelines on how to conduct a HAZOP more effectively.
A HAZOP should consist of a chairperson/ facilitator, a scribe and the remaining team members from various disciplines . The team must be diverse with operations, engineering and exploration being a must. It is essential that the chairperson/ facilitator is an experienced HAZOP facilitator (at the least 10 years), while team members possess the necessary knowledge and skills coupled with decent amount of experience (> 10 years). HAZOP is inherently a brainstorming session that requires postulation of failure scenarios and the more experienced the team is the better the outcome of the HAZOP workshops are. Experience plays a pivotal role in describing some of the less obvious causes or failure events. Bear in mind for large HAZOP the workshops could go on for months and the team has to have the mental fortitude to be able to sit in workshops and get through their daily work. A backup team for each discipline should be on standby if the workshops extend anywhere more than 2 weeks.
Everybody needs to be on the same page prior to the HAZOP workshop. To ensure that that the HAZOP is effective, a Terms of Reference (TOR) is developed to set the ground rules for the workshop. The ToR should contain the following:
Preparation is the key for an effective HAZOP session. All correct documents, personnel, venue and refresher, presentation slides, etc. shall be prepared and printed out prior to the HAZOP. A checklist per the ToR is recommended.
Although it might seem self-explanatory , considerable thought needs to go into getting this section ready for the TOR. For scope, all systems that require HAZOP’ing need to be defined with their description. Boundaries need to be defined in the nodes later but this scope section shall encompass both the hydrocarbon systems and the utility systems that need to be HAZOPed . HAZOPs are done at various stages of a project and is primarily driven by the process ,process safety discipline. But as above your study team really needs to be diverse.
HAZOP workshops spans from early CONCEPT, FEED to Detailed Design. Some early HAZOPs during FEED will omit vendor packages , so scope as a rule of thumb needs to have an exclusion section . This way all team members are clear exactly what systems will be HAZOPed and what will be left for later . Vendor packages rightfully will need a separate focused HAZOP team that involves the vendors. Its imperative at these workshops for vendor packages to discuss interfaces between vendor packages and the overall systems.
Oddly IEC (International Electrotechnical Commission) has a standard out there for HAZOPs – IEC 61882. Organisation that does not have an internal standard should refer to the IEC standard. The methodology section shall detail out the template and, parameters and the guide words to be used. Each node defined shall have a design intent to start with, here pressures, temperatures are captured as well. Each node is normally defined from one shutdown valve (SDV) to the adjacent SDV.
There are some specific parameters used in the HAZOP: Flow, Pressure, Temperature, Level, Phase, Composition, and Operation, the first three of which are usually regarded as the main parameters.
The methodology shall require each node to be analysed against the predefined parameter using specific guide words . These guide words are process deviation guide words( No, More, Reverse etc). It helps get the thinking juices flowing , team members will brain storm on deviation and what if something went wrong (More Flow, Less Pressure, Reverse Flow etc), what the causes could be and potential consequences.
Systems are complex , the causes for the deviation are usually within a node. This is highly recommended otherwise it could be an infinite amount of causes as you traverse each system/node to find other causes far and wide. This way as you move from node to node all deviation causes are covered.
Consequences are worst cases postulated not accounting for existing safeguards . In an established organisation clients will require a final risk assessment based on their risk matrix. Well written consequences will require a narrative with events leading to a final plausible worst case scenario. Worst case scenarios must describe impact upon People, Environment , Asset or Reputation (PEAR). Some examples are as follows:
The methodology section really requires details also on rule sets surrounding safeguards and what would be acceptable. We have tabulated some of the challenges and recommendation that should be channeled to this methodology section as rule sets.
No | Challenges | Discussion | Recommendation |
1 | Human error as a cause | Many would have challenged that personnel (operators) are highly trained personnel, and they will not going to make a mistake. The comment is true that personnel are trained and not expected to make errors. However, in a panic, stressed or unfamiliar situation, e.g. when alarms goes off, when a non-routine operation e.g. switching over or start up scenario; it could still lead to a mistake. This is supported by many lessons learnt and investigation findings, human error is clearly one of the most common cause. | Generally, human error should be considered as a cause. |
2 | Taking credit of SOP as a safeguard | Many would have insisted to include SOP as a safeguard | Our suggestion is that SOPs can only be taken credit when the SOPs falls into one of the elements of DDA (Detect, Decide and Action) where there are clear instruction on the actions to be taken during the upset; and there are sufficient reaction time. Even when SOP fulfils the above requirement and taken credit, it should not be the first layer of protection. Considerations should be given to implementing engineered safeguards. |
3 | Double jeopardy | Double jeopardy is no doubt the most challenging scenario to be achieved in a HAZOP workshop. Double jeopardy is the situation where two independent events occurs at the same time. | It is commonly acceptable to ignore double jeopardy situation. However, before declaring a situation double jeopardy, perform analysis to confirm there are no common source of failure between the two cases. |
4 | Taking credit of Check Valve against reverse flow. | Many have insisted that check valve to be taken credit against reverse flow. | A check valve is know for failure and passing, it is not a tight shut off valve and certain leakage can always be expected. Overtime, the effectiveness of a check valve is also impacted. In certain system, two dissimilar check valves can be taken credit for reverse flow |
5 | Taking credit of alarm as safeguard | Many would have insisted to include alarm as a safeguard | Similar to SOP, recommendation is that alarm can only be taken credit when it fulfils the DDA elements and given sufficient reaction time. Alarm should never replace an automated engineered safeguards, e.g. automated trip. |
Risk assessments are critical to the success of the HAZOP workshops, once consequences are assessed the next step is the likelihood assessment. This is at best a semi-quantitative exercise and will really depend on the number of safeguards listed and the organisation risk matrix. The ‘tolerability’ of the risk may then be determined again using the risk matrix
Once completed a HAZOP report is issued, The HAZOP report focuses on the findings, recommendations that comes with it as well as the action plan. The recommendations should contain all the necessary information and completely standalone. Close out are tedious and requires a multi discipline & organisation approach as well. Some recommendation could potentially lead to millions being spent and really requires various levels of approvers to sign off on each action.
We have developed an workflow solution (part of ehs tools application suite) to help with exactly this. Your 100, or 1000s of actions from HAZOP or any other risk assessments can be loaded in minutes using our data science tools. Further details are at here.