Inside MQTT Sparkplug B: Architecting State-Aware HMI Communications

flowchart LR
    A["Edge Node (PLC)"]:::blue -->|NBIRTH / NDEATH| B["MQTT Broker"]:::gray
    B -->|Subscribe| C["SCADA / HMI"]:::green
    B -->|Unified Namespace| D["MES / ERP"]:::purple

    classDef blue fill:#2563eb,color:#ffffff,stroke:#1e40af,stroke-width:2px;
    classDef gray fill:#4b5563,color:#ffffff,stroke:#374151,stroke-width:2px;
    classDef green fill:#16a34a,color:#ffffff,stroke:#166534,stroke-width:2px;
    classDef purple fill:#9333ea,color:#ffffff,stroke:#6b21a8,stroke-width:2px;

Key Takeaways

• Standard MQTT lacks structured data and connection state monitoring, leading to fragmented SCADA implementations.
• MQTT Sparkplug B standardizes the topic namespace, enabling plug-and-play interoperability for HMI systems.
• Birth and Death certificates provide real-time connection state awareness without constant polling.
• Protocol Buffers optimize bandwidth usage while enforcing strict data typing for industrial metrics.

When connecting hundreds of PLCs to a modern SCADA system, engineers frequently encounter a fundamental issue: raw MQTT is too flexible. While the lightweight pub/sub model is excellent for data transmission, the absence of a standardized data structure forces integrators to write custom parsing scripts for every vendor. Furthermore, standard MQTT provides no inherent mechanism to immediately detect when an edge device fails. MQTT Sparkplug B addresses these shortcomings, providing a deterministic framework for industrial HMI applications.

The Problem with Raw MQTT in Industrial Environments

In a standard MQTT setup, a sensor might publish temperature data to a topic like factory/line1/temp with a JSON payload of {"val": 45}. Another vendor’s PLC might use plant/oven/temperature with the payload {"temperature_celsius": 45.0, "status": "ok"}. This inconsistency prevents automatic discovery. The HMI developer must manually map each tag, increasing commissioning time and long-term maintenance overhead.

A more critical issue is state awareness. If a remote terminal unit drops its connection, the MQTT broker stops receiving messages. Without a continuous polling mechanism, the HMI continues to display the last known value indefinitely. Operators might interpret a stale “safe” temperature as current, leading to potentially dangerous operational decisions.

Architecting State Awareness with Sparkplug B

Sparkplug B introduces robust state management through the use of Birth and Death certificates. When an edge node connects to the broker, it publishes an NBIRTH (Node Birth) message containing all its supported tags and data types. The HMI system instantly reads this metadata, enabling true automatic discovery.

To handle disconnections, Sparkplug B leverages the MQTT Last Will and Testament feature. The edge node registers an NDEATH (Node Death) message with the broker upon connection. If the node disconnects unexpectedly, the broker immediately broadcasts the NDEATH message. The HMI instantly marks all associated tags as “stale” or “offline,” alerting the operator without relying on slow polling loops.

flowchart TD
    subgraph edge_network ["Edge Network"]
        plc1["PLC (EoN)"]:::blue
        plc2["Sensor Gateway"]:::blue
    end

    broker["MQTT Broker (Central Hub)"]:::gray

    subgraph enterprise ["Enterprise / SCADA"]
        hmi["Primary HMI Application"]:::green
        historian["Time-Series Historian"]:::purple
    end

    plc1 -->|NBIRTH/DBIRTH Data| broker
    plc2 -->|DDEATH/NDEATH State| broker
    broker -->|Push Updates| hmi
    broker -->|Push Updates| historian

    classDef blue fill:#2563eb,color:#ffffff,stroke:#1e40af,stroke-width:2px;
    classDef gray fill:#4b5563,color:#ffffff,stroke:#374151,stroke-width:2px;
    classDef green fill:#16a34a,color:#ffffff,stroke:#166534,stroke-width:2px;
    classDef purple fill:#9333ea,color:#ffffff,stroke:#6b21a8,stroke-width:2px;

Structured Topic Namespace and Payloads

Sparkplug B dictates a rigid topic structure: spBv1.0/[Group ID]/[Message Type]/[Edge Node ID]/[Device ID]. This uniformity guarantees that any compliant application knows exactly where to find specific data points and what the message type implies (e.g., data update, birth certificate, command).

Instead of verbose JSON or CSV, Sparkplug B utilizes Google Protocol Buffers for the payload. This binary format significantly reduces bandwidth consumption, which is highly advantageous for cellular or low-bandwidth networks. Additionally, the payload enforcing strict data typing ensures that a floating-point temperature value cannot be accidentally parsed as a string by the HMI.

Comparing MQTT Protocols for HMI

Conclusion

Adopting MQTT Sparkplug B transitions the HMI architecture from a brittle, point-to-point configuration into a scalable Unified Namespace. By enforcing a standardized payload, strict topic hierarchy, and native state management, automation teams can drastically reduce integration time and eliminate stale data artifacts on operator displays.

FAQ

Why use Protocol Buffers instead of JSON for the payload?

Protocol Buffers serialize data into a compact binary format, drastically reducing payload size compared to plain text JSON. This efficiency is critical for high-frequency telemetry over restricted networks.

Can standard MQTT clients read Sparkplug B messages?

Any MQTT client can subscribe to the topics, but extracting the data requires a Protocol Buffers decoder aware of the Sparkplug B schema.

Ready to upgrade your control room infrastructure? Explore our highly optimized HMI templates and PLC scripts in the AutomationView Store to accelerate your next deployment.