Messaging, Protocols, and Interoperability

Introduction

An Internet of Things (IoT) system is not merely a collection of sensors connected to the Internet. It is a distributed engineering system in which devices, controllers, gateways, applications, databases, and human users exchange information reliably and meaningfully. Messaging protocols determine how information is transported; data models determine what the information means; gateways connect networks with different capabilities; and interoperability allows independently developed components to cooperate.

In mechatronics, these concerns are especially important. A production cell may contain programmable logic controllers (PLCs), servo drives, robot controllers, vision systems, safety devices, energy meters, and cloud services. Each may use different addressing schemes, message formats, timing assumptions, and security mechanisms. A successful IoT architecture must therefore address two questions:

1. How is data delivered from one endpoint to another?
2. How can the receiving system interpret the data correctly and safely?

This chapter develops the foundations needed to design such systems. It covers addressing, gateways, application programming interfaces (APIs), REST, MQTT, CoAP, OPC UA, publish–subscribe communication, serialization, semantic interoperability, time synchronization, and standards-based integration.

Learning objectives

After studying this chapter, you should be able to:

• distinguish device, network, service, and resource addressing;
• explain the function and limitations of gateways;
• compare request–response and publish–subscribe communication;
• design basic REST, MQTT, CoAP, and OPC UA interactions;
• select suitable data-serialization formats;
• explain syntactic, structural, and semantic interoperability;
• identify the role of timestamps and time synchronization;
• integrate industrial devices using standards-based interfaces;
• evaluate reliability, security, scalability, and maintainability trade-offs.

1. Communication as a layered engineering problem

IoT communication is commonly understood through layers. At the lower levels, physical and link technologies move bits across media such as Ethernet, Wi-Fi, 5G, or industrial fieldbus. The Internet Protocol (IP) provides logical addressing and routing. Transport protocols such as TCP and UDP provide different delivery properties. Application protocols define the meaning and interaction pattern of messages.

A useful distinction is:

• Payload: the application data, such as temperature, motor speed, or alarm state.
• Metadata: information about the payload, such as its unit, timestamp, quality, source, and encoding.
• Envelope: protocol information used for routing, delivery, authentication, and correlation.

For example, a temperature message may contain the value 72.4, but this number is incomplete without its unit, sensor identity, measurement time, calibration status, and physical location. Interoperable systems transmit both values and the context required to interpret them.

Addressing

Addressing occurs at several levels:

An IP address identifies a network location, not necessarily a permanent physical identity. Devices may receive addresses dynamically through DHCP, while an asset identity should remain stable even if its network location changes. Robust systems therefore separate network addressing from logical asset naming.

IPv4 uses 32-bit addresses, whereas IPv6 uses 128-bit addresses and supports a substantially larger address space. Address planning should consider device growth, network segmentation, remote access, address translation, and security zones. A device should not be exposed directly to the public Internet merely because it has an address. Firewalls, virtual networks, authentication, and controlled gateways are normally required.

2. Gateways and edge integration

A gateway connects networks, protocols, or data models. In a mechatronic installation it might connect Modbus RTU devices on an RS-485 bus to an MQTT broker over Ethernet, or expose PLC data through OPC UA to a manufacturing execution system.

Gateways perform several possible functions:

• protocol translation, such as Modbus-to-MQTT;
• data aggregation and filtering;
• buffering during cloud or network outages;
• address translation and routing;
• security enforcement and certificate validation;
• unit conversion and data normalization;
• local analytics and event detection;
• device provisioning and lifecycle management.

A gateway should not be viewed as a magical universal translator. Protocol translation may preserve bytes while losing semantics. For example, a Modbus register containing the integer 250 does not reveal whether the value means 25.0 °C, 250 rpm, or an alarm code. Engineering metadata must therefore be configured explicitly or obtained from a standard information model.

Edge versus cloud responsibilities

Time-critical control should normally remain close to the machine. Cloud services are valuable for long-term storage, fleet analysis, optimization, and remote supervision, but dependence on a distant service introduces latency and availability risks. A practical architecture often assigns control loops and safety functions to local controllers, while gateways perform protocol adaptation and the cloud performs broader analysis.

