OCPP-proxy: wat het is en wanneer je er een nodig hebt
Vrijwel elke moderne laadpaal spreekt OCPP, het open protocol dat laadpalen met een beheerplatform verbindt. In theorie betekent dat dat je een laadpaal op elke backoffice kunt aansluiten die je wilt. In de praktijk houdt de meeste hardware maar één OCPP-verbinding open: een WebSocket-URL, geconfigureerd in de laadpaal, wijzend naar een platform. Alles wat je met die laadpaal doet, billing, diagnostiek, smart charging, rapportage, loopt via het platform aan het einde van die URL.
Die ene verbinding is waar lock-in ontstaat, en een OCPP-proxy neemt die weg. De OCPP-proxy van Plugchoice is gratis. De laadpaal maakt één keer verbinding met Plugchoice, en Plugchoice stuurt het OCPP-verkeer tegelijk door naar een of meer backends (CSMS). Een backend toevoegen of verwijderen is een schakelaar, dus de laadpaal wordt nooit opnieuw ingesteld, en berichten worden bewaard zolang een gekoppelde backend eruit ligt.
Waarom laadpalen vast komen te zitten aan een backend
Het OCPP-endpoint van een laadpaal pas je niet zomaar aan. Meestal moet je bij de configuratie via een installateursapp, een servicemenu of een bezoek op locatie, en als het misgaat staat de laadpaal offline. Dus zodra een laadpaal op een platform is ingericht, blijft hij daar meestal staan, ook als het platform niet meer past.
En platformen gaan een keer knellen. Een billing-aanbieder verandert zijn prijzen. Een operatorcontract loopt af. Een backend stopt of verandert van koers, en ineens is de vraag niet "welk platform is het beste" maar "hoe herconfigureren we honderden laadpalen". Voor installateurs en charge point operators is dat herconfigureren echt werk met echte downtime.
Er is nog een tweede, stiller probleem: een verbinding betekent dat een platform alles krijgt. Als je billing-platform de OCPP-verbinding heeft, beheert het ook je diagnostiek, je configuratietoegang en je data. Wil je een aparte analytics-tool, of een energiemanagementsysteem dat dezelfde sessies meeleest? Met een enkele directe verbinding kan dat niet allebei.
Wat een OCPP-proxy doet
Een OCPP-proxy zit tussen de laadpaal en de platformen in. De laadpaal verbindt een keer met de proxy, en de proxy stuurt OCPP-berichten door naar een of meer backends. Voor de laadpaal gedraagt de proxy zich als zijn backend. Voor elk aangesloten platform gedraagt de proxy zich als de laadpaal.
Software op die plek heeft ook andere namen, waaronder gateway en broker. Ze betekenen niet allemaal hetzelfde; OCPP-proxy, gateway of broker vergelijkt ze.
Die ene verandering in de opbouw heeft twee gevolgen.
Ten eerste wordt de configuratie van de laadpaal permanent. Hij wijst naar de proxy en hoeft nooit meer aangepast te worden. Welke platformen zijn verkeer ontvangen bepaal je in de proxy, in software, niet in de instellingen van de laadpaal.
Ten tweede is "een laadpaal, een platform" geen regel meer. De proxy kan berichten naar meerdere platformen tegelijk doorsturen, elk met een eigen rol: het ene doet billing, het andere ontvangt sessiedata voor analytics, en de beheerlaag blijft eronder beschikbaar.
Wisselen van backend zonder downtime
Dit is het scenario waarvoor de proxy bestaat. Stel, je laadpalen zijn ingericht op billing-platform A, en je wilt naar platform B.
Zonder proxy is dat een migratie: elke laadpaal omzetten naar de nieuwe WebSocket-URL, hopen dat firmware en instellingen meewerken, en een periode accepteren waarin sessies, laadpassen en rapportage in het luchtledige hangen.
Met een proxy is het een routeringswijziging. Je voegt platform B als operator toe op de proxy, controleert of het de laadpalen ziet en sessies goed verwerkt, en schakelt daarna de route naar platform A uit. De laadpalen merken er niets van. Geen bezoek op locatie, geen heraansluiting, en geen periode waarin de vloot onbeheerd is, want de laag waar de laadpalen echt mee verbonden zijn is nooit weggeweest.
Hetzelfde werkt ook andersom: je kunt een nieuw platform eerst op een handvol laadpalen testen, parallel aan je huidige inrichting, voordat je je hele vloot overzet.
Wanneer een proxy zinvol is
Een proxy is niet voor iedereen. Een huiseigenaar met een laadpaal en een app kan prima met een directe verbinding uit de voeten. De proxy gaat zich terugverdienen zodra een van deze situaties speelt:
- Je beheert laadpalen voor anderen. Installateurs en CPO's die vloten inrichten willen hun hardwaretoegang onafhankelijk houden van de billing-operator die een klant vandaag kiest.
- Verschillende locaties vragen verschillende platformen. Met een proxy combineer je billing- of automatiseringsplatformen binnen een vloot, met een beheerlaag voor het geheel.
- Je hebt meer dan een systeem op dezelfde laadpaal nodig. Billing op het ene platform, monitoring of een energiemanagementsysteem op het andere, allebei gevoed door dezelfde OCPP-stroom.
- Je wilt een uitweg voordat je die nodig hebt. Als een backend duurder wordt, verslechtert of verdwijnt, is omrouteren beter dan opnieuw aansluiten. Backendverloop is in deze markt niet hypothetisch; eigenaren van laadpalen hebben platformen zien herstructureren en verdwijnen terwijl hun laadpalen gewoon aan de muur hingen.
Hoe de OCPP-proxy van Plugchoice werkt
De gratis OCPP-proxy van Plugchoice werkt volgens dit model. Laadpalen verbinden met wss://ocpp.plugchoice.com, Plugchoice blijft de beheerlaag (portaal, app, diagnostiek en configuratie blijven beschikbaar, welke backends je ook koppelt), en de proxy stuurt het OCPP-verkeer door naar de backoffices die je toevoegt.
Een paar details van de implementatie:
- Elke OCPP 1.6J-backend. De backoffices in de integratielijst kies je uit een lijst. Elke andere backoffice die OCPP 1.6J spreekt, verbind je met zijn websocket-URL.
- Een rol per backoffice. Facturering geeft een backoffice de autorisatie van kaarten, sessies en transacties. Data & besturing laat hem alles lezen en commando's sturen, maar nooit een sessie starten of stoppen.
- Berichten bewaard als een backend offline is. De proxy bewaart de OCPP-berichten voor een gekoppelde backoffice die wegvalt, en stuurt ze opnieuw zodra hij terug is. Zo gaan er in de tussentijd geen sessies verloren.
- Elk bericht gelogd. Elk OCPP-bericht van en naar de laadpaal wordt bewaard, en is te filteren en te exporteren.
- Een schakelaar om te koppelen of ontkoppelen. Backoffices zet je aan en uit in het portaal of de app. Weggaan bij een platform is een schakelaar, geen project.
De proxy spreekt OCPP 1.6J, afhankelijk van model, firmware en configuratie van de laadpaal. De OCPP 1.6J-gids beschrijft de berichten die hij doorstuurt.
Het resultaat is dat de laadpaallaag van jou blijft. Platformen daarboven kunnen komen, gaan en tegelijk draaien, en geen van ze kan jouw hardwaretoegang meenemen.
Begin bij de OCPP-proxypagina of sluit een laadpaal aan en probeer het eerst op een locatie.
Kan een laadpaal met twee backends tegelijk verbonden zijn
Ja, via een OCPP-proxy. Met Plugchoice maakt de laadpaal een keer verbinding met Plugchoice, en Plugchoice stuurt hetzelfde OCPP-verkeer tegelijk door naar meerdere backends, bijvoorbeeld een billing-platform en een energieplatform, elk met een eigen rol. De tweede backend voeg je toe met een schakelaar in de portal; de laadpaal houdt zijn ene verbinding en wordt niet opnieuw geconfigureerd.
Bronnen
Hoe we berichten: Redactiestatuut | Correcties | Auteurs
De nieuwsbrief van Plugchoice
Nieuws en uitleg over EV-laden per e-mail. Je kunt je op elk moment afmelden. Privacybeleid