White Paper

Design Like a Pro:

Best Practices for IIoT
6 Guidelines for Setting Up MQTT Architectures

800.266.7798
www.inductiveautomation.com
Design Lie
k a Pro:
Best Practices for IoT

The industrial automation industry Best Practice #1: Gradually Transition to

is benefiting from the incredible a New IIoT Infrastructure
opportunities made possible by the There is a lot of hype about the IIoT and many or-
ganizations want to leverage the benefits it prom-
Internet of Things (IoT). ises. However, for many organizations, the path to
technological adoption seems unclear, and some
While the IoT has shown incredible promise
still question if IIoT will ever happen. Fortunately,
within the corporate and consumer environment,
with current and emerging offerings, organizations
the true value of the IoT can be found in the
can actually take full advantage of IIoT today. Be-
industrial space, which has aptly become known
fore making the leap, though, they should recog-
as the Industrial Internet of Things (IIoT).
nize that legacy devices are still in use. Planning
The unquenchable thirst for industrial data has and patience are required as you move forward
ignited this IIoT movement to bring operational with an IIoT solution for your organization. As the
technology (OT) up to speed with its enterprise old saying goes, you should look before you leap.
counterpart, information technology (IT). This
movement aims to overcome hurdles that have Build a Parallel Infrastructure
handicapped the growth of the industrial world,
There are still hundreds of millions of proprietary
and to connect data across a wide network
legacy PLCs and devices being used by organi-
throughout an organization.
zations today, and they will continue to be in use
The IIoT unlocks data, clearing the way for easy for many years to come. Upgrading all of these
access and shareability. By working with IT, OT devices would be incredibly cost-prohibitive. It
can leverage the scalability and flexibility of open would also be very difficult to just switch to a new
technologies to access and share all types of technology, because making a quick switch could
data with every level of an organization. In this result in a catastrophic failure and loss of revenue.
white paper, we’ll provide some best practices
Your best approach is to build a parallel infrastruc-
when approaching your new IIoT infrastructure.
ture alongside with your existing installation and
gradually transition devices from your old system
to your new IIoT infrastructure. Many systems are

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 2 | 10
Design Lie
k a Pro:
Best Practices for IoT

critical in nature and upgrades could cause out- The other category is the poll-response or client-
ages, which are unacceptable. Building a system server protocols, such as Allen-Bradley, Omron,
in parallel allows you and your organization to and Modbus, in which clients continually connect
compare data from your established system with to the server and make requests to determine if
your new system. The gradual approach helps you any data has changed.
to make sure your new system works and is stable
Of the two categories, which one should you
before making a complete infrastructure transition.
choose? To effectively build a highly scalable solu-
tion with a high level of efficiency, it is best to adopt
Allow Time for Testing
a publish-subscribe communication protocol. Rath-
Migrating to a brand-new IIoT system of a large er than connecting applications directly to devices,
magnitude requires thought and thorough planning. publish-subscribe protocols decouple devices
This is a process you shouldn’t rush nor take lightly. and allow applications to connect to middleware.
Through middleware, you can connect any appli-
Taking your time affords you the ability to test
cation that requires data from any device without
your system. As you gradually build your new
placing any heavy demands on the network.
infrastructure, you can test along the way to
make sure communication is stable. Furthermore, From the list of available protocols in the pub-sub cat-
if a failure occurs while you install your new egory, we highly recommend using MQTT. More than
infrastructure, the current system is still available, just a protocol, MQTT is the foundation for building
mitigating any downtime. your new architecture, making IIoT a reality today.
As you begin developing a plan for your new IIoT
Make MQTT Your Communications Protocol
infrastructure, you should start looking at which
communication protocols to use in your infrastruc- While MQTT’s recent emergence into the limelight
ture. The protocol you choose will determine the may suggest that it’s a brand new technology,
IIoT devices and software for your infrastructure. MQTT has been around for quite some time. In
Take the time to understand the needs of your 1999, Dr. Andy Stanford-Clark of IBM and Arlen Nip-
organization and how your current system is set per invented a messaging protocol that was mainly
up. The final solution you choose is a large com- intended for real-time, oil-and-gas SCADA systems.
mitment. Once implemented, your infrastructure At the time, operational technology and informa-
will be in place for many years to come. tion technology were two separate worlds. Unlike
IT, bandwidth in OT was neither free nor unlimited.
In the next section, we’ll look at MQTT and why it
is the ideal communications protocol for IIoT. In an effort to circumvent the communication
limitations of OT, MQTT was designed to be a
lightweight, pub-sub protocol that economizes on
Best Practice #2: Choose MQTT as
bandwidth. However, the true value of MQTT is
Your IIoT Messaging Protocol now found in its ability to decouple edge devices
from applications that need the data. Traditional
Your entire IIoT solution will heavily depend on
poll-response communication protocols can eat a
the protocol you choose, as it is the backbone
lot of bandwidth without providing any real value.
of your system.
MQTT’s pub-sub method allows devices to put
Most common IIoT protocols fall into two categories. data on message-oriented middleware (MOM). In-
One category is the publish-and-subscribe (pub- stead of applications constantly checking devices
sub) protocols which connect and publish data to a for any value changes, applications can connect
topic on an intermediary broker. MQTT, AMQP, DDS, to a MOM and subscribe to the important data
and XMPP are examples of pub-sub protocols. that they need, including device state information.

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 3 | 10
Design Lie
k a Pro:
Best Practices for IoT

