AGV Fleet Management System: Integrating Multiple Vendors with VDA 5050

A magnetic-tape AGV installed first, an AMR from another vendor added later, an automated forklift (AGF) now under consideration: at Japanese plants in Thailand, vehicles from different vendors sharing one building are no longer unusual. But each vendor brings its own AGV fleet management system, and the vehicles compete for the same aisles, intersections, automatic doors, elevators and chargers. The result is an operation of “splitting by time of day,” “stopping one side” or “people coordinating by radio,” and adding vehicles does not raise transport volume as much as expected. That is when two things come up for consideration: a configuration that brings vehicles from multiple vendors under one AGV fleet management system, and VDA 5050, the common interface for doing so.

This article makes one argument. When you run AGVs/AMRs from multiple vendors in one plant, success is decided not by “whether they support a communication standard” but by whether you decided the following three things first. (1) Who owns the arbitration of intersection zones and shared equipment (an upper level that is not any vendor’s fleet manager, or one vendor that everything is consolidated on). (2) How far you align maps and coordinate systems, the vocabulary of actions and the meaning of errors. (3) The division of responsibility for safety and for failures. VDA 5050 aligns the “way of talking” between the fleet control and the vehicles. But the standard itself states explicitly that it does not cover safety requirements, traffic management logic, interfaces with peripheral equipment and higher-level IT, project and acceptance procedures, the allocation of responsibilities, or cybersecurity. Those you have to decide yourselves.

Below, so that staff in production engineering, maintenance, logistics improvement and IT, plant managers, and production engineering departments at head offices in Japan can assemble the material they need for internal decisions, we go through the differences between control layers, the scope of VDA 5050, where mixed fleets stop, a comparison of control approaches, the scope of standardization, links with higher-level systems and equipment, safety and the division of responsibility, networks, a model cost calculation, the RFP, and PoC and acceptance testing, in that order. The overall flow of AGV deployment is covered in “AGV System Integration in Thailand: 2026 RFP and Deployment Guide,” so this article focuses on “fleet control once you have two or more vendors.” All amounts for the model plant in this article are placeholder figures set for this article. Also, the parts that touch on safety standards and tax are an introduction to publicly available information and are not legal advice or advice on obtaining certification.

Why review your AGV fleet management system now

What happens at a plant that brings in a second vendor

As long as all AGVs come from one vendor, you can leave fleet control to that vendor’s software. Yielding at intersections, charging timing and elevator calls are all handled by that vendor’s fleet manager. The problem arises when you add vehicles from another vendor because of differences in the loads or uses.

• The two vendors’ fleet managers do not know where each other’s vehicles are, so at intersections and narrow aisles the only option is “stop one of them”
• Call signals for automatic doors and elevators split into two systems, and arbitration of the contention has to be built into the PLC on the equipment side
• Chargers are dedicated per vendor, and two types stand side by side along the same wall
• Transport orders from the WMS or MES come through a separate entry point for each vendor (a separate API, a separate screen, a separate call button)
• When a failure occurs, it takes time to isolate which vendor’s problem it is

If this continues, the number of vehicles goes up, but waiting at intersection zones increases and transport volume does not grow. In Thailand too, a 2021 report said that a Thai factory automation company that had signed a distribution agreement with the AGV manufacturer BlueBotics had by then commissioned more than 80 vehicles in the country, so the groundwork exists for vehicles of different vendors and generations to end up in the same plant. How to choose a vendor in the first place is left to “AGV Manufacturer Selection in Thailand: An RFP Buyer’s Guide“; this article starts from the state where “as a result of those choices, there are now several vendors.”

VDA 5050 3.0.0 was published in March 2026

The common interface most often mentioned for running vehicles from multiple vendors under one fleet control is Germany’s VDA 5050. The current version is version 3.0.0, published by the VDA (German Association of the Automotive Industry) in March 2026. The VDA’s official page also shows the current version as “Version 3.0.0, March 2026.”

In 3.0.0, the title of the specification itself changed. Up to 2.1.0 it was “Interface for the communication between automated guided vehicles (AGV) and a master control”; in 3.0.0 it is “Interface for the Communication between Mobile Robots and a Fleet Control.” The terms have also been replaced, from “master control / AGV” to “fleet control / mobile robot.” In this article, the control placed above the vendor-specific fleet managers to coordinate vehicles from multiple vendors is called the “upper-level control” (called fleet control in VDA 5050 3.0 and master control in earlier versions).

As the main changes in 3.0.0, the GitHub release notes list support for freely navigating mobile robots (sharing planned paths, the concept of zones), a revision of operating modes and action states, the addition of the error levels “URGENT” and “CRITICAL,” and the addition of instant actions such as certificate updates. The AMR manufacturer idealworks, one of the participating companies, explains in its own news that 3.0.0 is the result of three years of work, 32 in-person workshops and a core team of 25 people (this is the company’s own account).

Interoperability testing and the market for transport robots

The VDA’s official page introduces the “AGV Mesh-Up” as a venue where VDMA member companies can test the interface compliance of their vehicles and fleet controls. According to Fraunhofer IML, the 4th edition was held in Dortmund in April 2024, and 8 mobile robots from different manufacturers were tested. A person in charge at the institute explained that before VDA 5050, mobile robots from different suppliers could not be run by a common master control.

On the market side, the International Federation of Robotics (IFR) reported in a release on September 30, 2026 that global shipments of professional service robots in 2025 rose 24% to about 250,000 units, and that the top application was “transportation and logistics” with 117,500 units (up 21%, a 47% share). These are figures for service robots worldwide; they are neither a count of factory AGVs alone nor a breakdown for Thailand. Even so, it is easy to imagine that transport robots will keep increasing and that situations where vehicles from multiple vendors share one site will continue to grow.

