How to Verify a High Wet-Well Overflow Alarm
A high wet-well alarm is only worth anything if it actually trips at the right level and the notification actually reaches someone who can act. Plenty of stations carry an alarm that was configured once and never tested, so nobody knows it was silently broken until an overflow happens. This procedure is for the technician verifying, end to end, that a high wet-well overflow alarm fires at its setpoint and that the alert gets through to a responder in time to prevent a spill.
Verify Wet-Well Overflow Alarm in one line: To verify a high wet-well overflow alarm, confirm the setpoint matches the drawing and is referenced to the same datum as the level sensor, inject a rising level in the controller until the alarm annunciates and confirm it fires at the configured elevation, then trigger the full notification path and confirm a responder actually receives the alert. Test the whole chain, not just the setpoint on the screen.
Confirm the Setpoint, Datum, and Placement
Start by confirming the alarm setpoint against the approved drawing and the same datum the level sensor uses, because an alarm number that is correct on paper but shifted by a datum mismatch or a scaling error fires at the wrong physical level. Confirm the alarm sits below the lowest incoming invert so it warns before sewage backs up the collection system, and above the normal working band so ordinary pump cycling never trips it. This placement is the same reasoning applied when you set SCADA alarms to prevent a sewer overflow.
Confirm the volume remaining above the alarm gives a real response window. The gap between the alarm level and the overflow point, divided by the worst-case net inflow, is the lead time the alarm buys, and if that window is shorter than the time to get a responder to the station, the alarm is technically correct but operationally useless. Verifying the number on the screen is not enough; the level it represents has to leave time to act.
Inject a Level and Confirm the Trip
With the pumps in a safe state, use the controller's simulation or force function to drive the level input upward and confirm the alarm annunciates at exactly the configured elevation, not above or below it. An alarm that trips at a different level than its setpoint points to an engineering-units scaling error or a setpoint entered in raw counts, the same faults a level-band sweep exposes. Then lower the level and confirm the alarm clears at the expected point, checking it has a sensible deadband so it does not chatter right at the setpoint.
Where the station has both an analog high-level alarm and an independent high-high on a backup float or second sensor, test them separately. Blind the analog path and confirm the independent high-high still trips on rising level, because the whole value of that layer is that it works when the primary sensor has failed. That independence check mirrors the one in the guide on how to verify wet-well float backup switches, and skipping it leaves a backup that has never been proven to be a backup.
Prove the Notification Reaches a Responder
An alarm that annunciates on a screen nobody is watching has not done its job, so the most important part of this verification is proving the notification path end to end. Trigger the alarm and confirm the alert actually travels all the way to a responder through whatever path the station uses, whether that is an autodialer, an SMS, an email, or a central operations desk. Confirm the message identifies the station and the condition clearly, because a cryptic alert wastes the lead time the level setpoint bought.
Test the path at the time of day it will really be needed, because a scheme that alerts the daytime control room but has no after-hours path leaves the station unprotected overnight when a responder is hardest to reach. Confirm the escalation works if the first contact does not acknowledge, so a missed page rolls to the next person rather than dead-ending. This notification chain is exactly what the guide on how to configure an email alarm notification in SCADA and the related SMS setup are for.
Verifying the Result and Common Mistakes
A verified overflow alarm trips at its configured elevation on an injected level, has a clean deadband, keeps any independent high-high working when the analog path is blinded, and delivers a clear notification to a responder through the real path at the real time of day. Record the as-left setpoint, the injected-level trip result, and confirmation that the notification arrived, so the next inspection has proof the whole chain worked. On a monitoring platform the alarm event and the level trace are logged together, giving a permanent record that the alarm annunciated at the right level.
The most common mistake is verifying the setpoint on the screen and never injecting a level to confirm the logic acts on it, which misses scaling and datum faults. The second is testing the annunciation on the local panel but never proving the notification reaches a person off-site. The third is testing only in daytime and never confirming the after-hours path, so the station is silently unprotected overnight. The fourth is leaving an independent high-high untested against a blinded analog path, so nobody knows whether it is really independent.
Frequently Asked Questions
Is checking the alarm setpoint on the screen enough?
No. The setpoint can read correctly while the logic acting on it is wrong, so you inject a rising level in the controller and confirm the alarm actually trips at the configured elevation. You then prove the notification travels all the way to a responder through the real path. A high wet-well alarm has three failure points - the setpoint, the trip logic, and the notification - and only an end-to-end test exercises all three.
How do you test an independent high-high alarm?
Blind the primary analog level path by forcing its input to a benign value or disconnecting the transmitter, then raise the level so the independent high-high, driven by a backup float or a second sensor, should trip. If it fires with the analog path blinded, it is genuinely independent; if it does not, its action runs through the same logic as the primary and it is not a true last-chance layer. That independence is the whole reason it exists.
Why test the notification at different times of day?
Because a scheme that alerts the daytime control room may have no after-hours path, leaving the station unprotected overnight when a responder is hardest to reach and an overflow is most likely to go unnoticed. Confirm the alert reaches a real person at the time of day it will actually be needed, and confirm the escalation rolls to the next contact if the first does not acknowledge, so a missed page does not dead-end.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.