Technical Guidance

Global – October 29, 2026 -- Secure MQTT telemetry collection across IT/OT boundaries depends on the architecture around the broker, clients, identity and operations, not on choosing an encrypted port, according to TDengine guidance on industrial data ingestion.

Broker placement decides which systems need a route to OT

The broker can sit near sources, in an industrial DMZ or in another approved service zone, depending on the site's threat model, reliability needs and operating ownership. An IT subscriber should connect only to an approved broker endpoint, not to controllers or the wider OT network. The guidance cites NIST's Guide to Operational Technology Security, which requires OT designs to weigh performance, reliability and safety alongside cybersecurity risk.

Global – October 29, 2026 -- An MQTT connection can recover while the historian still has a permanent data gap, because reconnection says nothing about where each measurement was durably held during the outage. Store and forward lowers that risk by retaining data near the failure point and replaying it after recovery, but it cannot restore a measurement that was never collected or never persisted at any boundary.

Four pipeline stages each own a separate loss boundary

An industrial MQTT path commonly runs through publisher, broker, collector and historian. A source-side buffer covers a site-to-broker interruption. A broker-side queue helps an offline subscriber receive messages the broker already accepted. A collector-side buffer covers messages after collection but before the historian confirms storage. None of these mechanisms automatically covers the others.

Global – October 29, 2026 -- Industrial historians should default to data-change subscriptions for continuously monitored OPC UA process variables and reserve polling for explicitly periodic records, according to collection guidance tied to TDengine TSDB-Enterprise.

Polling leaves a blind spot between reads

A polling client issues Read requests at a fixed interval, so a ten-second poll fetches the latest value every ten seconds whether or not it changed. If a motor status flips from 0 to 1 and back to 0 inside that window, both surrounding polls return 0. A shorter interval cuts the risk but raises load, and it never removes the gap between samples.

Polling fits periodic reporting, slow-changing values that need regular records, and servers with weak subscription support. A quality report requiring one temperature record per minute, including unchanged periods, is a polling case.

Global – October 29, 2026 -- Choosing the wrong OPC UA timestamp can reorder events, hide network delay or place valid data outside the historian query window, so most process analysis should use a trustworthy SourceTimestamp as event time and keep collector receipt time as a separate field.

SourceTimestamp stays fixed as data passes through servers

The OPC UA specification defines SourceTimestamp as the time a data source applies to a value, ideally the last change of the value or status, generated as close to the source as possible. It does not change when the value passes through another OPC UA server. That makes it the best fit for sequence-of-events work, batch analysis and calculations tied to when the process changed.

Global – October 29, 2026 -- A restored OPC UA connection does not guarantee that the historian holds every value generated during an outage, because the three links in the data path (source, collector and historian) each lose data in different ways. Buffering at one layer cannot repair a loss that occurred earlier in the chain.

In the common architecture of device or PLC, OPC UA server, collector and historian, the first step is to find which link failed. If the device or server stops producing values, the collector has nothing to recover unless the source keeps its own history. If the collector cannot reach the historian, a durable local buffer can protect messages it has already collected. Treating all three as a generic network outage leads to the wrong fix.

Global – October 29, 2026 -- Industrial historians that store an OPC UA value and timestamp without the accompanying 32-bit StatusCode can pass stale, substituted, or Bad readings into averages, alarm reviews, and production calculations as ordinary process measurements.

StatusCode carries more than a Good, Bad, or Uncertain label

Every OPC UA DataValue can contain a value, timestamps, and a StatusCode. The severity class is Good, Uncertain, or Bad. The remaining bits can carry a specific subcode and information bits, such as monitored-item queue overflow, limit state, or changed semantics.

The SemanticsChanged bit can indicate that metadata such as engineering units changed and should be re-read before processing. A value of 100 is not comparable with the previous day's 100 if the unit or scale changed in between.

Global – October 28, 2026 -- QoS 1 is the practical starting point for most industrial telemetry over MQTT, but none of the three QoS levels guarantees a complete historian, according to engineering guidance tied to the OASIS MQTT 5.0 standard.

QoS 1 reduces the risk of losing a message on an MQTT delivery hop. The receiving system must tolerate duplicates. QoS 0 fits replaceable readings where low overhead matters more than complete delivery. QoS 2 is reserved for flows where duplicate delivery on that hop is unacceptable and the extra protocol exchange is justified.

MQTT QoS covers one sender-receiver hop, not the whole pipeline

The OASIS MQTT 5.0 standard defines QoS for a single delivery flow. A device publishing to a broker is one flow. The broker sending to a subscribing collector is another, and it can use a different QoS depending on the original publication and the subscriber's granted maximum.

Global – October 28, 2026 -- Neither MQTT retained messages nor persistent sessions can guarantee complete production history, so industrial operators who need every measurement must add application-level buffering and a historian, according to an engineering analysis of the OASIS MQTT 5.0 specification.

Retained messages deliver the latest state to new subscribers

A retained message gives a subscriber the last retained value on a topic when it subscribes. In the example of a packaging line publishing to plant/line2/packer/status, a new maintenance display receives the retained RUNNING state without waiting for the next live publication, provided the message is still available and the subscription's retain-handling settings permit delivery.

Global – October 27, 2026 -- Industrial teams can locate missing historian records by tracing one test message across five boundaries: broker receipt, subscriber receipt, parsing, database write and query. The approach comes from troubleshooting guidance on TDengine's MQTT ingestion, which warns that a live broker feed or a connected publisher proves only part of the chain.

One tagged test message anchors the diagnosis

Engineers should publish a single message for one equipment tag through the approved production path, such as plant/line2/pump07/pressure. They should log the exact topic, payload bytes, broker timestamp, publisher identity, destination table and intended source timestamp. Each test needs a fresh timestamp, because identical timestamps can make a successful write indistinguishable from an earlier one.

Global – October 27, 2026 -- An MQTT message is only a topic plus a payload, so a usable historian record needs four additions: stable equipment identity, typed measurements, a trustworthy timestamp and a schema that survives device and site growth. Engineers should settle these before configuring ingestion into TDengine TSDB Enterprise. Skipping that step can produce technically successful writes that create tables that are hard to query, compare or maintain.