Wat is OCPP? Het Open Charge Point Protocol uitgelegd

Wat OCPP precies regelt — en wat niet

OCPP regelt uitsluitend het verkeer tussen de laadpaal en het beheersysteem. Dat beheersysteem heet in de specificatie een CSMS: Charging Station Management System. Alles wat daarbuiten valt — de communicatie met de auto, de afrekening met een andere laadpasaanbieder, de afstemming met de netbeheerder — loopt via andere protocollen.

CSMS(Charging Station Management System)

Het centrale systeem dat laadpalen aanstuurt, laadsessies registreert, gebruikers autoriseert en storingen bewaakt. In OCPP 1.6 heette dit nog Central System. Elke laadpaal onderhoudt een verbinding met precies één CSMS.

Dit onderscheid verklaart de meeste verwarring in de markt. Een leverancier die zegt "onze palen zijn OCPP-compatibel" belooft daarmee alleen dat de paal met een willekeurig CSMS kan praten. Of jouw laadpas het bij een concurrent doet, staat daar volledig los van — dat is OCPI.

Voor de meeste bedrijven is alleen OCPP relevant. Zolang je je eigen laadpalen beheert voor je eigen wagenpark, medewerkers of huurders, heb je geen roamingprotocol nodig.

Hoe de verbinding technisch werkt

De laadpaal maakt zelf verbinding met het CSMS, niet andersom. Dat is een bewuste keuze: laadpalen staan vrijwel altijd achter een router zonder vast IP-adres, waardoor een inkomende verbinding onmogelijk zou zijn. De paal opent een WebSocket-verbinding naar de server en houdt die permanent open.

Over die ene verbinding lopen berichten in beide richtingen. De paar meldt bijvoorbeeld uit zichzelf dat er een auto is aangesloten, terwijl het CSMS op elk moment kan opdragen om de sessie te stoppen. Elk bericht is een JSON-array met een uniek id, zodat antwoord en vraag altijd aan elkaar te koppelen zijn.

[2,"19223201","BootNotification",{
  "chargePointVendor": "Alfen",
  "chargePointModel": "Eve Single Pro-line",
  "firmwareVersion": "6.3.0"
}]

[3,"19223201",{
  "status": "Accepted",
  "currentTime": "2026-08-12T09:14:22Z",
  "interval": 300
}]

De cijfers vooraan geven het berichttype aan: 2 is een verzoek, 3 een geslaagd antwoord en 4 een fout. Het CSMS antwoordt hier met Accepted en geeft meteen de juiste tijd door, plus een interval van 300 seconden waarmee de paal voortaan zijn hartslag moet sturen.

Heartbeat

Een leeg bericht dat de laadpaal op vaste intervallen stuurt om te laten weten dat hij nog leeft. Blijft de heartbeat uit, dan weet het CSMS dat de paal offline is — nog voordat iemand er tevergeefs voor staat.

Het verloop van een laadsessie, bericht voor bericht

Een complete laadsessie bestaat in OCPP 1.6 uit een vaste reeks berichten. Wie die reeks kent, kan bij een storing precies aanwijzen waar het misgaat.

1. 1StatusNotification — de paal meldt dat de connector van Available naar Preparing gaat zodra er een kabel wordt ingestoken.
2. 2Authorize — de paal vraagt het CSMS of de aangeboden pas mag laden. Het CSMS antwoordt met Accepted, Blocked, Expired of Invalid.
3. 3StartTransaction — bij akkoord opent de paal een transactie en krijgt een transactionId terug.
4. 4MeterValues — gedurende de sessie stuurt de paal periodiek meterstanden, standaard elke 60 tot 300 seconden.
5. 5StopTransaction — bij loskoppelen sluit de paal de transactie af met de eindmeterstand en een reden.
6. 6StatusNotification — de connector gaat via Finishing terug naar Available.

In OCPP 2.0.1 is deze reeks vervangen door één bericht: TransactionEvent, met de types Started, Updated en Ended. Dat maakt de afhandeling betrouwbaarder, omdat de paal een transactie ook kan afronden als hij tussendoor offline is geweest.

Welke versies er zijn

Er zijn drie versies die er vandaag toe doen: 1.6, 2.0.1 en 2.1. OCPP 1.6 stamt uit 2015 en draait nog op het overgrote deel van de geïnstalleerde laadpalen. OCPP 2.0.1 is sinds 2020 beschikbaar en is de basis van de IEC 63584-norm. OCPP 2.1 verscheen in januari 2025 en voegt bidirectioneel laden toe.

Belangrijk om te weten: 1.6 en 2.0.1 zijn niet uitwisselbaar. Een paal die 1.6 spreekt kan niet zomaar met een 2.0.1-server praten. Tussen 2.0.1 en 2.1 is dat wél zo — 2.1 is achterwaarts compatibel, waardoor een upgrade daar geen herbouw vraagt.

De letter achter 1.6 verwijst naar de transportlaag. OCPP 1.6J gebruikt JSON over WebSocket, OCPP 1.6S gebruikt SOAP over HTTP. In de praktijk kom je vrijwel alleen 1.6J tegen; SOAP wordt door vrijwel geen enkele nieuwe installatie meer gebruikt.

Waarom een open protocol het verschil maakt

Zonder open protocol bepaalt je laadpaalleverancier wat je met je eigen data mag. Dat was precies het probleem waar ElaadNL in 2009 tegenaan liep: elke fabrikant had een eigen systeem, en wie duizenden palen van verschillende merken wilde beheren, moest evenzoveel losse beheerportalen accepteren.

Met OCPP kun je drie dingen die anders onmogelijk zijn. Je kunt palen van verschillende merken in één omgeving beheren, je kunt van beheerplatform wisselen zonder je hardware te vervangen, en je kunt je laaddata rechtstreeks in je eigen systemen krijgen in plaats van via een export uit andermans portaal.

Wanneer je zelf iets met OCPP moet doen

Een eigen OCPP-server is zinvol zodra je meer wilt dan sessies zien. Voor bedrijven die alleen wat medewerkers laten laden, volstaat het platform van de leverancier meestal prima.

• Je wilt laadkosten automatisch doorbelasten aan afdelingen, huurders of klanten vanuit je eigen administratie.
• Je hebt laadpalen van meerdere merken en wilt ze in één omgeving beheren.
• Je netaansluiting is te krap en je moet laadvermogen actief verdelen over voertuigen.
• Je wilt laaddata in je ERP, fleet management of BI-omgeving in plaats van in een portaal.
• Je bouwt zelf een dienst rondom laden en hebt een API nodig in plaats van een dashboard.

Herken je twee of meer van deze punten, dan loop je binnen afzienbare tijd tegen de grenzen van een standaardplatform aan. Dat is het moment om te kijken naar een eigen OCPP-server of een koppeling op je bestaande omgeving.