Start/Insights/Cold-Chain-Telemetrie: Owasys Open-Linux-Gateway
Aus dem Feld

Cold-Chain-Telemetrie: Owasys Open-Linux-Gateway

Wie ein Kühltransport-Flottenbetreiber vier anbietergebundene Geräte pro Trailer durch ein einziges Owasys Open-Linux-Gateway ersetzte, kundeneigene Embedded-Software, die Carrier- und Thermo-King-Reefer-Protokolle auf einer Platine vereint. Cloud-Ingestion −70%, SIM-Kosten −40%.

Wie es im Feld aussah

Die Flotte betrieb rund 600 Kühlauflieger, eine Mischung aus Carrier Vector- und Thermo King SLXi-Reefer-Einheiten, gezogen von einem gemischten Zugmaschinen-Bestand. An Bord trug jeder Trailer seinen eigenen Mini-Stack:

  • Ein Carrier- oder Thermo-King-Controller, der sein eigenes proprietäres serielles Protokoll sprach, gekoppelt an das Cloud-Abonnement des OEMs.
  • Ein separater GPS-Tracker auf einer Orbcomm- oder Spireon-ähnlichen Plattform, mit eigener SIM und eigenem Dashboard.
  • Ein eigenständiger Türsensor mit einer weiteren SIM und einer weiteren Monatsgebühr.
  • Für HACCP-Kunden ein Temperatur-Datenlogger, der nur per USB im Depot ausgelesen werden konnte.

Vier Geräte pro Trailer. Vier Datenpläne. Vier Cloud-Plattformen. Vier Rechnungen. Fünf verschiedene APIs, wenn jemand eine Frage stellen wollte, die mehr als eines davon berührte.

Drei Probleme, die wir parallel lösen mussten

Vendor Lock-in über den gesamten Trailer. Jede Komponente kam mit einer Plattformgebühr. Telemetrie, deren Konnektivität der Betreiber bereits bezahlte, musste durch die Cloud des Anbieters laufen, bevor sie überhaupt jemand sehen konnte. Der Betreiber besaß seine Daten nie selbst. Er besaß ein Abonnement auf eine Kopie davon.

Multi-Protokoll-Fragmentierung. Das serielle Carrier-IntelliSet und das Thermo-King-DSR-Protokoll sind nicht kompatibel. Der GPS-Tracker sprach NMEA auf einer separaten UART. Der Türsensor war 1-Wire. Kein Standard-Gerät am Markt sprach alles davon nativ, also blieb die Flotte bei vier Boxen pro Trailer, um dieselbe Fläche abzudecken.

Gerätekosten, die mit der Flotte skalierten. Jeder Trailer brachte vier SIMs, vier Plattform-Abonnements, vier Rechnungen mit. Hundert Trailer mehr bedeuteten vierhundert SIMs mehr. Die Konnektivitätskosten wuchsen ungefähr linear mit der Flotte. Der operative Mehrwert nicht.

Architektur: von geschlossen zu offen

Wir ersetzten alle vier Geräte durch ein einziges Owasys owa4x unter Debian Linux. Das owa4x bietet die I/O-Ausstattung, um alles, was ein Kühlauflieger braucht, an einem Ort abzudecken:

  • RS-485- und RS-232-UARTs, eine für den Reefer-Controller, eine Reserve für ein OBC, Fahrer-Tablet oder zukünftige Sonden.
  • CAN J1939, für Motor- und Fahrgestelldaten der Zugmaschine.
  • 1-Wire / I²C, für Türsensor und trailermontierte Sonden.
  • Integriertes Multi-Konstellations-GNSS.
  • LTE Cat-4 Mobilfunkmodem mit Dual-SIM.
  • Weitbereichs-DC-Eingang für Fahrzeuge, dichtes Gehäuse, voller Betriebstemperaturbereich.

Die Embedded-Software liefern wir, sie gehört dem Kunden. Daten werden via MQTT an den Broker des Kunden veröffentlicht, er entschied sich für AWS IoT Core, aber der Vertrag ist portabel, wenn er später wechseln will.

Ein Gerät, jedes Protokoll

Die technische Leistung steckt in der Embedded-Anwendung, nicht in der Hardware. Das owa4x hat die Ports; was die Konsolidierung möglich machte, ist Software, die jedes Protokoll der Flotte versteht, gemeinsam auf einer Platine.

Die Umsetzung: ein Linux-Prozess pro Protokoll, isoliert und einzeln neustartbar. Der Reefer-Controller-Adapter spricht sowohl Carrier IntelliSet als auch Thermo King DSR auf derselben seriellen Leitung, per Konfiguration pro Trailer umgeschaltet. Der CAN-Prozess dekodiert J1939-PGNs jeder J1939-konformen Zugmaschine. GPS, Türzustand und Modem-Gesundheit veröffentlichen alle über dieselbe MQTT-Topic-Hierarchie mit konsistentem Schema.

