The Bypass Nobody Cleared: Making Maintenance Overrides Visible in SCADA

A gas detector in Area 2 got bypassed on a Tuesday afternoon so a technician could bump-test it without tripping the ventilation fans. Seven weeks later somebody pulling an alarm-frequency report noticed the suppression was still active.

Nobody had falsified paperwork. The bypass simply never appeared anywhere an operator actually looked. The detector's faceplate showed a process value in normal white text and nothing else. Two shift teams handed over twenty-one times in front of a screen that gave them no reason to ask.

That is the failure mode, and it is almost never carelessness. Bypasses get forgotten because they are invisible everywhere except the screen where they were set.

The standards already call this an operating state

You do not have to argue this one from first principles. IEC 61511-1 clause 11.8 requires the operator interface to indicate when a safety instrumented function is bypassed, and the operation and maintenance clauses expect compensating measures while the bypass is in force. A bypass that only exists as a bit in a PLC does not meet that in any meaningful sense.

ISA-18.2 gives you the vocabulary that most HMIs get wrong. Shelving is operator-initiated, self-service, and temporary — the operator silences a chattering nuisance alarm for an hour. Out of service is maintenance-initiated, needs higher authorization, and is expected to be tracked and reviewed. A maintenance bypass is out of service. If your HMI dumps it onto the shelved list, operators will unshelve it by accident, or worse, will learn to scroll past that list because it is full of nuisance entries.

At the device level, NAMUR NE 107 already has the concept: Function check means the reading is temporarily invalid because someone is working on the instrument. If your transmitters report NE 107 status over HART or PROFINET, use it instead of inventing a parallel flag that can disagree with the device.

Name the tag after the risk, not the sequence number

BYPASS_01, MAINT_MODE, TEMP_BYP. I have chased all three, and the tag name told me nothing while the plant was running. The name has to survive being read out of context, six weeks later, in a CSV export.

• P101_LOW_FLOW_TRIP_BYPASS — pump P101 low-flow trip
• TT204_BAD_QUALITY_ALARM_BYPASS — TT204 bad-quality alarm
• CONV3_GUARD_DOOR_PERMISSIVE_BYPASS — conveyor 3 guard-door permissive
• AREA2_GAS_DETECTOR_MAINT_BYPASS — Area 2 gas detector

This is not a case for long names on principle. It is that the same string ends up in the alarm summary, the event log, a trend annotation, and a handover sheet, and it has to mean the same thing in all four.

Put it where the decision gets made

One indication on one screen is the same as no indication. The operator deciding whether to start a pump is not looking at the bypass summary; they are looking at the pump.

At minimum the state belongs on the equipment faceplate, on the interlock or permissive detail page, on the alarm detail for anything it suppresses, on an area-level active-bypass list, and in whatever the startup permissive list is. Colour alone does not carry it — a red-ish tint reads as "alarm" to half the crew and "maintenance" to the other half. Use words: BYPASSED, TRIP BYPASSED, ALARM BYPASSED. If the design is icon-driven, the tooltip or detail popup has to name the bypassed function, not just say "maintenance".

Give it an expiry, and make the expiry mildly annoying

The single change that fixes more forgotten bypasses than every screen tweak combined: an expected end time.

I default it to one shift — eight hours, or twelve where the site runs twelve. If the job genuinely needs three days, someone should have to type that in and sign for it rather than getting it by default. Past the expiry, the bypass goes to an overdue state that raises an alarm at the same priority as whatever it suppressed. Not a low-priority housekeeping message; those are exactly what people filter out.

What I would not do is auto-clear on expiry. Restoring a trip path without warning while a technician has the instrument in pieces is a worse outcome than a stale bypass. Escalate, do not act.

Alongside the timer, record the bypassed function, requester, approver where site procedure needs one, reason text, start time, current status, and who cleared it and when. On a small system a structured comment gets you most of the way. On anything with more than a handful of bypasses, it wants to be a record per bypass, because the alternative shows up below.

Decide the alarm behaviour before commissioning, not after

Bypass and alarm interact in messy ways, and the messiness is where operators lose trust in the screen. Pick one of these deliberately:

• suppress the original alarm and raise a distinct BYPASS ACTIVE alarm in its place;
• keep the alarm visible and annotate it as bypassed, so it is clear it will not trip anything;
• disable only the trip action and leave the diagnostic alarm live — my usual preference for instrument work;
• require operator acknowledgement on both enable and clear.

The one to avoid is silent removal from the banner. If a transmitter is reading bad quality and its trip is bypassed, those are two separate facts and the operator needs both.

Audit it like a control write, because it is one

Enabling a bypass changes how the plant is protected. That is a control action, not a display preference, and IEC 62443-3-3 treats it accordingly: SR 2.1 for authorization enforcement, SR 2.8 for auditable events, SR 2.11 for timestamps on those events.

In practice that means a login for both enable and clear, roles that distinguish "can operate" from "can bypass a trip", failed attempts logged alongside successful ones, and the reason text stored with the event rather than in a live HMI tag that the next person overwrites.

If the PLC owns the bypass bit, check that the HMI audit event and the controller event can actually be correlated. That needs a common tag name and clocks that agree — NTP to the same source, and a look at the real offset rather than an assumption. A one-off I spent an afternoon on turned out to be a controller running 40 seconds ahead of the historian, which put every bypass event on the wrong side of the trip it was supposed to explain.

Four ways this goes wrong

The bit is still set after the work order closed. Almost always a visibility problem rather than a discipline problem. Area summary plus overdue indication, plus a handover step that reviews the active bypass list the same way it reviews standing alarms.

The HMI says BYPASSED and the logic trips anyway. The display bit and the logic bit are separate sources. Catch it at commissioning by forcing the bypass and driving the process variable past the trip point — watch the actual permissive, not the faceplate colour.

The alarm vanished and nobody knows why. Suppression wired straight to the bypass bit with no replacement indication. Add the bypass-active alarm and keep suppressed alarms queryable in history.

The reason text belongs to a different bypass. Classic symptom of one global string tag serving every bypass on the system. Write the reason into the audit event at the moment of the enable, where it is immutable.

Before you sign off the design

Enable and clear each bypass from both an authorized and an unauthorized account. Confirm the faceplate, area summary, and interlock detail all read from the same source rather than three copies that can drift. Verify the real PLC permissive, trip, or alarm behaviour. Check that the audit record carries user, station, time, old value, new value, and reason. Restart the HMI client and confirm active bypasses are still visible — a bypass list held in client-side session state is not a bypass list. Force an overdue condition and watch the escalation fire. Then export the active-bypass report a shift supervisor would actually use.

One question worth asking before any of that: can this site answer "how many bypasses are active right now, and on what" in under a minute? If not, the screen colours are beside the point.