Skip to content

Elevator interface — requirements for safe robot operation

What an elevator interface must be able to do so that a mobile service robot can use a passenger elevator without a person in the loop. This page carries the full content of the document Elevator Interface — URG Requirements for Safe Robot Operation, version 1.0 of 11.09.2026, prepared for an elevator interface partner.

The document is written to be marked up and returned: sections 2 and 4 are tables with three columns on the right — Available today, With planned change, Not possible. Exactly one box per line. Where the answer is "with planned change", the expected release is added; where it is "not possible", a one-line reason is enough. The marked-up document is then the basis for the integration plan and the on-site acceptance test — no further specification round is needed from the URG side.

Document control

Item Value
Document Elevator Interface — URG Requirements for Safe Robot Operation
Version 1.0 · 11 September 2026
Issued by United Robotics Group GmbH
Prepared for an elevator interface partner — partner document
Release Released by management on 12 September 2026; QM review pending
Contact support@unitedrobotics.group
Return sections 2 and 4 with one box marked per line, plus expected release dates where With planned change is marked

1 Purpose and scope

This document covers exactly one function: a robot requests a ride, enters the cabin, is carried to the target floor and leaves the cabin, with the elevator controller remaining master for every safety-relevant function — safety circuit, door supervision, fire service and emergency operation, evacuation.

It does not cover robot navigation, floor and door numbering (agreed per site at commissioning), or any building or facility function beyond the ride itself. The robot is a passenger with an advance booking, never a control instance.

1.1 Why this list exists

During robot tests in a laboratory in early September 2026, an accepted elevator request was lost twice, in two different ways:

  1. Accepted request discarded while the cabin was already standing at the floor. The doors did not open, the cabin left the floor, and the robot was left waiting in front of a closed door with no error that named a cause.
  2. Request expired by a 30 s timeout while the robot was already inside the cabin. After expiry no target floor could be selected any more; the robot was stuck in the cabin and had to be recovered by staff.

Both cases have the same root: the robot loads and unloads open sample carriers, drives into and out of the cabin slowly and deliberately, and a 30 s door-hold or request lifetime is not enough for that. The 30 s figure was reported as a default value that was estimated rather than measured, and one that can be changed.

The point of conflict

Our operating profile and the current interface default are in direct conflict, and it must be resolved before any productive installation.

As an interim arrangement for the ongoing tests, the entry and exit timeouts were set to 120 s and URG places its calls with priority High and exclusive = true. That arrangement is reflected in R3, R4 and R14. It is an interim measure — the requirement remains that an accepted request is not dropped by a timer while the robot is physically committed to the ride, and that any drop is reported (R7).

2 Requirements

"Must" is a precondition for robot operation. "Should" improves availability or usability and is not a blocking item.

