Specify a supervisory control and data acquisition (SCADA) system through observable operating behavior, not a screen count or a list of protocol names. Each important point, command and failure condition needs a defined meaning, a responsible owner and an acceptance test.
This workflow is for qualified teams defining supervisory service across distributed electrical field sites. It ends at a testable specification and handover record, independent of any one communication protocol. Fast local protection and protocol-specific substation engineering are separate tasks. It does not set universal response times, assign a safety integrity level or authorize remote operation of equipment.
Define what remains local
Map field equipment, local controllers, communications, supervisory servers and operator stations. Identify which protection, interlocks and essential process functions remain independent of the supervisory service.
The National Institute of Standards and Technology (NIST), in SP 800-82 Revision 3, section 2.3.2, describes SCADA’s remote-field and centralized-supervision architecture. Use that distinction when assigning functions; do not assume a monitoring network is the safety system.
For an electrical site, the distribution-substation overview provides equipment context. The SCADA specification must state what it may observe or request for that equipment and who retains operational authority.
Give every point more than a name
A point list should identify its origin, engineering meaning, units or discrete states, scaling, quality indication, time basis and intended use. Keep source measurement time distinct from receipt or display time where that distinction affects the operator’s interpretation.
For discrete points, record every valid state and how invalid or unavailable values appear. For analog values, record range/scaling and the handling of missing or out-of-range data. A number that remains on screen after communications loss must not be mistaken for a fresh measurement.
Do not prescribe one universal polling period. Derive update and latency requirements from the operating task, field capability and communications conditions. Document how the actual design will demonstrate them.
Define commands as transactions
Record who may request a command, under which local/remote mode, with what prerequisites, and how rejection, execution and final state are reported. An acknowledgement of receipt is not evidence that the physical equipment completed the operation.
Avoid ambiguous queued commands. State what happens to a pending request when communications fail, authority changes or the server restarts. Any subsequent action must remain consistent with the approved process and interlocks.
The intelligent-breaker acceptance guide addresses device interfaces. SCADA adds the end-to-end interpretation from field indication through permission and operator feedback.
Turn requirements into an acceptance register
The following is a proposed specification tool, not a standards-mandated test schedule.
| Requirement | Test condition | Observable result to agree before testing |
|---|---|---|
| Valid measurement | Known input and normal communications | Correct identity, value, units, quality and time basis |
| Communications loss | Controlled interruption in an approved test environment | Stale/unavailable indication and defined local behavior |
| Command rejection | Missing permission or unmet prerequisite | Clear rejection without unintended actuation |
| Successful command | Authorized request with prerequisites met | Receipt, outcome and final indication distinguishable |
| Supervisory failure | Defined server or service failure | Agreed degraded service and authority behavior |
| Recovery | Restore service or configuration from accepted backup | Known configuration, verified points and controlled return |
Specify expected results before execution. “System works” is not an acceptance criterion. For each row, retain the requirement identifier, test owner, configuration, method, result and unresolved exception.
Test one failed-link scenario end to end
Choose a representative remote indication and permitted command in a controlled test environment. Establish a valid baseline. Then introduce the agreed communications loss without defeating live protection or process safeguards.
Check the operator’s displayed quality, local mode, command availability, pending-request behavior and restoration sequence. After the link returns, verify the source’s actual state rather than simply clearing an alarm.
NIST section 5.3 discusses known-state behavior and availability during disrupted operation. Sections 3.3.9 and 6 also address recovery. Its guidance supports defining the behavior; it does not establish a site-specific safe state or timeout.
A second server or network route only addresses the failures it actually covers. NIST distinguishes redundancy from sufficient protection against malicious activity. Test shared dependencies and authorized paths rather than equating two devices with complete resilience.
Keep cybersecurity and operational acceptance linked
Record allowed communication flows, access roles, configuration ownership, backups and controlled maintenance access. A protocol label, separate network name or encrypted channel alone does not establish that the process and access policy are protected.
Plan changes with the operating team. Do not carry out intrusive scanning, uncontrolled failover or mass command testing against a live system merely to complete a checklist. Use an approved test environment and coordinated site procedures where operating functions may be affected.
NIST’s publication record identifies Revision 3 as final in 2023 and points to an initial public draft of Revision 4 dated September 2026. The draft is not a completed replacement guide.
Release an operable handover, not just software
Deliver the accepted architecture, point list, command/mode definitions, access policy, tested configuration, recovery instructions and unresolved holds. Include operator training for invalid data and degraded service, not only normal screens.
The specification is complete when another responsible team can identify what the system means, what it can command, how it behaves when a dependency fails and what demonstrates recovery. Attractive displays are one output of that contract, not the contract itself.