OPC UA'dan MQTT'ye saha verisini anlamını kaybetmeden taşımak

Bir OPC UA sunucusundaki değerleri MQTT sunucusuna aktarmak kolaydır. Birkaç satır kod bir düğümü okur ve sayıyı yayınlar. Asıl zor olan, o değerlerin anlamını da taşımaktır. Köprülerin çoğu, kimse fark etmeden tam bu noktada başarısız olur. Sayılar karşı tarafa ulaşır, ama veriyi kullanan hiç kimse değerin hangi birimde olduğunu söyleyemez. Okumanın geçerli olup olmadığı, ne zaman alındığı ve hangi makineye ait olduğu da bilinmez.

Bu rehber o ikinci sorunu ele alıyor. Bir OPC UA sunucusunda gerçekte hangi bilgilerin bulunduğunu, MQTT'nin bunları taşımak için ne sunduğunu, arada verilmesi gereken eşleme kararlarını ve bir şeyin kaybolup kaybolmadığını gösteren testleri anlatıyor. Rehber belirli bir üreticiye bağlı değil; Proxus'tan söz ettiğimiz yerlerde, anlatılan seçimlerin somut bir örneğini veriyoruz. İki protokolün daha geniş bir karşılaştırması için Modern IIoT'de MQTT ve OPC UA yazımıza göz atabilirsiniz.

Neden köprü kurulur?

OPC UA ve MQTT farklı sorunları çözer. OPC UA, istemci-sunucu mantığıyla çalışan zengin bir protokoldür: istemci tek bir sunucuya bağlanır, adres alanında gezinir, değer okur ve yazar, metot çağırır, değişikliklere abone olur. Tek bir makineyle ya da tek bir SCADA sunucusuyla konuşmak için mükemmeldir. Ancak üç ayrı ağdaki on sistemin aynı değeri istediği durumlara pek uymaz. Bu sistemlerin her biri kendi oturumunu, kendi sertifika güvenini ve fabrika ağına kendi erişim yolunu ister.

MQTT ise yayınla-abone ol mantığıyla çalışan bir taşıma katmanıdır. Ortada bir MQTT sunucusu durur; veriyi üretenler konulara yayın yapar, kullananlar bu konulara abone olur. Veriyi kullanan yeni bir sistem eklemek makineye ek yük getirmez. Fabrikaların köprü kurmasının nedeni budur. Yapısı ve güvenlik modeli sahaya uyduğu için tesis tarafında OPC UA kullanılır; diğer sistemlere doğru ise MQTT çoğunlukla bir Unified Namespace taşıyıcısı olarak çalışır.

Verinin anlamı ya bu köprüde korunur ya da bu köprüde kaybolur.

OPC UA hangi bilgileri taşır?

Eşlemeye başlamadan önce kaynağın size ne verdiğini listeleyin. Tipik bir OPC UA sunucusu, her değişken düğümü için şunları sunar:

Her sunucu bu öğelerin hepsini doldurmaz. Bir PLC'nin yerleşik OPC UA sunucusu yalnızca adları, türleri ve değerleri sunabilir; bir companion specification üzerine özenle kurulmuş bir sunucu ise birimleri, aralıkları ve nesne türlerini de verebilir. İlk iş, sunucularınızın bunlardan hangilerini gerçekten sağladığını öğrenmektir. Bunun için sunucuda genel amaçlı bir istemciyle gezinin ve ne bulduğunuzu not edin.

MQTT bu bilgileri taşımak için ne sunar?

MQTT'nin kendisi çok az şey taşır: bir konu (metin), bir veri içeriği (bayt dizisi), bir QoS seviyesi ve bir retain bayrağı. MQTT 5 bunlara kullanıcı özelliklerini ve içerik türünü ekler. Geri kalan her şeyi sizin tasarlamanız gerekir:

• Konu, verinin yerini ve kimliğini taşıyabilir.
• Veri içeriği, değeri, zamanı, kaliteyi, türü ve birimi taşımak zorundadır.
• Kalıcı (retained) üst veri konuları, birim, aralık ve açıklama gibi seyrek değişen bilgileri taşıyabilir.
• Sparkplug B, bunların çoğu için hazır bir yapı tanımlar: türü belli metrikler, her metriği tanıtan birth mesajları, kalite ve birim için özellikler.

