Unified Namespace nedir, nasıl tasarlanır?

Fikir: noktadan noktaya yerine ortak isim alanı

Noktadan noktaya entegrasyonda her yeni sistem, bağlanması gereken her sistemle ayrı bir arayüz gerektirir. UNS’de her sistem yalnızca isim alanına bağlanır: veri üreten sistem yayınlar, veri tüketen sistem abone olur. Böylece yeni bir tüketici eklemek yayıncıyı değiştirmeden yapılabilir.

İsim alanı tesisin “şu anki gerçeğini” taşır: bir hattın durumu, bir makinenin sayacı, bir üretim emrinin aşaması. Geçmiş verinin uzun süreli saklanması ayrı bir sorundur ve çoğunlukla bir historian veya veritabanı ile çözülür; UNS bu sistemleri de besleyebilir.

Hiyerarşi ve adlandırma

Hiyerarşi ölçümün fiziksel konumunu soldan sağa daraltır. ISA-95 ekipman hiyerarşisinden esinlenen yaygın bir yapı şöyledir:

isletme/tesis/alan/hat/hucre/olcum

Bu yapıda “bir hattaki tüm durumlar” veya “tüm tesislerde sıcaklık” gibi sorgular abonelik filtresiyle ifade edilebilir. Adlandırmada topic tasarımı ilkeleri geçerlidir: küçük harf, kararlı adlar ve topic’e değer koymamak. MQTT topic oluşturucu bu yapıdan örnekler ve abonelik filtreleri üretir.

Seviye sayısını ve adları baştan, ilgili ekiplerle birlikte kararlaştırın. Bir ad değiştiğinde ona bağlı tüm yayıncılar ve aboneler etkilenir.

Güncel durum ve olay

UNS’de iki tür veri vardır ve ikisini ayrı tutmak gerekir. Durum (state), bir şeyin şu anki halidir: hat çalışıyor, sıcaklık 72. Durum topic’leri retain ile yayınlanırsa yeni bir abone son bilinen değeri hemen alır. Olay (event) bir anda olan şeydir: bir parti tamamlandı, bir alarm başladı. Olay topic’lerinde retain uygun değildir; yeni abone yalnızca en son olayı görür ve önceki olayları kaçırır.

Her mesaj kaynak zaman damgasını, birimi ve kaliteyi taşımalıdır. Retain edilmiş bir durum değerinin ne kadar eski olduğunu yalnızca zaman damgası söyler. Kaynağın canlı olup olmadığını bildirmek için çevrimiçi/çevrimdışı durumu ve Last Will kullanılabilir (ayrıntı için üretimde MQTT yazısına bakın).

Payload sözleşmesi ve Sparkplug

Topic adı konumu söyler; anlamı payload taşır. Bir veri sözleşmesi her mesaj türü için alanları, tipleri, birimleri ve sürümü tanımlar. Yapıyı kendiniz tanımlayabilir (örneğin JSON ile) veya Sparkplug B gibi bir belirtim kullanabilirsiniz. Sparkplug belirli bir topic yapısı ve Protobuf payload’ı getirir; kendi yapınız daha esnektir ama belgelemek ve tutarlı uygulamak size aittir. Her iki durumda da bir sürüm alanı, yapıyı ileride değiştirmeyi mümkün kılar.

Yönetişim: kim neyin sahibi?

UNS’nin teknik kısmı hızlı kurulur; zor olan kuralların sürdürülmesidir:

• Adlandırma sahibi. Yeni bir alan, hat veya ölçüm eklemeye kim karar verir?
• Yayın yetkisi. Hangi sistem hangi alt ağaca yayın yapabilir? Broker yetkilendirmesiyle her yayıncıyı kendi alt ağacına sınırlayın.
• Değişiklik süreci. Bir payload alanı değiştiğinde aboneler nasıl haberdar olur?
• Broker işletimi. Broker kritik bir bileşendir; yedeklilik, izleme ve kapasite ayrıca planlanmalıdır.

Sık yapılan hatalar

• Ham etiketleri topic’e dökmek. PLC etiket adlarını olduğu gibi yayınlamak isim alanını teknik ayrıntılarla doldurur; tüketici için anlamlı adlar üretin.
• Zaman damgasız veri. Retain edilmiş değerlerin eskiyip eskimediği anlaşılamaz.
• Komut ile durumu karıştırmak. Yazma komutlarını ve durum bilgisini aynı topic’te tutmak karışıklık ve güvenlik riski yaratır; komutlar ayrı, yetkili topic’lerde olmalıdır.
• UNS’yi tek başına çözüm sanmak. İsim alanı veri sahipliğini ve kalitesini kendiliğinden çözmez.

OPC Router’ın rolü

UNS’de veri kaynakları farklı protokollerle konuşur: OPC UA, SQL, SAP, REST. Bu kaynaklardan okuyup değeri tanımlı şemaya dönüştürerek isim alanına yayınlayan (veya isim alanından okuyup bir hedefe yazan) katman bir entegrasyon katmanıdır. OPC Router, MQTT Client ve Sparkplug bağlantılarıyla bu rolü üstlenebilir; topic hiyerarşisi, payload şeması ve kesinti davranışı projede veri sözleşmesiyle birlikte belirlenir. Başlamak için Endüstriyel IoT ve MQTT çözüm sayfasına ve MQTT rehberine bakın.