Warum Ladevorgänge fehlschlagen: Ein Diagnoseleitfaden für Betreiber und Fahrer

Die Ladestation meldet Verfügbar. Der Fahrer schließt das Fahrzeug an. Nichts passiert. Oder der Ladevorgang läuft zwei Stunden und bricht bei 4 % unter dem Zielwert ab, während das Dashboard den Port die ganze Zeit als online anzeigt.

Jeder Betreiber hat wöchentlich damit zu tun. Kaum jemand veröffentlicht den Entscheidungsbaum dazu.

Dieser Leitfaden ist genau dieser Baum. Er unterteilt Fehler bei Ladevorgängen in drei Zweige, basierend auf dem, was man morgens um 6 Uhr auf dem Betriebshof sieht – also dem Verhalten der Ladestation. Anschließend liefert er das Diagnosesignal für jeden Fall: den OCPP-Status und den Fehlercode, den Sie erwarten würden, ob der Hinweis im Ladestationsprotokoll oder im Backend-Log zu finden ist und wie man zwischen einem fahrzeugseitigen, ladestationsseitigen oder netzwerkseitigen Fehler unterscheidet. Der letzte Abschnitt behandelt die operative Ebene: Welche Fehler beheben sich von selbst, welche erfordern einen Remote-Reset, welche einen Vor-Ort-Einsatz und wie man die Meldungen steuert, ohne das Team mit Alarmen zu überfluten.

Hier anfangen: Die Triage in drei Zweigen

Die Reihenfolge ist entscheidend. Zweig eins bedeutet, dass die Ladestation ohnehin nicht funktionieren würde; egal, was der Fahrer tut. Zweig zwei und drei sind einen Versuch des Fahrers wert.

Zweig 1: Die Ladestation ist gestört oder nicht verfügbar

So sieht es aus. Die Statusleuchte leuchtet rot. Auf dem Bildschirm steht „Nicht verfügbar“, „Gestört“, „Außer Betrieb“ oder Ähnliches. Dies ist sichtbar, bevor überhaupt jemand ein Kabel anschließt.

Was der Fahrer tun sollte. Nichts. Das muss man so deutlich sagen, weil Fahrer hier Zeit verlieren. Eine Ladestation in diesem Zustand startet den Authentifizierungsprozess gar nicht erst – das Anschließen und Vorhalten einer Ladekarte führt zu keinem Ladevorgang, egal wie oft man es versucht. Wenn es eine alternative Ladestation gibt, nutzen Sie diese. Wenn dies die einzige Option ist, rufen Sie den Standortleiter oder den Support an und lassen Sie diese das Problem lösen.

Was dahintersteckt. In OCPP 1.6 ist dies eine StatusNotification mit dem Status Faulted oder Nicht verfügbar, und das dazugehörige errorCode ist die Diagnose-Nutzlast. Häufige Fehlercodes und ihre Bedeutung:

Drei verschiedene Ursachen führen zu diesem Zweig, wobei sie unterschiedlich wahrscheinlich sind:

1. Ein tatsächlicher Hardware- oder Firmware-Fehler. Dies trifft auf die meisten Fälle zu.
2. Der Betreiber hat das Ladegerät absichtlich außer Betrieb genommen – etwa für geplante Wartungsarbeiten, bei einem bekannten Problem oder an einem Standort, der eine vorherige Genehmigung erfordert. Dies ist ChangeAvailability auf Inoperative im Backend und kein Fehler. Es sollte Ihr eigenes Team nicht überraschen, tut dies aber regelmäßig bei den Fahrern.
3. Etwas vorgelagertes – ein ausgelöster Schutzschalter, ein Lastmanagementsystem, das den Standort auf Null hält, oder ein Versorgungsproblem.

