Agentic AI for Protective Relay Testing: What It Can and Cannot Do

Agentic AI is an overloaded phrase. In protection engineering, it should not mean that a language model is allowed to change a relay setting, energize a circuit, or declare a protection scheme safe. A more useful definition is narrower: an agent can retrieve approved evidence, call bounded engineering tools, carry context between steps, stop when information is missing, and prepare a reviewable work product for a qualified engineer.

The short answer

An agentic assistant can reduce repetitive work around a relay test without becoming part of the protection function. The defensible use cases are:

• finding the correct relay manual, settings version, test template, or prior result;
• checking whether the evidence pack is complete before an outage;
• translating an approved settings model into a draft test sequence;
• running deterministic simulator calculations and explaining the output;
• comparing expected and measured values using a stated tolerance basis;
• identifying contradictions, stale files, missing channels, or unexplained changes;
• drafting a report that links every conclusion to a source record.

The boundaries are equally important. AI does not replace a calibrated relay test set, a safe isolation procedure, the engineer responsible for the scheme, a physical trip-path test, or the maintenance programme that governs the asset. IEEE C37.233 treats protection testing as an engineering activity with defined methods and evidence; the AI layer should support that activity, not quietly redefine it.

What makes an assistant “agentic”

A chat window can answer a question about an overcurrent curve, but it usually cannot see the issued settings, firmware version, wiring diagram, test-set calibration record, or last as-found result. An agentic workbench connects the model to explicitly registered tools and data objects. A typical bounded sequence looks like this:

1. The engineer selects an asset, approved settings package, procedure, and test scope.
2. A quality gate checks identity, units, version, data freshness, and required evidence.
3. The assistant retrieves relevant manual passages and proposes a plan, with citations and unresolved questions.
4. Deterministic software calculates expected values, characteristic points, timing, or simulated waveforms.
5. The engineer reviews the plan and either edits, rejects, or authorizes the next step under the local procedure.
6. Results, comments, deviations, and the final decision are stored with links to the raw record.

The model is useful because it can coordinate context across those steps. It is not useful as a source of untraceable numerical authority. Recent power-system research and road maps describe agentic or tool-using workflows, but the literature does not establish unsupervised LLM control of live high-voltage protection trips. A 2024 review also describes practical real-time ML protection as an early-stage field rather than a proven basis for replacing established protection practice.

Keep verdicts deterministic

For a relay test, the most important calculation is not prose. It is the comparison between an expected value, a measured value, and a stated tolerance. If an inverse-time curve is defined by a standard and a manufacturer-specific implementation, the software should show the formula, constants, settings, input quantities, and tolerance basis. Given the same inputs, the result should be reproducible.

That makes a clean authority split:

• deterministic code owns curve mathematics, point generation, tolerance comparison, and the recorded verdict;
• the assistant can explain a failed point, retrieve a manual page, suggest a diagnostic question, or draft narrative;
• a qualified engineer decides whether the result is accepted, repeated, escalated, or investigated.

This is not a claim that deterministic software is automatically correct. A wrong settings file or wrong CT ratio can produce a repeatable test of the wrong thing. Determinism makes the assumption visible and reviewable; it does not remove the need for engineering judgement.

Commissioning, maintenance, and event review

The value of an agent often appears before and after injection. During commissioning, it can check that the test plan covers the issued settings, CT/VT circuits, communications, binary inputs, breaker-failure logic, and representative system cases. During maintenance, it can compare the last as-found and as-left records, highlight drift, and assemble the evidence needed by the responsible programme. After an operation, it can connect a COMTRADE record, relay target, settings version, disturbance report, and corrective action without asking an engineer to search five folders manually.

Those are evidence-management and reasoning tasks. They are not proof that a physical relay or complete scheme will operate correctly in every system condition. CIGRE guidance on acceptance, commissioning, field testing, and lifecycle testing is a useful reminder that the test strategy has to match the PAC function and its lifecycle stage.

Where ProtectionAI fits

ProtectionAI is GridAPM’s protective-relay testing software with an agentic copilot. Its published positioning is a Windows workbench for settings, test modules, simulation, manuals, and reports. The product boundary matters: the published v1.3 workflow is simulator-first, and any connection to physical test equipment must be treated as a separate qualification and customer-procedure question. A generated report is a draft until the responsible engineer checks the inputs, calculations, procedure, and evidence.

For a pilot, the most credible question is not “Can the AI test a relay by itself?” It is “Which review steps become faster or more complete when the assistant is grounded in our approved records, while the existing safety and approval gates remain intact?” Measure review time, missing-evidence rate, rework, citation coverage, and engineer acceptance. Do not publish a percentage saving until the pilot has a defined baseline and repeatable measurement.

A practical evaluation checklist

Ask any vendor, including GridAPM:

• Can I see the exact source record and page behind an AI-generated statement?
• What does the tool do when settings, units, firmware, or channels conflict?
• Which calculations are deterministic, and which are generated language?
• Can the assistant abstain instead of filling a missing value?
• Is the output outside the protection and control path by default?
• Can I export the raw evidence, reviewer changes, and final decision?
• What has been validated on physical hardware, and what remains simulation-only?
• Does the procedure still require calibrated equipment and qualified personnel?

These questions convert an AI demo into an engineering review. They also align with the NIST AI Risk Management Framework’s emphasis on governing, mapping, measuring, and managing risk across a system’s lifecycle.

References

• Elandaloussi, A., et al. (2023). Practical applications of artificial intelligence and machine learning in power system protection and control (IEEE PES Technical Report TP-TR112-PSRC-2023). IEEE. https://doi.org/10.17023/yqdm-wv86
• 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/
• Porawagamage, G., Dharmapala, K., Chaves, J. S., Villegas, D., & Rajapakse, A. (2024). A review of machine learning applications in power system protection and emergency control. Frontiers in Smart Grids, 3, Article 1371153. https://doi.org/10.3389/frsgr.2024.1371153
• Zhang, Q., & Xie, L. (2025). PowerAgent: A road map toward agentic intelligence in power systems. IEEE Power & Energy Magazine, 23(5), 93–101. https://doi.org/10.1109/MPE.2025.3579718
• Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1