Skip to content

Integrations — Elevator, Doors (uGate), LIS, Pneumatic tube

Four integrations to systems that are not ours: the building's elevator, its automatic doors, the laboratory information system, and the pneumatic tube installation. Three of them have a released customer document; the fourth is a requirements specification in an internal draft and is listed here so that nobody mistakes it for a product.

Status as of 12.09.2026, evening.

New since the evening of 12.09.2026 — three of these documents are now portal pages

Until now this page named the integration documents and said where the PDFs are filed. Three of them can now be read on the portal itself, in full:

Every integration on this page follows the same two rules, and they are worth reading before the tables:

Two rules that hold for all four integrations

  1. No drive command from outside. An external system places an order or grants a release. It never chooses a vehicle, a route or a target point, it never calls an elevator and never opens a door on its own account.
  2. Safety stays with the system that owns it. The elevator controller stays master of its safety circuit, the door drive of its light barrier and closing force, the LIS of the medical decision. The robot is a passenger, a trigger, or a carrier — never a control instance.

At a glance

Integration Customer document Version Languages Portal page
Elevator (uGo) Service description uGo Elevator Integration 1.0 (12.09.2026) DE, EN, FR, ES, IT, NL Lifts
Elevator — interface partner Requirements document Elevator Interface — URG Requirements for Safe Robot Operation 1.0 (11.09.2026) EN Elevator interface — requirements
Doors (uGate) Service description uGate Door Control 1.0 (12.09.2026) DE, EN, FR, ES, IT, NL Doors, u-IoT Module
LIS (uGo+) Service description uGo+ LIS Integration 1.0 (12.09.2026) DE, EN, FR, ES, IT, NL Laboratory Systems (LIS)
Pneumatic tube Requirements specification (draft) 0.1 (12.09.2026) DE, EN, FR, ES, IT, NL Pneumatic tube — requirements 0.1
Building side (all of the above) Interface description uGo Building Integration 1.1 (12.09.2026) DE, EN, FR, ES, IT, NL Building integration 1.1

The server-side interface behind all building integrations is described on Building API (/api/gebaeude); how the pieces are wired on site is on Site computer and building, which also carries the one port table.

1 Elevator integration (uGo)

Purpose. A mobile service robot uses a passenger or goods elevator without an accompanying person: it requests a ride, enters the cabin, is carried to the target floor and leaves the cabin again. The elevator controller remains master for every safety-relevant function — safety circuit, door supervision, fire service and emergency operation, evacuation. The robot is a passenger with an advance booking.

What URG supplies.

Item What it is
Site computer An industrial computer in the technical room. The only crossing point between the robot network and the building services. No other device in the building talks to a robot; no driving or control command for the elevator comes from the cloud.
Level-change service Carries out the ride on a fixed session model — one session per ride, from request to release, with a unique request identifier: waiting point → request ride → enter → map change → relocalisation → continue. Exactly one robot request per elevator is active at a time; further robots wait at their waiting points. Every step is time-supervised, every call and status change is logged with timestamp and request identifier.
Connection to the manufacturer's interface The adapter to the elevator controller's own interface, with exclusive ride, door hold times, abort rules and the emergency path through the in-cabin floor button.

What the operator provides. An elevator controller with an interface, permanently available, restart time under five minutes. A network segment released by the IT department with one firewall rule in one direction and an access credential per site computer. Floor and door numbering per elevator, fixed jointly at commissioning and entered identically on both sides. A waiting point per floor outside the door area. A passable transition between landing and cabin. Power and LAN in the technical room, a time source in the building, one elevator reserved for the integration and acceptance test with a named minute-taker, and an operating instruction for staff on recovering a robot from the cabin.

