Enhancing Process Safety Through a Holistic Approach to Safe Operating Limits

Overview

Limits that operators can actually use

A Safe Operating Limit (SOL) is the validated threshold where normal operation ends and predefined emergency action must begin — the “line in the sand” that tells an operator when to stop troubleshooting and start a shutdown. The problem most facilities run into is that limits set only at the design boundary (MAWP or MAWT), or pulled straight from a Process Hazard Analysis (PHA), don’t give operators a practical point to act before damage occurs.

Without robust limits, the response to an abnormal event comes down to individual judgment. Some operators shut down too early and force costly interruptions; others push too far and increase the risk of a serious incident. Effective SOLs remove that variability by giving everyone the same pre-approved, engineering-backed boundary.

Drawing on a real-world case study spanning three refineries, this white paper lays out a holistic approach to safe operating limit development that supplements the PHA with engineering validation and corporate guidance at the unit and equipment level. The result is a repeatable workflow that delivers consistent, actionable limits even where PHA quality varies from site to site — reducing risk while improving day-to-day decisions in the field.

What The Data Shows

Why PHA-only programs leave gaps

The figures in the paper come from three refineries across two years of SOL implementation. The pattern was consistent: building limits from the hazard study alone leaves two kinds of holes.

Missed limits. More than half of the SOLs that mattered — 140 of 270 — were identified outside the PHA, through equipment- and unit-level engineering guidance rather than the hazard study. A program that references only PHA results would have missed them.

Safeguards that are too slow. Many instruments credited as protection couldn’t actually respond in time. At one unit, none of the credited instruments passed process safety time (PST) analysis — the same failure mode we examine in our case study on instruments that can’t respond in time. Crediting a protection that can’t act fast enough creates a false sense of security.

You can’t protect against a scenario you never identified, and you can’t rely on a safeguard that can’t respond in time. A holistic approach closes both gaps.

The Core Problem

Why a PHA alone can’t define your operating limits

A PHA is a qualitative risk-assessment tool. It identifies hazards and screens risk — it was never designed to set enforceable operating boundaries. Relying on it as the sole input tends to produce limits that are misaligned with operating reality. This shows up three ways:

1. Overly conservative limits

PHA teams credit safeguards that maximize response time — an early low-reflux-flow alarm on a distillation column, for example. Converted directly into an SOL, that forces a shutdown during brief, recoverable upsets, causing nuisance trips, off-spec product, and downstream instability. The SOL belongs at the final not-to-exceed boundary (the rising pressure that signals imminent overpressure), not the first early warning.

2. Indirect indicators

A PHA might credit a high-level alarm for a blocked pump outlet. But the same alarm can mean a pump trip — where the correct operator response is the opposite. Tying the SOL to a more direct parameter (pump running and low flow) removes that ambiguity during an emergency, and can replace two level-based limits with a single hazard-focused one.

3. Incomplete coverage

Because a PHA judges risk acceptability, it can conclude “no instrumented protection required” and leave a parameter unmonitored — even when overpressure could still lead to a high-severity event. Critical equipment operating near MAWP warrants a high-pressure SOL even when the relief valve alone satisfies the risk ranking.

The Method

A holistic approach to SOL development

The core of the paper is a repeatable workflow that combines three inputs — PHA outputs, engineering validation, and corporate guidance — so accuracy and consistency reinforce each other. PHA-derived inputs drive accuracy; corporate guidance drives consistency across sites. The workflow runs in six steps:

1. Preparation — review the PHA for high-severity events, combine with equipment and unit guidance, and set the initial rigor for each candidate limit.
2. Calibration — meet to review candidate SOLs, resolve differences between the corporate list and the PHA-based list, and get site buy-in.
3. Development — run statistical analysis on operating data, complete process-safety-time and response-time calculations, and recommend instrument or configuration changes.
4. Validation — review completed SOLs for consequences, corrective actions, setpoints, and response times; confirm the package with the site.
5. PHA revision — update the PHA and LOPAs to reflect new limits, adding PST calculations wherever additional protection is required.
6. Documentation — complete the full operating-window documentation and operator-specific guidance, and issue the SOL report.

To stay practical, each limit should be “SUITable”: Severe (it protects against a high-severity scenario), Utility (it gives a clear corrective action), Independent (it isn’t defeated by the failure that caused the deviation), and Timely (the response happens fast enough to act before design limits are exceeded). This workflow is the backbone of our SOL development services, and it adds value whether a facility is starting from scratch or refining an established program.

