Introduction

To understand why this article exists, it helps to take a step back and look at how Advanced Metering Infrastructure (AMI) is structured — and where things get complicated in the real world.

The standard AMI architecture follows a well-established chain:

Smart Meter → Communication Network → HES → MDM → Billing, ERP, …

Each layer has a distinct role:

• The Smart Meter generates data: interval load profiles, readings, events, and alarms.
• The Communication Network (RF Mesh, PLC, cellular, LoRaWAN, NB-IoT) carries the data from meters to the collection software.
• The HES (Head-End System) manages real-time communication with meters: data collection, remote control (connect/disconnect), time synchronization, firmware updates, and connection monitoring.
• The MDM (Meter Data Management System) receives raw data from HES and transforms it into something usable. This transformation — known in the industry as VEE (Validation, Estimation, Editing) — is the critical step between raw meter readings and reliable business data. MDM detects and fills gaps in data, corrects anomalies, builds interval load profiles, and serves as the integration hub toward upper-level systems: Billing, ERP, OMS, CIS.

Amivisor is a complete AMI platform that combines both HES and MDM capabilities. It includes its own multivendor HES — capable of collecting data directly from meters via standard protocols — as well as a full-featured MDM layer that performs VEE processing, analytics, and integration with external systems.

For many clients, Amivisor is deployed as the entire AMI solution: its HES collects meter data, its MDM validates and normalizes that data, and the resulting clean information is used for billing, analytics, reporting, and external integrations.

However, large enterprises often already have HES systems from multiple meter manufacturers in place. These systems were typically introduced over time, as metering infrastructure expanded vendor by vendor. In that case, the challenge is different: the customer already has operational HES platforms, but needs a unified MDM layer to validate, normalize, analyze, and consolidate data from all of them.

This is where Amivisor’s integration capabilities become especially relevant. Instead of replacing every existing HES, Amivisor can connect to them, ingest their data, apply VEE processing in its MDM, and provide a single analytical and operational view across the entire enterprise.

The question this article addresses is simple: how do you connect Amivisor to such a diverse landscape of HES systems, each with its own architecture, protocols, and data models? The answer is: through several proven integration methods, each suited to a different technical scenario.

Integration Methods

1. International Data Exchange Standards

In a number of countries, inter-system exchange protocols for commercial electricity metering systems have been developed based on the international CIM standard family (IEC 61968/61970 and 62325). Implementing one such protocol allows connecting multiple compliant HES platforms at once, without developing a separate connector for each system individually.

Amivisor has hands-on experience implementing the PODIS inter-system exchange protocol — an industry-specific standard developed drawing on principles of the CIM/IEC 61968 standard family. Implementations of such standards may vary between vendors, sometimes requiring minor protocol adjustments for a specific HES platform.

Integration case: Amivisor successfully integrated with the Pyramida platform via the PODIS protocol, enabling automatic data collection from a large meter fleet. The raw data collected via Piramida is passed through Amivisor’s VEE pipeline before being made available in the analytical modules.

Advantages:

• One integration covers multiple compliant systems
• Standardized data formats simplify validation
• Minimal risks when switching meter vendors

Limitations:

• Best suited to regions with a robust regulatory and standards framework
• Vendor-specific deviations in standard implementations are possible

2. HES System’s Own API

If the HES provides a programmatic interface (REST API, SOAP, MQTT, etc.), Amivisor uses it for bidirectional or unidirectional data exchange. A dedicated connector is developed for each platform using Amivisor’s ready-made integration layer toolset, which significantly reduces development time.

This is the most common and preferred method in modern projects, as API integration requires no direct access to the client’s internal infrastructure.

What is needed for implementation:

• API documentation (specification) of the target HES
• Test access to the HES system (sandbox or staging environment)
• Agreement on data exchange formats

Integration cases:

• WAVIoT — a cloud-based IoT/AMI platform with an NB-Fi-based HES. WAVIoT exposes a well-documented REST API to raw device data, which Amivisor uses to retrieve interval meter readings and other data.
• Strizh — an NB-IoT-based smart metering platform. Amivisor connects to the Strizh HES via its API to collect consumption data and operational events from the smart meter fleet.

Advantages:

• Clear integration boundaries, without touching internal HES structures
• High reliability and predictability of data exchange
• HES updates do not require reworking the integration (provided the API version is preserved)
• Supports real-time data and event-driven notifications (webhooks)

Limitations:

• Not all HES platforms have a documented or publicly accessible API
• A separate connector must be developed for each system

