Ein Industrieunternehmen hatte vor wenigen Monaten eine neue Logistik-Anwendung eingeführt, bei der Kommissionierwagen mit Hilfe autonomer Fahrzeuge, so genannter Fahrerloser Transportfahrzeuge (FTF), zwischen Lager und Arbeitsplatz bewegt werden. In diesem Bereich hatten verschiedene andere Endgeräte Schwierigkeiten, sich mit WLAN Access Points zu verbinden.
Eine erste Untersuchung führte ans Licht, dass in Bereichen, wo sich typischerweise viele der FTF aufhalten, die Kanalauslastung der Access Points außergewöhnlich hoch war. Die betroffenen Endgeräte meldeten sich möglicherweise aus diesem Grund an weiter entfernten und weniger ausgelasteten Access Points an. Ich habe daher versucht herauszufinden, was die Ursache für die hohe Kanalauslastung war.
Eine Paketaufzeichnung im WLAN führte hohe Paketraten und einen hohen Prozentsatz langer Pakete zu Tage. Genaugenommen waren zahlreiche UDP-Datagramme mit mehr als 6 kB Länge unterwegs. Die IP-Adressen gehörten zu den FTF. Die weitere Analyse zeigte, dass jedes FTF mit ca. 40 anderen kommunizierte – ununterbrochen.
Wozu könnte das gut sein? Schließlich fährt so ein FTF autonom. Es nutzt dafür Informationen, die von bordeigenen Sensoren erhoben werden. Der Fahrweg wird gern über spezielle Leit-Streifen bestimmt, die auf dem Boden aufgebracht sind, oder man versenkt in regelmäßigen Abständen Magnete im Estrich. Weitere Sensoren prüfen, ob Hindernisse den Weg verstellen. Daten muss ein FTF eigentlich nur austauschen, wenn neue Fahraufträge anfallen oder wenn z.B. an Kreuzungspunkten eine Koordination mit anderen Fahrzeugen erforderlich ist. Soweit meine naive Vorstellung von der FTF-Steuerung…
Ich habe dann auf der Website des FTF-Herstellers nachgesehen. Dort wird beworben, dass die FTFe als „Schwarm“ mit bis zu 100 Fahrzeugen operieren. Aha, es scheint also eine Art Schwarm-Wissen zu geben, das allen FTFen zur Verfügung steht. Der Vorteil einer solchen Lösung liegt auf der Hand: Es wird keine zentrale Infrastruktur benötigt. Insbesondere braucht kein Server in irgendeinem Rechenzentrum installiert und betrieben (!) zu werden. Der Nachteil besteht darin, dass Schwarm-Wissen an alle verteilt werden muss. Die einfachste Lösung dafür scheint zu sein, dass jedes FTF mit jedem anderen kommuniziert.
Rechnen Sie mal: Bei nur 40 FTFen sind es 780 paarweise Kommunikationsbeziehungen. Erfolgt jede Sekunde ein vollständiger Datenaustausch zwischen allen FTFen, macht das 1.560 Pakete. Mit 6 kB Paketlänge ergibt sich eine Rate von 75 Mbit/s. Das klingt nach nicht viel im Zeitalter von Gigabit-WLAN. Jedoch müssen sich die FTF bei meinem Industriekunden die verfügbare Bitrate mit zig anderen Anwendungen teilen.
Ein weiteres Problem – nicht zuletzt für die Anwendung selbst – sind die langen UDP-Datagramme. Die müssen nämlich auf IP-Fragmente aufgeteilt werden. Und geht nur ein einziges Fragment verloren, ist das gesamte Datagramm futsch. Ich habe also untersucht, was diese Datagramme so lang macht und sehe mit Verwunderung, dass alle Informationen in lesbaren Texten kodiert sind. Mit einem einfachen ZIP-Packer konnte ich ein solches Datagramm um 85% schrumpfen. Eine effiziente Kodierung sieht wahrlich anders aus.
Mit diesem Wissen haben wir schließlich Kontakt zum Hersteller aufgenommen. Dort hat man – so sagte man uns – bereits eine Version vorbereitet, bei der nur noch Parameter versandt werden, die sich verändert haben. Über eine effizientere Kodierung will man nachdenken.
Fazit: Untersuchen Sie alle Applikationen genau, bevor Sie sie in Ihr WLAN aufnehmen. Trauen Sie sich, den Anbietern und Entwicklern solcher Anwendungen Vorgaben zu machen. Kontrollieren Sie das Verhalten neuer Anwendungen bereits im Rahmen einer Pilotphase.
Teile diesen Eintrag