OCPP 1.6 of 2.0.1: wat verandert er en wat controleert u voor u migreert

Uw leverancier van monitoring stelt “OCPP 2.0.1” voor, of een fabrikant prijst een laadpaal aan die “compatibel is met 2.0.1”. Voor een exploitant is de nuttige vraag niet welke versie de recentste is, maar wat elke versie verandert aan de exploitatie van het park en wat een versienaam niet garandeert. De onderstaande informatie komt uit documenten van de Open Charge Alliance, geraadpleegd op 1 november 2026.

Wat OCPP doet en wat de versie niet zegt

OCPP regelt de dialoog tussen een laadpaal en zijn beheersysteem. Het beschrijft niet de uitwisseling tussen het voertuig en de laadpaal. De versie legt een kader van berichten vast, niet de lijst van functies die een product biedt. De Open Charge Alliance preciseert zelf dat 2.0.1 veel functies bevat die niet voor elke fabrikant of exploitant nodig hoeven te zijn, en dat de certificering een minimale set functies oplegt, aangevuld met extra profielen zoals laadbeheer of ISO 15118.

Rechtstreeks gevolg: twee laadpalen met dezelfde versie doen mogelijk niet hetzelfde. Een lastenboek moet dus de verwachte functies noemen, niet alleen het versienummer.

De twee versies zijn niet uitwisselbaar

Volgens de Open Charge Alliance zijn OCPP 1.6 en 2.0.1 niet compatibel, en is 2.0.1 geen stapsgewijze evolutie van 1.6: ze delen bepaalde concepten en berichten, maar niet alle. Versie 1.6 bestaat in SOAP en in JSON over WebSocket, versie 2.0.1 enkel in JSON over WebSocket. Versie 2.1, gepubliceerd in 2025, is gebaseerd op 2.0.1 en blijft ermee compatibel.

In de praktijk moeten een laadpaal en een monitoring dezelfde versie spreken. Een monitoring die beide ondersteunt is mogelijk, maar dat is een eigenschap van de uitgever die u moet laten bevestigen, geen vanzelfsprekendheid.

Wat 2.0.1 toevoegt

• Een apparaatmodel, dat de onderdelen van de laadpaal beschrijft, gebeurtenissen meldt met het betrokken onderdeel en een instelbare bewaking mogelijk maakt. De alliantie benadrukt het nut ervan voor parken met meerdere fabrikanten.
• Een uniek transactiebericht, dat de start-, stop- en meetberichten van 1.6 vervangt, met instelbare start- en stopvoorwaarden.
• Een beter gedefinieerd gedrag zonder verbinding: tijdelijke transactienummers die de laadpaal genereert, nummering van de berichten, lokale autorisatielijst.
• Drie beveiligingsprofielen, het beheer van certificaten aan de kant van de laadpaal, ondertekende firmware-updates en een logboek van beveiligingsgebeurtenissen.
• De ondersteuning van ISO 15118-2, waaronder laden zonder badge via een certificaat. In 1.6 werd laden zonder badge alleen gedekt door een aparte toepassingsnota.
• Weergaveberichten, meerdere talen en het volgen van de kosten tijdens het laden.

Versie 1.6 wordt van haar kant door de alliantie nog steeds beschreven als wijdverspreid geïmplementeerd door fabrikanten en uitgevers, en blijft certificeerbaar. Versie 2.0.1 wordt voorgesteld als de komende opvolger als sectorstandaard: dat is een aangekondigde tendens, geen verplichting.

En versie 2.1? Gepubliceerd in 2025, steunt ze op 2.0.1 en voegt onder meer ISO 15118-20 toe met bidirectionele energieoverdracht, bidirectioneel laden (V2X), het beheer van gedecentraliseerde energiebronnen en de ondersteuning van batterijwissel. Op het moment van de raadpleging geeft de FAQ van de alliantie aan dat de details van de certificering nog moeten worden aangekondigd: een product “2.1” heeft dus nog niet dezelfde ervaring achter zich als een product dat voor 1.6 of 2.0.1 is gecertificeerd.

Vragen om te stellen voor u kiest of migreert

1. Welke precieze functies worden geïmplementeerd aan de kant van de laadpaal en aan de kant van de monitoring: laadbeheer, lokale autorisatielijst, update op afstand, laden zonder badge?
2. Is het product gecertificeerd door de Open Charge Alliance, voor welke versie en welke profielen? Het programma bestaat voor 1.6 en 2.0.1.
3. Beschrijft de fabrikant schriftelijk een updatepad voor de laadpaal, en beheert de monitoring de doelversie?
4. Wat gebeurt er met de statussen, meldingen en historieken die uw dashboards gebruiken? Omdat de transacties anders worden gegroepeerd, moeten de indicatoren opnieuw worden gevalideerd.
5. Wie draagt de verantwoordelijkheid voor de test ter plaatse en welke reeks proeven bewijst dat alles weer normaal is?

Een migratie leiden zonder het overzicht van het park te verliezen

Ga te werk met een proefreeks, één laadpaal of één site, in plaats van op het hele park. Bewaar vóór de wijziging de chronologie van de communicaties en de gekende instellingen, en leg daarna elke handeling vast met haar uur. Maak na de wijziging onderscheid tussen drie vaststellingen: de laadpaal communiceert, de monitoring ziet hem, een echte laadsessie start en meldt haar verslag. Die drie vaststellingen zijn niet gelijkwaardig. Overschakelen op 2.0.1 maakt de communicatie ook niet automatisch veiliger: de veiligheid hangt af van het gekozen profiel, van de certificaten en van de manier waarop ze worden beheerd. De logica is dezelfde als bij een offline laadpaal, uitgewerkt in de gids over monitoring.

De instellingen van de laadpaal, de certificaten en de toegangen zijn voorbehouden aan bevoegde en gemachtigde personen, met de documentatie van de fabrikant. Open geen toegang om iets “uit te proberen” en schakel geen beveiligingscontrole uit om een test te versnellen.

Wanneer de communicatie na een wijziging wegvalt

Na een migratie of een update kan een laadpaal offline lijken zonder buiten dienst te zijn. Controleer eerst de omvang (één laadpaal of een hele reeks) en het uur van de laatste communicatie. De pagina /panne oriënteert volgens het symptoom, en de pagina /depannage-borne-de-recharge toont de depannage per stad, waaronder /belgique/depannage-borne-de-recharge/bruxelles voor België.