From the Smarter Meter to the Smarter Grid

If you're evaluating AMI 2.0, you've heard the pitches: "open networks", "edge intelligence", "Artificial Intelligence (AI) in the meter." This is our view on what the meter can and can't do today, and why realizing the full value of that investment takes a distributed intelligence (DI) platform above it.

Edge intelligence isn't just a feature you add to a device; it's a systematic capability. The real question a utility faces goes beyond "how smart can the meter get?" to "what intelligence belongs at each layer of the grid, and where can it actually run?"

In our view, that question has a clear answer. Narrow, purpose-built detection belongs at the lowest tier, i.e., the grid edge, where it must be fast and local. Coordinating intelligence, grading assets, prioritizing action across many devices — these are the types of edge intelligence that belong at the gateway or similar intermediate tier. Reasoning, forecasting, and closed-loop control across the whole system belong on a platform above them. Match each job to the layer whose compute, vantage point, and authority fit it, and the grid gets smarter. Force the wrong intelligence onto the wrong layer, and you get a capability that can't run, can't see far enough, or can't safely act.

AMI 2.0 is a genuine step forward within this picture: an open, IP-native sensing and telemetry capability with meaningful detection on the meter. But the meter is only one layer, not the system. It reads the grid from behind the meter, acts only on behind-the-meter equipment, and runs meter-class silicon — the right design for its job, and the wrong place for the reasoning and control that running a feeder, coordinating a substation, or holding an interconnection inside limits demands.

This paper lays out that tiered approach — the right intelligence, at the right layer, for the right use case — and outlines how an inference layer such as the one implemented by OES' OpenDSO platform can turn the AMI network into a grid-wide sensing and detection fabric, putting each tier of intelligence where it belongs, to bring observability and situational awareness across the grid.

To see why that layered approach matters now, let's start with the question many utilities are already asking as they plan their meter upgrade cycles: "what value has our AMI 1.0 metering delivered, and what is still left on the table?"

The smart meters deployed in the late 2000s and early 2010s are reaching end of life. As utilities plan the replacement wave, most are looking beyond basic metering to AMI 2.0, not just to read usage, but to finally realize the grid benefits the first investment was supposed to deliver.

First-generation AMI was justified, and largely paid for, on hard-dollar operational savings: automated meter reading, remote connect and disconnect, fewer estimated bills, outage and restoration support, and conservation voltage reduction (CVR). Those benefits were real. But the second-order benefits, which promised grid-modernization value from all that interval data, mostly stayed on the slide deck.

The primary reason is structural, and it's the same reason that matters for AMI 2.0: the meter alone doesn't generate the benefit; it requires an overarching observability, analytics, and inference layer to deliver the value of high-frequency endpoint data. Interval reads, in conjunction with grid telemetry and state, become intelligence on state, faults, local peaks, asset health, or DER visibility for equipment downstream to turn into action. For many first-gen deployments, that inference layer was never built.

Why did the second-order value of AMI 1.0 stall?

The gap wasn't the meter data; it was the layer that should have turned that data into grid operations.

• Batched usage and demand data landed in an MDMS built for billing, not grid operations.
• Metering processes were built for efficient, daily validation, editing and estimation (VEE) and market operations, not real-time intelligence and operations.
• Integration into ADMS, DERMS, or OMS was limited.
• First-gen meters predated standardized container-based approaches to add new use cases.
• Deployed technologies (proprietary and centralized) were not designed for real-time observability and analytics.

AMI 2.0 business cases often lead with the second-order benefits first-gen AMI left on the table:

The lesson that carries forward: value comes from the layer that turns meter data into action. In principle, AMI 2.0 should make that layer easier to build. That is exactly where an open platform earns its place in the overall solution.

So, what does this new generation of meters bring to the table? Cutting through the marketing, three characteristics of AMI 2.0 stand out, each a building block that the rest of the grid intelligence can be built upon.

The cumulative impact of these capabilities is what advances the next-generation meter from a periodic read-and-report device to an IP-native grid-edge detection sensor within a layered edge-intelligence architecture.

