Endüstri 4.0 Karşılaştırması: MQTT mi Yoksa OPC UA mi Seçmelisiniz?

Dijital bir fabrikanın veri omurgasını tasarlamakla görevli bir IT/OT Sistem Mimarı (Enterprise Architect) veya Otomasyon Yöneticisiyseniz, endüstriyel dünyada en çok tartışılan ve taraf tutulan o büyük yol ayrımına kaçınılmaz olarak geleceksiniz: Altyapımızı MQTT üzerine mi kurmalıyız, yoksa OPC UA üzerine mi?

Yıllardır endüstri dergileri ve makine üreticileri bu iki protokolü birbirine kırdırmakta ve agresif bir şekilde kendi silolarını savunmaktadır. Ancak bu durumu basit bir "A vs. B" kafes dövüşüne indirgemek; şirketiniz için milyon dolarlık faturaya mal olacak korkunç bir mimari (Architectural) tasarım hatasıdır.

Bu derin kılavuzda pazarlama palavrasını bir kenara bırakıyoruz. MQTT ve OPC UA'nın kaputun altında teknik olarak nasıl (Mekanik seviyede) çalıştığına, nerede mükemmel olduklarına, nerede feci şekilde çöktüklerine ve neden Proxus Edge Gateway gibi modern inovatif platformların sahada durdurulamaz bir Tekil Veri Mimarisi (UNS) kurmak için bu iki teknolojinin her ikisini de birbirine örmek zorunda olduğuna bakacağız.

1. OPC UA: Fabrika Zemininin Tartışmasız Ağır Sıklet Şampiyonu

OPC Unified Architecture (OPC UA), sürekli çöken ve belalı 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 devasa hedefi vardı: Endüstriyel veri alışverişinde nihai, en 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 (Complex Information Modeling): OPC UA sadece basit bir taşıma (Transport) protokolü değildir; o devasa, 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 tamamen ş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 tartışmasız fenomenal ve deterministik bir hız sunar.
• Sektörel Derin Penetrasyon: Bugün Siemens, Rockwell, beckhoff gibi neredeyse tüm üst düzey otomasyon devri otomasyon devleri, PLC donanımlarında OPC UA dilini yerel (Native) olarak kayıtsız şartsız destekler.

OPC UA'nın Çöküş Noktası (Neden Bulut/Cloud Ölçeğinde Patlıyor?)

OPC UA "Ağır (Heavyweight)" bir protokoldür. Çalışma mantığı gereği agresif şekilde "Sürekli Sorgulama (Polling)" esasına dayandığı için son derece gevezeyken, boş ve tekrarlayan verilerle bile ağı işgal eder. 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; devasa bir veri şişmesi (Bandwidth Saturation - Tıkanması) yaratırsınız.

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 felç eder.

2. MQTT: Yıkıcı, Çevik ve Hafif Sıklet Akıncı Kuvvet

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, o ilkel ve hantal (İstemci/Sunucu) sorma (Polling) modelini tamamen dinamitler! Tüm sistemin ortasında oturan akılsız bir postacı (Pano/Aracı - Broker) etrafında şekillenen modern Yayın/Abonelik (Publish/Subscribe) mimarisini kullanır.

Sensörler veya Uç Ağ Geçitleri (Publishers) 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 "fırlatır" (İstisna Raporlama / Report-by-Exception).