Thailand’s automotive industry has investment incentives for automation and robotics

In the Thai context, BOI (Board of Investment of Thailand) Notification No. 4/2569 was published in the Royal Gazette on March 31, 2026. According to a law firm’s commentary, it is limited to promoted projects in general automotive manufacturing (activity 3.6) and PHEV/HEV manufacturing (activity 3.8), and grants, for the introduction of automation and robotic systems, an import duty exemption on machinery and a 50% corporate income tax exemption for 3 years capped at the investment amount (excluding land costs and working capital). Under certain conditions involving Thai domestic manufacturers of automation machinery, this is raised to 100%; the investment must be at least 1,000,000 THB, and the application deadline is the end of 2027. Projects currently receiving a corporate income tax exemption are not eligible. This is a measure for the automotive industry and does not apply to plants in general. Other industries may have different measures, so check eligibility with the BOI or a specialist. This article is not tax advice.

What an AGV fleet management system is: vehicle control, vendor fleet managers, upper-level master control and WMS/MES

The term “AGV fleet management system” covers different scopes depending on who is speaking. Much of the reason internal discussions do not mesh is that people are talking about different layers. First, let us separate the layers.

VDA 5050 3.0.0 lists, as the minimum functions performed by the upper-level control, assigning orders to vehicles, path calculation and guidance for line-guided robots (taking into account each vehicle’s size and maneuverability), detection and resolution of blockages (deadlocks), energy management (charging orders can interrupt transport orders), traffic control (buffer paths and waiting positions), temporary changes to the environment (such as releasing areas or changing maximum speeds), communication with peripheral systems such as doors, gates and elevators, and detection and resolution of communication errors. The functions handled by the mobile robot, on the other hand, are localization, path execution, action execution and continuous transmission of status.

The point to note here is that the standard listing “the functions the upper-level control performs” is a different thing from deciding how to implement them. As we will see later, traffic management logic and interfaces with peripheral equipment are outside the scope of the standard. If you introduce an upper-level control, its contents (how intersection priorities are decided, how deadlocks are resolved, how doors and elevators are connected) differ by product and by project.

The same applies to the relationship with the WMS. The WMS decides “what to transport,” and fleet control decides “with which vehicle and by which route.” WMS implementation itself is covered in “Thailand WMS 2026: RFP, 90-Day PoC and Acceptance for Brownfield Warehouses.”

What VDA 5050 is: who makes it, what it standardizes and what it does not

Who makes it

According to the foreword of VDA 5050 3.0.0, the specification was created jointly by the VDA and the VDMA (German Mechanical Engineering Industry Association). The Institute for Material Handling and Logistics (IFL) at the Karlsruhe Institute of Technology (KIT), commissioned by both associations, coordinates development and manages the official GitHub repository. The publisher is the VDA.

Section 2 Scope of the standard defines the document as “a standardized, vendor-neutral communication interface between fleet control systems and mobile robots,” and gives three goals: (1) reducing the complexity of connecting mobile robots to a fleet control, (2) enabling heterogeneous fleets made up of mobile robots from different manufacturers to operate cooperatively in the same physical environment, and (3) providing generic definitions usable for mobile robots that differ in locomotion, dimensions, load handling capability and degree of autonomy. It also states explicitly that use of this specification is voluntary and non-binding, and its application is at the discretion of the parties involved. The disclaimer also says that those applying it are responsible for using it correctly in each individual case, and that it does not replace the interpretation of laws and regulations.

Version numbers follow semantic versioning: a major version (x.0.0) usually contains changes that are not backward compatible, a minor version adds new features, and a patch version contains small corrections such as fixing typographical errors. The GitHub README says that 3.0.1 (minor fixes) and 3.1.0 (backward-compatible changes) are envisaged next, and that 4.0.0 is not currently planned. The content and timing of the next versions are not covered here.

How communication works

Communication is assumed to run over wireless networks, and the effects of connection loss and message loss are to be taken into account. The message protocol is MQTT, used in combination with the JSON format, and the minimum version for compatibility is MQTT 3.1.1. For a local broker, the recommended topic hierarchy is “interfaceName/majorVersion/manufacturer/serialNumber/topic,” so the major version number is part of the topic. The topics in 3.0.0 are as follows.

The topics in 2.1.0 are the six of order, instantActions, state, visualization, connection and factsheet; zoneSet and responses were added in 3.0.0. In 2.1.0, the main changes from 2.0.0 were a free-driving range within an aisle width (corridors), map distribution, error hints, and the addition of vehicle configuration information to the factsheet.

What VDA 5050 aligns and what it does not

This distinction is the most important point when thinking about multi-vendor fleet control. Below, we set what the standard defines alongside what the standard itself says it “does not cover.”

The six “not aligned” items are written as such in Section 2 Scope of the standard. In other words, even if you buy a fleet control and vehicles that support VDA 5050, these six items are not settled at the time of purchase. The RFP and FAT/SAT sections in the second half of this article are largely the work of filling in these six items yourselves.

One AGV manufacturer (BlueBotics), in its own explanatory article, lists as limitations of VDA 5050 that there is no unified map format, that interpretation of complex errors and coordination of recovery are not specified, that security is left to the integrator, and that adding each new vehicle type almost certainly requires some custom software development. This is one company’s view, but on map file format and security it does not contradict what the standard’s text says.

How VDA 5050 differs from other AMR interoperability initiatives

Besides VDA 5050, there are other initiatives for running vehicles from multiple vendors together.

