Engineering / Protokollmigration

Aktualisieren der Firmware des EV-Ladegeräts auf eine neuere OCPP-Version

Der Wechsel von OCPP 1.6J auf 2.0.1 ist kein Versionssprung. Der Nachrichtensatz, das Datenmodell und das Gerätemodell sind so unterschiedlich, dass der größte Teil der Protokollschicht neu geschrieben und nicht erweitert wird. Die sinnvolle erste Frage ist nicht, wie, sondern ob Ihre installierte Hardware das überhaupt tragen kann.

Auf dieser Seite wird die Migration eines vorhandenen Ladegerätprodukts auf eine neuere OCPP-Version behandelt: Welche Änderungen in der Firmware, was die installierte Flotte aufnehmen kann, wie beide Versionen während eines Übergangs nebeneinander betrieben werden und in welchen Fällen die ehrliche Empfehlung lautet, 1,6 J dort zu belassen, wo sie sind.

OCPP Migration

Für Ein Hersteller oder Betreiber, dessen Produkt OCPP 1.6J spricht und dessen Kunden oder Ausschreibungen nun nach einer neueren Version fragen.

01

Was sich tatsächlich zwischen 1,6J und 2,0,1 ändert

Die beiden sind in der Absicht verwandt und in der Konstruktion unterschiedlich. Die Annahme, dass 2.0.1 als 1.6J mit mehr Nachrichten behandelt wird, führt dazu, dass diese Projekte überlastet werden.

Wischen, um zu vergleichen

Hauptunterschiede zwischen OCPP 1.6J und 2.0.1, da sie sich auf eine Firmware-Migration auswirken.
BereichOCPP 1.6JOCPP 2.0.1
GerätemodellImplizit. Anschlüsse und eine LadestationExplizites Komponenten- und Variablenmodell, das deklariert werden muss
KonfigurationFlachschlüssel und WertelisteStrukturierte Variablen mit Attributen und Merkmalen
TransaktionenBeginnen und stoppen Sie mit einer Transaktions-IDEreignisbasiert, mit einem definierten Lebenszyklus und umfassenderen Gründen
SicherheitOptional, weitgehend einsatzspezifischDefinierte Profile inklusive zertifikatbasierter Authentifizierung
Intelligentes LadenGrundprofileDeutlich erweitert, mit klareren Grenzen und Hierarchien
DiagnoseProtokoll-UploadStrukturiertes Überwachungs-, Ereignis- und Berichtsmodell

Das Gerätemodell wird am häufigsten unterschätzt. Dabei handelt es sich nicht um eine Formatierungsänderung, sondern um eine Anforderung, das Produkt auf strukturierte Weise zu beschreiben, für die viele vorhandene Firmware-Designs keine interne Darstellung haben.

02

Die Frage muss zunächst geklärt werden

Bevor Sie Firmware-Arbeiten festlegen, stellen Sie fest, ob die Hardware im Feld den neuen Stack überhaupt unterstützen kann. Drei Zwänge entscheiden darüber.

  • Flash- und RAM-Spielraum. Ein 2.0.1-Stack mit Sicherheitsprofilen ist wesentlich größer als ein 1.6J-Stack, und bei vielen bereitgestellten Controllern wurde nur wenig Platz übrig
  • Kryptografische Fähigkeit. Die zertifikatbasierte Sicherheit erfordert sowohl den Coderaum als auch genügend Verarbeitung, um einen Handshake innerhalb der Zeitüberschreitungen abzuschließen, und auf einigen älteren Controllern ist dies nicht möglich
  • Ein funktionierender Updatepfad. Wenn die Flotte nicht aus der Ferne aktualisiert und überprüft werden kann, handelt es sich bei einer Protokollmigration um eine Fertigungsänderung und nicht um ein Flotten-Upgrade

Wenn bei der installierten Hardware einer dieser Punkte ausfällt, handelt es sich nicht um ein gescheitertes Projekt. Dies bedeutet, dass das Upgrade für die neue Produktion gilt und die installierte Basis bei 1,6 J bleibt, was eine vollkommen praktikable Position ist und viel günstiger ist, als sie auf halbem Weg zu entdecken.

03

Während des Übergangs werden beide Versionen ausgeführt

An einem Wochenende migriert keine echte Flotte. Die praktische Anordnung ist ein Ladegerät, das beide Versionen sprechen kann, wobei die Version zum Zeitpunkt der Verbindung festgelegt und nicht angenommen wird.

OCPP handelt die Version über den WebSocket-Unterprotokoll-Header aus, bevor eine OCPP-Nachricht ausgetauscht wird, sodass eine Einheit beides anbieten und dem Backend die Wahl überlassen kann. Dadurch kann die Hardware den Plattformen voraus sein oder die Plattformen der Hardware voraus sein, ohne dass eine Seite auf die andere warten muss. Es kostet Firmware-Größe, was auf die oben stehende Headroom-Frage zurückführt.

