How Industrial Telemetry Works. From sensor to historian, the path data actually takes.
Telemetry is the word for "data showing up where it's needed, generated where the process actually happens." Every operator's dashboard exists because of telemetry. Every regulatory report. Every predictive-maintenance model. This article is the practical version of the path that data takes from a 4-20 mA sensor on a tank to the chart on the operator's screen.
The seven layers of an industrial telemetry path
Every measurement in your plant follows roughly the same journey from the physical process to the dashboard. Most of the layers are invisible to the operator, but each one can fail in its own way:
- Process variable — the actual physical quantity (pressure, level, temperature) exists as a real-world value, independent of any measurement.
- Sensor / transmitter — converts the physical quantity to an electrical signal (4-20 mA, 0-10 V, RTD, thermocouple, pulse output).
- Field wiring — copper, sometimes fiber for longer runs. Susceptible to ground loops, EMI, water ingress, animal damage.
- I/O module — converts the electrical signal to a digital number via ADC. Lives in the PLC, RTU, or a remote I/O panel.
- Controller — the PLC or RTU. Scans the I/O, applies engineering-unit conversion (e.g., 12 mA → 87.5% level), applies quality-checking logic, often runs local control loops on the value.
- Comms layer — the controller reports the value over Modbus / DNP3 / OPC UA / radio / cellular to a SCADA front-end. (See our Modbusand OPC UA articles for protocol depth.)
- SCADA + historian — value arrives at the SCADA server, gets stored in the historian (see our Historian primer), surfaced to the HMI, and made available for reporting.
Where data quality actually breaks down
A reading that's accurate at the sensor can still be wrong by the time it reaches the operator. Common breakdowns by layer:
| Layer | How it breaks | What it looks like at the HMI |
|---|---|---|
| Transmitter | Drift, span shift, electronics failure | Value reads, but wrong. Slow drift over months. |
| Wiring | Open circuit, short, ground loop | 4-20 mA reads at 0 or 22 mA. Sometimes oscillates. |
| I/O module | Channel failure, ADC drift | One value stuck, others normal. "Stuck at last good." |
| Controller | Misconfigured scaling, wrong eng-unit conversion | Value off by 10× or 100×. Always wrong, never inconsistent. |
| Comms | Dropped messages, retry storms, bad byte order | Latency creep, occasional zero values, NaN spikes. |
| Historian compression | Deadband too wide, retention truncation | Trend looks flat when reality was changing. |
| HMI rendering | Wrong units, formatting bugs, stale cache | Display says one thing, log says another. |
Quality codes — the GOOD / BAD / UNCERTAIN flag attached to every value — exist to surface these failures. Most SCADA systems support them. Most operators don't have HMI screens that show them prominently. A reading from a stuck sensor labeled BAD at the historian renders as a clean number on the dashboard because the HMI was built without checking the quality flag.
Polling vs report-by-exception vs publish-subscribe
How the controller gets the value to the SCADA is one of the most consequential architectural choices in a telemetry system. Three patterns:
Polling (the classic SCADA pattern)
The SCADA front-end periodically asks each controller "what's your current value?" Controllers respond. Predictable bandwidth. Inefficient — most values haven't changed since the last poll. Modbus is the canonical polled protocol.
Report-by-exception
The controller only sends values when they change beyond a configured deadband. Massive bandwidth savings on slow-moving processes. DNP3 supports this; OPC UA's MonitoredItems are a modern equivalent.
Publish-subscribe
The controller publishes to a broker (MQTT, AMQP, Kafka). Anyone interested subscribes. Decoupled, scalable, fits cloud architectures. MQTT/Sparkplug is the rising standard for modern IIoT. Doesn't require the SCADA to know what controllers exist — they self-announce.
Modern industrial deployments increasingly use pub/sub at the cloud edge and polling inside the plant LAN — a hybrid that combines deterministic local behavior with elastic cloud-side analytics.
Sample rates and the bandwidth budget
Sample rate is the rate at which the sensor produces a reading. Scan rate is the rate at which the controller reads the sensor. Poll rate is the rate at which the SCADA reads the controller. These are not the same number, and the gap between them is where most telemetry bandwidth conversations live.
- Slow-changing values (tank level, ambient temperature, daily production totals): 1 sample / minute is generous. 1 sample / 5 minutes is often fine.
- Control-loop values (pressure for a fast PID, flow): 1 sample / second is typical, 100+ samples / second sometimes.
- Vibration / acoustic / RF: kHz-to-MHz sample rates, processed at the edge and only summary statistics forwarded.
The architectural rule: sample fast at the edge, decide what to forward, transmit only what's needed centrally. See our edge computing article for the broader pattern.
How Aevus uses telemetry
Aevus is a telemetry consumer, not a producer. The platform ingests the customer's existing telemetry stream (via historian subscription, OPC UA client, or MQTT subscription), validates quality codes, normalizes units, and runs analytics on top. We never write back into the telemetry path — see IL-9000.
Telemetry, end to end.
If your operations team is dealing with telemetry quality, drift, or visibility gaps, that's the conversation we're built for.
Related Articles
Bands, degradation, and predictive failover for field radios.
Time-series databases, deadband compression, and query patterns.
Architecture, layers, and the signal path from sensor to control room.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.