The need for the test follows from the design of the schemes that use it. Distance teleprotection, line differential, transfer trip and blocking schemes all depend on information exchanged between locations, and the protection decision is made from a combination of local and remote quantities. If the remote quantity arrives late, arrives distorted by a routing error, or is compared against a local measurement whose time reference is wrong, the decision is wrong regardless of how well each relay was tested individually.

What end-to-end testing adds over unit tests

Unit testing verifies a relay against its settings by applying quantities at its terminals. It is precise, repeatable and essential, and it is deliberately blind to everything outside the relay. The test set applies a known quantity and the relay’s response is measured; the source of the quantity in service is not part of the test.

End-to-end testing inverts that logic. It injects a quantity at one end of the scheme and observes the resulting behaviour at the other, using the real communication path in between. What it verifies is the assembly: the relay, the interface to the communication equipment, the channel itself, the receiving interface, the addressing and the time reference at both ends.

The two tests are complementary and the order matters. Unit tests establish that each device behaves according to its settings. End-to-end tests establish that the two devices, together with the channel, behave as the scheme design intends. A failure at the end-to-end stage is far easier to attribute if the unit tests have already passed at both ends.

Communication channel as part of the test object

The channel is not a passive pipe. Between the two relays there is usually a multiplexer, a fibre or microwave link, a digital cross-connect and possibly a routed network. Each element introduces delay, and some introduce variable delay depending on the traffic they are carrying. The protection scheme’s settings include assumptions about the channel’s behaviour, and end-to-end testing is what confirms those assumptions against the actual installation.

The elements that most often cause trouble are the interfaces rather than the medium. An interface configured for the wrong bit rate, a channel that has been re-provisioned through a different route without the protection settings being reviewed, or an addressing error that delivers the message to the correct device with the wrong association all produce a scheme that appears to communicate and does not protect correctly.

Where the channel is shared with other services, its behaviour under load is part of the test. A channel that performs correctly when the network is quiet may behave differently when other traffic is present, and the protection scheme’s tolerance for that variation should be established rather than assumed.

GPS and time-synchronisation requirements

Schemes that compare quantities measured at two locations need a common time reference. In practice that reference is usually derived from a satellite timing signal at each end, and the protection algorithms assume that both ends are synchronised to within a defined accuracy.

Three conditions have to hold for the assumption to be valid. The timing source has to be available at both ends. The device that consumes the timing signal has to be receiving it, not merely connected to it. And the accuracy during the test has to be within the scheme’s tolerance, which means the synchronisation status has to be checked rather than assumed from the presence of equipment.

Loss of synchronisation is one of the failure modes that end-to-end testing exposes and unit testing cannot, because the effect appears only in the comparison between the two ends. A scheme that loses synchronisation may block rather than operate, or may operate incorrectly on load, depending on how it is configured. The behaviour under that condition is worth establishing deliberately, since the alternative is discovering it during a real fault.

Test set arrangement at each end

An end-to-end test requires equipment at both substations and a way for the two test sets to be coordinated. The arrangement depends on the scheme type. For a line differential scheme, each end injects currents into its own relay and the relays exchange the resulting quantities over the real channel, so the test sets only need to apply the correct currents at the correct times. For a distance teleprotection scheme, the test involves applying a fault condition locally and confirming that the remote end responds as intended.

The coordination requirement is what makes the arrangement different from any other test. The two test sets have to be started at a defined moment, and the results have to be captured with a common reference so that the timing can be interpreted. Where the test sets have their own timing inputs, both should be referenced to the same source, and the status of that reference should be recorded.

Fallback arrangements should be prepared in advance. If the channel fails during the test, the crews at both ends need an agreed procedure for stopping, recording the state and deciding whether the result is a finding or a test failure. That procedure is best agreed in writing before the window rather than improvised during it.

Delay and asymmetry measurement

Channel delay is measured by injecting a signal at one end and observing when the corresponding signal appears at the other, using a common time reference. The measurement is performed in both directions, because the delay from A to B is not necessarily equal to the delay from B to A.

The absolute delay matters because the scheme’s settings may include a compensation based on it. The asymmetry between the two directions matters for a different reason: several algorithms compensate for the round-trip delay but assume that the two directions are similar, and a difference between them produces an error that the compensation cannot remove.

The results should be compared against the channel delay budget in the scheme design and against the values recorded at commissioning. A delay that is stable but different from the design value may be acceptable if the scheme settings have been adjusted accordingly; a delay that varies between tests is a channel condition that needs investigation regardless of its average value.

Verifying the channel against the scheme

Verifying the channel in isolation establishes how it behaves as a communication path. Verifying it against the scheme establishes whether the scheme can operate correctly over it. The second is the test that matters, and it requires the protection functions to be exercised across the channel rather than a signal to be looped back.

The practical procedure is to create fault conditions at one end, in sequence, that should produce a defined response at the other. Internal faults, external faults, load conditions and conditions that should produce no operation are all included, because a scheme that operates correctly on internal faults and incorrectly on load has failed its purpose.

The record should state which function was exercised, what was applied at each end, what was expected and what was observed. Where a function was verified by a channel loop-back rather than by an actual scheme operation, the record should say so, because a loop-back proves connectivity rather than protection behaviour.

Common failures only end-to-end testing finds

The failures that end-to-end testing finds are concentrated in the interfaces and the configuration rather than in the relays. Interface wiring between the relay and the communication equipment is a frequent finding, especially where the interface was wired during a later phase of the project than the relay itself.

Addressing and routing errors come next. A channel that has been re-provisioned through a different path or with different identifiers can still deliver traffic while associating it incorrectly, and the resulting protection behaviour is wrong in a way that is invisible from either end in isolation.

Synchronisation problems form the third group, and they include cases where the timing source is available but is not being used by the device that needs it, or where the accuracy degrades under conditions that a short test does not reproduce. The fourth group is asymmetry, which produces errors that scale with the quantity being compared and are therefore most visible near the boundaries of the protection characteristic.

Planning a window across two substations

The planning constraint is simultaneous availability at both ends, and that usually dominates the test duration. Both substations have to have the scheme out of service, the communication channel available, crews present and a means of coordinating between them.

The plan should state the sequence of tests, the expected duration, the abort conditions, the method of coordination between the crews and the state the scheme is left in at each stage. Where the channel is shared with other schemes, the window has to account for the effect on those schemes, which may be the real limitation.

A useful practice is to perform the delay and asymmetry measurements at the start of the window, before the functional tests. Those measurements are quick, they establish whether the channel is in a condition to support the rest of the test, and if it is not, the window can be stood down early rather than continuing into a sequence that will produce confusing results.

The communication framework that these schemes are built on is introduced in IEC TR 61850-1, and the relay requirements the individual devices are verified against are defined in IEC 60255-1. Practical sequences for end-to-end testing are described in the test application documentation published by OMICRON and in the protection engineering literature from Schweitzer Engineering Laboratories. Where the channel is carried over routed network infrastructure, the security guidance published by CISA addresses the same shared-path concerns from the network side, and utility practice is coordinated through CIGRE study committees. The test equipment range is grouped on the relay protection testing hub.