Container-Tracking auf See mit LoRaWAN: Netze, Zeitstempel und echte Sichtbarkeit

Der Container ist auf See. Auf der Karte steht noch Rotterdam. Ist der Tracker ausgefallen? Nicht unbedingt. Vielleicht zeichnet er Ereignisse auf und wartet auf die nächste Verbindung. Ein brauchbares Tracking zeigt diesen Unterschied, statt aus dem letzten bekannten Punkt eine aktuelle Position zu machen.

LoRaWAN kann Container in Terminals, Depots und mit passender Bordausrüstung auch auf Schiffen anbinden. Für eine gesamte Reise müssen Ortung, Datenübertragung und Prozessereignisse getrennt geplant werden. Ein Funksystem übernimmt nicht automatisch alle drei Aufgaben.

Was soll während der Reise bekannt sein?

Für manche Ladungen genügt die Bestätigung wichtiger Übergaben. Andere benötigen Temperaturverlauf, Türereignisse oder einen aktuellen Standort. Diese Anforderungen unterscheiden sich bei Datenmenge, Energiebedarf und tolerierbarer Verzögerung deutlich.

Information Mögliche Quelle Grenze
Position GNSS oder geeignetes lokales Ortungsverfahren Empfang, Infrastruktur und Fehlergrenzen müssen passen.
Präsenz in einer Zone Bekannter Erfassungspunkt, Beacon oder Gatewaykontext Ein Funkkontakt ist keine metergenaue Koordinate.
Türöffnung oder Erschütterung Sensor am zugeordneten Container Sensorereignis ist noch keine bestätigte Prozessursache.
Verladung oder Entladung Bestätigtes Terminal- oder Carrier-Ereignis Bewegung allein beweist keine Verladung auf ein bestimmtes Schiff.

GNSS ist damit eine wichtige Ortungsquelle, aber nicht die einzige Möglichkeit für genaue Positionsbestimmung. Umgekehrt garantiert ein eingebauter GNSS-Empfänger noch keinen Fix im Container oder tief im Stahlstapel.

Wie funktioniert die Übertragung zwischen Hafen und See?

Im Depot oder Terminal können eigene oder vertraglich nutzbare LoRaWAN-Gateways Nachrichten empfangen. Auf dem Schiff kann ein Bord-Gateway dieselbe Rolle übernehmen. Sein Anschluss an die Datenplattform erfolgt dann über die vorhandene Bordkommunikation, beispielsweise einen Satelliten-Backhaul.

Davon zu unterscheiden sind direkte satellitengestützte LoRaWAN-Angebote. Solche Ansätze existieren, wie die LoRa Alliance zur Netzabdeckung erläutert. Sie benötigen geeignete Endgeräte, Antennen und einen nutzbaren Dienst. Daraus folgt keine lückenlose Sofortübertragung für einen beliebigen Tracker unter Deck.

Fehlt eine Verbindung, kann der Tracker lokal speichern und später übertragen. Das muss jedoch Bestandteil des Produkts sein. LoRaWAN allein garantiert keinen Ereignisspeicher. Speicherkapazität, Uhr, Stromausfallverhalten und Nachlieferung gehören deshalb ins Lastenheft.

Warum internationale Routen ein Frequenzkonzept brauchen

Ein Gerät für eine europäische Frequenzregion ist nicht automatisch auf jeder Route mit unveränderten Einstellungen nutzbar. Frequenzband, regionale Parameter, Endgeräteausführung und örtliche Zulässigkeit müssen zusammenpassen. Die LoRaWAN Regional Parameters RP002-1.0.5 beschreiben die technischen Regionalprofile; nationale Funkvorgaben bleiben zusätzlich zu prüfen.

Roaming setzt außerdem Vereinbarungen und kompatible Netze voraus. Ein erreichbares fremdes Gateway bedeutet nicht, dass der Betreiber Nachrichten dieses Geräts annehmen und zur eigenen Anwendung weiterreichen wird. Die geplante Route wird daher mit konkreten Netzen und Übergaben geprüft.