Decoupled Applications & Devices

Since MQTT has proven to be a formidable com- The second important feature is the
munications protocol, its use has gone far beyond use of a cryptographic security protocol
the oil and gas industry, and it has emerged as called Transport Layer Security (TLS),
the defacto standard for IIoT and M2M messaging. which provides communications security over a
In the Eclipse Foundation’s 2016 IoT Developer computer network. TLS aims to provide privacy
Survey, 80 percent of the respondents chose and data integrity between two communicating
MQTT as the leading protocol for IIoT. MQTT is computer applications. It is designed to prevent
becoming more available as manufacturers begin eavesdropping and tampering. By using TLS,
to embed MQTT onto their devices. With so much MQTT establishes a secure, private connection
interest in MQTT, it is safe to say that MQTT is the via a handshake process. Once a connection is
best choice for your IIoT solution. made, data is encrypted and transmitted between
the client and the server. If the handshake fails,
What Makes MQTT the Ideal Protocol? data is not transmitted.
MQTT has three distinct features that also make In addition to providing low bandwidth
it the ideal IIoT protocol: low bandwidth, TLS and a high level of security, MQTT has an
security, and stateful awareness. incredibly useful feature called stateful
awareness. While current SCADA implementa-
Limited bandwidth presents a serious
tions purely transmit data from devices, MQTT also
challenge to IIoT, especially for remote lo-
sends the device state data about the health of
cations, which is why MQTT is the perfect
the device or network connection. This is incred-
solution. It is a lightweight, low-bandwidth commu-
ibly important for remote locations because it
nications protocol that uses a pub-sub methodolo-
enables operators to determine if network connec-
gy. Poll-response protocols send and receive a lot
tions are operational or devices are unavailable.
of repetitive data which can take up an unneces-
sary amount of bandwidth. MQTT employs a MOM As we dive deeper into the best practices for IIoT,
which decouples devices from applications and we will discover that stateful awareness is one of the
thus reduces bandwidth usage. Devices connect key ingredients to a successful IIoT implementation.
directly to a MOM, or in this case the MQTT server, Next, let’s look into the importance of stateful aware-
where data is gathered. Applications then connect ness and how to implement MQTT.
to the MQTT server, getting an update whenever
there are changes to the data.

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 4 | 10
Design Lie
k a Pro:
Best Practices for IoT

Birth Death
Certificate Certificate

Death Birth
Certificate Certificate

Best Practice #3: stops working and falls off the network, then the
Use MQTT’s Built-In Stateful Awareness MQTT server will publish a “death certificate” and
the device will be marked as being unable to
With its low-bandwidth publish-subscribe method- publish data. On a larger scale, with thousands of
ology and TLS security, MQTT has proven to be a devices connected to the MQTT server, it is im-
formidable IIoT communication protocol. Another portant to know within seconds the state of each
feature that is critical to your IIoT infrastructure is device: whether it is online and ready to publish
the stateful awareness that is built into MQTT. data or if it is unavailable.
Let’s say that you’re using the Ignition platform
Stateful Awareness is Important for IIoT
with an MQTT server and an MQTT client. When a
Stateful awareness is important for SCADA sys- device connects to an MQTT server, it registers its
tems, especially for remote installations. state and then it registers its last will and testa-
ment. Ignition and the MQTT client will know that
Knowing the health of the device and the network
the devices are online and will deliver information
connection helps to mitigate any downtime and
if and when it changes. In the event of hardware
ensures data is being shared with all levels of an
failure or environmental issue, the MQTT server
organization. By having stateful awareness, data
will publish the fact that the device is no longer
becomes more stable, reliable, and contextual.
available. In Ignition, those tags are represented as
Most enterprises still depend on legacy poll- stale data and the device is marked as unavailable.
response communication protocols to be able When the device comes back online, it repub-
to know the state of the network connection lishes its birth certificate. The MQTT client knows
between devices and the SCADA system. Un- that the device is available, and Ignition shows the
fortunately, devices must be polled frequently to updated tags and the device’s availability.
determine whether or not a network connection
is good, which can put a strain on the system. Stateful Awareness Improves Processes
Stateful awareness is a subtle but powerful feature
Stateful Awareness is Built Into MQTT
of MQTT. There are many MQTT implementations
MQTT has stateful awareness built in and it is the that are stateless, but for SCADA implementations,
only stateful architecture available. It is designed stateful awareness is essential. MQTT uses report-
with a “last will and testament”: if the device ing by exception (RBE), which is made possible by

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 5 | 10
Design Lie
k a Pro:
Best Practices for IoT

