OPC UA or MQTT for Measurement Data: Comparing Data Models, Communication Direction and IT/OT Integration

→ Product category: IIoT solutions

 

A pressure sensor provides:

6.42 bar

A temperature sensor reports:

78.3 °C

and a vibration sensor generates several condition values for a machine.

The measured values are then to be:

• displayed in the control system,
• stored in a historian,
• made available for a dashboard,
• transferred to a higher-level IT system

.

At the latest when designing the system architecture, the following question often arises:

OPC UA or MQTT?

The question is reasonable – but from a technical perspective, these are not two completely interchangeable protocols.

In addition to communication mechanisms, OPC UA provides a comprehensive information model for industrial data. MQTT, on the other hand, is primarily a lightweight publish/subscribe messaging protocol in which the applications themselves define the semantics of the transmitted payload data.

In simplified terms:

OPC UA → provide machine and process data in a structured form

MQTT → efficiently distribute data to many recipients

In many IIoT projects, the correct answer is therefore not:

OPC UA OR MQTT

but:

OPC UA AND MQTT

For example:

Machine / PLC → OPC UA → Edge Gateway → MQTT → Broker → Historian / Dashboard / Cloud

Or even:

OPC UA PubSub → MQTT Broker

because OPC UA itself includes a publish/subscribe model that can use MQTT, among other technologies, as a transport mechanism.

Protocol selection should therefore not be based solely on data rate or manufacturer support. The decisive factors are the data model, communication direction, semantics, time reference, data quality, scalability, security and the subsequent use of the measurement data.

IIoT solutions for industrial measurement data can be found at ICS Schneider under IIoT Solutions.

Why OPC UA and MQTT are not directly the same thing

In discussions, OPC UA and MQTT are often presented as two alternative industrial protocols.

This simplification is helpful for an initial overview, but technically incomplete.

OPC UA covers more than data transport

OPC UA can, among other things:

• model objects,
• provide variables,
• define data types,
• represent relationships between objects,
• provide methods,
• transmit events,
• identify data quality,
• transmit timestamps.

MQTT focuses on message distribution

At its core, MQTT works with:

Publisher → Broker → Subscriber

A publisher publishes a message to a topic.

All authorized subscribers whose subscription matches the topic can receive the message.

This already explains a key difference

OPC UA answers questions such as:

What does this value mean within an industrial information model?

MQTT primarily answers:

How do I distribute this message efficiently to interested recipients?

What is OPC UA?

OPC UA stands for:

Open Platform Communications Unified Architecture

OPC UA was developed for structured and interoperable information exchange between industrial systems.

Address Space

An OPC UA server provides information in an:

Address Space

.

For example, it can represent:

Plant → Line → Machine → Pump → Pressure

A value is more than just a number

A variable can, for example, contain or be associated with:

• value,
• data type,
• status,
• timestamp,
• engineering unit,
• description,
• additional relationships and metadata.

Example

Instead of merely transmitting:

6.42

a system can provide, in simplified form:

Asset: Pump_17

Variable: DischargePressure

Value: 6.42

Unit: bar

Quality: Good

SourceTimestamp: 2026-08-19T10:15:42.250Z

The semantics are therefore much more closely linked to the data itself.

What is MQTT?

MQTT stands for:

Message Queuing Telemetry Transport

The protocol was developed for efficient message transmission based on the publish/subscribe principle.

Basic structure

MQTT uses:

• clients,
• publishers,
• subscribers,
• a broker,
• topics,
• messages or payloads.

Example

An edge gateway publishes a pressure value under:

plant/berlin/line3/pump17/pressure/discharge

The payload could, for example, be:

{"value":6.42,"unit":"bar","quality":"good","ts":"2026-08-19T10:15:42.250Z"}

Important difference

MQTT does not fundamentally specify that such a payload must contain:

• JSON,
• XML,
• binary data,
• a single numerical value

.

The payload structure is defined by the participating applications or by the data model being used.

MQTT reliably handles message distribution – the system architecture must define the technical meaning of the message.

Understanding OPC UA Client/Server

Classic OPC UA communication often works according to:

Client ↔ Server

Server

The server provides its information.

Client

The client decides which information it wants to:

• browse,
• read,
• write where applicable,
• monitor

.

Browsing

A major advantage is that a client can browse the structure of a server.

For example:

Objects

→ ProductionLine3

→ Pump17

→ Measurements

→ DischargePressure

