MQTT vs DDS: Broker'lı ve Broker'sız Endüstriyel Mesajlaşma

MQTT vs DDS sorusu; bazı sistemlerin yerel ağda mikrosaniye düzeyinde determinizme, diğerlerinin ise birçok sahadan buluta veri taşımaya ihtiyaç duyduğu robotik, otomotiv ve endüstriyel otomasyon projelerinde karşımıza çıkar. İkisi de publish/subscribe modelini kullanır; ancak MQTT merkezi bir broker'a dayanırken DDS katılımcıların birbirini keşfetmesine ve verileri doğrudan paylaşmasına olanak tanır. Bu rehber mimarileri, gerçek zamanlı garantileri ve tipik kurulumları karşılaştırıyor ve bir bulut servisine broker'lı MQTT bağlantısının nerede pratik bir seçim olduğunu gösteriyor.

Publish/Subscribe'ın İki Felsefesi

MQTT broker'lıdır. Her istemci bir broker'a bağlantı açar, topic'lere publish eder ve topic filtrelerine subscribe olur; her mesajı broker yönlendirir. İstemciler birbirinden haberdar değildir. Bu, ağ topolojisini basitleştirir: cihazların yalnızca iyi bilinen tek bir uç noktaya giden bir bağlantıya ihtiyacı vardır ve bu NAT, firewall'lar ve hücresel ağlar üzerinden sorunsuz çalışır. Broker'ın rolünü hatırlamak için bir MQTT broker'ın ne yaptığı yazısına bakın.

DDS (Data Distribution Service), veri merkezli ve broker'sız publish/subscribe için bir Object Management Group standardıdır. Bir DDS domain'indeki katılımcılar, genellikle yerel ağda UDP multicast üzerinden birbirini keşfeder ve DDSI-RTPS hat protokolünü kullanarak verileri doğrudan paylaşır. Topic'ler, IDL ile tanımlanmış bir veri yapısıyla güçlü şekilde tiplendirilmiştir ve her reader ile writer, DDS'in otomatik olarak eşleştirdiği quality-of-service politikaları bildirir. DDS, ROS 2'nin altındaki middleware'dir ve savunma, havacılık, tıbbi cihazlar ile bazı otomotiv ve enerji sistemlerinde yaygındır.

Bir Bakışta MQTT vs DDS

Mimari: Broker vs Veri Yolu

MQTT'deki broker hem bir güç hem de bir maliyettir. İstemcileri doğrulamak, kotaları uygulamak, her topic'i görmek ve bulutu bağlamak için size tek bir yer sunar. Aynı zamanda bir ağ atlaması ekler ve erişilebilir olması gereken bir bileşendir. Yönetilen bir broker bu erişilebilirlik yükünü sağlayıcıya devreder.

DDS aradaki atlamayı ortadan kaldırır. Writer'lar eşleşen reader'lara doğrudan gönderir; bu da gecikmeyi azaltır ve yerel ağda merkezi bir bağımlılıktan kaçınır. Bedeli karmaşıklıktır: keşif trafiği katılımcı ve uç nokta sayısıyla birlikte büyür, ağda multicast'e izin verilmesi gerekir ve alt ağları, NAT'ı veya interneti aşmak ek yönlendirme servisleri gerektirir. DDS bir robotun, bir aracın ya da bir hücrenin içinde mükemmeldir; yüzlerce uzak sahaya yayıldığında ise hantallaşır.

Gerçek Zamanlı Garantiler ve QoS

DDS QoS'u, MQTT QoS'undan çok daha zengindir. Bir DDS writer; bir topic'i en az 10 milisaniyede bir güncelleyeceğini (deadline), sonradan katılanların son N örneği alması gerektiğini (durability ve history), bir writer sessizleştiğinde reader'ın bilgilendirilmesi gerektiğini (liveliness) ya da yalnızca en yüksek güce sahip writer'ın dinlenmesi gerektiğini (yedekli sensörler için faydalı olan ownership) bildirebilir. DDS uyumlu reader ve writer'ları eşleştirir ve uyumsuzlukları raporlar. UDP ve paylaşımlı bellek taşımalarıyla birleştiğinde bu, DDS'i kontrol döngüleri ve sensör füzyonu için uygun kılar.

