Getting WirelessHART Data Into SCADA Without Trusting a Stale Reading

A tank level sat at 62.4% for forty minutes while the tank was actually filling. The trend was a perfectly flat line — not noisy, not missing, just flat. Operators read it as "level holding" because that is what a flat line means everywhere else on the screen. The transmitter was a WirelessHART unit that had lost its path to the gateway. The gateway knew. SCADA didn't, because the integrator had mapped the process value out of the gateway's Modbus table and left the status register alone.

That is the entire problem with wireless instrumentation on a SCADA screen. A wired 4–20 mA loop that dies goes to 0 mA or drives to a fault current, and every SCADA I've worked on flags that. A wireless value that dies just stops updating, and the last good number keeps drawing.

The value and its status are two separate things

WirelessHART (IEC 62591, the HART 7 wireless extension) devices don't answer polls. They publish — each device is scheduled by the network manager to burst its variables at a configured update rate, and the gateway caches whatever arrived last. When you read the gateway, you are reading the cache, not the field.

So the gateway carries, for every device, some form of:

the process variable itself (PV, and often SV/TV/QV — a Coriolis meter or a multivariable transmitter gives you several)
the HART device status byte, including the device-malfunction and "more status available" bits
a freshness indicator — how long since the last successful publish, or a boolean stale flag once that exceeds the gateway's stale timer

Map all three. If you map only the first one, you have built a display that cannot tell "steady" from "gone." The stale timer on most gateways defaults to some multiple of the device's update rate; check what yours actually is instead of assuming, because a device set to a 60 s update rate and a stale timer left at a fixed 30 s will flap constantly, and one set to 1 s with an hour-long timer will hide a genuine failure until the shift ends.

My rule: derive the SCADA tag quality from the gateway's staleness output, not from the SCADA driver's own comms status. The driver will report the gateway as healthy — it is. The device behind it is what's missing. If your SCADA supports writing quality on a tag, set it Bad/Uncertain and let the standard bad-quality rendering do the work. If it doesn't, carry a companion .STALE boolean and put it on the faceplate; a frozen number with no visual difference is worse than no number.

Don't poll faster than the device publishes

The most common commissioning mistake I see is a 1-second scan class pointed at the gateway for a device publishing every 32 seconds. It costs you gateway CPU and network traffic, and it buys nothing — you get 31 repeats of the same float, then a step.

Worse, it distorts everything downstream. Exception-based historian collection sees a staircase and stores the transitions as though the process moved in steps. Rate-of-change alarms compute a slope across a step edge that never happened in the process. Anything doing derivative or trend-slope analysis on that tag gets garbage.

Poll the gateway at roughly the fastest device update rate on it, group the devices into a scan class that matches their configured rate, and be honest on the trend that this is sampled data.

Picking the update rate itself is a battery conversation, not a control conversation. WirelessHART supports rates from 1 s up to many minutes, but the power module in a battery-powered transmitter is sized around a specific duty cycle — moving a device from 32 s to 1 s can turn a multi-year module life into months. Check the vendor's published life curve for the actual module before someone asks for "faster." And nothing on a WirelessHART mesh belongs in a closed control loop or an interlock. Monitoring, optimization, energy accounting, tank inventory, corrosion, steam trap and relief valve monitoring, temperature surveys — that's the workload. IEC 62591 doesn't promise you deterministic latency across a multi-hop mesh.

The Modbus map will bite you before the radio does

Most gateways expose HART-IP, OPC UA, EtherNet/IP, and Modbus TCP/RTU. If you have the choice, take HART-IP or OPC UA — the device status and freshness come through as structured data instead of something you have to reconstruct from register offsets.

When it has to be Modbus (and on brownfield jobs it usually does), expect the standard traps:

32-bit float word order. Same fight as every other Modbus integration. Confirm against a known value — put the transmitter on a bench reading a real pressure and check the number, don't trust the manual's diagram.
The register block is assigned, not fixed. The gateway's Modbus table is built from a configuration you make: device X's PV lands in the registers you told it to. Add a device six months later, and if someone re-orders or re-packs that table, every downstream address shifts. Export the map, put it in the project docs, and treat it as a controlled document.
Units are whatever the device says. The gateway republishes the transmitter's configured engineering unit. A tech who changes a transmitter from kPa to bar in the field has just changed your SCADA value by a factor of 100 with no alarm anywhere. Range-check the tag.

Join problems look like radio problems and usually aren't

A device that won't come onto the network is, in my experience, wrong credentials far more often than weak signal. Every device needs the network ID and the join key that match the gateway, and the join key is long enough to be typed wrong. The gateway's join-failure log tells you which one it is: a device that's being heard but rejected is a key problem; a device that never appears at all is a radio or a power problem.

Joining is also slow, by design. A device at the edge of a large mesh can take a long stretch of minutes to find neighbors, get advertisement packets, and receive its bandwidth allocation — much longer than the "it should be online in a few seconds" instinct you bring from wired commissioning. Power it up, walk away, come back.

For layout, follow the vendor design guidance rather than intuition: give every device at least three neighbors within range, and keep a meaningful fraction of devices in direct range of the gateway so the mesh isn't strung out through one relay. Emerson's rule of thumb is 25% within direct range, five for smaller networks. Metal, moving equipment, and full tanks all change the picture — a network that was fine at commissioning can degrade when the tank farm fills.

What to check before signing off

Every device's reliability percentage on the gateway's diagnostics page. Consistently below ~90% means the mesh needs another device or a repeater, not a retune.
Path stability for each neighbor link, and whether any device has only one usable path. A single-path device is a single point of failure that the mesh cannot route around.
Battery / power module remaining life exposed as a SCADA tag with a low alarm. Set it long enough ahead that it lands in a planned outage, not a callout.
Pull one device's power and watch what the operator screen does. If it doesn't visibly change within the expected stale window, the staleness mapping is wrong. Do this on the real screen, with an operator watching, not on the engineering workstation.

The gateway's own diagnostics are the best troubleshooting tool on this network and they are almost always unmapped, sitting behind a web page nobody logs into after handover. Pull the network-health metrics into SCADA tags at commissioning time — it costs you a scan class and about an hour, and it turns "the level looks stuck" into "device 14 dropped to one path last Tuesday."