Modern IIoT'de MQTT ve OPC UA: Hangi Koşulda Hangisi Uygun?

Dijital fabrikanın veri omurgasını tasarlayan bir IT/OT mimarı için temel sorulardan biri şudur: Altyapıda MQTT mi, OPC UA mı, yoksa birlikte kullanım mı daha uygun?

Bu iki protokol çoğu zaman karşıt seçenekler gibi sunulur. Oysa bağlantı sayısı, bant genişliği ve entegrasyon etkisi; subscription modeli, payload, güvenlik, cihaz kapasitesi, broker ve tüketici topolojisine bağlıdır. Kararı yalnızca "A veya B" düzeyine indirgemek işletme sınırlarını gizler.

Bu makalede protokol davranışı, mimari sınırlar ve trade-off'lar ele alınır. MQTT ve OPC UA'nın nasıl çalıştığını, hangi koşullarda uygun olduklarını ve neden Proxus Edge Gateway gibi platformlarda birlikte kullanıldıklarını inceleyeceğiz. OPC UA kaynaklarını doğrudan MQTT topic yapısına taşımak istiyorsanız odak sayfa olarak OPC UA-MQTT veri köprüsü içeriğine bakabilirsiniz.

Gözlenen performans, yük deseni ve dağıtım mimarisine göre farklılaşabilir.

OPC UA: Fabrika Katmanında Yerleşik Yaklaşım

OPC Unified Architecture (OPC UA), yerini alan bir Windows-COM teknolojisi olan eski OPC DA'nın halefi olarak 2008 yılında piyasaya sürüldü. OPC Vakfı tarafından kurgulanırken tek bir önemli hedefi vardı: Endüstriyel veri alışverişinde güvenli ve her üreticinin ortak anlaştığı (Vendor-Agnostic) tek standart olmak.

Nasıl Çalışır? (İstemci/Sunucu Polling Mimarisi)

OPC UA yaygın olarak istemci/sunucu mimarisi kullanır. Sunucu bir address space ve servisler açar; istemciler yetkili olduğunda okuma, yazma veya method çağrısı yapabilir, değişim ve event bildirimleri için subscription ile monitored item oluşturabilir. OPC UA ayrıca PubSub profilleri de tanımlar.

OPC UA'nın güçlü olduğu alanlar

• Karmaşık Bilgi Modelleme: OPC UA sadece basit bir taşıma (Transport) protokolü değildir; o önemli, hiyerarşik yapısal bir sözlüktür. Bağlandığı nesneleri (Obje) yapısal ve anlamsal (Semantic) olarak doğuştan anlar. (Örn: "Karşımdaki cihaz sıradan bir Float (Ondalıklı Sayı) dizisi değildir; o 6 eksenli bir Fanuc Robot Koludur ve eksenler arası teknik ilişkiler şu katı kurallara bağlıdır.")
• Zengin endüstriyel birlikte çalışabilirlik: OPC UA tipli bilgi modelleri, subscription, event, method, güvenlik ve vendor-neutral semantik sağlar. Deterministik emniyet kontrolü yine uygun fieldbus ve safety sisteminde kalır.
• Sektörel Derin Penetrasyon: Bugün Siemens, Rockwell, Beckhoff gibi birçok otomasyon üreticisi, gelişmiş PLC donanımlarında OPC UA dilini yerel (Native) olarak destekler.

OPC UA ölçekleme değerlendirmeleri

OPC UA yalnızca polling ile sınırlı değildir; istemciler subscription ve monitored item kullanabilir, ayrıca OPC UA PubSub tanımlıdır. Kurumsal ölçekte yine de sunucu session'ları, subscription'lar, sertifika güveni, address-space farkları, ağ bölgeleri ve kaynak sahipliği yönetilmelidir. Çok sayıda tüketicinin her kaynağa doğrudan erişmesi yönetişimi zorlaştırabilir.

Dahası; bir OPC cihazı her müşteri yazılıma ayrı kapı (Socket) açmalıdır. Katı, noktadan noktaya bağlantılar konfigüre etmek zorundasınız. Sahada 50 adet Akıllı PLC'niz ve 5 adet de o veriyi isteyen istemci programınız varsa (ERP, MES, SCADA, AI Algoritması); omuzlarınıza aniden manuel konfigüre edilmek ve bakımı yapılmak zorunda kalınan 250 adet kırılgan sanal kablo / bağlantı (TCP/IP Yükü) biner. Bu hantal kurgu, çeviklik (Agility) ve Birleşik İsim Alanı (UNS) hedeflerinizi daha başlamadan zorlaştırır.

MQTT: Hafif Pub/Sub Yaklaşımı

Message Queuing Telemetry Transport (MQTT); 1999 yılında ıssız okyanuslarda döşeli uzun petrol boru hatlarını; inanılmaz pahalı (Parası MB başına ödenen) ve sinyali berbat uydu (Satellite) bağlantıları üzerinden "Uzaktan ve Çok ucuza izleyebilir miyiz?" diye düşünen Ar-Ge mühendisleri tarafından icat edildi.

Nasıl Çalışır? (Yayıncı/Abonelik "Pub/Sub" Mimarisi)

