Live · CAN-Bus-Telemetrie
OCPP meldet den Ausfall.
Der CAN-Bus kündigt ihn an.
Wie Stackbox über den Controller der Ladestation die Daten des CAN-Bus ausliest – Sensorwerte, Ladeleistung und Status aus derselben Quelle – und Bauteilfehler sichtbar macht, bevor der erste Kunde vor einer defekten Säule steht. Kein Zusatzgerät. Kein Herstellerportal.
Animierte Darstellung des Zugriffs auf den Controller der Ladestation: CAN-Botschaften werden mitgelesen, in benannte Signale dekodiert, mit der Ladeleistung aus derselben Quelle korreliert und zu einem Befund verdichtet – im Beispiel eine Temperaturdrift des Leistungsmoduls B2 bei gleichbleibender Last. Alle Werte sind exemplarisch.
01 · Challenge
Das CPMS kennt zwei Zustände: läuft und kaputt.
Wer ein Schnellladenetz betreibt, kennt die Lücke: Das Betriebssystem zeigt zuverlässig an, dass eine Station steht – aber nie, dass sie gleich stehen wird. Zwischen verfügbar und gestört liegt kein Zustand, in dem man noch handeln könnte.
OCPP kennt keinen Zwischenzustand
StatusNotification liefert Available, Charging, Faulted. Kein Bauteil, kein Verlauf, keine Vorstufe. Die Meldung kommt in dem Moment, in dem der Schaden bereits eingetreten ist – und der Kunde meist schon davorsteht.
Stille Leistungsminderung
Ein Standort meldet sich als verfügbar, liefert aber statt der vollen Ladeleistung nur noch einen Bruchteil. Im System ist kein Fehler sichtbar. Spürbar ist es nur an längeren Ladezeiten, sinkendem Umsatz und Beschwerden, die niemand einem Bauteil zuordnen kann.
Ein Portal pro Hersteller
Jeder Hardwarehersteller bringt sein eigenes Serviceportal mit, eigene Zugänge, eigene Begriffe. In einem gemischten Netz entsteht daraus kein Gesamtbild, sondern Mehrarbeit – und niemand vergleicht Standorte über Herstellergrenzen hinweg.
Einsätze ohne Befund
Der Techniker fährt raus, findet nichts oder tauscht das falsche Teil und fährt beim nächsten Mal wieder. Jede Fahrt kostet Zeit und Geld, und die eigentliche Ursache bleibt so lange unentdeckt, bis sie erneut zuschlägt.
OCPP ist ein Betriebsprotokoll, kein Diagnoseprotokoll. Es wurde entworfen, um Ladevorgänge zu steuern und abzurechnen – nicht, um den Zustand von Leistungsmodulen, Kühlkreisläufen und Schützen zu beschreiben. Diese Daten existieren längst: Sie liegen auf dem internen Bus der Station. Sie verlassen sie nur nicht.
02 · Solution
Kein Zusatzgerät. Der Controller weiß es längst.
Stackbox greift auf den Controller der Ladestation zu und liest dort die Daten des CAN-Bus aus – Sensorwerte ebenso wie Ladeleistung, Dauer und Status. Daraus entsteht ein Befund, mit dem die Instandhaltung tatsächlich arbeiten kann: ohne zusätzliche Hardware am Standort, ohne Eingriff in die Ladesteuerung, ohne Herstellersoftware.
Zugriff auf den Controller der Station
Der Controller der Ladestation hängt ohnehin am internen CAN-Bus und kennt dessen Botschaften. Stackbox liest sie dort passiv aus: Temperaturen der Leistungsmodule, Kühlkreislauf, Schaltzyklen der DC-Schütze, Isolationsüberwachung, Lüfterdrehzahlen. Mitlesen statt eingreifen – die Ladesteuerung bleibt unberührt, zusätzliche Hardware im Schaltschrank braucht es nicht.
Normalisierung über Hersteller hinweg
Jeder Hersteller kodiert seine Botschaften anders. Ein Mapping-Layer übersetzt die herstellerspezifischen Signale in ein einheitliches Modell – dieselbe Kennzahl bedeutet dasselbe, egal welche Hardware am Standort steht.
Korrelation innerhalb einer Quelle
Ein Temperaturwert allein sagt wenig. Erst zusammen mit Ladeleistung, Dauer und Status wird daraus eine Aussage: zu warm für diese Last. Beides liefert derselbe Controller – die Werte müssen nicht erst aus einem zweiten System geholt und zeitlich zusammengeführt werden.
Trends statt starrer Grenzwerte
Ein fester Schwellwert schlägt erst an, wenn es fast zu spät ist. Beobachtet wird deshalb der Verlauf: Ein Modul, das über Wochen bei gleicher Last immer wärmer wird, meldet sich – lange bevor es in die Abregelung geht.
Befund im Arbeitsablauf, nicht im Dashboard
Auffälligkeiten laufen als Ticket ins bestehende Servicesystem, mit Standort, betroffenem Bauteil und Handlungsempfehlung. Der Einsatz wird geplant und mit dem richtigen Ersatzteil gefahren – statt reaktiv und zweimal.
Systemarchitektur
Erfassung · Normalisierung · Korrelation
Integration
03 · Impact
Was sich im Betrieb konkret verändert.
Aus einem Netz, das Störungen meldet, wird ein Netz, das Störungen ankündigt. Das verändert nicht nur die Verfügbarkeit, sondern die Arbeitsweise der Instandhaltung – von reaktiv zu geplant.
Täglich, stündlich, minütlich – in welchem Takt überwacht und ausgewertet wird, ist frei konfigurierbar
Herstellerportale, die das Serviceteam parallel bedienen muss
durchgehende Zustandserfassung statt Stichprobe im Wartungsintervall
einheitliches Signalmodell für alle Hersteller im Netz
Leistungsminderung wird erkannt, bevor sie als Beschwerde zurückkommt
Befunde fließen direkt ins bestehende Ticket- und Betriebssystem
Vorher haben wir erfahren, dass eine Säule steht, wenn ein Kunde angerufen hat. Heute sehen wir die Auffälligkeit, während die Säule noch lädt – und planen den Einsatz, statt ihn zu fahren.
Stackbox · Condition Monitoring
Ähnliche Fragestellung im Betrieb?
Wir schauen uns an, welche Daten deine Hardware heute schon liefert – und was davon ungenutzt in der Station liegen bleibt.
Gespräch vereinbaren →