Köprünün görevi, her OPC UA öğesini bunlardan birine yerleştirmektir.

Hiyerarşinin nasıl eşleneceğine karar verin

Bir OPC UA adres alanını konulara dönüştürmenin iki yolu vardır ve bu seçim sonraki her şeyi etkiler.

Sunucunun yapısını aynen kopyalamak

Her düğümü, sunucudaki gezinme yolunu kopyalayan bir konu altında yayınlarsınız:

opcua/plc-line1/Objects/PLC_1/DataBlocks/DB_Filler/Speed

Bu yöntem hızlıdır, modelleme gerektirmez ve kaynakla bire bir bağı korur. Öte yandan PLC'nin iç yapısını veriyi kullanan herkese açar. PLC programcısı veri bloklarını yeniden düzenlediğinde konular değişir ve onları kullanan uygulamalar bozulur. Makinesi aynı ama PLC programı farklı iki hatta, aynı ölçüm iki farklı konuya düşer.

Tesis modeline göre eşlemek

Her değeri, sunucunun onu nasıl düzenlediğinden bağımsız olarak, tesisteki yerine göre yayınlarsınız:

v1/Acme/Izmir/Packaging/Line1/Filler/telemetry/Speed

Bu yöntem başta daha çok emek ister, çünkü birinin her değerin nereye ait olduğuna karar vermesi gerekir. Karşılığında veriyi kullananlar tesisle örtüşen kararlı bir yapı görür. Aynı makine tipi her hatta aynı görünür ve PLC'deki bir değişiklik her uygulamada değil, yalnızca köprünün yapılandırmasında karşılanır.

Birden fazla uygulamanın kullanacağı her veri için tesis modelini kullanın. Arıza teşhisi için bir görünüm ya da kısa süreli bir test için sunucuyu kopyalamak yeterlidir. Bakım mühendisleri kaynağı yine de bulabilsin diye NodeId'yi veri noktasının üst verisi olarak saklayın.

Proxus'ta her OPC UA sunucusu (OPC UA sürücüsüyle okunur), tesis yapısında (kuruluş, tesis, alan, hücre, ekipman modülü) yeri olan bir cihaza dönüşür; seçtiğiniz düğümler de bu cihazın veri noktaları olur. Veri noktasının adresi NodeId'dir. Konu ise sunucudaki gezinme yolundan değil, bu yerden, cihaz adından ve veri noktasının adından oluşturulur. Sunucuda gezinmeyi ve düğüm seçmeyi OPC UA rehberi adım adım anlatıyor.

Veri içeriğini tasarlayın

Bir telemetri konusundaki mesaj, başka bir açıklamaya ihtiyaç duymadan anlaşılmalıdır. OPC UA'daki önemli bilgileri koruyan en sade veri içeriği şuna benzer:

{
  "ts": "2026-10-16T08:14:22.395Z",
  "value": 82.4,
  "dataType": "Double",
  "unit": "rpm",
  "quality": "Good"
}

Aşağıdaki bölümler en çok sorun çıkaran alanları ele alıyor.

Hangi zaman damgasını kullandığınızı açıkça belirtin

OPC UA'dan okunan bir değer için en az üç aday zaman vardır: SourceTimestamp, ServerTimestamp ve köprünün değeri aldığı an. Sorgulamayla çalışan bir bağlantıda aradaki fark bir sorgulama aralığının tamamı kadar olabilir; yoğun bir sunucuda daha da fazla. Saniye çözünürlüklü trendlerde bu pek fark etmez. Ama olay sırası analizinde ("basınç vana kapanmadan önce mi düştü, sonra mı?") cevabı tam olarak bu fark belirler.

Birini seçin, belgeleyin ve adını açıkça koyun. Sunucu anlamlı bir kaynak zamanı veriyorsa, mümkünse onu taşıyın. Köprünüz kendi okuma zamanını kullanıyorsa bunu açıkça belirtin; aksi hâlde veriyi kullananlar bunun kaynak zamanı olduğunu varsayar. Örneğin Proxus her değere Edge Gateway'in onu okuduğu anı yazar. Bu, tüm protokollerde tutarlıdır ama OPC UA'daki SourceTimestamp değildir.

