Unified namespace'in nasıl kurulacağını bilmek, popüler bir kavramı çalışan bir mimariye dönüştürür: her makinenin, hattın ve sistemin güncel durumunu öngörülebilir, hiyerarşiye dayalı bir topic altında yayınladığı tek bir MQTT broker. Bu rehberde tesisinizi modelleyecek, bir broker seçecek, Python ile sahadan retained veri yayınlayacak, tüm tesis durumunu okuyan bir tüketici ekleyecek ve namespace büyüdükçe kullanılabilir kalmasını sağlayan yönetişim kurallarını hayata geçireceksiniz.
Ne İnşa Ediyorsunuz?
Unified namespace (UNS) bir ürün değildir. Bir mutabakattır: tüm üreticiler ortak bir yapıya göre düzenlenmiş tek bir olay güdümlü merkeze yayın yapar, tüm tüketiciler de noktadan noktaya entegrasyonlar kurmak yerine ihtiyaç duydukları veriye abone olur. Pratikte bu merkez bir MQTT broker, yapı ise genellikle ISA-95 ekipman hiyerarşisidir.
Tamamlanmış mimari dört katmandan oluşur:
| Katman | Sorumluluk | Tipik bileşenler |
|---|---|---|
| Saha (Edge) | Makineleri okumak ve durum yayınlamak | PLC gateway'leri, OPC UA veya Modbus köprüleri, Sparkplug edge node'ları |
| Merkez (Hub) | Yönlendirmek ve güncel durumu tutmak | Retained message destekli MQTT broker |
| Yapı | Veriyi bulunabilir kılmak | ISA-95 topic ağacı, payload kuralları |
| Tüketiciler | Veriyi kullanmak | Panolar, historian'lar, MES, analitik, alarm |
Temel özellik, bileşenlerin birbirinden ayrışmasıdır. Historian, PLC'nin varlığından habersizdir; PLC gateway'i de kimin dinlediğini bilmez. Her biri yalnızca bir kez, broker'a bağlanır.
Adım 1: Tesis Hiyerarşinizi Modelleyin
Tek satır kod yazmadan önce tesisin namespace içinde nasıl düzenleneceğine karar verin. ISA-95 ekipman hiyerarşisi size kanıtlanmış bir başlangıç noktası sunar: kuruluş (enterprise), saha (site), alan (area), hat (veya proses hücresi) ve hücre ya da makine. ISA-95 ekipman hiyerarşisi rehberimiz her seviyeyi tesis örnekleriyle açıklıyor.
Pilot alan için kısa bir listeyi adım adım tamamlayın:
- Kapsamdaki sahaları listeleyin ve her birine kısa, kalıcı, küçük harfli bir tanımlayıcı verin (
dallas,izmir). - Bir sahanın içinde alanları listeleyin (
packaging,utilities,machining). - Bir alanın içinde hatları ve makinelerini listeleyin (
line2/filler,line2/capper). - Her makinenin altında ne olacağına karar verin: tek bir
telemetrynesnesi mi, ayrı metrik topic'leri mi, yoksa ikisi birden mi. - Sonucu bir topic ağacı olarak yazın ve operasyon, mühendislik ve BT ekiplerinin üzerinde uzlaşmasını sağlayın.
İlk pilot ağaç şöyle görünebilir:
acme/dallas/packaging/line2/filler/telemetry
acme/dallas/packaging/line2/filler/state
acme/dallas/packaging/line2/capper/telemetry
acme/dallas/utilities/compressors/comp1/telemetry
Bu adıma zaman ayırın. Yirmi tüketici bir topic'e bağımlı hale geldikten sonra onu yeniden adlandırmak zahmetlidir. ISA-95 MQTT topic'leri ve UNS topic yapısı rehberlerimiz hazır ağaçlar ve kaçınılması gereken tuzakları içeriyor.
Adım 2: Merkezi Broker'ı Seçin
Broker, çalıştırdığınız en önemli tesis yazılımı haline gelir; bu yüzden bilinçli seçim yapın. Eski gateway'ler için MQTT 3.1.1'i, yeni istemciler için MQTT 5'i, güncel durum için retained message'ları, istemci bazlı kimlik bilgileriyle TLS'i ve eklemeyi planladığınız her gateway ile tüketici için yeterli bağlantı kapasitesini desteklemelidir. Tam kontrol listesi için IoT MQTT broker nasıl seçilir yazımıza bakın.
Broker'ı tesisteki bir sunucuda kendiniz çalıştırabilir ya da başkasının işlettiği bir bulut MQTT broker kullanabilirsiniz. Tesisler pilot için çoğunlukla barındırılan bir broker ile başlar, çünkü bu, sunucu yamalama ve izleme işlerini kritik yoldan çıkarır. Örneğin ConnectMQ her broker'a MQTT 3.1.1 ve 5.0, 8883 portunda TLS, canlı bir topic gezgini ve canlı cihazları ISA-95 seviyelerine göre gruplayan bir cihazlar görünümü sunar; namespace şekillenirken görmek istediğiniz de tam olarak budur.
Bu rehber için broker.connectmq.com adresindeki herkese açık test broker'ını kullanabilirsiniz. Hesap gerektirmez, ancak orada yayınlanan her şeyi herkes okuyabilir; bu nedenle topic'lerin başına connectmq/demo/<random-id>/ ekliyor ve yalnızca simüle değerler yayınlıyoruz. Herkese açık broker en fazla 8 topic seviyesine izin verir; bu da connectmq/demo/k4p9/dallas/packaging/line2/filler/telemetry için tam olarak yeterlidir.
Adım 3: Saha Verisini Retained Durum Olarak Yayınlayın
Saha katmanı makineleri okur ve güncel durumlarını yayınlar. Gerçek kurulumlarda OPC UA, Modbus veya PLC sürücüleri kullanılır; burada yayınlama kurallarını net görebilmeniz için bir Python betiği gateway rolünü üstleniyor. İstemciyi pip install "paho-mqtt>=2.0" ile kurun.
import json
import random
import time
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/k4p9" # k4p9'u kendi rastgele kimliğinizle değiştirin
MACHINES = [
("dallas", "packaging", "line2", "filler"),
("dallas", "packaging", "line2", "capper"),
]
def on_connect(client, userdata, flags, reason_code, properties):
print("gateway connected:", reason_code)
for site, area, line, machine in MACHINES:
state_topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/state"
client.publish(state_topic, "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-gateway-k4p9")
client.on_connect = on_connect
# Gateway çökerse broker ilk makineyi herkes için çevrimdışı olarak işaretler
client.will_set(f"{PREFIX}/dallas/packaging/line2/filler/state", "offline", qos=1, retain=True)
client.connect(BROKER, 1883, keepalive=30)
client.loop_start()
counts = {m[3]: 0 for m in MACHINES}
try:
while True:
for site, area, line, machine in MACHINES:
counts[machine] += random.randint(4, 6)
payload = {
"timestamp": datetime.now(timezone.utc).isoformat(),
"speed_bpm": round(random.uniform(110, 125), 1),
"temperature_c": round(random.uniform(38, 44), 1),
"good_count": counts[machine],
}
topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/telemetry"
client.publish(topic, json.dumps(payload), qos=1, retain=True)
time.sleep(5)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Bu betiği yalnızca veri gönderen bir araç olmaktan çıkarıp bir UNS yayıncısı yapan üç kural vardır. Her mesaj retained olarak gönderilir; böylece yeni bir tüketici güncel değeri anında alır. Payload'lar kendi zaman damgasını taşır ve birimler alan adlarında yer alır. Makine erişilebilirliği de açıkça belirtilir: gateway ortadan kaybolduğunda durumu offline yapan bir will mesajı tanımlıdır.
Saha katmanınız zaten Sparkplug B konuşuyorsa onu yeniden yazmanız gerekmez. ConnectMQ, Sparkplug B payload'larını çözer ve bunları ISA-95 topic'lerine yeniden yayınlayabilir; örneğin spBv1.0/factory1/DDATA/line1/cnc1 verisini connectmq/factory1/production/line1/cnc1/telemetry altına. Bu sayede Sparkplug edge node'ları ve düz JSON yayıncıları tek bir namespace'i paylaşabilir. İkisi arasındaki ödünleşimler MQTT, Sparkplug B ve unified namespace yazımızda ele alınıyor.
Adım 4: İlk Tüketicilerinizi Ekleyin
Bir namespace, sahaya kimse dokunmadan yeni tüketiciler eklenebildiğinde değerini kanıtlar. Aşağıdaki abone, tek bir joker karakterli abonelikle tüm tesisin bellek içi bir modelini oluşturur:
import json
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/k4p9"
plant = {}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/#", qos=1)
def on_message(client, userdata, msg):
levels = msg.topic[len(PREFIX) + 1:].split("/")
if len(levels) != 5:
return
site, area, line, machine, kind = levels
node = plant.setdefault(site, {}).setdefault(area, {}).setdefault(line, {}).setdefault(machine, {})
text = msg.payload.decode()
node[kind] = json.loads(text) if kind == "telemetry" else text
print(f"{site}/{area}/{line}/{machine} {kind}: {node[kind]}" + (" (retained)" if msg.retain else ""))
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-viewer-k4p9")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Gateway çalışırken bu betiği başlatın ve ilk mesajların retained olarak işaretlendiğine dikkat edin: tüketici, abone olduğu anda tesisin tam resmine sahipti. Kapsamı önekten sonra joker karakterlerle daraltın; örneğin her sahadaki tek bir alan için connectmq/demo/k4p9/+/packaging/#, her yerdeki tüm dolum makineleri için connectmq/demo/k4p9/+/+/+/filler/telemetry.
Tipik sonraki tüketiciler bir pano, bir historian ve bir alarm servisidir. Her biri yalnızca bir abone daha demektir. Depolama için MQTT historian rehberimiz, zaman serisi veritabanlarını besleyen Telegraf ve Python abonelerini gösteriyor; namespace güncel gerçeğin kaynağı olarak kalırken geçmişi depolama katmanı tutar.
Adım 5: Namespace'i Yönetin
Kurallar olmadan bir UNS birkaç ay içinde bir topic bataklığına dönüşür. İkinci alan katılmadan önce şunları devreye alın:
- Adlandırma standardı. Küçük harf, boşluk yerine tire; topic'lerde kişi adları veya talep numaraları yok.
- Sahiplik. Ağacın her dalının, yeni topic'leri onaylayan bir sahibi vardır.
- Payload sözleşmesi. Her topic türü için birim ve zaman damgası kurallarını içeren belgelenmiş bir JSON şeması.
- Yayıncı başına kimlik bilgisi. Kimin neyi yayınladığını görebilmek ve erişimi temiz biçimde iptal edebilmek için her gateway veya uygulama başına bir kimlik.
- Değişiklik süreci. Yeni topic'ler eklenir, eskiler bir kullanımdan kaldırma tarihiyle emekliye ayrılır; asla sessizce yeniden adlandırılmaz.
- Gözlemlenebilirlik. Birileri bağlantı durumunu, mesaj hızlarını ve bayatlamış topic'leri izler.
ConnectMQ portalı gözlemlenebilirlik tarafında yardımcı olur: canlı topic gezgini ağacı büyüdükçe gösterir, ISA-95 cihazlar görünümü her canlı cihazın hangi kuruluş, saha, alan ve hatta ait olduğunu gösterir ve eşik alarm kuralları bir değer sınırı aştığında sizi bilgilendirir.
UNS Kurarken Yapılan Yaygın Hatalar
| Hata | Sonuç | Daha iyi yaklaşım |
|---|---|---|
| Tüm tesisle başlamak | Herhangi bir değer üretmeden aylarca modelleme | Tek bir hatla pilot yapın, sonra genişletin |
| Retained olmayan durum | Yeni tüketiciler değerler değişene kadar hiçbir şey görmez | Güncel durum topic'lerini retained yapın |
| Topic yolunda teknoloji adı | opcua/ ve modbus/ tüketicilere sızar |
Protokolü değil, tesisi modelleyin |
| Tek ortak broker girişi | Hesap verebilirlik yok, riskli erişim iptali | İstemci başına bir kimlik bilgisi |
| UNS'yi veritabanı olarak kullanmak | Broker, hiç amaçlanmadığı halde geçmiş verisini tutar | Bir historian veya veri gölü abone olur |
Daha geniş endüstriyel bağlam için endüstriyel IoT MQTT rehberimize göz atın.
Unified Namespace'inizi ConnectMQ Üzerinde Kurun
Bir unified namespace, ayakta kalacağına güvenebileceğiniz bir broker'a ve büyüdükçe topic ağacının net bir görünümüne ihtiyaç duyar. ConnectMQ; MQTT 3.1.1 ve 5.0, TLS, retained message'lar, Sparkplug B çözümleme, ISA-95'e yeniden yayınlama ve ISA-95 cihazlar görünümü sunan bir yönetilen MQTT broker hizmetidir. Pilotunuzu kredi kartı gerektirmeden app.connectmq.com adresinde ücretsiz Serverless planıyla başlatın; daha fazla hat katıldıkça ücretli, Dedicated veya BYOC plana geçin.
Sık Sorulan Sorular
Unified namespace kurmak için Sparkplug B gerekli mi?
Hayır. Pek çok namespace, MQTT üzerinden düz JSON kullanır. Sparkplug B durum yönetimi ve tipli metrikler ekler; broker Sparkplug verisini okunabilir topic'lere yeniden yayınlıyorsa ikisi bir arada var olabilir.
UNS broker'ı tesis içinde mi yoksa bulutta mı çalışmalı?
İkisi de işe yarar. Tesis içi kurulum trafiği yerelde tutar; barındırılan bir broker ise operasyon yükünü ortadan kaldırır ve sahalar arası erişimi kolaylaştırır. Pek çok tesis pilota barındırılan bir broker ile başlar ve öğrendiklerine göre karar verir.
İlk UNS pilotu ne büyüklükte olmalı?
Birkaç makine ve iki üç tüketiciyle tek bir hat veya tek bir alan, deseni kanıtlamak ve adlandırma standardını olgunlaştırmak için yeterlidir.
Unified namespace bir historian'ın yerini alır mı?
Hayır. UNS güncel durumu ve olayları tutar; bir historian veya veri gölü ona abone olur ve uzun vadeli geçmişi saklar.



