Warehouse Digital Twin for Logistics Operations

A warehouse digital twin is a live 3D or 2D model of your distribution center in which inventory moves, AGVs drive and conveyors change state as they do on the floor. This guide covers the use cases that matter for logistics teams, how to design MQTT topics for vehicles, conveyors and stock movements, and how to prototype a twin that updates in real time.

What a Warehouse Digital Twin Shows

A warehouse is a flow system. Goods arrive, get stored, are picked, packed and shipped, and the bottlenecks move during the day. Traditional systems split the picture:

• The WMS (warehouse management system) knows locations, orders and stock levels.
• The WCS or PLCs know conveyor and sorter states.
• The fleet manager knows where AGVs and AMRs are and what they are doing.
• Handheld scanners and RFID generate movement events.

A warehouse digital twin merges these streams into one spatial model. A supervisor sees a jam forming at merge point 4, three AGVs queued behind it, and the outbound wave that will miss its truck cut-off if the jam lasts another ten minutes. For general twin concepts, see the digital twin technology guide.

Use Cases for Logistics Operations

The first three are real-time and depend on low-latency data. The last three use history and are where the twin pays back over months.

Data Architecture with MQTT

The cleanest architecture puts an MQTT broker between every source and every consumer:

1. Conveyors and sorters: PLCs or the WCS publish zone states and jam alarms on change.
2. AGVs and AMRs: the fleet manager (or the vehicles themselves) publish position and status at a fixed rate, typically one to a few times per second.
3. WMS events: a small adapter publishes stock movements (put-away, pick, transfer) as events.
4. Twin services: subscribers that derive queue lengths, dwell times and congestion scores and write history.
5. Twin viewers: browser clients that subscribe over Secure WebSocket and animate the 3D scene.

A fully managed MQTT service is a good fit because the twin's value depends on that backbone being always available, and warehouse IT teams are usually focused on the WMS rather than broker operations.

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

Some practical rules:

• Conveyor zone states: retained, QoS 1, published only on change.
• AGV poses: not retained, QoS 0, fixed rate. A lost position update is replaced a moment later.
• AGV status and errors: retained, QoS 1, so a viewer opening mid-shift sees the current mission and battery.
• Inventory movements: QoS 1 events, not retained, consumed by a service that maintains stock positions.

The digital twin state synchronization article explains these choices in more depth.

Hands-On: Animate an AGV and a Conveyor Zone

Prototype against the public MQTT test broker at broker.connectmq.com. Its limits (10 messages per second per client, 64 KB per message) are fine for a few simulated vehicles. Do not publish real operational data there, as the public area is readable by everyone.

A Python simulator for one AGV driving a loop and one conveyor zone that occasionally jams:

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)

In the browser, the viewer subscribes and moves a 3D object:

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);
  }
});

The scene object is your three.js scene with meshes named after asset IDs. Interpolating poses between messages makes motion smooth even at two updates per second. See three.js digital twin for building the scene, and the ConnectMQ 3D digital twin web demo for a working example with a conveyor and robot arm streamed live over WSS.

Rollout Checklist

1. Start with one area, such as outbound conveyors, where jams are costly and visible.
2. Get a scaled floor plan and agree on one coordinate system for AGV poses and the 3D model.
3. Map every PLC zone and AGV ID to a mesh name in the model.
4. Publish states on change and poses at a fixed modest rate.
5. Move to a private broker over TLS before connecting real systems, with one credential per source system.
6. Count connections: each AGV, gateway, service and viewer tab is a client. The free Serverless plan supports up to 25; paid Serverless supports up to 1,000.
7. Record history for slotting and layout analysis with a separate subscriber.
8. Validate the twin against the floor during a busy shift before trusting it.

Common Pitfalls

• Coordinate mismatches. The fleet manager's map origin rarely matches the CAD origin. Calibrate with known points.
• Flooding the broker with poses. Ten vehicles at 20 Hz is unnecessary for visualization. Two to five updates per second with interpolation looks smooth.
• Treating WMS data as real time. Many WMS updates are batched. Show their timestamps so users know how fresh stock data is.
• Overbuilding the 3D model. Simple boxes for racks and conveyors render faster and are easier to maintain.
• Ignoring disconnects. If the fleet manager or a PLC gateway drops off the network, the twin keeps showing the last positions and states as if nothing happened. Publish a retained online/offline status per source (MQTT last will messages are ideal for this) and grey out assets whose source is offline, so supervisors never act on frozen data.
• One viewer per screen, unbounded. Every open browser tab is a separate MQTT client. Wall displays, supervisor laptops and tablets add up quickly, so include them when you plan connection limits.

Many of these patterns are shared with the factory digital twin.

Build Your Warehouse Digital Twin on ConnectMQ

ConnectMQ gives your PLCs, fleet manager and browser viewers one MQTT backbone with TLS, WebSocket and MQTT 5 support. Create a free Serverless broker at app.connectmq.com, no credit card needed, and use the live topic explorer to watch AGV and conveyor topics as you build the twin.

Frequently Asked Questions

What is a warehouse digital twin?

It is a live digital model of a warehouse that mirrors inventory movements, vehicle positions and equipment states in real time, used for monitoring, analysis and layout planning.

How often should AGV positions be published?

For visualization, one to five updates per second is usually enough when the viewer interpolates between positions. Safety-critical navigation stays within the fleet system itself.

Can a warehouse twin integrate with my WMS?

Yes. An adapter reads WMS events through its API or database and publishes them to MQTT, so the twin consumes them like any other data source.

Should conveyor states use retained messages?

Yes. Retaining state topics lets a newly opened twin viewer show every zone's current state immediately rather than waiting for the next change.