Modern IIoT'de MQTT mi, OPC UA mı? Hangi protokolü seçmelisiniz?

IIoT mimarisi için doğru protokolü seçmek

Endüstriyel entegrasyon projelerinde gördüğüm en hararetli mimari tartışmalar, ilk bakışta basit görünen tek bir soru etrafında döner. Yeni bir dijital fabrikanın omurgasını tasarlayan kurumsal mimar ya da IT/OT yöneticisi, er geç endüstriyel otomasyonun en çok tartışılan yol ayrımına gelir: Altyapıyı MQTT üzerine mi kuralım, OPC UA üzerine mi?

Sektör yıllarca bu iki protokolü birbirinin rakibi gibi gösterdi. Üreticiler de genellikle kendi seçtikleri tarafı savundu. Oysa konuyu basit bir "A mı, B mi?" sorusuna indirgemek, pahalıya patlayan bir mimari hatadır.

Bu yazıda protokollerin nasıl davrandığına, sınırlarına, artılarına ve eksilerine odaklanıyoruz. MQTT ile OPC UA'nın nasıl çalıştığını, hangisinin nerede uygun olduğunu ve Proxus gibi pek çok modern platformun neden ikisini bir Unified Namespace stratejisi içinde birlikte kullandığını inceliyoruz. OPC UA kaynaklarını MQTT konularına bağlamanız gerektiğini zaten biliyorsanız doğrudan OPC UA'dan MQTT'ye veri aktarımı sayfasına geçebilirsiniz.

Sonuçlar iş yüküne, donanıma ve ağ yapısına göre değişir.

OPC UA sahanın yerleşik standardıdır

OPC Unified Architecture (OPC UA), Windows COM teknolojisine dayanan ve sorunlarıyla bilinen OPC DA'nın yerini almak üzere 2008'de yayımlandı. OPC Foundation onu tek bir ana hedefle tasarladı: endüstriyel veri alışverişinde yaygın kabul gören, güvenli ve üreticiden bağımsız standart olmak.

Nasıl çalışır? (istemci/sunucu ve sorgulama)

OPC UA çoğunlukla istemci/sunucu mimarisiyle çalışır. Sunucu bir adres alanı ve çeşitli servisler sunar. İstemciler veri okuyabilir, yetkileri varsa yazabilir, metot çağırabilir ya da değişiklik ve olay bildirimleri için abonelikler ve izlenen öğeler (monitored item) oluşturabilir. OPC UA ayrıca PubSub profillerini de tanımlar.

OPC UA nerede güçlüdür?

• Karmaşık bilgi modelleri: OPC UA yalnızca bir taşıma protokolü değil, kapsamlı bir yapı sözlüğüdür. Karmaşık nesne tiplerini doğrudan anlar (örneğin "Bu sıradan bir ondalık sayı değil; 6 eksenli bir Fanuc robot kolu ve eksenler arasındaki ilişkiler de kesin olarak şöyle.").
• Güçlü endüstriyel birlikte çalışabilirlik: OPC UA; tipli bilgi modellerini, abonelikleri, olayları, metotları, güvenliği ve üreticiden bağımsız anlam yapısını destekler. Deterministik emniyet kontrolü ise yine uygun saha veri yolunda (fieldbus) ve emniyet sisteminde kalır.
• Geniş yaygınlık: Büyük otomasyon üreticilerinin çoğu (Siemens, Rockwell, Beckhoff) gelişmiş donanımlarında OPC UA'yı doğrudan destekler.

OPC UA ölçeklenirken nelere dikkat edilmeli?

OPC UA yalnızca sorgulamadan ibaret değildir; istemciler abonelikleri ve izlenen öğeleri kullanabilir, OPC UA ayrıca PubSub'ı da tanımlar. Yine de kurumsal ölçekte ekiplerin sunucu oturumlarını, abonelikleri, sertifika güvenini, adres alanları arasındaki farkları, ağ bölgelerini ve kaynakların sahipliğini yönetmesi gerekir. Çok sayıda sistemin her kaynağa doğrudan bağlanması, düzeni korumayı zorlaştırabilir.