Tüm zamanlar UTC olmalı ve sonunda açık bir Z ya da saat farkı bulunmalıdır. Saat farkı belirtilmemiş yerel saat, yılda iki kez bir saatlik hataların bilinen kaynağıdır.

Hatalı değeri geçerliymiş gibi göstermeyin

OPC UA'daki StatusCode'ların üç önem seviyesi (Good, Uncertain, Bad) ve çok sayıda alt kodu vardır. Siz eklemedikçe MQTT'de bunun bir karşılığı yoktur. En kötü sonuç, durumu atıp değeri sorunsuzmuş gibi yayınlayan bir köprüdür. O zaman Bad_SensorFailure durumundaki 0.0 okuması gerçek bir sıfırdan ayırt edilemez.

Savunulabilir iki yaklaşım vardır:

1. Durumu taşımak. Veri içeriğinde en azından Good, Uncertain ve Bad ayrımını yapın; isterseniz arıza teşhisi için orijinal kodu da saklayın. Belirsiz değerlerle ne yapılacağına veriyi kullanan sistem karar verir.
2. Yalnızca geçerli değerleri yayınlamak, hataları başka yerde göstermek. Hatalı okumalar değer olarak yayınlanmaz; okumanın başarısız olduğunu bir durum konusu ya da cihaz durumu gösterir. Veriyi kullananlar hiçbir zaman hatalı değer görmez, ama "değişmedi" ile "bilinmiyor" arasındaki farkı anlamak için durumu kontrol etmeleri gerekir.

Proxus, UNS telemetri konularında ikinci yaklaşımı uygular: okunamayan değerler bu konulara yayınlanmaz, okuma hataları cihaz sayfasında ve cihazın durumunda görünür. Hangi yaklaşımı seçerseniz seçin, bir boşluğu doldurmak için son geçerli değeri yeni bir zaman damgasıyla asla tekrarlamayın.

Veri türlerinde sınır durumlara dikkat edin

OPC UA'nın tür sistemi JSON'unkinden daha zengindir. Şunlara açıkça karar vermeniz gerekir:

• Tam sayı genişlikleri. 2^53'ün üzerindeki UInt64 değerleri, birçok dilde JSON sayısı olarak işlendiğinde hassasiyet kaybeder. Bu kadar büyüyebilecek değerleri metin olarak gönderin ya da bu kadar büyümeyeceklerinden emin olun.
• Tam sayı olarak saklanan mantıksal değerler. Bazı PLC'ler bir durum bitini Int16 olarak sunar. Anlamı buysa, köprüde boolean'a çevirin; böylece veriyi kullananların bunu bilmesi gerekmez.
• Diziler ve yapılar. Bir yapı (OPC UA ExtensionObject) ya da dizi tek bir JSON nesnesi olarak yayınlanabilir, her üye için ayrı bir konuya bölünebilir ya da metne dönüştürülebilir. Bölmek, veriyi kullananlar için en kolayıdır; tek nesne ise üyelerin birbiriyle tutarlı kalmasını sağlar. Her durum için ayrı karar verin.
• DateTime değerleri. Bunları UTC'de ISO 8601 metni olarak yayınlayın.

Türü veri içeriğinde belirtin. Proxus'ta OPC UA türleri veri noktasında Proxus türlerine eşlenir (Boolean'dan Bool'a, Int32'den Int'e, Double'dan Double'a ve OPC UA rehberinde listelenen diğerleri); diziler ve doğrudan karşılığı olmayan türler metin olarak okunur. UNS veri içeriği de taşıdığı türü belirtir (Bool, Int, Long, Float, Double, DateTime ya da String).

Birimler ve aralıklar

Sunucu EngineeringUnits tanımlamışsa birimleri karşıya taşıyın. Tanımlamamışsa (PLC sunucularında bu sık görülür), veri noktasını oluştururken birimi köprünün yapılandırmasına ekleyin. Birimi olmayan bir değer, er ya da geç birinin yanlış okuyacağı bir değerdir. Aralıklar (EURange) doğrulama ve gösterge ölçeklendirme için işe yarar; veriyi kullananlar bunlara ihtiyaç duyuyorsa kalıcı bir üst veri konusunda yayınlayın.

Sunucuda olmayan bilgiler

