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 MigrationFür Ein Hersteller oder Betreiber, dessen Produkt OCPP 1.6J spricht und dessen Kunden oder Ausschreibungen nun nach einer neueren Version fragen.
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
| Bereich | OCPP 1.6J | OCPP 2.0.1 |
|---|---|---|
| Gerätemodell | Implizit. Anschlüsse und eine Ladestation | Explizites Komponenten- und Variablenmodell, das deklariert werden muss |
| Konfiguration | Flachschlüssel und Werteliste | Strukturierte Variablen mit Attributen und Merkmalen |
| Transaktionen | Beginnen und stoppen Sie mit einer Transaktions-ID | Ereignisbasiert, mit einem definierten Lebenszyklus und umfassenderen Gründen |
| Sicherheit | Optional, weitgehend einsatzspezifisch | Definierte Profile inklusive zertifikatbasierter Authentifizierung |
| Intelligentes Laden | Grundprofile | Deutlich erweitert, mit klareren Grenzen und Hierarchien |
| Diagnose | Protokoll-Upload | Strukturiertes Ü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.
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.
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.
Wie die Migration abläuft
- 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
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
Stack-Integration
Die Protokollschicht wurde erstellt oder portiert, wobei die Hardware-Abstraktion erhalten blieb, sodass das bestehende Ladeverhalten nicht gestört wird.
- 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
Gestaffelte Flottenfreigabe
Eine überwachte Pilotgruppe mit einem definierten Rollback, bevor flottenweit etwas passiert.
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 MigrationVerwandte Inhalte
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