MQTT’de Cihaz Online Görünüyor Ama Veri Geç Geliyorsa QoS ve publish periyodu nasıl düşünülmeli? Nedir?

Endüstriyel otomasyon sistemlerinde, bir MQTT cihazının broker ile bağlantısının aktif (online) görünmesine rağmen, sensör verileri veya kontrol sinyalleri gibi uygulama verilerinin gecikmeli gelmesi sık karşılaşılan bir durumdur. Bu durum, sistemin genel performansını, karar alma süreçlerini ve otomasyon tepki sürelerini olumsuz etkileyebilir. Temelde bu gecikmelerin arkasında yatan faktörler, MQTT QoS (Quality of Service) seviyesinin yanlış seçimi, veri yayın periyodunun (publish period) optimize edilmemesi, ağ altyapısındaki darboğazlar veya broker üzerindeki aşırı yük olabilir. Cihazın online görünmesi, genellikle MQTT Keep Alive mekanizmasının aktif olduğunu gösterir; ancak bu, uygulama verilerinin sorunsuz bir şekilde aktarıldığı anlamına gelmez. Bu rehber, endüstriyel otomasyon profesyonelleri için bu kritik parametrelerin nasıl analiz edilmesi ve optimize edilmesi gerektiğini detaylandıracaktır.

Çalışma Prensibi ve Teknik Veriler

MQTT (Message Queuing Telemetry Transport), hafif, yayınlama/abone olma tabanlı bir mesajlaşma protokolüdür ve özellikle kısıtlı kaynaklara sahip cihazlar ve güvenilir olmayan ağlar için tasarlanmıştır. Ancak, bu protokolün sunduğu esneklik, doğru yapılandırılmadığında performans sorunlarına yol açabilir. Veri gecikmesi sorununu anlamak için QoS ve yayın periyodu kavramlarını derinlemesine incelemek gerekir.

QoS (Quality of Service) Seviyeleri

MQTT, mesaj teslimi için üç farklı QoS seviyesi sunar. Bu seviyeler, mesajın güvenilirliği ile ağ ve cihaz kaynakları üzerindeki yük arasında bir denge kurar:

• QoS 0 (At Most Once – En Fazla Bir Kez): Mesajın bir kez gönderildiği ancak teslimatın garanti edilmediği seviyedir. Gönderici, mesajı yayınlar ve alıcıdan herhangi bir onay beklemez. Bu, en düşük gecikmeye ve en az bant genişliği kullanımına sahip seviyedir. Ancak, mesaj kaybı yaşanabilir. Endüstriyel otomasyonda, sürekli güncellenen, küçük ve kritik olmayan sensör verileri (örneğin, anlık sıcaklık veya nem takibi) için uygun olabilir. Kayıp verinin sistemin genel işleyişini aksatmadığı durumlarda tercih edilir.
• QoS 1 (At Least Once – En Az Bir Kez): Mesajın en az bir kez teslim edildiği garanti edilir. Gönderici, mesajı yayınlar ve alıcıdan bir PUBACK (Publish Acknowledge) paketi bekler. Eğer PUBACK gelmezse, mesaj tekrar gönderilir (retry). Bu durum, mesajın birden fazla kez teslim edilmesine neden olabilir, bu yüzden alıcı uygulamanın yinelenen mesajları işleyebilmesi (idempotent olması) önemlidir. Endüstriyel otomasyonda, çoğu kritik veri (örneğin, üretim sayımları, durum güncellemeleri) için iyi bir denge sunar. Güvenilirlik önemliyken, aşırı gecikmenin kabul edilebilir olduğu durumlarda kullanılır.
• QoS 2 (Exactly Once – Tam Olarak Bir Kez): Mesajın tam olarak bir kez teslim edildiği garanti edilir. Bu seviye, dört aşamalı bir el sıkışma (handshake) mekanizması kullanır: PUBLISH, PUBREC (Publish Received), PUBREL (Publish Release), PUBCOMP (Publish Complete). Bu, en yüksek güvenilirliği sağlarken aynı zamanda en yüksek gecikmeye ve en fazla ağ trafiğine neden olur. Endüstriyel otomasyonda, kritik kontrol komutları, finansal işlemler veya stok seviyeleri gibi kesinlikle veri kaybı veya tekrarının kabul edilemez olduğu durumlar için ayrılmalıdır.

Yayın Periyodu (Publish Period)

Yayın periyodu, bir cihazın sensör verilerini veya durum güncellemelerini ne sıklıkla MQTT broker’ına gönderdiğini ifade eder. Bu periyodun belirlenmesi, ağ bant genişliği, cihazın işlemci yükü, pil ömrü ve veri tazeliği arasında doğrudan bir denge gerektirir.

