MQTT / ISO-IEC 20922

Overview

MQTT, published internationally as ISO/IEC 20922, is the lightweight publish/subscribe protocol that carries most IoT and OT telemetry. Instead of devices talking to each other directly, publishers send messages to named topics on a broker and subscribers receive the topics they care about, which keeps producers and consumers decoupled and works well over constrained or intermittent links. ControlBird speaks MQTT as both a client and an embedded broker, so it fits whether a site already runs a central broker or needs ControlBird to be one. Sparkplug B, the convention that layers stateful birth and death certificates and a structured metric model on top of MQTT, is on the roadmap and not yet available; the page states that plainly so it can be checked against a tender rather than assumed.

Key requirements

Publish/subscribe through a broker

Decouple producers from consumers: clients publish to and subscribe from named topics on a broker, rather than holding direct point-to-point connections, so devices can come and go without reconfiguring the others.

Quality-of-service delivery

Offer the three delivery guarantees the standard defines, from fire-and-forget through at-least-once to exactly-once, and retained messages so a newly connected subscriber immediately receives the last known value on a topic.

Topic namespace and wildcards

Organise data under a hierarchical topic namespace and let subscribers match it with single-level (+) and multi-level (#) wildcards, so a consumer can take a whole branch of topics without enumerating each one.

Secured, authenticated connections

Protect the transport with TLS and identify clients to the broker, so telemetry is encrypted in transit and only authorised clients can publish or subscribe.

How ControlBird aligns

Acts as both client and embedded broker

ControlBird connects out to external MQTT brokers to publish and subscribe, and can host its own embedded broker for devices to connect to. It can sit on either side of an integration, so it fits whether the existing system is the broker or a client of one.

Full quality-of-service range

Mappings support all three QoS levels (at most once, at least once, exactly once), the retained flag for publishes, and clean-session control, each selectable per connection and per mapping to match how critical the topic is.

Topic-to-entity mapping

Topics are bound to entity fields in either direction, with single-level (+) and multi-level (#) wildcards on subscriptions. Payloads are handled as plain text, JSON with path extraction to pull a value out of a larger message, or binary with configurable byte order, so the same broker can feed simple and structured topics alike.

Secured connections

Both the client and the embedded broker support TLS, with username and password or client-certificate identities, so telemetry is encrypted in transit and the broker only accepts authorised clients.

Scope you should plan around

Sparkplug B birth and death certificates and its metric model are on the roadmap and not implemented today, and a Last-Will and Testament message is not yet configurable. Integrations that depend on Sparkplug B semantics should be planned around plain MQTT topics for now. We state this up front so it can be confirmed against a tender’s requirements rather than discovered later.