Sparkplug 3.0, Eclipse Foundation'ın Sparkplug Working Group çatısı altında yayınlanan ilk Sparkplug spesifikasyonu sürümüdür ve büyük ölçüde 2.2'nin yoruma açık bıraktığı davranışları netleştirir. Bu karşılaştırmada 2.2 ile 3.0 arasında tam olarak neyin değiştiğini, karışık bir filoda hangi değişikliklerin birlikte çalışabilirliği bozabileceğini ve edge node'lar ile host uygulamalarının geçişini sürprizsiz nasıl planlayacağınızı öğreneceksiniz.
Kısaca
Sparkplug 3.0 protokolü yeniden icat etmedi. Topic namespace hâlâ spBv1.0, Protobuf payload hâlâ Sparkplug B şeması ve birth ile death sertifikaları hâlâ aynı şekilde çalışıyor. Değişen şey kesinliktir. 2.2 sürümü davranışları farklı üreticilerin farklı okuduğu düz bir anlatımla tarif ediyordu. 3.0 sürümü ise belgeyi numaralandırılmış normatif ifadelerden oluşan resmi bir spesifikasyon olarak yeniden yazdı ve implementasyonları bu ifadelere karşı test eden bir Technology Compatibility Kit (TCK) ile destekledi.
Neredeyse herkes için ağ üzerinde görünür olan tek değişiklik, host uygulamasının STATE mesajıdır. Diğer değişikliklerin çoğu uç durumları etkiler: yeniden bağlanmalar, gecikmiş will'ler, oturum yönetimi ve veri tipi kodlaması.
Bir Bakışta Sparkplug 3.0 ve 2.2
| Alan | Sparkplug 2.2 | Sparkplug 3.0 |
|---|---|---|
| Belge üslubu | Açıklayıcı anlatım | Normatif, test edilebilir ifadeler |
| Uygunluk | Resmi test paketi yok | Uyumluluk profilleriyle TCK |
| Topic namespace | spBv1.0/... |
Değişmedi |
| Payload şeması | Sparkplug B Protobuf | Değişmedi, kodlama kuralları netleştirildi |
| STATE topic'i | STATE/{host_id} |
spBv1.0/STATE/{host_id} |
| STATE payload'ı | ONLINE / OFFLINE dizesi |
JSON {"online": true, "timestamp": ...} |
| bdSeq | Gevşek şekilde tarif edilmiş | NBIRTH ile NDEATH arasında eşleşmeli, artırma kuralları var |
| NDEATH will QoS | Tutarlı şekilde belirtilmemiş | QoS 1, retained değil |
| MQTT oturumu | Örtük | Edge node'lar ve host'lar clean session kullanır |
| Terminoloji | SCADA/IIoT host, primary application | Host Application, Primary Host Application |
| Dizi veri tipleri | Listelenmiş, kodlama belirsiz | Kodlama tanımlı |
En Önemli Değişiklikler
Yeni STATE topic'i ve payload'ı
2.2'de bir primary host, STATE/{host_id} üzerine retained ONLINE dizesini yayınlıyor ve will olarak OFFLINE kaydediyordu. Bu topic spBv1.0 namespace'inin dışında yer alıyordu, bu da yetkilendirmeyi karmaşıklaştırıyordu; düz bir dize ise eski bir mesajı yenisinden ayırt etmenin hiçbir yolunu sunmuyordu.
3.0'da topic spBv1.0/STATE/{host_id} adresine taşınır ve payload JSON olur:
{ "online": true, "timestamp": 1792137600000 }
Host bunu bağlandıktan sonra QoS 1 ile retained olarak yayınlar ve birth'te kullandığı aynı zaman damgasıyla "online": false içeren bir will kaydeder. Edge node'lar zaman damgalarını karşılaştırır ve daha önce gördüklerinden eski bir STATE mesajını yok sayar. Bu, önceki bir host oturumundan gelen gecikmiş bir OFFLINE will'inin, host çoktan geri gelmiş olsa bile tüm edge node'ların bağlantısını kesmesine yol açabilen bir yarış durumunu ortadan kaldırır. Tüm akış Sparkplug primary host uygulaması yazımızda ele alınıyor.
Bu, geriye dönük uyumluluğu bozan bir değişikliktir. STATE/scada1 topic'ini izleyen bir 2.2 edge node'u bir 3.0 host'unu asla görmez; spBv1.0/STATE/scada1 bekleyen bir 3.0 node'u ise bir 2.2 host'unun arkasında sonsuza dek bekler. Bazı ürünler geçiş sürecinde her iki biçimi de destekler; herhangi bir şeyi yükseltmeden önce kendi ürününüzü kontrol edin.
bdSeq kuralları
bdSeq metriği, bir NBIRTH'ü aynı MQTT oturumu için kaydedilen NDEATH'e bağlar. 3.0 sürümü kuralları açık hâle getirir: NDEATH will'i bir bdSeq içermeli, ardından gelen NBIRTH aynı değeri taşımalı ve değer her yeni bağlantıda değişmelidir. Host'lar bu eşleşmeyi, daha eski bir oturuma ait death sertifikasını göz ardı etmek için kullanır. Kendi edge node'unuzu 2.2'ye göre yazdıysanız, doğrulamanız gereken ilk şey budur. Sparkplug birth ve death sertifikaları rehberimiz çalışan bir implementasyon gösteriyor.
Oturum ve QoS davranışı
3.0 sürümü, edge node'lar ve host uygulamaları için clean session zorunlu kılar (MQTT 3.1.1'de clean session true, MQTT 5'te ise sıfır session expiry ile clean start). Aksi takdirde eski bir oturumdan kuyrukta bekleyen mesajlar yeni bir birth'ten sonra gelebilir ve durum modelini karıştırabilir. NDEATH will'i QoS 1 kullanır ve retained değildir; birth ve veri mesajları da retained değildir. Yalnızca host STATE mesajı retained'dır.
Daha net veri tipleri ve alias'lar
Birth mesajlarında her metrik için veri tipi bulunmalıdır. Alias'lar her edge node için benzersiz olmalıdır. Int32Array veya BooleanArray gibi dizi tiplerinin tanımlı bir bayt kodlaması vardır; böylece dizi desteği iddia eden üreticiler gerçekten dizi alışverişi yapabilir. Sparkplug B veri tipleri referansı her kodu listeliyor.
Uyumluluk profilleri
TCK; Edge Node, Host Application, MQTT Server ve isteğe bağlı Sparkplug Aware MQTT Server için profiller tanımlar. QoS 0 ve 1, retained mesajlar ve will destekleyen her MQTT 3.1.1 broker Sparkplug trafiği taşıyabilir. "Aware" profili, spesifikasyonda tanımlanan isteğe bağlı broker tarafı özellikleri ekler. Bir üretici Sparkplug 3.0 uyumlu olduğunu söylediğinde, hangi profil için olduğunu ve TCK'yi geçip geçmediğini sorun.
Sparkplug 3.0 Broker'ınız İçin Ne Anlama Geliyor?
Payload yönlendirme açısından opak olduğu için broker'ın işi neredeyse hiç değişmez. Güvenilir last will yönetimine, STATE için retained mesajlara, QoS 1'e ve her node ile host için yeterli bağlantı kapasitesine ihtiyaç duyar. ConnectMQ gibi yönetilen bir MQTT broker, aynı endpoint'lerde MQTT 3.1.1 ve 5.0'ı destekler; böylece geçiş yaparken 2.2 ve 3.0 node'ları yan yana bağlanabilir. ConnectMQ ayrıca Sparkplug B payload'larını çözer ve portaldaki topic gezgininde gösterir; bu da geçiş sırasında birth mesajlarının veri tiplerini taşıdığını, bdSeq değerlerinin eşleştiğini ve yeni STATE topic'inin beklenen JSON ile retained olduğunu kontrol etmeyi kolaylaştırır.
Üretime dokunmadan önce, herkese açık MQTT test broker'ında rastgele bir grup ID'siyle prova yapabilirsiniz. Örneğin bir 3.0 STATE mesajı yayınlayıp okuyun:
mosquitto_pub -h broker.connectmq.com -p 1883 -i host-test-4e1b -r -q 1 \
-t "spBv1.0/STATE/demo-host-4e1b" -m '{"online": true, "timestamp": 1792137600000}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i host-watch-4e1b -t "spBv1.0/STATE/demo-host-4e1b" -v
Herkese açık alan paylaşımlı olduğu için, işiniz bittiğinde aynı topic'e boş bir retained payload yayınlayarak retained mesajı temizleyin.
2.2'den 3.0'a Geçiş Kontrol Listesi
- Her edge node'un ve host'un envanterini çıkarın ve her birinin hangi Sparkplug sürümünü desteklediğini kaydedin.
- STATE topic stratejisine karar verin: host'ları ve node'ları birlikte yükseltin ya da geçiş sürecinde her iki biçimi de destekleyen ürünler kullanın.
- Her edge node'un bağlanmadan önce bdSeq içeren bir NDEATH will'i kaydettiğini ve bu bdSeq'i NBIRTH'te tekrarladığını doğrulayın.
- Node'larda ve host'larda clean session ayarlarını teyit edin.
- Birth mesajlarının her metrik için bir veri tipi içerdiğini ve alias'ların node başına benzersiz olduğunu kontrol edin.
- Kullanıyorsanız, dizi ve template metriklerini üreticiler arasında test edin.
- Yeni host'u bir test grubunda paralel çalıştırın; çözülmüş birth ve STATE mesajlarını bir topic gezgininde izleyin.
- Her seferinde bir grubu geçirin ve host için bir geri dönüş planı hazır tutun.
Yükseltmeli misiniz?
Yeni projelerde 3.0 ile başlayın. Güncel Eclipse Tahu sürümleri üzerine kurulu araçlar onu izler ve TCK, üreticileri spesifikasyona bağlı tutmanın bir yolunu sunar. Sorunsuz çalışan mevcut 2.2 tesisleri için, STATE değişikliği koordinasyon gerektirdiğinden, host uygulamalarını değiştirdiğinizde veya yenilerini eklediğinizde yükseltin. bdSeq'i zaten doğru işleyen edge node'lar çoğu zaman yalnızca bir firmware veya yapılandırma güncellemesine ihtiyaç duyar. Daha geniş mimari bağlam için MQTT ile Endüstriyel IoT rehberini okuyun. Resmi metin Eclipse Sparkplug sitesinde yer alıyor.
ConnectMQ ile Başlayın
app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun. Sparkplug 3.0 edge node'larınızı ve host'unuzu 8883 portu üzerinden TLS ile bağlayın ve üretimi taşımadan önce birth, death ve STATE mesajlarını ConnectMQ portalında çözülmüş olarak doğrulayın.
Sık Sorulan Sorular
Sparkplug 3.0, 2.2 ile geriye dönük uyumlu mu?
Payload ve spBv1.0 topic namespace uyumludur. Host STATE topic'i ve payload'ı değiştiği için, bir uyumluluk modu olmadan 2.2 node'ları ile 3.0 host'ları (veya tersi) birbirlerinin host durumunu tanımaz.
Sparkplug 3.0, MQTT 5 gerektirir mi?
Hayır. Sparkplug MQTT 3.1.1 üzerinde çalışır ve MQTT 5 broker'ları eşdeğer oturum ayarlarıyla onu taşıyabilir. Her iki sürümü de destekleyen bir broker kademeli geçiş yapmanızı sağlar.
Sparkplug 3.0'da topic hâlâ spBv1.0 mı?
Evet. Namespace, değişmeyen Sparkplug B payload formatını tanımlar; bu yüzden topic'ler spBv1.0/... olarak kalır. Yalnızca STATE bu namespace'in içine taşındı.
Sparkplug TCK nedir?
Technology Compatibility Kit, Eclipse Sparkplug projesinin, implementasyonları 3.0 spesifikasyonundaki normatif ifadelere karşı edge node veya host uygulaması gibi profil bazında kontrol eden bir test paketidir.