• Çok Sık Yayın (Kısa Periyot): Cihazın verileri çok sık göndermesi, ağda gereksiz trafik oluşturabilir ve ağ tıkanıklığına (network congestion) yol açabilir. Bu durum, mesajların kuyruğa girmesine ve dolayısıyla gecikmelere neden olabilir. Ayrıca, cihazın işlemcisini ve hafızasını gereksiz yere meşgul ederek, pil ömrünü kısaltabilir. Broker üzerinde de aşırı yük oluşturarak genel sistem performansını düşürebilir.
• Çok Seyrek Yayın (Uzun Periyot): Verilerin çok seyrek gönderilmesi, topladığınız verinin güncelliğini yitirmesine neden olabilir. Bu, operasyonel kararların eski verilere dayanmasına yol açabilir ve otomasyon sistemlerinin gerçek zamanlı tepki verme yeteneğini kısıtlar. Örneğin, bir acil durum sensörünün verilerini 1 dakikada bir göndermesi, kritik bir hatayı tespit etmede çok geç kalınmasına neden olabilir.

Optimal bir yayın periyodu belirlemek için, uygulamanın gereksinimleri, ağ altyapısının kapasitesi ve cihazın kaynakları dikkate alınmalıdır. Bazı durumlarda, sabit bir periyot yerine Değer Değişimi (Change of Value – COV) tabanlı yayınlama veya eşik tabanlı yayınlama stratejileri daha verimli olabilir. Bu stratejilerde, veri sadece belirli bir eşiği aştığında veya değerinde önemli bir değişiklik olduğunda gönderilir, bu da gereksiz trafiği azaltır.

Ağ Altyapısı ve Broker Performansı

Sahada Dikkat Edilmesi Gerekenler

• Uygulama Kritikliğine Göre Doğru QoS Seçimi: Her zaman en yüksek QoS seviyesini kullanmak doğru değildir. Her bir veri türü için (örneğin, sıcaklık sensörü verisi, acil durum butonu sinyali, motor durdurma komutu) ayrı ayrı kritiklik analizi yapılmalıdır. Kritik olmayan, anlık değişen ve kayıp toleransı olan veriler için QoS 0 tercih edilmeli, ağ ve broker üzerindeki yük azaltılmalıdır. Kritik ancak tekrarlamaya dayanıklı veriler için QoS 1, mutlak güvenilirlik ve tekil teslimat gerektiren komutlar veya finansal işlemler gibi durumlar için ise QoS 2 kullanılmalıdır. Aşırı yüksek QoS kullanımı, gereksiz yeniden denemeler ve el sıkışmalar nedeniyle gecikmeleri artırabilir.
• Dinamik Yayın Periyodu ve COV Stratejileri: Sabit bir yayın periyodu yerine, Değer Değişimi (Change of Value – COV) veya eşik tabanlı yayınlama stratejileri benimsenmelidir. Örneğin, bir sıcaklık sensörü verisi sadece belirli bir derecenin üzerinde veya altında değiştiğinde ya da belirlenmiş bir delta değeri aştığında yayınlanabilir. Bu, gereksiz veri trafiğini önemli ölçüde azaltır ve ağ kaynaklarını verimli kullanır. Ayrıca, cihazlar uyku moduna geçerek pil ömrünü uzatabilir. Kritik durumlar için ise daha kısa periyotlar veya anlık yayınlar devreye sokulmalıdır.
• Ağ Altyapısı Denetimi ve Optimizasyonu: MQTT performansının temelinde sağlam bir ağ altyapısı yatar. Endüstriyel ortamlarda, kablosuz ağlarda (Wi-Fi, LoRaWAN, NB-IoT) sinyal gücü, parazit ve kapsama alanı kontrol edilmelidir. Kablolu ağlarda ise kablo kalitesi, anahtar/router performansı ve ağ gecikmeleri düzenli olarak izlenmelidir. Gerekirse, VLAN’lar veya QoS mekanizmaları ile MQTT trafiğine öncelik verilerek ağdaki diğer trafikten izole edilebilir. Ağdaki darboğazların giderilmesi, mesajların daha hızlı iletilmesini sağlar.
• Broker Performansı ve Ölçeklenebilirlik: Kullanılan MQTT broker’ının, bağlı cihaz sayısını ve mesaj hacmini kaldırabilecek kapasitede olduğundan emin olunmalıdır. Broker’ın CPU, RAM kullanımı, disk I/O ve eş zamanlı bağlantı sayısı gibi metrikleri sürekli izlenmelidir. Yüksek trafik durumlarında, broker’ın mesaj kuyruklarında birikme olup olmadığı kontrol edilmelidir. Gerekirse, broker’ın donanım kaynakları artırılmalı, yük dengeleme (load balancing) veya kümeleme (clustering) çözümleri ile ölçeklenebilirlik sağlanmalıdır.
• Cihaz Kaynak Yönetimi: Özellikle gömülü sistemler ve IoT cihazları gibi kısıtlı kaynaklara sahip cihazlarda, MQTT istemcisinin bellek ve işlemci kullanımı optimize edilmelidir. Aşırı sık yayın yapmak veya yüksek QoS seviyelerini gereksiz yere kullanmak, cihazın işlemcisini aşırı yükleyebilir ve kararsız çalışmasına neden olabilir. Cihazın yazılımı, verileri verimli bir şekilde paketlemeli ve sıkıştırmalıdır.
• Keep Alive ve LWT (Last Will and Testament) Doğru Yapılandırması: Keep Alive süresi, cihazın “online” durumunu broker’a bildirdiği aralığı belirler. Bu süre çok uzun olursa, bir cihazın bağlantı kesintisi geç fark edilebilir. Çok kısa olursa, gereksiz ağ trafiği oluşturur. Genellikle 30-60 saniye arası uygun kabul edilir. LWT mesajları, bir cihazın beklenmedik şekilde bağlantısı kesildiğinde otomatik olarak yayınlanan mesajlardır. Bu, diğer sistemlerin cihazın durum değişikliğini hızlıca algılamasına olanak tanır ve sistemin genel tepki süresini artırır. LWT mesajları, cihazın “offline” olduğunu belirten bir durum mesajı içermelidir.