Subscriptions

A client does not have to query values continuously by repeated reading.

It can create subscriptions or monitored items for relevant variables.

The server then provides the corresponding changes.

Do not forget OPC UA PubSub

The statement:

OPC UA = Client/Server

is incomplete today.

OPC UA also has its own:

Publish/Subscribe model

Publishers and subscribers are decoupled

With OPC UA PubSub, a publisher publishes configured datasets.

Subscribers receive the datasets relevant to them.

Brokerless or broker-based

OPC UA PubSub supports different transport concepts.

These include:

• brokerless communication, for example using datagram mechanisms,
• broker-based communication.

MQTT can be part of OPC UA

For broker-based OPC UA PubSub communication, MQTT can be used as the messaging protocol.

An architecture can therefore, for example, be:

OPC UA information model → OPC UA PubSub → MQTT → Broker

Important consequence for selection

“OPC UA or MQTT?” is therefore partly the wrong question. OPC UA can provide industrial semantics while MQTT is simultaneously used for message transport.

Publish/Subscribe with MQTT

MQTT is fundamentally based on publish/subscribe.

Publisher

A publisher sends, for example:

Topic:

plant/berlin/line3/pump17/pressure

with:

Payload: {"value":6.42}

Subscriber

A subscriber can, for example, subscribe to:

plant/berlin/line3/pump17/pressure

Wildcard subscription

Another system could, for example, subscribe to all measurement data from the pump:

plant/berlin/line3/pump17/#

Advantage

The publisher does not need to know:

• which dashboard uses the data,
• which historian stores it,
• which cloud application processes it.

It simply publishes its message.

What role does the MQTT broker play?

The broker is the central message intermediary in a classic MQTT architecture.

Example

Edge Gateway

↓

MQTT Broker

↓ ↓ ↓

Historian / Dashboard / MES

The broker handles, among other things

• receiving messages,
• matching them with subscriptions,
• forwarding them to subscribers,
• QoS processing,
• session management depending on configuration,
• retained messages,
• access control.

Architectural advantage

New data consumers can be added without the field device or gateway having to know every recipient individually.

Data model: the biggest difference

Especially with industrial measurement data, the numerical value alone is rarely sufficient.

A pressure value requires context

For example:

• measurement point,
• measured variable,
• unit,
• timestamp,
• quality,
• measuring range,
• sensor ID.

OPC UA

OPC UA provides a standardized information model for this using:

• Nodes,
• Objects,
• Variables,
• References,
• DataTypes,
• Properties.

MQTT

MQTT transports a message to a topic.

What the following means within that message:

6.42

must be defined by the application.

Poor MQTT example

Topic: sensor17

Payload: 6.42

For example, the following information is missing:

• measured variable,
• unit,
• location,
• time reference,
• quality information.

Better

plant/berlin/line3/pump17/pressure/discharge

with:

{"value":6.42,"unit":"bar","ts":"2026-08-19T10:15:42.250Z","quality":"good"}

Structuring MQTT topics correctly

MQTT topics can be structured hierarchically.

The individual levels are typically separated by:

/

.

Example of an industrial structure

plant/{plant}/area/{area}/line/{line}/device/{id}/measurement/{measured_variable}

Specific example

plant/berlin/area/production/line/3/device/pump17/measurement/pressure

Stable IDs are important

A topic that depends on freely changeable descriptive text, for example, would be unfavorable.

Better choices include:

• unique asset IDs,
• a clearly defined naming scheme,
• documented versioning.

Do not confuse topics with the complete data model

The topic hierarchy can already contain technical information.

However, it does not automatically replace a consistent data model.

Defining the MQTT payload clearly

A common IIoT mistake is to introduce MQTT without defining a consistent payload schema.

System A sends

{"pressure":6.42}

System B sends

{"p":6.42,"u":"bar"}

System C sends

6.42

Consequence

Every downstream application requires individual translation logic.

Better

Define a common schema, for example:

{"value":6.42,"unit":"bar","timestamp":"2026-08-19T10:15:42.250Z","quality":"good"}

Additional possible fields

• deviceId,
• measurementId,
• status,
• alarm,
• rangeMin,
• rangeMax,
• firmwareVersion,
• configurationVersion.

Handling timestamps correctly for measurement data

For measurement data, it is not only important to know:

Which value?

but also:

When was this value actually acquired?

OPC UA distinguishes between different time references

An OPC UA DataValue can contain, among other things:

• SourceTimestamp,
• ServerTimestamp.

SourceTimestamp

describes, where possible, the time at the original source of the measured value.

ServerTimestamp

describes the time at which the server received the value or recognized it as valid.

With MQTT, the measurement time must be defined deliberately

Just because the broker receives a message at:

10:15:45

does not mean that the measured value was acquired at that time.

Example with offline buffering

Sensor value acquired:

10:10:00

Network available again:

10:15:00

Message published:

10:15:01

Without a measurement timestamp, the historian could assign the value to a point in time five minutes too late.

Recommendation

For MQTT telemetry, the payload for relevant process data should contain an unambiguous:

UTC timestamp of measurement acquisition

.

Transmitting measurement quality

A measured value is not automatically valid simply because it is available as a number.

Example

A pressure value is:

6.42 bar

but the sensor is simultaneously in a diagnostic state.

OPC UA

OPC UA can transmit a StatusCode together with the value.

This allows a distinction, for example, between:

• Good,
• Uncertain,
• Bad

.

MQTT

With a custom MQTT data model, corresponding quality information should be explicitly included.

For example:

{"value":6.42,"unit":"bar","quality":"bad"}

Why is this important?

A historian should not treat an invalid sensor value in the same way as a valid process value.

Documenting units and scaling

The numerical value:

25

could, for example, mean:

• 25 bar,
• 25 kPa,
• 25 °C,
• 25 %,
• 25 mm.

OPC UA

OPC UA provides standardized options for describing engineering units for variables.

MQTT

With MQTT, the unit must be specified, for example:

• in the payload,
• via metadata,
• via a central schema definition

.

Do not hide scaling only in the receiving system

A raw value such as:

16384

is problematic in the long term if only one PLC knows that:

16384 corresponds to 6.42 bar

A well-designed edge/IIoT architecture should provide measured variables as clearly and as well documented as possible.

Comparing communication direction

The direction of communication has a significant influence on the network architecture.

OPC UA Client/Server

Typically:

Client → connection to server

The client reads, browses or subscribes to information from the server.

MQTT

Typically:

Publisher → outbound connection to broker

and:

Subscriber → connection to broker

Advantage for IT/cloud integration

An edge gateway can actively transmit measurement data outward to a defined broker.

This means that not every higher-level system necessarily has to access each field device directly.

OT perspective

For local SCADA or machine integration, on the other hand, browsing and selectively reading an OPC UA server can be particularly convenient.

Understanding MQTT QoS correctly

MQTT defines three Quality of Service levels:

QoS	Basic principle	Typical consideration
0	At most once	Low overhead, message may be lost
1	At least once	Delivery is acknowledged, duplicates are possible
2	Exactly once	Higher protocol overhead

QoS is not measurement quality

This is an important distinction.

MQTT QoS

describes message transmission.

It says nothing about whether:

the pressure sensor is measuring correctly

QoS does not replace a timestamp either

A reliably delivered message can still contain an old, buffered measured value.

Using retained messages appropriately

MQTT can store a message for a topic as:

retained

.

A new subscriber can therefore immediately receive the most recently stored value.

Well suited, for example, for

• device status,
• configuration information,
• last known state,
• certain metadata.

Use caution with events

An old alarm should not appear to be a new event simply because a new subscriber receives the retained message.

Distinguish between state and event

state

and:

event

should therefore be clearly separated in the data model.

Bandwidth and data volume

MQTT is often used where measurement data needs to be distributed efficiently to higher-level systems.

Data volume does not depend only on the protocol

The following are equally important:

• sampling rate,
• publication rate,
• payload size,
• number of measurement points,
• QoS,
• metadata,
• connection setup.

Distinguish between sampling and publishing

An edge gateway can, for example, internally acquire:

10 values/s

.

However, only:

1 value/s

or statistical values may be transmitted to the IT system.

Edge preprocessing

Possible functions:

• Min/Max,
• mean value,
• median,
• deadband,
• publish-on-change,
• alarm events.

Role of the edge gateway

In many industrial plants, an edge gateway is located between field technology and IT.

Typical architecture

Sensors / PLC / field devices

↓

Modbus / HART / IO-Link / OPC UA

↓

Edge Gateway

↓

MQTT / HTTPS / OPC UA

↓

SCADA / Historian / MES / Cloud

Edge tasks

The gateway can, for example:

