The reason is that most protection problems found during commissioning are not inside the relays. They are in the connections between devices, in the cores and taps chosen, in the state of test links, in the polarity of instrument transformers and in settings that do not coordinate between adjacent devices. Every one of those can exist while each relay passes its own test.

Why a scheme test needs its own plan

A scheme is not a collection of relays; it is a set of relationships. Which device detects which fault, which breaker it trips, which other devices it blocks or is blocked by, how it behaves when a communication channel is unavailable, and what it does when a measurement circuit fails. Those relationships are properties of the assembly, and they are only exercised when the assembly is tested as such.

A plan that treats the scheme as a set of devices has a specific failure mode at handover. The commissioning file is complete, every relay has been tested and signed off, and yet the first system event reveals that a blocking signal was not correctly wired, that two devices had settings derived from different revisions of the same study, or that a trip output was connected to the wrong breaker. None of these is detectable by testing devices individually.

The plan therefore needs at least three stages: settings verification, functional testing of individual devices, and scheme testing that exercises the relationships. Where the scheme spans substations over a communication link, a fourth stage is added, because the link itself is part of the protection path.

Bay-by-bay sequence across the substation

Within a substation, commissioning proceeds bay by bay, because that is how the primary equipment becomes available and how outages are arranged. The bay sequence interacts with the scheme sequence, and the two need to be reconciled in the plan rather than discovered during the work.

A practical approach is to complete the full three-stage programme for each bay as it becomes available, and then to run the scheme-wide tests once the bays they depend on are complete. Busbar protection is the clearest example: its scheme test cannot be run until every bay that contributes current to the protected zone has been individually verified, because a failure in the busbar scheme cannot be attributed to a bay that has not been tested.

The plan should also identify the tests that require more than one bay to be out of service at the same time. Those are the tests that constrain the outage plan, and finding out about them during commissioning rather than before it is the most common cause of an extended outage.

Settings verification before functional testing

Settings verification is a comparison exercise: the values in the relay are compared against the values in the approved setting study, group by group and function by function. It happens before functional testing because a relay tested against the wrong settings produces a result that says nothing about the scheme’s compliance.

The verification has to cover the settings that are not simply numbers. Group selection, logic configuration, binary input mapping, output contact assignment, communication addressing and the enabled or disabled status of each element all affect behaviour as much as any threshold value. Reading the numeric settings and ignoring the configuration is a partial verification that gives a false sense of completeness.

The output of this stage is an as-left settings record that is signed and stored. It becomes the reference for every later maintenance test and for any post-event analysis, because it defines the state the relay was actually in rather than the state the study intended.

Trip and alarm matrix as the acceptance artefact

The trip and alarm matrix is the document that turns a set of test results into a verification statement. Each row is one protective function. The columns state the device or devices that implement it, the breaker or breakers it should trip, the alarms and indications it should raise, and any blocking or interlocking conditions that should suppress it.

The matrix earns its place by making the gaps visible. A row without evidence is an unfinished item, and a row that lists a function proved by only one method shows exactly where the coverage stops. At handover, the completed matrix is the statement that the scheme has been verified against the design.

Interlocks, blocking and trip circuit supervision

These three are grouped because they share a property that makes them easy to omit: they are functions whose correct behaviour is the absence of an action. Proving that a trip did not occur is a different test from proving that it did, and it requires the test to establish that the initiating condition was genuinely present.

Interlocking tests require the blocking condition to be created and the intended operation to be attempted. A test that merely confirms the interlock is enabled does not prove the scheme, because the logic between the condition and the output is where errors occur. The test record should state which condition was applied, at which point, and what was observed.

Trip circuit supervision is tested by breaking the supervised circuit at a representative point and confirming that the supervision alarms. The representative point matters: a supervision scheme that detects an open circuit near the relay but not at the breaker end leaves the more exposed section unsupervised, and the test should be designed to show which parts of the circuit are covered.

Blocking schemes, including power swing blocking, out-of-step tripping and communication-assisted blocking, need tests that establish the blocking condition and verify the resulting behaviour. Because these functions interact with the settings of other elements, they should be tested after the settings verification and in coordination with the scheme tests.

Recording evidence per function

Evidence is recorded per function rather than per test session. That orientation is what makes the matrix completable and what allows a reviewer to check coverage without reconstructing the sequence of the outage.

Each evidence record should identify the function, the device and firmware version, the applied quantities, the expected response, the observed response, the test instrument and its calibration status, the date and the personnel involved. Where a function was tested as part of a scheme rather than individually, the record should say so and name the scheme test it formed part of.

Configuration files should be captured as evidence in their own right. The relay configuration as installed is part of the scheme, and a configuration file that differs from the one used to produce the test evidence invalidates the test. Capturing the file at the time of testing and storing it with the record closes that gap.

Witnessing and sign-off requirements

Witnessing works when it is defined in advance. The plan should state which tests are witnessed, who witnesses them, what the witness is confirming and how the signature is recorded. Ambiguity about the scope of a signature is the most common source of dispute during handover.

The most workable arrangement is a single record signed by both the tester and the witness, with the procedure document referenced so that both parties are confirming the same thing. Where the witness is a utility representative with responsibility for acceptance, the record should make clear whether the signature covers the result of the test, the method used, or both.

Deviations from the design should be signed off separately and explicitly. A deviation that is accepted informally during commissioning tends to reappear during a fault investigation as an unexplained difference between the as-built scheme and the design intent.

Handover into operation

The handover package is what allows the scheme to be maintained and diagnosed for the rest of its life. It contains the as-left settings, the completed trip and alarm matrix with evidence, the primary and secondary injection records, the communication test results where applicable, the as-installed configuration files and the list of accepted deviations.

The package should also include the scheme’s dependence on external elements: the current transformer cores and taps used, the voltage transformer circuits and their fuses or miniature circuit breakers, the communication channel identifiers and the auxiliary supply arrangements. Those dependencies are what a maintenance team needs to test the scheme again without reconstructing it from drawings.

The measuring relay requirements the tests are judged against are defined in IEC 60255-1, and the substation communication framework that distributed schemes depend on is introduced in IEC TR 61850-1. Test application documentation from suppliers such as OMICRON and protection engineering literature from Schweitzer Engineering Laboratories describe practical sequences for the stages described here, the research background for protection verification practice is published by EPRI, and utility experience is coordinated through CIGRE study committees. The wider equipment range is grouped on the relay protection testing hub.