stateful awareness. Data is only sent when there and connect to your MQTT server and to the rest
are changes to the state of the device or when of your IIoT implementation. In this strategy, these
data values change, which reduces the amount of edge-of-network devices do not require a sepa-
useless data taking up bandwidth resources. rate edge gateway since the MQTT functionality is
already built in.
Knowing the device state is valuable since it
helps to provide context to the data. Operators, Now that we have established the importance of
especially, can keep track of devices and quickly stateful awareness and how to implement MQTT,
pinpoint any trouble spots without having to we can turn our attention to edge-of-network
send a technician out to a location to verify an devices, which act as a bridge between PLCs
issue. On the organizational level, data can be and the MQTT server or “broker.” This capability
verified to be up-to-date and accurate. makes them a critical component in the MQTT
architecture and IIoT infrastructure.
3 Ways to Implement MQTT
Now that we have established that MQTT is Best Practice #4:
the ideal communications protocol for your Implement Redundant Edge Gateways
IIoT system, our next step is to look at ways to
start implementing MQTT. There are three main
strategies to transition your SCADA system over
to MQTT: converting existing devices to MQTT,
enabling existing devices to communicate with
MQTT platforms, and embedding MQTT directly
onto devices.
The first strategy is to convert legacy devices
to use MQTT. An edge-of-network device is
Regardless of whether a location is local or
designed to communicate with legacy devices
remote, connectivity can pose a major challenge.
using their native protocol. The edge gateway
Local locations tend to rely on hardline connec-
then connects directly to an MQTT server. The
tions to transmit data. Remote locations rely on
poll-response is moved to the local level, and
wireless services such as cellular or satellite. In ei-
data is converted to MQTT and published to an
ther case, the main communications conduit could
MQTT server. This strategy is ideal for current
potentially fail. As a best practice, especially for
installations using legacy equipment and tradi-
mission-critical systems, make sure to integrate
tional poll-response protocols.
failsafes and install redundant edge gateways.
The second strategy is to enable edge devices
to communicate with MQTT platforms using the Edge Devices and Gateways
Sparkplug specification from Cirrus Link Solu-
Edge gateways are a type of edge-of-network
tions. Cirrus Link provides open-source software,
device. Edge-of-network devices are a key
tools, and the Sparkplug reference specification
component in MQTT architectures, providing an
to allow applications, sensors, devices, or gate-
entry point into an enterprise core network. Edge
ways to seamlessly integrate with Ignition using
devices can include routers, routing switches,
the Cirrus Link MQTT modules.
integrated access devices (IADs), multiplexers,
The third strategy, which is appropriate for newer and a variety of metropolitan-area network (MAN)
installations, is to use devices with MQTT already and wide-area network (WAN) devices. An edge
embedded into them. Manufacturers have begun gateway can be thought of as a combination of a
to offer devices that have the Sparkplug speci- router, network box, terminal server, and a net-
fication enabled, making them ready to install work arbitrator.

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 6 | 10
Design Lie
k a Pro:
Best Practices for IoT

