IIoT için Unified Namespace (UNS): Nedir, Neden Önemlidir ve Nasıl Uygulanır?

Endüstriyel tesislerde veri çoğu zaman eksik değildir. Asıl sorun, verinin farklı sistemlerde dağınık, kopuk ve yeniden kullanımı zor bir yapıda bulunmasıdır.

Bir hatta PLC vardır, yanında HMI vardır, başka bir katmanda SCADA vardır, historian ayrıdır, MES ayrıdır, ERP kendi dünyasında çalışır. Her sistem bir şekilde veri üretir ya da veri tüketir. Ama yapının tamamına birlikte bakıldığında aynı verinin farklı isimlerle dolaştığı, bazı bilginin yalnızca belirli uygulamalarda kaldığı ve yeni bir sistem eklendiğinde mevcut mimarinin zorlandığı görülür.

Bu yüzden birçok tesiste asıl mesele veri toplamak değil, veriyi ortak bir yapı içinde anlamlı ve yeniden kullanılabilir hale getirmektir. Unified Namespace yaklaşımı da tam burada devreye girer.

Unified Namespace (UNS) nedir?

Unified Namespace, endüstriyel veriyi ortak bir isimlendirme ve yayın modeli altında toplama yaklaşımıdır. Bir yazılım ürünü değil, veri mimarisi tasarım biçimidir.

Bu yaklaşımda veriler yalnızca uygulamadan uygulamaya taşınmaz. Bunun yerine, tüm sistemlerin referans alabileceği ortak bir veri ağacı altında yayınlanır. Böylece yeni bir sistem veri tüketmek istediğinde, özel ve kırılgan bir bağlantı zinciri kurmak yerine mevcut veri omurgasına bağlanabilir.

UNS yaklaşımının temel amacı şunlardır:

• veriyi bağlamıyla birlikte taşımak
• aynı verinin farklı sistemler tarafından yeniden kullanılmasını kolaylaştırmak
• nokta-nokta entegrasyon bağımlılıklarını azaltmak
• OT ve IT katmanları arasında daha tutarlı bir veri dili kurmak

Buradaki önemli nokta şu: UNS bir protokol değildir. Genellikle MQTT gibi publish-subscribe tabanlı taşıma modelleri ve ISA-95 gibi hiyerarşik veri modelleme yaklaşımları ile birlikte uygulanır.

Klasik entegrasyon modeli neden zamanla zorlaşır?

Geleneksel yapılarda veri çoğu zaman katman katman ilerler. PLC'den çıkan bilgi önce SCADA'ya, sonra historian'a, oradan raporlama ya da MES katmanına, en sonunda da ERP veya başka kurumsal sistemlere ulaşır.

Bu model belirli ölçekte çalışabilir. Ama sistem sayısı arttıkça bazı sorunlar daha görünür hale gelir:

• her yeni tüketici için yeni bir entegrasyon hattı gerekir
• veri anlamı taşıma sırasında zayıflayabilir
• aynı ölçüm farklı ekiplerde farklı isimlerle yaşamaya başlar
• mevcut bir hattı bozmadan yeni sistem eklemek zorlaşır
• bakım ve değişiklik maliyeti zamanla büyür

Bu yüzden birçok tesiste önemli soru yalnızca “veriyi nasıl okuyacağız?” değildir. Daha kritik soru şudur:

Yeni bir sistem eklendiğinde mimari daha mı sadeleşiyor, yoksa daha mı karmaşık hale geliyor?

UNS, bu soruya daha düzenli bir cevap vermeye çalışır.

UNS neden IIoT projelerinde bu kadar konuşuluyor?

Çünkü IIoT projelerinin çoğunda ilk zorluk veri toplamak değil, veri toplandıktan sonra onu sürdürülebilir biçimde kullanmaktır.

Bir projede ilk dashboard'u yapmak çoğu zaman mümkündür. İlk rapor da hazırlanabilir. İlk ERP entegrasyonu da bir şekilde çıkar. Ama iş birkaç hattı, birkaç tesisi, bakım ekiplerini, enerji analitiğini, kalite uygulamalarını, AI kullanım senaryolarını ve dış sistem entegrasyonlarını aynı resme dahil etmeye gelince yapı zorlanmaya başlar.

UNS bu noktada şu faydaları hedefler:

• veri kaynağını ve veri bağlamını birlikte görünür kılmak
• yeni tüketici sistemlerin eklenmesini kolaylaştırmak
• farklı ekiplerin aynı veriyi daha tutarlı biçimde kullanmasını sağlamak
• historian, dashboard, MES, ERP ve analitik katmanlarını ortak veri omurgasında buluşturmak