Bazı bilgiler OPC UA sunucusunda hiç yer almaz: üretilen sipariş, ürün, vardiya. Bunları her değerin veri içeriğine zorla sokmaya çalışmayın. Hat ya da makine düğümünde, bu bilginin sahibi olan sistemden (MES, ERP ya da operatör girişi) kendi kalıcı konuları olarak yayınlayın. Veriyi kullananlar bunları telemetriyle zaman ve yer üzerinden birleştirsin.

Sunucu sorgulamayla mı, abonelikle mi okunmalı?

OPC UA değerleri almak için iki yol sunar: değerleri belirli bir takvime göre okumak ya da izlenen öğelerle bir abonelik oluşturup değişiklikleri sunucunun göndermesini beklemek.

Abonelikler, yavaş değişen çok sayıda değer için verimlidir. Sunucu örnekleme aralığında örnek alır ve yayın aralığında bildirim gönderir. İstenirse bildirim yalnızca değer belirli bir ölü bandı aştığında gider. Aboneliklerin dikkat isteyen ayarları vardır: kuyruk boyutu, örnekleme aralığı, yayın aralığı, keep-alive ve lifetime sayaçları. Yanlış yapılandırılmış bir abonelik, ara değerleri sessizce kaybeder ya da takılıp kalır.

Sorgulama (tüm veri noktalarını sabit bir aralıkla birlikte okumak) daha basittir ve tamamen öngörülebilirdir: her aralıkta bir okuma, sunucuya bilinen bir yük. Öte yandan değişmemiş değerleri de okur ve iki okuma arasındaki çok kısa darbeleri kaçırabilir.

Hiçbiri her durumda daha iyi değildir. Kısa süreli değişiklikleri yakalamanız gerekiyorsa ve sunucunun abonelik desteği iyiyse aboneliği seçin; öngörülebilirliği önemsiyorsanız ya da sunucunun abonelik desteği zayıfsa sorgulamayı seçin. Proxus OPC UA cihazlarını sorgulayarak okur: Edge Gateway, cihazın tüm veri noktalarını her Read every aralığında bir kez birlikte okur ve abonelik kullanmaz. Aralığı, değerlerin ne kadar güncel olması gerektiğine göre ayarlayın; bundan kısa süren olaylar için PLC tarafında bir mandal ya da sayaç kullanın.

Karşı tarafa yalnızca değişiklikleri göndermek

OPC UA tarafında ister sorgulayın ister abone olun, her okumaya ihtiyaç duymayan uygulamalar için trafiği azaltmak amacıyla MQTT'ye yalnızca değişiklikleri yayınlayabilirsiniz. MQTT tarafındaki ölü bantlara dikkat edin: ölü banttan daha az değişen bir değer hiç yayınlanmaz, bu yüzden veriyi kullanan sistem "sabit" ile "takılı kalmış" arasındaki farkı anlayamaz. Bir azami raporlama aralığı (değişiklik olmasa bile en geç her N saniyede bir yayınlamak) bu sorunu çözer. Proxus'ta cihaz başına UNS konuları her okumayı taşır; her veri hedefinin ise kendi aktarım stratejisi vardır: her değer, yalnızca değişen değerler ya da yalnızca bir işlem akışının ona gönderdikleri.

İki tarafta da güvenlik

Köprü iki ayrı güvenlik alanını birbirine bağlar ve her tarafın kendi kuralları vardır.

OPC UA tarafı

• Güncel bir güvenlik politikasıyla Sign ya da Sign & encrypt kullanın. None, ağdaki herkesin değerleri okumasına ve değiştirmesine olanak tanır; onu test tezgâhlarına bırakın.
• Güven iki yönde kurulmalıdır: köprü sunucunun sertifikasına, sunucu da köprünün sertifikasına güvenmelidir. İlk bağlantıda sunulan sertifikayı olduğu gibi kabul etmek yerine, güvenmeden önce parmak izlerini karşılaştırın.
• Güven kararlarını tek bir yerde tutun. On köprünün her biri kendi güven listesini tutuyorsa, ele geçirilmiş bir sertifikayı iptal etmek her köprüyü tek tek aramaya dönüşür. Proxus'ta merkez sunucudaki Sertifika deposu, OPC UA sunucu sertifikalarının güvenilir sayıldığı ya da reddedildiği tek yerdir ve her Edge Gateway bir dakika içinde bu karara uyar.
• Yalnızca okuma yapan bir köprü için sunucuda salt okuma yetkisi olan ayrı bir OPC UA kullanıcısı tercih edin.

