MQTT ile IoT cihaz haberleşmesi: kavramlar, konu tasarımı ve güvenlik

MQTT nedir, IoT için neden yaygın kullanılır?

MQTT, resmî sitesinde IoT için geliştirilmiş, OASIS standardı olan, son derece hafif bir yayın-abonelik (publish/subscribe) mesajlaşma taşıma protokolü olarak tanıtılır. Sınırlı işlemci, bellek ve dengesiz ağ bağlantısına sahip cihazlarda çalışacak biçimde tasarlandığı için sensörler, sayaçlar, araç takip cihazları ve fabrika makineleri gibi alanlarda yaygındır.

Klasik istemci-sunucu modelinde bir uygulama her cihaza doğrudan bağlanıp veri ister. MQTT'de ise cihazlar bir aracıya (broker) bağlanır; veri gönderen taraf (yayıncı) mesajı bir konuya yazar, ilgilenen taraflar (aboneler) o konuya abone olur. Yayıncı ile abone birbirini tanımak zorunda değildir. Bu gevşek bağlılık, yeni bir tüketici (örneğin bir pano, bir veri gölü ya da bir uyarı servisi) eklemeyi cihaz tarafına dokunmadan mümkün kılar. Çok sayıda cihazın tek bir noktaya veri akıttığı mimarilerde bu özellik büyük kolaylık sağlar.

Temel kavramlar: broker, konu, teslim seviyesi

MQTT'nin işleyişini anlamak için şu kavramlar yeterlidir: • Broker: mesajları alan, abonelere dağıtan ve oturum bilgisini yöneten sunucu. • Konu (topic): mesajın adresi; eğik çizgilerle ayrılan hiyerarşik bir ad. Aboneler belirli bir konuya ya da joker karakterlerle bir konu grubuna abone olabilir. • Teslim kalitesi (QoS): resmî sitede seviyeler tanımlanır: en fazla bir kez, en az bir kez ve tam bir kez teslim. Seviye yükseldikçe güvence artar, ancak trafik ve gecikme de artar. • Kalıcı oturum: bağlantı kopup geri geldiğinde istemcinin broker ile yeniden bağlanma süresini kısaltır. • Korunan (retained) mesaj ve son istek (last will) mesajı: yeni abone olana en son değeri göstermek ve cihaz beklenmedik biçimde koptuğunda bunu diğerlerine bildirmek için kullanılan protokol özellikleridir.

Temel hata sınıfı, bu seviyeleri iş ihtiyacına göre seçmemektir. Sıcaklık ölçümü gibi sık tekrarlanan veride en fazla bir kez teslim sıklıkla yeterlidir; bir vana komutunda ise teslimin doğrulanması gerekir.

Konu (topic) tasarımı ve veri modeli

MQTT projelerinin kalitesini en çok konu hiyerarşisi belirler; sonradan değiştirmek tüm cihaz yazılımını ve tüketicileri etkiler. İyi bir hiyerarşi okunur, genelden özele ilerler ve abonelikte joker kullanımına izin verir. Örneğin bir fabrika için şu yapı düşünülebilir: tesis, hat, makine, ardından ölçüm türü. Böyle bir yapıda bir hattın bütün makinelerine tek abonelikle ulaşılabilir.

Tasarım ilkeleri: • Konu adında cihaz kimliği ile ölçüm türü ayrı düzeylerde yer alsın. • Veri ve komutlar farklı dallara ayrılsın; böylece yetki kuralları sade kalır. • Konu adına değişken ve kişisel veri koymayın. • Mesaj içeriği için ortak bir biçim ve şema belirleyin: değer, birim, zaman damgası ve kalite bilgisi. Zaman damgasını cihazdan göndermek, ağ gecikmesinden bağımsız doğru sıralama sağlar. • Şema sürümünü mesajda taşıyın.

Fabrika ortamında bu hiyerarşi tek bir mantıksal ad uzayına (Unified Namespace) dönüştürülür; farklı sistemler veriyi aynı yerden alır, noktadan noktaya entegrasyon karmaşası ortadan kalkar.

Cihaz tarafında bağlantı yönetimi ve dayanıklılık

IoT cihazları ağın kesilmesine hazır olmalıdır. Hücresel ya da kablosuz bağlantı sık kopar, güç dalgalanır, cihaz yeniden başlar. Cihaz yazılımında şu davranışlar tasarlanmalıdır: • Yeniden bağlanma: bağlantı koptuğunda sabit aralıkla değil, giderek uzayan bekleme süreleriyle denemek; çok sayıda cihazın aynı anda broker'a yüklenmesini önler. • Yerel tamponlama: bağlantı yokken ölçümleri cihaz belleğinde ya da kalıcı depoda biriktirip bağlantı gelince göndermek. Tampon sınırlıdır; dolduğunda hangi verinin atılacağı bilinçli seçilmelidir. • Canlılık kontrolü: cihazın hâlâ bağlı olduğunu broker'a bildiren periyodik sinyal. • Son istek mesajı: cihaz beklenmedik biçimde koptuğunda broker'ın çevrimdışı bilgisi yayımlaması. • Sıra ve tekrar: en az bir kez teslimde aynı mesaj tekrar gelebilir; tüketici bunu tolere edecek şekilde yazılmalıdır.

