XRIO Templates Explained: Settings Containers, Converters and Test Plans

Re-typing relay settings into a test tool is the most reproducible error source in relay testing. Not the most dramatic — a mistyped zone reach rarely causes an incident on the day — but the most reliably repeatable. Give the same settings sheet to five technicians and you will get five transcriptions, and at least one will differ somewhere that matters.

The second half of the problem is worse: a settings change silently invalidates every test you previously built. The test plan still runs. It still produces a report with a pass verdict. It is now checking the wrong numbers. That is the problem the RIO and XRIO formats exist to solve, and it is worth understanding what they solve it with.

Key takeaways

• Manual settings transcription and stale test plans are the two failure modes these formats address.
• RIO is OMICRON’s older flat parameter-exchange format; XRIO is its XML-based successor.
• Separate two ideas: a settings container (a machine-readable record of the settings) and a converter (the formula layer that derives expected test values from them). The converter is where the leverage is.
• A relay-specific template library is a substantial asset and a substantial maintenance commitment, because a template is per-model and firmware moves.
• Verify every import against the approved settings sheet. Converters can default a missing parameter without complaint.
• ProtectionAI imports XRIO and RIO into a normalized settings model and keeps a JSON template library; a deterministic settings-to-test binding and a curated per-model library are on the roadmap.

What RIO and XRIO are

Both are OMICRON’s parameter-exchange formats — RIO standing for Relay Interface by OMICRON. RIO is the older format, flat in structure and limited in what it can express. XRIO is the XML-based successor and is what you will meet in current work.

An XRIO file describes a relay as a structured parameter set: blocks of settings, each with a value, a unit, and usually a permitted range and a resolution. That structure is the machine-readable equivalent of the settings sheet. Because the file is XML, it can be read, compared and version-controlled with ordinary tools, which matters more than it sounds like it should.

XRIO can carry a second thing as well, and this is the part that matters: a converter layer. A converter holds the mapping and the formulas that turn raw relay settings into the quantities a test actually needs — pickup currents at test points, expected operate times, impedance-zone boundaries in the reference frame the test set uses, tolerance bands. OMICRON’s own description of its Protection Testing Library puts it directly: XRIO converters model the protection characteristics and tolerances, such as impedance zones and the shape of the current-time characteristic, from the relay’s parameters.

XRIO is not an IEC or IEEE standard. It is a vendor format that became widely used because Test Universe and the Protection Testing Library are built on it, and because it is XML rather than an opaque binary. Other vendors’ test software imports XRIO to varying degrees of fidelity — assume partial support and verify, rather than assuming a clean round trip.

The two ideas engineers conflate

It is worth being pedantic here, because the distinction determines what you can actually expect from a file someone hands you.

A settings container is a machine-readable record of what the relay is set to. Its value is that it removes transcription. Import it and the test tool knows the pickup, the time multiplier, the curve selection, the CT and VT ratios, without anyone typing them.

A converter or template is the mapping and formula layer that turns those settings into expected test values and test-module parameters. Its value is different in kind: it makes the test recompute itself. Change the time multiplier in the settings, and the expected operate times at every test point change with it, because they were never stored as literal numbers — they were stored as formulas over the settings.

That second property is the whole mechanism behind settings-linked test plans, and it is the answer to the stale-test-plan problem in the opening paragraphs. A test plan with hard-coded expected values is a snapshot that decays. A test plan bound to a settings model through a converter is a derivation that follows the settings. OMICRON’s LinkToXRIO is the named mechanism for that binding in its own ecosystem.

If someone gives you “the XRIO for that relay”, the useful question is which of the two you have been given. A settings-only file saves typing. A converter saves the test plan.

What a relay-specific template library gives you, and what it costs

The established libraries are genuinely substantial assets, and it would be dishonest to pretend otherwise. OMICRON describes its Protection Testing Library as covering the important test sequences for several hundred protection device types, complete with test plans, XRIO converters and parameter import filters. Doble’s and Megger’s automated-testing products likewise ship large collections of model-specific routines; the counts each vendor publishes for its own product are the ones to quote, and they change with releases, so “several hundred” is the honest description rather than a specific number we cannot currently verify.

What you get is real: the impedance characteristic, the curve shape, the tolerance model and a sensible set of test points already encoded by someone who read the manual carefully. That is weeks of work you do not repeat per device type.

What it costs is equally real, and it is structural rather than commercial:

