Data centers
A data center adds its own rules to everything in Connecting your robots. Robots come in the way goods do, not through the people's mantrap. Every passage into a data hall or a cage names its job. A tenant approves each visit to its cage. Life safety follows the site's fire panel, room by room. This page covers what's different.
The freight route, not the mantrap
A data center's mantrap counts one person with its own sensors, and no mantrap passes a robot. GET /v1/places lists it with type mantrap. A robot that asks there is refused mantrap_people_only, and retrying doesn't help.
Your robot comes in the way goods do: the loading dock, staging, the freight door and the freight elevator, each a door or elevator like any other. Where an operator does require the mantrap, it sets a person to approve each escorted crossing, and your passage waits for them in AWAITING_APPROVAL, never on a badge alone.
Credentials are the operator's. Your robot's credential lives in the site's own access-control system, not beside it. For a tenant's cage, it's a dated access group, issued when the tenant approves your job and ending with it.
Work orders
Every passage into a data hall or a cage names its job: "work_order": "INC-4102", the ticket or work-order reference. It's 1 to 40 characters: letters and digits, and after the first, also -, _, ., :, / and #. Places that need one carry work_order: true in GET /v1/places. Without it, the passage is refused work_order_required.
Auditors sample work orders against access, so the building keeps the work order with the passage for its retention period (a data center often keeps a year). It's a reference only: the building never acts on it.
Cages and tenant permits
A cage belongs to one of the site's tenants: GET /v1/places lists it with type cage and its tenant. Your robot goes in only on a permit that tenant approved, for that robot and that job, as a colocation work visit names it:
POST /v1/permits
{"cage": "<the cage's ID>", "work_order": "INC-4102", "cabinet": "A1-07", "scope": "Swap the failed drive in slot 3", "minutes": 30}cabinet: the cabinet's number in the cage, up to 20 characters.scope: the job, up to 80 characters.minutes: how long the permit lasts, 5 to 480; 60 if you leave it out. Addsince, a unix time within the next week, to start it later.
The permit is pending until the tenant's own people answer from their portal. Asking again for the same job while one is pending or approved answers with that one. GET /v1/permits lists your robot's permits, and your robot hears each answer in its notices (kind permit, with its status).
At the cage door, a passage with the permit's work order goes through while the permit is approved. Otherwise it's refused: tenant_pending (the tenant hasn't answered yet; retry), tenant_approval (no permit for this robot and work order now) or tenant_revoked. The tenant can revoke a permit at any time. Its people export the record by date and cage for their auditors: who went in, when, on which job and at which cabinet, on whose yes.
What your robot carries through
A passage can name what your robot carries through the door: "carrying": "Replacement drive SN ZL4K21R8; failed drive SN ZL4F09Q2 stays in the tenant's media bin", up to 120 characters. A failed drive is data-bearing media, whose custody auditors check (PCI DSS 9.4). So name the part going in, with its serial number, and where the one it replaced went: left in the tenant's locked media bin, or out for return or destruction on the tenant's order. The tenant's record shows it at its cages. Like the work order, it's a reference, kept for the site's retention and never acted on.
Cameras and radios
Send them on the capability sheet: cameras, and radios, the bands it transmits on (up to 6, each up to 20 characters, such as "Wi-Fi 5 GHz"). Each site approves them. GET /v1/me says what, under sensors: whether cameras may run (cameras), whether they may record inside tenants' cages (recording_in_cages), and which radios (radios). It's null until the site has decided. Your robot keeps to it.
Life safety in a data center
Alarms come from the site's fire panel and building systems, each scoped to a protected room, such as a data hall or a gas-protected electrical room, and for smoke, the containment pod. GET /v1/places tells your robot, for each door, the room it opens into (space), with the room's suppression (gas or pre-action), its emergency power off zone, and the pod the door is in, if one.
The emergency notice works as in any building (emergencies), with these kinds besides. Its scope names the room (room, room_name) and the pod (pod), and its also says what else each asks:
emergency | What your robot is told | Confirm within | also |
|---|---|---|---|
smoke alert | clear and hold. Very early smoke detection in one aisle. No robot is let into the room until it clears | 10 s | Leave that aisle and its containment; stop any heat- or dust-making work anywhere |
pre-discharge | go to zone (the room's safe spot outside), or clear and hold if it can't get there in time | 5 s | Clear doorways and exits; never hold a door open |
discharge | stay put. The agent is in | 10 s | Ask for no door into the room until all clear |
emergency power off | clear and hold. The room's power, cooling and UPS are cut, but not your robot's battery | 10 s | Stop clear of exit paths; stop charging |
power transfer | clear and hold. The UPS hands over to generators in about 10 seconds | 30 s | Start no elevator trip; expect Wi-Fi to drop |
medical | go to zone, or make way: the route from the lobby to the person is kept clear | 20 s | Leave the route from the lobby; give up the freight elevator |
Every emergency notice carries never: never press or block a hold button, emergency power off station or manual release; never hold any door during an alarm; never use an elevator after recall; never treat a door unlocked for egress as permission.
The pre-discharge countdown
A clean-agent room counts down before it discharges. The notice carries seconds (the panel's countdown; 30 is typical), discharge_at (unix time) and clear_by (10 seconds before it). Confirm within 5 seconds.
Your robot is sent to the room's safe spot outside only if it can be there by clear_by. The gateway works that out from the distance along the spot's way in, at the speed_mps on your robot's capability sheet, plus its clear_door_s, the seconds it takes to clear a doorway. Where your sheet doesn't say, it assumes 0.8 m a second and 5 seconds. Otherwise your robot is told to clear its doorway and hold, clear of exits. Never hold a door: a held door lets the agent out. Where each robot was when the countdown ended is kept in words, for the fire official and the insurer.
Chargers in a protected room
A charger inside a protected room loses its power with the room's equipment, at a discharge or an emergency power off. A robot on one hears charger power goes before it, and charger power cut after. Its slot there ends, and no slot there is given meanwhile.
Emergency exits are never a way in
A data center's egress-only doors, with no entry hardware outside, are places of type exit. Asking to pass one is refused egress_only, even when it stands unlocked in an alarm.
Pods and racks
Inside a hall, racks stand in rows, and pairs of rows around a contained aisle make a pod, with a containment door at each end. Alarms name pods (scope.pod), and pod end doors are no-stop areas. The way through a hall follows its aisles, never a row.
No-stop areas
GET /v1/places lists them by floor, as no_stop: door swings, containment doors, exit paths, hold buttons and power-off stations. Your robot may pass through one, but never stop in it, alarm or not. A robot stopped in one past the site's dwell limit (30 seconds unless the site sets another) hears a no-stop notice, and the site's people are told at once. Moving on clears it. The gateway knows where your robot is only from the positions it shares, so share them while it's moving.
The capability sheet for a data hall
The capability sheet adds what a data hall asks:
| Field | What it says |
|---|---|
grounded | It's static-dissipative and bonded to ground, as ASHRAE asks of all mobile equipment in a data hall |
cameras_off_in_cages | It stops its cameras inside tenants' cages |
containment_doors | It opens and closes containment and cage doors itself |
max_temp_c | The hottest air it works in, up to 100. Contained hot aisles run 49 to 54 °C |
clear_door_s | How many seconds it takes to clear a doorway, up to 120. A pre-discharge countdown is checked against it |
radios | The bands it transmits on, for the site to approve |
As everywhere, each POST /v1/profile replaces the whole sheet: send all of it each time.
Try it on the sandbox
The sandbox has a gas-protected room, server-room, on floor 2, behind the badge door secure-door, with a 30-second countdown. Its safe spot outside is Server Room Exit, and its door's swing, Server Room Door Swing, is a no-stop area with a 5-second dwell limit, short so a test doesn't wait long.
Start a drill there with POST /v1/drills {"kind": "pre-discharge", "room": "server-room"}, or "emergency power off", with your robot's position inside the room (on floor 2, at x 0.8 and z 0.8, say). The conformance check runs a pre-discharge drill, an emergency power off drill and a doorway dwell there. See the sandbox.
The sandbox has no mantrap, cages, tenants or work-order places, so permits, work_order and carrying can't be tried there yet.