• read field protocols,
• scale raw values,
• standardize units,
• set or adopt timestamps,
• map quality information,
• generate topics,
• calculate local alarms,
• buffer data,
• translate protocols.

The gateway therefore becomes a semantic boundary

At precisely this point, it should be clearly documented:

How does a field value become a measurement value that can be used by IT?

Integrating brownfield plants

Existing plants often do not have modern IIoT interfaces.

Typical existing signals

• 4 … 20 mA,
• 0 … 10 V,
• HART,
• Modbus RTU,
• PROFIBUS,
• digital switching states.

These devices do not necessarily have to be replaced

An edge system can acquire existing signals and convert them into a standardized data model.

Example

4 … 20 mA pressure transmitter

↓

Edge analog input

↓

Scaling 0 … 10 bar

↓

MQTT payload with value + unit + time + quality

Or

An existing PLC already provides structured data via OPC UA.

The edge system can then adopt this data and publish it, for example via MQTT, for additional IT systems.

OPC UA for SCADA and OT

OPC UA is particularly strong when a higher-level system needs to understand the structure of an industrial system and access data selectively.

Typical applications

• SCADA,
• HMI,
• machine integration,
• PLC communication,
• process control systems,
• OT data hubs.

Advantage

A client can browse the provided structure and does not have to rely solely on an externally maintained list of cryptic data points.

Commands and methods are also possible

OPC UA is therefore not limited to pure telemetry.

Depending on the implemented model, it can also provide:

• write access,
• methods,
• events,
• diagnostic information

.

MQTT for IT, cloud and site connectivity

MQTT is particularly suitable for the decoupled distribution of telemetry data.

Typical architecture

Plant A ─┐

Plant B ─┼→ MQTT Broker → Data Platform

Plant C ─┘

Multiple consumers

The same measurement data can, for example, be used simultaneously by:

• historian,
• dashboard,
• alarm service,
• analytics system,
• MES

.

Adding a new application

The existing field communication does not necessarily have to be changed.

The new subscriber simply subscribes to the required topics.

Security with OPC UA and MQTT

Both technologies can be operated securely.

However, their security mechanisms differ in architecture.

OPC UA

OPC UA has its own security mechanisms, including those relating to:

• Secure Channels,
• application certificates,
• authentication,
• authorization,
• signing and encryption according to the profiles used.

MQTT

MQTT itself must not be equated with encryption.

A secure industrial MQTT architecture typically additionally uses:

• TLS,
• broker authentication,
• client certificates or suitable credentials,
• topic-based permissions,
• network segmentation,
• firewall rules.

Example permissions concept

A measurement gateway is allowed to:

PUBLISH plant/berlin/line3/#

but not:

SUBSCRIBE plant/other-site/#

Least Privilege

A device should only be able to access the topics or OPC UA areas required for its task.

Connection interruptions and buffering

Industrial networks and site connections are not always continuously available.

Example

The edge gateway acquires:

60 measured values/min

The connection to the central system fails for:

10 minutes

.

Without local buffering

a data gap occurs.

With Store-and-Forward

measured values can be stored locally and transferred once the connection has been restored.

Timestamps are again critical

The stored values must retain their original:

measurement time

.

Otherwise the entire backlog would be assigned to the wrong time.

Using OPC UA and MQTT together

For many industrial projects, a combination is particularly useful.

Example architecture

PLC / Machine

↓ OPC UA

Edge Gateway

↓ MQTT

Broker

↓

Historian / Dashboard / MES / Cloud

OPC UA handles

• structured OT integration,
• browsing,
• data types,
• semantics,
• status and time information.

MQTT handles

• decoupled distribution,
• broker communication,
• distribution to many subscribers,
• site and IT integration.

Mapping is crucial

The edge system must, for example, define:

OPC UA Node Pump17.DischargePressure

becomes:

plant/berlin/line3/pump17/pressure/discharge

with payload:

{"value":6.42,"unit":"bar","quality":"good","ts":"2026-08-19T10:15:42.250Z"}

Do not lose semantics

A protocol conversion is only complete when, in addition to the numerical value, the unit, quality, time reference and asset assignment are also transferred correctly.

Typical errors in OPC UA and MQTT integrations

