ISO/IEC 20237:2023

Information technology — Sparkplug® version 3.0

Technologies de l'information — Sparkplug® version 3.0

General Information

• Status: Published
• Publication Date: 17-Oct-2023
• ICS: 35.020 - Information technology (IT) in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 18-Oct-2023
• Due Date: 05-Jun-2024
• Completion Date: 18-Oct-2023

Overview

ISO/IEC 20237:2023 - Information technology - Sparkplug® version 3.0 standardizes the Sparkplug v3.0 specification for MQTT-based industrial messaging. Published October 2023 (First edition), the document formalizes topic namespace conventions, state management, message types and payload encodings (including Google Protocol Buffers), operational behavior for sessions, and security and high‑availability considerations. The specification was prepared by OASIS (Sparkplug 3.0.0) and adopted under the ISO/IEC JTC 1 PAS procedure.

Keywords: ISO/IEC 20237:2023, Sparkplug 3.0, MQTT, industrial IoT, Protocol Buffers, IIoT, message payload, topic namespace

Key Topics and Technical Requirements

• Topic namespace and naming: Defines elements such as namespace, group_id, message_type, edge_node_id and device_id to ensure consistent MQTT topic structure and routing.
• Message types and lifecycle: Standardizes core message types (e.g., birth/death certificates, data and command messages) and their semantics for NBIRTH/DBIRTH, NDATA/DDATA, NCMD/DCMD, NDEATH/DDEATH, and STATE messages.
• Payload formats: Specifies Sparkplug payloads and explicitly references Google Protocol Buffers for efficient, interoperable serialization; includes metric naming, templates, DataSet and metadata constructs.
• Operational behavior: Covers pub/sub principles, session establishment and termination for host applications, edge nodes and MQTT-enabled devices, timestamping, case sensitivity and message ordering rules.
• State management: Defines continuous session awareness, report-by-exception patterns, and birth/death certificate semantics to manage node and device state across MQTT brokers.
• Security: Addresses TLS, authentication, authorization and implementation notes (underlying MQTT security, encrypted sockets, ACLs).
• High availability: Guidance for resilient MQTT server topologies and state handling in multi-broker deployments.

Practical Applications

• Industrial IoT (IIoT) telemetry and device-to-cloud integration
• SCADA and process automation messaging between PLCs, edge gateways and cloud systems
• Edge computing deployments where reliable state management and lightweight serialization are required
• Systems integration for MES, historian, and analytics platforms that consume standardized MQTT topics and Protocol Buffers payloads

Who Should Use This Standard

• MQTT broker and client implementers
• Edge gateway and device OEMs building Sparkplug-enabled devices
• Systems integrators and software developers implementing industrial telemetry
• Security architects and operations teams deploying secure, high‑availability MQTT infrastructures
• Standards bodies and procurement teams specifying IIoT interoperability

Related Standards and Notes

• Builds on the MQTT messaging pattern and leverages Google Protocol Buffers for payload serialization.
• Prepared by OASIS Sparkplug working groups; implementers should consult MQTT and TLS best practices alongside ISO/IEC 20237:2023 for secure deployments.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 20237
First edition
2023-10
Information technology —
Sparkplug® version 3.0
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had
not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by OASIS (as Sparkplug 3.0.0, Sparkplug Specification) and drafted in
accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint Technical
Committee ISO/IEC JTC 1, Information technology.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
Table of Contents
1. Introduction . 2
1.1. Rationale and Use Case . 2
1.1.1. Define an MQTT Topic Namespace . 2
1.1.2. Define MQTT State Management . 2
1.1.3. Define the MQTT Payload . 2
1.1.4. Background . 3
1.2. Intellectual Property Rights . 4
1.2.1. Disclaimers . 4
1.3. Organization of the Sparkplug Specification . 4
1.4. Terminology. 5
1.4.1. Infrastructure Components . 5
1.5. Normative References . 8
1.6. Consolidated List of Normative Statements . 9
1.7. Security . 9
1.7.1. Authentication . 9
1.7.2. Authorization . 9
1.7.3. Encryption . 9
1.8. Normative Keywords . 10
1.9. Leveraging Standards and Open Source . 10
2. Principles . 10
2.1. Pub/Sub . 10
2.2. Report by Exception . 10
2.3. Continuous Session Awareness . 11
2.4. Birth and Death Certificates . 11
2.5. Persistent vs Non-Persistent Connections for Edge Nodes . 12
3. Sparkplug Architecture and Infrastructure Components . 12
3.1. MQTT Server(s) . 13
3.2. MQTT Edge Node . 13
3.3. Device/Sensor . 14
3.4. MQTT Enabled Device (Sparkplug) . 14
3.5. Primary Host Application . 14
3.6. Sparkplug Host Application . 14
4. Topics and Messages . 14
4.1. Topic Namespace Elements . 15
4.1.1. namespace Element . 15
4.1.2. group_id Element . 15
© ISO/IEC 2023 – All rights reserved iv

