OPC UA mı MQTT mi? İkisi neden çoğu projede birlikte kullanılır

Aynı katman değil

OPC UA bir makinenin veya sürecin ne olduğunu tanımlar: nesneler, değişkenler, birimler, metotlar ve bunların birbiriyle ilişkisi. İstemci, sunucunun adres uzayını gezerek ne sunulduğunu keşfedebilir. Ayrıntılar için OPC UA mimarisi yazısına bakın.

MQTT ise bir mesajın bir topic’e yayınlanıp abonelere iletilmesini sağlar. Mesajın içinde ne olduğunu, hangi birimde olduğunu ya da bir topic adının neyi temsil ettiğini tanımlamaz. Bu sade yapı MQTT’yi hafif ve yaygın kılar; anlamı taşımayı ise sizin sorumluluğunuza bırakır (veri sözleşmesi).

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

• Makineye yakın erişim. Etiketleri gezerek keşfetmek, yapılandırılmış nesnelerle çalışmak, standart tipler ve eşlik eden belirtimlerle aynı türden cihazlara aynı biçimde ulaşmak.
• Yazma ve komut. Yetkilendirilmiş yazma ve metot çağrısı, bir kontrol veya reçete işlemi gerektiğinde doğal yoldur.
• Yerleşik güvenlik. İmzalama, şifreleme, uygulama sertifikaları ve kullanıcı doğrulaması belirtimin parçasıdır.
• Kalite ve zaman. Her değer bir durum kodu ve zaman damgasıyla gelir.

Bedeli, daha fazla yapılandırma ve istemci-sunucu bağlantısıdır: her tüketici sunucuya ayrı bir oturum açar; çok sayıda tüketici sunucu üzerinde yük oluşturur.

MQTT nerede güçlüdür?

• Dağıtım (fan-out). Aynı veriyi yayıncı tüketicileri tanımadan birçok tüketiciye iletmek.
• Gevşek bağlılık. Yeni bir tüketici eklemek yayıncıyı değiştirmez.
• Dar bant ve güvenilir olmayan ağlar. Hafif başlık ve QoS seviyeleri kısıtlı bağlantılar için tasarlanmıştır.
• Merkezi veya bulut sistemlere dağıtım. Broker, tesis ile merkez arasında doğal bir ara noktadır.

Bedeli, anlamın dışarıdan gelmesi ve broker’ın kritik bir bileşen olmasıdır. Ayrıntılı tasarım ilkeleri için üretimde MQTT yazısına bakın.

Birlikte kullanım: iki kalıp

Kalıp 1: OPC UA ile oku, MQTT ile dağıt. Makine ve PLC verisi OPC UA ile okunur; bir entegrasyon katmanında birim, ad ve zaman damgası düzenlenir ve tesis genelinde bir MQTT isim alanına yayınlanır. Böylece bir tüketici makine protokollerini bilmeden veriyi alır. Bu yaklaşımın adlandırma boyutu Unified Namespace yazısında ele alınır.

Kalıp 2: OPC UA PubSub. OPC UA, istemci/sunucu modelinin yanında yayın/abone modelini de tanımlar ve MQTT’yi bir taşıma seçeneği olarak destekler. Amaç, OPC UA bilgi modelini MQTT’nin dağıtım avantajıyla birleştirmektir. Cihaz ve yazılım desteği ürüne bağlıdır; kullanmadan önce ürünlerinizin desteklediği profili doğrulayın.

İkinci kalıp mümkün olsa da uygulamada birinci kalıp sık görülür: makineler OPC UA konuşur, merkezi sistemler MQTT veya benzeri bir yapıyı tercih eder ve aradaki dönüşümü bir entegrasyon katmanı üstlenir.

Karar için beş soru

1. Kim yazacak? Kontrol parametresi veya reçete yazılacaksa OPC UA’nın yetkilendirilmiş yazması ve metotları daha uygundur.
2. Kaç tüketici var, kaçı olacak? Çok sayıda ve değişen tüketici MQTT tarafını öne çıkarır.
3. Ağ nasıl? Merkeze giden dar veya kesintili bir hat, hafif ve tamponlanabilir bir akış gerektirir.
4. Anlam nerede taşınacak? Eşlik eden belirtim ve bilgi modeli istiyorsanız OPC UA; kendi JSON sözleşmenizi yazmaya hazırsanız MQTT yeterli olabilir.
5. Kesintide ne olmalı? Kayıp kabul edilmiyorsa hangi katmanın tamponlayacağını ve tekrar işlemenin nasıl güvenli yapılacağını (Store & Forward) baştan belirleyin.

Entegrasyon planlayıcı, kaynak ve hedef sistemlerinizi seçerek bu soruları projenize uyarlanmış bir taslakta toplar.