MQTT ise işi daha basit tutar. QoS 0, 1 ve 2 teslim garantilerini tanımlar, retained message'lar sonradan katılanlara son değeri verir, kalıcı oturumlar çevrimdışı subscriber'lar için tamponlama yapar ve Last Will beklenmedik bağlantı kopmalarını bildirir. MQTT 5, eskimiş komutları atmaya yardımcı olan mesaj süresi dolumunu (message expiry) ekler. Bunlar, telemetri ve denetim uygulamalarının çoğunun gerçekte ihtiyaç duyduğu özelliklerdir. Hatırlamak için MQTT QoS seviyeleri yazısına bakın.

Hiçbir protokol tek başına bir sistemi katı gerçek zamanlı (hard real-time) yapmaz. Determinizm aynı zamanda işletim sistemine, ağa ve donanıma da bağlıdır. Ancak DDS size zamanlama davranışını tanımlamak için gereken kelime dağarcığını verir; MQTT ise bunu denemez bile.

Robotik vs IIoT

Robotikte ROS 2, DDS'i varsayılan hale getirdi. Aynı robottaki veya yerel ağdaki node'lar sensör verilerini, dönüşümleri ve komutları düşük gecikmeyle birbirlerine publish eder ve keşif sayesinde node'ları herhangi bir sırayla başlatabilirsiniz. Bu, DDS'in tam olarak tasarlandığı işi yapmasıdır.

Endüstriyel IoT'de ise gereksinimler farklıdır. Verilerin birçok tesisteki PLC'lerden, makinelerden ve gateway'lerden denetim sistemlerine, historian'lara ve bulut uygulamalarına; firewall'lar ve WAN bağlantıları üzerinden akması gerekir. Entegratörler ISA-95 seviyelerine göre düzenlenmiş bir Unified Namespace bekler ve birçok cihaz zaten MQTT veya Sparkplug B konuşur. Burada broker bir avantajdır, çünkü her sahaya giden tek bir bağlantı ve verileri aramak için tek bir yer sağlar. MQTT Sparkplug B ve Unified Namespace rehberi bu modeli açıklıyor.

DDS'ten MQTT'ye Köprü: Bir ROS 2 Örneği

Yaygın desen, makinenin içinde DDS ve dışarıya doğru MQTT kullanmaktır. Küçük bir ROS 2 node'u yerel DDS topic'lerine subscribe olur ve seçilmiş, örnekleme oranı düşürülmüş verileri bir MQTT broker'a publish eder. Aşağıdaki örnek, bir robotun batarya durumunu ConnectMQ'ya iletir.

import json
import ssl
import time

import paho.mqtt.client as mqtt
import rclpy
from rclpy.node import Node
from sensor_msgs.msg import BatteryState


class BatteryToMqtt(Node):
    def __init__(self):
        super().__init__("battery_to_mqtt")
        self.last_sent = 0.0
        self.mqtt = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                                client_id="YOUR_CLIENT_ID")
        self.mqtt.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
        self.mqtt.tls_set(cert_reqs=ssl.CERT_REQUIRED)
        self.mqtt.will_set("connectmq/site1/fleet/robot7/status", "offline",
                           qos=1, retain=True)
        self.mqtt.connect("broker.connectmq.com", 8883, keepalive=30)
        self.mqtt.loop_start()
        self.mqtt.publish("connectmq/site1/fleet/robot7/status", "online",
                          qos=1, retain=True)
        self.create_subscription(BatteryState, "/battery_state",
                                 self.on_battery, 10)

    def on_battery(self, msg: BatteryState):
        now = time.time()
        if now - self.last_sent < 5.0:  # 5 saniyede bir mesaja düşür
            return
        self.last_sent = now
        payload = json.dumps({
            "voltage": round(msg.voltage, 2),
            "percentage": round(msg.percentage, 3),
            "ts": int(now),
        })
        self.mqtt.publish("connectmq/site1/fleet/robot7/battery", payload,
                          qos=1, retain=True)


