Sparkplug B vs JSON, her endüstriyel MQTT projesindeki ilk tasarım kararlarından biridir ve cevap nadiren "sonsuza dek ya biri ya diğeri" olur. Bu karşılaştırmada iki yaklaşımın birlikte çalışabilirlik, durum farkındalığı, bant genişliği ve araçlar açısından nasıl ayrıldığını, her birinin ne zaman uygun olduğunu ve makineler Sparkplug konuşurken insanların ve dashboard'ların JSON okuyabilmesi için ikisini nasıl birleştireceğinizi öğreneceksiniz.
İki Farklı Felsefe
MQTT'nin kendisi bir mesajın içinde ne olduğuyla ilgilenmez. Bu hem onun gücüdür hem de bu tartışmanın var olma sebebidir.
MQTT üzerinde düz JSON, kendi topic'lerinizi ve payload'larınızı tasarlamanız anlamına gelir. Bir sıcaklık sensörü plant1/hall2/sensor7/telemetry topic'ine {"temp": 21.4, "unit": "C", "ts": 1792137600} yayınlayabilir. Herkes okuyabilir, her dil parse edebilir ve beş dakikada başlayabilirsiniz.
Sparkplug B, MQTT üzerine kurulu bir spesifikasyondur. Topic yapısını sabitler (spBv1.0/group/type/node/device), payload'ları Protobuf ile kodlar ve birth ile death sertifikaları, sıra numaraları ve komutlardan oluşan bir durum modeli ekler. Özgürlükten vazgeçer, karşılığında Sparkplug'dan haberdar herhangi bir SCADA veya host uygulamasıyla birlikte çalışabilirlik kazanırsınız.
İşte aynı okuma JSON olarak:
{
"timestamp": 1792137600123,
"spindleSpeed": 1462.3,
"spindleRunning": true
}
Sparkplug B olarak eşdeğer DDATA payload'ı binary Protobuf'tur. Çözüldükten sonra şöyle görünür, ancak ağ üzerinde adlar yerine alias'lar içeren kompakt baytlardan oluşur:
{
"timestamp": 1792137600123,
"seq": 17,
"metrics": [
{ "alias": 3, "datatype": 10, "doubleValue": 1462.3 },
{ "alias": 4, "datatype": 11, "booleanValue": true }
]
}
Yan Yana Sparkplug B ve JSON
| Kriter | Düz JSON | Sparkplug B |
|---|---|---|
| Topic yapısı | Sizin seçiminiz | Sabit spBv1.0 namespace |
| Payload kodlaması | Metin, insan tarafından okunabilir | Binary Protobuf |
| Şema | Gayriresmî, projeye göre | Spesifikasyonla tanımlı |
| Veri tipleri | JSON number, string, bool | Int8'den UInt64'e, Float, Double, DateTime, DataSet, Template ve daha fazlası açıkça |
| Cihaz çevrimiçi/çevrimdışı | Kendiniz kurarsınız (LWT, durum topic'leri) | NBIRTH/NDEATH/DBIRTH/DDEATH ile yerleşik |
| Kayıp mesajları algılama | Kendiniz kurarsınız | Sıra numaraları |
| Metrik keşfi | Dokümantasyon veya gelenekler | Birth mesajları her metriği listeler |
| Payload boyutu | Daha büyük, adlar her mesajda tekrarlanır | Kompakt, birth'ten sonra alias'lar |
| Genel araçlarda okunabilirlik | Mükemmel | Decoder gerektirir |
| SCADA birlikte çalışabilirliği | Her sistem için özel eşleme | Sparkplug host'larıyla tak ve çalıştır |
| Öğrenme eğrisi | Düşük | Orta |
| Cihazlara komutlar | Kendi geleneğiniz | NCMD ve DCMD |
Sparkplug B'nin Kazandığı Yerler
Birlikte çalışabilirlik
Sparkplug lehine en güçlü argüman, bir üreticinin gateway'i ile başka bir üreticinin SCADA sisteminin bir eşleme projesi olmadan birlikte çalışabilmesidir. Host birth mesajlarını okur, her metriği veri tipiyle birlikte keşfeder ve veriyi göstermeye başlar. JSON'da ise her yeni veri kaynağı için birinin alan adları, birimler ve zaman damgaları üzerinde uzlaşması gerekir.
Durum farkındalığı
Sparkplug size yalnızca son değeri değil, bu değerin hâlâ geçerli olup olmadığını da söyler. Bir gateway'in gücü kesildiğinde broker NDEATH'ini yayınlar ve her host ilgili tag'leri bayat olarak işaretler. JSON'da bunu bir durum topic'indeki last will ile yaklaşık olarak sağlayabilirsiniz, ancak ayrıca retained değerlere, cihaz seviyesinde durum için bir geleneğe ve her tüketicide mantığa ihtiyaç duyarsınız.
Bant genişliği
Metrik alias'larıyla Protobuf, alan adlarını her mesajda tekrarlayan JSON'dan çok daha küçüktür. Yalnızca değişen değerlerin gönderildiği report by exception ile birleştiğinde Sparkplug, hücresel ve uydu bağlantılarına çok iyi uyar. Tesis Ethernet'indeki birkaç sensör için fark nadiren önem taşır.
JSON'un Kazandığı Yerler
Basitlik ve okunabilirlik
JSON'da mosquitto_sub ve kendi gözlerinizle hata ayıklayabilirsiniz. Web geliştiricileri, veri mühendisleri ve BT ekipleri onu zaten bilir. Node-RED gibi low-code araçlar onu doğal olarak işler.
Esneklik
JSON, topic'leri tesis hiyerarşiniz etrafında, örneğin bir ISA-95 ağacı şeklinde modellemenize izin verir; birçok ekip Unified Namespace'i bu şekilde yapılandırır. Sparkplug'ın sabit namespace'i ise grup, node ve cihazda durur.
Endüstriyel olmayan tüketiciler
Mobil uygulamalar, web dashboard'ları, bulut fonksiyonları ve analitik notebook'ları genellikle JSON ister. Onları Sparkplug ile beslemek, her birinin proto dosyasına ve alias işlemeye ihtiyaç duyması demektir.
İkisini de Bir Test Broker'ında Deneyin
Okunabilirliği herkese açık MQTT test broker'ında kendiniz karşılaştırabilirsiniz. JSON yayınlayın:
mosquitto_pub -h broker.connectmq.com -p 1883 -i json-test-a81c \
-t "connectmq/demo/a81c/line1/cnc1/telemetry" \
-m '{"timestamp": 1792137600123, "spindleSpeed": 1462.3, "spindleRunning": true}'
Ardından Sparkplug birth ve death sertifikaları rehberimizdeki gibi bir Sparkplug simülatörü çalıştırın ve ayrıntılı çıktıyla ikisine de abone olun. JSON temiz bir şekilde yazdırılır; Sparkplug mesajları ise siz onları çözene kadar kısmen binary metin olarak görünür. Herkese açık alan herkes tarafından okunabilir; bu yüzden rastgele ID'ler kullanın ve gerçek veri göndermeyin.
Hibrit Kalıp: Edge'de Sparkplug, Tüketiciler İçin JSON
Birçok tesis sonunda ikisini birden kullanır. Edge node'lar ve SCADA güvenilir, durumdan haberdar taşıma için Sparkplug B konuşur; bir çeviri katmanı ise dashboard'lar, analitik ve BT sistemleri için okunabilir JSON'u bir ISA-95 topic ağacına yayınlar.
Bu çeviri katmanını kendiniz kurabilirsiniz: spBv1.0/# topic'ine abone olan, Protobuf'u çözen, alias'ları çözümleyen ve JSON'u yeniden yayınlayan bir Python servisi. Python ile Sparkplug B çözme eğitimimiz sağlam bir başlangıç noktasıdır.
Alternatif olarak bu işi broker'a bırakın. ConnectMQ Sparkplug B'yi çözer ve ISA-95 topic'lerine yeniden yayınlayabilir; böylece spBv1.0/factory1/DDATA/line1/cnc1, connectmq/factory1/production/line1/cnc1/telemetry olarak görünür. Dashboard'lar, Node-RED akışları ve Telegraf agent'ları okunabilir topic'lere sıradan MQTT client'ları olarak abone olurken, Sparkplug host'larınız orijinal namespace'i kullanmaya devam eder. Portal, topic gezgininde çözülmüş Sparkplug görünümünü de gösterir; böylece mühendisler baytlar yerine metrik adlarını görür.
Karar Kontrol Listesi
- Sparkplug'dan haberdar bir SCADA veya host uygulamanız var mı ya da satın almayı planlıyor musunuz? Evet ise Sparkplug'a yönelin.
- Operatörlerin değerlerin ne zaman bayatladığını bilmesi gerekiyor mu? Sparkplug bunu özel kod olmadan sağlar.
- Bağlantılar ölçülü (kotalı) veya düşük bant genişlikli mi? Alias'lar ve report by exception ile Sparkplug yardımcı olur.
- Ekip çoğunlukla birkaç sensörle çalışan web ve BT geliştiricilerinden mi oluşuyor? JSON sizi daha hızlı harekete geçirir.
- Topic'lerin ISA-95 seviyelerine göre düzenlenmesini mi istiyorsunuz? JSON buna doğal olarak uyar ya da hibrit kalıbı kullanın.
- Veriyi endüstriyel olmayan birçok uygulama mı tüketecek? JSON'u yerel olarak veya çeviri yoluyla sağlayın.
- Edge'de farklı üreticileri bir arada mı kullanıyorsunuz? Sparkplug eşleme işini azaltır.
Her iki taraftaki maddelere de evet dediyseniz, genellikle doğru yaklaşım hibrit olandır.
Her İki Durumda da Broker Aynıdır
Her iki payload da standartlara uygun herhangi bir MQTT broker üzerinde çalışır; dolayısıyla bu karar sizi bir altyapıya bağlamaz. Değişen, ne kadar görünürlük elde ettiğinizdir. Sparkplug ve ISA-95 topic'lerini anlayan barındırılan bir MQTT broker, binary tarafı JSON tarafı kadar erişilebilir kılar. Daha geniş mimari için MQTT, Sparkplug B ve Unified Namespace yazısını ve MQTT ile Endüstriyel IoT rehberini okuyun.
ConnectMQ ile Başlayın
app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun. JSON ve Sparkplug B'yi yan yana yayınlayın; Sparkplug verisi ISA-95 topic'lerine yeniden yayınlanırken her ikisini de ConnectMQ topic gezgininde okunabilir şekilde görün.
Sık Sorulan Sorular
Endüstriyel IoT için Sparkplug B her zaman JSON'dan daha mı iyi?
Hayır. Sparkplug B, SCADA ile birlikte çalışabilirlik ve yerleşik durum farkındalığı için daha iyidir. JSON daha basit ve daha esnektir; küçük projeler veya BT odaklı tüketiciler için çoğu zaman daha iyi bir seçimdir.
Sparkplug, Protobuf yerine JSON kullanabilir mi?
Sparkplug B spesifikasyonu Protobuf kodlamasını tanımlar. Bazı araçlar hata ayıklama veya köprüleme için bir JSON temsili sunar ve ConnectMQ her iki biçimi de çözebilir.
Aynı broker'da Sparkplug B ve JSON'u bir arada kullanabilir miyim?
Evet. Farklı topic'ler kullandıkları için çakışma olmadan bir arada var olurlar. Birçok tesis aynı broker üzerinde Sparkplug'ı spBv1.0 altında, JSON'u ise bir ISA-95 ağacı altında çalıştırır.
MQTT üzerinde JSON, cihaz çevrimiçi durumunu destekler mi?
Kendiliğinden desteklemez. Bunu bir durum topic'inde retained bir last will mesajıyla uygulayabilirsiniz, ancak geleneği kendiniz tanımlamanız ve uygulatmanız gerekir.



