Sparkplug topic namespace, her Sparkplug B mesajının kullandığı sabit yapıdır: spBv1.0/group_id/message_type/edge_node_id/device_id. Bu rehberde her öğenin ne anlama geldiğini, grupları, node'ları ve cihazları yönetilebilir kalacak şekilde nasıl adlandıracağınızı ve izleme, komut gönderme ve hata ayıklama için hangi wildcard aboneliklerine ihtiyaç duyduğunuzu öğreneceksiniz.
Sparkplug Topic Yapısını Neden Sabitler?
Düz MQTT, istediğiniz herhangi bir topic hiyerarşisini icat etmenize izin verir. Bu özgürlük tek bir proje için harikadır, ancak her entegratörün farklı bir şema seçtiği bir tesis genelinde can sıkıcıdır. Sparkplug bu seçimi ortadan kaldırır. Topic'ler tek bir kalıbı izler; böylece Sparkplug'dan haberdar herhangi bir host uygulaması, sahaya özel yapılandırma gerektirmeden her edge node'u ve cihazı keşfedebilir.
Bunun bedeli, topic'in tesis hiyerarşinizi grup, node ve cihazın ötesinde tanımlamamasıdır. Saha, alan ve hat bilgisi ya grup ve node ID'lerinde ya da metrik adlarının içinde yer alır. Bu ayrım bir Unified Namespace tasarlarken önemlidir; aşağıda buna geri döneceğiz.
Öğe Öğe Sparkplug Topic Namespace
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
| Öğe | Örnek | Anlamı | Zorunlu |
|---|---|---|---|
| Namespace | spBv1.0 |
Sparkplug B payload sürümünü tanımlar | Her zaman |
| group_id | factory1 |
Edge node'ların mantıksal gruplaması | Her zaman |
| message_type | DDATA |
Mesajın türü | Her zaman |
| edge_node_id | line1 |
Gateway veya edge node | Her zaman |
| device_id | cnc1 |
Edge node'un arkasındaki bir cihaz | Yalnızca D mesajları için |
Namespace: spBv1.0
İlk seviye her zaman spBv1.0 sabit dizesidir. Tüketicilere payload'ın Sparkplug B Protobuf olduğunu bildirir. Eski Sparkplug A, spAv1.0 kullanıyordu ve kullanımdan kaldırılmıştır. Başka bir şeyle başlayan bir topic görürseniz, payload tesadüfen Protobuf olsa bile bu Sparkplug B değildir.
group_id
Grup ID'si edge node'ları mantıksal olarak gruplar. Birçok ekip bir saha veya alan kullanır; örneğin plant-izmir ya da packaging. Bir host uygulaması çoğu zaman grup bazında abone olur, bu nedenle izlemeyi ve yetkileri nasıl bölmek istediğinize uyan gruplar seçin.
message_type
Namespace'in kalbi budur. Tüketiciye payload'ı nasıl ele alacağını söyler:
| Tip | Gönderen | Amaç |
|---|---|---|
| NBIRTH | Edge node | Node çevrimiçi oldu, tüm node metriklerini duyurur |
| NDEATH | Broker (will) veya node | Node çevrimdışı oldu |
| DBIRTH | Edge node | Cihaz çevrimiçi oldu, cihaz metriklerini duyurur |
| DDEATH | Edge node | Cihaz çevrimdışı oldu |
| NDATA | Edge node | Değişen node metrik değerleri |
| DDATA | Edge node | Değişen cihaz metrik değerleri |
| NCMD | Host uygulaması | Edge node'a komut, örneğin rebirth |
| DCMD | Host uygulaması | Cihaza komut, örneğin bir setpoint yazma |
| STATE | Host uygulaması | Host çevrimiçi/çevrimdışı durumu |
Birth ve death tipleri, Sparkplug'ı güvenilir kılan durum modelini taşır. Sparkplug birth ve death sertifikaları rehberimiz tüm yaşam döngüsünü açıklıyor.
edge_node_id
Edge node ID'si, MQTT bağlantısını tutan gateway'i, PLC'yi veya yazılımı tanımlar. Kendi grubu içinde benzersiz olmalıdır. Aynı ID'yi paylaşan iki node birbirinin birth mesajlarının üzerine yazar ve sıra numaralarını bozar; bu, devreye almada en sık karşılaşılan hatalardan biridir.
device_id
Cihazlar bir edge node'un arkasında yer alır: bir CNC, bir sürücü, bir Modbus sayacı. Cihaz seviyesindeki mesajlar (DBIRTH, DDEATH, DDATA, DCMD) beşinci seviye olarak cihaz ID'sini ekler. Node seviyesindeki mesajlar edge node ID'sinde biter.
STATE topic'i
STATE mesajı bu kalıbın istisnasıdır. Sparkplug 3.0'da küçük bir JSON payload ile spBv1.0/STATE/{host_id} şeklindedir ve Sparkplug primary host uygulaması tarafından retained olarak yayınlanır. Eski 2.2 implementasyonları namespace öneki olmadan STATE/{host_id} kullanıyordu. Karışık sürümler çalıştırıyorsanız, host'unuzun ve node'larınızın hangi biçimi beklediğini kontrol edin.
İleride Sizi Kurtaracak Adlandırma Kuralları
Spesifikasyon, MQTT özel karakterleri olan +, # ve / karakterlerinin grup, node ve cihaz ID'lerinde kullanılmasını yasaklar; çünkü bunlar topic seviyelerini bozar. Bunun ötesinde birkaç gelenek işinizi kolaylaştırır:
- Yalnızca küçük harf, rakam ve tire kullanın. Karışık büyük/küçük harf, sistemler arasında uyumsuzluklara davetiye çıkarır.
- ID'leri sabit tutun. Bir edge node'u yeniden adlandırmak, host açısından yeni bir node oluşturur ve geçmiş bölünebilir.
- Firmware sürümü veya IP adresi gibi değişen değerleri bir ID'ye kodlamayın.
- Topic seviyesi eklemeye çalışmak yerine daha derin hiyerarşiyi metrik adlarına koyun; örneğin
Spindle/Speed. - Yeni entegratörlerin node'ları doğru yere yerleştirmesi için her grubun anlamını belgeleyin.
- ID'leri kısa tutun. Her topic'te tekrarlanırlar ve her logda görünürler.
Kullanışlı Abonelikler
Sabit yapı, wildcard aboneliklerini öngörülebilir kılar. İşte en sık kullanacağınız kalıplar:
spBv1.0/# everything Sparkplug on the broker
spBv1.0/factory1/# everything in one group
spBv1.0/+/NBIRTH/# every node birth, all groups
spBv1.0/+/DDATA/+/+ every device data message
spBv1.0/factory1/+/line1/# everything from one edge node
spBv1.0/factory1/DDATA/line1/cnc1 one device's data
spBv1.0/STATE/+ host application status
Sırasıyla: broker'daki tüm Sparkplug trafiği, tek bir gruptaki her şey, tüm gruplardaki her node birth'ü, her cihaz veri mesajı, tek bir edge node'dan gelen her şey, tek bir cihazın verisi ve host uygulaması durumu.
Bunları herkese açık MQTT test broker'ında deneyebilirsiniz. Herkese açık alan herkes tarafından okunabilir; bu yüzden rastgele bir grup ID'si kullanın ve oraya asla gerçek tesis verisi yayınlamayın:
mosquitto_sub -h broker.connectmq.com -p 1883 -i ns-explorer-5c21 -t "spBv1.0/demo-5c21/#" -v
İkinci bir terminalde, bir cihaz veri topic'ine test mesajı yayınlayın. Buradaki payload yalnızca yönlendirmeyi doğrulamak için düz metindir; gerçek bir node Protobuf gönderir:
mosquitto_pub -h broker.connectmq.com -p 1883 -i ns-pub-5c21 -t "spBv1.0/demo-5c21/DDATA/line1/cnc1" -m "routing test"
Herkese açık broker'daki Sparkplug topic'lerinin beş seviye kullandığını ve bunun sekiz seviyelik sınırın rahatça içinde kaldığını unutmayın; dolayısıyla bir Sparkplug simülatörü orada değişiklik yapmadan çalışır.
Namespace'e Bir Topic Gezgininde Göz Atmak
Bir namespace'i ağaç olarak görebildiğinizde anlamak çok daha kolaydır. ConnectMQ portalındaki topic gezgini spBv1.0 topic'lerini geldikçe gösterir ve broker Sparkplug B'yi çözdüğü için bir DDATA topic'ine tıklayıp ham baytlar yerine metriklerini okuyabilirsiniz. Bu, yeni bir edge node'un birth mesajını yayınlayıp yayınlamadığı veya belirli bir node'un altında hangi cihazların bulunduğu gibi devreye alma sorularını hızla yanıtlamanızı sağlar.
ConnectMQ, Sparkplug verisini ISA-95 topic'lerine de yeniden yayınlayabilir. spBv1.0/factory1/DDATA/line1/cnc1 üzerindeki bir mesaj connectmq/factory1/production/line1/cnc1/telemetry üzerinde kullanılabilir hâle gelir; bu, tesis hiyerarşisi bekleyen dashboard'lar ve araçlar için daha kullanıcı dostudur.
Sparkplug Topic'leri ve Unified Namespace
Sparkplug topic namespace tasarım gereği düzdür: grup, node, cihaz. Bir Unified Namespace ise genellikle ISA-95'i izler: kuruluş, saha, alan, hat, hücre. Bu iki görünüm pek çok mimaride bir arada var olur. Sparkplug, edge'den güvenilir ve durumdan haberdar taşımayı üstlenir; bir ISA-95 ağacı ise insanlara ve uygulamalara gezinilebilir bir model sunar. Tasarım gerekçeleri için MQTT, Sparkplug B ve Unified Namespace yazımızı, daha geniş bağlam için ise MQTT ile Endüstriyel IoT rehberini okuyun.
Topic Sorunlarını Giderme
| Belirti | Olası neden | Kontrol edilecek |
|---|---|---|
| Host bir node'u hiç görmüyor | Topic'te yazım hatası veya spBv1.0 içinde yanlış büyük/küçük harf |
Namespace dizesinin birebir doğruluğu, büyük/küçük harfe duyarlı |
| İki node sürekli rebirth yapıyor | Aynı grupta yinelenen edge node ID'si | Grup başına benzersiz ID'ler |
| Komutlar alınmıyor | Node, NCMD/DCMD topic'lerine abone değil | Node'un spBv1.0/group/NCMD/node ve DCMD'ye abone olması |
| Cihaz verisi yok sayılıyor | DDATA, DBIRTH'ten önce gönderildi | Cihaz önce DBIRTH yayınlamalı |
| Host durumu eksik | Host ve node'lar STATE topic biçiminde anlaşamıyor | 2.2 ile 3.0 STATE topic'i |
Bir topic sorunundan şüphelendiğinizde, ayrıntılı çıktı ile spBv1.0/your-group/# topic'ine abone olun ve başlatma sırasında mesajların sırasını izleyin. Önce birth mesajları, ardından veri gelmelidir.
Nerede Çalıştıracağınızı Seçmek
Sparkplug trafiği standartlara uygun herhangi bir MQTT broker üzerinde çalışır, ancak üretim tesisleri kimlik bilgilerine, TLS'e ve çalışma süresinden sorumlu birine ihtiyaç duyar. Barındırılan bir MQTT broker altyapıyı üstlenir; böylece ekibiniz adlandırma, modelleme ve entegrasyona odaklanabilir. Birth ve veri akmaya başladığında sıradaki adım payload'ların kendisini okumaktır; bu konu Sparkplug B payload rehberimizde ele alınıyor.
ConnectMQ ile Başlayın
app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun. Edge node'unuzu oluşturulan kimlik bilgileriyle 8883 portu üzerinden TLS ile bağlayın ve Sparkplug topic namespace'inize ConnectMQ topic gezgininde çözülmüş ve düzenlenmiş olarak göz atın.
Sık Sorulan Sorular
Bir Sparkplug topic'ine daha fazla seviye ekleyebilir miyim?
Hayır. Sparkplug topic namespace, node mesajları için dört, cihaz mesajları için beş seviyede sabittir. Ek hiyerarşiyi metrik adlarına koyun veya veriyi bir ISA-95 ağacına eşleyin.
Grup ID'si bir sahayla aynı şey mi?
Olabilir, ancak spesifikasyon onu yalnızca edge node'ların mantıksal bir gruplaması olarak tanımlar. Birçok ekip, host uygulamalarının kapsamına bağlı olarak saha başına veya alan başına bir grup kullanır.
STATE topic'i neden farklı görünüyor?
STATE mesajları edge node'lardan değil host uygulamalarından gelir; bu nedenle node ve cihaz kalıbını izlemezler. Sparkplug 3.0'da topic spBv1.0/STATE/{host_id} şeklindedir.
Sparkplug topic'leri büyük/küçük harfe duyarlı mı?
Evet. MQTT topic'leri büyük/küçük harfe duyarlıdır; bu yüzden spBv1.0 ile SPBV1.0 farklı topic'lerdir, Line1 ile line1 de öyle.
