IIoT için Birleşik İsim Alanı (UNS): Mimari ve Uygulama Değerlendirmesi

Çoğu endüstriyel organizasyon ve üretim tesisi için Operasyonel Teknoloji (OT) verileri, adeta birbirleriyle iletişim kuramayan onlarca donanımın içine hapsolmuş durumdadır:

• Seri (Serial) formattaki özel protokollere sıkışmış 20 yıllık PLC'ler,
• Tesisin yalnızca bir köşesindeki spesifik HMI ekranlarına göbekten bağlı SCADA sistemleri,
• İçinden veri çekebilmek için haftalar süren zorlu SQL sorguları gerektiren SQL Logger ve Historian veritabanları,
• ERP, MES ve raporlama sistemlerine çekilen, her dokunuşta kırılganlaşan karmaşık Spagetti entegrasyonlar.

Bunun sonucunda ortaya önemli bir Spagetti Mimarisi çıkar. Her yeni IT veya otomasyon projesi, sistemi anlamayı, bakımını yapmayı ve yeni bir cihaza ölçeklendirmeyi logaritmik olarak zorlaştırır. Endüstri 4.0 analistlerine göre, fabrikalar milyon dolarlık IIoT bütçelerinin %40 ila %60'ını sadece veriyi bir sistemden diğerine haritalamak (Data Mapping) ve taşımak için harcıyor; gerçek mühendislik sorunlarını çözmek için değil.

Proxus, tesislerdeki bu kronik kördüğümü kökten farklı bir yaklaşımla çözer: Tüm mimarinin merkezine modern ve çevik bir Tekil Veri Mimarisi / Birleşik İsim Alanı (Unified Namespace - UNS) oturtarak.

Sonuçlar yük profiline, donanım kapasitesine ve dağıtım topolojisine bağlıdır.

Birleşik İsim Alanı Nedir?

Birleşik İsim Alanı (UNS), kutuya girip satın aldığınız bir yazılım programı değildir; o, endüstriyel bir veri mimarisi tasarım yaklaşımıdır. Fabrikadaki tüm operasyonel verilerin (sensör, motor komutu, üretim emri vb.) tek, iyi yapılandırılmış, hiyerarşik bir Merkezi Broker üzerinden akmasını şart koşar.

Gerçek bir UNS mimarisinde:

• Tesisin her veri noktası önceden tahmin edilebilir, anlamsal (Semantic) bir isme ve konuma sahiptir (MQTT Topic hiyerarşisi).
• Tüm adlandırma, fabrikadaki cihaz sayısından bağımsız olarak genellikle ISA-95 ağaç yapısına sıkı sıkıya bağlıdır.
• Fabrikadaki tüm dış Tüketici sistemler (ERP, MES, AI Modelleri), ekstra bir özel dönüştürücüye ihtiyaç duymadan tek bir kaynağa ve formata bakar.

Eski usülde bir tesiste yeni alınan makineyi MES, ERP ve raporlama ekranına bağlamak için her biri ayrı 3 bağımsız kablolama ve protokol adaptörü gerekir (N × M noktadan-noktaya bağlantı problemi). UNS yaklaşımında ise her mekanizma bağımsızdır:

• Kendisinin ürettiği sensör sinyalini UNS Merkezine Yayınlar.
• Yalnızca kendisini ilgilendiren spesifik sinyal dalına dışarıdan Abone Olur.

Bu çevik Publish-Subscribe topolojisi, veri silolarını belirgin bicimde azaltir. İntegrasyon maliyetini önemli ölçüde düşürür. Hattın ucuna anlık bir Kestirimci Bakım algoritması veya MES platformu bağlamayı hızlı bir konfigürasyona dönüştürür.

Neden Endüstri Standardı MQTT?

MQTT (Message Queuing Telemetry Transport), UNS kurulumlarının genellikle endüstri standart transport protokolüdür çünkü donanımsal doğası şunlara dayanır:

• Bant genişliği verimliliği: MQTT tabanlı report-by-exception yaklaşımında veri, her polling döngüsünde değil değer değişimi olduğunda iletilir.
• Hata Dayanımı: Kalıcı Hizmet Kalitesi (QoS kuralı) kuyrukları, zayıf Wi-Fi çeken bir depoda veya anlık şebeke kesintilerinde veri kaybı riskini düşürmeye yardımcı olur.
• Limitsiz Ölçeklenme (Scale): Modern bir MQTT Broker (Proxus çekirdeğini oluşturan asenkron model gibi), milyonlarca hiyerarşik konuyu ve yüz binlerce canlı cihaz bağlantısını tek bir açık iletişim portu üzerinden gecikmesiz yönetir.

MQTT Broker'ını fabrikanızın Merkezi Sinir Sistemi olarak düşünün. Sensörler, robotlar ve iş emri sistemleri genellikle birbirlerine karmaşık bağlantılar yapmaz; hepsi merkezi sinir sistemine tek kanaldan bağlanır.

ISA-95 Hiyerarşisi: Veriyi Standartlaştırmak