Why this matters for what's next: the same standardization of communications and security in the field area network (FAN) that lets AMI 2.0 meters from different vendors be interchangeable — IPv6 addressability, standardized metering protocols, and standardized security and encryption — is what an agentic architecture layer needs to infer, correlate, and make recommendations based on real-time detection events from the meter. A stronger, more open meter layer makes the intelligence above it more valuable, not less.

The openness is real at the communications and protocol layer, where vendor-neutral standards now interoperate. On-board intelligence is a different matter: it reflects each vendor's engineering trade-offs in computing and memory. So before building on that promise, it pays to be clear about:

• What can the meter realistically compute?
• How well can the meters communicate with each other?
• How far into the grid should the meter be able to see and operate?
• How do you secure the asset?

The following sections articulate our perspective on these questions.

"Edge AI," "AI agents on the meter," and "a language model at the edge" are common phrases in AMI 2.0 marketing. It is worth being precise about what the meter's compute envelope supports because the meter's role and the platform's role are different, and treating them as the same leads to the wrong architecture. While AMI 2.0 aims to convert the meter from a simple measurement device to an edge IoT computer, CPU, memory/storage, power consumption, and cost per point all limit how far the envelope of edge computing can be pushed on the device.

Start with the electronics: a typical meter runs meter-class compute, a small, power-sipping microcontroller sized to do metrology, run the network stack, hold the security layer, and execute one fixed detection routine reliably for fifteen-plus years in a sealed enclosure. That design suits its job well. An AMI 2.0 meter might push into basic app-class compute, operating on the equivalent of a lower-end processor with limited memory (such as an ARM Cortex-A RISC processor with 256 MB of RAM, expandable with flash storage). It is, however, a different class of hardware from the compute (e.g., the processors, memory, and accelerators) that complex machine-learning models, agentic reasoning, and large language models require.

From a functional standpoint, the on-board neural network interface on AMI 2.0 meters is well suited for time-series neural network applications such as arc / high-impedance / broken-neutral fault detection. Fixed-model anomaly detection use cases would also be a good fit.

However, while the grid modernization benefits are significant, nothing comes for free; these advanced capabilities come with trade-offs. The 2.0 meters can average 3.5–5 W of power draw (compared to ~1 W for first-generation AMI meters), adding to both system peaks and distribution losses. The meters themselves are estimated to cost at least 50% more than 1.0 meters and have shorter depreciable lives.

So where should the heavier AI run? On the tier that can host it. Fit-for-purpose 'detection' ML belongs on the meter and at the grid edge. Coordinating agents that grade assets and prioritize action belong at the substation, gateway, or data-concentrator tier, on higher-end app-class compute reached over cellular or fiber. Language-native reasoning and reporting belong in the enterprise tier. The meter is the sensor, not the brain, and, while a metering network implements ubiquitous sensing across the grid, it is not suited to carry agent-to-agent reasoning in real time.

A useful question during procurement: if a meter or AMI solution is described as running "agents" or a named language model on the device itself, ask which device is meant (the meter, a collar device, or an upstream data-concentrator / gateway), and the nature of its on-board compute capabilities. While they are all valid options, each represents a different tier. The most robust architecture places narrow, purpose-built detection on the meter and the heavier intelligence on the tiers built to run it.

While compute capability and location are key considerations in designing a layered intelligence architecture, the communication network also plays a critical role.

Distribution circuits now carry DERs, EV fast-charging, and small-to-medium data-center loads that behave nothing like the demand these systems were built for. Meeting that takes real-time intelligence that both sees and acts across the grid — and that, in turn, depends on how much the field network can actually carry. Here the cost-effective AMI network runs into a hard limit.

Wi-SUN FAN and LoRaWAN are the workhorses of AMI 2.0 communications, and both are deliberately low-bandwidth. Wi-SUN standardizes an open, self-healing IPv6 routing fabric over a sub-GHz radio; LoRaWAN extends reach to sparse, hard-to-reach endpoints. Both are engineered to move small, periodic reads and compact event messages efficiently across a shared mesh, not to sustain the frequent, low-latency exchange that machine-to-machine coordination requires. Cellular to the meter does supply that bandwidth, but at a per-endpoint hardware and subscription cost that rarely pencils out across millions of meters, so it is typically reserved for backhaul from concentrators or for sparse, high-value sites.

