Endüstriyel bir MQTT broker, tesis verinizin merkezinde yer alır: her gateway ona yayın yapar, her SCADA, MES, historian ve pano da ondan okur. Bu rehberde, fabrika sahasında ayakta kalan bir broker'ı yalnızca protokol testlerini geçen bir broker'dan ayıran yetenekleri öğrenecek ve değerlendirdiğiniz herhangi bir broker'da en önemli davranışları kontrol eden kısa bir Python betiği çalıştıracaksınız.
Endüstriyel Kullanım Gereksinimleri Neden Değiştirir?
Standartlara uygun her broker bir mesajı yayıncıdan aboneye yönlendirebilir. Tüketici odaklı bir IoT uygulamasında bu çoğu zaman yeterlidir. Bir tesiste ise broker mesajdan fazlasını taşır. Durumu taşır: hangi makinelerin çevrim içi olduğunu, her tag'in güncel değerini ve bir okumanın taze mi yoksa bayat mı olduğunu. Operatörler kararlarını bu duruma göre verir; bazı mimarilerde SCADA sistemleri alarmları bu durumdan üretir.
Endüstriyel trafik de farklı görünür. Binlerce tag düzensiz hızlarda değişir, kısa bir ağ kesintisinin ardından koca bir hat aynı anda yeniden bağlanabilir ve payload'lar okunabilir JSON yerine Sparkplug B protobuf olabilir. Client'lar, kimsenin dokunmak istemediği gateway'lerde yıllarca yaşar. Hobi projesi için gayet iyi olan bir broker bu koşullarda zorlanabilir. Broker'ın rolüne yeniyseniz önce MQTT broker'ın ne olduğunu okuyun.
Endüstriyel Bir MQTT Broker'ın Temel Yetenekleri
| Yetenek | Tesiste neden önemli | Neyi kontrol etmeli |
|---|---|---|
| MQTT 3.1.1 ve 5.0 | Eski gateway'ler ve yeni client'lar bir arada yaşamalı | İki sürümün de aynı endpoint'te kabul edilmesi |
| Retained message'lar | Yeni aboneler güncel duruma anında ihtiyaç duyar | Abone olununca retained değerlerin iletilmesi |
| Kalıcı oturumlar | Gateway'ler QoS 1 verisini kaybetmeden yeniden bağlanır | Session expiry'ye uyulması, kuyruktaki mesajların iletilmesi |
| Last will and testament | Çevrim dışı gateway'ler otomatik işaretlenmeli | Düzensiz kopmada will mesajının yayımlanması |
| Sparkplug B desteği | Protobuf payload'lar çözülmeden anlaşılmaz | Payload'ların araçlarda okunabilmesi |
| ISA-95 / UNS yapısı | Veri tesis hiyerarşisine göre bulunabilmeli | Topic ağacının saha, alan, hatta göre gezilebilmesi |
| TLS ve kimlik doğrulama | Tesis verisi ağ bölgeleri arasında geçer | 8883'te TLS, client başına kimlik bilgileri |
| Kötüye kullanım koruması | Hatalı davranan bir gateway diğerlerine zarar vermemeli | Kotalar, flood koruması, giriş kilitleme |
| Görünürlük | Devreye alma ve sorun giderme veriyi görmeyi gerektirir | Canlı topic explorer, bağlantı durumu, uyarılar |
| İşletim modeli | Birinin yamalaması ve izlemesi gerekir | Net sahiplik, yönetilen veya kendi barındırılan |
Sparkplug desteği
Sparkplug B, endüstriyel MQTT için topic yapısını, birth ve death sertifikalarını ve bir protobuf payload'ı tanımlar. Kesin konuşmak gerekirse broker'ın Sparkplug'ı anlaması gerekmez: Sparkplug client tarafı bir spesifikasyondur ve retained message, QoS ve will destekleyen her MQTT 3.1.1 broker onu taşıyabilir. Ancak pratikte Sparkplug payload'larını çözebilen bir broker saatler kazandırır. Devreye alma sırasında bir yığın ikili veri yerine Temperature = 72.4 görmek istersiniz. İçinde ne olduğunu anlamak için Sparkplug B payload rehberimizi okuyun.
Daha da faydalı bir adım yeniden yayımlamadır. spBv1.0/factory1/DDATA/line1/cnc1 gibi Sparkplug topic'leri kompakttır ama IT tüketicileri için kullanışlı değildir. Bu metrikleri connectmq/factory1/production/line1/cnc1/telemetry gibi ISA-95 topic'lerine yeniden yayımlayabilen bir broker, Sparkplug tabanlı SCADA'nın ve JSON odaklı iş uygulamalarının aynı veriyi kullanmasını sağlar. İki model arasındaki ilişki Sparkplug B ve Unified Namespace yazımızda ele alınıyor.
Retained durum ve oturumlar
Bir Unified Namespace ancak saat 9:00'da açılan bir pano her makinenin 9:00'daki durumunu görebiliyorsa çalışır; her makinenin bir sonraki değişikliğini beklemeden. Retained message'ların sağladığı şey budur. Makul bir session expiry ile kalıcı oturumlar diğer yaygın arızaya karşı korur: kısa bir ağ kopmasından sonra yeniden bağlanan bir gateway'in arada aboneliklerine yayımlanan her şeyi kaçırması. Sparkplug sistemlerinde primary host application, edge node durumunu takip etmek için bu mekanizmalara ve death sertifikalarına birlikte dayanır.
OT gerçekliğine uygun güvenlik
Gateway'ler kendi kimlik bilgileriyle kimlik doğrulamalı, TLS üzerinden bağlanmalı ve biri yanlış şifrelerle girişi zorlarsa engellenmelidir. Kimlik bilgilerine bağlanmış client ID'ler, bir cihazın başka birini taklit etmesini veya onun ID'sini yeniden kullanarak bağlantısını düşürmesini önler. Broker ayrıca tek bir client'ın ne kadar yayın yapabileceğini sınırlamalıdır; böylece her milisaniyede bir tag yayımlayan yanlış yapılandırılmış bir gateway tesisin geri kalanının hizmetini bozamaz.
Sistemi devreye alanlar için görünürlük
En az değer verilen broker yeteneği, içine iyi bir pencere açmasıdır. Bir kontrol mühendisi yeni bir gateway bağladığında ilk soru her zaman şudur: "Veri geliyor mu ve doğru yerde mi?" Canlı bir topic explorer, bağlı client'ların görünümü ve bir bağlantı durumu topic'i bu soruyu saniyeler içinde yanıtlar. Eşik uyarıları broker'ı bir borudan, sıcaklık sınırları veya gateway sağlığı gibi değerler için temel bir izleme aracına dönüştürür.
Çalışma süresi ve işletim modeli
Broker'ı kimin yamaladığını, sertifikaları kimin yenilediğini, diski ve belleği kimin izlediğini ve gece 3'te kimin arandığını sorun. Kendi barındırmak tam kontrol sağlar ama tesis ekibini internete açık bir sunucudan sorumlu kılar. Tam yönetilen bir MQTT hizmeti bu işi sağlayıcıya devreder. Seçiminiz ne olursa olsun, broker yeniden başlatılırken client'ların nasıl davranacağını planlayın: backoff ile yeniden bağlanma, oturumları sürdürme ve gerektiğinde birth mesajlarını veya retained durumu yeniden yayımlama.
Herhangi Bir Endüstriyel MQTT Broker'ı Kendiniz Test Edin
Özellik listesi yazmak kolaydır. Bu MQTT 5 betiği, tesislerde önemli olan dört davranışı kontrol eder: retained iletim, oturumun sürdürülmesi, last will ve reason code'lar. Önce public test broker'da, ardından değerlendirdiğiniz herhangi bir broker'da çalıştırın.
import time
import uuid
import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes
HOST, PORT = "broker.connectmq.com", 1883
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1"
def make_client(cid):
return mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=cid, protocol=mqtt.MQTTv5)
def session_props(seconds):
p = Properties(PacketTypes.CONNECT)
p.SessionExpiryInterval = seconds
return p
received = []
def on_message(client, userdata, msg):
received.append((msg.topic, msg.payload.decode(), msg.retain))
# 1. Gateway retained durumu yayımlar ve bir last will kaydeder
gw = make_client("gw-" + uuid.uuid4().hex[:6])
gw.will_set(f"{BASE}/gw1/status", "OFFLINE", qos=1, retain=True)
gw.connect(HOST, PORT, keepalive=5)
gw.loop_start()
gw.publish(f"{BASE}/gw1/status", "ONLINE", qos=1, retain=True)
gw.publish(f"{BASE}/cnc1/state", "RUNNING", qos=1, retain=True).wait_for_publish()
# 2. Kalıcı oturumlu geç gelen abone retained durumu hemen alır
sub_id = "scada-" + uuid.uuid4().hex[:6]
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
sub.subscribe(f"{BASE}/#", qos=1)
time.sleep(2)
print("Retained on subscribe:", received)
# 3. Abone kopar, gateway yayımlar, abone oturumunu sürdürür
sub.disconnect(); sub.loop_stop()
gw.publish(f"{BASE}/cnc1/state", "IDLE", qos=1).wait_for_publish()
received.clear()
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
time.sleep(2)
print("Delivered after resume:", received)
# 4. Gateway çökmesini simüle et: DISCONNECT göndermeden ağ döngüsünü durdur
received.clear()
gw.loop_stop()
gw.socket().close()
time.sleep(10) # 1,5 x keepalive süresinden fazla bekle
print("Last will:", received)
sub.disconnect()
Beklenen çıktı: abone olunduğunda retained ONLINE ve RUNNING değerleri; abone yokken yayımlanmış olmasına rağmen oturum sürdürüldükten sonra iletilen IDLE değişikliği; ve broker gateway'in gittiğini fark ettiğinde gelen OFFLINE. Public broker'ın herkes tarafından okunabildiğini ve bilinçli sınırları olduğunu unutmayın (64 KB mesaj, client başına saniyede 10 mesaj, en fazla 30 dakika session expiry); bu yüzden yük testlerini yalnızca kendi broker'ınızda yapın.
Değerlendirme Kontrol Listesi
- Yukarıdaki betiği aday broker'da 8883 portunda TLS ile çalıştırın.
- Bir simülatörden gerçek Sparkplug B trafiği yayımlayın ve bunu broker araçlarında okuyup okuyamadığınızı kontrol edin.
- 50 client'ı aynı anda yeniden bağlayın ve reddedilen bağlantıları veya yavaş CONNACK'leri izleyin.
- Bilerek çok hızlı yayın yapın ve hangi reason code'u aldığınızı kontrol edin; örneğin MQTT 5'te 0x97 (kota aşıldı).
- Art arda beş yanlış şifre deneyin ve broker'ın tepki verdiğini doğrulayın.
- Broker'ı kimin işlettiğini ve sertifika yenilemenin nasıl çalıştığını sorun.
Daha geniş, endüstriyel olmayan bir karşılaştırma için IoT MQTT broker nasıl seçilir yazımıza bakın.
ConnectMQ Endüstriyel Kullanıma Nasıl Yaklaşıyor?
ConnectMQ, bu gereksinimler göz önünde bulundurularak geliştirilmiş yönetilen bir broker'dır. TCP, TLS, WebSocket ve güvenli WebSocket üzerinden MQTT 3.1.1 ve 5.0'ı, retained message'ları, session expiry'yi ve MQTT 5 reason code'larının tamamını destekler. ISA-95 ve Unified Namespace topic'lerini algılar, Sparkplug B'yi (protobuf ve JSON) çözer ve Sparkplug metriklerini ISA-95 topic'lerine yeniden yayımlar. Her broker bağlantı durumunu $SYS/broker/connection/{clientId}/state üzerinden sunar; portal ise canlı bir topic explorer, ISA-95 seviyesine göre bir cihaz görünümü ve eşik uyarı kuralları ekler. Çok kiracılı izolasyon, plan bazlı kotalar, flood koruması ve tekrarlanan başarısız girişlerden sonra IP engelleme her kiracıyı korur. Planlar ücretsiz Serverless'tan Dedicated kümelere, kendi bulut hesabınızda BYOC'ye ve Self Managed Enterprise'a kadar uzanır. Genel olarak barındırma ödünleşimleri için bulut MQTT broker rehberimizi, daha büyük endüstriyel resim için ise MQTT ile Endüstriyel IoT yazımızı okuyun.
ConnectMQ ile Başlayın
app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun. Test betiğini ve bir Sparkplug simülatörünü ona yönlendirin ve tesis verinizin dakikalar içinde ConnectMQ portalında çözülüp ISA-95 seviyesine göre düzenlendiğini görün.
Sık Sorulan Sorular
Endüstriyel bir MQTT broker'ın Sparkplug B'yi desteklemesi gerekir mi?
Sparkplug B; retained message, QoS ve last will destekleyen, standartlara uygun her broker'da çalışır. Sparkplug payload'larını ayrıca çözebilen bir broker, devreye almayı ve sorun gidermeyi çok daha kolaylaştırır.
Endüstriyel kullanım için MQTT 5 şart mı?
Hayır; Sparkplug B ve birçok gateway MQTT 3.1.1 kullanır. MQTT 5, session expiry, reason code'lar ve shared subscription gibi faydalı özellikler ekler; bu nedenle bir broker iki sürümü de desteklemelidir.
Kendim mi barındırmalıyım, yoksa yönetilen bir endüstriyel MQTT broker mı kullanmalıyım?
Kendi barındırmak tam kontrol sağlar ama yama, sertifika ve izleme sorumluluğunu ekibinize yükler. Yönetilen bir broker bu işi ortadan kaldırır; BYOC gibi seçenekler de broker'ı kendi bulut hesabınızda tutar.
Bir gateway'in çevrim dışı olduğunu nasıl anlarım?
Bir durum topic'inde OFFLINE gibi retained bir last will mesajı yapılandırın. Gateway temiz bir DISCONNECT göndermeden koptuğunda broker bunu otomatik olarak yayımlar.
