Skip to content

Building integration — interface description 1.1

Lift, doors and calls: what the robot needs from the building in order to change floors, pass doors and react to calls — and who provides what. This page carries the full content of the document uGo Building Integration – Lift, Doors, Calls, version 1.1 of 12.09.2026, the leading document for the site side.

Addressed to integrators, lift and door contractors and the operator's IT department. It names no addresses, keys or serial numbers; those live in a commissioning sheet per site. Manufacturer-specific connections (lift controller, door drive) are implemented per site in an adapter. What is written here applies to all sites.

Document control

Item Value
Document uGo Building Integration — Lift, Doors, Calls · interface description
Version 1.1 · as of 12.09.2026
Applies to robots of the uLog and uServe ranges with uGo, site computer with level-change service, u-IoT modules
Software level uGo 1.0.8, Kiosk 1.0.3, network guard 1.1.9 — frozen on 10.09.2026
Written by Product Management and Service, 12.09.2026
Reviewed by Product Management and Service, 12.09.2026
Release Released by management on 12 September 2026; QM review pending
Languages DE, EN, FR, ES, IT, NL — see uLog and uServe — Documents

0 Summary

  1. The coupling between robot and building runs entirely inside the building's network. A site computer of United Robotics Group is the only gateway between the robots and the building services. No drive command and no control command for lift or doors comes from the cloud.
  2. A lift is connected through an adapter. The robot has a fixed interface to the lift (section 4); the adapter translates it to the building's controller. The robot side does not change from site to site.
  3. A robot ride is an exclusive ride. Call with start and destination floor, the cabin waits with open door for boarding, travels without intermediate stops, waits with open door for alighting, release by the robot (sections 5 to 7).
  4. Doors and calls run over u-IoT modules of United Robotics Group: potential-free contacts for door drives, inputs for call buttons, outputs for light and sound (sections 9 and 10).
  5. Safety rule: the robot never enters a cabin whose state is not confirmed. On loss of connection, fault, fire-service or emergency operation the lift controller has priority; the robot stays at the waiting point or inside the cabin and reports.
  6. What this version provides: the level-change service runs on the site computer and executes the lift ride. Modules, doors, calls and floors are configured on the robot's technician page (Building tab). A test ride from that interface is not part of this version; test rides during commissioning are driven through the level-change service.

1 Purpose and scope

This document describes what the robot needs from the building in order to change floors, pass doors and react to calls — and who provides what.

2 System boundaries

Robot (uLog / uServe)  --Wi-Fi-->  Site computer  --LAN-->  Lift controller (interface in the building)
  uGo, level change                  level-change service      calls, status, exclusive ride
  waiting point, entry               lift adapter              cabin, doors, safety circuit
                                     door service   --LAN-->  u-IoT modules  --contact-->  door drives, buttons, light, sound
Part Task Provided by
Robot with uGo drives jobs, knows the maps of all floors, stops at the waiting point, enters and leaves the cabin, re-localises on the destination floor. Technician page with the Building tab for configuration. United Robotics Group
Site computer industrial computer in the plant room (230 V, LAN). The only gateway between the robot network and the building services. Runs the level-change service (sequence of a lift ride, session per robot ride, timing supervision, log), the lift adapter and the door service. United Robotics Group
Lift controller with interface accepts calls, performs exclusive rides, reports status. Remains master for all safety-related functions. operator / lift contractor
u-IoT modules one device, two inputs, two outputs; call button, light, sound and door contact are the same assembly in different configurations. REST interface inside the protected network segment. United Robotics Group
Door drives, buttons, signalling devices automatic doors with a potential-free opening input, push buttons, lamps, loudspeakers. operator / integrator

3 Principles

  • One communication path, one port, one key per connection site computer ↔ building services. No anonymous access.
  • The lift controller is master. Safety circuit, door supervision, fire-service and emergency operation stay unchanged in the controller. The robot is a passenger with a reservation, never a controlling instance.
  • The robot enters a confirmed cabin only (right floor, right door open, exclusive ride active).
  • No drive command from the cloud. The cloud of United Robotics Group (uSuite; data in Europe, data centre Frankfurt) serves administration, evaluation and remote support. Lift and door control work without an internet connection.
  • No access to the robot from the network without credentials. Every request from the building network to a robot needs a login or a service key; configuration is reserved to the technician.

4 What the robot needs from the lift

"Must" is a precondition for robot operation; "should" improves availability or handling.

