For a Chinese AGV deployment in this environment, the problem is not simply whether the vehicle can navigate from point A to point B. The fleet system must coordinate physical zones, task permissions, inventory data, traffic rules, and unpredictable human activity without allowing one tenant's operations to interfere with another tenant's controlled area.
The exact implementation depends on the AGV supplier's fleet software and the warehouse's WMS architecture, but the following design principles are important when evaluating a system for a shared 3PL facility.
Restricted areas should be treated as a combination of physical access control and fleet-level traffic rules. A software map alone should not be considered a complete security barrier.
For example, a warehouse may contain:
Tenant A's dedicated pallet storage area.
Tenant B's high-value inventory zone.
A shared inbound staging area.
A shared outbound dock.
A temperature-controlled or special-handling area.
Manual-forklift-only corridors.
Maintenance and employee-only areas.
The fleet manager can typically represent these areas as different logical zones, routes, stations, or task destinations. The system may then apply different rules to each zone, such as allowing certain AGVs to enter while preventing other vehicles from receiving tasks there.
However, logical exclusion should not be confused with physical security. If entering a tenant's area could create a serious security or safety consequence, the warehouse may also need physical barriers, controlled doors, access systems, gates, safety scanners, or other site-level controls.
This distinction is particularly important in a multi-tenant 3PL because warehouse boundaries may change as customers move inventory or expand their leased areas.
Depending on the fleet platform, zone permissions can potentially be combined with time-based operating rules. For example, a shared aisle may be available to Tenant A during one operating window and reserved for Tenant B during another.
The important procurement question is not simply whether the software supports “zones.” Ask whether the system supports zone permissions, vehicle permissions, task permissions, scheduling rules, user roles, and audit logs, and whether these controls can be changed without modifying the core navigation system.
This is primarily a software architecture question rather than an AGV navigation question.
In a multi-tenant 3PL operation, the fleet system may know information such as task IDs, pallet locations, vehicle status, destination stations, timestamps, and movement history. Some of that information may originate from the WMS rather than the AGV itself.
A suitable architecture should define which system owns each type of data and which users are allowed to access it.
| Data Layer | Example Information | Important Control |
|---|---|---|
| Tenant Inventory | SKU, pallet ID, location, quantity | Tenant-level authorization |
| AGV Operations | Vehicle status, missions, alarms | Role-based access |
| Fleet Traffic | Routes, zones, traffic rules | Operator/admin permissions |
| Integration Data | WMS/API messages, task status | API authentication and authorization |
| Audit Data | User actions, changes, timestamps | Access and retention policy |
The buyer should not assume that a fleet manager is automatically a full multi-tenant platform simply because it has multiple user accounts. A basic role system may control who can log into the dashboard without actually isolating one customer's inventory records from another customer's records.
For a 3PL, ask the supplier to demonstrate the separation using representative test accounts. For example, a Tenant A user should only see the inventory and operational information that the business has authorized, while a system administrator may have broader visibility.
Can users be assigned different roles?
Can permissions be restricted by warehouse zone or customer?
Can APIs be restricted to specific functions or tenants?
Are user actions recorded in an audit log?
Can operational data be exported by tenant or customer?
How long are historical task and inventory records retained?
Can a tenant administrator accidentally modify fleet-level traffic rules?
These requirements should be documented in the software specification rather than relying on a general statement such as “WMS integration supported.”
This is one of the most practical problems in a shared warehouse.
An AGV operating in a dedicated facility may encounter a relatively predictable traffic pattern. A multi-tenant 3PL facility can be much less controlled. Another tenant's employee may leave a pallet jack in an aisle, place cartons temporarily in a travel lane, park a forklift in front of a rack, or create a temporary staging area without notifying the automation system.
The AGV should therefore treat many temporary objects as dynamic obstacles rather than assuming that every object belongs to the permanent warehouse map.
Depending on the vehicle configuration, obstacle detection may use safety scanners, LiDAR, cameras, 3D sensors, or a combination of sensors. The vehicle can slow down or stop when an object enters its defined detection or protective area.
After the obstacle remains in place, the fleet system may determine whether another route is available. If the route can be safely changed, the vehicle may wait, select an alternative path, or allow the fleet manager to assign another task.
However, buyers should not assume that every obstacle will automatically trigger intelligent route planning. The actual response depends on the supplier's navigation technology, map architecture, traffic-management logic, sensor configuration, and software settings.
A good shared-warehouse design should define what happens when a vehicle cannot reach a restricted destination.
For example:
The AGV detects an obstacle and reduces speed or stops according to its configured safety behavior.
The fleet software determines whether the obstacle is temporary or whether the route remains unavailable.
If an approved alternative route exists, the task may be rerouted.
If no approved route exists, the AGV waits or generates an exception.
An operator can investigate the blockage and clear the area.
The original task resumes or is reassigned according to the system's recovery logic.
The key point is that rerouting should never override a restricted-zone rule. A vehicle should not enter Tenant B's protected area simply because Tenant A's normal route has been blocked.
Dynamic routing in a multi-tenant warehouse should be considered a constrained optimization problem. The system is not simply looking for the shortest route. It must select a route that satisfies the warehouse's operational and access rules.
Depending on the fleet platform, route selection can consider factors such as:
Current vehicle location.
Destination and task priority.
Blocked or congested paths.
One-way or directional traffic rules.
Vehicle-specific restrictions.
Tenant-specific restricted zones.
Temporary exclusion zones.
Charging requirements.
Traffic congestion and other AGVs.
A simplified example is a three-zone warehouse containing Tenant A, Tenant B, and shared space. If an AGV assigned to Tenant A encounters a blocked aisle, the fleet manager can search for an alternative path through the shared area. The routing logic should exclude Tenant B's restricted zone even if that path is physically shorter.
This means that the shortest physical path is not necessarily the valid path.
For procurement, the supplier should explain how its system represents restricted zones and whether those restrictions are evaluated during dynamic route planning rather than only during manual route creation.
This can be particularly valuable in a multi-tenant facility. A tenant may temporarily reserve an area for inventory counting, high-value goods handling, maintenance, an inbound surge, or a customer-specific operation.
If supported by the fleet software, an operator could create or activate a temporary exclusion area and prevent normal AGV tasks from entering it.
The important questions are whether the change requires engineering support, whether it can be performed by an authorized warehouse administrator, whether the change is logged, and how the system handles AGVs that are already inside the affected area.
The last point is especially important. A new software restriction should not be evaluated only for newly created missions. The buyer should test how existing missions, vehicles already in transit, queued tasks, and recovery operations behave when a zone becomes unavailable.
A conventional AGV demonstration is not enough. The acceptance test should reproduce the conflicts that make the shared warehouse difficult.
| Test Scenario | What to Verify |
|---|---|
| Tenant A task | Vehicle remains within authorized route and destination rules |
| Tenant B restricted zone | Unauthorized task cannot enter the protected zone |
| Temporary blockage | Vehicle responds safely and follows defined recovery logic |
| Alternative route | Rerouting respects restricted-zone rules |
| Multiple AGVs | Traffic management prevents conflicts and deadlocks |
| Tenant user login | User sees only authorized data and controls |
| Zone becomes unavailable | Existing and queued missions recover correctly |
| Communication interruption | Vehicle and fleet system follow defined loss-of-communication behavior |
For a serious 3PL deployment, these scenarios should be included in FAT and SAT rather than left as informal demonstrations.
Multi-tenant requirements should be written into the technical specification instead of relying on a supplier's general statement that its fleet software supports “multi-zone management.”
Tenant and warehouse zone architecture.
Vehicle access permissions.
Task and destination restrictions.
User roles and administrative permissions.
Inventory and operational data isolation requirements.
API/WMS data separation requirements.
Dynamic obstacle response.
Dynamic rerouting rules.
Temporary exclusion-zone functionality.
Audit logging and configuration-change records.
FAT and SAT test scenarios.
Remote support permissions and access controls.
For sensitive 3PL operations, the contract should also clarify who owns the operational data, where the fleet server is deployed, what information is exposed through APIs, how long historical data is retained, and what happens to customer data when the project or software license ends.
A robust deployment normally separates several responsibilities rather than expecting the AGV itself to solve every multi-tenant problem.
WMS: determines inventory ownership, customer orders, pallet records and warehouse business logic.
Fleet Manager / RCS: converts authorized material-handling tasks into AGV missions and manages vehicle traffic, routes, zones and fleet status.
AGV: performs navigation, pallet handling, obstacle detection and its configured local safety functions.
Warehouse Access Control: provides physical restrictions where software-only access control is insufficient.
3PL IT Security: controls network access, user accounts, API permissions, remote access, logging and data governance.
This separation is important because tenant inventory isolation, AGV navigation, and physical warehouse security are different engineering problems.
For a multi-tenant 3PL warehouse, do not evaluate an AGV only by its ability to navigate the warehouse map. Ask the supplier to demonstrate restricted-zone control, tenant-level data permissions, dynamic obstacle handling, rerouting rules, temporary exclusion zones, and recovery behavior under realistic shared-warehouse conditions.
Chinese
English