Üstelik noktadan noktaya bağlantıların her birini titizlikle yapılandırmanız gerekir. 50 PLC'niz ve 5 istemci uygulamanız (ERP, MES, SCADA, yapay zekâ) varsa bir anda 250 ayrı ve kırılgan bağlantıyı yönetmek zorunda kalırsınız. Bu da bir Unified Namespace için gereken esnekliği ciddi biçimde azaltır.

MQTT hafif bir yayınla/abone ol alternatifidir

Message Queuing Telemetry Transport (MQTT), 1999'da petrol boru hatlarını pahalı ve bant genişliği düşük uydu bağlantıları üzerinden izlemek için geliştirildi.

Nasıl çalışır? (yayınla/abone ol)

MQTT, istemcinin sunucuyu doğrudan sorguladığı yapının yerine bir MQTT sunucusu etrafında kurulan yayınla/abone ol (Pub/Sub) mimarisini koyar. Yayıncılar mesajlarını, uygulamanın belirlediği zamanlamaya ya da olaylara göre MQTT sunucusundaki konulara gönderir. Aboneler de her kaynağa ayrı bağlantı açmadan ilgilendikleri mesajları alır. MQTT'nin kendisi bir değerin ne zaman anlamlı olduğuna karar vermez ve mesaj içeriğinin şemasını tanımlamaz.

MQTT nerede öne çıkar?

• Bant genişliği verimliliği: Yalnızca değişiklikleri bildirdiği için MQTT, pek çok senaryoda sürekli OPC UA sorgulamasına kıyasla ağ trafiğini belirgin biçimde azaltabilir. Bağlantısı sık kopan Wi-Fi ya da mobil ağlarda bile rahat çalışır.
• Yüksek ölçeklenebilirlik: Yeni bir yapay zekâ analiz uygulaması mı ekliyorsunuz? Uygulama MQTT sunucusuna abone olur, o kadar. PLC'nin bu uygulamadan haberi bile olmaz. MQTT sunucusu çok sayıda eşzamanlı bağlantıyı verimli biçimde karşılayabilir.
• Durum takibi: "Last Will and Testament" (LWT) gibi özellikler sayesinde bir makinenin enerjisi kesildiğinde MQTT sunucusu, abonelere veri kaynağına ulaşılamadığını bildirebilir.

Yalın MQTT'nin sorunu

MQTT yalnızca bir taşıma katmanıdır; içinde ne olduğuyla ilgilenmeyen bir kargo zarfı gibidir. İçine düzgünce yapılandırılmış bir JSON da koyabilirsiniz, anlaşılmaz bir ikili veri yığını da. Bu standart eksikliği IIoT'nin ilk yıllarında ciddi bir karmaşa yarattı ve mühendisleri zahmetli veri eşleştirme işleriyle uğraşmak zorunda bıraktı.

Mesajların getirdiği ek yük tek bir bayt sayısıyla kıyaslanamaz. Konu uzunluğu, QoS, oturum durumu, güvenlik, paketleme, mesaj kodlaması, kullanılan OPC UA servisi ve taşıma katmanı sonucu etkiler. Karşılaştırmayı gerçek eşleştirme ve gerçek iş yüküyle ölçerek yapın.

Dengeyi MQTT + Sparkplug B kurar

Eclipse Foundation, yalın MQTT'deki "herkes istediğini gönderir" sorununu çözmek için Sparkplug B spesifikasyonunu ortaya koydu.

Sparkplug B, MQTT'nin üzerine kurulan bir spesifikasyondur. Protocol Buffers (ProtoBuf) kullanan katı ve standart bir mesaj biçimi getirir; oturum durumunun yönetimi için de kesin kurallar koyar (Birth ve Death mesajları).

Sparkplug B sayesinde MQTT, yayınla/abone ol modelinin ölçeklenebilirliğini ve düşük ek yükünü korurken OPC UA'ya benzer bir yapısal öngörülebilirlik kazanır. Bu ikili, modern Unified Namespace mimarisinin en yaygın omurgalarından biridir.