ID Requirement Must / Should Rationale Available today With planned change Not possible
R1 Destination call with source and target floor. One call brings the cabin to the source floor and registers the target floor in the same operation. The interface returns a request id for the call. Must The robot cannot press buttons. A pure hall call would leave the target floor unset once the robot is inside. ☐ ☐ ☐
R2 Exclusive ride. While a request with priority High and exclusive = true is active, no passenger calls are served for that cabin: no intermediate stops, no car calls, hall calls suppressed or queued for later service. Every further ride request for the same elevator is rejected with a distinct code, not queued, until the active request is completed or explicitly cancelled. Must The robot occupies the cabin with open sample carriers. Intermediate stops and co-riders are excluded for hygiene and safety reasons; silent queueing would hide the conflict from the robot. ☐ ☐ ☐
R3 Door hold at entry until "entered" confirmation. At the source floor the doors stay open until the robot reports "entered". The request must not be dropped by a timeout while the cabin is standing at the floor. If a timeout cannot be avoided, it must be configurable per elevator and at least 120 s. Must Field cases 1 and 2 above. Entering with an open load takes noticeably longer than a person stepping in; 30 s is not sufficient and the value was not measured. ☐ ☐ ☐
R4 Door hold at exit until "release". At the target floor the doors stay open until the robot reports "release". Same timeout rule as R3: no timeout-based drop, or a per-elevator configurable timeout of at least 120 s. Must The robot leaves the cabin, changes to the map of the target floor and re-localises before it releases. Losing the request during that window strands the robot in the cabin. ☐ ☐ ☐
R5 Explicit cancellation through the API only. An accepted request ends only when it is completed or when URG cancels it through the interface. Cancellation is idempotent: a repeated cancellation for the same request id has no further effect and is not an error. Must A single, deterministic termination path. Repeated cancellation happens after a gateway restart and must not produce faults. ☐ ☐ ☐
R6 In-cabin floor button as the only other termination path. Pressing a floor button inside the cabin may end the exclusive ride as an emergency path for staff. If it does, the interface reports the event with a distinct reason code. Must Staff must be able to take back a cabin without a tool. The robot must learn that it happened rather than infer it from a missing status change. ☐ ☐ ☐
R7 Notification on every loss of a request. Whenever a request is dropped, cancelled, expired or otherwise ended without completion, the interface signals this — by push event or by a status field carrying a reason code and a timestamp — within 1 s. The robot must never lose a request silently. Must Both field cases were undetectable from the robot side. Without this signal the robot waits in front of a door, or in a cabin, until a person intervenes. ☐ ☐ ☐
R8 Status read. Readable at any time: request status (accepted / assigned / waiting for entry / moving / at destination / completed / failed), cabin floor, door state per floor and door side, travel direction, operating mode (normal / fault / out of service / fire service / maintenance). By polling at 1 Hz or faster, or by push. Must The robot checks plausibility (correct floor, correct door open, mode normal) before every entry and exit, and uses the operating mode as an abort criterion. ☐ ☐ ☐
R9 Rejection and error codes. Machine-readable and distinguishable, at minimum: rejected (implausible request, e.g. source = target), duplicate, out of service, access denied, timeout. Must Determines whether the robot retries, waits or returns the transport order as undeliverable. A single generic error code makes that decision impossible. ☐ ☐ ☐
R10 Unique request id. A UUID generated by URG is accepted in all calls and returned in all status and event messages. Duplicate detection is based on this id. Must Correlation of calls, status and log entries across gateway restarts and across several robots. ☐ ☐ ☐
R11 Configurable timers per elevator. Entry door hold, exit door hold and any request lifetime are settable per elevator, and the values in effect can be read back through the interface or are recorded in the commissioning sheet. Must Door hold times differ between a goods elevator and a narrow passenger cabin. Values that are hard-coded or only known inside the interface cannot be verified at acceptance. ☐ ☐ ☐
R12 Authentication and transport encryption. No anonymous access. Transport encrypted with TLS 1.2 or higher; per-gateway access key or client certificate, or TLS-PSK / client certificate for message-broker transports. The credential grants access only to the functions in section 5 and only to the elevators released for robot use. Must Elevator control commands on a building network. An unauthenticated endpoint or broker is not acceptable to the customer IT departments we work with. ☐ ☐ ☐
R13 Elevator selection in groups. For elevator groups the interface returns the assigned car so the robot waits in front of the correct door. Should Without the assigned car the robot has to guess which door will open. Not applicable where there is no group control. ☐ ☐ ☐
R14 Priority levels. A ride can be requested with a priority (low / medium / high) that affects the order of waiting requests. URG places robot rides with High. Should Agreed as part of the interim arrangement. Affects ordering only, never the safety behaviour of the controller. ☐ ☐ ☐
R15 "Robot ride" indication in the cabin and at the landing. Display or announcement while an exclusive ride is active. Should Keeps people from boarding a cabin that will not stop for them, and explains a door that stays open. ☐ ☐ ☐
R16 Event push. State changes delivered as events (webhook, WebSocket or message broker) instead of polling. Should Lower latency and load; also the natural carrier for the notification required in R7. ☐ ☐ ☐

3 Safety rules on site

These rules apply on the customer site regardless of what the interface supports. They are listed here because R2, R15 and the acceptance tests depend on them.

  • No person rides with a loaded robot. The cabin is reserved for the robot for the duration of the exclusive ride. Any person present in the door area stops the robot from entering.
  • Never two robots in one cabin. At most one robot request per elevator is active at any time. Further robots wait at their waiting points outside the door area until the active request is completed or cancelled.
  • The elevator controller stays master. Safety circuit, door supervision, fire service and emergency operation, and evacuation are unchanged and always take precedence. On fire service or emergency operation the robot outside stays at its waiting point; a robot inside the cabin leaves only when it has positively recognised the floor.
  • The robot never enters a cabin whose state is not confirmed (correct floor, correct door open, exclusive ride active, operating mode normal).
  • Staff instruction. Operating staff are instructed on how to recover a robot from a cabin manually and on the in-cabin button path in R6.

4 Acceptance tests

Preconditions: interface productive at the site, network release active, floor and door table agreed, at least one robot with maps of all floors involved, one elevator reserved for the test, a named person keeping the record.