What To Avoid

Common pitfalls in SOL development

• Overreliance on PHAs — treating PHA safeguards or LOPA independent protection layers as if they were enforceable operating limits, when they were built to assess risk, not define thresholds.
• PHA quality variability — weak or inconsistently facilitated studies miss high-severity scenarios or credit safeguards that can’t respond within the required process safety time, producing limits that are incomplete or technically weak.
• Excessive SOL identification — creating a limit for nearly every transmitter to appear compliant buries the handful that truly matter, drives frequent trips and alarm fatigue, and erodes operator trust in the whole program.

In Practice

Implementation challenges — and how to handle them

Cultural resistance to shutdowns

Operators hesitate to trip under production pressure or fear of blame. The fix is consistent messaging that an operator-initiated response and an automatic interlock serve the same safety function — an interlock isn’t reprimanded for acting at its setpoint, and neither should an operator be. A “Red Flag Review” that overlays proposed setpoints on historical data catches impractical limits before they go live.

Tight operating windows

When the margin between limits and design is narrow, interim measures — enhanced monitoring, increased inspection, targeted training — provide risk reduction while longer-term fixes are engineered: higher equipment design ratings, additional or larger relief devices, pilot-operated valves, or reduced throughput. See our work on pressure relief system design.

Imperfect monitoring

Where an instrument lacks the needed precision or span, time delays (to filter transient conditions) and state-based alarm settings (limits that adjust by operating mode — startup, shutdown, regeneration) preserve the safety function without triggering nuisance trips.

Reference

Key terms, defined

• SOL (Safe Operating Limit) — the validated boundary where normal operation ends and predefined emergency action begins.
• PHA (Process Hazard Analysis) — a qualitative study that identifies hazards and screens risk; a starting point for SOLs, not the endpoint.
• HAZOP — Hazard and Operability Study, a structured, qualitative form of PHA.
• LOPA (Layers of Protection Analysis) — a semi-quantitative method for judging whether enough independent safeguards exist for a scenario.
• IPL (Independent Protection Layer) — a safeguard credited in LOPA that is independent of the initiating event and other layers.
• C&E Matrix (Cause & Effect) — the document mapping process trips and interlocks to their triggering conditions.
• PST (Process Safety Time) — the time between a failure and the hazardous event; a protection is only valid if it can act within it.
• TOL / SDL — Target Operating Limit (the early-warning alarm) and Safe Design Limit (the equipment design envelope) that bracket the SOL.
• MAWP / MAWT — Maximum Allowable Working Pressure / Temperature; absolute design boundaries, not practical operating limits.
• IOW (Integrity Operating Window) — process limits protecting equipment integrity over time; see corrosion control documents and IOWs.

FAQ

Frequently asked questions

What is a safe operating limit (SOL)?

It is the validated threshold where normal operation ends and predefined emergency action must begin. Unlike a design boundary such as MAWP or MAWT, an SOL is contextual and actionable — it gives operators enough lead time to act before an excursion causes equipment damage.

Why isn’t a PHA enough to set safe operating limits?

A PHA is a qualitative risk-assessment tool designed to identify hazards, not to define enforceable operating boundaries. Relying on it alone tends to produce limits that are overly conservative, tied to indirect indicators, or incomplete. In the paper’s data set, 52% of the SOLs that mattered were found outside the PHA.

How do you develop SOLs across units with different PHA quality?

A holistic workflow combines PHA outputs with engineering validation and corporate guidance. Where PHAs are strong, they accelerate the work; where they’re weak, corporate guidance provides a consistent baseline — so the program produces comparable, actionable limits regardless of site-to-site variation.

What is process safety time (PST), and why does it matter?

PST is the time between a failure and the resulting hazardous event. A credited instrument or trip is only valid protection if it can complete its action within that window. In one unit studied, none of the credited instruments passed PST analysis — meaning the “protection” couldn’t have acted in time.

How many SOLs should a unit have?

Only as many as truly matter. Creating a limit for nearly every transmitter buries the critical few, drives nuisance trips and alarm fatigue, and erodes trust in the program. The goal is a focused set of high-severity, fast-developing scenarios — not maximum coverage.

The Authors

Meet the authors