What a HAZOP is

A HAZOP is a structured examination of a process, carried out by a team, to find the ways it could depart from its design intent and what the consequences would be. It is one of several process hazard analysis methods, and the one usually chosen where a process is continuous, well defined by drawings, and complex enough that an unstructured review would miss things.

The method is codified in IEC 61882. What makes it a HAZOP rather than a general review is the discipline: the process is divided into sections, each section has a stated design intent, and a fixed vocabulary of guidewords is applied to each relevant parameter in turn. The team does not decide what to look at next. The structure decides, and the team argues about what it finds.

It is a team exercise by definition. A HAZOP is run by a facilitator who owns the method, with people who own the process: operations, engineering, maintenance, and whoever knows what the plant actually does rather than what the drawing says it does. One person working alone can produce a document that looks like a HAZOP. It will not have done the thing a HAZOP is for.

Nodes and design intent

The process is divided into nodes. A node is a section of the process with a single, stateable design intent: typically a line between two items of equipment, a vessel with its inlets and outlets, or a defined piece of a utility system.

The design intent is the premise every deviation is judged against: what this section is meant to achieve under normal operation, in what quantity, from where, to where. It is not written on the P&ID. It lives in the operating philosophy and in the knowledge of the people who run the plant, and getting the team to state it explicitly is often where the first findings come from, because two people in the room turn out to have assumed different things.

Node boundaries are a judgement. Too large and a deviation means different things at either end of the node; too small and the study takes longer than the plant can spare and the team stops thinking.

Guidewords and parameters

A deviation is a guideword applied to a parameter. The guidewords are deliberately few and deliberately abstract, so that the same seven words force a different question of every parameter in every node.

No / None: The design intent is not achieved at all: no flow, no reaction.
More: A quantitative increase: more flow, higher pressure, higher temperature.
Less: A quantitative decrease: less flow, lower level.
Reverse: The opposite of the intent, most often reverse flow.
As well as: The intent is achieved, and something else happens too: contamination, an extra phase.
Part of: Only some of the intent is achieved: one component of a stream missing.
Other than: Something entirely different happens: the wrong material, the wrong route.

The parameters are the properties of the stream or the equipment that the intent depends on. A typical set is Flow, Pressure, Temperature, Level, Composition, Reaction, Phase. Not every combination is meaningful, and a facilitator who insists on working through all of them produces a long worksheet and a tired team rather than a better study. More flow and reverse flow are credible almost everywhere; reverse temperature is not a thing.

Both lists are a starting point rather than a standard. Operators extend them: sequence guidewords such as early, late and before matter for batch processes, and parameters such as corrosion or static can earn a place in a particular plant.

What the team records

For each deviation the team judges credible, the worksheet records the chain of reasoning, not just the conclusion:

Causes. A specific initiating event or failure that could realistically produce this deviation in this node: a named valve failing in a stated position, a utility lost, an operator action. “Equipment failure” is not a cause, because nothing can be done with it.
Consequences. What happens if the deviation proceeds, assessed as though the safeguards are not effective. This is the step teams most often soften, and softening it is what makes a study agree with the answer somebody wanted.
Safeguards. What is already in place that prevents the cause or limits the consequence.
Risk. Severity and likelihood against the operator’s own matrix, usually recorded both unmitigated and with the safeguards credited, so the value of the safeguards is visible rather than assumed.
Recommendations. What should change, who owns it, and by when. A recommendation with no owner is a note.

Safeguards

A safeguard is something that exists, not something that ought to. The distinction matters: a protection that has been recommended but not installed belongs in the recommendations, and crediting it in the risk assessment understates the risk the plant is carrying today.

BPCS: The basic process control system: the loop that holds the parameter where it belongs in normal operation.
Alarm: Tells an operator something has moved, and depends on there being time and a procedure to act on it.
SIF: A safety instrumented function: sensor, logic solver and final element, acting without an operator.
Relief device: A relief valve or rupture disc, which limits the consequence rather than preventing the cause.
Procedural: A written procedure or a permit. Real, and weaker than the engineered layers above it.
Physical: Bunding, segregation, a flame arrester: protection that cannot fail to be in service.

Where the safeguards are not obviously sufficient, and the consequence is severe enough to justify the arithmetic, the scenario goes to a LOPA, which asks how much risk reduction the layers actually supply and how much is still missing.

When a HAZOP is done

Most operators run one on a new design once the P&IDs are firm enough to be worth examining but early enough that changes are still affordable, again before start-up, and then on a cycle, commonly every five years, as a revalidation. A management of change process will also trigger one on the part of the plant being modified.

A revalidation is not a fresh study. It asks what has changed: modifications made, incidents since, recommendations closed or still open, and whether the risk criteria the original study used are still the ones the company holds itself to.

Where software helps, and where it does not

The parts of a HAZOP that take the most time are not the parts that need the most judgement. Reading equipment and instrument tags off a drawing, laying out nodes, carrying the worksheet structure, cross-referencing safeguards to the deviations they answer, and producing the report are all mechanical. The judgement is in whether a cause is credible, whether a consequence has been stated honestly, and whether a safeguard is really independent.

TechPHA takes the mechanical half. It reads equipment, instruments, valves and lines from the P&ID, proposes nodes and deviations with a confidence score against each, and keeps the worksheet, the registers and the revision history. Every item it produces is a proposal that a named engineer accepts, edits or rejects, and the record of who decided what is part of the study.

What it does not do is run the workshop. The room full of engineers disagreeing with each other is the method; nothing here replaces it.

Start a study free

One complete study, no card. See also how a study runs in TechPHA and the full guide.