Sparkplug B क्या है? इंडस्ट्रियल IoT के लिए MQTT, आसान भाषा में

24 मार्च 2026 पढ़ने में 12 मिनट

MQTT, IoT के लिए सबसे प्रचलित मैसेजिंग प्रोटोकॉल बन चुका है। यह हल्का है, सीमित हार्डवेयर पर चलता है, और साफ़-सुथरा publish/subscribe मॉडल इस्तेमाल करता है। लेकिन MQTT जानबूझकर न्यूनतम रखा गया है — यह सिर्फ़ इतना तय करता है कि client और broker के बीच bytes कैसे चलें, इससे ज़्यादा कुछ नहीं। आपकी topic strings कैसी दिखें, payloads किस फ़ॉर्मेट में हों, या कैसे पता चले कि कोई डिवाइस चालू है या बंद — इस पर यह कुछ नहीं कहता।

Consumer IoT के लिए यह लचीलापन ठीक है। चार अलग-अलग vendors के 200 PLC वाले मैन्युफैक्चरिंग प्लांट के लिए यह एक समस्या है। अगर हर integrator अपना topic स्ट्रक्चर, payload फ़ॉर्मेट और state management तरीका ख़ुद बनाए, तो आपके पास दर्जनों ऐसे MQTT implementations होंगे जो custom middleware के बिना आपस में बात नहीं कर सकते।

Sparkplug B वह specification है जो इसे हल करता है। यह standard MQTT v3.1.1 (या v5) के ऊपर बैठता है और वे तीन चीज़ें जोड़ता है जिनकी इंडस्ट्रियल IoT को असल में ज़रूरत है: एक तय topic namespace, एक मानकीकृत binary payload encoding, और birth व death certificates के साथ पूरा डिवाइस lifecycle मॉडल। नतीजा: एक interoperable, self-describing डेटा लेयर, जिसे Sparkplug B के अनुरूप कोई भी application, publish करने वाले डिवाइसों की पहले से जानकारी के बिना, इस्तेमाल कर सकता है।

Sparkplug B कौन-सी समस्या हल करता है

Sparkplug B क्यों बना, यह समझने के लिए देखिए कि फ़ैक्टरी में साधारण MQTT डिप्लॉय करने पर क्या होता है:

Topic का कोई convention नहीं। एक integrator factory/line1/plc3/temperature इस्तेमाल करता है। दूसरा site-cleveland/area-mixing/tag-TT101। तीसरा data/json/12345। डेटा इस्तेमाल करने वाला application हर एक के लिए custom कोड लिखे बिना तीनों को parse नहीं कर सकता।
Payload का कोई स्टैंडर्ड नहीं। कुछ डिवाइस JSON publish करते हैं। कुछ CSV। कुछ raw binary वैल्यू। JSON publish करने वालों में भी key names, nesting और data types बहुत अलग होते हैं। Consumer को हर publisher का सटीक schema पहले से जानना पड़ता है।
डिवाइस lifecycle नहीं। MQTT का Last Will and Testament (LWT) फ़ीचर बता सकता है कि client डिस्कनेक्ट हुआ, लेकिन इसका कोई स्टैंडर्ड नहीं कि will message में क्या हो, साफ़ shutdown और crash में फ़र्क़ कैसे करें, या ऑनलाइन आने पर डिवाइस अपने सभी metrics की घोषणा कैसे करे।
State की कोई जानकारी नहीं। अगर कोई नया SCADA application महीनों से चल रहे broker को subscribe करे, तो उसे अगले publish तक कुछ नहीं मिलता। उसके पास सभी डिवाइसों की मौजूदा state माँगने का कोई तरीका नहीं। जब तक संयोग से डेटा न आए, वह अँधेरे में रहता है।

Sparkplug B इनमें से हर समस्या को एक सख़्त, साफ़ परिभाषित specification से हल करता है, जिसे कोई भी vendor लागू कर सकता है।

Sparkplug B topic namespace

हर Sparkplug B मैसेज ऐसे topic पर publish होता है जो ठीक इसी स्ट्रक्चर का पालन करता है:

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

