Ein Ladegerät sitzt zwischen zwei Gesprächen, die sich nicht begegnen. Auf der einen Seite spricht es mit dem Fahrzeug darüber, wie viel Strom es nehmen soll und wer zahlt. Andererseits spricht es mit einem Backend über Sitzungen, Meter und Fernbefehle. Beide verwenden unterschiedliche Protokolle, unterschiedliche Datenmodelle und unterschiedliche Zertifizierungsregime.
Käufer verwechseln sie ständig, und die Vermischung führt zu einigen der teuersten Missverständnisse im Beschaffungsbereich: eine Spezifikation, die ein modernes Backend-Protokoll erfordert, in der Annahme, dass es Plug and Charge liefert, oder ein Fahrzeug-Upgrade, das ein Abrechnungsproblem beheben soll. Die Trennung der Schichten macht jede Anforderung für sich überprüfbar.
zwei Stacks, zwei Jobs
Der untere Stapel verläuft über das Ladekabel. Es übernimmt die physische Verbindung, die Sicherheitskontrollen vor der Stromanwendung, die Aushandlung von Ladeparametern und – in späteren Versionen – die Identität des Fahrzeugs und den Zertifikatsaustausch, der eine automatische Genehmigung ermöglicht.
Der obere Stack läuft über eine Netzwerkverbindung, meist mobile Daten oder ein LAN an einem Standort. Er transportiert, was der Bediener benötigt: Start- und Stoppbefehle, Transaktionsaufzeichnungen, Zählerwerte, Diagnosen, Firmware-Verwaltung und Konfiguration. Es hat keinen direkten Blick auf das Fahrzeug. Alles, was es über eine Sitzung weiß, hat es vom Ladegerät gelernt.
Diese Asymmetrie ist der Schlüssel zum gesamten Thema. Das Ladegerät ist ein Übersetzer mit eigenen Meinungen, kein transparentes Rohr. Was das Backend aufzeichnet, ist das, was das Ladegerät meldet, in dem Format, das das obere Protokoll definiert.
Zwischen Fahrzeug und Ladegerät
Die ältere Anordnung ist einfach und weiterhin universell als Rückfall. Ein pulsbreitenmoduliertes Signal am Steuerpiloten überträgt einen maximalen Strom, das Fahrzeug reagiert, indem es einen Spannungspegel ändert, und das Ladegerät schließt seinen Kontaktor, wenn die Sequenz es erlaubt. Es gibt keinen Datenkanal im modernen Sinne und keinen Identitätsaustausch. Die Autorisierung erfolgt außerhalb des Protokolls, über einen Kartenleser, eine App oder eine manuelle Freigabe.
Die hochrangigen Protokolle fügen einen Datenkanal hinzu. ISO 15118 und sein Vorgänger DIN 70121 führen eine strukturierte Kommunikation über die Stromleitung: Das Fahrzeug identifiziert sich, die beiden Seiten tauschen Fähigkeiten aus, das Fahrzeug gibt an, was es möchte, und der Ladegerät meldet, was er liefern kann. Der Austausch läuft während der gesamten Sitzung weiter, weshalb das Ladegerät die Anfrage des Fahrzeugs sehen kann und nicht nur den resultierenden Strom.
Die späteren Ausgaben von ISO 15118 erweitern dies auf die zertifikatsbasierte Identität, die die automatische Autorisierung ermöglicht, sowie auf bidirektionale Energieübertragung. Beide Erweiterungen erfordern Hardware und Software, die ein Charger, das nur für die frühere Edition gebaut wurde, nicht hat.
Diese Ebene ist der Ort, an dem die Fahrzeugeigenschaften ins System gelangen. Es ist auch der Ort, an dem die eigene Dokumentation eines Ladegeräts meist zwei verschiedene Dinge angibt: welches High-Level-Protokoll mit dem Fahrzeug spricht, und welches Backend-Protokoll es nach oben spricht.
Zwischen Charger und Backend
Das dominierende Protokoll hier ist OCPP, ein offener Standard, der von einem Branchenverband gepflegt und von Ladegerätherstellern sowie Backend-Plattformen unabhängig implementiert wird. Es definiert Nachrichten für Autorisierung, Transaktionsstart und -stopp, Messwerte, Statusbenachrichtigungen, Fernbefehle, Firmware-Updates und Konfigurationen.
Spätere Versionen von OCPP fügen Geräteverwaltung, verbesserte intelligente Ladeprofile und einen strukturierteren Ansatz für zusammengesetzte Zeitpläne hinzu. Der praktische Unterschied für einen Bediener besteht darin, wie viel Kontrolle das Backend darüber hat, wann und wie schnell jeder Stecker lädt, und wie viel davon ohne Besuch vor Ort geändert werden kann.
Was OCPP nicht tut, ist, mit dem Fahrzeug zu kommunizieren. Ein Backend, das die neueste Version unterstützt, lernt das Fahrzeug noch gebraucht kennen. Wenn das Ladegerät keinen Wert angibt, kann das Backend ihn nicht anzeigen, und keine Plattform-Raffinesse stellt ihn wieder her.
Compliance fügt eine weitere Verwirrungsebene hinzu. Die OCPP-Konformität ist für ein Ladegerät anhand einer definierten Version zertifiziert, und die Zertifizierung gehört zu diesem Produkt und jener Version. Es steht nichts über das fahrzeugseitige Protokoll und auch nichts darüber, wie gut ein bestimmtes Backend dieselbe Version implementiert. Zwei konforme Produkte können weiterhin nicht an den optionalen Teilen der Spezifikation interagieren, weshalb Integrationstests als separate Aktivität existieren.
Warum Plug and Charge beide Seiten braucht
Automatische Autorisierung, üblicherweise als Plug and Charge beschrieben, ist eine Kette und kein Feature. Das Fahrzeug präsentiert ein Vertragszertifikat über dem hochrangigen Protokoll. Der Ladegerät validiert ihn gegen eine Zertifikatskette, der er vertraut, und autorisiert entweder lokal oder leitet die Identität nach oben weiter, um eine Entscheidung zu treffen. Das Backend bestätigt, dass der Vertrag gültig ist und abgerechnet werden kann.
Jeder Link muss vorhanden sein. Ein Fahrzeug ohne Vertragsbescheinigung darf keine vorlegen. Ein Ladegerät ohne das hochstufige Protokoll und der Trust Store können es nicht lesen. Ein Backend ohne die entsprechende Zertifikatsbehandlung kann es nicht abschließen. Wenn eine Verbindung fehlt, greift die Sitzung auf eine Karte, eine App oder einen QR-Code zurück – genau das erleben Fahrer in Netzwerken, die automatisches Laden bewerben und nur für bestimmte Fahrzeug- und Fahrerkombinationen ausliefern.
Deshalb ist die Funktion in der Praxis auch ungleichmäßig verfügbar. Sie hängt vom Schnitt von drei unabhängig aktualisierten Systemen ab, und der Schnitt ist kleiner als jedes einzelne von ihnen.
Das Upgrade eines verbessert das andere nicht das andere
Vier gängige Annahmen scheitern aus demselben Grund.
Dass ein neueres Backend-Protokoll automatische Autorisierung liefert. Das tut sie nicht, weil die Autorisierung über den unteren Stack läuft. Ein Ladegerät kann die neueste Backend-Version übertragen und benötigt trotzdem eine Karte.
Dass ein Fahrzeug mit automatischem Laden in jedem Netzwerk funktioniert. Es funktioniert so, dass das Ladegerät und das Backend dafür konfiguriert sind und der Betreiber eine Roaming- oder Vertragsbeziehung mit dem Anbieter des Fahrzeugs hat.
Dass ein Firmware-Update des Ladegeräts eine fahrzeugseitige Funktion hinzufügt. Die Seite des Ladegeräts kann aktualisiert werden. Das Fahrzeug kann das nicht vom Ladegerät aus.
Und diese Zertifizierung deckt beide ab. Zertifizierungen werden pro Produkt, pro Protokoll und pro Version ausgegeben, und ein Zertifikat, das eine Schicht benennt, sagt nichts über die andere aus.
Ein gut spezifiziertes Ladegerät gibt die beiden Schichten getrennt an, und Produkte in diesem Bereich listen typischerweise eine Backend-Protokollversion neben den fahrzeugseitigen Protokollen an, die sie unterstützen. Die 120 und 180 kW Stationsspezifikation macht dies, und die Trennung macht die beiden Anforderungen individuell testbar.
Wie man dies in eine Anforderung schreibt
Eine Anforderung, die nicht getestet werden kann, ist keine Voraussetzung. Vier Linien machen es testbar.
Geben Sie das fahrzeugseitige Protokoll und die Ausgabe an, die das Ladegerät unterstützen muss, und ob eine automatische Autorisierung auf dieser Schnittstelle erforderlich ist. Geben Sie das Backend-Protokoll und die Version an und ob die Konformität zertifiziert oder lediglich deklariert werden muss. Geben Sie das Rückfallverhalten an, wenn eine der Verhandlungen scheitert, denn eine Seite, die lautlos in einen nicht authentifizierten Modus übergeht, ist ein Umsatzproblem. Und geben Sie an, welche Beweise akzeptiert werden: eine Zertifikatsnummer, einen Testbericht oder einen gemeinsamen Test mit der Plattform, die der Betreiber verwenden möchte.
Letzteres davon ist das, das die meisten Projekte erfasst. Konformitätstests beweisen, dass ein Produkt einer Spezifikation entspricht. Integrationstests beweisen, dass zwei Produkte zusammenarbeiten. Beschaffungsdokumente verlangen häufig das erste und benötigen das zweite, und die Lücke wird erst sichtbar, nachdem die Hardware geliefert wurde.
Die Beziehung zwischen diesen Protokollen und dem Lastmanagement ist eng genug, um eigene Verwirrung zu verursachen: Ein Smart Charging Profile, das über das Backend-Protokoll geliefert wird, ist eine Anweisung an den Ladegerät, der diese dann innerhalb dessen respektieren muss, was das Fahrzeug akzeptiert. Diese Interaktion wird in der Notiz behandelt zu load management, das beschreibt, wo die Instruktion endet und die eigenen Grenzen des Fahrzeugs beginnen.
Ein Stapel zeigt das Fahrzeug, einer zeigt die Plattform, und keiner kann den anderen ersetzen. Wenn ein Feature fehlt, ist die erste Frage, auf welchem Stack es eigentlich ankommen sollte.
Für die meisten Operatoren ist die praktische Folge eine Checkliste und kein Redesign. Schreiben Sie die beiden Protokollanforderungen auf getrennte Zeilen, nennen Sie jeweils die Version, fragen Sie, was passiert, wenn Verhandlungen scheitern, und testen Sie die Kombination, bevor die Seite eröffnet wird, statt nach der ersten Beschwerde.
Überprüfen, was ein Ladegerät tatsächlich unterstützt?
Fragen Sie nach dem fahrzeugseitigen Protokoll und dem Backend-Protokoll als zwei separate Zeilen, jeweils mit ihrer Version. Ein Zertifikat deckt nicht beide ab.
Stellen Sie eine Spezifikationsfrage