MQTT AS A KEY TECHNOLOGY FOR INDUSTRY 4.0 & IIoT

Copyright © by HiveMQ. All Rights Reserved.
MQTT AS A KEY
TECHNOLOGY
FOR INDUSTRY
4.0 & IIoT

WELCOME
• HiveMQ CTO
• Strong background in distributed and large scale
systems architecture
• OASIS MQTT TC Member
• Author of „The Technical Foundations of IoT“
• Conference Speaker and Author
• Program committee member for German and
international IoT conferences
Dominik
Obermaier
@dobermai
linkedin.com/in/dobermai/

We Will Talk Today About...
• Why major automotive OEMs chose MQTT for in-factory Industry
4.0 and IIoT use cases (including case studies!)
• Why MQTT is a key technology for IIoT and Industry 4.0
• Why not every cloud vendor delivers what they promise when it
comes to MQTT (including the most common pitfalls)
• How MQTT works and all relevant features
• How to achieve interoperability with MQTT

MQTT INTRODUCTION

What is MQTT?
• Binary
• Easy
• Publish/Subscribe
• Minimal Overhead
• (I)IoT Messaging Protocol
• Data Agnostic
• Designed for reliable communication
over unreliable channels

MQTT Overview
• Binary with minimal overhead
• Persistent (offline) sessions
• Retained Messages
• 3 QoS Levels
• (I)IoT Messaging Protocol

MQTT Use
Cases
• Connected Car
• Industry 4.0 / IIoT
• Logistics / Transportation
• (IoT) Messaging
Middleware
• Telecommunications

MQTT Use
Cases
• Push Communication
• Reliable Communication
over unreliable networks
• Constrained Devices
• Low Bandwidth and
High Latency
• Industrial Message Bus

Publish / Subscribe

Protocol Details
• Heartbeat mechanism
• Persistent TCP connections
• Also works over websockets
• IPv4 and IPv6 supported
• MQTT requires TCP/IP
• Clean & Persistent Sessions
• QoS levels for message delivery guarantees
• TLS in the mix for professional deployments
MQTT
TCP
IP
5-7
ISO/OSI
Layer
4
ISO/OSI
Layer
3
ISO/OSI
Layer

MQTT Pub/Sub Advantages
• Push Communication
• Message filtering based on subjects topics
• Synchronization Decoupling
• Time Decoupling
• Space Decoupling
• Dynamic Topics

MQTT HISTORY

2018
MQTT 5 officially
released
2013
HiveMQ 1.3 released
2013
OASIS TC formed
2014
MQTT 3.1.1
officially released
2018
HiveMQ 4 has
MQTT 5 support2019
HiveMQ MQTT
Client 1.0 released
2012
Mosquitto 1.0
released
2010
MQTT 3.1 opened as royalty
free protocol
1999
MQTT invented
for oil pipeline
monitoring

The MQTT TC

We will talk today about...MQTT Popularity over Time

Where does MQTT fit in?

Cloud Communication

Factory IIoT Bus

Consuming Applications:
Data Warehouse,
Analytics Tools,
Reporting, Monitoring
Application Area
Cloud Connector
Smart Sensors
Power, Consumption,
Vibrations, Temperature,
Humidity…
IIoT Area
Automation Area
Automation Sensors
PLS/STS
IIoT MQTT Broker

MULTI CLOUD ISO CONNECTIVITY

• MQTT is an ISO Standard (ISO/IEC 20922:2016)
• The ISO standard is clear about the features required for
interoperable communication
• Best practice is to have a central connectivity layer
• Standard conform vendors are replaceable by the the
customer, so the vendor risk is reduced significantly for
customers
• While usually not a concern in the PoC phase, Multi-Cloud
capabilities for the MQTT broker are extremely important
Multi Cloud & ISO

Cloud Vendors &
Third Party Services
Connectivity Layer
running on any or
multiple clouds
Devices, Factories
and "Things"
Multi-Cloud
High available
MQTT broker
(multi-cloud possible)
Other 3rd party
services

