Wireless sensor route loss and the stale-data blind spot

A condition-monitoring node on a SAG mill discharge bearing, a conveyor drive gearbox, or a control valve actuator can stop delivering data for two very different reasons. The first is that the node itself has failed. The second is that the node is healthy and transmitting, but the wireless route carrying its packets has failed. Conventional stale-data alarms catch the first case and miss the second.

That distinction matters because the two failure modes look identical at the historian. A frozen last-known-good value, a flat trend line, and a timestamp that stops advancing are the same on screen whether the transmitter died or the route collapsed. The maintenance planner sees a gap. The reliability engineer assumes a battery or a radio. Neither is necessarily true.

The mechanism of a silent route loss

A wireless sensor node in an industrial deployment typically reaches its gateway through one of three paths: a direct link, a parent node acting as a router in a mesh, or a dedicated repeater. The node does not know which path its packets take. It hands a frame to its radio stack, the stack forwards it, and the node waits for an acknowledgement at the link layer.

When a parent node loses power, is physically moved, or its own upstream link degrades, the child node’s next transmission attempt fails. A well-designed stack will retry, then attempt to rejoin the network through a different parent. During that rejoin window, which can run from seconds to hours depending on scan intervals and backoff behaviour, the node is not sending process data. It may also be holding its last sampled value in a local buffer, waiting for a route to open.

The gateway, meanwhile, has received nothing. If the gateway’s stale-data logic is keyed to the node’s own health telemetry, and that telemetry is also carried over the failed route, the gateway has no signal to act on. The node is not reporting that it cannot report. This is the silent dropout: a route failure that produces no alarm because the alarm path shares the failure.

On a conveyor drive gearbox, that gap might span a shift. On a control valve actuator on a tailings line, it might span a weekend. The condition data that would have shown a rising bearing temperature or a slow stroke-time drift simply does not exist for that interval.

Why stale-data alarms are not diagnostic coverage

IEC 61511 frames this in terms of diagnostic coverage: the fraction of dangerous failures that the diagnostic subsystem can detect. A stale-data alarm is a diagnostic, but its coverage is bounded by what it can observe. If the diagnostic observes only the node’s heartbeat, and the heartbeat travels the same route as the process data, then a route failure is a common-cause failure of both the measurement and its diagnostic. Coverage for that specific failure mode is effectively zero.

This is not a claim that the sensor is a safety device or that any node carries a SIL rating. It is a statement about the diagnostic architecture. A diagnostic that shares a failure path with the function it monitors cannot be credited with detecting that path’s failure. IEC 61511-1 clause 11.4 and the associated guidance on proven-in-use and diagnostic coverage both point at this: the diagnostic must be independent of the failure it is meant to reveal, or its claimed coverage must be reduced accordingly.

The practical consequence for a reliability engineer is that a route failure can degrade the integrity of a condition-monitoring function without any annunciation. The function appears to be operating because the last value is still on the trend. The proof-test interval that was calculated on the assumption of continuous data is now wrong.

Periodic route proof-testing

The remedy is a proof test of the route, not of the sensor. IEC 61511 treats proof testing as the periodic verification that a function still performs as specified. For a wireless condition-monitoring function, that means periodically verifying that data actually traverses the route, end to end, and that the absence of data is detected.

A defensible route proof test has four elements. First, a known-good reference value is injected at the node or at a point upstream of the radio, and the gateway is checked for its arrival within a bounded time. Second, the route is deliberately perturbed — a parent node is taken offline, or a repeater is isolated — and the gateway is checked for a route-loss annunciation within the specified detection time. Third, the node’s rejoin behaviour is observed: how long until it re-establishes a path, and does it report the gap. Fourth, the gateway’s stale-data logic is verified against a node that is transmitting but whose packets are being dropped upstream, which is the exact failure mode a heartbeat-only diagnostic misses.

The test interval should be derived from the required integrity of the condition-monitoring function, not from a vendor default. Where the function supports maintenance decisions on a SAG mill gearbox or a critical conveyor, a shorter interval is defensible. Where it informs a trend on a non-critical pump, a longer one is.

The output of the proof test is evidence: a record that the route carried data, that a route failure annunciated, and that the annunciation was independent of the failed path. That record is what allows diagnostic coverage to be claimed at all.

Getting started

Inventory the wireless routes that carry condition data on your site and map which nodes depend on which parents and repeaters. For each route, identify whether the stale-data alarm is triggered by node heartbeat, by gateway-side timeout, or by both. Where the alarm depends on a path that shares the route, treat the diagnostic coverage as unproven until a route proof test demonstrates otherwise. Then schedule the test, record the result, and set the interval from the consequence of a missed detection on that specific asset.

Source: internal-backlog — grounded in S5 engineering design notes, not a current market event.

Talk to S5 System about your site

S5 System designs and manufactures ultra-low-power industrial IoT sensors for mining, agriculture, infrastructure and utilities.

Discuss your IoT monitoring project — book a call.