Migreren van OCPP 1.6 naar 2.0.1: stappenplan en valkuilen

Wanneer migreren loont — en wanneer niet

Migreer als je functionaliteit nodig hebt die 1.6 principieel niet biedt. In alle andere gevallen is de kosten-batenverhouding ongunstig, zeker zolang 1.6J breed ondersteund blijft.

Wat er technisch verandert aan jouw kant

1. Transacties worden gebeurtenissen

StartTransaction en StopTransaction verdwijnen ten gunste van TransactionEvent met de types Started, Updated en Ended. Je transactieadministratie moet daarop worden herschreven, inclusief de afhandeling van berichten die in een andere volgorde binnenkomen dan ze zijn verstuurd.

2. Configuratie wordt een devicemodel

De platte sleutel-waardelijst van ChangeConfiguration maakt plaats voor componenten met variabelen. Dit is doorgaans het grootste stuk werk, omdat je code niet langer vaste sleutels kan aannemen maar het model per paal moet uitlezen met GetBaseReport.

3. Statussen worden grover

Van negen connectorstatussen blijven er vijf over. Dashboards, alerts en rapportages die op Preparing, Charging of SuspendedEV filteren, moeten die informatie voortaan uit de transactiegebeurtenissen halen.

4. Identificatie wordt gestructureerd

Het simpele idTag-tekstveld wordt een idToken-object met een expliciet type: RFID, een ISO 15118-certificaat, een lokaal nummer of een centrale identifier. Je autorisatielogica moet dat onderscheid gaan maken.

Stappenplan

1. 1Inventariseer per laadpaal merk, model en firmwareversie, en vraag de leverancier vanaf welke firmware 2.0.1 beschikbaar is. Reken erop dat een deel van je park het nooit gaat halen.
2. 2Bepaal welke functionaliteit je daadwerkelijk nodig hebt. Niet alle zestien functieblokken van 2.0.1 zijn relevant; kies wat je gaat implementeren en leg de rest vast als buiten scope.
3. 3Bouw 2.0.1 naast 1.6 in je server. Beide protocollen draaien een tijd naast elkaar; de WebSocket-subprotocolheader bepaalt welke een paal gebruikt.
4. 4Test per hardwaremodel met één paal. Implementaties verschillen tussen fabrikanten, dus een geslaagde test op merk A zegt weinig over merk B.
5. 5Migreer in golven per locatie, niet per merk. Zo blijft een storing beperkt tot één locatie en houd je een werkende referentie.
6. 6Draai minimaal één volledige factureringscyclus dubbel. Vergelijk de transactieadministratie van beide protocollen voordat je 1.6 uitzet.
7. 7Zet 1.6 pas uit als de laatste paal over is en de cijfers kloppen.

Valkuilen die het meeste tijd kosten

• Aannemen dat 2.0.1-ondersteuning in de folder betekent dat het in de geleverde firmware zit. Vraag altijd naar het exacte versienummer.
• Het devicemodel per merk hardcoderen. Dat werkt tot de eerste paal van een ander merk erbij komt en is dan lastig terug te draaien.
• Historische data niet meenemen. Transacties uit 1.6 hebben een ander model dan die uit 2.0.1; zonder vertaalslag breekt je rapportage op de migratiedatum.
• Eigen DataTransfer-uitbreidingen vergeten. Fabrikantspecifieke functionaliteit die via DataTransfer liep, moet apart worden nagelopen — die verandert niet mee.
• De laadpassen vergeten. Het nieuwe idToken-model met types vraagt vaak een opschoning van de bestaande paslijst.

Die laatste blijkt in de praktijk vaak het meeste handwerk. Paslijsten die jarenlang zijn gegroeid bevatten dubbele nummers, verlopen passen en handmatig ingevoerde identifiers die in het strengere 2.0.1-model niet meer geldig zijn.

En OCPP 2.1?

Wie nu naar 2.0.1 migreert, hoeft zich over 2.1 geen zorgen te maken. OCPP 2.1 is volledig achterwaarts compatibel met 2.0.1: alle applicatielogica blijft werken en de nieuwe functionaliteit zit in aanvullende functieblokken.

Dat maakt 2.0.1 een veilige bestemming. De pijnlijke breuk zit tussen 1.6 en 2.0.1; wie die stap heeft gezet, groeit daarna mee zonder opnieuw te herbouwen.