Proxus, "Unified Namespace" kurgusunu, üretim verilerini beş seviyeli bir hiyerarşik piramide oturtan ISA-95 (Bölüm 2) standardını yerel olarak kullanarak sağlar:

Kurum (Örn. "Proxus_Global")
 └─ Saha (Örn. "Istanbul_Fabrikasi")
 └─ Bölüm (Örn. "Montaj_Hatti_1")
 └─ Ekipman (Örn. "Robot_Kol_04")
 └─ Metrikler (Örn. "Sıcaklık", "MotorDurum", "OEE")

Bu katı hiyerarşi şu avantajları sağlar:

1. İnsanlar API kitapçığına ihtiyaç duymaz: Mühendisler veri ağacında doğrudan klasörler arasında gezinir gibi gezinebilir.
2. Joker Abone (Wildcard Subscription) gücü: Istanbul_Fabrikasi/Montaj_Hatti_1/+/+/OEE adresine abone olduğunuzda, Montaj Hattı 1 içerisindeki o anki ve fabrika yönetimi tarafından 5 yıl sonra satın alınıp eklenecek olan tüm cihazların gerçek zamanlı OEE verisini tek tıkla çekebilirsiniz.
3. Bağlam genellikle kaybolmaz: Çıplak bir "72" sayısı hiçbir şey ifade etmez. Ancak Konu Yolu (Topic) kendini açıklar: Istanbul/Hat1/Firin/metrikler/Sıcaklık = 72 her şeyi ifade eder.
4. Eski Donanımlar: 25 yıllık seri portla çalışan makineniz, Proxus ağ geçidine bağlanıp kolayca "Ekipman" düğümlerinden biri olur.

Sparkplug B: "Sadece Yolu Değil, Veri Yükünü de Standartlaştır"

MQTT size verinizi taşımak için bir otoban sağlar, ancak Sparkplug B spesifikasyonu o otobandaki araç türünün ortak veri formatını standartlaştırır.

Eğer Sparkplug B kural setini kullanmazsanız, fabrikadaki bir robot sıcaklık verisini JSON olarak {"temp": 24} yollarken, başka marka bir debimetre ham Hex byte olarak 24.0 yayınlar ve merkezi veri gölünüz Babil Kulesi kaosuna döner. Eğitilecek yapay zeka modelleri bu veriyi okuyamaz.

Sparkplug B şunları zorunlu kılar:

Doğum ve Ölüm Sertifikaları (Birth & Death Certificates)

• Bir cihaz veya Edge Gateway elektriğe kavuşup ağda ayağa kalktığında sisteme bir DOĞUM (BIRTH) mesajı basar; cihaz bu mesajla tüm "Yeteneklerini" (Şemalarını, metrik türlerini, sensör isimlerini) ağa bildirir.
• Cihazın güç şalteri iner veya ağ kablosu koparsa, MQTT Broker otomatik olarak onun düştüğünü bir ÖLÜM (DEATH) mesajı ile yakalar.
• Bu işlem o cihaza bakan tüm dashboard'ları ve aboneleri milisaniyeler içerisinde anında uyararak "Eski veriyi sil, cihaz koptu" sinyali verir (Ghost data problemine son).

Tip Güvenliği ve Protokol Sıkıştırması

• Sparkplug B, aşırı yoğun JSON metinleri yerine verileri Google'ın Protocol Buffers (ProtoBuf) ikili serileştirme mimarisiyle taşır. Network bant yükünü %70 oranında düşürür.
• Sıcaklık değeri sisteme girmeden önce onun Float tipinde olduğu iyilestirmeyi hedefler edilir (Tip Güvenliği).

(Not: Proxus altyapısı hem standart JSON/MQTT'yi hem de endüstriyel standart olan raw Sparkplug B formatını asenkron karma şekilde destekler.)

Proxus Mimarisi UNS Uygulamasını Nasıl Başarır?

Proxus, sadece standart bir SCADA programı üstüne MQTT sunucusu eklentisi yamalanmış bir yazılım değildir. Çekirdekten itibaren bir UNS Kalbi olarak davranacak Asenkron Actor Modeli (Actor-Based Architecture) üzerine yazılmıştır:

Bu mimari; kritik iş güvenliği alarmları ve motor komutları için Düşük Gecikme, internetin kesildiği senaryolarda sensör verilerini uç disklere yedekleyerek veri kaybi riskinin azaltilmasi sağlar.

Gerçek Dünya Örneği: İçecek Şişeleme Tesisi

ProxusMfg İstanbul Üretim Tesisi'nin eş zamanlı 3 üretim hattını canlı dijitalleştirme senaryosunu inceleyelim.

UNS Öncesi (Kaos Dönemi)

• Hatlardaki Siemens S7-1200 PLC'ler sadece başlarındaki operatör ekranıyla (HMI) kapalı Profinet ile konuşuyor.
• Şirketin satın aldığı dev MES entegratörü yazılımı, her PLC'ye ayrı ayrı 10 saniyede bir otonom sorgu atıyor (Network'te çılgın trafik).
• Kurumsal SAP (ERP), bu MES uygulamasının yavaş veritabanından 15 dakikada bir batch scriptler çekerek güya sahadan veri alıyor.
• Tıkanma Noktası: Hat sonuna Kestirimci Bakım Algoritması (Yapay Zeka) kamerası eklemek ve veriyi çekmek, dışarıdan entegratörlerin 4 hafta SCADA değiştirmesini gerektiriyore.

