Ein OCPP-Client sieht aus wie ein Messaging-Problem und ist in Wirklichkeit ein Zustandssynchronisierungsproblem. Zwei Systeme haben einen Überblick darüber, was ein Ladegerät tut, sie sind über eine unzuverlässige Verbindung verbunden und beide müssen korrekt bleiben, wenn die Verbindung zu einem ungünstigen Zeitpunkt ausfällt.
Implementierungen, die es als Nachrichtenformatierung behandeln, funktionieren bis zur ersten Unterbrechung ordnungsgemäß.
Beharrlichkeit ist die Grundlage
Ein Ladegerät kann während der Sitzung neu starten, und wenn es zurückkommt, muss es wissen, dass eine Transaktion im Gange ist. Ohne Persistenz geht die Sitzung verloren, der Connector verbleibt möglicherweise in einem inkonsistenten Zustand und das Backend verfügt über eine offene Transaktion, die nie geschlossen wird.
Was einen Neustart überstehen muss, ist die aktive Transaktion, ihre Kennungen, ihr Lesebeginn und alle noch nicht bestätigten Nachrichten in der Warteschlange. Hierbei handelt es sich um eine früh getroffene Speicherdesign-Entscheidung, deren spätere Ergänzung in der Regel eine Umstrukturierung der Zustandsmaschine bedeutet.
Die Ausgangswarteschlange
Offline generierte Nachrichten müssen gespeichert und später der Reihe nach ohne Duplikate zugestellt werden. Eine Vervielfältigung geschieht, wenn das Ladegerät sendet, die Verbindung vor der Bestätigung verliert und nicht wissen kann, ob es angekommen ist.
Der Client muss daher davon ausgehen, dass Duplikate möglich sind und das Backend muss diese erkennen. Das Design, als ob eine Bestätigung garantiert ist, führt zu doppelt abgerechneten Sitzungen.
Wiederverbindung und Backoff
Eine flottenweite synchronisierte Wiederverbindung ist ein echter Fehlermodus. Ein Backend, das die normale Belastung übersteht, kann nach einem regionalen Netzwerkereignis durch tausend Ladegeräte überlastet werden, die gleichzeitig wieder eine Verbindung herstellen.
- Versuchen Sie es nicht kontinuierlich, sondern in zunehmenden Abständen erneut, damit ein ausgefallenes Backend nicht von einer ganzen Flotte geplagt wird.
- Fügen Sie Randomisierung hinzu, damit Einheiten, die alle zusammen die Verbindung verloren haben, nicht alle im selben Moment wieder eine Verbindung herstellen.
- Begrenzen Sie das Intervall, damit ein Ladegerät nach einem längeren Ausfall nicht den Geist aufgibt.
- Setzen Sie die Strategie nur bei einer tatsächlich eingerichteten Sitzung zurück, nicht bei einer TCP-Verbindung.
In der Parallelität leben die Fehler
Die Pilotzustandsmaschine, die Messschleife, der Nachrichtenhandler und der Aktualisierungsmechanismus laufen alle gleichzeitig und berühren alle den gemeinsamen Zustand. Die schwierigsten OCPP-Defekte sind eher Wettkämpfe als Protokollmissverständnisse.
Ein häufiges Beispiel ist ein Fernstopp, der eintrifft, während das Fahrzeug abkuppelt und zwei Pfade erzeugt, die beide versuchen, dieselbe Transaktion zu beenden. Wer gewinnt und ob das Ergebnis ein sauberer Stopp oder zwei widersprüchliche ist, hängt von der Sperre ab, die niemand dokumentiert hat.
Umgang mit der Uhr
Zeitstempel müssen auch dann plausibel sein, wenn das Ladegerät kein Netzwerk hat. Eine Einheit, die mit einer ungültigen Uhr startet und eine Sitzung startet, erzeugt Datensätze, die nicht abgeglichen werden können, und die Korrektur der Uhr mitten in der Sitzung führt zu einer Transaktion, die scheinbar vor ihrem Start endet.
Der praktikable Ansatz ist eine monotone Quelle für die Dauer und eine absolute Uhr für Zeitstempel mit einem definierten Verhalten für das Fenster, bevor der absoluten Uhr vertraut wird.
Protokoll vom Produkt trennen
Der Protokoll-Client sollte nichts über Schütze oder Steuerspannungen wissen, und die Ladezustandsmaschine sollte nichts über Nachrichtenformate wissen. Wenn diese Bedenken zusammenkommen, bedeutet die Unterstützung einer zweiten Protokollversion, dass die Ladelogik berührt wird, wodurch ein Protokoll-Upgrade zu einer Sicherheitsüberprüfung wird.
Diese Trennung ist die einzige Entwurfsentscheidung, die sich am meisten auf die Kosten einer späteren Migration auswirkt.
AC und DC unterscheiden sich stärker, als das Protokoll vermuten lässt
Der Nachrichtensatz wird größtenteils gemeinsam genutzt. Was sich unterscheidet, ist die zugrunde liegende Ladesteuerung: Gleichstrom umfasst ein Kommunikationsprotokoll mit dem Fahrzeug und einen weitaus komplexeren Leistungsregelkreis, und die zeitlichen Einschränkungen sind strenger.
Bei einem für AC geschriebenen und auf DC erweiterten Stack muss in der Regel das Parallelitätsmodell überarbeitet und nicht nur die Zustandsmaschine erweitert werden.