Alarm-limit change control

Measure the change before it ships.

AlarmOps checks every edit to a plant's alarm settings. It replays known faults against the new settings, shows what would be missed, and leaves the final yes to a person.

Try it yourself How it works

Everything here is simulated. No real plant is connected.

Change status panel / click a tile

Change A / loosen a limitBlockednotices 17 of 21 faults, was 21 Change B / password in codeBlockedthe secret scan stops it Change C / safe tighteningReadynotices 21 of 21; waits for a person

01 / The problem

A loosened limit fails silently

In a factory, an alarm limit is the number at which the control system warns an operator. Over the years people edit these numbers.

Loosen a limit by mistake and a real problem can happen with no warning at all. Tighten it too far and operators drown in false alarms and start ignoring them.

Today these edits are mostly checked by eye. Nobody measures what they really do, and nobody watches the alarm rate afterwards.

Words used on this page

Alarm limit: The number at which the control system warns an operator, such as a tank being 80% full.
Fault: Something going wrong in the process: a sudden spike, a slow drift, or a sensor stuck on one value.
Detection rate: Of the faults we hid in the data, how many the alarms noticed.
False alarm: An alarm that sounds when nothing is wrong. Too many and operators stop listening.
Deadband and delay: Two settings that stop alarms from flickering: how far the value must recover, and how many readings in a row must break the limit.
Gate: The pass or fail rule. A change that loses too much detection is blocked.

current high limita limit that was loosenedhidden fault, noticedhidden fault, missed

Showing change A: the loosened limit would leave 4 tank faults unnoticed (hatched red). Run the lab below to try your own.

What you are looking at: a simulated tank level over time. We hid 21 faults in the data (this chart shows the tank's). The grey trace is the level, the bands are the faults. A limit set too high lets some faults pass unnoticed.

02 / How it works

Nine automatic steps, one human

Every proposed change runs this line. It stops at the first step that fails. Only the approval is manual.

PlanCheck the change is well-formed.
ReviewReplay hidden faults on the old and new limits. Compare.
TestRun the automatic tests.
SecurityScan for passwords and keys saved in the code.
ComplianceWrite the change record and a parts list.
StagingRelease to a practice environment.
ValidateCheck the practice release works.
ApprovalThe one manual step. A named person says yes.
MonitorWatch alarm counts after release. Open an issue if they drift.

03 / Try it yourself

Break an alarm limit. Watch it get caught.

These buttons run the real AlarmOps code on the server, on the same simulated data. The black panel prints what the command line would print. The site runs only this fixed set of checks and stores nothing you type.

STEP 1Pick a ready-made change, or type your own limits for the tank.

STEP 2Press Run the checks. The server replays the hidden faults on your limits.

STEP 3Read the verdict and the pipeline lights. The chart above also updates.

Tank alarm limits

very lowlow highvery high deadbanddelay (readings)

Limits go in order: very low, then low, then high, then very high. Hover a box for what it means.

Scan text for passwords and keys

This is change B. Paste a config snippet, or use the fake example key.

What the command line would print

Pick something above. Results appear here.

Stages marked "GitLab only" are not run by this website; they run in the real pipeline.

04 / After release

The monitor screen

Releasing a change is not the end. The monitor counts alarms per hour after the release and compares the recent hours with the quiet period before. If the rate climbs past the drift limit, it raises an issue with a diagnosis.

Healthy logNOT CHECKED

Before release: -
Recent: -
Drift limit: -

Drifting logNOT CHECKED

Before release: -
Recent: -
Drift limit: -

Press a button on a log to run the monitor on it.

What you are looking at: alarms per hour over 72 simulated hours. The dashed line is the drift limit and the shaded strip is the recent window the monitor checks. A healthy line stays under the limit; a drifting one climbs through it.

05 / Results

Measured, not claimed

The figures come from replaying the simulated data on each version of the rules, every time this page is built. None are typed in by hand.

CHANGE A

Loosen a limit

The tank's "too full" alarm moves from 80% up to 88%.

17 of 21
faults noticed (before: 21 of 21)

Blocked

CHANGE B

A password in the code

Someone commits a key that unlocks a cloud account. The key in the demo is fake.

Not a limit change
so there is no detection figure

Blocked by the secret scan

CHANGE C

A safe tightening

The alarm moves from 80% down to 75%, so it speaks up earlier.

21 of 21
faults noticed, 0 false alarms

Ready for a person

Baseline by tag

Tag	Faults noticed	False alarms
tank_level	7 / 7	0
pump_pressure	7 / 7	0
flow_rate	7 / 7	0

Baseline overall: 21 of 21 noticed, 0 false alarms.

How the pass or fail is decided

A change passes if it keeps at least 90.0% detection, loses no more than 5.0% compared with the current rules, causes at most 3 false alarms, and adds at most 2. A fault counts as noticed when an alarm for its tag starts between the fault's start and 20 readings after its end. These thresholds are choices for this demo, not an industry standard. Raw numbers: /api/replay.

06 / What this is not

Honest limits

A simulationThe sensor data is made up and the deployment is simulated. It is not connected to any real plant or equipment.

Not a certificationThe mapping to ISA-18.2 and IEC 62443 in each change record is a reference mapping. It is not a certificate or a compliance claim.

Demo thresholdsThe pass and fail numbers are policy choices made for this demo, not an industry standard.