Automating Protection System Monitoring and Verification With the SELRTAC

A Practical Framework for Continuous NERC PRC-005 Compliance, Predictive Maintenance Alarming, and Automated Reporting

The Silent Sentinel Problem

Protection relays are unusual assets. Unlike a transformer that hums under load every hour of every day, a generator or transmission protection relay may sit armed for months — sometimes years — before it is ever called upon to operate. When that moment finally arrives, the relay must trip correctly, instantly, and in coordination with every other device in the scheme. There is no second chance. A failed CT circuit, a drifted setting, a degraded communications channel, or a quietly failing power supply can remain completely invisible until the exact moment the system needs the relay most, and the result is either a failure to operate or a false operation — both of which can cascade into equipment damage, extended outages, and NERC misoperation reporting.

This is the fundamental weakness of purely time-based maintenance: it verifies the protection system only at discrete points on the calendar. Everything that happens between test intervals is an act of faith. The industry answer to this problem — and the foundation of the performance-based options within NERC PRC-005 — is continuous, automated monitoring of protection system components using the self-test intelligence and communications capability already built into modern microprocessor relays and intelligent electronic devices (IEDs).

In this article, we walk through a practical, field-proven architecture for building that automated monitoring layer using the SEL Real-Time Automation Controller (RTAC) as the central data concentrator, logic engine, and reporting platform. We cover the six functional pillars of an automated protection monitoring program: settings and firmware verification, continuous CT/PT validation, protection channel integrity monitoring, IED hardware diagnostics, automated report generation, and durable maintenance-condition logging.

Keentel Insight

PRC-005 defines the protection system broadly: protective relays, associated communications systems,voltage- and current-sensing devices and their circuits, dc control circuitry, and station dc supplies. An automated monitoring program that only watches relay self-test bits covers a fraction of that scope.The architecture described here is designed to reach across the full definition — including the instrument transformer circuits and communications channels that manual programs routinely under-test.

Why Automate? Compliance Is the Floor, Not the Ceiling

NERC, under FERC oversight, requires registered entities to maintain a documented protection system maintenance program with activities executed on time-based intervals, performance-based intervals, or a combination of the two. Meeting that obligation with clipboards and spreadsheets is possible — but it is slow, error-prone, and audit preparation becomes an archaeology project. Automation changes the economics entirely. When IEDs are continuously interrogated and every anomaly is timestamped and logged, three things happen at once:

• Awareness: Failed or degrading components that would otherwise go unnoticed between maintenance intervals are surfaced in near real time, dramatically improving protection system awareness.
• Documentation: Every monitored component generates a continuous evidentiary record that directly supports maintenance and validation testing documentation requirements — the daily report itself becomes audit evidence.
• Baselining: The behavior of power system components is captured during both fault events and steady-state operation, giving engineers baseline data that makes abnormal behavior obvious.

Beyond the compliance case, predictive alarming on critical assets is simply good asset management. Catching a failing CT circuit or a chattering communications channel weeks before it causes a misoperation keeps generation online, protects capital equipment, and avoids the reputational and regulatory cost of a reportable event.

The RTAC as the Monitoring Backbone

The SEL RTAC is a substation-hardened data concentrator and communications gateway with an integrated IEC 61131 programming environment. That combination is exactly what an automated monitoring program needs: the RTAC already speaks to every IED in the station over its native protocols, it already polls measurements and status points on user-defined intervals, and its logic engine can process those points continuously against user-specified limits. In other words, the monitoring system rides on infrastructure most substations already own.



SEL extends the RTAC's native capability with the ACSELERATOR RTAC SEL-5033 library extensions — downloadable libraries that plug into the IEC 61131-3 environment. Two libraries do the heavy lifting for protection monitoring: the ChannelMonitoring library, which provides purpose-built function blocks for comparing analog channels and supervising status indicators, and the FileIO library (a paid option requiring the correct model option table), which provides file-management classes for writing structured reports to the RTAC file system. Each library installs with its own instruction manual, accessible directly from the RTAC help menu.

Programs can be written in Continuous Function Chart (CFC) for engineers who prefer graphical logic, or in Structured Text (ST) for those who prefer code. The function blocks output Boolean alerts alongside enumerated status values, and helper functions convert those enumerations to human-readable strings for logging — a small detail that pays off enormously when reports are reviewed months later.

