The verification is a comparison, and like every comparison it is only as good as the traceability of what is being compared. The study has a revision, the relay has a configuration, and the two have to be linked by a record that shows which revision the relay is holding.

From protection study to relay settings

The protection study produces the criteria: the fault levels, the grading margins, the time multipliers and the thresholds that make the scheme coordinate. The setting sheet translates those criteria into the values a specific relay model expects.

The translation is where errors enter. A study expressed in primary quantities, a setting sheet expressed in secondary quantities and a relay configured in per-unit or in secondary values requires a consistent conversion, and the conversion depends on the current transformer ratio and the tap actually in use.

The verification therefore starts from the study and works forward through the translation, rather than starting from the relay and reading what is there. A value that is present and plausible can still be the wrong value if the conversion was made against a different ratio.

Verifying settings against the study, not opinion

Every verified value should be traceable to a line in the approved study. Where a value differs, the finding is either an error in the relay or a change that was agreed and not recorded.

The verification should cover the settings that are not numbers. Group selection, logic configuration, binary input mapping, output contact assignment, communication addressing and the enabled status of each element all affect behaviour as much as any threshold, and they are frequently omitted from a settings check that focuses on the numeric list.

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

Group settings and multiple setting groups

The group switching logic deserves particular attention on schemes that change group with network configuration. A relay that switches group at a defined condition is protecting correctly only if the condition and the group it selects are both as designed.

Version control when the study changes

Protection studies are revised: after a network change, a new connection, a revised fault level calculation or a change in the operating regime. Each revision produces new settings for some relays, and the relays that were not changed retain the previous revision’s values.

Without version control, a relay can hold values from two revisions and nothing in the record shows it. The verification cannot resolve that after the fact, because the record does not state which revision the relay was set to.

The practical arrangement is to record the study revision alongside the settings for each relay, and to record the date on which each relay was last updated to that revision. A relay whose update date precedes the current revision is then identifiable without opening the device.

What to check in the relay before injecting

Before any quantity is injected, the relay should be confirmed as being in the configuration that will be in service: the correct setting group active, the elements enabled as designed, the binary inputs and outputs mapped as the scheme drawing shows, and the communication addressing correct where the scheme uses it.

The firmware and configuration version should also be recorded. A relay that has been updated or replaced since the last verification is a different device from the one that was verified, and the record should show that.

Where the relay is one of several in a scheme, the pre-injection check should confirm that the settings coordinate with the neighbouring devices. A relay whose own settings are correct but whose grading does not match the device downstream is a scheme that will mis-coordinate, and the comparison is what reveals it.

Documenting setting changes for audit

A setting change is a controlled change. The record should contain the previous value, the new value, the authorisation, the reason, the date and the person who applied it, together with a reference to the study revision that required it.

The record should also state whether the change invalidates an earlier test. A change to a setting that has been functionally verified means part of that verification no longer applies, and the decision about whether to re-test should be recorded rather than assumed.

Where a change is made during commissioning to accommodate a site condition, the reason belongs in the record with the engineer’s justification. Those changes are the ones most likely to be forgotten and the ones most likely to be questioned later, because they differ from the study without necessarily being wrong.

Coordinating settings across bays

Protection settings coordinate across bays: a feeder relay and the transformer relay upstream have a grading relationship, a busbar scheme and its incomers have a zone relationship, and a distance scheme at each end of a line has a pairing relationship.

Verifying each relay against its own setting sheet confirms that each is configured as designed. It does not confirm that the design coordinates, and it certainly does not confirm that the two ends of a line are paired correctly after one end has been replaced.

Where the scheme is distributed, a coordination table that shows the relationship between the devices should accompany the individual settings records. That table is what allows a reviewer to see whether the values in the devices produce the grading the study intended.

Handover of the final settings record

The handover should contain the as-left settings for every device, the study revision each corresponds to, the configuration files as installed, the change record with its authorisations, and the coordination table for the schemes that depend on more than one device.

The record should identify the device unambiguously by type, model, serial number and firmware version, because a later replacement with the same model but a different firmware can behave differently at the margins.

Finally, the handover should state what was verified and what was not. A settings record that states the origin of every value and the revision it belongs to is what allows the protection scheme to be maintained and audited for the rest of its life. The measuring relay requirements that the verification is judged against are defined in IEC 60255-1, the substation communication framework that distributed schemes depend on is introduced in IEC TR 61850-1, protection engineering practice is published by Schweitzer Engineering Laboratories, test application documentation is available from OMICRON, the research background is published by EPRI, and utility practice is coordinated through CIGRE study committees. The equipment range is grouped on the relay protection testing hub.