A robot that moves stock changes your inventory. If the fleet controller keeps its own authoritative stock table and the ERP finds out afterwards, you have two sources of truth and a reconciliation nobody owns. The ERP stays the system of record; the fleet owns execution.
One place that is authoritative
Warehouse automation vendors ship capable software, and it is usually happy to hold stock state. Letting it is the decision that causes the most trouble later, because two systems that both believe they know the count will disagree, and the disagreement is discovered at a count, long after it occurred.
| Owns | System of record | Fleet controller |
|---|---|---|
| What stock exists, and where | Yes | No — it reads |
| Commercial priority | Yes | No |
| How a move is executed | No | Yes |
| Which unit does it, and when | No | Yes |
| That a move completed | Records it | Reports it |
Ordering, and what arrives late
Movement events arrive out of order, arrive twice, and sometimes arrive after the shift they describe has ended. Design for it: sequence on the robot's own clock, key on a move identifier so a repeat is idempotent, and reconcile continuously rather than at a count.
The integration that only works when messages arrive once and in order will work in the pilot and fail in the third week of production.
The task that cannot be finished
A blocked aisle, a tote that is not where the system believed, a pick that fails three times. Each leaves state that a person has to resolve.
- The task becomes a visible exception with an owner, not a vanished job.
- The stock involved is flagged, not silently assumed correct.
- The reason is recorded by category, because repeated reasons are a physical problem, not a software one.
Silent abandonment is the expensive design. The discrepancy still exists; it just surfaces later, larger, and with no trail back to what caused it.
Where priority comes from
The ERP knows which order is late, which customer is on credit hold, which shipment has a carrier cut-off in ninety minutes. The fleet controller knows which robots are charging, which aisle is blocked, and what the realistic sequence is.
Priority should originate commercially and be sequenced physically. A controller optimising purely for throughput will pick efficiently and ship the wrong order first.
Safety is not a software layer
Emergency stops, light curtains, speed and separation limits belong in hardware interlocks that hold regardless of what any application believes is happening.
Software adds supervision, traceability and evidence on top of that. It does not substitute for it. A safety case that depends on an application behaving correctly is not a safety case, and it will not be accepted as one.
Record per unit
Utilisation, tasks completed, faults by type, battery cycles, maintenance history — all against the individual robot, the same way a serialised asset is tracked anywhere else.
Fleet averages look healthy while one unit fails twice a week. That unit is where the maintenance cost and most of the exception queue actually come from, and an average is precisely the statistic that hides it.