spBv1.0 — Sparkplug B वर्ज़न बताने वाला तय prefix। Specification के अनुरूप हर मैसेज यहीं से शुरू होता है।
group_id — एक तार्किक समूह, आमतौर पर प्लांट, साइट या प्रोडक्शन एरिया (जैसे Cleveland_Plant)।
message_type — आठ तय types में से एक: NBIRTH, NDEATH, DBIRTH, DDEATH, NDATA, DDATA, NCMD, DCMD.
edge_node_id — एज gateway या नेटवर्क के किनारे वाले डिवाइस की पहचान (जैसे Line1_Gateway)।
device_id — (वैकल्पिक) एज नोड के अंतर्गत कोई ख़ास डिवाइस (जैसे Saw_04)। नोड-स्तर के मैसेज में यह नहीं होता।

एक असली उदाहरण: spBv1.0/Cleveland_Plant/DDATA/Line1_Gateway/Saw_04 — यह Cleveland_Plant group में एज नोड Line1_Gateway पर डिवाइस Saw_04 का डेटा मैसेज है।

क्योंकि topic स्ट्रक्चर तय है, Sparkplug को समझने वाला कोई भी application बिना कॉन्फ़िगरेशन के किसी भी मैसेज से group, node और डिवाइस की पहचान निकाल सकता है। आप spBv1.0/# को subscribe करके तुरंत जान सकते हैं कि हर metric कहाँ से आ रहा है।

आठ message types

Sparkplug B ठीक आठ message types तय करता है। डिवाइस lifecycle में हर एक का ख़ास काम है:

Message type	दिशा	उद्देश्य
`NBIRTH`	एज नोड → broker	नोड birth certificate। एज नोड के जुड़ने पर publish होता है। इसमें नोड-स्तर के सभी metrics की पूरी सूची होती है — मौजूदा वैल्यू, data types और metadata के साथ।
`NDEATH`	Broker (LWT)	नोड death certificate। MQTT Last Will मैसेज के रूप में रजिस्टर होता है। एज नोड के अचानक डिस्कनेक्ट होने पर broker इसे publish करता है।
`DBIRTH`	एज नोड → broker	डिवाइस birth certificate। एज नोड के ज़रिए जुड़े हर डिवाइस के लिए publish होता है। इसमें डिवाइस-स्तर के सभी metrics होते हैं।
`DDEATH`	एज नोड → broker	डिवाइस death certificate। जब कोई downstream डिवाइस डिस्कनेक्ट या अनुपलब्ध हो जाए, तो एज नोड इसे publish करता है।
`NDATA`	एज नोड → broker	नोड डेटा। नोड-स्तर पर बदली हुई metric वैल्यू publish करता है। सिर्फ़ वही metrics शामिल होते हैं जो पिछले publish के बाद बदले हैं (report by exception)।
`DDATA`	एज नोड → broker	डिवाइस डेटा। किसी ख़ास डिवाइस की बदली हुई metric वैल्यू publish करता है। चलते सिस्टम में यह सबसे ज़्यादा आने वाला message type है।
`NCMD`	Application → एज नोड	नोड command। Host application (SCADA, MES) इसे ख़ुद एज नोड में वैल्यू लिखने के लिए भेजता है।
`DCMD`	Application → एज नोड	डिवाइस command। Host application इसे एज नोड के ज़रिए किसी ख़ास डिवाइस में वैल्यू लिखने के लिए भेजता है। Setpoint लिखने, recipe download और control actions के लिए इस्तेमाल होता है।

नामकरण का नियम एक जैसा है: N = Node, D = Device। BIRTH = ऑनलाइन आया, DEATH = ऑफ़लाइन हुआ, DATA = metric वैल्यू, CMD = write command।

Birth और death certificates

Birth/death व्यवस्था Sparkplug B का सबसे अहम नवाचार है। यह "late joiner" (देर से जुड़ने वाले) की उस समस्या को हल करती है जो साधारण MQTT डिप्लॉयमेंट को परेशान करती है।

Birth certificates कैसे काम करते हैं

