Understanding Fleet Management in AGV Robot Systems (RCS-2000)

When several warehouse robots share a narrow aisle, a forklift robot may be ready to deliver a pallet while a tote-handling robot is approaching the same crossing. Both machines may know how to navigate, but someone still needs to decide which task runs first, which route is available and what the operator should see if the destination is blocked. This is the job of fleet management.

RCS-2000 is presented on Wesar’s website as a centralized robot control system for task assignment, AMR scheduling and route planning. The customer-supplied RCS-2000 V4.2 technical introduction describes the task-flow, traffic, charging and monitoring functions behind that role. Which features and interfaces are available in a particular installation should be confirmed against the deployed version and project scope.

1. Where Fleet Management Fits in the System

A warehouse management system (WMS) manages inventory and warehouse business processes; production or enterprise systems may issue replenishment requests. A robot control system translates transport requirements into executable robot tasks and coordinates how vehicles move. This separation is useful, but the precise boundary between systems varies by project.

Весар RCS-2000 product page describes order processing downstream of an order system, communication with site equipment such as doors and elevators, and exception monitoring for robot operations. That is a control-layer description, not a claim that RCS replaces the entire WMS or MES.

A good system review follows one request from its business trigger to pickup, delivery and completion feedback. It should identify who owns the destination, who confirms it is available, and who resolves the exception when the expected response does not arrive.

2. How RCS Assigns Tasks Across a Fleet

Dispatch is more complicated than sending a request to the physically closest robot. The V4.2 introduction describes an assignment algorithm that considers global conveying distance and the balance of task loads at destinations, with dynamic adjustments while work is executing. Those are relevant inputs when several robots can perform the same movement.

Consider three replenishment calls from the same warehouse zone. A distance-only choice might overload one delivery station or send vehicles toward the same crossing simultaneously. Fleet control should evaluate the wider task queue and the state of destinations. For a project test, provide a cluster of real requests and ask the integrator to show which robots are selected, what happens to queued work and how priorities are applied.

3. Coordinating Different Robot Types and Shared Routes

Mixed fleets can include forklifts that lift pallets, lifting LMRs that move carriers from below and CTUs that handle totes. Wesar lists these as distinct vehicle families, including forklift mobile robots (FMR) и carton transfer units (CTU). Fleet management has to allocate jobs and coordinate shared paths while respecting the handling role of each vehicle.

The V4.2 technical material describes path planning for robots with different navigation modes, congestion anticipation and deadlock prevention. It also describes intersection control where multiple vendors share routes. Its discussion of VDA5050 is conditional: third-party robot support depends on the actual implementation, protocol version and approved interfaces, not simply on the presence of the acronym in a brochure.

At the site, mark narrow aisles, intersections, elevators and transfer stations on one map. Ask how routes are reserved or released, what happens when a vehicle stops, and how pedestrian access is managed. Software traffic coordination does not replace a separate physical safety review.

4. Configuring Task Flows for Real Warehouse Work

A replenishment request may include more than a drive command. It can require confirming that a pickup station is ready, allocating a suitable carrier, checking a delivery point, opening a door and sending a completion signal. The V4.2 introduction describes using preset logical nodes to organize such sequences into executable task flows; subflows can be reused for recurring operations.

The material also describes time-based task scheduling using start times, cycle counts and intervals. This is useful for predictable replenishment cycles, but the underlying business rule must come first: what should occur if production cancels a request or a station has not cleared its previous load? The answers need to be encoded and then tested.

5. Charging Policies Are Part of Fleet Scheduling

Battery management influences which vehicles are available when work arrives. The V4.2 technical introduction describes three operating levels: a no-charge level, an interruptible-charge level where charging can pause for tasks, and a must-charge level in which the robot does not accept new tasks. These are scheduling states, not universal battery-runtime specifications.

A shift plan should distinguish between short breaks, high-priority delivery periods and longer charging windows. Review battery thresholds and charger access with the actual robots and duty cycle. A fleet sized without its charging policy may appear sufficient in a spreadsheet but struggle during a sustained peak.

6. Managing Faults, Changed Destinations and Restarts

Exceptions are a normal part of plant logistics. The V4.2 material describes task reassignment when a robot cannot continue, destination changes initiated by an upper-level system, and recovery of stored task states and communication messages after an abnormal system restart.

These features require operational procedures. If a failed robot is carrying a pallet, another robot must not automatically assume that the physical load is available for pickup. If a destination is changed, the new location must be able to accept the carrier. After restart, operators should verify outstanding requests and any loads that remain in transit. The system description does not establish a guaranteed recovery time.

7. Monitoring the Fleet and Investigating Delays

A fleet is easier to manage when operators can see robot status, task progress and exceptions in one place. The V4.2 introduction shows an operations client and historical playback for robot routes and slot states. These tools can help answer practical questions: which robot was waiting, where did the route become blocked, and what task state preceded the stoppage?

Before acceptance, confirm what events are displayed, how alarms are assigned to staff, whether permissions are role-based and how long recordings or logs will be kept. The existence of a playback function in reference material does not by itself establish a specific retention period or completed site configuration.

8. Connecting RCS to Warehouse and Plant Equipment

The supplied technical document identifies interfaces for host systems and a device-access service. It lists examples such as REST, TCP, Modbus and OPC UA, along with equipment including elevators, doors, conveyors and robotic arms. These indicate possible integration routes, not a guarantee that every device supports a direct connection without engineering work.

For comparison, a warehouse using a lifting carrier robot such as Wesar’s Q2-400D LMR may need different pickup confirmations from a forklift model at an elevated rack. The integrator should define signal ownership, acknowledgement timing, failure behavior and the checks needed for each real device.

9. What to Demonstrate Before Commissioning

A useful acceptance test should follow one representative request across the whole system and then deliberately introduce the exceptions that staff will face during an ordinary week.

Shared aisle conflicts: show task priority, route coordination and the operator view.

Occupied destinations: demonstrate the wait state, alert and approved destination change.

Robot failure with a load: verify physical-load status, task ownership and the reassignment procedure.

System restart: compare stored task states, messages and final completion status.

Peak-period charging: check charging priorities and resulting fleet availability.

Unavailable device signal: verify the hold condition, alarm and responsible responder.

Record the expected behavior, the actual result and which party owns any corrective action. This turns fleet management from a broad software claim into a set of demonstrable operating capabilities.

Заключение

AGV fleet management coordinates the work that individual vehicles cannot resolve alone: choosing the next task, managing shared routes, organizing multi-step workflows, controlling charging availability, responding to exceptions and presenting operational evidence. RCS-2000 provides a framework for these activities; a successful installation still depends on the actual robots, business rules, device interfaces and site acceptance tests.

Часто задаваемые вопросы

Is an AGV fleet-management system the same as a WMS?

No. A WMS manages warehouse business data and transactions, while robot control coordinates transport execution. Their responsibilities and the signals exchanged between them must be defined for the project.

Can RCS-2000 coordinate more than one type of robot?

The product and V4.2 material describe mixed robot operation. Compatibility depends on the selected vehicles, navigation methods, installed software version and interfaces; it should be verified rather than assumed for all brands.

What happens if a robot stops during an active task?

The V4.2 introduction describes task reassignment and recovery options. The site procedure must also account for any load held by the stopped robot and confirm the correct task state before another vehicle resumes work.