MQTT, klasik istemci/sunucu polling modeline alternatif olarak broker merkezli Yayın/Abonelik (Publish/Subscribe) mimarisi kullanır.

Yayıncılar, uygulamanın tanımladığı periyot veya olaylara göre broker topic'lerine mesaj gönderir. Aboneler her kaynağa doğrudan bağlantı açmadan eşleşen mesajları alır. MQTT bir değerin ne zaman anlamlı olduğuna karar vermez ve payload şemasını kendiliğinden tanımlamaz.

Veriyi tüketen Kurumsal Müşterileriniz (Subscribers - SCADA/ERP vb.) ise Postacıya (Broker) gider ve sorgular: "Hey, Makine 1'in fırın sıcaklık değerinde herhangi bir değişiklik olursa gel de bana haber ver/ilet."

MQTT'nin güçlü olduğu alanlar

• Bant Genişliği Tasarrufu: Cihazlar sensörde istisnai farklılık (Olay/Değişim) olduğunda paket yayımladığı için, MQTT geleneksel OPC UA polling trafiğine kıyasla ağ yükünü önemli ölçüde (yük profiline ve örnekleme stratejisine bağlı olarak) azaltabilir.
• Ölçeklenebilirlik: Yeni bir analitik uygulama eklendiğinde çoğu durumda PLC tarafında değişiklik gerekmez; uygulama broker'a abone olur. Bu ayrışma (decoupling), çoklu tüketici senaryolarında entegrasyon maliyetini düşürür.
• Durum Farkındalığı: MQTT'de Last Will and Testament (LWT) mekanizması, bir kaynak cihaz bağlantısını kaybettiğinde abonelere durum bilgisinin iletilmesini sağlar.

"Saf (Çıplak) MQTT'nin" Sınırı

MQTT bir taşıma katmanıdır ve payload şemasını zorunlu kılmaz. Bu nedenle farklı cihazlar JSON, binary veya farklı özel formatlar gönderebilir.

Şema standardizasyonu yoksa birlikte çalışabilirlik maliyeti artar ve veri eşleme (data mapping) yükü uygulama ekiplerine kalır.

Büyük Dengeleyici Standart: MQTT + Sparkplug B

Çıplak MQTT kullanımındaki payload standardizasyonu sorununu azaltmak için Eclipse Foundation, Sparkplug B standardını yayımladı.

Sparkplug B, yeni bir protokol değildir. MQTT'nin en tepesine kurulan net tanımlı "Bir Yazım Standardı Spesifikasyonudur (Kalıptır)". Saf metinler yerine yüksek oranda sıkıştırılmış Protocol Buffers (ProtoBuf) teknolojisini kullanarak, zarfın (paket formatını) ağdaki birçok PLC/Makine üreticisinin uyduğu sözlük kurallarına (Örn: Cihaz Doğum ve Ölüm Sertifikaları Gönderme, Reçeteyi formatlama vs) uygun şekle sokar.

Sparkplug B ile MQTT, şema ve durum yönetimi açısından daha öngörülebilir hale gelirken pub/sub modelinin düşük overhead avantajını korur. Bu birleşik yaklaşım, modern UNS mimarilerinde sık kullanılan bir omurga modelidir.

Peki Hangi Protokolü Ne Zaman Kullanmalısınız?

Mimarlar için pratik yaklaşım: Masada Sadece birini seçmek zorunda değilsiniz. Üstün zeka (Master-class) ile harmanlanmış IT/OT şirket mimarilerinde; iki protokolü de tam olarak "Ait olmaları gereken yerde" duruma uygun olarak hibrit olarak kullanın.

Senaryo A: Makineden Makineye Sıkı Kontrol Gereksinimi (Tipik Seçim: OPC UA)

Makine bilgi modeli, güvenli veri erişimi, alarm, event veya vendor-neutral birlikte çalışabilirlik gerekiyorsa OPC UA güçlü bir kaynak sözleşmesi olabilir. Emniyet-kritik ve hard real-time kontrol, makine için onaylanan fieldbus ve safety mimarisini kullanmalıdır; yalnızca OPC UA seçmek determinizm sağlamaz.

Senaryo B: Kurumsal Veri Toplama ve Bulut Analitiği (Tipik Seçim: MQTT + Sparkplug B)

Eğer 4 farklı ülkedeki 300 farklı pres fabrikasından o sahadan toplanan verileri; Merkezi Data Lake'e (Veri Gölüne), Kestirimci Bakım, şirketin toplam Enerji (ISO 50001) maliyeti, OEE Dashboard raporları için saliseler içinde yüksek hacimli veriyi internetten kontrollü şekilde öngörülebilir "Tek Bir Borudan" akıtıp çekmek istiyorsanız --> pratikte MQTT ve Sparkplug B hibrit gücünü kullanın. OPC UA böylesine açık network bir veri seli (Bulut, AI vs) söz konusu olduğunda önemli ağ ağırlık yükü ve konfigüre edilmesi zor bağlantı (Node) karmaşası altında ölçeklendirme maliyeti ve bağlantı karmaşıklığı artabilir.