Veriyi tüketen Kurumsal Müşterileriniz (Subscribers - SCADA/ERP vb.) ise Postacıya (Broker) gider ve fısıldar: "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 (Bandwidth Efficiency): Dev cihazlar sadece sensörde istisnai farklılık (Olay/Değişim) yaşandığında paketi ağa bastığı için, MQTT geleneksel OPC UA sorgulama paketlerine (Polling traffic) kıyasla fabrika ağınızdaki trafiği kelimenin tam anlamıyla tek tıkla %80 ila %90 oranında ferahlatır. Kopan, stabil olmayan (Intermittent) en berbat 3G çekmeyen sahalarda bile hayatta kalmaya programlıdır.
• Devasa ve Sonsuz Ölçeklenebilirlik (Massive Scalability): Şirkete OEE ölçümü için dışarıdan yeni bir AI (Yapay Zeka MLYAnalitik) programı mı aldınız? Programa tek kod yazmazsınız, programı sadece aradaki aracıya (Broker'a) Abone edersiniz. Sahadaki o zavallı, yaşlı PLC; o saniyeden sonra milyonlarca kez tüketilmiş olsa bile AI programının varlığından bile "Fiziksel olarak Haberdar Değildir (Ayrışma/Decoupling)". MQTT sayesinde, saniyeler içerisinde hiç çökmeden bir veriyi anlık canlı yayında bir (1) milyon SCADA sistemine basabilirsiniz.
• Durum Farkındalığı (State Awareness - Ölüm Sertifikası Sensörü): MQTT'nin efsanevi "Son Vasiyet/Mirasiyet (Last Will and Testament - LWT)" gibi keskin özellikleri sayesinde, makine ustası gidip üretim sahasındaki makinenin 220V gücünü fişten vahşice çekerse veya router yanarsa; donanımla irtibatını saniyede kaybeden Broker (Postacı) derhal ağdaki "Abonelere" bağırır ve anlık OEE grafiğini çözen tüm o fabrikanın ekranlarına (Siyah Offline İkonuna) "Bu makineden son 30 saniyede gelen eski veri ölü ve yalandır, sistem düştü. Analitik hesabına katmayın!" raporunu basar.

"Saf (Çıplak) MQTT'nin" Arkasındaki Çirkin Sorun

MQTT, kelime manasıyla içi tamamen "Kusursuz Taşıma Şirketi (Transport Layer)" 'dir. Yolladığınız o harika zarfın içine ne (Hangi mektubu) koyduğunuzu umursamaz. Sahadaki makine, çok yakışıklı, kolay okunacak temiz kurgulu bir JSON {"Sıcaklık":20} yollayabileceği gibi; şifreli berbat bir Binary (1100100) on altılık yığın da kusabilir.

Standardizasyon eksiği; ilk nesil IIoT devrimini tam bir Diller Çöplüğüne ve kaosa (Endüstriyel Babil Kulesi) dönüştürmüştü; sahada veri akıyordu ama yukarıda veriyi toplayan mühendisler datayı tek tek çözmekten (Data-mapping cehennemi) uyku uyuyamıyorlardı.

3. Büyük Dengeleyici Standart: MQTT + Sparkplug B Sinerjisi

"Çıplak (Naked)" MQTT'nin o kaotik Vahşi Batı (Wild West) problematiğinden tamamen arınıp, veriye ciddi bir kural şekli verebilmek için; "Eclipse Foundation" isimli vakıf sektöre bir atom bombası bıraktı: Sparkplug B.

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

Bu tek spesifikasyon (Sparkplug B) kurulduğunda MQTT; mucizevi bir şekilde bir anda OPC UA'nın sunduğu o yapısal olarak tahmin edilebilir (Güvenli Sözlük), anlamsal ciddiyete bürünürken, bir taraftan da Pub/Sub mimarisinin o muazzam hafifliğini ve sonsuz ölçeklenebilir hızını kaybetmemiş olur. Bu kutsal birleşim formülü; şu anda dünyada kurulan tartışmasız modern Sıfır Kesinti Tekil İsim Alanı (UNS) Mimarilerindeki; omurganın ana taşıyıcısıdır.

4. Nihai Karar: Hangi Protokolü Ne Zaman Kullanmalısınız?

Mimarlar için acı ama basit gerçek: 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" acımasızca hibrit olarak kullanın.

Senaryo A: Katı (Kesin) Makineden Makineye Fiziksel Kontrol (Kazanan: OPC UA)

Eğer sahadaki o Tonlarca ağırlıktaki otonom bir Robotik Kaynak Kolu, fiziksel ölümcül 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) "Kesinlikle ve Kesinlikle milisaniye şaşmadan, tam 5 milisaniyede" mesaj gönderip emri geri çekmek gibi agresif, hayati ve sert kapalı döngü (Closed-loop) bir fiziksel işlem yapmak zorundaysa --> Gözü kapalı OPC UA'yı (Veya PROFINET/EtherCAT'i) kullanın. Deterministik (Şaşmaz), ağırdır, fiziksel kontrol için inşa edilmiştir.

Senaryo B: Kurumsal Veri Toplama, AI & Bulut Analitiği Karar Destek Modeli (Kazanan: MQTT + Sparkplug B)

Eğer 4 farklı ülkedeki 300 farklı pres fabrikasından o çok temiz verileri; Merkezi Data Lake'e (Veri Gölüne), Kestirimci (Predictive) Bakım, şirketin toplam Enerji (ISO 50001) maliyeti, OEE Dashboard raporları için saliseler içinde milyon satırlık veriyi internetten boğulmadan kusursuz "Tek Bir Borudan" akıtıp çekmek istiyorsanız --> Kesinlikle 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 devasa ağ ağırlık yükü ve konfigüre edilmesi imkansız bağlantı (Node) karmaşası altında ağlayarak pes edecektir.

5. Proxus Uç Platformu (Edge) Mimarideki O 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 çıkmaz sokakta, o devasa ağır dilleri şifreleyip Uçta hafifletilmesi misyonu için, devrimsel tasarımıyla sahanın ortasına Proxus Edge (Donanım Geçidi/Ağ Yazılım Gateway) donanımı indirilmektedir.

Protokol din savaşlarını bırakın, şirket omurganızı ve verilerinizi (Milyon Doları) hareket ettirmeye odaklanın. Tek bir satır dahi kendi personelinize özel kod yazdırmadan (Custom-code cehennemi); lokal sahadaki katı "OPC UA" ekipmanlarınızın, nasıl bulut/merkez "MQTT Unified Namespace (UNS)" mimarisine devasa veri dökebileceğini Proxus ile test etmek ister misiniz?

Hemen Bir Sistem Mimarına (Demo) Ulaşın →