Messages

hermsen



Project Members:

Sparkplug™ and the Sparkplug™ logo are trademarks of the Eclipse Foundation
Copyright © 10/11/19 Eclipse Foundation, Inc. https://www.eclipse.org/legal/efsl.php

Introduction

Sparkplug Messages consists of two parts;

  • 1 Topic Namespace,
  • 2 Message (a Payload and Metrics)

The idea is simple;
Basicly a Sparkplug message containing a SparkplugB encoded payload is posted in a specific Sparkplug Topic Namespace on the broker by an Edge Node or any other node that can publish messages. These message can be consumed by any other Node that is subscribed on these messages.

Each EoN node can share data on a broker via a set of pre-defined topic rules (these are the namespaces). The topics follow these pre-defined rules. When your infrastucture changes, the topics will change along. If your infrastructure grows, the topics grow accordingly, if your infrastructure shrinks, your topics shrink accordingly.
Each message consists of a single Topic in the form of a hierarchy and a payload which consists of one or several metrics and it's metadata.

The Node decides what payload information will sent the broker (and thus shared to all other clients in the network which are subscribed) and whether this information is refreshed in a timely fashion or on change of the data (The decision of what information is shared is ultimatly determined by the goal of the software)
So, it is up to the EoN node device how much information and what kind of meta data of the information is shared.

Topic Namespace

Sparkplug defines the Topic Namespace for a set of MQTT messages that are used to manage connection state as well as bidirectional metric information exchange that would apply to many typical real-time SCADA/IIoT, monitoring, and data collection system use cases.

Using these defined messages host SCADA/IIoT applications can:
1. Discover all metadata and monitor state of any EoN/Device connected to the MQTT infrastructure.
2. Discover all metrics which include all diagnostics, properties, metadata, and current state values.
3. Issue write/command messages to any EoN/Device metric.

All MQTT clients using the Sparkplug specification use the following Topic Namespace structure:

    namespace/group_id/message_type/edge_node_id/[device_id]

Where:

  • namespace is either “spAv1.0” or “spBv1.0” (the Sparkplug A and Sparkplug B or any new future releases of the specification),
  • group_id is a group string reference to a logical grouping of nodes, for instance a machine, manufacturing cell or an oil pipeline section,
  • message_type element is an name string that defines how the MQTT Server processes the message,
  • edge_node_id is the Name ID of the MQTT Edge device that interfaces to real-world inputs and outputs or a acts as gateway device,
  • device_id is the name ID of the end device that physically interfaces to the real-world input and outputs. The device ID is optional and not present if the edge node is the actual device interfacing to the real world inputs and outputs.

namespace

The root element that will define both the structure of the remaining namespace elements as well as the encoding used for the associated payload data. The current Sparkplug specification defines two namespaces

Sparkplug payload definition B -> namespace element is spBv1.0
Sparkplug payload definition A -> namespace element is spAv1.0 (Deprecated!)

group_id

This provides unique logical group ID of MQTT EoN nodes. For group_id the format should be UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign).
Examples of where the group_id might be used include Cement industry where MQTT EoN nodes on different department have the different group_id

message_type Element

Provide the indication as to, how to handle the MQTT payload of the message.
The following message_type elements are defined for the Sparkplug Topic Namespace:

NBIRTH  Birth certificate for MQTT EoN nodes.
NDEATH  Death certificate for MQTT EoN nodes.
DBIRTH  Birth certificate for Devices.
DDEATH  Death certificate for Devices.
NDATA  Node data message.
DDATA  Device data message.
NCMD  Node command message.
DCMD  Device command message.
STATE  Critical application state message.

edge_node_id

Unique identification for the MQTT EoN nodes within the infrastructure.
For edge_node_id the format should be UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign).
The edge_node_id travels with every message published, so it should be as short as possible

device_id

Unique ID which used to identify the device attached to the MQTT EoN node.
The device_id is an optional element since some messages will be either originating or destined to the edge_node_id, in that place device_id would not be required.
The format of the device_id is a valid UTF-8 alphanumeric String except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign).
The device_id travels with every message published, so it should be as short as possible.

For an in depth overview of all namespaces see
SparkPlug Specification Chapter 6. Sparkplug™ MQTT Topic Namespace

Message Payload & Metrics Component

As specified the second part of the message consists of a Payload and Metrics
A Sparkplug B payload is the top-level component that is encoded and used in an MQTT message.
It contains some basic information such as a timestamp and a sequence number as well as an array of metrics which contain key/value pairs of data.

For a in depth overview of all Payload components & metrics see
SparkPlug Specification Chapter 15. Sparkplug™ B v1.0 Payload Components


Related

Home: Add SparkplugB to existing CODESYS project
Home: General Sparkplug info
Home: Home
Home: Infrastructure
Home: Preview how-to
Home: Security
Home: Setup a test system with Ignition Primary Host