The ride in short. The robot waits at its waiting point and requests the level change. The service books an exclusive ride with source and target floor and receives a request identifier. The cabin arrives, the door opens, the service checks floor, door state and operating mode and only then releases the entry. The robot enters, halts at its entry position and reports "entered"; only then does the ride begin. The cabin travels without an intermediate stop. At the target floor the service checks again, releases the exit, the robot leaves the cabin, switches to the map of the target floor and relocalises at the anchor point. Only after it has completely left the cabin and confirmed its position is the elevator released.

Customer documents, version 1.0.

Language File
DE URG_uGo_Aufzuganbindung_Leistungsbeschreibung_DE_V1-0.pdf
EN URG_uGo_Elevator_Integration_Service_Description_EN_V1-0.pdf
FR URG_uGo_Integration_Ascenseur_Description_des_Prestations_FR_V1-0.pdf
ES URG_uGo_Integracion_Ascensor_Descripcion_de_Servicios_ES_V1-0.pdf
IT URG_uGo_Integrazione_Ascensore_Descrizione_dei_Servizi_IT_V1-0.pdf
NL URG_uGo_Liftintegratie_Dienstbeschrijving_NL_V1-0.pdf

Partner document: requirements on the elevator interface, version 1.0. Since the evening of 12.09.2026 the requirements document Elevator Interface — URG Requirements for Safe Robot Operation (EN, 11.09.2026) is filed in the Anbindungen folders alongside the three service descriptions:

File Where
URG_Elevator_Interface_Requirements_EN_V1-0.pdf All Product Information › #0003 uLog Series & uServe › Anbindungen; Sales Kit › URG_Product_Service_Description › Anbindungen; Product Management › #008 Service Descriptions › Anbindungen

It is the requirement list handed to an elevator interface partner for mark-up: sixteen requirements R1–R16, twenty acceptance tests T01–T20, and the call and status model URG sends and expects. Its full content is on Elevator interface — requirements. Two field cases from early September 2026 — an accepted request discarded at the floor, and a request expired by a 30 s timeout with the robot inside the cabin — are the reason it exists; the interim arrangement is 120 s entry and exit timeouts with priority High and exclusive = true.

2 Door control (uGate)

Purpose. A mobile service robot opens an automatic door or gate and passes through it on its own. The robot only triggers the opening: light barrier, anti-trap protection, closing-force limitation and the whole safety chain stay unchanged with the door drive and its manufacturer.

What URG supplies. Two build forms of the u-IoT control device, one board and one firmware in different housings:

Building block Order code Task
uGate — u-IoT door opener UIOT-D Wired to the door drive. Receives the open command over the device-to-device radio link, switches its potential-free output and reports that output's state back. Input 1 can optionally take a "door open" feedback signal from the drive.
Robot bridge — u-IoT bridge UIOT-X Sits on the robot and is powered from the housing of the operating terminal. Tracks pose and planned path and sends the open commands to the responsible uGate. Inputs and outputs stay unused.

Both bring two digital inputs, two digital outputs, a rule-based action engine, a web console and a programming interface. Also part of the supply: the three-zone logic, the times, the set-up, and a test without a robot from the web console. The bridge stores no path of its own — it reads the path the robot has planned. Maps and routes therefore have to be maintained carefully.

What the operator provides. A door drive with a potential-free open input (and, where present, a potential-free "door open" feedback) — without an open input no connection is possible. Supply of 10 to 40 V DC, typically 24 V, at the mounting location. A dry, serviceable mounting location within cable reach, outside the public area. Wiring by a qualified electrician at the terminals provided by the door manufacturer; the safety chain stays untouched. From the door contractor: type of open input, impulse duration, opening time and hold time of the door — the opening time determines the distance of the trigger zone. A network connection in the protected segment; the device does not belong in an open building network and not on the internet. A time source in the building. A notice to the IT department about the device's own access point, which is switched off at commissioning if it is not needed. A free, passable door opening with a turning area in front of the trigger zone.

