Sparkplug B Nedir? Endüstriyel IoT için MQTT

Düz MQTT bilinçli olarak tarafsızdır: herhangi bir topic, herhangi bir payload. Bu esneklik, bir üreticinin SCADA sisteminin başka bir üreticinin yaptığı PLC ağ geçitlerinden gelen veriyi anlaması gereken fabrikalarda bir sorundur. Sparkplug B bu boşluğu doldurur. Eclipse Foundation’ın Sparkplug Working Group’u tarafından sürdürülen açık bir spesifikasyondur ve MQTT’nin endüstriyel IoT için nasıl kullanılacağını tanımlar: sabit bir topic yapısı, ikili (binary) bir payload formatı ve her cihazın çevrimiçi olup olmadığını bilmek için kurallar. Spesifikasyonun 3.0 sürümü aynı zamanda uluslararası standart ISO/IEC 20237 olarak yayımlanmıştır.

Alttaki protokolde yeniyseniz MQTT nedir yazısıyla başlayın.

Bir Sparkplug sisteminin bileşenleri

• MQTT sunucusu — uyumlu herhangi bir MQTT 3.1.1 veya 5 broker’ı.
• Edge Node — MQTT’ye bağlanan bir ağ geçidi veya cihaz, örneğin bir PLC ağ geçidi. Hem kendi verisini hem de arkasındaki cihazların verisini publish eder.
• Device — bir Edge Node’a bağlı sensör, PLC veya makine. Device’lar MQTT’ye kendileri bağlanmaz; onların adına Edge Node konuşur.
• Host Application — veriye abone olan ve komut gönderen SCADA, MES veya historian gibi bir tüketici. Bunlardan biri Primary Host Application olarak belirlenebilir.

Sparkplug topic ad alanı

Her Sparkplug B topic’i aynı yapıyı izler:

spBv1.0/<group_id>/<message_type>/<edge_node_id>[/<device_id>]

# Examples
spBv1.0/Plant1/NBIRTH/Gateway-07
spBv1.0/Plant1/DDATA/Gateway-07/Press-3
spBv1.0/Plant1/DCMD/Gateway-07/Press-3

• spBv1.0 — payload tanımının ad alanı ve sürümü.
• group_id — Edge Node’ların bir lokasyon veya üretim hattı gibi mantıksal bir gruplaması.
• message_type — aşağıdaki mesaj türlerinden biri.
• edge_node_id ve isteğe bağlı device_id — publisher’ı tanımlar.

Yapı sabit olduğu için tüketiciler spBv1.0/Plant1/+/# veya spBv1.0/+/DDATA/# gibi wildcard’larla abone olabilir. Neyle eşleştiklerini kontrol etmek için bunları topic eşleştiriciye yapıştırın veya kurallar için MQTT topic’leri ve joker karakterler yazısını okuyun.

Mesaj türleri

Sparkplug report by exception (yalnızca değişiklikte raporlama) ilkesine dayanır: BIRTH mesajı her metriği tanımladıktan sonra DATA mesajları yalnızca değişen değerleri taşır. Geç katılan veya takibi kaybeden bir tüketici, Node Control/Rebirth metriğini true yapan bir NCMD göndererek yeni bir BIRTH isteyebilir.

Oturum durumu: NDEATH, bdSeq ve seq

Sparkplug’ın en güçlü özelliği, bir host’un verinin güncel olup olmadığını her zaman bilmesidir. Bu, MQTT’nin Last Will and Testament özelliği üzerine kuruludur:

1. Edge Node bağlandığında will olarak bir NDEATH mesajı kaydeder. Will mesajı bir bdSeq (birth/death sequence) metriği taşır.
2. Bağlandıktan hemen sonra aynı bdSeq ile NBIRTH publish eder, ardından her device için bir DBIRTH gönderir.
3. Node bağlantıdan düşerse broker NDEATH will mesajını publish eder. Host, bu mesajın bdSeq’ini son NBIRTH ile karşılaştırır ve o node’un ve device’larının tüm metriklerini eskimiş (stale) olarak işaretler.