def main():
    rclpy.init()
    node = BatteryToMqtt()
    try:
        rclpy.spin(node)
    finally:
        node.mqtt.loop_stop()
        node.destroy_node()
        rclpy.shutdown()


if __name__ == "__main__":
    main()

İki tasarım tercihi bu köprüyü sağlam kılar. Birincisi örnekleme oranını düşürür, çünkü DDS topic'leri bir WAN üzerinden taşınması anlamsız olan hızlarda çalışabilir. İkincisi retained bir Last Will kullanır; böylece köprü çökse bile filo dashboard'ları robotun çevrimdışı olduğunu görür. Kimlik bilgileri olmadan hızlıca denemek için benzersiz bir client ID ile 1883 portuna bağlanın ve ücretsiz herkese açık MQTT broker'da connectmq/demo/<random-id>/ önekini kullanın.

Karar Kontrol Listesi

1. Bileşenlerin aynı makinede veya LAN'da, katı zamanlama QoS'u ile milisaniyeler içinde veri paylaşması gerekiyor mu? Orada DDS kullanın.
2. Birçok sahadan, NAT veya hücresel ağ üzerinden buluta veri taşımanız mı gerekiyor? Bu yol için MQTT kullanın.
3. Cihazlarınız mikrodenetleyiciler, PLC'ler veya ticari gateway'ler mi? Büyük olasılıkla MQTT konuşuyorlardır.
4. ROS 2 üzerinde mi geliştiriyorsunuz? DDS'i robotta tutun ve seçili topic'leri MQTT'ye köprüleyin.
5. Unified Namespace veya Sparkplug B'ye mi ihtiyacınız var? Bu bir MQTT ekosistemidir.
6. İstemcileri doğrulamak, izlemek ve sınırlamak için tek bir yer mi istiyorsunuz? Bu bir broker'ın işidir.

Bulut MQTT Broker Nereye Oturur?

DDS dünyasının dashboard'larla, historian'larla, mobil uygulamalarla ve diğer sahalarla konuşması gerektiğinde bulut MQTT broker pratik buluşma noktasıdır. ConnectMQ; TLS üzerinden MQTT 3.1.1 ve 5.0 sunar, ISA-95 ve Unified Namespace topic'lerini algılar, Sparkplug B'yi çözümler ve portalında cihazları ISA-95 seviyesine göre gösterir. Kendisi DDS konuşmaz; bu nedenle yukarıdaki gibi bir köprü node'u dürüst entegrasyon yoludur. Daha derin endüstriyel bağlam için MQTT ile endüstriyel IoT rehberini, protokol temelleri için ise MQTT eğitimini okuyun.

ConnectMQ ile Başlayın

Determinizmin önemli olduğu yerde DDS'i koruyun, işletmenin geri kalanının ihtiyaç duyduğu verileri ise yönetilen bir broker'a gönderin. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun, köprü node'unuzu çalıştırın ve topic'lerin canlı gezginde belirmesini izleyin.

Sık Sorulan Sorular

DDS, MQTT'den daha mı hızlı?

Yerel ağda DDS'in gecikmesi genellikle daha düşüktür, çünkü veriler bir broker atlaması olmadan doğrudan writer'dan reader'a gider. WAN ve internet bağlantılarında bu avantaj kaybolur ve MQTT'yi yönlendirmek daha kolaydır.

DDS internet üzerinden çalışabilir mi?

Tek başına kolay değil, çünkü keşif yerel multicast'e ve doğrudan eş adreslemesine dayanır. Yönlendirme servisleri ve relay'ler mevcuttur, ancak çoğu ekip bunun yerine seçili verileri MQTT'ye köprüler.

ROS 2 MQTT'yi destekliyor mu?

ROS 2 varsayılan olarak DDS kullanır. Onu bir köprü node'u ile MQTT'ye bağlayabilirsiniz; bu bir topluluk paketi ya da bu makaledeki örnek gibi küçük, özel bir node olabilir.

IIoT için DDS mi yoksa MQTT mi kullanmalıyım?

Tesisten buluta telemetri, denetim verileri ve Unified Namespace mimarileri için MQTT genellikle daha uygundur. DDS ise makinelerin ve hücrelerin içindeki gerçek zamanlı kontrole uygundur.