Welches Datenmodell verhindert eine falsche Reisehistorie?

Jeder Datensatz braucht mindestens die Zuordnung zu Gerät und Container, Ereigniszeit, Empfangszeit, Datenquelle und Qualitätsstatus. Bei Umladung oder Wiederverwendung des Trackers wird die Zuordnung kontrolliert geändert. Ein Sensor, der noch dem Container der letzten Reise zugeordnet ist, kann sehr zuverlässig falsche Geschichten erzählen.

Die DCSA-Standards für Track & Trace definieren gemeinsame Prozess- und Ereignismodelle. Daneben beschreibt DCSA IoT Commercial Events; die dort ausgewiesene Fassung IoT Events 1.0 Beta 1 ist als Beta gekennzeichnet. Für eine Integration müssen die Partner eine konkrete Version und deren Umsetzung vereinbaren.

Standardisierte Datenstrukturen ersetzen keine Messprüfung. Ein Türsensor meldet eine Zustandsänderung. Ob dabei die Ladung manipuliert wurde, bleibt eine zusätzliche Bewertung. Ebenso sind tatsächliche, geplante und geschätzte Transportereignisse getrennt darzustellen.

Beispiel: Ereignis auf See, Empfang erst im Zielhafen

Als Planungsbeispiel registriert ein Tracker auf See eine Erschütterung und speichert sie mit Uhrzeit und Ereignisnummer. Erst bei der Entladung erreicht er wieder ein nutzbares Gateway. Die Anwendung erhält dann mehrere historische Meldungen.

In der Reisehistorie werden diese am ursprünglichen Ereigniszeitpunkt eingeordnet. Der Empfang im Zielhafen bleibt separat sichtbar. Wiederholte Übertragungen dürfen keine doppelten Schadensereignisse erzeugen. Falls die Geräteuhr unsicher ist, wird auch diese Unsicherheit angezeigt.

Für die Bewertung eines möglichen Transportschadens sind zudem Sensorbefestigung, Messbereich und tatsächlicher Befund relevant. Die Übertragung schützt nicht automatisch die gesamte Nachweiskette vom Sensor bis zu einem späteren Bericht.

Wie hält die Batterie über die geplante Nutzung?

Die Energiebilanz umfasst Sensoren, GNSS-Suche, lokale Speicherung und Funk. Erfolglose wiederholte Positionssuche kann besonders ungünstig sein. Das Gerät sollte daher mit seinen tatsächlich unterstützten Betriebsmodi auf Reisephasen abgestimmt werden.

Ein sinnvoller Plan kann im ruhenden Depot seltene Meldungen und bei Bewegung zusätzliche Ereignisse vorsehen. Speicherinhalte werden bei Kontakt kontrolliert nachgeliefert. Unbegrenzte Wiederholungen bei fehlendem Netz sind keine brauchbare Strategie.

Auch Rückführung und Wartung gehören zum Konzept: Wer entfernt den Tracker, kontrolliert die Halterung, lädt oder tauscht die Batterie und ordnet ihn der nächsten Sendung zu? Ohne diesen Ablauf endet die digitale Reise häufig in einer Schublade.

Was muss eine Testreise abdecken?

  1. Zuordnung und Datenübertragung im Depot prüfen.
  2. Gate, Containerstapel und tatsächliche Montageposition im Terminal testen.
  3. Funklücken und lokale Speicherung an Bord bewerten.
  4. Nachlieferung einschließlich Zeitstempeln, Reihenfolge und Duplikaten kontrollieren.
  5. Netz- und Regionalwechsel entlang der vorgesehenen Route prüfen.
  6. Rücknahme, Wartung und Wiederverwendung praktisch durchspielen.

Ein erfolgreicher Test auf dem offenen Hof belegt keine Abdeckung im beladenen Schiff. Die Bewertung sollte deshalb zeigen, welche Etappen live sichtbar sind und welche erst nachträglich. Für viele Prozesse ist nachträgliche Transparenz nützlich – solange sie nicht als aktuelle Ortung verkauft wird.

Quellen und fachliche Grundlagen