LINDA Documentatie
Introductie
Laadpaal Infrastructuur Data (LINDA) is een project van NDW, in opdracht van de G4 gemeenten en Nationale Agenda Laadinfrastructuur (NAL) regio's, welke het doel heeft om integrale laadinfrastructuur data beschikbaar te stellen.
Het LINDA Dataportaal verzamelt gegevens van openbare laadpalen om het gebruik van deze laadpalen inzichtelijk te maken en de behoefte aan nieuwe laadpalen te kunnen bepalen. Het LINDA Dataportaal is bedoeld om deze gegevens beschikbaar te maken voor beleid, onderzoek en ontwikkeling van nieuwe diensten. Daarmee draagt het bij aan beter inzicht en betere monitoring, ondersteunt het de energietransitie en klimaatdoelstellingen en stimuleert het samenwerking en efficiency.
De LINDA data wordt aangeleverd, opgeslagen en gedeeld via het dataportaal van NDW genaamd Dexter. Daarnaast is er een dashboard ontwikkeld te vinden op LINDA Dashboard, dit dashboard kan worden gebruikt om verschillende KPI's te visualiseren.
Betrokken partijen
Deze documentatie is tot stand gekomen in samenwerking met onderstaande partijen:
- NAL-regio's
- NDW
- Rijksdienst voor Ondernemend Nederland (RVO)
De NAL-regio’s verzorgen de afstemming met alle gemeenten binnen hun gebied. Zij hebben een informatieplicht, zowel naar de gemeenten die deelnemen in een concessie, als naar gemeenten met een open marktcontract.
Voor gebruikers/afnemers van data uit het LINDA Dataportaal geldt dat zij moeten instemmen met de voorwaarden, zoals vastgelegd in een Verwerkersovereenkomst.
Charge Point Operators
Charge Point Operators (CPO's) zijn betrokken bij dit project, zij leveren de data aan welke wordt ontsloten binnen dit dataportaal. De ontsloten CPO's betreffen:
| CPO | Beschikbaar sinds | Regio's |
|---|---|---|
| Allego | 01-2024 | Gelderland, Overijssel, Arhhem, Amsterdam |
| Equans (Greenflux) | 06-04-2023 | Groningen, Drenthe, Amsterdam, Utrecht (stad) |
| Equans (LMS) | 26-03-2023 | Zuid-Holland, Gelderland |
| Qwello | 21-06-2024 | Landelijk verspreid |
| Total Energies | 01-01-2023 | MRA-e, Friesland |
| Ubitricity | 07-2023 | MRA-e |
| Vattenfall | 01-01-2023 | Amsterdam, Gelderland-Overijssel, Brabant-Limburg, MRA-e, Utrecht (stad), Den Haag |
| WeDriveSolar (LMS) | 26-03-2023 | Utrecht (stad) |
Key Performance Indicators
De export KPI's zijn te vinden in het Dexter portaal. Tevens zijn op het Dexter dataportaal ook de losse CDR's te vinden. De dashboard KPI's zijn te vinden op de dashboard pagina van NDW. Onderstaande tabel toont alle KPI's die reeds berekend en onstloten worden, daarbij is aangegevne welke in de export te ontsluiten zijn en welke in het dashboard getoond worden.
| KPI (per maand - jaar) | Export | Dashboard | Beschrijving |
|---|---|---|---|
| KwH Sum | ✅ | ❌ | Totaal aantal KwH per maand |
| SessionCount | ✅ | ❌ | Totaal aantal unieke Charge Data Record (CDR) per laadpaal |
| Sessiongt24hPercent | ✅ | ❌ | Percentage van sessies die langer duurt dan 24 uur (Aantal sessies > 24h / Totaal aantal sessies) * 100 % |
| OccupancyRate | ✅ | ❌ | Aandeel bezetting per paal (som aantal minuten bezet) / (totaal aantal minuten beschikbaar) |
| NumberofUsedConnectors | ✅ | ❌ | Aantallen gebruikte laadpunten. Alleen connectors die voorkomen in een sessie worden geteld. Indien het aantal laadpunten per paal onbekend is, wordt deze op 2 gezet |
| numberofUnusedConnectors | ✅ | ❌ | Aantal ongebruikte laadpunten |
| averageKwhPerDay | ✅ | ❌ | Maandelijks gemiddelde kWh per laadstation (gemiddelde Kwh per locatie / (som KiloWattuur)/ (aantal palen), alleen zinvol op hoger aggregratieniveau dan laadpaal) |
| averageNumberOfSessionsPerDay | ✅ | ❌ | Gemiddelde aantal sessies per dag |
| sumAvailableHours | ✅ | ❌ | Totaal aantal mogelijke laaduren (totaal aantal uren dat er mogelijk geladen kan worden, indien meerdere connectors dan totaal aantal uren per maand * aantal connectors) |
| sumChargeTime | ✅ | ❌ | Totaal aantal uren dat er geladen is |
| averageNumberOfUniqueRfidPerDay | ✅ | ❌ | Gemiddelde antal unieke RFIDs per dag |
| HourlyOccupancyRates ( 0 - 23) | ✅ | ❌ | (Som aantal minuten bezet / (totaal aantal minuten beschikbaar) ) per uur van de dag |
| HourlyOccRatesPerDayOfWeek (01-07) (00-23) | ✅ | ❌ | (Som aantal minuten bezet / (totaal aantal minuten beschikbaar) ) per uur van de weekdag; Zondag = 1, Maandag = 2 |
| Gebruik laadpalen | ❌ | ✅ | |
| Sessies | ❌ | ✅ | |
| Verbruik | ❌ | ✅ | |
| Laaduren | ❌ | ✅ | |
| RFID's | ❌ | ✅ |
Uitsluitingen van laadsessies bij de KPI berekening
Bij het berekenen van alle KPI's, behalve: Som Kwh, % sessies > 24 uur en Maandelijks gemiddelde kWh per laadstation, worden CDR's uitgesloten die voldoen aan een van de volgende regels:
- De laadsessie duur (Verschil tussen start en eindttijd) < dan 10 minuten
- De hoeveelheid afgenomen stroom < dan 1 Kwh
Data sharing
Bij het LINDA Dataportaal zijn veel partijen betrokken. Dat betekent dat afspraken over het aanleveren, verzamelen, ontsluiten en gebruiken van data nodig zijn. Die afspraken staan hieronder.
Datalevering
- Het beschikbaar stellen van sessiegegevens van openbare laadpalen door een CPO aan NDW vindt uitsluitend plaats na een schriftelijke opdracht van de data-eigenaar. Als het data-eigenaarschap bij de contracthouder/concessiegever ligt, dan geeft die toestemming aan betreffende CPO. Ligt het data-eigenaarschap bij een CPO, dan geeft deze rechtstreeks toestemming aan NDW voor het toevoegen van sessiegegevens van openbare laadpalen aan het LINDA Dataportaal.
- Voor het vastleggen van de instemming wordt gebruik gemaakt van een standaard bevestigingsbrief tussen data-eigenaar en CPO, indien dat niet al in het contract is geregeld. De NAL-regio’s verzorgen deze standaard bevestigingsbrief en informeren alle gemeenten.
- De instemming van de data-eigenaar aan een CPO, geeft een CPO toestemming om sessiegegevens van openbare laadpalen beschikbaar te stellen aan het LINDA-dataplatform bij NDW.
- Een CPO stelt sessiedata van openbare laadpalen beschikbaar via de OCPI-standaard aan NDW. Specifiek gaat het voor het LINDA Dataportaal om toepassing van de Sessions module (CPO interface) en Locations module van de OCPI-standaard. Er wordt gebruik gemaakt van de meest recente, stabiele versie van OCPI 2.1.1, zoals beschreven op GitHub.
- NDW haalt de locatiegegevens van openbare laadpalen minimaal één keer per dag en de sessiegegevens elke twee weken op bij een CPO.
Aansluiten voor CPO's
Wanneer een CPO zich wil melden om data te leveren in het LINDA-dataportaal kan hij beginnen bij de NDW Servicedesk. LINDA ondersteunt OCPI versie 2.1.1 en 2.2.1. Tijdens het aansluitproces wordt een aansluit-document verstrekt welke verdergaande informatie verstrekt.
Datakwaliteit
- De verantwoordelijkheid voor de kwaliteit van de sessie- en locatiegegevens van openbare laadpalen ligt bij een CPO. Het uitgangspunt is “beheer bij de bron”.
- Een CPO zorgt dat gegevens die uitgewisseld worden via de Sessions-module van OCPI (een CDR-record) de velden bevat.
- Een CPO is verantwoordelijk voor het vastleggen van de daadwerkelijke, exacte locatie c.q. coördinaten van een openbare laadpaal, conform het betreffende verkeersbesluit en/of de verleende vergunning. Locatiegegevens worden aangeleverd aan het LINDA Dataportaal via de Locations-module van de OCPI-standaard.
- NDW controleert of de sessie- en locatiegegevens van openbare laadpalen die door een CPO worden aangeleverd, voldoen aan de kwaliteitseisen, zoals omschreven in Datakwaliteit. Wanneer data niet voldoet aan de kwaliteitseisen verwijdert NDW deze niet, we 'flaggen' ze wel zodat we laten weten dat wij vinden dat deze data niet voldoet aan de kwaliteitseisen.
Dataverzameling
- NDW is de technisch en functioneel beheerder van het LINDA-dataportaal en de onderliggende infrastructuur. Aan het beheer ligt een Dossier Afspraken en Procedures (DAP) ten grondslag tussen NDW en de NAL-regio’s.
- NDW heeft passende technische en organisatorische maatregelen genomen om de geleverde gegevens te beveiligen en te beschermen tegen ongeoorloofd of onrechtmatig gebruik, onopzettelijk verlies, vernietiging of beschadiging. NDW werkt volgens de algemeen erkende Baseline Informatiebeveiliging Overheid (BIO) beveiligingsnorm van de Rijksoverheid conform NEN-ISO/IEC 27001 en NEN-ISO/IEC 27002
Data-ontsluiting
- Data-eigenaren krijgen via het LINDA Dataportaal inzicht en toegang tot hun eigen gegevens.
- Data van het LINDA Dataportaal worden in twee vormen beschikbaar gesteld: KPI-data of CDR-data.
- KPI-data zijn geaggregeerde data die betrekking hebben op één van de mogelijke KPI’s zoals genoemd in KPI's. Beschikbare KPI-data worden door NDW beschikbaar gesteld aan geautoriseerde gebruikers via een exportmogelijkheid in haar Dexter-portaal of via een API. Toevoeging van nieuwe KPI’s loopt via de NAL-regio’s en gebeurt alleen als er middelen voor ontwikkeling en beheer van nieuwe KPI’s beschikbaar zijn.
- CDR-data zijn gegevens van individuele laadsessies, conform de OCPI-standaard. CDR-data worden door NDW uitsluitend beschikbaar gesteld aan geautoriseerde gebruikers via het Dexter-platoform en een REST API en in overeenstemming met de procedure voor een data-aanvraag.
- Bij CDR data kunnen individuele velden uitgesloten worden van data delen, als op basis van een data-aanvraag beoordeeld wordt dat betreffend veld niet gedeeld kan/mag worden met de aanvrager of niet past binnen doel van de aanvraag.
- Data die via een API beschikbaar worden gesteld, vereisen altijd een sleutel (API-key). Deze sleutel (API-key) is gekoppeld aan de aanvrager van de data (data-gebruiker) en onderdeel van de Verwerkersovereenkomst.
Datagebruik
- Iedereen kan een aanvraag indienen voor toegang tot de data. Dit betekent niet dat iedereen ook daadwerkelijk toegang krijgt tot de data. Elke aanvraag moet onderbouwd worden en wordt beoordeeld door het LINDA team. Alleen indien aan de voorwaarden wordt voldaan, wordt een aanvraag gehonoreerd.
- Elke data-aanvraag wordt geregistreerd in een register.
- Bij een positieve beoordeling ontvangt de aanvrager een gebruikersovereenkomst waarin de afspraken zijn vastgelegd. Er is een concept gebruikersovereenkomst beschreven.
- Na ondertekening van de gebruikersovereenkomst door de data-aanvrager (datagebruiker), stelt NDW de data beschikbaar aan de datagebruiker onder de voorwaarden zoals beschreven in de gebruikersovereenkomst.
- Indien geconstateerd wordt dat data oneigenlijk gebruikt worden of sprake is van een datalek, dan neemt NDW passende maatregelen, zoals het afsluiten van de data-gebruiker of het doen van een melding bij de Autoriteit Persoonsgegevens. Ook vindt terugkoppeling plaats aan de CPO’s zodat zij, indien nodig, aan hun wettelijke verplichtingen kunnen voldoen.
- Vooralsnog zijn de data alleen voor geautoriseerde gebruikers toegankelijk. Alle partijen streven ernaar om data die geen privacygevoelige gegevens bevatten, als open data beschikbaar te stellen, dat wil zeggen zonder beperkingen aan (her)gebruik. Pas na schriftelijke instemming van de data-eigenaar, worden data als open data beschikbaar gesteld.
Toegang
Zoals ook vermeld in Data sharing - Datagebruik is het mogelijk om toegang aan te vragen voor het LINDA dataportaal. Echter betekent dit niet dat je ook werkelijk toegang krijgt tot de data. Elke aanvraag moet onderbouwd worden en wordt beoordeeld door de NDW Servicedesk en het LINDA datateam. Alleen indien aan de voorwaarden wordt voldaan, wordt een een vraag gehonoreerd. Dit leunt voornamelijk op het feit of een gebruiker is aangesloten bij een deelnemende partij.
Datakwaliteit
Omdat er voor alle CPO's een aparte importer is gemaakt, vanwege verschillende implementaties van data delen bij de CPO's, worden er kolommen gemapped. Dus de .csv of .xlsx bestanden worden gevuld op basis van bepaalde values in de door de CPO's gedeelde data.
| CSV kolom | Beschrijving | OCPI 2.1.1 | OCPI 2.2.x | Allego | Overig |
|---|---|---|---|---|---|
| id | CDR id | cdr.id | cdr.id | sessionId | |
| location_id | ID van de locatie | cdr.location.id | cdr.cdr_location.id | Zelfde als charge_station_id | |
| charge_station_id | ID van de laadpaal | Zie sectie over charge station id bepaling | |||
| evse_id | ID van het laadpunt | cdr.location.evses[0].evseId | cdr.cdr_location.evse_id | connectorId | |
| connector_id | ID van de connector | cdr.location.evses[0].connectors[0].id | cdr.cdr_location.connector_id | connectorId | |
| token_uid | ID van het betaalmiddel | cdr.auth_id | cdr.cdr_token.uid | hashedTokenEvcoId of evDriverId | |
| start_date_time | Starttijd van de sessie | cdr.start_date_time | cdr.start_date_time | startDateTime | |
| stop_date_time | Eindtijd van de sessie | cdr.stop_date_time | cdr_end_date_time | endDateTime | |
| total_time | Totale tijd in uren dat de auto verbonden is | cdr.total_time | cdr.total_time | sessionDurationHrs | |
| total_parking_time | Totale tijd in uren dat de auto verbonden is, maar er niet geladen is | cdr.total_parking_time | cdr.total_parking_time | sessionDurationHrs - chargingDurationHrs | |
| total_energy | Totale hoeveelheid afgenomen energie in Kwh | cdr.total_energy | cdr.total_energy | consumedEnergyKWh |
Voorbeeld csv
id,location_id,charge_station_id,evse_id,connector_id,token_uid,start_date_time,stop_date_time,total_time,total_parking_time,total_energy
BFEEB3627CA34BC1BD402EE01D27646E,0907f10d-fa10-46ac-8186-c12d11950a76,NL*GFX*ETNLP030085,NL*GFX*ETNLP030085*1,1,NLCPIC002CSL7Z,2025-03-01T18:53:37Z,2025-03-02T10:35:51Z,15.7039,8.4308,22.83
Validatieregels
Tijdens de verwerking van de CDR's worden validaties uitgevoerd. Een aantal validaties zijn bedoeld om te controleren of een CDR door ons verwerkt en opgeslagen kan worden. CDR's die hier niet aan voldoen worden genegeerd. Hiervoor controleren we op het volgende:
- Startdatum in de toekomst
- Location id niet aanwezig
- Charge station id kan niet bepaald worden
Datakwaliteit toetsen
De laadpaaldata wordt beoordeeld op kwaliteit aan de hand van verschillende testen. Dagelijks wordt per EVSE ID gecontroleerd of de data aan de testcriteria voldoet. Als een test herhaaldelijk faalt en als 'verdacht' wordt beschouwd, verschijnt de betreffende EVSE ID in Janet. Dit kan al na één dag gebeuren, maar ook pas na meerdere opeenvolgende dagen van falen. Hieronder volgt een overzicht van de huidige testen met een korte toelichting.
| test_id | Uitleg |
|---|---|
| t_duplicate_different_socket_session | laadsessie met identieke start_date_time, total_energy en token_uid, maar met andere connector_id |
| t_exceeding_capacity | aantal laadsessies bij een locatie is op een moment groter dan het aantal laders wat die locatie heeft |
| t_extreme_total_energy | totale energie kan niet groter zijn dan 100 |
| t_is_disrupted_session | laadsessie met dezelfde token_uid wordt binnen een half uur gestopt en weer hervat aan dezelfde lader |
| t_is_duplicate_session | laadsessie met identieke evse_id, start_date_time, stop_date_time en token_uid als een andere laadsessie |
| t_is_exact_overlap_different_user | laadsessie met identieke evse_id, start_date_time en stop_date_time, maar een andere token_uid als een andere laadsessie |
| t_is_partial_overlap_different_user | laadsessie met identieke evse_id en andere token_uid, die begint voordat de huidige laadsessie eindigt |
| t_is_partial_overlap_same_user | laadsessie met identieke evse_id en token_uid, die begint voordat de huidige laadsessie eindigt |
| t_is_socket_switch_session | laadsessie met dezelfde token_uid wordt binnen een half uur gestopt en weer hervat aan een andere lader |
| t_missing | laadsessie heeft een NaN-value bij total_energy |
Er is een wens om te controleren of een EVSE voor langer dan een week geen data levert, maar dit moet nog worden geïmplementeerd.
t_duplicate_different_socket_session
Deze test controleert of er laadtransacties zijn waarbij dezelfde sessie op verschillende sockets/connectoren lijkt plaats te vinden. Dit kan wijzen op een ongebruikelijke wisseling van socket binnen een enkele sessie.
Werking van de test
- De test kijkt naar laadsessies met dezelfde starttijd, totale geladen energie en token ID (gebruiker).
- Vervolgens wordt gecontroleerd of deze sessies op verschillende connector ID's zijn geregistreerd.
- Als een sessie meerdere connector ID's heeft, wordt deze gemarkeerd als een mogelijke wisseling van connector.
Mogelijke oorzaken
- Een fysieke wisseling van connector tijdens het laden.
- Fouten in de dataregistratie.
- Onverwachte afwijkingen in de laadinfrastructuur.
Voorbeeld: Detectie van duplicaten met verschillende connectoren
Deze test controleert of een laadtransactie als een socket switch wordt gemarkeerd wanneer dezelfde sessie met verschillende connectoren wordt geregistreerd.
Testscenario
| Starttijd | Totale energie (kWh) | Token ID | Locatie ID | Connector ID | Verwachte uitkomst |
|---|---|---|---|---|---|
| 2024-01-01 10:00:00 | 10 | A | 1 | 1 | ✅ Gemarkeerd als wisseling van connector |
| 2024-01-01 10:00:00 | 10 | A | 1 | 2 | ✅ Gemarkeerd als wisseling van connector |
Uitleg
- Beide transacties hebben dezelfde starttijd, energie en token ID, wat erop wijst dat het dezelfde sessie betreft.
- De connector ID's verschillen, wat betekent dat de auto tijdens de sessie van connector is gewisseld.
- De test detecteert dit patroon en markeert de sessie als een wisseling van connector.
Wanneer deze situatie zich herhaaldelijk voordoet, kan dit duiden op een fout in de dataregistratie of een afwijking in het laadproces.
t_exceeding_capacity
Deze test controleert of er laadsessies zijn waarbij het aantal gelijktijdige laadsessies de beschikbare hoeveelheid connectoren overschrijdt.
Werking van de test
- Elke laadsessie heeft een starttijd, stoptijd en een locatie met een bekend aantal beschikbare connectoren.
- De test controleert of er meerdere laadsessies tegelijkertijd plaatsvinden op dezelfde locatie.
- Als het aantal gelijktijdige sessies groter is dan het aantal beschikbare connectoren, wordt de sessie als capaciteit overschrijdend gemarkeerd.
Mogelijke oorzaken
- Onjuiste registratie van het aantal beschikbare connectoren.
- Fouten in de sessiegegevens, bijvoorbeeld overlappende tijden door incorrecte dataregistratie.
Voorbeeld: Detectie van sessies die de laadcapaciteit overschrijden
Deze test controleert of er laadsessies zijn waarbij het aantal gelijktijdige sessies hoger is dan het aantal beschikbare connectoren op de locatie.
Testscenario
| Sessienaam | Starttijd | Stoptijd | Locatie ID | Beschikbare connectoren | Gelijktijdige sessies | Verwachte uitkomst |
|---|---|---|---|---|---|---|
| Sessie 1 | 2024-01-01 10:00:00 | 2024-01-01 11:00:00 | 1 | 2 | 2 | ❌ Niet gemarkeerd |
| Sessie 2 | 2024-01-01 10:30:00 | 2024-01-01 11:15:00 | 1 | 2 | 3 | ✅ Capaciteit overschreden |
| Sessie 3 | 2024-01-01 10:45:00 | 2024-01-01 11:30:00 | 1 | 2 | 3 | ✅ Capaciteit overschreden |
| Sessie 4 | 2024-01-01 11:00:00 | 2024-01-01 12:00:00 | 1 | 2 | 1 | ❌ Niet gemarkeerd |
Uitleg
- Sessie 1 overlapt met Sessie 2, maar blijft binnen de limiet van 2 beschikbare connectoren.
- Sessie 2 overlapt met Sessie 1 en Sessie 3, waardoor er 3 gelijktijdige sessies zijn (capaciteit overschreden).
- Sessie 3 overlapt met Sessie 2 en blijft tegelijkertijd actief, wat ook leidt tot een overschrijding.
- Sessie 4 start nadat Sessie 1 is afgelopen en blijft onder de limiet, dus deze sessie wordt niet gemarkeerd.
Sessies die regelmatig de capaciteit overschrijden kunnen wijzen op fouten in de registratie.
t_extreme_total_energy
Deze test controleert of de totale geladen hoeveelheid energie voor een laadsessie boven de 100 kWh uitkomt. Hoewel dit niet per definitie onmogelijk is, is het belangrijk om dit te monitoren, omdat het kan wijzen op meetfouten of onrealistische gegevens.
Voorbeeld: Detectie van extreem hoge laadsessies
Testscenario
| Sessienaam | Starttijd | Stoptijd | Locatie ID | Totaal geladen energie (kWh) | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 2024-01-01 08:00:00 | 2024-01-01 10:00:00 | 1 | 80 | ❌ Niet gemarkeerd |
| Sessie 2 | 2024-01-01 09:30:00 | 2024-01-01 12:00:00 | 1 | 150 | ✅ Mogelijk onrealistisch |
| Sessie 3 | 2024-01-01 14:00:00 | 2024-01-01 16:30:00 | 1 | 95 | ❌ Niet gemarkeerd |
| Sessie 4 | 2024-01-01 18:00:00 | 2024-01-01 21:00:00 | 1 | 110 | ✅ Mogelijk onrealistisch |
Uitleg
- Sessie 1 en 3 hebben een realistische geladen energie en worden niet gemarkeerd.
- Sessie 2 en 4 overschrijden de grens van 100 kWh en worden daarom als opvallend beschouwd.
- Dit kan wijzen op meetfouten, manipulatie, of uitzonderlijk lange/hoge laadsessies. Verdachte gevallen kunnen nader onderzocht worden.
t_is_disrupted_session
Deze test controleert of een laadsessie binnen 30 minuten na een vorige sessie op hetzelfde laadpunt door dezelfde gebruiker wordt hervat.
Werking van de test
- Elke laadsessie heeft een starttijd, stoptijd, een EVSE ID (uniek laadpunt) en een token UID (gebruiker).
- De test kijkt of dezelfde gebruiker (token UID) binnen 30 minuten na het einde van een vorige sessie op hetzelfde laadpunt (EVSE ID) een nieuwe sessie start.
- Als dat het geval is, wordt de sessie als onderbroken gemarkeerd.
Mogelijke oorzaken
- Technische storing: De laadsessie werd onbedoeld onderbroken door een fout in het systeem.
- Handmatige afkoppeling: De gebruiker heeft de laadkabel losgekoppeld en kort daarna opnieuw aangesloten.
- Tijdslimiet: Sommige laadstations zouden een tijdslimiet kunnen hebben waarna een nieuwe sessie moet worden gestart.
- Onjuiste dataregistratie: Fouten in de dataset kunnen leiden tot onterecht gedetecteerde onderbrekingen.
Voorbeeld: Detectie van onderbroken laadsessies
Testscenario
| Sessienaam | EVSE ID | Token UID | Starttijd | Stoptijd | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 101 | A | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ❌ Niet onderbroken |
| Sessie 2 | 101 | A | 2024-01-01 09:10:00 | 2024-01-01 10:00:00 | ✅ Onderbroken |
| Sessie 3 | 101 | A | 2024-01-01 11:00:00 | 2024-01-01 12:00:00 | ❌ Niet onderbroken |
| Sessie 4 | 102 | B | 2024-01-01 14:00:00 | 2024-01-01 15:00:00 | ❌ Niet onderbroken |
| Sessie 5 | 102 | B | 2024-01-01 15:25:00 | 2024-01-01 16:00:00 | ✅ Onderbroken |
Uitleg
- Sessie 2 en 5 worden gemarkeerd als onderbroken, omdat dezelfde gebruiker binnen 30 minuten een nieuwe sessie start op hetzelfde laadpunt.
- Sessie 1, 3 en 4 hebben geen directe hervatting binnen 30 minuten en worden niet gemarkeerd.
- Dit kan wijzen op technische storingen, onderbrekingen door de gebruiker, of andere operationele problemen.
t_is_duplicate_session
Deze test controleert of er dubbele laadsessies in de dataset voorkomen. Dit gebeurt wanneer exact dezelfde sessiegegevens meerdere keren geregistreerd staan.
Werking van de test
- De test controleert of er dubbele sessies voorkomen op basis van:
- EVSE ID (het laadpunt)
- Token UID (de gebruiker)
- Starttijd (wanneer de sessie begon)
- Stoptijd (wanneer de sessie eindigde)
- Als er meerdere sessies met exact dezelfde waarden voorkomen, wordt alleen de eerste sessie behouden en de rest als duplicaat gemarkeerd.
Mogelijke oorzaken
- Fout in de datalogging: Dezelfde sessie is per ongeluk meerdere keren opgeslagen.
- Synchronisatieproblemen: Meerdere databronnen registreren dezelfde sessie onafhankelijk van elkaar.
Voorbeeld: Detectie van dubbele laadsessies
Testscenario
| Sessienaam | EVSE ID | Token UID | Starttijd | Stoptijd | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 201 | X | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ❌ Niet dubbel |
| Sessie 2 | 201 | X | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ✅ Dubbel |
| Sessie 3 | 202 | Y | 2024-01-01 10:00:00 | 2024-01-01 11:00:00 | ❌ Niet dubbel |
| Sessie 4 | 203 | Z | 2024-01-01 12:00:00 | 2024-01-01 13:00:00 | ❌ Niet dubbel |
| Sessie 5 | 201 | X | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ✅ Dubbel |
Uitleg
- Sessie 2 en 5 worden gemarkeerd als dubbele sessies, omdat ze exact dezelfde gegevens hebben als Sessie 1.
- Sessie 3 en 4 hebben unieke combinaties en worden niet als duplicaten beschouwd.
- Dit helpt bij het opschonen van de dataset en voorkomt foutieve analyses door onbedoeld verdubbelde gegevens.
t_is_exact_overlap_different_user
Deze test controleert of er exact overlappende laadsessies zijn op hetzelfde laadpunt, maar met verschillende gebruikers. Dit betekent dat twee of meer sessies op exact hetzelfde moment plaatsvinden bij dezelfde EVSE, maar met verschillende Token UIDs (gebruikers).
Werking van de test
- De test controleert of verschillende gebruikers een sessie hebben met exact dezelfde tijdsduur op hetzelfde laadpunt.
- Dit wordt bepaald door sessies te vergelijken op basis van:
- EVSE ID (het laadpunt)
- Starttijd (wanneer de sessie begon)
- Stoptijd (wanneer de sessie eindigde)
- Indien er een match is, wordt de sessie als exacte overlap door een andere gebruiker gemarkeerd.
Mogelijke oorzaken
- Fout in de datalogging: Het laadstation registreert per ongeluk dezelfde sessie onder meerdere gebruikers.
- Onjuiste sessiesynchronisatie: Meerdere backends registreren overlappende sessies door verschillende systemen.
- Identificatiefout: Een gebruiker wordt per ongeluk als twee geregistreerd.
Voorbeeld: Detectie van exact overlappende sessies met verschillende gebruikers
Testscenario
| Sessienaam | EVSE ID | Token UID | Starttijd | Stoptijd | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 101 | A | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ❌ Niet overlappend |
| Sessie 2 | 101 | B | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ✅ Overlap met andere gebruiker |
| Sessie 3 | 102 | C | 2024-01-01 10:00:00 | 2024-01-01 11:00:00 | ❌ Niet overlappend |
| Sessie 4 | 101 | A | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ❌ Wel overlappend, maar niet zelfde gebruiker. Zie hiervoor t_is_duplicate_session |
| Sessie 5 | 103 | D | 2024-01-01 12:00:00 | 2024-01-01 13:00:00 | ❌ Niet overlappend |
Uitleg
- Sessie 2 wordt gemarkeerd als overlappend, omdat het exact dezelfde tijd en locatie deelt met Sessie 1, maar met een andere gebruiker (Token UID B).
- Sessie 4 overlapt ook met Sessie 1, maar heeft dezelfde gebruiker (Token UID A) en wordt daarom niet als een probleem gezien. Dit wordt wel afgevangen in een andere test, namelijk t_is_duplicate_session.
- Sessie 3 en 5 hebben unieke combinaties en worden niet als exacte overlappen beschouwd.
- Dit helpt bij het detecteren van fouten in de sessieregistratie en voorkomt onterechte facturering aan meerdere gebruikers voor dezelfde laadsessie.
t_is_partial_overlap_different_user
Deze test controleert of er gedeeltelijk overlappende laadsessies zijn op hetzelfde laadpunt, maar met verschillende gebruikers. Dit betekent dat de sessies elkaar overlappen in tijd, maar niet exact dezelfde begin- en eindtijd hebben.
Werking van de test
- De test controleert of verschillende gebruikers overlappende laadsessies hebben op hetzelfde laadpunt.
- Dit wordt bepaald door sessies te vergelijken op basis van:
- EVSE ID (het laadpunt)
- Token UID (om verschillende gebruikers te identificeren)
- Start- en stoptijden, waarbij:
- De tweede sessie begint voordat de eerste eindigt.
- De sessies niet exact gelijk zijn in start- en stoptijd.
- Indien dit het geval is, wordt de sessie als gedeeltelijke overlap door een andere gebruiker gemarkeerd.
Mogelijke oorzaken
- Synchronisatiefout: Backend-systemen verwerken sessies met kleine tijdverschuivingen.
- Fout in de registratie: Een sessie wordt per ongeluk aan twee verschillende gebruikers gekoppeld.
- Onjuist afgebroken sessies: Een sessie stopt en een nieuwe begint te vroeg, zonder dat de vorige correct is afgesloten.
- Technische storing: Laadpaalsoftware verwerkt de gebruikersinformatie niet correct.
Voorbeeld: Detectie van gedeeltelijke overlappende sessies tussen verschillende gebruikers
Testscenario
| Sessienaam | EVSE ID | Token UID | Starttijd | Stoptijd | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 101 | A | 2024-01-01 08:00:00 | 2024-01-01 09:30:00 | ❌ Geen overlap |
| Sessie 2 | 101 | B | 2024-01-01 09:00:00 | 2024-01-01 10:00:00 | ✅ Gedeeltelijke overlap |
| Sessie 3 | 102 | C | 2024-01-01 10:00:00 | 2024-01-01 11:00:00 | ❌ Geen overlap |
| Sessie 4 | 101 | A | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ❌ Zelfde gebruiker. Zie hiervoor t_is_partial_overlap_same_user |
| Sessie 5 | 103 | D | 2024-01-01 12:00:00 | 2024-01-01 13:00:00 | ❌ Geen overlap |
| Sessie 6 | 101 | C | 2024-01-01 09:15:00 | 2024-01-01 09:45:00 | ✅ Gedeeltelijke overlap |
Uitleg
- Sessie 2 overlapt gedeeltelijk met Sessie 1, want hij begint terwijl Sessie 1 nog bezig is en eindigt later. Ze hebben andere gebruikers en worden hier dus gedetecteerd.
- Sessie 6 overlapt gedeeltelijk met Sessie 2, want hij begint binnen de tijdspanne van Sessie 2. Ze hebben ook andere gebruikers en worden hier dus gedetecteerd.
- Sessie 4 overlapt met Sessie 1, maar heeft dezelfde gebruiker (A), dus wordt niet als probleem gemarkeerd. Dit wordt wel afgevangen in een andere test, namelijk t_is_partial_overlap_same_user.
- Sessies 3 en 5 zijn unieke sessies zonder overlap.
- Dit helpt bij het identificeren van mogelijk incorrecte gebruikerskoppelingen.
- Het kan technische storingen of incorrecte gegevensregistratie opsporen.
t_is_partial_overlap_same_user
Deze test controleert of er gedeeltelijk overlappende laadsessies zijn op hetzelfde laadpunt, waarbij dezelfde gebruiker (Token UID) betrokken is. Dit betekent dat een gebruiker twee sessies heeft die elkaar overlappen in tijd, maar niet exact dezelfde start- en stoptijden hebben.
Werking van de test
- De test controleert of dezelfde gebruiker overlappende laadsessies heeft op hetzelfde laadpunt.
- Dit wordt bepaald door sessies te vergelijken op basis van:
- EVSE ID (het laadpunt)
- Token UID (om dezelfde gebruiker te identificeren)
- Start- en stoptijden, waarbij:
- De tweede sessie begint voordat de eerste eindigt.
- De sessies niet exact gelijk zijn in start- en stoptijd.
- Indien dit het geval is, wordt de sessie als gedeeltelijke overlap door dezelfde gebruiker gemarkeerd.
Mogelijke oorzaken
- Dubbele registratie van een sessie: Door een fout in de backend wordt een sessie (deels) dubbel geregistreerd.
- Onjuist afgebroken sessies: Een sessie start opnieuw zonder correcte afsluiting.
- Software problemen: Bij de laadpaal of backend worden de sessies verkeerd opgeslagen.
Voorbeeld: Detectie van gedeeltelijk overlappende sessies met dezelfde gebruiker
Testscenario
| Sessienaam | EVSE ID | Token UID | Starttijd | Stoptijd | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 201 | X | 2024-01-01 08:00:00 | 2024-01-01 09:30:00 | ❌ Geen overlap |
| Sessie 2 | 201 | X | 2024-01-01 09:00:00 | 2024-01-01 10:00:00 | ✅ Gedeeltelijke overlap |
| Sessie 3 | 202 | Y | 2024-01-01 10:00:00 | 2024-01-01 11:00:00 | ❌ Geen overlap |
| Sessie 4 | 201 | X | 2024-01-01 08:00:00 | 2024-01-01 09:00:00 | ✅ Gedeeltelijke overlap |
| Sessie 5 | 203 | Z | 2024-01-01 12:00:00 | 2024-01-01 13:00:00 | ❌ Geen overlap |
Uitleg
- Sessie 2 overlapt gedeeltelijk met Sessie 1, want hij begint terwijl Sessie 1 nog bezig is.
- Sessie 4 overlapt gedeeltelijk met Sessie 1, want hij begint binnen de tijdspanne van Sessie 1.
- Sessies 3 en 5 hebben geen overlap met andere sessies.
- Dit helpt bij het detecteren van mogelijk incorrecte sessies binnen een laadpunt.
- Het kan wijzen op technische fouten, zoals dubbele boekingen of incorrecte afsluitingen.
t_is_socket_switch_session
Deze test controleert of een gebruiker binnen 30 minuten na het stoppen van een laadsessie opnieuw begint met laden, maar op een ander laadpunt (EVSE ID).
Werking van de test
- De test controleert of dezelfde gebruiker (Token UID) een nieuwe laadsessie start op een ander EVSE ID binnen 30 minuten na het beëindigen van de vorige sessie.
- Dit wordt bepaald door sessies te vergelijken op basis van:
- Token UID (de unieke identificatie van de gebruiker).
- Start- en stoptijden, waarbij:
- De nieuwe sessie start nadat de vorige is gestopt.
- De tijd tussen het stoppen van de vorige en het starten van de nieuwe sessie maximaal 30 minuten is.
- EVSE ID, waarbij:
- De nieuwe sessie plaatsvindt op een ander laadpunt (EVSE ID ≠ vorige EVSE ID).
- Indien dit het geval is, wordt de sessie als socket switch session gemarkeerd.
Mogelijke oorzaken
- Technische problemen: Het laadpunt beëindigt onverwacht de sessie, waarna de gebruiker op een ander punt verder laadt.
- Bewuste keuze: De gebruiker wisselt van laadpaal vanwege gunstigere tarieven.
- Software problemen: Bij de laadpaal of backend worden de sessies verkeerd opgeslagen.
Voorbeeld: Detectie van socket switch charging sessions
Testscenario
| Sessienaam | EVSE ID | Token UID | Starttijd | Stoptijd | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | A | X | 2024-03-21 10:00:00 | 2024-03-21 10:30:00 | ❌ Geen switch |
| Sessie 2 | B | X | 2024-03-21 10:40:00 | 2024-03-21 11:10:00 | ✅ Socket switch |
| Sessie 3 | A | X | 2024-03-21 12:50:00 | 2024-03-21 13:30:00 | ❌ Geen switch |
| Sessie 4 | C | Y | 2024-03-21 12:00:00 | 2024-03-21 12:45:00 | ❌ Geen switch |
| Sessie 5 | D | Y | 2024-03-21 13:14:00 | 2024-03-21 13:40:00 | ✅ Socket switch |
| Sessie 6 | D | Y | 2024-03-21 14:00:00 | 2024-03-21 14:45:00 | ❌ Geen switch, maar wel onderbroken. Zie hiervoor t_is_disrupted_session |
Uitleg
- Sessie 2 wordt als socket switch session gemarkeerd, omdat dezelfde gebruiker 10 minuten na het stoppen op EVSE A opnieuw start op EVSE B.
- Sessie 5 wordt als socket switch session gemarkeerd, omdat dezelfde gebruiker 29 minuten na het stoppen op EVSE C opnieuw start op EVSE D.
- Sessie 3 is geen socket switch sessions, omdat de gebruiker niet binnen 30 minuten wisselt.
- Sessie 6 is geen socket switch sessions, omdat de gebruiker op hetzelfde laadpunt blijft. Dit wordt wel afgevangen in een andere test, namelijk t_is_disrupted_session.
- Dit helpt bij het detecteren van mogelijk incorrecte registraties of bewuste wissels van laadpaal.
t_missing
Deze test controleert of een laadsessie een ontbrekende (NaN) waarde heeft voor total_energy. Dit kan duiden op meetfouten, ontbrekende data in het systeem of een niet-geregistreerde energieafname.
Werking van de test
- De test controleert of de kolom total_energy (kWh) een NaN-waarde bevat.
- Sessies met een
NaN-waarde worden gemarkeerd als mogelijk onbetrouwbaar en verdienen nader onderzoek.
Voorbeeld: Detectie van ontbrekende energiegegevens
Testscenario
| Sessienaam | Starttijd | Stoptijd | Locatie ID | Totaal geladen energie (kWh) | Verwachte uitkomst |
|---|---|---|---|---|---|
| Sessie 1 | 2024-01-01 08:00:00 | 2024-01-01 10:00:00 | 1 | 80 | ❌ Niet gemarkeerd |
| Sessie 2 | 2024-01-01 09:30:00 | 2024-01-01 12:00:00 | 1 | NaN | ✅ Mogelijk onbetrouwbaar |
| Sessie 3 | 2024-01-01 14:00:00 | 2024-01-01 16:30:00 | 1 | 95 | ❌ Niet gemarkeerd |
| Sessie 4 | 2024-01-01 18:00:00 | 2024-01-01 21:00:00 | 1 | NaN | ✅ Mogelijk onbetrouwbaar |
Uitleg
- Sessie 1 en 3 hebben geldige waarden en worden niet gemarkeerd.
- Sessie 2 en 4 hebben een NaN-waarde in
total_energy, wat betekent dat de totale geladen energie onbekend is. - Dit kan wijzen op meetfouten, gebrekkige communicatie tussen het laadpunt en het systeem, of ontbrekende gegevens in de database.