जब एज नोड broker से जुड़ता है, तो (अपना NDEATH, MQTT Last Will के रूप में रजिस्टर करने के बाद) सबसे पहले एक NBIRTH मैसेज publish करता है। इस मैसेज में नोड का हर metric होता है: नाम, data type, मौजूदा वैल्यू, और वैकल्पिक metadata जैसे engineering units या description। इसके तुरंत बाद वह अपने हर डिवाइस के लिए एक DBIRTH publish करता है।

असर ज़बरदस्त है: spBv1.0/+/NBIRTH/# और spBv1.0/+/DBIRTH/# को subscribe करने वाले किसी भी application को नेटवर्क के हर डिवाइस का पूरा metric catalog और मौजूदा state तुरंत मिल जाती है। न कॉन्फ़िगरेशन फ़ाइलें, न tag डेटाबेस, न हाथ से mapping। नेटवर्क ख़ुद अपना परिचय देता है।

Death certificates कैसे काम करते हैं

एज नोड के जुड़ते समय NDEATH मैसेज MQTT Last Will के रूप में रजिस्टर होता है। अगर TCP कनेक्शन टूटे (पावर जाना, नेटवर्क फ़ेल्योर, crash), तो broker बंद हुए नोड की ओर से अपने-आप NDEATH publish करता है। NDEATH में एक bdSeq (birth/death sequence number) होता है जो संबंधित NBIRTH से मेल खाता है, ताकि consumers ठीक-ठीक जान सकें कि कौन-सा session ख़त्म हुआ।

डिवाइस-स्तर की death के लिए एज नोड ख़ुद DDEATH publish करता है, जब उसे पता चलता है कि कोई downstream डिवाइस ऑफ़लाइन हो गया है (जैसे कोई PLC जो polls का जवाब देना बंद कर दे)। यह फ़र्क़ मायने रखता है: एज नोड अभी भी चालू है और रिपोर्ट कर रहा है, लेकिन उसके अंतर्गत कोई ख़ास डिवाइस फ़ेल हो गया है।

यह क्यों मायने रखता है

साधारण MQTT सिस्टम में अगर आप किसी topic को subscribe करें और कुछ न आए, तो आपको पता नहीं चलता कि डिवाइस ऑफ़लाइन है, topic ग़लत है, या डिवाइस ने अभी तक publish ही नहीं किया। Sparkplug B में आपको हमेशा पता रहता है। हर डिवाइस या तो BIRTH state में है (ऑनलाइन, ये रहे उसके metrics) या DEATH state में (ऑफ़लाइन, यह रहा उसके बंद होने का समय)। कोई अस्पष्टता नहीं।

Payload encoding: Protocol Buffers

Sparkplug B payloads Google Protocol Buffers (protobuf) से encode होते हैं, जो एक compact binary serialization फ़ॉर्मेट है। JSON की जगह यह सोच-समझकर चुना गया है, और इसके कारण व्यावहारिक हैं:

आकार। Protobuf से encode किया गया payload आमतौर पर बराबर के JSON से 50–80% छोटा होता है। हर सेकंड 200 tags publish करने वाले PLC के लिए सीमित नेटवर्क पर यह फ़र्क़ काफ़ी बड़ा है।
Typed metrics। Sparkplug B payload के हर metric का एक स्पष्ट data type होता है: Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64, Float, Double, Boolean, String, DateTime, Bytes, और भी। Consumer को अंदाज़ा नहीं लगाना पड़ता कि "temperature": 72 integer है या float — type payload में ही encode होता है।
टाइमस्टैम्प। हर metric के साथ मिलीसेकंड-सटीक UTC टाइमस्टैम्प होता है। मैन्युफैक्चरिंग के लिए यह बेहद ज़रूरी है: आपको जानना होता है कि PLC ने वैल्यू कब sample की, न कि broker को वह कब मिली। साधारण MQTT पर JSON में टाइमस्टैम्प बाद में सोची गई चीज़ होते हैं (अगर हों भी)।
Schema evolution। Protobuf ग़ायब या नए fields को आराम से संभाल लेता है। अगर firmware अपडेट में कोई डिवाइस नए metrics जोड़ता है, तो मौजूदा consumers काम करते रहते हैं — वे बस अनजान fields को अनदेखा कर देते हैं।

