Every Outage Needs a Reason: How Your Best Engineer Would Explain It
Every outage in a NERC GADS filing needs a cause, an event type and a narrative that will stand up later. The inverter's fault code is where the investigation starts, not where it ends: the same code can come from a failed cable, a breaker opened for maintenance, a grid disturbance or a lightning strike, and each is filed differently. A good engineer settles it by reading the whole picture — what the equipment reported, what the weather was doing, whether it has happened before, whether neighbouring equipment dropped too, and whether output faded or cut off — and by asking when the data cannot answer. Ellume Bridge works the same way, for every outage in the quarter, and leaves the final call to your engineer.
At quarter close, a compliance team faces a list: a tracker row that stalled at dawn, an inverter that tripped mid-afternoon, a combiner box offline for a day, fourteen inverters that dropped at once. Each line needs a cause before the filing goes in. Most of the evidence that would explain them sits in different systems, and nobody has had time to cross-check it. So the explanations get written the fast way: from the fault code, by resemblance to last quarter, or as “cause unknown”. Each shortcut is understandable. Each leaves a filing that is hard to defend.
A fault code tells you what the inverter noticed. It rarely tells you why.
Who this matters to
Compliance managers responsible for NERC GADS Solar submissions, the engineers who are asked to explain outages weeks after they happened, and asset managers who sign off on what the plant reports to its regulator.
Why the fault code isn’t the answer
GADS Solar event records carry a cause code, an event type — forced, maintenance or planned — a duration, the energy lost and a narrative. The cause should reflect the root cause of the outage, not the symptom the equipment reported. A fault code is a symptom. Take an inverter reporting that it lost its AC connection. That can mean a failed cable, a breaker that tripped on a fault, a breaker someone opened deliberately for maintenance, a utility-side disturbance, or a lightning strike nearby. The telemetry can look identical. The cause code, the event type and whether the hours count as a forced outage do not.
Five questions your best engineer asks
- •What did the equipment report? Fault codes, alarms and state changes from the inverters and other equipment are the starting point: they show which equipment stopped and what it noticed first.
- •What was the sky doing? Irradiance, storms, high winds, snow and extreme heat at that hour, and either side of it. A trip during a thunderstorm and a trip under clear skies are different investigations.
- •Has this happened here before? The same fault on the same equipment in recent months points to a recurring problem — and to how it was classified last time, which is worth checking rather than copying.
- •Did the neighbours drop too? One inverter dropping alone suggests a problem with that inverter. Fourteen dropping in the same interval suggests something they share: a feeder, a transformer, the grid connection or an external event.
- •Did output fade, or cut off? A gradual fade suggests the resource — cloud, soiling, snow. A hard cut-off to zero suggests a trip or a disconnection. The shape of the output often separates causes that the fault code cannot.
| Evidence | What it can tell you | Example |
|---|---|---|
| Equipment alerts | Which equipment stopped, and what it noticed first | AC disconnection reported on 14 inverters |
| Weather | Whether conditions outside the fence explain the event | Thunderstorm cell over the site at 2:30 PM |
| Past history | Whether this is new or recurring | No similar event in the last 90 days |
| Nearby failures | Whether the cause is shared upstream | Every inverter on one feeder dropped together |
| Data patterns | Whether output faded or cut off | Hard drop to zero in a single interval |
What the data can’t tell you
Some of the facts that decide a classification are not in any telemetry stream: whether the utility recorded a lightning strike, whether a technician opened a breaker for planned work, whether the grid operator switched a line. Those answers live with people — the site team, the maintenance calendar, the utility. A good engineer recognises that gap and asks. A weak process fills it with the most likely-sounding answer. One clear question is better than a confident guess that ends up in a regulatory filing.
One afternoon, fourteen inverters: an illustrative case
Numbers illustrative. At 2:42 PM, fourteen inverters drop at once. Their fault codes report an AC disconnection. Weather data shows a thunderstorm cell over the site. There is no similar event in the plant's recent history. All fourteen sit on the same feeder, and their output fell to zero in a single interval rather than fading. The leading explanation is a storm-related trip — but the data alone cannot confirm it, so confidence is medium. One question settles it: was there a lightning report near the site that afternoon? The site team checks with the utility, which confirms a strike at 2:39 PM. Confidence rises to high, the engineer approves the classification, and the record is locked with the evidence and the answer attached. Written from the fault code alone, the same event could easily have been filed as an equipment failure inside the plant.
How Ellume Bridge explains every outage
- •Outages detected, figures calculated. Bridge detects outages from inverter state and fault codes, and computes hours, energy lost and the other filed figures by arithmetic. AI never produces a number that gets filed.
- •The whole picture, every time. For each outage, Bridge reviews equipment alerts, the weather, the plant's history, nearby failures and the shape of the data — like your best engineer would, before writing a single word.
- •It asks when it isn’t sure. When the data cannot settle the cause, Bridge does not guess. It asks your team one clear question — was there a lightning report, was this planned work — and refines its view when the answer comes back.
- •Your engineer decides. Clear calls take one click to accept. Uncertain ones get a conversation. Your engineer can accept, discuss or override, nothing is filed without sign-off, and once approved, the record is locked.
- •Every decision traceable. Every outage keeps its evidence, its questions and answers, and who approved it and when, so the question “why was this filed as a forced outage?” has an answer on record.
What a defensible outage explanation contains
A cause chosen for the root cause, not the symptom. The evidence behind it — equipment, weather, history, neighbours, data pattern. The alternatives that were considered and why they were ruled out. Any questions that had to be asked, who answered them and when. And a named person who signed off. If an outage in your last filing is missing any of these, it is the one an auditor will ask about.
Frequently asked questions
- Why can’t the inverter’s fault code be used as the outage cause?
- Because it records a symptom — what the equipment detected — not the root cause. The same code can come from several different causes, which may be filed with different cause codes and event types.
- What evidence should support a GADS outage classification?
- At minimum: what the equipment reported, the weather at the time, the plant's history of similar events, whether neighbouring equipment was affected, and the shape of the output during the event — plus any facts from the site team or utility that the data cannot show.
- What if the evidence I need is not in my data?
- Ask the people who have it — the site team, the maintenance calendar, the utility — and record the answer with the classification. A documented answer is far stronger than an assumption.
- Does Ellume Bridge file outage causes automatically?
- No. Bridge proposes a cause with its evidence and asks when it is unsure. Your engineer accepts, discusses or overrides, and nothing goes into the report without a person signing off.
