Rate-of-Change Alarms: Catch a Runaway Before the High-High Ever Trips

A jacketed batch reactor was heating on schedule — 82°C, climbing about 1.5°C per minute, right on the recipe curve. Four minutes later it was at 148°C and the high-high tripped the batch. The operator's first question in the review: "Why didn't anything warn me?" The absolute alarms were set correctly. High was 130, high-high 150. The reactor just went from "normal" to "past High" to "trip" faster than a person parked on another screen could react. Nothing was wrong with the thresholds. The process was telling us something a level alarm can't see: not where the temperature was, but how fast it was moving.

That's what a rate-of-change alarm is for. Instead of comparing the PV to a limit, you compare its slope — dPV/dt — to a limit. A reactor that normally heats at 1.5°C/min and is suddenly climbing at 4°C/min is in an exotherm whether it's at 90°C or 140°C. Catch the slope and you get the warning minutes before the absolute limit, while there's still time to open cooling or kill the feed. ISA-18.2 (IEC 62682) lists rate-of-change alongside high/low and deviation as a legitimate alarm type — it's not exotic, it's just underused because people set it badly and then turn it off.

Where it earns its keep

Rate alarms are worth the trouble in a specific shape of problem: the absolute limit is real but slow, and the dangerous part is the transient.

• Exotherms and runaway reactions — temperature slope is the earliest honest signal.
• Tank leaks — a level dropping 2%/min with the outlet valve commanded shut is a leak or a passing valve, long before "Low" ever annunciates. This one has saved more spills than any level float.
• Loss of cooling / loss of flow — bearing temp rising 3°C/min, or a header pressure collapsing, tells you the pump or fan quit before the equipment reaches its damage limit.
• Pressure surge / water hammer on a fast valve stroke — but here you're usually past the point of human reaction, so the rate alarm is for the record and the interlock does the acting.

Where it does not earn its keep: anything that legitimately steps. A tank that gets a truck delivery, a heater that stages on, a flow that jumps when a downstream valve opens. On those, a rate alarm just chatters, and a chattering alarm gets ignored, and now you've trained the operator to ignore an alarm class. Don't put rate alarms on step processes to feel thorough.

The math is where people get burned

Differentiation amplifies noise. That's not a tuning inconvenience, it's the whole design constraint. If your temperature signal has ±0.3°C of measurement noise and you compute the slope scan-to-scan at a 500 ms scan, that noise alone looks like ±36°C/min. Your 4°C/min alarm will fire on nothing.

So you never compute rate per scan. You compute it over a window:

rate = (PV_now − PV_[n samples ago]) / (window_seconds)   [in EU per minute or per second]

Pick the window from two numbers. The floor is noise: the window has to be long enough that real movement clears the measurement noise band — a decent rule is window ≥ 10× the period of your sample jitter, or long enough that the smallest slope you care about produces a delta several times bigger than the noise. The ceiling is response time: the window can't be longer than the time you're willing to let the excursion run before someone acts. For that reactor, 30 seconds worked — long enough to bury the ±0.3°C noise, short enough that a 4°C/min climb was obvious within half a minute.

If a plain windowed delta is still ragged, take the slope of a least-squares line through the window instead of just endpoint-minus-endpoint. It rejects noise far better because every sample votes, and it costs a handful of PLC instructions. Endpoint difference throws away everything between the two ends and trusts two possibly-noisy samples to define the whole slope. Don't reach for a derivative-plus-lag-filter cascade first; the windowed least-squares slope solves the noise problem with less to tune and nothing to drift.

Do the arithmetic in engineering units, not raw counts, and state the alarm in units a person reads off a trend — °C/min, %/min, kPa/s. "Rate high at 320 counts/scan" is unmaintainable. "Reactor temp rising >3°C/min" is something an operator and a process engineer can argue about and agree on.

Compute it in the PLC, not the SCADA

The rate calculation divides by time, so it's only as good as the time you divide by. SCADA polling has jitter — a poll that's supposed to land every second actually arrives 0.9 to 1.4 seconds apart depending on network and load. Feed that wobbly dt into a divide and you manufacture rate spikes out of pure timing noise. The PLC has a deterministic scan and a real clock; do the delta and the divide there, publish the rate as its own analog tag, and alarm on that tag in SCADA like any other analog. You also get the rate on trends and in the historian for free, which is what you'll actually use to tune the threshold.

What makes rate alarms scream — and how to shut that up

The failure mode that gets rate alarms banned is the fake step. Any discontinuity in the signal looks like an infinite slope:

• Comms recovery. The link drops, the tag holds its last value, comms come back and the PV jumps to now-true. That jump is a giant fake rate. Gate the calculation on quality: if any sample in the window is bad, freeze the rate output and hold the alarm off. Then suppress the rate alarm for at least one full window length after quality goes good again, so the stale-to-fresh jump ages out of the window before you trust the slope.
• Range or scaling changes, sensor swaps, and manual value forces — same problem, same fix: suppress on the transition.
• Bad-quality freeze. If the PV is frozen at a constant, its rate is zero and the alarm sits quiet — which is fine, but don't let "rate normal" read as "process healthy." A frozen tag needs a stale/quality alarm of its own; the rate alarm is not a comms watchdog.

Add a short on-delay too — a few seconds of persistence so a single clean-but-brief spike doesn't annunciate. And run rate-of-rise and rate-of-fall as two separate alarms with their own thresholds. A reactor heating too fast and a reactor cooling too fast are different events with different responses, and they almost never share a limit.

Setting the threshold without a runaway to test on

You can't stage a real exotherm to tune the alarm, and you shouldn't want to. Pull the historian instead. Trend the last dozen normal batches, read the actual heat-up slope and its spread, and set the alarm a clear margin above the worst normal rate — not at the theoretical maximum from a P&ID nobody has trusted since commissioning. Then find one past upset in the archive, overlay it, and confirm your threshold would have caught it with enough lead time to matter. If the plant has never had the upset, be honest that the number is an estimate and leave the threshold where an operator can question it after the first real event — which is the only test that counts.