No. Requirement Level Explanation
A1 Call with start and destination floor (destination call) must one call brings the cabin to the start floor and registers the destination. Returns a job id.
A2 Exclusive ride (special ride, robot mode) must no passenger calls during the robot ride: no intermediate stops, no car calls, landing calls suppressed or collected with lower priority.
A3 Hold door at boarding until "entered" must the door stays open at the start floor until the robot reports "entered" or the hold time expires.
A4 Hold door at alighting until "release" must at the destination floor the door stays open until the robot reports "release" or the hold time expires.
A5 Read status must job status, cabin floor, door state per floor and door side, travel direction, operating mode (normal, fault, out of service, fire-service/emergency, maintenance). Polling at least once per second or event push.
A6 Release / abort must the robot can end a job at any time; afterwards the controller serves normally again. Release is idempotent.
A7 Rejection and error codes must at least: rejected (illogical), duplicate, out of service, access denied, timeout.
A8 Unique job id must generated by the site computer (UUID), carried in all calls and status messages; duplicate detection by it.
A9 Configurable timing must door hold times for boarding and alighting per lift (section 7).
A10 Authentication and transport encryption must HTTPS (TLS 1.2 or newer), access key or client certificate per site computer.
A11 Selection of the lift in a group should for lift groups the controller returns the assigned car number so the robot waits at the right door.
A12 Priority should robot call with priority; affects only the order of waiting jobs.
A13 "Robot ride" indication should notice in cabin and landing during the exclusive ride so people do not board.
A14 Event push should state changes as events instead of polling; reduces load and latency.

If the controller does not offer A2 to A4, a connection at controller level through a message-based robot-lift interface is the second way. An adapter exists for that as well.

The same requirements, written as a questionnaire that a partner marks line by line, are on Elevator interface — requirements.

5 Messages and signals

The level-change service works with a fixed session model per robot ride. The lift adapter maps four calls and three status signals to the building's interface; the concrete endpoints and fields are filled in by the lift contractor in the column "interface in the building".

5.1 Calls (site computer → lift)

Call Fields Meaning Interface in the building
requestRide requestId, robotId, pickup{floor, doors[]}, destination{floor, doors[]}, exclusive=true, priority request a robot ride: cabin to the start floor, register destination, activate exclusive ride (to be named by the lift contractor)
liftEntered requestId the robot stands completely inside the cabin; the door may close, the ride may start
releaseLift requestId the robot has left the cabin or aborts; lift back to normal operation
getState requestId or liftId job and lift status (polling only)

5.2 Status (lift → site computer)

Signal Values Use
requestReply Accepted, Rejected, Duplicate, OutOfService, AccessDenied answer to requestRide; anything but Accepted ends the job with an error
requestStatus Queued → LiftAssigned → WaitingForEntry → InTransit → AtDestination → Completed; Failed at any time WaitingForEntry = cabin at the start floor, door open, robot may enter. AtDestination = cabin at the destination floor, door open, robot may leave
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

Floor and door numbering: the controller does not publish it. It is fixed per lift in a table during commissioning (annex B) and configured identically on both sides — in the level-change service and on the robot's technician page (floor ↔ map, lift doors per floor).

6 Sequence of a robot ride

6.1 Sequence

Robot                  Level-change service (site computer)       Lift controller
  |-- drives to waiting point (floor A) ------------------------------->|
  |-- request level change ---->|                                       |
  |                             |-- requestRide(A -> B, exclusive) ----->|
  |                             |<-- Accepted (requestId) --------------|
  |                             |<-- Queued / LiftAssigned(n) ----------|  cabin n travels to A
  |<-- "wait at door n" --------|                                       |
  |                             |<-- WaitingForEntry -------------------|  door A open, T_entry running
  |                             |  plausibility: currentFloor=A, door A open, mode Normal
  |<-- "enter" (drive profile) -|                                       |
  |-- stands in cabin --------->|                                       |
  |                             |-- liftEntered ------------------------>|  door closes, ride A -> B
  |                             |<-- InTransit -------------------------|
  |                             |<-- AtDestination ---------------------|  door B open, T_exit running
  |                             |  plausibility: currentFloor=B, door B open
  |<-- "exit, map B" -----------|                                       |
  |-- map switched, re-localised, standing on anchor point B            |
  |-- "cabin left" ------------>|                                       |
  |                             |-- releaseLift ------------------------>|  exclusive ride lifted
  |                             |<-- Completed -------------------------|
  |-- continues to destination                                          |

