Few AGV and AMR producers have the resources required to develop a vehicle for every application. So, it is important to know how to make other brands work seamlessly with yours, in one connected fleet, if needed. Here we explore the three main ways to achieve this.
As more businesses look to deploy and expand fleets of automated guided vehicles (AGVs) and autonomous mobile robots (AMRs), the ability to run multiple vehicle brands–called interoperability–in one fleet is becoming increasingly important.
In this guide we explain:
There are several reasons why a customer might require multiple brands of AGV or AMR to work together. The two main drivers are:
Your customer might want to expand its automation program by automating more of its transport processes. However, your product portfolio might not include vehicles that suit these tasks.
As a result, your customer might be considering speaking with a second mobile robot supplier. If they do this and you are not involved in the process, this could be risky for your business, potentially affecting: your control of the project; your perceived importance to the customer, and the overall success of your client’s operation.
A customer might have some existing/legacy AGVs or AMRs in use, but is now looking to expand its automation program (or replace some of its existing fleet) by bringing in new brands of vehicles (such as your systems). Thus, the need for these two sets of systems to work together.
In addition, enterprise-level buyers such as large manufacturers with multiple production sites, are increasingly thinking ‘platform first, vehicles second’.
These organizations are looking to standardize their AGV and AMR operations around a single core technology, usually the fleet manager.
The goal in short: one fleet supervisor software, deployed across multiple sites globally, which can integrate pretty much any brand of AGV or AMR (whether the vehicle is existing or new) into any form of fleet the plant desires.
What is the exact pain that customers are looking to avoid?
Traditionally, each separate brand of AGV or AMR runs using its own dedicated fleet management software. This might be a fleet manager provided by the navigation supplier (such as BlueBotics, Navitec Systems, or Kollmorgen), or it could be a fleet manager that you—the vehicle OEM—have developed yourself.
The problem is: different brand fleet have not traditionally been capable of natively communicating with each other.
For customers looking to deploy or scale up larger fleets, and who therefore increasingly require multiple types of vehicles from different vendors, this lack of fleet manager communication can vastly complicate operations.
There are several reasons for this:
Since vehicles cannot share the same virtual routes, they often need to run on different paths around a site, which requires more space. This is often an issue on space-restricted brownfield sites.
Interoperability promises to overcome these challenges—so for customers thinking "platform first", managing multiple disconnected fleet managers is simply becoming harder to justify.
So, what are the different ways of achieving true vehicle interoperability? And, crucially, which approach makes the most sense for you, as a vehicle maker, to adopt?
Today there are three main methods of achieving AGV/AMR interoperability within a single connected fleet:
Let’s explore each of these three approaches in more depth.
An interlock is a programmed link between two different fleet managers that enables AGV/AMR traffic to smoothly handle shared areas, such as crossings and particular sections of routes.
For every shared space, the different fleet managers concerned effectively ‘talk’ to each other to decide which vehicle has the right of way.
Interlocks act as virtual traffic lights. They connect two different systems with a virtual 'handshake'.
Take this example: AGV brand A is already installed on-site and a customer now wants to add a second brand of vehicle to the operation. As the integrator, you would identify the sections in question and program a ‘handshake’ between the fleet managers at these locations.
In operation, a vehicle that is about to enter a shared section will notify any oncoming vehicle – via the programmed fleet manager interface – that it is coming, and block the shared path; the equivalent of a traffic light turning red to allow crossing traffic to pass. When the first vehicle clears the area, it will then unblock the path and the waiting vehicle will be notified; the equivalent of the traffic light turning green.
There are two key issues with the interlock approach:
Various organizations are currently coming to market with fleet management-level communication standards. These are designed to make it easy for different brands of AGV and AMR to work together.
The most advanced standard to date is VDA 5050, which is driven by the German automotive industry in collaboration with VDMA Materials Handling and Intralogistics Association. This standard aims to enable compliant robots to work seamlessly together in one multi-brand fleet.
Newer still is the MassRobotics standard from the U.S. This focuses more on communication between AMRs themselves than their operations. There is also a Chinese standard in development, driven by the China Mobile Robot and AGV Industry Alliance (CMR), and the Open RMF interoperability standard out of California.
Even when fleet management standards are mature, they might not be the right approach for every customer. To reach the broadest number of potential users, the functionality offered by these standards is likely to be built around the lowest common denominator, which might compromise your vehicle’s speed and site efficiency, and therefore stand in the way of optimization.
More rarely discussed than even the need for ‘dialects’ is the tricky future support question.
If a customer has several AGV suppliers, and potentially a third-party fleet manager provider also, who will install and integrate what? Who will the customer call if and when something goes wrong?
If there is a vehicle deadlock and the AGV operation stops, what then? Is your team responsible?
Some more specific questions to consider:
Customers who are considering basing their mobile robot operations on an interoperability standard should consider these questions closely, and discuss them in-depth with potential suppliers, to guarantee the success of their installation and to minimize future risk.
BlueBotics’ fleet management software, called ANT server, offers advanced mission and fleet management functionality for vehicles driven by BlueBotics’ own ANT lite+ navigation technology.
The result? Over 120 models of different-brand AGVs and AMRs can be configured to work together seamlessly in a single fleet.
The functionality of ANT server covers, for example:
• Mission scheduling and management
• Traffic control
• Charging management
• Interfacing with on-site equipment (automatic doors, elevators etc.)
• Project simulation
• The ability to manage multi-floor installations
• Plus, a simple API for easy WMS/ERP/MES integration.
• Even outdoor operation and manual forklift tracking are possible.
Effectively, the ANT platform offers all the final-stage functionality that VDA 5050 and similar standards promise (and more), only this functionality is available immediately.
In addition, ANT server is also compatible with the VDA 5050 standard, which guarantees that companies can enjoy the best of both worlds: advanced multi-brand ANT driven fleets, with the potential for even wider expansion in future.
Watch a multi-brand ‘ANT driven’ fleet in action:
As the number of automated vehicles being deployed around the world continues to grow, and customers’ AGV/AMR projects become larger and more complex, it’s certain that vehicle interoperability will become more and more a requirement.
Vehicle makers will struggle to win projects if the interoperability box is not checked.
If only a few vehicles are involved, and if you have access to a project’s other fleet manager supplier(s), interlocks remain an inexpensive, reliable solution. However, projects involving several different vehicle models or brands will likely be larger, more complex, and therefore require more sophisticated management.
While mature interoperability standards will undoubtedly play a role in managing such complex installations, the goal of using these to manage such operations – at least without significant extra development and future compliance updates being required – remains several years away.
In the meantime, choosing to work with a natively interoperable fleet manager like ANT server–which is and will remain compliant with VDA 5050 and similar future standards–can be an effective way to achieve a high-functioning yet flexible fleet that can adapt to a customer’s evolving needs.
If you are developing or upgrading a mobile robot system and want to learn more about ANT server (or our full ANT navigation stack in general), our team is happy to chat. Just get in touch here to set up a no-obligation call.