MQTT and Sparkplug: choosing the data model

Application guide · 13 September 2026. Illustrative project guidance; verify device, version and license compatibility separately.

Separate transport from the data model

Connecting to a broker does not mean that systems interpret messages consistently. Define types, units, source identity and timestamps in the message contract. Plain MQTT allows a project-specific payload, but that flexibility creates responsibility for schema changes and compatibility across all consumers.

What does Sparkplug add?

The Eclipse Sparkplug specification defines a topic namespace, payload and session-state rules for MQTT. This gives compatible systems a shared interpretation. Not every MQTT product implements Sparkplug. Verify the supported profile and version for the actual source and consumer; MQTT support alone is not proof of Sparkplug compatibility.

Design state and freshness

Show whether a last-known value is still valid. Define dashboard and storage behavior when a source goes offline. Test old messages reappearing, data received after reconnection and out-of-order delivery. Restrict topic permissions by producer and consumer role instead of granting blanket access.

Choose the product after the data requirement

Kepware IoT Gateway offers MQTT and HTTP/REST paths for industrial data. Evaluate the OPC Router MQTT plug-in to connect broker data with wider integration workflows. Compare them against payload design, direction, transformation and operational requirements. Check the exact product version and plug-in license for each required feature.

Review with your team

  • Payload schema and units defined.
  • Topic permissions separated.
  • Offline state and stale data tested.
  • Sparkplug compatibility verified at each endpoint when required.

Official sources and further reading

Continue planning with the project tools