Observation	Possible cause	Recommended check
MQTT values are available, but nobody knows the unit	Incomplete payload/metadata model	Add unit and measured variable to the schema
Dashboard shows values shifted in time	Broker/receive time used instead of measurement time	Transmit and evaluate source timestamp
Invalid sensor value is stored as valid	Quality information lost during mapping	Add status/quality field to the data model
Every application requires its own parsing	Different MQTT payloads	Define a consistent schema
MQTT topic structure becomes unusable after plant modification	Topics are based on changeable names instead of stable IDs	Revise asset and topic concept
SCADA does not automatically find data points	Pure MQTT telemetry without a corresponding information model	Check OPC UA interface or mapping
Many direct connections place a load on the PLC	Many independent clients access it directly	Check edge/broker architecture
Measured values are missing after a connection failure	No local buffering	Provide Store-and-Forward at the edge
After reconnection, old data appears as new values	Measurement timestamp missing	Preserve original timestamp
Old alarm appears again for a new subscriber	Retained message used inappropriately for an event	Model state and event separately
MQTT works but is unencrypted	TLS not configured	Check broker, client and certificate configuration
OPC UA connection fails after certificate replacement	Trust/certificate management not updated	Check certificates and trust lists

Systematic selection procedure for OPC UA or MQTT

1. Determine the data source: Identify sensor, PLC, machine, edge system or database.
2. Determine existing interfaces: Document 4 … 20 mA, HART, Modbus, IO-Link, OPC UA, Ethernet or other protocols.
3. Determine data consumers: Distinguish between SCADA, HMI, historian, MES, ERP, dashboard or cloud.
4. Define communication direction: Determine direct query, subscription or publish/subscribe.
5. Evaluate the data model: Determine whether structured objects, types and relationships are required.
6. Define asset identities: Assign stable machine, sensor and measurement-point IDs.
7. Define measured variables: Clearly specify value, unit and measuring range.
8. Define the time model: Distinguish between measurement time, receive time and server time where applicable.
9. Define the quality model: Provide Good/Bad/Uncertain or an equivalent custom model.
10. Consider OPC UA: Particularly for structured OT/SCADA communication and browsing.
11. Consider MQTT: Particularly for decoupled telemetry, many data consumers or IT/cloud integration.
12. Consider a combination: OPC UA on the OT side and MQTT toward IT may be more useful than an either-or decision.
13. Define the topic schema: For MQTT, define stable hierarchical topics.
14. Define the payload schema: Standardize value, unit, timestamp, quality and additional metadata.
15. Select QoS: Consider message relevance and permissible communication overhead.
16. Define the retain concept: Distinguish between state values and events.
17. Separate sampling and publication rates: Adapt data volume to process requirements.
18. Define offline behavior: Consider buffering, restart and Store-and-Forward.
19. Create a security concept: Plan TLS, certificates, authentication, permissions and segmentation.
20. Build a pilot: Fully integrate several representative measurement points.
21. Check data quality: Verify values, unit, time, quality and asset assignment end-to-end.
22. Document the mapping: Record field variable → OPC UA Node → MQTT Topic → target system in a traceable manner.
23. Test scalability: Add additional devices and subscribers and observe system load.
24. Define an operating concept: Assign responsibility for certificates, broker, gateway, data model and changes.

Practical example: measurement data from a pumping system

A production plant has several pumps.

For each pump, the following are measured:

• suction pressure,
• discharge pressure,
• temperature,
• vibration,
• operating status.

Requirement 1: local SCADA

The SCADA system should:

• browse all pumps,
• display measured values,
• receive status information.

Requirement 2: central historian

A cross-site historian should store selected measurement values.

Requirement 3: Condition Monitoring

An analytics application requires:

• vibration indicators,
• temperature,
• operating status.

Step 1: OPC UA at OT level

The pump information is provided in a structured form.

For example:

Pump17

├── SuctionPressure

├── DischargePressure

├── Temperature

├── Vibration

└── Running

Step 2: Edge system acquires the data

The edge system acquires relevant measurement data including:

• measured value,
• timestamp,
• quality,
• asset assignment.

Step 3: MQTT toward IT

For the discharge pressure, for example, the following is published:

plant/berlin/line3/pump17/pressure/discharge

Payload:

{"value":6.42,"unit":"bar","quality":"good","ts":"2026-08-19T10:15:42.250Z"}

Step 4: multiple subscribers

The same value is used by:

• historian,
• dashboard,
• condition-monitoring application.

Step 5: connection to the central system fails

The edge system temporarily stores the measured values locally.

Step 6: connection becomes available again

The buffered data is transmitted.

The historian continues to use:

the original measurement timestamp

