Real-Time Contingency Analysis (RTCA)

Foreword

Foreword

This professional reference is one of a series Energy Compliance, Inc. publishes for registered entities and the people who run their compliance programs.

I've spent more than thirty years on every side of the bulk electric system. I've operated control centers as a Reliability Coordinator, Transmission Operator, and Power System Operator. I've audited grid facilities and signed off on findings as a senior compliance auditor. I've worked enforcement matters from inside the regulator's process. For the last several years I've advised registered entities directly through the firm I founded.

The entities that do reliability well share a habit. They take the standards seriously without confusing them with reliability itself. A NERC Reliability Standard is a floor, not a ceiling. Compliance is something an auditor evaluates; reliability is something a system either delivers or doesn't. So these entities prepare for audits by building programs that survive real questions, not binders that look thick.

That's the perspective these references try to share. Each one takes a single topic, whether a standard family, an operational function, a regulatory framework, or an emerging industry problem, and walks through how it actually works.

They're written for the compliance manager who wants to understand the system and not just memorize requirements. For the legal counsel who has to brief a board honestly. For the senior operator who's been told that compliance and reliability are the same thing and suspects they aren't. And for the new compliance hire who got handed a binder and told good luck.

These references aren't marketing material disguised as content. They come from three decades of doing this work and watching it succeed and fail. I've written them in the voice I use in a control room or in front of a Regional Entity audit team: direct, grounded in evidence, and honest about what the standards do and do not require.

Energy Compliance exists because much of the consulting offered to registered entities today is structured for billable hours rather than for outcomes. Every engagement is overseen by a senior practitioner. We don't bring five people to a meeting that needs one. We automate the work that should be automated and apply senior judgment to the work that requires it. If that's what you want in a compliance partner, the back of this reference has our contact information.

If not, the reference still belongs to you. Take what's useful and apply it well. And remember the only test that ultimately matters: when the system needs to perform, does it?

Rob Smith

Founder and Principal, Energy Compliance, Inc.

Executive Summary

Executive Summary

Real-Time Contingency Analysis is the tool that tells the operator what the system is about to do. It runs every few minutes, evaluates the contingencies on its list, and flags the ones that would push the system past its limits. RTCA warns; it does not recommend. Operators who read it well stay ahead of the system. Operators who don't get caught by contingencies the tool already warned about.

• The judgment stays with the operator.
• A solution that looks too clean or too noisy is telling you about model accuracy, not just system condition.
• Reading RTCA under pressure is pattern recognition. An operator who can't recognize the pattern is operating without the tool's value.
• RTCA and SOL/IROL management are intertwined. An IROL exceedance identified in a Real-time Assessment runs against the IROL Tv, which the NERC Glossary caps at 30 minutes.
• When RTCA says something the operator believes is wrong, the operator may well be right. The cases where the operator is wrong are the ones that cost reliability.
• The tool's limitations are real. Operators who treat it as authoritative without knowing its boundaries are trusting it past the point the model can carry.
• The audit asks how RTCA was used. In my view, programs that can document the operator's decisions around RTCA output have the easiest audits.

Chapter 1