As their name suggests, edge gateways live at remote geographical areas. Having a failsafe
the outermost edge of a SCADA system. With an ensures your data is safe and available when it
abundance of legacy PLCs and devices still using is needed the most. If there are system failures,
poll-response communication protocols, edge having backup systems ensures smooth operation
gateways act as a bridge to connect to these leg- and minimizes downtime, which could save your
acy devices, converting them to MQTT, enabling organization thousands or millions of dollars.
them to communicate to MQTT servers, and allow-
The key to a redundant architecture is to take
ing enterprise networks to access the data.
advantage of multiple communication channels.
Having a hardline system is always preferable,
Make the Edge Gateways Redundant
but having a wireless backup such as cellular or
Putting in failsafes is a must for your SCADA satellite ensures your system has continual cover-
transition. The data you’re collecting and sharing age to ensure your valuable data is safe and your
is important and any failures can lead to nega- system keeps running smoothly.
tive effects on your organization. Because edge
Next, we’ll discuss options for the edge devices,
gateways are critical, adding a redundant edge
MQTT servers, and MQTT clients in your MQTT
gateway is a best practice.
architecture.
It is also highly recommended that you add
redundancy to your IIoT infrastructure as a whole.
Best Practice #5:
Make sure there isn’t a single point of failure
that can cripple your operation. You should add Use MQTT Modules in Your Ignition IIoT
redundancy at every point in the system where
MQTT is an incredible communications protocol
data is published.
that is ideal for your IIoT infrastructure. Yet, you
Make sure you have edge gateways that are able still need an industrial platform that fully takes
to communicate via cellular and satellite. Set up advantage of MQTT and brings IIoT together. With
multiple MQTT servers and use all available chan- Cirrus Link’s MQTT modules, Ignition becomes the
nels to make sure data is available at all times. ideal IIoT platform. The Cirrus Link MQTT modules
leverage Ignition’s rich feature set and superb
Always Have Backup Systems SQL database capabilities to take existing equip-
ment and systems to create a robust IIoT infra-
Redundancy is crucial for your IIoT implementa-
structure. Depending on your specific needs, be
tion, especially when you have installations in

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 7 | 10
Design Lie
k a Pro:
Best Practices for IoT

it an edge gateway, an MQTT server, or enabling message-oriented middleware (MOM) resides. All
MQTT functionality, the Cirrus Link MQTT mod- edge-of-network devices in the MQTT architec-
ules and Ignition have you covered. ture publish MQTT tag and state data to the MQTT
server. The MQTT server then enables MQTT
Ignition architectures with MQTT are comprised
clients to securely connect and subscribe to the
of several elements: edge devices, MQTT serv-
device’s published data.
ers, and MQTT clients. Each of these elements
plays an important role in your ability to take a Since MQTT is an open standard, there are many
legacy system and migrate into a cutting-edge companies making their own brand of MQTT serv-
SCADA system. ers. For example, there’s AWS IoT from Amazon,
Azure IoT Hub from Microsoft, and Chariot from
Edge-of-Network Devices Cirrus Link, as well as HiveMQ, CloudMQTT, Red
Hat AMQ, and VerneMQ. There are many options
The edge-of-network device is the first important
to choose from, whether it be a locally hosted or
component of the MQTT architecture. Edge de-
cloud-hosted solution.
vices which include edge gateways (also known
as directors) allow you to communicate to legacy As a best practice, use the Cirrus Link MQTT Dis-
devices such as PLCs and RTUs, to collect tag and tributor Module for Ignition. The MQTT Distributor
state data, convert it to MQTT, and publish that Module is launched by the Ignition Gateway and
data onto an MQTT server. Edge gateways, along is a small, self-contained MQTT server. It provides
with MQTT, allow you to decouple devices from you with a complete MOM solution that is best
applications, thus improving bandwidth usage. suited for an on-premise MQTT infrastructure with
a limited number of edge-of-network devices. The
There are four methods for implementing an
module provides rapid development and is ideal
edge-of-network device. The first method is to
for situations where communications are restrict-
use a dedicated edge gateway to bridge legacy
ed or costly. It’s designed to simplify and speed
devices to new devices or to an MQTT server.
up the process of getting a complete MQTT
The second method is to install a brand-new infrastructure going. It’s also very effective at
edge device that natively communicates via increasing data throughput for high-performance
MQTT. Several manufacturers are now embed- plant-floor solutions.
ding the Sparkplug specification onto their
devices, allowing for direct communication with MQTT Clients
an MQTT server.
The third piece of the MQTT architecture is the
The third method is to use the Cirrus Link MQTT MQTT client, which connects to the MQTT server
Transmission Module on an Ignition server. The and subscribes to one or more topics of information,
MQTT Transmission Module turns the Ignition bringing that data right into an application.
server into an edge gateway, allowing you to col-
While there are many MQTT client tools available, it
lect and publish edge data to the MQTT server.
is recommended to use the Cirrus Link MQTT En-
The fourth method is to use Ignition Edge MQTT, gine Module for Ignition. The MQTT Engine Module
a limited, lightweight Ignition solution that turns is the key component that enables Ignition to act
touch panels, client terminals, or virtually any em- as a native MQTT citizen.
bedded PC or field device into an MQTT-enabled
The MQTT Engine allows the Ignition platform to
edge gateway.
communicate bidirectionally with MQTT-enabled
edge-of-network devices via the MQTT server,
MQTT Servers
which can be sent securely all the way down to
The second piece of the architecture is the MQTT the device. It takes data from the MQTT server
server, often called the broker. This is where the and injects it into industrial SCADA applications.

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 8 | 10
Design Lie
k a Pro:
Best Practices for IoT

