AGV Fleet Management System: What Happens When One AGV Becomes a Fleet?

Running a single AGV on a point-to-point transport task is relatively straightforward.

It receives a task, travels to the pickup point, moves the load, and delivers it to the designated destination.

But when a factory is operating 10, 20, or even more AGVs and AMRs at the same time, the real challenge is no longer whether the robots can move. The challenge is coordinating the entire fleet.

• When 10 transport tasks are generated at the same time, which robot should handle each one?
• If two robots reach a narrow aisle at the same time, which one should go first?
• If an AGV is low on battery while a production line urgently needs replenishment, should it charge first or execute the task?
• If a station is occupied, should the next robot wait or be rerouted?
• How can logistics requests from MES or WMS be converted automatically into tasks that robots can execute?

These are exactly the kinds of problems an AGV Fleet Management System is designed to solve.

In many AGV/AMR projects, this software layer is also referred to as RCS (Robot Control System). Some vendors also use RSS (Robot Scheduling System) to describe software focused primarily on robot task scheduling.

What Is an AGV Fleet Management System?

An AGV Fleet Management System is the software layer between higher-level business systems and AGVs/AMRs. It manages tasks, robots, routes, traffic, and fleet status, and converts logistics requirements into transport tasks that robots can execute.

It does not physically move goods. Instead, it continuously makes decisions such as:

What tasks exist now? -> Which robot is the best fit? -> Which route should it take? -> Will it conflict with other robots? -> Has the task been completed?

For example, suppose a factory suddenly generates an urgent production-line replenishment request.

There are 12 robots on site, but their conditions are different:

• 3 are already executing tasks;
• 2 are charging;
• 1 has a fault;
• 2 are far from the pickup point;
• 4 are available for dispatch.

Instead of requiring an operator to check each vehicle manually, the RCS can evaluate robot location, battery level, vehicle type, task status, and current traffic conditions, then assign the most suitable robot.

An AGV Fleet Management System therefore manages a dynamically changing robot fleet, rather than simply sending a destination to each AGV.

What Changes When One AGV Becomes a Fleet?

Many coordination problems are barely noticeable when only one AGV is deployed.

With a single vehicle, the route may be fixed and the transport task simple enough to run with predefined logic. As the number of robots increases, however, fleet-management complexity grows rapidly.

Multiple Tasks Compete for the Same Robots

A manufacturing site may generate several types of logistics tasks at the same time:

• Production-line replenishment;
• WIP transfer;
• Raw-material delivery;
• Finished-goods transport;
• Empty-pallet return.

Some tasks can wait, while a production-line material shortage may need immediate attention. If there is no centralized task management, different departments may all consider their own requests the most urgent.

The RCS must therefore decide which task should be executed first, and which robot should execute it.

Multiple Robots Compete for the Same Routes

Robots do not operate on separate road networks. They often share:

• Intersections;
• Main aisles;
• Narrow aisles;
• Elevators;
• Automatic doors;
• Pickup and drop-off stations;
• Charging areas.

The shortest route for an individual robot is not always the most efficient route for the fleet as a whole. If five robots all choose the same shortest aisle, they may simply queue there.

This is why a multi-robot system needs not only navigation, but also fleet-level traffic management.

Robot Status Is Constantly Changing

A robot that was available five minutes ago may now be:

• Executing a task;
• Waiting for a load;
• Charging;
• Blocked by another vehicle;
• Waiting for an elevator;
• In an exception state.

Fleet management is therefore not a one-time dispatch decision. It continuously adjusts operating decisions as fleet conditions change.

What Does the RCS Actually Control?

Rather than treating RCS as a long checklist of software functions, it is easier to understand by looking at the questions the system has to answer for the fleet every day.

Which Robot? - Which Robot Should Execute the Task?

When a logistics request is generated, the system first has to select a robot.

It may consider:

• Distance from the pickup point;
• Current availability;
• Remaining battery level;
• Robot type;
• Rated payload;
• Current task;
• Task priority.

For example, a 1,500 kg pallet transport task should not be assigned to a robot designed to move a 600 kg material cart. Dispatching is therefore not simply about choosing the nearest robot, but the robot best suited to the task.

Which Route? - Which Route Should It Take?

The RCS plans a route based on the origin, destination, and site map.

In a real project, however, route selection may also need to consider:

• Current traffic conditions;
• One-way areas;
• Restricted zones;
• Temporary obstructions;
• Vehicle access limitations;
• The positions of other robots.

The shortest route and the fastest route are not always the same.

Who Goes First? - Which Robot Has Priority?

When two robots need to enter the same narrow aisle, they cannot simply rely on local obstacle avoidance to negotiate with each other.

The system needs to determine which robot currently has access to the shared resource.

