Bir Unified Namespace kurulduktan sonra değiştirilmesi en zor şey adlardır: her ad değişikliği o dala abone olan tüm sistemleri etkiler. Bu yüzden adlandırma kararlarını teknik detaydan çok bir sözleşme olarak ele almak gerekir.
ISA-95 ile hiyerarşi
ISA-95 ekipman hiyerarşisi, UNS için doğal bir iskelet sunar. Yaygın bir düzen şöyledir:
| Seviye | Anlamı | Örnek |
|---|---|---|
| İşletme (enterprise) | Şirket veya iş birimi | acme |
| Tesis (site) | Fiziksel tesis | istanbul |
| Alan (area) | Tesis içi bölüm | paketleme |
| Hat (line) | Üretim hattı / iş merkezi | hat-3 |
| Hücre (cell) | İsteğe bağlı alt bölüm | dolum |
| Varlık (asset) | Makine veya ekipman | dolum-02 |
| Metrik (metric) | Ölçüm veya durum | sicaklik |
Sonuç: acme/istanbul/paketleme/hat-3/dolum/dolum-02/sicaklik. Her tesisin ihtiyacı farklıdır; hücre gibi seviyeleri atlayabilirsiniz, ancak aynı işletme içinde sıra ve anlam tutarlı kalmalıdır.
MQTT’nin getirdiği kısıtlar
- Topic adları büyük/küçük harfe duyarlıdır:
Hat-3ilehat-3farklı dallardır. /seviye ayırıcıdır; ad içinde kullanılamaz.+(tek seviye) ve#(çok seviyeli) joker karakterleri yalnızca abonelik filtrelerinde bulunur; yayın yaptığınız topic adında yer alamaz.$ile başlayan konular genellikle aracı tarafından kendi amaçları için ayrılmıştır (ör.$SYS); işletme adınızı bununla başlatmayın.- Topic uzunluğu pratikte çok daha kısa olmalıdır; çok uzun yollar bakımı ve ağ yükünü artırır.
Pratik adlandırma kuralları
- Küçük harf, tire: Boşluk ve büyük/küçük harf karışıklığından kaçının.
dolum-02güvenle okunur ve yazılır. - ASCII: Türkçe karakterler (ş, ğ, ı) farklı sistemlerde sorun çıkarabilir; sadeleştirin (
sicaklik). - Genelden özele: Aboneliklerin dallara göre yapılabilmesi için sıra sabit olmalıdır.
- Kararlı adlar: Yola, değişebilecek bilgileri (sipariş no, vardiya, operatör) koymayın; onları yükte (payload) taşıyın.
- Birimi yola değil modele koyun:
sicaklik-cyerinesicakliktopic’i ve yükte{"deger":74.2,"birim":"°C"}. - Derinliği sınırlayın: Her yeni seviye, abonelik filtrelerini ve erişim kurallarını karmaşıklaştırır.
- Tek dil, tek sözlük: “hat/line”, “makine/machine” gibi karışık kullanımdan kaçının; bir adlandırma sözlüğü tutun.
Sparkplug B ile fark
Sparkplug B kendi topic yapısını dayatır: spBv1.0/{group_id}/{message_type}/{edge_node_id}[/{device_id}]. Burada ISA-95 hiyerarşisi topic yolunda değil, genellikle metrik adlarında veya group/node/device eşlemelerinde taşınır. Düz MQTT tabanlı UNS’de hiyerarşi doğrudan yoldadır. Hangisini seçeceğiniz; cihaz keşfi ve durum yönetimi ihtiyacınıza, kullandığınız ürünlerin desteğine ve ekibin tercihine bağlıdır. Her iki yapıyı da deneyebileceğiniz Sparkplug B ve UNS Topic Oluşturucu aracımız ücretsizdir ve tarayıcıda çalışır.
Abonelik ve erişim tasarımı
İyi bir hiyerarşi, aboneliği de kolaylaştırır:
acme/istanbul/paketleme/hat-3/#— bir hattın tüm verisiacme/istanbul/+/+/+/durum— tesisteki tüm varlıkların durumu (seviye sayısı sabit olduğunda)
Erişim kontrolünü de dallar üzerinden tanımlayabilirsiniz: bir hat gateway’i yalnızca kendi dalına yazabilir; bir pano yalnızca okuyabilir. Bu, hem güvenliği hem de hata yayılımını sınırlar. Aracıların ağdaki yeri için OT ağ segmentasyonu yazımıza bakın.
Sık yapılan hatalar
- Topic’e zaman veya sipariş bilgisi koymak (sonsuz sayıda dal üretir).
- Her projede farklı hiyerarşi kullanmak.
- Ad değiştirirken eski dalı kaldırmamak ve iki kopya veri yayımlamak.
- Saklı (retained) mesajları temizlemeyi unutmak; retain ve Last Will yazımızda ayrıntılar var.