Now that we have covered all the available options, Ignition, enabling MQTT local masters, and switch-
resources, and best practices, it is time to look at ing over to the pure MQTT solution.
how to bring everything together. In the last section,
Step 1: Install and set up an edge gateway, such
we’ll take a look at the best migration strategy to
as an Elecsys Director. The edge gateway acts as
take when implementing an IIoT infrastructure.
a TCP/IP cellular, VSAT, or Ethernet IP endpoint. In
this step, you are setting up the edge gateway to
Best Practice #6: Follow the Optimal communicate with PLCs or edge devices using the
IIoT Migration Strategy poll-response protocol. The edge gateway then
connects to an MQTT server using a TCP/IP link
Migrating to a new IIoT infrastructure takes time and sends collected data via the MQTT protocol.
and careful planning. As we discussed in the first
Step 2: Start the conventional poll-response with
best practice, you must approach the migra-
Ignition by connecting to the internal terminal
tion transition slowly. There are many pieces
server and keeping poll-response going. You will
involved with an IIoT infrastructure and when
enable both the serial and Ethernet connections
you factor in the added complexity of a legacy
between Ignition and the field devices using the
system, you need a slow transition to ensure
edge gateway.
that downtime is minimized.
Step 3: Enable MQTT local masters. Once the
Many organizations face a Catch-22 when imple-
conventional poll-response protocols have been
menting a SCADA infrastructure upgrade. Current
enabled, legacy SCADA users can start to see
SCADA solutions still use the poll-response pro-
the conventional use of Ignition. You now have
tocol drivers that are directly connected to field
a parallel communication system where you can
devices over a communications channel or a TCP/
compare values coming in from the conventional
IP network. Because of this, they cannot replace
poll-response and publish-subscribe of MQTT.
or upgrade the poll-response protocol on the
SCADA host until the new protocol is in the field Step 4: You are ready to switch over to your pure
and, vice versa, they cannot upgrade devices until MQTT solution. Once the organization is happy
they have a new protocol on the SCADA host. with the final, pure MQTT infrastructure, you can
remove the OPC poll-response components. This
The Best Way to Migrate Your System will greatly simplify the network topology and
leave you with a clean and pure MQTT solu-
There is a proven four-step migration strategy
tion. Furthermore, you now have a plug-and-play
that uses Ignition, the MQTT Engine Module, and
SCADA system that is easily scalable and can
an edge gateway. The four steps are installing
quickly grow with your organization.
an edge gateway, starting the poll-response with

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 9 | 10
Design Lie
k a Pro:
Best Practices for IoT

Best Practices Recap

To recap the best practices for a successful IIoT implementation, we recommend:

• Planning your strategy and adding to your infrastructure in pieces, giving yourself opportunities to test
and make sure everything is working.
• Choosing MQTT as your IIoT messaging protocol since its feature set is ideal for an IIoT infrastructure.
• Leveraging stateful awareness to help maintain the health of your IIoT infrastructure.
• Employing a redundant strategy throughout your solution.
• Considering Ignition with the Cirrus Link MQTT Engine, Transmission, and Distributor Modules as your
IIoT solution.
• Finally, following the optimal migration strategy to ensure a smooth transition to a new IIoT infrastructure.

The best practices discussed in this paper are proven methods for success. Even if you have a legacy
system, the solutions we have offered reduce friction and give your organization the resources to move
an existing installation into a state-of-the-art IIoT and SCADA solution.

To learn more about how Ignition delivers the industry’s best IIoT solution, visit: inductiveautomation.com

800.266.7798 Design Like a Pro: Best Practices for IIoT

www.inductiveautomation.com © 2017 Inductive Automation 10 | 10