Vom CAN-Bus zur Cloud: Eine praktische Telematikarchitektur

Ein funktionierendes Telematiksystem hat vier bewegliche Teile und eine ehrliche Randbedingung. Die Teile: ein Gateway an der Maschine, das den Bus liest, Edge-Software, die aus Roh-Frames Bedeutung macht, ein Transport, der schlechte Netzabdeckung übersteht, und eine Cloud, die das Ergebnis speichert und bereitstellt. Die Randbedingung: Die Maschine hört nicht auf, Daten zu erzeugen, wenn das Netz wegbricht, also muss das Gateway sich selbst behelfen.

Dieser Leitfaden verfolgt den Weg eines einzelnen Signals, von einem CAN-Frame am Antriebsstrang bis zu einer Zeile in einer Cloud-Datenbank, und benennt die Entscheidungen, die an jedem Übergang wirklich zählen. Die Hardware ist hier ein Embedded-Linux-Gateway, denn das Eigentum an dieser Ebene erlaubt Ihnen, jede dieser Entscheidungen später zu ändern.

CAN ist ein Broadcast-Bus. Jeder Controller legt Frames auf die Leitung und jeder Knoten sieht sie; nichts ist an Sie adressiert. Ein Gateway klinkt sich ein, meist im Listen-only-Modus, damit es das Fahrzeugnetz nicht stören kann, und liest Frames mit der Busrate, bei schwerem Gerät üblicherweise 250 kbit/s oder 500 kbit/s.

Roh-Frames sind noch keine Daten. In einem J1939-Netz (dem Standard über CAN für Lkw und Off-Highway-Maschinen) trägt ein 29-Bit-Identifier eine PGN (Parameter Group Number), und in der Nutzlast stecken einzelne Signale, adressiert über die SPN (Suspect Parameter Number): Motordrehzahl, Kühlmitteltemperatur, Kraftstoffrate, Hydraulikdruck. Sie zu dekodieren heißt, Skalierung und Offset auf bestimmte Bits anzuwenden, die Zuordnung, die eine DBC-Datei beschreibt. Spricht eine Maschine stattdessen einen proprietären CAN-Dialekt, müssen Sie diese Zuordnung rückentwickeln oder lizenzieren. An dieser Stelle filtert das Gateway hart: Von den Hunderten PGNs auf einem belebten Bus braucht ein Telematik-Anwendungsfall meist nur einige Dutzend.

Dekodierung liefert Werte. Die Edge-Verarbeitung entscheidet, welche davon die Maschine verlassen und wie oft. Ein 500-kbit/s-Bus kann Tausende Signalaktualisierungen pro Sekunde bieten; alles davon über Mobilfunk zu senden ist sinnlos und teuer. Also tastet das Gateway ab und aggregiert: Die Motordrehzahl geht vielleicht als Ein-Sekunden-Mittel hinaus, ein Fehlercode in dem Moment, in dem er auftritt, GPS alle paar Sekunden, ein Türschalter nur bei Änderung.

Hier verdient sich die Datenqualität auch ihr Vertrauen. Einheitenumrechnung, Bereichsprüfungen, die einen physikalisch unmöglichen Wert verwerfen, und ein Deduplizierungsschritt, damit ein Signal, das sich nicht bewegt hat, keinen Verkehr erzeugt. Zwei Muster teilen die Bandbreitenfrage. Polling tastet auf festem Takt ab und ist leicht nachzuvollziehen. Report-by-Exception sendet nur, wenn ein Wert eine Schwelle überschreitet oder den Zustand wechselt, was bei Industriesignalen das Volumen stark senkt. Die meisten realen Installationen nutzen beides, je nach Signal.

Die Verbindung ist der Teil, den Sie nicht voraussetzen können. Mobilfunk (LTE, zunehmend 5G, dazu LTE-M oder NB-IoT für Sensoren mit geringer Datenrate) deckt die meisten mobilen Assets ab; WLAN oder Ethernet passen für Depots und feste Installationen; Satellit ist der Rückfall, wo nichts anderes hinreicht. Keine davon ist im Feld durchgehend verfügbar, und genau das ist das eigentliche Designproblem.

MQTT ist der übliche Transport, und das aus gutem Grund: leichtgewichtig, Publish-Subscribe, und seine QoS-Stufen passen zu dem, was Telematik braucht. QoS 0 für hochfrequente Abtastungen, deren Verlust verkraftbar ist, QoS 1 für Ereignisse, die mindestens einmal ankommen müssen. Das Gateway puffert lokal (eine kleine Warteschlange auf dem Datenträger) und sendet bei Wiederverbindung nach, sodass ein Tunnel oder ein Funkloch Daten verzögert statt verliert. Jede Verbindung läuft über TLS, idealerweise mit einem Client-Zertifikat pro Gerät, damit ein kompromittiertes Gateway gesperrt werden kann, ohne die übrige Flotte anzufassen.

Auf der Gegenseite authentifiziert ein Broker oder ein Ingestion-Endpunkt das Gerät, nimmt den Datenstrom an und schreibt ihn weg. Zeitreihenspeicher passt zur Form der Daten; die Nutzlast ist meist kompaktes JSON oder ein binäres Schema, das an dieselben Felddefinitionen gebunden ist, die das Gateway verwendet hat, damit ein Wert von Anfang bis Ende dasselbe bedeutet.

Von dort speisen die Daten das, was man eigentlich wollte: Live-Dashboards, Auslastungs- und Wartungs-KPIs, Alarme und eine API in die eigenen Systeme des Kunden. Das Detail, das im Stillen über die Vertrauenswürdigkeit entscheidet, ist der Zeitstempel. Versehen Sie Messwerte am Edge mit einem Zeitstempel, wenn sie entstehen, nicht bei Ankunft, sonst landen gepufferte Daten nach einer Störung in falscher Reihenfolge und verderben jeden daraus berechneten Mittelwert.

Eine Demo auf einer Maschine auf dem Labortisch ist leicht. Tausend Maschinen im Feld über zehn Jahre sind die eigentliche Aufgabe, und wenige Entscheidungen bestimmen, welche davon Sie gebaut haben. Betreiben Sie den Edge auf offenem Embedded-Linux, das Sie kontrollieren, sodass eine neue PGN oder eine geänderte Schwelle ein Firmware-Build nach Ihrem Zeitplan ist und kein Anbieter-Ticket. Machen Sie OTA-Updates von Tag eins an sicher: signierte Images und ein A/B-Partitionsschema, das automatisch zurückrollt, wenn ein Boot fehlschlägt, denn Sie werden nicht neben dem Gateway stehen, wenn ein Update schiefgeht.

Konstruieren Sie für den schlechten Tag, nicht für die Demo. Nehmen Sie an, dass das Netz abbricht, der Speicher verschleißt und der Bus verstummt, und legen Sie für jeden Fall fest, was das Gateway tut, bevor es ausgeliefert wird. Stimmt die Feldebene, ist die Cloud größtenteils Konfiguration. Stimmt sie nicht, rettet auch die cleverste Cloud keine Daten, die nie korrekt erfasst wurden.