Buurtnet

Dit ontwerp beschrijft het beoogde gebruiksscenario voor het dataproduct Buurtnet, alsmede de achterliggende architectuur en gemaakte keuzes.

Voor alle data-uitwisseling binnen de scope van de Visie Datadelen is expliciet gekozen voor het denken over data in de vorm van dataproducten. Een dataproduct combineert de semantische-, technische- en gebruiksaspecten van data-uitwisseling. Om dit invulling te geven bestaat een dataproduct uit de volgende componenten:

  • dataset: de daadwerkelijke gegevens die worden uitgewisseld. Zie een dataset als een tabel met gegevens, waarbij de kolommen beschrijven wat er op elke rij van de data aan gegevens wordt geleverd. Een dataset voor aansluitingen zal minstens een kolom "Aansluitingsnummer" bevatten, waarbij elke rij in de dataset een aansluiting beschrijft;

  • dataservice: de (technische) manier van verspreiden van de dataset. Dit gaat over hoe de data ontsloten wordt, de onderliggende architectuur en de gebruiksscenario’s;

  • voorwaarden: er kunnen voorwaarden liggen op beschikbaarheid, kwaliteit, classificatie en doelbinding bij gebruik van het dataproduct.

Het dataproduct combineert de dataset en dataservice, verrijkt met voorwaarden voor gebruik.

Reikwijdte

Dit dataproduct verstrekt de informatie voor de volgende gebruikersscenario’s:

  1. Wijkbewoners activeren om hun energie-gebruik en -opwek in balans te brengen op basis van beschikbare data, zodat de MSR (trafostation) niet overbelast raakt. Door het aanjagen van zelforganisatie en gedragsverandering hopen we piekbelasting te reduceren en spanningsklachten te verminderen waarmee de wachttijd voor wijkgerichte verzwaring wordt overbrugd;

  2. Klanten in (kritieke) wijken inzicht en handelingsperspectief bieden.

Functionele eisen

Het dataproduct is onderheving aan functionele eisen: wat het dataproduct moet doen.

Table 1. Functionele eisen
Als Rol Wil ik Want

Klant

De belasting van de transformator(en) in het netstation in mijn wijk inzien (actueel, 24 en 48 uur geprognotiseerd)

Dan krijg ik inzicht in de momenten van overbelasting en kan ik mijn gedrag daarop kan aanpassen.

Klant

Meldingen van momenten waarop overbelasting wordt verwacht ontvangen

Dan kan ik mijn gedrag hierop aanpassen en helpen de overbelasting te voorkomen.

Netbeheerder

Expliciet onderscheid tussen Acceptatie en Productie

Ik wil controle over het moment waarop datasets beschikbaar gemaakt worden aan een klant en kwaliteitsbeheersing op de dataset.

Netbeheerder

Zonder menselijke interventie nieuwe datasets aanleveren

Ik wil de betrouwbaarheid van mijn interne processen verhogen.

Dataservice

De gebruiksscenario’s beschrijven niet het uitvalproces (happy flow), deze stappen dienen apart beschreven en geïmplementeerd te worden.

Gebruiksscenario

Het volgende gebruiksscenario wordt ondersteund:

Gebruiksscenario
Figure 1. Gebruiksscenario
  1. Elke netbeheerder levert twee datasets aan EDSN met connectiviteit & belasting voor het LS-net binnen het dekkingsgebied van de netbeheerder;

  2. EDSN verwerkt de datasets en stelt deze beschikbaar aan afnemers. Hiervoor consolideert EDSN de aangeleverde datasets van de verschillende netbeheerders voor centrale ontsluiting;

  3. EDSN bevestigt ontvangst en verwerking van de datasets aan de netbeheerder;

  4. Een klant vraagt de geconsolideerde datasets op bij EDSN;

  5. EDSN levert de geconsolideerde datasets.

Architectuur

Vanuit architectuurperspectief zijn de volgende keuzes gemaakt:

Architectuur
Figure 2. Architectuur
  • de structuur van de dataset behorende bij het dataproduct is gebaseerd op het Begrippenmodel NBNL (betekenis) en NBNL Profile Group (structuur);

  • er worden drie dataproducten beschikbaar gesteld door de netbeheerder vanuit het Dataloket van de netbeheerder. Er worden drie JSON-LD bestanden aangeleverd aan EDSN, conform bovenstaand architectuuroverzicht (zie Dataset);

  • EDSN verwerkt de aangeleverde dataproducten tot geconsolideerde datasets en ontsluit de datasets als JSON-LD bestanden of vanuit een REST API TODO: alignment met systeemarchitectuur EDSN.

Dataset

Voor de informatiebehoefte van Buurtnet worden drie dataproducten vanuit de NBNL Profile Group (her)gebruikt:

  • Equipment (EQ): connectiviteit voor het LS-net, definitie van netfuncties voor de overige dataproducten;

  • Operation (OP): belasting van transformatoren in het LS-net;

  • GeoLocation (GL): locatie van aansluitingen in het LS-net;

  • Topology (TP): koppeling tussen overdrachtspunt en transformator.

Volume, variety, veracity, velocity

Data kent vier kenmerken:

  • volume: data kent een volume, een hoeveelheid;

  • variety (variëteit): data is te verdelen in gestructureerde en ongestructureerde data. Ongestructureerde data kent geen metamodel;

  • veracity (betrouwbaarheid): de mate waarin de data vertrouwd kan worden voor de toepassing;

  • velocity (snelheid): de frequentie waarmee data verandert.

Dataproduct Volume Variety Veracity Velocity

Equipment

Midden, < 300MB (ongecomprimeerd)

Gestructureerd

Hoog, de dataset wordt samengesteld uit gegevens voor connectiviteit en aansluitingen.

Laag, verandert alleen wanneer de connectiviteit van het LS-net verandert

Operation

Midden, < 300MB (ongecomprimeerd)

Gestructureerd

Hoog, minimaal één maal per 24 uur (zie Functionele eisen)

GeoLocation

Laag, < 100MB (ongecomprimeerd)

Gestructureerd

Laag, verandert alleen wanneer de connectiviteit van het LS-net verandert

Topology

Laag, < 100MB (ongecomprimeerd)

Gestructureerd

Laag, verandert alleen wanneer de connectiviteit van het LS-net verandert

Voorwaarden

Deze dataproducten worden als open data aangeboden.

Beslissingen en aannames

Datum Type Beschrijving

01-03-2025

Beslissing

Er is gekozen voor een open dataproduct in fase 1.

02-12-2025

Aanname

Er is in fase 2 gekozen voor een open dataproduct. Dit houdt in dat er in dit ontwerp geen rekening wordt gehouden met alle faciliteiten die nodig zijn om een gesloten dataproduct te ontsluiten. TODO: Een positief advies van GEMS is vereist om deze beslissing definitief te nemen.

02-12-2025

Aanname

Er is in fase 2 gekozen voor centrale dataproducten. Netbeheerders leveren hiervoor datasets aan bij EDSN.

02-12-2025

Beslissing

Er is gekozen voor twee fases. In de eerste (pilot) fase wordt de data aangeleverd in een Excel-bestand. Voor de tweede fase is er gekozen voor het bulk-integratiepatroon, waarbij elke deelnemende netbeheerder data ontsluit via JSON-LD bestanden richting EDSN. Dit ontwerp beschrijft fase 2.

02-12-2025

Beslissing

EDSN biedt faciliteiten voor de processen Extract, Load en Transform, waarbij de consolideerde data van de netbeheerders via JSON-LD en REST API wordt ontsloten. Dit is inclusief filteren van de via het Load-proces ontsloten datasets.

02-12-2025

Beslissing

Data ontsloten voor Buurtnet wordt als meerdere generieke bouwblokken aangeleverd om hergebruik en interopabiliteit van de data te verhogen. De concrete impact van deze keuze is dat de netbeheerder meerdere JSON-LD bestanden aanlevert, die naar elkaar verwijzen.

04-12-2025

Beslissing

Belasting vanuit Operation wordt direct aan Equipment (connectiviteit) gekoppeld via mRID.

04-12-2025

Beslissing

De dataproducten zijn vindbaar via het NBNL Dataportaal.