Unified Namespace (UNS) Mimarisi: ISA-95 Hiyerarşisiyle Topic Tasarımı

Bir fabrikada SCADA, historian, MES, bakım yazılımı, kalite sistemi ve raporlama araçları çoğu zaman aynı PLC’lerden veri ister. Her yeni ihtiyaçta yeni bir bağlantı açılır; birkaç yıl sonra kimse hangi sistemin hangi PLC’ye nereden bağlandığını tam olarak bilmez. Unified Namespace (UNS), bu dağınıklığı tesis geneli tek bir olay odaklı veri katmanıyla değiştiren bir mimari yaklaşımdır. Aşağıda UNS’nin bileşenlerini, ISA-95 ekipman hiyerarşisine dayalı topic tasarımını, broker mimarisini ve UNS’nin yanlış tercih olduğu durumları saha gözüyle anlatıyoruz.

Noktadan noktaya entegrasyon nerede patlar

Klasik yapıda her tüketici veriyi kaynağından doğrudan çeker: SCADA PLC’leri okur, historian SCADA’dan veya ayrı bir OPC sunucusundan veri alır, MES iş emri durumunu kendi sürücüsüyle PLC’den sorgular, raporlama aracı historian veritabanına bağlanır. N sistemin birbiriyle konuştuğu bir yapıda olası bağlantı sayısı en fazla N×(N−1)/2’dir; on sistem için örnek hesapla 45 potansiyel entegrasyon eder.

Sahada bunun karşılığı şudur:

• PLC yükü: Aynı değişken birden fazla sistem tarafından ayrı ayrı sorgulanır. Haberleşme kaynakları sınırlı eski PLC’lerde bağlantı slotları dolar, yeni istemci bağlanamaz.
• Tutarsız anlam: Aynı sayaç SCADA’da “Uretim_Adet”, MES’te “GoodCount”, raporlamada başka bir isimle yaşar; birim ve sıfırlama mantığı her yerde ayrı yorumlanır. Vardiya sonunda iki ekran iki farklı rakam gösterir.
• Değişiklik maliyeti: PLC programı değiştiğinde hangi sistemlerin etkileneceğini bilmek için tüm entegrasyonların envanteri gerekir. Bu envanter çoğu zaman yoktur.
• Yeni tüketici zorluğu: Analiz ekibinin basit bir veri ihtiyacı, haftalar süren bir bağlantı projesine dönüşür.

Unified Namespace kavramı ve bileşenleri

Fikir basit: işletmenin anlık durumu tek bir yerde, iş yapısını yansıtan bir hiyerarşi içinde yayımlanır. Veriyi üreten her sistem kendi verisini bu katmana yazar, ihtiyacı olan her sistem buradan abone olur. Üretici ile tüketici birbirini tanımak zorunda değildir.

UNS bir ürün değil, bir mimari desendir. Bir satıcı size “UNS kutusu” satamaz. Tipik bileşenleri:

Bileşen	Görev	Tipik teknoloji
Edge bağlantı katmanı	PLC ve cihaz protokollerini okuyup yayımlamak	Edge gateway, OPC UA istemcisi, Sparkplug B edge node
Mesaj aracısı (broker)	Yayın/abonelik, son durum saklama, erişim kontrolü	MQTT broker (3.1.1 veya 5.0)
Bağlamlandırma servisleri	Ham veriye ekipman, iş emri, ürün bilgisi eklemek	Akış işleme, kural motoru, MES
Tüketiciler	Görselleştirme, saklama, analiz, iş süreçleri	SCADA, historian, MES, ERP entegrasyonu, BI

UNS’yi ayıran şey “son bilinen durum” kavramıdır. MQTT’deki retained mesajlar sayesinde yeni bağlanan tüketici her topic’in son değerini hemen alır. Geçmişi sorgulamak historian’ın işidir. UNS geçmiş veri saklamaz; anlık durumu dağıtır.

Sahadan merkeze taşımada Sparkplug B kullanıyorsanız, onun düz topic yapısı ile UNS’nin hiyerarşik ağacı arasında bir dönüşüm katmanı gerekir; bu ayrımı MQTT Sparkplug B rehberinde ayrıntılı anlattık.

ISA-95 hiyerarşisine göre topic ağacı

Ağacın iskeleti için en yaygın başvuru noktası ISA-95’in (IEC 62264) rol tabanlı ekipman hiyerarşisidir: kurum (enterprise), saha (site), alan (area), iş merkezi (hat, proses hücresi, üretim birimi veya depo bölgesi) ve iş birimi (work unit). Bu hiyerarşi işletmenin fiziksel ve organizasyonel yapısını yansıttığı için IT ile OT’nin ortak dili olur. Standarda ISA üzerinden ulaşabilirsiniz.