04

Wie die Migration abläuft

  1. 1

    Machbarkeit

    Headroom, Kryptofähigkeit und Update-Pfad im Vergleich zum tatsächlichen Controller bewertet. Das ist eine kurze Arbeit, die alles danach entscheidet.

  2. 2

    Design des Gerätemodells

    Beschreibung des Produkts im Komponenten- und Variablenmodell 2.0.1. Früher erledigt, da es die Firmware-Architektur einschränkt, anstatt auf ihr zu sitzen.

  3. 3

    Stack-Integration

    Die Protokollschicht wurde erstellt oder portiert, wobei die Hardware-Abstraktion erhalten blieb, sodass das bestehende Ladeverhalten nicht gestört wird.

  4. 4

    Interoperabilitätstests

    Die Ausführung erfolgt anhand der spezifischen Plattform und Version, nicht nur anhand der Spezifikation. Compliance und Interoperabilität sind unterschiedliche Eigenschaften.

  5. 5

    Gestaffelte Flottenfreigabe

    Eine überwachte Pilotgruppe mit einem definierten Rollback, bevor flottenweit etwas passiert.

05

Wenn wir Ihnen sagen würden, dass Sie es nicht tun sollen

Es gibt gute Gründe für eine Migration und einen häufig schlechten, nämlich, dass in einem Ausschreibungsdokument nach einer Versionsnummer gefragt wurde, ohne dass jemand den Grund dafür nennen konnte.

  • Wenn nichts in Ihrem Betrieb das erfordert, was 2.0.1 hinzufügt, und kein Kundenvertrag dies erfordert, ist 1.6J ein unterstütztes und weit verbreitetes Protokoll, das nicht aufhört zu funktionieren
  • Wenn Ihre installierten Controller den Stack nicht tragen können, ist die Migration nur der neuen Produktion in der Regel die richtige Antwort und nicht eine Hardware-Aktualisierung, die allein durch das Protokoll gerechtfertigt ist
  • Wenn die eigentliche Anforderung eine bessere Sicherheit ist, kann ein Teil davon bei 1,6J-Bereitstellungen durch Transport- und Netzwerkdesign zu einem Bruchteil der Kosten erreicht werden

Wir bauen diese Stapel, daher kostet es uns Arbeit, davon abzuraten. Es ist immer noch der richtige Rat, wenn es sich beim Treiber um eine Zeile in einer Spezifikation handelt und nicht um etwas, das der Betrieb tatsächlich benötigt.

Auf Ihren eigenen Standort angewendet?

OCPP Migration

Technisch geprüft von Deepu Joy, Director of Products and Delivery. Zuletzt geprüft 2026-09-10.

Häufig gestellte Fragen

Können unsere vorhandenen Ladegeräte aufgerüstet werden oder nur neue?

Dies hängt von der Flash- und RAM-Reserve ab und davon, ob der Controller innerhalb der Protokoll-Timeouts eine zertifikatbasierte Verschlüsselung durchführen kann. Diese Beurteilung ist kurz und sollte erfolgen, bevor irgendetwas anderes festgelegt wird.

Kann ein Ladegerät gleichzeitig 1,6 J und 2,0,1 unterstützen?

Ja. Die Version wird im WebSocket-Unterprotokoll-Header ausgehandelt, bevor eine OCPP-Nachricht ausgetauscht wird, sodass eine Einheit beides anbieten und dem Backend die Auswahl überlassen kann. Es kostet Firmware-Größe.

Was ist mit OCPP 2.1?

Unsere eigene 2.1-Arbeit ist in der Entwicklung. Wo ein Projekt es benötigt, ist der Migrationspfad von 2.0.1 deutlich kürzer als der von 1.6J, da das Gerätemodell bereits vorhanden ist.

Wie lange dauert eine Migration?

Es hängt fast ausschließlich davon ab, wie die vorhandene Firmware aufgebaut ist. Firmware mit einer sauberen Trennung zwischen Protokoll- und Hardwareebene migriert viel schneller als Firmware, bei der die Protokollverarbeitung über die Anwendung verteilt ist.

Ist OCPP 1.6J veraltet?

Nein. Es ist die installierte Basis in den meisten Teilen der Welt und wird nicht abgeschaltet. Neue Beschaffung spezifiziert zunehmend 2.0.1, was eher ein kommerzieller Grund für die Unterstützung als ein technischer Grund für den Verzicht auf 1.6J ist.

Erwägen Sie einen Wechsel zu OCPP 2.0.1?

Beginnen Sie mit der Machbarkeitsfrage. Teilen Sie uns Ihren Controller, Ihren Flash- und RAM-Spielraum mit und ob die Flotte noch heute aus der Ferne aktualisiert wird.

OCPP Migration