Search the field guide, causes, requirements, and glossary

Safety over wireless

A safety protocol turns a late or missing packet into a stop, so wireless trouble should cost you availability, not people; the hazard is a vehicle that needs a message to stop, and every millisecond it waits is distance traveled.

On this page7 sections
  1. The network is a black channel
  2. Late counts the same as missing
  3. Stops are the price of trusting nothing
  4. The hazard is a vehicle that needs a message to stop
  5. Two questions for every vehicle
  6. Protective functions belong on the vehicle
  7. Time is distance

A safety protocol does not trust your wireless network, and that is exactly why safety over wireless can work.

CIP Safety and PROFIsafe were built on one assumption: the network will fail. They do not try to make the channel reliable. They check every message for age, order, origin and corruption, and they treat anything late or missing as a reason to stop. Done properly, wireless trouble costs you production, not people. Done badly, a vehicle’s ability to stop depends on a packet arriving, and no amount of Wi-Fi tuning fixes that.

The network is a black channel

ODVA’s technology overview of CIP Safety states the design goal plainly. The aim was never a network that could not fail. It was a system in which network failures drive safety devices to a known safe state. The industry name for this is the black channel: the safety layer assumes the network is completely unreliable and carries its own diagnostics from end to end.

PROFIsafe works the same way. PI’s system description says the protocol makes no assumptions about transmission rates or error detection on the channel beneath it, and runs over copper, fiber, wireless links or backplanes. Because the safety layer checks everything itself, the switches, access points and radios in between need no safety assessment of their own.

Both organizations name wireless directly. ODVA lists Wi-Fi from 802.11a through 802.11ax1 among the media CIP Safety can use. PI lists wireless safety transmission for driverless transport systems and AGVs as an application.

What the safety layer checks, in plain terms:

  • Age. Every CIP Safety message carries a time stamp, so the receiver knows how old the data is, not just when something last arrived. Data past the age limit is discarded.
  • Order. PROFIsafe numbers each message with a 32-bit monitoring number2, so a repeated, lost or reordered message is caught.
  • Origin. A codename or production identifier confirms the message reached the right receiver.
  • Integrity. A safety CRC, computed by the safety layer itself, catches corrupted bits.

The black channel

The safety protocol trusts only its two endpoints. Everything between them is treated as unproven, including the radio.

Schematic, not to scale

Safety controllersafety layer:all the checksSafety I/Osafety layer:all the checksBlack channelswitchaccess pointradio linkvehicle radiono safety design or validation requiredCIP Safetytime stamps with time expectation, unique device identifiers, integrity checksPROFIsafeconsecutive numbering, a watchdog, an F-address, a CRCTimeliness is one of the checks, so a late packet trips the safety function like a missing one.

IEC 61784-3 defines a black channel as a communication system containing elements without evidence of design or validation to IEC 61508. Ethernet's own error detection may not satisfy any part of the safety function; the endpoints carry it.

Sources: IEC 61784-3, ODVA on wireless functional safety, and the PROFIsafe system description.

Late counts the same as missing

The timing checks are the ones a wireless engineer feels. On a GuardLogix controller, a CIP Safety input connection has a connection reaction time limit, which is the maximum age a safety packet may reach. If no valid packet arrives inside it, the connection times out and the data goes to the safe state, which is off. At Rockwell’s documented defaults, that limit is 40 ms3.

PROFIsafe uses a watchdog. Each device has an F_WD_Time, a number of milliseconds within which the next valid message must arrive. On a timeliness error, PI says the system initiates a safe reaction, such as safely stopping a drive.

Neither protocol cares why a message is late. ODVA notes that the CIP Safety time stamp exposes transmission, media access, queuing, retry and routing delays. Every item on that list is something Wi-Fi does. A frame stuck in retries during a roam and delivered after the limit counts the same as a frame that never arrived.

Stops are the price of trusting nothing

So wireless shows up in the safety conversation as an availability problem. A dropped safety connection stops the machine it protects.

The protocol designers say so themselves. ODVA writes that false trips reduce availability, and that CIP Safety tolerates minor disturbances by accepting a retransmission that lands before the time limit expires. PI permits wireless for PROFIsafe as long as sufficient availability, meaning no nuisance trips, and security can be guaranteed.

