Skip to content

Almelo/Aadorp — Positive Energy District#

Profile owners: City of Almelo + Almelo Energie (energy services: HyEnSys) · LDT-UC-02 · Status: 🟠 skeleton pre-filled

1–2 · Identity, problem & context#

The Aadorp Positive Energy District must balance local generation, storage and demand so the district produces more energy than it uses — and prove it. The twin computes hourly balances, costs, emissions and network impact (ESSIM/DEMkit); the LDT adds trustworthy data exchange with grid parties, the Marketplace of the EU LDT Toolbox and other sites.

3 · Objectives & KPIs#

Decided Metrics: kgCO₂e per building and per district scenario; renewable share; peak-impact metrics; community participation rate.

Needs owner — Almelo Energie, with the City of Almelo.** Baseline, target and measurement window per metric, as for every profile. Two PED-specific points the scheme needs stated explicitly: whether each figure is measured or modelled (ESSIM/DEMkit outputs are modelled, and conflating the two is the error that discredits PED claims — see Descriptions section 4), and the measurement boundary — building, block or district — since "positive energy" is only meaningful against a stated boundary.

4 · Stakeholders#

City of Almelo, Almelo Energie (community energy cooperative — also data-rights holder representative for households), HyEnSys (Commons and energy services), residents.

Needs owner — City of Almelo + Almelo Energie.** The DSO is the open question with the largest consequences in this profile. Flexibility and balance data flowing to grid parties is already foreseen under a bilateral annex to the standard data-sharing terms, but no grid operator is confirmed as a participant. Three things are needed: whether the DSO participates at all; if so, whether as a full participant with an accession agreement or as a counterparty under a bilateral annex only; and whether NL energy-market rules constrain what may be shared with it. Until this is settled the annex in Contractual framework is drafting against an unknown counterparty.

5 · Data needs & sources#

Smart-meter / household energy data (personal and sensitive — consent via Commons), generation and storage telemetry, ESSIM/DEMkit model outputs, weather.

The signed application names the sources this twin runs on today: ESSIM/DEMkit energy-system model outputs, weather and demographic datasets, and public spatial and infrastructure layers. They are ingested through ETL with quality assurance into a combined geo and time store with a metadata catalogue; scenarios are authored in ESDL using the open-source ESDL MapEditor and executed in ESSIM/DEMkit to compute hourly balances. Household data is not in that list — it is what the Commons controls have to make possible, not what the twin already holds. (Source: EUTwinLink LDT4SSC WS1 Application Form §1.7, Annex 4 to the Pilot Grant Agreement.)

Needs owner — Almelo Energie.** Source inventory: format, frequency, resolution, quality, and personal-data status per source, as the precondition for Data models and Data exchange.

The resolution of the household meter data is the critical figure. It determines the aggregation floor the scheme must enforce: high-resolution household consumption reveals occupancy and behaviour, and the ODRL constraint protecting it cannot be written until the resolution and the intended aggregation level are known. Also needed: whether telemetry frequency justifies streaming (MQTT) rather than the scheme's default request/response — see Data exchange section 1.

6 · Sharing rules this use case needs from the scheme#

  • Household-level data shared only aggregated or with explicit Commons-mediated consent; ODRL constraints encode aggregation floors and purpose limits.
  • Flexibility/balance data to grid parties under bilateral annex to the standard data-sharing terms.
  • Scenario outputs (non-personal) publishable open-tier for replication by other PEDs.

7 · Architecture (building blocks used)#

ESSIM/DEMkit ↔ twin integration; EDC + iSHARE extension for external exchange; Commons controls as the policy layer; wallets for cooperative roles.

Proposed Blocks used: Access & usage policies (the Commons controls sit here, as the community layer above the baseline), Identity & attestation (cooperative roles as credentials; Almelo Energie as data-rights-holder representative is a delegation pattern the scheme has not yet modelled), Data models, Data exchange, Provenance.

Needs owner — HyEnSys.** Integration notes, and — more importantly — the Commons-controls specification this profile depends on, which is also the open 🧩 in Access & usage policies. Specifically: how a household joins, consents, delegates to the cooperative and leaves; how a community mandate is expressed so a PDP can act on it; and what happens when a Commons rule and a participant's policy conflict. This specification gates two building blocks and is the single most load-bearing missing contribution in the scheme.

8 · Timeline & maturity#

Decided Maturity: PED instrumentation is live; the LDT interconnection follows the WP7 plan.

Needs owner — City of Almelo + Almelo Energie.** Milestones with dates: Commons consent mechanism operational, first aggregated district indicator published, DSO exchange established (dependent on the open question in section 4), and ITB-S conformance of the exchange path. Dependencies: the Commons specification above, and the source inventory.

9–12 · Value, risks, EU alignment, materials#

Decided Value: proven PED operation; community ownership of data; replicable energy-community governance — the governance pattern being at least as transferable as the technology.

Proposed Risks and mitigations:

Risk Mitigation
Consent fatigue among households consent mediated once through the cooperative rather than per transaction; Commons delegation is the mechanism, and it is unspecified
Energy-data sensitivity (occupancy inference) aggregation floors as ODRL constraints; household-level data shared only aggregated or under explicit Commons-mediated consent
NL energy-sharing rules in flux rules tracked by Almelo Energie; the scheme's layering absorbs change by letting the use-case layer tighten without amending the baseline
Measured-versus-modelled confusion in PED claims metadata distinguishes them (section 3); provenance where figures become claims
Cooperative as single point of consent failure unmitigated — if the delegation to Almelo Energie is invalid, every household flow is affected at once

Decided EU alignment: EPBD, RED III energy communities, Green Deal.

Needs owner — City of Almelo + HyEnSys.** The last risk is the drafter's addition and needs a judgement from people who know Dutch cooperative and data-protection law: is a cooperative mandate a sound basis for household data delegation, and what happens to flows if it is challenged?