You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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.

The combination of the Transmitter configuration and Ignition tag trees provides the ultimate flexibility in how published data is described. It is important to understand these concepts when defining your system data hierarchy.

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.

The MQTT topics are essentially the 'addresses' of the different components in the distributed system and the combination of any GROUP_ID and EDGE_NODE_ID 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 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.

Each EdgeNodeID will generate a single MQTT Client connection. If your tag tree has multiple folders that are identified as Edge Node IDs, a single Transmitter configuration will result in multiple Sparkplug MQTT clients publishing messages to an MQTT Server.
If your tag folder hierarchy does not conform to this structure, you can explicitly define these required elements under the Sparkplug Settings section in the Transmitter configuration. When configured, these elements will replace the Sparkplug IDs that would otherwise be dynamically picked up from the folder structure.


Let’s take a look at some examples that demonstrate how the message payload is 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 an empty Tag Path, Transmission will dynamically pick up the folders from the root of the tag tree building the following Sparkplug IDs:

GroupID = Facility1, EdgeNodeID = Line1 and DeviceID = PLC1

Since there is only one folder representing an EdgeNodeID (Line1) only one MQTT Client will be created. When tag data changes, there is only one publish topic from this MQTT Client with the payload containing the tag:

Topic: spBv1.0/Facility1/DDATA/Line1/PLC1

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag3","timestamp":1643823756467,"dataType":"Double","value":35.537027196095224}],"seq":23}


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



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 containing the tag.

Topic: spBv1.0/Facility1/DDATA/Line1/PLC1

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag3","timestamp":1643823756467,"dataType":"Double","value":35.537027196095224}],"seq":23}

Topic: spBv1.0/Facility1/DDATA/Line1/PLC2

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823722222,"dataType":"Double","value":40}],"seq":23}


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



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

GroupID = Facility1, EdgeNodeID = Line2 and DeviceID = PLC2

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

MQTT Client Facility1/Line1

Topic: spBv1.0/Facility1/DDATA/Line1/PLC1

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag3","timestamp":1643823756467,"dataType":"Double","value":35.537027196095224}],"seq":23}

MQTT Client Facility1/Line1

Topic: spBv1.0/Facility1/DDATA/Line1/PLC2

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823722222,"dataType":"Double","value":40}],"seq":17}

MQTT Client Facility1/Line2

Topic: spBv1.0/Facility1/DDATA/Line2/PLC1

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823756467,"dataType":"Double","value":60}],"seq":19}

MQTT Client Facility1/Line2

Topic: spBv1.0/Facility1/DDATA/Line2/PLC2

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Tag1","timestamp":1643823722222,"dataType":"Double","value":50}],"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.


Let’s extend our infrastructure again to add a second facility with a physical Edge Node connected to a PLC. Again, we will use the default Transmitter configuration for this device.


At this second facility we will end up with the following Sparkplug IDs and a single MQTT Client.

GroupID = Facility2, EdgeNodeID = Line1 and DeviceID = PLC1

Data published from this second facility will use the topic spBv1.0/Facility2/DDATA/Line1/PLC1 and since the GroupID/EdgeNodeID combination is unique across the two facilities, there will be no data conflict at any MQTT Clients subscribing to the data messages.


If you can design your tag tree to conform to the Sparkplug specification, you can leave MQTT Transmission to dynamically manage the topics and payloads for the tags being published.

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.

If we use the default Transmitter configuration, this will result in following Sparkplug IDs with one MQTT Client.

GroupID = MyCompany, EdgeNodeID = Lakeside and DeviceID = Finished Goods

When tag data changes, there will be one publish topic from this MQTT Client, however, because there are additional folders below the identified DeviceID folder of “Finished Goods”, the tag name included in the payload will include these additional folders.

