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: Manche stellen einen Standard-J1939-CAN-Bus bereit, andere nur analoge Wägezellen- und Neigungsausgänge, eine Handvoll spricht einen proprietären CAN-Dialekt ohne öffentliche Dokumentation. Der Betreiber wollte dieselben Last-, Neigungs- und Auslastungswerte von jedem Chassis, auf einem Bildschirm, den er kontrolliert, ohne die Flotte an ein OEM-Telematikprodukt oder ein Cloud-Silo zu binden.

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.

Drei 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 Protokolle auf demselben Chassis. Bei neueren Einheiten tragen J1939-Frames Auslegerwinkel, Hubgeschwindigkeit und Motorlast über CAN. Ältere Einheiten haben keinen lesbaren Bus: Wägezellengewicht und Neigung kommen als analoge Spannungen von der Sensorverkabelung. Beides musste in einem normalisierten Datensatz pro Kran pro Sekunde aufgehen, unter einem einzigen kanonischen Schema, damit ein Gittermast-Kran von 2008 und ein aktueller All-Terrain-Kran die Auslastung auf dieselbe Weise melden.

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 offenes Linux-Gateway von Owasys, das J1939 über CAN sowie die analogen Last- und Neigungseingänge terminiert. Ein kleiner Erfassungs-Daemon liest beide Quellen, 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.

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, inklusive der Einheiten mit proprietärem CAN. Wir haben die relevanten Frames mit dem leitenden Mechaniker des Betreibers im Loop reverse engineered, indem wir Auslegerwinkel und Hubsignale gegen bekannte physische Positionen dekodiert haben, und dann den Dialekt dem Erfassungs-Daemon beigebracht. Kein OEM wurde kontaktiert, und 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.

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.

Am Ende gibt es kein „Kran-Monitoring-System" zum Kauf. 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 Protokollmischung, 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.