How to Validate a SCADA Config Before Go-Live

Back to Blog

Prove Every Point End to End

Validation starts at the field and ends at the display, one point at a time. For each point, inject or produce a known signal at the field end and confirm the correct value appears everywhere it should - on the HMI, in the historian, in any calculation that uses it. A point that reads right on the HMI but wrong in the historian, or a value that never updates because a mapping is off by one register, is exactly the kind of error that end-to-end checking catches and desk-checking the configuration misses.

Confirm the scaling and units at the same time, because a point that updates but reads the wrong magnitude is still broken. Injecting the endpoints of the range and checking the displayed engineering value proves the engineering unit scaling is right, and adding a midpoint catches a nonlinear scale gone wrong. A point is only validated when it reads the correct value, in the correct units, everywhere it appears, not merely when it moves.

Check comms health and quality per device as part of the point walk. Confirm each device is communicating, that its points carry good quality when it is healthy, and that the mapping matches the real device address, because a point-to-point test on a device that is not actually connected proves nothing. This ties the validation to the underlying SCADA tag definitions and their device bindings, which are where remap errors hide.

Prove Alarms, Calculations, and Failure Behavior

Test every alarm by driving its input across the limit and confirming it trips at the right value, annunciates with the right priority and message, and clears correctly, including the deadband and any delay. An alarm that is configured but never tested is an alarm you are hoping works, and the failure modes - a limit entered wrong, a deadband that swallows the trip, a message that says nothing - only show up when you actually push the value through. This proves each SCADA alarm does what its configuration claims.

Verify calculations against known inputs and check their failure handling. Take real or forced input values, work the formula independently, and confirm the calculated tag matches, then force the failure cases - a bad input, a zero denominator - and confirm the calc fails visibly rather than publishing a confident wrong number. This is the validation half of building calculated tags safely, and skipping it lets a subtly wrong formula go live looking correct.

Test the failure behavior deliberately, because the happy path always looks fine and the failures are what bite in production. Pull comms and confirm the comms-fail alarm fires and data goes bad; cut a link long enough to exercise store-and-forward and confirm recovery is gapless and correctly timed; check that a bad-quality value does not trip a spurious alarm or launder into a calculation. A configuration that works when everything is healthy but misbehaves when a device dies is not validated, and the failure tests are exactly the ones people skip under schedule pressure.

Work From a Checklist and Sign Off Honestly

Drive the validation from a written checklist so nothing gets skipped, especially under the time pressure that always surrounds go-live. The checklist forces coverage - every point walked, every alarm tripped, every calculation checked, the failure cases exercised - and turns validation from a vague sense that it probably works into a documented set of things that were actually verified. The ordered checklist below is a starting frame:

1. Every point reads the correct value and units end to end.
2. Every device communicates and its points carry correct quality.
3. Every alarm trips, annunciates, and clears at the right value.
4. Every calculation matches a hand check and fails visibly on bad input.
5. Comms-fail detection fires and marks data bad when a device is cut.
6. Store-and-forward recovers gaplessly with correct timestamps.
7. The change is recorded and the configuration is backed up.

Sign off only what was actually tested, not what was assumed. The temptation at go-live is to check off items that look obviously fine without exercising them, and that is precisely where the missed error hides. An honest validation records what was verified and flags what was not, so anyone relying on the sign-off knows its real coverage. This discipline is the same one behind staging a config change with rollback: prove it before you trust it.

Verifying the Validation Was Complete

Confirm coverage by reconciling the checklist against the full point and alarm list. Every point should have been walked and every alarm tested, and a quick count of tested items against the total reveals anything that fell through - the twenty points on a device nobody got to, the alarms on a screen that was never opened. Validation that covered most of the system still ships the untested remainder to production, so the reconciliation is how you know the coverage is complete rather than merely large.

Capture the go-live state so you have a known-good baseline. Back up the validated configuration and record what the system looked like at sign-off, so any later problem can be compared against a proven starting point and any drift can be traced. A validated configuration that is not preserved leaves you unable to tell later whether a fault was always there or crept in afterward, which is why the final validation step is securing a SCADA backup of exactly what went live.

Common Mistakes to Avoid

The biggest mistake is validating only the happy path - confirming everything reads right when all is well and never testing what happens when a device dies, a link drops, or an input goes bad. The failure behavior is what bites in production, so test it deliberately. The second mistake is desk-checking the configuration instead of proving points end to end with real signals, which misses mapping errors and scaling faults that only appear when a real value flows through.

The third mistake is signing off items that were assumed rather than tested, which is exactly where the missed error hides - record only what was actually verified. The fourth is failing to reconcile the checklist against the full point and alarm list, so a device or a screen that nobody got to ships untested to production, its errors waiting to surface on the day the plant is depending on it.

Frequently Asked Questions