• MassRobotics AMR Interoperability Standard (version 1.0): developed by MassRobotics in the US. It is a standard for sharing information such as position, speed, direction, health, and task and availability status so that AMRs from multiple vendors can “coexist” on the floor. Transport is WebSocket and messages are JSON; status messages are sent on change, at a maximum frequency of once per second. The document states that it must not be relied on for safety-related purposes, and that each robot system remains responsible for its own safety and navigation. Whereas VDA 5050 is an interface through which “the fleet control gives orders to the vehicles,” MassRobotics 1.0 is mainly about sharing status and does not define a format for driving orders.
• Open-RMF: free, open-source software that enables sharing and interoperability between multiple robot fleets and physical infrastructure such as doors, elevators and building management systems. Since 2024 it has been run by the Open Source Robotics Alliance (OSRA). It was originally developed for healthcare facilities and is described as usable in factories and logistics centers as well.
• openTCS: open-source transport control software from Fraunhofer IML. It is announced that the standalone repository for the VDA 5050 communication adapter was archived in August 2026 and that the adapter was integrated into openTCS itself (7.4 and later).

Five places where a multi-vendor AMR fleet stops

When you run vehicles from multiple vendors in the same plant, the places where they stop are fairly predictable. Identifying these five at the inventory stage gives you material for choosing a control approach.

(1) Intersection zones

The most common is the intersection zone. A vendor’s fleet manager can make its own vehicles yield to each other, but it does not know where other vendors’ vehicles are. Each vehicle has its own safety functions, so it stops before a collision. But if there is no one to decide which moves first after they stop, both keep waiting. On the shop floor this is resolved by “a person moving one of them by hand,” and that becomes the norm.

(2) Shared equipment

Automatic doors and elevators are resources that can only be used by one vehicle at a time. If you connect each vendor’s call signals to the equipment PLC, you have to build into the PLC “which call to accept first” and “what to do if another vendor’s vehicle arrives while it is in use.” Elevator integration is covered in detail in “AGV Elevator Integration: RFP and FAT/SAT Acceptance,” and charger selection in “AGV Automatic Charging System Selection for Thai Factories.”

(3) Misaligned maps and coordinates

Each vendor’s vehicles build maps in that vendor’s own way. Because the origin and orientation can differ by vendor, overlaying them at the upper level requires coordinate transformation. If the transformation is wrong, a vehicle that should be just short of an intersection on the upper-level screen may in reality already be inside the intersection.

(4) Different meanings of actions and errors

VDA 5050 defines predefined actions such as pick, drop and startCharging, but where these do not fit, manufacturers can define their own actions. Error levels are also fixed, but the types and content of errors depend on the manufacturer’s implementation. To reach a state where “things with the same meaning look the same” on the upper-level screen, you need a mapping table.

(5) Multiple entry points for transport orders

If transport orders originate from the WMS, MES, call buttons and people, and on top of that come through a separate entry point for each vendor, the same transport may be issued twice, or a cancellation may reach only one side. For forklift and transport call systems, “Forklift Call and Dispatch System: 30-Day PoC & RFP Guide” is also a useful reference.

Comparing four AGV fleet control architectures

Which of the five places is owned by whom determines the control approach. We compare four broad approaches.

Approach A: Standardize on one vendor

This is the simplest, and responsibility is also consolidated in one company. However, the cost of replacing existing vehicles, downtime during replacement and the risk of depending on one vendor vary greatly from plant to plant. If the time to replace old magnetic-tape AGVs is near, it is a strong option.

Approach B: Vendor-specific fleet managers + zone arbitration

Each vendor’s fleet manager is used as is, and a gate deciding “may it enter” for intersection zones and shared equipment is placed at the upper level. The upper level manages only zone availability and the sequence of entry, and leaves the choice of route to each vendor’s fleet manager. Because the connection method differs by vendor, whether through the vendor fleet manager’s API, stop and resume signals in front of the zone, or via the equipment-side PLC, custom interface development is needed for each vendor. With about two vendors and a few intersection zones, it is an approach that is easy to introduce.

Approach C: Integrate under AGV master control via a common interface

An upper-level control that supports VDA 5050 gives driving orders directly to each vendor’s vehicles. Several software companies and vehicle manufacturers offer products of this type. All of the following are vendor claims; examples of how they are described include:

• SYNAOS says on its website that it can centrally control AMRs, AGVs and forklifts in compliance with VDA 5050, without being tied to a manufacturer. In a case with the automotive technology company ZF, it is described as running vehicles from different hardware vendors in one system, with a plan to integrate 250 to 300 vehicles per year over the next 4 to 5 years (this is what the case article states, not a track record).
• Navitec Systems says of its fleet control “Navithor” that VDA 5050 allows vehicles from any vendor to be combined in the same fleet, and advertises integration with MES, WMS and ERP and with external systems such as elevators and door sensors.
• BlueBotics says its fleet management software ANT server supports VDA 5050 and can manage, in addition to customers’ AGVs/AMRs using its own technology, VDA 5050-compliant vehicles of other brands.
• KUKA says of its fleet management software “KUKA.AMR Fleet” that it can integrate AMRs from different manufacturers via VDA 5050 and can connect with doors and elevators, WMS, ERP/MES and PLCs.

Vehicle-side support also takes different forms. MiR (Mobile Industrial Robots) says it provides, through certified system integrators, the “MiR VDA 5050 Adapter,” which bridges its own REST API and MQTT and exchanges messages between MiR AMRs and third-party fleet management systems that support VDA 5050. This is a form in which the vehicle has a proprietary API and supports VDA 5050 through an adapter.

