> For the complete documentation index, see [llms.txt](https://india-energy-stack.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://india-energy-stack.gitbook.io/docs/use-case-implementation-guides/smart-meter-data-exchange.md). # Smart Meter Data Exchange **A standard, audit-trailed way to exchange smart-meter telemetry between an AMISP, a DISCOM, a state regulator, and consented third parties — over** [**IES Data Exchange**](/docs/what-ies-provides/discover.md)**, carrying the** [**MeterData**](/docs/schemas/meterdata.md) **payload (currently `v0.6`).** You replace bespoke FTP drops, proprietary MDMS APIs, and CSV email attachments with one signed, schema-validated flow. The same surface area works AMISP→DISCOM, DISCOM→SERC, and DISCOM→consented-third-party. > For consumer-pull of *their own* meter data (one-meter, on-demand, wallet-shareable), see [Consumer Meter Digest](/docs/use-case-implementation-guides/consumer-meter-digest.md). This guide is the bulk, scheduled, machine-to-machine flow. For the standards basis and full field schedule, see the [**Overview**](/docs/use-case-overviews/smart-meter-data-exchange.md). *** ## Building blocks used This use case is a thin composition over four existing building blocks. The setup steps below map one-to-one to them — read the building-block pages for the detail; come back here for what changes for the meter-data case. | What you need | Building block | What it gives you | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | A name and a signing key your counterparties can verify | [Identifiers & Addressing](/docs/what-ies-provides/register.md), [Registries](/docs/what-ies-provides/register.md#the-directory-dedi) | A DeDi namespace under your control and your current public key published into it. A formal `did:web` document is **not** required for this use case; the namespace + key are enough for Beckn signing and verification. | | A trust boundary — "who can transact on this network" | [Registries — IES networks today](/docs/what-ies-provides/register.md#the-ies-networks-today) | Your subscriber record referenced in the IES network registry | | The transport that carries discovery, contract, audit, and the payload | [Data Exchange](/docs/what-ies-provides/discover.md) | The Beckn lifecycle + ONIX adapter; the same `accessMethod` covers inline payloads and signed-URL handoff | | (Optional) Cryptographic proof that the requester is authorised | [MeterDataRequestCredential](/docs/schemas/meterdatarequestcredential.md) | A signed credential the seeker attaches at `confirm`; provider verifies offline | *** ## The dataset — `MeterData/v0.6` The payload is the [MeterData](/docs/schemas/meterdata.md) compact-profile schema (currently `v0.6`). v0.6 standardises eight profile shapes covering every smart-meter cadence: | Profile | Carries | | --------------- | -------------------------------------------------------------------- | | `CUSTOMER` | Slow-changing customer / service-point / meter installation metadata | | `INTERVAL` | Block load survey at 15- or 30-minute resolution | | `DAILY` | Daily accumulated load survey | | `MONTHLY` | Monthly billing resets (cumulative kWh, ToU buckets, MD) | | `BILL_DETAILS` | Utility-side billing computed details | | `INSTANTANEOUS` | Real-time snapshot of V / A / P / Q | | `EVENT` | IS 15959 diagnostic / tamper events | | `ALARM` | Real-time active alerts | For the Indian-terminology mapping (OBIS codes, IS 15959 event IDs, CIM master-data fields) see the companion page [IES Meter Data Model](/docs/use-case-implementation-guides/smart-meter-data-exchange/ies-meter-data-model.md). *** ## Optional consent — `MeterDataRequestCredential` When a third party (a consented app, a researcher, sometimes a regulator) is the BAP, the provider's offer policy can require an authorisation credential at `confirm` time. IES uses [`MeterDataRequestCredential`](/docs/schemas/meterdatarequestcredential.md) — a W3C VC 2.0 that wraps a [`MeterDataRequest`](/docs/schemas/meterdatarequest.md) and identifies the requester, scopes the request (which meters, which time window, which profile), and is signed by the authoriser (typically the DISCOM, sometimes the consumer themselves via OpenCred). ``` Seeker (BAP) Provider (BPP) e.g. consented app, SERC e.g. AMISP, DISCOM │── confirm ─── { MeterDataRequest } ─── │ + MeterDataRequestCredential ──>│ │ ├─ verify VC: type ✓ │ │ validUntil ✓ │ │ DeDi status ✓ │ │ scope ⊆ contract │<── on_confirm / on_status — MeterData/v0.6 ────│ ``` The provider checks credential type, expiry, DeDi revocation status, and that the embedded request scope is within the contracted scope — no callback to the issuer. *** ## Setup: Register → Discover → Exchange The order below takes you from zero to a working AMISP → DISCOM flow on the local devkit, then upgrades to the real IES network. ### 1. Decide scope Meter population, geography, granularity (15-min / daily / monthly), counterparties (AMISP→DISCOM only, DISCOM→SERC, DISCOM→third-party). Phase 1 should be one cadence and one counterparty. ### 2. Register — get a network identity Both BAP and BPP need a DeDi subscriber record with a published signing key. If you have one already (any other Beckn flow on this network), reuse it. If not, follow [**Setup Register**](/docs/how-you-implement-ies/setup-register.md). You do **not** need to rename anything in your CIS, MDMS, or asset registers. Your existing IDs are reused as the tail of the DID. ### 3. Discover — stand up the Data Exchange adapters Both sides run an [ONIX](/docs/glossary.md#onix) adapter → [**Setup Exchange**](/docs/how-you-implement-ies/setup-exchange.md). The fastest start is the devkit sandbox: ```bash git clone https://github.com/beckn/DEG.git cd DEG/devkits/data-exchange/install docker compose up -d ``` This brings up `sandbox-bap`, `sandbox-bpp`, and `beckn-router` pre-wired with placeholder identities. ### 4. Exchange — publish your dataset catalogue (BPP) Publish a Beckn catalogue entry for the `MeterData/v0.6` dataset you offer — `programID`, geographic scope, refresh cadence, [`accessMethod`](/docs/how-you-implement-ies/setup-exchange.md) (`INLINE` for ≤MB-scale chunks; `SIGNED_URL` for daily/monthly bulk), and any required credentials (point at `MeterDataRequestCredential` if you require one). Pre-agreed bilateral subscriptions can skip `discover` and go straight to `confirm`. ### 5. Exercise the flow The minimal lifecycle is `confirm` → `on_confirm` → (`status` → `on_status` if delivery is asynchronous): | Step | Sender | What happens | | ------------ | ------ | ------------------------------------------------------------------------------------------------ | | `confirm` | BAP | Requests data for a meter list + date range. Optionally attaches a `MeterDataRequestCredential`. | | `on_confirm` | BPP | Acknowledges; declares whether delivery is inline or async. | | `on_status` | BPP | Delivers `MeterData/v0.6` inline or returns a signed-URL pointer. | The payload sits inside `message.contract.commitments[].resources[].resourceAttributes` qualified with the DDM `DatasetItem/v1.1` context — see [Data Exchange — `DatasetItem` and `accessMethod`](/docs/how-you-implement-ies/setup-exchange.md). ### 6. Connect your real metering system Replace the sandbox response with a live connection to your HES / MDMS. Verify the Indian-OBIS → `MeterData/v0.6` mapping for every reading you ship — [IES Meter Data Model](/docs/use-case-implementation-guides/smart-meter-data-exchange/ies-meter-data-model.md) is the reference. ### 7. (Optional, at the end) Adopt the `did:web` convention for meters and assets **There are no new IDs to allocate.** Your existing meter SLNOs, DT codes, feeder codes, and substation codes are the IDs of record and stay exactly as they are. The IES convention is a `did:web` wrapper format that reuses those existing IDs: ``` did:web::meters: did:web::dts: did:web::feeders: did:web::substations: ``` `` is your own domain — the same one your `did.json` and DeDi namespace hang off (see [Setup Register §1.1](/docs/how-you-implement-ies/setup-register.md)). The DID method is always `did:web`, so these resolve under your domain exactly like your organisation DID; DeDi acts as the discovery and verification layer for your namespace — see [Glossary → DeDi](/docs/glossary.md#dedi) and [Identifiers — Appendix C](/docs/what-ies-provides/register.md#identifier-patterns). This step is *nice to have*, not a blocker for first deployment — initial flows can use bare IDs inside `MeterData` payloads and adopt the `did:web` form incrementally. *** ## Checklist for your meter-data rollout For the **underlying network onboarding** (DeDi subscriber, ONIX, signing keys, sandbox→test→prod cut-over), follow [**How you implement IES**](/docs/how-you-implement-ies/how-you-implement-ies.md). Don't duplicate those items here. The items below are **meter-data-specific** additions on top of that checklist: * [ ] Meter population, geography, granularity, and counterparty for Phase 1 agreed * [ ] Source system mapped (HES / MDMS endpoint, owner team, SLA) * [ ] Indian-OBIS → `MeterData/v0.6` mapping verified for every reading and event you ship (see [IES Meter Data Model](/docs/use-case-implementation-guides/smart-meter-data-exchange/ies-meter-data-model.md)) * [ ] Data-quality flags (missing / estimated) handled per the v0.6 `validationStatus` enum * [ ] Catalogue entry published (`programID`, geographic scope, refresh cadence, `accessMethod`, credential requirements) * [ ] (If third-party access in scope) `MeterDataRequestCredential` verification wired into the BPP — type, validity, DeDi status, scope ⊆ contract * [ ] (Optional) `did:web` convention adopted for meters / DTs / feeders — wrapping (not replacing) existing internal numbers, so VCs can be issued about them * [ ] IT/data SPOC nominated; Authorised Signatory nominated *** ## Open items * **Chunking convention** for bulk historical pulls (daily / monthly / quarterly) is being agreed across deployments. * **Quality flags** — the v0.6 `validationStatus` enum is stable; the recommended profile of allowed values per cadence is being tightened. *** ## References * [MeterData — schema and examples](/docs/schemas/meterdata.md) (current: `v0.6`) * [MeterDataRequest — request payload schema](/docs/schemas/meterdatarequest.md) (current: `v0.6`) * [MeterDataRequestCredential — authorisation VC](/docs/schemas/meterdatarequestcredential.md) (current: `v0.1`) * [IES Meter Data Model](/docs/use-case-implementation-guides/smart-meter-data-exchange/ies-meter-data-model.md) — OBIS / IS 15959 / CIM → MeterData v0.6 mapping * [Overview — Smart Meter Data Exchange](/docs/use-case-overviews/smart-meter-data-exchange.md) — standards basis, definitions, full field schedule * [Data Exchange chapter](/docs/what-ies-provides/discover.md) * [Registries and Directories](/docs/what-ies-provides/register.md#the-directory-dedi) * [Identifiers and Addressing](/docs/what-ies-provides/register.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://india-energy-stack.gitbook.io/docs/use-case-implementation-guides/smart-meter-data-exchange.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.