MQTT architecture
MQTT was created in 1999 by Andy Stanford-Clark and Arlen Nipper. MQTT 3.1.1 is ISO/IEC 20922; MQTT 5 is an OASIS standard. Publishers send messages to a broker, which distributes them to matching subscribers. A client can play both roles.
Topics use slash-separated levels; + matches one level and # the remaining levels under the applicable subscription rules. Topic organisation and access permissions are application decisions.
Delivery and state
QoS 0 is at most once, QoS 1 at least once and QoS 2 exactly once for the relevant MQTT delivery exchange. These do not guarantee exactly-once execution of a business action end to end. The selected QoS must match the application and profile.
A retained message is the broker's last retained publication for a topic, not automatically its last ordinary publication. It can be stale. Last Will is registered on connection and published under the relevant disconnection conditions. Detection depends on transport/Keep Alive and MQTT 5 Will Delay/session rules.
MQTT 5 and protection
MQTT 5 adds properties, shared subscriptions, topic aliases, message expiry and more detailed reason codes. Enhanced Authentication is extensible and can support SASL-style exchanges when both endpoints implement them.
TLS protects supported client-broker connections; authentication and topic ACLs restrict operations. A password or token does not itself encrypt traffic. Broker capacity, persistence, remote access and certificate management must be engineered.
Sparkplug B semantics
Sparkplug specifies a topic namespace, typed Protobuf metrics and state management. Topics follow spBv1.0/group/message-type/edge-node with a device component where applicable. NBIRTH/DBIRTH establish node/device data models; NDATA/DDATA carry changes; NDEATH/DDEATH indicate loss; NCMD/DCMD carry supported commands. Primary Host state contributes to coordinated recovery.
Aliases can reduce later payload size only after a valid BIRTH model is known. Timestamps and properties matter. is_null/is_transient are specific protocol fields, not universal substitutes for IEC quality descriptors. QoS and retained settings follow each Sparkplug message type, not a blanket QoS 1 rule.
Integration and comparison
A gateway can read Modbus or telecontrol data and publish Sparkplug metrics. Consumers need compatible MQTT and Sparkplug features. Not every cloud IoT service implements a full broker suitable for Sparkplug; topics, subscriptions, LWT and retained behaviour may require an adapter.
IEC 104 k is the window of unacknowledged I-frames on a connection, not the number of consumers. Both architectures have implementation-dependent capacity. Sparkplug has a Technology Compatibility Kit for conformity checks; it is not a universal suitability assurance for protection functions.
Practical checks
Test BIRTH, reconnect, DEATH, aliases and state recovery, as well as stale retained data and message loss. Measure publication rates, payloads and subscriber load before deciding on clustering. MQTT/Sparkplug can complement IEC 104/61850 for integration and analytics; control suitability depends on timing, failure and application requirements.