Was es normalerweise nicht ist: ein Verbindungsproblem. Dies ist eine häufige Fehldiagnose. Ladegeräte sind so konzipiert, dass sie auch ohne Backend-Verbindung eine Zeit lang weiterarbeiten, indem sie zwischengespeicherte Autorisierungslisten verwenden. Ein Ladegerät, das die Netzwerkverbindung verloren hat, lädt in der Regel weiter; es geht normalerweise nicht auf Faulted. Wenn Ihre Standorte echte Offline-Phasen erleben, ist das ein Fall für Konnektivität mit Redundanz und Fallback und Unterstützung für Offline-Ladevorgänge – aber suchen Sie nicht nach einer Netzwerkstörung, wenn das Licht rot leuchtet.

Zweig 2: Ladestation ist verfügbar, aber der Ladevorgang startet nicht

So sieht es aus. Die Ladestation leuchtet grün. Der Fahrer schließt das Kabel an und authentifiziert sich – per App, Tankkarte oder automatischer Fahrzeugerkennung. Die Ladestation reagiert sichtbar: Das Display ändert sich, es sieht nach einer Vorbereitung aus. Dann springt sie zurück auf „Verfügbar“ oder in einen Fehlerzustand. Zieht man das Kabel ab, leuchtet sie wieder grün.

Dies ist für Fahrer der verwirrendste Fall, da eigentlich alles funktionieren sollte.

Vorgehensweise für den Fahrer – in dieser Reihenfolge:

1. Stellen Sie sicher, dass Sie die richtige Tankkarte oder das richtige Konto für diesen Standort verwenden.
2. Trennen Sie das Kabel vom Fahrzeug.
3. Schalten Sie das Fahrzeug aus, wieder ein und dann erneut aus. Lassen Sie es ausgeschaltet.
4. Schließen Sie das Kabel wieder an.
5. Starten Sie innerhalb von etwa 20 Sekunden einen neuen Ladevorgang.
6. Falls dies fehlschlägt, versuchen Sie eine andere Authentifizierungsmethode – über das Display der Ladestation statt der App oder mit einer anderen Karte.

Was im Hintergrund passiert. Die Ladestation wechselt von Verfügbar → Vorbereitung Sobald ein Kabel oder eine Karte erkannt wird. Dieser Übergang ist normal und zeigt, dass das Ladegerät ordnungsgemäß arbeitet. Was danach geschieht, ist der kritische Punkt; es gibt zwei verschiedene Fehlerkategorien, die von außerhalb des Fahrzeugs identisch aussehen.

Kategorie A – Autorisierung und Backend. Das Ladegerät sendet eine Authorize -Anfrage (oder das idTag innerhalb von StartTransaction) an das Backend. Das Backend antwortet mit einem idTagInfo -Status:

• Invalid – Karte oder Konto ist in diesem System unbekannt
• Blocked – bekannt, aber deaktiviert
• Expired – Gültigkeitszeitraum abgelaufen
• ConcurrentTx – für diesen Token existiert bereits eine offene Sitzung
• Accepted – Ladevorgang freigegeben

Jede nichtAkzeptiert -Antwort beendet den Versuch und die Ladestation kehrt in den Status Verfügbarzurück. Dies ist deterministisch: Der Fehler tritt bei jedem erneuten Versuch auf, was ein eindeutiges Indiz ist. Die Ursache liegt im Backend-Protokoll, nicht in der Ladestation. Die Ladestation weiß nur, dass der Vorgang abgelehnt wurde; das Backend kennt den Grund.

Es gibt eine dritte Möglichkeit in dieser Kategorie: Das Backend hat überhaupt nicht geantwortet, weil ein Timeout aufgetreten ist oder es überlastet war. Das ist seltener, führt aber zum gleichen sichtbaren Verhalten – und im Gegensatz zu einer abgelehnten Karte kann ein erneuter Versuch hier tatsächlich erfolgreich sein. Dies ist der einzige Fall, in dem „Versuchen Sie es noch einmal“ ein ernst gemeinter Rat und keine bloße Hinhaltetaktik ist.

Kategorie B – die Ladestation kann nicht mit dem Fahrzeug kommunizieren. Ladestation und Fahrzeug tauschen über den Control Pilot im Ladekabel Daten aus: Betriebsbereitschaft, verfügbarer Strom, Fehlerzustände. Wenn das Fahrzeug längere Zeit geparkt war, ist sein Kommunikations-Controller möglicherweise in den Ruhemodus gewechselt und wacht nicht mehr auf, um zu antworten.

