IEEE Smart Village · Technology Committee · working draft · overview

Call for village microgrid designs

Overview · then one page each: Phase 1 · Phase 2 · Phase 3

Issuer ISV Technology Committee

Closes TBD

Contact Tech Comm Chair · adam.r.sauer@ieee.org

Introduction

Recent developments in the ecosystem of rural village energy metering systems in Africa have pushed several large metering service providers to open-source their software to allow for fully off-grid rural operations. Instead of Remote Operations, it is shifting towards On-Site Operations with Remote Monitoring. They servers, token credit systems, and other relevant operational control systems are hosted on-site with no cloud dependencies.

Open Metering Infrastructure

The current understanding is that several of these open-sourced systems will be collectively referred to as Open Metering Infrastructure. The basic layer becoming available provides customer meter monitoring and relay toggle from local teams, even if the grid is disconnected from the internet. ThunderCloud 2.0, published by EarthSpark on behalf of SparkMeter, is the first of potentially many implementations whose local deployment (referred to as GroundBolt when deployed locally) falls under Open Metering Infrastructure. It is anticipated that other brands like SteamaCo will have their equivalent systems published under Open Metering Infrastructure. We design this RFP for the purpose of documenting example deployments of these systems, effectively creating a snapshot of this pivotal moment in the industry.

The ladder

Phase	Award	What it is	Funded?
Phase 1	$25k	Brownfield Village Upgrade — existing village onto Open Metering Infrastructure. Model it in the Tech Comm simulator.	Yes
Phase 2	Up to $50k	Greenfield Neighborhood Install — one new neighborhood, state how many customers, with a neighborhood broker.	Yes
Phase 3	$150–250k	Greenfield Village Install — compose proven neighborhoods under one village: generation, storage, local servers, telecom.	Later — gated on P1+P2 data

Three grains

Grain	What to specify
Customer	The customer connection: meter, customer interface, prepaid/cutoff, WAN-down. Describe the billing plan; billing data is not required.
Neighborhood	One neighborhood circuit: trunk, poles, transformers, laterals, neighborhood-head monitor, neighborhood broker. State how many customers.
Village	Generation, storage, local servers (GroundBolt equivalent), reliable telecom. Local operations with remote monitoring. Cloud is sync, not the only brain.

Data access

Every phase requires geospatial and operational access. Billing data is not required. Proposers still describe the billing plan — how prepaid, vending, and cutoff will work — without handing over ledgers, credentials, or source.

Geospatial · required GIS of all system components (customers, laterals, neighborhoods, poles, xfmrs, gen, storage, village head-end). Permission to document. ISV converts lat/long to x,y from the largest energy asset when sharing for education.

Operational · required Read-only API or bulk export: customer reads, disconnects, outages, uptime. No write, no cutoff, no tariff change. Work with ISV to avoid PII.

Billing data · not required Describe the billing plan: prepaid vs postpaid, vending path, WAN-down credit and cutoff, and how it sits beside Open Metering Infrastructure. Ledgers, ARPU, credentials, and source are not required.

Phase 1 of 3 · funded · Brownfield Village Upgrade

Phase 1 — $25k · Brownfield Village Upgrade

Phase 1 upgrades an existing village that is already in operation — typically on EarthSpark (SparkMeter) or SteamaCo — onto Open Metering Infrastructure. These sites run today. What is fickle is the stability of vendor support. Now is the best time to move them to locally functional deployments that are not restrained by vendor restrictions: on-site operations, prepaid and cutoff that still work when the wide-area link is down, remote monitoring as a complement rather than a dependency.

Hardware already in the ground stays. The $25,000 pays upgrade work, operator training, modeling the as-built village in the Technology Committee simulator, and the written Open Metering Infrastructure record — not new customers, not new generation, not new lines.

If your team does not already operate an affiliated site, ISV is working with these meter providers to identify eligible villages and can introduce you.

Work

Named operating village — operator consent, current stack, why support is unstable, existing maps. Site size is whatever is already built.
Provider path — name your affiliated village, or work with ISV and the meter providers to pick an eligible site.
Simulator — enter the as-built village in the Technology Committee simulator. ISV tutorials; maps must already exist.
Upgrade record — what Open Metering Infrastructure includes, what ran on the prior stack, what changed, what was reused. WAN-down prepaid and cutoff specified.
Billing plan — describe prepaid vs postpaid, vending, and cutoff on Open Metering Infrastructure. Billing data is not required.
ThunderCloud 2.0 — allowed as the reference Open Metering Infrastructure implementation (GroundBolt when local). Not a brand lock.

Score (this phase)

Weight	Criterion
25%	Brownfield upgrade and model — named operating village, GIS in hand, EarthSpark or SteamaCo → Open Metering Infrastructure, in the simulator.
20%	One-month reviews — prior ops and Open Metering Infrastructure operations, one month each.
15%	WAN-down — credit and cutoff continue at the customer when the wide-area link is down.

Data access

