In part 2 of our series, we look at how to set up groov Manage and Ignition Edge for publishing with Sparkplug B payloads.

MQTT is the darling of enterprise IoT because of its efficiency, simplicity, and flexibility, which makes it ideal for use in applications that communicate with resource-constrained edge-of-network devices. After being nurtured for years within IBM, and incorporated into their smart energy, health, and utilities solutions, MQTT has become the chosen messaging protocol across all the major cloud IoT platforms as well as highly scalable applications, like Facebook Messenger.

But I wouldn’t be talking about MQTT here if it didn’t also have an important place in the world of industrial control. There are other options for communication within a control network and across IT systems, but the most common ones share similar drawbacks that MQTT avoids. In particular, both OPC and HTTP utilize a point-to-point, request-response communication model and a much larger payload than MQTT, which results in numerous security challenges and significantly higher network demand. 

As we saw in part one of this series, though, plain-vanilla MQTT has a few weaknesses when it comes to large-scale, mission-critical scenarios. This inspired the development of the open-source Sparkplug specification under the leadership of one of MQTT’s co-inventors, Arlen Nipper. The current version of Sparkplug (Sparkplug B, or SpB) adds a handful of implementation details to MQTT clients:

Enforced state monitoring

While MQTT includes features to monitor client connection status, there’s no guarantee that a vendor will implement them. A device that conforms to the Sparkplug spec, on the other hand, will always register a death message with the server, to be distributed in case it unexpectedly disconnects from the network.

Payload definition

Like HTTP, MQTT doesn’t care what type of data it transmits, which puts the burden on subscribers to interpret data correctly. Sparkplug B clients package the payload with structured metadata so the format can be identified by any subscriber. The full payload is then encoded to maintain a small footprint.

Standard topic format

MQTT’s flexible topic naming can require heavy up-front configuration for large networks and becomes an issue with devices from different vendors, which may use different naming patterns. Sparkplug defines a standard topic format, reducing variability among vendors, and in combination with the SpB payload, enabling clients to automatically discover available data.

With Sparkplug B, an MQTT network is guaranteed to be state-aware and interoperable without compromising flexibility and efficiency. Devices from different vendors can share and use data without needing to know the details of where it originated, host applications can discover published data quickly, and all clients are notified in real-time when data becomes stale.

Getting started with Sparkplug B

Next, I’ll show you how to set up groov EPIC for Sparkplug publishing. Again, you have two options: groov Manage or Ignition Edge.

Option 1: groov Manage

Last time we walked through setting up groov Manage to publish PAC Control tags and I/O as string data. Configuring groov Manage to use a Sparkplug B payload instead is nearly identical.

Here’s a comparison of the two configuration screens:

You’ll notice the fields are slightly different. That’s because of Sparkplug’s topic path requirements. The benefit is that any subscriber, regardless of vendor, can read updates published by any other client using the following path format:

“spBv1.0/<Group ID>/+/<Edge Node ID>/<Device ID>”

which, in this case, maps to: 

“spBv1.0/opto22/+/2nd-floor-josh/epic-lc”.

Once you’ve configured the MQTT service for your EPIC, you can create and publish tags via PAC Control by enabling the Make Public option in the tag or I/O point configuration dialog.

Option 2: Ignition Edge

Setting up Ignition Edge involves more steps than groov Manage, but the result is powerful. Fortunately for you and me, we already have some great video tutorials that walk us through:

1. Configuring Ignition Edge for the first time (feel free to skip license activation for now)
2. Configuring the Ignition Edge OPC-UA server and adding a device (you'll add your EPIC using the “Opto 22 groov EPIC and SNAP PAC” driver with localhost as the address)
3. Configuring the MQTT Transmission module, connecting to an MQTT server, and setting up the Ignition tag folder structure

Here’s what my tag folder structure looks like in Ignition Designer:

This setup produces the same Sparkplug B topic path as the groov Manage setup in the previous section.

Out of the box, you’ll have unrestricted access to all of the features of Ignition Edge on a two hour timer. At the end of two hours, just reset the timer. For uninterrupted use, you can purchase an Ignition Edge license (GROOV-LIC-EDGE).

In addition to EPIC data, if you need to connect to and publish data from legacy systems or PLCs, like Allen-Bradley or Siemens, or any Modbus/TCP compatible device, you can follow the same process, using Ignition Edge on EPIC as the gateway to your MQTT network. It's one of the primary advantages of the Ignition Edge MQTT client.

Alternative: Node-RED

If you only need your groov EPIC to subscribe to MQTT data, Node-RED can also work with Sparkplug B payloads. It requires substantial custom programming to create a fully compatible client, so you won't have all of Sparkplug's functionality. (For this reason, we don't recommend trying to publish Sparkplug payloads with Node-RED. That’s like doing your own dental work 🦷⛏️)

But Node-RED does have the advantage of being available for free, and it easily mashes up MQTT topics with data from other sources. It’s also great for creating dashboards or a light UI.

Take a look at this guide on the developer forums to give it a try. UPDATE: Here's an additional post on Sparkplug control messages.

Trade-offs and considerations

Sparkplug makes it easier to bring MQTT publishers and subscribers online, and to work with devices from different vendors, so we recommend it when looking to grow and manage a large network. We recommend using groov Manage when working with data sets up to around 1000 PAC Control or I/O tags per EPIC. Ignition Edge should be able to go higher than this without affecting performance, but we haven’t tested its limits yet.

Sparkplug also gives you the guarantee of state awareness, important if you rely on high-quality data for operations, auditing, or historization. Next time, we will get into the additional fault-tolerance features that both groov Manage and Ignition Edge offer. For now, I will just say that for the modest price of an Ignition Edge license, you get a lot.

Let’s see how our two clients stack up right now:

^† current list pricing as of 2/17/20

A general consideration, of course, is the need for Sparkplug-compatible clients. Since MQTT is data-agnostic, any broker can handle Sparkplug B traffic alongside plain MQTT traffic without an issue. However, any device or application clients that want to subscribe to your SpB data will need to support SpB as well.

Coming up next...

What about legacy applications, like SCADA or HMI packages that don’t support MQTT with Sparkplug yet? We'll look at this, as well as features that build on Sparkplug's inherent fault-tolerance, as we explore MQTT on groov EPIC for large-scale and mission-critical operations.

All posts in this series

Part 1 - MQTT: Basic publishing with groov EPIC
Part 2 - MQTT: Faster, better with Sparkplug B
Part 3 - MQTT: Mission-critical fault tolerance
Part 4 - MQTT: Bringing it all together