In OCPP 1.6 äußert sich dies als errorCode: EVCommunicationErroroder als eine Sitzung, die den Status SuspendedEV erreicht und dort verharrt – die Ladestation ist bereit und bietet Strom an, aber das Fahrzeug nimmt ihn nicht ab. Diese Unterscheidung ist der nützlichste Hinweis in diesem gesamten Leitfaden: SuspendedEVSE bedeutet, dass die Ladestation oder der Standort die Stromabgabe verweigert; SuspendedEV bedeutet, dass das Fahrzeug bereit ist. Eines liegt in Ihrer Verantwortung, das andere in der der Flotte.

Der Aus-/Ein-/Aus-Zyklus in der Wiederholungssequenz dient gezielt dazu, das Steuergerät des Fahrzeugs aufzuwecken. Er ist oft genug erfolgreich, um ihn vor einer Eskalation auszuprobieren.

So unterscheiden Sie die Fehlergruppen schnell: wenn es jedes Mal identisch fehlschlägt und sauber zurückkehrt zu Verfügbar, liegt der Verdacht bei der Autorisierung – prüfen Sie das Backend. Wenn das Verhalten zwischen den Versuchen variiert oder die Sitzung im Status „ausgesetzt“ hängen bleibt, liegt der Verdacht bei der Fahrzeugkommunikation. Echtzeit-OCPP-Warnmeldungen und Ladegerät- und Anschlussstatus liefern Ihnen diese Unterscheidung, ohne dass jemand Rohdaten auf dem Betriebshof auslesen muss.

Zweig 3: Die Sitzung startet, bricht dann aber vorzeitig ab

So sieht es aus. Die Sitzung wurde ordnungsgemäß gestartet. Das Fahrzeug hat tatsächlich Energie aufgenommen – mehrere kWh, möglicherweise über Stunden. Dann wurde der Vorgang gestoppt, obwohl das Fahrzeug noch nicht voll geladen war.

Aktionen für den Fahrer: Starten Sie eine neue Sitzung. Falls das nicht funktioniert, schalten Sie das Fahrzeug aus und wieder ein und versuchen Sie es erneut. Wenn es immer noch nicht klappt, versuchen Sie es mit einer anderen Karte oder einem anderen Konto.

Was dahintersteckt. Da eine Sitzung bereits erfolgreich lief, ist ein Hardwaredefekt die am wenigsten wahrscheinliche Ursache. Gehen Sie stattdessen von Richtlinienproblemen aus.

Häufigste Ursache: ein beabsichtigtes SoC-Limit. Viele Depots und öffentliche Ladepunkte begrenzen Ladevorgänge bei einem bestimmten Ladestand (SoC). Dies geschieht aus zwei guten Gründen bewusst. Erstens sinkt die Ladegeschwindigkeit der meisten Fahrzeuge ab etwa 80 % SoC drastisch, sodass das letzte Fünftel unverhältnismäßig lange dauert und den Anschluss für das nächste Fahrzeug blockiert. Zweitens verkürzt das tägliche Laden auf 100 % messbar die Lebensdauer des Akkus. Wenn Ihre Flotte dies tut, informieren Sie Ihre Fahrer – ein geplanter Stopp, der nicht dokumentiert wurde, führt zu denselben Support-Anfragen wie eine echte Störung.

Zweite Ursache: ein Autorisierungslimit. An öffentlichen Ladepunkten unterliegen Tank- und Kreditkarten Vorautorisierungslimits. Wenn die laufenden Kosten des Ladevorgangs dieses Limit erreichen, beenden viele Betreiber die Sitzung, anstatt das finanzielle Risiko zu tragen. Ein neuer Ladevorgang setzt das Limit zurück, weshalb ein Neustart das Problem meist löst.