Geospatial · required As-built GIS of the operating village, already in hand. All components. Permission to document. ISV anonymizes lat/long to x,y from the largest generation or battery asset.

Operational · required Read-only pre-upgrade API or export. Close Phase 1 with one month of historical ops and one month of Open Metering Infrastructure operations. No write, no cutoff, no tariff change.

Billing data · not required Describe how billing will run after the upgrade. Ledgers, ARPU, credentials, and source are not required.

Phase 2 of 3 · funded · Greenfield Neighborhood Install

Phase 2 — up to $50k · Greenfield Neighborhood Install

One new neighborhood of the proposer’s own design, compatible with Open Metering Infrastructure. State how many customers that neighborhood will serve. Award up to $50,000. At about $707 per new connection (SEforALL 2024), $50k covers on the order of 70 customers — a typical neighborhood if that count is tens to about a hundred. If you plan more customers than $50k can buy, say what the award covers versus what is co-funded or already in the ground.

Neighborhood broker — software and comms at neighborhood grain, not a second village cloud. It aggregates that neighborhood’s customers, localizes leakage and overload to the neighborhood trunk, can act on customer or board relays when WAN is down, and publishes northbound to the village Open Metering Infrastructure head-end. OpenAMI MQTT is an example path, not a mandated product.

Work

Itemized pack — specs and pricing at the customer, the neighborhood, the broker, and takeoff toward the village.
Architecture note — how this neighborhood composes 100 / 1,000 / 10,000 customers on paper. Name standards used (IEEE 2030.10, DLMS, STS or OpenPAYGO, OpenAMI).
Billing plan — describe vending, prepaid/cutoff, and settlement for this neighborhood and its customer count. Billing data is not required.
Simulator — the funded neighborhood must be complete enough to enter in the Technology Committee simulator.

Score (this phase)

Weight	Criterion
20%	Neighborhood and broker — customer count stated, priced and GIS-planned, compatible with Open Metering Infrastructure, up to $50k.
10%	Ready for the simulator — the Phase 2 neighborhood can be documented there.
10%	Honest cost — published industry bands; if $50k cannot cover the stated customer count, say what is co-funded or already built.

Data access

Geospatial · required Detailed GIS plan of every specced part of that neighborhood: customers, laterals, trunk, pole transformers, neighborhood-head monitor, broker, takeoff toward the village, and any generation or storage in the $50k. Layers match the BOM. OpenAMI-aligned GeoJSON preferred.

Operational · required Continued read-only ops access from Phase 1 and Phase 2 so Tech Comm can verify the investment and monitor reliability. Award stays in force only while that access continues.

Billing data · not required Describe the billing plan for this neighborhood. Ledgers, ARPU, credentials, and source are not required.

Phase 3 of 3 · Greenfield Village Install · not funded in this call · gated on Phase 1 + 2 data

Phase 3 — $150–250k · Greenfield Village Install

Phase 3 copies the proven Phase 2 neighborhood under one village: generation, storage, local servers, and reliable telecom that a $50k neighborhood award cannot buy. Neighborhood brokers federate to a village broker that runs on those local servers. Local operations; remote monitoring as sync. Prefer attaching those neighborhoods to the Phase 1 upgraded village so existing customers and new plant share one Open Metering Infrastructure head-end. Indicative award $150,000–$250,000. A second Open Metering Infrastructure implementation on the same neighborhood may be a Phase 3 gate.

What the village holds

Primary energy assets — generation, storage, and village switchgear.
Local servers — village Open Metering Infrastructure head-end and the village broker of neighborhood brokers. Prepaid and cutoff still specified to run when WAN is down.
Reliable telecom — backhaul and neighborhood radios. WAN-down at the customer is still required; the village link is for sync, monitoring, and northbound ops data.

What to design now (paper)

100 customers — how many of the proposer’s neighborhoods sit under one village, and what generation and storage sit with it.
1,000 / 10,000 customers — how many villages, how they federate. Same neighborhood architecture as Phase 2.
Billing plan — describe how the village vends across neighborhoods. Billing data is not required.

Data access

Geospatial · required GIS of the village and every neighborhood that takes off from it: generation, storage, switchgear, local servers, telecom, takeoffs. Same anonymize rule (x,y from the largest energy asset).

Operational · required Continued read-only ops access across Phase 1, the Phase 2 neighborhood, and the village. Reliability and investment success are judged on that stream. No write, no cutoff, no tariff change from ISV.

Billing data · not required Describe the billing plan for the village. Ledgers, ARPU, credentials, and source are not required.

Rights

Proposers keep design IP. Tech Comm may document packs in the simulator for review, education, and (if later deployed with an ISV partner) an as-built overlay. Phase 2 and Phase 3 awards remain in force only while ISV maintains geospatial and operational access sufficient to verify success. Billing data is never a condition of award. Public wiki pages will not publish named customers, real quotes, or NDA material.

Working draft for ISV leadership / Tech Comm review — dates and weights freeze before public issue. Not legal advice; not an IEEE standards ballot. isv.wiki