| Supplement |
Sup-003 |
| Title |
BMS Infrastructure Contract |
| Status |
DRAFT |
| Edition |
2026a |
| Depends On |
CP-001 (VDA 5050 v2.1 pin), Part 3, Part 4, Part 5 |
| License |
CC-BY 4.0 |
1. Scope
This supplement defines the protocol-agnostic BMS infrastructure contract for robot operations in healthcare buildings. It specifies normative request/response schemas for four contract elements: door access, elevator dispatch, zone authorization, and emergency override.
Informative appendices map the normative schema to BACnet, KNX, and OPC UA protocol implementations.
2. Normative References
- Part 1 — Architecture and IT/OT Zones
- Part 2 — Conformance Framework
- Part 3 — Information Model (Location, TimeWindow)
- Part 4 — Service Contracts
- Part 5 — Transport Profile (VDA 5050 v2.1 per CP-001)
- VDA 5050-2 Release 2.1 (2023)
3. Contract Elements
3.1. Door Access Request
The robot SHALL send a door access request to the BMS before entering a zone requiring door authorization. The BMS SHALL respond within the response_deadline (default: 2 seconds).
3.1.1. Request Schema
The door access request SHALL contain the following fields:
request_id |
UUID |
1..1 |
Unique request identifier |
agent_id |
UUID |
1..1 |
Robot requesting access |
task_id |
UUID |
1..1 |
Task authorizing the movement |
door_id |
String |
1..1 |
BMS door identifier |
zone |
String |
1..1 |
Ward/zone from Part 3 Location model |
access_type |
Enum |
1..1 |
normal, emergency, restricted |
time_window |
TimeWindow |
1..1 |
Requested access period (Part 3 schema) |
audit_ref |
UUID |
1..1 |
Orchestrator AuditEvent correlation ID |
response_deadline |
Duration |
0..1 |
Max wait time; default 2s |
3.1.2. Response Schema
The BMS response SHALL contain:
request_id |
UUID |
1..1 |
Echo of request ID |
authorization |
Enum |
1..1 |
granted, denied, pending |
reason |
String |
1..1 if denied; 0..1 otherwise |
Denial reason |
valid_until |
DateTime |
1..1 if granted; 0..1 otherwise |
Authorization expiry |
3.1.3. Behavior
- If
authorization is denied, the robot SHALL NOT enter the zone and SHALL transition to ERROR state per Part 5 §6.1.
- If
authorization is pending, the robot SHALL wait up to response_deadline then SHALL treat as denied if no response.
- If
authorization is granted, the robot SHALL proceed and SHALL re-request before valid_until.
3.2. Elevator Dispatch
The robot SHALL send an elevator dispatch request when floor transitions require elevator use. The BMS SHALL coordinate elevator access with human traffic and emergency operations.
3.2.1. Request Schema
request_id |
UUID |
1..1 |
Unique request identifier |
agent_id |
UUID |
1..1 |
Robot requesting elevator |
task_id |
UUID |
1..1 |
Task authorizing the movement |
elevator_id |
String |
1..1 |
BMS elevator identifier |
floor_from |
String |
1..1 |
Current floor (VDA 5050 building/floor) |
floor_to |
String |
1..1 |
Target floor |
direction |
Enum |
1..1 |
up, down, any |
priority |
Enum |
1..1 |
routine, urgent, emergency |
boarding_status |
Enum |
1..1 |
approaching, at_door, boarding, on_board, exiting |
audit_ref |
UUID |
1..1 |
Orchestrator AuditEvent correlation ID |
3.2.2. Response Schema
request_id |
UUID |
1..1 |
Echo of request ID |
dispatch_status |
Enum |
1..1 |
dispatched, queued, denied |
estimated_arrival |
DateTime |
1..1 if dispatched or queued; 0..1 otherwise |
ETA |
elevator_car_id |
String |
1..1 if dispatched; 0..1 otherwise |
Assigned car |
reason |
String |
1..1 if denied; 0..1 otherwise |
Denial reason |
3.2.3. Boarding Status Updates
After receiving a dispatched response, the robot SHALL publish boarding status updates at each state transition:
approaching |
Robot en route to elevator door |
at_door |
Robot at elevator door, awaiting arrival |
boarding |
Robot entering elevator car |
on_board |
Robot inside elevator, doors closed |
exiting |
Robot leaving elevator at target floor |
3.3. Zone Authorization
The robot SHALL request zone authorization before operating in a specific zone. The BMS SHALL authorize based on building security level, operational status, and time-based policies.
3.3.1. Request Schema
request_id |
UUID |
1..1 |
Unique request identifier |
agent_id |
UUID |
1..1 |
Robot requesting zone access |
task_id |
UUID |
1..1 |
Task authorizing the operation |
zone |
String |
1..1 |
Ward/zone from Part 3 Location model |
zone_type |
Enum |
1..1 |
ward, corridor, restricted, maintenance, clinical |
operation_type |
Enum |
1..1 |
transit, stationary, delivery, cleaning |
duration |
Duration |
1..1 |
Requested authorization period |
audit_ref |
UUID |
1..1 |
Orchestrator AuditEvent correlation ID |
3.3.2. Response Schema
request_id |
UUID |
1..1 |
Echo of request ID |
authorization |
Enum |
1..1 |
granted, denied, conditional |
conditions |
Array[String] |
1..n if conditional; 0..1 otherwise |
Operational constraints (e.g., max_speed_0.5m_s, no_stopping_allowed) |
valid_until |
DateTime |
1..1 if granted or conditional; 0..1 otherwise |
Authorization expiry |
reason |
String |
1..1 if denied; 0..1 otherwise |
Denial reason |
3.3.3. Behavior
- If
authorization is conditional, the robot SHALL comply with all listed conditions and SHALL report condition violations as compliance events per Part 5 §2.2.
- If
authorization expires, the robot SHALL re-request before valid_until and SHALL stop if re-request is denied.
3.4. Emergency Override
The BMS MAY issue emergency commands to all robots. This is a BMS-initiated command. The robot SHALL acknowledge within 1 second.
3.4.1. Emergency Command Schema
command_id |
UUID |
1..1 |
Unique emergency command identifier |
emergency_type |
Enum |
1..1 |
fire_alarm, lockdown, evacuation, general_emergency |
scope |
Enum |
1..1 |
all_zones, zone_specific, floor_specific |
zone |
String |
1..1 if scope=zone_specific; 0..1 otherwise |
Target zone |
action |
Enum |
1..1 |
suspend_all, suspend_non_essential, clear_path, return_to_base |
timestamp |
DateTime |
1..1 |
Command issuance time |
3.4.2. Robot Acknowledgment Schema
command_id |
UUID |
1..1 |
Echo of command ID |
agent_id |
UUID |
1..1 |
Acknowledging robot |
acknowledged |
Boolean |
1..1 |
Always true |
current_zone |
String |
1..1 |
Robot’s current zone |
action_taken |
Enum |
1..1 |
stopped, returning, clearing_path |
acknowledged_at |
DateTime |
1..1 |
Acknowledgment timestamp |
3.4.3. Behavior
- The robot SHALL acknowledge the emergency command within 1 second of receipt.
- The robot SHALL execute the commanded action immediately.
- For
clear_path, the robot SHALL navigate to the nearest passing bay or designated safe zone and transition to STANDBY state.
- For
return_to_base, the robot SHALL navigate to its designated base station using the shortest available path.
4. Safety Requirements
4.1. Safety Clause
Building safety systems remain authoritative at all times. This supplement never overrides fire, life-safety or access-control functions. On loss of BMS authorization the robot SHALL fail safe (stop/yield).
4.2. Communication Failure
- On loss of BMS communication for more than 3 seconds, the robot SHALL stop and transition to ERROR state per Part 5 §6.1.
- The robot SHALL attempt reconnection and SHALL resume operations only after re-establishing BMS authorization.
4.3. Authorization Expiry
- The robot SHALL re-request BMS authorization before
valid_until.
- If re-request is denied or times out, the robot SHALL stop within 2 seconds and transition to ERROR state.
5.1. Test ID Reservation
Test ID series BMS-xx is reserved in the conformance test registry.
| BMS-01 |
Door access request/response |
L1 |
| BMS-02 |
Door access denial handling |
L1 |
| BMS-03 |
Elevator dispatch |
L2 |
| BMS-04 |
Elevator boarding status |
L2 |
| BMS-05 |
Zone authorization |
L2 |
| BMS-06 |
Zone authorization expiry |
L2 |
| BMS-07 |
Emergency override — fire alarm |
L1 |
| BMS-08 |
Emergency override — lockdown |
L1 |
| BMS-09 |
Loss of BMS communication — fail safe |
L1 |
| BMS-10 |
Audit correlation — all elements |
L3 |
| L1 |
Door access + emergency override. Minimum for safe robot operation. |
| L2 |
L1 + elevator dispatch + zone authorization. Full production readiness. |
| L3 |
L2 + audit correlation + multi-site federation. Regional operations. |
6. Transport Binding
BMS infrastructure messages SHALL be transported over MQTT using the rocom/v0/bms/ topic namespace:
| Door access request |
rocom/v0/bms/door/request/{door_id} |
Robot → BMS |
| Door access response |
rocom/v0/bms/door/response/{request_id} |
BMS → Robot |
| Elevator dispatch request |
rocom/v0/bms/elevator/request/{elevator_id} |
Robot → BMS |
| Elevator dispatch response |
rocom/v0/bms/elevator/response/{request_id} |
BMS → Robot |
| Zone auth request |
rocom/v0/bms/zone/request/{zone} |
Robot → BMS |
| Zone auth response |
rocom/v0/bms/zone/response/{request_id} |
BMS → Robot |
| Emergency command |
rocom/v0/bms/emergency/command |
BMS → All robots |
| Emergency acknowledgment |
rocom/v0/bms/emergency/ack/{agent_id} |
Robot → BMS |
| Door access |
AccessDoor |
Write_Property (door lock status) |
| Elevator dispatch |
ElevatorGroup |
Write_Property (car call) |
| Zone authorization |
AccessRights |
Read_Property (access level) |
| Emergency override |
LifeSafetyPoint |
Alarm event |
| Door access |
Door Controller |
DPT 1.001 (1-bit switch) |
| Elevator dispatch |
Car Call |
DPT 1.001 (1-bit switch) |
| Emergency override |
Fire Alarm |
DPT 1.007 (alarm status) |
| Door access |
ns=2;i=1001 (DoorAccess) |
Struct |
| Elevator dispatch |
ns=2;i=1002 (ElevatorDispatch) |
Struct |
| Zone authorization |
ns=2;i=1003 (ZoneAuth) |
Struct |
| Emergency override |
ns=2;i=1004 (EmergencyCmd) |
Struct |