For any of these products, the supported VDA 5050 version (2.x or 3.0) is not necessarily clear from public information. When comparing products, confirm the version, the optional features available, the traffic management logic and integration with peripheral equipment through RFP responses and acceptance tests, not through vendor descriptions. This article does not recommend any specific product.

As an example of a Japanese manufacturer’s fleet control, Sharp says that its centralized AGV control system “AOS” offers dispatch control with automatic generation of shortest routes, deadlock avoidance, customized integration with elevators, automatic doors, conveyors and MES, WMS and PLCs, and coexistence with AGVs and transport vehicles from other manufacturers (this is the company’s own account). Whether to keep such a vendor fleet manager as the “vendor-specific fleet manager” of approach B, or to consolidate on it as approach A, is also something to consider.

Approach D: Open-source middleware

Open-RMF is a set of libraries and tools built on ROS 2, with functional areas including a traffic schedule (traffic coordination), fleet adapters (bridges to each vendor’s system), infrastructure adapters for doors, elevators and the like, and task dispatch. openTCS is Fraunhofer IML’s transport control software, and it is announced that its VDA 5050 communication adapter has been integrated into the main software (7.4 and later). However, which version of VDA 5050 the openTCS adapter supports could not be confirmed in the research for this article.

Open source costs nothing in license fees, but in exchange the question becomes who handles building it, maintaining it, keeping up with versions and taking responsibility when failures occur. Decide based on whether you can arrange, by contract, a maintenance setup that keeps the plant’s material flow from stopping.

How to choose

There are four decision axes: the number of vendors, the number of intersection zones and shared equipment, whether vendors will increase in future, and whether existing vehicles support a common interface. With two vendors and few intersection zones, starting with approach B and considering approach C once a third vendor comes into view is a reasonable order. The basis for this order is put into numbers in the “model cost calculation” section later.

Deciding the scope of standardization: maps and coordinate systems, nodes and edges, actions, errors, charging, factsheet

Whether you choose approach C or do only zone arbitration in approach B, first decide “what to align and how far.” Using the provisions of VDA 5050 as a guide, we look at six items.

Maps and coordinate systems

In VDA 5050, to ensure consistent driving across different types of mobile robots, positions are always expressed in a “project-specific coordinate system.” A unique mapId is used to distinguish floors and the like; the map coordinate system is right-handed with the z axis pointing up, positive rotation is counterclockwise, X, Y and Z are in meters, and orientation is in radians. Each floor has its own map, but all maps use the same project-specific global origin. When changing floors by elevator, the vehicle is described as disappearing from the departure floor’s map and appearing at the lift node on the arrival floor’s map.

Map distribution is also specified. Map files are placed on a map server the vehicles can access, and the upper-level control instructs them to fetch it with the instant action downloadMap. Maps are identified by the pair of mapId and mapVersion, and if a vehicle does not have the map with the mapId included in an order, it reports “UNKNOWN_MAP_ID.” And ensuring that the correct map is active is the responsibility of the upper-level control. On the other hand, the format of the map file itself is not unified by the standard.

For common coordinates, MassRobotics 1.0 shows a method in which physical landmarks in the facility (such as pillars) are defined as “Datum Reference Points,” at least two (three or more recommended), and each vendor measures the same points on its own map and transforms coordinates. When aligning with VDA 5050, this idea can also be used in acceptance testing: measure the same physical points on each vendor’s map and check that they match the coordinates in the upper-level control.

What to decide: the common origin and axis orientation, how mapIds are assigned per floor, and who updates maps, how mapVersion is incremented, and in what order maps are distributed to vehicles. A layout change becomes a map version change, so involving the fleet control staff from the layout design stage reduces rework. Layout thinking is covered in “AGV Layout Design 2026 – Fleet Size Is Not Set by Throughput.”

Nodes and edges

A VDA 5050 driving order is part of a graph of nodes and edges. The upper-level control holds the full graph; constraints such as which vehicles may use which edges are not sent to the vehicle, and the fleet control includes in the order only “the edges that vehicle may use.” The released section (base) and the planned section not yet released (horizon) can be sent separately.

What to decide here is how to place nodes in front of intersection zones and how far to release at once. This relates to the “communication loss” test later: even if the vehicle loses its connection to the upper-level control, it executes the order up to the last released node. If you release all the way into an intersection zone at once, the vehicle may enter the zone when communication is lost.

For importing routes, the VDMA’s LIF (Layout Interchange Format) can be used, or the operator may configure them manually. However, it is stated explicitly that “configuration of routes and route networks is outside the scope of this document.”

Actions

Predefined actions (pick, drop, startCharging, stopCharging, initializePosition, downloadMap, enableMap, factsheetRequest, waitForTrigger, etc.) are used when the vehicle’s capability matches the description. Three of them, cancelOrder, startPause and stopPause, must be supported by every mobile robot. Where these do not fit, the vehicle manufacturer can define additional actions.

Therefore, differences in the action vocabulary between vendors do not disappear through the standard alone. List the actions used in the plant (load, unload, wait, charge, hand over with a conveyor, etc.) and have each vendor answer in the RFP which predefined action, or which custom action, it uses to achieve each. For handover specifications with conveyors, “Conveyor-Top AMR Integration: Interface and 90-Day PoC” is also a useful reference.

Errors and states

VDA 5050 3.0.0 has four error levels.

At every level, the vehicle must not delete its order because of an error. The levels are aligned, but the types and wording of errors depend on the manufacturer’s implementation. Have each vendor submit its error list, and create a mapping table to the plant’s responses (whom to notify, reassignment, human intervention).