6.2 Rules

  1. The robot waits at the waiting point outside the door area, never in front of the light curtain.
  2. Entry only on WaitingForEntry and a plausible liftState (right floor, right door open, mode Normal). If liftState is missing, WaitingForEntry alone counts as release; this is tested explicitly during acceptance.
  3. liftEntered is sent only when the robot has reached its entry position and stands still.
  4. The robot leaves the cabin only on AtDestination and a confirmed destination floor.
  5. releaseLift is sent only when the robot has left the cabin completely and confirmed its position on the destination floor (re-localisation completed). Until then the door stays open (within T_exit).
  6. Per lift exactly one robot job is active at any time. Further robots wait at their waiting points.
  7. After Completed, Failed or abort, releaseLift is always sent (idempotent).

6.3 Drive profile at the sill

The robot drives over the sill into the cabin and out again at a fixed, sufficient speed — approached too slowly, it stops at the sill. The drive profile is set per lift: cabin approach speed (default 0.35 m/s, range 0.2 to 0.5 m/s, never above the vehicle's maximum speed) and sill behaviour (default: no stop at the sill, because the cabin is assigned to the robot). Gap and sill between landing and cabin are measured per lift during commissioning; the profile is set afterwards and checked loaded during acceptance (T21).

7 Timing

Parameter Value (default) Set where Behaviour on expiry
answer to requestRide 15 s site computer job Failed, one retry, then report
wait until WaitingForEntry 180 s site computer abort job, releaseLift, robot stays at the waiting point, report; new attempt after 60 s (at most 3)
door hold time boarding T_entry 60 s (controller); robot reports liftEntered after ≤ 40 s controller controller ends the job (Failed); robot aborts entry and returns to the waiting point
ride (InTransit) 120 s site computer report only, no abort (robot is in the cabin)
door hold time alighting T_exit 90 s (controller); robot reports releaseLift after ≤ 60 s controller controller closes the door; robot, if still inside, stays; site computer sends a new requestRide (destination = current floor)
status polling 1 s site computer –
status stale (no answer) 5 s site computer loss of connection (section 8)
total runtime of a job 10 min site computer job Failed, releaseLift, report

The values 60 s / 90 s replace the 30 s usual for robot interfaces, which are too short for a loaded cabin crossing a lobby. They are measured during acceptance and reduced to 45 s / 60 s if possible.

8 Fault cases and safety

Case Lift Robot Report
loss of connection site computer ↔ lift, robot outside job expires controller-side within T_entry, normal operation stays at the waiting point, does not enter; new job after reconnection "lift not reachable"
loss of connection, robot inside the cabin ride is completed, door opens at destination, T_exit runs leaves only if it recognises the destination floor (map B, re-localisation successful); otherwise stays alarm "robot in cabin, check manually"; staff drives it out by manual operation
loss of connection robot ↔ site computer releaseLift if the robot is outside; otherwise wait for reconnection until T_exit robot stops (own safety logic) alarm
Rejected / AccessDenied / Duplicate – stays at the waiting point; configuration error, no automatic retry report with code to service
OutOfService / fault / maintenance no robot ride stays at the waiting point; job Failed; retry every 5 min; transport job returned after 15 min as "lift out of service" control room
fire-service / emergency operation, evacuation controller aborts the robot job, priority for fire-service/evacuation function outside: stays at the waiting point. Inside: leaves at the next door opening only if it recognises the floor; otherwise stays. Lift rides locked until release alarm; staff removes the robot on instruction of the emergency services
person boards despite exclusive ride light curtain / door supervision as usual does not enter while people stand in the door area (sensors) –
door closes during entry/exit door supervision reopens stops immediately (safety sensors), continues after the door opens event logged
restart of the site computer job expires controller-side service starts without active sessions; sends releaseLift for all known ids as a precaution; robot at the waiting point requests again log
two robots, one lift – site computer serialises; the second robot waits at the waiting point of its floor –

Further rules: operation at the robot (emergency stop, manual drive) stays independent of the lift coupling. All calls and status changes are logged on the site computer with timestamp and requestId (90 days). The controller may lift the exclusive ride at any time; the site computer recognises that via Failed or operatingMode.

9 Door control over u-IoT modules

9.1 What the module provides

Channel Use at a door
output 1 / output 2 (potential-free contact) opening pulse or continuous signal to the door drive ("open door")
input 1 / input 2 optional: feedback "door open" / "door closed" from the door drive, or a push button

The module is switched by the site computer over its REST interface; the state of the output is re-read at the module after every switching. The module itself contains no drive logic.

9.2 What the operator provides

  • Door drive with a potential-free opening input (pulse or continuous, as specified by the door contractor) and, where available, a potential-free feedback "door open".
  • Door safety stays with the drive: light curtain, anti-trap protection, closing force limitation. The robot only triggers the opening.
  • Power supply and network connection of the module inside the protected segment; a time source in the building (the module ships without a set clock).
  • If a module's own wireless network is not needed in operation, it is switched off during commissioning; if it is needed, the building's IT department is informed beforehand.

9.3 How a door is defined in the robot

Per door and per map: name, module and output, zone on the map, opening point, closing point. When the robot reaches the opening point before the zone, the output is switched; at the closing point behind the zone it is withdrawn. Without one of these the door is created but not armed. Doors belong to exactly one map; while the robot's current map is not confirmed, no door is actuated.

9.4 Delays and distances (commissioning values)

Value Meaning Who sets it
door opening time time from the opening pulse to full opening door contractor; determines the distance of the opening point in front of the door (at 0.5 m/s driving speed, 0.5 m per second of opening time)
trigger distance distance of the opening point in front of the door United Robotics Group during commissioning, from the opening time
hold time how long the door stays open after the passage before the drive closes door contractor; at least the time the robot needs to pass with trailer or cart
safety distance area in which the robot stops when the door is closing United Robotics Group during commissioning
pulse duration of the output duration of the opening signal as specified by the door contractor

10 Calls

10.1 Call buttons

A call button is a potential-free push button on an input of a u-IoT module. During commissioning it is assigned to a position on the map (the name of a map point). A press calls the robot to that point.

The call logic — queue, assignment, fallback — lives in the modules: exactly one module per site is the coordinator, the others are participants. The coordinator distributes calls to the registered robots. Open calls are visible on the robot's technician page and can be accepted and completed there.

10.2 Light and sound

Lamps and loudspeakers are outputs of a module (potential-free contact; the signalling device is provided by the operator). During commissioning they are assigned a purpose (light, sound) and are switched by the robot software.

10.3 What the operator provides

  • Buttons and signalling devices with potential-free contacts, wiring to the module.
  • Per call button a destination point in the building (robot's standing place), created as a map point during mapping.
  • Network connection of the modules inside the protected segment (section 11).

11 Network requirements

This chapter is addressed to the operator's IT department.

Point Rule
Site computer as the only gateway robots talk inside the robot network (own Wi-Fi or own VLAN); the building services (lift interface, modules) are in a segment released by the operator. Only the site computer is in both. No other device of the building talks to a robot.
Connections site computer → lift interface HTTPS (TLS 1.2 or newer), one destination port, access key or client certificate per site computer. Firewall rule in this direction only; with event push one return channel to the site computer, also TLS.
Connections site computer → modules HTTP inside the protected segment, port 80 (or the port fixed during commissioning). The modules do not belong in an open building network and not on the internet.
Connections site computer → robots HTTP, port 5301 (the robot's uGo server), with a service key per robot. Chassis: ports 8090, 9000, 9001 from the site computer only; SSH never.
Outbound to the internet only from the site computer and the robots to the uSuite (ports 443 and 8883, TCP) and to the remote support tool of United Robotics Group (ports 443, 5938). Data in Europe, data centre Frankfurt. Lift and door control need no internet access.
Inbound from the internet nothing. No device accepts connections from the internet. Remote support is established from the device and is time-limited: the technician opens the window on the device for 15, 60 or 240 minutes (network guard 1.1.9); afterwards the guard closes by itself.
No drive command from the cloud jobs, maps, tours, doors, calls and lift rides run inside the building. Operation works without an internet connection.
Access from the building network to a robot only with a login (operator or technician) or a service key; without a service password a robot cannot be operated from the network.
Time time server in the building (NTP, port 123/UDP) for site computer, robots and modules.
Addresses and keys kept in a commissioning sheet per site, not in this document. Keys are handed over separately from the document path.
Availability the lift interface in the building runs permanently (no maintenance window during the day without notice); restart time under 5 min.

11.1 Ports on the site computer (rule of 11.09.2026)

Principle of the rule: manufacturer services keep their ports; the services of United Robotics Group move out of the way. The one substantive change is the lift simulator of United Robotics Group, which moved from 8085 to 8185; ports 8080 and 8085 of the manufacturer service stay unchanged. A port list written before 11.09.2026 that carries the simulator on 8085 has to be corrected.

One table, one place

The full port table is on Site computer and building § 5.1 and nowhere else on this portal, so that a port change has exactly one place to be made. The offline document 1.1 carries the table in chapter 11.1; where the two ever differ, the offline document is the leading one and the portal is out of date.

12 Acceptance tests

Prerequisites: lift interface productive, network releases active, floor and door table agreed, at least one robot with maps of all floors involved, lift reserved for the test, minute-taker appointed. During acceptance, rides are triggered through the level-change service on the site computer.

No. Step Expected result
T01 site computer reaches the lift interface (status query without job) liftState with correct floor and door state; latency < 1 s
T02 invalid key AccessDenied, no call triggered
T03 call with start = destination Rejected, lift unchanged
T04 duplicate requestId Duplicate, only one job active
T05 robot ride floor A → B cabin arrives, door stays open until liftEntered, ride without intermediate stop, door stays open until releaseLift, robot reaches destination on map B
T06 return ride B → A as T05
T07 landing call by a person during the robot ride no intermediate stop; call served after releaseLift
T08 car call button during exclusive ride no effect
T09 robot does not report liftEntered (robot held at the waiting point) door closes after T_entry, job Failed, robot stays at the waiting point, report
T10 robot does not report releaseLift (report suppressed) door closes after T_exit, robot stands safely on floor B, job cleaned up
T11 person stands in the door during entry robot does not enter, waits; door stays open
T12 door closes during exit (closing pulse) door supervision reopens, robot stops and continues
T13 network site computer ↔ lift disconnected, robot at the waiting point robot does not enter; new job successful after reconnection
T14 network disconnected, robot in the cabin ride completed, robot recognises floor B and exits; without recognition it stays and an alarm appears
T15 lift "out of service" OutOfService, robot stays at the waiting point, retry after 5 min
T16 fire-service ride during robot ride controller aborts, robot behaves per section 8, alarm
T17 restart of the site computer during an active job after restart releaseLift, lift in normal operation, robot requests again
T18 two robots request at the same time serialised, both rides successful
T19 endurance run, 20 rides in a row 20/20 successful, door hold times logged, proposal for final T_entry/T_exit
T20 log check all jobs with requestId, timestamps and status in the site computer's log
T21 sill: entry and exit with the set drive profile, loaded no obstacle stop at the sill, no getting stuck
T22 door: approach to the opening point door fully open when the zone is reached; output withdrawn at the closing point; feedback at the module correct
T23 door closes during the passage (closing pulse) robot stops within the safety distance; drive reopens
T24 press call button call appears within 2 s with point name; robot drives to the assigned point
T25 disconnect a module from the network technician page shows "not reachable" within 5 s, no frozen state; door stays in a safe state

Acceptance is passed when T01–T18 and T21–T25 are passed and T19 reaches at least 19/20. Signatures operator, lift contractor or integrator, United Robotics Group.

13 Responsibilities

Task Operator (customer) Integrator / lift and door contractor United Robotics Group
provide the interface description of the lift controller assist responsible –
set up the lift interface in the building, release lifts, parametrise exclusive ride and door hold times commission responsible provide values (section 7)
network segment, firewall rules, keys and certificates responsible (IT) assist provide requirements (section 11)
floor and door numbering per lift (annex B) assist responsible document, enter into the robot
waiting and entry points per floor (space in front of the lift, floor marking) responsible – provide specifications, map the points
door drives with potential-free input, buttons, signalling devices, wiring to the modules responsible execute supply module, supply pin assignment
lift adapter in the level-change service – answer queries responsible
test environment of the lift interface (test instance or test lift) assist responsible provide test cases
integration test in the workshop – assist responsible
configuration in the robot (modules, doors, calls, floors, drive profile) – – responsible
acceptance test on site (section 12) acceptance assist perform
operating instruction for staff (robot in cabin, fire service) responsible – provide template
time source, network connection and power supply of the modules responsible – provide requirements

14 What this version provides — and what not

Capability State
level change (waiting point → lift → cabin → map switch → re-localisation → continue) runs in the level-change service on the site computer
lift adapter per site; a message-based adapter for robot-lift interfaces at controller level is implemented and tested against a lift simulator; further adapters per interface description
configuration of modules, doors, calls, floors ↔ maps, waiting points and drive profile robot's technician page, Building tab
test ride from the technician page not in this version; test rides during commissioning through the level-change service
drive profile per lift recorded and validated in the robot; for the ride it is entered in the level-change service during commissioning
doors definition per map on the technician page; actuation by the door service on the site computer
calls call logic in the modules; display, accept and complete on the technician page

15 State of the findings

The internal review of the building functions against the source code recorded twenty findings (A1 to A20). They are the reason why several statements in this document read "not included in this version". No finding is reported as fixed in this version.

As of 06.09.2026 — the re-check against uGo 1.0.8 is still pending (A0c)

The routes and code statements behind these findings were read from uGo 1.0.4. The frozen software level is 1.0.8. Until the re-check is done, every finding below is a finding about 1.0.4.

No. Finding in brief
A1 The drive profile per lift takes effect in the user interface only; the level-change service rides with its own profile.
A2 The test ride from the technician page is disabled.
A3 The door list of the technician page is a local list; no handover to the door service, no test run.
A4 Call actions (ride, sound, light) are stored but not executed.
A5 The lift configuration is kept only; no validation against the lift service, no session state.
A6 Map identity: user interface and service carry the map id differently; the alignment is open.
A7 The notes "accepted" and "completed" live in memory only and are gone after a restart.
A8 Module port: default 80; older interfaces named 8080. A scan over 1024 addresses takes up to 96 s.
A9 A time source cannot be set on the module; the interface only shows its state.
A10 A restart of the device from the technician page is not passed through.
A11 On some devices the service access may answer "caller cannot be verified" (403).
A12 No service in the estate sends the service key; a call button without the header receives 401.
A13 Service key and fleet key are mixed up in older instructions.
A14 The tiles for passwords, service key and service access sit in the "Device" area, not in "Administration".
A15 The statement about the brake on wrong keys in the developer documentation is outdated.
A16 Session ten minutes sliding, session cookie at most eight hours: an operator tablet logs in again every day.
A17 The maintenance tunnel counts as device (loopback); the decision on this is open.
A18 The question who may operate the Building tab is answered in the source code: the technician only, reading included.
A19 Manufacturer and personal names from the source code must never enter a customer document; run the name check on every transfer.
A20 The language decision for the interface pages of the developer portal is open.

The complete list of findings is an internal paper and not part of this document.

Annex A — Terms

Term Meaning
site computer industrial computer of United Robotics Group in the plant room; the only gateway between robots and building services
level-change service service on the site computer with a fixed robot-lift interface (session model) and lift adapters
session / job one robot ride from request to release, identified by requestId
exclusive ride ride without serving passenger calls (special ride, robot mode)
waiting point mapped standing place per floor outside the door area
entry point mapped position inside the cabin
anchor point mapped position on the destination floor where the robot re-localises after the map switch
u-IoT module device of United Robotics Group with two inputs and two outputs; call button, light, sound, door contact
coordinator the one module per site that keeps and distributes calls
service key credential of an automaton (e.g. the site computer) towards a robot; one per robot, generated by the technician

Annex B — Template floor and door numbering (per lift)

Lift (building designation) Interface id Floor (building) Floor number controller Door side Door number controller Waiting point (map point) Remark
e.g. bed lift 3 – ground floor – front – LIFT3-WAIT-F0 kitchen
1st floor – front – LIFT3-WAIT-F1 ward
…

Filled in jointly during commissioning and entered on both sides: in the lift interface and in the robot (floor ↔ map, waiting point, lift doors).

Change history

Version Date Change
1.1 12.09.2026 Software level updated to uGo 1.0.8, Kiosk 1.0.3, network guard 1.1.9 (frozen on 10.09.2026). Service access with a window of 15, 60 or 240 minutes named in chapter 11. New chapter 11.1 with the port rule of 11.09.2026 (lift simulator of United Robotics Group from 8085 to 8185; manufacturer service 8080 and 8085 unchanged). New chapter 15 "State of the findings" (as of 06.09.2026, re-check against 1.0.8 pending, A0c). Contact and publisher added. Released by management on 12 September 2026; QM review pending.
1.0 06.09.2026 First version. Manufacturer-neutral summary of the lift interface, door control and calls over u-IoT modules, network requirements, acceptance tests, responsibilities.

Sales and enquiries: health@unitedrobotics.group. Fault and service: support@unitedrobotics.group.