• A template is per-model. It encodes one relay type’s parameter names, ranges and characteristic behaviour. It does not generalise to the next relay.
• Firmware moves. A revision can rename a setting, change a range, add a parameter or alter how a characteristic is defined. The template has to be maintained in step, by whoever owns it.
• Coverage is uneven. Common transmission relays are well covered; an older distribution device or a regional model may not be, and then you are writing the converter yourself.
• Depth varies. A template that covers overcurrent thoroughly may treat a less-used function superficially. Read what is actually in it before you plan an outage around it.

None of that argues against template libraries. It argues for knowing whose job it is to keep yours current.

The practical workflow

1. Export the settings from the relay’s own configuration tool. The relay vendor’s tool is the authoritative source. Not a PDF of a settings sheet, not a screenshot, and not the copy in the commissioning folder unless you know it is current.
2. Produce or obtain the XRIO. Either an import filter converts the vendor export, or you take a library template for that model and load the settings into it.
3. Import it into the test tool.
4. Verify the imported values against the approved settings sheet. Every parameter the test depends on. Not a spot check on two values.
5. Build or generate the test plan from the imported model, so that expected values derive from settings rather than being typed alongside them.
6. Record which settings version the test was run against, in the test record itself.

Step 4 is the one people skip and the one that catches the errors. An import that succeeds without an error message has not told you it was correct — only that it was parseable. A converter that finds no value for a parameter it expects may substitute a default, and a default pickup or a default CT ratio produces a test that runs cleanly and proves nothing. Read the imported values back and compare them to the sheet, deliberately, as a signed step.

Pitfalls

• Firmware revisions that shift the ground. Setting names and ranges change between revisions. A template built for an earlier revision may map a parameter to the wrong place, or fail to see a parameter that now exists.
• Silent defaulting. As above: the most dangerous import failure is the one that does not report itself.
• Per-unit versus primary versus secondary. Whether a setting is expressed in per-unit, in secondary amps, or referred to primary is a persistent source of factor-of-CT-ratio errors. Converters handle this correctly when configured correctly, which is not the same as automatically.
• A template applied across a CT ratio change. Reusing a template from a similar bay is efficient and usually right, and it is exactly the situation in which a different CT or VT ratio slips through unchanged.
• The updated settings file nobody re-imported. Settings were revised, approved and loaded into the relay. The test plan still holds last quarter’s model. This is the failure the converter mechanism exists to prevent, and it only works if the re-import actually happens — so make it a step in the settings-change procedure, not a habit.
• Trusting a cross-vendor import. Importing XRIO into a tool that is not OMICRON’s may drop or approximate parts of the converter. Verify against the settings sheet, not against the fact that the file loaded.

The case for open, inspectable templates

There is a second approach worth considering alongside vendor libraries: template libraries stored as plain, readable text — JSON being the obvious choice — that you can open, read, diff and keep in version control.

The advantages are unglamorous and add up:

• Reviewable. A colleague can read the template and check the logic. A senior engineer can approve it. That is a different quality of assurance from trusting a binary artefact.
• Diffable. When a template changes, you can see exactly what changed. When a test result changes, you can tell whether the template moved under you.
• Versionable. Ordinary version control gives you history, branching for a firmware revision, and an audit trail that came free.
• Portable. A text format you own does not retire with the tool that created it — which is exactly the retrievability concern that shows up in PRC-005 evidence work.

The trade-off is honest: an open format does not by itself give you several hundred curated per-model templates. Openness is a property of the container; coverage is work.

GridAPM ProtectionAI, honestly

What ProtectionAI does today:

• Imports XRIO and RIO files into a normalized settings model, so relay settings enter the system as structured data rather than transcription.
• Keeps a JSON template library of reusable test plans — plain text, readable, diffable, versionable.
• Offers an AI copilot that can draft a first-pass template from a relay manual or a settings export, for an engineer to review and correct. It drafts; the engineer decides.

What is on the roadmap and not shipping:

• A deterministic settings-to-test binding of the LinkToXRIO kind — the formula-level link that makes expected values recompute automatically from the settings model.
• A curated per-model template library. The library mechanism exists; the breadth of vendor libraries built over decades does not, and we are not going to imply that it does.

Two more things about the copilot, because they are the questions engineers ask first. It requires the customer’s own Anthropic or OpenAI API key — GridAPM does not supply model access on your behalf. And it is entirely optional: everything the copilot drafts can be done manually, and the product is usable with the copilot switched off. A drafting assistant is not a prerequisite for the tool.

ProtectionAI does not drive physical test hardware. It works on settings, templates and test plans, and the test set remains the test set.

For the import and interchange detail, see the ProtectionAI integrations page. For the curve mathematics that converters encode, see IEC 60255-151 inverse-time curve constants and IEEE C37.112 curves explained.