Sık Karşılaşılan Sorunlar ve Çözümleri

Endüstriyel otomasyon sistemlerinde MQTT ile veri gecikmesi yaşandığında karşılaşılan bazı yaygın sorunlar ve bunlara yönelik çözüm önerileri şunlardır:

• Sorun 1: Veri Gecikmesi ve QoS 0 Kullanımı
  Senaryo: Kritik sensör verileri (örneğin, basınç veya akış) QoS 0 ile gönderiliyor ve zaman zaman veri kayıpları veya belirgin gecikmeler yaşanıyor.
  Çözüm: Kritik veriler için QoS 1 veya duruma göre QoS 2‘ye geçiş yapılmalıdır. QoS 1, teslimatı garanti ederken, QoS 2 hem teslimatı hem de tekilliği garanti eder. Bu geçiş, mesajın kaybolma riskini ortadan kaldırır ve broker tarafından onaylanana kadar yeniden denemelerle teslimatı sağlar. Ayrıca, ağ altyapısının stabilitesi kontrol edilmeli ve iyileştirilmelidir.
• Sorun 2: Ağ Tıkanıklığı ve Çok Sık Yayın
  Senaryo: Çok sayıda cihaz aynı anda ve çok kısa aralıklarla (örneğin her saniye) veri yayınlıyor, bu da ağda aşırı yük ve gecikmelere neden oluyor.
  Çözüm: Yayın periyodu uzatılmalı veya Değer Değişimi (COV) tabanlı yayın stratejileri benimsenmelidir. Örneğin, bir sıcaklık sensörü sadece 0.5°C’den fazla değiştiğinde veri gönderebilir. Önemli olmayan telemetri verileri için yayın periyodu 5-10 saniyeye kadar uzatılabilir. Ağ segmentasyonu veya bant genişliği yönetimi ile MQTT trafiğine öncelik verilebilir.
• Sorun 3: Broker Aşırı Yüklenmesi
  Senaryo: Broker, çok fazla eş zamanlı bağlantıyı veya yüksek mesaj hacmini kaldıramıyor, bu da mesajların kuyruklanmasına ve gecikmelere yol açıyor.
  Çözüm: Broker’ın donanım kaynakları (CPU, RAM) artırılmalıdır. Yüksek kullanılabilirlik ve ölçeklenebilirlik için birden fazla broker örneği kullanarak yük dengeleme (load balancing) veya kümeleme (clustering) çözümleri uygulanabilir. Ayrıca, gereksiz mesaj trafiğini azaltmak için cihazların yayın periyotları optimize edilmelidir.
