Robot fleet ERP data exchange is a two way flow: task requests travel in, and confirmations travel back out. Inbound, the fleet receives task requests naming what to move, from where, to where, with a priority and a deadline. Outbound it returns acceptance, progress, completion, exceptions and load confirmations that trigger stock movements, while battery state and fault codes stay inside the fleet layer. The stakes are physical as well as clerical. Provisional HSE figures record 126 workers killed in Great Britain in 2025/26, 24 of them struck by a moving vehicle. For a supply chain director in a regulated pharmaceutical warehouse, the pain this quarter is reconciliation. A pallet physically moves, the robot logs it, and the batch record does not change until someone keys it in at shift end. Stock reads correctly on paper and wrongly on the floor, traceability takes hours, and the automation business case dies quietly in the gap between the two systems.
Why pharmaceutical automation stalls at the data layer, not at the robot
Most stalled projects in UK pharmaceutical warehousing are not robot problems. The trucks navigate, lift and charge perfectly well. What fails is the seam between the fleet and the system holding the batch record.
Three causes recur. The first is scope. Integration is often sold as a single line called "ERP interface" with no named message set behind it, so nobody discovers until commissioning that the business system can issue a putaway task but not accept a partial completion. The second is master data: robots need every location uniquely identified and every pallet reliably labelled, and a site that tolerates a faded label read sensibly by a person will not tolerate a robot doing it. The third is ownership. The robot supplier owns the fleet side, the ERP vendor owns the business side, and the exception path between them belongs to nobody until something fails at two in the morning.
In a regulated site the consequences are heavier than in general merchandise. The MHRA expects distribution records to show what moved, when, and under whose authority. If a robot completes a move and the confirmation is lost, the physical stock and the batch record disagree, and the site is carrying an unrecorded movement until a person reconciles it by hand. That is a deviation, not a nuisance.
The safety case depends on the same data. PUWER requires work equipment to be suitable and properly controlled, and the 1998 regulations place that duty on the operator, not the supplier. Shared aisles at the distribution estates around Magna Park, DIRFT and Daventry mix pedestrians with manual and automated trucks, and the rules keeping them apart are enforced by the same orchestration layer that answers the business system. HSE guidance on segregating vehicles and pedestrians assumes somebody knows where every vehicle is, which is a data question before it is a safety one.
Lever 1: agree the message set before a single truck arrives
This is the operational lever, and it is free. Before any hardware is ordered, write down every message crossing the boundary, in both directions, with an owner and an example payload. A workable minimum is four inbound messages and five outbound.
Inbound: new task, cancel task, change priority, and a heartbeat so each side knows the other is alive. Outbound: task accepted, task started, task completed with a load confirmation naming the load, the source and the destination, task failed with a reason code, and a periodic fleet status summary.
Then settle the hard questions on paper, where they are cheap. What happens to a task the fleet cannot accept because the destination is blocked? Does a partial move post, or roll back? Which reason codes require a person before stock is touched? Teams that answer these before commissioning usually find the robot work is the shorter half of the project.
Lever 2: put a fleet manager between the business system and the trucks
This is the technical lever. Autonomous forklifts do not speak to an ERP directly, and you should not want them to. A fleet management layer sits in between: it takes work from the business system over a documented interface, turns each task into routes, traffic rules and vehicle assignments, and reports state back. Downwards it speaks to vehicles over VDA 5050, the open standard for command and control between a fleet manager and mobile robots, so one layer can command machines from several manufacturers without a bespoke interface for each, as our guide to whether a multi vendor robot fleet can run in one warehouse sets out.
The architectural rule is simple. The business system decides what work is needed. The fleet manager decides how it gets done. Neither holds the other data. The moment a fleet manager keeps its own stock balances you have created a second source of truth and an unbudgeted reconciliation task.
| Approach | Typical integration effort | Stock update latency | Main risk in a regulated site |
|---|---|---|---|
| Scheduled file exchange | Low, days to two weeks | Batch, typically 15 to 60 minutes | Duplicate or missed confirmations on retry, so the batch record drifts |
| Live interface between business system and fleet manager | Medium, weeks, dominated by field mapping | Seconds | Without an agreed exception path, failed moves can post as successes |
| Middleware translating both sides | Medium to high, no change to the core system | Seconds, with queued replay | One more validated component under change control |
Lever 3: treat every exchanged message as a regulated record
This is the regulatory lever, and it is where pharmaceutical sites diverge from general warehousing. Every message crossing the boundary is evidence. A completion naming the load, the source, the destination, the vehicle and the timestamp is an auditable record of a stock movement. A completion that says only "done" is not.
Three standards shape the design. PUWER makes the operator responsible for equipment being suitable, maintained and used by informed people, so the fleet layer must log who authorised a manual override and when. BS EN ISO 3691-4, the standard for driverless industrial trucks and their systems, governs vehicle safety functions and the zones they work in, and BSI publishes the British adoption. The expectations the MHRA applies to computerised systems put the integration itself in scope for validation: change control, access control, and an audit trail you can produce on request.
The practical test is one a supply chain director can run in a meeting. Ask for last Tuesday between 14:00 and 15:00, filtered to one batch, showing every robot move and the matching posting in the business system. If that report takes a developer a day to produce, the integration is not audit ready, whatever the commissioning certificate says.
Lever 4: design for the link dropping, not for the happy path
Networks fail, business systems are patched, interfaces time out. A well designed integration degrades rather than stops. Robots finish the task already issued and then hold safely. The fleet layer queues completions and replays them when the link returns, and every message carries an identifier so a replay cannot post the same movement twice.
Agree three numbers up front: how long the fleet may run detached before it stops accepting new work, how long completions may queue before a person is alerted, and how many retries before a message is parked for manual handling. Put them in the specification, not in a supplier assumption.
Then test them before go live by pulling the link deliberately during a shift simulation. It is the most useful hour of commissioning and it is almost always skipped. Phasing helps too: proving the exception path on one real flow is far safer than switching a whole site at once, as our guide to phased warehouse automation without a rebuild explains.
A robot fleet exchanges task requests inbound and acceptance, progress, completion, exception and load confirmation messages outbound with an ERP, while battery state and fault codes stay inside the fleet layer.
What FlyWei does here
FlyWei is an independent, vendor neutral systems integrator of autonomous forklifts and mobile robots. Because FlyWei is not tied to one manufacturer, the integration design starts from the systems a site already runs rather than from a product catalogue, and the message set above is specified before any machine is selected.
In a pharmaceutical distribution centre that means two pieces of work before any machine is chosen. FlyWei maps the flows worth automating and the data each one needs, which is where ERP and WMS integration is scoped as named messages with owners on both sides rather than one hopeful line item. FlyWei then specifies the fleet: a narrow aisle autonomous reach truck for high bay putaway, a counterbalanced autonomous forklift for inbound, and lifting robots for tote moves between picking and despatch.
The layer that makes it coherent is the M4 fleet manager, which takes work from the business system, arbitrates traffic between machines from different manufacturers over VDA 5050, and writes completions back with the detail an audit needs. The robot dispatch software applies the site rules above it: which flows run unattended, which need a person, and what happens to work in progress when something upstream stops. Sector designs are set out across the FlyWei solutions pages.
Frequently asked questions
What data does an ERP send to a robot fleet?
Task requests, and little else: what to move, the source, the destination, a priority and a deadline, plus cancel and change priority messages for work already issued. Routes and vehicle choices are fleet layer decisions.
What does the robot fleet send back?
Acceptance, start, completion with a load confirmation naming the load and both locations, and an exception with a reason code when a task cannot finish. Battery state and fault codes stay in the fleet layer.
Do we need to replace our WMS to use autonomous forklifts?
Usually not. An orchestration layer sits above the warehouse system and takes work from it, so that system stays the source of truth for stock and orders. Middleware is normally cheaper than replacement.
How do warehouse robots update stock levels in real time?
Each completed move sends a confirmation naming the load, the location it left and the location it reached. The warehouse system posts that as a stock movement, so balances update as pallets move. Failed moves must raise an exception.
What happens if the ERP or the network goes down during robot operation?
A well designed integration degrades rather than stops. Robots finish the task already issued and hold safely, while the fleet layer queues completions and replays them once the link returns without posting a movement twice.
Does connecting robots to our business system create a cyber security risk?
It creates a link between operational and business systems, so design it like any other. Segment the robot network, limit the integration account to the fields it needs, log all traffic and control supplier remote access.
If reconciling robot moves against your batch record is on your Q4 risk register, the quickest way to size the work is one flow, not the whole site.
Get a 48-hour feasibility read on your highest-volume flow and you will know which messages your existing system can already issue and which need middleware. You can also see how the M4 fleet manager sits between a business system and a mixed fleet.
No obligation, reply within one business day.