Protection-Testing Data Interoperability: SCL, RIO, XRIO, COMTRADE, and Evidence

Protection teams rarely work with one file format. An IEC 61850 digital-substation project may include SCL files. A relay-test workflow may use RIO or XRIO settings. A disturbance analysis may use COMTRADE. The report may be PDF or a database record. The engineering problem is not just converting files; it is preserving meaning while the data crosses tools.

Different formats carry different kinds of truth

SCL: system and communication context

IEC 61850-6 defines SCL as a configuration description language for IEDs, communication systems, and substation structure. It can carry the relationships that matter to GOOSE, sampled values, logical nodes, datasets, and control blocks. It does not automatically say that the installed system matches the file, that a relay setting is correct, or that the network will meet the tested timing.

RIO and XRIO: relay settings and characteristics

RIO-style data can describe relay characteristics and settings in a form that test software can use. XRIO templates extend the idea with structured parameters and model-specific mapping. The XRIO guide explains why settings-driven plans reduce retyping but also why a mapping error can create a precise test of the wrong setting.

COMTRADE: transient evidence

COMTRADE carries samples and metadata for transient exchange. It is valuable for playback and event analysis, but it is not a complete asset identity, settings history, or system model. The CFG/DAT pair must be interpreted with channel names, ratios, time, trigger, and relay context.

Build a data contract before adding AI

Before an assistant is allowed to reason over imported data, define the invariants:

• asset identifier and aliasing rules;
• device model, serial, hardware, and firmware;
• settings group and checksum;
• nominal quantities, ratio, units, phase sequence, and polarity;
• time zone, time source, sample rate, and synchronization;
• source format and version;
• parser and mapping version;
• permitted transformations and rounding;
• original-file hash and storage location;
• reviewer required for each transformation.

The contract should make it possible to say: “This expected value came from this setting in this export, parsed by this version, mapped to this function, under this procedure.” Without that chain, the AI may be able to summarize the data but the engineer cannot defend the result.

What agents can validate

A tool-using assistant can coordinate deterministic checks and make the exceptions easier to read:

1. Compare the relay identity in the RIO/XRIO package with the work order and SCL device.
2. Check that every imported parameter has a unit, source, and mapping.
3. Flag a settings value that falls outside the relay manual’s declared range.
4. Compare the test plan’s binary and communication references with the SCL relationships.
5. Confirm that a COMTRADE record’s channel count and sample rate match the selected replay or analysis path.
6. Draft a mapping report with changed values and unresolved fields.

The checks should be deterministic. The model can explain the finding or propose a question, but the parser and schema validator should establish what is actually different.

Interoperability does not remove qualification

Vendor documentation may say that a test platform imports certain files or supports an interface. That is evidence of a documented capability, not proof that every relay model, firmware, or customer configuration is interoperable. Test-set software, relay firmware, SCL engineering tools, and settings exports all evolve.

The acceptance question is concrete: can the selected tool map this customer’s actual files to this customer’s actual relay and reproduce the expected test under the approved procedure? If not, the workflow should stop at review rather than silently convert the data.

Where ProtectionAI fits

ProtectionAI can be evaluated as a context and evidence layer around these formats. It can help engineers inspect imported settings, connect a manual passage to a parameter, build a simulation plan, and explain conflicts. The product should not claim universal interoperability with OMICRON, Doble, Megger, EuroSMC, or every IEC 61850 configuration tool unless each path is explicitly qualified.

The strongest product behavior is to show the original value, mapped value, source, transformation, and reviewer status. A red “needs review” row is more valuable than a green dashboard that hides a conversion assumption.

A useful handoff format

For every imported item, retain:

source file -> source path -> parsed value -> normalized value -> target field
            -> validation -> transformation -> reviewer -> approved version

The same structure applies to SCL relationships, settings, COMTRADE channels, and report claims. It gives the AI an evidence graph to traverse and gives the engineer a way to audit it.

References

• Institute of Electrical and Electronics Engineers. (2013). IEEE standard for common format for transient data exchange (COMTRADE) for power systems (IEEE Std C37.111-2013). https://standards.ieee.org/ieee/C37.111/10507/
• International Electrotechnical Commission. (2024). Communication networks and systems for power utility automation—Part 6: Configuration description language for communication in electrical substations related to IEDs (IEC 61850-6 consolidated version). https://webstore.iec.ch/en/publication/103863
• International Electrotechnical Commission. (2022). Measuring relays and protection equipment—Part 1: Common requirements (IEC 60255-1:2022). https://webstore.iec.ch/en/publication/59762
• Institute of Electrical and Electronics Engineers. (2023). IEEE guide for power system protection testing (IEEE Std C37.233-2023). https://standards.ieee.org/ieee/C37.233/6676/
• OMICRON. (n.d.). Test Universe [Product page]. Retrieved August 1, 2026, from https://www.omicronenergy.com/en/products/test-universe/