The document outlines Don Pearson's agenda for a presentation on MQTT for IIoT. It discusses how MQTT is well-suited as an IIoT messaging protocol due to its low bandwidth usage, TLS security, and stateful awareness. It also describes how to implement MQTT architectures with edge devices, MQTT servers, and MQTT clients like Ignition. The presentation demonstrates how Ignition and its MQTT modules can be used to migrate legacy systems and enable bidirectional communication with MQTT-enabled devices.
3. Today’s Agenda
1. Introduction to Ignition
2. IIoT and the Current Landscape
3. MQTT for IIoT
4. Edge Device/MQTT Transmission
5. MQTT Server/MQTT Distributor
6. MQTT Client/MQTT Engine
7. Demo
8. Migration & MQTT Resources
9. Q&A
4. About Inductive Automation
• Founded in 2003
• HMI, SCADA, IIoT software used in 100+ countries
• Supported by 1,400+ integrators
• Used in virtually every industry
• 60% average annual growth rate since 2010
Learn more at: inductiveautomation.com/about
7. Presenters
Travis Cox
Co-Director of Sales
Engineering
Inductive Automation
Arlen Nipper
President & Chief Technology
Officer
Cirrus Link Solutions
8.
9. IIoT and the Current Landscape
IIoT (Industrial Internet of Things)
• The capability for IIoT is here
• The challenge is how to leverage
new technology while working
with existing legacy systems
10. IIoT and the Current Landscape
Reality: Proprietary Devices Still Prevalent
• Hundreds of millions of proprietary
legacy PLCs & devices in operation
• Legacy PLCs & devices likely to be in
use for 10-15 more years
11. IIoT: Current Landscape
Best Practice: Make a Slow Transition
• Transition gradually since you will likely
have proprietary devices for a while
• Work in parallel: develop new infrastructure
alongside your current one
• Make sure your new process works before
you stop using the old process
14. MQTT for IIoT
Best Practice:
Choose MQTT As Your IIoT Messaging Protocol
• Inductive Automation recommends MQTT as the best
choice
• MQTT is more than a IIoT protocol; it’s an architecture for
IIoT
15. MQTT for IIoT
Origin and Background:
• Developed 18 years ago by Arlen Nipper
and Dr. Andy Stanford-Clark
• Originally designed as a message transport
for real-time SCADA systems
• Developed for oil & gas companies
• Adopted for IoT and IIoT purposes
Arlen Nipper
President & Chief Technology Officer
Cirrus Link Solutions
16. MQTT for IIoT
Emerging as the Standard:
• Now seen by many as the de facto standard for
IIoT & M2M messaging
• In Eclipse Foundation’s 2016 IoT developer survey,
80% chose MQTT as the leading protocol for IoT
• Manufacturers embedding MQTT on devices
17. MQTT for IIoT
Why MQTT is the Best Protocol for IIoT:
• Low bandwidth
• TLS security
• Stateful awareness
18. MQTT for IIoT
Low Bandwidth
• Lightweight communications protocol
• Report by Exception (RBE)
19. MQTT for IIoT
TLS Security
• TLS – Transport Layer Security
• Uses encryption to transmit sensitive info
• Uses certificate authorities
• Blocks common attack routes by closing
all ports over connection between edge
gateways and MQTT servers
20. MQTT for IIoT
It’s the Only Stateful IIoT Architecture:
• Stateful awareness = Knowing the state of
the network connection at all times
• Especially important in SCADA architecture
• For RBE to work properly in real-time SCADA,
the state of the end device must be known at all times.
21. MQTT for IIoT
Best Practice: Use Stateful Awareness
• Stateless implementation of MQTT solutions aren’t taking
advantage of the capability for MQTT-based
infrastructures.
• To properly implement MQTT within a SCADA system, you
need to understand and properly implement the built-in
session state mechanism.
• Rather than operating on last-known-good values, you can
know what the state is at any time.
26. Edge-of-Network Device
Three Approaches:
• An Edge Gateway that bridges legacy devices to new
devices or to MQTT
• New devices onboard that can natively speak in MQTT
• MQTT Transmission Module
27. Edge Gateway
What It Does:
• Combines functions of routers, network boxes, terminal
servers, and network arbitrators
• Used for dealing with existing infrastructure
• Part of the answer of how we can take what we have now
and transition into new technology as well as add more
technology in the future
28. Edge Gateway
Best Practice:
Make Sure the Edge Gateway is Redundant.
• It should be able to publish through cellular or satellite,
or have backups.
• No single point of failure
29. MQTT Transmission
MQTT Transmission Module Basically Functions
as an Edge Gateway:
• Edge gateways securely transmit and receive data from
edge-of-network devices directly via MQTT Transmission
Module
• MQTT Transmission is a bridge from Ignition tags to
MQTT
• Provides Ignition with an OPC-UA-to-MQTT bridge
30. MQTT Servers
MQTT Architectures Include a Central MQTT Server
Which:
• Connects devices
• Publishes data
• Subscribes to data
31. MQTT Servers
Available Options for MQTT Server/Brokers Include:
• AWS IoT (Amazon)
• Azure IoT Hub (Microsoft)
• Chariot (Cirrus Link)
• Cirrus Link MQTT Distributor Module for Ignition
• CloudMQTT
• HiveMQ
• Red Hat AMQ
• VerneMQ
32. MQTT Server: MQTT Distributor Module
The Cirrus Link MQTT Distributor Module is the MQTT
Server Component in Ignition:
• Launched by the Ignition Gateway
• Small, self-contained MQTT server
• MQTT Server Module inside an Ignition Gateway:
complete, on-premise solution
• Standalone solution for on-premise infrastructures with a
limited number of edge devices, and for other applications
33. MQTT Clients
What MQTT Clients Do:
• Connect to MQTT servers
• Subscribes to information with MQTT servers
• Publishes information it receives to its network
34. MQTT Engine Module
What MQTT Engine Does:
• The key to enabling of Ignition to act as a
native MQTT citizen
• It enables Ignition to communicate bidirectionally
with MQTT-enabled edge-of-network devices securely
via an MQTT server
36. Migration Strategy
The “Catch-22”:
When organizations using Poll/Response protocol drivers that are
directly connected to field devices over a communications circuit
or TCP/IP network try to implement SCADA upgrade
infrastructures, they can’t replace or upgrade the Poll/Response
protocol on the SCADA host until they have the new protocol in
the field, and can’t change the field devices until they have the
new protocol on the SCADA host.
37. Migration Strategy
A Proven, 4-Step Strategy Using Ignition, MQTT Engine
Module, and Elecsys Director:
• Step 1: Use the Elecsys Director as a TCP/IP Endpoint
• Step 2: Conventional Poll/Response with Ignition
• Step 3: Enable MQTT Local Masters
• Step 4: Pure MQTT Solution
38. Leveraging Standards and Open-Source
Best Practice: Leverage Open-source Development
& Data Encoding As Much As Possible
• OASIS MQTT V3.1.1 Specification docs.chariot.io
• Eclipse Foundation IoT Resources iot.eclipse.org
• Paho eclipse.org/paho
• Kura eclipse.org/kura
• Raspberry Pi hardware
39. Sparkplug Specification
The Sparkplug specification and reference implementation
code in C, Java, Python, JavaScript, and Node Red are
available on GitHub at:
Github.com/Cirrus-Link/Sparkplug
40. Best Practices Summary:
• Transition slowly to new infrastructure.
• Choose MQTT as your IIoT messaging protocol.
• Use stateful awareness in MQTT.
• Edge gateways should be redundant.
• Use MQTT Transmission in Ignition IIoT along with MQTT
Distributor and MQTT Engine.
• Leverage open-source development & data encoding.
Conclusion
41.
42.
43. Questions & Comments
Jim Meisler x227
Vannessa Garcia x231
Vivian Mudge x253
Account Executives
Ramin Rofagha x251
Shane Miller x218
Myron Hoertling x224
Maria Chinappi x264
Dan Domerofski x273
Lester Ares x214
Melanie Hottman
Director of Sales,
Inductive Automation
1.800.266.7798 x247
Arlen Nipper (Panelist)
Cirrus Link Solutions
www.cirrus-link.com