Bu, her projede aynı sonucu vermez. Ama özellikle çoklu sistem, çoklu hat ve çoklu tüketici senaryolarında daha sürdürülebilir bir yön sunabilir.

MQTT, UNS ile neden sık birlikte anılır?

UNS bir veri organizasyon yaklaşımıdır. MQTT ise bu yaklaşımı taşımak için sık kullanılan iletişim modellerinden biridir.

Bunun temel nedeni MQTT'nin publish-subscribe yapısıdır. Veri üreten taraf ile veri tüketen taraf birbirini doğrudan bilmek zorunda değildir. Bir edge gateway, PLC'den aldığı veriyi publish eder; historian, dashboard, MES veya analitik servis de ilgili topic'lere subscribe olur.

Bu yapı özellikle şu alanlarda faydalıdır:

• üretici ve tüketici arasındaki bağımlılığı azaltır
• veri aynı anda birden fazla sistem tarafından tüketilebilir
• edge ile merkez arasında esnek bir veri akışı kurulabilir
• uygun tasarlandığında gereksiz polling yükü azaltılabilir

Yine de MQTT her senaryo için tek doğru yol değildir. Dar kapsamlı, düşük frekanslı veya sınırlı sistem sayısına sahip yapılarda daha basit yöntemler yeterli olabilir. Buradaki asıl değer, MQTT'nin tek başına kullanılması değil, iyi tasarlanmış bir namespace ve veri modeli ile birlikte kullanılmasıdır.

ISA-95 neden önemli?

UNS yaklaşımının en kritik tarafı veriyi taşımak değil, veriyi düzenli biçimde adlandırmaktır.

Eğer aynı veriye her ekip farklı isim veriyorsa, yalnızca MQTT kullanmak veri karmaşasını çözmez. Verinin nereden geldiği, neyi temsil ettiği ve organizasyon içinde nereye ait olduğu da açık olmalıdır.

Burada ISA-95 pratik bir çerçeve sunar. Kurum, site, alan, process cell, equipment ve metric gibi seviyeler, verinin yalnızca teknik olarak değil operasyonel bağlamla da tanımlanmasına yardımcı olur.

Örnek bir yapı şöyle olabilir:

enterprise/site/area/processCell/equipmentModule/deviceId/metric

Bu yapı her tesiste birebir aynı olmak zorunda değildir. Ama benzer bir hiyerarşik yaklaşım şu avantajları sağlayabilir:

• topic yapısının daha öngörülebilir hale gelmesi
• wildcard aboneliklerin daha anlamlı kullanılması
• veri keşfinin kolaylaşması
• yeni ekipman eklendiğinde isim karmaşasının azalması
• çoklu tesis yapılarında daha tutarlı bir model oluşması

Örneğin aşağıdaki topic yalnızca bir ölçüm taşımaz. Aynı zamanda o ölçümün bağlamını da taşır:

AcmePlant/Istanbul/FillingLine1/Filler/Capper01/MotorCurrent

Sparkplug B bu resimde nereye oturur?

MQTT veri taşımayı sağlar. Sparkplug B ise özellikle endüstriyel kullanımlarda veri biçimini ve cihaz yaşam döngüsü mesajlarını daha düzenli hale getiren bir spesifikasyondur.

Bu şu durumlarda öne çıkar:

• cihazın çevrimiçi ya da çevrimdışı durumunu daha standart biçimde izlemek
• metrik tiplerini daha tutarlı taşımak
• farklı üreticilerden gelen veriler arasında ortak payload disiplini kurmak
• Sparkplug B ekosistemine sahip platformlarla daha öngörülebilir entegrasyon kurmak

Ancak Sparkplug B her proje için zorunlu değildir. Bazı yapılarda JSON tabanlı daha sade payload tasarımları yeterli olabilir. Hangi yaklaşımın daha uygun olduğu; hedef entegrasyonlara, veri tüketicilerine ve birlikte çalışabilirlik ihtiyacına bağlıdır.

Proxus içinde UNS nasıl ele alınıyor?

Proxus tarafında UNS yalnızca kavramsal bir anlatı değildir. Veri toplama, normalizasyon, edge işleme ve merkezi tüketim akışının önemli parçalarından biridir.

Genel akış şu şekildedir:

Bu yaklaşımın önemli tarafı, verinin yalnızca bir veritabanına yazılması değil; aynı zamanda canlı veri akışı içinde de anlamlı biçimde dolaşabilmesidir.

Edge katmanı neden kritik?

UNS çoğu zaman merkezde kurgulanan bir topic ağacı gibi anlatılır. Oysa pratikte veri kalitesi, veri hacmi ve veri davranışı çoğu zaman edge tarafında şekillenir.

Proxus'ta edge katmanı şu görevleri üstlenebilir:

• saha protokollerinden veri toplamak
• veriyi normalize etmek
• kullanıcı tanımlı C# fonksiyonları çalıştırmak
• kuralları edge'de işletmek
• gereksiz veri trafiğini azaltacak filtreleme yapmak
• bağlantı kesintilerinde veri akışını daha dayanıklı hale getirmek

Bunun sahadaki etkisi; veri yoğunluğu, ağ kararlılığı, topoloji ve uygulanan kurallara göre değişir. Ama birçok yapıda edge tarafı, yalnızca veri toplayan pasif bir katman olmaktan daha fazlasını ifade eder.

Bu yaklaşım pratikte hangi problemi hafifletir?

UNS'in gerçek değeri, “yeni bir teknoloji” olmasında değil, operasyonel sürtünmeyi azaltma potansiyelinde ortaya çıkar.

Özellikle şu alanlarda etkisi görülür:

Yeni tüketici sistem eklemek

Yeni bir dashboard, MES fonksiyonu, enerji analitiği servisi ya da AI katmanı eklendiğinde mevcut bağlantıların tamamını yeniden kurmak gerekmez. Ortak veri omurgası varsa entegrasyon yüzeyi daha yönetilebilir hale gelir.

Veri bağlamını korumak

Ham sayıların tek başına anlamı sınırlıdır. Topic yapısı ve isimlendirme disiplini sayesinde veri, nereden geldiğiyle birlikte okunabilir hale gelir.

Veri tekrar kullanımını kolaylaştırmak

Aynı veri historian, dashboard, alarm, raporlama ve dış sistem entegrasyonlarında yeniden kullanılabilir.

Edge ve merkez arasındaki sorumluluğu ayırmak

Filtreleme, ön işleme ve saha yakınındaki bazı hesaplamalar edge'de yapılabilir. Merkez ise görünürlük, orkestrasyon ve daha geniş tüketim senaryolarına odaklanabilir.

Her tesis için aynı ölçüde uygun mu?

Hayır. UNS güçlü bir mimari desen olabilir, ancak her proje için ilk tercih olmak zorunda değildir.

Aşağıdaki durumlarda daha dikkatli değerlendirilmelidir:

• veri hacmi düşükse ve yalnızca birkaç cihaz izleniyorsa
• tek hatlı, sabit ve sınırlı bir sistem söz konusuysa
• mevcut SCADA veya historian yapısı iş ihtiyacını karşılıyorsa
• veri modelleme ve isimlendirme disiplinini sürdürecek sahiplik yoksa
• emniyet-kritik kontrol ile veri paylaşımı mimarisi birbirine karıştırılıyorsa

Özellikle son madde önemlidir. UNS, veri paylaşımı ve entegrasyon mimarisi için güçlü bir yaklaşım olabilir; ancak bu, kapalı çevrim kontrol mantığının PLC veya safety PLC katmanından çıkarılması gerektiği anlamına gelmez.

Proxus için neden merkezi bir konu?

Çünkü Proxus'un temel yaklaşımı yalnızca veri toplamak değil, veriyi farklı sistemler arasında yeniden kullanılabilir hale getirmektir.

Bu çerçevede UNS, şu başlıklarla doğrudan ilişkilidir:

• edge computing
• MQTT tabanlı veri yayılımı
• ISA-95 uyumlu veri bağlamı
• historian ve dashboard tüketimi
• kurallar ve kullanıcı tanımlı işleme katmanları
• dış sistem entegrasyonları

Başka bir deyişle UNS, Proxus içinde yalnızca teknik bir özellik değil; veri modelleme ve sistemler arası veri paylaşımı mantığının merkezindeki yaklaşımlardan biridir.

Kaynaklar

1. ISA-95 / IEC 62264 - Kurum-kontrol entegrasyonu ve hiyerarşik modelleme için temel standart çerçevelerden biridir. ISA-95
2. MQTT Version 5.0 - Publish-subscribe veri taşımada kullanılan açık standartlardan biridir. OASIS MQTT Specification
3. Eclipse Sparkplug Specification - MQTT tabanlı IIoT veri birlikte çalışabilirliği için kullanılan spesifikasyonlardan biridir. Eclipse Sparkplug
4. NIST SP 800-82 Rev. 3 - Endüstriyel kontrol sistemleri için güvenlik rehberleri içerir. NIST SP 800-82r3

Veri mimarisini yalnızca entegrasyon açısından değil, işletme ölçeğinde sürdürülebilirlik açısından da düşünüyorsanız, bir sonraki mantıklı adım topic tasarımı, veri sahipliği ve edge sorumluluklarının birlikte ele alınmasıdır. Bu çerçevede Unified Namespace dokümantasyonundan devam edebilirsiniz.