Cloud Vendors &
Third Party Services
Connectivity Layer
running on any or
multiple clouds
Devices, Factories
and "Things"
Multi-Cloud Other 3rd party
services
Device Management
AWS IoT
Big Data
Kinesis
IoT Hub Data Lakes
Machine Learning
Event Hubs

HiveMQ

Risks when Using Cloud Platforms for
MQTT Connectivity
• SLAs of cloud vendor services usually not acceptable for mission-
critical cloud data pipelines
‣ Azure offers 99,9% uptime for IoTHub [1]
‣ AWS offers 99,9% uptime for IoT Core [2]
‣ 99,9% uptime guarantees is approximately 9 hours downtime per year
• Cloud Vendors don't offer stable API guarantees
‣ Can change or terminate any service at any time
‣ they notice 12 months in advance, though
‣ Many customers require 15+ years guarantees because field device
updates are sometimes hard or impossible
• No price stability guarantees from cloud vendors [3]
[1] https://azure.microsoft.com/en-gb/support/legal/sla/iot-hub/v1_2/
[2] https://aws.amazon.com/iot-core/sla/
[3] https://aws.amazon.com/agreement/
Vendor lock-in to specific clouds (AWS, Azure, GCP)
too risky for industry leaders

• Only subsets of the protocol are supported and MQTT can only
be used in a very opinionated way
• Azure does not support the MQTT 5 specification and doesn't
support all MQTT 3 features
• AWS IoT does not support the MQTT 5 specification and
doesn't support all MQTT 3 features
•
Cloud Services don't offer the MQTT ISO Standard
MQTT Connectivity

Source: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support
MQTT Connectivity

Source: https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html
MQTT Connectivity

• Pricing may change at any time for most cloud vendors (including
AWS and Azure)
• Pricing for MQTT services usually consists of many variables which
makes it VERY hard to calculate the actual costs upfront
‣ Only specific MQTT packets are counted and a single packet can
count as multiple packets if it has large payload
‣ Distinction between incoming and outgoing traffic
‣ Sometimes concepts as connectivity duration + traffic + processing
rules are used together with a lot of other variables
‣ Integrating other services usually also adds more variables
• Usually the prices for POCs are extremely low but actual production
workload gets incredibly expensive
Hard to calculate costs upfront
MQTT Connectivity

How to Fix?
• Usually the connectivity layer (MQTT Broker) is HOSTED at a
cloud provider but not proprietary cloud-specific services are
used
• Use a MQTT broker that is built for high-availability and has
industry references
• Don't use open source software like mosquitto for mission-
critical deployments (fine for testing, though)
• Use a vendor that can integrate with the value-added services
of your cloud providers (like Device Management, ...)
• If it's mission critical, make sure the vendor has good SLAs
and is responsive
Use a vendor that supports 100% of the MQTT ISO standard in a
cloud agnostic way

INTEROPERABLE DATA EXCHANGE

Interoperable Data Exchange
• MQTT is data agnostic, it can carry any payload up to 256MB
• MQTT supports content types that describes the payload
• Usual data formats for include
‣ Protocol Buffers (tiny and very efficient, supports schema
evolution)
‣ JSON (human readable and widely accepted)
‣ XML (heavyweight, human readable, easy to validate)
‣ Avro (efficient, support schema evolution)

The Babble Fish

NON-DOMAIN SPECIFIC SEMANTICS &
INTEROPERABILITY ARE SCIENCE-FICTION

Ok, but how to do
domain speciﬁc data
interoperability?

VDA Publication
https://www.vda.de/dam/vda/publications/2019/Logistik/VDA5050.pdf

Interoperable Data Exchange with MQTT
• Domain specific knowledge needs to be documented and agreed
upon by major industry players
• Best practice: Offer data validation schemas
• MQTT brokers can add validation rules for topics
• OPC UA companion specifications for data models can also be used
with MQTT

SECURITY

