Why a one-second drop stops a plant

A one-second network drop does not cost one second.

On a plant floor it costs whatever it takes to get the line moving again. The drop trips a timeout measured in milliseconds. The timeout puts the machine into a fault or safe state. The recovery runs on human time.

That is the gap between IT and OT, and it is why this site starts from a narrow claim. Wi-Fi will never be deterministic. The job is to prove the worst case fits inside the application’s timeout.

What one second means in IT

Office networks run on protocols that expect loss and wait it out. TCP carries web traffic, file transfers and most business applications, and it resends anything that goes missing. Its retransmission timer starts at 1 second and should not be set below 1 second¹, and it doubles after each timeout.

A one-second outage fits inside the first retransmission. The page loads late. The file copy pauses. Nobody files a ticket.

That design tells you what IT optimizes for: data that arrives eventually and intact. A late packet is still a useful packet.

What one second means to a machine

Control traffic optimizes for something else. Data arrives on time, or it is worthless.

Start from zero. A programmable logic controller (PLC) runs the machine’s logic. Its inputs and outputs (I/O) sit out on the machine: sensors, valves, drives, light curtains, and more and more often a vehicle. The controller and each device trade data on a fixed interval. EtherNet/IP calls that interval the requested packet interval (RPI). PROFINET calls it the update time. Fresh data crosses the network every interval, whether anything changed or not.

That cyclic traffic does not retransmit. On EtherNet/IP it rides UDP, and each connection carries a timing mechanism that alerts the application when the other side stops communicating. A lost packet is never resent. The next one replaces it. What matters is how long the receiver goes without valid data.

Each protocol puts a clock on that silence:

A CIP Safety input connection at its documented defaults faults if no valid packet arrives within 40 ms².
A standard EtherNet/IP I/O connection on Logix controllers times out at a multiple of the RPI that the firmware picks so the result is at least 100 ms³.
A PROFINET IO connection at a 2 ms update time, with the standard threshold of three missed cycles, detects an error after 6 ms⁴.

Against those clocks, a one-second drop is 25 times the CIP Safety default and 10 times the Logix floor. TCP has barely reached its first retransmission.

From timeout to stopped machine

A timeout is not a warning. It changes what the machine does.

When a CIP Safety connection exceeds its limit, the connection faults and its input and output data go to the safe state, which is off. When a PROFINET watchdog expires, the IO device outputs substitute values and the controller reports a station failure. Standard outputs that lose their connection go to a configured fault state: off, on, or hold the last value.

The protocol designers all made the same choice. When the controller cannot see the machine, the machine stops trusting the controller.

Getting back is slower than falling over. PI’s PROFIsafe system description notes that a safety function is usually not allowed to switch from a safe state back to normal operation without human interaction. Siemens’ safety programming manual requires, after every communication error, a user acknowledgment generated by manual operation before fail-safe I/O returns to service.

So the outage is measured in milliseconds, and the recovery waits for a person.

From stopped machine to stopped line

Mobile equipment turns one fault into many. A fixed machine that stops halts its own cell. A vehicle that stops is part of a sequence, and the sequence stops with it.

Field note. One AGV disconnecting on an assembly line shuts down the entire line. An autonomous bot that disconnects inside a safety-enclosed structure forces a temporary shutdown and a manual retrieval.

Published research describes the same mechanism at the vehicle level. A peer-reviewed study of production AGVs in an automotive factory notes that Wi-Fi disconnections can make AGVs stop unexpectedly or deviate from their intended paths.

Recovery is where the cost compounds.

Field note. Getting one stranded bot out by hand can take more than half an hour, and its cell, level, or aisle has to be locked out first. Depending on the structure, that can mean full PPE, crawling, and reaching into tight spots. When several bots drop together, it becomes hours. On an assembly line, a dropped AGV faults, and the fault takes the line with it. The resets are manual, and not everything comes back right away. Sometimes the AGV has to be lined back up by hand and the system walked through where it is, and getting location back in sync can take a long time.

The disconnect is only the trigger. The shutdown and the recovery are the bill.

What the stop costs

Credible downtime numbers are scarce, and most of the ones quoted widely come from vendors. Treat them that way.

A vendor survey published by Siemens, built on 181 online interviews at large industrial organizations between 2019 and 2023⁵, puts an hour of unplanned downtime at a large automotive plant at $2.3 million, which the report frames as more than $600 a second. That is a vendor figure, from a report that sells predictive maintenance, and it covers downtime from every cause.

A government estimate is narrower. NIST put the 2016 losses to U.S. discrete manufacturers from preventable maintenance problems alone at $119.1 billion, of which $18.1 billion was downtime⁶.

Neither study isolates the network, and you should not stretch either one to cover it. You do not need to. The structure is enough: the drop sets off the stop, and the stop is priced by the hour.

Roaming is the failure mode wired networks never had

Plants ran deterministic wired networks for years. A wired device stays plugged into the same switch port for as long as the machine runs.

Field note. Deterministic wired networks worked for years. Adding wireless and roaming introduced the hard problems.

A moving client cannot stay on one access point. It has to leave one cell and join the next while the machine keeps running. Every handoff is a moment when the client’s traffic depends on the client, the old access point and the new one all getting it right.

The best public field data on this comes from that same study. Over 3.5 months, the AGVs in one automotive factory logged 1,131 disconnections lasting 3 seconds or more⁷. Of the 331 the researchers could analyze in full, 85.84% began with a roaming attempt. Failed roams kept a vehicle offline for 5.1 seconds on average and up to 24 seconds.

The surprise was the roams that worked. More than half of the analyzed disconnections, 57.53%, came after a roam that succeeded, and the authors concluded that a successful roam does not guarantee a stable connection.

That is one plant, one fleet and one study. It is still the clearest public evidence that the handoff is where vehicles most often lose the network. Even the shortest event the study counted, 3 seconds, is 75 times the CIP Safety default.

The strongest objection

The strongest objection is that this is already solved. Plants run vehicles, and even safety protocols, over Wi-Fi every day. PI’s PROFIsafe system description permits wireless transmission as long as sufficient availability, meaning no nuisance trips, can be guaranteed.

Concede it. Wireless control works. Now read the condition. Availability has to be guaranteed, and a guarantee is a statement about the worst case.

Wi-Fi shares its medium with every other radio in range. NIST’s measurements in automotive assembly, engine and stamping plants describe highly reflective environments, noise from heavy machinery, and a crowded 2.4 GHz band⁸. No access point setting turns that into a deterministic link.

So the question is not whether Wi-Fi is fast on average. It is whether the longest gap it will ever produce, on the worst roam of the worst shift, still fits inside the timeout. A timeout does not average. It fires once.

Where to go next

Proving the worst case takes three moves.

Work out the budget. The timing budget shows how each protocol’s timeout is built and how to turn it into a roam time you can design to. The timing budget calculator does the arithmetic.
Know what shares the air. Airtime is finite shows how to inventory every flow on the wireless network, so you know what control and safety traffic is competing with.
Work a drop like a fault. Disconnect triage ranks likely causes from the symptoms you can see, and the cause library explains how to confirm each one, fix it, and keep it from coming back.

Field note. You have to know everything on the air so control and safety traffic are prioritized over large transfers and updates.

The drop lasts a second. The stop lasts until a person restarts the line.