Substation Relay Settings Handover: Approved Files, Version Checks and Change Control

Substation relay settings handover is complete only when the owner can connect an approved engineering decision to the configuration actually verified on a specific device. A folder of files named final does not establish that connection. The handover package must identify the relay, the approved baseline, the relevant setting groups, the comparison evidence and any changes made after testing.

For EPC teams, this is a practical interface between protection design, panel integration, commissioning and operations. The framework below focuses on configuration evidence and responsibilities. It does not prescribe protection pickup values, time delays or an energization decision. Those remain the responsibility of the authorized project engineers using the approved studies, device instructions and operating requirements.

1. Define the substation relay settings handover baseline

Three records can legitimately exist during a project. The approved file expresses the accepted design. The applied file records the intended configuration sent during commissioning. A readback or equivalent device export records what the commissioning team retrieved from the identified relay. The package should explain their relationship instead of treating their filenames as proof of equality.

Define a baseline for each device

Assign a configuration baseline to each equipment tag and protection function. Include the device model, relevant hardware options, firmware identification, engineering software version and file format where these affect compatibility. A relay with the same front-panel appearance may have a different configuration or application role. Match the record to the physical device identity and the current protection drawings.

Keep approved settings reports and editable native files together, with their purposes stated. A PDF can communicate reviewed values, while a native file supports controlled future engineering work. Neither format alone proves the installed state. If proprietary software is required, record the applicable version and the owner's agreed access arrangements without placing passwords inside the technical dossier.

2. Build a settings register with clear ownership

Use one register to connect the protection study, device schedule and commissioning evidence. Avoid parallel spreadsheets in which different teams maintain different meanings of latest. Every row should identify the equipment, configuration revision, approval reference, test reference and responsible reviewer. The register can point to controlled files instead of embedding large attachments.

Identify the release authority

The person collecting files may not be the person authorized to approve protection changes. State who owns the design baseline, who applies an approved revision, who checks the evidence and who accepts the final package. Utility-owned protection can introduce an additional approval boundary. Resolve that boundary before a site correction becomes an informal design change.

Register field	Purpose	Useful supporting evidence
Equipment and relay tag	Connect the file to one installed device	Panel schedule and device identity record
Model and applicable version	Establish the configuration context	Device information export or verified inspection
Approved revision	Identify the engineering baseline	Approval transmittal and settings report
Applied configuration reference	Record the controlled commissioning action	Authorized work record
Readback and comparison reference	Support the final configuration check	Export and reviewed difference report
Remaining restrictions	Prevent incomplete work being hidden	Open-item register with owner and closure evidence

3. Control setting groups and conditional logic

A device can contain more than one group or configuration set. The handover must identify which groups are used, how they are selected and what was verified during testing. A correct value in an inactive group may not support the intended operating arrangement. Likewise, a tested group can cease to be the relevant group if a selection input or control condition changes.

Record the selection basis

Include the approved group-selection description and the evidence for the states tested. Distinguish local selection, external inputs and application logic where the particular device supports them. Do not infer active-group behavior from an offline file alone. Capture the relevant device indication or report through the approved commissioning process and link it to the test condition.

Check whether the delivery scope includes programmable logic, communications mappings, input and output assignments or other related configuration files. These may be managed separately by the manufacturer. The settings register should describe that boundary. A protection settings comparison must not be presented as verification of every communication or control function in the substation.

4. Compare the device record against the approved baseline

Use a comparison method appropriate to the device and engineering software. Manufacturer tools may offer structured comparison functions. An SEL-published application example, Section III: Comparing Settings describes retrieving relay settings and comparing them with the settings database. The project procedure should define the actual tool, file types and review process for the installed equipment rather than assuming every relay uses the same workflow.

Explain differences instead of counting them

A difference report is a starting point for review. Some differences may concern identifiers, timestamps or other fields whose significance depends on the device. Others can affect protection or control behavior. The reviewer should classify each difference and record the approved disposition. A statement that only a few differences remain is not an acceptance criterion.

Retain the original export and the reviewed comparison record. If a later export becomes the accepted baseline, preserve its relation to the earlier record and explain why it changed. Do not overwrite the only copy of the original evidence. A clear revision chain is more useful during troubleshooting than a folder containing several indistinguishable final versions.

Use checksums for the right purpose

A checksum can help demonstrate that a transferred file is byte-for-byte identical to a recorded file when the same method is used. It does not prove that the settings are technically correct, approved or active in a relay. Record the checksum method if it is part of the document-control process, and keep that integrity check separate from the engineering comparison and approval.

5. Link configuration evidence to commissioning tests

Every relevant test report should identify the configuration revision used for that test. Without that reference, the team cannot readily determine whether a later change invalidated part of the evidence. Connect the settings baseline to the approved test scope, including the functions and interfaces that the project requires to be demonstrated.

Assess changes after testing

