Operational Details

 

The MQTT application implements the MQTT protocol to push data to an MQTT broker. Subscribing to data is only supported when using the Sparkplug B publishing format.

 

All data is published at MQTT Quality of Service (QoS) level 1, which is also known as At Least Once. This level of service requires the MQTT  broker (host) to acknowledge that it received the published data. If the published data is not acknowledged by the broker, the MQTT application will make a diagnostic log entry, but data is not buffered and resent.

 

The MQTT application operates on a 1 second cycle. Values are processed once per second, assuming that the RTU is not overloaded and can support this execution speed.

 

When the application is first started, or when the application is reconfigured, it checks to see if the the MQTT broker is enabled. As long as the server is enabled in the application's configuration, the application will attempt to the connect to the MQTT broker. If the TLS option is checked, the application executable supports TLS, and the TLS option is licensed, then the application will attempt a TLS connection.

 

If the TLS option is checked but the executable does not support TLS, then the connection won't be attempted and an entry will be made in the diagnostic log. If the TLS option is checked but the license doesn't support TLS, then the connection won't be attempted and an entry will be made in the diagnostic log.

 

 

MQTT keep alives are sent once per minute, assuming that there is an active connection to the MQTT broker.

 

Once a connection to the broker is established, on each application execution cycle, the application will first read all monitored values from Modbus registers, regardless of whether alarming is enabled or not. If any values are out of range, then the value that is out of range will be published to the broker. If a value that was formerly out of range is back in range, then that value will be immediately published, because the alarm has been cleared.

 

For integer and float values that have publishing on change enabled, the currently read value will be compared to the last published value. If the current value has changed from the last published value by more than the deadband, then the value will be immediately published. Digital values are published on any change.

 

After values are processed for alarms and changes, reporting groups are processed. If a reporting group is scheduled to be published, or the On Demand coil for the reporting group is set, then the values in the reporting group will be published.

 

When an alarm is published and the Publish Format setting is Tags, three tags will actually be published: one for the value, the time that the report was generated at, and the status. The tag name will be a combination of the Topic Prefix as configured in the MQTT Server Settings, the group instance name of the monitored value, and the sub-value that is published (value, time or status.)

For example, if the Topic Prefix is A946612, the value to be monitored is named Pressure raw counts, and the actual value is high when compared to the alarms limits, the published tags will look like the screen grab below. Three tags are published for each alarm that occurs. Time is the number of seconds since January 1, 1970, value is the actual value, and status is whether the value is high, low or normal when compared to the alarm limits.

 

 

When a reporting group is published, a single tag will be published for each value that belongs to the group. Each tag will be named according to a combination of the Topic Prefix as configured in the MQTT Server Settings and the name of the group instance that the value belongs to, along with value.

 

For example, if the Topic Prefix is A946612 and a reporting group contains 4 tags, and they are named static pressure, differential pressure, temperature and flow, the published data will look like the screen grab below. Value is appended to the tag's name, and each tag in the group is published individually.

 

 

When an alarm is published and the Publish Format setting is JSON, the values will be published in a single JSON object: one for the value, one for the time that the report was generated at, and the status. The JSON object will be published under a tag that is named for the Topic Prefix as configured in the MQTT Server Settings.

For example, if the Topic Prefix is A946612, the value to be monitored is named Pressure raw counts, and the actual value is high when compared to the alarms limits, the published JSON object will look like the screen grab below. The  JSON object holds three different values. Time is the number of seconds since January 1, 1970, value is the actual value, and status is whether the value is high, low or normal when compared to the alarm limits.

 

 

When a reporting group is published, the JSON object will contain keys for each tag in the group. Each tag will be named according to the name of the group instance that the value belongs to. The JSON object will also contain a time stamp that is the seconds from January 1, 1970.

 

For example, if the Topic Prefix is A946612 and a reporting group contains 4 tags, and they are named static pressure, differential pressure, temperature and flow, the published data will look like the screen grab below.

 

 

 

Sparkplug B is a data standard authored by Cirrus Link Solutions. Details on the Sparkplug B standard can be found online. This standard applies metadata to values to give them some context. This additional context is useful in downstream applications and allows for advanced functionality in applications that support the Sparkplug standard. For example, using Inductive Automation's Ignition SCADA platform, and Cirrus Link's MQTT Engine, completely automated tag generation is possible.