Status is sent on a single topic, when a relevant event occurs or at least every 30 seconds. There are seven operating modes: AUTOMATIC, SEMIAUTOMATIC, INTERVENED, MANUAL, STARTUP, SERVICE and TEACH_IN, and the fleet control controls the vehicle only in AUTOMATIC and SEMIAUTOMATIC. In MANUAL, SERVICE and TEACH_IN, the fleet control must not send orders or actions, and when the vehicle enters these modes it deletes its current order. Also decide how the upper-level control and the WMS handle that transport when maintenance staff switch a vehicle to manual.

Charging

Energy management (charging orders can interrupt transport orders) is listed as a function of the upper-level control, and the actions include startCharging and stopCharging. On the other hand, the chargers themselves may be dedicated per vendor. What to decide: whether to separate chargers by vendor or share them, at what charge level and on whose judgment vehicles are sent to charge, and the order when vehicles from two vendors run low on battery at the same time.

Specifications (factsheet)

The factsheet is basic information on a vehicle type series, used both as a human-readable document and as machine-processable JSON imported by the fleet control. Its items include the vehicle type and capabilities, physical characteristics, upper limits for identifier and array lengths, supported optional parameters and actions, vehicle geometry, load specifications, and software and hardware versions. Anything not listed among the supported optional parameters is to be regarded as “not supported.” In 3.0.0, the factsheet also announces which zone types each vehicle can understand (because some vehicles cannot process zones, or can process only some of them).

One way to use the factsheet is to have each vendor submit it at the RFP stage and to check it against the one obtained from the actual vehicle at acceptance. If the maximum speed, payload, available actions or software version differ between the documents and the actual vehicle, the upper-level control will issue orders based on wrong assumptions.

AGV WMS integration and links with MES and equipment: one entry point for transport orders

VDA 5050 treats interfaces with peripheral equipment, infrastructure devices and external IT systems as outside its scope. “Communication with peripheral systems such as doors, gates and elevators” is listed as a function of the upper-level control, but how to connect them is outside the standard. In other words, both integration with the WMS and MES and integration with doors, elevators and conveyors require specifications to be written for each project.

Transport orders from the WMS and MES

At a plant with vehicles from multiple vendors, the first thing to decide is to “have one entry point for transport orders.” The WMS or MES, without knowing which vendor’s vehicle will carry the load, issues only transport requests: “this load, from here to there, by this time.” The fleet control decides which vehicle to assign. With this setup, modifications on the WMS side do not increase as vendors are added.

With approach C, the upper-level control becomes the entry point for transport orders. With approach B, a layer that distributes transport requests to each vendor’s fleet manager is needed separately from the upper-level zone arbitration. Either way, what you need to decide is the same.

• The unit and identifier of a transport request (can the same request be recognized if it arrives twice)
• Handling of cancellations and changes (where, and by whom, a cancellation is received after the vehicle has started moving)
• Reporting of completion and failure (do inventory movements in the WMS stay in line with the actual movement of loads)
• Whether call buttons and human instructions go into the same entry point as WMS/MES requests or a separate one

Among the standard’s actions, cancelOrder is mandatory for all mobile robots. There is a means of cancellation from the upper level to the vehicle, but at what point a WMS cancellation is turned into a vehicle cancellation is something to decide in the project.

Doors, elevators and conveyors

The standard says that, at the deployment stage, loading and unloading locations, charging stations, the surrounding environment (gates, elevators, barriers), waiting positions, buffers and the like are defined within the route network. On top of that, specify the signal exchange with equipment (PLC signals or higher-level communication), interlock conditions (what confirms that a door is fully open, what confirms that the elevator car has landed), and where vehicles wait when equipment fails.

What matters especially with multiple vendors is to issue equipment calls from one place. If you connect signals to the equipment for each vendor, arbitration of the contention has to be built into the equipment, and every additional vendor requires equipment modifications. If the upper-level control (approach C) or zone arbitration (approach B) consolidates equipment calls so that, from the equipment’s point of view, “the caller is always a single party,” the equipment-side specification becomes simpler. Open-RMF having “infrastructure adapters” for doors and elevators among its components is close to this idea.

Requests, responses and timeouts

3.0.0 added a mechanism in which, when fleet control permission is needed, for example to enter a zone, the vehicle issues a request within its state and the fleet control returns “GRANTED,” “QUEUED,” “REJECTED” or “REVOKED” on the responses topic. Permissions can be given an expiry. If no response arrives in time, the vehicle behaves as if permission was not granted and does not perform that operation. The standard says that the handling of timeouts and retries is decided at integration, and the standard gives no numbers for how many seconds to wait or how many times to retry. Decide them in the project, together with the response times of the equipment.

Safety and division of responsibility: what lies outside the scope of VDA 5050

Supporting a communication standard does not guarantee safety

VDA 5050 states explicitly that it must not be regarded as, or applied as, a safety standard. MassRobotics 1.0 also says it must not be relied on for safety-related purposes. In other words, supporting either standard does not, on its own, guarantee safety. Each vehicle’s safety functions (slowing down and stopping by safety laser scanners, emergency stops, etc.) remain the design and responsibility of each vehicle manufacturer. Selecting and accepting safety laser scanners is covered in “Safety laser scanner selection for Thai factories: from site survey to acceptance.”

Related safety standards (to the extent confirmed)

R15.08 is a US standard, and we have not confirmed whether it is a legal obligation in Thailand. In addition, the texts of ISO 3691-4 and R15.08 are paid documents, and they are introduced here only to the extent of published summaries, press releases and reports. This article is not advice on obtaining certification or on legal compliance. Confirm the standards and procedures that should apply with a certification body or a specialist.