3. Interaction models

Request–response

In request–response communication, a client sends a request and a server returns a response. The client usually initiates each transaction. HTTP and CoAP commonly use this model.

A request typically contains a method, target resource, headers, and optional payload. The response contains a status code, headers, and optional data. Request–response is intuitive and appropriate for configuration, resource retrieval, and administrative operations. Its limitations include repeated polling, dependence on server availability, and inefficient delivery when data changes frequently.

Publish–subscribe

In publish–subscribe communication, producers publish messages to named topics, while consumers subscribe to topics. A broker receives publications and distributes them to matching subscribers. Publishers and subscribers need not know each other directly.

This model provides spatial decoupling, because endpoints do not need direct addresses; temporal decoupling, because a broker may retain messages; and synchronization decoupling, because producers and consumers operate independently. It is well suited to telemetry, alarms, and event distribution. However, topic design, access control, retained messages, ordering, and duplicate delivery must be managed carefully.

Quality of service

Communication quality is not a single property. It includes latency, throughput, availability, delivery assurance, ordering, freshness, and integrity. A message marked “delivered” may only have reached a broker, not the final application. Engineers must define the required guarantee precisely.

In MQTT, Quality of Service (QoS) levels are commonly described as:

• QoS 0: at most once; no protocol-level retransmission;
• QoS 1: at least once; duplicates are possible;
• QoS 2: exactly once at the MQTT protocol level, with greater overhead.

“Exactly once” does not automatically mean that an industrial action occurs exactly once. The application must also be idempotent or use transaction identifiers. A command to open a valve should include a command ID and device-side duplicate handling rather than relying on transport semantics alone.

4. APIs and REST

An API is a defined interface through which software components request data or operations. A well-designed API specifies resources, operations, representations, authentication, errors, versioning, and rate limits.

Representational State Transfer (REST) is an architectural style commonly implemented over HTTP. Its important constraints include client–server separation, stateless requests, cacheable responses where appropriate, a uniform interface, and layered components.

Typical HTTP methods include:

• GET: retrieve a resource;
• POST: submit data or request creation of a subordinate resource;
• PUT: create or replace a resource at a known URI;
• PATCH: partially modify a resource;
• DELETE: remove a resource.

A REST resource might be represented as:

{
  "assetId": "press-07",
  "temperature": 72.4,
  "unit": "degC",
  "quality": "good",
  "observedAt": "2025-03-08T10:15:30Z"
}

The representation is not the resource itself; it is a transferable description of the resource. HTTP status codes communicate outcomes. For example, 200 indicates successful retrieval, 201 successful creation, 400 an invalid request, 401 missing or invalid authentication, 403 insufficient authorization, 404 an unknown resource, and 409 a conflict.

REST is effective for configuration, historical queries, and integration between enterprise applications. It is less suitable for extremely constrained devices or high-rate event streams unless combined with streaming, webhooks, or a broker-based system.

5. MQTT

MQTT is a lightweight application protocol designed for constrained devices and unreliable networks. It uses a client–broker architecture. A client establishes a connection to a broker, publishes messages, subscribes to topics, and may receive messages from other clients through the broker.

A topic is a UTF-8 hierarchical string, such as plant/line1/press07/temperature. Topic names should be stable, meaningful, and designed with authorization in mind. Wildcards allow subscriptions to groups of topics; for example, plant/line1/+/temperature may match temperatures from all assets on a line.

Important MQTT features include:

• retained messages, which provide the latest retained value to a new subscriber;
• Last Will and Testament messages, which can announce unexpected disconnection;
• persistent sessions, depending on protocol version and broker configuration;
• QoS levels for delivery assurance;
• TLS-based transport security and client authentication.

MQTT does not inherently define the meaning of a payload. JSON, CBOR, Protocol Buffers, or a domain-specific model may be carried inside the message. Thus MQTT provides transport interaction, not complete semantic interoperability.

6. CoAP

The Constrained Application Protocol (CoAP) is designed for constrained nodes and low-power or lossy networks. It resembles HTTP in its resource-oriented request–response model but uses compact binary encoding and commonly runs over UDP. CoAP supports methods such as GET, POST, PUT, and DELETE, resource discovery, confirmable messages, and asynchronous communication.

