Unified Namespace (UNS) nedir?

Unified Namespace (UNS), yani ortak veri modeli, bir tesisteki her sistemin güncel işletme verisini yayınladığı ve diğer her sistemin bu veriyi okuduğu, tek ve düzenli bir yerdir. Her değerin tesis hiyerarşisinden (tesis, alan, hat, makine) oluşan, önceden bilinen bir adresi vardır; veriyi kullanan bir sistem, değeri hangi PLC adresinde tutulduğuna göre değil, nereden geldiğine göre bulur.

Tesisler neden UNS'e ihtiyaç duyar?

Pek çok sanayi kuruluşunda operasyonel teknoloji (OT) verisi birbirinden kopuk adacıklarda yaşar:

• Kapalı seri protokollerin arkasına hapsolmuş eski PLC'ler.
• Belirli operatör panellerine sıkı sıkıya bağlı SCADA sistemleri.
• Sorgulamak için SQL'de doktora yapmış olmayı gerektiren geçmiş veri depoları.
• ERP ve MES platformlarına doğrudan yamanmış, gelişigüzel ve kırılgan entegrasyonlar.

Sonuç çoğu zaman kırılgan bir spagetti mimarisidir. Böyle bir ortamda her yeni entegrasyon projesi bakım yükünü, adlandırma tutarsızlıklarını ve değişiklik riskini ekiplerin beklediğinden daha fazla artırır.

Proxus bu temel soruna farklı bir yoldan yaklaşır: mimarinin tam merkezine bir Unified Namespace (UNS) yerleştirir. Bunu yalnızca bir mimari kalıp olarak değil, üretimde çalışacak bir yazılım katmanı olarak değerlendiriyorsanız Proxus Unified Namespace yazılımı sayfasına göz atın.

• Ortak bağlam: Tüm kullanıcılar aynı işletme bağlamını görür
• Aşamalı geçiş: Önerilen devreye alma modeli

Gözlenen performans iş yükünün niteliğine, düğüm kapasitesine ve kurulum tasarımına bağlıdır.

Unified Namespace nasıl çalışır?

Unified Namespace, satın alınan bir yazılım değil, bir mimari tasarım kalıbıdır. Üretimde bu kalıbın yine de bağlantı, konu yapısının kurallara bağlanması, yetkiler, ara belleğe alma, geçmiş veri ve izlenebilirlik için yazılıma ihtiyacı vardır. Kalıbın temel ilkesi, tüm işletme verisinin iyi yapılandırılmış tek bir merkezi MQTT sunucusundan akmasıdır.

UNS mimarisinde:

• Her veri noktasının öngörülebilir ve anlamı belli bir yeri vardır (MQTT konu yolu).
• Adlandırma kurumun tamamında, genellikle ISA-95'ten esinlenerek, katı biçimde tutarlıdır.
• Veriyi kullanan tüm sistemler, özel veri eşlemelerine gerek kalmadan fabrikayı aynı biçimde görür.

N × M sayıda noktadan noktaya bağlantı kurmak yerine (yani yeni bir yazılım sistemi eklemek için onu mevcut 30 makineye tek tek bağlamak yerine), her bileşen bağımsız hareket eder:

• Ürettiği veriyi UNS'e yayınlar.
• UNS'ten yalnızca ihtiyaç duyduğu veri dallarına abone olur.

Bu yapı veri adacıklarını ortadan kaldırır, entegrasyon zahmetini önemli ölçüde azaltır ve yeni bir kestirimci bakım algoritması ya da bir ERP köprüsü eklemeyi çok daha kolay hâle getirir.

Neden MQTT?

MQTT (Message Queuing Telemetry Transport), UNS uygulamalarında en çok tercih edilen taşıma protokolüdür, çünkü yapısı gereği:

• Bant genişliğini en aza indirir: Cihazlar değişmeyen değerleri sürekli sorgulatmak yerine yalnızca veri değiştiğinde yayın yapar (değişince raporlama).
• Güvenilirlik sağlar: Kalıcı QoS kuyrukları, kısa ağ kesintilerinde veri kaybını önlemeye yardımcı olur.
• Öngörülebilir biçimde büyür: Boyutlandırma, veri içeriği disiplini ve veriyi kullanan sistemler doğru tasarlandığında modern MQTT sunucuları çok sayıda konu ve aboneyi kaldırabilir.
• Güvenliği zorunlu kılar: Dışa doğru açılan bağlantılarla, yerleşik TLS şifrelemesi ve katı erişim listeleri (ACL) ile çalışır.

MQTT sunucusu, mesajları yayıncılarla aboneler arasında taşır. Kullanılabilir bir UNS için bunun yanında kurallara bağlanmış konu sahipliği, varlık kimliği, şemalar, kalite, yetkilendirme, yaşam döngüsü kuralları ve veri kullanım sözleşmeleri de gerekir.

