Substation Local/Remote Control Acceptance: Command Authority and EPC Test Evidence

Substation local/remote control acceptance asks a question that a successful status indication cannot answer: which control location is allowed to issue a particular command in the present operating mode? Zisheng Electric recommends resolving that question across the transformer, switchgear and automation packages before EPC handover. A correctly named button can still send a request from an unauthorized level, while a correctly rejected command can be mistaken for a communication defect if its rejection is not visible.

This guide concerns design coordination, acceptance coverage and evidence. It does not provide a switching sequence or instructions for testing live equipment. All command-related verification must follow the owner’s approved commissioning procedure, equipment instructions and operating authorization. Use approved simulation or a suitably isolated test arrangement; a website checklist is never permission to operate plant.

Define substation local/remote control acceptance by command origin

Start with an inventory of control origins rather than a single checkbox labelled remote control. Depending on the design, a request may originate at the equipment mechanism, a bay controller, the station HMI, a remote control centre or an automatic function. Identify which of those origins exist in the delivered system and which functions they can request.

A selector marked local or remote may apply only to one device or one part of the command path. Its label does not establish how the station HMI, remote gateway and automatic controller interpret the mode. The EPC must obtain an approved command-authority description that connects the physical selector, implemented logic and operator indication. Ambiguity at this point becomes expensive during integrated testing.

Keep authority separate from other permissions

Command authority, user access rights, process interlocks and protection functions solve different problems. An operator may have a valid account yet be unable to command a bay because the selected control origin is not permitted. Conversely, an authorized control origin must still satisfy applicable interlocks. Do not describe a local/remote selection as an electrical isolation or as proof that every possible actuation path is blocked.

SEL’s technical paper Benefits of Implementing Control Authority in Substation Automation Systems distinguishes process, bay, station and remote levels and explains that configured authority can restrict which origin is accepted. Its examples also distinguish manual process-level controls from MMS command authority. The practical procurement lesson is to request the actual manufacturer’s implemented behaviour, not infer a universal truth table from a front-panel label.

Write one authority matrix before separate packages are tested

List every controlled equipment function included in the contract. Breaker open and close requests, transformer tap commands and auxiliary control commands may have different arrangements. Avoid grouping them under “all controls” unless the engineering review establishes that they genuinely use the same authority logic and exceptions.

For each function, record the command origin, required mode, applicable interlock reference, expected acceptance or rejection, and the feedback available to the initiating operator. Include the device or application that makes the authority decision. A gateway that forwards a request and an IED that finally accepts it are different responsibilities, even when the operator sees one screen.

The matrix must describe the project, not an imagined ideal station. If simultaneous control from several levels is intentionally supported, document the conditions and the accepted conflict-handling behaviour. If it is prohibited, show where that restriction is enforced and how the acceptance test will establish it.

Resolve terminology at the interface meeting

Ask the switchgear supplier, transformer accessory supplier, integrator and owner to explain one representative command using the same equipment tag. Which selector changes the mode? Which input reports its position? Which configuration evaluates the request? Which screen shows the current authority? This short discussion often reveals differences hidden by identical words in separate specifications.

Separate normal acceptance from negative-test coverage

A positive test establishes that a permitted request behaves as specified within the tested boundary. It does not establish that requests from other origins are refused. Include controlled negative cases that the approved design requires, with an expected result agreed before the session. Rejection is a successful test outcome when rejection is the requirement.

Record why each case exists. A request from an unauthorized origin, a permitted origin with an unsatisfied interlock, and an unavailable communication path are different cases. Combining them into one “command failed” result loses information. The reviewer should be able to tell whether authority, process conditions or transport prevented completion.

The SCADA point-to-point test guide addresses signal-path evidence. Authority acceptance builds on that evidence but has a separate purpose: proving the permitted relationship between origin, mode and function. A point-list sign-off should not automatically close the authority matrix.

State what was actually simulated

A software test of the integrator’s application may establish its decision logic without proving the physical selector input or final output circuit. A factory test with representative hardware has another boundary. A site test of installed interfaces has another. Keep those boundaries visible so that the final dossier does not claim end-to-end coverage from a narrower simulation.

Test equipment and temporary connections must be covered by the approved method. The team should not bypass an interlock or alter a running network merely to produce a desired result. Where a case cannot be tested safely within the current boundary, record the limitation and obtain an approved alternative or a later hold point.

Treat transfer of control as a state change

A selector change is not just a new label on the screen. The owner needs an agreed account of what authority becomes available, which indications change and how a request already in progress is handled. The exact implementation depends on the equipment and control model, so obtain it from the responsible supplier and the project design.

