Relay Test File Management Across a Commissioning Programme
Send your test requirement — get a tailored solution and a quote within one working day.
On a commissioning programme with hundreds of relays, the test records that fail an audit are almost never the ones where the test was performed badly. They fail because the file cannot be found, or cannot be linked to the asset, or does not show the configuration the results were obtained against. Relay test records management is a structural decision made at the start of a programme, and it is expensive to retrofit.
The volume is what makes it structural. A single relay test produces settings, configuration, functional results and often event records, and a programme multiplies that by every device in every bay. A structure that works for ten devices becomes unusable at five hundred.
Why test records fail an audit
The first failure is findability. A reviewer investigating a device needs its settings, its configuration, its test results and its change history together. Where the files are organised by date, by engineer or by test type, the reviewer has to search the whole programme to assemble that set.
The second is attribution. A result stored without the device identification, the configuration version and the as-left settings cannot be attributed to a state of the equipment, so it cannot support a conclusion about whether the protection is correct.
The third is completeness. Programmes tend to capture the results and omit the configuration, the deviations and the changes made during commissioning. Those are the items that explain why the installed state differs from the design, and they are the items an auditor asks for.
File naming and structure across a programme
The structure should be organised by asset, following the owner’s own hierarchy: substation, bay, device. Within each device, the files group by type: settings, configuration, test results, event records and change history.
The naming convention should encode the identification rather than the content. A file named by device and date can be sorted; a file named by the engineer or by the subject line of an email cannot be sorted into a programme.
| Structure based on | Works at ten devices | Works at five hundred |
|---|---|---|
| Asset hierarchy | Yes | Yes |
| Test date | Yes | No; requires searching the whole programme for one device |
| Engineer or team | Yes | No; records fragment as teams change |
| Test type | Yes | Partly; separates the settings from the results they apply to |
| Project phase | Yes | No; phases interleave and devices appear in several |
The asset hierarchy is the only structure that survives the scale, and it is also the structure the owner’s maintenance team will use afterwards. Building the programme records on it means the handover requires no reorganisation.
Storing relay configs alongside results
A relay test result describes the behaviour of a device in a particular configuration. The configuration therefore belongs with the result, not in a separate repository.
Storing them together also solves a versioning problem. Where a device is reconfigured during commissioning, the results taken before and after the change refer to different configurations, and the pair can only be interpreted if both configurations are stored with their respective results.
The configuration file should be captured at the same time as the test, and its hash or version recorded in the test record. That link is what allows a reviewer to confirm that the configuration examined was the configuration tested.
Reporting formats utilities accept
Utilities vary in what they accept. Some require a defined test report format, some accept the instrument’s native export, and some require the data to be entered into their asset management system or a specified database.
The requirement should be established before the programme starts, because it determines what the field team captures and how the data is exported. Discovering the format requirement at handover means reformatting every record in the programme.
Where no requirement is stated, the practical approach is to export in an open, structured format alongside any proprietary one, and to keep the raw data. That gives the owner the option to import it later without returning to the contractor.
Access, retention and revision control
Access should be controlled so that records cannot be altered after the fact without a trace. A shared folder with no revision control allows a result to be corrected informally, and the correction is invisible to the owner.
Retention should span the life of the asset, because the commissioning record is the baseline for every later comparison. Retention through the defect liability period alone is not enough.
Revision control should apply to settings and configurations as well as to reports. Where a device is reconfigured, the new configuration becomes a new revision with a record of what changed, who authorised it and why. That history is what allows a later investigation to establish what the protection was doing at the time of an event.
Linking records to the asset register
Each record should be linked to the asset identifier the owner uses in its register. The link is what allows a maintenance engineer to find the commissioning data for a device years later without knowing anything about the project it was installed under.
The linkage should be by identifier rather than by location, because assets move and locations are renumbered. Where the owner’s register uses a hierarchy, the commissioning record should identify its position in that hierarchy rather than inventing its own.
Where the register does not yet exist at the time of commissioning, the record should propose the identifiers and structure. Reconstructing the linkage later from drawings and schedules is one of the more time-consuming exercises a maintenance team can be given.
What to hand over at completion
The handover should contain the as-left settings and configuration for every device, the test results with their conditions and instrument details, the coordination records for schemes that span devices, and the change and deviation records with their authorisations.
It should be organised so that a third party can retrieve any single device’s complete record without reference to the programme structure. That is the test the structure has to pass, and it is the test that an audit applies.
Where the programme produced event records during commissioning, those belong in the package too, because they describe the behaviour of the scheme during the period when it was being proved. The measuring relay requirements the results are judged against are defined in IEC 60255-1, the substation communication framework relevant to distributed schemes is introduced in IEC TR 61850-1, independent acceptance practice that specifies record content is published by NETA, the traceability requirements that the instrument records have to satisfy are described in the NIST handbooks and by the accreditation bodies such as ILAC, and utility practice is coordinated through CIGRE study committees. Downloadable product documentation of the kind a package should include is listed under product documents for download, and support arrangements are described under testing services and OEM/ODM solutions.
A record structure organised by date cannot answer a question about one device.
Send your programme device list and the owner’s asset numbering to our engineering team and we will propose a folder and naming structure for it. Relay test equipment and its export options are listed on the relay protection testing hub.
FAQ
Why do relay test records fail an audit when the tests were performed correctly?
Because the record cannot be found, or cannot be linked to the asset, or lacks the configuration that the results were obtained against. The tests were done and the data exists; the failure is in the structure that makes the data retrievable and attributable. Those are decisions made before the programme starts, and repairing them afterwards is expensive.
What should the file structure be based on?
The asset, not the test date or the engineer. A structure organised by substation, bay and device allows a reviewer to find everything about one device in one place, which is what an investigation requires. A structure organised by date forces the reviewer to search the whole programme for the records of one relay.
Why store configuration files alongside results?
Because a test result describes the behaviour of a device in a particular configuration. Without the configuration, a result is a number without a state. Storing the configuration file in the same place as the results makes the pair retrievable together, which is what turns a result into evidence.
What reporting formats do utilities accept?
It varies, and it is worth establishing at the start rather than at handover. Some require a specific test report format, some accept the instrument’s native export, and some require the data in their asset management system. Where the requirement is not stated, agreeing it before the programme starts avoids reformatting thousands of records at the end.
What should be handed over at completion?
The as-left settings and configuration for every device, the test results with their conditions, the coordination records and the deviations, all organised so that a third party can find and understand any single device’s record without reference to the programme as a whole.