• Sorun 4: Cihaz Kaynak Kısıtlamaları
  Senaryo: Kısıtlı donanım kaynaklarına sahip (düşük işlemci, az RAM) IoT veya gömülü cihazlar, yüksek QoS seviyeleri veya sık yayın nedeniyle takılıyor veya gecikmeli çalışıyor.
  Çözüm: Cihazın yazılımı optimize edilmeli, bellek ve işlemci kullanımı minimize edilmelidir. Mümkünse, daha düşük QoS seviyeleri tercih edilmeli ve yayın periyodu uzatılmalıdır. Veri sıkıştırma algoritmaları kullanarak gönderilen veri miktarı azaltılabilir. Daha güçlü donanıma sahip cihazlara geçiş bir diğer seçenektir.
• Sorun 5: Yanlış LWT Yapılandırması
  Senaryo: Bir cihazın bağlantısı kesildiğinde, diğer sistemler bunu anında fark edemiyor veya yanlış bir durum algılıyor.
  Çözüm: Her MQTT istemcisinde Last Will and Testament (LWT) mesajı doğru şekilde yapılandırılmalıdır. LWT mesajı, cihazın beklenmedik şekilde bağlantısı kesildiğinde broker tarafından yayınlanacak bir “offline” durum mesajı içermelidir. Bu, diğer sistemlerin cihazın durum değişikliğini hızlıca algılamasını sağlar.
• Sorun 6: Ağ Güvenlik Duvarı veya Proxy Sorunları
  Senaryo: Cihazın broker ile bağlantısı kuruluyor gibi görünüyor ancak veri geç geliyor veya hiç gelmiyor, ağ seviyesinde bir sorun olduğu düşünülüyor.
  Çözüm: Güvenlik duvarı (firewall) ve proxy ayarları kontrol edilmelidir. MQTT trafiği için gerekli portların (genellikle 1883 TCP için, 8883 TLS/SSL için) açık olduğundan ve herhangi bir filtreleme veya engelleme olmadığından emin olunmalıdır. Ağ diagnostik araçları (ping, traceroute, netcat) kullanarak bağlantı ve gecikme sorunları tespit edilebilir.

Uzman Tavsiyesi

Endüstriyel otomasyon sistemlerinde MQTT tabanlı cihazlardan veri gecikmesi yaşanması, karmaşık bir sorun olup, tek bir nedeni veya basit bir çözümü nadiren vardır. Cihazın “online” görünmesi, yalnızca temel ağ bağlantısının ve Keep Alive mesajlarının çalıştığını gösterir; bu, uygulama verilerinin sorunsuz bir şekilde aktarıldığı anlamına gelmez. Bu tür durumlarda, bir uzmanın yaklaşımı, QoS (Quality of Service) seviyesi ve yayın periyodu (publish period) başta olmak üzere, tüm sistemin bütünsel bir analizi ile başlamalıdır. Her bir veri tipi için, uygulamanın kritiklik düzeyi, veri tazeliği gereksinimleri ve tolerans eşikleri dikkatlice değerlendirilerek en uygun QoS seviyesi belirlenmelidir. QoS 0, hızlı ve düşük maliyetli telemetri için uygunken, QoS 1 çoğu endüstriyel veri için güvenilirlik ve performans arasında iyi bir denge sunar. En yüksek güvenilirlik gerektiren kritik kontrol komutları için QoS 2 kaçınılmazdır, ancak getirdiği ek gecikme ve yük göz önünde bulundurulmalıdır. Yayın periyodu ise, ağ bant genişliği, cihaz kaynakları ve veri tazeliği arasındaki hassas dengeyi kurar. Sabit periyotlar yerine, Değer Değişimi (COV) veya eşik tabanlı dinamik yayınlama stratejileri, hem ağ trafiğini optimize eder hem de cihaz ömrünü uzatır. Unutulmamalıdır ki, ağ altyapısının performansı, MQTT broker’ının kapasitesi ve cihazın işlem gücü de veri gecikmelerinde kilit rol oynar. Güvenilir bir ağ altyapısı, yeterli broker kaynakları ve optimize edilmiş cihaz yazılımları, doğru QoS ve yayın periyodu seçimleriyle birleştiğinde, endüstriyel otomasyon sistemlerinde güvenilir, verimli ve gerçek zamanlı veri akışını mümkün kılar. Sahadaki deneyimlerimize göre, bu parametrelerin dikkatli bir şekilde test edilmesi ve gerçek operasyonel koşullara göre ayarlanması, sistemin genel performansını ve güvenilirliğini önemli ölçüde artıracaktır. Her zaman en yüksek garantiyi seçmek yerine, ihtiyaca yönelik en uygun çözümü bulmak, hem maliyet hem de performans açısından en akılcı yaklaşımdır. Sonuç olarak, bu sorunların üstesinden gelmek için kapsamlı bir izleme, test ve iteratif optimizasyon süreci şarttır.