Include transitions that matter operationally, such as moving from bay control to station control or restoring a remote-control path after maintenance. Define the expected observation at each relevant workstation. A station display and a remote control centre should not silently disagree about who has authority. If an indication is unavailable or outdated, its interpretation must follow the approved operating philosophy.

Requests that were selected, queued or interrupted before a mode change need explicit consideration where the implementation supports those behaviours. Do not assume that every product discards or retains them in the same way. The acceptance plan should reference the actual command model, its documented timeouts and the approved handling of an incomplete operation.

Make rejection and completion understandable to the operator

Document the feedback provided to the originator: request received, request rejected, operation in progress, completed or timed out, as applicable to the delivered system. These are not synonyms. The evidence should preserve the distinction between a communication acknowledgement and the physical or functional feedback used to establish completion.

For a rejected request, confirm the agreed reason presentation and event record. The operator should not need to infer authority from the absence of movement alone. At the same time, avoid inventing diagnostic detail that the equipment does not provide. If the implementation cannot distinguish two failure reasons, make that limitation visible in the design review and operating documentation.

The related HMI mimic acceptance checklist addresses display identity and data quality. Use consistent equipment tags and mode wording across both dossiers. A correctly functioning authority decision can still be difficult to operate if one screen calls the mode station and another calls the same condition remote.

Preserve a common event reference

Where several devices contribute records, identify the timestamp basis and configuration used. Acceptance should demonstrate the sequence required by the project without claiming a timing accuracy that was never specified or measured. Keep the initiating workstation, target equipment and test-case identifier together in the record so that a later reviewer can reconstruct the particular event.

Include degraded operation and restoration in the design review

Ask what the system is intended to do when a workstation, gateway, communication path or relevant control supply becomes unavailable. These are engineering questions for the supplied architecture. Do not assume that loss of a remote path automatically grants local authority, or that a restored path automatically returns the previous operating arrangement.

The acceptance scope should identify approved cases, expected indications and the limits of the demonstration. A laboratory simulation of a communication failure may be useful, but it is not evidence that every installed network failure has been tested. Preserve any exclusions and connect them to the project’s remaining verification activities.

Restoration deserves its own result. Confirm the accepted configuration and authority state after temporary conditions have been removed. The responsible team should reconcile any changed settings, test modes and temporary connections before releasing the system from the test boundary. A final screenshot alone is weaker than a traceable restoration checklist signed by the appropriate parties.

Use a short discrepancy example to test the handover logic

Consider a hypothetical factory test in which a station HMI correctly refuses a request when bay control is selected, but the remote control-centre simulation can still send that request through another path. The first test passed within its boundary; the complete authority requirement did not. This is an illustrative review case, not a report of an actual customer project.

The response should be a controlled discrepancy, identifying the affected function, origin, mode and configuration. Assign the design decision to the responsible engineer. After correction, repeat both the failed case and other cases affected by the change. Do not close the issue merely because the original HMI button now appears disabled.

This example also shows why ownership must cross package boundaries. The integrator may own the station screen, while the receiving IED owns final authority enforcement. Procurement should name the party responsible for coordinating the complete acceptance result and the party authorized to approve any deviation.

Hand over a matrix that operations can maintain

The final package should contain the approved authority description, tested case matrix, actual configuration identities, discrepancy dispositions and restoration evidence. Keep the applicable manufacturer documents with the accepted project revisions. Record which tests were factory simulations and which covered installed site interfaces.

Changes after handover can invalidate part of that evidence. A replacement controller, new remote workstation or altered automatic function should trigger an impact review of the affected authority paths. Preserve the original acceptance basis so the maintenance team can decide what needs re-verification instead of repeating an entire commissioning programme without a defined reason.

Coordinate the equipment enquiry with the control architecture

For packages using 35 kV–46 kV power transformers or 110 kV–115 kV power transformers, identify the supplied accessories and external control responsibilities explicitly. The product voltage class does not determine station command authority. That authority belongs to the coordinated project design and must be accepted at the relevant interfaces.

To plan substation local/remote control acceptance with Zisheng Electric, provide the single-line diagram, equipment datasheets, load list, technical specifications, control architecture, command-origin matrix, verified grid parameters and environmental and installation-site conditions. Highlight unresolved supplier boundaries before the test schedule is fixed. Our engineering team will review the requirements and respond to project inquiries within 24 hours.

Technical reference: SEL, Benefits of Implementing Control Authority in Substation Automation Systems, 2025. Project-specific behaviour must be confirmed against the delivered equipment documentation.