The passage in short. The robot reports pose and planned path to the bridge. The bridge evaluates five times per second whether a stored door is involved — path crosses the door zone, robot inside the trigger zone, direction of travel towards the door. If all three hold, it sends the open command to the responsible uGate and repeats it once per second. The uGate switches its potential-free contact; the door drive opens the door with its own safety devices and the uGate reports the output state back. Only that counts as "door open". If the confirmation fails to arrive in time, the bridge aborts and the robot halts in front of the closed door — the door keeps being requested and the ride can be repeated. After passing through, the command stops, the contact drops out and the drive closes the door after its own hold time.

Customer documents, version 1.0.

Language File
DE URG_uGate_Tuersteuerung_Leistungsbeschreibung_DE_V1-0.pdf
EN URG_uGate_Door_Control_Service_Description_EN_V1-0.pdf
FR URG_uGate_Commande_de_Porte_Description_des_Prestations_FR_V1-0.pdf
ES URG_uGate_Control_de_Puertas_Descripcion_de_Servicios_ES_V1-0.pdf
IT URG_uGate_Controllo_Porte_Descrizione_dei_Servizi_IT_V1-0.pdf
NL URG_uGate_Deurbesturing_Dienstbeschrijving_NL_V1-0.pdf

3 LIS integration (uGo+)

Purpose. The uLab system — the part of uGo+ that processes sample tubes in the laboratory — works together with the laboratory information system of the building. The division of tasks is the whole point: the LIS decides where a sample is to go; the uLab system takes it there and reports where it stands. The system makes no assumptions of its own about the medical procedure, names no findings and evaluates no results.

What URG supplies. The client side of the protocol: CLSI LIS 1-A and CLSI LIS 2-A over TCP/IP, the uLab system as client and the LIS as server, one data package per message, compact mode so that every message fits into one frame, checksum, delimiters, character set and time format as fixed in the interface specification. Three message types — request, instruction, position update — plus the process-specific data and what the system can determine about a sample at infeed.

What the operator provides. A LIS with an interface to CLSI LIS 1-A / LIS 2-A over TCP/IP that answers requests with a target station — without it no integration is possible. Network connection and releases in the released segment with a firewall rule. A site specification drawn up jointly: stations with identifiers and storage structure, coding of cap colours and tube dimensions, the governing priority, the intermediate target, the target station for invalid samples and for processing errors, and the answer deadline of the LIS. A definition of the scope of the LIS instructions. A contact at the LIS provider, a test path or test window for the acceptance, laboratory staff for the medical responsibility, and an operating instruction for manual interventions.

The sequence in short. The uLab system feeds a sample in and records what the hardware on site can determine. It sends a request with all available details; the LIS answers with an instruction naming the target station; the system brings the sample there and sends a position update on arrival. The same three steps repeat from station to station. Repeat measurements and add-on orders are supported in principle — the LIS can initiate them as an answer to a request or unsolicited; from which situations is defined per site.

Per laboratory, not once for all

The LIS integration is implemented per laboratory. There is no shared, cross-site implementation today, and a statement about "the LIS integration" applies to exactly one site to begin with. A considerable part of the interface is defined per site and belongs in the site specification; the base document alone is never the whole truth for a site. A shared implementation across several sites is not built and has no date. See Integration Status.

Customer documents, version 1.0.

Language File
DE URG_uGoPlus_LIS-Anbindung_Leistungsbeschreibung_DE_V1-0.pdf
EN URG_uGoPlus_LIS_Integration_Service_Description_EN_V1-0.pdf
FR URG_uGoPlus_Integration_LIS_Description_des_Prestations_FR_V1-0.pdf
ES URG_uGoPlus_Integracion_LIS_Descripcion_de_Servicios_ES_V1-0.pdf
IT URG_uGoPlus_Integrazione_LIS_Descrizione_dei_Servizi_IT_V1-0.pdf
NL URG_uGoPlus_LIS-integratie_Dienstbeschrijving_NL_V1-0.pdf

4 Pneumatic tube — requirements specification 0.1 (draft)

