SCADA Commissioning Checklist

Why commissioning needs a checklist

SCADA commissioning is where design assumptions meet real devices, real operators, and real network conditions. A system can look complete in engineering, pass a quick screen review, and still fail during startup because tag quality is ignored, alarms are not actionable, historian values are scaled incorrectly, or a firewall rule was never tested from the production subnet.

A checklist does not replace engineering judgment. It prevents avoidable misses when the project team is tired, schedules are compressed, and everyone is focused on getting the line or process running.

Before going to site

Start before the first live device test. The best commissioning work happens when the team knows what must be proven.

• Confirm the final architecture: SCADA servers, clients, historians, OPC UA servers, protocol gateways, domain services, and remote access boundaries.
• Confirm IP addresses, hostnames, VLANs, firewall rules, and required ports.
• Export the latest tag list, alarm list, screen list, user list, and historian point list.
• Identify which tags are simulated, which are live, and which are not yet available.
• Prepare test credentials for each intended role.
• Bring offline installers, licenses, certificates, backups, and recovery notes.
• Define who can approve PLC writes, setpoint changes, alarm changes, and bypasses.

Do not wait until startup to discover that the only copy of a driver installer is on a laptop that did not come to site.

Communication checks

Communication should be validated from the SCADA layer down, not guessed from screen behavior.

Basic network checks

Verify link, addressing, and routing first:

• Device is powered and connected to the expected switch port.
• IP address, subnet mask, gateway, and VLAN match the network plan.
• DNS or hostname resolution works if hostnames are used.
• Required TCP ports are reachable from the SCADA server or gateway.
• Time synchronization is working across servers and devices that provide timestamps.

Protocol checks

Use the right tool for the protocol before debugging HMI bindings:

• For Modbus TCP, validate unit ID, function code, register range, data type, scaling, and word order.
• For OPC UA, validate endpoint URL, security policy, certificate trust, namespace, node IDs, subscriptions, and quality.
• For MQTT, validate broker address, credentials, topic structure, retained message behavior, payload format, timestamp, and quality fields.
• For vendor drivers, check driver diagnostics and error counters instead of only looking at screen values.

A screen showing zero is not proof of a valid value. It may be a real zero, a failed read, a default value, a stale value, or a scaling error.

Tag validation

Tag validation should prove meaning, not only connectivity.

For each important tag, confirm:

• The tag name matches the naming standard.
• The description is understandable to someone outside the implementation team.
• The source address or node is correct.
• The data type is correct.
• Engineering units are correct.
• Scaling is correct across the expected range.
• Quality is visible or handled appropriately.
• Command tags and feedback tags are not confused.
• Setpoints have limits and authorization where required.

For analog values, test at more than one value when possible. A single point may hide scaling, offset, or word-order problems.

Screen and operator workflow checks

A screen is ready only when it supports the operator's workflow.

Review each major display with operations and maintenance:

• Equipment state is visible without hunting through multiple popups.
• Color use is consistent and not overloaded.
• Alarm state, running state, fault state, permissive state, and manual state are visually distinct.
• Units, ranges, and descriptions are shown where needed.
• Navigation is predictable.
• Commands require the appropriate confirmation and security role.
• Faceplates show the same meaning across similar equipment.
• Diagnostic screens expose communication health and device status.

Avoid judging screens only by how they look in a meeting. The better test is whether an operator can answer: what is running, what is stopped, what is abnormal, what changed, and what action is safe.

Alarm checks

Alarm commissioning is one of the highest-value reviews.

For each configured alarm, confirm:

• The condition is real and meaningful.
• The priority reflects urgency and consequence.
• The message identifies equipment, condition, and useful context.
• The alarm has an expected operator response.
• Deadband and delay settings prevent chatter.
• Acknowledgement, shelving, latching, and reset behavior are understood.
• Alarm summary, alarm history, and event logs show the right timestamp and source.

Run at least one alarm flood scenario if the process allows it or if it can be simulated safely. Startup often reveals alarms that were technically configured but operationally useless.

Trends and historian checks

Trending and historian data should be validated before handover, not weeks later when someone needs a report.

Check:

• Trend pens show the right tag, units, and range.
• Values align with live screen values.
• Historian collection rate matches the purpose of the data.
• Exception, compression, or deadband settings do not hide important changes.
• Bad quality is visible or queryable.
• Timestamps are correct and consistent.
• Renamed tags have a migration or lineage plan.
• Reports and exports can access the expected data.

A historian is only useful if future engineers trust the data. Commissioning is the moment to earn that trust.

Security, users, and recovery

Before handover, prove that the system can be operated and recovered safely.

• Confirm user roles and permissions.
• Test login, logout, password, and lockout behavior.
• Verify audit trails for commands, setpoint changes, acknowledgements, and configuration changes.
• Confirm certificates and credentials are documented in the approved secure location.
• Create backups of applications, configuration files, licenses, certificates, scripts, and deployment notes.
• Perform at least one restore test or document exactly how restore was verified.
• Confirm PM2, systemd, services, or scheduled tasks restart correctly after reboot.

Backups are not complete until someone can explain how to restore them.

Handover package

A practical handover package should include:

• Final architecture diagram.
• Final IP and port list.
• Tag export.
• Alarm export and alarm philosophy notes.
• Historian point list.
• User and role summary.
• Backup location and restore steps.
• Known issues and temporary workarounds.
• Commissioning test record.
• Vendor manuals and official protocol references.

The goal is not paperwork for its own sake. The goal is to make the system maintainable after the project team leaves.

Practical rule

Commissioning is complete when the system has been proven from device data to operator workflow to recovery path. If a future maintainer cannot understand what was tested, what was accepted, and what remains risky, commissioning is not finished.