If a setting or logic element changes after a test, identify the affected function and obtain an approved assessment of the necessary retest. The scope may depend on whether the change affects a single parameter, shared logic, group selection or an interface to another device. Do not label a change as minor solely because it involves a small number of characters.

Maintain a record of temporary test configurations and their authorized restoration. The final dossier should show the accepted service baseline and the evidence that relevant temporary changes were closed. This article does not authorize live changes or the defeat of protection functions; all testing and restoration belong within the project's controlled commissioning arrangements.

Coordinate this evidence with the EPC transformer pre-energization commissioning test pack. The test pack should reference the accepted configuration rather than repeating a manually copied set of values that can drift from the controlled file.

6. Use a practical discrepancy decision matrix

The following matrix supports document and evidence review. It is not a substitute for the project's protection engineering judgment. Each unresolved condition needs an identified owner, an agreed action and a closure record. Handover should make restrictions visible to the receiving operations team.

Finding	Why it matters	Closure evidence to seek
File identity does not match the installed relay	The comparison may concern the wrong asset	Correct device mapping and repeated identity check
Readback differs from the approved settings	The applied baseline is not reconciled	Reviewed difference report and authorized disposition
Active group is not documented	Tested values may not represent the intended state	Verified group-selection evidence
Change occurred after commissioning tests	Existing results may no longer cover the baseline	Impact assessment and required retest records
Native file cannot be opened with the documented tool	Future support may depend on an unusable archive	A successful controlled file-readability check
File checksum matches but approval is absent	File integrity does not establish engineering acceptance	Appropriate approval reference

7. Package the files for an owner who did not attend FAT

Organize the handover so that an engineer can find the accepted baseline without asking the original commissioning technician. Use equipment tags and revision identifiers consistently across folders, reports and the register. Include a short index explaining native files, readable reports, comparison outputs and configuration-related open items.

Avoid ambiguous status labels

Names such as final, final-new and final-approved-new are poor substitutes for a controlled revision. Define the project naming convention and retain a status field in the register. If the owner has a document management system, align the package with that system's accepted naming and revision rules. Do not invent a second approval vocabulary during handover.

Keep superseded material distinguishable from the accepted service package. It can remain valuable historical evidence, but the receiving team must know which files are current and which are retained only for traceability. A transmittal should list the delivered revisions and any excluded material so that the scope of acceptance is explicit.

The EPC transformer document register can provide the wider structure for this controlled package. The relay settings register should link into that structure rather than operating as an undocumented side folder.

8. Plan support and later change control

Handover transfers information and responsibility, not a permanent guarantee that the configuration will never change. Define how an operations request, device replacement or study revision will trigger a controlled review. Include the support contact role, the information needed for a technical enquiry and the owner's rules for obtaining and approving a new baseline.

Keep access arrangements separate

Configuration files and access credentials have different handling needs. Refer to the owner's approved access-management process for accounts and permissions. The technical dossier can identify where the controlled access record is managed without reproducing secrets in a broadly circulated settings report. Confirm that the owner can use the delivered information through an authorized workflow.

For replacement devices, the team should review compatibility and application identity before relying on an old file. A similar model designation does not by itself establish interchangeability. The handover package should preserve the information needed for that review, including the relevant software and firmware context and any project-specific configuration dependencies.

9. Frequently asked handover questions

Is a signed settings report enough?

A signed report establishes the approval represented by that document. It does not automatically demonstrate that the same configuration was applied to the identified relay or that the related functions were tested. Connect approval, device evidence and commissioning records so that each claim is supported by the appropriate record.

Must every project use a checksum?

The project document-control process determines whether checksums are required and which method is used. They can be helpful for file integrity and transfer checks, but they do not replace a structured settings comparison. State what was checked and avoid turning an optional integrity measure into an unsupported universal requirement.

What belongs in a technical enquiry?

Provide the protection device schedule, approved interface drawings, settings approval process, intended file formats and commissioning boundaries. Identify utility or owner approval interfaces and the required handover format. For integrated transformer packages, include the protection and control interface matrix so that device configuration and physical interfaces are reviewed together.

10. Establish the accepted baseline before project closeout

A useful substation relay settings handover package answers five questions: which device, which approved revision, which verified configuration, which tests, and which changes remain open. Keeping these questions connected reduces ambiguity when the operations team investigates an event or plans later work.

For an EPC project review, submit the equipment scope, protection interface schedule and proposed acceptance dossier. Specify whether the enquiry concerns a transformer package, associated control interfaces or a wider substation integration scope. The required evidence can then be agreed with the responsible suppliers and project engineers before closeout becomes a search for missing files.

Technical reference: SEL-published relay testing and settings-comparison example. The manufacturer example supports the distinction between an offline settings file and a retrieved device record; use the current instructions and approved procedure for the actual equipment.

Our engineering team will review the requirements and respond to project inquiries within 24 hours.