MQTT, cihazların veriyi merkezi bir aracıya (broker) "konu" (topic) adıyla yayınladığı, o veriyi isteyen yazılımların da aynı konuya abone olarak aldığı hafif bir yayınla/abone ol mesajlaşma protokolüdür. Az bant genişliği harcar, kopan bağlantıya dayanıklıdır; bu yüzden sensörden, ağ geçidinden ve uzak sahalardan buluta veri taşımanın en yaygın yollarından biridir.
Sahadan gelen veri neden yolda kayboluyor?
Tipik bir IoT projesi birkaç sensör ve bir web servisine doğrudan istek atan bir cihazla başlar. İlk haftalarda sorun görünmez. Sonra saha sayısı artar, GSM bağlantısı gece yarısı kopar, sunucu bakıma girer ve o aralıkta gelen ölçümler sessizce kaybolur.
Asıl sorun protokol seçiminden çok mimaridir. Her cihaz her yazılımla ayrı ayrı konuştuğunda, yeni bir rapor ya da yeni bir alıcı eklemek için cihazların yazılımını güncellemek gerekir. Sahadaki yüzlerce cihaza yazılım göndermek ise hem risklidir hem de yavaştır.
MQTT bu bağımlılığı koparır. Cihaz yalnızca broker'ı tanır; SCADA, raporlama, alarm servisi ya da zaman serisi veritabanı aynı veriye birbirinden habersiz abone olur. Yeni bir alıcı eklemek cihaza dokunmadan yapılır.
Güvenilmez veri akışının maliyeti
Bağlı cihaz sayısı büyüdükçe küçük veri kayıpları büyük kör noktalara dönüşür. IoT Analytics'in State of IoT 2025 raporuna göre bağlı IoT cihazı sayısının 2025'te %14 artarak 21,1 milyara, 2030'da ise 39 milyara ulaşması bekleniyor. Bu ölçekte "cihaz başına ayrı bağlantı" düzeni yönetilemez hale gelir.
Veri geç ya da eksik geldiğinde ilk bedel üretimde ödenir. Alarm sensörde doğmuş ama merkeze ulaşmamışsa duruş, ancak biri fark ettiğinde başlar gibi görünür.
Siemens'in The True Cost of Downtime 2024 raporuna göre büyük üretim tesisleri ayda ortalama 25 plansız duruş yaşıyor ve ayda 27 saat üretim kaybediyor.
İkinci bedel güvenliktir. Parolasız, şifrelemesiz açılmış bir broker, sahadaki tüm verinin ve bazen komutların herkese açık olması demektir. Verizon 2026 Data Breach Investigations Report verisine göre fidye yazılımı tüm ihlallerin %48'inde yer aldı; internete açık ve korumasız bırakılan her servis, IoT broker'ı da dahil, saldırganlar için olası bir giriş noktasıdır.
MQTT nedir ve nasıl çalışır? Beş temel kavram
mqtt.org'un tanımına göre MQTT, nesnelerin interneti için OASIS standardı olan hafif bir yayınla/abone ol protokolüdür. Sahada bilinmesi gereken kavramlar şunlardır:
- Broker: Tüm mesajların geçtiği merkezi sunucu. Kimin bağlanabileceğine, hangi konuya yazıp hangisini okuyabileceğine broker karar verir.
- Topic (konu): Mesajın adresi.
tesis1/hat2/pres3/yag_sicakligigibi eğik çizgiyle ayrılmış bir yoldur;+tek seviyeyi,#altındaki her şeyi kapsayan joker karakterdir. - QoS (hizmet kalitesi): QoS 0 en fazla bir kez, QoS 1 en az bir kez, QoS 2 tam olarak bir kez teslim anlamına gelir. Seviye yükseldikçe güvence artar, trafik ve gecikme de artar.
- Retained mesaj: Broker bir konudaki son değeri saklar; yeni abone olan ekran boş başlamaz, son bilinen durumu hemen görür.
- Last Will (son vasiyet): Cihaz bağlanırken "beklenmedik şekilde koparsam şu mesajı yayınla" der. Böylece "cihaz çevrimdışı" bilgisi alarm sistemine kendiliğinden düşer.
Bağlantı standart olarak TCP üzerinden kurulur; şifresiz bağlantı için 1883, TLS ile şifreli bağlantı için 8883 numaralı port yaygın kullanılır. MQTT 5 sürümü, hata nedeni kodları, mesaj ömrü ve paylaşımlı abonelik gibi işletmede işe yarayan eklemeler getirdi.
Endüstriyel sahada sık karşılaşılan bir tamamlayıcı da Eclipse Foundation'ın Sparkplug B tanımıdır. MQTT içerik biçimini serbest bırakır; Sparkplug ise topic yapısını, veri tiplerini ve cihazın "doğum/ölüm" mesajlarını standartlaştırarak farklı üreticilerin cihazlarını aynı SCADA'da tutarlı gösterir.
MQTT mi, HTTP mi, OPC UA mı? Protokol karşılaştırması
MQTT her işin cevabı değildir; örneğin bina otomasyonunda HVAC ve aydınlatma cihazları çoğunlukla BACnet protokolüyle konuşur. Doğru katmana doğru protokolü koymak için sahada en sık karşılaşılan seçeneklerle yan yana bakmak gerekir:
| Ölçüt | MQTT | HTTP / REST | OPC UA | Modbus TCP |
|---|---|---|---|---|
| İletişim modeli | Yayınla/abone ol, broker üzerinden | İstek/yanıt | İstemci/sunucu ve PubSub | Sorgulama (master/slave) |
| Veri modeli | Serbest; Sparkplug ile standartlaşır | Serbest, genelde JSON | Zengin, hiyerarşik, tipli | Numaralı yazmaçlar |
| Kopuk bağlantıya dayanıklılık | Yüksek: QoS, oturum, Last Will | Düşük: yeniden deneme uygulamaya kalır | Orta | Düşük |
| Bant genişliği | Çok düşük başlık yükü | Görece yüksek | Orta | Düşük |
| Tipik kullanım yeri | Sahadan buluta, çok alıcılı dağıtım | Uygulamalar arası entegrasyon | Makine, SCADA, MES arası | Sayaç, analizör, basit cihaz |
Pratikte bu protokoller birbirinin rakibi değil, zincirin halkalarıdır. Enerji analizörü Modbus ile okunur, makine verisi OPC UA ile modellenir, bir ağ geçidi bu veriyi MQTT ile merkeze yayınlar.
İş sistemleriyle konuşma ise çoğu zaman ayrı bir API entegrasyonu katmanında çözülür; MQTT sahadan veriyi toplar, API ise bu veriyi ERP ya da CRM gibi uygulamalara taşır.
Ağ geçidinin hattın yanında veriyi süzüp özetlemesi, bağlantı koptuğunda ara belleğe alması üretimde edge computing yazımızın konusudur. Cihazın hangi taşıyıcı ağla (LoRa, NB-IoT, GSM) bağlanacağı ise ayrı bir karardır; bunu LoRa, NB-IoT ve GSM karşılaştırması yazısında ele aldık.
MQTT tabanlı veri akışını kurmak: 7 adımlık çerçeve
MQTT'yi kurmak birkaç saatlik iştir; onu yıllarca sorunsuz işletilebilir kılmak ise tasarım ister. Aşağıdaki sıra, en sık yapılan hataları baştan önler:
- Veri envanteri çıkarın. Hangi cihaz hangi değeri, hangi sıklıkta ve hangi birimle üretiyor, tek tabloya yazın. Değişmeyen değeri her saniye göndermek yerine yalnızca değiştiğinde göndermeyi (report by exception) planlayın.
- Topic hiyerarşisini tasarlayın. Kurum, tesis, alan, cihaz, ölçüm sırasını belirleyin; küçük harf ve sabit kurallarla yazın. Topic adına seri numarası ya da kişisel veri koymayın.
- Her veri için QoS seçin. Sık gelen sıcaklık okuması için QoS 0 çoğu zaman yeter; sayaç, adet ve alarm için QoS 1 ve tekrarlanan mesajı ayıklayan alıcı tercih edin. QoS 2'yi gerçekten gereken az sayıdaki akışa ayırın.
- İçerik biçimini standartlaştırın. Her mesajda değer, birim ve cihaz saatine göre zaman damgası olsun; sahada tutarlılık gerekiyorsa Sparkplug B'yi değerlendirin.
- Güvenliği ilk günden kurun. TLS zorunlu olsun, her cihaz kendi kimliğiyle bağlansın, erişim listesi (ACL) cihazın yalnızca kendi konusuna yazmasına izin versin. Broker'ı doğrudan internete açmayın.
- Kopma senaryolarını test edin. Last Will, kalıcı oturum ve cihaz tarafı ara bellek ile bağlantıyı bilerek koparıp verinin eksiksiz geldiğini doğrulayın.
- İzleme ve işletme kurallarını yazın. Broker'ın bağlı istemci sayısını, kuyruk büyümesini ve sertifika sürelerini izleyin; yeni cihaz eklerken izlenecek şablonu dokümante edin.
Canlıya almadan önce aşağıdaki kontrol listesiyle kurulumu gözden geçirin:
| Kontrol noktası | Sorulacak soru | Yanlış cevabın sonucu |
|---|---|---|
| Şifreleme | 1883 portu dışarıya kapalı, tüm istemciler TLS ile mi bağlanıyor? | Veri ve parolalar ağda açık metin dolaşır |
| Kimlik | Her cihazın ayrı kimliği ya da sertifikası var mı? | Tek sızan parola tüm sahayı açar |
| Yetki | Cihaz yalnızca kendi topic'ine mi yazabiliyor? | Bir cihaz başka cihazın verisini taklit edebilir |
| Kopma | Cihaz çevrimdışı kalınca veri tamponlanıyor mu? | Bağlantı gelince boşluklu grafik ve eksik rapor |
| Komut | Uzaktan komut gönderen topic'ler ayrı ve sıkı yetkili mi? | Yetkisiz kişi sahadaki ekipmanı çalıştırabilir |
| İzleme | Broker yükü ve bağlantı sayısı için alarm var mı? | Sorun müşteri şikâyetiyle fark edilir |
Uzaktan komut içeren kurulumlarda MQTT güvenliği, sahadaki OT ağının genel güvenliğinden ayrı düşünülemez. Ağ ayrımı ve uzaktan erişim kuralları için OT güvenliği ve SCADA yazımıza bakabilirsiniz. Topic ya da mesaj içeriği bir kişiyle ilişkilendirilebilecek veri taşıyorsa (örneğin araç takip cihazında sürücü kimliği) bu veri kişisel veri sayılabilir ve KVKK yükümlülükleri gündeme gelir; bu durumda hukuki değerlendirmeyi kurulum öncesinde yaptırmak gerekir.
Digital Bridge'de MQTT projelerini nasıl yapıyoruz?
İşe keşif ve ihtiyaç analiziyle başlıyoruz. Sahadaki cihazları, mevcut protokolleri, bağlantı imkânını ve verinin hangi karar için gerektiğini çıkarıyor; ardından kapsamı, aşamaları ve bedeli net yazılı bir teklif hazırlıyoruz. Endüstri 4.0 projeleri için saha değerlendirmesi ücretsizdir.
Hazır cihazın karşılamadığı durumlarda IoT cihaz imalatı hizmetimizle elektronik kartı, kasayı ve gömülü yazılımı aynı ekipte tasarlıyoruz. Cihaz yazılımı ile panel yazılımını aynı ekip yazdığı için topic yapısı, QoS seçimi ve kopma davranışı iki tarafta tutarlı kalır. Bu sürecin aşamalarını IoT cihaz geliştirme süreci yazısında anlattık.
Pilotta birkaç noktayı bağlıyor, veriyi uzaktan izleme platformumuza taşıyoruz. Platform Modbus TCP/RTU cihazlarından, MQTT ile yayın yapan sensörlerden ve REST API ile veri gönderen sistemlerden veri alır; harita, alarm kuralı ve mobil uygulamayla aylık abonelikle çalışır. Platform seçerken nelere bakılacağını uzaktan izleme IoT platformu rehberimizde, sahadaki bir örneği pompa istasyonu uzaktan izleme yazısında bulabilirsiniz.
Fabrika içinde veri operatör ekranına ve üretim yazılımına da gitmelidir. MQTT'den gelen değerleri SCADA ve HMI ekranlarına bağlıyor, ERP ya da MES tarafını sistem entegrasyonları hizmetimizle kuruyoruz. Broker'ın ve ağın güvenlik tasarımında siber güvenlik danışmanlığı ekibimiz sürece dahil olur.
Nereden başlamalı?
MQTT'ye geçmek için tüm sahayı aynı anda değiştirmek gerekmez. Kaybolan verinin en çok maliyet yarattığı bir akışı seçin, topic yapısını ve QoS kararlarını yazılı hale getirin, birkaç cihazla kopma testini yapın. Protokolü PLC'si olmayan eski makinelere taşımak isterseniz eski makineleri dijitalleştirme rehberi iyi bir başlangıç noktasıdır; diğer yazılar için IoT ve donanım yazılarımıza göz atabilirsiniz.
Sahanızdaki cihazların MQTT'ye nasıl bağlanacağını birlikte değerlendirmek için bizimle iletişime geçin. Keşifte mevcut altyapıyı çıkarıp ilk pilot için somut bir kapsam öneriyoruz.