Introduction

Smart meters generate more than just periodic consumption readings. They can produce alarms, diagnostics, communication information, battery information and other operational data.

The traditional AMI model sends much of this information through the communication network to central platforms:

Meter → Network → HES → MDMS → Applications

This architecture remains important, particularly for centralized data management, historical records, validation, analytics and utility applications.

But not every decision needs to travel all the way to a central platform before something can happen.

Some processing can happen closer to where the data is generated — inside the meter, at a gateway, at a building controller, at a concentrator or at another local computing layer.

This is where edge computing becomes relevant to smart metering.

Key Takeaways

• Edge computing means processing selected data closer to where it is generated.
• It does not mean eliminating HES, MDMS or central analytics.
• Local processing can reduce unnecessary communication and improve response time.
• Edge capability can allow selected functions to continue during temporary connectivity interruptions.
• For smart water, edge processing can support leak, continuous-flow, abnormal-consumption and tamper detection.
• Additional processing can increase device complexity and energy consumption.
• Distributed intelligence increases the importance of OTA, security and centralized governance.
• Utilities should decide which functions belong at the edge, centrally, or at both levels.
• The starting point should be the operational problem, not the technology.

What Is Edge Computing?

At its simplest, edge computing means processing data closer to its source.

In smart metering, the edge can exist at several levels:

• Inside the smart meter
• At a local gateway
• At a building or site controller
• At a communication concentrator
• At a local utility network node
• At an on-premise or regional computing platform

The farther processing moves toward the field, the less dependent selected functions become on continuous communication with a central system.

For example, a local device could identify a significant event and transmit the event rather than continuously sending every underlying measurement.

The important point is that not every meter needs a powerful processor. Processing responsibilities can instead be distributed across the architecture.

Why Does This Matter for Smart Metering?

Centralized AMI systems remain highly effective for fleet-wide visibility, historical storage, data validation, analytics, billing integration, reporting and operational dashboards.

However, central processing means information generated in the field must travel through the communication network before it can be acted upon.

That creates considerations around:

• Communication bandwidth
• Network availability
• Latency
• Data volume
• Communication cost
• Central processing requirements
• Privacy and security
• Resilience during connectivity interruptions

Edge computing provides another architectural option:

Process what needs immediate local action locally, and send what needs central analysis centrally.

Not All Meter Data Needs to Be Sent

One of the most useful concepts in edge computing is data reduction.

A meter may generate measurements at regular intervals, but some applications may primarily need information about a condition rather than every underlying measurement.

Examples include:

• Threshold violations
• Sudden changes
• Abnormal patterns
• Leak indications
• Tamper events
• Communication faults
• Battery warnings

An edge device can identify the relevant condition and communicate the event instead of continuously transmitting all underlying information.

But data reduction must be applied carefully. Information may still be required for billing, regulatory requirements, investigations, analytics, audits or asset management.

The better question is therefore not:

How much data can we eliminate?

It is:

Which data needs to move, when, and for what purpose?

Edge Computing Can Reduce Communication Dependency

Smart meters can temporarily lose connectivity because of weak RF conditions, network outages, basement installations, building structures, congestion, maintenance or other service interruptions.

If every operational function depends on immediate communication with the central platform, an interruption can delay the response.

Edge capability can provide a degree of local autonomy.

Depending on the architecture, a meter or gateway could continue to:

• Record measurements
• Detect predefined events
• Store information locally
• Perform basic validation
• Trigger local actions
• Queue information for later transmission

When connectivity returns, relevant information can be synchronized with the central system.

This creates an important resilience principle:

Connectivity failure should not necessarily mean operational failure.

Edge Does Not Mean “No Cloud”

Edge computing is sometimes interpreted as a replacement for centralized platforms. In AMI, a more practical model is distributed processing.

Meter

Collects measurements and performs basic local processing.

Gateway or Concentrator

Aggregates devices, performs local filtering or event processing and manages communication.

HES

Manages device communications, commands, data collection and connectivity.

MDMS

Validates, processes, stores and manages meter data.

Utility Applications

Use trusted information for billing, analytics, operations and customer services.

The architecture question is therefore not whether processing should be local or central in every case. It is:

Which function belongs at which layer?

Edge Computing and Smart Water

Edge computing is particularly relevant to smart water metering because water utilities increasingly want to move beyond simple consumption collection.

