TDengine

MQTT Historians Need Source Event Time, Not Arrival Time

Global – October 29, 2026 -- Historians that stamp MQTT messages with broker arrival time can display an old pressure reading as a new process condition, distorting aggregates, alarms and event order during outage replays.

Plain MQTT defines no process-time field

MQTT specifies only the transport of an application message. It prescribes no timestamp field, industrial clock model or time semantics. The publisher's application contract decides whether a payload carries a time, in what format and with what quality.

OPC UA's SourceTimestamp and ServerTimestamp concepts do not carry over to ordinary MQTT payloads. Broker receipt time and connector receipt time are useful operational observations, but they do not prove when a machine produced a measurement.

Industrial AI Data Platforms Should Be Judged by One Decision

Image
Industrial AI Data Platforms Should Be Judged by One Decision

Global – October 29, 2026 -- Plants selecting an industrial data platform for AI should start with a single operational decision, such as whether a reliability engineer must review a compressed-air pressure drop within an hour, rather than with a list of AI features. That decision defines the required sources, history, context, access controls and response time.

Four data sources feed the compressed-air pilot

The example pilot investigates periods when header pressure falls while compressor energy use rises. It needs PLC compressor state and control values, historian pressure, flow and power trends, IoT vibration readings, and maintenance records. None of these sources has to be replaced; the test is whether the evidence can be found, understood, governed and accessed together at the necessary time scale.

Knowledge Graphs give Industrial AI traceable plant context

Image
Knowledge Graphs give Industrial AI traceable plant context

Global – October 29, 2026 -- An Industrial Knowledge Graph links assets, measurements, events, documents and procedures as connected entities. This gives Industrial AI more relevant context than raw document search, according to a TDengine explainer for OT architects.

Graph links symptoms to causes, checks and approved actions

Nodes cover equipment concepts, fault conditions, maintenance procedures, rules, documents and events. Links express relations such as causes, applies to, requires or precedes. A compressor alarm, for example, can be tied to its troubleshooting procedure, operating conditions and earlier investigation records.

Roller press case shows reuse of a hydraulic pressure investigation

A roller press shut down after hydraulic pressure fluctuated. The maintenance record captured the observed condition, a possible cause, the handling sequence, the pressure limit and required spare parts.

MQTT Security Hinges on Broker Architecture, Not Encrypted Ports

Image
MQTT Security Hinges on Broker Architecture, Not Encrypted Ports

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.

MQTT Reconnects Do Not Guarantee Complete Historian Data

Image
MQTT Reconnects Do Not Guarantee Complete Historian Data

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.

TDengine Maps Three OPC UA Collection Modes to Historian Needs

Image
TDengine Maps Three OPC UA Collection Modes to Historian Needs

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.

OPC UA Historians Should Store Source Time and Receipt Time

Image
OPC UA Historians Should Store Source Time and Receipt Time

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.

Reconnected OPC UA Links Can Still Leave Historian Data Gaps

Image
Reconnected OPC UA Links Can Still Leave Historian Data Gaps

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.

Historians Dropping OPC UA StatusCodes Risk Skewed Process Data

Image
Historians Dropping OPC UA StatusCodes Risk Skewed Process Data

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.

MQTT QoS 1 Suits Most Industrial Telemetry; Duplicates Need Handling

Image
MQTT QoS 1 Suits Most Industrial Telemetry; Duplicates Need Handling

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.