Veri ISA-95 hiyerarşisine göre nasıl düzenlenir?

Proxus veri ağacını ISA-95 ekipman hiyerarşisine göre kurar. Bu hiyerarşi, üretim verisini kolay anlaşılır beş seviyeli bir piramitte düzenler:

Enterprise (e.g., "Proxus_Global")
 └─ Site (e.g., "Istanbul_Factory")
 └─ Area (e.g., "Assembly_Line_1")
 └─ Equipment (e.g., "Robot_Arm_04")
 └─ Metrics (e.g., "Temperature", "Status", "OEE")

Bu yapı sayesinde:

1. İnsanlar veri ağacında rahatça gezinir; sürekli değişken eşleme tablolarına bakmaları gerekmez.
2. Joker karakterli abonelikler sisteme özel eşlemeleri azaltır: Veriyi kullanan bir sistem Istanbul_Factory/Assembly_Line_1/+/+/OEE gibi kontrollü bir konu kalıbına abone olabilir. Yeni bir ekipman, ancak onaylanmış veri ağacı, veri içeriği, kimlik ve erişim kontrolü sözleşmesine uyduğunda bu kalıpla bulunabilir hâle gelir.
3. Bağlam korunur: Konu yolu, verinin nereden geldiğini kendisi gösterir. Kimliği belirsiz bir 72 değeri hiçbir şey ifade etmez; Istanbul/Line1/Oven/metrics/Temperature = 72 ise her şeyi anlatır.
4. Eski sistemler de uyum sağlar: 25 yıllık bir PLC'yi bir Edge Gateway okur ve PLC, standart bir "Equipment" düğümü hâline gelir.

Somut bir örnek

Bir içecek dolum tesisinde konularınız şöyle görünür:

ProxusMfg/Istanbul/Bottling/Line3/FillerMachine/metrics/Temperature
ProxusMfg/Istanbul/Bottling/Line3/FillerMachine/state/Running
ProxusMfg/Istanbul/Bottling/Line3/FillerMachine/events/MaintenanceAlert

Veri içeriği: JSON mu, Sparkplug B mi?

MQTT mesajları taşır, ama içlerinde ne olduğunu söylemez: bir cihaz {"temp": 24} değerini JSON olarak, bir diğeri 24.0 değerini ham bayt olarak yayınlayabilir. Bir UNS'in üzerinde anlaşılmış bir veri içeriğine ihtiyacı vardır; değer, kaynaktaki zaman damgası, kalite ve birim birlikte taşınmalıdır. Eclipse spesifikasyonu olan Sparkplug B bunun bir cevabıdır: türü belli metrikler taşıyan Protocol Buffers içerikleri ve bir düğümün metriklerini ve bağlantı kopmalarını duyuran BIRTH ve DEATH mesajları. Belgelenmiş bir JSON şeması ise diğer cevaptır ve tek tesisli bir başlangıç için çoğu zaman daha sadedir. Seçeneklerin artısı eksisi ve veri içeriği sözleşmesinin nasıl yazılacağı uygulamalı rehberde anlatılıyor.

Proxus'ta cihazlar Edge Gateway'in yerleşik MQTT sunucusuna JSON yayınlayabilir; sorgulanan kontrolörleri ise protokol sürücüleri okur. Her ikisi de aynı veri ağacına düşer. Sparkplug B çıkış tarafında desteklenir; böylece veri ağacı Sparkplug'ı anlayan uygulamalara yayınlanabilir.

Proxus UNS'i nasıl hayata geçirir?

Proxus, bir UNS'in çekirdeği olacak şekilde tasarlandı. Eski bir SCADA'ya açık kaynaklı bir MQTT sunucusu iliştirmek yerine (Proxus ile tek başına bir MQTT sunucusunun karşılaştırması), yüksek eşzamanlılığa sahip, aktör tabanlı bir mimari kullanır:

Bu mimarinin amacı canlı dağıtımı, ara belleğe almayı ve verinin kullanımını birbirinden ayrı tutmaktır; böylece her biri noktadan noktaya entegrasyon kalıplarına göre çok daha düzgün büyüyebilir.

Spagetti mimari bir örnekte nasıl çözülür?

Aşağıdaki senaryo bir müşteri hikâyesi değil, anlatımı somutlaştırmak için kurgulanmış bir örnektir. İstanbul'da bir dolum tesisi düşünün (konu yollarında adı "ProxusMfg"). Ekibin üç ayrı hattı gerçek zamanlı izlemesi ve hat genelindeki OEE'yi ilişkilendirmesi gerekiyordu.

UNS öncesi karmaşa

