OPC UA ve MQTT, Endüstriyel IoT'nin en yaygın tartışmalarından biridir ve genellikle yanlış biçimde çerçevelenir. Bu karşılaştırma her protokolün ne için tasarlandığını, bilgi modelleme, iletişim modeli, güvenlik ve bulut bağlantısı açısından nasıl ayrıştıklarını ve gerçek dünyadaki en yaygın yanıtın neden "edge'de OPC UA, buluta MQTT" olduğunu açıklıyor. Sonunda mimarinizin her katmanı için hangisini kullanacağınızı bileceksiniz.
İki Protokol, İki Farklı İş
OPC UA (Open Platform Communications Unified Architecture) endüstriyel bir birlikte çalışabilirlik çerçevesidir. Yalnızca byte'ların nasıl taşındığını değil, bir makinenin kendini nasıl tanımladığını da belirler: nesneler, değişkenler, metotlar, tipler, mühendislik birimleri, alarmlar ve geçmiş. Bir client bir sunucuya bağlanır, adres alanında gezinir ve okur, yazar, abone olur veya metot çağırır. IEC 62541 olarak standartlaştırılmıştır ve birçok modern PLC'ye, CNC'ye ve SCADA sistemine yerleşiktir.
MQTT hafif bir publish/subscribe mesajlaşma protokolüdür. Client'lar merkezi bir broker'a bağlanır, topic'lere mesaj yayımlar ve ilgilendikleri topic'lere abone olur. MQTT, payload'ın ne anlama geldiği hakkında bilinçli olarak hiçbir şey söylemez; byte'ları güvenilmez ağlar üzerinde verimli ve güvenilir biçimde taşır. Bir OASIS standardıdır; 3.1.1 ve 5.0 sürümleri yaygın olarak kullanılır. Broker kavramına yeniyseniz bir MQTT broker'ın ne yaptığıyla başlayın.
Dolayısıyla bu karşılaştırma biraz bir veritabanı şemasını bir mesaj veri yoluyla karşılaştırmaya benzer. İkisi de veri taşır, ama her birinin getirdiği değer farklıdır.
Bir Bakışta OPC UA ve MQTT
| Boyut | OPC UA (client/server) | MQTT |
|---|---|---|
| Birincil model | Client/server oturumları; oturum başına subscription'lar | Bir broker üzerinden publish/subscribe |
| Bilgi modeli | Meta veri içeren zengin, tipli, gezilebilir adres alanı | Yerleşik değil; topic'leri ve payload'ları siz veya Sparkplug B gibi bir spesifikasyon tanımlar |
| Keşif | Node'ları ve tipleri bulmak için sunucuda gezinme | Wildcard ile abone olma; yerleşik şema keşfi yok |
| Bağlılık | Her tüketici her sunucuya bağlanır | Üreticiler ve tüketiciler yalnızca broker'ı bilir |
| Ağ yönü | Client sunucuya ulaşmalı; tipik olarak OT ağına gelen yönde | Tüm client'lar broker'a dışa doğru bağlanır |
| Kaynak ayak izi | Daha ağır yığın, daha büyük mesajlar, oturum durumu | Çok küçük client kütüphaneleri, en az 2 byte başlık |
| Güvenlik | Uygulama sertifikaları, imzalama ve şifreleme, kullanıcı token'ları | Taşıma katmanında TLS, kullanıcı adı/şifre veya client sertifikaları, broker tarafı yetkilendirme |
| Yazma ve metot çağrıları | Yerleşik: değişken yazma, metot çağırma | Komut topic'leriyle mümkün, ama teamül yoluyla |
| Bulut ve IT erişimi | Bulut platformlarında sınırlı yerleşik destek | Neredeyse her IoT platformu ve dil tarafından desteklenir |
| Tipik yeri | Tesis ağındaki PLC'ler, CNC'ler, SCADA, MES | Edge gateway'ler, bulut uygulamaları, panolar, mobil, kısıtlı cihazlar |
OPC UA'nın MQTT'yi taşıma katmanı olarak kullanabilen bir PubSub uzantısı (Part 14) da vardır. Bu, sınırı epeyce bulanıklaştırır ve MQTT üzerinden OPC UA PubSub yazımızda ele alınır. Bu karşılaştırma klasik client/server OPC UA'ya odaklanıyor, çünkü bugün kurulu ekipmanların çoğunun sunduğu budur.
Bilgi Modelleme: OPC UA'nın Büyük Avantajı
OPC UA'nın en güçlü özelliği anlambilimdir. Bir sunucu şunu söyleyebilir: "Bu, SpindleTemperature adlı bir değişkendir; tipi Double, birimi santigrat derece, aralığı 0 ile 120 arası ve MachineToolType tipindeki bir nesneye aittir." Companion spesifikasyonları daha da ileri giderek tüm makine sınıfları için standart modeller tanımlar; böylece iki farklı üreticinin enjeksiyon kalıplama makineleri bir client'a aynı görünebilir.
MQTT'de bunların hiçbiri kutudan çıktığı hâliyle yoktur. Bir topic üzerindeki 47.3 payload'ı yalnızca byte'lardır. Ekipler bunu üç şekilde telafi eder:
- Topic kuralları; örneğin yolun kendisinin bağlam taşıdığı bir ISA-95 hiyerarşisi. ISA-95 MQTT topic'leri rehberimiz pratik bir düzen gösteriyor.
- Her mesajda değer, birim, kalite ve zaman damgası içeren kendini tanımlayan JSON.
- MQTT'nin üzerine tanımlı bir payload, birth ve death sertifikaları ve metrik meta verisi ekleyen Sparkplug B.
Bir kullanım senaryosu için zengin modelleme vazgeçilmezse, örneğin bir MES'in bir makinedeki reçeteleri okuması ve metot çağırması gibi, OPC UA doğal seçimdir.
İletişim Modeli: Oturumlar ve Ayrıştırma
Klasik OPC UA'da her tüketici, ihtiyaç duyduğu her sunucuyla bir oturum açar. Elli makineden okuyan on uygulama yüzlerce oturum demek olabilir; her biri hiçbir zaman buna göre boyutlandırılmamış PLC'lerde bellek tüketir. Yeni bir tüketici eklemek, güvenlik duvarı kurallarına ve sunucu yapılandırmasına dokunmak demektir.
MQTT'de her makine veya gateway broker'a bir kez yayın yapar ve istenen sayıda tüketici abone olur. Yeni bir pano veya analitik işi eklemek fabrika sahasında hiçbir şeye dokunmaz. Bu ayrıştırma, MQTT'nin Unified Namespace modelinin omurgası olmasının temel nedenidir.
Madalyonun öbür yüzü: MQTT broker'ı kritik yola koyar. Broker çalışmıyorsa hiçbir şey akmaz; bu yüzden broker erişilebilirliği, izleme ve kapasite operasyonel kaygılara dönüşür. Birçok ekibin broker'ları kendileri çalıştırmak yerine tam yönetilen bir MQTT hizmeti seçmesinin bir nedeni de budur.
Güvenlik Modelleri
İki protokol de iyi şekilde güvenceye alınabilir; ikisi de güvensiz şekilde kurulabilir.
OPC UA güvenliği uygulama seviyesindedir: her client ve sunucunun bir X.509 uygulama örneği sertifikası vardır ve oturum imzalanabilir ya da imzalanıp şifrelenebilir. Kullanıcı kimlik doğrulaması bunun üzerine katmanlanır. Yaygın operasyonel sıkıntı, düzinelerce cihaz genelinde sertifika güven yönetimidir.
MQTT güvenliği çoğunlukla taşıma ve broker seviyesindedir: şifreleme için TLS, kimlik doğrulama için kimlik bilgileri veya client sertifikaları ve her client'ın neler yapabileceği için broker tarafı kurallar. Mimari avantaj yöndedir. Her MQTT client'ı broker'a dışa doğru bağlandığından OT ağına gelen port açmanız gerekmez. MQTT güvenliği en iyi uygulamaları yazımız temel gereksinimleri listeliyor.
Bulut Bağlantısı
Karşılaştırmanın en dengesiz olduğu yer burasıdır. Bulut hizmetleri, web uygulamaları, mobil uygulamalar ve veri araçları neredeyse evrensel olarak MQTT, HTTP veya her ikisini konuşur. Çok azı OPC UA client/server'ı yerel olarak konuşur ve bir OPC UA sunucusunu doğrudan internete açmak kötü bir fikirdir. MQTT'nin küçük ayak izi, kararsız bağlantılara toleransı, keep-alive'ları ve Last Will mesajları tam da bu tür uzak, kesintili bağlantılar için tasarlanmıştır.
Çoğu Tesisin Kullandığı Model: Edge'de OPC UA, Buluta MQTT
Pratikte soru nadiren "OPC UA mı, MQTT mi"dir; asıl soru "her biri nereye konacak"tır. Tekrar tekrar karşılaşılan model:
Level 0-2 Machines and PLCs -> OPC UA servers (native or via drivers)
Level 2-3 Edge gateway -> OPC UA client: subscribes to tags
-> maps nodes to a topic hierarchy, adds units and quality
Level 3-4 MQTT broker -> single hub (Unified Namespace)
Level 4+ Consumers -> dashboards, historian, MES, analytics, cloud apps
Gateway, OPC UA'nın anlambilimini makinelerin bulunduğu yerde korur ve bunları diğer her şeyin tüketebileceği bir topic yapısına ve payload biçimine çevirir. OPC UA'dan MQTT'ye gateway oluşturma eğitimimiz, TLS üzerinden bir broker'a yayın yapan çalışır bir Python uygulamasını adım adım anlatıyor.
Bu modelin MQTT tarafının nasıl göründüğünü saniyeler içinde görebilirsiniz. Bu komut, OPC UA'dan türetilmiş bir değeri bağlamıyla birlikte public test broker'a yayımlar:
mosquitto_pub -h broker.connectmq.com -p 1883 -i opcua-vs-mqtt-5d2e \
-t "connectmq/demo/5d2e/plant1/line1/cnc1/spindle_temp" -r -q 1 \
-m '{"value":47.3,"unit":"degC","quality":"Good","source":"ns=2;s=Line1.CNC1.SpindleTemp"}'
connectmq/demo/5d2e/# topic'ine abone olan herkes artık bu mesajı, OPC UA hakkında hiçbir şey bilmeden alır.
Karar Kontrol Listesi
Bu listeyi tesis başına değil, kullanım senaryosu başına karar vermek için kullanın:
- Bir client'ın bir makinede gezinmesi, set değeri yazması veya metot çağırması mı gerekiyor? OPC UA client/server kullanın.
- Bazıları tesis ağı dışında olan birçok tüketicinin aynı veriye mi ihtiyacı var? Veriyi MQTT'ye yayımlayın.
- Cihazlar kısıtlı mı (mikrodenetleyiciler, pilli sensörler) veya hücresel bağlantı üzerinde mi? MQTT.
- Standart anlambilime sahip, üreticiden bağımsız makine modellerine mi ihtiyacınız var? OPC UA ve companion spesifikasyonları; köprüleme yaparsanız anlambilimi MQTT payload'larına taşıyın.
- Bir Unified Namespace mi istiyorsunuz? Merkez olarak MQTT, edge'de onu besleyen OPC UA.
- Gelen güvenlik duvarı portları açamıyor musunuz? MQTT'nin yalnızca dışa doğru bağlantıları uygundur.
- Kontrolörler arasında deterministik, düşük gecikmeli kontrol mü gerekiyor? Sert gerçek zamanlı kontrol için ikisi de doğru araç değildir; bunun için tasarlanmış fieldbus'ı kullanın.
ConnectMQ Nereye Oturur?
ConnectMQ bu mimarinin MQTT tarafıdır: TCP, TLS ve WebSocket üzerinden MQTT 3.1.1 ve 5.0'ı destekleyen yönetilen bir broker. Kendisi OPC UA konuşmaz ve bu bilinçli bir tasarım tercihidir; OPC UA'yı edge gateway'iniz ele alır ve ona MQTT yayımlar. ConnectMQ ISA-95 ve Unified Namespace topic'lerini algılar, bunları canlı bir topic explorer'da ve ISA-95 seviyelerine göre düzenlenmiş bir cihaz görünümünde gösterir; gateway'iniz bu biçimi kullanıyorsa Sparkplug B payload'larını da çözebilir. Tüm yığına genel bir bakış için MQTT ile endüstriyel IoT rehberimize bakın.
ConnectMQ ile Başlayın
Edge'den buluta modeli broker kurmadan deneyin. app.connectmq.com adresinde ücretsiz Serverless planla (kredi kartı gerekmez) kaydolun, bir broker oluşturun ve oluşturulan kimlik bilgileriyle OPC UA gateway'inizi ona yönlendirin. Aynı öğleden sonra tesis veriniz buluttaki özel bir MQTT broker'a akıyor olacak.
Sık Sorulan Sorular
MQTT, OPC UA'nın yerini mi alıyor?
Hayır. MQTT fabrika sahasının üzerindeki noktadan noktaya entegrasyonların yerini alıyor; OPC UA ise birçok makinenin yapılandırılmış veri sunmasının standart yolu olmaya devam ediyor. Çoğu mimari ikisini birlikte kullanır.
OPC UA mı daha güvenli, MQTT mi?
İkisi de doğru yapılandırıldığında güvenlidir. OPC UA oturumları uygulama sertifikalarıyla güvenceye alır; MQTT ise TLS ve broker kimlik doğrulamasına dayanır ve client'ların yalnızca dışa doğru bağlantı kurması avantajını taşır.
OPC UA doğrudan MQTT kullanabilir mi?
Evet. OPC UA Part 14 PubSub, MQTT'yi JSON veya ikili UADP kodlamalarıyla bir taşıma katmanı olarak tanımlar; böylece OPC UA yayıncıları mesajlarını standart bir MQTT broker üzerinden gönderebilir.
Unified Namespace için hangisi daha iyi, OPC UA mı MQTT mi?
Publish/subscribe ayrıştırması sayesinde MQTT, Unified Namespace için olağan merkezdir. OPC UA sunucuları bu namespace'i genellikle edge gateway'ler üzerinden besler.