MQTT tarafı

• TLS kullanın (geleneksel olarak 8883 numaralı port) ve MQTT sunucusunu kendi kontrolünüzdeki bir CA ile doğrulayın.
• MQTT sunucusu destekliyorsa, veriyi kullanan her uygulamaya ayrı bir kimlik bilgisi verin.
• MQTT sunucunuzun konu bazında neleri kısıtlayabildiğini bilin. Bazı sunucularda konu bazında erişim listeleri (ACL) vardır, bazılarında yoktur. Sizinkinde yoksa, kimlik bilgisini kimin alacağını baştan sınırlayın; daha ince görünürlük kurallarını insanlara ve uygulamalara hizmet veren platformda uygulayın.
• Köprüyü denetimsiz bir yazma yoluna dönüştürmeyin. OPC UA'dan okuyup MQTT'ye yayınlamak tek yönlü bir iştir. Bir uygulamanın makineye geri yazması gerekiyorsa, bu kendi yetkilendirmesi, doğrulaması ve kayıt tutması olan ayrı bir yoldur.

Sparkplug B mi, düz JSON mu?

Sparkplug B, MQTT üzerine kurulu bir spesifikasyondur; konuları, veri içeriğinin kodlanmasını (Protocol Buffers) ve oturum durumunu standart hâle getirir. Bir Sparkplug edge node önce göndereceği her metriği türleri ve özellikleriyle tanıtan birth mesajlarını, ardından değerleri taşıyan veri mesajlarını yayınlar; bağlantısı koptuğunda da bir death mesajı gönderir.

Farklı üreticilerin uygulamaları özel bir sözleşmeye gerek kalmadan birbirini anlamak zorundaysa ya da bant genişliği önemliyse Sparkplug B iyi bir seçimdir. Ancak kendi kurallarını da beraberinde getirir: sıra numaraları, rebirth istekleri ve durumu takip eden host uygulamaları. Belgelenmiş bir şemaya sahip düz JSON ise okuması ve hata ayıklaması daha kolaydır; iki ucu da sizin kontrolünüzdeyse yeterlidir.

Bazı köprülerde bu seçim MQTT sunucusu bazında yapılabilir. Proxus varsayılan olarak JSON yayınlar; Edge Gateway'in UNS veri içeriği biçimini Sparkplug B olarak ayarladığınızda bunun yerine Sparkplug B 3.0 yayınlar. Bu durumda her cihaz bir Sparkplug cihazı olur ve her metrik kaynak, kalite ve birim özelliklerini taşır. Sparkplug B, başka bir sisteme veri hedefi olarak da kullanılabilir. Proxus başka düğümlerden Sparkplug B verisi almaz; yalnızca yayınlar.

Bağlantı koptuğunda

Köprü, fabrika ağıyla daha geniş bir ağın arasında durur ve o geniş ağ bağlantısı zaman zaman kopacaktır. Şunlara önceden karar verin:

• Değerler nerede bekleyecek? Ara belleği olmayan bir köprü, kesinti sırasında okunan her şeyi kaybeder. Ara belleği olan bir köprü ise bu değerleri daha sonra, orijinal zaman damgalarıyla gönderebilir.
• Ne kadar bekleyecekler? Ara belleğin sınırını disk kapasitesi ve sizin belirlediğiniz kural çizer. Atlatmanız gereken en uzun kesintiye göre boyutlandırın.
• Yeniden gönderimde veriyi kullananlar ne görecek? Ara bellekte bekleyen değerler geç ve topluca gelir. Her mesajın "şimdi" üretildiğini varsayan uygulamalar onları yanlış zamana yerleştirir; veriyi kullananlar veri içeriğindeki zaman damgasını esas almalıdır.
• Mükerrer mesajlar. Ara belleğe dayalı aktarımın çoğu "en az bir kez" esasına göre çalışır. Bağlantı yeniden kurulduktan sonra bir uygulama aynı mesajı iki kez görebilir. Yazma işlemlerini, örneğin cihaz, veri noktası ve zaman damgası üzerinden anahtarlayarak tekrarlansa da sonucu değiştirmeyecek şekilde kurun.

