Der Aufbau eines Lade-Backends ist nicht in erster Linie eine Protokollübung. Das Protokoll ist dokumentiert und endlich. Die Schwierigkeit besteht darin, den genauen Status für Tausende langlebiger Verbindungen aufrechtzuerhalten, deren Gegenparteien unzuverlässig und inkonsistent sind.
Jedes schwierige Problem in einer Ladeplattform ist eine Variante davon.
Langlebige Verbindungen verändern die Architektur
Ladegeräte halten die Verbindung wochenlang aufrecht. Das ist anders als beim Request-Response-Webverkehr und schränkt die Bereitstellung der Plattform ein: Bei einem routinemäßigen Neustart wird jede Verbindung unterbrochen, und eine Flotte, die sich gleichzeitig wieder verbindet, trifft als Donnerherde ein.
Um dies zu bewältigen, ist ein Verbindungsstatus erforderlich, der Prozessneustarts übersteht, oder ein Bereitstellungsmodell, das Verbindungen ordnungsgemäß entleert, anstatt sie zu löschen.
Transaktionsintegrität über Unterbrechungen hinweg
Eine Sitzung kann beginnen, die Verbindung kann unterbrochen werden, das Ladegerät kann neu starten und der Stopp kann Stunden später oder nie erfolgen. Die Plattform muss alle diese Punkte in einen vertretbaren Abrechnungsdatensatz umwandeln.
Das bedeutet, dass Transaktionen nicht an eine Verbindung gebunden im Speicher gehalten werden können. Sie sind dauerhaft und haben einen Lebenszyklus, der unabhängig davon ist, ob das Ladegerät gerade erreichbar ist.
Duplikate sind garantiert
Ein Ladegerät, das keine Bestätigung erhält, sendet erneut. Früher oder später kommt jeder Nachrichtentyp zweimal an und das Backend muss ihn erkennen, anstatt ihn als neu zu behandeln.
Idempotenz ist daher eine Designanforderung und keine Verfeinerung. Ohne sie wird ein Netzwerk den Fahrern doppelte Rechnungen stellen, was mehr Vertrauen kostet, als die Energie wert war.
Abweichendes Ladegerätverhalten tolerieren
Ladegeräte unterscheiden sich in den unterstützten Konfigurationsschlüsseln, der Fehlercodezuordnung, den Statusübergängen und in der Art und Weise, wie strikt sie sich an die Spezifikation halten. Ein Backend, das gegen das Verhalten eines Anbieters geschrieben wurde, schlägt beim zweiten Anbieter fehl.
Das verbleibende Muster besteht aus einem Kern, der die Spezifikation verwaltet, und einer herstellerspezifischen Anpassungsschicht, die die Unterschiede normalisiert, wobei der Rohaustausch erhalten bleibt, sodass unerwartetes Verhalten untersucht und nicht vermutet werden kann.
Behalten Sie den Austausch bei
Das wertvollste Betriebsmerkmal ist die Möglichkeit zu lesen, was zu einem bestimmten Zeitpunkt tatsächlich mit einem bestimmten Ladegerät ausgetauscht wurde. Es schlichtet Lieferantenstreitigkeiten, diagnostiziert vorübergehende Fehler und beantwortet Rechnungsfragen.
Plattformen, die nur Ergebnisse speichern, machen jeden Vorfall zur Ansichtssache. Lagerung kostet Geld; Die fehlende Spur kostet mehr.
Die Unterstützung zweier Protokollversionen ist dauerhaft
Flotten migrieren nicht atomar, sodass ein Backend, das ein echtes Netzwerk bedient, mehr als eine Version auf unbestimmte Zeit unterstützt. Wenn man das als Übergangszustand betrachtet, entsteht eine Architektur, die der Realität entgegentritt.
Die Versionen unterscheiden sich hinsichtlich Gerät und Transaktionsmodell so stark, dass nahezu zwei Protokolle unterstützt werden, und die Planung von Anfang an ist weitaus günstiger als eine Nachrüstung.
Die Zeit ist schwieriger als es aussieht
Ladegeräte driften ab, melden ihre eigene Zeitzone und liefern nach Ausfällen rückwirkende Transaktionen. Tarife sind zeitabhängig, daher ist die Handhabung von Zeitstempeln eher ein Problem der Abrechnungskorrektheit als ein Problem der Formatierung.
Das Speichern aller Daten in einer einzigen absoluten Referenz und das Beibehalten der vom Ladegerät gemeldeten Zeit neben der empfangenen Zeit ermöglicht einen späteren Abgleich.