Outages leave marks in meter data
When a feeder trips, or a utility de-energizes lines for a public safety power shutoff, AMI data does something predictable. Meters on the affected circuits go quiet, report zero consumption, or come back with gaps and power-fail events. From the meter's point of view, all of that is accurate. The customer really did use no energy while the power was off.
The trouble starts when VEE does not know why. A validation engine that sees a run of zeros on an occupied home will call it suspect. An estimation routine that sees missing intervals will fill them, often with usage that looks like a normal day. Now the utility has estimated consumption for hours when the customer had no power. That estimate can reach the bill. It can also reach analytics and regulatory reporting, where it quietly makes the outage look smaller than it was.
The opposite mistake is just as costly. If outage zeros are accepted as ordinary usage, they distort the history that later estimates and forecasts draw on. They trigger zero-consumption and tamper alarms. They send field crews to check meters that were working exactly as designed.
Either way, the data ends up telling a story that did not happen.
Why outages are hard for meter data systems
The facts about an outage usually live somewhere else. The outage management system knows which devices opened and when crews restored them. The meter data system sees only the symptoms. Even when the two are integrated, the outage picture keeps moving: scope grows, then shrinks; circuits come back in stages; a second event starts before the first one is closed.
Restoration brings its own wave of data. Meters that were dark upload stored intervals when they come back, often out of order and hours or days late. If VEE already estimated those periods, the late actuals now conflict with the estimates, and someone has to sort it out.
Then there are the exceptions. A single large event can raise an exception for every affected meter on every affected day. Analysts face a wall of work where each item has the same root cause, and working them one at a time takes days. Meanwhile bills are due, customers are calling, and customer service needs a clear answer about what the next bill will show.
PSPS events add public scrutiny. They are planned, their scope is announced in advance, and regulators and customers expect the utility to account for them precisely.
Principles of outage-aware meter data
Make the outage a first-class record. An outage should be more than a note or a flag on a read. It needs a lifecycle, a scope (which premises, meters and periods it covers), evidence (the events and outage tickets that support it) and a policy for how affected data is treated. Once that record exists, every downstream decision can refer to it.
Hold instead of guessing. When data falls inside an active outage, the safest action is usually to hold it from estimation and billing until the picture is clear, rather than fill the gap with usage that did not happen.
Replay on restoration. When power comes back and meters upload what they stored, the held data should be re-run through VEE automatically, under the outage policy, without an analyst having to find and resubmit it.
Close outage-caused exceptions together. Exceptions raised by an outage should be linked to it and resolvable in bulk, with the outage recorded as the reason. The audit trail should show exactly which exceptions were closed, by whom and on what basis.
Treat PSPS as its own case. A planned de-energization is known before it starts. The meter data system should be able to act on that plan, not only react to what the meters report.
Give operations one view. Outage, billing and customer service teams should see the same picture: which meters are affected, what is on hold, what has been restored, and what is still waiting.
What it looks like in practice
In the Grid Data Management Platform, an outage is a first-class record with lifecycle, scope, evidence and policy. VEE applies outage-aware treatment to affected meters and days. Data can be held while an outage is active and replayed automatically on restoration. Exceptions an outage caused are linked to it and can be closed in bulk. PSPS events are handled explicitly. An outage command view with a map shows affected meters, holds and restoration progress in one place.
Because the platform serves one consistent answer, billing, outage operations, analytics and regulatory reporting all see the same outage treatment. Nobody has to reconcile an outage report against a billing extract that handled the same hours differently.
Illustrative example (hypothetical)
Picture a hypothetical utility that calls a PSPS event ahead of a high-wind forecast in a fire-prone area. The utility de-energizes a set of circuits overnight and restores them in stages over the following days.
The team opens an outage record from the PSPS plan, with its scope tied to the affected circuits and premises. As those meters go dark, their data is held rather than estimated. In the outage command view, operations can see on the map which circuits are still de-energized, which have been restored, and how much data is still on hold.
As each circuit comes back, meters upload their stored intervals and the platform replays the held data under the outage policy. The zeros during de-energization are treated as what they are: real, outage-caused zero usage. The exceptions they raised are linked to the PSPS event and closed in bulk, with the event recorded as the reason. Bills for the affected cycle reflect what actually happened. When a customer calls, the service representative can see that their premise was inside the event and explain the bill with confidence.
Questions to ask any MDMS vendor
Is an outage a record in your system with its own scope, evidence and policy, or just a flag on reads?
Can you hold affected data during an outage instead of estimating across it?
When meters upload stored reads after restoration, is held data replayed automatically?
Can analysts close all exceptions caused by one outage in a single action, with the outage as the recorded reason?
How do you handle a planned PSPS event differently from an unplanned outage?
Do billing, outage and analytics teams all see the same treatment of outage periods?
Keeping the record straight
Outages are hard enough on customers and crews. The meter data should not add to the damage by billing for hours without power, raising alarms on healthy meters, or understating an event in reports. Outage-aware VEE keeps the record honest, and it saves analysts from cleaning up the same event one exception at a time.
Learn more about the Grid Data Management Platform at perinimble.com/grid-data-management/, or talk with our team at perinimble.com/contact/.