3. Direct Access to HES Database

When an HES lacks both standardized protocols and an API, data can still be retrieved via direct database queries. This is the lowest-level but most universal approach, applicable to virtually any system running on a relational DBMS.

Implementation mechanism:

1. A secure VPN channel is established to the server hosting the HES database.
2. A dedicated read-only account with minimal privileges on the required tables is created for Amivisor.
3. The Amivisor team analyzes the database schema and develops data extraction scripts.
4. To accelerate the analysis phase, the customer provides a database dump and, where possible, access to a demo or working instance of the HES.

Integration case: Amivisor integrated with SIMS (Smart Integrated Metering System) — the Head-End Software component of the ADDAX IMS platform developed by ADD Grup, an international metering manufacturer. SIMS manages a fleet of ADDAX (Matrix series) smart electricity meters. The integration was carried out via direct database access, enabling full historical data retrieval without any modifications to the HES architecture.

Advantages:

• Applicable to any HES regardless of API or protocol availability
• Full access to historical data without restrictions
• No changes required to the HES architecture

Limitations:

• HES updates that alter table schemas may require script revisions
• Requires secure network access setup (VPN)
• Elevated information security requirements compared with API-based methods

4. Special Case: Digital Twin

Some HES platforms offer a particularly elegant integration path through a digital twin mechanism. In this model, the HES itself acts as an intermediary: it polls real meters using its internal protocol and accumulates the collected data on its side.

To expose data to external systems, the HES creates a virtual (software) meter — a digital twin of the real physical device — and publishes the data through it using standard protocols such as DLMS/COSEM. Amivisor interacts with this digital twin exactly as it would with a physical meter: sending standard DLMS requests and receiving responses in a standard format. From Amivisor’s perspective, the integration is indistinguishable from ordinary meter polling, while the HES runs a complete virtual device model.

Integration case: Amivisor integrated with LarTech, a metering platform that collects data from meters over a LoRaWAN network. LarTech creates digital twins of its metered devices and exposes them via the DLMS/COSEM protocol. Amivisor queries these virtual meters directly over the standard DLMS interface. LoRaWAN imposes inherent constraints on data volume and latency; the integration was designed with optimized polling schedules to work reliably within the network’s bandwidth characteristics.

Advantages:

• Simple integration on the Amivisor side — no custom protocol development required
• No dependency on the internal architecture of the HES
• Fully standardized data exchange interface (DLMS/COSEM)

Limitations:

• Applicable only when the HES supports digital twin functionality
• Data freshness and granularity may be constrained by the underlying communication network (e.g., LoRaWAN)

5. File-Based Data Exchange

For systems that lack API, database access, and support for modern protocols, Amivisor supports integration via file-based data exchange. This approach covers both export from Amivisor to external systems and import of data from third-party platforms.

Amivisor supports the following exchange directions:

• Export: meter readings, load profiles, and instantaneous values — in XLS and XML formats.
• Import: meter readings and load profiles — from XLS and XML files generated by external systems.

Processing XLS files: Arbitrary-format spreadsheets require one-time configuration, during which the system is told which columns contain which data types (meter ID, timestamp, active energy, etc.). After that initial setup, all subsequent file processing is fully automated.

Processing XML files: Standardized XML schemas enable automatic, configuration-free processing. For example, Amivisor handles files built on the 80020 template — a format that contains not only consumption data but also the full description of the metering point. When such files are received, Amivisor automatically creates any missing metering points and meters, and reconstructs hourly or half-hourly consumption profiles.

Integration case: A common use case for this method involves commercial and industrial consumers whose energy supplier has installed smart meters on their premises but does not provide a customer-facing portal for viewing the collected data. The supplier delivers periodic reports — daily or monthly — containing hourly consumption data in XML format. These files are uploaded into Amivisor, which processes them through its VEE pipeline and makes the resulting load profiles available for tariff analysis: comparing billing scenarios across different rate structures (flat, time-of-use, demand-based) to identify the most cost-effective electricity pricing scheme.

Advantages:

• Applicable to legacy HES and supplier-provided data without API or database access
• Support for standardized XML formats (e.g., 80020) ensures hands-free, zero-configuration processing
• Flexible handling of arbitrary XLS structures via configurable column templates

Limitations:

• Batch-oriented: no real-time data delivery
• Data freshness is determined by the frequency of file exchanges

Amivisor’s Own HES: When to Use It and When to Keep the Vendor’s