Dritte Ursache: ein tatsächlicher Abbruch. OCPP StopTransaction enthält ein reason Feld, und dies ist der schnellste Weg, um die Ursache zu klären:

Ein Remote Stopp an einem Depotstandort ist sehr oft Ihr eigenes Lastmanagement, das genau das tut, wofür es konfiguriert wurde. Prüfen Sie das, bevor Sie jemanden vor Ort schicken.

Ladepunkt-Log oder Backend-Log?

Die beiden Protokolle beantworten unterschiedliche Fragen, und die Wahl des falschen Logs verschwendet die ersten zwanzig Minuten jeder Untersuchung.

• Backend-Log – war das Token gültig, was ergab die Autorisierung, was zeigten die Zählerstände im Zeitverlauf, welcher Stoppgrund wurde übermittelt, wann begann die Unterbrechung des Heartbeats? Nutzen Sie es für Autorisierungsfehler, richtlinienbasierte Stopps und alles, was die Konnektivität betrifft.
• Ladepunkt-Log – Schütz- und Relaisereignisse, thermische Auslösungen und Schutzabschaltungen, Zustandsänderungen des Control Pilots, Firmware-Verhalten, interne Fehler. Nutzen Sie es für alles Physische und für InternalError oder OtherError.

Die Faustregel lautet: Wenn der Fehler deterministisch und sauberwar, ist es ein Backend-Problem. Wenn er unklar, sporadisch oder physischer Naturwar, liegt es am Ladegerät.

Früher musste man für das Ladeprotokoll vor Ort sein. Das sollte nicht nötig sein. Hardware-Diagnose und Ladeprotokolle und Audits machen dies zu einer Aufgabe, die sich vom Schreibtisch aus erledigen lässt. Das ist entscheidend, denn der Unterschied zwischen einer Fern- und einer Vor-Ort-Diagnose entspricht einem ganzen Arbeitstag für einen Techniker.

Die operative Ebene: Was ist bei den einzelnen Fehlern zu tun?

Die Diagnose ist die halbe Miete. Die andere Hälfte ist das Routing – also die Entscheidung, welche Fehler überhaupt menschliches Eingreifen erfordern.

Selbstheilung – protokollieren, aber keinen Alarm auslösen. Thermische Leistungsdrosselung, die sich von selbst behebt. Einzelne SuspendedEV -Ereignisse bei Fahrzeugen, die danach problemlos laden. Kurzzeitige Verbindungsabbrüche, die sich innerhalb des Wiederholungsintervalls von selbst beheben. Wenn Sie bei solchen Vorfällen Alarm schlagen, gewöhnen Sie Ihr Team daran, Warnmeldungen zu ignorieren – was schlimmer ist, als sie zu übersehen.

Remote-Reset – automatisch versuchen, Alarm nur bei Misserfolg. ConnectorLockFailure, ReaderFailuresowie viele InternalError Fälle lassen sich durch einen Soft-Reset beheben. Versuchen Sie dies zuerst und eskalieren Sie das Problem nur dann an einen Mitarbeiter, wenn der Reset nicht dauerhaft hilft oder der Fehler erneut auftritt. Fernsteuerung des Ladegeräts und automatisierte Firmware-Updates decken den Großteil dieser Kategorie ab – insbesondere wiederkehrende firmwarebedingte Fehler sollten durch ein Versions-Rollout behoben werden, nicht durch wiederholte Resets.

Technikereinsatz – sofort alarmieren, inklusive Kontext. GroundFailure, PowerSwitchFailure, PowerMeterFailure, physische Schäden am Anschluss sowie alles, was auch nach zwei Resets weiterhin besteht. Ein tatsächlich defektes Ladegerät erfordert eine Inspektion oder Notfallreparatur, was Stunden bis Tage in Anspruch nehmen kann. Die Benachrichtigung sollte bereits den Fehlercode, den Log-Auszug und den Reset-Verlauf enthalten, damit der entsandte Techniker genau weiß, was ihn vor Ort erwartet. Mehrkanal-Benachrichtigungen, das Alert-Center, und die Team-Zusammenarbeit bei Warnmeldungen verhindern, dass dies zu einer Telefonkette wird.