Protobuf schema (.proto फ़ाइल) Eclipse Sparkplug specification में सार्वजनिक रूप से उपलब्ध है। Protobuf सपोर्ट वाली कोई भी भाषा — Python, Java, C, Go, JavaScript — Sparkplug B payloads decode कर सकती है।

Unified namespace की अवधारणा

Sparkplug B उस चीज़ की तकनीकी नींव है जिसे इंडस्ट्री Unified Namespace (UNS) कहती है — यह विचार कि पूरे प्लांट (या enterprise) का सारा operational डेटा एक ही MQTT broker पर publish हो, और कोई भी अधिकृत consumer किसी भी डेटा को subscribe कर सके।

यह पारंपरिक मैन्युफैक्चरिंग IT आर्किटेक्चर से एक बुनियादी बदलाव है, जहाँ डेटा point-to-point integrations से होकर चलता है:

पारंपरिक: PLC → OPC server → SCADA → historian → MES → ERP। हर कड़ी एक custom integration है, जिसे बनाना, संभालना और debug करना पड़ता है। नया consumer (जैसे कोई AI मॉडल) जोड़ने का मतलब है एक और integration बनाना।
Unified Namespace: PLC → MQTT broker (Sparkplug B के ज़रिए)। SCADA, historian, MES, ERP, AI और डैशबोर्ड सभी एक ही broker को subscribe करते हैं। नया consumer जोड़ना बस एक subscription है — integration का कोई काम नहीं।

Sparkplug B अपनी self-describing प्रकृति की वजह से इसे संभव बनाता है। Broker से जुड़ने वाले नए application को हर ऑनलाइन डिवाइस के BIRTH मैसेज मिलते हैं, वह सभी उपलब्ध metrics और उनके types जान लेता है, और तुरंत डेटा प्रोसेस करना शुरू कर देता है। न tag export, न CSV import, न हाथ से कॉन्फ़िगरेशन।

UNS "data silo" की समस्या भी ख़त्म करता है। जब आपका MES, आपका OEE calculator और आपका क्वालिटी सिस्टम सब एक ही डेटा stream से पढ़ते हैं, तो सच का एक ही वर्ज़न होता है। ऑपरेटर HMI पर जो मशीन state देखता है, MES शेड्यूलिंग के फ़ैसलों के लिए वही state इस्तेमाल करता है।

Sparkplug B बनाम साधारण MQTT

क्षमता	साधारण MQTT	Sparkplug B
Topic स्ट्रक्चर	मनमर्ज़ी का — हर vendor अपना बनाता है	तय: `spBv1.0/group/type/node/device`
Payload फ़ॉर्मेट	तय नहीं (JSON, CSV, binary, XML)	Typed metrics के साथ Protocol Buffers
डिवाइस lifecycle	सिर्फ़ बुनियादी Last Will	Sequence numbers के साथ पूरे birth/death certificates
State की जानकारी	नहीं — देर से जुड़ने वालों को अगले publish तक कुछ नहीं मिलता	जुड़ते ही BIRTH मैसेज पूरी state देते हैं
Metric metadata	परिभाषित नहीं	Data type, टाइमस्टैम्प, engineering units, description
Interoperability	सिर्फ़ एक जैसे implementations के बीच	Specification के अनुरूप कोई भी client, अनुरूप किसी भी publisher का डेटा इस्तेमाल कर सकता है
Bandwidth की बचत	Implementation पर निर्भर	Report by exception + protobuf compression

साफ़ कर दें: Sparkplug B, MQTT की जगह नहीं लेता। यह उसके ऊपर की एक लेयर है। हर Sparkplug B मैसेज एक वैध MQTT मैसेज है। आप किसी standard MQTT broker (Mosquitto, HiveMQ, EMQX) को बिना बदलाव के इस्तेमाल कर सकते हैं — हालाँकि कुछ brokers topic aliasing और metric indexing जैसे Sparkplug-aware फ़ीचर भी देते हैं।

Sparkplug B कौन इस्तेमाल करता है

Sparkplug B specification मूल रूप से Cirrus Link Solutions ने बनाया था, और अब Eclipse Foundation इसे Eclipse Sparkplug project के तहत एक open standard के रूप में संभालता है। इसे इंडस्ट्री का व्यापक समर्थन है:

Inductive Automation (Ignition) — Ignition के MQTT Transmission और MQTT Engine modules मैन्युफैक्चरिंग में सबसे ज़्यादा डिप्लॉय किया गया Sparkplug B implementation हैं। ये एज नोड की भूमिका (PLC tags पढ़कर उन्हें Sparkplug B के रूप में publish करना) और host application की भूमिका (subscribe करके Ignition tags भरना) दोनों निभाते हैं।
Cirrus Link — Ignition के लिए MQTT modules और standalone Sparkplug B एज gateways देता है।
AWS IoT Core — Amazon ने native Sparkplug B सपोर्ट जोड़ा, जिससे AWS बिना custom parsing के Sparkplug B payloads decode करके metrics को सीधे IoT rules, Lambda functions और analytics services तक भेज सकता है।
HiveMQ — Enterprise MQTT broker, जिसका Sparkplug-aware extension broker स्तर पर metric discovery और state management देता है।
EMQX — Open-source MQTT broker, जिसमें rule engine integration के लिए बिल्ट-इन Sparkplug B codec सपोर्ट है।
Opto 22, Wago, Beckhoff, Siemens — PLC और एज हार्डवेयर vendors तेज़ी से native Sparkplug B publish क्षमता दे रहे हैं, जिससे अलग gateway की ज़रूरत नहीं रहती।

यह specification खुला और royalty-free है। कोई भी इसे लागू कर सकता है। Protobuf definition फ़ाइलें, specification दस्तावेज़ और reference implementations, सब उपलब्ध हैं: Eclipse Sparkplug project पेज (अंग्रेज़ी में)।

Report by exception

Sparkplug B डेटा मैसेज के लिए report by exception (RBE) मॉडल इस्तेमाल करता है। शुरुआती BIRTH (जिसमें सभी metrics मौजूदा वैल्यू के साथ होते हैं) के बाद, आगे के DDATA और NDATA मैसेज में सिर्फ़ वे metrics होते हैं जिनकी वैल्यू पिछले publish के बाद बदली है।

Bandwidth बचाने के लिए यह बेहद ज़रूरी है। कोई PLC 500 tags दे सकता है, लेकिन किसी एक scan cycle में शायद 10–20 ही बदलें। Sparkplug B सिर्फ़ वे 10–20 बदली हुई वैल्यू भेजता है, सभी 500 नहीं। डेटा इस्तेमाल करने वाला application आख़िरी ज्ञात वैल्यू का एक लोकल cache रखता है (जो BIRTH मैसेज से भरा जाता है) और आने वाले DDATA अपडेट उसी cache में मिलाता है।

अगर एज नोड या डेटा इस्तेमाल करने वाले application का sync टूट जाए (जैसे network partition के बाद), तो Sparkplug B spec एक rebirth व्यवस्था तय करता है: host application एक NCMD भेजकर एज नोड से अपना NBIRTH और सभी DBIRTH दोबारा publish करने को कहता है। इससे cache reset होता है और state की पूरी जानकारी लौट आती है।

PulseMQ, Sparkplug B का इस्तेमाल कैसे करता है

PulseMQ शुरू से ही Sparkplug B पर बना है। जब कोई PLC एज नोड NBIRTH publish करता है, तो PulseMQ उस डिवाइस और उसके सभी metrics को अपने-आप खोज लेता है — हाथ से tag कॉन्फ़िगरेशन की ज़रूरत नहीं। Birth/death lifecycle से रियल-टाइम में डिवाइस की सेहत ट्रैक होती है: मशीन ऑफ़लाइन होते ही और वापस आते ही प्लेटफ़ॉर्म को तुरंत पता चल जाता है। Recipe download, job dispatch और control setpoints के लिए DCMD मैसेज MES लेयर से वापस एज नोड तक जाते हैं। MQTT आर्किटेक्चर के बारे में और जानें या पूरा PulseMQ प्लेटफ़ॉर्म देखें।

अपने PLC को Sparkplug B से जोड़ें

PulseMQ आपके डिवाइस अपने-आप खोजता है, मशीन state ट्रैक करता है, और आपको रियल-टाइम unified namespace देता है — हाथ से tag mapping की ज़रूरत नहीं।

सेल्स से संपर्क करें