Which AGV and AMR Manufacturers Support VDA 5050?

Manufacturer support for VDA 5050 is a per-supplier question, not a published list, because the standard is open to any vehicle maker. The interface reached version 3.0.0 in March 2026, published by the VDA with the VDMA and the Karlsruhe Institute of Technology, and is a free download, so no central body certifies or registers compliant vehicles. VDA 5050 standardises the order and state messages between a fleet manager and a vehicle, but support is a per-model claim rather than a brand-wide one, so UK buyers must have it confirmed in writing for the exact trucks quoted. For an operations director in 3PL contract logistics that detail decides whether a fleet is an asset or a stranded one. Robots bought for a three-year contract at a Midlands campus should move to the next contract when it ends, and they only move if a single fleet manager can drive them all.

Why nobody can hand you a list

Interoperability questions get brand-level answers because that is how buying works, but VDA 5050 does not operate at brand level. It is a published interface, not a certification scheme. The specification and its JSON schemas sit in a public repository, and anyone may implement it. There is no conformance mark, no audit and no register, so a supplier saying it supports VDA 5050 is describing particular software on particular vehicles at a particular firmware level.

Three things vary underneath that sentence. The first is version. Version 3.0.0 is current, while many vehicles in service still speak a 2.x dialect, and a truck and a fleet manager that disagree will connect happily and then fail on the messages that matter. The second is scope. Mandatory order and state messages are the easy part. Load handling, fork height, charging behaviour and custom actions are where the real work sits. The third is route. Some vehicles speak the standard natively. Others reach it through an adapter beside the maker's own protocol, which is sound engineering, but it adds a component somebody has to own at 03:00 when a message is dropped.

None of this is a reason to avoid the standard. It is a reason to stop asking which manufacturers support VDA 5050 and start asking what this supplier will connect, to what, and by when. For an operations director in third-party logistics the stakes are concrete. Contracts at campuses such as Magna Park, DIRFT and Daventry run for a few years, not for the working life of a truck. When each supplier's software drives only its own vehicles, every renewal becomes a kit decision rather than a service decision.

Lever 1: turn interoperability into an acceptance test

The question stops being rhetorical the moment it becomes a test with a pass mark. Write into the trial scope that a named vehicle must accept an order from your chosen fleet manager, report state at the agreed interval and complete a defined move, with no bespoke integration written during the trial. Put a second machine class in the same test, so you test the interface rather than one supplier's happy path. Ask to witness it at a working site, and if a visit is needed to see a mixed fleet running, arrange one before contracts rather than after. A supplier who volunteers the optional actions not yet implemented is telling you more about delivery risk than one whose answer is a single word. It is the same evidence discipline as vetting any automation supplier.

Lever 2: put the fleet manager at the centre and the controller on the truck

Interoperability is an architecture choice before it is a procurement one. The durable pattern puts a fleet manager above the vehicles, taking work from your warehouse system and issuing it as orders, while each vehicle runs an onboard controller handling navigation, safety interlocks and motion. The VDA 5050 interface is the seam between those two layers, carrying orders down and state back over a documented message format. Keep that seam standard and the vehicle becomes a replaceable component. Let a supplier bridge it with a proprietary protocol and the fleet manager quietly becomes that supplier's product. The same logic applies on the truck, where an open AMR and AGV controller choice keeps retrofit options alive. The M4 fleet manager is built for this: one traffic model, one charging strategy and one set of business rules across machine classes never designed to work together. The operating detail is in our guide to whether a multi-vendor robot fleet can run in one warehouse.

VDA 5050 standardises the order and state messages between a fleet manager and a vehicle, but support is a per-model claim rather than a brand-wide one, so UK buyers must have it confirmed in writing for the exact trucks quoted.

Lever 3: treat every vehicle as work equipment, whoever built it

A mixed fleet does not get a mixed safety case. Every driverless truck on your floor is work equipment under the Provision and Use of Work Equipment Regulations 1998, whoever made it, and the duties under PUWER on suitability, inspection and maintenance follow the equipment, not the badge. ISO 3691-4 sets the safety requirements for driverless industrial trucks, and each machine needs its own UKCA documentation and thorough examination regime where lifting is involved. Pedestrian segregation, covered in the HSE guidance on workplace transport, is the site-level control that must hold across every supplier at once. In practice that means one traffic plan, one set of zone rules and one escalation route, not one per manufacturer. Interoperability at the command layer is what makes that enforceable, because a fleet manager that can see and stop everything is the only place a site-wide rule can live.

Lever 4: own the map, the data and the integration

Three assets decide whether you can change supplier later, and none of them is the robot. The first is the site map and its zone definitions. The second is the task and telemetry data, including completions written back to your warehouse system. The third is the integration itself. Where those sit with one vendor, interoperability on paper will not save you, because swapping a truck means rebuilding the layer above it. Specify in the contract that maps and operational data are yours and exportable, that interface documentation is handed over, and that the integration is documented well enough for another competent party to maintain. Logistics UK is a useful reference for members weighing supplier dependency. If your existing systems are the constraint rather than the robots, our guidance on what to do when a system has no API covers the realistic routes.

What FlyWei does here

FlyWei is the UK partner of SEER Robotics and a UK systems integrator, which is why this question gets a straight answer from us. FlyWei integrates the best machines across multiple manufacturers rather than selling one maker's range, so when a client asks which vehicles genuinely speak VDA 5050 at the version and scope they need, FlyWei checks it model by model and says what is native, what runs through an adapter and what is not there yet.

In a 3PL setting that starts with the flows repeating across every contract you win: dock to stock, stock to pick face, and the long runs between. FlyWei designs the fleet around those flows, then specifies FlyWei autonomous forklifts and AMR classes fitting the loads and lift heights involved. The M4 fleet manager holds the traffic model, the charging strategy and the business rules, and the robot dispatch software connects it to the system you already run, so that system stays the record of stock. Across the sectors FlyWei works in the test is the same: can this fleet be re-pointed at a different contract without rewriting the layer above it. Where a client is weighing whether their warehouse system must change at all, we have set out why replacing a WMS is rarely necessary.

Frequently asked questions