This is the role of traffic management. At intersections, shared stations, elevators, and automatic doors, the RCS can use zone locking, right-of-way rules, and waiting logic to control the order in which robots enter.

When to Charge? - When Should a Robot Leave the Fleet to Charge?

If robots wait until their batteries are nearly depleted before charging, several vehicles may become unavailable at the same time.

The RCS may therefore schedule charging based on:

• Battery state of charge (SOC);
• Current task volume;
• Expected upcoming tasks;
• Charging-station occupancy;
• Robot idle time.

Some systems also use opportunity charging during lower-demand periods so that more robots remain available during peak operations.

What If Something Goes Wrong? - How Are Exceptions Handled?

Real factories do not operate in a perfect state all the time.

Common exceptions include:

• Pickup failure;
• Occupied station;
• Blocked route;
• AGV fault;
• Communication interruption;
• Unavailable elevator;
• Load not ready.

The RCS needs to determine whether it should wait, retry, reroute, assign another robot, reschedule the task, or request manual intervention. In practice, exception handling often determines whether a multi-robot system can run reliably in a real production environment, not just whether the robots can move during a demonstration.

How Does an AGV Fleet Management System Integrate with MES, WMS, and WCS?

One of the most important things to understand about RCS is that it does not replace MES, WMS, or WCS.

These systems operate at different levels and solve different problems.

A simplified system architecture can be viewed as:

ERP / MES / WMS↓What logistics action does the business require?↓RCS / AGV Fleet Management System↓Which robot should execute it, and how?↓AGV / AMR↓Physical material transport

At the same time, PLCs, conveyors, elevators, and automatic doors may interact with the robot workflow as peripheral equipment.

RCS and MES

MES is primarily concerned with production.

For example, Production Line A may need a new batch of components.

Production demand -> MES issues a logistics request -> RCS creates a robot task -> AGV completes delivery -> RCS returns task status

MES does not need to know which AGV currently has the highest battery level, nor does it need to determine which robot should pass through an intersection first. Those decisions belong to the RCS.

RCS and WMS

WMS is primarily concerned with inventory and warehouse operations.

For example, WMS may determine that Pallet A needs to move from Storage Location 01 to Shipping Station 05.

WMS is concerned with what needs to move, from where, and to where.

RCS is responsible for assigning a robot and coordinating the transport process.

This is one of the clearest ways to understand the boundary between WMS and RCS.

RCS and WCS

When AGVs exchange loads with conveyors, AS/RS, lifts, or other automated equipment, the RCS may need to coordinate with WCS.

AGV arrives at conveyor -> Confirm conveyor is ready -> Transfer the load -> Confirm handoff completion -> AGV departs

In a complex warehouse, mobile robots are only one execution layer within the broader automation system.

RCS and PLCs or Peripheral Equipment

Some equipment can interact with robots without going through MES or WMS.

Examples include:

• Automatic doors;
• Elevators;
• High-speed roll-up doors;
• Production-equipment PLCs;
• Charging stations;
• Traffic-signal equipment.

The RCS can trigger or coordinate these devices based on the active robot task.

For this reason, system integration is more accurate than simply saying system connection when describing these relationships.

API, OPC UA, TCP/IP, or PLC communication are specific technical methods used to implement that integration.

How Coolyne Integrates an AGV Fleet Management System into an Existing Factory

When a company deploys an AGV Fleet Management System, it usually does not need to replace its existing MES, WMS, or production-management software just to add RCS.

The key question is: how should the existing system pass logistics requirements to the RCS, and how should the RCS return execution results to the existing system?

Coolyne can define system responsibilities, data interfaces, and task flows based on the company's existing IT/OT architecture.

For example, a manufacturing project may follow this flow:

MES generates a production replenishment request↓RCS creates and dispatches a robot task↓AGV picks up the material and delivers it↓PLC / station confirms the handoff↓RCS returns task status to MES

For warehouses that already operate WMS or WCS, the existing warehouse logic can be retained while the RCS focuses on robot task execution and fleet coordination.

During implementation, the project typically needs to clarify:

• Which system generates each task;
• What data the RCS needs to receive;
• What robot status information the upper-level system needs;
• Which system decides the next action when a task fails;
• How PLCs, conveyors, elevators, and automatic doors should interact;
• How multiple robots share traffic resources;
• Whether fleet configuration needs to change when new robots are added.

For projects with multiple AGVs or AMRs, Coolyne can also evaluate fleet size and dispatching capacity based on actual task volume, task cycle time, routes, and peak demand.

If you already use MES, WMS, or another production-management system, the goal is usually not to rebuild the entire software architecture, but to make the AGV Fleet Management System a stable execution and scheduling layer between your existing business systems and the mobile robot fleet. Contact Coolyne to discuss RCS architecture, interface integration, and fleet configuration for your AGV/AMR project.