Potential applications include:

• Leak detection
• Continuous-flow detection
• Abnormal consumption
• Burst-pipe identification
• Backflow detection
• Tamper detection
• Pressure-related events
• Meter health monitoring
• Local diagnostics

Some of these applications can be handled using relatively simple rules.

For example, a meter or local gateway could identify continuous flow for an unusually long period and generate an event without waiting for a central analytics platform to examine every individual reading.

More advanced applications may use statistical analysis or machine-learning models, but edge computing does not automatically mean AI. A simple threshold or rule can also be an edge function.

Edge Computing Can Improve Response Time

Latency matters when an event requires a fast response.

Consider a potential water leak. A centralized workflow may require:

Collect data → Transmit data → Process centrally → Generate alert → Return command

For some applications, that latency is acceptable. For others, a local response may be preferable.

An edge device could detect an abnormal condition and immediately generate an event. More advanced architectures could potentially trigger another local function.

This creates a hierarchy of response:

• Local event → Local response
• Operational information → Central platform
• Long-term analysis → Cloud or enterprise systems

Edge Computing Can Help During Network Outages

Resilience is another reason to consider edge processing.

Imagine a building, neighbourhood or utility area temporarily losing connectivity. The meters themselves may continue operating normally.

With suitable edge capability, selected functions can continue locally, such as:

• Storing readings
• Identifying alarms
• Maintaining event history
• Performing basic diagnostics
• Continuing local validation
• Queuing priority events

Once communication is restored, information can be synchronized.

This can make the overall architecture more resilient without requiring every function to operate independently of the central system.

But Edge Computing Has a Cost

Edge computing introduces additional requirements into field devices and local infrastructure.

These may include:

• More capable processors
• Additional memory
• More sophisticated firmware
• Software development
• Local storage
• Security controls
• Model management
• Remote configuration
• OTA updates
• Monitoring
• Lifecycle support

For battery-powered water meters, there is an additional constraint: energy consumption.

More processing can consume more energy. The additional processing therefore needs to be justified by the operational value it creates.

Edge Processing Can Affect Battery Life

Smart water meters operate under a very different constraint from conventional computing devices. They may need to operate for 10–15 years with a limited energy budget.

Every additional function can have an energy impact:

More sensing → More processing → More memory activity → More communication

However, the relationship is not always negative. If edge processing reduces unnecessary communication, the energy saved by transmitting less information may outweigh the energy used for local processing.

The objective should therefore not be maximum edge processing.

It should be:

The right amount of edge processing for the required operational outcome.

Edge Analytics Should Not Create Another Data Silo

Moving intelligence into field devices also creates a governance challenge.

If meters and gateways independently run different versions of detection rules, thresholds, algorithms or machine-learning models, fleet management can become difficult.

Utilities need to know:

• Which algorithm is running
• Which firmware version is installed
• Which parameters are configured
• When configuration changed
• What event triggered an alert
• Whether the result can be reproduced

This leads to an important principle:

Edge computing should be distributed operationally but governed centrally.

OTA Becomes Even More Important

As more intelligence moves into field devices, firmware becomes more than a communication component.

It may contain:

• Data processing rules
• Event detection
• Local analytics
• Security functions
• Device-management logic
• Machine-learning models

Utilities may therefore need to update not only firmware, but also configuration, algorithms, models and security functions.

This makes secure and recoverable OTA capability an important enabler of edge computing.

Without reliable fleet management, sophisticated edge capabilities can become difficult to maintain across a 10–15 year asset lifecycle.

Security Becomes More Distributed

Edge computing expands the security boundary.

Instead of protecting only:

HES → MDMS → Applications

the utility may also need to protect:

Meter → Gateway → Local Processing → Network → HES → MDMS

Edge devices may store information locally and execute logic independently.

Relevant security considerations include:

• Device authentication
• Secure boot
• Firmware integrity
• Encrypted communications
• Access control
• Key management
• Secure OTA
• Local data protection
• Protection against unauthorized configuration

The more capable the edge device becomes, the more important these controls become.

Edge Computing Does Not Replace the MDMS

This distinction is particularly important in AMI architecture.

The MDMS continues to perform centralized meter data management functions such as:

• Validation
• Estimation
• Editing
• Storage
• Data quality management
• Historical analysis
• Enterprise integration