Wenn der Kunde in zwei Jahren ein neues Reefer-Modell hinzufügt, tauscht er nicht das Gateway. Er schreibt, oder beauftragt, einen weiteren Adapter.

Polling raus, Events rein

Der alte Stack pollte. Jedes Gerät meldete in festem Takt, unabhängig davon, ob sich etwas verändert hatte, sodass die Mobilfunkrechnung für einen leeren Heartbeat genauso hoch ausfiel wie für ein echtes Ereignis. Auf einem Kühlauflieger bewegt sich die meiste Telemetrie zwischen den Polls nicht: der Setpoint ist stabil, die Tür ist zu, der LKW ist auf der Autobahn.

Die neue Software veröffentlicht bei Zustandsübergängen: Setpoint-Wechsel, Türöffnung, Alarm, Geofence-Übergang, Abtauzyklus-Start. Ein periodischer Heartbeat füllt die Lücken, damit die Plattform weiß, dass das Gerät noch lebt. Über ein Ein-Stunden-Fenster auf einem fahrenden Trailer veröffentlicht der neue Stack eine Handvoll Ereignisse, wo der alte Stack Dutzende vollständiger Payloads gesendet hätte.

Polling
Ereignisgesteuert
030 Min.60 Min.
Polling. Reporting in festen Intervallen auf jedem Kanal, vollständige Payload, unabhängig vom Trailer-Zustand.
Ereignisgesteuert. Setpoint-Änderungen, Tür-Events, Alarme, nur veröffentlicht, wenn der Zustand tatsächlich wechselt.
Veröffentlichte Nachrichten in einem Ein-Stunden-Fenster auf einem einzelnen Trailer. Jeder Polling-Tick ist ein vollständiger Multi-Kanal-Report; jeder Ereignis-Marker ist ein Zustandsübergang, den die Plattform tatsächlich braucht.

Migration: Audit, Pilot, Flotten-Rollout

Fünfzig Trailer im Pilotbetrieb, eine repräsentative Mischung aus Reefer-Marken und Zugmaschinen-Kombinationen. Wir instrumentierten alten und neuen Stack zwei Monate parallel, um stille Datenabhängigkeiten zu erfassen, auf die sich Servicetechniker im Feld verlassen hatten. Danach voller Rollout über sechs Monate, Depot für Depot, ein Anbieter-Abonnement pro Welle eingestampft.

Bis Monat neun lief jeder Trailer auf Owasys-Hardware, und die vier ursprünglichen Abonnements waren weg. Die einzigen laufenden Kosten am Trailer waren die SIMs des Kunden selbst.

Was sich jenseits der Schlagzeilen geändert hat

Geräte pro Trailer: 4 → 1. Weniger Verkabelung, weniger Stromaufnahme, weniger Feld-Ausfallmodi, schnellere Installationen im Depot.

Cloud-Ingestion-Volumen −70%. Ereignisgesteuertes Publishing ersetzt die Polling-Schleifen des alten Stacks.

SIM- und Konnektivitätsausgaben −40%. Eine SIM pro Trailer statt drei oder vier, mit einem Carrier-Mix, der nach Routengeografie statt Anbieterbequemlichkeit gewählt wurde.

Plattform-Abogebühren: gestrichen. Die Cloud des Reefer-OEMs steht weiterhin für Gewährleistungsfälle zur Verfügung; der Kunde zahlt nicht mehr für sie als Datenpfad.

IP-Eigentum. Embedded-Software, Datenmodell und MQTT-Vertrag wurden bei der Übergabe vollständig übertragen. Am Trailer läuft kein Melqart-Abonnement.

Indexiert auf die Pre-Change-Baseline (=100%). 600-Trailer-Flotte, sechs Monate Beobachtungsfenster nach vollständigem Rollout.

Warum das Muster funktioniert

Cold Chain hat nicht einen großen Vendor Lock-in. Es hat vier: den Reefer-Hersteller, den Tracker-Anbieter, den Zusatzsensor-Lieferanten und (meist) die Cloud-Plattform, die zur Beschaffungszeit am lautesten war. Jeder davon kassiert für den Zugriff auf Daten, deren Konnektivität der Betreiber schon bezahlt hat.

Ein Open-Linux-Gateway räumt alle vier gleichzeitig ab. Die Hardware ist offen und langfristig unterstützbar, an niemandes Roadmap gebunden. Die Software gehört dem Kunden. Die Protokolle bleiben verhandelbar, weil der Code, der sie liest, ein Linux-Prozess ist, keine geschlossene Firmware.

Das Muster reproduziert sich in jedem fragmentierten Flottenmarkt: Baumaschinenvermietung, Abfallwirtschaft, Lohnunternehmen in der Landwirtschaft. Cold Chain ist das sauberste Beispiel, weil die Kosten pro Trailer am leichtesten zu zählen sind.

Bauen Sie Ihre industrielle Telemetrie aus.

Sprechen Sie mit uns über Gateway-Software, Telemetrie-Pipelines und kundeneigene IP.

Cold-Chain-Telemetrie: Owasys Open-Linux-Gateway