Don Pearson and Travis Cox from Inductive Automation, and Arlen Nipper, the president/CTO of Cirrus Link Solutions and co-inventor of MQTT, will take you on a deeper dive into the components and infrastructure of an MQTT-based SCADA solution.

2. Moderator
Don Pearson
Chief Strategy Officer
Inductive Automation

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

5. Used by Major Companies Worldwide

6. Web-Based
Deployment
Unlimited
Licensing
Security
& Stability
Real-Time Control
& Monitoring
Rapid Development
& Deployment
Easy
Expandability
6 Reasons Why Ignition is Unique

7. Presenters
Travis Cox
Co-Director of Sales
Engineering
Inductive Automation
Arlen Nipper
President & Chief Technology
Officer
Cirrus Link Solutions

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

12. Common IIoT Protocols
Publish/Subscribe:
MQTT, AMQP, DDS, XMPP
Client/Server:
HTTP (REST/JSON), OPC-UA, CoAP

13. Common IIoT Protocols
Publish/Subscribe:
MQTT, AMQP, DDS, XMPP
Publish/Subscribe:
MQTT, AMQP, DDS, XMPP
Client/Server:
HTTP (REST/JSON), OPC-UA, CoAP

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.

22. MQTT for IIoT

23. MQTT for IIoT
“All of our engineers are talking about MQTT. They don’t
want direct API calls anymore.”
– Anonymous customer

24. MQTT for IIoT
Ways to Implement MQTT:
• Converting existing PLCs and equipment to MQTT
• Enabling devices to communicate with MQTT platforms
(Sparkplug specification)
• Embedding MQTT onto devices

25. MQTT Architectures

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

35. Ignition Demo

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 your Ignition IIoT along with
MQTT Distributor and MQTT Engine.
• Leverage open-source development & data encoding.
Conclusion

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