That R15.08 is divided into parts by role (manufacturer, integrator, user) offers a clue when thinking about the division of responsibility in a multi-vendor fleet: the safety of a single vehicle lies with the manufacturer, the safety of the integrated result with the integrator, and maintaining safety in operation with the user.

Who performs the risk assessment after integration

Within what we could confirm, we found no provision that directly decides who performs the risk assessment after vehicles from multiple vendors are run under one fleet control. VDA 5050 states explicitly that it does not allocate responsibilities among the operator, system integrator, vehicle manufacturer and fleet control provider. This is therefore something that must be decided by contract. At a minimum, write the following points into the contract and the RFP.

• Who performs, and who approves, the risk assessment of the whole system after integration
• Who redoes the assessment each time a vendor is added, the layout or maps are changed, or the upper-level control’s settings are changed
• Whether the settings of each vehicle’s safety functions (slowdown and stop ranges, etc.) may be changed for the convenience of the upper-level control, and who approves such changes

First-line failure isolation

In a multi-vendor configuration, when a failure occurs it is not immediately clear “where the problem is”: the vehicle, the vendor’s fleet manager, the upper-level control, the broker, the wireless network, the equipment or the WMS. Decide the procedure for first-line isolation and document who looks at which logs and whom to contact. The vehicle status provided by the upper-level control (operating mode, errors, connection state) is the first material for isolation. Have each vendor answer at the RFP stage the time from receiving a failure report to responding, and how costs are handled when investigating together with the upper-level control company.

Network and cybersecurity: MQTT broker, wireless and access rights

VDA 5050 states explicitly that it does not specify the mechanisms, technologies or processes for communication security and data protection. It also says that “protocol security needs to be considered in the broker configuration, but is not covered in this guideline.” Below we separate what is written in the standard from general design cautions.

What is written in the standard

• Communication is assumed to run over wireless networks, and the effects of connection loss and message loss are to be taken into account
• MQTT 3.1.1 or later is used
• QoS is 0 (Best Effort) for order, instantActions, state and the like, and 1 (At Least Once) for connection
• The vehicle sets a “last will” when connecting to the broker, and on an unexpected disconnection “CONNECTION_BROKEN” is delivered on the connection topic. On a normal disconnection it sends “OFFLINE,” and on connection “ONLINE,” and these are sent with the retained flag
• Even if the vehicle is disconnected from the broker, it keeps the orders it has received and executes them up to the last released node
• With a cloud MQTT broker, the topic structure may need to be adjusted
• In 3.0.0, the instant action updateCertificate for updating the vehicle’s certificate was added

QoS 0 is a setting that assumes some messages may not arrive. How the vehicle and the upper-level control behave if a driving order does not arrive is something to check in acceptance testing.

General design cautions

The following are not provisions of the standard but general design considerations.

• Broker location: whether to place it inside the plant’s control network or in the cloud. If in the cloud, consider whether a loss of the internet line would stop the plant’s material flow
• Authentication and authorization: separate credentials per vehicle and narrow permissions so that each vehicle can read and write only its own topics. Make sure that nothing other than the upper-level control can issue order or instantActions
• Certificate renewal: decide who manages certificate expiry and the renewal procedure
• Wireless: check with actual vehicles whether there are places along the whole transport route where wireless coverage drops, and whether communication drops when roaming switches access points
• Remote maintenance: who authorizes and records the paths by which each vendor accesses vehicles and fleet managers remotely

How to set cybersecurity requirements for FA system integrators is covered in “FA System Integrator Cybersecurity — Thailand RFP and Acceptance Evidence Guide 2026.” Decide specific values (password length, renewal intervals, etc.) in line with your own information security policy.

Model cost calculation: comparing 5-year totals for approaches B and C by number of vendors (placeholder figures)

From here, using a model plant to show the structure of the calculation, we compare the 5-year totals of approach B (vendor-specific fleet managers + zone arbitration) and approach C (integration under upper-level control via a common interface). All amounts below are placeholders set for this article. They are neither vendor prices nor survey figures. Replace them with your own quotations when using them.

Model plant assumptions

Assume one site of a Japanese manufacturer in Thailand that has introduced AGVs/AMRs from several vendors and has intersection zones and shared equipment. The currency is Thai baht (THB) and the period is 5 years. Let V be the number of vehicle vendors.

Approach B has small fixed costs and large per-vendor costs. Approach C is the opposite, with large fixed costs and small per-vendor costs. From the formulas, each additional vendor increases the 5-year total by 1,000,000 THB under approach B and by 250,000 THB under approach C.

Which is cheaper as the number of vendors changes

The break-even point follows from 300,000 + 1,000,000V = 2,500,000 + 250,000V, giving 750,000V = 2,200,000 and V ≈ 2.93. Under these placeholder assumptions, the 5-year totals of approaches B and C reverse at around the point where a third vendor is added. With 2 vendors approach B is 700,000 THB cheaper; with 3 vendors they are about the same (approach C is 50,000 THB cheaper); with 4 vendors approach C is 800,000 THB cheaper, and with 5 vendors 1,550,000 THB cheaper.

Approach A (standardize on one vendor) is not given an amount. The cost of replacing existing vehicles, the downtime during replacement and the risk of depending on one vendor differ too much from plant to plant.

What this calculation does not include

• Increases in transport volume, or a reduction in the number of vehicles needed, from less waiting at intersection zones (because these vary greatly with each plant’s flow lines)
• Modification or adapter costs when existing vehicles do not support a common interface
• The possibility that optimization built into a vendor’s own fleet manager (functions that get the most out of the vehicle’s performance) cannot be used under the upper-level control
• Increases or decreases in the time spent isolating failures