A safety stop is rarely a blip. PI’s system description notes that a safety function is usually not allowed to switch from a safe state back to normal operation without human interaction. A gap that lasted a fraction of a second can leave a machine waiting for a person to acknowledge it.

Field note. When an autonomous bot disconnects inside a safety-enclosed structure, the result is a temporary shutdown and a manual retrieval.

That is the safety function doing its job. Your job is to make it rare.

Field note. The roam time you need depends on what is connected and whether safety runs over wireless, such as CIP Safety. Safety over wireless needs very low roam times to avoid safety timeouts.

Hold your measured worst-case roam, not the average, against the limit. The timing budget guide explains where the limit comes from, and the Timing Budget calculator draws the two side by side, to scale.

The hazard is a vehicle that needs a message to stop

Everything above assumes the safety function fails toward a stop when the network goes quiet. The dangerous design is the reverse: a vehicle that keeps moving until a message tells it to stop. If the stop lives only in a fleet manager or a remote controller, a dropped connection takes the stop away with it. Silence means carry on.

That is a system design gap, not a Wi-Fi tuning problem. The strongest objection is that a good enough network makes the gap theoretical. Faster roaming, more access points and cleaner channels do make it appear less often. They cannot change what happens when it does appear, and the black channel principle exists because no network, wired or wireless, can promise delivery. NIST’s guide to industrial wireless deployments says that using wireless for control and safety calls for a careful risk analysis.

Field note. Some devices travel above 30 mph. A disconnect with no safety features for stopping is a major safety concern. Those vehicles are typically autonomous bots. An onboard function now monitors the network and stops the vehicle after a timer. Before that, the case was not thought of, and it caused accidents.

If you find a vehicle like this, it is not yours to fix with RF. Take it to the controls engineer and the machine builder, who own the risk assessment.

Two questions for every vehicle

Before you design coverage for any vehicle, get two answers from the people who configured it:

  1. What does it do when it loses the network? You want the specific behavior, written down, not an assurance that it handles it.
  2. How long does it wait before deciding? That wait might be a connection reaction time limit, a PROFIsafe watchdog time, or a heartbeat timeout in a fleet manager.

Both answers are settings, and someone other than you usually sets them. ODVA notes that configurable settings typically decide how many missed, late or lost packets a CIP Safety connection allows before it goes to the safe state. The PROFIsafe watchdog time is a per-device parameter. The loss of comms guide covers what to ask a vehicle vendor.

The first answer tells you whether wireless trouble becomes a stop or a hazard. The second tells you your roam budget, and how far the vehicle travels before it reacts.

Protective functions belong on the vehicle

The functions that keep a vehicle from striking a person have to work with no network at all. The standards for driverless industrial vehicles are written around the vehicle and the system it belongs to. This section describes what each one covers. It does not tell you how to comply; the standards themselves and your risk assessment do that.

ISO 3691-4:2023. Industrial trucks, safety requirements and verification, Part 4: driverless industrial trucks and their systems. ISO lists it as Edition 2, published June 20234. It covers trucks such as automated guided vehicles, autonomous mobile robots, bots, automated guided carts, tunnel tuggers and under carts. Its system includes the control system, which can sit on the truck, off it, or both, along with guidance and power. It excludes trucks guided solely by mechanical means and remotely controlled trucks. ISO marks it as under revision, with a draft (ISO/DIS 3691-4) in development.

ANSI/ITSDF B56.5-2024. Safety Standard for Driverless, Automatic Guided Industrial Vehicles and Automated Functions of Manned Industrial Vehicles. ITSDF lists it as effective December 16, 20255. It covers the design, operation and maintenance of powered, unmanned automatic guided industrial vehicles that are not mechanically restrained, and the system they are part of. It also covers manned vehicles later modified to run in an unmanned, automatic mode. NIST research written around the 2012 edition describes its model of obstacle detection: bumpers and non-contact sensors on the vehicle that must trigger a safety stop.

