MQTT Payload Design for IIoT: JSON vs Sparkplug B

MQTT is just the transport (the truck). The payload is the cargo. If you load the truck by throwing boxes randomly (malformed JSONs), your destination system (SCADA, MES, Cloud) will become an unsustainable chaos of parsers.

For serious IIoT systems, there are two paths: Structured JSON or Sparkplug B.

1. The Cost of “Sloppy” JSON

It is tempting to send this from an ESP32:

{"temp": 24, "status": "ok"}

But when you have 100 machines, what does “temp” mean? Is it the motor or the cabinet? Is it Celsius or Fahrenheit? When was it measured?

The Minimum Viable Structure (JSON)

If you are going to use JSON, enforce a strict data contract. I recommend following the Unified Namespace (UNS) pattern for topics and a payload with metadata:

Topic: enterprise/plant1/line4/machine2/telemetry

Payload:

{
  "ts": 1699982000000,    // ISO Timestamp or Epoch (Mandatory)
  "values": {
    "motor_temp_c": 45.2, // Unit in name
    "vibration_mm_s": 1.2
  },
  "q": 192,               // Quality (OPC UA style: Good)
  "seq": 1042             // Sequence to detect packet loss
}

2. Sparkplug B: The Industrial Standard

Sparkplug B is not another protocol. It is a specification on how to use MQTT so industrial devices understand each other automatically. It defines:

1. Rigid Topics: spBv1.0/GROUP/MESSAGE/NODE/DEVICE
2. State Management: The famous “Birth Certificate” (NBIRTH) and “Death Certificate” (NDEATH). The SCADA knows INSTANTLY if the PLC disconnected, thanks to MQTT’s Last Will and Testament (LWT) mechanism.
3. Compression: Uses Google Protobuf. The payload is binary, weighing 10 times less than JSON. Ideal for cellular networks (4G/LTE).

When to use Sparkplug B?

• ✅ You have a modern SCADA (Ignition, FrameworX) that supports it natively.
• ✅ You need “Plug and Play”: The SCADA discovers tags automatically when the PLC connects.
• ✅ Bandwidth is critical (Satellite, Radio, 4G).

When to use JSON?

• ✅ Your destination is a Web App, direct Grafana Dashboard, or AWS IoT Core.
• ✅ You want to debug by reading messages with the human eye.
• ✅ You don’t have a “Primary Host” (central SCADA) managing state.

3. “Report by Exception” (RBE) Strategy

Don’t send data just because every 1 second. That saturates the broker and costs a fortune in the cloud. Use RBE: Only publish if the value changed beyond a deadband or if a max time (heartbeat) passed.

• Temperature: Changes > 0.5°C -> Publish.
• State: Changes from 0 to 1 -> Publish Immediately (Priority).

Conclusion

• If you are building a prototype or web dashboard: Structured JSON (with Timestamp and Quality).
• If you are integrating a full plant with a central SCADA: Sparkplug B.

Don’t invent your own format. Interoperability pays the bills.