Kran-Monitoring-Retrofit für eine gemischte mobile Flotte

Ein europäischer Kranvermieter betreibt eine gemischte Mobilkran-Flotte über drei Depots. Die Maschinen stammen aus mehreren Generationen und von verschiedenen OEMs. J1939 an Motor und Antriebsstrang liefert die Diagnose: Fehlercodes, Tankfüllstand, Temperaturen der Teilsysteme und Betriebsstunden. Wägezellengewicht und Neigung kommen über CANopen, und wo ein Kran kein verwertbares Neigungssignal hatte, musste ein Neigungssensor nachgerüstet werden. Meldete ein Kran eine Störung, schickte die Instandhaltung jemanden hin, um die Codes auszulesen und den Datenlogger vor Ort herunterzuladen. Der Betreiber wollte diagnostizieren, bevor jemand losfährt, mit denselben Last-, Neigungs- und Auslastungswerten von jedem Chassis, auf einem Bildschirm, den er kontrolliert.

Zwei frühere Pilotprojekte waren ins Stocken geraten, beide auf geschlossenen Gateway-Plattformen. Die Daten verließen die Kabine, blieben dann an einem Anbieterportal stehen. Eine Alarmschwelle anzupassen oder einen KPI neu zu definieren bedeutete einen kostenpflichtigen Change Request mit einem Release-Zyklus in Monaten. Dem Betreiber gehörten die Maschinen. Ihm gehörte nicht die Telemetrie-Pipeline, und genau sie entscheidet, was der Flottenmanager jeden Morgen tatsächlich sieht.

Vier Randbedingungen prägten die Architektur, und der Auftrag war unmissverständlich: keine davon war verhandelbar.

Die IP bleibt beim Betreiber. Gateway-Software, Datenschema und Dashboards mussten auditierbar und portierbar sein. Sollte Melqart ausscheiden, würde der Betreiber die Flotte unverändert weiterbetreiben, mit Quellcode, Schemadefinitionen und Deployment-Skripten im eigenen Repository.

Zwei Busse auf demselben Chassis. J1939-Frames tragen Auslegerwinkel, Hubgeschwindigkeit und Motorlast, dazu Fehlercodes, Tankfüllstand, Temperaturen der Teilsysteme und Betriebsstunden. CANopen trägt die Wägezelle und den Neigungssensor, der nachgerüstet wurde, wo der Kran keinen hatte. Beides musste in einem normalisierten Datensatz pro Kran pro Sekunde aufgehen, mit angehängter GPS-Position, unter einem einzigen kanonischen Schema, damit ein Gittermast-Kran von 2008 und ein aktueller All-Terrain-Kran die Auslastung auf dieselbe Weise melden.

Der Datenlogger muss erreichbar sein. Jeder Kran führt einen detaillierten Datenlogger an Bord. Ihn auszulesen hieß, in die Kabine zu fahren, also musste das Gateway ihn aus der Ferne herunterladbar machen.

Konnektivität ist keine Selbstverständlichkeit. Steinbrüche und Innenbaustellen fallen stundenlang auf 2G oder auf gar kein Signal. Die Pipeline musste auf dem Gateway puffern, den Rückstand bei Wiederverbindung übertragen und während eines Hubvorgangs niemals stillschweigend einen Frame verlieren. Eine Lücke in der Funkabdeckung darf keine Lücke im Hubprotokoll werden.

Der ausgerollte Stack ist bewusst langweilig, und das ist der Punkt. Jeder Kran trägt ein Owasys-Gateway, das J1939 und CANopen terminiert, mit GPS an Bord. Ein kleiner Erfassungs-Daemon liest beide Busse, wendet eine Kalibriertabelle pro Einheit an (jede Wägezelle hat ihren eigenen Offset und Messbereich) und schreibt einen normalisierten Datensatz in einen lokalen Zeitreihen-Puffer, bevor irgendein Netzwerk berührt wird. Der Puffer, nicht der Broker, ist das Datenregister an der Edge. Dasselbe Gateway vermittelt den Zugriff auf den Datenlogger an Bord, sodass die Instandhaltung ihn aus dem Büro herunterlädt.

Von dort überträgt ein MQTT-Publisher die Datensätze über Mobilfunk an einen Broker, den der Betreiber in seiner eigenen VPC hostet. MQTT transportiert die Datensätze im Sekundentakt mit gesetztem Quality-of-Service, sodass eine unterbrochene Sitzung aus dem Puffer fortsetzt, statt das Übertragene zu verlieren. Ein Stream-Worker verteilt die Daten in zwei Richtungen: in eine Postgres-Datenbank mit der TimescaleDB-Erweiterung für die Dashboards und in einen Objektspeicher für Langzeit-Rohdatenarchive. Im Pfad sitzt kein SaaS-Portal. Jede Komponente läuft im Account des Betreibers, und jeder Datensatz hat ein dokumentiertes Schema und einen benannten Eigentümer.