A confirmable CoAP message requires acknowledgment or retransmission according to protocol rules; a non-confirmable message reduces overhead when occasional loss is acceptable. CoAP can be secured using Datagram Transport Layer Security (DTLS), Object Security for Constrained RESTful Environments (OSCORE), or suitable network protections.

CoAP is appropriate for small embedded devices and local constrained networks. MQTT is often preferable when broker-based event distribution and enterprise integration are central. The choice depends on network conditions, device resources, communication pattern, and operational requirements.

7. OPC UA and industrial interoperability

OPC Unified Architecture (OPC UA) is a platform-independent framework for industrial communication. It supports client–server interactions, subscriptions, events, methods, security services, and rich information models. An OPC UA server exposes an address space containing objects, variables, methods, relationships, data types, engineering units, and metadata.

This information-model approach is a major distinction from a simple register protocol. A variable can be described as a motor speed with a unit, data type, engineering range, status, and timestamp. OPC UA also supports companion specifications that define models for particular industrial domains.

OPC UA PubSub extends OPC UA concepts to publisher–subscriber communication. It can use transports such as UDP or MQTT, allowing industrial information models to move through broker-based architectures.

OPC UA security may include application authentication, user authentication, signing, encryption, certificate management, and role-based authorization. Security configuration is an engineering responsibility: default credentials, unmanaged certificates, excessive privileges, and unrestricted methods create serious risks.

8. Data serialization and information models

Serialization converts structured data into a transferable representation. Deserialization reconstructs the data at the receiving endpoint. Common formats include:

Serialization is not the same as semantic modeling. JSON can represent a temperature, but a shared schema is needed to define whether temperature is measured in Celsius, Fahrenheit, or kelvin; whether the value is instantaneous or averaged; and how quality is represented.

A robust message often includes:

• stable asset identifier;
• measurement or command name;
• value and explicit unit;
• timestamp and time basis;
• quality or validity status;
• source and schema version;
• correlation or command identifier where applicable.

Schema evolution must be planned. Additive changes are often safer than changing the meaning of an existing field. Versioning, validation, backward compatibility, and rejection of malformed messages should be treated as lifecycle concerns.

9. Interoperability and semantics

Interoperability has several levels:

1. Technical interoperability: systems can exchange signals or packets.
2. Syntactic interoperability: systems agree on message structure and encoding.
3. Structural interoperability: fields and relationships are organized consistently.
4. Semantic interoperability: systems interpret data with the same meaning.
5. Organizational interoperability: processes, responsibilities, and policies align.

The semantic problem is often the most difficult. Consider three fields: speed, velocity, and rpm. They may describe different quantities, reference frames, or units. Semantic interoperability requires common definitions, controlled vocabularies, units of measure, identifiers, and relationships among entities.

Standards and models that may support industrial integration include OPC UA information models, AutomationML, Asset Administration Shell concepts, ISA-95-related manufacturing structures, W3C Web of Things concepts, and domain-specific companion specifications. Standards should be selected according to the industrial domain and deployment constraints rather than adopted as labels without implementation discipline.

10. Time synchronization and event meaning

Time is essential when correlating sensor readings, diagnosing faults, calculating production intervals, or reconstructing an incident. A timestamp should identify when an observation occurred, not merely when a gateway forwarded it.

Common time protocols include:

• NTP: network-based synchronization suitable for many IT and moderate industrial applications;
• SNTP: simplified NTP implementation;
• PTP (IEEE 1588): precision synchronization capable of much tighter coordination on suitable networks;
• GNSS-based timing: provides a reference derived from satellite systems, subject to antenna and signal conditions.

A timestamp should specify a time scale or offset, commonly using UTC and an unambiguous format such as ISO 8601. Systems should distinguish event time, measurement time, processing time, and ingestion time.

For two devices, the clock offset may be represented conceptually as:

where t_A and t_B are simultaneous clock readings from devices A and B, and Δt is their offset. This expression is meaningful only when the readings are compared for the same reference event and the measurement uncertainty is understood. Network delay, asymmetric paths, oscillator drift, timestamping location, and synchronization method affect accuracy.

For a sensor sampled at frequency f_s, the nominal sampling interval is:

where T_s is in seconds when f_s is in hertz. This relation describes the intended sampling schedule; it does not guarantee accurate timestamps or absence of jitter.

11. Standards-based device integration workflow

A disciplined integration process can be organized as follows:

1. Define use cases. Identify telemetry, alarms, commands, configuration, diagnostics, and historical queries.
2. Identify assets and ownership. Assign stable identities and document device responsibilities.
3. Characterize constraints. Record bandwidth, latency, power, reliability, safety, and environmental requirements.
4. Choose interaction patterns. Use request–response for resource operations and publish–subscribe for events and telemetry where appropriate.
5. Select protocols. Consider MQTT, CoAP, OPC UA, HTTP, or existing industrial protocols.
6. Define information models. Specify types, units, quality, timestamps, relationships, and allowed values.
7. Design security. Establish identities, certificates or keys, authorization, network zones, logging, and update procedures.
8. Plan failure behavior. Define buffering, retries, duplicate handling, stale-data detection, and safe fallback states.
9. Test interoperability. Validate schemas, timing, error handling, security, load, and version compatibility.
10. Operate and govern. Monitor protocol health, certificate expiry, drift, data quality, and changes to schemas.

Worked example: selecting an integration pattern

A packaging cell contains a PLC, a vision camera, an energy meter, and a cloud dashboard. The PLC executes motion and interlocking logic. The camera produces inspection results. The energy meter reports values every five seconds. The dashboard needs live status and daily energy summaries.

A suitable design is:

• PLC and safety devices remain on the industrial control network.
• An edge gateway reads approved PLC variables through OPC UA.
• The gateway publishes normalized telemetry through MQTT.
• Inspection events use a topic such as plant/packaging/cell3/inspection.
• The dashboard uses MQTT for live updates and HTTPS REST APIs for historical queries.
• The gateway stores data locally during temporary cloud loss and republishes it with original measurement timestamps.
• Each inspection message contains asset ID, result, defect code, image reference, event time, quality, and schema version.
• Commands from the dashboard pass through an authenticated API and are converted into controlled OPC UA method calls; safety-critical actions cannot be issued by the dashboard.

This design separates control from monitoring, uses protocols according to their strengths, and preserves meaning through explicit metadata. It also recognizes that a gateway is a security boundary and a potential single point of failure, so redundancy and local fallback may be required.

Case study: illustrative smart machining cell

Background

A machining cell contains three CNC machines from different vendors, a robot, vibration sensors, and a plant analytics platform. One vendor exposes OPC UA, another provides an older proprietary TCP interface, and the vibration sensors use MQTT.

Problem

The analytics platform receives measurements but cannot reliably compare spindle speed, vibration, and downtime. Units differ, timestamps reflect gateway arrival rather than measurement time, and a network interruption causes duplicate records.

Analysis

The technical connections exist, but semantic and operational interoperability are weak. The integration team identifies four issues: inconsistent asset identities, inadequate metadata, unsynchronized clocks, and missing duplicate detection.

Approach and solution

The team assigns stable asset identifiers and creates a canonical model for spindle speed, vibration amplitude, machine state, and downtime reason. Each value includes unit, quality, measurement timestamp, source, and schema version. OPC UA data is read through modeled nodes; the proprietary TCP interface is isolated within a gateway adapter; MQTT vibration messages are validated against the canonical schema.

The gateway synchronizes clocks using an industrially suitable time service and records both measurement and ingestion times. Each message receives a unique event identifier. The analytics platform treats repeated event identifiers as duplicates rather than new observations. MQTT topics are organized by plant, cell, asset, and data class, with authorization rules preventing one machine from publishing to another machine’s command topic.

Outcome

The platform can compare data across vendors, distinguish late data from new data, and reconstruct machine events more accurately. The solution does not eliminate every problem: proprietary interfaces still require maintenance, and the canonical model must evolve as new machine types are added.

Learning points

