How to Test an AMR Fleet During a Wi-Fi Outage

What should a good outage drill prove?

A useful AMR outage test is not just pulling access points and seeing what breaks. It is a controlled failure-mode exercise that proves six things in order: each robot stays safe, local autonomy behaves as designed, missions are either queued or rejected cleanly, operators get alerted, the fleet reconnects without confusion, and the site can keep moving with a manual fallback.

Run the drill in layers. Start with one dead zone, then remove a network segment, then make the fleet server unreachable, then simulate a broader wireless outage. For each layer, record what the robot did, what the server believed happened, what the operator saw, and how long recovery took.

That rigor is worth the trouble. In its May 13, 2026 outage analysis, Uptime Institute said outages tied to fiber and connectivity issues are rising and are more likely to cause extended disruptions, and about 1 in 10 operators said their last outage had serious or severe impacts. A real outage is a bad time to learn your robot fleet management stack has hidden assumptions.

Which failure are you actually simulating?

Wi-Fi outage is a broad label. An AMR fleet deployment can fail because the robot loses radio coverage, because roaming degrades at the edge of coverage, because DNS or DHCP disappears, because the fleet server stays up but becomes unreachable, or because a VPN, firewall, or cloud dependency drops while the local network still looks healthy. Those failures do not produce the same robot behavior.

Name the failure mode before the test and keep the test narrow. If you blur local RF loss together with backend loss, you will not know if a missed mission came from navigation logic, dispatch logic, or a networking control plane problem. That is how weak incident reports get written.

• Stage 1: Degraded coverage at the route edge, using a known low-signal zone.
• Stage 2: One access point or VLAN loss, with the rest of the building normal.
• Stage 3: Fleet server unreachable, while robots still have local Wi-Fi.
• Stage 4: Wider wireless outage, followed by a timed and observed recovery.

Set the pass and fail rules before you touch the network

A clean drill starts with written acceptance criteria. Current industrial mobile robot safety work in the US sits under ANSI and A3 R15.08, and ANSI lists ISO 3691-4:2023 for driverless industrial trucks. You do not need to turn the test into a standards seminar, but you do need explicit rules for safe state, restart conditions, speed limits after reconnect, and who is allowed to re-release a stopped robot.

Choose measurable network triggers too. Cisco's WLAN site-survey guidance uses minus 67 dBm minimum signal, 25 dB SNR, and about 20 percent overlap as a conservative roaming benchmark. That is voice guidance, not a robot certification, but it is a sensible threshold for picking coverage-edge test zones during site assessment mapping. If your robots need better radio conditions, use the stricter mark.

What should each robot do when coverage disappears?

This is the heart of the exercise. Some autonomous mobile robots can finish a short local path, avoid obstacles, and stop at a safe hold point after losing contact. Others should stop almost immediately and wait for instruction. Neither behavior is automatically right. The right behavior depends on aisle width, crossing traffic, payload risk, and what hazards exist if a robot keeps rolling without dispatch supervision.

What matters is determinism. The robot should move into one documented state after a defined timeout, and that state should be visible to operators. If the unit is meant to continue locally, verify that it does not accept new cloud-side dispatches, does not reroute into restricted space, and does not keep hunting for a charger it can no longer confirm is available. If it is meant to stop, verify the stop is orderly, legible, and recoverable.

NIST SP 1800-10 notes that denial of service or corrupted communications infrastructure can force manufacturing processes into a fail-safe state, and that a process not designed to fail safe can create equipment damage. Translate that directly into your drill. A pass is not merely motion continuing. A pass is motion staying safe when the supervisory layer is gone.

What should happen to dispatches, queues, and maps?

Mission handling during an outage deserves its own scoreboard. When the fleet server becomes unreachable, every new job should do one clear thing: queue, reject, or hand off to a manual process. Half-accepted missions are poison. They produce duplicate work, stranded carts, and angry operators who think a job is in flight when the robot never received it.

Test the full chain. Launch missions just before the outage, during the outage, and immediately after recovery. Then verify timestamps, acknowledgments, and final status codes. Your site should know exactly how many missions were completed offline, how many were abandoned, how many stayed queued, and whether any map edits, elevator calls, door triggers, or traffic-control reservations went missing during the gap.

How do you test reconnection without hiding data loss?

Many fleets look fine during the outage and fail on the rebound. A robot reconnects, the dashboard turns green, and everyone relaxes while logs, telemetry, and mission history quietly fork into two different stories. That is why reconnection has to be tested as its own event, not treated as the end of the incident.

NIST's OT Backup Quick Start Guide, published June 17, 2026, says OT backups should be created regularly, tested, and reviewed during recovery exercises. Apply that discipline here. Restore any related fleet database backup in a lab, compare it with live records after the drill, and prove that route history, alarms, queue state, and operator interventions reconcile cleanly.

• Capture robot-side event logs and server-side event logs with synchronized time sources.
• Compare mission counts before the outage, during the outage, and 30 minutes after recovery.
• Verify no duplicate mission IDs, no orphaned queue entries, and no missing alarm acknowledgments.
• Check that dashboards, APIs, and exported reports all tell the same recovery story.

Alerts and manual fallback need their own drill

If operators do not know an outage happened, the autonomy question is secondary. CISA advises operators to identify workarounds or manual controls and to test those contingency plans regularly if OT networks need to be taken offline. Your outage test should therefore measure alert delivery, escalation path, and human response time, not just robot behavior.

Build a PACE communications plan for the drill. CISA uses that shorthand for Primary, Alternate, Contingency, Emergency communications planning. For AMR fleet deployment, that usually means the primary path is the fleet UI, the alternate is text or voice alerting, the contingency path is radio or phone, and the emergency path is a pre-briefed floor lead who can halt traffic and switch the route to a manual tug, cart crew, or local operator.

• Who gets the first outage alert, and in how many seconds.
• Who is allowed to pause routes, clear intersections, and release robots after recovery.
• What manual transport method takes over each critical route.
• What paper or offline checklist the shift lead uses until the fleet UI is trusted again.

Why mixed fleets need an integrator view

Outage behavior gets harder when a site runs more than one robot type, or when cleaning, delivery, and material movement share parts of the same network. One fleet may queue jobs locally, another may reject them, and a third may keep moving until a timer expires. Without one playbook, operators are left translating brands in the middle of an incident.

That is where Service Robot Co. fits naturally. We are a full-service commercial robot integrator for US businesses, and our job is not to push one machine. It is to run the robot deployment and integration work across manufacturers, define the failure-mode test, align alerts and recovery steps, train the site team, and support every unit through a nationwide US engineer network. For a mixed fleet, one partner and one number matters most when the network stops being polite.