Edge processing operates at a different level.

For example:

Edge: Detect continuous flow for six hours.

MDMS: Validate the meter's consumption history and make trusted data available to downstream systems.

Analytics platform: Determine whether the pattern represents a likely leak across a population of meters.

Each layer contributes something different.

Where Should Processing Happen?

A practical way to think about edge architecture is to divide processing into three categories.

Process Locally

Use the edge when the function requires:

• Low latency
• Local resilience
• Immediate event detection
• Significant data reduction
• Minimal dependence on connectivity

Process Centrally

Use HES, MDMS or enterprise platforms when the function requires:

• Fleet-wide data
• Historical analysis
• Cross-meter comparison
• Regulatory records
• Central governance
• Enterprise integration

Process at Both Levels

Some applications benefit from a hybrid model.

For example:

Edge: Detect abnormal consumption.

Central platform: Compare the event against historical behaviour, customer information and nearby meters.

This combines the speed of local processing with the analytical depth of central systems.

Start With the Operational Problem

One of the biggest mistakes in edge computing is starting with the technology rather than the operational problem.

Instead of asking:

Should we put AI at the edge?

a better starting point is:

What operational problem are we trying to solve?

Examples include:

• Too much communication data: local filtering or event-based transmission.
• Slow leak detection: local event detection combined with central validation.
• Network outages: local storage and autonomous event handling.
• Fleet-wide analytics: centralized processing.
• Immediate local response: edge decision-making.

This problem-first approach prevents edge computing from becoming another technology project without a clear operational outcome.

A Practical Edge Computing Architecture

A modern smart water metering architecture could distribute responsibilities across several layers:

Smart Meter
Measurement and basic event detection

↓

Local Gateway / Edge Node
Aggregation, filtering and local analytics

↓

Communication Network
Efficient transmission of relevant information

↓

HES
Device communication and management

↓

MDMS
Trusted meter data management

↓

Analytics / AI Platform
Fleet-wide intelligence

↓

Utility Applications
Operational and customer decisions

This approach allows each layer to perform the functions it is best suited to handle rather than forcing one platform to do everything.

What Utilities Should Ask During Procurement

Edge capability should increasingly become part of AMI procurement discussions.

Utilities should ask:

• What processing can be performed locally?
• Where does the edge function reside?
• How much additional energy does it consume?
• Can edge functions be configured remotely?
• Can algorithms be updated through secure OTA?
• How are different firmware versions managed?
• What happens when communication is unavailable?
• What data is stored locally?
• How long is local data retained?
• How is local data protected?
• How are edge-generated events represented in HES and MDMS?
• Can edge functions operate across multiple vendors?
• Can the architecture evolve over a 10–15 year lifecycle?

The procurement question therefore moves beyond:

Does the meter support edge computing?

toward:

Can the utility operate and govern distributed intelligence at scale?

The Bigger Lesson: Intelligence Is Moving Closer to the Field

Smart metering began primarily as an automated data collection exercise. The architecture is now capable of supporting more distributed intelligence.

Meters and field devices can increasingly sense, analyse and identify events before information reaches central systems.

This does not mean intelligence is leaving central utility platforms.

It means intelligence is becoming distributed.

The architecture may therefore evolve from:

Millions of meters → One central brain

toward:

Millions of intelligent endpoints → Distributed processing → Central intelligence

Each layer contributes to the overall system.

Conclusion

Edge computing matters in smart metering because the value of data is not determined only by how much information a utility can collect.

It also depends on where, when and how that information is processed.

For smart water metering, edge processing can support faster event detection, reduced communication, improved resilience, local diagnostics and more responsive leak and anomaly detection.

But it also introduces requirements around processing power, battery consumption, security, OTA management, software governance and fleet-scale operations.

The objective should therefore not be to move as much intelligence as possible to the edge.

It should be to create the right distribution of intelligence across the meter, network, HES, MDMS and analytics platforms.

For utilities, the important question is not simply:

Do we need edge computing?

It is:

Which decisions should happen at the edge — and which should remain central?

That is where edge computing becomes more than a technology trend. It becomes an architecture decision that can shape how smart metering systems operate over the next decade.

The future of smart metering may not be about sending more data to the centre. It may be about making better decisions before the data gets there.