4.1.3. message_type Element . 15
4.1.4. edge_node_id Element . 16
4.1.5. device_id Element . 16
4.2. Message Types and Contents . 17
4.2.1. Edge Node . 17
4.2.2. Device/Sensor . 21
4.2.3. Birth Certificate Message (STATE) . 24
4.2.4. Death Certificate Message (STATE) . 25
5. Operational Behavior . 26
5.1. Timestamps in Sparkplug. 26
5.2. Case Sensitivity in Sparkplug . 26
5.3. Host Application Session Establishment. 27
5.4. Edge Node Session Establishment . 30
5.5. Edge Node Session Termination. 34
5.6. Device Session Establishment . 36
5.7. Device Session Termination . 39
5.8. Sparkplug Host Applications . 40
5.9. Sparkplug Host Application Message Ordering . 40
5.10. Primary Host Application STATE in Multiple MQTT Server Topologies . 41
5.11. Edge Node NDATA and NCMD Messages . 43
5.12. MQTT Enabled Device Session Establishment . 46
5.13. Sparkplug Host Application Session Establishment . 46
5.14. Sparkplug Host Application Session Termination . 47
5.15. Sparkplug Host Application Receive Data . 48
5.16. Data Publish . 49
5.17. Commands . 50
6. Payloads . 52
6.1. Overview . 52
6.2. Google Protocol Buffers . 53
6.3. Sparkplug A MQTT Payload Definition . 53
6.4. Sparkplug B MQTT Payload Definition . 53
6.4.1. Google Protocol Buffer Schema . 54
6.4.2. Payload Metric Naming Convention . 59
6.4.3. Sparkplug B v1.0 Payload Components . 60
6.4.4. Payload Component Definitions . 60
6.4.5. Payload . 60
6.4.6. Metric . 61
v © ISO/IEC 2023 – All rights reserved

6.4.7. MetaData . 64
6.4.8. PropertySet . 64
6.4.9. PropertyValue . 65
6.4.10. PropertySetList . 66
6.4.11. DataSet. 66
6.4.12. DataSet.Row . 67
6.4.13. DataSet.DataSetValue . 67
6.4.14. Template . 68
6.4.15. Template.Parameter . 70
6.4.16. Data Types . 71
6.4.17. Datatype Details . 72
6.4.18. Payload Representation on Host Applications . 77
6.4.19. NBIRTH . 78
6.4.20. DBIRTH. 80
6.4.21. NDATA . 83
6.4.22. DDATA . 84
6.4.23. NCMD . 85
6.4.24. DCMD . 86
6.4.25. NDEATH . 87
6.4.26. DDEATH . 89
6.4.27. STATE. 89
7. Security . 90
7.1. TLS . 90
7.2. Authentication . 91
7.3. Authorization . 91
7.4. Implementation Notes . 91
7.4.1. Underlying MQTT Security . 91
7.4.2. Encrypted Sockets . 91
7.4.3. Access Control Lists . 91
8. High Availability . 92
8.1. High Availability for MQTT Servers . 92
8.1.1. MQTT Server HA Clustering (non-normative) . 93
8.1.2. High Availability Cluster . 93
8.1.3. High Availability Cluster with Load Balancer . 94
8.2. Multiple Isolated MQTT Servers (non-normative) . 94
9. Acknowledgements . 96
10. Conformance . 97
© ISO/IEC 2023 – All rights reserved vi