and not the time of the later transmission.

Result

In this example, OPC UA structures the OT data, while MQTT distributes selected measured values in a decoupled manner to several IT applications. The two technologies perform different tasks within the same architecture.

Suitable ICS solutions for OPC UA and MQTT architectures

ICS IIoT Solutions

For this topic, the complete data architecture is more important than a single sensor.

ICS Schneider describes its IIoT solutions as a connection of:

Sensors / field devices → Edge Gateway → IT/OT systems

using technologies such as:

• RS-485 / Modbus RTU,
• HART,
• IO-Link,
• OPC UA,
• Ethernet,
• MQTT,
• HTTPS.

Typical tasks of the edge system

Within such an architecture, the following may be required, among other things:

• data acquisition,
• register mapping,
• scaling,
• data modeling,
• timestamping,
• topic design,
• local alarm processing,
• secure transmission to SCADA or cloud.

Further information can be found under IIoT Solutions at ICS Schneider.

Siemens SITRANS MS200 as an example of an IIoT measurement chain

A specific IIoT field device listed by ICS is the:

Siemens SITRANS MS200

with article number:

7MP2210-2AB21-2AB1

The MS200 is a Bluetooth IIoT multisensor for:

• vibration,
• temperature.

The ICS product page specifies use in combination with the:

SITRANS CC220 Gateway

and the corresponding Siemens monitoring solution.

Important for this article

The MS200 serves here as an example showing that an IIoT sensor does not automatically have to be an:

MQTT client

or:

OPC UA server

itself.

The higher-level gateway or platform determines how the data is subsequently integrated into other systems.

Concrete support for OPC UA, MQTT or other IT protocols must therefore always be checked for the actual gateway, firmware and software configuration being used.

Further information can be found under Siemens SITRANS MS200 at ICS Schneider.

Siemens IIoT weighing electronics for SIMATIC IOT2050

Another example listed by ICS is:

7MH4647-0KK00-0AA2

The IIoT weighing electronics has one channel for connecting a:

load cell / full strain-gauge bridge 1 … 4 mV/V

and, according to ICS, is intended for the:

SIMATIC IOT2050 Gateway

.

Typical architecture

Load cell → IIoT weighing electronics → SIMATIC IOT2050 → higher-level system

The same applies here

The ICS product page identifies the weighing electronics as hardware for SIMATIC IOT2050.

Which specific:

• OPC UA functions,
• MQTT functions,
• security functions,
• software packages

are available in a particular application depends on the gateway and software configuration used and must be checked on a project-specific basis.

Further information can be found under Siemens IIoT Weighing Electronics 7MH4647-0KK00-0AA2 at ICS Schneider.

Which solution is suitable for which task?

Requirement	Typical approach
Browse machine structure and provide measured values with semantics	Consider OPC UA
Distribute measured values to many IT systems	Consider MQTT
SCADA integration within OT	OPC UA is often particularly suitable
Edge-to-cloud telemetry	MQTT is often particularly suitable
Integrate existing field devices into IIoT	Edge gateway with field-protocol mapping
Additionally distribute structured OT data to the cloud	OPC UA → Edge → MQTT
OPC UA semantics with Publish/Subscribe	Consider OPC UA PubSub
OPC UA PubSub via broker	MQTT can be used as the transport

Conclusion

The question:

OPC UA or MQTT?

cannot be answered with one universal winner.

Both technologies have different strengths.

OPC UA is particularly strong in

• structured industrial information models,
• browsing,
• SCADA and OT integration,
• data types and metadata,
• status information,
• source and server timestamps,
• engineering units.

MQTT is particularly strong in

• publish/subscribe telemetry,
• decoupled communication,
• distribution to many data consumers,
• edge-to-IT communication,
• cross-site architectures,
• cloud and data-platform integration.

The most important difference

MQTT alone does not automatically define an industrial data model.

A topic such as:

sensor17

and a payload such as:

6.42

can be transmitted technically, but provide only limited technical meaning.

For measurement data that remains reliable and usable over the long term, the following must additionally be defined:

• measurement point,
• measured variable,
• unit,
• timestamp,
• data quality,
• asset ID,
• schema version.

OPC UA and MQTT can complement each other

A very typical architecture is:

Field device / PLC → OPC UA → Edge → MQTT → Broker → IT / Cloud

In addition, OPC UA itself has a PubSub model that can also use MQTT as a broker-based transport.