Proxus UNS Geçişi Sonrası

• Üç adet Proxus Edge Gateway S7 PLC panolarının içine kurulur. Makinelerin datasını ISA-95 ağacı mantığıyla doğrudan Merkezi Proxus MQTT sunucusuna akıtmaya başlarlar.
• Mevcut MES Sunucusu hantal özel bağlantı sürücülerini çöpe atar. Ağa eklenip ProxusMfg/Istanbul/Siseleme_Hatti/+/+/metrikler/OEE adresine abone olur.
• Şirket SAP Sunucusu o günki iş emrini üretim planlamasından direkt .../Siseleme_Hatti/+/komutlar/UretimEmri adresine anında yollar. (Operatöre basılı kağıt gitmez).
• Yeni Alınan Yapay Zeka Aracı, sisteme yeni bir kablo, sürücü kuralı girmeden doğrudan "Titresim ve akım MQTT dalına" abone olmakla işe başlar ve çıkarım yaptığı sonucu anında merkeze MQTT ile fırlatarak görevini tamamlar.

Sonuç: AI aracının entegrasyonu kod ve makine duruşu gerektirmeden 2 saatte tamamlandı.

Değişime Hazır Mısınız?

Birleşik İsim Alanı (UNS) bir trend kelime değil, fabrikaların temel veri yönetimi operasyonlarında mimari bir dönüşümdür. Fabrika verisini "gizli ve kilitli SCADA bilgisayarlarından" alıp; paylaşımlı, okunması kolay ve şirketin Ar-Ge mühendislerini hızlandıran kurumsal ortak bir havuza dönüştürür.

Eskiden olduğu gibi böyle bir entegrasyonu kurmak için derin MQTT uzmanlarına, binlerce satır Python kodu yazmaya veya bitmek bilmeyen teknoloji danışmanlığı faturalarına ihtiyacınız yok. Proxus altyapısı o donanımsal karmaşayı (Sensörün sahada fiziksel eşleşmesinden, Sparkplug B format uyumuna ve buluta stabil ulaştırılmasına kadar) kendi Edge mimarisinde soyutlar.

Ne zaman uygun olmayabilir?

• Düşük frekanslı telemetride daha basit yaklaşımlar yeterli olabilir.
• Tek hatlı küçük tesislerde tam dağıtık mimari maliyet-etkin olmayabilir.
• Katı legacy kısıtları olan ortamlarda kademeli geçiş gerekebilir.
• Emniyet-kritik kapalı çevrim kontrol, PLC/Safety PLC katmanında kalmalıdır.

Bu davranış, topoloji ve yük özelliklerine göre değişebilir.

Sık Sorulan Sorular

Bu makale ile UNS Mimari Kılavuzu arasındaki fark nedir?

Bu makale UNS kavramını açıklar - neden var, Otomasyon Piramidi'nden nasıl farklı ve ne iş değeri sunuyor. UNS Mimari Kılavuzu ise uygulama planıdır - MQTT topolojisi, ISA-95 namespace tasarımı, Sparkplug B payloadları ve 5 fazlı rollout yol haritası.

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

Evet. UNS, OPC UA'nın yerini almaz; onu tamamlar. OPC UA lokal makine-makine okumalarında uygundur; MQTT ölçeklenebilir pub/sub dağıtımında üstündür. Edge Gateway'ler OPC UA ile okur ve MQTT üzerinden UNS'e yayınlar.

UNS'de veri kalitesi nasıl sağlanır?

UNS'e veri girmeden önce uçta Akıllı Filtreleme ile gürültüyü temizleyin ve katı topic adlandırma kuralları uygulayın. OT DataOps hattı verinin tüm tüketici sistemlerde temiz, bağlamsallaştırılmış ve anlamsal olarak tutarlı olmasını sağlar.

Kaynaklar

1. ISA-95 (IEC 62264) - UNS topic tasarımı için uyarlanan hiyerarşik modeli tanımlayan kurum-kontrol entegrasyon standardı. ISA-95
2. MQTT v5.0 OASIS Standardı - UNS taşıma katmanı olarak kullanılan publish-subscribe protokolü. mqtt.org
3. Eclipse Sparkplug Spesifikasyonu - MQTT tabanlı IIoT birlikte çalışabilirliği için payload standardizasyon çerçevesi. sparkplug.eclipse.org

Tekil veri hattı mimarinizi fiziken nasıl tasarlayacağınızı öğrenmek için Uç Bilişim Mimarisi Kılavuzumuzu okuyabilir veya İletişim Formumuzu doldurabilirsiniz.