ISV IEEE Smart Village
← Meter Interoperability

Meter Interoperability

ISV Tech Comm primary endeavor · 2026

Mini-grid and village-energy operators need per-customer energy reads, prepaid billing, and theft visibility — without buying a full utility AMI stack. This section documents how ISV scopes affordable metering: normalize vendor-specific meter data at the gateway, publish a small northbound contract, and procure only what a feeder actually needs. IEEE Smart Village does not sell meters or head-end software — it uses IEEE’s agnostic place in the ecosystem to help those practices take hold.

Why IEEE · why ISV

Rural metering stalls when every vendor ships a closed AMI bundle, every tender copies utility MDMS boilerplate, and operators cannot swap gear without rewriting billing. Meter OEMs, integrators, open-platform builders (EnAccess, Energy IoT), and field operators all have legitimate interests — but no single commercial player can credibly write the common contract everyone else must adopt. IEEE sits outside those product lines: a neutral forum where ISV’s Technology Committee can convene stakeholders, compare field evidence, and publish reference artifacts without picking a winner.

That is the picture this section is building toward: a rural energy metering ecosystem that can flourish — more integrators bidding on the same scope, operators mixing OEM fleets on one feeder, migration paths when vendors exit, and open gateways that compete on implementation rather than proprietary lock-in. ISV turns alignment into draft specs (northbound MQTT, VMRS tiers, vendor benchmarks, POC gap matrices), validated on real deployments — not certified standards, but shared practice operators and vendors can point to. OpenAMI drives actionable energy telemetry on the same thread (geo asset model, gateways) — not a separate initiative from Street Pole EMS.

What ISV is normalizing

Procurement scope

Village tenders that paste “Cadillac” utility AMI requirements strand budgets. ISV documents a minimum viable northbound contract — what a 50–500 connection feeder actually needs for prepaid billing and theft visibility.

Gateway contract

Southbound stays OEM-specific (DLMS, RF mesh, Modbus). Northbound converges on one MQTT/JSON envelope so HES and MPM integrations are written once, regardless of meter brand under the pole.

Register semantics

OBIS keys are standardized; ICD exposure is not. VMRS tiers separate universal reads from model-specific gaps so procurement and integration arguments happen on a shared checklist, not vendor slide decks.

Field evidence

Anchor POCs (SteamaCo, Darway) publish which registers each model actually exposes — gap matrices operators can cite, integrators can bid against, and vendors can close without a proprietary certification gate.

Primary audience: operators, integrators, and vendors deploying STS prepaid, pole-mounted DCUs, and mixed OEM fleets in emerging markets.

Draft artifacts — not IEC/DLMS UA published standards.

Primary machine-readable spec: northbound-mqtt-v0.1.json. Register appendix: vmrs-registers.json. Human-readable tiers and OBIS keys: OBIS · VMRS.

Two deliverables

Northbound MQTT profile (v0.1)

  • JSON envelope from pole EMS / DCU to operator HES or MPM
  • Topic layout, register array, optional SIP session hooks
  • Gateway may speak DLMS, OEM RF, Modbus, or PLC southbound — MQTT/JSON northbound only

VMRS register checklist

  • ~10 OBIS keys every village billing case needs (import kWh, credit, tamper, disconnect, clock…)
  • Tier A (universal IEC) · Tier B (ICD varies) · Tier C (optional audit)
  • Explicit exclusions: full Profile Generic buffers, utility MDMS semantics, STSA key mgmt

Gateway normalization

Southbound protocols differ by meter OEM and NAN (RF mesh, PLC, GPRS). Requiring one wire protocol across a mixed fleet locks you to a single vendor. Instead, the edge gateway reads whatever the meter exposes locally, maps registers to OBIS semantics, and publishes one northbound shape.

Meter (DLMS / OEM / Modbus) NAN (RF · PLC · cellular) Pole EMS / DCU MQTT / JSON northbound Operator HES · MPM · billing

STS token vending (SMS, USSD, CIU keypad) stays on its own path — it is a payment layer, not the meter read protocol. See Problems for the full utility-vs-village layer diagram.

Why procurement goes wrong

“Cadillac” RFPs

Consultants and utility AMI playbooks get pasted into village tenders: full MDMS, Profile Generic load profiles, DLMS conformance matrices, and per-meter HLS on rural WAN. That is appropriate for a 500k-meter utility — not for a 200-connection feeder on a $40–110/connection budget. ISV scopes a minimum viable northbound contract instead.

Layer soup

STS, OBIS, DLMS, MQTT, and SunSpec sit at different layers. A single RFP line like “DLMS + STS + SunSpec” mixes prepaid vending (L6), register semantics (L5), wire protocol (L2), northbound format (L4), and inverter DER (parallel track). Problems maps each layer.

OEM lock-in

Closed AMI platforms (mesh + cloud + MDMS bundle) ship fast but block second-source DCUs and migration. Northbound normalization lets operators swap meter OEMs while keeping one HES integration — if the gateway exposes VMRS-shaped JSON.

Comms fragility

When the DCU or WAN link fails, customers still need STS tokens. CIU keypads, SMS vending, and redundant NAN paths must work independently of scheduled DLMS reads. May 2026 call notes cover SMS token delivery and phone-relay fallbacks.

Sub-pages in this section

Field validation

Anchor POCs compare vendor ICD maps against northbound-mqtt-v0.1 on real feeders and publish gap matrices (which OBIS keys each model actually exposes).

SteamaCo

  • Nimbus / Savi stack — closed AMI with DLMS claims; benchmark for migration path to open northbound
  • Power Africa workshop pre-session (Warren Scott) · Kenya deployment context

Darway

  • Feeder-scale pilot target for pole EMS + MQTT envelope on schedule
  • ICD extraction and tier B register gaps documented per model