Topic: spBv1.0/MyCompany/DDATA/Lakeside/Finished Goods

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Line1/Input/PLC1/Tag3","timestamp":1643823756467,"dataType":"Double","value":45.58}],"seq":23}

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Line1/Input/PLC2/Tag2","timestamp":1643823756467,"dataType":"Double","value":50}],"seq":24}

Payload: {"timestamp":1643823757750,"metrics":[{"name":"Line1/Output/PLC2/Tag2","timestamp":1643823756467,"dataType":"Double","value":4}],"seq":25}


If we change the Tag Path to point to a different folder in the tag tree, we will affect how the data is published:


With a Tag Path of My Company/Lakeside/Finished Goods defined, Transmission will dynamically pick up the folders in the tag tree below the Tag Path for the Sparkplug IDs and so we end up with the following:

GroupID = Line1, EdgeNodeID = Input and DeviceID = PLC1

GroupID = Line1, EdgeNodeID = Input and DeviceID = PLC2

GroupID = Line1, EdgeNodeID = Output and DeviceID = PLC1

Now we have two folders representing EdgeNodeIDs and so two MQTT Clients will be created one for Line1/Input and one for Line1/Output. 

However, when tag data changes, each MQTT Client will publish a unique publish topic for each DeviceID and, since there are no additional folders below the DeviceID folder, the tag name only is included in the payload:

MQTT Client connecting as Line1/Input

Topic: spBv1.0/Line1/DDATA/Input/PLC1

Payload: {"timestamp":1643824561258,"metrics":[{"name":"Tag3","timestamp":1643824559684,"dataType":"Double","value":-47.23189031326556}],"seq":95}

Topic: spBv1.0/Line1/DDATA/Input/PLC2

Payload: {"timestamp":1643825036860,"metrics":[{"name":"Tag1","timestamp":1643825035561,"dataType":"Int32","value":50}],"seq":97}

MQTT Client connecting as Line1/Output

Topic: spBv1.0/Line1/DDATA/Output/PLC1

Payload: {"timestamp":1643825036860,"metrics":[{"name":"Tag1","timestamp":1643825035561,"dataType":"Int32","value":80}],"seq":77}



Whilst these two examples shows how flexible the configuration can be, you will need to ensure that your namespace works with your infrastructure. If we added a second identical facility of Meadowside and used the same Transmitter configuration, we would end up with GroupID/EdgeID conflicts.

For example, both Lakeside and Meadowside locations would publish using the topic namespace of spBv1.0/Line1/DDATA/Input/PLC1 and it would not be possible for any MQTT clients subscribing to the data to know which edge node sent the data.


Sparkplug Settings

If your tag folder hierarchy does not allow for MQTT Transmission to dynamically build the required Sparkplug Group ID and Edge ID, then you will need to explicitly define these under the Transmitter Sparkplug Settings section in the MQTT Transmission configuration guide. When configured, these elements will replace the Sparkplug IDs that would otherwise be dynamically picked up from the folder structure.


As an example, using the tag tree and Transmitter configuration below:

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.


We can explicitly configure the Group ID, Edge ID and Device ID under the Sparkplug Settings for the Transmitter. In this example we will set Group ID = MyGroup and Edge Node ID = MyEdgeNode

If you do not explicitly set a value, the Transmitter will dynamically determine those from the tag tree using the Tag Path.


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

GroupID = MyGroup, EdgeNodeID = MyEdgeNode and DeviceID = Lakeside (determined dynamically from the tag tree structure under the Tag Path)

When tag data changes, there is only one publish topic from this MQTT Client

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

Payload: {"timestamp":1643828214163,"metrics":[{"name":"Tag3","timestamp":1643828212379,"dataType":"Double","value":-6.622853362629208}],"seq":113}


If we explicitly set the Device ID also


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":1643828854747,"metrics":[{"name":"Lakeside/Tag3","timestamp":1643828852918,"dataType":"Double","value":32.82691817225028}],"seq":10}


Returning to our first example tag tree:

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}



Additional Resources

  • No labels

New to MQTT? Start Here!