Industrial Telemetry Data Collection and Normalization with OPC UA and MQTT Buses

The Challenge of Connecting the Factory Floor to the Office

In the industrial universe, the biggest bottleneck has never been a lack of sensors, but the barrier diversity between equipment. Each manufacturer of PLCs (Programmable Logic Controllers, which act as the electronic brains automating machines) uses proprietary and closed protocols. In practice, making a German hydraulic press talk to a Japanese injection molding machine requires complex and expensive translators. Industrial telemetry solves this problem by collecting continuous metrics on temperature, vibration, and power consumption to predict failures before they halt production.

To overcome this communication barrier, modern engineering has moved away from dedicated serial cables and adopted industrial Ethernet networks. However, simply plugging in cables does not solve the technological babel. Without a universal data standard, each system continues to view raw numbers without context, like a meter reading seventy-two without specifying degrees Celsius, RPM, or humidity percentage. This is precisely where architectures based on open standards and lightweight messaging come into play.

The Role of OPC UA in Local Standardization

OPC UA (Open Platform Communications Unified Architecture) acts as a multilingual universal translator installed inside the factory. It takes the proprietary signal from a PLC and transforms it into a structured object carrying not only the numeric value but also crucial metadata such as measurement units, timestamps, and quality status. In practice, if a sensor fails, OPC UA does not send corrupted data; it explicitly warns that the reading is invalid, preventing faulty automated decisions.

Beyond translation, OPC UA guarantees native security through high-end encryption and rigorous access control via digital certificates. This is fundamental in industrial environments, where a cyber intrusion can paralyze entire assembly lines or cause physical harm to operators. The protocol operates primarily in a client-server model or via local pub-sub (publish-subscribe), connecting PLCs, supervisory systems, and edge servers within the same internal factory network.

The Efficiency of MQTT in Long-Distance Transport

While OPC UA organizes the house and normalizes data locally, the MQTT (Message Queuing Telemetry Transport) protocol takes responsibility for delivering this information wherever needed. It was specifically designed for Internet of Things (IoT) scenarios, operating with extremely lightweight data packets and a topic-based publishing model. In practice, it works like a messaging group: the machine publishes the temperature to the topic factory/line1/press/temperature, and any authorized system interested in that data subscribes to the channel and receives updates instantly.

Another major asset of MQTT is its resilience in unstable networks. Since many factories have signal dead zones or intermittent internet connections, the protocol allows configuring Quality of Service (QoS) levels. At level one, for example, the broker (the central server managing messages) ensures data delivery even if a temporary connection drop occurs, storing pending messages until the link is re-established.

Practical Collection and Normalization Pipeline

To build a functional telemetry pipeline, the first step is configuring the OPC UA server on the edge gateway to read PLC registers via Modbus TCP or Ethernet/IP. The second step involves mapping these raw variables into a standardized JSON structure before transmission. The third step applies the MQTT publishing routine using a lightweight script, as shown in the functional Python example below simulating data normalization and transmission.

import time
import json
import paho.mqtt.client as mqtt

# MQTT broker configuration
MQTT_BROKER =