• Her hattaki Siemens S7-1200 PLC'ler, Profinet üzerinden birbirinden yalıtılmış yerel operatör panelleriyle konuşuyordu.
• MES sistemi, özel bir sürücüyle her PLC'yi 10 saniyede bir doğrudan sorguluyordu.
• ERP (SAP), MES veritabanından veri çekmek için 15 dakikada bir toplu iş çalıştırıyordu.
• İş zekâsı panoları ciddi gecikmeli bir SAP veri ambarını sorguluyordu.
• Darboğaz: Yeni bir kestirimci bakım uygulaması eklemek her seferinde kaynağa özel yeni bir eşleme, yeni bir güvenlik incelemesi ve yeni bir kurulum değişikliği gerektiriyordu.

Proxus ile UNS sonrası

• Üç Proxus Edge Gateway'i S7 PLC'leri okur ve normalleştirilmiş veriyi merkez sunucudaki veri ağacına yayınlar.
• MES özel sorgulama sürücüsünü bırakır ve yalnızca ProxusMfg/Istanbul/Bottling/+/+/metrics/OEE konusuna abone olur.
• ERP üretim adetlerini 15 dakikalık toplu çekme yerine bir veri hedefi üzerinden alır.
• Kestirimci bakım aracı yalnızca titreşim ve akım konularına abone olur; Edge Gateway'lerdeki anomali kuralları da sapmaları ve düz çizgileri yerelde işaretler.

Sonuç: Yeni yapay zekâ uygulaması, yeni bir özel noktadan noktaya entegrasyon turuna gerek kalmadan büyük ölçüde yapılandırmayla eklenebildi.

Ekipler UNS'i neden benimsiyor?

Unified Namespace'i bir slogan olarak değil, bir veri dağıtım kalıbı olarak ele almak en doğrusudur. Değeri, her yeni kullanıcı için aynı entegrasyon yolunu yeniden kurmadan işletme verisinin sistemler arasında kolayca yeniden kullanılabilmesinden gelir.

UNS kurmak yine de net kurallar ve sahiplik, adlandırma disiplini ve özenli bir devreye alma süreci gerektirir. Proxus, uygulamanın büyük kısmını üstlenecek şekilde tasarlandı: fiziksel bağlantı, veri içeriğinin işlenmesi, uçta ara belleğe alma ve merkezi dağıtım.

Bu yaklaşım ne zaman uygun olmayabilir?

• Düşük frekanslı telemetri, dağıtık bir mimarinin tüm karmaşıklığına değmeyebilir.
• Tek hatlı küçük tesisler önce daha sade mimarileri tercih edebilir.
• Katı eski sistem kısıtları aşamalı bir geçiş gerektirebilir.
• Emniyet açısından kritik kapalı çevrim kontrol, PLC ve emniyet PLC'si katmanlarında kalmalıdır.

Sonuçlar iş yükü profiline, donanım kapasitesine ve kurulum yapısına bağlıdır.

Sık sorulan sorular

Bu yazının diğer UNS yazılarından farkı nedir?

Bu yazı kavramı anlatır: UNS nedir, neden vardır ve otomasyon piramidinden nasıl ayrılır. Unified Namespace mimarisi için uygulamalı rehber tasarım için başvuru kaynağıdır: adlandırma, veri içeriği, durum, sahiplik ve test. UNS'ye geçiş yol haritası ise iş sırasını, pilot hattan tüm tesise beş aşamada anlatır.

UNS, OPC UA ile birlikte çalışabilir mi?

Evet. UNS, OPC UA'nın yerini almaz, onu tamamlar. OPC UA makineden makineye yerel okumalarda, MQTT ise ölçeklenebilir yayınla-abone ol dağıtımında başarılıdır. Edge Gateway'ler OPC UA ile okur ve MQTT ile UNS'e yayınlar.

UNS'te veri kalitesini nasıl sağlarım?

Veri UNS'e girmeden önce gürültüyü ayıklamak için uçta akıllı filtreleme kullanın ve konu adlandırmasında katı kurallar uygulayın. OT DataOps süreci, verinin tüm kullanıcılar için temiz, anlamı belli ve tutarlı olmasını sağlar.

Kaynaklar

1. ISA-95 (IEC 62264): UNS konu tasarımına uyarlanan hiyerarşik modeli tanımlayan, kurumsal sistemlerle kontrol sistemlerinin entegrasyonu standardı. ISA-95
2. MQTT v5.0 OASIS Standard: UNS'in taşıma katmanı olarak kullanılan yayınla-abone ol protokolü. mqtt.org
3. Eclipse Sparkplug Specification: MQTT tabanlı IIoT'de birlikte çalışabilirlik için veri içeriği standardı. sparkplug.eclipse.org

Tasarım kuralları için Unified Namespace mimarisi için uygulamalı rehber yazısıyla devam edin, Proxus'un veri ağacını nasıl çalıştırdığına bakın ya da dokümanlardaki Unified Namespace kavramları sayfasına geçin.