• Connectivity does not guarantee interoperability.
• Meaning, time, identity, and quality are part of the data contract.
• Gateways should isolate legacy protocols rather than spread them through the enterprise.
• Duplicate handling must be designed at the application level.
• Standards reduce integration effort when implemented with disciplined information models.

12. Security, governance, and ethical responsibilities

Messaging systems are part of the cyber-physical attack surface. Threats include unauthorized commands, credential theft, broker compromise, topic subscription abuse, denial of service, malicious firmware, falsified sensor values, and leakage of production information.

Good practice includes:

• unique device identities rather than shared passwords;
• mutual authentication where feasible;
• encryption in transit and appropriate protection at rest;
• least-privilege authorization for topics, methods, and APIs;
• network segmentation between safety, control, enterprise, and external zones;
• secure boot and signed updates where supported;
• certificate and key rotation;
• audit logs for commands and administrative actions;
• input validation and resource limits;
• tested backup and recovery procedures.

Safety and security must be coordinated. A security response that disables communications must not create an unsafe machine state. Likewise, availability requirements may justify local operation when a cloud service is unavailable. Data governance also matters: production data may reveal proprietary processes, while worker-related data can raise privacy concerns. Collection should be necessary, proportionate, access-controlled, and retained according to policy and law.

13. Contemporary developments and professional practice

Current IoT integration increasingly combines edge computing, digital twins, event-driven architectures, and machine-learning services. These developments increase the value of standardized data, but they also increase dependency on schema governance and trustworthy data pipelines. Artificial intelligence cannot compensate for ambiguous units, incorrect timestamps, or poorly controlled identities.

Emerging practice emphasizes:

• zero-trust approaches in which every connection and request is authenticated and authorized;
• software bills of materials and supply-chain transparency;
• interoperable digital representations of assets;
• deterministic or time-sensitive networking for demanding industrial traffic;
• event-driven data products rather than uncontrolled raw-data lakes;
• automated conformance and contract testing;
• lifecycle management from device commissioning through secure retirement.

Engineers should evaluate standards by examining maturity, tooling, conformance tests, vendor support, licensing, performance, and migration cost. A fashionable protocol is not automatically the correct protocol.

Best-practice checklist

Before approving an IoT integration, verify that:

• every device and asset has a stable identity;
• each field has a defined type, unit, meaning, and quality status;
• event and measurement timestamps are distinguished;
• the interaction model matches the use case;
• retries and duplicates have defined behavior;
• commands are authenticated, authorized, audited, and bounded;
• gateways have documented failure and recovery behavior;
• schemas are versioned and validated;
• time synchronization accuracy is appropriate to the application;
• security and safety teams have reviewed the design;
• conformance and interoperability tests are repeatable.

Chapter Summary

IoT messaging is an engineering discipline involving communication patterns, protocols, data representation, meaning, timing, and governance. Addressing must distinguish network location from stable asset identity. Gateways connect heterogeneous systems but require explicit semantic mapping. Request–response protocols such as HTTP and CoAP suit resource operations, while MQTT and OPC UA PubSub support event-oriented distribution. OPC UA adds rich industrial information models, security, subscriptions, and methods.

Serialization formats determine how data is encoded, but semantic interoperability requires shared definitions of identities, types, units, timestamps, quality, and relationships. Time synchronization supports reliable event correlation, while application-level duplicate handling and failure design are essential for dependable operation. Standards-based integration succeeds when protocol selection, information modeling, security, testing, and lifecycle governance are treated as one engineering problem.

Key Terms

Addressing: Identifying interfaces, devices, services, resources, or topics for communication.

API: A defined software interface through which components exchange data or request operations.

CoAP: A constrained, resource-oriented application protocol commonly used on embedded networks.

Data serialization: Conversion of structured data into a transferable representation.

Gateway: A component that connects networks, protocols, or information models.

HTTP: An application protocol widely used for web and REST communication.

Information model: A formal description of entities, properties, types, and relationships.

Interoperability: The ability of independent systems to exchange and correctly use information.

MQTT: A lightweight broker-based publish–subscribe messaging protocol.

OPC UA: An industrial communication and information-modeling framework.

