A SCADA commissioning checklist is the structured sequence that takes an automation system from “wired and powered” to “verified and accepted,” moving through a Factory Acceptance Test (FAT) in the integrator’s shop, then a Site Acceptance Test (SAT) on the live plant. The goal is simple: prove that every signal, alarm, interlock, and screen behaves exactly as the functional design specification says before operators take the keys. This guide breaks the work into 12 concrete steps, each with an objective and an unambiguous pass criterion so nothing is signed off on assumption.
Commissioning sits at the tail end of a project lifecycle that includes design, panel build, and installation. If you want the wider context of what commissioning means as a discipline, see our pillar explainer on what commissioning is. The steps below assume the SCADA host, PLCs, network, and field instruments are physically installed and the wiring has been continuity-checked.
FAT vs SAT: why the split matters
FAT is performed at the integrator’s facility against a simulated or partially real I/O environment. It catches logic errors, screen bugs, and configuration mistakes while they are cheap to fix. SAT repeats the critical tests on the actual plant with real field devices, real cable runs, and real process conditions, confirming that nothing degraded during shipping, installation, and field termination. A defect found at FAT might cost an hour; the same defect found at SAT, with a process crew standing by, costs a shift. Treat FAT as the rehearsal and SAT as opening night.
The 12-step commissioning checklist
Step 1: FAT scope and document baseline
Before anyone touches a keyboard, agree the FAT scope in writing: which functions are tested with live I/O, which are simulated, and which are deferred to SAT. Lock the document baseline, the P&IDs, the I/O list, the functional design specification (FDS), the alarm rationalization list, and the network architecture drawing under revision control. Every later step is measured against these baselined documents, not against verbal intent.
Step 2: Network and addressing verification
Confirm IP addressing, subnets, VLAN segregation, and that the SCADA host can reach every PLC and managed switch. For serial fieldbus segments, verify that Modbus RTU and Modbus TCP device addresses are unique and that baud rate, parity, and stop bits match across the bus. EIA/TIA-485-A allows up to 32 unit loads on a single segment and roughly 1200 m of cable at lower baud rates, so confirm the physical bus has not exceeded those limits during installation.
Step 3: Power-up and instrument loop energization
Energize panels in a controlled sequence and confirm correct power supply voltages, UPS hold-up, and that field instruments report sane raw values rather than open-circuit or saturated readings. Verify signal conditioning hardware (isolators, surge protection, intrinsic safety barriers) is fitted where the design calls for it; protecting RS-485 segments with components such as an RS-485 signal isolator prevents ground loops that masquerade as comms faults later.
Step 4: I/O point-to-point checks
This is the heart of commissioning. For every physical point, inject a known stimulus at the field end and confirm the value arrives correctly at the SCADA tag. For a 4 to 20 mA analog input, drive 4, 12, and 20 mA and confirm the scaled engineering value matches within tolerance. For a digital input, operate the field contact and confirm the tag changes state. For outputs, command from SCADA and confirm the field element actuates. Sign each point individually; a sampled approach will miss the cross-wired pair.
Step 5: Communications loopback and exception handling
Beyond raw reachability, test how the system behaves when a link fails. Pull a comms cable and confirm the SCADA flags the device as offline rather than freezing stale data. On Modbus segments, confirm the master handles exception responses correctly. The standard exception codes from the Modbus Application Protocol specification are worth verifying against your driver behavior:
| Code | Name | Meaning |
|---|---|---|
| 01 | Illegal Function | Function code not supported by the slave |
| 02 | Illegal Data Address | Register or coil address not valid for the device |
| 03 | Illegal Data Value | Value in the query field is out of range |
| 04 | Slave Device Failure | Unrecoverable error while processing the request |
| 05 | Acknowledge | Request accepted, long processing in progress |
| 06 | Slave Device Busy | Device engaged, master should retry later |
| 0B | Gateway Target Failed to Respond | No response from the target behind a gateway |
If your architecture bridges serial meters to the host through a gateway, validate the mapping end to end; our Modbus RTU to MQTT gateway guide covers the translation layer in detail, and field hardware such as the SRT-MGATE-1210 gateway is what carries those registers from the RS-485 bus to the upstream broker.
Step 6: HMI screen and tag verification
Walk every graphic. Confirm each displayed value is bound to the correct tag, that engineering units and decimal places are right, and that animations (valve open/closed, pump run, level fill) track the underlying state. A frequent FAT defect is a graphic element pointed at a neighboring tag, which only surfaces when two adjacent points are stimulated independently. Cross-check navigation, security levels, and that operator setpoint entry writes back to the correct controller register.
Step 7: Alarm and trip testing
Drive each analog signal across its alarm thresholds (low-low, low, high, high-high) and confirm the alarm raises, annunciates, time-stamps, and clears at the correct value with the configured deadband. For safety interlocks and trips, simulate the initiating condition and confirm the final element moves to its safe state. Verify alarm priority, acknowledgement behavior, and that the alarm does not chatter around the threshold. Record the as-tested trip value next to the design value.
Step 8: Control logic and sequence testing
Exercise PID loops, interlocks, and any automated start/stop sequences. Confirm interlock permissives block the wrong action and that a sequence aborts cleanly on a fault rather than leaving the process in an undefined state. For closed loops, confirm the loop is stable and that auto/manual bumpless transfer works. Tuning refinement belongs to the wider industrial engineering and automation effort, but commissioning must prove the loop is at least stable and correctly directioned.
Step 9: Historian and trend verification
Confirm that historized tags are logging at the configured scan and deadband, that trends display correctly, and that data survives a SCADA restart. Force a value change and confirm it appears in both the live trend and the stored history with an accurate timestamp. Verify retention settings match the project requirement so long-term reporting is not silently truncated.
Step 10: Redundancy and failover testing
If the architecture includes redundant SCADA servers, redundant PLCs, or ring network topology, force a failure of the primary and confirm clean failover with no loss of view and no loss of control. Time the failover and confirm it meets the specified bumpless threshold. Then restore the primary and confirm a controlled fallback without a double-master condition. Redundancy that is never tested under fault is redundancy you do not actually have.
Step 11: Site Acceptance Test (SAT)
Repeat the safety-critical and operationally critical subset of the above on the live plant with real field devices. SAT focuses on what cannot be faithfully simulated at FAT: real cable runs, real instrument calibration, real ground references, and real process interaction. Re-run point-to-point checks on a sampled-but-justified basis, re-prove every trip, and confirm the network performs under real electrical noise. Electrical integrity in the field is where many SAT issues originate; a clean power and signal environment, supported by the kind of automation and electrical engineering done at design time, prevents most of them.
Step 12: Punch list and handover documentation
Capture every outstanding item on a punch list, classified by severity, with an owner and a target date. Agree which items block acceptance and which are minor and tracked to closure post-handover. Compile the handover package: as-built drawings, the signed point-to-point and alarm records, the I/O list reflecting any field changes, network configuration backups, PLC and SCADA project file backups, and operator documentation. Acceptance is granted against the signed records, not a verbal “looks good.”
Checklist summary table
| Step | Objective | Pass criterion |
|---|---|---|
| 1. FAT scope and baseline | Define what is tested where; lock documents | Scope and revision-controlled FDS/P&ID/I/O list signed by all parties |
| 2. Network and addressing | Confirm reachability and bus parameters | Host reaches every node; unique addresses; matching serial settings |
| 3. Power-up and energization | Safe sequenced energization | Correct voltages; UPS holds; instruments report plausible values |
| 4. I/O point-to-point | Verify every physical point end to end | Each AI scales at 4/12/20 mA; each DI/DO toggles; signed individually |
| 5. Comms loopback and exceptions | Verify fault behavior, not just success | Offline flagged on cable pull; exception codes handled correctly |
| 6. HMI and tag verification | Confirm screen-to-tag bindings | Every value, unit, and animation tracks the correct underlying tag |
| 7. Alarm and trip testing | Prove alarms and trips at threshold | Alarm raises/clears at design value with deadband; trip drives safe state |
| 8. Control logic and sequence | Prove interlocks and loops | Permissives block wrong action; loops stable; bumpless transfer works |
| 9. Historian and trend | Confirm data capture and retention | Tags log at configured rate; history survives restart; timestamps correct |
| 10. Redundancy and failover | Prove fault tolerance under fault | Clean failover within spec; no loss of view/control; clean fallback |
| 11. SAT | Re-prove on the live plant | Critical points and all trips re-verified with real field devices |
| 12. Punch list and handover | Close out and transfer ownership | Punch list owned and dated; signed as-built package delivered |
Common commissioning failures and their root causes
Most commissioning delays trace to a handful of recurring issues. Recognizing the pattern speeds diagnosis.
| Symptom | Likely root cause | First check |
|---|---|---|
| Tag reads correct at FAT, wrong at SAT | Field cross-wire or termination error | Re-run point-to-point on that loop with a field stimulus |
| Intermittent Modbus timeouts | Bus length, missing termination, or ground loop | Verify 120 ohm termination at both ends; check shield grounding |
| Alarm chatters around threshold | Deadband too small or noisy signal | Widen deadband; add filtering or surge protection on the loop |
| Failover loses control briefly | Sync interval or watchdog misconfigured | Check redundancy heartbeat and switchover timer settings |
| Historian gaps after restart | Buffering or store-and-forward not enabled | Confirm local buffering on the data collector |
For the deeper serial-layer faults referenced above, our companion article on troubleshooting Modbus communication errors walks through the systematic isolation procedure.
Frequently Asked Questions
What is the difference between FAT and SAT in SCADA commissioning?
FAT (Factory Acceptance Test) is performed at the integrator’s facility, often against simulated I/O, to catch logic and configuration errors cheaply. SAT (Site Acceptance Test) repeats the critical tests on the live plant with real field devices, cable runs, and process conditions to confirm nothing degraded during installation.
Do I need to point-to-point check every single I/O point?
At FAT, yes, every physical point should be individually verified, because sampling cannot catch a cross-wired pair. At SAT you can use a justified sampled approach for non-critical points, but every safety trip and interlock should be re-proven on the real plant without exception.
What belongs in a commissioning handover package?
As-built drawings, signed point-to-point and alarm test records, the final I/O list reflecting field changes, network and controller configuration backups, the SCADA project file backup, the closed-out punch list, and operator documentation. Acceptance is granted against these signed records.
How do I test SCADA redundancy correctly?
Force an actual fault on the primary server, PLC, or network ring rather than relying on a graceful manual switch. Confirm failover happens within the specified time with no loss of view or control, then restore the primary and confirm a clean fallback without creating a double-master condition.