Understand Smart Meters, differences between AMR and AMI, architecture, communications, HES, MDM, data, ANEEL, interoperability, pilots, FAT, SAT, and engineering criteria.
Check it out!
A Smart Meter is an electronic energy meter capable of recording quantities with greater time granularity and exchanging data digitally with external systems. When integrated into an Advanced Metering Infrastructure — AMI — it ceases to be only a billing device and becomes an observation point at the grid edge, supporting use cases such as remote reading, outage detection, voltage analysis, load profiles, distributed generation, demand response, and improved distribution operation.
An isolated smart meter, however, does not constitute a Smart Grid. Technical value appears when metering, communications, data management, integration, and operational processes are designed as a system. Therefore, in engineering, the specification should start from use cases, data quality, and the interfaces that must be demonstrated — not merely from the list of functions available in the meter.
What is a Smart Meter?
A Smart Meter, or intelligent meter, is a digital meter capable of recording energy and other quantities, storing data, and communicating with back-end systems. Depending on the application, it may record active and reactive energy, demand, voltage, current, power, power factor, events, supply conditions, and power flow in more than one direction.
NIST highlights that modern smart meters need to deal with conditions that go beyond traditional metering, including distorted waveforms, bidirectional flow associated with renewable sources, and use of the meter as a distributed grid sensor. This expands the engineering role of the device: accuracy remains essential, but it must coexist with communications, data, interoperability, upgradeability, and integration requirements.
In the context of Smart Grid, the Smart Meter is a sensing and interaction element at the edge. The smart grid still needs telecommunications, data platforms, grid models, automation, and operational applications.
Conventional meter vs. AMR vs. Smart Meter vs. AMI
The terms are often used as equivalents, but they represent different levels of capability.
| Concept | Main characteristic | Communication | System role |
| conventional meter | records accumulated consumption | none or local | billing by on-site reading |
| AMR — Automated Meter Reading | automates meter-reading collection | normally reading-oriented | reduce manual collection |
| Smart Meter | measures, records intervals, and exchanges data digitally | may be bidirectional | intelligent metering node |
| AMI — Advanced Metering Infrastructure | integrates meters, communications, and data systems | bidirectional in a system architecture | support multiple metering and operational use cases |
The central difference is that AMI is not a type of meter. It is an infrastructure. A project can purchase Smart Meters and still not have a mature AMI if communications, data management, and integrations have not been defined.
Architecture of a smart metering infrastructure
Smart metering combines electrical equipment, telecommunications, system integration, and automation. Interfaces need to be defined before rollout.
A complete AMI connects the metering point to systems that transform data into operational, commercial, or planning information.
Meter
This is the metrological and electrical boundary. Selection depends on connection type, current, voltage, accuracy class, flow direction, required quantities, memory, clock, event records, local interface, and communications requirements.
Communications system
It transports readings, events, authorized commands, and maintenance information. It may use different technologies depending on customer density, urban or rural topology, coverage, latency, availability, and life-cycle cost.
Head-End System
The HES manages communications with the meter population and abstracts field differences for higher-level systems. Depending on the architecture, it concentrates technical registration, acquisition, monitoring, and communications management.
Meter data management
The Meter Data Management — MDM — layer, or equivalent function, validates, estimates, edits, and makes data available for billing, analysis, and other applications. The value is not merely in storing readings, but in maintaining traceability, quality, and context.
Systems that consume the data
CIS, billing, OMS, ADMS, analytics, portals, and planning systems may consume AMI information. Each integration should have defined responsibility, frequency, quality, and exception behavior.
What a Smart Meter can measure
The exact list depends on the equipment, application, and regulatory requirements. Possible quantities and records include:
- imported and exported active energy;
- reactive energy;
- demand;
- phase voltages;
- phase currents;
- active, reactive, and apparent power;
- power factor;
- interval load profile;
- energization and de-energization events;
- variations and abnormal conditions according to device capability;
- reverse energy flow;
- data quality or status;
- records associated with the internal clock and synchronization.
Not every quantity needs to be collected at the same periodicity. The design should distinguish what is necessary for billing, operations, planning, diagnostics, and maintenance.
Metering interval and granularity
Granularity defines how much time detail exists in a profile. More frequent readings make it possible to observe ramps, peaks, distributed-generation behavior, and load changes at higher resolution, but they increase data volume, traffic, storage, and processing.
The interval should be selected from the use case. A billing application may tolerate different dynamics from a function intended to improve voltage observability or detect grid events.
It is also necessary to distinguish three time dimensions:
- measurement interval: how often the quantity is recorded;
- transmission frequency: how often data are sent to the central system;
- end-to-end latency: time between a field event and its availability to the application.
Confusing these three quantities leads to contradictory specifications.
Bidirectional metering, distributed generation, and BESS
With distributed energy resources, the point of connection may alternate between consumption and injection. The meter must correctly represent energy directions and remain consistent with applicable billing and operational rules.
Bidirectional metering also helps understand the impact of reverse power flow on the grid. However, the existence of metering does not replace capacity, voltage, protection, or power-quality studies.
BESS adds another dynamic: charging and discharging may occur at different times and at high power. If the purpose is to evaluate the system’s operational behavior, metering granularity must be compatible with the phenomenon to be observed.
Smart Meter as a distribution-grid sensor
A distributed population of meters can significantly expand low-voltage observability. NIST explicitly treats the Smart Meter as a possible terminal-node sensor in distribution.
This enables applications such as:
- identify loss of supply across groups of customers;
- observe voltage levels in poorly instrumented areas;
- improve load estimates;
- validate connectivity and phasing;
- support hosting-capacity studies;
- detect abnormal consumption or metering patterns;
- provide data for reinforcement planning;
- support analysis of distributed generation and electrification.
The gain, however, depends on registration quality. If the system does not know which transformer, phase, or circuit the meter is connected to, a significant part of the operational value is lost.
Smart Meter and ADMS
ADMS — Advanced Distribution Management System uses data from different sources to model and analyze the distribution network. AMI can contribute voltage, supply status, and load profiles, complementing telemetry from SCADA and field devices.
Integration should not be indiscriminate. An ADMS needs to know data quality, timestamp, electrical location, and latency. Smart Meter data with high delay may be suitable for planning or historical analysis, but unsuitable for a fast-response operational function.
Communications: there is no universal technology
The AMI communications network may use RF mesh, cellular networks, PLC, and other technologies or combinations. Selection should consider territory characteristics, point density, coverage, propagation, existing infrastructure, availability, and cost.
| Criterion | Engineering question |
| coverage | what percentage of meters must communicate directly or through relaying? |
| latency | what maximum time can each use case tolerate? |
| availability | what level is required for readings, events, and operations? |
| capacity | what message volume will be carried under normal and contingency conditions? |
| scalability | does the architecture support base growth and new functions? |
| maintenance | how will communications failures be located and addressed? |
| upgradeability | can equipment and communications evolve without premature replacement? |
Communications technology should not be selected solely from nominal catalog range. Representative pilots and surveys are important because the built environment, vegetation, terrain, and noise influence actual performance.
RF mesh, cellular, and PLC: conceptual differences
RF mesh
Meters or network devices may forward traffic from other nodes, creating multiple paths to collectors or gateways. The topology can be efficient in dense areas, but it must be validated for coverage, density, and capacity.
Cellular
It enables connection through carrier infrastructure. It may simplify certain scenarios, but depends on coverage, connectivity model, mobile-technology life cycles, and large-scale management strategy.
PLC
Power Line Communication uses the electrical grid itself as the communications medium. Performance is influenced by electrical topology and by noise and attenuation conditions in the channel.
There is no universal winner. The correct architecture is the one that meets use-case requirements and can be tested in the real environment.
Data quality and VEE
Meter Data Management must handle missing, duplicate, out-of-sequence, or inconsistent data. Validation, Estimation and Editing — VEE — processes create rules to validate and, when permitted, estimate or correct data while maintaining traceability.
The critical point is not to hide uncertainty. An estimated value should remain identifiable as estimated. Consuming systems need to know whether they are using an actual reading, estimate, correction, or insufficient-quality data.
Data quality can be tracked through indicators such as completeness, delay, estimation rate, registration discrepancies, and number of meters without communications.
Time synchronization
Load profiles, events, and comparative analyses depend on coherent clocks. Time deviations can shift peaks, create inconsistencies among systems, and compromise event reconstruction.
The design should define time source, tolerance, correction policy, treatment of official time, and behavior when the meter loses synchronization.
Interoperability and upgradeability
AMI projects have long life cycles. NIST published specific work on Smart Meter upgradeability precisely to reduce the risk of premature obsolescence as new functions emerge.
Interoperability needs to be analyzed across several layers:
- communication between meter and infrastructure;
- data model and format;
- integration between HES and MDM;
- integration with CIS, OMS, ADMS, and analytics;
- unique asset identification;
- version management;
- equipment replacement throughout the life cycle.
An excessively closed architecture may work during the first rollout and later hinder expansion, multivendor operation, and evolution.
Security, privacy, and data governance
Smart metering increases the amount and granularity of data associated with consumption. The architecture must protect confidentiality, integrity, and availability according to the criticality and purpose of each piece of information.
This involves access management, traceability, communications protection, controlled updates, monitoring, continuity, and data-retention and usage rules. It is also necessary to separate data required for billing, operations, and additional analyses, with governance compatible with legislation and organizational processes.
The design should incorporate security from the requirements and architecture stage. Adding it after equipment selection tends to create technical and operational constraints.
Smart Meter in Brazil: what ANEEL discussed in 2026
ANEEL opened the second phase of Public Consultation No. 1/2026 between July 1 and August 14, 2026, to discuss minimum requirements for smart metering systems used to bill low-voltage consumers.
It is important to state the status correctly: the documentation released at that stage represented a regulatory-improvement proposal submitted for public consultation and should not be confused with a definitive rule already incorporated into PRODIST merely because it was published for contributions.
According to ANEEL, the proposal considered the smart metering system as a solution made up of four integrated components:
- meter;
- communications interface with the customer;
- data communications system;
- data management system.
The consultation also addressed minimum requirements, methods and deadlines for providing data to customers, capabilities for new billing modalities, and topics related to interoperability, information quality, and architecture security.
This approach reinforces an engineering point: Smart Meter should not be specified separately from the rest of the metering system.
From the meter to the use case
Each use case creates different requirements. The matrix below helps separate intentions.
| Use case | Main data | Latency sensitivity | Additional dependencies |
| billing | energy and metrological records | low to moderate | VEE, CIS, traceability |
| load profile | energy/demand intervals | moderate | MDM and analytics |
| outage detection | status/event | higher | OMS, electrical records |
| voltage monitoring | voltage and data quality | depends on application | correct location and phase |
| distributed generation | import/export | moderate | DER registration and applicable rules |
| demand response | consumption and operational signals | higher | bidirectional communications and integration |
| planning | consolidated history | low | data quality and retention |
A mature specification starts from this matrix and derives periodicity, latency, availability, storage, and integrations.
How to size data volume
Volume depends on the number of meters, number of channels, recording interval, events, and retention policy. Engineering should consider not only daily averages, but also traffic peaks during reconnections, updates, mass events, and recovery after unavailability.
Sizing should cover:
- communications;
- HES capacity;
- MDM ingestion;
- primary and historical storage;
- VEE processing;
- APIs and integrations;
- backup;
- analytics and reporting.
An architecture that supports the initial base may not support new channels or shorter intervals a few years later.
How to structure an AMI project
Before defining the meter, communications, and platform, the project must characterize the installed base, grid, legacy systems, registration quality, and use cases. This AS-IS determines the viable architecture.
Structure the assessment with Technical Engineering Due Diligence
A smart metering project should combine electrical engineering, telecommunications, systems, and operational processes.
A reference sequence is:
- define use cases and expected benefits;
- characterize the metering fleet, installations, grid, and existing systems;
- define the target architecture and boundaries among meter, communications, HES, and MDM;
- specify metrological and functional requirements;
- select communications and coverage strategy;
- define the data model and integrations;
- establish security, privacy, and continuity requirements;
- execute a representative pilot;
- review results and adjust parameters;
- plan rollout by regions or groups;
- execute FAT, interoperability tests, and field acceptance;
- monitor communications, data, and operational KPIs.
Pilot: why it is more than a commercial proof
A useful pilot must represent real conditions and answer engineering questions. Installing a few meters in a favorable location demonstrates little.
The sample should cover relevant conditions such as dense and dispersed areas, different construction types, communications conditions, single-phase and polyphase installations where applicable, distributed generation, different load patterns, and loss-of-communications scenarios.
The pilot should measure:
- coverage;
- read rate;
- latency;
- communications stability;
- data completeness;
- failure behavior;
- upgradeability;
- interoperability;
- operational effort;
- integration quality.
Results need to become objective criteria for rollout.
Smart Meter and AMI procurement
Leveling AMI proposals requires comparing meters, communications, HES, MDM, integrations, tests, documentation, support, and life-cycle cost on the same technical basis.
An RFP should not be merely a feature spreadsheet. The scope needs to separate equipment, communications, software, data, services, integration, and life-cycle requirements.
Technical leveling should compare:
- electrical and metrological requirements;
- recorded functions;
- memory and intervals;
- local and remote interfaces;
- communications technologies;
- scalability;
- interoperability;
- firmware and version management;
- HES/MDM architecture;
- APIs and integrations;
- migration and registration;
- installation and replacement;
- testing;
- documentation;
- training;
- support and maintenance;
- warranties and service life;
- conditions for multivendor expansion.
The goal is to procure a system that can be operated throughout its life cycle, not merely the lowest unit cost per meter.
FAT and interoperability testing
Before rollout, laboratory testing and FAT should verify the combination of meter, communications, HES, and integrations.
Important cases include:
- accuracy and quantities according to the applicable scope;
- interval recording;
- energy import and export when required;
- clock and synchronization;
- memory and recovery after interruption;
- communications and reconnection;
- events;
- remote reading;
- controlled update;
- registration and identification;
- HES–MDM integration;
- data quality and traceability;
- behavior when an interface becomes unavailable.
Interoperability should be demonstrated through real integration cases, not merely through a statement of protocol compliance.
SAT and field acceptance
Field acceptance verifies installation, communications, and operation in the real environment.
The test must prove the entire chain. A meter appearing online in the HES does not prove that data arrive correctly at billing, OMS, or ADMS.
AMI operations and KPIs
After rollout, AMI becomes permanent operational infrastructure. KPIs should identify degradation before it affects billing or advanced use cases.
Useful indicators include:
- percentage of communicating meters;
- complete-read rate by period;
- latency by application;
- percentage of estimated data;
- HES and MDM availability;
- event success rate;
- failures by communications technology;
- mean recovery time;
- number of registration discrepancies;
- firmware versions in the field;
- integration success;
- recurrence of defects by batch or model.
Common mistakes in Smart Meter projects
Buying the meter before defining AMI
The hardware begins to dictate the architecture and may limit future integration.
Confusing read rate with system quality
Receiving a reading does not mean it is correct, contextualized, and available in time for the use case.
Selecting communications without a representative pilot
Nominal coverage does not replace real-world performance in the territory.
Collecting everything without a use case
More channels and shorter intervals increase cost without necessarily creating value.
Ignoring electrical registration
Without correct transformer, feeder, and phase information, data lose part of their operational value.
Treating HES and MDM as the same function
Data acquisition and data management have different responsibilities and need a clear boundary.
Planning only deployment
The meter base will continue to evolve for many years; updates, replacement, expansion, and maintenance need to be part of the project.
How to procure engineering for smart metering
Vendor-independent engineering can act from use-case definition through acceptance. The scope may include AS-IS survey, requirements, AMI architecture, telecommunications criteria, meter specification, interface matrix, pilot strategy, TBE, design review, FAT, SAT, and commissioning.
The engagement should produce traceable deliverables: Owner’s Requirements, reference architecture, list of points and quantities, communications requirements, data model, interface matrix, test plan, rollout criteria, and acceptance matrix.
This allows vendors to be compared on a technical basis and reduces the risk of turning the project into dependence on a proprietary solution without clear evolution criteria.
Final considerations
Smart Meter is an important part of distribution modernization, but value comes from the complete metering infrastructure. Meter, communications, HES, data management, and integrations must operate as a coherent system.
Mature projects begin with use cases, size data and communications from them, validate performance through a pilot, specify interoperability, and treat FAT, SAT, and operations as part of the engineering cycle. The expected outcome is not merely remote reading: it is reliable, usable information for billing, customers, planning, and grid operations.
Acceptance must prove the end-to-end chain: electrical quantity, meter, communications, HES, data management, and final application.
Technical references
[1] ANEEL — Brazilian Electricity Regulatory Agency. Electricity meters: ANEEL opens second phase of public consultation. 2026. Available at: https://www.gov.br/aneel/pt-br/assuntos/noticias/2026-defeso-eleitoral/medidores-de-energia-eletrica-aneel-abre-segunda-fase-da-consulta-publica.
[2] NIST — National Institute of Standards and Technology. Advanced Metering in Smart Distribution Grids. 2025. Available at: https://www.nist.gov/programs-projects/advanced-metering-smart-distribution-grids.
[3] NIST — National Institute of Standards and Technology. Advanced Metering Infrastructure Smart Meter Upgradeability Test Framework. 2015. Available at: https://www.nist.gov/publications/advanced-metering-infrastructure-smart-meter-upgradeability-test-framework.
[4] NIST — National Institute of Standards and Technology. NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 4.0. 2021. Available at: https://www.nist.gov/publications/nist-framework-and-roadmap-smart-grid-interoperability-standards-release-40.
[5] NIST — National Institute of Standards and Technology. Smart Grid Priority Action Plans. 2026. Available at: https://www.nist.gov/ctl/smartsystems/smart-grid-priority-action-plans.
Frequently asked questions
It is an electronic meter capable of recording energy and other quantities with greater granularity and exchanging data digitally with external systems.
A Smart Meter is the metering device. AMI is the infrastructure that integrates meters, communications, data acquisition and management systems, and applications that consume this information.
No. A Smart Meter is one component of the architecture. Smart Grid includes the electric network, sensing, telecommunications, data, automation, and control applications.
Depending on the equipment and scope, it may record imported and exported energy, demand, voltage, current, power, power factor, interval profiles, and events.
It can record import and export flows when correctly specified and applied, allowing consumption and injection to be represented at the metering point.
Options include RF mesh, cellular networks, and PLC. Selection should be based on coverage, latency, availability, capacity, maintenance, and life-cycle cost.
The second phase of Public Consultation No. 1/2026, which ended on August 14, 2026, discussed a proposal for minimum requirements for low-voltage smart metering systems. Publication of the consultation should not be confused with a definitive rule already incorporated merely because it was submitted for contributions.
Through laboratory tests, FAT, interoperability testing, and a representative pilot, followed by SAT and end-to-end acceptance across meter, communications, HES, MDM, and applications.
Complementary technical materials
Related services
- Industrial Automation Engineering Design: control, supervision, OT networks, and integration
- Electrical Engineering Services: designs, inspections, studies, reports, and commissioning
- Technical Engineering Due Diligence: assets, risks, compliance, and recommendations
- Technical Procurement: specification, bid leveling, suppliers, and contracting support
- Commissioning and Technical Acceptance of Electrical Installations
Core content on the topic
- Smart Grid: what it is, architecture, automation, and distributed energy resource integration
- ADMS: what it is, architecture, functions, and advanced distribution management
