De e-rijder staat er vanzelfsprekend niet bij stil, maar voordat een laadpaal kan worden gerealiseerd in de straat of op private terreinen is er een heel aantal stappen te zetten. Afstemming tussen stakeholders zoals de gemeente, CPO, netbeheerder en eventueel vastgoedpartijen, omwonenden en de aanvrager zijn nodig om de laadpaal te kunnen neerzetten op bepaalde plekken en binnen kaders die zijn afgesproken. Om dit goed te begeleiden zijn software en data onmisbaar.
Dat merkte EVtools al vrij snel en daarom ontwikkelde het marktonafhankelijke software om plan- en prognosekaarten te maken in Maps, het realisatieproces te vereenvoudigen met Worklfow en om het laadnetwerk in de gaten te houden met Monitoring. Al deze modules zijn gebouwd op basis van één sterke overtuiging: het ecosysteem werkt alleen effectief met gestandaardiseerde onderlinge koppelingen. Tussen de EVtools-modules werkt dit al, maar ook andere systemen van stakeholders, zoals CRM- of GIS-systemen, moeten kunnen worden aangesloten op het de software. Relevante data is zo voor iedereen in het samenwerkingsverband met de juiste autorisatie beschikbaar. Denk dan bijvoorbeeld aan concessies in steden waarbij de gemeente, meerdere laadpaalexploitanten en de netbeheerder toegang heeft om het realisatieproces te vergemakkelijken.
Waarom deze overtuiging?
Dat is eigenlijk heel voor de hand liggend zegt Tim van Beek, oprichter en directeur van EVtools: “Contracten worden steeds opnieuw gegund aan diverse laadpaalexploitanten en soms zijn er meerdere tegelijk actief. Met het gebruik van een open IT-standaard tussen alle systemen is een overdracht naar een andere partij veel soepeler, ontstaat er onderling overzicht en wordt een ‘vendor lock-in’ voorkomen. Dat komt een snellere opschaling van een kwalitatief laadnetwerk ten goede. Ook zijn in Nederland zogenoemde vergunningsgemeenten. In deze gemeente is er geen gunning geweest aan één partij, maar zijn er meerdere CPO’s actief in een regio of stad die laadpalen realiseren. Dat zou met gesloten systemen inhouden dat er meerdere systemen moeten worden geraadpleegd om overzicht te houden op de ontwikkeling van het laadnetwerk. Niet wenselijk voor de gemeente, maar ook niet voor de CPO’s die actief zijn.”
Nationale standaarden
Veel partijen hebben geïnvesteerd in eigen softwaresystemen en om deze capaciteit te benutten is het dus verstandig om deze systemen met elkaar te laten praten. Dat gebeurt met ‘Application Programming Interface’, oftewel API. Om afspraken te maken over nationale standaarden waarin beschreven staat wat, wanneer en hoe het overzenden van informatie plaatsvindt in een open structuur is er een rol weggelegd voor een partij met een marktonafhankelijke positie.
Roland Ferwerda van NKL (een nationaal kenniscentrum op het gebied van laadinfrastructuur) deelt deze mening en maakt zich hard om deze API standaarden te ontwikkelen: “Een voorbeeld is de uitwisseling van laadpaalaanvragen en statusinformatie over een laadpaal in het realisatieproces. Daarbij mag iedere partij een eigen database of proces inrichten zolang dit maar via de open standaard API kan worden uitgewisseld met andere partijen. Dit creëert kansen en een gezonde marktsituatie voor bedrijven die actief zijn in dit segment om te innoveren, te groeien en meer impact te kunnen maken in de energietransitie.”
Tim van Beek sluit zich hierbij aan. “Door hier werk van te maken benutten we optimaal de softwaresystemen die er zijn en kunnen wij een schat aan informatie delen. Zo ontstaat er inzicht in bijvoorbeeld laadbehoefte op buurtniveau nu en in de toekomst, kunnen de prestaties van laadpalen worden bekeken en krijgen netbeheerders een overzicht van de realisatie zodat er noodzakelijke aanpassingen aan netaansluitingen kunnen worden ingepland. Een open IT-standaard levert voordelen op: sneller en kwalitatief opschalen van laadnetwerken en het beperken van maatschappelijke kosten.”
Open communicatieprotocol
Het is overigens niet zo dat alle data voor iedereen beschikbaar is. Bij EVtools is ingericht dat er afhankelijk van de status van de gebruiker en het eigenaarschap van bepaalde data wordt bepaald wat er wel en niet zichtbaar is. Ook dit zou moet worden beschreven in het open communicatieprotocol zodat informatie in CRM- en GIS-systemen tot databases beheerd door netbeheerders, laaddienstverleners (MSP’s), CPO’s en nog veel meer zorgvuldig worden gedeeld zonder concurrentie- of privacygevoelige informatie prijs te geven.
EVtools heeft hiertoe al vele API’s ontwikkeld. Enkele aansprekende voorbeelden waar dit is toegepast is het aanvraagportaal van MRA-e, locatie-data met Ecomovement, de plankaarten in Gelderland en Overijssel en de monitoring van laadpaalexploitant Vattenfall. Binnenkort kan EVtools een API voor het aanvraagportaal van NKL daaraan toevoegen.