firma/
└── gebze/                                  # site
    ├── dolum/                              # area
    │   ├── hat3/                           # line (work center)
    │   │   ├── dolum01/                    # work unit
    │   │   │   ├── durum/makine_durumu     # "calisiyor"
    │   │   │   ├── uretim/iyi_adet         # 18420
    │   │   │   ├── uretim/red_adet         # 37
    │   │   │   ├── proses/urun_sicakligi   # {"v": 21.4, "u": "°C", "ts": ...}
    │   │   │   └── olay/durus              # duruş olayı
    │   │   └── hat/aktif_is_emri           # "IE-2026-11-0412"
    │   └── ...
    └── enerji/
        └── ana_pano/aktif_guc

İsimlendirme kurallarını proje başında yazılı hale getirin. Sonradan düzeltmeye kalkarsanız her tüketiciyi tek tek elden geçirirsiniz:

• Küçük harf, Türkçe karaktersiz, boşluksuz; ayırıcı olarak alt çizgi veya tire. Birini seçin, karıştırmayın.
• Topic başında / kullanmayın; boş bir ilk seviye oluşturur. +, # karakterleri ve $ ile başlayan seviyeler MQTT’de özel anlam taşır.
• Ekipman seviyelerinden sonra sabit bir veri sınıflandırması kullanın (durum, uretim, proses, olay, komut gibi). Tüketici böylece firma/gebze/+/+/+/durum/# gibi joker bir abonelikle tüm makinelerin durumunu alır.
• Ekipman adı fiziksel konumu değil işlevsel kimliği temsil etsin. Makine başka hatta taşınırsa topic yolunun değişeceğini kabul edin ve bunun için bir değişiklik süreci tanımlayın.
• Payload biçimini sabitleyin: değer, birim, kaynak zaman damgası ve kalite bilgisi her mesajda aynı alan adlarıyla gelsin.

İş birimi seviyesindeki yapıyı OPC UA tarafındaki tip modeliyle uyumlu kurarsanız dönüşüm basitleşir; ayrıntısı OPC UA bilgi modeli ve Companion Specification yazısında.

Ham veri, bağlamlandırma ve olay verisi

UNS’ye yayımlanan her şey aynı nitelikte değildir. Bunları ayırmazsanız ağaç birkaç ayda çöplüğe döner:

Veri türü	Örnek	Yayımlama biçimi
Ham sinyal	PLC’deki sayaç, sıcaklık, bit	Değişimde; çoğu zaman edge’de
Bağlamlandırılmış değer	Aktif iş emrine ait iyi adet, birimli sıcaklık	Retained; ağacın ana içeriği
Olay	Duruş başladı/bitti, reçete değişti, parti tamamlandı	Retain kapalı; QoS 1
Hesaplanmış değer	Vardiya OEE’si, enerji/adet	Hesaplayan servis yayımlar

Ham PLC adreslerini (DB12.DBW40 gibi) doğrudan UNS’ye taşımak, noktadan noktaya yapının karmaşıklığını broker’a taşımaktan başka bir şey değildir. Edge katmanında ham veri anlamlı isimlere ve birimlere dönüşmeli; iş emri ve ürün gibi bağlamı MES veya ayrı bir servis eklemeli.

Olaylarda retained kullanmayın. Yeni bağlanan tüketici saatler önceki bir “duruş başladı” olayını yeni olay sanar ve yanlış alarm üretir; sahada en sık gördüğümüz UNS hatalarından biri budur. Olayın sonucu olan durum (makine şu an duruşta mı) ayrı bir retained topic’te tutulur. İşlemsel veriler, yani iş emri onayı ve malzeme tüketim bildirimi, ayrı değerlendirilir; bunların ERP ile kesin teslim gerektiren alışverişi ISA-95 ile MES–ERP entegrasyonu yazısının konusu.

Broker mimarisi ve ölçekleme

Broker tüm işletmeye hizmet eden merkezi bileşendir. Mimarinin en ağır kararı burada verilir.

Yaklaşım	Avantaj	Sınırlama
Tek merkezi broker	Basit; tek ağaç, tek ACL	Tekil arıza noktası; saha–merkez bağlantısı koparsa yerel tüketiciler de etkilenir
Kümelenmiş broker	Yüksek erişilebilirlik, yatay ölçekleme	Ürün desteği ve lisans; retained/oturum tutarlılığı test gerektirir
Saha broker’ı + merkez broker’ı (bridge)	Saha bağlantısı kopsa da yerel çalışır; DMZ geçişi kontrol edilir	Bridge tanımları ve döngü önleme dikkat ister

Birden fazla tesisi olan veya OT ile IT arasında DMZ bulunan yapılarda bridge modeli yaygındır: her saha kendi broker’ını OT altyapısında çalıştırır, yalnız seçilen topic alt ağaçları DMZ’deki broker’a aktarılır. Bridge’in yönünü ve kapsamını açık tanımlayın. IT’den OT’ye doğru yalnız komut sınıfındaki belirli topic’ler izin almalı; mümkünse hiçbiri. Mosquitto’da örnek bir bridge tanımı:

connection gebze-to-dmz
address dmz-broker.firma.local:8883
bridge_cafile /etc/mosquitto/certs/ca.crt
bridge_certfile /etc/mosquitto/certs/gebze-bridge.crt
bridge_keyfile /etc/mosquitto/certs/gebze-bridge.key
# yalnız dışarı (out) yönde, QoS 1
topic firma/gebze/+/+/+/durum/# out 1
topic firma/gebze/+/+/+/uretim/# out 1
topic firma/gebze/+/+/+/olay/#   out 1

DMZ’de hangi bileşenin nerede duracağını OT DMZ tasarımı yazısında ele aldık. Ölçeklemede broker’ın yükünü topic sayısı, saniyedeki mesaj sayısı, abone sayısı ve retained mesaj sayısı belirler. Değişimde yayımlama (report by exception) ve uygun deadband değerleri, trafiği sabit aralıklı yayımlamaya göre belirgin şekilde azaltır. Deadband’siz analog sinyal, gürültüsünü de yayımlar. MQTT 5.0’ın paylaşımlı abonelik (shared subscription) özelliği, aynı veriyi işleyen bir servisin birden fazla kopyası arasında yük dağıtır; ayrıntılar OASIS MQTT 5.0 spesifikasyonunda.

Erişim kontrolünü ağaç yapısına bağlayın: bir hattın edge gateway’i yalnız kendi alt ağacına yazar, raporlama aracı yalnız okur, komut topic’lerine yazma yetkisi yalnız tanımlı servislerdedir. Herkesin her yere yazabildiği bir broker, UNS değil, ortak bir panodur.

UNS’nin yanlış tercih olduğu durumlar

UNS her entegrasyon sorununun cevabı değildir. Aşağıdaki durumlarda başka yaklaşım daha doğrudur ya da UNS’ye ek olarak gerekir:

• Gerçek zamanlı kontrol: PLC’ler arası kilitlemeler, hareket kontrolü ve güvenlik fonksiyonları broker üzerinden değil, PROFINET, EtherNet/IP gibi deterministik saha protokolleriyle yapılır.
• Yüksek frekanslı dalga formu verisi: Titreşim analizi gibi kHz düzeyindeki örnekleri tek tek mesaj olarak broker’a basmak doğru değildir; edge’de işleyin, özet değerleri yayımlayın.
• Kesin teslim gerektiren işlemler: İş emri onayı veya stok hareketi gibi ERP kayıtları idempotent API çağrıları ve onay mekanizması ister; yalnız yayın/abonelik modeline güvenmek risklidir.
• Küçük ve kararlı yapılar: İki üç sistemin konuştuğu, değişmeyen bir yapıda broker işletme yükü kazancı aşabilir.
• Sahiplik tanımı yoksa: Topic ağacının ve isimlendirme kurallarının sahibi olmayan bir UNS kısa sürede düzensiz bir topic yığınına döner. Yeni dal ekleme, payload değişikliği ve kullanım dışı bırakma yetkisi bir ekibe atanmalı.

Geçiş genellikle tek bir hat veya alanla başlar: önce isimlendirme kuralı ve payload biçimi sabitlenir, bir edge katmanı kurulur, bir tüketici (örneğin üretim panosu) bağlanır, sonra diğer tüketiciler eski bağlantılarından UNS’ye taşınır. Eski bağlantılar ancak yeni yol doğrulandıktan sonra kapatılır. Planlama için IT/OT entegrasyon danışmanlığı, edge ve broker katmanının kurulumu için OPC UA, MQTT ve veri entegrasyonu sayfalarımıza bakabilirsiniz.

Sık sorulan sorular

Unified Namespace için mutlaka MQTT mi kullanılmalı?

Zorunlu değil. Yayın/abonelik modeli, retained mesajla son durum saklama ve hiyerarşik topic yapısı nedeniyle MQTT en yaygın tercihtir. Kavram olarak UNS, iş yapısını yansıtan tek bir olay odaklı veri katmanıdır ve başka mesajlaşma altyapılarıyla da kurulabilir.

UNS historian’ın yerini alır mı?

Hayır. UNS işletmenin anlık durumunu dağıtır, geçmiş veriyi saklamaz. Historian UNS’ye abone olan tüketicilerden biridir; zaman serisi sorgularını, trend analizini ve uzun süreli saklamayı o üstlenir.

Mevcut SCADA’yı UNS’ye bağlamak için baştan kurmak gerekir mi?

Gerekmez. Birçok SCADA ürünü MQTT istemcisi olarak abone olabilir veya kendi verisini yayımlayabilir. Destek yoksa ara bir dönüştürücü kullanılır. Geçişi mevcut bağlantıları bir anda kapatmadan, tüketicileri tek tek UNS’ye taşıyarak yapın.

Makine fiziksel olarak başka hatta taşınırsa topic ağacında ne olur?

Topic yolu ekipmanın hiyerarşideki yerini yansıttığı için değişir. Taşıma için bir değişiklik süreci tanımlayın, tüketicilere eski ve yeni yolu bildiren bir geçiş dönemi uygulayın ve historian’da varlık kimliğini topic yolundan bağımsız tutun.