No. Step Expected result Result
T01 Gateway reaches the elevator interface (status read without an active request) Elevator state with correct floor and door state; latency < 1 s ☐
T02 Invalid access credential Access denied; no call triggered ☐
T03 Ride requested with source floor = target floor Rejected; elevator unchanged ☐
T04 Same request id sent twice Duplicate; only one request active ☐
T05 Normal robot ride floor A → B Cabin arrives, doors stay open until "entered", ride without intermediate stop, doors stay open until "release", robot reaches its target on the map of floor B ☐
T06 Return ride B → A As T05 ☐
T07 A person presses a hall call during the robot ride No intermediate stop; the call is served after the robot releases the elevator ☐
T08 Car call button pressed during the exclusive ride No effect on the ride, or ride ends as defined in R6 and the event is reported ☐
T09 Robot does not report "entered" (test: robot held at the waiting point) Doors close only after the configured entry timeout (≥ 120 s), request ends with a reported reason, robot stays at the waiting point, notification received ☐
T10 Robot does not report "release" (test: the release message is suppressed) Doors close only after the configured exit timeout (≥ 120 s), robot stands safely on floor B, request is cleaned up and the end is reported ☐
T11 A person stands in the door while the robot is entering Robot does not enter and waits; doors stay open ☐
T12 Doors are made to close during the robot's exit (test: close impulse) Door supervision reopens, robot stops and then continues ☐
T13 Network connection gateway ↔ elevator interface cut, robot at the waiting point Robot does not enter; after reconnection a new request succeeds ☐
T14 Network connection cut while the robot is in the cabin The ride is completed, the robot recognises floor B and exits; without recognition it stays in the cabin and an alarm is raised ☐
T15 Elevator switched out of service (maintenance switch) Out of service reported, robot stays at the waiting point, retry after 5 min ☐
T16 Fire service switch operated during a robot ride Controller aborts the ride, robot behaves as in section 3, alarm at the control station ☐
T17 Gateway restart while a request is active After the restart the request is cancelled through the API, elevator back in normal operation, robot requests again ☐
T18 Two robots request a ride at the same time Serialised, both rides succeed, no mutual blocking, the second request is rejected with a distinct code rather than queued silently ☐
T19 Endurance run, 20 consecutive rides 20/20 successful, door hold times recorded, proposal for the final entry and exit timeout values ☐
T20 Log check All requests present with request id, timestamps and status in the gateway log ☐

Acceptance is passed when T01–T18 pass and T19 reaches at least 19/20. Signed off by the customer, the interface partner and United Robotics Group GmbH.

5 What URG sends and expects

The URG elevator bridge works with a fixed session model. The call and status names below are ours and are transport-neutral; the mapping to the partner's interface is to be filled in by the partner in the right-hand column.

5.1 Calls (URG gateway → elevator)

Call Fields Meaning Partner interface (to be mapped)
requestRide requestId (UUID), robotId, pickup{floor, doors[]}, destination{floor, doors[]}, exclusive = true, priority = High Request a robot ride: cabin to the source floor, target floor registered, exclusive ride activated
liftEntered requestId The robot stands completely inside the cabin; the doors may close and the ride may start
releaseLift requestId The robot has left the cabin and re-localised on the target floor; the elevator returns to normal operation
cancelRide requestId, reason Abort an accepted request from the robot side; idempotent (R5)
getStatus requestId or liftId Read request and elevator status (used when polling; not needed with event push)

releaseLift and cancelRide are both idempotent and are always sent after completion, failure or abort, so that the elevator reliably returns to normal operation.

5.2 Status expected in return (elevator → URG gateway)

Signal Values Use in the robot sequence
requestReply Accepted, Rejected, Duplicate, OutOfService, AccessDenied Answer to requestRide; anything other than Accepted ends the request with an error (R9)
requestStatus Queued → LiftAssigned → WaitingForEntry → InTransit → AtDestination → Completed; Failed at any time, with a reason code WaitingForEntry = cabin at the source floor, doors open, robot may enter. AtDestination = cabin at the target floor, doors open, robot may exit. Every transition to Failed carries a reason (R7)
liftState currentFloor, openDoors[], travelDirection (Idle / Up / Down), operatingMode (Normal / Fault / OutOfService / FireService / Maintenance), controllerReady Plausibility check before every entry and exit; abort criterion on a change of operating mode (R8)

Floor and door numbering is not published by the controller. It is fixed per elevator at commissioning in a joint table and configured identically on both sides.

Contact: support@unitedrobotics.group.