Pneumatic tube integration — requirements specification 0.1 (draft)¶
What would have to be built so that a consignment arriving by pneumatic tube reaches its target workplace without staff walking, and what a system manufacturer would have to provide for it. This page carries the content of the document Requirements Specification: Pneumatic Tube Integration with uLog/uGo, version 0.1 of 12.09.2026.
Requirements specification 0.1, draft — not a product, not an offer
This is a requirements specification, version 0.1, draft. It is not a commitment and not a service description. There is no released customer document for the pneumatic tube and nothing is built. It says what is missing. It is on this portal so that the gap is visible, not so that it can be quoted in an offer.
It contains no customer or site names, no network addresses and no name of a pneumatic tube manufacturer. The manufacturer is recorded per project in the system sheet (annex B).
Document control
| Item | Value |
|---|---|
| Document | Requirements Specification — Pneumatic Tube Integration with uLog/uGo |
| Version | 0.1 (draft) · status 12.09.2026 |
| Software level under consideration | uGo 1.0.8, Kiosk 1.0.3, network guard 1.1.9 — frozen 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. The document itself stays at draft status 0.1 — releasing the draft does not make it a specification. |
| Languages | DE, EN, FR, ES, IT, NL |
0 Preliminary note — an assumption is withdrawn¶
The instruction of 12.09.2026 assumes that no documentation on pneumatic tube integration exists. After examination this is not correct, and the assumption is expressly withdrawn. Two documents dated 20.08.2026 exist:
| Document | Content |
|---|---|
| Interface Pneumatic Tube ↔ uGo — technical description (20.08.2026) | Role model, decision rule "tube or robot", data fields of a transport order, state model with twelve states and transitions, error cases, delimitation (no drive commands from outside), IT security, list of sources |
| Pneumatic tube requirements letter — template for sales (20.08.2026) | Model letter to manufacturers or hospital IT, catalogue of questions on the system, the interface, the network and the handover points, checklist to tick off |
This requirements specification does not start from zero. It does three things the two documents of 20.08.2026 do not do:
- It separates the evidenced current state from prior knowledge. The technical description of 20.08.2026 carries, under the marking "prior knowledge of the management", the statement that integration with two manufacturers "has taken place and is in operation". The market review of 10.09.2026 contradicts this. The contradiction is open and is put up for decision in section 12, item 1.
- It cuts the subject into two expansion stages and makes every requirement verifiable with an acceptance criterion.
- It names the gaps in our own building blocks (uGo 1.0.8, u-IoT, site computer) that must be closed before an integration can be accepted.
1 Current state¶
Every row carries its evidence level: B = evidenced in a named source · V = prior knowledge from an internal document, not evidenced there · A = assumption by the author, no evidence · U = unknown, to be clarified.
1.1 Our own building blocks¶
| No. | Statement | Level |
|---|---|---|
| I-01 | uGo 1.0.8 accepts an external trigger via POST /api/regeln/aktion, body {"aktion":"taster","kennung":"<button id>"}. A rule on the technician page decides what becomes of it. |
B |
| I-02 | Since access protection was introduced, this call requires a service key: header x-urg-dienstschluessel or — for this single endpoint only — ?schluessel= in the address. Without a key, 401; after five failed attempts, 429 for one minute. A new key invalidates the old one everywhere. One key per device. |
B |
| I-03 | Whether the u-IoT firmware can set this header itself in an HTTP action is not evidenced. If not, the site computer must relay the button press. | U — software |
| I-04 | uGo 1.0.8 offers no status query for automata without a browser session. Today only the response to the POST carries the field planer. |
B |
| I-05 | The u-IoT module has two digital inputs (DI_1, DI_2) and two digital outputs (DO_1, DO_2), a rule-based action engine with the triggers "DI_1 activated", "DI_2 activated" and "System", and the tasks: control an output, send an HTTP request, call a robot and run a uGo workflow. | B |
| I-06 | The HTTP action knows method (GET/POST/PUT/PATCH/DELETE), address, timeout (default 2000 ms), retries (0–5), headers and body (none/JSON/text). A result output can be assigned that switches on at the start and off at the end. | B |
| I-07 | The action "call a robot" requests a robot to a named map point (point name/id, a specific robot or "any available", timeout, optional follow-up action). Prerequisite: the call service is enabled in the coordination tab. | B |
| I-08 | The relay output of the u-IoT is a dry contact: it only switches, it does not supply power. | B |
| I-09 | For the lift there is a worked-out determination with a session model, order id as UUID, plausibility check, time limits, error cases and an acceptance test. That pattern is transferable to the pneumatic tube. | B |
| I-10 | The handshake between fleet and handover station is recorded under ULS-207 as planned — not as implemented. | B |
| I-11 | The uLab Uno service description 2.0 lists pneumatic tube as an optional skill / add-on: the robot takes the canister from a drip tray supplied by URG, opens it with an opening station and processes the contents; re-inserting it into the system is done by the customer. Canisters of 60–100 mm with a twist-and-swivel lock on both ends can be processed, without clip and without locking lug; a secondary packaging with screw cap specified by URG must be used. Additionally required: camera, specification of canister and secondary packaging, landmark, opening station. Per that document the skill is available only as a service model. | B |
| I-12 | In the application layer an object model "Station pneumatic tube" (landmark, unload action, gripper tool for canisters) and a device "pneumatic tube opener" are described; an initialisation is required before the first command. | B |
| I-13 | In an ongoing project the sequence is mapped entirely through uGo — without a programmable logic controller and without a control system. No sensors are planned: arriving canisters are not detected, deposited canisters are not detected; the sequence is started manually by staff at the tablet. Collisions of deposited canisters must be prevented by the sequence itself. | B |
| I-14 | In the same project the following is expressly not in scope: emptying the canister, resealing it, return transport of the empty canister. Whether the canister can be opened at both ends is open. Whether a two-tier return rail is needed is open. | B |
| I-15 | The market review of 10.09.2026 records: for a built and proven pneumatic tube integration, no evidence can be found in our documents. Whether the "pneumatic tube" skill has the status Proven or Ready is open. | B |
| I-16 | The technical description of 20.08.2026 records as prior knowledge of the management that integration with two manufacturers has taken place and is in operation. This is not evidenced there; the concrete protocol details are left open as "to be added by URG". | V |
| I-17 | I-15 and I-16 contradict each other. As long as the contradiction is unresolved, the cautious reading applies for this specification: no evidenced, accepted integration exists. | A |
1.2 Pneumatic tube systems¶
| No. | Statement | Level |
|---|---|---|
| I-18 | There is no standard and no cross-manufacturer agreement for interfaces of pneumatic tube systems — comparable, say, to the agreements for nurse call systems or picking machines. Every integration is an individual agreement with the respective manufacturer. | B (evidence by non-finding, research 20.08.2026) |
| I-19 | None of the four large providers in the German-speaking area has a publicly documented interface to mobile robots. One provider advertises generally with "interfaces to automation robots and software systems", without technical detail. | B |
| I-20 | Pneumatic tube systems are attackable network participants. Nine vulnerabilities have been published for a widespread control panel: memory faults in the control protocol, remote access active by default with hard-coded credentials, unencrypted and unsigned firmware updates. Access lists and network segmentation were recommended. | B |
| I-21 | In a floor plan review of 09.09.2026, two pneumatic tube stations are drawn in a laboratory. Station type, manufacturer and consignment volume are unknown and noted as open questions for the site walk. | B |
| I-22 | Pneumatic tube systems typically offer send and receive stations with a release signal, detection of the canister at the station, and either a control interface or potential-free contacts at the station. | A — expressly an assumption. To be verified per system in the system sheet. |
| I-23 | Canister dimensions, permissible payload, soft-travel mode, exclusion lists for consignment types and the form of authorisation at the collection point differ per system and per building. | B |
1.3 What is expressly unknown¶
| No. | Question |
|---|---|
| I-24 | For which target customer and which system are we building? Without a system there is no canister dimension, no payload and no interface. |
| I-25 | Is expansion stage 2 wanted at all, or does it stay at stage 1? |
| I-26 | Which canister geometry must be supported? The uLab Uno service description names 60–100 mm; in the ongoing project the figures are around 120 mm diameter and a lid diameter of 125 mm. That is outside the range of the service description. |
| I-27 | Can the u-IoT firmware send the service key itself? (I-03) |
| I-28 | Is there a status query for automata in uGo? (I-04) |
| I-29 | What throughput is to be expected per building (consignments per hour at peak)? Without a figure, every statement about relief is an assertion. |
| I-30 | What legal situation applies — is the integration part of a machine within the meaning of the machinery regulation, and who declares the conformity of the assembly? |
2 Problem¶
- Samples that arrive by pneumatic tube lie there until a human collects them. In laboratories with tube reception, staff today cover the distance between the tube station and the workplace. That is the distance the mobile robot exists for. How often this happens and how long it takes is not measured in our documents (I-29).
- Opening the canisters by hand strains the employees. In one project a high rate of absence due to strain on wrist and forearm is the reason for the enquiry. That is an evidenced occasion, but from one building only.
- We sell a skill we cannot evidence. The data sheet and the service description list "pneumatic tube" as a skill; evidence of a built and proven integration is missing (I-15). In the laboratory market, a skill without evidence costs more trust than it earns.
- Without sensors nobody knows when a canister has arrived. In the ongoing project staff start the sequence manually because arriving canisters are not detected (I-13). The benefit thus depends on one person's attention.
- Two systems can dispatch the same consignment. If the pneumatic tube system and the robot fleet may both decide, duplicate transports arise, and in a fault they block each other.
- Our own building blocks have two gaps that affect every acknowledgement via a button: the service key in the module (I-03) and the missing status query for automata (I-04).
3 Objective and non-objective¶
3.1 Objective¶
| No. | What shall apply afterwards |
|---|---|
| Z1 | A consignment arriving by pneumatic tube is brought to the target workplace without staff walking, and a consignment to be sent by pneumatic tube is brought to the sending station without staff walking. |
| Z2 | For the handover between pneumatic tube and robot there is exactly one described form per expansion stage, with an acknowledgement that is logged. |
| Z3 | Every transport order has an id that is carried across its entire lifetime and across both systems. |
| Z4 | The requirements on the interface of a pneumatic tube system are fixed such that they can be put to a manufacturer as a questionnaire with yes/no per row. |
| Z5 | Robot operation does not depend on the pneumatic tube integration: if the integration fails, the robots keep driving. |
| Z6 | There is an acceptance test that is passed or failed — not an impression. |
3.2 Non-objective¶
| No. | What is expressly not the subject |
|---|---|
| N1 | No drive command from outside. The pneumatic tube system, or its control computer, places an order. It does not choose a vehicle, a route or a target point; it does not call a lift and does not open a door. |
| N2 | No intervention by uGo in the system control. No diverter, no blower, no send command out of uGo, unless expansion stage 2 is expressly agreed — and then only via the interface released by the manufacturer. |
| N3 | No replacement of the pneumatic tube. The robot relieves the system of consignments it was never intended for. It does not replace its throughput. |
| N4 | No patient data. A transport order contains places and consignment types, no persons, no diagnoses, no medical orders. |
| N5 | No construction of a pneumatic tube system and no change to existing system technology by URG. |
| N6 | Not the subject here: lift and door integration (see Building integration — interface description 1.1), integration with laboratory and hospital information systems, goods trains. |
| N7 | No emptying, resealing or return transport of the empty canister in expansion stage 1. For stage 2 it is to be decided (section 12, item 6). |
4 System boundaries¶
Pneumatic tube system Handover point uLog / uLab uGo 1.0.8
(customer, manufacturer) (structural, customer) (robot, URG) (URG)
--------------------- -------------- ------------ ---------
Send/receive station ---> Landing position / drip tray ---> Pick-up ---> Order
Control computer Floor space, landmark Opening station Rule/action
Diverters, lines Call button (u-IoT) Camera Log
| ^
+---- u-IoT module: DI/DO, HTTP action --------------+
POST /api/regeln/aktion (service key)
Stage 2 in addition:
Control computer of system <--- LAN/TLS ---> Site computer (tube bridge, URG) <---> uGo
| Building block | Who is responsible | What it does |
|---|---|---|
| Pneumatic tube system incl. control computer | Customer and system manufacturer | Executes tube consignments, reports state and fault. Remains master for everything concerning the system. |
| Handover point (landing position, floor space, landmark, button) | Customer structurally, URG in the determination | The one named place where pneumatic tube and robot meet. |
| u-IoT module | URG | Accepts the staff button press or a potential-free contact of the system and triggers an action. |
| Robot (uLog Deliver, uLab Mobile) | URG | Drives, picks up, hands over; in the laboratory variant additionally gripping, aligning, opening. |
| uGo 1.0.8 | URG | Accepts orders, executes rules, logs. The only writer of drive commands remains the robot itself. |
| Tube bridge on the site computer (stage 2 only) | URG | Translates between the manufacturer interface and our fixed order model. One service per site. |
The seam lies at the handover point. Everything on this side belongs to us, everything beyond to the customer and their system manufacturer. In expansion stage 2 a second seam is added: the interface between the control computer of the system and the site computer. Section 7.2 applies to this second seam.
5 Constraints¶
| No. | Constraint | Effect |
|---|---|---|
| R1 | Installed base at the customer. Pneumatic tube systems run for ten to thirty years. The software level of the control is given and will not be raised for us. | The requirements in section 7 are a questionnaire, not an order. What the system cannot do, it cannot do. |
| R2 | No uniform standard (I-18). | A separate adapter arises for each manufacturer. The effort recurs per manufacturer, not per site. |
| R3 | Approval and CE. The robot carries its own declaration of conformity, the system carries its own. Who declares the conformity of the assembled whole is open (I-30). A mechanical coupling of system and robot can create a new assembly. | To be clarified before the first mechanically coupled setup. Until then the handover point remains a place to set things down, not a coupling. |
| R4 | Data protection. A transport order contains no personal data (N4). Existing default: station names are switched off and are switched on only on express request. Data in Europe, Frankfurt data centre. | The field list in section 8 is exhaustive. Free-text fields may be truncated by either side. |
| R5 | Contracts covering bought-in building blocks. The "pneumatic tube" skill is tied in the uLab Uno service description to a service model (I-11). Whether that stays so is to be checked. | Concerns the form of the offer, not the technology. |
| R6 | Backward compatibility. The calls in section 8 are to be kept stable from first delivery onwards. A field may be added, none may change its meaning. | Concerns uGo and the adapter alike. |
| R7 | Maintenance window. Pneumatic tube systems run around the clock. A test window in live operation is to be agreed with the building; without a test window there is no acceptance. | Section 13, prerequisites. |
| R8 | Staff. In expansion stage 1 the human is part of the sequence. They need a marking at the handover point, a short instruction and feedback on whether their acknowledgement arrived. Without that the button will not be pressed. | Requirements A6 and A10. |
| R9 | Network. Full radio coverage on all travelled routes with seamless roaming between access points. That is the prerequisite projects fail on, not the interface. | Section 10. |
| R10 | No sensors in the installed base. In the ongoing project, arriving canisters are not detected (I-13). | Expansion stage 1 must work without arrival detection. Arrival detection is the subject of stage 2 or of a separate building block. |
6 Use case¶
6.1 The four cases¶
| Case | Direction | Sequence in words |
|---|---|---|
| F1 | Pneumatic tube → laboratory | A canister arrives at the receiving station. It is to be opened and its contents brought to a workplace or into the sample run. |
| F2 | Laboratory → pneumatic tube | A sample or container is to be sent by pneumatic tube. The robot brings it to the sending station; dispatch takes place at the station. |
| F3 | Pneumatic tube → station in the building | A canister arrives; its contents do not belong in the laboratory but at another place in the building. The robot covers the distance. |
| F4 | Diverting | A consignment is intended for the tube, the line is blocked or the target station is full. The consignment shall — if suitable for it — go via the robot. |
F1 and F2 are the core. F3 differs from F1 only in the destination. F4 presupposes expansion stage 2, because it needs a report from the system about its own state.
6.2 Expansion stage 1 — handover by staff¶
Staff u-IoT module uGo 1.0.8 Robot
| | | |
|-- press button ---->| | |
| |-- POST /api/regeln/aktion -------------->|
| | {"aktion":"taster","kennung":"RP-01"} |
| | x-urg-dienstschluessel: urg-… |
| |<-- 200, rule applies ------| |
| | |-- create order ---->|
| | | |-- drives to handover point
|<---------- feedback "robot is coming" (output/display) --------|
| | |<-- at handover pt. -|
|-- take canister, transfer contents, press ack button --------->|
| |-- POST /api/regeln/aktion -------------->|
| | {"aktion":"taster","kennung":"RP-01-Q"}|
| | |-- order continues ->|
| | | |-- drives to destination
Characteristics: there is no connection to the pneumatic tube system. The system knows nothing of the robot, the robot nothing of the system. The human is the coupling. This is the state achievable today without any involvement of a system manufacturer.
6.3 Expansion stage 2 — handover via an interface of the system¶
Pneumatic tube system Site computer uGo 1.0.8 Robot
(control computer) (tube bridge)
| | | |
|-- order / arrival --->| | |
| orderId, place, | | |
| type, urgency | | |
| |-- create order --->| |
| | |-- plan trip ------>|
| | | |-- drives to station
|<-- request handover --|<-- at handover pt.-|<-------------------|
|-- release granted --->| | |
| (station free, | | |
| canister ready) | |-- pick up -------->|
|<-- handover finished -|<-- acknowledged ---|<-------------------|
|-- state: handed over->| | |
Characteristics: the system reports arrival, occupancy and fault; it releases the handover; it receives the state of the order back. It still does not drive any robot (N1).
7 Requirements¶
Every requirement carries an expansion stage, a grade and an acceptance criterion that is passed or failed. The Evidence column says what the requirement rests on: B evidenced, A assumption, F to be fixed.
Must = without this requirement there is no operation. Should = improves availability, operation or evidence; waiving it must be justified and recorded in the system sheet.
7.1 Expansion stage 1 — handover by staff¶
| No. | Requirement | Grade | Acceptance criterion | Evidence |
|---|---|---|---|---|
| A1 | The handover point is a station named in uGo with a unique id, a mapped approach position and a landmark. A handover point without an id does not exist for the integration. | Must | The uGo station list contains an entry with the id; the robot approaches it from three different starting positions and stops within the tolerance fixed in the system sheet. Test T01. | B (I-12) |
| A2 | A button press at the handover point triggers an order in uGo via the u-IoT module: POST /api/regeln/aktion with {"aktion":"taster","kennung":"<id>"}. Which trip results is decided by a rule on the technician page. |
Must | The button press creates an order in uGo with the correct id within the fixed time; the order is visible in the log. Test T02. | B (I-01, I-05) |
| A3 | The call from A2 carries a valid service key — as header x-urg-dienstschluessel or as ?schluessel=. If the module firmware cannot set the header, the site computer relays the button press. |
Must | A call without a key is rejected with 401 and creates no order; a call with a key is accepted. After five failed attempts the server answers with 429 for one minute. Test T03. | B (I-02); the route via the site computer is required as long as I-03 is open |
| A4 | The transfer is acknowledged by the person. The acknowledgement is a second, clearly marked trigger (its own button or a second input on the module), not the same one as the trigger from A2. | Must | Without acknowledgement the robot does not continue but runs into the waiting time limit from A5. With acknowledgement it continues immediately. Test T04. | B (I-05: two inputs per module) |
| A5 | A time limit applies to waiting at the handover point. After it expires the robot frees the place, reports the order as not handed over and drives to its waiting point. A waiting robot blocks a workplace. | Must | If the acknowledgement fails to appear, the robot leaves after the waiting time fixed in the system sheet; the order appears in the log with the reason "not handed over". Test T05. | F — value per system |
| A6 | The person receives feedback on whether their input arrived and whether a robot is coming. At minimum via an output of the u-IoT module (lamp); if a display is present, there in plain text. | Should | A button press switches a visible feedback within one second; a rejected call (401, timeout) switches a distinguishable error feedback. Test T06. | B (I-06) |
| A7 | uGo offers a status query that an automaton can read without a browser session using the service key. Today only the response to the POST carries the field planer. |
Should | A script queries the state with the service key and receives the order state without a prior POST. Test T07. | B — not present today (I-04) |
| A8 | Every order is logged with id, timestamp, triggering id and final state. The retention period is to be fixed. | Must | After ten runs the log contains ten entries with different ids, complete timestamps and a final state. Test T08. | B (I-09); period F |
| A9 | Robot operation is independent of the pneumatic tube system. In expansion stage 1 there is no network connection to the system. | Must | After disconnecting every connection to the system technology and the internet connection, the system executes a complete transport order from trigger to acknowledgement. Test T09. | B |
| A10 | At the handover point the following are affixed: a marking with the station id, a short instruction in the local language of the building, and the assignment of the two buttons. | Should | A person who has been briefed but is unpractised in the sequence performs a handover without asking. Test T10. | A — derived from R8 |
7.2 Expansion stage 2 — requirements on the interface of the system¶
This section is written so that it can be put to a system manufacturer as a questionnaire: one row, one answer yes or no, and on "no" a statement of what is possible instead.
| No. | Requirement on the system | Grade | Acceptance criterion | Evidence |
|---|---|---|---|---|
| A11 | The system can hand over and accept a transport order — with sender place, recipient place, consignment type, weight, urgency, temperature requirement and proof obligation. | Must | An order handed over by the system appears in uGo within the fixed time with all mandatory fields; an order handed over by uGo appears in the system control. Test T11. | B |
| A12 | Every order carries a unique id that both sides carry in every message. Duplicates are detected via this id. | Must | Sending the same id twice creates exactly one order; the second answer is "duplicate". Test T12. | B |
| A13 | The system grants a release for the handover at a station: the station is free, the canister is ready or the loading place is open. | Must | The robot grips only after release. Without release it does not grip and reports an error after the time limit expires. Test T13. | A — assumption (I-22) |
| A14 | The system reports state changes of an order: accepted, in transit, at destination, handed over, completed, faulted, cancelled. | Must | A complete run produces the state sequence without gaps and in the correct order; no state jumps backwards except out of "faulted". Test T14. | B |
| A15 | The system allows occupancy and operating state of a station to be read: free, occupied, full, blocked, out of service, maintenance. | Must | If a station is blocked by hand, the query reports "blocked" within the fixed time, and uGo sends no more robots there. Test T15. | A — assumption (I-22) |
| A16 | The system delivers rejection and error codes from a fixed, documented list. At minimum: rejected, duplicate, station out of service, no access, timeout, line blocked, station full. | Must | Each of the named cases is triggered in the test and delivers the corresponding code; an unknown code leads in uGo to "faulted" with plain text, not to a silent continuation. Test T16. | B |
| A17 | An order can be cancelled at any time; the cancellation is idempotent. | Must | Cancelling the same order twice leaves the same final state and no error message. Test T17. | B |
| A18 | Time limits for release, handover and collection are adjustable per station and documented. | Must | A changed value takes effect after being applied without restarting the system; the effective value can be read back. Test T18. | B |
| A19 | Access is authenticated and encrypted (TLS 1.2 or higher), with an access key or client certificate per site computer. No anonymous access. The authorisation permits only the calls in section 8 and only the released stations. | Must | Access without a valid key is rejected and logged. Access to a station that is not released is rejected. Test T19. | B (I-20 justifies the strictness) |
| A20 | The software level of the system control from which the interface is available is named; the calls remain backward compatible within a major version. | Must | The manufacturer states the software level and the compatibility commitment in writing; the statement is recorded in the system sheet. Test T20 (document check). | B (R1, R6) |
| A21 | State changes are reported as an event (callback or message channel) instead of by polling. | Should | A state change reaches the site computer without polling; if the event path fails, polling takes over as fallback. Test T21. | B |
| A22 | The system delivers an id of the canister (imprint, transponder or consignment number) so that consignment and order can be brought together. | Should | On an arrival the message contains a canister id; two consecutive arrivals carry different ids. Test T22. | A — assumption (I-22) |
| A23 | If a control interface is missing, the system provides at least potential-free contacts at the station: one output "canister arrived / station occupied" and one input "handover finished / release". | Should | The output switches on an arrival and is detected by the u-IoT module; the input is switched by the module and the system reacts. Test T23. | A — assumption (I-22); module side evidenced (I-05, I-08) |
| A24 | The manufacturer provides a test facility: test system, simulation or a test window on the real system. | Must | Before on-site acceptance, at least one complete run against the test environment is logged. Test T24 (evidence). | B |
If A11 cannot be fulfilled, expansion stage 2 is dropped for that system. What remains is the organisational division of labour without data exchange — that is, expansion stage 1. That is a permissible outcome and not a failure; it is to be recorded in the system sheet.
7.3 Cross-cutting requirements¶
| No. | Requirement | Stage | Grade | Acceptance criterion | Evidence |
|---|---|---|---|---|---|
| A25 | No drive command goes over the interface: no target point, no route, no speed, no vehicle selection. An order that names a specific vehicle is rejected. | 1+2 | Must | A test call with a vehicle statement or a target coordinate is rejected with a reason and creates no trip. Test T25. | B |
| A26 | An order contains no personal data: no name, no case number with meaning outside, no diagnosis, no medical order. Free text is limited and may be truncated by either side. | 1+2 | Must | A check across one hundred logged orders finds no field with a personal reference. Test T26. | B (R4) |
| A27 | Container and load limits are fixed per system before the first commissioning: outer diameter, length, lid diameter, empty weight, permissible payload, type of closure, opening direction, whether it opens at both ends. | 1+2 | Must | The system sheet (annex B) is fully completed and countersigned by application and mechanics before a gripper is ordered. Test T27 (document check). | F — conflict between I-11 and I-26 open |
| A28 | The landing position is unambiguous: arriving canisters lie at the same place, in the same orientation, without one canister touching another. Where the system does not achieve this, a drip tray supplied by URG or a storage surface with a fixed order achieves it. | 1+2 | Must | Twenty consecutive arrivals lie within the position tolerance fixed in the system sheet; no two canisters touch. Test T28. | B (I-11, I-13) |
| A29 | On failure of the interface (network, control computer, maintenance) both sides buffer their messages and deliver them afterwards in order. New external orders are not accepted for the duration of the fault. The robots keep driving. | 2 | Must | After five minutes of disconnection all state messages created in that time have been delivered in the correct order; no order is lost, none duplicated. Test T29. | B |
| A30 | For each system a system sheet (annex B) and a commissioning record are created with date, checked points, software levels of both sides and the functions of the checking persons. Ports, addresses and keys appear only there, never in a document that is handed out. | 1+2 | Must | Both documents are signed before operation begins. Test T30 (document check). | B |
8 Messages and signals¶
The calls are described functionally. The encoding (JSON, XML, fixed-position record), the field names and the field lengths on the manufacturer side are fixed per manufacturer in the adapter and recorded in the system sheet.
8.1 Expansion stage 1¶
| Signal | Direction | Content | Evidenced? |
|---|---|---|---|
| Button press, trigger | Button → u-IoT → uGo | POST /api/regeln/aktion, body {"aktion":"taster","kennung":"<station id>"}, service key |
B (I-01, I-02) |
| Button press, acknowledgement | Button → u-IoT → uGo | as above, own id | B |
| Feedback to staff | u-IoT → lamp/display | Result output of the HTTP action: on at start, off at end | B (I-06) |
| Potential-free contact of the system (if present) | System → u-IoT DI_1/DI_2 | "canister arrived" or "station occupied" | A (I-22) |
| Status query by an automaton | Automaton → uGo | not present today | B — gap (I-04) |
8.2 Expansion stage 2 — fixed calls of the tube bridge¶
| Call | Direction | Fields | Meaning |
|---|---|---|---|
auftragStellen |
System → bridge, or bridge → system | auftragId, erzeugtAm, quelle, absenderStelle, empfaengerStelle, art, gewichtG, dringlichkeit, conditionally abmessungenMm, temperaturanforderung, nachweispflicht, wunschzeitBis |
Register a transport need |
uebergabeAnfordern |
Bridge → system | auftragId, stationId, richtung (entnahme/aufgabe) |
The robot is at the handover point and asks for release |
uebergabeBeendet |
Bridge → system | auftragId, stationId, ergebnis (erfolgreich/abgebrochen), grund |
The robot has finished; the station is free again |
auftragAbbrechen |
both directions | auftragId, grund |
End the order; idempotent |
zustandLesen |
Bridge → system | auftragId or stationId |
Only when polling; dropped with event push |
| Message | Direction | Values |
|---|---|---|
auftragAntwort |
System → bridge | angenommen, abgelehnt, duplikat, ausserBetrieb, keinZugriff |
auftragZustand |
both directions | angelegt → disponiert → bereitstellung → wartetAufAufgabe → unterwegs → amZiel → uebergeben → abgeschlossen; at any time gestoert, umdisponiert, abgebrochen |
stationZustand |
System → bridge | frei, belegt, voll, gesperrt, ausserBetrieb, wartung |
uebergabeFreigabe |
System → bridge | freigegeben, wartet, verweigert with reason |
The state names are taken from the technical description of 20.08.2026, so that the adapter and the existing document speak the same language.
9 Timing¶
None of these figures has been measured
Only the three rows marked B are evidenced. All others are proposals that are to be fixed before acceptance and measured afterwards.
| Parameter | Stage | Proposal | Behaviour on expiry |
|---|---|---|---|
| Timeout of the HTTP action in the u-IoT | 1 | 2000 ms (firmware default) — B | Retry per setting (0–5) |
| Retries of the HTTP action | 1 | 0–5 adjustable — B | Error feedback after the last retry |
| Throttle after failed service key attempts | 1 | five failed attempts, then 60 s block — B | 429; the module must wait |
| Response time of uGo to the button press | 1 | to be fixed | Feedback "error" at the handover point |
| Waiting time of the robot at the handover point until acknowledgement | 1 | to be fixed per system | Robot frees the place, order "not handed over" (A5) |
Response time of the system to uebergabeAnfordern |
2 | to be fixed | Order "faulted", robot frees the place |
| Validity period of a handover release | 2 | to be fixed | The release lapses, the robot does not grip |
| Polling interval when polling | 2 | to be fixed | – |
| State stale (no answer) | 2 | to be fixed | Loss of connection (section 10) |
| Total run time of an order | 1+2 | to be fixed | Order "cancelled", report |
| Retention of the logs | 1+2 | to be fixed | – |
The lift determination of 06.09.2026 works with door hold times of 60 s and 90 s. These values are not transferable to the pneumatic tube; they come from a different sequence with a different hazard. They are expressly not entered here.
10 Error cases¶
Principle: the pneumatic tube system is master for everything concerning its technology. The robot is a collector and a sender, never a control instance. Second principle: whoever detects a fault reports it immediately. If neither side can resolve it, a human learns of it — with place, order id and reason. A fault that appears only in a log is not a reported fault.
| Case | Stage | System | Robot / uGo | Report |
|---|---|---|---|---|
| Staff do not acknowledge | 1 | – | The robot waits until the time limit, then frees the place; order "not handed over" | Feedback at the handover point; log entry |
| Button without a valid service key | 1 | – | 401, no order; after five attempts 429 for one minute | Error feedback at the module; log entry |
| Module unreachable (power, radio) | 1 | – | No order. There is no silent alternative route. | Absent feedback; the staff call the service |
| Robot blocked at the handover point (route obstructed) | 1+2 | – | uGo reports "faulted" with a reason; escalation only after the deadline | Control room; in stage 2 additionally to the system |
| Two canisters lie inside one another / storage full | 1+2 | – | The robot does not grip, reports "faulted"; the sequence is halted | Feedback at the handover point |
| Station full, canister not removed | 2 | detects and reports | uGo sends no more robots there | To the staff of the target place |
| Line blocked / system out of service | 2 | detects and reports | Affected orders go to "faulted"; re-dispatch to the robot only if the consignment is suitable | Control room and building services |
| Release fails to appear | 2 | – | The robot does not grip, waits until the time limit, frees the place | Control room |
| Interface unreachable | 2 | buffers | buffers, delivers in order afterwards; accepts no new external orders; the robots keep driving | Control room; the building falls back to expansion stage 1 |
| Contradictory dispatch (both sides dispatch the same consignment) | 2 | – | Must not occur: dispatch lies at exactly one place. If it does occur, the order with the older id wins; the younger goes to "cancelled" with reason "duplicate" | Control room |
| Unknown error code of the system | 2 | – | "faulted" with plain text, no silent continuation | Control room |
| Fire, emergency stop, evacuation | 1+2 | System per its own rule | Fleet into the safe state; running orders "faulted". This path does not run over the pneumatic tube interface but over the existing potential-free contact of the building services | Alarm |
| Restart of the site computer | 2 | – | The bridge starts without active sessions; sends uebergabeBeendet as a precaution for all known ids |
Log |
11 Network and IT security¶
The occasion is stated in I-20: nine vulnerabilities have been published for a widespread control panel of pneumatic tube systems. Two sentences follow from that, which should be said before any offer rather than waiting for the hospital IT to say them: the integration must not tear a new hole in the network segmentation of the system, and URG raises the topic itself.
| Point | Determination |
|---|---|
| Expansion stage 1 | No connection to the system technology. The u-IoT module addresses only the robot. The pneumatic tube system remains untouched. This is the simplest case in security terms and an argument for stage 1. |
| Connection in stage 2 | Site computer → control computer of the system, TLS 1.2 or higher, one target port, a named address, recorded in an access list — in both directions. With event push, a return channel to the site computer, likewise encrypted. |
| Network segments | Robot and site computer in a separate segment released by the building IT. The segmentation of the pneumatic tube components remains in place; the integration is added as a single rule, not as an opening. |
| Authentication | Access key or client certificate per site computer, issued by the manufacturer or the building. Handover separate from the document route. Keys are stored encrypted on the site computer. Never by e-mail. |
| Authorisation | The key may address only the calls in section 8 and only the stations released for robot operation. |
| Service key in uGo | One key per device, created on the technician page, shown once, stored hashed. Renewal invalidates the old one everywhere. |
| No internet | No internet access is needed for the integration. Remote maintenance only as a session over the maintenance access released by the building, logged. |
| Data storage | Data in Europe, Frankfurt data centre. Maps, floor plans and camera images do not leave the installation. |
| Addresses and keys | Appear in the system sheet, never in this or any other document that is handed out. |
| Time | A common time source on both sides. Without synchronised clocks no evidence can be evaluated. |
| Radio network | Full coverage on all travelled routes, with seamless roaming between access points. To be measured before any commitment. |
12 Open decisions¶
This requirements specification cannot answer these points. They are decided, not filled in. The named deciders are recorded in the internal copy; here only the decision and its effect.
| No. | Decision | Effect if left open |
|---|---|---|
| 1 | Resolve the contradiction: does the statement "integration with two manufacturers has taken place and is in operation" (I-16) hold, or the finding of the market review that no evidence exists (I-15)? If it holds: where is the evidence, which systems, which software level? | Without resolution, every statement about pneumatic tube in an offer is open to attack. |
| 2 | Target customer and system. For which system are we building? Without a system there is no canister dimension, no payload, no interface, no gripper. | Section 7.2 remains a questionnaire without an addressee. |
| 3 | Is expansion stage 2 wanted? Or does it stay permanently at stage 1 with the human in the middle? | Without a decision, a bridge is being developed that nobody has ordered. |
| 4 | Container compatibility. 60–100 mm with a twist-and-swivel lock on both ends (I-11), or around 120 mm diameter and a 125 mm lid diameter (I-26)? Which range is product, which is special construction? And does the large diameter load the gripper beyond its torque? | The service description is wrong or incomplete on this point. |
| 5 | Arrival detection. Does it stay with the manual start by staff (I-13), or is a detection built — sensor at the landing position, camera or potential-free contact of the system (A23)? | Without detection the benefit depends on one person's attention. |
| 6 | Return of empty canisters. Is it in scope (F2 in full) or not (N7)? | Affects mechanics, sequence and offer price. |
| 7 | Who closes the two gaps in our building blocks — the service key in the module firmware (I-03) and the status query for automata (I-04)? And in which version of uGo? | Without the first, the site computer must relay the button press; without the second, no automaton can read the order state. |
| 8 | Conformity of the assembly. Does a mechanical coupling of system and robot create a new assembly, and who declares its conformity? | Until then the handover point remains a place to set things down, not a coupling. |
| 9 | Relationship to ULS-207. The handshake fleet ↔ handover station is planned (I-10). Is the pneumatic tube a special case of that handshake or a separate route? | Two routes for the same problem cost more than one. |
| 10 | Relationship to the documents of 20.08.2026. Will the technical description be continued and this requirements specification carried as its requirements part, or do the two papers remain separate? | Two papers on the same subject drift apart. |
13 Responsibilities¶
| Task | Customer / building | System manufacturer | URG |
|---|---|---|---|
| Complete the system sheet (annex B) | contribute | responsible for the system details | consolidate |
| Provide the interface description (stage 2) | contribute | responsible | review and report back |
| Prepare the handover point structurally (floor space, approach without manoeuvring, not in the escape route) | responsible | – | supply specifications |
| Exclusion rule on what must not go into the tube | responsible (laboratory, pharmacy, transfusion officer) | – | supply the structure |
| Network segment, access list, keys | responsible (building IT) | contribute | supply requirements (section 11) |
| Radio network on the travelled routes | responsible | – | measure and assess |
| Test window in live operation | responsible | contribute | supply test cases |
| u-IoT module, wiring of the button, feedback | – | – | responsible (network and hardware) |
| Service key, status query, uGo rule (I-03, I-04) | – | – | responsible (software and releases) |
| Gripper, opening station, drip tray, landing position | – | contribute (canister dimensions) | responsible (mechanics) |
| Sequence, skill, landmarks, acceptance of the application | contribute | – | responsible (application) |
| Tube bridge and manufacturer adapter (stage 2) | – | answer queries | responsible (software) |
| Acceptance test (section 14) | acceptance | contribute | carry out |
| Operating instruction for the staff | responsible | – | supply a template |
14 Acceptance test¶
Prerequisites: system sheet completed and countersigned, handover point built and mapped, buttons wired, service key created, radio network measured, test window agreed, record keeper named. For stage 2 in addition: interface enabled, network route released, manufacturer test environment reachable.
A test counts as passed if the expected result occurs and appears in the log.
| No. | Req. | Stage | Step | Expected result |
|---|---|---|---|---|
| T01 | A1 | 1 | Approach the handover point from three different starting positions | The robot stops each time within the position tolerance of the system sheet |
| T02 | A2 | 1 | Press the trigger button | An order with the correct id arises in uGo and appears in the log |
| T03 | A3 | 1 | Call without a key; then five failed attempts; then a valid key | 401 without an order; after the fifth attempt 429 for one minute; with a valid key 200 and an order |
| T04 | A4 | 1 | Handover without acknowledgement, then with acknowledgement | Without: the robot does not continue. With: it continues immediately |
| T05 | A5 | 1 | Deliberately omit the acknowledgement | The robot frees the place after the waiting time expires; order "not handed over" in the log |
| T06 | A6 | 1 | Valid button press; then a button press with the network disconnected | Visible feedback within one second; in the second case a distinguishable error feedback |
| T07 | A7 | 1 | Query the state with the service key without sending beforehand | The order state is delivered. Expected today: not passed (I-04) |
| T08 | A8 | 1 | Ten consecutive runs | Ten log entries with different ids, complete timestamps, final state |
| T09 | A9 | 1 | Disconnect the internet connection; disconnect every connection to the system technology | A complete transport order runs through from trigger to acknowledgement |
| T10 | A10 | 1 | A briefed but unpractised person performs a handover | The handover succeeds without asking |
| T11 | A11 | 2 | Hand over an order from the system; hand over an order to the system | The order appears on the other side with all mandatory fields |
| T12 | A12 | 2 | Send the same order id twice | Exactly one order; second answer "duplicate" |
| T13 | A13 | 2 | Request handover, withhold the release; then release | Without release the robot does not grip and reports an error after the time limit; with release it grips |
| T14 | A14 | 2 | Complete run | The state sequence is complete and in the correct order; no backward jump except out of "faulted" |
| T15 | A15 | 2 | Block the station by hand | The query reports "blocked"; uGo sends no more robots there |
| T16 | A16 | 2 | Trigger every error case from A16; then inject an unknown code | The corresponding code each time; an unknown code leads to "faulted" with plain text |
| T17 | A17 | 2 | Cancel the same order twice | Same final state, no error message |
| T18 | A18 | 2 | Change a time limit and read it back | The new value takes effect without a restart and can be read back |
| T19 | A19 | 2 | Access without a key; access to a station that is not released | Both rejected and logged |
| T20 | A20 | 2 | Check the manufacturer's written statement on software level and compatibility | The statement exists and appears in the system sheet |
| T21 | A21 | 2 | Disconnect the event path | Polling takes over as fallback; no state is lost |
| T22 | A22 | 2 | Two consecutive arrivals | Two different canister ids in the messages |
| T23 | A23 | 2 | Trigger the potential-free contact of the system; switch the contact from the module | The module detects the arrival; the system reacts to the release signal |
| T24 | A24 | 2 | Present evidence of a complete run against the test environment | The log exists, dated, before on-site acceptance |
| T25 | A25 | 1+2 | Call with a vehicle statement or a target coordinate | Rejected with a reason; no trip |
| T26 | A26 | 1+2 | Check one hundred logged orders for personal reference | No field with a personal reference |
| T27 | A27 | 1+2 | Check the system sheet for completeness | All container and load details completed and countersigned |
| T28 | A28 | 1+2 | Twenty consecutive arrivals | All within the position tolerance; no two canisters touch |
| T29 | A29 | 2 | Disconnect the connection for five minutes | All messages delivered afterwards in the correct order; no order lost or duplicated |
| T30 | A30 | 1+2 | Check the system sheet and the commissioning record | Both exist, signed |
Acceptance of expansion stage 1 counts as passed if T01–T06, T08–T10, T25–T28 and T30 are passed. T07 is expected today not to pass (I-04) and is carried into the commissioning record as an open item.
Acceptance of expansion stage 2 counts as passed if T11–T21, T24 and T29 are passed in addition. T22 and T23 concern "should" requirements; a failure must be justified and recorded in the system sheet.
Annex A — Terms¶
| Term | Meaning |
|---|---|
| Canister | The container that travels in the pneumatic tube system. |
| Handover point | The one named place with an id where pneumatic tube and robot meet. Without an id it does not exist for the integration. |
| Landing position | The place where an arriving canister comes to rest, including the order of the storage. |
| Drip tray | Component supplied by URG that brings the arriving canister into a known orientation. |
| Opening station | Device with which the robot releases the lid of the canister. |
| Tube bridge | Service on the site computer with a fixed order model and one adapter per manufacturer (expansion stage 2 only). |
| Site computer | Computer in the technical room on which the building services run. |
| u-IoT | Module built by URG with two digital inputs, two digital outputs and a rule-based action engine. |
| Call button | Button that triggers an order in uGo via u-IoT. |
| Service key | Key per device with which an automaton may work against uGo without a browser session. |
| Order id | The one key across the entire lifetime of a transport order, carried on both sides. |
| Dispatch | The role that decides whether a consignment goes through the tube or via the robot. Exactly one place per building. |
| System sheet | The sheet per system with all values, addresses and keys. Does not leave the project. |
| Must / Should | Must: without this requirement there is no operation. Should: waiving it must be justified and recorded. |
| Evidence level B / A / F / U | Evidenced / assumption / to be fixed / unknown. |
Annex B — System sheet template (to be completed per system)¶
Completed during preparation and countersigned by application, mechanics and software. It contains the values that this requirements specification deliberately leaves open.
| Field | Value |
|---|---|
| Designation of the system (internal) | |
| System manufacturer, type, year of construction | |
| Software level of the control | |
| Number of stations, lines, diverters | |
| Canister: outer diameter / length / lid diameter | |
| Canister: empty weight / permissible payload | |
| Canister: type of closure, opening direction, opens at both ends? | |
| Soft-travel mode available? | |
| Exclusion list of the building available? | |
| Station id of the handover point in uGo | |
| Position tolerance at the handover point | |
| Landing position / drip tray: design | |
| Id of trigger button / id of acknowledgement button | |
| Waiting time at the handover point | |
| Retention period of the logs | |
| Expansion stage (1 or 2) | |
| Stage 2: interface present? Form? | |
| Stage 2: response time, release duration, polling interval | |
| Stage 2: address, port, authentication | |
| Network segment, access list, releasing party | |
| Radio network measurement: date, result | |
| Test window: agreed with, period | |
| Unfulfilled "should" requirements and justification |
Related pages on this portal¶
- Integrations — all four integrations side by side, and why the pneumatic tube has no customer document
- Integration Status — the pneumatic tube row and the unresolved contradiction
- Building integration — interface description 1.1 — the lift and door determination whose session pattern this document borrows
- u-IoT Module
Contact: health@unitedrobotics.group. Faults: support@unitedrobotics.group.