Voertuigprotocol versus Backendprotocol: Twee aparte stacks

Een oplader zit tussen twee gesprekken die elkaar niet ontmoeten. Aan de ene kant wordt met het voertuig verteld hoeveel stroom het moet nemen en wie betaalt. Aan de andere kant praat het met een backend over sessies, meters en externe commando's. De twee gebruiken verschillende protocollen, verschillende datamodellen en verschillende certificeringsregimes.

Kopers halen ze voortdurend door elkaar, en de verwarring leidt tot enkele van de duurste misverstanden in de inkoop: een specificatie die een modern backendprotocol vereist in de veronderstelling dat het plug and charge levert, of een voertuigupgrade die een facturatieprobleem zal oplossen. Het scheiden van de lagen maakt elke vereiste op zichzelf controleerbaar.

Twee stapels, twee taken

De onderste stack loopt over de oplaadkabel. Het verzorgt de fysieke aansluiting, de veiligheidscontroles voordat de stroom wordt aangelegd, het onderhandelen van laadparameters en — in latere versies — de identiteit van het voertuig en de certificaatuitwisseling die automatische autorisatie mogelijk maakt.

De bovenste stack loopt via een netwerkverbinding, meestal mobiele data of een site LAN. Het bevat wat de operator nodig heeft: start- en stopcommando's, transactierecords, meterwaarden, diagnostiek, firmwarebeheer en configuratie. Het heeft geen direct zicht op het voertuig. Alles wat het weet over een sessie, heeft het geleerd van de oplader.

Die asymmetrie is de sleutel tot het hele onderwerp. De oplader is een vertaler met eigen meningen, geen transparante pijp. Wat de backend registreert, is wat de lader heeft gekozen te rapporteren, in het formaat dat het bovenste protocol definieert.

Tussen Voertuig en Lader

De oudere opstelling is eenvoudig en nog steeds universeel als vangnet. Een pulsbreedte-gemoduleerd signaal op de besturingspiloot geeft een maximale stroom, het voertuig reageert door een spanningsniveau te veranderen, en de lader sluit zijn contactor wanneer de volgorde het toelaat. Er is geen datakanaal in de moderne zin en geen identiteitsuitwisseling. Autorisatie gebeurt buiten het protocol, via een kaartlezer, een app of een handmatige release.

De high-level protocollen voegen een datakanaal toe. ISO 15118 en zijn voorganger DIN 70121 voeren een gestructureerd gesprek over hoogspanningscommunicatie: het voertuig identificeert zichzelf, de twee partijen wisselen van mogelijkheden, het voertuig geeft aan wat het wil en de lader rapporteert wat het kan leveren. De uitwisseling gaat door gedurende de hele sessie, waardoor de lader het verzoek van het voertuig kan zien in plaats van alleen de resulterende stroom.

De latere edities van ISO 15118 breiden dit uit naar certificaatgebaseerde identiteit, wat automatische autorisatie mogelijk maakt, en naar bidirectionele energieoverdracht. Beide extensies vereisen hardware en software die een oplader die alleen voor de eerdere editie is gebouwd niet heeft.

Deze laag is waar de eigenschappen van het voertuig het systeem binnenkomen. Het is ook waar de eigen documentatie van een lader meestal twee aparte dingen vermeldt: welk high-level protocol het met het voertuig spreekt, en welk backendprotocol het omhoog spreekt.

Tussen Charger en Backend

Het dominante protocol hier is OCPP, een open standaard die wordt onderhouden door een branchevereniging en onafhankelijk wordt geïmplementeerd door opladerfabrikanten en backendplatforms. Het definieert berichten voor autorisatie, transactiestart en -stop, meterwaarden, statusmeldingen, externe commando's, firmware-updates en configuratie.

Latere versies van OCPP voegen apparaatbeheer, verbeterde slimme laadprofielen en een meer gestructureerde aanpak van samengestelde schema's toe. Het praktische verschil voor een operator is hoeveel controle de backend heeft over wanneer en hoe snel elke connector oplaadt, en hoeveel daarvan kan worden aangepast zonder een bezoek aan de locatie.

Wat OCPP niet doet, is met het voertuig communiceren. Een backend die de nieuwste versie ondersteunt, leert het voertuig nog steeds via tweedehands. Als de lader geen waarde rapporteert, kan de backend die niet weergeven en herstelt geen enkele platformverfijning hem.