Status: not a product, not an offer

For the pneumatic tube there is no service description and no customer document. What exists as of 12.09.2026 is a requirements specification, version 0.1, draft, in DE, EN, FR, ES, IT and NL. It says what would have to be built and what a system manufacturer would have to provide. It is named here so that the gap is visible, not so that it can be quoted in an offer. The full content is on Pneumatic tube integration — requirements specification 0.1: requirements A1–A30, tests T01–T30, and the ten open decisions.

What the requirements specification covers. A consignment arriving by pneumatic tube is brought to the target workplace without staff walking, and a consignment to be sent is brought to the sending station the same way. Every transport order carries one id across its whole lifetime and across both systems. The requirements on the interface of a pneumatic tube system are written so that they can be put to a manufacturer as a questionnaire with yes/no per row. Robot operation does not depend on the integration: if the integration fails, the robots keep driving. And there is an acceptance test that is passed or failed.

Expressly not the subject: any drive command from outside, any intervention by uGo in the system control, replacing the pneumatic tube's throughput, patient data, building a pneumatic tube system, and — in this document — elevator and door integration, which are settled separately.

Two expansion stages.

Stage Handover What it needs
1 — handover by staff A person is the coupling. A press on a call button reaches the robot's uGo server through a u-IoT module; the robot drives to the handover point; the person takes the canister, transfers the contents and acknowledges at a second button; the order continues. Nothing from the pneumatic tube system. There is no connection to it — the system knows nothing of the robot and the robot nothing of the system. This is what is achievable today without involving a system manufacturer.
2 — handover through an interface of the system The system's control computer reports arrival, occupancy and fault to a tube bridge on the site computer, grants the release for the handover and receives the state of the order back. It still does not drive any robot. An interface released by the system manufacturer, plus the decisions in the open-points list. Several of the assumptions this stage rests on — station release signal, canister detection, a control interface or potential-free contacts — are assumptions, not confirmed, and have to be checked per installation.

What is open. Whether stage 2 is wanted at all; the target installation, without which there is no canister dimension, no payload and no interface; canister compatibility; whether arrival is detected by a sensor or started by hand; whether empty canisters are returned; two gaps in our own building blocks (a service key sent by the module firmware, and a state query for machines without a browser session); and the conformity of the coupled assembly. Almost every timing value in the document is marked "to be fixed" rather than estimated.

Documents, version 0.1 (draft).

Language File
DE URG_uGo_Rohrpostanbindung_Lastenheft_DE_V0-1.pdf
EN URG_uGo_Rohrpostanbindung_Requirements_Specification_EN_V0-1.pdf
FR URG_uGo_Rohrpostanbindung_Cahier_des_Charges_FR_V0-1.pdf
ES URG_uGo_Rohrpostanbindung_Pliego_de_Condiciones_ES_V0-1.pdf
IT URG_uGo_Rohrpostanbindung_Capitolato_Oneri_IT_V0-1.pdf
NL URG_uGo_Rohrpostanbindung_Programma_van_Eisen_NL_V0-1.pdf

Where to get them

The three service descriptions 1.0 for elevator, uGate and LIS are customer documents. Colleagues: SharePoint, All Product Information › #0003 uLog Series & uServe, folder Anbindungen — the same folder exists in the Sales Kit under URG_Product_Service_Description. The uGate set is additionally filed under the u-IoT product folder, the LIS set under the uGo LIS Connection folder. Customers and partners: through their URG contact or health@unitedrobotics.group. See Product Documents.

The elevator interface requirements 1.0 (EN) sits in the same Anbindungen folders since the evening of 12.09.2026 — it is a partner document, handed to an elevator interface partner for mark-up, not a customer document. Its source files (Markdown, HTML, build script) are archived in Product Management under #008 Service Descriptions › Anbindungen and in the development document store.

The pneumatic tube requirements specification 0.1 is a draft. It is not in the Sales Kit and is not handed to customers.