The convergence of Operational Technology (OT) and Informational Technology (IT) has become a strategic imperative for organizations aiming to unlock efficiency, innovation and competitiveness. This confluence necessitates a seamless and secure flow of data between the physical world of industrial equipment and the digital information world of enterprise systems. As organizations grapple with this integration challenge, the choice of a standardized software communication protocol becomes paramount. This blog explores and positions two popular middleware standards, DDS™ (Data Distribution Service) and MQTT (Message Queuing Telemetry Transport), shedding light on their architectures, performance, scalability, reliability, and protocols. This blog is a quick summary of the more in-depth comparison found in the recent RTI technical paper, IIoT Protocols: Comparing DDS and MQTT.
Today, architecture serves as the backbone of any software development project, defining its structure, organization and functionality. As a result, architects must first evaluate and understand all system requirements and determine which type of network architecture – centralized, decentralized, or distributed – meets the needs of the system. Once the type of architecture is understood, a communication model for distributing applications can be evaluated. DDS and MQTT present two distinct communication approaches: data-centric (DDS) and message-centric (MQTT).
DDS uses the RTPS protocol, which is a data-centric publish-subscribe model that allows participants to communicate directly without the need for a centralized broker. Critical communication is controlled by fine-grained Quality of Service (QoS), which introduces the concept of data centricity – this approach delivers flexibility in data distribution and discovery. DDS is designed for constant change, providing a robust foundation for distributed, scalable, fault-tolerant, deterministic and performant systems.
By contrast, the MQTT protocol is message-centric and follows a lightweight publish-subscribe model with a broker-based approach. MQTT is well-suited for resource-constrained devices and unreliable network environments, due to its lightweight design. However, it may not be ideal for applications with high data throughput or strict latency requirements. MQTT allows for configuration of Quality of Service (QoS), determining the reliability of messages, but relies on a centralized broker for message distribution.
Performance matters in distributed computing systems, particularly for complex Industrial IoT (IIoT) applications that require low latency, high efficiency, and reliability. Because it is specifically tailored for high-performance and real-time data exchange, DDS supports efficient data filtering, multicast communication and reliable delivery mechanisms. Crucially, its fine-grained control over QoS parameters makes it especially suitable for applications with stringent performance requirements.
MQTT, on the other hand, is optimized for low-bandwidth and low-latency environments. Its simple header structure results in smaller message sizes and reduced network overhead, making it highly suitable for resource-constrained scenarios. However, it may not meet the demands of applications requiring high data throughput or real-time performance.
On the scalability front, it’s fair to say that scalability is vital for distributed systems that need to adapt to changing demands and technological advancements. DDS, operating in a distributed manner, inherently supports scalability and is able to accommodate a large number of participants. Its peer-to-peer communication model ensures efficient data distribution, making it suitable for complex and dynamic industrial automation environments.
MQTT is also scalable, handling a large number of publishers and subscribers. However, its scalability can be limited by the capacity of the centralized broker, potentially introducing bottlenecks.
Another important factor is reliability, which is a cornerstone of distributed systems, ensuring data integrity, system availability and business continuity. DDS significantly enhances system reliability with robust communication features, including advanced QoS settings, reliable message delivery, data persistence, fault tolerance, redundancy and failover mechanisms. These features make DDS a trusted choice for mission-critical applications.
Though MQTT offers QoS levels for message delivery, it also requires careful configuration to achieve robust performance. Factors such as network stability, broker reliability, and chosen QoS levels influence MQTT's reliability.
On the subject of Data Topics, both DDS and MQTT leverage Topics to facilitate communication and coordination among distributed components. However, while both use Topics to categorize and organize data, they differ in their implementations and intended use cases. To summarize:
- DDS Topics = Structured Data Communication. In DDS, a Topic represents a specific type of data exchanged within the system. It defines the format or structure of the data, acting as a communication channel for data distribution. Topics are associated with specific data types, enabling efficient and selective real-time communication in distributed systems.
- MQTT Topics = Information Organization. MQTT Topics serve as logical channels or subjects to which messages are published and from which messages are subscribed. Represented as hierarchical strings, topics categorize and organize messages in a tree-like structure. Unlike DDS, MQTT topics focus solely on information organization, lacking the detailed structuring of message content.
In modern computing environments, standards and interoperability form the foundation for efficient data exchange between diverse systems and devices. DDS and MQTT each approach this aspect differently, aligning with their respective design philosophies.
- DDS: Focused on Interoperability. DDS, which is managed by the Object Management Group® (OMG®), emphasizes interoperability and standardized APIs. The DDS standard ensures compatibility between different vendor implementations, fostering openness and modularity. It provides a wider range of QoS policies, supporting integration with various programming languages.
- MQTT: Widespread Adoption, Varied Implementations. MQTT, an OASIS® standard, boasts a large user base and diverse client libraries and broker implementations. While this contributes to interoperability across different platforms, the variability in MQTT broker implementations and security features may pose challenges for seamless integration.
Conclusion: Pick the Protocol That’s Right for Your Use Case
In the pursuit of IIoT excellence, the choice between DDS and MQTT becomes pivotal. Each protocol excels in specific domains, offering unique advantages that cater to the diverse needs of modern organizations. In making the choice between DDS and MQTT, the type of architecture must first be understood, then the right communication model for distributing applications can be evaluated and implemented.
With its data-centric approach, DDS is the proven standard of choice for applications that require real-time control, deterministic communication, complex data modeling, reliability and advanced QoS control. DDS maintains high performance, regardless of system size. Its optimal performance is evident in expansive, mission-critical systems, where precision and reliability are paramount and non-negotiable.
And as a versatile protocol, MQTT is ideal for use cases involving data aggregation, IoT sensor networks, remote monitoring and cloud integration, as well as scenarios where broad device connectivity is a priority. Its lightweight design and simplicity make it an excellent choice for quick integration and efficient communication.
As organizations navigate the complex landscape of IIoT, it is vital to align the choice of communications technology with specific use case requirements. Factors such as latency, reliability, scalability, data complexity and the need for real-time control, play a crucial role in determining whether DDS or MQTT is optimal for the specific system. The right choice enables system designers to harness the full potential of IT/OT convergence, driving innovation, efficiency and competitiveness in their operations.
About the author:
Mark Carrier is a Principal Engineer at RTI. As a technologist with over 25 years of experience, Mark brings a combination of deep business and technical expertise to help customers identify and solve their challenges while driving sales. Leading RTI’s Industrial Automation efforts, Mark is focused on building a complete ecosystem, bringing alignment across the organization and identifying ways the company can grow and cultivate in the market.
In 2016 Mark was named a Smart Industry 50 Innovator on the Leading Edge of Digital Transformation. Mark was the architect of the world’s first autonomous drilling platform and was also a key contributor to ION Geophysical's 80,000 channel count seismic recorder which, at the time, was the largest recorder built.
Prior to joining RTI, Mark was the System Architect and Technical Manager for National Oilwell Varco and the System Architect of the Energy Drilling Automation Platform for Ensign Energy. He also spent eight years focused on research and development for embedded systems and Digital Signal Processors, and served five years at MIT’s Draper Laboratory. Mark graduated from the Indiana University of Pennsylvania with a BS in Computer Science.
Posts by Tag
- Connext DDS Suite
- Standards & Consortia
- News & Events
- Aerospace & Defense
- Culture & Careers
- Connext DDS Secure
- Connext DDS Tools
- Connext DDS Pro
- Energy Systems
- Military Avionics
- Connext DDS Micro
- ROS 2
- Connext DDS Cert
- Connectivity Technology
- Oil & Gas
- Connext Conference
- Connext DDS
- RTI Labs
- Case + Code
- FACE Technical Standard
- Edge Computing
- Other Markets
- ISO 26262
- National Instruments
- Tech Talks