Even if the silicon could score a model, the network that connects millions of meters cost-effectively is designed for periodic reporting, not continuous dialogue. Agent-to-agent coordination and real-time inference belong where there is both the compute to run them and the bandwidth to feed them: at the gateway, the substation, and above.

Beyond the physical limits discussed above, vantage point and authority represent operational boundaries, and neither is fixed by a faster radio or a newer meter.

The meter you're upgrading is the right first layer. It isn't the whole system, and it is not meant to be.

As distributed intelligence moves toward the grid edge, the security question moves with it. AMI 2.0 raises the bar over first-generation metering, and, at the same time, expands the surface a utility must defend. Both are worth stating plainly.

On the standards side, the direction is clearly positive. Wi-SUN FAN specifies PKI-based device authentication, AES packet encryption, EAP-TLS network authentication, and standards-based key management. Modern metering silicon ships with a hardware root of trust (secure element or TrustZone), and PKI-native designs support certificate issuance and rotation as an ongoing operation rather than a one-time factory event. Compared with the shared passwords and proprietary schemes common in first-generation fleets, this is a significant improvement.

Why does this matter for control at the edge? A meter that senses and reports has a bounded radius if compromised. Extending grid-control authority to millions of premise-located endpoints is a different risk equation: it widens both the number of entry points and the potential consequence of a compromise. This is a strong, practical reason that coordinated grid control is best executed through a smaller population of hardened, utility-owned field devices under strong access control and protection coordination, not pushed onto the metering endpoint or data concentrators. It is the same trust boundary that good safety and protection engineering already draws.

Compute, communications, vantage point, authority, and security all point to a common need: a layered platform architecture is a critical component of enabling grid-edge intelligence.

OpenDSO is the layer that turns the metering network into grid intelligence and action by combining it with substation and grid telemetry. It operates across the electric grid, pipelines, renewables, and industrial sites, and is built in three tiers so that intelligence runs where it is most effective: be it in a meter, a gateway in a device cabinet, a substation controller, enterprise, or in the cloud.

How OpenDSO approaches secure, distributed intelligence. A secure meter, on its own, still only produces trusted premise data. Turning that into a smarter grid takes a distributed intelligence platform above it that treats the metering network as a sensing and telemetry layer, fuses its detections with substation and grid telemetry, and keeps control actions on the platform's hardened tier: utility-owned devices, deterministic and secured communications, zero-trust identity with rotating credentials and workload attestation across users, devices, networks, applications, and data. That is what lets a utility safely extend intelligence from monitoring to coordinated, closed-loop control across the grid.

Critically, this does not replace the AMI investment a utility is making; it builds directly on it.

Building on the lessons from first-generation AMI: value comes from the layer that converts metering data into action. OpenDSO is that layer, using the AMI 2.0 network as a sensing and telemetry fabric and combining it with substation and grid telemetry into one operating picture that both watches and acts.

How does the utility benefit? The metering investment you're already making continues to pay off, there's no rip-and-replace, and you gain full-grid monitoring and control on one open, secure platform, deployed use case by use case, where the value is greatest. As the economic and energy costs of app-class computing in the meter come down, reasoning and inference can be pushed further to the edge. The platform architecture fully supports this progressive distribution of intelligence.

What does that look like in practice? The same pattern plays out across the use cases utilities care about most.

OpenDSO implements the edge architecture for executing a repeatable pattern that puts each kind of intelligence on the tier that can host it: fit-for-purpose ML at the grid edge, coordinating agents at the substation, language-native reasoning in the enterprise.

The same edge-to-enterprise pattern runs across the operations that matter most, including several that turn AMI 2.0 data into grid action. The use cases listed below are illustrative targets that show the shape of the opportunity; the right starting point depends on your feeders, your data coverage, and your priorities.

