OCPP 1.6 vs 2.0.1 vs 2.1: alle verschillen op een rij

De drie versies in één overzicht

De belangrijkste conclusie uit deze tabel is praktisch van aard. OCPP 1.6 wint op beschikbaarheid, 2.0.1 op beheersbaarheid en beveiliging, en 2.1 op toekomstvastheid. Welke daarvan zwaarder weegt, hangt af van wat er nu al aan de muur hangt.

Het berichtenmodel: van losse acties naar gebeurtenissen

De grootste verandering in 2.0.1 is dat een transactie één samenhangende gebeurtenisstroom is geworden. Waar 1.6 losse berichten kent voor starten, meten en stoppen, gebruikt 2.0.1 één bericht — TransactionEvent — met de types Started, Updated en Ended.

Dat lost een concreet probleem op. In 1.6 kan een laadpaal die tijdens een sessie de verbinding verliest de transactie niet netjes afsluiten, omdat StopTransaction het CSMS nooit bereikt. In 2.0.1 draagt elk TransactionEvent voldoende context om achteraf te reconstrueren wat er gebeurd is, ook als berichten in een andere volgorde binnenkomen.

Het devicemodel: de onderschatte verandering

OCPP 2.0.1 vervangt de platte configuratielijst door een hiërarchisch devicemodel. In 1.6 zet je instellingen met ChangeConfiguration op een sleutel als HeartbeatInterval — een vlakke lijst die per fabrikant verschilt en nauwelijks te ontdekken valt.

In 2.0.1 bestaat een laadstation uit componenten met variabelen, elk met een type, eenheid en toegestane waardenbereik. Je kunt het volledige model uitlezen met GetBaseReport, waardoor je software zelf kan ontdekken wat een specifieke paal kan in plaats van dat per merk hard te coderen.

// OCPP 1.6 — platte sleutel, betekenis per fabrikant anders
[2,"a1","ChangeConfiguration",{
  "key": "HeartbeatInterval",
  "value": "300"
}]

// OCPP 2.0.1 — expliciet welk onderdeel van welke EVSE
[2,"a1","SetVariables",{
  "setVariableData": [{
    "component": { "name": "OCPPCommCtrlr" },
    "variable": { "name": "HeartbeatInterval" },
    "attributeValue": "300"
  }]
}]

Dit is de reden dat een migratie van 1.6 naar 2.0.1 meer werk is dan het omzetten van berichtnamen. Je beheerlogica moet leren omgaan met een model dat per paal kan verschillen, in plaats van met een lijst die je vooraf kent.

Daar staat een concreet voordeel tegenover: monitoring. Met SetVariableMonitoring laat je een paal zelf melden zodra een waarde buiten een grens komt, bijvoorbeeld een temperatuur of een spanningsniveau. In 1.6 moest je daarvoor blijven pollen.

Beveiliging: van bijlage naar fundament

OCPP 1.6 bevat in de basisspecificatie geen enkele vorm van beveiliging. Er is geen authenticatie voorgeschreven, geen versleuteling en geen certificaatbeheer. In de praktijk betekent dat: een laadpaal die zich met alleen een identifier meldt op een open WebSocket.

De Open Charge Alliance heeft dat achteraf gerepareerd met een aparte securitywhitepaper die drie profielen introduceert. Die profielen zijn optioneel voor 1.6 en verplicht onderdeel van 2.0.1 geworden.

Wat OCPP 2.1 daar bovenop zet

OCPP 2.1 richt zich op de rol van de laadpaal in het energiesysteem, niet op het laden zelf. De grootste toevoeging is bidirectioneel laden: een auto kan energie terugleveren aan het net, een gebouw of een woning.

• Bidirectioneel laden via ISO 15118-20, met een eigen functieblok voor V2X-energiestromen.
• Aansturing van decentrale energiebronnen (DER), zodat zon, batterij en laadpaal samen gestuurd worden.
• Uitgebreidere tariefopties: transacties met een vaste prijs, een vaste hoeveelheid energie of een vaste tijdsduur.
• Ondersteuning voor batterijwissel-stations en ad-hocbetalingen aan de paal.
• Verfijnder slim laden, met betere verdeling van vermogen over meerdere laadpunten.

Voor de meeste Nederlandse bedrijven is 2.1 nu nog vooruitkijken. De hardware-ondersteuning is beperkt en bidirectioneel laden vraagt naast een geschikte laadpaal ook een auto die het ondersteunt. Wie vandaag investeert in nieuwe infrastructuur doet er wel goed aan te controleren of de gekozen palen een upgradepad naar 2.1 hebben.

Welke versie past bij jouw situatie

Je hebt al laadpalen op OCPP 1.6J

Blijf op 1.6J zolang alles werkt, maar zet wel securityprofiel 2 aan. Migreren naar 2.0.1 vraagt in de meeste gevallen een firmware-upgrade van elke paal én een nieuwe serverimplementatie, terwijl 1.6J voorlopig breed ondersteund blijft. De uitzondering is als je Plug & Charge of fijnmazige monitoring nodig hebt.

Je koopt nu nieuwe laadpalen

Kies hardware die 2.0.1 spreekt, ook als je server voorlopig 1.6 draait. Palen gaan tien jaar mee en de norm is inmiddels IEC 63584; hardware die daar niet op uitkomt beperkt je keuze over vijf jaar. Vraag expliciet of 2.0.1 in de huidige firmware zit of alleen op de roadmap staat.

Je bouwt zelf een platform of dienst

Implementeer 2.0.1 als basis en houd 1.6J erbij voor bestaande hardware. Omdat 2.1 achterwaarts compatibel is met 2.0.1, groeit die basis mee zonder herbouw. De omgekeerde volgorde — beginnen bij 1.6 en later 2.0.1 erbij bouwen — kost aanzienlijk meer, omdat het devicemodel dan achteraf in een bestaand ontwerp moet worden gewrongen.