10.1. Conformance Profiles . 97
10.1.1. Sparkplug Edge Node . 97
10.1.2. Sparkplug Host Application . 97
10.1.3. Sparkplug Compliant MQTT Server . 98
10.1.4. Sparkplug Aware MQTT Server. 98
11. Appendix A: Open Source Software (non-normative). 99
11.1. OASIS MQTT Specifications . 99
11.2. Eclipse Foundation IoT Resources. 100
11.3. Eclipse Paho . 100
11.4. Google Protocol Buffers . 100
11.5. Eclipse Kura Google Protocol Buffer Schema . 100
11.6. Raspberry Pi Hardware . 100
12. Appendix B: List of Normative Statements (non-normative) . 100
12.1. Host Applications . 100
12.2. Sparkplug Identifiers . 101
12.3. Report by Exception . 101
12.4. Birth and Death Certificates . 101
12.5. Persistent vs Non-Persistent Connections for Edge Nodes . 101
12.6. Sparkplug Host Application . 101
12.7. Topic Namespace Elements . 101
12.8. namespace Element . 102
12.9. group_id Element . 102
12.10. edge_node_id Element . 102
12.11. device_id Element . 102
12.12. Topic (NBIRTH) . 102
12.13. Payload (NBIRTH) . 102
12.14. Topic (NDATA) . 103
12.15. Payload (NDATA) . 103
12.16. Topic (NDEATH) . 103
12.17. Payload (NDEATH) . 104
12.18. Topic (NCMD) . 104
12.19. Payload (NCMD) . 104
12.20. Topic (DBIRTH) . 104
12.21. Payload (DBIRTH) . 104
12.22. Topic (DDATA) . 105
12.23. Payload (DDATA) . 105
12.24. Topic (DDEATH) . 105
vii © ISO/IEC 2023 – All rights reserved

12.25. Payload (DDEATH) . 105
12.26. Topic DCMD) . 105
12.27. Payload (DCMD) . 105
12.28. Birth Certificate Message (STATE) . 106
12.29. Birth Certificate Topic (STATE) . 106
12.30. Birth Certificate Payload (STATE) . 106
12.31. Death Certificate Message (STATE) . 106
12.32. Death Certificate Topic (STATE) . 106
12.33. Death Certificate Payload (STATE) . 106
12.34. Case Sensitivity in Sparkplug . 107
12.35. Host Application Session Establishment . 107
12.36. Edge Node Session Establishment . 108
12.37. Edge Node Session Termination . 109
12.38. Device Session Establishment . 110
12.39. Device Session Termination . 111
12.40. Sparkplug Host Application Message Ordering . 111
12.41. Primary Host Application STATE in Multiple MQTT Server Topologies . 112
12.42. Sparkplug Host Application Session Establishment . 112
12.43. Sparkplug Host Application Session Termination . 113
12.44. Data Publish . 113
12.45. Commands . 114
12.46. Payload . 115
12.47. Metric . 115
12.48. PropertySet . 116
12.49. PropertyValue . 116
12.50. Quality Codes . 116
12.51. DataSet . 116
12.52. DataSet.DataSetValue . 117
12.53. Template . 117
12.54. Template.Parameter . 118
12.55. NBIRTH . 118
12.56. DBIRTH . 119
12.57. NDATA . 119
12.58. DDATA . 120
12.59. NCMD . 120
12.60. DCMD . 120
12.61. NDEATH . 120
© ISO/IEC 2023 – All rights reserved viii

12.62. DDEATH . 121
12.63. STATE . 121
12.64. Sparkplug Host Application . 122
12.65. Sparkplug Compliant MQTT Server . 122
12.66. Sparkplug Aware MQTT Server . 122
ix © ISO/IEC 2023 – All rights reserved

Revision Number Date Author Description
1.0 5/26/16 Cirrus Link Initial Release
2.1 12/10/16 Cirrus Link Payload B Addition
2.2 10/11/19 Cirrus Link Re-branding for
Eclipse foundation
added TM to
Sparkplug
3.0.0 11/16/22 Eclipse Sparkplug Reorganized to be in
Specification Project AsciiDoc format and
Team to include normative
and non-normative
statements
Sparkplug®, Sparkplug Compatible, and the Sparkplug Logo are trademarks of the Eclipse
Foundation.
1 © ISO/IEC 2023 – All rights reserved