The correct architecture is therefore not created by deciding on a protocol name, but by clearly assigning the tasks: field integration → data model → time and quality → edge processing → transport → data consumers → security → operation.

For practical applications:

Determine data source → determine existing interface → define data consumers → define communication direction → design data model → assign stable asset IDs → define unit, timestamp and quality → consider OPC UA for structured OT integration → consider MQTT for decoupled telemetry → evaluate a combination of both technologies → define topic and payload schema → select QoS and retain appropriately → provide offline buffering → plan TLS/certificates/permissions → test end-to-end mapping → define documentation and responsibilities.

FAQ: OPC UA or MQTT for Industrial Measurement Data

What is the most important difference between OPC UA and MQTT?

OPC UA includes a comprehensive industrial information model and various communication mechanisms. MQTT is primarily a publish/subscribe messaging protocol for distributing application messages via topics and a broker.

Is OPC UA a client/server protocol?

OPC UA supports client/server communication but also has its own publish/subscribe model.

Is MQTT always Publish/Subscribe?

The basic MQTT communication model is based on publishers, a broker and subscribers.

Can OPC UA also use Publish/Subscribe?

Yes. OPC UA PubSub complements the classic client/server model.

Can OPC UA PubSub use MQTT?

Yes. In a broker-based architecture, OPC UA PubSub can use MQTT, among other technologies, as the messaging transport.

Does that mean OPC UA and MQTT are not alternatives?

They can be alternatives for certain tasks, but they often perform different roles and can be combined within the same architecture.

When is OPC UA particularly suitable?

When structured machine data, browsing, industrial semantics, status information or classic SCADA/OT integration is required.

When is MQTT particularly suitable?

When measurement data needs to be distributed efficiently and in a decoupled manner to one or more data consumers, sites or IT/cloud systems.

What is an OPC UA Address Space?

The Address Space is the structured information representation of an OPC UA server. It includes objects, variables, types and relationships, among other things.

What is an MQTT topic?

A topic is the designation of the information channel under which an MQTT message is published.

Can MQTT topics be structured hierarchically?

Yes. Topic levels are separated by a forward slash.

What is a good MQTT topic for a pressure sensor?

For example, plant/berlin/line3/pump17/pressure/discharge. However, the specific schema should be defined consistently for the entire plant.

Should the unit be included in the MQTT topic?

Not necessarily. It is often preferable to include the unit in the payload or in defined metadata so that the topic does not have to change when the display unit changes.

Does MQTT define the JSON format?

No. MQTT transports application-specific payload data. JSON is only one possible payload representation.

Does MQTT have to use JSON?

No. Depending on the application, the payload can contain text, JSON or binary data, for example.

What should an MQTT measurement payload contain?

For many industrial applications, at least the value, timestamp and quality information are useful. Depending on the topic and metadata concept, the unit, measurement-point ID and additional information may also be required.

Why is the timestamp important?

Because the time of measurement may differ from the time of transmission or storage.

What is the SourceTimestamp in OPC UA?

It describes the timestamp as close as possible to the original source of the measured value.

What is the ServerTimestamp?

It describes the time at which the OPC UA server received the value or recognized it as valid.

Does MQTT automatically have a measurement timestamp?

An application-specific measurement timestamp must deliberately be included in the data model if it is required for the application.

What is an OPC UA StatusCode?

A StatusCode describes the usability or quality of a value and can indicate Good, Uncertain or Bad, among other states.

Does MQTT automatically provide Good/Bad quality values?

No. Such measurement quality must be defined and transmitted by the MQTT data model or application being used.

What does MQTT QoS mean?

QoS describes the service level of message transmission between MQTT clients and the broker.

Which MQTT QoS levels are available?

MQTT defines QoS 0, QoS 1 and QoS 2.

What does QoS 0 mean?

At most once – the message is transmitted without the acknowledgment mechanism used by the higher QoS levels.

What does QoS 1 mean?

At least once – delivery is acknowledged, although under certain conditions a message may arrive at the recipient more than once.

What does QoS 2 mean?

Exactly once – MQTT uses a more extensive message exchange to achieve exactly-once transmission at protocol level.

Is MQTT QoS the same as measurement quality?

No. MQTT QoS concerns message transmission. It says nothing about the metrological quality of the sensor value.

What is a retained message?

The broker can store the most recently published retained message for a topic and provide it to new matching subscribers.

Should alarms be transmitted as retained messages?