Proxus Bu Köprüyü Nasıl Kuruyor?

Uygulamadaki temel iş; mevcut OPC UA, Modbus RTU/TCP veya Siemens S7 kaynaklarının kimlik, datatype, kalite ve zaman bilgilerini hedef MQTT topic ile payload sözleşmesine doğru eşlemektir.

İşte tam olarak bu çıkmazda Proxus OPC UA-MQTT veri köprüsü ve daha geniş endüstriyel edge platformu yaklaşımı devreye girer; ağır OT protokollerini sahada yönetip yukarı katmana daha kontrollü bir veri akışı sağlar. Proxus burada yalnızca taşıma yapan basit bir broker değil; topic eşleme, edge tamponlama, UNS uyumu ve endüstriyel veri platformu teslimatı sağlayan endüstriyel MQTT gateway katmanıdır.

Ne zaman uygun olmayabilir?

• Düşük frekanslı telemetride daha basit yaklaşımlar yeterli olabilir.
• Tek hatlı küçük tesislerde tam dağıtık mimari maliyet-etkin olmayabilir.
• Katı legacy kısıtları olan ortamlarda kademeli geçiş gerekebilir.
• Emniyet-kritik kapalı çevrim kontrol, PLC/Safety PLC katmanında kalmalıdır.

Sonuçlar yük profiline, donanım kapasitesine ve dağıtım topolojisine bağlıdır.

Sık Sorulan Sorular

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

Evet ve modern IIoT mimarilerinin çoğunda çalışmalıdır. OPC UA yapısal, lokal makine-makine iletişiminde (CNC makineden karmaşık veri okumak) uygundur. MQTT hafif, ölçeklenebilir pub/sub dağıtımında üstündür. Proxus Edge Gateway köprü görevi görür - lokal olarak OPC UA ile okur, MQTT Sparkplug B'ye çevirir ve Birleşik İsim Alanı'na yayınlar.

OPC UA Pub/Sub, MQTT'nin yerini alabilir mi?

2026 itibarıyla birçok tesiste sınırlı. OPC UA Pub/Sub (Part 14) spesifikasyonda var ancak üretim seviyesinde broker implementasyonları hâlâ sınırlı ve MQTT ekosistemine kıyasla benimsenmesi düşük. Satıcınız stabil bir OPC UA Pub/Sub broker sunuyorsa değerlendirebilirsiniz; yine de geçişi kademeli ve test odaklı planlamak daha güvenlidir.

Hangi protokol daha güvenlidir?

OPC UA, uygulama katmanında sertifika tabanlı imzalama ve şifreleme ile yerleşik güvenliğe sahiptir. MQTT, taşıma şifrelemesi için TLS'e ve broker seviyesinde sertifika/kullanıcı doğrulamasına dayanır. OT-bulut yollarında her ikisi de doğru yapılandırıldığında karşılaştırılabilir güvenlik sağlar. Kritik güvenlik kararı protokol değil mimaridir - sadece-dışa yönelik ağ geçitleri kullanın.

Modbus demode mi oldu?

Modbus TCP/RTU, dünya genelinde en yaygın endüstriyel protokol olmaya devam ediyor. Basit, iyi anlaşılmış ve cihazlara (güç analizörleri, VFD'ler, debimetreler) derinden gömülüdür. Semantik veri modelleme yeteneği yoktur - 40001 gibi bir register adresi bağlam taşımaz. Edge Gateway'lerin var olma sebebi tam budur.

Sparkplug B mi, düz MQTT mi kullanmalıyım?

Tek tesisli bir pilot, homojen PLC'ler ve küçük bir ekip için düz MQTT ile dokümante edilmiş JSON şeması daha basit bir başlangıçtır. Sparkplug B'ye çoklu satıcı ortamları, çoklu tesis ve üçüncü taraf tüketiciler için ihtiyaç duyulur. UNS Mimari Rehberi ne zaman benimseneceği konusunda rehberlik sağlar.

Kaynaklar

1. OASIS MQTT v5.0 Standardı - MQTT publish-subscribe mesajlaşma protokol spesifikasyonu. mqtt.org
2. OPC Foundation - OPC UA Spesifikasyonu (IEC 62541) - Bilgi modelleme, client-server ve pub/sub iletişim standardı. opcfoundation.org
3. Eclipse Sparkplug Spesifikasyonu - IIoT için MQTT tabanlı birlikte çalışabilirlik çerçevesi. sparkplug.eclipse.org
4. Modbus Organizasyonu - Modbus Protokol Spesifikasyonu - Endüstriyel cihazlar için açık seri ve TCP iletişim standardı. modbus.org
5. ISA-95 / IEC 62264 - UNS topic tasarımında kullanılan hiyerarşik namespace modeli standardı. isa.org

Protokol seçimini iş yükü, topoloji ve yönetişim gereksinimlerine göre yapın. Lokal OPC UA ekipmanlarını MQTT tabanlı Unified Namespace yapısına nasıl bağlayabileceğinizi incelemek için bizimle iletişime geçebilirsiniz.

Hemen Bir Sistem Mimarına Ulaşın →