The first item in particular tends to favor approach C. Approach B only handles zone exclusion and does not optimize traffic, so some waiting at intersection zones remains. Conversely, the third item works against approach C. Neither is given an amount, so do not decide on the differences in the tables above alone; set these four items side by side qualitatively when judging.

What the calculation tells us

From these placeholder assumptions, the following order can be derived: with up to two vendors, start with approach B (zone arbitration), and consider approach C once adding a third vendor comes into view. However, even if a third vendor is not confirmed, we recommend that you require support for a common interface (and its version) in the RFP for any vehicles you buy from now on. If you do, the cost of modifying existing vehicles or adding adapters will be lower when you later move to approach C (this effect is not given an amount). How to think about the cost of the AGVs and AMRs themselves is covered in “AGV and AMR Cost: A Five-Year TCO Guide for Thai Factories.”

What to write in an RFP for an AGV fleet management system

In the RFP, asking “do you support VDA 5050” is not enough. Structure it so that you fill in the six items the standard does not cover yourselves. Have the upper-level control company, each vehicle manufacturer and the system integrator each answer the same items.

Item 3, “supported version,” is especially important. The major version number is part of the topic hierarchy, and a change of major version usually contains changes that are not backward compatible. Whether a combination of vehicles and fleet control on different versions actually works cannot be said from the standard; it is something to confirm for each product. Hold off evaluating any answer that just says “VDA 5050 supported” until the version is known.

What to check in PoC and FAT/SAT: acceptance tests that deliberately break things

In the PoC and acceptance tests, check not only whether vehicles run when everything is normal, but also whether, when you deliberately cause an abnormality, the vehicles stop on the safe side, their status is shown correctly at the upper level, they can recover as documented, and the cause can be traced in the logs. Since the standard states explicitly that it does not cover “verification and acceptance procedures,” you have no choice but to decide the content of the tests yourselves. Split them into tests in the vendor’s or system integrator’s environment (FAT) and tests at your own plant connected to the actual wireless network, equipment and WMS (SAT).

Seven cases to test deliberately

1. Two vendors entering an intersection zone at the same time: run vehicles from two vendors so that they arrive at the same intersection zone at the same time. Does only one enter while the other waits at a set position in front? Does it avoid a deadlock?
2. Communication loss between the upper-level control and a vehicle: create a gap in wireless coverage or stop an access point. Because the vehicle executes the order up to the last released node, check that the release does not extend into the intersection zone. Does “CONNECTION_BROKEN” appear on the upper-level screen?
3. Restarting the broker (or the upper-level control server): restart it during operation. After reconnection, does the vehicle’s status return correctly to the upper level (status is sent at least every 30 seconds), and are no duplicate orders issued?
4. Mismatch between the factsheet and the actual vehicle: do the maximum speed, payload and available actions in the documents match the factsheet obtained from the actual vehicle? If some items do not match, does the upper-level control avoid issuing wrong orders?
5. Reconnection after a software (firmware) update from one vendor: update the software of one vendor’s vehicles and have them reconnect. Is the version information in the factsheet updated? Has the handling of actions, errors and zones stayed unchanged?
6. Contention for chargers: bring vehicles from two vendors to low battery (equivalent to URGENT) at the same time. Is the charging order as decided? Does interruption of transport orders work correctly?
7. Duplicate and cancelled transport orders from the upper level (WMS/MES): send the same transport request twice, and cancel one while the vehicle is driving. Are the duplicates merged into one? Does the cancellation reach the vehicle, and do WMS inventory movements stay in line?

Five items to check

For each case, check the following five items.

If you create a table crossing the 7 cases with the 5 items and record a pass/fail result and evidence (screen recordings, logs, video) in each cell, FAT and SAT results become easier to compare. Not every case relates to every item with the same weight. For example, simultaneous entry into an intersection zone centers on “stop/wait is on the safe side,” while reconnection after a software update centers on “status is shown correctly at the upper level” and “cause can be traced in the logs.”

Dividing work between FAT and SAT

In FAT, run through the 7 cases at the test site and check the items of orders, status, errors and logs for the combination of the upper-level control and each vendor’s vehicles. In SAT, run the same cases at your own plant, connected to the actual wireless network, doors, elevators, chargers and WMS. Communication loss and gaps in wireless coverage can only be checked in the plant’s actual environment. Coordinate agreement is also checked by measuring the same physical points in the plant on each vendor’s map.

The standard gives no numbers for timeout seconds, the number of retries, or how far it is acceptable to release when communication is lost. Decide them based on the FAT results, confirm them in SAT, and record the decided values in documents. After go-live, too, run retests centered on cases 4 and 5 each time there is a vendor software update or a map change. For how to proceed with AMR introduction in existing plants, “AMR Implementation Case Studies for Brownfield Factories: A 90-Day PoC” is also a useful reference.

Frequently asked questions

What is VDA 5050?

It is a communication interface between the upper-level control (fleet control) and mobile robots (AGVs/AMRs), created jointly by Germany’s VDA and VDMA. The current version is 3.0.0, published in March 2026; it uses MQTT and JSON and defines formats for driving orders, status, errors, actions, map distribution, vehicle specifications (factsheet) and more. Its use is voluntary and non-binding.

If they support VDA 5050, will AMRs from different vendors simply run together?

Not necessarily. What VDA 5050 aligns is the “way of talking” between the fleet control and the vehicles. The standard itself states explicitly that it does not cover safety requirements, traffic management logic, interfaces with peripheral equipment and higher-level IT, acceptance procedures, the allocation of responsibilities, or cybersecurity. In addition, vendor differences may remain in custom actions, supported optional items, map file formats and supported versions. Integration of maps and coordinate systems, mapping tables for actions and errors, and acceptance testing need to be done separately.