Amivisor includes its own built-in, multivendor HES capable of polling smart meters directly via standard protocols — including DLMS/COSEM — without any intermediary vendor software. Understanding what it collects, and what it doesn’t, helps decide which deployment model makes sense for a given project.

What Amivisor’s HES collects:

• Current and archived meter readings
• Interval load profiles (power demand curves)
• Instantaneous consumption parameters (voltage, current, power, power factor, etc.)
• Event logs: outages, electronic seal violations, time synchronization events
• Power quality violation logs
• Relay status and control, including power limit settings
• Time synchronization commands

This covers everything needed for commercial and technical energy metering: billing calculations, load analysis, energy balances, loss detection, and power quality monitoring.

What Amivisor’s HES deliberately does not replace is the extended configuration and parametrization functionality provided by manufacturer-specific HES and configurator tools. Programming tariff zones, reading vendor-specific diagnostic registers, or updating meter firmware — these tasks require deep, device-level access that Amivisor does not aim to replicate. For these purposes, clients continue using their vendor’s HES or configurator software alongside Amivisor.

When it makes sense to replace the vendor HES entirely:

• The vendor’s HES is end-of-life or no longer supported
• License costs for the vendor HES are prohibitively high
• No extended meter programming is required beyond standard operational parameters
• The company is building a new metering infrastructure from scratch and wants to avoid vendor lock-in

When it makes sense to keep the vendor HES alongside Amivisor:

• Extended meter configuration or firmware management is an ongoing operational need
• The vendor HES is actively used for specialized parametrization workflows
• Regulatory requirements mandate use of a certified vendor platform for certain metering functions

Bridging the two worlds — Amivisor.Bridge:

For deployments where both Amivisor and a vendor HES coexist, Amivisor offers a companion tool — Amivisor.Bridge — that solves a practical challenge: once a meter is connected via Amivisor’s communication channel, how does the vendor’s configurator software reach that meter for programming?

Amivisor.Bridge creates a transparent tunnel between the meter and the vendor’s configurator over the already-established Amivisor communication path. From the configurator’s perspective, it is communicating directly with the meter via a standard interface — while in reality, the data travels through Amivisor’s infrastructure. This eliminates the need for separate parallel communication channels or physical on-site access to meters, and allows remote meter parametrization using the vendor’s own tools through a single, unified connection.

Multivendor Integration Architecture

Applying the methods described above within a unified architecture allows Amivisor to serve as the central MDM-level aggregator for an enterprise or energy company’s entire HES fleet. Data from each HES — regardless of the acquisition method used — passes through the same VEE pipeline, is normalized into a single unified format, and becomes available across the platform’s analytical modules.

This approach aligns fully with the global practice of building multivendor AMI infrastructures, where the MDM layer decouples analytical applications from specific vendor systems and provides a normalized, consistent interface for all business processes.

Key advantages of Amivisor’s multivendor architecture:

• Energy companies retain their existing HES investments without costly replacements.
• Raw data from disparate systems is validated, normalized, and consolidated into a single analytical space.
• The platform scales gracefully: adding a new HES does not affect existing integrations.
• Support for multiple integration methods allows connecting any HES, regardless of its age, type, or technical openness.
• When needed, Amivisor can act as a full HES replacement through direct meter polling — eliminating dependency on any vendor platform entirely.

Integration Process

For launching integration with any HES system, Amivisor follows a consistent, well-defined process:

1. Technical audit — gathering information about the HES: vendor, version, API availability, DBMS type, documentation status, and network accessibility.
2. Method selection — based on the audit findings, the optimal integration method is determined.
3. Access provisioning — depending on the selected method: API documentation and test environment credentials; or VPN connection and database dump; or a file-exchange channel (SFTP, shared folder) with clearly defined file layouts.
4. Connector development and testing — carried out using Amivisor’s ready-made integration layer toolset.
5. Production launch — the integration is moved to live operation, with ongoing monitoring of data quality and delivery reliability.

---

Conclusion

Amivisor is a complete AMI platform combining HES and MDM capabilities. Many clients deploy it as a unified solution end-to-end. Others — particularly large enterprises with existing HES infrastructure — use Amivisor’s MDM layer to aggregate, validate, and analyze data flowing from multiple vendor HES systems.

The versatile integration toolkit described in this article — supporting international standards, vendor APIs, direct database access, digital twins, and file-based exchange — ensures that Amivisor can sit above any HES landscape, regardless of its complexity or age. It transforms fragmented meter data into a single, coherent analytical layer that serves the entire business.