Page History

Abstract

This page describes how MQTT Transmission Transmitter configurations interact with Ignition tag trees to publish MQTT messages and tags to an MQTT Server. It explains how tags get identified to be published as well as the specific topics that data will be published on. It also goes over some example configurations to show how the system will behave in different scenarios.

Sparkplug Overview

All MQTT clients using the Sparkplug specification will publish MQTT messages consisting of a topic and payload component. For the Sparkplug B specification, which is used by MQTT Transmission, the Topic Namespace structure is defined as

spBv1.0/GROUP_ID/VERB/EDGE_NODE_ID/DEVICE_ID

where

• GROUP_ID is meant to represent a logical grouping of Edge Nodes. This can be a region, a facility name, or any meaningful grouping of Edge Nodes within your application.
• VERB provides an indication on how to handle the payload of the message. This includes whether the message is a birth certificate, death certificate, data message, command message, etc.
• EDGE_NODE_ID is the ID of the logical Edge Node. This is often the name of the system running Ignition with MQTT Transmission.
• DEVICE_ID is the ID of a device attached to the Ignition instance. This can be a PLC or logical grouping of tags that represent a physical or logical device connected to Ignition.

In the Sparkplug specification there are two Sparkplug Descriptors defined as:

• Edge Node Descriptor which is the GROUP_ID and EDGE_NODE_ID combination
• Device Descriptor which is the GROUP_ID, EDGE_NODE_ID and DEVICE_ID combination

The MQTT topics are essentially the 'addresses' of the different components in the distributed system and the

Sparkplug Edge Node Descriptor must be unique within the distributed system.

 Because these are used as 'addresses' in the system you should never have two that conflict with each other

- it is a bit like having two houses with the same postal address. It isn't possible for other MQTT clients in the system to tell which edge node sent the data and, when sending messages to them, they will both receive the messages.

Of course, you can have two or more Edge Nodes with the same GROUP_ID as long as each EDGE_NODE_ID is unique. To use the analogy above, it would be like having houses on the same street with different house numbers.

Transmitters and Tag Trees

MQTT Transmission is designed to dynamically pick up tags in Ignition or Ignition Edge and publish tag change events to an MQTT Server. How the tags are published to the MQTT Server is based on a combination of a 'Transmitter' configuration as well as the arrangement of tags in the Ignition tag tree.

Transmitters will monitor tags from a specific Tag Provider and, optionally, a specific Tag Path. Each folder under the Tag Path would be considered a Sparkplug 'Group ID', each folder under a 'Group ID' folder would be considered an 'Edge Node ID' and finally, each folder under an 'Edge Node ID' folder would be considered a 'Device ID'. The tag folder hierarchy is then used to dynamically build the MQTT message that will represent the tags.

A transmitter will use the tag folder hierarchy under the configured Tag Path in combination with the Sparkplug IDs to dynamically build the topic namespace used to represent the tags.

The following the rules below are used when building the topic namespace:

• If the Sparkplug IDs are empty, there must be at least 3 folder levels below the Tag Path to resolve the Group, Edge and Device IDs (if needed) where the Group and Edge combination is unique.

• If the Sparkplug Group ID only is configured, there must be at least 2 folder levels below the Tag Path to resolve to Edge and Device IDs (if needed) where the Group and Edge combination is unique.

• If the Sparkplug Group ID and Edge ID only are configured, there must be least 1 folder level or device level UDT below the Tag Path to resolve to a Device ID (if needed)

• If the Sparkplug IDs are all configured the tag folder hierarchy will not be used

MQTT Transmission will then use the remainder of the tag folder hierarchy not used in the topic namespace to identify the name of the tag included in the payload metrics.

Let’s take a look at some examples that demonstrate how the message topic and payload

are affected by the tag tree and Transmitter configurations starting with

a basic Ignition tag folder hierarchy conforming to the GroupID, EdgeNodeID and DeviceID structure and the default Transmitter configuration.

In this example the folders represent a facility, physical edge node device and the PLCs connected to that device.

With this configuration of an empty Tag Path and empty Sparkplug IDs, Transmission will dynamically

pickup the folders from the root of the tag

provider building the

Sparkplug

Descriptors as:

• Edge Node Descriptor = Facility/Line1
• Device Descriptor = Facility/Line1/PLC1

Since there is only one

Edge Node Descriptor identified, only one MQTT Client will be created.

When tag data changes, there is only one publish topic from this MQTT Client with the payload metrics containing the tag name Tag3 :

• Topic: spBv1.0/

• Facility/DDATA/Line1/PLC1
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag3","timestamp":1643823756467,"dataType":"Double","value":33.02}],"seq":23}

Let's extend the Ignition tag folder with this example:

With the same configuration, there is no change to the message topic of spBv1.0/Facility/DDATA/LIne1/PLC1 but the payload metrics will use the remainder of the Ignition tag path for the tag name:

• Payload: {"timestamp":1643823757750,"metrics":[{"name":"Area1/Batch1/Tag3","timestamp":1643823756467,"dataType":"Double","value":

• 33.

• 02}],"seq":23}

Let’s add additional PLCs under the physical Edge Node.

Now let's see how changing the Tag Path and Sparkplug IDs in the Transmitter configuration affects the message topic and payload name metric for the Ignition tag based on the topic namespace rules list above:

As you can see the combination of Tag Path and Sparkplug IDs provides immense flexibility in your Sparkplug namespace configuration.

Let's add an additional tag and tag folder with the configuration of an empty Tag Path and empty Sparkplug IDs:

Transmission will build the following Sparkplug Descriptors:

• Edge Node Descriptor
  1. Facility/Line1
• Device Descriptors
  1. Facility/Line1/PLC1
  2. Facility/Line1/PLC2

As there is still only one Edge Node Descriptor, only one MQTT Client will be created. 

This will result in following Sparkplug IDs but still only one MQTT Client:

GroupID = Facility1, EdgeNodeID = Line1 and DeviceID = PLC1

GroupID = Facility1, EdgeNodeID = Line1 and DeviceID = PLC2

When tag data changes, there are two publish topics from this MQTT Client with the payload metrics containing the tag names Tag3 and Tag1.

• Topic: spBv1.0/

• Facility/DDATA/Line1/PLC1
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag3","timestamp":1643823756467,"dataType":"Double","value":

• • 1.

• • 88}],"seq":23}
• Topic: spBv1.0/

• Facility/DDATA/Line1/PLC2
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823722222,"dataType":"Double","value":

• • 85.16}],"seq":

• • 24}

Extending the tag tree to add a second physical Edge Node with PLCs

Let's add an additional tags and tag folders: 

Transmission will build the following Sparkplug Descriptors:

• Edge Node Descriptors
  1. Facility/Line1
  2. Facility/Line2
• Device Descriptors
  1. Facility/Line1/PLC1
  2. Facility/Line1/PLC2
  3. Facility/Line2/PLC1
  4. Facility/Line2/PLC2

Now there are two Edge Node Descriptors which results in the creation of two MQTT Clients.

This will result in following Sparkplug IDs and, since there are now two EdgeNodes identified, two MQTT Clients will be created.

GroupID = Facility1, EdgeNodeID = Line1 and DeviceID = PLC1

GroupID = Facility1, EdgeNodeID = Line1 and DeviceID = PLC2

GroupID = Facility1, EdgeNodeID = Line2 and DeviceID = PLC1

When tag data changes, there are two publish topics from each MQTT Client with the payload metrics containing the tag

names Tag1, Tag2 and Tag3.

• Topic: spBv1.0/

• Facility/DDATA/Line1/PLC1
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag3","timestamp":1643823756467,"dataType":"Double","value":

• • 60.

• • 22}]

• • "seq":23}

MQTT Client Facility1/Line1

• cspBv1.0/

• Facility/DDATA/Line1/PLC2
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823722222,"dataType":"Double","value":

• • 53.79}],"seq":17}

• Topic: spBv1.0/

• Facility/DDATA/Line2/PLC1
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823756467,"dataType":"Double","value":60.22}],"seq":19}

• Topic: spBv1.0/

• Facility/DDATA/Line2/PLC2
  • Payload: {"timestamp":1643823757750,"metrics":[{"name":"

• • Tag2","timestamp":1643823722222,"dataType":"Double","value":

• • 60.22}],"seq":57}

