Alle artikelen
OCPP590 woordenVertaalconcept – niet geïndexeerd

Een OCPP firmwarestack bouwen voor AC- en DC-laders

Wat een ingebouwde OCPP-client moet doen naast het verzenden van berichten: afstemming van de status, persistentie bij opnieuw opstarten, uitstel en de gelijktijdigheid die de meeste defecten veroorzaakt.

Technisch beoordeeld door Anees P K, Director of Technology. Laatst beoordeeld 2026-09-01.

Een OCPP-client ziet eruit als een berichtenprobleem en is in werkelijkheid een statussynchronisatieprobleem. Twee systemen houden zicht op wat een lader doet, ze zijn met elkaar verbonden via een onbetrouwbare verbinding en beide moeten correct blijven als de verbinding op een ongelegen moment uitvalt.

Implementaties die het behandelen als berichtopmaak werken correct tot de eerste onderbreking.

Doorzettingsvermogen is de basis

Een oplader kan halverwege de sessie opnieuw opstarten en als hij terugkomt, moet hij weten dat er een transactie gaande was. Zonder persistentie gaat die sessie verloren, blijft de connector mogelijk in een inconsistente staat en heeft de backend een open transactie die nooit wordt gesloten.

Wat een herstart moet overleven, zijn de actieve transactie, de identificatiegegevens ervan, het begin van het lezen en eventuele berichten in de wachtrij die nog niet zijn bevestigd. Dit is een beslissing over het opslagontwerp die vroeg wordt genomen, en het later toevoegen ervan betekent meestal een herstructurering van de staatsmachine.

De uitgaande wachtrij

Berichten die offline worden gegenereerd, moeten in volgorde en zonder duplicatie worden opgeslagen en later worden afgeleverd. Duplicatie vindt plaats wanneer de oplader verzendt, de verbinding verliest vóór de bevestiging en niet kan weten of deze is aangekomen.

De klant moet er daarom van uitgaan dat duplicaten mogelijk zijn en dat de backend deze moet detecteren. Ontwerpen alsof een erkenning gegarandeerd is, levert dubbel gefactureerde sessies op.

Opnieuw verbinden en terugtrekken

Gesynchroniseerd opnieuw verbinden in de hele vloot is een echte faalmodus. Een backend die normale belasting overleeft, kan overweldigd worden door duizend opladers die tegelijkertijd opnieuw verbinding maken na een regionale netwerkgebeurtenis.

  • Probeer het opnieuw met toenemende intervallen in plaats van continu, zodat een mislukte backend niet door een hele vloot wordt gehamerd.
  • Voeg randomisatie toe, zodat eenheden die allemaal de connectiviteit zijn kwijtgeraakt, niet allemaal op hetzelfde moment opnieuw verbinding maken.
  • Beperk het interval, zodat een lader het niet effectief opgeeft na een lange storing.
  • Reset de strategie alleen op een werkelijk bestaande sessie, niet op een TCP-verbinding.

Gelijktijdigheid is waar de gebreken leven

De pilot state machine, de meetlus, de berichtenafhandelaar en het updatemechanisme draaien allemaal gelijktijdig en raken allemaal een gedeelde status. De moeilijkste OCPP-defecten zijn eerder onderlinge conflicten dan protocolmisverstanden.

Een veelvoorkomend voorbeeld is een halte op afstand die arriveert wanneer het voertuig de verbinding verbreekt, waardoor twee paden ontstaan die beide proberen dezelfde transactie te beëindigen. Welke wint, en of het resultaat één zuivere stop of twee tegenstrijdige stops is, hangt af van het feit of niemand gedocumenteerd is.

Bediening van de klok

Tijdstempels moeten plausibel zijn, ook als de lader geen netwerk heeft. Een eenheid die opstart met een ongeldige klok en een sessie start, produceert records die niet kunnen worden afgestemd, en het corrigeren van de klok halverwege de sessie creëert een transactie die lijkt te eindigen voordat deze is begonnen.

De werkbare aanpak is een monotone bron voor duur en een absolute klok voor tijdstempels, met een gedefinieerd gedrag voor het venster voordat de absolute klok wordt vertrouwd.

Protocol en product scheiden

De protocolclient mag niets weten over contactors of pilootspanningen, en de laadstatusmachine mag niets weten over berichtformaten. Waar deze zorgen zich vermengen, betekent het ondersteunen van een tweede protocolversie het aanraken van de oplaadlogica, waardoor een protocolupgrade een veiligheidsbeoordeling wordt.

Deze scheiding is de enige ontwerpbeslissing die de meeste invloed heeft op wat een latere migratie kost.

AC en DC verschillen meer dan het protocol suggereert

De berichtenset wordt grotendeels gedeeld. Wat verschilt is de onderliggende laadcontrole: DC omvat een communicatieprotocol met het voertuig en een veel ingewikkeldere stroomregellus, en de timingbeperkingen zijn strenger.

Voor een stapel die is geschreven voor AC en wordt uitgebreid naar DC moet het concurrency-model doorgaans opnieuw worden bekeken, in plaats van dat alleen de statusmachine wordt uitgebreid.