Payload: The application data carried by a message.

Publish–subscribe: A communication model in which publishers send messages to topics and subscribers receive matching messages.

QoS: Quality of Service; protocol or system properties governing delivery and communication performance.

REST: An architectural style using resources and a uniform interface, commonly over HTTP.

Schema: A formal description of permitted data structure, types, and constraints.

Semantic interoperability: Agreement on the meaning of exchanged information.

Timestamp: A value identifying when an event, measurement, processing action, or arrival occurred.

Topic: A named channel used to organize publish–subscribe messages.

UTC: Coordinated Universal Time, commonly used as an unambiguous time reference.

Review Questions

Short Answer Questions

1. Distinguish a device identity from an IP address.
2. What is the main function of an IoT gateway?
3. State the difference between request–response and publish–subscribe communication.
4. What information should accompany a measured numerical value to improve semantic interoperability?
5. Why are measurement time and ingestion time different?

Long Answer Questions

1. Compare MQTT, CoAP, HTTP/REST, and OPC UA for a mechatronic manufacturing system.
2. Explain the levels of interoperability and show why syntactic interoperability alone is insufficient.
3. Discuss MQTT QoS levels and explain why application-level duplicate handling remains necessary.
4. Describe a standards-based workflow for integrating a legacy industrial device into an IoT platform.
5. Explain how security, safety, and availability requirements influence gateway architecture.

Analytical / Application Questions

1. Design a communication architecture for a robotic cell requiring local control, live monitoring, historical analysis, and secure remote commands. Justify each protocol and data path.
2. A plant receives identical sensor values twice after a network outage. Analyze possible causes and propose a message, gateway, and database strategy to prevent incorrect production analytics.
3. Two machines report speed = 1500, but one means rpm and the other means millimetres per second. Explain how you would redesign the information model and validation process to achieve semantic interoperability.

Multiple Choice Questions with Answers

Question 1

Which communication model uses a broker to distribute messages from publishers to subscribers?

A. Circuit switching

B. Publish–subscribe

C. Polling-only communication

D. Point-to-point serial communication

Correct Answer: B. Publish–subscribe

Question 2

Which MQTT QoS level provides at-least-once delivery and may produce duplicates?

A. QoS 0

B. QoS 1

C. QoS 2

D. QoS -1

Correct Answer: B. QoS 1

Question 3

What is the primary purpose of an information model in industrial IoT?

A. To increase electrical power

B. To define the meaning, types, and relationships of data

C. To replace all network cables

D. To eliminate device authentication

Correct Answer: B. To define the meaning, types, and relationships of data

Question 4

Which HTTP method is normally used to retrieve a resource?

A. GET

B. POST

C. PATCH

D. DELETE

Correct Answer: A. GET

Question 5

Which protocol is specifically designed for constrained devices and commonly uses UDP?

A. CoAP

B. SMTP

C. FTP

D. SSH

Correct Answer: A. CoAP

Question 6

What does OPC UA add beyond simple register-based communication?

A. Only higher electrical voltage

B. Rich information models, services, and industrial security

C. A replacement for all sensors

D. Unrestricted anonymous access

Correct Answer: B. Rich information models, services, and industrial security

Question 7

If a sensor samples at 100 Hz, what is its nominal sampling interval?

A. 0.001 s

B. 0.01 s

C. 0.1 s

D. 1 s

Correct Answer: B. 0.01 s

Question 8

Which timestamp identifies when a sensor observation actually occurred?

A. Measurement time

B. Ingestion time only

C. Certificate expiry time

D. Database backup time

Correct Answer: A. Measurement time

Question 9

Which statement best describes semantic interoperability?

A. Devices use the same cable connector

B. Messages travel through the same router

C. Systems interpret exchanged information consistently

D. All devices use identical processors

Correct Answer: C. Systems interpret exchanged information consistently

Question 10

Why should a gateway preserve both measurement time and ingestion time?

A. To increase message size without benefit

B. To distinguish when data was observed from when it arrived

C. To remove the need for synchronization

D. To disable buffering

Correct Answer: B. To distinguish when data was observed from when it arrived