R15.08, industrial mobile robots. Published by A3, the Association for Advancing Automation, in three parts that A3 describes as covering design, integration and use:

  • Part 1, ANSI/RIA R15.08-1-2020 (R2026): requirements for the individual industrial mobile robot. A3 lists it under both ANSI/RIA and ANSI/A3 designations and states that the 2026 reaffirmation has no technical differences from the 2020 text.
  • Part 2, ANSI/A3 R15.08-2-2023: requirements for IMR systems and IMR applications, the integration side of the series.
  • Part 3, ANSI/A3 R15.08-3-2026: requirements for users keeping risk acceptable in day-to-day operation. A3 lists it as published April 23, 20266.

None of these is a wireless standard, and none of their published scopes mentions the wireless network. What they give you is the list of people who own the stop: the manufacturer, the integrator and the user.

Time is distance

Every millisecond a vehicle waits before it reacts, it keeps moving. Two formulas from constant-acceleration kinematics turn a timeout into meters:

  • Distance traveled before the stop begins = speed × (timeout + onboard reaction time)
  • Braking distance = speed² ÷ (2 × deceleration)

The physics textbook’s own worked example does the same thing for a driver at a red light: distance covered during the reaction time, plus braking distance. Machine safety uses the same logic. PI’s system description sizes a light curtain’s minimum distance from the hazard as approach speed times the safety function response time, with a hand assumed to move at 2 m/s. Into that response time, PI adds the gap between a device’s watchdog time and its worst case delay, because one failure can hold a signal for the full watchdog. A longer watchdog is a longer worst case.

Now the arithmetic for a vehicle at 30 mph, the speed in the field note above, which is 13.41 m/s7. The 500 ms timeout and the 3 m/s² deceleration are assumed figures for the arithmetic only. Real values come from the machine builder. Onboard reaction time is left at zero to isolate the timeout.

40 ms timeout (CIP Safety default) 500 ms timeout (assumed)
Distance before the stop begins 0.54 m 6.71 m
Braking distance at 3 m/s² 29.97 m 29.97 m
Total 30.51 m 36.68 m

Time is distance: a vehicle at 30 mph

Distance covered while the timeout runs, before the stop begins, then while braking.

Drawn to scale

40 msCIP Safety default0.54 m before the stop begins+ 29.97 m braking = 30.51 m500 msassumed timeout6.71 m before the stop begins+ 29.97 m braking = 36.68 m0510152025303540meterswhile the timeout runsbraking at an assumed 3 m/s²

30 mph is 13.41 m/s. Distance before the stop begins = speed × timeout; braking distance = speed² ÷ (2 × deceleration). The 500 ms timeout and the 3 m/s² deceleration are assumed for the arithmetic only; real values come from the machine builder's risk assessment. Onboard reaction time is left at zero.

Sources: NIST SP 811, Appendix B9, constant-acceleration kinematics, and the CIP Safety default limit.

Loosening the timeout from 40 ms to 500 ms adds 6.17 m of travel at this speed before the vehicle even starts to brake.

That is the trade hidden in every request to loosen a timeout so it survives a roam. The roam stops faulting the connection. In exchange, when the network really is gone, the vehicle covers more ground before it reacts. Whether that is acceptable is a risk assessment decision, and it belongs to the controls engineer and the machine builder, not the wireless team. What you bring is the measured worst-case roam, so they make the trade with real numbers. Run your own figures in the Timing Budget calculator, where distance results are labeled as planning aids.

A safety protocol will always choose a stop over a guess. Know which vehicles on your network were built to make the same choice, and spend your RF effort making their stops rare.

About this page

Built from 13 sources: 5 standards bodies and labs, 6 protocol owners and alliances, 1 research paper or thesis and 1 vendor document. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Safety over wireless." OT Wireless, published October 5, 2026. https://otwireless.com/guides/safety-over-wireless/

APA 7

Rutter, B. (2026, October 5). Safety over wireless. OT Wireless. https://otwireless.com/guides/safety-over-wireless/

BibTeX

@misc{rutter2026safetyoverwireless,
  author = {Rutter, Ben},
  title = {{Safety over wireless}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/guides/safety-over-wireless/}},
  organization = {OT Wireless},
}