Hangisini ne zaman kullanmalı?

İşin aslı, seçim yapmak zorunda değilsiniz. Pratik bir IT/OT mimarisi iki protokolü de tam ait oldukları yerde kullanır.

A senaryosu: Makineler arası sıkı kontrol (genellikle OPC UA)

Makine bilgi modelleri, güvenli veri erişimi, alarmlar, olaylar ya da üreticiden bağımsız birlikte çalışabilirlik söz konusuysa kaynak tarafında OPC UA daha iyi bir sözleşme olabilir. Güvenlik açısından kritik ve katı gerçek zamanlı kontrol ise o makine için onaylanmış saha veri yolunu ve emniyet mimarisini kullanmalıdır. Yalnızca OPC UA'yı seçmek determinizmi garanti etmez.

B senaryosu: Kurumsal veri toplama ve bulutta yapay zekâ (genellikle MQTT + Sparkplug B)

Verinin birden fazla tesise ve birden fazla sisteme bir MQTT sunucusu üzerinden dağıtılması gerekiyorsa MQTT, kaynak ile veriyi kullanan sistem arasındaki doğrudan bağımlılığı azaltabilir. Sparkplug B'nin durum, metrik ve konu kuralları taraflara uyuyorsa Sparkplug B'yi kullanın. Seçimi; MQTT sunucusunun kapasitesine, mesaj içeriğinin anlamına, iletim beklentilerine ve sistemin ömrü boyunca nasıl yönetileceğine göre doğrulayın.

OPC UA'dan MQTT'ye köprü kurmak

Çoğu tesis sonunda ikisini birlikte kullanır: tesis ağında OPC UA (ve Modbus ya da Siemens S7), veri ağacına ve kurumsal tarafa doğru MQTT. Aradaki köprü, bağlamın korunduğu ya da kaybolduğu yerdir: sunucudaki gezinme yolu mu, tesis yapısına göre konu mu; kaynak zaman damgası mı, okuma zamanı mı; StatusCode mu, çıplak bir sayı mı? OPC UA'dan MQTT'ye saha verisini anlamını kaybetmeden taşımak rehberi bu kararları tek tek ele alıyor.

Proxus'ta bu işi, sahadaki bir endüstriyel bilgisayarda çalışan Edge Gateway yapar. OPC UA sürücüsü ve diğer kontrolör sürücüleri ekipmanı okur; Edge Gateway değerleri kaynağında ölçekler, dönüştürür, filtreler ve bağlantı koparsa ara bellekte tutar; merkez sunucu da onları Unified Namespace içine yerleştirir. Veri buradan, ihtiyaç duyan sistemlere MQTT üzerinden, Sparkplug B biçimi de dâhil olmak üzere yayınlanabilir.

Bu yaklaşım ne zaman uygun olmayabilir?

• Seyrek gelen telemetri, tamamen dağıtık bir mimarinin karmaşıklığına değmeyebilir.
• Küçük, tek hatlık tesisler işe daha basit mimarilerle başlamayı tercih edebilir.
• Eski sistemlerden gelen katı kısıtlar, geçişin aşama aşama yapılmasını gerektirebilir.
• Güvenlik açısından kritik kapalı çevrim kontrol, PLC ve Safety PLC katmanlarında kalmalıdır.

Sahada görülen performans iş yükünün niteliğine, düğüm kapasitesine ve kurulum tasarımına bağlıdır.

Sık sorulan sorular

MQTT ve OPC UA birlikte çalışabilir mi?

Evet; modern IIoT mimarilerinin çoğunda birlikte çalışmaları da gerekir. OPC UA, sahada yapılandırılmış makineler arası haberleşmede (örneğin bir CNC tezgâhının çok katmanlı karmaşık veri modelini okumakta) güçlüdür. MQTT ise veriyi tesisler arasında hafif ve ölçeklenebilir biçimde dağıtmakta güçlüdür. Proxus Edge Gateway'i bu ikisi arasında köprü kurar: OPC UA'yı sahada okur, değerleri Unified Namespace içine yerleştirir ve MQTT ya da Sparkplug B üzerinden yayınlayabilir.