Pillar 1: Verifying Commissioned Settings and Firmware.

The first question any protection monitoring program must answer is deceptively simple: is the relay still configured the way we commissioned it? Settings drift is real — a technician's temporary change that never got reverted, a firmware update that altered default behavior, an unauthorized modification. Under a manual program, these discrepancies hide until the next scheduled settings review.

The Configuration Monitor feature in SEL clients solves this elegantly. The RTAC periodically sends ASCII commands to each SEL IED — by default, commands that retrieve the relay ID information and the settings configuration — and computes a 32-bit cyclic redundancy check (CRC) over each valid response. That CRC is stored as the baseline. On every subsequent poll, the freshly computed CRC is compared against the stored value. A mismatch pulses a dedicated mismatch pin in the logic, flagging that something in the relay's configuration has changed; a response that cannot be validated pulses a separate error pin.

Engineers can tune the monitoring interval, retry behavior, and access level, and can add additional ASCII commands to widen the verification scope — subject to confirming command support in the specific relay firmware.

Two practical field notes: the Configuration Monitor ships disabled and must be explicitly enabled in the logic pin settings, and software flow control on serial channels can interfere with the monitor — disabling Xon/Xoff flow control in the communications settings resolves it. These are exactly the kinds of details that separate a monitoring system that works in the lab from one that works in the field.

Keentel Insight

Treat the settings CRC baseline as a controlled configuration item. When an authorized settings change is made, re-baseline deliberately and record the event in your change-management log. A mismatch alarm should always mean one of two things: an undocumented change (a compliance finding waiting to happen) or a relay malfunction. Either way, it deserves immediate investigation.

Pillar 2: Continuous CT and PT Verification

Instrument transformer circuits are among the hardest protection system components to verify. A shorted CT winding, a corroded terminal block, an open test switch, a failing analog-to-digital converter — any of these can silently corrupt the current or voltage picture the relay depends on. Traditional verification requires an outage and a test set.

The ChannelMonitoring library provides two function blocks purpose-built for this task. Both alert on test failure — meaning either a sustained divergence between compared inputs or repeated short divergences (chatter) — and both track the quality of the input data itself, so a communications dropout is distinguishable from a genuine measurement problem.

Cross-Comparison Within One IED

Where a relay has two current terminals wired to independent CTs — the classic example being the high side and load side of a breaker — the multi-channel alert function block compares the phase measurements from the two CT sets against each other. Under normal through-current conditions, the two measurement sets should agree closely. A sustained excursion beyond a user-defined threshold, held for a user-defined time, indicates a developing problem in one of the CT circuits or the relay's measuring chain. Monitoring is typically supervised so it only runs when there is enough signal to compare meaningfully — for example, enabling comparison only when measured power exceeds five percent of nominal, which prevents nuisance alarms at light load.

Cross-Comparison Across Multiple IEDs

The single-channel alert function block generalizes the idea across the substation: a common phase measurement is gathered from several IEDs whose CTs see related current, and each is compared against a chosen reference IED. Because the comparison exercises the entire measurement chain CT, secondary wiring, relay input, and analog-to-digital conversion a persistent deviation on one device localizes the problem quickly. Supervising the comparison with the reference measurement's quality flag ensures the scheme only evaluates when the reference data is valid.

One implementation detail worth understanding: SEL protocol returns many analog values as complex measured values carrying both magnitude and angle, while the comparison blocks consume simple measured values. A small conversion function that maps the magnitude, quality, and timestamp fields bridges the two data types a few lines of Structured Text that get reused across every monitoring program in the fleet.

Pillar 3: Protection Channel Integrity

Communications-assisted protection schemes — permissive transfer trip, direct transfer trip, line current differential — are only as reliable as the channel underneath them. A channel that drops messages intermittently may still pass a monthly loopback test while degrading the security and dependability of the scheme every day in between. Continuous channel supervision closes that gap and provides early warning of conditions that could culminate in a misoperation.



