Beispiele
Beispiele
Vier typische Konstellationen, wie sie im Second- und Third-Level-Support für Ladetechnik immer wieder vorkommen – und wie ich an sie herangehe.
Die Beispiele sind synthetisch: Sie beschreiben typische Konstellationen, keine Kundenprojekte. Namen von Kunden oder Flotten nenne ich nicht; Gerätehersteller nur beschreibend.
01
Typische Konstellation, keine Kundenreferenz
Sporadische Offline-Phasen bei Mobilfunkanbindung
- Ausgangslage
- Eine Wallbox mit Mobilfunkanbindung ist im Backend immer wieder für einige Minuten offline. Vor Ort ist nie ein Fehler zu sehen; ein Neustart hilft, aber nicht dauerhaft.
- Mögliche Ursachen
- Keepalive: Heartbeat oder WebSocket-Ping kommen zu selten, um die Verbindung offen zu halten.
- NAT-Timeout im Mobilfunknetz ist kürzer als das Intervall, in dem das Gerät Daten sendet.
- Modem-Firmware verliert die Datenverbindung, ohne dass die Ladesteuerung es bemerkt.
- Vorgehen
- Heartbeat-Lücken im Backend mit Geräte-Logs und Modem-Statusmeldungen zeitlich abgleichen, Muster nach Netz, Tageszeit und Firmware-Stand trennen, Keepalive-Parameter gezielt variieren.
- Ergebnis
- Eine belegte Ursache – zum Beispiel ein zu langes Keepalive-Intervall im Verhältnis zum NAT-Timeout – mit Sofortmaßnahme per Konfiguration und dauerhafter Abstellmaßnahme in der Firmware.
02
Typische Konstellation, keine Kundenreferenz
Das Gerät läuft an Backend X, aber nicht an Backend Y
- Ausgangslage
- Ein Ladepunkt funktioniert an einem Backend einwandfrei. An einem zweiten Backend meldet er sich an, startet aber keine Transaktion – oder wird gar nicht erst akzeptiert.
- Mögliche Ursachen
- BootNotification wird abgelehnt oder bleibt im Status „Pending“.
- Die Aushandlung des WebSocket-Subprotokolls (OCPP-Version) scheitert.
- Konfigurationsschlüssel oder Feldformate weichen von dem ab, was das zweite Backend erwartet.
- Vorgehen
- Nachrichtenverlauf an beiden Backends nebeneinanderlegen, Abweichungen gegen die OCPP-Spezifikation prüfen, Konfigurationen vergleichen.
- Ergebnis
- Eine Liste der Abweichungen mit klarer Zuordnung: Was ändert die Firmware, was die Backend-Konfiguration?
03
Typische Konstellation, keine Kundenreferenz
Signierte Messwerte werden nach einem Firmware-Update abgelehnt
- Ausgangslage
- Nach einem Firmware-Update lehnen Backend oder Transparenzsoftware die signierten Messwerte ab. Ladevorgänge lassen sich nicht mehr abrechnen.
- Mögliche Ursachen
- Der öffentliche Schlüssel hat sich geändert oder wird anders an das Backend übertragen.
- Format oder Kodierung der OCMF-Datensätze haben sich geändert.
- Zeitstempel oder Zeitzone weichen ab.
- Vorgehen
- OCMF-Datensätze vor und nach dem Update vergleichen, Signaturen mit dem hinterlegten öffentlichen Schlüssel prüfen, den Weg des Schlüssels ins Backend nachvollziehen.
- Ergebnis
- Eine klare Aussage, ob Gerät, Update-Prozess oder Backend-Konfiguration angepasst werden muss – und welche bereits erzeugten Datensätze betroffen sind.
04
Typische Konstellation, keine Kundenreferenz
Ladeprofile werden nach einem Neustart ignoriert (§ 14a EnWG)
- Ausgangslage
- Der Netzbetreiber begrenzt die Leistung. Nach einem Neustart lädt das Fahrzeug wieder mit voller Leistung, bis das Backend das Ladeprofil erneut sendet.
- Mögliche Ursachen
- Ladeprofile werden nicht dauerhaft gespeichert.
- Gültigkeitszeitraum oder Stack-Level des Profils passen nicht.
- Nach dem Start beginnt die Transaktion, bevor das Profil wieder aktiv ist.
- Vorgehen
- Boot-Sequenz und Ladeprofil-Nachrichten zeitlich auswerten, das Verhalten gegen die OCPP-Spezifikation und die Anforderungen aus § 14a EnWG abgleichen, im Testaufbau reproduzieren.
- Ergebnis
- Eine belegte Ursache mit Maßnahmen für Firmware und Backend-Konfiguration.
Wie sieht ein Bericht aus?
Ein synthetischer Muster-8D-Bericht zeigt Aufbau und Detailtiefe am Beispiel der Offline-Phasen.