Safety

For your engineers and your safety lead, as input to your own risk assessment. The gateway decides whether your robot may use a door or an elevator, commands it, and keeps the record. Your robot still decides when it's safe to move. This page gathers what the gateway does, what it never does, and what stays with your robot. It doesn't replace your own assessment, the building's, or the elevator maker's, and the agreement for each pilot, not this page, says who is liable for what.

What the gateway does

• It fails closed. No answer within your timeout means no: your robot uses its own fallback (wait, reroute, call staff). A refusal always says so, with a reason_code.
• It sends each command once. Resending the same request with the same passage ID returns its status and never sends a second command. A command that may or may not have reached a device when the gateway stopped is never sent again: the passage ends unknown_outcome.
• Only your robot's report completes a passage. A device's acknowledgement never counts as your robot being through.
• It holds every robot in the fire alarm. While the building's fire alarm is on, every robot is held at every door and elevator, calls not yet boarded end, every robot is told, and no door is held open for a robot.
• It tells every robot that may be in the way. A building-wide emergency goes to every robot online; one for a floor or an area goes to the robots placed there, and to the robots online that it can't place whose last floor was that one or is unknown. A robot it can't place is told to clear and hold, or to make way in a make way (who is told).
• It applies the owner's rules to every request, and keeps each decision in an append-only record.

What the building keeps, whatever the gateway does

Four life-safety rules are witnessed on site before a building's first robot company goes live, usually by the elevator partner (Going live):

• Fire service recall ends every robot call, and nothing a robot does can delay it.
• Fire and egress doors keep their code function.
• A lost connection or power returns the equipment to normal, with no held doors and no stuck calls.
• There's no network link to an elevator controller: only the maker's cloud API, or a relay.

The building's own equipment never waits for the gateway or a robot. The gateway carries no safety certification of its own: the life-safety functions stay in the building's equipment, and the gateway never changes them.

What the gateway never does

• Hold a fire or egress door open, or delay recall.
• Treat a door unlocked for egress as permission: a door the building marks as an exit refuses egress_only, unlocked or not.
• See your robot's surroundings. It doesn't know whether a doorway or a car is clear, whether people are in the way, or whether a door actually opened.
• Drive your robot. Your routes, tasks and navigation stay yours; directions are a plan, and they open nothing.

What stays with your robot

• OPEN_COMMANDED is not "the door is open". The door was told to open. Go through when your own sensors say the way is clear.
• CAR_ARRIVED is the elevator system's word. Check that the doors are open and there's room before boarding. Doors close on their own timers and reopen for obstacles, and people ride too.
• Say what you did. Report passed, boarded and exited: the gateway can't see them.
• Stop when held, and keep to every emergency notice's never list.
• In a car, fire recall can end the ride. Get out when the doors open, and report exited.
• A lost connection is your fallback's to handle, mid-passage too. Keep your own timeouts.

Who does what

Testing

Nothing moves in the sandbox. In a building, real doors open and real cars move: test with someone from the site watching, and mark test calls with X-Test-Run so the record shows them as tests (Getting certified).