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?

Gerçek dünyadaki senaryolarda, OPC UA'nın 250+ bağlantı yönetimi yükü sorun yaratabilir. MQTT + Sparkplug B'ye geçiş yapılması durumunda ise bant genişliği %90 azalabilir ve yeni MES entegrasyonları hızlanabilir. Bu iki protokol çoğu zaman karşıt seçenekler gibi sunulur. Ancak karar sürecini yalnızca "A vs B" düzeyine indirgemek, entegrasyon ve işletme maliyetlerini artırabilir.

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.

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 temel olarak geleneksel bir İstemci/Sunucu (Client/Server) mimarisinde çalışır. Bir ekipmanın (Örn: Siemens S7-1500 serisi veya bir Beckhoff IPC) içine OPC UA Sunucusu (Server) oturtulur. Karşısına geçen bir OPC UA İstemcisi (SCADA yazılımı, Kepware vb.) ağ üzerinden makineye sürekli bağırarak sorar (Sorgulama / Polling): "Sıcaklık değeri kaç? Sıcaklık değeri kaç? Şu an Sıcaklık değeri kaç?"

OPC UA'nın Mükemmel Olduğu Donanımlar

• 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.")
• Yerel Ağ (LAN) Saf Hızı: Kararlı, stabil çalışabilen kablolu, kapalı bir fabrika Gigabit ağında (Local Area Network); OPC UA iki makinenin birbiriyle (Machine-to-machine / M2M) senkronizasyonu için genellikle fenomenal ve deterministik bir hız sunar.
• 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'nın Çöküş Noktası (Neden Bulut/Cloud Ölçeğinde Patlıyor?)

OPC UA "Ağır" bir protokoldür. Çalışma mantığı gereği agresif şekilde "Sürekli Sorgulama" esasına dayandığı için chatty bir profil oluşturur ve tekrarlayan verilerle bile ağ kaynağı tüketebilir. OPC UA trafiğini 4G (Hücresel/LTE) yönlendiricisi üzerinden veya zayıf bir atölye Wi-Fi ağından buluttaki bir merkeze (Dashboard) aktarmaya çalışırsanız; veri hacmi artışı riski yaratabilirsiniz.

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.

Sensörler veya Uç Ağ Geçitleri panoya "Veri nedir?" diye sormaz. Aksine, sadece ama sadece makinenin sensör değerinde bir değişiklik gerçekleştiği (Olay) an güncellediği değeri merkezi postacıya (Broker) doğruca "yayınlar" (İstisna Raporlama / Report-by-Exception).

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 Şov Yaptığı 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)

Eğer sahadaki otonom bir Robotik Kaynak Kolu, fiziksel kritik bir çarpışmayı önleyebilmesi için (Acil Stop/Fren algısı için); dibindeki güvenlik hücresi Safety-PLC sürücüsüne lokal ağ üzerinde (Hemen yan panodaki) çok düşük gecikmelerle (örneğin 5 milisaniyede) mesaj gönderip emri geri çekmek gibi agresif, hayati ve sert kapalı döngü (Closed-loop) bir fiziksel işlem yapmak zorundaysa --> öncelikli olarak OPC UA'yı (Veya PROFINET/EtherCAT'i) kullanın. Deterministik yapıdadır ve fiziksel kontrol için inşa edilmiştir.

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?

Uygulamalı Endüstri 4.0 Projelerindeki en acı çektiren, mimari olarak en sancılı kısım (Bu noktayı Proxus olmadan aylarca IT yazılım çözümleri arayarak çözemezsiniz); tesisteki halihazırda var olan (Legacy - 15 yıllık yaşlı yatırım olan) lokal OPC UA, Modbus RTU/TCP, veya Siemens S7 ekipmanlarınızı nasıl akıllı hale sokup Merkezdeki kurumsal omurgaya (MQTT Sparkplug B standardında) TERCÜME ETTİRECEĞİNİZDİR?

İş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.

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 →