The through-line: each of these use cases runs on the same pattern — efficient ML at the edge, coordinating agents near the grid, language-native reasoning in the enterprise, all on one edge intelligence platform with autonomy earned in stages.

A worked example: wildfire risk, from meter event to grid action

Wildfire detection is often listed as an edge intelligence feature in AMI 2.0 meters. The detection capability is real, but detection is only the first step. Follow one event end to end and the tiered pattern comes to life: the meter senses, the network carries, the substation agent correlates, the enterprise reasons, and utility-owned devices act. Each job runs where its compute, data, and authority fit.

Detection is the meter's job; inference is the platform's; response is the utility's. On-meter ML flags an arcing or high-impedance fault and pushes a compact, standardized DLMS/COSEM event over the Wi-SUN network immediately. That single event is where the meter's responsibility ends and the platform's coordination begins: a substation agent correlates it with nearby meters, feeder SCADA/DA, and fire-weather data to confirm actual ignition risk; the enterprise tier scores circuit risk and drafts a plan; and switching executes through hardened, utility-owned devices with a person in the loop.

You don't need a territory-wide program to start; just as with AMI, a network-first, phased approach lowers switching cost and risk. OpenDSO deploys against specific use cases on the sites and circuits that matter most, and the same solution carries through every stage, so what you validate is what you run.

AMI 2.0 is a substantial advance toward grid modernization. It gives utilities an open, IP-native sensing layer and practical detection at the edge, and it makes the second-order value of metering data attainable. But the lesson of first-generation AMI still holds: the meter does not create that value on its own. Value comes from the layer that turns measurement into intelligence, and intelligence into coordinated action.

That is the case for a tiered approach. Fit-for-purpose detection belongs on the meter, where it must be fast, local, and resilient. Coordinating agents belong at the substation and gateway, where there is compute and context to reason across assets. Language-native reasoning and closed-loop control belong on a platform that spans the whole system, with authority kept on hardened, utility-owned devices where it can be governed. Match each job to the layer whose compute, vantage point, and authority fit it, and the grid gets smarter; force it onto the wrong layer, and the capability either can't run, can't see far enough, or can't safely act.

OpenDSO is built to be that layer. It uses the AMI network you are already investing in as a trusted sensing layer, integrating it with substation and grid telemetry, and places each kind of intelligence on the tier suited to it, without a rip-and-replace, and without locking you to a single vendor. The result is a continuous path from a smarter meter to a smarter grid: one that protects the metering investment, respects the trust boundaries that keep the grid safe, and scales from a first pilot to full deployment as confidence grows.

Let's build it together. The quickest way to prove the value is a targeted engagement: a few feeders, a clear use case, and the data you already have. We will help you design the edge-to-cloud architecture and the business case around it. Learn more at openenergysolutions.com.

About Open Energy Solutions. Open Energy Solutions (OES) builds OpenDSO™, an open, secure distributed intelligence platform that brings real-time monitoring and control to energy infrastructure across the electric grid, pipelines, renewables, and industrial sites. OES works with utilities and technology providers to modernize the grid edge without locking customers into a single vendor. Learn more at openenergysolutions.com.

OpenDSO™ and Execution at the Edge™ are trademarks of Open Energy Solutions, Inc. OpenFMB is a NAESB standard; Wi-SUN is a mark of the Wi-SUN Alliance; LoRa and LoRaWAN are marks of their respective owners. "AMI 2.0" is an industry term, not a formal standard; capabilities vary by vendor. Third-party names and marks, including any protocol or vendor names referenced, are the property of their respective owners and are used for identification only; reference does not imply endorsement or partnership beyond any separately announced relationship.

This is a marketing position paper describing Open Energy Solutions' point of view and product direction. Performance figures, targets, and use cases are illustrative, may reflect goals or forward-looking capabilities rather than guaranteed results, and vary with each deployment's data coverage, grid conditions, and configuration. Nothing here is a warranty, service-level commitment, or offer. © 2026 Open Energy Solutions, Inc. All rights reserved.