Automotive assembly | OT Wireless

Wireless availability on an assembly line is line availability. The line is a chain of stations, and the vehicles that carry work between them are links in the chain. When one of them loses the network, the chain stops.

The product makes this plant harder than most. Every car on the line carries radios, and by the end of the line it is a working Wi-Fi network parked on your floor.

What runs there

Automated guided vehicles (AGVs, driverless carts that follow programmed routes) move materials and components between production zones under the control of a central system over Wi-Fi. A published study of one car plant describes several dozen AGVs on Wi-Fi 6, served by dozens of evenly spaced access points¹.

Some stations need two moving systems to agree in real time. In body and chassis “marriage”, the conveyor carrying the chassis and the conveyor carrying the body have to communicate as they close together, and a collision damages both.

Around the vehicles sits a crowd of smaller clients. NIST’s deployment guide lists AGV control, crane and machine tool pendants, RFID tracking of parts and tools, wireless barcode readers and door openers among typical factory radio uses. Tightening tools belong on that list too. One cordless Wi-Fi nutrunner manual describes sending tightening results and receiving control commands over the WLAN, with a mode that stores results when there is no radio connection. Not every client fails the same way when the link drops.

The buildings are large and full of metal. A transmission assembly factory measured by NIST was over 400 m by 400 m, with ceilings near 12 m, dense with tall metal machines².

Then there is the product. A vehicle’s telematics unit can act as a hotspot for devices on board, a client to outside access points for updates and diagnostics, and a receiver for content cast from passenger devices. Wireless Android Auto requires a phone with 5 GHz Wi-Fi support³. Wireless CarPlay has the phone join a CarPlay network over Wi-Fi. One vehicle manufacturer’s service bulletin states it plainly: the vehicle communicates with the phone over a 5 GHz Wi-Fi connection⁴.

What it needs from the network

Every vehicle, every time. The line is only as available as its least available vehicle.

Field note. One AGV disconnecting on an assembly line shuts down the entire line. The AGV faults, the line faults with it, and the resets are manual. Not everything comes back right away, and when an AGV has to be lined back up by hand so the system knows where it is, getting back in sync can take a long time.

Control traffic rides on connections that carry timers. In EtherNet/IP, producers send data at a requested packet interval (RPI), and consumers listen for it at that interval. A connection survives a gap only if the gap ends before the connection timeout timers expire, which is why the RPI and timeout multiplier have to be set to cover any switchover. From the connection’s point of view, a roam is a switchover.

Safety connections are tighter. One controller vendor’s safety reference manual defaults a CIP Safety input connection to a 10 ms RPI, a timeout multiplier of 2 and a network delay multiplier of 200%, which gives a 40 ms connection reaction time limit⁵. If no valid packet arrives inside that limit, the connection times out and its data goes to the safe state. An ODVA conference paper calls a timeout like that, with no real hazard behind it, a “spurious trip”.

PROFINET IO works the same way under different names. Update times run from 250 µs to 512 ms, and each connection is watched with a time limit that is a multiple of the update time⁶. When cyclic data misses that window, the consumer reports the failure to the application.

So the requirement is neither coverage nor throughput. It is one comparison: the longest gap any vehicle sees anywhere on its route has to be shorter than the shortest timeout riding on that vehicle.

How wireless fails there

The roam, mostly from the client side. A study of kernel logs from AGVs in a car plant counted 1,131 disconnections of 3 seconds or more over 3.5 months. Of the 331 events with complete logs, 85.84% began with a roam attempt. The surprise: 57.53% came after a roam that succeeded, and the longest lasted 30 seconds.

The most common single pattern, at 28.91%, pointed at the vehicle’s Wi-Fi chip, firmware or driver rather than the access point. Add up the patterns the authors trace to the vehicle side in the study’s pattern table and they cover about four in five events, though the authors stop short of root causes. Another 4.21% were access points ending sessions whose authentication had apparently expired.

An access point log that shows a clean roam does not prove the vehicle stayed connected.