OTA-Updates landen über einen signierten Kanal. Der Betreiber kann eine Firmware-Version pinnen oder ein ganzes Depot aus der eigenen Konsole rollen, ohne uns anzurufen. Ein Gateway-Tausch kostet eine Servicekraft rund fünfzehn Minuten, unterstützt durch ein vorgeflashtes Image und einen Kabelbaum, der den OEM-Service-Stecker spiegelt, sodass die Einheit auf vorhandene Kontakte fällt statt in eine Lötarbeit.

Der Rollout lief als drei Depots in Folge, nie als ein einziger Big-Bang über die Flotte.

Depot A (Wochen 1–3): zwölf Krane über drei OEM-Generationen. Ziel war es, die Kalibriertabellen, das Pufferverhalten und den Mobilfunk-Backhaul unter realen Hüben zu belegen, nicht am Prüfstand. Alles lief instrumentiert. Jeder verlorene Frame wurde protokolliert und täglich geprüft, und die wenigen, die wir fanden, gingen auf die Verkabelung zurück, nicht auf die Pipeline.

Depot B (Wochen 4–7): dreißig Krane, darunter die Einheiten ohne verwertbares Neigungssignal. Sie erhielten einen nachgerüsteten Neigungssensor im CANopen-Netz, kalibriert mit dem leitenden Mechaniker des Betreibers im Loop gegen bekannte Auslegerpositionen. Keine IP verließ den Betreiber.

Depot C (Wochen 8–11): die restliche Flotte. Inzwischen war die Arbeit mechanisch: montieren, flashen, kalibrieren, weitergehen. Depot-Crews nahmen neue Einheiten selbst in Betrieb, und unsere Rolle verschob sich vom Installieren zum Beantworten der gelegentlichen Frage.

Der Betreiber führt sein eigenes KPI-Dashboard, daher sind die folgenden Zahlen seine. Wir geben sie so wieder, wie sie zwölf Wochen nach dem Go-Live des letzten Depots zurückgemeldet wurden.

• Zeit bis zur ersten Telemetrie auf einem neu nachgerüsteten Kran: unter 30 Minuten, einschließlich Kalibrierung.
• Frame-Verlust unter 2G- oder Kein-Empfangs-Bedingungen: 0 % innerhalb eines 24-Stunden-Fensters, dank lokaler Pufferung und Resume-on-Reconnect.
• Erfassungsrate für Hubereignisse, mit Wägezellengewicht, Neigung und Auslegerwinkel auf einen Zeitstempel korreliert: ~99,3 % über die Flotte hinweg.
• Zeit, einen neuen Alarmschwellenwert in die gesamte Flotte auszuspielen: am selben Tag, ohne Anbieter-Change-Request.

Für die Instandhaltung liegt die größere Veränderung außerhalb dieser Liste. Fehlercodes, Temperaturen der Teilsysteme und Tankfüllstand werden aus der Ferne gelesen, und der Datenlogger wird aus dem Büro heruntergeladen, bevor jemand entscheidet loszufahren.

Die Flotten-Auslastungs-KPI zu veröffentlichen, steht dem Betreiber zu, nicht uns. Die Notiz des Disponenten zählte für uns am meisten: „Die Zahl, die wir am Bildschirm lesen, ist die Zahl, der wir im Morgenmeeting vertrauen." Dieser Satz ist der neu formulierte Auftrag: ein Feed, dem sie glauben, weil ihnen gehört, wie er gebaut ist.

Aus diesem Projekt ist unser Angebot zur Kran-Ferndiagnose entstanden, aber dahinter steht kein Einheitsbaukasten. Es gibt ein Architekturmuster, eine konkrete Hardware-Entscheidung, ein normalisiertes Schema und eine Zusammenarbeit, die den gesamten Stack an das Team des Betreibers übergeben hat. Der nächste Betreiber, der nach einem Kran-Retrofit fragt, bekommt ein Programm, das von seiner Flotte und seinen Randbedingungen geformt wird, keine Neuauflage dieses einen. Die Busmischung, die Anzahl der Depots und die Funklücken werden anders sein, und das Design folgt aus diesen Fakten.

Was der Betreiber nach der Übergabe behalten hat: die Gateway-IP, das Schema, die Dashboards, die Runbooks und das Recht, jederzeit zu gehen. Was er nicht behalten hat: eine Abhängigkeit von irgendeinem Anbieter, uns eingeschlossen.