State information can benefit from this. With events, however, care must be taken to prevent an old stored alarm from being incorrectly interpreted as a new event.

What is an MQTT broker?

The broker receives messages from publishers and distributes them to authorized subscribers based on topics and subscriptions.

Does every sensor need to support MQTT directly?

No. A field device can, for example, use 4 … 20 mA, HART, Modbus or OPC UA. An edge gateway can generate MQTT telemetry from these signals.

Does every sensor need to support OPC UA directly?

No. A PLC, remote I/O or edge gateway can also integrate existing field signals and subsequently provide them via OPC UA.

What does edge gateway mean?

An edge gateway forms an interface between field/OT technology and higher-level IT systems and can, among other things, translate protocols, scale values, buffer data and add metadata.

Can I transmit a 4–20 mA sensor via MQTT?

Yes. The analog signal must first be digitized and scaled using suitable input hardware. An edge system can then transmit the resulting measured value via MQTT.

Can I convert Modbus to MQTT?

Yes. A suitable gateway can read Modbus registers, scale them and convert them into an MQTT data model.

Can I convert OPC UA to MQTT?

Yes. An edge system can obtain information from an OPC UA server and publish selected data as MQTT messages.

What must be preserved during this conversion?

In addition to the value, particular attention should be paid to measurement-point identity, unit, timestamp and quality information.

Is OPC UA suitable for cloud applications?

OPC UA can also be used in appropriate IT architectures. However, in many IIoT projects, MQTT is used for decoupled telemetry toward IT or cloud systems.

Is MQTT suitable for SCADA?

MQTT can be used in SCADA architectures if the SCADA system and data model are designed accordingly. For conventional browsing of structured OT data, however, OPC UA often provides advantages.

Is MQTT encrypted?

MQTT should not automatically be equated with encrypted communication. TLS or another appropriately secured transport connection is typically used for secure connections.

Is OPC UA encrypted?

OPC UA supports security mechanisms including Secure Channels, certificates, signing and encryption in appropriate security configurations.

Does OPC UA require certificates?

For secure OPC UA communication, application certificates and the management of trusted applications play an important role.

Can MQTT use client certificates?

Yes. In a TLS-secured MQTT architecture, client certificates can be used for authentication if the broker and clients are configured accordingly.

What happens if the Internet connection fails?

An edge system can buffer measured values locally and forward them once the connection has been restored if the specific solution provides an appropriate Store-and-Forward function.

Why is the original timestamp important in this case?

So that a measured value transmitted later can still be assigned to its actual measurement time.

What is brownfield integration?

This refers to integrating existing plants and devices into a new data or IIoT architecture without having to replace all field devices.

Which field protocols does ICS specify for IIoT integrations?

ICS lists Modbus RTU, HART, IO-Link, OPC UA and Ethernet, among others, as well as corresponding edge integrations.

What role does ICS specify for MQTT?

ICS describes MQTT particularly as lightweight publish/subscribe telemetry between edge and IT systems.

What role does ICS specify for OPC UA?

ICS mentions OPC UA particularly for models, browsing and SCADA integration, as well as part of brownfield integration.

What is the Siemens SITRANS MS200?

The SITRANS MS200 is a Bluetooth IIoT multisensor listed by ICS for vibration and temperature monitoring.

Which gateway does ICS specify for the SITRANS MS200?

The ICS product page specifies SITRANS CC220 as the associated gateway for this solution.

Does this automatically mean that the MS200 itself supports MQTT or OPC UA?

No. The specific data communication of the complete solution must be checked at gateway, software and firmware level.

What is 7MH4647-0KK00-0AA2?

It is an IIoT weighing electronics module listed by ICS for a load cell or full strain-gauge bridge with 1 … 4 mV/V for use with SIMATIC IOT2050.

Does the weighing electronics directly support OPC UA or MQTT?

The ICS product page describes it as weighing electronics for SIMATIC IOT2050. Which higher-level communication protocols are available must be determined based on the actual gateway and software configuration used.

Where can I find IIoT solutions at ICS Schneider?

Further information can be found under IIoT Solutions at ICS Schneider.

Where can I find the SITRANS MS200 at ICS Schneider?

Further information can be found under Siemens SITRANS MS200 at ICS Schneider.

Where can I find the IIoT weighing electronics for SIMATIC IOT2050 at ICS Schneider?

Further information can be found under 7MH4647-0KK00-0AA2 at ICS Schneider.