MQTT Security
• TLS for transport encryption
• Pluggable authentication and authorization mechanisms
‣ X509 client certificates possible
‣ OAuth 2.0 and OpenID possible
‣ LDAP / Active Directory possible
‣ Any database access as credential store possible
‣ RBAC
• VERY fine grained permissions possible based on
‣ ip addresses
‣ topics + actions (pub/sub)
‣ features (retained, shared subscriptions, qos, ...)
MQTT is built for secure communication

MQTT DETAILS

MQTT Topics

MQTT Topics
• Dynamic
• Very lightweight
• Queuing (QoS > 0)
• Wildcards (+ and #)
• Hierarchically

MQTT Topics
• UTF-8 string - Used for message filtering
myhome / groundﬂoor / livingroom / temperature
Topic level
Separator
Topic levelTopic level
• Each topic level is separated by a forward slash
• Each topic contains at least 1 character, may contain spaces, is case sensitive

MQTT Topics
Single level: + myhome / groundﬂoor / + / temperature
Topic level
Separator
Only one level
Single level: #
myhome / groundﬂoor / #
multi-level
Wildcard
Only at the end
Multiple topic levels

factory1
MQTT Topics
/ /
ﬂoor1
ﬂoor2
plc1
plc2
plc1
plc2

factory1
MQTT Topics
/ /
ﬂoor1
ﬂoor2
plc1
plc2
plc1
plc2
PLC Data 1 from floor1: factory1/floor1/plc1

factory1
MQTT Topics
/ /
ﬂoor1
ﬂoor2
plc1
plc2
plc1
plc2
All Data from floor2: factory1/floor2/#

factory1
MQTT Topics
/ /
ﬂoor1
ﬂoor2
plc1
plc2
plc1
plc2
All Data from deathstar: factory1/#

Quality of Service (QoS)

MQTT QoS
QoS 1
QoS 2
QoS 0
QoS 0
QoS 1
QoS 2
At most once delivery
At least once delivery
Exactly once delivery

Retained Messages

Retained Messages
• Clients receive retained message after
subscription
• The client decides if a message should be
retained
• Broker saves the last message for a given
topic
• „Last Known Good Value“

Last Testament & Will

Last Will & Testament
• Useful to implement „on/off“
• Real Push
• Broker sends message after client „death“
• Client defines LWT

Persistent Sessions

Persistent Session
• Queuing for QoS > 0
• Client decides if he wants to use persistent
sessions
• Broker saves Client Sessions
Connect
Subscribe
device/+/status
device/12/status: „1“
Re-Connect
device/12/status: „1“
1st
2nd

Request / Response

Request / Response
• Pattern for „business ACKs“
• Request /Response is a pattern that is also
available for MQTT 3.1.1
• Publishing Client must subscribe to a response
topic prior to sending data
• „Request Response Information“ Header for
response topic
• „Correlation Data“ header for correlation of
request/response

Shared Subscriptions

Shared Subscriptions
* HiveMQ fully supports all optional features, including this feature
• Client Load Balancing. Multiple clients share the
same subscription
• Special Syntax: $share/{ID}/my/topic
• Useful for scaling out backend subscribers
• Also supported by HiveMQ for MQTT 3.1 and
MQTT 3.1.1
• Up-/Downscaling of clients at runtime possible.
Perfect for cloud native scenarios (Kubernetes, …)
• Optional feature, not supported by all vendors*

User Properties

User Properties
• User Defined Metadata Headers
• Can be part of most MQTT packets
• UTF-8 encoded Strings
• An unlimited number of user properties can be
added

THANK
YOU
Dominik Obermaier
@dobermai
linkedin.com/in/dobermai/
dominik.obermaier@hivemq.com
Contact

MQTT AS A KEY TECHNOLOGY FOR INDUSTRY 4.0 & IIoT

More Related Content

What's hot (20)

Similar to MQTT AS A KEY TECHNOLOGY FOR INDUSTRY 4.0 & IIoT (20)

More from Dominik Obermaier (13)

Recently uploaded (20)

MQTT AS A KEY TECHNOLOGY FOR INDUSTRY 4.0 & IIoT