Meter data management

Effective-dated metering context, measurement versions, VEE, Usage, technical Bill Determinants and delivery.

PRODUCT OVERVIEW

From a reading to a traceable data product.

AetherMDMS sits between the head end and financial billing. It owns effective-dated metering context, measurement versions, VEE, Usage, technical Bill Determinants, technical energy balance and data delivery with lineage.

A Metering Point and its installation history are MDMS objects. Customer/service identity stays in CIS, spatial truth in GIS and financial tariffs, bills and payment in Revenue.

Who it is for

Metering-data and data-quality teams
Metering-master and replacement teams
Billing-data, integration and technical-balance analysts

Concept metering data illustration: intervals, version layers, accepted data and meter-replacement context. — Concept illustration of the product responsibility. It is not a customer installation or an operational record.

Responsibilities and evaluation scope

Metering context: Approved design scopeEffective-dated append-only installations, physical/logical channels, registers and CT/PT/multiplier versions; Metering Point list and 360 projections.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Replacement continuity: Approved design scopeOld/new interval references, half-open installation boundaries and restart-safe lineage. This does not prove cumulative-register kWh offset continuity.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Canonical measurement versions: Approved design scopeSeparate immutable received, normalized, validated and estimated records with input versions, event/correlation/causation identities and hashes.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
VEE: Approved design scopeMissing interval, spike and clock-drift rules. Linear interpolation only fills a gap between compatible normalized boundary readings.; Available in this editionThree rules and bounded interpolation are available locally. Browser editing and approval are synthetic demonstration interfaces.
Usage and Bill Determinants: Approved design scopeAccepted 15-minute average kW becomes kWh Usage and append-only provisional total-consumption determinants. An incomplete window produces no determinant.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Data delivery: Approved design scopeImmutable products and approved subscription versions; async-event and batch-file datasets or REST-pull, with every attempt, acknowledgement, retry and supersession traced.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Lineage and replay: Approved design scopeConnect reading references, versions, VEE, Usage, determinants, delivery and acknowledgement. Sandbox replay compares pinned hashes without re-sending delivery.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Quality and lifecycle evidence: Approved design scopeEvidence reports match, mismatch or incomplete; no quality score is calculated without a configured formula. Lifecycle runs return local dry-run decisions only.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Technical energy balance: Approved design scopeQuality-aware balances from persisted Usage and immutable valid-time topology snapshots, with residual and anomaly evidence for investigation.; Available in this editionBounded local component for evaluation; deployment conditions require project-specific acceptance.
Standards mapping: Approved design scopeVersioned field mapping aligned with IEC 61968-9.; Available in this editionEvaluation mapping; conformance has not been validated.

How the work connects

The original diagrams and interface excerpts below are in English. The surrounding description explains their scope in the page language.

MDMS design: decoded references, versions, VEE, Usage, technical determinants, delivery, acknowledgement, lineage and replay. — Design workflow. The relationships shown are not a claim of running cross-product integration.

Clear responsibility across products

AetherHES: Supplies decoded readings and acquisition references. MDMS owns neither device sessions nor device control and never reads the HES private store.
AetherCIS / AetherGIS: CIS owns service identity; Service Point and Metering Point remain different objects. GIS owns spatial/network truth; MDMS pins the topology version used in a calculation.
AetherRevenue / AetherDispatch: Revenue owns tariffs and financial bills; MDMS supplies technical Usage and Bill Determinants. Dispatch owns field work; MDMS commits the validated installation and continuity.

Utility scenarios

Replace a meter without losing context

Retain effective-dated installations, CT/PT ratio history and adjacent interval references; review field evidence before committing installation continuity.

Investigate a suspect interval

Follow separate received, normalized, validated and estimated versions with input lineage; demonstration corrections do not prove a live approval workflow.

Deliver data and read the answer

Follow the product version, delivery attempt, recipient acknowledgement and any retry or supersession as separate evidence.

Review a technical energy balance

Pin persisted Usage and a valid-time topology snapshot, then investigate residuals together with input quality; this is technical analysis, not financial settlement.

Evaluation views · synthetic data

The original diagrams and interface excerpts below are in English. The surrounding description explains their scope in the page language.

Synthetic Metering Point 360 and CT/PT ratio history. — Evaluation interface excerpt with synthetic data. Identifiers, amounts, dates and counts are examples, not customer or performance evidence.

Synthetic measurement explorer with an estimated block and a sample correction. — Evaluation interface excerpt with synthetic data. Identifiers, amounts, dates and counts are examples, not customer or performance evidence.

Synthetic MDMS operations, billing readiness and exception summary. — Evaluation interface excerpt with synthetic data. Identifiers, amounts, dates and counts are examples, not customer or performance evidence.

Edition and evaluation conditions

Bounded local evaluation covers the metering read model, continuity, measurement versions, three VEE rules, Usage, provisional determinants, delivery, replay and technical balance. Most local services require Node.js 24+.

Browser editing, approval, settlement and replacement-wizard screens use synthetic data. Normalization does not cover every time-zone, unit or late-data case. TOU and maximum demand are later scope; price and tax belong to Revenue.

Production adapters, authentication and authorization require project configuration. Local append-only SHA-256 evidence is not a capacity or availability claim. Retained prepayment tests use deterministic test tokens, not production STS.

Document edition 2026.10 identifies the supplied documents, not a commercial release or a deployed version.

Product documents

Choose a language to download the matching document edition.

AetherMDMS Datasheet · English (PDF)English · PDFDocument edition 2026.10
AetherMDMS Catalogue · English (PDF)English · PDFDocument edition 2026.10

Discuss an evaluation ↗

EXPLORE OTHER LINES

AetherEdge™Smart Metering→

AetherLink™Communication Modules→

AetherNexus™Data Concentrators & Gateways→

AetherSol™Solar Power Electronics→