Automating NERC GADS Reporting: From Spreadsheets to Source-Cited EFOR/EAF

Every quarter, performance engineers across North America pull the same fire drill: reconciling outage logs, megawatt readings, and operator narratives into the NERC Generating Availability Data System format before the submittal window closes. For a fleet of even a dozen units, that is thousands of hours of derate calculations and cause-code assignments, most of it done in spreadsheets that no two plants build the same way.

The problem is not that engineers do not understand the standard. It is that GADS demands a level of bookkeeping discipline that ad hoc tooling cannot enforce, and the metrics it produces feed directly into capacity accreditation, insurance, and executive scorecards. A small classification error quietly compounds into a wrong EFOR.

Event Records Versus Performance Records

GADS splits the world in two. Performance records capture monthly energy accounting: net actual generation, net maximum capacity, service hours, and the period totals that roll up into availability factors. Event records capture every departure from full availability: forced outages, maintenance outages, planned outages, and the full menu of deratings.

The two have to tie out. If your event records claim a unit was in a U1 forced outage for 48 hours, your performance record service hours for that month must reflect it. When these are maintained in separate workbooks by different people, they drift, and the drift is exactly what an audit finds.

• Performance records: period hours, NAG, NMC, service hours, reserve shutdown hours
• Event records: start and end timestamps, event type (U1, U2, U3, MO, PO, D1 to D4), and the magnitude of any derate
• Cross-checks: event hours must reconcile against available and unavailable hours in the performance record

Cause Codes Are Where Accuracy Goes to Die

Each event needs a cause code identifying the failed component down to the system and subcomponent level, plus the primary and contributing equipment. The code set runs to hundreds of entries: boiler tube leaks, exciter faults, main transformer issues, condenser problems, and on and on. Operators under pressure during an actual trip reach for whatever code is closest and move on.

Those imprecise codes degrade the dataset that drives root-cause analysis and reliability benchmarking. If half your forced outages are coded to a generic miscellaneous bucket, your EFOR is technically correct but analytically useless, and you cannot defend a single number against the NERC benchmark for your unit class.

A defensible EFOR is not just a number that is right. It is a number where every contributing event traces back to a timestamp, a meter reading, and a cause code you can stand behind in an audit.

Why Manual GADS Breaks at Scale

The equivalent forced outage rate is, in plain terms, the share of demanded hours that the unit could not deliver due to forced events. The math is unforgiving: forced outage and forced derate hours over the sum of service hours and forced outage hours, weighted by capacity for partial events. Get the derate magnitude wrong on a few summer-peak events and your EFOR moves enough to change a capacity payment.

Manual processes fail in predictable ways: copy-paste errors between the DCS historian and the workbook, timezone mismatches on event boundaries that span midnight, double-counting overlapping derates, and the institutional knowledge that walks out the door when the engineer who built the spreadsheet retires.

The fix is to treat GADS as a data pipeline, not a document. Pull service hours and net generation straight from the historian and revenue meters, pull event boundaries from the outage management system, and compute EFOR and EAF with the formulas encoded once and applied consistently. Every figure in the submittal should link back to its source row so a reviewer can click from the rolled-up rate down to the raw reading.

This is the kind of internal tool that used to require a year of IT backlog. With a no-code AI app builder like DOTA, a performance engineer can wire the historian, the OMS, and the meter data into one app, encode the cause-code logic and the EAF and EFOR formulas, and generate a source-cited quarterly submittal that flags reconciliation breaks before they reach NERC, without writing the integration code by hand.