What RTCA Actually Is (And What It Isn't)

RTCA is a specific tool with a specific purpose. Mischaracterizing it leads to operating decisions made on the wrong information.

1.1 Where RTCA Sits

Real-Time Contingency Analysis is a software application that runs in a control center's energy management system (EMS). It starts from the state estimator's picture of current conditions. On a cycle each entity configures, usually every few minutes, it simulates the system's response to each contingency on a defined list: the loss of a transmission line, a generator, a transformer, or a defined combination of elements. The output identifies which contingencies, if they occurred right now, would push the system beyond its operating limits.

The standards don't name RTCA, but they lean on it. TOP-001-6 Requirement R13 requires each Transmission Operator to ensure that a Real-time Assessment is performed at least once every 30 minutes, and IRO-008-3 Requirement R4 puts the same obligation on the Reliability Coordinator. The NERC Glossary defines a Real-time Assessment as an evaluation of system conditions using Real-time data to assess existing (pre-Contingency) and potential (post-Contingency) operating conditions. The supplemental material to TOP-010-1(i) lists Real-time Contingency analysis, alongside state estimation and stability analysis, among the types of analysis used in Real-time Assessments. RTCA is how most operators get the post-Contingency half of that picture.

1.2 What RTCA Is

RTCA is a situational-awareness amplifier. It tells the operator that if a specific contingency happens in the next few minutes, the system will respond in a specific way. That lets the operator judge whether the current operating posture has acceptable margin, or whether action is needed to restore margin before a contingency can occur.

1.3 What RTCA Is Not

RTCA is not a decision engine. It does not tell the operator what to do. It does not weigh trade-offs or consider commercial implications. It identifies risks; the operator decides responses. The most common mischaracterization is treating the tool as authoritative, as if its output determines the action. The output informs the action. The operator owns the action.

1.4 It Runs on a Model

RTCA is also not infallible. It runs on a model, and the model is an approximation of the system: good, but not perfect. Model errors propagate into RTCA results, and operators who don't understand the model's limitations make decisions on data that doesn't support them. Using RTCA well includes knowing when to trust the tool and when to question it.

From the Field

If you can't explain an RTCA result without the tool, you don't own the decision the tool is pointing toward.

Chapter 2

The Contingency List: Comprehensive vs. Computable

RTCA's contingency list is finite. It reflects choices about what is worth simulating against the cost of simulation. Knowing what is on the list, and what isn't, matters.

2.1 Finite by Design

RTCA evaluates a defined list of contingencies. The list is large, but it is finite. Every system has more potential contingencies than RTCA can simulate in real time, so the list reflects choices about which ones are most consequential to evaluate.

2.2 Who Decides What Is on It

Those choices are not left to the EMS vendor. FAC-011-4 Requirement R5 requires each Reliability Coordinator to identify in its SOL methodology the set of Contingency events used for Operational Planning Analyses and Real-time Assessments. Part 5.1 sets the floor: the loss of any generator, transmission circuit, transformer, shunt device, or single pole block in a monopolar or bipolar high voltage direct current system, by single phase to ground or three phase Fault (whichever is more severe) with Normal Clearing, or without a Fault. Part 5.2 lets the RC specify additional single or multiple Contingency events. For stability limits, Part 5.3 has the RC describe how it selects among the Contingency events the Planning Coordinator or Transmission Planner provides under FAC-014-3 Requirement R7.

In practice, that means the single-element contingencies on the bulk transmission system, selected multiple-element events where elements cluster together physically or operationally, and defined contingencies on neighboring systems that could affect the operator's footprint. FAC-014-3 Requirement R2 has the TOP establish its SOLs under its RC's SOL methodology, so in my view the TOP's RTCA list should line up with the set that methodology specifies.

2.3 What the List Leaves Out

What the list excludes matters just as much. It may leave out contingencies on lower-voltage facilities, contingencies on neighboring systems beyond defined boundaries, and common-mode failures the methodology does not treat as credible. Each exclusion is a judgment call about likelihood and consequence.

Operators who know what's on the list operate with appropriate confidence in RTCA's coverage. Operators who don't sometimes assume RTCA covers contingencies it doesn't, and they are surprised when an event occurs that wasn't on the list. The audit asks about the list: its completeness, its rationale, its review cadence. Programs with explicit answers fare better than programs whose answer is "RTCA evaluates the standard contingencies."

2.4 Keeping the List Current

The list also has to change as the system changes. New equipment should trigger a list update, and topology changes should trigger a review. Maintaining the list is part of keeping RTCA reliable.

From the Field

What is not on the list matters as much as what is. Operators who know both operate with appropriate confidence. The audit asks about the list. A program that can explain the rationale and the review cadence answers the question in one pass.

Chapter 3

Reading RTCA Output: Pattern Recognition Under Pressure

RTCA produces structured output that has to be interpreted quickly. The interpretation is pattern recognition built through experience.

3.1 Dense Output, Little Time

RTCA output is structured but dense. Each run lists the contingencies that would produce operating limit violations, with the limit, the amount, and the equipment. A quiet run may show a handful of entries. A stressed one can show dozens. The operator has to parse it fast and find the entries that matter most.

3.2 Pattern Recognition Is Built, Not Born

Experienced operators look at RTCA output and recognize at once which entries reflect normal system stress, to be watched, and which reflect actionable risk, to be acted on. That recognition isn't innate. It comes from repeated exposure to the system under varying conditions, from comparing RTCA output with what actually happened, and from mentoring by operators who already have it.

Programs that build it deliberately get stronger operators than programs that leave it to time on the desk. Deliberate development means structured exposure to historical RTCA output, walk-throughs of past events with the RTCA snapshots from the time, and explicit discussion of what the patterns meant. PER-005-2 Requirement R1 already requires each RC, BA, and TOP to use a systematic approach to training its System Operators, built on a list of company-specific Real-time reliability-related tasks. Reading and acting on contingency analysis belongs on that list. The investment pays back in faster, more accurate response when real events occur.

3.3 When the Output Is Implausible

The other half of reading RTCA is knowing when the output is incomplete or wrong. RTCA can produce results that are mathematically valid but operationally implausible: a flagged contingency the operator knows the system would respond to differently than the model predicts. Recognizing those cases, and knowing how to act on them, separates strong operators from those who execute the tool's output mechanically.

From the Field

When RTCA produces output the operator believes is wrong, the operator may well be right. The hard part is knowing when they're not.

Chapter 4

RTCA and SOL/IROL Management

RTCA output feeds directly into SOL and IROL management. An IROL exceedance in a Real-time Assessment runs against a clock that is never longer than 30 minutes.

4.1 The Most Consequential Output

RTCA's most consequential outputs are post-Contingency exceedances of a System Operating Limit (SOL) or an Interconnection Reliability Operating Limit (IROL). What counts as an exceedance is not the operator's call or the vendor's. FAC-011-4 Requirement R6 requires the RC's SOL methodology to include the performance framework used to determine SOL exceedances in Real-time monitoring, Real-time Assessments, and Operational Planning Analyses. Under Part 6.2, for the single Contingencies in Part 5.1, post-Contingency flows must stay within applicable Emergency Ratings and post-Contingency voltages within emergency System Voltage Limits. Requirement R8 has the methodology describe which SOLs are IROLs and when exceeding an SOL qualifies as exceeding an IROL.

4.2 The Clock

Once RTCA identifies an exceedance, the standards start to move:

The NERC Glossary defines IROL Tv as the maximum time an IROL can be violated before the risk to the Interconnection or other Reliability Coordinator Areas becomes greater than acceptable, and it provides that each IROL's Tv shall be less than or equal to 30 minutes. That is the 30-minute clock. The TOP and the RC coordinate, and either the mitigation is implemented or the system is moved to a different operating posture.

4.3 Acting on the Forewarning

This is where RTCA's value is most direct. The tool warns the operator of an IROL exposure that hasn't happened yet. The operator can act on the warning, by switching to a different topology, redispatching generation, or requesting load adjustments, before the contingency occurs. If the action is taken and the contingency never comes, the operator never learns whether the action was necessary. If the action is taken and the contingency comes, the system is in position to ride through. If no action is taken and the contingency comes, the IROL exceedance becomes real and the consequences follow.

4.4 Documenting RTCA-Driven Actions

The audit looks at RTCA-driven actions. Operators should record what RTCA showed, what action was considered, what action was taken, and what the outcome was. The record is the evidence that the operator was reading RTCA and acting on it. The measures say as much: M14 points to dated computer logs showing when the Operating Plan was initiated, and M12 to dated logs showing the date, time, duration, and details of any IROL excursion. In my view, programs that keep this record routinely have clean IROL audits. Programs that don't get asked whether anyone was reading RTCA at all.

From the Field

An IROL exceedance identified in RTCA runs against a Tv of 30 minutes or less. The tool's job is to give you that warning as early as possible. Acting on the forewarning prevents the exceedance; ignoring it means documenting one. The audit looks at the record around RTCA-driven actions. Keep it as you go.

Chapter 5

When RTCA Says Something the Operator Knows Is Wrong

RTCA model errors are real. Operators have to know when to trust the tool and when to question it.

5.1 Where the Errors Come From

RTCA is only as accurate as its model. The model is built from the planning model, updated continuously with topology and equipment status, and run against current Real-time data. Errors enter in several places: incorrect equipment status, stale topology, inaccurate generator parameters, incomplete representation of neighboring systems. When they propagate, RTCA produces results that don't reflect reality.

5.2 Recognizing the Pattern

Experienced operators learn the patterns of RTCA error. A flagged contingency involving equipment the operator knows is already out. A predicted overload on a line the operator knows has already been derated. A contingency severity that doesn't match the operator's mental model of the system's current condition. Signals like these point to model error, not actual risk.

The decision is consequential either way. If the operator dismisses RTCA as wrong and the result was right, the system is exposed. If the operator treats RTCA as authoritative and the result was wrong, the operator may take unnecessary action that creates other problems. This is the judgment the standards rest on. TOP-001-6 Requirement R1 requires each TOP to act to maintain the reliability of its Transmission Operator Area through its own actions or by issuing Operating Instructions, and those actions are only as good as the operator's reading of the analysis in front of them.

5.3 The Lesson from August 14, 2003

The final report of the U.S.-Canada Power System Outage Task Force shows what status errors can do. At about 12:15 EDT on August 14, 2003, MISO's state estimator failed to solve because the out-of-service status of Cinergy's Bloomington-Denois Creek 230-kV line had not been automatically linked to MISO's model. The analyst corrected the status by 13:00 EDT but left the automatic five-minute trigger switched off. When that was found and the trigger re-enabled at about 14:40 EDT, the state estimator failed again, this time because of the Stuart-Atlanta 345-kV line, which had tripped at 14:02 EDT and sat under PJM's reliability umbrella rather than MISO's. The report found that MISO's state estimator and real-time contingency analysis tools were effectively out of service between 12:15 and 16:04 EDT, about two minutes before the cascade began, which prevented MISO from performing its precontingency "early warning" assessments. At FirstEnergy, the report found that the contingency analysis model was likely running but was not consulted at any point that afternoon.

Two different failures: a model that couldn't solve because two line statuses never reached it, made worse by an automatic run left switched off, and a tool that ran without anyone reading it. Both are still the failure modes to design against.

5.4 Model Maintenance Is Reliability Work

Programs support the operator's judgment by making model maintenance a priority. Topology updates should flow through the EMS quickly, equipment status changes should reach the model promptly, and periodic model validation should catch drift before it confuses operations. The standards back this up. TOP-003-7 Requirement R1 requires each TOP to maintain a documented specification for the data it needs to perform its Real-time monitoring and Real-time Assessments. TOP-010-1(i) Requirement R1 requires an Operating Process or Operating Procedure addressing the quality of Real-time data, and Requirement R3 requires one addressing the quality of analysis used in Real-time Assessments, with criteria for evaluating it, provisions for showing it to operators, and actions to address problems. Every improvement in model accuracy means fewer "trust or question" calls under pressure.

From the Field

RTCA model errors are real. Operators who can't recognize their pattern end up acting on a model that has drifted from the system. Model maintenance is reliability work. Programs that defer it accept more judgment calls under pressure.

Chapter 6

Tool Limitations Operators Need to Know

Every RTCA tool has limitations. Knowing them is part of operator training and audit defense.

6.1 Limits to Operate Around

RTCA tools differ across vendors and configurations, but they share limitations operators need to internalize. These aren't flaws to be eliminated. They are characteristics to operate around.

6.2 Five Limitations

Limitation one: solution time

RTCA results reflect conditions at the start of the analysis cycle, not the moment of viewing. By the time the operator reads a result, the system may have moved. In fast-changing conditions, that gap matters.

Limitation two: contingency list scope

Covered in Chapter 2. Contingencies not on the list aren't evaluated.

Limitation three: steady state versus stability

RTCA is typically a steady-state power flow analysis. It catches post-Contingency overloads and voltage violations, but it does not by itself evaluate transient stability, and some tools screen with simplified or linearized methods before solving the worst cases in full. FAC-011-4 recognizes the gap: its stability evaluations can be performed with real-time stability assessments, predetermined stability limits, or other offline analysis techniques. The operator needs to know what their specific tool does and doesn't evaluate, and where the stability answer comes from instead.

Limitation four: convergence behavior

In stressed conditions, RTCA can fail to converge on certain contingencies. A non-converged contingency isn't a "no problem" result. It's a "couldn't evaluate" result, and the operator has to treat it that way. The TOP-010-1(i) supplemental material names solution tolerances, mismatches with Real-time data, and convergence among the criteria an entity may use to evaluate analysis quality.

Limitation five: external system representation

RTCA models neighboring systems with simplified equivalents. When the system is interacting strongly with its neighbors, those equivalents may not represent the relevant behavior accurately.

6.3 Calibrated Confidence

Operators trained explicitly on these limitations operate with calibrated confidence in the tool. Without that training, the errors run both ways: over-reliance, treating its output as authoritative, or under-reliance, dismissing it as unreliable. Both cost reliability.

From the Field

A non-converged contingency isn't a "no problem" result. It's a "couldn't evaluate" result, and the operator has to act on that distinction.

Chapter 7

RTCA in the Audit Conversation

Audits look at how RTCA was used during specific events. Programs that can document RTCA use have cleaner audits.

7.1 What the Auditor Asks

When the Compliance Enforcement Authority audits a Transmission Operator, RTCA use is part of the conversation. Under Section 4.1.1 of Appendix 4C to the NERC Rules of Procedure, the audit notice goes out at least 90 days before the audit and requests documents, data, and information. The audit team can then ask about specific historical events, such as disturbances, IROL exceedances, and abnormal conditions, to understand what RTCA showed at the time, what the operator did about it, and how the action connected to the standard.

7.2 The Contemporaneous Record

Programs that keep operating logs alongside RTCA snapshots answer those questions cleanly. The auditor sees the contingency RTCA flagged, the operator's action recorded at the time, the outcome that followed, and the post-event review. The measures in the standards point the same way: dated computer logs for the 30-minute Real-time Assessment cycle under TOP-001-6 M13, and dated operator logs and checklists as evidence of the analysis-quality procedure under TOP-010-1(i) M3. The conversation moves quickly because the record is complete.

7.3 The Reconstructed Record

Programs without that record have much longer audit conversations. The auditor asks what RTCA showed, and the program tries to reconstruct it from EMS archives. The auditor asks what the operator did, and the program relies on operator memory. The auditor asks what the outcome was, and the program pulls downstream records that may not tie cleanly to the RTCA snapshot. Each gap invites more questions and can widen the scope of the audit.

7.4 Small per Shift, Large over Years

RTCA documentation costs little in any given moment and pays off over time. Capturing the snapshot when an action is taken, recording the action with a reference to the snapshot, and putting both in the operator log adds little to a shift. Across years of shifts, it produces an audit-ready record that other programs have to rebuild after the fact.

From the Field

Audits look at how RTCA was used during specific events. Programs that documented at the time have shorter audits. An RTCA snapshot captured at the moment of action is worth more than the most thorough post-event reconstruction. Documentation is small per shift and large across years. The compounded value shows at audit.

Chapter 8

RTCA's Future as the System Evolves

The system RTCA evaluates is changing. Inverter-based resources, distributed generation, and storage all challenge the tool's assumptions.

8.1 A Tool Built for a Different Fleet

RTCA was designed for a system dominated by synchronous machines, conventional transmission, and predictable load. The system it evaluates today looks increasingly different. Inverter-based resources behave differently from synchronous machines and aren't always represented accurately in RTCA models. Distributed generation adds variability the tool wasn't designed to capture. Storage can swing between charging and discharging within seconds. Large concentrated loads create stress patterns that older assessments didn't anticipate.

8.2 What Changes for the Tool

The result, in my view, is that RTCA output is becoming in some cases a less reliable indicator of actual system risk than it was when the fleet was mostly synchronous. The tool isn't broken. It's working as designed against a system that is changing faster than its assumptions.

The standards are moving too. PRC-029-2, Frequency and Voltage Ride-through Requirements for Inverter-Based Resources, became effective October 1, 2026, replacing PRC-029-1, following FERC approval. PRC-030-1, Unexpected Inverter-Based Resource Event Mitigation, became effective the same day and requires Generator Owners to identify, analyze, and mitigate unexpected changes in IBR power output. Neither standard is about RTCA. But in my view, a contingency tool implicitly assumes that resources not involved in the contingency stay online through it, and ride-through requirements and event mitigation push IBR behavior toward that assumption. Modeling improvements and new tools that handle inverter-based behavior more accurately are working their way through the industry. The transition is likely to take years.

8.3 Operating in the Meantime

In the meantime, operators have to work with what they have. RTCA remains the primary contingency analysis tool. Operators have to compensate for known model limitations with judgment, and programs have to invest in training to build that judgment. It isn't a comfortable steady state, but it's the operating reality, and programs that face it directly do better than programs that pretend RTCA hasn't changed.

From the Field

IBR growth changes what RTCA can reliably tell you. Operator judgment has to cover the gap.

Glossary

Glossary

Cascading. The uncontrolled successive loss of System Elements triggered by an incident at any location, resulting in widespread electric service interruption that cannot be restrained from sequentially spreading beyond an area predetermined by studies.

Compliance Enforcement Authority (CEA). NERC or the Regional Entity, in their respective roles of monitoring and enforcing compliance with the NERC Reliability Standards.

Contingency. The unexpected failure or outage of a system component, such as a generator, transmission line, circuit breaker, switch, or other electrical element.

Contingency list. As used in this reference, the defined set of Contingency events RTCA simulates on each run, drawn from the set the RC's SOL methodology specifies under FAC-011-4 Requirement R5.

Emergency Rating. The rating, as defined by the equipment owner, that specifies the level of electrical loading or output a system, facility, or element can support, produce, or withstand for a finite period.

Interconnection Reliability Operating Limit (IROL). A System Operating Limit that, if violated, could lead to instability, uncontrolled separation, or Cascading outages that adversely impact the reliability of the Bulk Electric System.

Inverter-Based Resource (IBR). A plant or facility of devices that export Real Power through a power electronic interface, such as an inverter or converter, operated together as a single resource at a common point of interconnection. Examples include solar photovoltaic, Type 3 and Type 4 wind, battery energy storage, and fuel cells.

IROL Tv. The maximum time an IROL can be violated before the risk to the Interconnection or other Reliability Coordinator Areas becomes greater than acceptable. Each IROL's Tv shall be less than or equal to 30 minutes.

Operating Plan. A document that identifies a group of activities that may be used to achieve some goal. An Operating Plan may contain Operating Procedures and Operating Processes.

Real-time Assessment (RTA). An evaluation of system conditions using Real-time data to assess existing (pre-Contingency) and potential (post-Contingency) operating conditions.

Real-Time Contingency Analysis (RTCA). As used in this reference, the EMS application that simulates each Contingency on a defined list against the current state-estimated system and reports the resulting limit violations.

State estimator. As used in this reference, the EMS application that combines the network model with Real-time measurements to estimate current voltages and flows, producing the base case RTCA runs from.

System Operating Limit (SOL). All Facility Ratings, System Voltage Limits, and stability limits, applicable to specified System configurations, used in Bulk Electric System operations for monitoring and assessing pre- and post-Contingency operating states.

System Operator. An individual at a Control Center of a Balancing Authority, Transmission Operator, or Reliability Coordinator who operates or directs the operation of the Bulk Electric System in Real-time.

How Energy Compliance Can Help

How Energy Compliance Can Help

RTCA questions land on the operations floor and in the audit room at once.

Audit defense and audit preparation

Your Real-time Assessment and IROL records have to show what RTCA said and what the operator did. EC provides NERC compliance program support, interpretation, and audit preparation; audit and enforcement support (non-advocacy); and audit defense, including Notice of Penalty response and settlement posture. RSAW production and data request strategy for TOP-001, TOP-010, and IRO-009 come from the same senior practitioner.

Senior review of the program you have

A regulator-perspective program review tests whether your contingency list rationale, analysis-quality procedure, and operator logs would survive real audit questions. EC also provides reliability governance and program assessments, operational and engineering reliability alignment, compliance program design and improvement, and mitigation planning and Self-Report development.

Advisory, registration, and training

EC offers NERC reliability and compliance advisory support; senior advisory on complex reliability questions; registration and applicability analysis; training and executive briefings on reliability frameworks; and industry engagement through standards development and working-group participation. Each engagement is scoped to the entity's role, function, and bulk system impact.

WattOps Compliance

The RTCA snapshot, the log entry, and the procedure belong in one evidence trail. WattOps Compliance is EC's NERC compliance evidence platform (wattopscompliance.com). EC will run one standard at one facility through WattOps at no cost (CIP standards excluded).

RenewOps

As IBRs change what RTCA sees, plant-side operations data matters more. RenewOps is EC's renewable operations monitoring and analytics platform, with a Data Center module.

Pick one IROL event from last year. If you can't show an auditor what RTCA said and what the operator did, call us.

Website: energycomplianceinc.com · Email: [email protected]

Phone: 763.438.4427

About the Author

About the Author

Rob Smith is the Founder and Principal of Energy Compliance, Inc., with more than thirty years in the industry on every side of the system. He began in control-room operations as a Reliability Coordinator, Transmission Operator, and Power System Operator across RTO/ISO and utility control centers. On the regulator side, he was a senior compliance auditor and subject matter expert for NERC Reliability Standards. He audited grid facilities, evaluated mitigation adequacy, participated in risk-based oversight of utility mitigation activities, and supported the development of violation notifications and settlements in FERC-directed enforcement actions. He conducted a regulatory audit in the Sultanate of Oman against the Sultanate's Sector Law and Grid Code.

He founded Energy Compliance, Inc. to deliver senior regulator-side compliance authority without the layered staffing and billable-hour overhead of larger firms.

Education:

• MBA, Energy Management, University of Mary
• MSL, Compliance Law, Fordham Law University
• BAS, Energy Management, Bismarck State College
• BAS, Mechanical Engineering, Metallurgy minor, University of Florida
• BAS, Criminology, St. Petersburg College (State Law Enforcement Certification)
• AAS, Power Plant Technology, Bismarck State College
• AAS, Electrical Transmission System Technology, Bismarck State College

Certifications: NERC Lead Auditor training; previously NERC-certified at the Reliability Coordinator level; 1st Class A Boiler Engineer License, Minnesota.

About Energy Compliance, Inc.

About Energy Compliance, Inc.

Energy Compliance, Inc. is an independent consulting and advisory firm based in Bloomington, Minnesota, focused exclusively on electric reliability, cybersecurity reliability, and regulatory compliance for organizations connected to the North American Bulk Electric System.

We support registered entities, including Generator Owners and Operators, Transmission Owners and Operators, Reliability Coordinators, Balancing Authorities, and Distribution Providers. Our work spans NERC Reliability Standards, FERC orders, RTO/ISO market participation rules, Regional Entity oversight, and state regulatory frameworks.

We do this work differently than larger consulting firms. A senior practitioner with regulator-side experience oversees every engagement. We staff for outcomes, not billable hours. Our deliverables are written to be operationally executable and audit-defensible, structured for the auditor's question rather than the consultant's binder. Where automation can replace manual work, we build the automation. Where senior judgment is required, the senior is in the room.

Energy Compliance is not affiliated with, sponsored by, or endorsed by the North American Electric Reliability Corporation, the Federal Energy Regulatory Commission, or any Regional Entity.

Learn more at energycomplianceinc.com.

Sources and Authorities

Sources and Authorities

• North American Electric Reliability Corporation, Glossary of Terms Used in NERC Reliability Standards (Cascading, Contingency, Emergency Rating, Interconnection Reliability Operating Limit, IROL Tv, Inverter-Based Resource, Operating Plan, Real-time Assessment, System Operating Limit, System Operator). https://www.nerc.com/glossary-of-terms
• North American Electric Reliability Corporation, Reliability Standard TOP-001-6, Transmission Operations (effective April 1, 2024), Requirements R1 and R12 through R15 and Measures M12 through M14. https://www.nerc.com/globalassets/standards/reliability-standards/top/top-001-6.pdf
• North American Electric Reliability Corporation, Reliability Standard TOP-003-7, Transmission Operator and Balancing Authority Data and Information Specification and Collection (effective October 1, 2026), Requirement R1. https://www.nerc.com/globalassets/standards/reliability-standards/top/top-003-7.pdf
• North American Electric Reliability Corporation, Reliability Standard TOP-010-1(i), Real-time Reliability Monitoring and Analysis Capabilities (effective April 1, 2018), Requirements R1 and R3, Measure M3, and Supplemental Material. https://www.nerc.com/globalassets/standards/reliability-standards/top/top-010-1i.pdf
• North American Electric Reliability Corporation, Reliability Standard IRO-008-3, Reliability Coordinator Operational Analyses and Real-time Assessments (effective April 1, 2024), Requirement R4. https://www.nerc.com/globalassets/standards/reliability-standards/iro/iro-008-3.pdf
• North American Electric Reliability Corporation, Reliability Standard IRO-009-2, Reliability Coordinator Actions to Operate Within IROLs (effective January 1, 2016), Requirements R2 and R3. https://www.nerc.com/globalassets/standards/reliability-standards/iro/iro-009-2.pdf
• North American Electric Reliability Corporation, Reliability Standard FAC-011-4, System Operating Limits Methodology for the Operations Horizon (effective April 1, 2024), Requirements R5 through R8. https://www.nerc.com/globalassets/standards/reliability-standards/fac/fac-011-4.pdf
• North American Electric Reliability Corporation, Reliability Standard FAC-014-3, Establish and Communicate System Operating Limits (effective April 1, 2024), Requirements R2 and R7. https://www.nerc.com/globalassets/standards/reliability-standards/fac/fac-014-3.pdf
• North American Electric Reliability Corporation, Reliability Standard PER-005-2, Operations Personnel Training (effective July 1, 2016), Requirement R1. https://www.nerc.com/globalassets/standards/reliability-standards/per/per-005-2.pdf
• North American Electric Reliability Corporation, Reliability Standard PRC-029-2, Frequency and Voltage Ride-through Requirements for Inverter-Based Resources (effective October 1, 2026, following FERC approval). https://www.nerc.com/globalassets/standards/reliability-standards/prc/prc-029-2.pdf
• North American Electric Reliability Corporation, Reliability Standard PRC-030-1, Unexpected Inverter-Based Resource Event Mitigation (effective October 1, 2026), Purpose and Applicability. https://www.nerc.com/pa/Stand/Reliability%20Standards/PRC-030-1.pdf
• North American Electric Reliability Corporation, Rules of Procedure, Appendix 4C, Compliance Monitoring and Enforcement Program (effective May 19, 2022), Section 4.1.1, Compliance Audit Process. https://www.nerc.com/globalassets/who-we-are/rules-of-procedure/appendix-4c.pdf
• North American Electric Reliability Corporation, Rules of Procedure, Appendix 2, Definitions Used in the Rules of Procedure (effective June 27, 2024), Compliance Enforcement Authority. https://www.nerc.com/globalassets/who-we-are/rules-of-procedure/appendix-2.pdf
• U.S.-Canada Power System Outage Task Force, Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations (April 2004), Chapter 5, pages 47 through 49 and endnote 7. https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/BlackoutFinal-Web.pdf