Metal, fixed and moving. NIST’s measurements in automotive plants found factories crowded with stationary and mobile metal structures, with high multipath and machine noise. Its later propagation study found industrial sites lose signal faster with distance than open space, the automotive plant most of all. NIST also describes rows of machines under overhead gantries in an automobile assembly factory forming a canyon where a device’s connection becomes unreliable, and warns that layout changes undo antenna placements that rely on reflections.

The strongest objection is that OFDM already handles multipath. For delay spread alone, it does. NIST estimated average delay spreads below 500 ns, inside Wi-Fi’s 0.8 µs legacy cyclic prefix, with 1.6 µs and 3.2 µs options since 802.11ax⁷. Echoes are not the threat. A large object that blocks the direct path can drop the link outright.

The product on the floor. Wi-Fi shares airtime among every network on a channel. The service bulletin explains the in-car link failing in crowded areas because bandwidth is shared among all Wi-Fi networks in the same spectrum, and only the traffic in that range matters, not signal strength. Inside a plant the roles reverse. Every finished vehicle with projection running is another network on your 5 GHz channels. NIST’s guide names automobile hotspots among the non-production emitters that interfere with factory wireless.

Field note. In automotive plants, vehicles run wireless Android Auto and CarPlay. Some use 80 MHz channels on 5 GHz and interfere with production wireless. The car networks beacon even with no phone paired. They show up at end-of-line testing, and anywhere a lot of vehicles sit together, whatever the environment. The fix has typically been a channel change or a redesign of the plant wireless.

People’s devices. NIST’s 2007 measurements found heavy, constant 2.4 GHz traffic from data nodes, wireless scanners and industrial equipment⁸, and recommended restricting personal electronics in that band. Its deployment guide puts employee-owned devices and mobile telephone hot spots in scope for the spectrum survey.

Field note. Employees have been found using LTE hotspots that caused interference.

Design implications

Budget the gap, not the coverage. For each vehicle, list every connection it carries and that connection’s timeout. The smallest one is the roam budget. A 40 ms default safety limit and a multi-second disconnect are not close.

Specify the client, not only the access point. The vehicle’s radio, driver and firmware drive most of the disconnects in the published data. Pin client firmware versions, test each one before rollout, and require vehicle suppliers to expose roam and disconnect logs.

Plan for the vehicles you build. Treat finished vehicles as co-located networks on 5 GHz, some of them 80 MHz wide. In the EU, a 5 GHz access point installed in a road vehicle may use only 5150 to 5250 MHz⁹, so an 80 MHz car network there fills all four of channels 36 to 48 on the 5 GHz channel map. Narrower production channels give you more channels to choose from, and more room to stay clear of them.

Write a spectrum policy and enforce it. NIST recommends a spectrum management plan that inventories every known network and emitter, with procedures for acting on events, and technical, educational and policy measures against non-production emitters. Personal hotspots and phone projection in production areas belong in that policy.

Get loss-of-comms behavior in writing. What a vehicle does when its link drops, and how it recovers, comes from the machine builder’s risk assessment and the applicable standards. The network design has to fit inside those numbers. It does not change them.

How to validate

Survey the plant as it runs. Measure with the line moving, vehicles on their routes, finished vehicles present and powered as they are in production, and people on shift. NIST calls for a spectral occupancy survey of all wireless networks and interference sources before design, and continual spectrum monitoring that correlates spectral activity with factory activity afterward.

Measure from the vehicle. Ride the real route with the real client radio and record every roam, every gap and every disconnect reason code. Client kernel logs separated causes that network-level metrics alone could not explain.

Plot gaps against timeouts. The result that matters is a distribution of gap durations per vehicle, with the shortest timeout drawn across it. An average hides the one gap that stops the line.

Test before you trust the model. NIST is explicit that harsh multipath does not mean wireless will fail, and that testing is required to find out.

Re-validate at every model change. A new vehicle program brings new radios onto your floor.

On an assembly line, the worst roam of the unluckiest vehicle sets the uptime of the whole line.

What runs there

What it needs from the network

How wireless fails there

Design implications

How to validate

Causes seen here

Requirements for this environment

Terms on this page

About this page