One Fault, Five Codes: Fix Your Fault Data Before You File NERC GADS
NERC GADS asks a simple question about every outage: why was the plant down? On a mixed-manufacturer fleet, the inverters answer in different languages. The same DC overvoltage arrives as a different number, name and level of detail from each brand, and a large share of what inverters report is not a fault at all. Mapping those raw codes straight to NERC cause codes produces inconsistent filings and phantom outages. The more reliable order is to normalise first — translate every manufacturer's code into one manufacturer-neutral fault type and decide whether it is a fault — then classify with context. Ellume Bridge detects outages from inverter state and fault codes, proposes ranked cause codes with its reasoning, and leaves the final decision to your reviewer.
A NERC GADS submission is only as consistent as the data underneath it. Outage hours come from when equipment stopped producing. Cause codes come from why. And on most solar fleets, the first evidence of why is a fault code reported by the inverter itself. That evidence was never designed for regulators. Each manufacturer writes its own fault codes, for its own service engineers, in its own vocabulary. Put three brands on one fleet and the same physical event can arrive as three unrelated messages — and a compliance team has to turn all of them into one consistent answer.
NERC asks why the plant was down. Your inverters answer in five different languages.
Who this matters to
Compliance teams filing NERC GADS for solar, asset managers running fleets with more than one inverter brand, and O&M teams whose fault logs end up as the evidence behind a regulatory submission.
The same fault, described five ways
Manufacturers differ in almost every dimension that matters. Code numbers are unrelated across brands. Names vary from terse to descriptive. Granularity differs: one brand reports a single string fault code, another reports a separate code for each string. Some prefix codes by type, so the same number means a fault in one context and a warning in another. And firmware updates can change what a code means on the same model.
| What physically happened | How different inverters may report it (illustrative) | What the filing needs |
|---|---|---|
| DC input voltage too high | “PV Voltage High”, “DC overvoltage”, a bare numeric code | One equipment or design cause, consistently coded |
| Grid voltage out of range | “Grid fault”, “AC voltage out of range”, “No AC connection” | Whether the cause was inside or outside the plant |
| One string failed | One string-fault code, or one of dozens of per-string codes | One fault type, with the string as detail |
| Morning start-up, low sun | “Waiting”, “Insufficient DC power” | Not an outage at all |
| Firmware update finished | “Update completed”, “Parameter upload complete” | Not an outage at all |
Not everything an inverter reports is a fault
Inverter event logs mix genuine faults with status messages, configuration changes, communication events and routine start-up conditions. A message that the clock was adjusted or an update completed is useful to a service engineer and meaningless to a regulator. Force every code into a NERC cause code and these messages turn into phantom outages that inflate forced outage hours. Even among real trips, the distinction matters. An inverter that disconnects because grid voltage left its permitted band behaved correctly; the cause sits outside the plant. An inverter that trips because a component failed is an equipment fault. A plant waiting for enough sunlight to start is a resource condition. Each leads to a different answer in GADS, and the raw code alone rarely says which.
Why mapping straight to NERC codes breaks down
The direct approach — a table from each manufacturer code to a NERC cause code — looks simple and scales badly. Every model needs its own table. Each table mixes two separate questions: what does this code mean, and how should NERC see it? And some codes cannot be mapped without context at all. A “No AC connection” code can be a failed AC cable or a breaker someone opened on purpose; the telemetry looks the same, and the filing is different.
Normalise first, then classify
- •Step one: one language for every brand. Translate every manufacturer code into a single manufacturer-neutral fault type — DC overvoltage, grid disconnection, string fault, communication loss — and give it a class: equipment fault, protection trip, grid event, resource condition or informational. Status messages are filtered out here, by design. This step is done once per inverter model, and the result is the same vocabulary for the whole fleet.
- •Step two: classify with context. With a consistent fault type in hand, assign the NERC cause code and event type using the context the code cannot carry: weather at that hour, grid conditions, fault history, concurrent events and what the operations team knows. This step is regulation-specific; the first is not.
Separating the steps means each inverter model is translated once, non-faults never reach the filing, the same fault is classified the same way on every brand, and the reasoning for each cause code is visible to an auditor.
One grid event, three brands: an illustrative case
Numbers illustrative. A voltage disturbance on the utility side trips 60 inverters across a three-brand fleet for 40 minutes. Brand A logs a grid voltage fault, brand B logs “No AC connection”, and brand C logs a numeric code its manual describes as an AC protection trip. In the same hour, brand C also writes several hundred status messages from a scheduled firmware update. Mapped code by code, the event becomes three different cause codes for one disturbance, and the firmware messages risk appearing as outages of their own. Normalised first, it is one grid event across 60 inverters, the firmware messages are recognised as informational, and a single cause is proposed with the grid record as supporting evidence — ready for a reviewer to confirm.
Where Ellume Bridge fits
- •Deterministic detection and arithmetic. Bridge identifies outages from inverter state and fault codes, and computes hours, energy lost, availability and Appendix L factors by arithmetic. AI never produces a number that gets filed.
- •Fault codes mapped per model. During onboarding, Bridge reads each inverter model's fault code documentation and maps its codes, with a person reviewing the mapping, so a new brand on the fleet is handled once rather than event by event.
- •Ranked cause codes, with reasons. For each event, Bridge gathers weather at that hour and either side of it, grid disturbance records, recent fault history and concurrent events, and proposes ranked cause code candidates with the reasoning behind each. When the telemetry cannot settle the question, it lists the ambiguity and asks rather than guessing.
- •Your reviewer decides. The reviewer chooses the cause code that is filed. Once approved or overridden, the record is locked, and every decision is kept with who made it, when and why.
Questions to ask before your next filing
How many inverter brands and models are on the fleet, and does each have a reviewed code mapping? Are status and informational messages filtered out before outage hours are counted? Is the same physical fault coded the same way on every brand? And when a cause code is challenged, can you show the evidence and reasoning behind it?
Frequently asked questions
- Why can’t inverter fault codes be used directly as NERC cause codes?
- Because they answer a different question in a different vocabulary. Manufacturer codes describe what the inverter detected; NERC cause codes describe why the unit was unavailable. The same code can have more than one valid cause, and many codes are not faults at all.
- What is fault code normalisation?
- Translating each manufacturer's fault codes into one shared, manufacturer-neutral set of fault types, and deciding for each whether it is a fault, a protection trip, a grid event, a resource condition or information only.
- Do inverter status messages count as outages?
- No. Messages such as completed updates, clock adjustments or start-up waiting states describe normal operation. Counting them as faults inflates forced outage hours.
- Does Ellume Bridge choose the cause code automatically?
- No. Bridge proposes ranked candidates with its reasoning and flags ambiguity. A reviewer chooses the cause code that is filed, and every decision is recorded.
