Data Distribution & Messaging

What do you cover under broker and brokerless industrial data architecture?

Broker vs brokerless industrial data architecture: it is the first decision in any industrial publish-subscribe design.

We make it against latency, participant count and failure behaviour rather than against the library that was prototyped with. Our delivered proof here is an engine-room control system built on a DDS backbone. The engagement is usually one of these shapes:

• The architecture decision on its own. Broker or brokerless, argued against your requirements and recorded with the reasoning.
• A DDS backbone. DDS backbone industrial work from topic and type design through to a running system, including mobility and engine-room cases where redundancy is the point.
• MQTT with real state. MQTT Sparkplug B industrial data distribution, with the birth and death semantics that separate it from plain MQTT.
• A real-time production data pipeline. Machine-to-machine communication and device-to-device industrial data exchange at rates a request-response design cannot hold.
• Bridging control and telemetry. Where a brokerless control layer and a brokered telemetry layer both exist, the mapping between them.

Topics, types, delivery guarantees and failure behaviour, in that order. A publish-subscribe architecture for industrial data is a set of promises about what happens when a subscriber is slow, when a publisher dies, when a participant joins late and wants history, and when a link comes back after being gone. Those promises are configuration in most middleware, and they are often left at the default. We specify them per flow, because a setpoint and a diagnostic log do not want the same reliability, durability or deadline.

We do not commission plants or machines. The distribution layer inside your product or your platform is ours to design and build, and we prove it under participant churn and link loss with your engineers, onshore while that phase is running and remotely afterwards.

When is a broker the right answer?

A broker is often the right answer when the extra hop fits inside the latency budget.

It gives you one place to observe, authorise and buffer, and a topology that a firewall and an IT department can reason about.

The right-hand column is the set of conditions that justify DDS and the configuration work it brings with it: discovery is peer to peer, delivery is direct, and the guarantees are expressed per topic instead of per broker.

What does quality of service decide in a DDS system?

Quality of service decides whether the system degrades or fails.

• Reliability decides whether a lost sample is retransmitted or forgotten.
• Durability decides whether a subscriber that joins late gets history or starts blank.
• Deadline states the rate a subscriber is entitled to expect, which is what turns a slow publisher into a reported fault rather than a silent one.
• Liveliness decides how quickly a dead participant is noticed.
• History decides how much is kept while a subscriber is behind.

These settings cascade: a domain-wide default is a starting point, and the entity closer to the data, the writer or reader QoS, is what actually wins. A domain default applied to every flow either spends resources on traffic that does not need them or starves traffic that does. A lot of the value in a DDS engagement is in that configuration table.

Which DDS implementation is suitable for us?

The trade-offs are the same ones a fieldbus or real-time Ethernet stack faces.

There are a few attributes to consider besides the licence.

The platform question and the licence question are the same question, because the constrained target is usually what narrows the field first. We size both against your volumes and your hardware, then build on whichever you pick. We do not license or resell a DDS implementation ourselves.

Can a DDS system span more than one site?

A DDS system does not span more than one site by default.

DDS discovery is scoped to one multicast domain, which in practice means one site or one VLAN. Participants find each other automatically inside it and not at all outside it.

Crossing that boundary is deliberate network configuration: either a routing service that relays between domains, or a fixed unicast peer list that replaces multicast discovery. Both work. Both add a component that has to be operated, secured and monitored, and both change the failure behaviour of the system, because a link between sites fails differently from how a link inside the same site does. We size that against your topology at the design stage. Where the traffic crossing the boundary is telemetry and not control, a broker on that hop is frequently the better answer, and the bridge between a brokerless control layer and a brokered telemetry layer is one of the shapes listed above.

Where does data distribution sit against the rest of the stack?

Data distribution sits above the network and beside the information model.

• What sits beneath it. The determinism that lets a distribution layer meet a deadline is engineered at the network: gate schedules, drivers, measurement. That work sits with real-time Ethernet.
• What sits beside it. The typed, browsable description of what a machine means, which a supervisory system browses rather than subscribes to, is OPC UA and information modelling.

The three are usually all present. What decides which one owns a given flow is whether the consumer needs to browse it, subscribe to it, or be guaranteed it by a deadline.