Örneğin soğuk zincir izleyen bir araç tünelden geçerken sıcaklık ölçümlerini biriktirir, bağlantı gelince zaman damgalarıyla birlikte toplu gönderir; böylece panoda boşluk değil, gecikmeli ama eksiksiz bir seri görünür.

Güvenlik ve cihaz kimliği

Resmî site, MQTT'nin TLS şifrelemesini ve OAuth gibi modern kimlik doğrulama yöntemlerini desteklediğini belirtir. Güvenlik tasarımı ise protokol desteğinden çok uygulamaya bağlıdır.

Temel kontroller: • Şifreli bağlantı: cihaz ile broker arasındaki trafik şifrelenmelidir; açık metin MQTT yalnız yalıtılmış ve güvenilir ağlarda düşünülebilir. • Cihaz başına kimlik: tüm cihazlara aynı parola ya da aynı sertifika vermek, tek bir cihazın ele geçirilmesinde bütün sistemi açığa çıkarır. • Konu bazlı yetkilendirme: bir cihaz yalnız kendi konularına yazabilmeli, yalnız kendi komut konusuna abone olabilmelidir. • Kimlik bilgilerinin güvenli saklanması ve yenilenebilmesi: cihaz yazılımına gömülmüş sabit parola yenilenemez. • Güncelleme kanalı: cihazlar yazılım güncellemesi alabilmelidir. • İzleme: beklenmeyen bağlantı denemelerini ve olağandışı mesaj hacmini görmek.

Güvenlik sonradan eklenen bir özellik değil, cihaz kimliğinin üretildiği ilk günden başlayan bir tasarım gerekliliğidir.

Sık yapılan hatalar

MQTT projelerinde sık görülen sorunlar: • Konu hiyerarşisini düşünmeden başlamak ve sonradan her şeyi yeniden adlandırmak. • Her ölçüm için en yüksek teslim seviyesini seçmek; gereksiz yük ve gecikme yaratır. • Tek bir broker'ı tek hata noktası olarak bırakmak. Ölçek ve süreklilik için kümeleme ya da yük dengeleme düşünülmelidir. • Cihaz tarafında yerel tampon ve yeniden bağlanma stratejisi olmaması. • Mesaj içeriğinde zaman damgası ve birim bilgisi taşımamak. • Aynı kimlikle birden çok cihazı bağlamak; broker aynı kimlikli eski bağlantıyı düşürür ve cihazlar birbirini sürekli koparır. • Büyük veri paketlerini (görüntü, günlük dosyası) MQTT üzerinden göndermeye çalışmak. Protokol küçük, sık mesajlar için tasarlanmıştır. • Korunan mesajları temizlememek; eski bir değer yeni abonelere güncelmiş gibi sunulur.

Bu sorunlar protokolün kendisinden değil, mimari kararların ihmalinden kaynaklanır.

Öğrenme yolu ve Mindset bağlamı

Önce yerel bir broker kurup birkaç istemciyle yayın ve aboneliği deneyin. Konu hiyerarşisi ve joker karakterleri oynayarak öğrenin. Ardından teslim seviyelerini ve bağlantı kopmasını simüle edin: bağlantıyı bilerek kesip kalıcı oturum, korunan mesaj ve son istek davranışını gözleyin. Sonra bir mikrodenetleyici ya da cihaz simülatörü yazılımında yeniden bağlanma ve tamponlama ekleyin. İleri aşamada şifreli bağlantı, cihaz kimlikleri, yetkilendirme, ölçekleme ve fabrika ölçeğinde ad uzayı tasarımı gelir.

IoT Cihaz Yazılımı ve MQTT Protokolü programı, modül başlıklarına göre IoT mimarisi ve MQTT temellerini, konu tasarımı ve veri modelini, cihaz tarafı bağlantı yönetimini, dayanıklılık ve yerel tamponlamayı, güvenlik ve cihaz kimliğini, cihaz yönetimi ve ölçeklenmeyi kapsar. MQTT ve Unified Namespace ile Fabrika Veri Mimarisi programı fabrika entegrasyon sorunları, MQTT temelleri, Sparkplug B özellikleri, Unified Namespace tasarımı, güvenlik ve işletim ile fabrika uygulama senaryolarını içerir.