bdSeq her yeni MQTT oturumunda artar (255’ten sonra başa döner); böylece eski bir bağlantıdan geç gelen bir NDEATH, mevcut bağlantının ölümü sanılmaz.

Bundan ayrı olarak, bir Edge Node’un publish ettiği her mesaj 0 ile 255 arasında bir seq numarası taşır. NBIRTH 0’dan başlar ve sonraki her mesaj bu numarayı artırır; 255’ten sonra 0’a döner. Host bir boşluk görürse bir mesajın kaybolduğunu anlar ve rebirth isteyebilir.

Primary Host Application ve STATE

Veri ancak biri onu kaydediyorsa işe yarar. Bir Primary Host Application retained bir STATE mesajı publish eder (ve will olarak çevrimdışı bir STATE kaydeder). Bir primary host ile yapılandırılmış Edge Node’lar, birth mesajlarını publish etmeden önce onun çevrimiçi olmasını bekler; host çevrimdışı olursa bağlantıyı keserler ve o geri dönene kadar veriyi yerel olarak saklayabilir veya başka bir MQTT sunucusuna geçebilirler. Sparkplug 3.0’da topic, küçük bir JSON payload ile spBv1.0/STATE/<host_id> şeklindedir:

{ "online": true, "timestamp": 1760140800000 }

Eski 2.x kurulumları, düz bir ONLINE/OFFLINE dizesiyle STATE/<host_id> topic’ini kullanıyordu.

Protobuf payload’ları

Sparkplug B payload’ları Google Protocol Buffers ile kodlanır. Bir payload’un bir zaman damgası, bir seq değeri ve bir metrik listesi vardır. Her metriğin bir adı, bir veri türü, bir değeri, isteğe bağlı bir zaman damgası ve isteğe bağlı sayısal bir alias’ı bulunur. Alias’lar BIRTH içinde tanımlanır; DATA mesajları daha sonra tam ad yerine alias gönderebilir, bu da mesajları kompakt tutar.

timestamp: 1760140800123
seq: 17
metrics {
  alias: 4            # "Press-3/Hydraulic/Pressure" in DBIRTH
  timestamp: 1760140800120
  datatype: Float
  float_value: 182.4
}

İkili kodlama payload’ları küçük tutar, bu da kısıtlı bağlantılarda önemlidir; paket boyutlarını MQTT paket boyutu hesaplayıcı ile tahmin edebilirsiniz. Dezavantajı, genel bir client’ın ham baytlar göstermesidir. Yine de birth ve death mesajlarının doğru topic’lere ulaştığını doğrulamak için genel bir client kullanabilirsiniz:

Bir Sparkplug ad alanını online client’ta izleyin

Sparkplug’ın kullandığı MQTT ayarları

• NBIRTH/DBIRTH, DATA ve CMD mesajları için QoS 0; NDEATH will mesajı ve STATE için QoS 1.
• Retained olan STATE dışında her şey için retain false.
• Edge Node’lar için clean session (3.1.1’de Clean Session true, MQTT 5’te session expiry 0 ile Clean Start true). Sparkplug durumu birth ve rebirth’lerle kendisi yönettiğinden kalıcı oturumlara dayanmaz.

Eclipse Tahu ile başlamak

Eclipse Tahu, Protobuf tanımı ve Java, C, Python ve JavaScript için client kütüphaneleriyle Sparkplug’ın referans uygulamasıdır. Kodlamayı, alias’ları ve sıra numaralarını sizin yerinize halleder; böylece metriklerinize odaklanabilirsiniz. Sparkplug Working Group, uygulamaların spesifikasyona uyup uymadığını test etmek için bir Technology Compatibility Kit (TCK) de yayımlar.

Güvenlik konuları

Sparkplug komutları gerçek makinelerde setpoint yazabildiği için NCMD ve DCMD topic’lerine erişimi güvenlik açısından kritik kabul edin. TLS, Edge Node başına benzersiz kimlik bilgileri ve her node’un yalnızca kendi edge_node_id’si altında publish etmesine izin veren ACL’ler kullanın. Ayrıntılar MQTT güvenliği en iyi uygulamalar yazımızda.

Sıkça sorulan sorular