AMR Integration with Automatic Doors, Elevators, and Access Control: Interface States, Interlocks, and Fault Recovery

Door or Elevator Integration Is a Sequence, Not a Signal

AMR interaction with automatic doors or elevators is not as simple as “send a signal to open the door.” It is a multi-step state sequence — each step has state confirmation, timeout, and exception handling.

A practitioner asked in an online forum: “Is the interaction between AGV and automatic doors/elevators typically done by the AGV itself, or by notifying the dispatching software?” This question received multiple replies — showing it is a common confusion in system integration.

The answer depends on architecture: some systems have the AMR directly control doors/elevators, others use the dispatching system for unified management. But regardless of architecture, the integration core is the state sequence — request, authorize, open, enter, clear — each step needs confirmation and timeout handling.

Request, Authorize, Open, Enter, and Clear States

Standard door/elevator interaction sequence:

Key design questions:

• Who initiates the request? AMR directly or the dispatching system?
• Who confirms authorization? Door/elevator system or dispatching system?
• How does the AMR confirm the door is fully open? Sensor detection or signal confirmation?
• What happens on timeout? Retry, alarm, reroute, or manual intervention?

Position Confirmation and Occupancy Sensing

Door zone occupancy:

• Multiple AMRs may be in the door zone — need to ensure only one enters.
• Pedestrians may be in the door zone — need person-vehicle separation or interlock.
• Elevator car occupancy — how does the AMR confirm no other vehicles or people inside?

Occupancy sensing methods:

Define a validated means of confirming safe entry and occupancy; depending on the building and system architecture, this may combine building sensors, robot sensing, interlocks, access-control logic, and traffic-control rules.

Elevator Call, Floor Selection, and Car Reservation

Special complexity of elevator interaction:

1. Call: AMR or dispatching calls elevator to current floor.
2. Arrival confirmation: Elevator arrives at current floor and opens.
3. Enter: AMR enters the car.
4. Floor selection: AMR or dispatching selects target floor.
5. Travel: Elevator travels to target floor.
6. Arrival and open: Elevator arrives at target floor and opens.
7. Exit: AMR leaves the car.
8. Release: Notify elevator it can serve other requests.

Key questions:

• What does the AMR do inside the car during travel? Typically enters standby, resumes task execution after arriving at target floor.
• What if the elevator stops at another floor mid-travel? Doors open but it is not the target floor.
• How do multiple AMRs sharing an elevator queue?
• What happens when the elevator fails?

Interlocks with Personnel and Other Vehicles

Person-vehicle interlock:

• Doors and elevators are personnel passages — how to ensure personnel safety when AMRs use them?
• Safety interlock: When the AMR requests door opening, is the door zone clear?
• Priority: When personnel and AMRs need the door/elevator simultaneously, who goes first?

Multi-vehicle interlock:

• Multiple AMRs requesting the same door/elevator — dispatching system needs queue management.
• When one AMR is in the door/elevator, others cannot enter.
• Dispatching system needs channel-level and device-level locking.

Timeout, Network Loss, and Door-Stuck Scenarios

Timeout handling:

Network loss handling:

• AMR-to-dispatching communication lost — how to handle door/elevator interaction?
• If AMR loses network inside the elevator — can it continue?
• Door/elevator system to dispatching communication lost — what state does the door hold?

Door stuck:

• Door stuck during opening — AMR detects door not fully open and cannot pass.
• Door stuck during closing — AMR has passed but door cannot close, affecting other users.

Fire Mode: Define, Do Not Assume

Fire mode is a high-risk scenario: When a fire occurs, the fire system may need to:

• Release all door locks — personnel evacuation.
• Recall elevators to designated floors — no elevator use.
• Shut down ventilation — affects AMR routes.

AMR behavior in fire mode must be defined by the building/fire engineer and applicable fire/life-safety requirements. The article must not prescribe stop, evacuation, elevator recall, or door-release behavior. Confirm the interface between the fire system and the AMR/dispatching system is defined by the building/fire engineer and applicable codes.

Building Interface Test Checklist

Door/Elevator State Table

Building Interface Test Inputs

1. Door/elevator integration is a state sequence, not a single signal — request → authorize → open → enter → clear, each step needs confirmation and timeout.
2. Confirm who initiates the request — AMR directly or dispatching system unified management.
3. Occupancy sensing cannot rely only on software locks — physical sensors are needed to confirm door zone and car occupancy.
4. Timeout and network loss safe states must be defined — do not assume “it won’t happen.”
5. Fire mode behavior must be explicitly defined — do not assume the fire system will automatically handle AMRs.
6. Multi-vehicle shared doors/elevators need queue management — dispatching system needs channel-level and device-level locking.
7. Fire interlock design must be confirmed by a building engineer or fire protection engineer and applicable building/fire codes — not the AMR supplier’s decision.