1. Introduction
1.1. Rationale and Use Case
Eclipse Sparkplug provides an open and freely available specification for how Edge of Network
Gateways (Sparkplug Edge Nodes) or native MQTT enabled end devices and Sparkplug Host
Applications communicate bi-directionally within an MQTT Infrastructure. This document
details the structure and implementation requirements for Sparkplug compliant MQTT Client
implementations on both Edge Nodes and Host Applications.
It is recognized that MQTT is used across a wide spectrum of application solution use-cases,
and an almost indefinable variation of network topologies. To that end the Sparkplug
Specification strives to accomplish the three following goals.
1.1.1. Define an MQTT Topic Namespace
As noted many times in this document one of the many attractive features of MQTT is that it
does not specify any required MQTT Topic Namespace within its implementation. This fact has
meant that MQTT has taken a dominant position across a wide spectrum of IoT solutions. The
intent of the Sparkplug Specification is to identify and document a Topic Namespace that is
well thought out and optimized for the SCADA/IIoT solution sector. In addition, Sparkplug
defines a Topic Namespace in such a way that it provides semantics which allow for automatic
discovery and bi-directional communication between MQTT clients in a system.
1.1.2. Define MQTT State Management
One of the unique aspects of MQTT is that it was originally designed for real time SCADA
systems to help reduce data latency over bandwidth limited and outage prone network
infrastructures. These can include cellular, satellite, and other radio based networks. In many
implementations the full benefit of this “Continuous Session Awareness” is not well
understood, or not even implemented. The intent of the Sparkplug Specification is to take full
advantage of MQTT’s native Continuous Session Awareness capability as it applies to real time
SCADA/IIoT solutions.
It is important to note that reducing bandwidth usage and being resilient to network drops is
advantageous on more reliable and high bandwidth networks as well. By reducing the
bandwidth usage, Sparkplug is able to move more data through the network because of its
efficiency. This in turn can reduce network costs.
1.1.3. Define the MQTT Payload
Just as the MQTT Specification does not dictate any particular Topic Namespace, it also does
not dictate any particular payload data encoding. The intent of the Sparkplug Specification is to
define payload encoding mechanisms that remain true to the original, lightweight, bandwidth
efficient, low latency features of MQTT while adding modern encoding schemes targeting the
SCADA/IIoT solution space.
Sparkplug has defined an approach where the Topic Namespace can aid in the determination of
the encoding scheme of any particular payload. Historically there have been two Sparkplug
defined encoding schemes. The first one was the 'Sparkplug A' and the second is 'Sparkplug B'.
Each of these uses a 'first topic token identifier' so Sparkplug Edge Nodes can declare the
payload encoding scheme they are using. These first topic tokens are:
© ISO/IEC 2023 – All rights reserved 2

spAv1.0
spBv1.0
Each token is divided up into three distinct components. These are:
• Sparkplug Identifier
– Always 'sp'
• Payload Encoding Scheme
– Currently 'A' or 'B' but there could be future versions
• Payload Encoding Scheme Version
– Currently v1.0 but denoted in the event that future versions are released
The original 'Sparkplug A' encoding scheme was based on the Eclipse Kura™ open source
Google Protocol Buffer definition. 'Sparkplug B' was released shortly after the release of
Sparkplug A and addressed a number of issues that were present in the A version of the
payload encoding scheme. Due to lack of adoption and the fact that 'Sparkplug B' was made
available shortly after the release of 'A', the Sparkplug A definition has been omitted from this
document and is no longer supported.
The 'Sparkplug B' encoding scheme was created with a richer data model developed with the
feedback of many system integrators and end user customers using MQTT. These additions
included metric timestamp support, complex datatype support, metadata, and other
improvements.
1.1.4. Background
MQTT was originally designed as a message transport for real-time SCADA systems. The MQTT
Specification does not specify the Topic Namespace nor does it define the Payload
representation of the data being published and/or subscribed to. In addition to this, since the
original use-case for MQTT was targeting real-time SCADA, there are mechanisms defined to
provide the state of an MQTT session such that SCADA/Control Human-Machine Interface
(HMI) application can monitor the current state of any MQTT enabled device in the
infrastructure. As with the Topic Namespace and Payload the way state information is
implemented and managed within the MQTT infrastructure is not defined. All of this was
intentional within the original MQTT Specification to provide maximum flexibility across any
solution sector that might choose to use MQTT infrastructures.
But at some point, for MQTT based solutions to be interoperable within a given market sector,
the Topic Namespace, Payload representation, and session state must be defined. The intent
and purpose of the Sparkplug Specification is to define an MQTT Topic Namespace, payload,
and session state management that can be applied generically to the overall IIoT market sector,
but specifically meets the requirements of real-time SCADA/Control HMI solutions. Meeting the
operational requirements for these systems will enable MQTT based infrastructures to provide
more valuable real-time information to Line of Business and MES solution requirements as
well.
The purpose of the Sparkplug Specification is to remain true to the original notion of keeping
the Topic Namespace and message sizes to a minimum while still making the overall message
3  © ISO/IEC 2023 – All rights reserved

