A worked example: from one timeout to an acceptance plan

The line

Picture one automotive assembly line served by twelve autonomous mobile robots of one published model. The plant, the fleet size, and every setting below are made up for this example. The robot's published values come from its entry in the requirements database.

Suppose each robot carries a small safety I/O module that talks to the line's safety controller over CIP Safety at its default settings. That module is an assumption of this example, not something the robot maker publishes.

Two more assumptions, each marked where it is used. The wired path and the endpoints take 5 ms, and the safety traffic is a 100-byte frame every 10 ms in each direction, marked as voice. Measure both on your own system.

Vehicle

MiR1350 (published values)

Environment

Automotive assembly

Safety connection

CIP Safety input connection at its default settings (assumed)

Wired path and endpoints

5 ms (assumed; measure yours)

Vehicle speed

1.2 m/s (the robot's published top speed)

Fleet

12 vehicles on one channel (assumed)

1. The outage budget

The tightest clock on the link sets the budget, and the wired path spends part of it before the radio gets any.

• The tightest timeout on this link is the CIP Safety input connection: 40 ms (RPI x (timeout multiplier + network delay multiplier)).
• After 5 ms for the wired path and the endpoints, the wireless network may never cause a gap longer than 35 ms: not in a roam, a scan, a rekey, or retries queued behind a large transfer.

2. Whether a roam fits

The roam is the longest regular gap a moving vehicle sees, so it has to fit inside that budget. Published ranges for each roaming method show where to start, not what your vehicles will do.

• PSK four-way handshake (no fast roaming): 55 ms to 520 ms published, which exceeds the budget.
• 802.11r fast BSS transition: 15 ms to 90 ms published, which crosses the budget: some published results fit, the worst do not.
• Vendor fast-roam and make-before-break schemes (vendor claim): 63 ms to 150 ms published, which exceeds the budget.

No published range sits wholly inside 35 ms. The design has to use the fastest method these vehicles support, and then the worst gap has to be measured on the vehicles themselves.

No usable published range, so these can only be measured: Full 802.1X reauthentication; PMK caching and opportunistic key caching; Wi-Fi 7 multi-link operation; 802.11bn seamless mobility domain.

At 1.2 m/s, the vehicle travels 0.04 m during the outage budget.

Open this in the Requirements translator

3. Airtime on the channel

Timing is half the check. The fleet's traffic also has to fit on one channel under the robot maker's published utilization ceiling. The ceiling here is 60%, the figure the robot maker publishes.

• One vehicle's traffic takes 3.148% of the channel's airtime at 86 Mbps, counting the waits, preambles, and acknowledgements each frame needs.
• Under a 60% utilization ceiling, 19 vehicles fit, with 0.188 percentage points to spare. That ceiling has to cover everything else on the channel too: other clients, beacons, and neighbors.
• Your 12 vehicles together take 37.78% of the channel.
• Only 17% of each of its exchanges is the data itself; the rest is fixed overhead. For small frames like these, a faster data rate barely helps, and fewer, larger frames would.

Open this in Fleet capacity

4. What the design must do

What the numbers require of the design, each rule linked to the page that explains it.

• Design and test for the worst gap, not the average one: a timeout fires on a single gap. Why
• Keep control traffic off DFS channels. A radar detection forces the access point off the channel, and every client on that radio drops. Why
• Enable fast roaming on both sides. If the client and the network disagree on 802.11r, roams fall back to slow ones or fail. Why
• Keep bulk transfers off the radio that carries control traffic. Prioritization improves the odds; it does not reserve the channel. Why
• Safety runs over this link. The safety layer in the endpoints decides the stop; the network has to stay inside the timeout, and the timing is the machine builder’s to set. Why
• Get the vehicle’s loss-of-comms timers from its maker. They decide what happens when a gap does exceed the budget. Why
• Plan for the cars being built: their infotainment and phone-projection radios bring their own Wi-Fi onto the floor. Why

To write these into a specification, start from the spec clauses.

5. The acceptance plan

The test plan turns the budget into a pass line and a count of roams that must all pass.

• The wireless outage budget is 35 ms, set by the CIP Safety input connection. With a 20% margin, every gap must stay at or under 28 ms for the test to pass.
• To rule out a failure rate of one roam in 1000 with 95% confidence, observe 2995 roams in a row with none over the line. One roam over the line fails the run; fix the cause and start the count again.
• At 6 roams a lap with 4 vehicles on the route, that is 125 laps, about 16.7 hours of running.

Open this in the Acceptance test plan

How to judge your result

Run the plan and compare every measured gap to the pass line. The worst gap decides, not the average.

• Pass: every measured gap is at or under 28 ms, across all 2995 roams.
• Fail: any single gap over 28 ms. Find its cause, fix it, and start the count again.
• A gap between 28 ms and 35 ms has not tripped the timeout yet. It has used up the margin, so it still fails.

This site does not yet publish measurements of its own, so this example stops at the plan. The result is yours to measure.