How much does an AGV fleet management system cost?

Because it varies greatly by product and configuration, we cannot give a general market price. In this article’s model calculation (placeholders), the 5-year totals were 2,300,000 THB with 2 vendors and 3,300,000 THB with 3 vendors for approach B (vendor-specific fleet managers + zone arbitration), and 3,000,000 THB with 2 vendors and 3,250,000 THB with 3 vendors for approach C (integration under upper-level control); the break-even point was V ≈ 2.93, meaning the two reversed around the third vendor. Apply the same formulas to your own quotations.

What if our existing AGVs do not support VDA 5050?

There are several options: use an adapter if the manufacturer provides one (for example, MiR says it provides a VDA 5050 adapter for its AMRs); keep the existing vehicles on their vendor’s fleet manager as approach B and handle only intersection zone exclusion at the upper level; connect them through a mechanism such as Open-RMF’s fleet adapters; or replace them in line with their replacement timing. Whichever method you use, check the supported version and the range of functions available. Requiring support and the version in the RFP for vehicles you buy from now on widens your options later.

Where should AGV WMS integration connect?

VDA 5050 treats interfaces with external IT systems such as the WMS as outside its scope, so how to connect them is decided in the project. With multiple vendors, if the WMS and MES issue only transport requests without regard to the vendor, and the upper-level control (or a distribution layer) serves as the entry point for transport orders, modifications on the WMS side are less likely to increase as vendors are added. Always check the handling of duplicates and cancellations in acceptance testing.

Summary

When running AGVs/AMRs from different vendors in the same plant, the first question to ask is not “does it support VDA 5050.” It is three things: (1) who owns the arbitration of intersection zones and shared equipment, (2) how far to align maps and coordinate systems, actions and the meaning of errors, and (3) how to divide responsibility for safety and failures. VDA 5050, at 3.0.0 published in March 2026, aligns the way of talking between the upper-level control and the vehicles, but states explicitly that it does not cover safety requirements, traffic management logic, interfaces with peripheral equipment and higher-level IT, acceptance procedures, the allocation of responsibilities, or cybersecurity. Filling these in through the RFP and acceptance testing is the job of the party introducing the system.

The process has five steps: transport inventory, choosing the control approach, deciding the scope of standardization, integrating higher-level systems and equipment, and dividing responsibility and acceptance testing. In the model calculation (placeholders), the 5-year totals of approaches B and C were 2,300,000 THB and 3,000,000 THB with 2 vendors, 3,300,000 THB and 3,250,000 THB with 3 vendors, 4,300,000 THB and 3,500,000 THB with 4 vendors, and 5,300,000 THB and 3,750,000 THB with 5 vendors, reversing at V ≈ 2.93, that is, around the point where a third vendor is added. Start with zone arbitration for up to two vendors, and consider integration under upper-level control once a third vendor comes into view. On top of that, require support for a common interface and its version in the RFP for vehicles you buy from now on. Deciding in this order makes it clear what to buy and what you need to decide yourselves.

TOMAS TECH helps Japanese-affiliated plants in Thailand automate material transport and integrate AGVs and AMRs with higher-level systems. You can consult us even before the product or approach has been decided, for example at the stage of taking a transport inventory or deciding which control approach to use. Please contact us through this form.

References

• VDA5050/VDA5050: Release VDA 5050 3.0.0 (GitHub)
• VDA5050/VDA5050: Releases (GitHub)
• VDA5050/VDA5050: README (GitHub)
• VDA5050/VDA5050: VDA5050_EN.md (v3.0.0, main branch)
• VDA5050/VDA5050: VDA5050_EN.md (v2.1.0 tag)
• Verband der Automobilindustrie (VDA): VDA 5050
• idealworks: VDA 5050 3.0.0 release (March 2026)
• MassRobotics: Mass Robotics Interoperability Standard – Version 1.0 (GitHub)
• Open-RMF
• Open Robotics: Programming Multiple Robots with ROS 2 — Introduction
• openTCS: opentcs-commadapter-vda5050 (GitHub)
• Swedish Institute for Standards (SIS): SS-EN ISO 3691-4:2023
• Association for Advancing Automation (A3): ANSI/A3 R15.08-2 Safety Standard for Industrial Mobile Robot Systems and Applications Now Available (October 9, 2023)
• Robotics & Automation News: Industry body A3 releases final part of safety standard for industrial mobile robots (October 2, 2026)
• Robotics 24/7: A3 announces R15.08 Part 3 safety standard for industrial mobile robot users is now available (October 4, 2026)
• Fraunhofer IML: Saying Goodbye to Communication Problems (discover logistics 25, 2024)
• SYNAOS
• IoT Use Case: Steering heterogeneous AGV fleets vendor-neutrally via VDA 5050 (August 25, 2026)
• Navitec Systems: Universal Fleet Control – Navithor
• BlueBotics: VDA 5050 Explained – An Overview of the Evolving AGV Communication Standard (updated April 2026)
• Mobile Industrial Robots: MiR Supports interoperability with new VDA5050 Adapter (March 11, 2025)
• KUKA: KUKA.AMR Fleet
• Sharp: AGV Operating System (AOS) (in Japanese)
• International Federation of Robotics (IFR): Global Sales of Professional Service Robots Surge 24% (September 30, 2026)
• Tilleke & Gibbins: Thailand Unveils New Incentives for Automotive and HEV/PHEV Manufacturing (April 21, 2026)
• American Journal of Transportation (AJOT): BlueBotics and Planet T & S enter into distribution agreement to grow Thai AGV market (October 4, 2021)