16.2 Hazard and Risk Assessment

Specification 5.B opens with hazard and risk assessment, then moves to allocation of safety functions to protection layers. The first job is identification: name the hazardous events, their causes, their consequences, and the existing safeguards. The second job is evaluation: decide whether remaining risk is tolerable and, if not, how much additional reduction is required. Jumping to “we need SIL 2” before those two jobs are done is the same lifecycle failure as buying transmitters without an SRS—only now it happens one phase earlier.

ISA/IEC 61511-1:2018 expects this work to be systematic and recorded. The 2027 spec’s evaluation examples include safety layer matrix, risk graph, LOPA, and QRA. Identification is commonly performed with HAZOP, what-if, and FMEA. Use the identification tools to build the scenario list; use the evaluation tools to judge those scenarios. Do not treat an evaluation method as a substitute for listing the event.

Identification tools: HAZOP, what-if, and FMEA

A hazard and operability study (HAZOP) divides the process into nodes (a vessel, a line, a packed column) and applies guide words to parameters (MORE pressure, LESS flow, NO level). For each deviation the team records initiating causes, consequences, and existing safeguards. HAZOP is deviation-based. It is strong when the P&ID is mature enough that “MORE pressure on V-101” is a real, reviewable node.

A what-if review uses challenge questions (“What if cooling water stops?” “What if the operator bypasses the high-level switch?”). It is less structured than HAZOP and is often used earlier in design or on simpler units. The output is still a hazard list with causes and consequences, not a SIL number.

Failure modes and effects analysis (FMEA) starts from equipment failure modes rather than process deviations: a control valve fails open, a transmitter sticks, a solenoid does not vent. It complements HAZOP. HAZOP asks how the process can deviate; FMEA asks how a device can fail and what that failure does. FMEA does not, by itself, assign a SIL. It feeds the same hazardous-event list that evaluation methods later score.

Whatever tool you use, the identification target is the same four-part record:

• Hazardous event — what actually goes wrong in the plant (vessel rupture from overpressure, tank overflow to atmosphere, furnace tube rupture).
• Causes — initiating events specific enough to test independence (BPCS PIC-101 fails, blocked vapor outlet, external fire).
• Consequences — severity in people, environment, and asset terms the later evaluation method can classify.
• Existing safeguards — BPCS loops, alarms, relief devices, dikes, operating procedures—listed before anyone is allowed to credit them as independent layers.

Worked example: vessel overpressure before any SIL talk

Node: high-pressure separator V-101. Parameter: pressure. Guide word: MORE. Deviation: high pressure.

The node must capture at least:

• Causes: blocked vapor outlet; BPCS pressure controller PIC-101 fails and the fuel-gas valve travels open; external pool fire.
• Hazardous event / consequence: V-101 exceeds design pressure, shell rupture, large flammable release, possible fatalities in the unit area.
• Existing safeguards as found: PIC-101 itself; high-pressure alarm PAH-101; spring-loaded PSV-101; unit dike (useful for liquid spill, not for vapor rupture).

Independence has to be visible on this worksheet, not invented later in LOPA. If PAH-101 uses the same transmitter as PIC-101, then for the initiating event “PIC-101 / transmitter failure” the alarm is not a separate safeguard. If the “safety” shutdown valve is the same control valve PIC-101 strokes, there is no independent final element. The HAZOP’s job is to write those facts down. SIL is not yet on the table. You cannot allocate a SIF, pick a voting architecture, or shop for SIL-capable devices until the event, the cause, the consequence, and the real existing layers are named.

A common exam miss is to treat “we have a BPCS pressure loop, so we already have SIL.” A BPCS loop is a control function. It may later be evaluated as an independent protection layer if—and only if—it is independent of the initiator, effective for this consequence, and auditable. It is not automatically a SIL-rated SIS layer.

Evaluation tools named in spec 5.B

Once the scenario exists, evaluation methods estimate remaining risk and the additional reduction required.

A risk matrix places consequence category against likelihood (often after existing safeguards). The outcome is a risk rank compared with the organization’s criteria: accept, reduce, or reject. It is a screening picture, not a SIF design.

A safety layer matrix maps remaining risk onto protection-layer performance. Calibrated forms of this matrix are widely used to turn “how much more reduction do we need?” into a required SIF integrity band. The output is a required layer / SIL indication, still tied to one hazardous event.

A risk graph walks typical qualitative parameters—consequence severity, occupancy or exposure, probability of avoiding the hazard, and demand rate—to a SIL band. It is faster than QRA and coarser than a full LOPA with documented frequencies. The output is a SIL indication plus the parameter choices, which must be recorded so someone can audit why SIL 2 appeared rather than SIL 1.

Layer of protection analysis (LOPA) is the semi-quantitative workhorse for allocation and is covered in the next section. Quantitative risk assessment (QRA) uses event trees, fault trees, and consequence modeling when order-of-magnitude tools are too coarse or the decision is high-stakes. QRA’s outcome is a numerical risk estimate. It still requires the same identified hazardous event; it does not replace the HAZOP node.

Exam trap: treating BPCS control as an independent SIL-rated layer

The trap is to point at a DCS faceplate and call it a SIL-rated independent layer. Three separate errors are usually stacked:

1. Independence. If the BPCS loop is the initiating event, it cannot also be the protection layer for that event. Shared transmitters, shared I/O cards, shared final elements, or shared utilities that fail with the initiator all defeat independence.
2. SIL versus IPL. SIL is an integrity claim for a SIF implemented in an SIS. A BPCS loop, even when creditable as an IPL, is not automatically a SIL-rated safety function. Converting BPCS control into a SIF requires the SIS lifecycle: allocation, SRS, independent design, validation, and the operation regime that supports the claim.
3. Effectiveness and auditability. An untested, undocumented, routinely bypassed control loop is not an auditable protection layer, regardless of how often operators say “the DCS will catch it.”

On a 5.B item, credit BPCS only when the stem actually establishes independence from the initiator and from other credited layers. If the stem is silent, do not invent independence. Record the loop as an existing safeguard in the HAZOP, then decide in allocation whether it survives as an IPL.