Unified Namespace mimarisi için uygulamalı rehber

Unified Namespace üzerine yazılanların çoğu, bunun neden iyi bir fikir olduğunu anlatır. Bu rehber ise karardan sonraki kısımla ilgileniyor: yazıya dökmeniz gereken kurallar, sonradan değiştirmesi pahalıya patlayan seçimler ve veri ağacının işe yarayıp yaramadığını gösteren kontroller. Temel fikri bildiğinizi varsayıyoruz. Bilmiyorsanız önce Unified Namespace (UNS) nedir? yazısını okuyup geri dönün. Kurallar üzerinde anlaşıldıktan sonraki iş sırası için UNS'ye geçiş yol haritası yazısına bakın.

Rehber, veri ağacının sorumluluğunu üstlenecek mühendis için yazıldı. Bu kişi genellikle otomasyon ya da OT tarafından gelir ve IT'deki bir veri ekibiyle birlikte çalışır. Mümkün olan her yerde belirli bir üreticiden bağımsız kalmaya çalıştık. Proxus'tan söz ettiğimiz yerlerde amacımız, bir kuralın somut bir uygulamasını göstermek; Proxus'a ihtiyacınız olduğunu savunmak değil.

Gerçekte ne kuruyorsunuz?

Unified Namespace (UNS), tesisin anlık durumunun yerine göre bulunabildiği, düzenli tek bir yerdir: şu kuruluş, şu tesis, şu alan, şu hat, şu makine, şu değer. Veriyi üretenler buraya yayın yapar. Veriyi kullananlar ihtiyaç duydukları kısma abone olur. Kimse veri ağacında zaten bulunan bir sayıyı almak için PLC'ye bağlanmaz.

Uygulamada bir UNS, birlikte çalışan dört parçadan oluşur:

1. Taşıma katmanı. Neredeyse her zaman bir MQTT sunucusu, bazen birkaç tane. Mesajları taşır ve kalıcı (retained) konuların son değerini saklar. Hiçbir şeyin ne anlama geldiğini bilmez.
2. Adlandırma sözleşmesi. Her değerin ağaçta nerede duracağını belirleyen kurallar. İnsanların hatırladığı kısım budur.
3. Veri içeriği sözleşmesi. Belirli bir konudaki mesajın neyi içerdiği: değer, zaman, kalite, birim, tür. İnsanların unuttuğu kısım da budur.
4. Sahiplik ve denetim. Kimin nereye yayın yapabileceği, kimin neyi okuyabileceği, ağaçtaki bir değişikliği kimin onaylayacağı ve veriyi kullananların bir şeyin değiştiğini nasıl öğreneceği.

Diğer üçü olmadan bir MQTT sunucusu, klasör yapısı düzgün bir mesaj yolundan ibarettir. Demoda iş görür, ama birkaç ay içinde dağılır; çünkü her yeni yayıncı kendi kurallarını icat eder. Rehberin geri kalanı, taşıma katmanının üzerinde duran bu üç sözleşmeyi anlatıyor.

Yapıdan önce kapsamı belirleyin

Ağacı çizmeden önce şu üç soruyu yazılı olarak cevaplayın.