Naleving voegt een extra laag verwarring toe. OCPP-conformiteit is gecertificeerd voor een oplader op basis van een gedefinieerde versie, en de certificering behoort toe aan dat product en die versie. Er staat niets over het voertuig-side protocol, en ook niet over hoe goed een bepaalde backend dezelfde versie implementeert. Twee conforme producten kunnen nog steeds falen in het samenwerken op de optionele onderdelen van de specificatie, daarom bestaat integratietesten als een aparte activiteit.

Waarom plug and charge beide kanten nodig heeft

Automatische autorisatie, meestal omschreven als plug and charge, is een keten in plaats van een functie. Het voertuig toont een contractcertificaat over het hoog-niveau protocol. De lader valideert het tegen een certificaatketen die hij vertrouwt, en autoriseert lokaal of stuurt de identiteit omhoog voor een beslissing. De backend bevestigt dat het contract geldig is en gefactureerd kan worden.

Elke link moet aanwezig zijn. Een voertuig zonder contractcertificaat mag geen certificaat tonen. Een oplader zonder het high-level protocol en de trust store kunnen het niet lezen. Een backend zonder de bijbehorende certificaatbehandeling kan het niet afhandelen. Wanneer er een verbinding ontbreekt, valt de sessie terug op een kaart, een app of een QR-code — precies wat bestuurders ervaren op netwerken die automatisch laden adverteren en het alleen aanbieden voor bepaalde combinaties van voertuig en bestuurder.

Dit is ook waarom de functie in de praktijk ongelijk beschikbaar is. Het hangt af van de doorsnede van drie onafhankelijk bijgewerkte systemen, en de doorsnede is kleiner dan elk van hen.

Het upgraden van de ene upgrade de ander niet

Vier veelvoorkomende aannames falen om dezelfde reden.

Dat een nieuwer backend-protocol automatische autorisatie levert. Dat is niet zo, omdat de autorisatie via de onderste stapel verloopt. Een oplader kan de nieuwste backendversie gebruiken en toch een kaart vereisen.

Dat een voertuig met automatische laadondersteuning op elk netwerk werkt. Het werkt waarbij de lader en de backend ervoor zijn geconfigureerd en de operator een roaming- of contractrelatie heeft met de provider van het voertuig.

Dat een firmware-update van de oplader een voertuigzijde functie toevoegt. De kant van het gesprek van de oplader kan worden bijgewerkt. Het voertuig kan niet, van de oplader.

En die ene certificering dekt beide. Certificeringen worden per product, per protocol en per versie uitgegeven, en een certificaat dat de ene laag benoemt zegt niets over de andere.

Een goed gespecificeerde oplader geeft de twee lagen afzonderlijk aan, en producten in deze reeks vermelden doorgaans een backend-protocolversie naast de voertuigzijde protocollen die ze ondersteunen. De 120 en 180 kW stationspecificatie doet dit, en de scheiding maakt de twee eisen afzonderlijk testbaar.

Hoe dit in een vereiste te schrijven

Een vereiste die niet getest kan worden, is geen vereiste. Vier lijnen maken het testbaar.

Geef het voertuig-zijde protocol en de versie aan die oplader moet ondersteunen, en of automatische autorisatie op die interface vereist is. Geef het backendprotocol en de versie aan, en of conformiteit gecertificeerd moet worden of slechts verklaard. Geef het fallbackgedrag aan wanneer een van de onderhandelingen faalt, want een site die stilletjes naar een niet-geauthenticeerde modus schakelt, is een inkomstenprobleem. En geef aan welk bewijs wordt geaccepteerd: een certificaatnummer, een testrapport of een gezamenlijke test met het platform dat de exploitant wil gebruiken.

De laatste daarvan is degene die de meeste projecten opvangt. Conformiteitstesten bewijzen dat een product aan een specificatie voldoet. Integratietests bewijzen dat twee producten samenwerken. Inkoopdocumenten vragen vaak om het eerste en vereisen het tweede, en het gat wordt pas zichtbaar nadat de hardware is geleverd.

De relatie tussen deze protocollen en load management is zo nauw dat het zelf verwarring veroorzaakt: een slim laadprofiel dat via het backend-protocol wordt geleverd, is een instructie aan de lader, die deze vervolgens moet respecteren binnen wat het voertuig accepteert. Die interactie wordt behandeld in de notitie op belastingbeheer, dat beschrijft waar de instructie eindigt en de eigen limieten van het voertuig beginnen.

Voor de meeste operators is het praktische gevolg een checklist in plaats van een herontwerp. Schrijf de twee protocolvereisten op aparte lijnen, noem de versie van elk, vraag wat er gebeurt als onderhandelingen mislukken, en test de combinatie voordat de site opent in plaats van na de eerste klacht.