The need for multi-fleet orchestration is growing in popularity with more and more vendors looking to enter this space. How many multi-fleet autonomous mobile robot (AMR) deployments have there actually been and how big will this market eventually grow?
What’s the point of multi-fleet AMR orchestration?
Growing at a forecast CAGR of 138% between 2021-2027, the development of multi-fleet orchestration platforms sometimes referred to as third-party fleet management solutions has largely mirrored the developments of the warehouse control software (WCS) segment. In the early days of fixed automation, there was a large number of “islands of automation” where a particular workflow or task was automated. For example, pick-to-light systems or unit-load automated storage retrieval systems (AS/RS).
Problems arose when warehouses started to use multiple types of fixed automation together. This led to the warehouse management system (WMS) having to communicate tasks to multiple sub-systems, resulting in inefficiencies as the sub-systems weren’t communicating with one another. As a result, the development of WCS solutions could interface with multiple types of fixed automation technology, allowing for a level of orchestration across different sub-systems.
Multiple types of mobile robot systems are being used for different workflows. In many cases, manufacturers will develop AMRs for specific workflows. Orchestrating multiple fleets of AMRs from different manufacturers requires a third-party fleet management solution (FMS), sometimes referred to as a multi-fleet orchestration platform. Customers could simply integrate AMRs from different vendors into their warehouses as distinct and independent automation “blocks,” but that inherently leads to efficiency losses and other challenges when the AMRs are not able to directly communicate with each other.
Approaches to multi-fleet orchestration
There are two main approaches to multi-fleet orchestration. The most common today is to directly interface with the mobile robots (referred to as “low-level control”), allowing the third-party fleet management system to “take control” of the bots. The second approach is to have a third-party fleet management system feed tasks to the proprietary fleet management systems of each robot manufacturer referred to as “high level control”. In other words, a fleet manager controlling a fleet manager.
The first approach of controlling the mobile robots directly works well for point-to-point material transport where the mobile robots have a lot of on-board software and navigation capabilities. Companies rely heavily on low-level control. It becomes more difficult when dealing with a complex swarm of bots, such as sortation or goods-to-person AMRs. Where the proprietary algorithms used to control the bots include order management and slotting capabilities to optimize throughput. In many cases, a third-party fleet management system would struggle to do a better job than the proprietary software.
This leads to the second approach where a third-party fleet manager would “control” various proprietary fleet managers. The benefit of this approach is that if you have an existing fleet of AMRs or AGVs, you don’t need to re-integrate the fleet management system, which can be costly. Furthermore, having a third-party fleet management system integrate directly with a fleet of mobile robots can be more expensive than having a third-party fleet manager control the proprietary fleet manager.
In reality, most platforms are able to provide both high-level control and low-level control, although their preference may be skewed toward a certain approach.
There are two main approaches to multi-fleet orchestration. Either integrate directly with the mobile robots which is low-level control or have a third-party fleet manager control the proprietary fleet managers of the mobile robots which is high level control.
Whilst the first approach of providing low-level control seems logical, there are several costs associated with integrating third-party fleet management systems, especially if the AMR doesn’t have an open API interface. Interoperability will likely have a commoditizing impact on the mobile robot hardware market. The robots themselves tend to be fairly standardized in terms of hardware and it’s the software that’s often the key IP for mobile robot vendors. To avoid commoditization, many mobile robot vendors have made it difficult for third-party fleet management systems to integrate their software with the robots by having proprietary APIs.
There are two main approaches to tackle the issues around interoperability:
1) creating a standard communication protocol such as VDA505 between mobile robots mainly AGVs and fleet management systems.
2) developing middleware to sit between the fleet management system and the robots acting as a Google Translate of sorts.
There are several companies looking to tap into the second category. Providing a middleware solution to allow for easier and quicker integrations between robots and third-party applications, like fleet management systems.
The jury is still out on whether high-level control or low-level control will be used long-term to facilitate the orchestration of multiple fleets of mobile robots. The pathway to interoperability may also be driven by common standards or middleware, facilitating the communication between AMRs and AGVs. What is for certain, is to expect to see a growing number of multi-fleet deployments as the market shifts from point solutions to end-to-end mobile automation.