Veri ağacına ne girer? Anlık işletme durumu: proses değerleri, makine durumları, sayaçlar, alarmlar, aktif sipariş ya da reçete, belki vardiya. Toplu geçmiş veri, büyük dosyalar ya da zaten bir kayıt sistemi olan işlem kayıtları için kötü bir yerdir (bir ERP satın alma siparişi ERP'de kalmalıdır; numarası bağlam olarak yayınlanabilir).

İlk kullanıcı kim? "Er geç herkes" için tasarlanan bir veri ağacı aslında hiç kimse için tasarlanmamıştır. İlk aylarda onu kullanacak tek bir sistem seçin, örneğin bir OEE panosu ya da bir bakım sistemi, ve önce onun ihtiyaçlarına göre tasarlayın. İkinci ve üçüncü kullanıcılar neyin eksik olduğunu size gösterecektir.

Veri ağacı esas kaynak mı, yoksa esas kaynağın bir görünümü mü? Canlı değerler için genellikle en taze kopyadır, ama asıl otorite PLC olarak kalır. Aktif sipariş gibi bağlam bilgileri için otorite MES ya da ERP'dir. Her veri türü için hangi sistemin esas alındığını yazın. İki sistem birbiriyle çeliştiğinde kimin haklı olduğuna bu liste karar verir.

Hiyerarşiyi tasarlayın

ISA-95 ile başlayın, sonra seviye eklemeyi bırakın

ISA-95 ekipman hiyerarşisi (kuruluş, tesis, alan, hat ya da hücre, ünite ya da ekipman) olağan başlangıç noktasıdır ve bunun iyi nedenleri vardır: bir standarttır, tesislerin örgütlenme biçimiyle örtüşür ve çoğu kişi onu tanır. Kullanın, ama fiziksel bir yer olmayan şeyler için seviye ekleme isteğine direnin.

Sık yapılan bir hata, birkaç farklı boyutu yolun içine katmaktır:

Acme/Izmir/Packaging/Line3/Filler/Production/Shift2/Order_44120/Count

Vardiya ve sipariş birer yer değildir. Birkaç saatte bir değişirler ve onları yola koymak, aynı fiziksel değerin her vardiyada yeni bir konuya taşınması demektir. Eski yola abone olan uygulamalar veri almayı bırakır, geçmiş veri de farklı yollara bölünür. Vardiya ve siparişi kendi değerleri olarak ya da veri içeriğindeki bağlam alanları olarak yayınlayın ve yolu sabit tutun:

Acme/Izmir/Packaging/Line3/Filler/Count
Acme/Izmir/Packaging/Line3/_context/Order
Acme/Izmir/Packaging/Line3/_context/Shift

Pratik kural: Bir yol parçası yalnızca ekipman fiziksel olarak taşındığında, yeniden adlandırıldığında ya da değiştirildiğinde değişmelidir.

Boş seviyelere izin verin

Her tesiste alan olmaz, her makine de bir hücreye ait değildir. Boş bir seviyenin atlanacağına mı (daha kısa yol), yoksa bir yer tutucuyla mı doldurulacağına karar verin. İkisi de işe yarar; ikisini karıştırmak ise yaramaz. Atlamak okumayı kolaylaştırır, ama +/+/+/Count gibi bir joker karakter farklı tesislerde farklı derinliklerle eşleşir. Yer tutucular derinliği sabit tutar ve joker karakterleri öngörülebilir kılar; bunun bedeli de Acme/Izmir/_none/Line3 gibi yollardır.

Proxus'ta her cihaz, yerini isteğe bağlı beş seviyeyle (kuruluş, tesis, alan, hücre, ekipman modülü) taşır ve boş seviyeler konuya yazılmaz. Bu makul bir tercihtir; MQTT dokümantasyonunun beş + içeren bir joker karakterin yalnızca beş seviyesi de dolu olan cihazlarla eşleştiği konusunda uyarmasının nedeni de budur.

Cihazın altında kategorileri ayırın

Her cihaz ya da makine düğümünün altında veri türlerini birbirinden ayırın. En sade ayrım şöyle olabilir:

Proxus değerler için telemetry/<tag>, cihaz durumu için de state/_status ve state/_lastSeen konularını yayınlar; durum konuları kalıcıdır. Adların tam olarak ne olduğu, her yayıncının aynı adları kullanmasından daha az önemlidir.

Köke bir sürüm ekleyin

İlk günden kökün başına bir sürüm parçası (v1/...) koyun. Maliyeti dört karakterdir. Yapıyı veriyi kullananları bozacak şekilde değiştirmeniz gerektiğinde, herkesi bir anda bozmak yerine bir geçiş dönemi boyunca v2/... konularını v1/... ile yan yana yayınlayabilirsiniz. Proxus konularının v1/ ile başlamasının nedeni budur.

Adlandırma kurallarını yazıya dökün

UNS'in güvenilirliğini yitirmesinin en yaygın nedeni adlandırma anlaşmazlıklarıdır. Aynı ağaçta Line1, line_1, L1 ve Linie1 bulunuyorsa, veriyi kullanan her sistem bir eşleme tablosuna ihtiyaç duyar; oysa veri ağacının ortadan kaldırması gereken sorun tam olarak buydu. Kuralları ikinci tesis katılmadan önce yazın.

Sahada ayakta kalan kısa bir kural seti:

• İzin verilen karakterler: harfler, rakamlar, _ ve -. Boşluk yok, ad içinde / yok, + ya da # yok (bunlar MQTT joker karakterleridir), başta $ yok (MQTT sunucusunun sistem konularına ayrılmıştır).
• Büyük-küçük harf: Bir kural seçin ve ona bağlı kalın. MQTT konuları büyük-küçük harfe duyarlıdır: Line1 ve line1 iki ayrı konudur.
• Dil: Çok dilli bir şirkette bile yapısal adlar için tek bir dil kullanın. Görünen adlar arayüzde çevrilebilir; konu adları çevrilmemelidir.
• Birimler ada yazılmaz. Temperature_C değil, Temperature. Birim, bir programın okuyabileceği yerde, veri içeriğinde durmalıdır.
• Adlar verinin nereden geldiğini değil, ne olduğunu anlatır. DB40_DBD12 değil, Speed. PLC adresi, bağlantının bakımını yapanlar için bir üst veridir.
• Ayrılmış önekler: Sistemin ürettiği konular için bir önek (örneğin _) belirleyin ki bunlar hiçbir zaman veri noktası adlarıyla çakışmasın.

Karakter kuralını bir araçla otomatik olarak uygulayın. Örneğin Proxus harfler, rakamlar, _ ve - dışındaki her karakteri _ ile değiştirir; böylece Lyon Foods Plant, Lyon_Foods_Plant olur ve büyük-küçük harf korunur. Platformunuz ne yapıyorsa belgeleyin, çünkü veriyi kullananların arayüzde gördükleri adın her zaman konudaki parçayla birebir aynı olmadığını bilmesi gerekir.

Veri içeriği sözleşmesini tanımlayın

Konu, değerin nereye ait olduğunu söyler. Veri içeriği ise onun ne olduğunu. Veriyi kullanan bir sistem, kimseye sormadan mesajı işleyebilmelidir; bu da bir telemetri konusundaki her mesajın aynı alanları taşıması demektir.

Uygulamada en az şunlar bulunmalıdır:

{
  "ts": "2026-10-16T08:14:22.410Z",
  "value": 72.4,
  "dataType": "Double",
  "unit": "°C",
  "quality": "Good"
}

Zaman damgası. UTC, ISO 8601 ve milisaniye kullanın. Bunun hangi zaman olduğunu yazın: sensörün ölçtüğü an mı, PLC'nin sakladığı an mı, yoksa Edge Gateway'in okuduğu an mı? Sorgulamayla çalışan bir bağlantıda bunlar arasında saniyelerce fark olabilir ve olayların sırasını belirlemek için bu önemlidir. Proxus, Edge Gateway'in değeri okuduğu anı kullanır.

Değer ve tür. Değeri doğal JSON türünde (sayı, boolean, metin) yayınlayın ve türü açıkça belirtin. 1 değerini alan bir sistem, bunun bir tam sayı sayaç mı, yoksa PLC'nin word olarak sakladığı bir boolean mı olduğunu anlayamaz.

Birim. Birimi her mesajda ya da veri noktası başına kalıcı bir üst veri konusunda taşıyın. Her mesajda bulunması birkaç bayta mal olur, ama bir dizi hatanın önüne geçer.

Kalite. Okuma başarısız olduğunda veriyi kullananın ne göreceğine karar verin. İki dürüst seçenek vardır: mesajı Bad kalitesiyle ve güvenilir bir değer olmadan yayınlamak ya da hiçbir şey yayınlamayıp cihazın çevrim dışı olduğunu durum konusunun göstermesini sağlamak. Dürüst olmayan seçenek, son geçerli değeri yeni bir zaman damgasıyla tekrar yayınlamaktır. Proxus telemetri konularında ikinci seçeneği uygular: okunamayan değerler bu konulara yayınlanmaz, okuma hatalarını cihaz sayfası gösterir.

Bağlam. Yerin tamamını (kuruluş, tesis, alan) her veri içeriğinde tekrarlamak mesajları büyütür, ama mesajları konusuz saklayan bir sistemin bile verinin nereden geldiğini bilmesini sağlar. Pek çok ekip veri noktası başına konularda sade bir veri içeriği, cihaz başına da daha zengin bir özet mesaj yayınlar. Proxus bunu, bir cihazın tüm veri noktalarının son değerini tutan bir _summary konusuyla ve her veri noktası mesajına bir context nesnesi ekleme seçeneğiyle yapar.

JSON mu, Sparkplug B mi? JSON'un okuması ve hata ayıklaması kolaydır, her yerde desteklenir. Sparkplug B ise tanımlı bir oturum modeli (doğum ve ölüm, yani birth ve death mesajları), türü belli metrikler ve kompakt Protocol Buffers veri içerikleri getirir. Farklı üreticilerin sistemleri özel bir sözleşme olmadan birlikte çalışmak zorundaysa ya da bant genişliği kısıtlıysa Sparkplug B'yi seçin; iki ucu da siz kontrol ediyorsanız ve okunabilirliği önemsiyorsanız JSON'u seçin. İkisini birden de sunabilirsiniz: Proxus varsayılan olarak JSON yayınlar, bir Edge Gateway'in MQTT sunucusunda bunun yerine Sparkplug B yayınlayabilir ve veriyi dışarıdaki uygulamalara Sparkplug B olarak gönderebilir. Başka düğümlerden Sparkplug B verisi almaz.

Durumu açıkça gösterin

Bir veri ağacı ancak veriyi kullanan sistem "değer 0" ile "bu makineden bir saattir haber yok" arasındaki farkı anlayabiliyorsa işe yarar.

Bunun büyük kısmını üç mekanizma karşılar:

1. Kalıcı durum konuları. Online ya da Offline değerini taşıyan kalıcı bir state/_status mesajı, sonradan bağlanan bir sistemin bir sonraki değişikliği beklemeden durumu hemen öğrenmesini sağlar.
2. Son görülme zamanı. En son okumanın zamanını taşıyan kalıcı bir state/_lastSeen konusu, veriyi kullananın bir değerin eskiyip eskimediğine kendisinin karar vermesini sağlar. Her sistemin toleransı farklıdır: bir pano bir dakikalık gecikmeyi kabul edebilir, bir alarm kuralı edemeyebilir.
3. Last Will and Testament. Bir MQTT istemcisi, vedalaşmadan bağlantısı koparsa MQTT sunucusunun yayınlayacağı bir mesaj kaydedebilir. MQTT sunucusuna doğrudan bağlanan yayıncılar için bunu kullanın; böylece ortadan kaybolduklarında durumları çevrim dışına döner.

Telemetri ve olayları varsayılan olarak asla kalıcı yapmayın. Kalıcı bir alarm, her yeni aboneye o anda olmuş gibi yeniden gönderilir.

Birden fazla MQTT sunucusu için plan yapın

Tek bir tesiste tek bir MQTT sunucusu işi basit tutar. Birkaç tesis söz konusu olduğunda ise veri ağacının fiziksel olarak nerede duracağına karar vermeniz gerekir.

• Tek merkezi MQTT sunucusu. Her tesis ona yayın yapar. Anlaşılması kolaydır, ama her tesis kendi veri ağacı için WAN'a bağımlı olur ve merkezi sunucu tüm trafiği görür.
• Her tesise bir MQTT sunucusu, aralarında köprü. Her tesisin kendi MQTT sunucusu vardır; bir köprü seçilen dalları merkezi bir sunucuya iletir. WAN çöktüğünde tesisler çalışmaya devam eder. Bedeli köprü yapılandırması ile döngü ya da mükerrer dal riskidir.
• Her Edge Gateway'e bir MQTT sunucusu. Her Edge Gateway, okuduğu cihazlar için bir MQTT sunucusu çalıştırır. Yerel uygulamalar doğrudan ona bağlanır; merkezi görünüm başka bir yerde oluşturulur.

Proxus üçüncü kalıbı izler: her Edge Gateway kendi MQTT sunucusunu çalıştırır ve yalnızca kendi cihazlarını yayınlar; her değer ayrıca ara belleği olan ayrı bir mesaj sunucusu üzerinden merkez sunucuya ulaşır. Geçmiş veri, panolar ve Veri ağacı (UNS) ekranı, tüm tesisi merkez sunucuda gösterir; bu görünümü Proxus'ta ortak veri modeli (UNS) sayfasında görebilirsiniz. Hangi kalıbı seçerseniz seçin, hangi dal için hangi MQTT sunucusunun esas alındığını yazın ki iki yayıncı hiçbir zaman aynı konu için çekişmesin.

Veri ağacını koruyun

Ağdaki herkesin okuyabildiği bir veri ağacı, tesisinizin ve anlık durumunun haritasıdır. Ona göre davranın.

• Taşıma katmanını şifreleyin. TLS üzerinden MQTT kullanın (geleneksel olarak 8883 numaralı port) ve istemcilerin MQTT sunucusunun sertifikasını kendi kontrolünüzdeki bir CA ile doğrulamasını sağlayın. Şifresiz portu yalnızca TLS desteklemeyen cihazlar için açık tutun ve ilk fırsatta kapatın.
• Her istemcinin kimliğini doğrulayın. Üretimde anonim bağlantı olmasın. Ortak bir parola yerine her sisteme ayrı bir kimlik bilgisi verin; böylece birinin erişimini diğerlerine dokunmadan iptal edebilirsiniz.
• Her kimliğin neyi görebileceğini sınırlayın. MQTT sunucusu düzeyindeki erişim listeleri (ACL) üreticiden üreticiye çok farklıdır; bazıları konu bazında kuralları destekler, bazıları desteklemez. Sizinkinin neyi desteklediğini bilin. Proxus'ta Edge Gateway'in MQTT sunucusu, Edge Gateway'in ana erişim anahtarını ya da bir cihazın kendi erişim anahtarını kabul eder ve konu bazında yetki tanımlamaz; bu yüzden ana erişim anahtarı yalnızca güvenilir sistemlere verilmelidir. Dal bazında görünürlük bunun yerine platformda uygulanır: UNS izinleri bir rol için bir yola izin verir ya da onu engeller ve kişiler, entegrasyonlar ve yapay zekâ istemcileri için aynı şekilde geçerlidir.
• Okumayı yazmadan ayırın. Veri ağacına bir değer yayınlamakla bir makineye ayar değeri yazmak farklı işlerdir. Veri ağacındaki bir konunun denetimsiz bir şekilde kontrolöre giden yola dönüşmesine izin vermeyin. Yazma gerekiyorsa, ona kendi komut modelini, yetkilendirmesini, doğrulamasını ve değişiklik kaydını verin.

Sorumluları belirleyin

Ağacın her dalının, o daldaki değişiklikleri onaylayan bir sorumlusu olmalıdır. Uygulamada:

Yapısal bir değişikliğe veritabanı şeması değişikliği gibi yaklaşın: yazıya dökün, gerçekleşmeden önce veriyi kullananlara duyurun, mümkünse eskiyi ve yeniyi paralel çalıştırın ve eski yolu ancak onu kullanan hiçbir sistem kalmadığında kaldırın.

Aşama aşama devreye alın

Bir ürün gibi test edin

Veri ağacı, başka sistemlerin dayandığı bir altyapıdır. Onu buna göre test edin.

• Sözleşme testleri. Bir saat boyunca v1/# konusuna abone olan ve adlandırma kuralını çiğneyen her konuyu, eksik alanı olan her veri içeriğini ve beklenmedik her tür değişikliğini raporlayan küçük bir betik. Her değişiklikten sonra çalıştırın.
• Eskimiş veri testi. Bir cihazın bağlantısını bilerek kesin. Durumunun değiştiğini, son görülme zamanının durduğunu ve hiçbir uygulamanın eski değeri güncelmiş gibi göstermeye devam etmediğini kontrol edin.
• Kesinti testi. Bir tesisle merkez arasındaki bağlantıyı kesin. Yerel uygulamaların neyi görmeye devam ettiğini, merkezi görünümün ne gösterdiğini ve kesinti sırasındaki verinin sonradan orijinal zaman damgalarıyla gelip gelmediğini kontrol edin. Proxus'un bu durumda ne yaptığını Veri akışı sayfası anlatıyor.
• Yeni kullanıcı testi. Veri ağacı dokümantasyonunu onu hiç görmemiş birine verin ve bir hattaki tüm sıcaklıklara abone olmasını isteyin. Bir soru sorması gerekiyorsa, dokümantasyonda ya da yapıda bir boşluk vardır.

Bitti demeden önce kontrol listesi

• Hiyerarşi yazıya dökülmüş; her seviye için örnek bir yol ve boş seviyeler için kural belli.
• Adlandırma kuralları yazılı ve hafızaya değil, bir araca dayanarak uygulanıyor.
• Her telemetri veri içeriği zaman, değer, tür, birim ve kalite taşıyor; zamanın neyi ifade ettiği belgelenmiş.
• Durum ve son görülme konuları kalıcı; telemetri ve olaylar değil.
• Taşıma katmanı TLS kullanıyor, her istemcinin kendi kimlik bilgisi var ve MQTT sunucunuzun konu bazında neyi kısıtlayıp neyi kısıtlayamadığını biliyorsunuz.
• Her dalın bir sorumlusu var ve yapısal değişiklikler yazılı bir süreci izliyor.
• En az iki farklı kullanıcı, makinelere kendi bağlantısını kurmadan veri ağacını kullanıyor.

İlgili yazılar

• UNS'ye geçiş yol haritası: pilot hattan tüm tesise beş aşama, bu kuralları ilk pilot hattan mevcut sistemlerin taşınmasına kadar bir sıraya koyuyor.
• Modern IIoT'de SCADA ve Unified Namespace (UNS) hangi rolü üstlenir? yazısı, SCADA'yı pek çok kullanıcıdan biri olarak çalıştırmayı inceliyor.
• OPC UA'dan MQTT'ye yazısı, kaynak bir OPC UA sunucusu olduğunda verinin anlamının nasıl korunacağını anlatıyor.
• Bu sözleşmeleri tutacak yazılımı mı seçiyorsunuz? Proxus ve HighByte karşılaştırması, mevcut sistemlerin üzerinde duran bir modelleme katmanını; veri toplama, modelleme, depolama ve aktarımı tek kurulumda sunan bir platformla karşılaştırıyor.
• Proxus dokümantasyonunda: Unified Namespace, MQTT ve UNS konuları, Veri ağacı (UNS) ve UNS izinleri.