OPC UA Pub/Sub, MQTT'nin yerini alır mı?

2026 itibarıyla pratikte hayır. OPC UA Pub/Sub (Part 14) spesifikasyonda yer alıyor, ancak üretime hazır mesaj sunucusu uygulamaları az ve geniş MQTT ekosistemine kıyasla pek benimsenmiş değil. Üreticilerin çoğu OPC UA'yı hâlâ klasik istemci/sunucu modunda sunuyor. Üreticiniz araç desteğiyle birlikte kararlı bir OPC UA Pub/Sub sunucusu sunuyorsa değerlendirin; ama mimarinizi henüz olgunlaşmakta olan bir ekosisteme emanet etmeyin.

Hangi protokol daha güvenli?

OPC UA'da uygulama katmanında (yalnızca taşıma katmanında değil) imzalama ve şifreleme yapan, sertifikaya dayalı yerleşik bir güvenlik yapısı vardır. MQTT ise taşıma katmanının şifrelenmesi için TLS'ye, kimlik doğrulama için de MQTT sunucusu düzeyinde kullanıcı adı ve parolaya ya da sertifikaya dayanır. OT'den buluta giden yollarda, doğru yapılandırıldığında ikisi de benzer düzeyde güvenlik sağlar. Asıl güvenlik kararı protokol seçimi değil, mimaridir: Yalnızca dışa doğru bağlantı kuran Edge Gateway'ler kullanın.

Modbus artık eskidi mi?

Modbus TCP/RTU, dünyada hâlâ en yaygın kullanılan endüstriyel protokoldür. Basittir, herkesçe bilinir ve enerji analizörleri, frekans invertörleri, debimetreler gibi cihazlara derinlemesine yerleşmiştir. Ancak verinin anlamını taşıyan bir modeli yoktur; 40001 gibi bir adres tek başına hiçbir şey anlatmaz. Edge Gateway'lerin varlık nedeni tam da budur: Modbus adreslerini okur, verinin neyi ifade ettiğini ekler ve bütün tanım bilgileriyle birlikte UNS'e yayınlar. Proxus'un neleri okuduğunu Modbus sürücüsü sayfasında görebilirsiniz.

Sparkplug B şart mı, yoksa yalın MQTT yeterli mi?

Tek tesiste, PLC'leri benzer ve ekibi küçük bir pilot projede, belgelenmiş bir JSON şemasıyla yalın MQTT kullanmak başlangıç için daha basittir. Farklı üreticilerin ekipmanları, birden fazla tesis ya da Birth/Death oturum yönetimiyle kendini tanımlayan mesajlara ihtiyaç duyan üçüncü taraf sistemler devreye girdiğinde Sparkplug B vazgeçilmez hâle gelir. Sparkplug B'ye ne zaman geçmeniz gerektiğini UNS mimarisi rehberinde bulabilirsiniz.

Kaynaklar

1. OASIS MQTT v5.0 Standardı - MQTT'nin yayınla/abone ol mesajlaşmasını tanımlayan protokol spesifikasyonu. mqtt.org
2. OPC Foundation - OPC UA Spesifikasyonu (IEC 62541) - Bilgi modellemeyi, istemci/sunucu ve pub/sub haberleşmeyi tanımlayan endüstriyel birlikte çalışabilirlik standardı. opcfoundation.org
3. Eclipse Sparkplug Spesifikasyonu - Birth/Death mesajlarını ve ProtoBuf mesaj biçimini tanımlayan, IIoT için MQTT tabanlı birlikte çalışabilirlik çerçevesi. sparkplug.eclipse.org
4. Modbus Organization - Modbus Protokol Spesifikasyonu - Endüstriyel cihazlar için açık seri ve TCP haberleşme standardı. modbus.org
5. ISA-95 / IEC 62264 - Kurumsal sistemlerle kontrol sistemlerinin entegrasyonuna dair standart; UNS konu tasarımında kullanılan hiyerarşik veri ağacı modelini tanımlar. isa.org