For serial MIRRORED BITS channels, the RTAC's built-in communications diagnostics expose an instantaneous receive-health indicator that deasserts the moment any of several transmission error types is detected, or whenever an expected message fails to arrive within the time needed to transmit three messages. Supervising that indicator with an indicator-alert function block — inverted, since the block detects assertion while the failure condition is a deassertion — yields a channel monitor that distinguishes between an occasional hiccup and a genuinely sick channel. The block's chatter counting catches channels that fail repeatedly for short periods, while its excursion timing catches sustained outages. Tying the monitor's enable to the communications instance's own enable status prevents false alarms when the channel is intentionally out of service.

Pillar 4: IED Hardware Diagnostics

Every SEL IED continuously self-tests its major internal components — power supplies, memory, analog measurement circuitry, and more. When a self-test finds a parameter out of tolerance but not yet compromising protection, the relay raises a warning alarm and pulses a contact. When the condition is severe, the relay declares a failure, and critically, enters a protection-disabled state. A relay sitting in failure is a protection hole in the system, and the clock on finding it should be measured in minutes, not maintenance cycles.



The hardware alarm Relay Word bit consolidates this self-test status into a single monitorable point. Polling that bit from the RTAC and supervising it with an indicator-alert function block — enabled only while the IED is online and responding to polls, so an offline device does not masquerade as a hardware failure — provides continuous assurance that every relay in the station is healthy. The chatter capability adds nuance: repeated warnings over a window indicate a developing out-of-tolerance condition worth scheduling maintenance for, while a sustained assertion demands immediate response. Many SEL IEDs expose additional configurable alert points beyond the consolidated hardware alarm, and the same supervision pattern extends to them directly.

Pillar 5: Automated Daily Reporting

Monitoring without reporting is just data. The reporting layer is what converts continuous monitoring into compliance evidence and actionable maintenance intelligence. Using the FileIO library's log directory manager class, the RTAC can generate a structured maintenance report on a user-defined interval daily being the natural cadence and manage the report archive automatically with configurable folder size limits, file counts, and naming conventions.

The report logic follows four simple steps: track the time elapsed since the last report, convert each function block's outputs into human-readable strings using the library's enumeration-to-string helpers, assemble formatted message blocks for every monitored component, and trigger the write. The resulting daily report consolidates in one document the status of relay configurations, instrument transformer circuits and their associated measuring chains, protection communications channels, and relay hardware alarms. Reports are downloadable on demand through the RTAC's web interface or pushed automatically to a centralized server over FTP, which is how fleet-scale programs aggregate station-level reports into an enterprise compliance archive.

Pillar 6: Durable Maintenance-Condition Logging

Reports summarize; logs prove. Every detected maintenance condition should also land in the RTAC's Sequence of Events (SOE) record, which provides nonvolatile storage for up to 30,000 log items. SOE data is accessible through the web interface or an ODBC connection, and can be streamed via Syslog protocol to a central syslog server for long-term archiving. For organizations not ready to purchase the FileIO library, SOE-plus-Syslog is a capable standalone mechanism for preserving maintenance alert history — and for organizations running the full reporting stack, it is the redundant evidentiary layer that makes the audit trail bulletproof.

Putting It Together: Program Design Considerations

The function blocks are the easy part. In our experience, the difference between a monitoring program that earns its keep and one that generates alarm fatigue comes down to engineering judgment in five areas:

Threshold engineering

Excursion thresholds and time delays must reflect the actual measurement uncertainty of each comparison — CT accuracy class, relay metering accuracy, and normal load asymmetry all belong in the threshold calculation.

Supervision logic

Every monitor needs an enable condition that answers the question: under what system conditions is this comparison meaningful? Light-load cutoffs, quality supervision, and offline supervision eliminate the majority of nuisance alarms.

Tag architecture

Alert outputs, statuses, and quality indicators should be mapped to a consistent tag structure across every station in the fleet, so reports read identically everywhere and enterprise aggregation is trivial.

Change management

The monitoring system itself is a change-controlled asset. Settings baselines, threshold revisions, and logic versions belong under the same configuration management discipline as relay settings.

Operational ownership. Reports only create value if someone owns the review. Define who reads the daily report, what constitutes an actionable finding, and how findings feed the maintenance work order system.

Keentel Insight

