AGV elevator integration succeeds or fails not on whether a call API works, but on whether every party agrees who confirms each state from reservation through release and where the process returns after a fault. This guide treats multi-floor transport as one distributed transaction and carries that design consistently through the RFP, FAT, SAT, and operational handover.
Executive answer: procure the elevator journey as a nine-state transaction
The practical answer is to specify nine states: reserve, assign, arrival confirmation, board, in-car presence confirmation, travel to the destination floor, alight, exit confirmation, and release. For every state, define its entry condition, success condition, timeout, retry, idempotency key, cancellation behavior, evidence, and responsible owner. An RFP that says only “the AGV shall call the elevator” may pass a demonstration while leaving communication loss and restart recovery impossible to accept objectively.
Adopting VDA 5050 3.0 does not automatically standardize the elevator connection. VDA’s published scope is the communication interface that exchanges order and status data between mobile robots and central Fleet Control. The elevator API, building gateway, fire-service operation, maintenance mode, door interlocks, and site authorization model form a separate integration boundary. Making that boundary explicit is the first quality gate in AGV system integration.
Why AGV elevator integration is difficult
For a single-floor AGV, the main coordination points are routes, intersections, charging, and load-transfer stations. Multi-floor transport adds AGV, Fleet Control, WMS/MES, the elevator gateway, elevator control, facilities, and EHS. Each system can observe the same mission in a different state. One may believe the AGV is in the car while another still records it as waiting at the landing. That drift produces duplicate calls, blocked doors, duplicate transport orders, trapped vehicles, and long manual recovery.
The elevator may not be dedicated to robots. If it is shared with people, carts, or maintenance teams, accepting a call is not the same as permitting a safe boarding movement. Fire and inspection modes take priority over business dispatch. Integration must therefore balance two needs: do not move when the current state cannot be proven, and restore operations through a controlled process once safety is confirmed.
ISO 3691-4:2023 covers safety requirements and verification means for driverless industrial trucks and their systems, including AGVs and AMRs, and notes that the operating-zone condition significantly affects safe operation. This article is not a conformity assessment. A project still needs a risk assessment based on the actual vehicle, building, load, human interaction, and applicable local requirements, with confirmation by the relevant manufacturers.
What VDA 5050 3.0 does and does not standardize
The VDA announcement for Version 3.0 describes an open basis for operating multi-vendor mobile robots under a master control, plus zone concepts for free navigation, path sharing, localized error information, and a power-saving action. The VDA 5050 publication page positions Version 3.0.0 as the interface for job and status exchange between mobile robots and Fleet Control. The official GitHub repository provides the specification and JSON schemas and states that the VDA-published PDF prevails if materials differ.
VDA 5050 is therefore a strong option for organizing the vehicle-side boundary of a mixed fleet, but it is not a complete elevator solution. Elevator companies publish integration resources, including the KONE API Portal, Schindler’s Cloud Robot API introduction, and an Otis robot-integration datasheet. Those resources do not mean that authentication, commands, events, building eligibility, regional availability, or commercial terms are identical. Evaluate “VDA 5050 support” and “support for the target elevator API” as separate RFP items.
| Boundary | Candidate standard or specification | What the RFP must settle |
|---|---|---|
| AGV to Fleet Control | VDA 5050 3.0, manufacturer specification | Version, mandatory features, extensions, error semantics, compatibility testing |
| Fleet Control to WMS/MES | REST, message bus, existing interface | Transport ID, priority, cancel, completion, deduplication, resend |
| Fleet Control to elevator | Manufacturer API, building gateway | Reservation, call, destination, door, occupancy, events, authentication, limits |
| Elevator control and safety | Manufacturer design, site safety requirements | Fire and maintenance modes, manual priority, recovery authority, inhibit conditions |
| Site operation | SOP, EHS, facility procedures | Shared-use rules, access, alarms, training, audit, change control |
If this table remains ambiguous, the AGV supplier may blame an elevator API that did not accept a command, the elevator supplier may blame robot state updates, and the user alone inherits the recovery decision. Map the boundaries before contract award and assign both a state owner and an evidence owner for every transition.
Break AGV elevator integration into nine states
The nine states provide vendor-neutral operational vocabulary. Even when API names differ, parties can compare how far the transaction has been confirmed. Evidence that a command was sent is not enough; the next state must be confirmed through observable evidence.
| State | Entry condition | Success condition | Primary evidence | Default response to failure |
|---|---|---|---|---|
| 1. Reserve | Valid transport order and floors | Unique reservation ID obtained | API response, event, audit log | Query with same key; do not blindly create another |
| 2. Assign | Eligible elevator candidates available | Car or service slot fixed | Assignment event, car ID | Apply reselection and cancellation rules |
| 3. Arrival confirmed | AGV and car travel to landing | Both AGV position and elevator arrival confirmed | Vehicle state, floor event | Decide wait, recall, or operational hold |
| 4. Board | Door, route, and occupancy permitted | AGV reaches defined in-car position | Position, sensor, completion event | Do not permit door closing; move to safe state |
| 5. In-car confirmed | Boarding motion completed | AGV identity and in-car state confirmed | AGV pose, in-car detection, correlation ID | Do not issue travel command if inconsistent |
| 6. Travel | Destination and in-car state valid | Destination reached and door-open condition valid | Floor, motion, arrival event | Query mode and equipment state; hold |
| 7. Alight | Destination route available | AGV reaches outside refuge point | Vehicle position, zone release | Treat as remaining in car; do not release |
| 8. Exit confirmed | AGV at refuge point | No interference with door closing confirmed | Safety zone, exit event | Reconfirm or move to manual verification |
| 9. Release | Exit and cleanup completed | Reservation, occupancy, and mission locks released | Release response, final audit log | Idempotent release plus stale-lock monitoring |
Use shared correlation across these transitions. Link the WMS/MES transport order ID, AGV mission ID, elevator reservation ID, and equipment event ID within one trace so operators can reconstruct sequence later. The identifiers do not need to collapse into one, but their mapping must be retained in the logs.
In-car confirmation deserves special attention. Completion of a boarding command does not prove that the AGV is correctly positioned inside. Combine AGV position, elevator-side detection, and door permission, then declare which information is authoritative. If sensors are added, do not let one sensor’s ON signal conclude the entire safety decision; agree failure behavior with the equipment manufacturer.
Put timeout, retry, and idempotency in the RFP
In a distributed system, “no response” does not mean “not processed.” If the response path drops immediately after a reservation request, the equipment may already hold a reservation. Sending a new request can create a duplicate. Require an idempotency key for every state-changing request so that resending the same key returns the same outcome or allows convergence by querying current state.
Do not impose one arbitrary timeout on every supplier operation. Require the supplier to provide state-specific rationale. Network response, elevator waiting, physical AGV movement, and door motion have different timing characteristics. After timeout, some states may permit a different car request; others must prohibit new calls until a person or the equipment confirms status. Make the decision from time plus the last confirmed safe state and current equipment mode.
Required elements of the retry policy
- Which commands may be resent, queried only, or require manual confirmation.
- How long the same idempotency key remains valid, where it is stored, and how it survives restart.
- How backoff and retry limits avoid overloading the equipment API.
- Handling for duplicate, delayed, and out-of-order events.
- Precedence and notification when cancellation races with completion.
- Abort behavior when the elevator enters fire or maintenance mode during a timeout.
- Conditions and authority for moving from automatic recovery to Manual Hold and back.
Retry does not mean “repeat until it works.” Once its defined limit is reached, the transaction moves to Manual Hold. The AGV may move to an established safe waiting point only after its physical position, equipment state, and a safe path have all been confirmed. If its state is unknown or it may be in the car, keep it stopped in place, remain in Manual Hold, and do not release the reservation or occupancy. Mature automation stops without creating extra false state and can be restored with a concise, auditable procedure.
State-machine design for communication loss and restart recovery
Communication can fail at AGV wireless, Fleet Control, the building network, a cloud API, or the elevator gateway. Writing only “resume automatically after communication is restored” is unsafe. A restored process must reconcile actual AGV position, door/floor/mode, persisted transactions, and WMS/MES transport status instead of trusting pre-failure memory.
Recovery first suppresses new missions and lists every incomplete transaction. It then reconciles the AGV’s physical position with elevator floor, door, and operating mode. Only when both sides are confirmed may an operator-authorized transition return from Recovering to exactly one verified state among Waiting, Boarding, In Car, or Exiting. Recovering must not return automatically to an arbitrary previous state. If reconciliation cannot confirm the state, its only destination is Manual Hold. If the possibility of an AGV in the elevator cannot be excluded, do not release the reservation or return the car to ordinary service. Require physical confirmation by facilities and release under designated authority.
| Failure point | What to query on recovery | Condition for automatic recovery | Manual Hold example |
|---|---|---|---|
| AGV wireless loss | Position, mission, speed, error | Safe stop and location confirmed; states match | Unknown position or possible in-car state |
| Fleet Control restart | Persisted transaction, vehicle, reservation | Correlation IDs and states can be rebuilt | State existed only in volatile memory |
| Gateway restart | Reservation, car, mode | Current equipment state can be queried | Execution of old request is uncertain |
| API link loss | Last event, current state, credentials | Read query succeeds without contradiction | State change may have succeeded alone |
| WMS/MES outage | Order, cancellation, completion receipt | Synchronizes with deduplication | Another order is handling the same load |
Do not stop recovery testing at simulated FAT faults. During SAT, use planned interruptions at intermediate states across the actual building network, roaming wireless, gateway, and operator terminals, then retain the evidence. Acceptance means no false duplicate reservation, exactly one business completion, no stale locks, and an audit trail that explains the recovery decision—not merely that the system “moved again.”
Make fire, maintenance, and shared-human use top-level requirements
Fire-service and maintenance operation must take precedence over ordinary AGV transport. Specific behavior depends on the elevator manufacturer, building design, and applicable requirements, so it cannot be generalized by the AGV team alone. Require a manufacturer-approved definition of where mode information originates, when AGV requests are rejected, who decides if an AGV could be in the car, and how service resumes after return to normal mode.
In a shared elevator, the policy matters as much as robot detection. Define dedicated time windows or cars, whether sharing is permitted, occupancy conditions, waiting points, conflict with push-button passengers, protruding carts, and people stopping near the doors. Use defense in depth: avoid creating an inviting conflict path, provide signage and training, and identify the abnormal-event contact, rather than relying only on “the sensor will stop it.”
Design boundary for AGV safety measures
| Item | AGV/Fleet side | Elevator side | User organization |
|---|---|---|---|
| Landing entry | Speed, stop position, route occupancy | Door, arrival, permission state | Floor, access, shared-use rules |
| Boarding/alighting | Positioning, obstacle detection, mission | Door motion, equipment interlock | Load condition, supervision, SOP |
| In-car movement | Stop at defined in-car position | Destination motion and mode precedence | Sharing policy, emergency contact |
| Fire/maintenance | Stop request, safe wait, alarm | Authorized mode behavior | Authority, evacuation/maintenance procedures, training |
| Recovery | Query, resync, prevent duplicate execution | Provide equipment state and availability | Physical confirmation, approval, records |
The safety allocation cannot be completed by an API document alone. Consistent with ISO 3691-4:2023’s focus on the operating zone, inspect level changes, sill gaps, positioning, wireless coverage, lighting, blind spots, evacuation paths, and load stability. Feed the risk-assessment results into SAT and operational procedures.
Responsibility from AGV WMS integration to equipment control
WMS/MES defines which load moves from where to where and by when, while Fleet Control assigns vehicles and routes. The elevator gateway translates service intent into commands and events for the target equipment, and elevator control follows its approved operating and safety logic. If WMS/MES directly micro-controls the car and doors, the solution becomes tightly coupled and harder to maintain when equipment or car counts change.
Agree where business completion occurs. “Reached destination floor,” “exit confirmed,” and “delivered at the next process station” are distinct states. In inter-process transport automation, passing through the elevator is not a completed business outcome if the load never reaches the next process. Separate equipment and business transactions while preserving their correlation.
In RACI, distinguish the Command Owner from the State Evidence Owner. Fleet Control may issue a reservation while authoritative reservation evidence lives in the elevator gateway. Safety-interlock ownership remains within the equipment manufacturer’s design boundary and cannot be silently substituted by the AGV layer. FAT evidence covers the integration range, including simulated equipment; SAT evidence covers the actual building and operation end to end.
RFP requirements ready for adaptation
Write the RFP in testable contract language, not as a feature wish list. Specify deliverables, exceptions, test methods, and passing evidence alongside “shall support.” Adapt the following to the project.
1. Architecture and interfaces
- Submit the supported VDA 5050 version, functions used, unsupported functions, and proprietary extensions.
- Treat VDA 5050 as the AGV-to-Fleet-Control boundary and submit the elevator API as a separate specification.
- Submit logical and physical diagrams for WMS/MES, Fleet Control, AGV, gateway, and elevator control.
- Document authentication, certificate renewal, time synchronization, network routes, ports, naming, and monitoring points.
- Define API commands, events, states, errors, rate limits, compatibility, and deprecation policy.
2. Transaction and exception handling
- Submit entry, success, failure, cancellation, timeout, retry, and idempotency for all nine states as a state diagram.
- Provide a way to reproduce duplicates, delays, out-of-order events, lost responses, and partial success.
- Rebuild incomplete transactions from persistent data after restart and reconcile them with current state.
- Define authority and audit for automatic recovery, Manual Hold, physical confirmation, release, and resume.
- Detect, display, and release stale reservation, zone, and transport-order locks.
3. Safety, equipment modes, and shared operation
- Document AGV request behavior under fire, maintenance, inspection, manual priority, and out-of-service modes.
- Define permitted and prohibited sharing with people, carts, and other robots, plus landing wait and refuge points.
- Show manufacturer-approved safety functions, interlocks, and boundaries for both AGV and elevator.
- Submit risk assessment, residual risks, training, signage, PPE, emergency contacts, and recovery SOP.
- Include reassessment and regression testing for software, equipment, and layout changes.
4. Monitoring, logs, and handover
- Trace one timeline from WMS/MES to equipment events through common correlation.
- Agree time base, retention, access, privacy, and export format for logs.
- Monitor incomplete duration, Manual Hold, retries, stale reservations, and mode changes.
- Deliver procedures, troubleshooting matrix, contacts, spares, backup, restore, and training material.
- State the handover scope for source, configuration, licenses, API contracts, certificates, and administrator accounts.
What evidence to receive from FAT and SAT
FAT verifies logic and integration early; SAT confirms the actual site with its building, network, people, and operating practices. FAT success must not waive SAT, but deferring every issue to SAT raises rework cost and downtime. Use simulation or hardware-in-the-loop to exhaust exception paths in FAT, then focus SAT on site-specific conditions and end-to-end behavior.
| ID | Test | FAT evidence | SAT evidence | Acceptance concept |
|---|---|---|---|---|
| T01 | Normal nine states | API trace, state sequence, video | Vehicle video, equipment log, order record | Sequence and correlation match; completes once |
| T02 | Reservation response lost | Blocked response, re-query | Planned building-network interruption | No duplicate reservation; converges to existing state |
| T03 | Duplicate/out-of-order | Message-injection record | Approved reproduction in monitored setup | No state regression or false completion |
| T04 | Link loss while boarding | Simulator and safe-stop record | Planned safe wireless test | Stops safely; preserves possible in-car state |
| T05 | Fleet restart | Database restore, resync log | Restart of production-equivalent setup | Rebuilds incomplete work without duplicates |
| T06 | Gateway restart | Equipment query log | Manufacturer-attended test | Determines whether old request executed |
| T07 | Fire/maintenance mode | Simulated mode and rejected demand | Manufacturer-approved procedure | Overrides normal requests and moves safe |
| T08 | Shared human use | Detection, stop, refuge record | Rehearsal on actual traffic path | Enforces defined prohibit/wait conditions |
| T09 | Destination exit blocked | Obstacle injection, timeout | Safe test load with observers | Does not release; enters Manual Hold |
| T10 | WMS/MES resend | Repeat same transport ID | Upper-system integration test | Does not transport the same load twice |
| T11 | Monitoring/notification | Alarm, timeline, access | Operator terminal and contact drill | Operator identifies cause and next action |
| T12 | Post-recovery residue | Lock list, release audit | Shift-handover confirmation | No reservation, zone, or order residue |
The evidence package should contain the test specification, approved procedure, configuration versions, test data, API traces, device logs, screen capture, video, defect records, retest results, and signed disposition. Logs alone do not show physical position; video alone does not reveal API order. Bind them with common time and correlation IDs.
Avoid acceptance language such as “operates without problem.” For T02, use an observable criterion such as: no additional reservation with the same key, convergence through current-state query, and zero stale reservation at completion. Set timing thresholds from equipment specification, transport demand, business requirements, and risk assessment for the site, then record the rationale.
Do not confuse a pre-deployment PoC with production acceptance
A PoC is useful for reducing uncertainty in API access and basic movement, but it does not replace production acceptance. One successful ride does not prove concurrent demand, mode transitions, restart, wireless loss, shared use, or shift handover. The PoC exit report must list untested items, constraints, required changes, and the likely production architecture.
During supplier selection, value state diagrams, API specifications, fault-injection methods, logs, boundaries, and elevator-manufacturer coordination more than a polished video. For an existing elevator, have the manufacturer confirm whether the specific building, car, controller, and software support the integration. A public API portal does not mean every installed elevator can use it immediately.
For the wider system context, see our AGV system integration guide for Thailand. For load-transfer choices, see conveyor-top AMR integration. If unattended night operation is in scope, align recovery authority and callout procedures with our unmanned night factory operation guide.
Inter-process transport automation and BOI planning in Thailand
When planning automation investment in Thailand, run the technical RFP and incentive review in parallel to reduce rework in equipment scope, contracting, evidence, and schedule. Subject to confirmation of eligibility, the BOI Smart and Sustainable Industry material describes a THB 1 million minimum investment excluding land and working capital, and machinery import-duty exemption. For an existing-business upgrade, it describes a three-year corporate income tax exemption capped at 50% of qualifying investment excluding land and working capital. If at least 30% of the total value of machinery, automation systems, or robotics used or upgraded in the project is linked to Thailand’s domestic automation industry, it describes a three-year corporate income tax exemption capped at 100% of qualifying investment excluding land and working capital.
These are planning references at the time of publication. Confirm the promoted activity, existing/new-project classification, investment calculation, eligible machinery, local-automation linkage, application timing, and approval conditions case by case with BOI or qualified advisors. Incentive eligibility and safe AGV elevator integration are different questions. Do not remove safety functions, logs, FAT/SAT, or training to fit a tax equipment boundary.
Separate quotations for the AGV, Fleet Control, WMS/MES changes, elevator API/gateway, panel work, network, floor and landing work, testing, training, and maintenance. Look for boundary work absent from every supplier quotation. Mapping the BOI equipment list to RFP functions and acceptance items also makes later change impact easier to trace.
A staged production ramp-up plan
Avoid a single big-bang cutover. Start with digital connectivity, then progress through unloaded AGV, test load, limited time window, limited floors, and normal shifts. For each stage, specify stop conditions, rollback, approver, and monitoring. The key control is preventing progression while exit conditions remain unmet.
Exit criteria by stage
| Stage | Main checks | Exit condition |
|---|---|---|
| Connectivity | Authentication, time sync, state read, test request | Correlated audit trail and no unexpected equipment motion |
| Unloaded test | Nine states, stopping position, boarding, communication | Normal and key fault cases pass; no stale locks |
| Test load | Load shape, center of gravity, transfer, sill | No interference or instability; all defined states observed |
| Limited operation | Sharing, alarms, manual recovery, handover | Site team can detect, stop, and recover through SOP |
| Normal operation | Priority, concurrent demand, maintenance, change control | Continuous KPI/audit and owner for every open risk |
Monitor distributions and fault breakdown, not only averages. Separate reservation wait, car wait, boarding, travel, and exit time; record Manual Hold causes, retries, cancellations, stale locks, and mode transitions. This guide sets no universal target because building topology, shared use, car utilization, and transport peaks differ. Measure a baseline and set site targets from business and safety requirements.
Change control should cover AGV software, Fleet Control, elevator gateway, controller, network, certificates, WMS/MES, and layout. Select affected states and test cases before an update, then run regression after it. A VDA 5050 version change must be checked not only for JSON validity but for equivalent meaning of the actions, states, extensions, and errors used by the project.
Five procurement pitfalls to avoid
Pitfall 1: treating a successful call as integration success
An HTTP success response does not show that the AGV exited safely at the destination. Track all nine states and separate exit confirmation from release.
Pitfall 2: assuming VDA 5050 standardizes building equipment
VDA 5050 3.0 focuses on mobile robots and Fleet Control. Accept the elevator API, equipment modes, and site interlocks under separate specifications.
Pitfall 3: creating a new request after timeout
The equipment may have processed the request despite response loss. Converge with idempotency and state query; use Manual Hold when the result is uncertain.
Pitfall 4: shortening SAT after only normal-path FAT
FAT cannot fully reproduce real wireless, floor, sill, people flow, and fire/maintenance operations. Use FAT for fault injection and SAT for site conditions.
Pitfall 5: training operations at the end
Recovery authority, alarms, equipment modes, and sharing rules are design inputs. Bring facilities, EHS, IT/OT, production, logistics, and maintenance into the RFP and test reviews.
FAQ
What does AGV elevator integration include?
It integrates WMS/MES transport demand, Fleet Control assignment, elevator reservation/car/door/destination/mode, and site safety and recovery—not only an API connection. Defining the nine states and their responsibility and evidence makes supplier boundaries manageable.
Does VDA 5050 3.0 make elevator APIs common?
No. VDA 5050 3.0 addresses mobile-robot communication with central Fleet Control. It does not automatically unify elevator APIs or building gateways. Confirm the target elevator, authentication, commands, events, and equipment modes and test the integration.
What should an AGV system integration RFP decide first?
Decide the business scope and completion point, nine states, system boundaries, owners, safe fault state, and FAT/SAT evidence. Procure from a whole-system architecture that includes the building, network, and operation, not only the vehicle specification.
When should AGV WMS integration return completion?
That is a business decision. Destination-floor arrival, exit confirmation, and handoff to the next process are different states. Separate equipment and business transactions and agree a completion point that prevents incorrect inventory or duplicate dispatch.
May AGV safety controls restart automatically after a link failure?
Only consider it when the last confirmed safe state matches the recovered physical state and no pending request or equipment mode conflicts. If in-car presence or old-request execution is unknown, keep Manual Hold and resume after authorized physical verification.
How should FAT and SAT be divided for inter-process transport automation?
Use FAT to reproduce the state machine, duplicates, delays, outages, and restarts with simulation or equipment. Use SAT for the real elevator, wireless, floor, door, load, people flow, modes, and handover. Retain correlated logs and site records in both.
Can Thailand BOI incentives cover AGV and elevator modifications?
It depends on the activity, equipment, project classification, and application timing. Current BOI material provides investment and tax/duty conditions, but eligibility requires individual confirmation. Map the technical RFP to the equipment list and consult BOI or an advisor before applying.
Conclusion
AGV elevator integration is not one API cable. It is a distributed transaction across reserve, assign, arrival confirmation, board, in-car confirmation, travel, alight, exit confirmation, and release, with defined timeout, retry, idempotency, link-loss, restart, fire/maintenance, and shared-human behavior. VDA 5050 3.0 is a valuable standard for the AGV-to-Fleet-Control boundary, while the elevator boundary still requires project-specific design and acceptance. Put responsibilities and evidence in the RFP, exercise faults in FAT, and confirm the actual building and operation in SAT to build inter-process transport that teams can recover in production.