transactions and session state management between MQTT enabled devices and MQTT
SCADA/IIoT applications simple, efficient, easy to understand, and implement.
1.2. Intellectual Property Rights
1.2.1. Disclaimers
THIS DOCUMENT IS PROVIDED "AS IS," AND THE COPYRIGHT HOLDERS AND THE ECLIPSE
FOUNDATION MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE
DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH
CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS
OR OTHER RIGHTS.
THE COPYRIGHT HOLDERS AND THE ECLIPSE FOUNDATION WILL NOT BE LIABLE FOR ANY
DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF
THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS
THEREOF.
The name and trademarks of the copyright holders or the Eclipse Foundation may NOT be used
in advertising or publicity pertaining to this document or its contents without specific, written
prior permission. Title to copyright in this document will at all times remain with copyright
holders.
1.3. Organization of the Sparkplug Specification
This specification is split into the following chapters and appendices:
• Chapter 1 - Introduction
• Chapter 2 - Principles
• Chapter 3 - Sparkplug Architecture and Infrastructure Components
• Chapter 4 - Topics and Messages
• Chapter 5 - Operational Behavior
• Chapter 6 - Payloads
• Chapter 7 - Security
• Chapter 8 - High Availability
• Chapter 9 - Acknowledgements
• Chapter 10 - Conformance
• Appendix A - Open Source Software
• Appendix B - List of Normative Statements
© ISO/IEC 2023 – All rights reserved 4

1.4. Terminology
1.4.1. Infrastructure Components
This section details the infrastructure components implemented.

Figure 1 - MQTT SCADA Infrastructure
MQTT Server(s)
Program or device that acts as an intermediary between Clients which publish Application
Messages and Clients which have made Subscriptions[MQTTV5-1.2]. MQTT enabled
infrastructure requires that one or more MQTT Servers are present in the infrastructure. An
MQTT Server must be compatible with the requirements outlined in the Conformance Section.
In addition, it must be sized to properly manage all MQTT message traffic.
One can implement the use (if required) of multiple MQTT servers for redundancy, high
availability, and scalability within any given infrastructure.
Sparkplug Group
Logical or physical group of Edge Nodes that makes sense in the context of a distributed
Sparkplug application. Groups can represent physical groups of Edge Nodes. For example, a
5  © ISO/IEC 2023 – All rights reserved

Sparkplug Group could represent a set of Edge Nodes at a particular location, facility, or along a
specific oil pipeline. Alternatively, a Sparkplug Group could represent group of similar types of
Edge Nodes. For example, it could represent a particular set of like make and models of
embedded gateways. The groups are meant to be defined by the system architects as
appropriate for their particular application.
Sparkplug Edge Node
Any v3.1.1 or v5.0 compliant MQTT Client application that manages an MQTT Session and
provides the physical and/or logical gateway functions required to participate in the Topic
Namespace and Payload definitions described in this document. The Edge Node is responsible
for any local protocol interface to existing devices (PLCs, RTUs, Flow Computers, Sensors, etc.)
and/or any local discrete I/O, and/or any logical internal process variables (PVs).
Sparkplug Device
Physical or logical device that makes sense in the context of a distributed Sparkplug
application. Often times a Sparkplug Device will be a physical PLC, RTU, Flow Computer,
Sensor, etc. However, a Sparkplug device could also represent a logical grouping of data points
as makes sense for the specific Sparkplug Application being developed. For example, it could
represent a set of data points across multiple PLCs that make up a logical device that makes
sense within the context of that application.
MQTT/Sparkplug Enabled Device
Any device, sensor, or hardware that directly connects to MQTT infrastructure using a
compliant MQTT v3.1
...