Operations

A substation acceptance checklist for protocol engineers

2026-10-29 · 7 min read

Site acceptance is the last cheap opportunity to find protocol problems, and it is usually spent on wiring checks and point-to-point verification while the interesting failures wait for a busy day. This checklist is the protocol half of the story, written so that a commissioning engineer can execute it without a protocol specialist present.

Before energising: configuration and identity

• Every device's SCL file hash matches the one used to configure the master. Record both.
• Firmware and model revision recorded per device, against the contract.
• IP addressing, VLAN assignment and time-source configuration documented, not just working.
• A written list of declared capabilities per device, read from each Services block.

Connectivity and time

• Each association establishes within a stated time, and survives a deliberate cable pull with automatic recovery.
• Clock offset against a reference recorded for every device; alarm tested by removing the time source.
• Reconnect behaviour verified: after the link returns, values are re-synchronised without operator action.

Data quality

• A forced invalid value propagates to the control room as invalid, not as a plausible number.
• A stale value is distinguishable from a current one by timestamp alone.
• Sequence-of-events ordering matches physical order for a scripted sequence.

Control

• Each control model exercised, including the refusal cases: execute without select, double select, expired selection.
• Command termination reported to the operator, distinguishable from acceptance.
• Test flag behaviour verified on equipment that can trip.

Load and failure

• A scripted burst above expected load, with event loss and latency recorded.
• A deliberate long outage, with buffered reporting resynchronisation verified.
• One full disturbance-file collection, timed, with the resulting record opened in a tool.
• Both redundant paths broken, one at a time, during traffic.

The evidence pack

Everything above is worth nothing if it is not captured. Take captures on both sides of every link during the tests, keep them with the test record, and note the tool and version used. The first question after any later incident will be "what did it look like when it was accepted", and a capture answers it in seconds.

Questions that come up

How long should this take?

For a single bay with a handful of devices, a day including captures. It scales with device count and with how many of these checks are scripted rather than manual.

Can it be automated?

Most of it, with a test tool that drives both ends and records the result. The parts that resist automation are the operator-visible judgments — whether a refusal was understandable.

What if the customer will not allow failure injection?

Then record that it was not done, in writing. An untested recovery path is an assumption, and the record should show whose assumption it was.

Keep reading