Start with the monitors that protect against your highest-consequence failure modes: hardware alarms on every relay, channel monitoring on every communications-assisted scheme, and configuration monitoring fleet-wide. CT/PT cross-comparison delivers enormous value but requires the most careful threshold engineering phase it in once the foundational monitors are stable and trusted.

How Keentel Engineering Helps

Keentel Engineering designs, programs, commissions, and documents automated protection system monitoring programs end to end — from PRC-005 program architecture and monitoring scope definition, through RTAC logic development in CFC and Structured Text, threshold and supervision engineering, report and SOE archiving design, and integration with enterprise compliance documentation systems. Our team combines licensed professional engineering oversight with hands-on RTAC, relay, and communications expertise across generation, transmission, and utility-scale renewable facilities. Whether you are building a monitoring program from scratch, expanding coverage under a performance-based maintenance strategy, or preparing for an audit, we deliver systems that are defensible, maintainable, and genuinely useful to your operations team.

Conclusion

Protection relays are silent sentinels — and silence is precisely the problem. A relay that has not operated in years tells you nothing about whether it will operate correctly tomorrow. By pairing the RTAC's data concentration and IEC 61131 logic capabilities with purpose-built monitoring libraries, engineers can continuously verify relay configurations, instrument transformer circuits, protection communications channels, and relay hardware health; document every status in automated daily reports; and preserve every maintenance condition in durable, archivable logs. The result is a protection system that reports on its own readiness every single day — turning compliance from a periodic scramble into a continuous byproduct of good engineering.

Case Study 1: Automated PRC-005 Monitoring for a Multi-Unit Generating Facility

All client, project, and location identifiers have been withheld to protect confidentiality.

Background

A generation owner operating a multi-unit facility connected to the bulk electric system maintained its protection system under a traditional time-based PRC-005 program. The facility's protection fleet included several dozen microprocessor relays covering generator, transformer, and interconnection protection, with an existing RTAC serving as the station data concentrator and SCADA gateway. Maintenance verification was performed manually at scheduled intervals, and compliance documentation was assembled from technician test records spread across multiple systems.

Challenge

Two events drove the owner to seek a better approach. First, an internal review discovered that a relay settings change made during a troubleshooting session had never been reverted or documented — the discrepancy had persisted undetected for months and was found only by chance during an unrelated review. Second, audit preparation for the compliance program consumed weeks of engineering time reconstructing evidence from disparate records. The owner needed continuous assurance that relay configurations matched the commissioned baseline, early warning of instrument transformer and measuring-chain problems on critical breakers, and audit-ready documentation generated automatically rather than assembled retroactively.

Keentel's Solution

Keentel Engineering designed and implemented an automated protection monitoring program on the facility's existing RTAC, structured around four monitoring layers:

• Settings and firmware verification. Configuration monitoring was enabled across the SEL relay fleet, with the RTAC periodically retrieving relay identification and settings information, computing CRC baselines, and alarming on any mismatch or invalid response. Command sets were verified against each relay's firmware documentation, and serial flow-control conflicts identified during testing were resolved.
• Dual-CT cross-comparison. On critical breakers where relays measured independent CT sets on the high and load sides, multi-channel comparison logic was deployed to continuously cross-check phase measurements. Comparison was supervised to enable only above a minimum loading threshold, with excursion thresholds engineered from CT accuracy class and relay metering tolerance.
• Fleet measurement validation. Phase measurements from multiple relays across the station were compared against a designated reference device, supervised by reference data quality, to validate CT circuits and relay analog-to-digital conversion chains without outages.
• Automated reporting and logging. A daily maintenance report was implemented using the RTAC's file-management library, consolidating the monitoring-enabled state, alert state, status, and data quality of every monitored component into a single archived document, with automated transfer to the owner's central compliance server and parallel logging of all maintenance conditions to the Sequence of Events record.
  

All logic was delivered in documented Continuous Function Chart programs with a standardized virtual tag architecture, factory-tested against simulated deviation scenarios, and commissioned with the owner's protection staff. The engineering package was sealed under professional engineering oversight and included a monitoring program basis document mapping each monitor to the corresponding maintenance program element.

Results

Why It Matters