Nicht Ihr Problem – leiten Sie es weiter. Fehler am Fahrzeug liegen in der Verantwortung der Flotte oder des OEM. Zahlungs- und Roaming-Probleme betreffen den eMSP. Versorgungsprobleme liegen beim Energieversorger. Die Kosten entstehen hier nicht durch die Reparatur, sondern durch die Stunde, die man damit verbringt, festzustellen, dass der Fehler von Anfang an nicht bei Ihnen lag. First-Level-Support und Second-Level-Support existieren, um diese Triage abzufangen, bevor sie Ihre Ingenieure erreicht.

Das Grundprinzip: jede Warnmeldung sollte einer Handlung entsprechen, die eine Person ausführen kann. Alles andere ist Rauschen, und wegen dieses Rauschens werden echte Fehler übersehen. In Kombination mit präventiver Wartung für Ladestationen wird ein erheblicher Teil dieser Ausfälle komplett aus der reaktiven Warteschlange entfernt.

Häufig gestellte Fragen

Warum zeigt meine Ladestation „Verfügbar“ an, startet aber keinen Ladevorgang?Die Ladestation ist bereit; ein nachgelagerter Schritt verweigert den Vorgang. Meist handelt es sich um eine Autorisierungsablehnung durch das Backend, ein Timeout im Backend oder eine fehlerhafte Kommunikation des Fahrzeugs über das Kabel. Ein Aus- und Einschalten des Fahrzeugs sowie ein erneuter Versuch innerhalb von 20 Sekunden lösen das Problem auf Fahrzeugseite.

Warum wurde mein Ladevorgang vor dem vollständigen Aufladen der Batterie beendet?Meistens ist das beabsichtigt. Viele Depots und öffentliche Standorte begrenzen Ladevorgänge bei einem bestimmten Ladestand, um den Anschluss freizugeben und die Lebensdauer der Batterie zu schonen. Eine weitere häufige Ursache ist ein Vorautorisierungslimit bei Tank- oder Kreditkarten. Ein Neustart des Ladevorgangs setzt das Laden in der Regel fort.

Woran erkenne ich, ob das Problem am Ladegerät oder am Fahrzeug liegt?Prüfen Sie, von welcher Seite der Ladevorgang unterbrochen wurde. In OCPP bedeutet SuspendedEVSE , dass das Ladegerät oder der Standort die Stromzufuhr unterbricht; SuspendedEV bedeutet, dass das Fahrzeug den Strom nicht annimmt. EVCommunicationError deutet auf ein Problem mit der Datenverbindung zum Fahrzeug über das Kabel hin.

Hört ein Ladegerät auf zu funktionieren, wenn die Internetverbindung unterbrochen wird?Im Allgemeinen nicht. Ladegeräte funktionieren dank zwischengespeicherter Autorisierungen auch eine Zeit lang ohne Backend-Verbindung. Ein rotes oder fehlerhaftes Ladegerät hat weitaus häufiger eine Hardware- oder Konfigurationsursache als ein Netzwerkproblem.

Welche Ladefehler erfordern einen Vor-Ort-Einsatz?Erdschlüsse, Schütz- und Zählerdefekte, physische Schäden sowie jeder Fehler, der nach zwei Fern-Resets erneut auftritt. Die meisten anderen Fehlerklassen – wie Verriegelungsfehler, Lesefehler, thermische Ereignisse und viele interne Fehler – lassen sich aus der Ferne beheben.

Reduzieren Sie unnötige Serviceeinsätze. Ampcontrol bietet Betreibern OCPP-Echtzeitwarnungen, Ferndiagnosen und Fernsteuerung für alle Ladegerätemarken – die Grundlage für die Überwachung und Wartung Ihrer Ladegeräte sowie für den Einsatz von OCPP im Ladebetrieb in großem Maßstab. Buchen Sie eine Demo, um die Lösung an Ihren eigenen Standorten zu sehen.

‍