You can see how many MQTT Clients have been created and whether they are connected from the Servers tab.

As you can see, we

haven't made any changes to the Transmitter configuration and MQTT Transmission has dynamically created the MQTT Clients, topic

and payloads from the Ignition tag tree.

Lets extend our infrastructure

to add a second facility with

a

Transmitter configured with an empty Tag Path and Sparkplug IDs.

At this second facility

, Transmission will build the following Sparkplug Descriptors:

• Edge Node Descriptor
  1. Facility2/Line1
• Device Descriptor
  1. Facility2/Line1/PLC1
  2. Facility2/Line1/PLC2

Data published from this second facility will use the

topics spBv1.0/Facility2/DDATA/Line1/PLC1 and

spBv1.0/Facility2/DDATA/Line1/PLC2.

Since the Edge Node Descriptors across the infrastructure are unique, there will be no data conflict at any MQTT Clients subscribing to the data messages.

Of course this may not be possible due to existing infrastructure definitions and so the Transmitter configuration allows ways to manage this using the Tag Path and Sparkplug Setting parameters.

Consider this tag tree which doesn’t easily conform to the Sparkplug specification. Using the Transmitter configuration, we can affect the MQTT Clients created, and topics published for the data.

Now let's consider extending the original configuration to 100 locations without having to make changes to the tag tree. How would we avoid Edge Node collisions in this scenario? 

Here is where we can leverage the Transmitter Tag Path and Sparkplug ID configurations.

At each facility we can build a transmitter configuration with a Tag Path of Facility and set a specific GROUP_ID corresponding to the location such as :

With this configuration, MQTT Transmission will pickup the next two folder levels under the Tag Path to use as the EDGE_NODE_ID and DEVICE_ID resulting in the following:

• Edge Node Descriptors
  • Plant_1/Line1
  • Plant_1/Line2
  • Plant_2/Line1
  • Plant_2/Line2

through to

• • Plant_100/Line1
  • Plant_100/Line2

Topics for data published would then become:

• spBv1.0/Plant_1/DDATA/Line1/PLC1
• spBv1.0/Plant_1/DDATA/Line1/PLC1
• spBv1.0/Plant_2/DDATA/Line1/PLC1
• spBv1.0/Plant_2/DDATA/Line1/PLC1

through to

• spBv1.0/Plant_100/DDATA/Line1/PLC1
• spBv1.0/Plant_100/DDATA/Line1/PLC1

The infrastructure would have 200 MQTT Clients with unique Edge Node Descriptors across the infrastructure.

With this Transmitter configuration and tag tree we end up with the following Sparkplug IDs:

GroupID = Lakeside, EdgeNodeID = "" and DeviceID = ""

Since there are no EdgeNodeIDs discovered, no MQTT Client will be created, and you will see that no MQTT Clients are connected when looking at the MQTT Transmission Server settings.

Even through we have a well formatted tag tree and could take advantage of the dynamic nature of the MQTT Transmitters configuration, we can still explicitly set the Sparkplug IDs.

We will have the following Sparkplug IDs and only one MQTT Client created.

GroupID = MyGroup, EdgeNodeID = MyEdgeNode and DeviceID = MyDevice

When tag data changes, there is only one publish topic from this MQTT Client and any folders below the Tag Path are represented in the tag name included in the payload

Topic: spBv1.0/MyGroup/DDATA/MyEdgeNode/MyDevice

Payload: {"timestamp":1643829342647,"metrics":[{"name":"Facility1/Line1/PLC1/Tag3","timestamp":1643829340684,"dataType":"Double","value":-49.89888853762046}],"seq":89}

Payload: {"timestamp":1643829404508,"metrics":[{"name":"Facility1/Line1/PLC1/Tag3","timestamp":1643829402895,"dataType":"Double","value":-16.272136663001845}{"name":"Facility1/Line1/PLC2/Tag1","timestamp":1643829403931,"dataType":"Int32","value":50}],"seq":120}

Payload: {"timestamp":1643829415502,"metrics”:[{"name":"Facility1/Line1/PLC2/Tag1","timestamp":1643829403931,"dataType":"Int32","value":60}],"seq":130}