Ein digitaler Zwilling für das Lager ist ein lebendiges 3D- oder 2D-Modell Ihres Distributionszentrums, in dem sich Bestände bewegen, FTS fahren und Förderstrecken ihren Zustand genauso ändern wie in der Halle. Dieser Leitfaden behandelt die Anwendungsfälle, die für Logistikteams zählen, das Design von MQTT-Topics für Fahrzeuge, Fördertechnik und Bestandsbewegungen und den Prototyp eines Zwillings, der sich in Echtzeit aktualisiert.
Was ein digitaler Zwilling für das Lager zeigt
Ein Lager ist ein Flusssystem. Waren kommen an, werden eingelagert, kommissioniert, verpackt und versendet, und die Engpässe wandern im Tagesverlauf. Klassische Systeme zerteilen das Bild:
- Das LVS (Lagerverwaltungssystem, WMS) kennt Lagerplätze, Aufträge und Bestände.
- Der Materialflussrechner (WCS) oder die SPSen kennen die Zustände von Förderern und Sortern.
- Der Flottenmanager weiß, wo sich FTS und AMR befinden und was sie tun.
- Handscanner und RFID erzeugen Bewegungsereignisse.
Ein digitaler Zwilling für das Lager führt diese Ströme in einem räumlichen Modell zusammen. Ein Schichtleiter sieht, wie sich an Zusammenführung 4 ein Stau bildet, drei FTS dahinter warten und die ausgehende Welle ihren LKW-Abfahrtszeitpunkt verpasst, wenn der Stau noch zehn Minuten anhält. Allgemeine Zwillingskonzepte finden Sie im Leitfaden zur Digital-Twin-Technologie.
Anwendungsfälle in der Logistik
| Anwendungsfall | Benötigte Daten | Was der Zwilling ergänzt |
|---|---|---|
| Live-Hallenübersicht | Förderzustände, FTS-Positionen, Status der Ladetore | Räumliches Bild, wo Arbeit fließt oder stockt |
| Stau- und Störungserkennung | Lichtschrankenzustände, Zonenbelegung, FTS-Warteschlangen | Zeigt Warteschlangen, die sich vor einer Störung aufbauen |
| FTS-Flottenüberwachung | Position, Akku, Auftrag, Fehlercodes | Flottenzustand und Verkehrsschwerpunkte im Layout |
| Bestandsbewegungen | Scan- und RFID-Ereignisse mit Orten | Wohin Bestände tatsächlich wandern im Vergleich zum geplanten Weg |
| Slotting-Analyse | Zugriffshäufigkeit je Lagerplatz über die Zeit | Heatmaps, die das Umlagern von Schnelldrehern leiten |
| Layout-Was-wäre-wenn | Historische Flüsse, auf einem geänderten Layout abgespielt | Schätzt den Effekt verschobener Stationen oder zusätzlicher Bahnen |
Die ersten drei laufen in Echtzeit und brauchen Daten mit geringer Latenz. Die letzten drei nutzen die Historie, und mit ihnen amortisiert sich der Zwilling über Monate.
Datenarchitektur mit MQTT
Die sauberste Architektur setzt einen MQTT-Broker zwischen jede Quelle und jeden Konsumenten. Er bildet den Unified Namespace (UNS) des Standorts: eine zentrale, nach ISA-95 gegliederte Topic-Struktur, in der LVS, Materialflussrechner, Flottenmanager und später auch MES und ERP ihre aktuellen Daten ablegen und abonnieren:
- Förderer und Sorter: SPSen oder der Materialflussrechner veröffentlichen Zonenzustände und Stau-Alarme bei Änderung.
- FTS und AMR: Der Flottenmanager (oder die Fahrzeuge selbst) veröffentlichen Position und Status mit fester Rate, typischerweise ein- bis mehrmals pro Sekunde.
- LVS-Ereignisse: Ein kleiner Adapter veröffentlicht Bestandsbewegungen (Einlagerung, Kommissionierung, Umlagerung) als Ereignisse.
- Zwillingsdienste: Subscriber, die Warteschlangenlängen, Verweilzeiten und Stau-Kennzahlen ableiten und die Historie schreiben.
- Zwillings-Viewer: Browser-Clients, die über Secure WebSocket abonnieren und die 3D-Szene animieren.
Ein verwalteter MQTT-Broker passt gut, weil der Wert des Zwillings davon abhängt, dass dieses Backbone immer verfügbar ist, und sich Lager-IT-Teams meist auf das LVS konzentrieren statt auf den Broker-Betrieb.
Topic-Design
connectmq/<site>/<area>/<asset-type>/<asset-id>/<data-type>
connectmq/dc-east/outbound/conveyor/zone-12/state
connectmq/dc-east/outbound/conveyor/merge-4/alarm
connectmq/dc-east/fleet/agv/agv-03/pose
connectmq/dc-east/fleet/agv/agv-03/status
connectmq/dc-east/inventory/movements
Die Ebenen folgen der ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell): Standort, Bereich, Anlagentyp und einzelnes Asset. Bei einem Mittelständler mit mehreren Standorten sieht ein UNS-Pfad dann etwa so aus: acme/lager-dortmund/warenausgang/foerdertechnik/zone-12/zustand. So finden MES, ERP und Zwilling dieselben Daten an derselben Stelle. Mehr zum Zusammenspiel mit Sparkplug B lesen Sie unter Sparkplug B und Unified Namespace.
Einige praktische Regeln:
- Zonenzustände der Fördertechnik: Retained, QoS 1, nur bei Änderung veröffentlicht.
- FTS-Posen: nicht Retained, QoS 0, feste Rate. Eine verlorene Positionsmeldung wird einen Moment später ersetzt.
- FTS-Status und Fehler: Retained, QoS 1, damit ein mitten in der Schicht geöffneter Viewer den aktuellen Auftrag und Akkustand sieht.
- Bestandsbewegungen: QoS-1-Ereignisse, nicht Retained, konsumiert von einem Dienst, der die Bestandspositionen pflegt.
Der Artikel zur Zustandssynchronisation im digitalen Zwilling erklärt diese Entscheidungen ausführlicher.
Praxis: ein FTS und eine Förderzone animieren
Erstellen Sie den Prototyp mit dem öffentlichen MQTT-Broker unter broker.connectmq.com. Seine Limits (10 Nachrichten pro Sekunde und Client, 64 KB pro Nachricht) reichen für einige simulierte Fahrzeuge. Er ist für Tests und Prototypen gedacht: Veröffentlichen Sie dort keine echten Betriebsdaten, da der öffentliche Bereich für alle lesbar ist.
Ein Python-Simulator für ein FTS, das eine Schleife fährt, und eine Förderzone, die gelegentlich staut:
import json
import math
import random
import time
import uuid
import paho.mqtt.client as mqtt
RUN = "wh-44d0" # change to your own unique id
BASE = f"connectmq/demo/{RUN}/dc-east"
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"wh-sim-{uuid.uuid4().hex[:6]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
t = 0.0
battery = 100.0
zone_state = "running"
client.publish(f"{BASE}/outbound/conveyor/zone-12/state", json.dumps({"state": zone_state}), qos=1, retain=True)
while True:
t += 0.5
x = 20 + 15 * math.cos(t / 10)
y = 10 + 6 * math.sin(t / 10)
heading = (math.degrees(t / 10) + 90) % 360
battery = max(5.0, battery - 0.01)
client.publish(f"{BASE}/fleet/agv/agv-03/pose",
json.dumps({"x": round(x, 2), "y": round(y, 2), "headingDeg": round(heading, 1), "ts": time.time()}))
if int(t * 2) % 20 == 0:
client.publish(f"{BASE}/fleet/agv/agv-03/status",
json.dumps({"mission": "replenish-A12", "batteryPct": round(battery, 1)}), qos=1, retain=True)
new_state = "jammed" if random.random() < 0.02 else ("running" if zone_state == "jammed" and random.random() < 0.2 else zone_state)
if new_state != zone_state:
zone_state = new_state
client.publish(f"{BASE}/outbound/conveyor/zone-12/state", json.dumps({"state": zone_state, "ts": time.time()}),
qos=1, retain=True)
print("zone-12 ->", zone_state)
time.sleep(0.5)
Im Browser abonniert der Viewer die Topics und bewegt ein 3D-Objekt:
import mqtt from "mqtt";
const base = "connectmq/demo/wh-44d0/dc-east";
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "wh-viewer-" + Math.random().toString(16).slice(2, 10),
protocolVersion: 5,
});
client.on("connect", () => {
client.subscribe([`${base}/fleet/agv/+/pose`, `${base}/fleet/agv/+/status`, `${base}/outbound/conveyor/+/state`]);
});
client.on("message", (topic, payload) => {
const data = JSON.parse(payload.toString());
const parts = topic.split("/");
if (topic.endsWith("/pose")) {
const agv = scene.getObjectByName(parts[parts.length - 2]);
if (agv) {
agv.position.set(data.x, 0, data.y);
agv.rotation.y = (-data.headingDeg * Math.PI) / 180;
}
} else if (topic.endsWith("/state")) {
const zone = scene.getObjectByName(parts[parts.length - 2]);
if (zone) zone.material.color.set(data.state === "jammed" ? 0xd94040 : 0x3fa34d);
}
});
Das Objekt scene ist Ihre three.js-Szene mit Meshes, die nach den Asset-IDs benannt sind. Wenn Sie die Posen zwischen den Nachrichten interpolieren, wirkt die Bewegung selbst bei zwei Aktualisierungen pro Sekunde flüssig. Zum Aufbau der Szene siehe Digitaler Zwilling mit three.js, und die 3D-Digital-Twin-Webdemo von ConnectMQ zeigt ein funktionierendes Beispiel mit Förderband und Roboterarm, live über WSS gestreamt.
Checkliste für die Einführung
- Beginnen Sie mit einem Bereich, etwa der Fördertechnik im Warenausgang, wo Staus teuer und sichtbar sind.
- Besorgen Sie einen maßstabsgetreuen Hallenplan und einigen Sie sich auf ein Koordinatensystem für FTS-Posen und das 3D-Modell.
- Ordnen Sie jede SPS-Zone und jede FTS-ID einem Mesh-Namen im Modell zu.
- Veröffentlichen Sie Zustände bei Änderung und Posen mit fester, moderater Rate.
- Wechseln Sie vor dem Anbinden echter Systeme zu einem privaten Broker über TLS, mit einer Zugangskennung pro Quellsystem.
- Zählen Sie die Verbindungen: Jedes FTS, Gateway, jeder Dienst und jeder Viewer-Tab ist ein Client. Der kostenlose Serverless-Tarif unterstützt bis zu 25, der kostenpflichtige Serverless-Tarif bis zu 1.000.
- Zeichnen Sie die Historie für Slotting- und Layout-Analysen mit einem separaten Subscriber auf.
- Validieren Sie den Zwilling während einer stark ausgelasteten Schicht gegen die Halle, bevor Sie ihm vertrauen.
Häufige Stolpersteine
- Abweichende Koordinaten. Der Kartenursprung des Flottenmanagers stimmt selten mit dem CAD-Ursprung überein. Kalibrieren Sie mit bekannten Punkten.
- Den Broker mit Posen überfluten. Zehn Fahrzeuge mit 20 Hz sind für die Visualisierung unnötig. Zwei bis fünf Aktualisierungen pro Sekunde mit Interpolation wirken flüssig.
- LVS-Daten als Echtzeit behandeln. Viele LVS-Aktualisierungen erfolgen gebündelt. Zeigen Sie ihre Zeitstempel an, damit Nutzer wissen, wie aktuell die Bestandsdaten sind.
- Das 3D-Modell überladen. Einfache Quader für Regale und Förderer rendern schneller und sind leichter zu pflegen.
- Verbindungsabbrüche ignorieren. Fällt der Flottenmanager oder ein SPS-Gateway aus dem Netz, zeigt der Zwilling weiter die letzten Positionen und Zustände, als wäre nichts geschehen. Veröffentlichen Sie je Quelle einen Retained-Online/Offline-Status (MQTT-Last-Will-Nachrichten sind dafür ideal) und grauen Sie Assets aus, deren Quelle offline ist, damit Schichtleiter nie auf eingefrorene Daten hin handeln.
- Ein Viewer pro Bildschirm, unbegrenzt. Jeder offene Browser-Tab ist ein eigener MQTT-Client. Wandbildschirme, Laptops von Schichtleitern und Tablets summieren sich schnell; berücksichtigen Sie sie bei der Planung der Verbindungslimits.
Viele dieser Muster teilt der Lagerzwilling mit dem digitalen Zwilling der Fabrik.
Bauen Sie Ihren digitalen Zwilling für das Lager auf ConnectMQ
ConnectMQ bietet Ihren SPSen, Ihrem Flottenmanager und Ihren Browser-Viewern ein MQTT-Backbone mit Unterstützung für TLS, WebSocket und MQTT 5. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, und beobachten Sie FTS- und Förder-Topics im Live-Topic-Explorer, während Sie den Zwilling aufbauen.
Häufig gestellte Fragen
Was ist ein digitaler Zwilling für das Lager?
Ein lebendiges digitales Modell eines Lagers, das Bestandsbewegungen, Fahrzeugpositionen und Anlagenzustände in Echtzeit abbildet und für Überwachung, Analyse und Layoutplanung genutzt wird.
Wie oft sollten FTS-Positionen veröffentlicht werden?
Für die Visualisierung reichen meist ein bis fünf Aktualisierungen pro Sekunde, wenn der Viewer zwischen den Positionen interpoliert. Sicherheitskritische Navigation bleibt im Flottensystem selbst.
Lässt sich ein Lagerzwilling mit meinem LVS integrieren?
Ja. Ein Adapter liest LVS-Ereignisse über dessen API oder Datenbank und veröffentlicht sie per MQTT, sodass der Zwilling sie wie jede andere Datenquelle konsumiert.
Sollten Förderzustände Retained Messages nutzen?
Ja. Wenn Zustands-Topics als Retained gespeichert werden, zeigt ein neu geöffneter Zwillings-Viewer sofort den aktuellen Zustand jeder Zone, statt auf die nächste Änderung zu warten.