Proxus'ta değerler her Edge Gateway'den merkez sunucuya ara bellekli bir mesaj sunucusu üzerinden gider: varsayılan olarak 48 saat, Edge Gateway başına 30 güne kadar saklanır ve orijinal okuma zamanlarıyla yeniden gönderilir. MQTT sunucuları dâhil veri hedefleri de aynı saklama süresiyle Edge Gateway'de kuyruğa alınır; hedef yeniden erişilebilir olduğunda sırasıyla ve en az bir kez yazılır. Ara belleğe almayı ve eksik verinin sonradan tamamlanmasını uçta geçmiş veri deposu rehberi ayrıntısıyla anlatıyor.

Verinin anlamının korunduğunu test edin

Köprünün bittiğini ilan etmeden önce, her bilgi türünü uçtan uca kontrol edin:

1. Kimlik. Beş değer seçin. Tesisi bilen biri yalnızca MQTT konusuna bakarak her birinin hangi makineye ve hangi ölçüme ait olduğunu söyleyebiliyor mu?
2. Birimler. Her telemetri veri içeriği ya da onun üst veri konusu bir birim taşıyor mu? Birkaçını operatör panelindekiyle karşılaştırın.
3. Zaman. PLC'de bilinen bir anda bir değeri değiştirin ve MQTT veri içeriğindeki zaman damgasıyla karşılaştırın. Aradaki fark belgelediğiniz gibi mi?
4. Kalite. Bir sensörün bağlantısını kesin ya da OPC UA sunucusunu durdurun. Veriyi kullananlar ne görüyor: hatalı kalite mi, mesajın kesilmesi ve çevrim dışı durumu mu, yoksa yeni zaman damgalı eski değer mi? Yalnızca sonuncusu yanlıştır.
5. Türler. Bir boolean, bir tam sayı, büyük bir sayaç ve bir metin değerini kontrol edin. Doğru JSON türleriyle mi geliyorlar?
6. Kesinti. Köprüyle MQTT sunucusu arasındaki ağı bir sorgulama aralığından daha uzun süre kesin. Kesinti sırasındaki değerler sonradan, orijinal zamanlarıyla geliyor mu?

Kontrol listesi

• Her kaynak sunucuda gezindiniz ve gerçekte hangi bilgileri sağladığını kayıt altına aldınız.
• Konular sunucunun gezinme yolunu değil tesis modelini izliyor; NodeId, veri noktasının üst verisi olarak saklanıyor.
• Her veri içeriği zaman, değer, tür, birim ve kalite taşıyor; zamanın neyi ifade ettiği belgelenmiş.
• Hatalı okumalar hiçbir zaman geçerli değer olarak görünmüyor.
• Büyük tam sayılar, tam sayı olarak saklanan mantıksal değerler, diziler ve yapılar için yazılı bir eşleme kuralı var.
• OPC UA bağlantıları Sign ya da Sign & encrypt kullanıyor ve güven ayarları tek bir yerden yönetiliyor.
• MQTT tarafında TLS ve her uygulama için ayrı kimlik bilgisi kullanılıyor; konu bazındaki sınırlar biliniyor.
• Köprü kesintiler boyunca veriyi ara belleğe alıyor; veriyi kullananlar geç ve mükerrer gelen mesajlarla başa çıkabiliyor.

İlgili yazılar

• Modern IIoT'de MQTT ve OPC UA: iki protokolün artıları ve eksileri, daha ayrıntılı.
• Unified Namespace mimarisi için uygulamalı rehber: köprünün beslediği veri ağacı için adlandırma, veri içeriği ve sahiplik kuralları.
• IIoT'de depola ve ilet: ara belleğe dayalı aktarımın arkasındaki yöntem.
• Halihazırda Kepware gibi bir OPC sunucusu mu çalıştırıyorsunuz? Proxus ve Kepware karşılaştırması, bir bağlantı sunucusunun nerede bitip bir veri katmanının nerede başladığını ve ikisinin birlikte nasıl çalıştığını anlatıyor.
• Proxus dokümantasyonunda: OPC UA sunucusu bağlama, MQTT ve UNS konuları, Sertifikalar ve protokol başvuru kılavuzu.