Reference · built on requestConnectorIndustrial & building protocols

Sparkplug

Edge node and device metrics, birth and death certificates, and host state from the Sparkplug B namespace on MQTT.

Request accessPricing ↗

About

Sparkplug is an Eclipse Foundation specification, at version 3.0.0, that defines an MQTT topic namespace, MQTT state management, and a payload for industrial data. Every client uses topics of the form namespace/group_id/message_type/edge_node_id, with device_id appended for device messages and spBv1.0 as the namespace. An Edge Node publishes an NBIRTH with every metric it will report, then NDATA messages by exception as values change, and registers an NDEATH as its MQTT Will Message. Devices behind it do the same with DBIRTH, DDATA, and DDEATH. Host Applications publish STATE on spBv1.0/STATE/sparkplug_host_id, and commands travel as NCMD and DCMD. Payloads are Google Protocol Buffers with typed metrics, DataSets, and Templates.

Through Fibric, a Host Application of its own subscribes to the groups you name and hands each metric change to an operator. A write is proposed for your approval and published once as a DCMD.

This is a reference listing. It documents what Fibric would read from Sparkplug and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • NBIRTH and DBIRTH messages: the full metric list, datatypes, Template definitions, and the bdSeq metric that ties a session to its Will Message
  • NDATA and DDATA messages published by exception when a metric changes, with the seq number for ordering
  • NDEATH and DDEATH: the Will Message the MQTT Server delivers when an Edge Node's session drops, matched by bdSeq to its NBIRTH
  • STATE messages from other Host Applications on spBv1.0/STATE/sparkplug_host_id, published as retained JSON at QoS 1
  • Metric properties: PropertySets, the historical and transient flags, and the null flag on each metric
  • The last NBIRTH and DBIRTH held by a Sparkplug Aware MQTT Server, served as retained messages on its $sparkplug topic

Proposed actions

  • Target capability: propose an NCMD to an Edge Node, including Node Control/Rebirth to request a fresh NBIRTH and DBIRTHs
  • Target capability: propose a DCMD that writes a metric value on a device, published at QoS 0 with retain false
  • Target capability: propose publishing this Host Application's own STATE birth and death certificates at QoS 1 with retain true

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • See a line stop the moment the node dies

    An Edge Node's NDEATH arrives as the MQTT Will Message. The operator matches its bdSeq to the last NBIRTH, marks every device under it stale, and posts one notice with the node name.

    With Line Downtime, Alarm Triage

  • Track a metric that drifts between births

    DDATA arrives only when a value changes. The operator compares cycle-time metrics against the Template definition from DBIRTH and flags drift before the shift report.

    With Cycle Drift, OEE Loss

  • Write a setpoint through the edge

    The operator proposes a DCMD carrying the metric name and new value. You approve. The command is published once and the next DDATA confirms the change as the receipt.

    With Setpoint Drift

  • Find nodes with the wrong catalog

    A Sparkplug Aware MQTT Server keeps the last NBIRTH and DBIRTH. The operator compares those metric lists with what your historian expects and lists the nodes to rebirth.

    With Data Freshness, Integration Health

Requirements

  • An MQTT v3.1.1 or v5.0 server reachable by the Edge Nodes and by this Host Application
  • Client sessions configured as the specification requires, including Clean Session set to true on MQTT 3.1.1
  • ACLs that let this client subscribe to spBv1.0/# and publish on its own spBv1.0/STATE/sparkplug_host_id topic
  • For commands, designation as an Edge Node's Primary Host Application, since only the Primary Host should have permission to issue commands
Authentication
Sparkplug rides on MQTT authentication: a unique MQTT Client ID with an optional username and password, TLS on the socket as the specification's examples show, and MQTT Server access control lists that confine each client to its own group and Edge Node topics.

Limits

  • Data messages are published at QoS 0 with retain false, so a Host that was offline sees nothing until the next change or a Rebirth
  • An Edge Node names at most one Primary Host Application, and only that host should issue commands to it
  • Sparkplug A payloads are deprecated; this listing covers the Sparkplug B (spBv1.0) namespace
  • Ordering depends on the seq number, and messages still missing after the Reorder Timeout force a Rebirth request

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Sparkplug ↗

Questions and answers

What is a birth certificate in Sparkplug?
An NBIRTH (Edge Node) or DBIRTH (device) message that declares every metric, datatype, and Template the node will publish, plus the bdSeq number. Later NDATA and DDATA messages carry only changes, so a Host builds its picture from the birth.
Which MQTT versions and QoS does Sparkplug use?
MQTT v3.1.1 or v5.0. NBIRTH, NDATA, NCMD, DBIRTH, DDATA, DDEATH, and DCMD are published at QoS 0 with retain false. Host STATE birth and death certificates use QoS 1 with retain true.
How does Sparkplug secure its traffic?
It defers to MQTT: a unique Client ID, optional username and password, TLS on the connection, and server-side ACLs so an Edge Node can publish only on topics for its own group and Edge Node ID. The specification does not mandate a TCP/IP security scheme.
Ask about Sparkplug

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Sparkplug through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy