Advanced Metering Infrastructure (AMI) Platform

This project covers the head-end and data-management layers of an Advanced Metering Infrastructure platform: the HES that talks to meters and DCUs, the MDM that turns raw reads into billing-grade data, the STS (Standard Transfer Specification) prepayment/token infrastructure, and the standards-based data model tying it all together — built to run across meters from multiple vendors (Hexing, CHINT, XJ, and others) on the same platform.

Metering at utility scale is less about reading a meter than about everything downstream of it staying correct, auditable and vendor-neutral as the estate grows.

• Every vendor speaks its own dialect of the same standard. DLMS/COSEM is a standard, but OBIS code usage, event semantics and quirks differ between Hexing, CHINT, XJ and others. Building against any one vendor's behaviour means rewriting the platform for the next procurement round.
• Raw meter data is not billing data. Reads arrive with gaps, duplicates, clock drift and anomalies. Billing needs a defensible number, which means validation, estimation and editing (VEE) with an audit trail explaining every adjustment.
• Prepayment is a security problem, not a payment problem. STS token generation puts key management on the critical path — the keys behind vending have to be protected and their use auditable, or the revenue model is exposed to fraud.
• One platform, many utilities. Serving more than one utility from shared infrastructure requires tenant isolation for data and access control without duplicating the whole stack per customer.

Add to confirm: deployment scale (meters, DCUs, utilities), communication media in production, and which vendor models were certified against.

Head-end system (HES)

Built the head-end collection layer: Data Concentrator Units aggregating meter-level DLMS/COSEM traffic and relaying it upstream, with a normalization layer absorbing vendor-specific DLMS/COSEM quirks across Hexing, CHINT, and XJ hardware so the HES sees one consistent object model.

MDM integration

Implemented data exchange between the HES and MDM following CIM (Common Information Model), IEC 61968, giving the MDM and downstream billing/customer systems a vendor-agnostic, standards-based view of meter data.

STS prepayment and vending

Wired the prepaid path end to end — customer portal through MDM and HES to the meter — so a recharge results in a token the meter will accept, with acceptance and execution status flowing back to the portal rather than leaving the customer guessing.

Key management (KMS)

Placed STS key handling behind a key-management service acting as the token authority, so vending keys are issued and protected centrally and their use is auditable — keeping the fraud-sensitive part of prepayment out of the application layer.

Multi-vendor interoperability

Delivered protocol-level interoperability across Hexing, CHINT, XJ, and other vendors using DLMS/COSEM, Modbus, and CAN, with bulk provisioning, firmware update, and diagnostic workflows that work identically regardless of hardware vendor.

• A vendor-neutral AMI platform: adding a meter vendor is an adapter and a mapping template, not a change to the core platform.
• Standards-mapped end to end — IEC 62056 (DLMS/COSEM), IEC 62055 (STS), IEC 62052/53/54 metering requirements, and IEC 61968/61969 (CIM) for downstream integration — so the architecture is defensible to a utility's technical review.
• Billing-grade data with an audit trail: a VEE exception workflow that classifies gaps, duplicates, anomalies and time drift, routes them to the right operations queue, and records who changed what and why.
• Multi-tenant by design, with per-tenant raw, validated and audit stores behind shared platform services.
• An operations layer — meter status, regional distribution, load profiles and active alerts — giving utility staff a live view of the estate rather than a nightly report.

Add to confirm: meters and DCUs in production, utilities served, vending volume, and any certification or acceptance testing passed.