The settings discrepancy that once hid for months would now surface in a single monitoring cycle. Continuous verification converted the owner’s compliance posture from periodic reconstruction to standing evidence and caught a real CT circuit problem before it could affect protection performance.

Case Study 2: Protection Channel and Relay Health Monitoring for a Transmission Owner

All client, project, and location identifiers have been withheld to protect confidentiality.

Background

A transmission owner operated multiple high-voltage substations employing communications-assisted protection schemes over serial MIRRORED BITS channels between line terminals. The owner's protection group had experienced an intermittent channel problem that degraded a pilot scheme for an extended period before being identified — the channel passed its periodic tests, but message errors were occurring between test intervals. Separately, the owner had no continuous visibility into relay hardware self-test status across its fleet; a relay entering a protection-disabled failure state would be discovered only through SCADA alarm review or a site visit.

Challenge

The owner required continuous, quantitative visibility into protection channel health at every terminal, immediate awareness of any relay hardware warning or failure condition fleet-wide, and a durable, centralized record of every maintenance condition suitable for both engineering trend analysis and compliance evidence — all deployable across multiple stations with consistent behavior and without adding hardware.

Keentel's Solution

Keentel Engineering developed a templated monitoring package deployed to the RTAC at each station:

Channel integrity monitoring

For every MIRRORED BITS instance, logic supervises the built-in instantaneous receive-health diagnostic — which deasserts on any detected transmission error or on failure to receive a message within the time required to transmit three messages. Indicator-alert supervision with chatter counting distinguishes intermittently degraded channels from sustained outages, and each monitor's enable is tied to the communications instance's own enabled status to suppress alarms during intentional channel outages.

Fleet hardware health monitoring

The consolidated hardware alarm bit on every SEL relay is polled continuously and supervised by indicator-alert logic enabled only while the device is online and responding — ensuring an offline device is reported as a communications condition, not misreported as a hardware failure. Chatter detection surfaces repeated warnings indicative of developing out-of-tolerance conditions; sustained assertion escalates immediately.

Centralized condition logging

Every detected maintenance condition is written to the RTAC Sequence of Events record — nonvolatile storage supporting up to 30,000 entries per device — and streamed via Syslog protocol to the owner's central log server, creating a fleet-wide, timestamped maintenance history without requiring additional report licensing at every station. Stations with file-management licensing additionally generate consolidated daily reports transferred by FTP to the compliance archive.

The package was engineered once, documented as a deployment standard with a fixed tag architecture and setting philosophy, and rolled out station by station — each deployment consisting primarily of configuration and site acceptance testing rather than new logic development.

Results

Why It Matters

The intermittent channel problem that once evaded periodic testing was exactly the failure mode continuous chatter supervision is built to catch. Fleet-wide hardware monitoring turned relay failure discovery from a matter of luck into a matter of minutes closing protection holes before the power system could find them first.

About Keentel Engineering

Keentel Engineering LLC is a power systems and grid interconnection consulting firm headquartered in Tampa, Florida, with offices in Austin, Sacramento, and Baltimore. Our services span point-of-interconnection and grid interconnection engineering, power system studies across EHV, HV, and MV networks, substation and transmission design, EMT modeling, utility-scale renewable and battery energy storage engineering, NERC compliance, owner's engineer services, and MEP engineering. Deliverables are produced under licensed professional engineering oversight (FL Firm Reg. No. 36853).

Contact

Keentel Engineering LLC

400 N Ashley Dr STE 2600, Tampa, FL 33602

contact@keentelengineering.com | 813-389-7871 | keentelengineering.com

Disclaimer: Keentel Engineering LLC is an independent consulting firm and is not affiliated with, endorsed by, or sponsored by Schweitzer Engineering Laboratories, Inc., NERC, FERC, or any other organization referenced in this document. All product names, trademarks, and registered trademarks are the property of their respective owners and are used for identification purposes only. This document is provided for general informational purposes and does not constitute engineering advice for any specific facility; application of the concepts described herein should be performed under the direction of a licensed professional engineer familiar with the specific installation.

Frequently Asked Questions

Common questions we receive from asset owners, plant engineers, and compliance managers about automated protection system monitoring with the SEL RTAC.