Ağ anahtarına bağlı çok sayıda kablo

“OPC UA mı MQTT mi?” sorusu, iki teknolojinin aynı işi yaptığını varsayar; oysa değildir. OPC UA, veriyi anlamıyla birlikte sunan ve sorgulanabilen bir bilgi modeli ile hizmet mimarisidir. MQTT ise taşınan veriye bakmayan, hafif bir mesajlaşma protokolüdür. Biri “veri nedir ve nasıl okunur?” sorusunu, diğeri “veri nasıl ve kime dağıtılır?” sorusunu yanıtlar.

Kısaca

Sahada cihazlarla konuşmak ve veriyi anlamlı biçimde sunmak için OPC UA; çok sayıda tüketiciye, bulut veya kurumsal katmana ağ kısıtlarına takılmadan dağıtmak için MQTT. Birçok mimaride ikisi birlikte yer alır.

Temel fark: iki model

OPC UA’nın klasik kullanımı istemci–sunucudur: bir istemci sunucuyla oturum kurar, adres uzayında gezinir, okur, yazar, abone olur. MQTT ise yayıncı–abone modelidir: yayıncılar bir broker’a mesaj gönderir, aboneler ilgilendikleri konulara abone olur; yayıncı ile abone birbirini tanımaz. OPC UA’nın da bir PubSub modeli vardır ve MQTT’yi taşıma katmanı olarak kullanabilir.

İstemci–sunucu ve PubSub karşılaştırmasıİstemci–sunucu modelinde bir istemci bir sunucuyla oturum kurar; PubSub modelinde yayıncı veriyi broker veya ağ üzerinden birden çok aboneye yayınlar.İstemci–sunucu: oturum tabanlı, bire birPubSub: bire çok, gevşek bağlıistek / yanıt · abonelikİstemciSorgular, yazar, abone olurSunucuAdres uzayını sunarYayıncıVeriyi bir kez yayınlarBroker veya UDP çoknoktaya yayınMQTT, AMQP veya UADPAbone AAbone B
İstemci–sunucu sorgu ve komut için, PubSub çok sayıda tüketiciye yayın için uygundur; birçok mimari ikisini birlikte kullanır.

Karşılaştırma

ÖlçütOPC UA (istemci–sunucu)MQTT (+ Sparkplug B)
Ne sağlar?Bilgi modeli, hizmetler (browse, read, write, subscribe, call, history)Hafif mesaj taşıma; Sparkplug ile konu yapısı ve yük biçimi
Veri anlamıTip, birim, hiyerarşi standardın parçasıHam MQTT’de yoktur; Sparkplug B tanımlı metrik yapısı ekler
Bağlantı yönüİstemci sunucuya bağlanır (sunucuda giriş portu gerekir)Hem yayıncı hem abone broker’a çıkış bağlantısı kurar
ÖlçekHer istemci ayrı oturum açarBir yayın, çok sayıda aboneye dağıtılır
Komut ve yazmaDoğal destek (write, method call)Konu ve yük tasarımıyla; Sparkplug’da NCMD/DCMD
KeşifAdres uzayında gezintiKonu ağacına abone olarak; Sparkplug BIRTH mesajlarıyla
GüvenlikUygulama sertifikası, imza, şifreleme, kullanıcı doğrulamaTLS, kimlik doğrulama ve broker erişim kuralları
Zayıf bağlantıOturum yeniden kurulur; abonelik yönetimi gerekirQoS düzeyleri, retained mesajlar, tamponlama

Hangi senaryoda hangisi?

OPC UA tercih edin

  • PLC, CNC, DCS ve sürücülerle doğrudan entegrasyon (Kepware Server gibi bir geçitle eski cihazlar dahil).
  • Adres uzayında gezinme, yöntem çağırma, tarihçe erişimi ve tip bilgisi gerekiyorsa.
  • Tesis içi, güvenilir bir ağda; az sayıda ama zengin istemci için.

MQTT (Sparkplug B ile) tercih edin

  • Aynı veriyi birçok sisteme (tarihçe, analitik, MES, bulut) dağıtacaksanız.
  • Güvenlik duvarında yalnızca çıkış bağlantısına izin veriliyorsa veya bağlantı zayıfsa.
  • Tek bir güncel veri uzayı (UNS) kuruyorsanız.

İkisini birlikte kullanın

Yaygın örüntü şudur: tesis içinde cihazlar OPC UA ile okunur; bir edge geçidi veriyi normalleştirir, kalite ve zaman damgasını korur ve MQTT/Sparkplug B ile broker’a yayınlar. Kepware Server’ın IoT Gateway eklentisi veya OPC Router bu rolü üstlenebilir. Broker, IT/OT sınırında bir DMZ’de durur ve OT tarafı yalnızca çıkış bağlantısı açar (IT/OT entegrasyonu).

Karar için altı soru

  1. Kaç tüketici aynı veriyi alacak? (Çoksa PubSub/MQTT.)
  2. Bağlantı hangi yönden açılabilir? (Yalnızca çıkış ise MQTT veya UA reverse connect.)
  3. Veri anlamı ve tipler kaybolmadan taşınmalı mı? (Evet ise UA modeli veya Sparkplug metrik yapısı.)
  4. Yazma/komut gerekiyor mu? (Evet ise kontrollü, onaylı bir mekanizma tasarlayın.)
  5. Bağlantı koptuğunda veri kaybedilebilir mi? (Hayır ise tamponlama: yedeklilik, tamponlama, kurtarma.)
  6. Veri modeli kimin sorumluluğunda? (Adlandırma kuralları ve sahiplik baştan belirlenmeli.)

Sık yapılan hatalar

  • Ham MQTT ile ortak yük biçimi tanımlamamak. Her uygulama kendi JSON yapısını icat eder; entegrasyon maliyeti artar. Sparkplug B veya belgelenmiş bir şema kullanın (veri modelini seçmek).
  • Tüm etiketleri en yüksek hızda buluta yayınlamak. Bant genişliği ve maliyet artar; değişime ve ihtiyaca göre yayınlayın.
  • Broker güvenliğini atlamak. TLS, kimlik doğrulama ve konu bazlı erişim kuralları zorunludur.
  • Kaliteyi ve zaman damgasını düşürmek. Dönüşümde değer taşınır ama bayat veya hatalı olduğu bilgisi kaybolur (OPC UA veri kalitesi ve zaman damgası).

OPC UA’nın temelleri için OPC UA nedir?, Sparkplug B hakkında Sparkplug B nedir? yazılarına bakın.

Sık sorulan sorular

MQTT güvenli midir?

MQTT’nin kendisi güvenliği broker ve taşıma katmanına bırakır. TLS, kimlik doğrulama ve konu bazlı erişim kuralları doğru yapılandırıldığında güvenli bir yapı kurulabilir.

OPC UA bulutla doğrudan konuşabilir mi?

Evet; ancak güvenlik duvarı ve ölçek nedeniyle çoğu mimaride bir geçit veya MQTT üzerinden yayın tercih edilir. OPC UA PubSub, MQTT taşımasıyla bunu doğrudan mümkün kılar.

Sparkplug B zorunlu mu?

Hayır; ancak MQTT’de ortak bir konu yapısı ve yük biçimi için yaygın bir standarttır ve farklı üreticilerin birlikte çalışmasını kolaylaştırır.