Doble RTS and AI-Assisted Test-Record Review: A Practical Boundary

Doble RTS is documented as a universal relay-testing software environment with test routines, plans, reports, and support for multiple test-set families. An AI article about it should remain a workflow study, not a claim that AI is part of the RTS product.

The review problem

The physical result may be stored correctly while the surrounding context is fragmented. A reviewer needs the asset identity, settings version, procedure, equipment calibration, case coverage, expected and measured values, tolerance, raw file, as-found/as-left state, and disposition of deviations. A universal test platform does not automatically solve the utility’s document-management problem.

A bounded AI review pattern

Use the AI layer after a deterministic export. Give it a manifest, not unbounded access. Let it compare identifiers, check for missing test cases, group deviations, retrieve the approved manual or procedure, and draft a report index. Require every assertion to point to a source row or file. If a record is missing, the assistant should say so.

The human reviewer must verify that a “missing” flag is real and that a “complete” pack covers the required physical scope. AI should not convert a Doble RTS result into a compliance conclusion.

ProtectionAI’s complementary position

ProtectionAI can be evaluated for cross-record context, simulator preparation, and review packages alongside an existing RTS workflow. The question is whether engineers spend less time searching and more time evaluating the actual protection result. A pilot should compare the same historical records with and without the assistant.

Preserve the vendor boundary

RTS, Protection Suite, and similar environments are the execution and record-management systems selected by the utility. An AI layer should not pretend to be a new RTS module or imply that a Doble result is incomplete simply because it was produced in another product. The better pattern is a controlled export: a manifest identifies the record, asset, test set, relay, setting group, procedure, calibration, measured values, raw files, and reviewer status. The assistant reads that manifest and links its observations back to the original source.

Cross-record checks are where the workflow often benefits. A reviewer may need to find every result for a relay after a firmware change, compare as-found and as-left settings, identify an asset with repeated failed cases, or confirm that a report includes the expected binary logic. An assistant can group those questions and draft a retrieval path. It should not silently “repair” a missing identifier or infer that a record is compliant because the report contains a green status.

Pilot measures that respect engineering work

Use a small historical sample and have a qualified reviewer grade each finding. Track the percentage of source-linked findings, false positives, time to verify a finding, time to locate the raw record, and the number of corrections made before an outage. Compare the same sample with the existing RTS search-and-review process. This gives a more useful answer than asking whether an AI summary sounds professional.

The complementary question for ProtectionAI is whether a simulator-first planning and review layer reduces the context gap around a physical test workflow. The pilot should document exactly what it can ingest, whether it can read a given export, and what remains outside scope. The physical test set, its approved software, calibration, wiring, and the engineer’s acceptance decision stay authoritative.

References

• Doble Engineering Company. (n.d.). RTS [Product page]. https://www.doble.com/product/rts/
• Doble Engineering Company. (n.d.). Protection Suite [Product page]. https://www.doble.com/product/protection-suite/
• Doble Engineering Company. (n.d.). PowerBase [Product page]. https://www.doble.com/product/powerbase/
• IEEE. (2023). IEEE guide for power system protection testing (IEEE Std C37.233-2023). https://standards.ieee.org/ieee/C37.233/6676/