औद्योगिक उपकरणों के लिए MQTT अलार्म मॉनिटरिंग

पारंपरिक अलार्म मॉनिटरिंग SCADA नेटवर्क के अंदर क़ैद रहती है। MQTT यह दीवार तोड़ता है — अलार्म state में हर बदलाव किसी भी subscriber तक, कहीं भी, मिलीसेकंड में पहुँचाता है।

Polling-आधारित अलार्म सिस्टम की समस्या

ज़्यादातर औद्योगिक अलार्म मॉनिटरिंग सिस्टम polling से काम करते हैं। SCADA सर्वर या HMI तय अंतराल पर PLC tags पढ़ता है — आमतौर पर हर 500ms से 5 सेकंड में — अलार्म conditions जाँचता है और हर बदलाव लॉग करता है। एक अकेले कंट्रोल नेटवर्क की सीमा में यह तरीका दशकों से चलता आया है, लेकिन इसकी कुछ बुनियादी सीमाएँ हैं।

Polling में latency कभी भी poll interval से कम नहीं हो सकती। अगर आप हर 2 सेकंड में poll करते हैं, तो उस बीच active होकर clear हो जाने वाला अलार्म छूट सकता है। इससे भी अहम बात: polling कई प्लांट्स में अच्छी तरह scale नहीं होती। अगर आप 3 इमारतों की 50 मशीनों के लिए एक केंद्रीय मॉनिटरिंग सिस्टम चाहते हैं, तो SCADA सर्वर को हर मशीन के लिए स्थायी कनेक्शन और poll cycles बनाए रखने होंगे — कॉन्फ़िगरेशन का ऐसा सिरदर्द जो मशीनों की संख्या के साथ बढ़ता जाता है।

फिर नेटवर्क की सीमा की समस्या है। SCADA सिस्टम आमतौर पर अलग-थलग OT नेटवर्क पर चलते हैं, जहाँ इंटरनेट नहीं होता। अलार्म डेटा को क्लाउड डैशबोर्ड, मोबाइल फ़ोन या enterprise historian तक पहुँचाने के लिए data diodes, relay सर्वर और custom middleware वाले जटिल DMZ आर्किटेक्चर बनाने पड़ते हैं।

अलार्म डिलीवरी के लिए MQTT बेहतर क्यों है

MQTT एक publish-subscribe मैसेजिंग प्रोटोकॉल है, जो सीमित नेटवर्क के लिए डिज़ाइन किया गया है। Polling की जगह डिवाइस तभी मैसेज publish करते हैं जब state बदलती है। Subscribers को वे मैसेज तुरंत मिल जाते हैं। बुनियादी फ़र्क़ है: event-driven डिलीवरी बनाम तय समय पर रीड।

अलार्म मॉनिटरिंग के लिए इसका मतलब है:

• Polling की कोई latency नहीं — अलार्म state बदलते ही उसी पल publish होती है, अगले poll cycle का इंतज़ार नहीं
• Report by exception — सिर्फ़ बदलाव भेजे जाते हैं, जिससे cyclic polling की तुलना में नेटवर्क ट्रैफ़िक 90%+ कम होता है
• Decoupled आर्किटेक्चर — publishers और subscribers को एक-दूसरे के बारे में जानने की ज़रूरत नहीं। नया अलार्म consumer जोड़ने के लिए PLC या एज gateway में कोई बदलाव नहीं करना पड़ता।
• बिल्ट-इन QoS — MQTT तीन quality-of-service levels सपोर्ट करता है। QoS 1 (at-least-once डिलीवरी) अपने-आप retry करके यह गारंटी देता है कि नेटवर्क रुकावट के बावजूद अलार्म मैसेज बचे रहें।
• Retained messages — broker हर topic का आख़िरी मैसेज सहेजकर रखता है। नया subscriber जुड़ते ही उसे मौजूदा अलार्म state तुरंत मिल जाती है, अगले बदलाव का इंतज़ार किए बिना।
• हल्का प्रोटोकॉल — MQTT बहुत कम bandwidth पर चलता है। अलार्म state बदलाव का पूरा मैसेज आमतौर पर 200 bytes से कम होता है। इसलिए दूरदराज़ की साइट्स के लिए यह cellular नेटवर्क पर भी काम करता है।

Sparkplug B: औद्योगिक MQTT स्टैंडर्ड

साधारण MQTT ट्रांसपोर्ट का तरीका तय करता है, डेटा फ़ॉर्मेट नहीं। Sparkplug B, जो अब Eclipse Foundation का specification है, वह स्ट्रक्चर जोड़ता है जिसकी औद्योगिक applications को ज़रूरत होती है:

Topic namespace

Sparkplug B एक hierarchical topic स्ट्रक्चर तय करता है: spBv1.0/GroupId/MessageType/EdgeNodeId/DeviceId। अलार्म मॉनिटरिंग के लिए एक सामान्य अलार्म topic ऐसा हो सकता है:

• spBv1.0/Plant1/DDATA/Line3/Mixer01

DDATA message type का मतलब है डिवाइस डेटा — एक report-by-exception payload, जिसमें सिर्फ़ वे metrics (tags) होते हैं जो पिछले publish के बाद बदले हैं।

Sparkplug B में अलार्म payload

Sparkplug B कुशल binary encoding के लिए Google Protocol Buffers (protobuf) इस्तेमाल करता है। Payload के हर metric में ये होते हैं:

• Name — tag path (जैसे Alarms/TempHH)
• Datatype — digital अलार्म के लिए Boolean, analog अलार्म वैल्यू के लिए Int32 या Float
• Value — मौजूदा state
• Timestamp — एज नोड से मिलीसेकंड रिज़ॉल्यूशन वाला UTC टाइमस्टैम्प
• Quality — good, bad या stale का संकेत

इस स्ट्रक्चर का मतलब है कि अलार्म state का हर बदलाव एज से आए सटीक टाइमस्टैम्प के साथ पहुँचता है, रिसीव करने वाले सर्वर के टाइमस्टैम्प के साथ नहीं। कई मशीनों में root cause analysis के लिए घटनाओं का क्रम तय करने में सटीक एज टाइमस्टैम्प बेहद ज़रूरी हैं।

Birth और death certificates

Sparkplug B में birth (NBIRTH/DBIRTH) और death (NDEATH/DDEATH) मैसेज होते हैं। एज नोड जुड़ते ही एक birth certificate publish करता है, जिसमें हर वह metric होता है जिसे वह रिपोर्ट करेगा — सभी अलार्म tags उनकी मौजूदा वैल्यू के साथ। अचानक डिस्कनेक्ट होने पर broker पहले से रजिस्टर किया गया death certificate publish करता है।

अलार्म मॉनिटरिंग के लिए इसका मतलब है:

• मॉनिटरिंग सिस्टम को हमेशा पता रहता है कि हर मशीन से कौन-कौन से अलार्म उपलब्ध हैं
• कनेक्शन टूटना अपने-आप में एक अलार्म इवेंट है, जिसे broker अपने-आप डिलीवर करता है
• कोई अलार्म state अज्ञात नहीं रहती — birth certificates शुरुआती state देते हैं, DDATA बदलाव देता है, death certificates बताते हैं कि दृश्यता खो गई है

OPC-UA subscriptions बनाम MQTT pub/sub

OPC-UA भी अपने subscription मॉडल के ज़रिए event-driven कम्युनिकेशन सपोर्ट करता है। Client एक subscription बनाता है, monitored items (tags) जोड़ता है, और वैल्यू बदलने पर notification पाता है। तो अलार्म मॉनिटरिंग के लिए OPC-UA की जगह MQTT क्यों चुनें?

• कनेक्शन मॉडल — OPC-UA subscriptions point-to-point होती हैं। हर consumer को OPC-UA सर्वर से अपना session और subscription चाहिए। MQTT one-to-many है: एक publish सभी subscribers तक पहुँचता है।
• नेटवर्क पार करना — OPC-UA को दोतरफ़ा TCP कनेक्शन चाहिए, जिन्हें firewall और NAT से गुज़ारना मुश्किल है। MQTT एज से सिर्फ़ outbound कनेक्शन इस्तेमाल करता है, जो firewall से सहज ही निकल जाते हैं।
• Broker persistence — MQTT broker डिस्कनेक्ट हुए subscribers के लिए मैसेज सहेजकर रखता है (QoS 1/2 और persistent sessions के साथ)। OPC-UA subscriptions की एक lifetime होती है — client बहुत देर तक डिस्कनेक्ट रहे तो subscription हट जाती है और डेटा खो जाता है।
• Scalability — OPC-UA सर्वर पर एक साथ चलने वाले sessions की व्यावहारिक सीमा होती है (आमतौर पर 20-50)। MQTT broker हज़ारों subscribers को एक साथ संभाल सकता है।

व्यावहारिक तरीका: एज पर PLC tags पढ़ने के लिए OPC-UA, और उन्हें मॉनिटरिंग सिस्टम तक पहुँचाने के लिए MQTT इस्तेमाल करें। OPC-UA-से-MQTT एज gateway दोनों की ख़ूबियाँ जोड़ता है: OPC-UA से भरोसेमंद PLC कम्युनिकेशन, MQTT से कुशल fan-out।

SCADA के बिना अलार्म मॉनिटरिंग सेट अप करना

अलार्म मॉनिटर करने के लिए पूरे SCADA सिस्टम की ज़रूरत नहीं है। MQTT-आधारित न्यूनतम अलार्म मॉनिटरिंग सेटअप के लिए तीन चीज़ें चाहिए:

1. एज gateway

एक छोटा industrial PC या gateway appliance, जिस पर OPC-UA client और MQTT publisher चलता हो। आम विकल्प:

• MQTT Transmission module के साथ Ignition Edge
• IoT Gateway plugin के साथ Kepware
• Open-source समाधान, जैसे OPC-UA और MQTT nodes के साथ Node-RED
• समर्पित हार्डवेयर, जैसे HMS Ewon या Moxa gateways

एज gateway PLC से OPC-UA के ज़रिए जुड़ता है (या Allen-Bradley के लिए EtherNet/IP, Siemens के लिए S7), अलार्म tags पढ़ता है और state के बदलाव MQTT broker पर publish करता है।

2. MQTT broker

Broker ऑन-प्रेम, क्लाउड में या managed service के रूप में चल सकता है। औद्योगिक अलार्म मॉनिटरिंग के लिए:

• ऑन-प्रेम: Mosquitto (open source), या ज़्यादा availability के लिए HiveMQ
• क्लाउड: AWS IoT Core, Azure IoT Hub या HiveMQ Cloud

अलार्म की विश्वसनीयता के लिए कम से कम QoS 1 इस्तेमाल करें। QoS 0 (fire-and-forget) में नेटवर्क गड़बड़ी के दौरान अलार्म मैसेज खोने का जोखिम है।

3. अलार्म consumer

कोई भी MQTT subscriber अलार्म डेटा इस्तेमाल कर सकता है। यह क्लाउड application, मोबाइल notification सर्विस, enterprise historian या अलार्म मैनेजमेंट के लिए बना कोई प्लेटफ़ॉर्म हो सकता है।

एज डिप्लॉयमेंट में ध्यान देने वाली बातें

एज पर MQTT अलार्म मॉनिटरिंग डिप्लॉय करते समय कुछ व्यावहारिक बातों का ध्यान रखना पड़ता है:

• Store and forward — इंटरनेट बंद होने पर एज gateway को अलार्म मैसेज buffer करने होंगे और कनेक्टिविटी लौटने पर आगे भेजने होंगे। ज़्यादातर commercial gateways यह पहले से सपोर्ट करते हैं।
• लोकल अलार्म प्रोसेसिंग — time-critical अलार्म को क्लाउड round-trip का इंतज़ार किए बिना एज पर ही प्रोसेस करें। एज लॉजिक सीधे SMS भेज सकता है या लोकल outputs ट्रिगर कर सकता है।
• Bandwidth — MQTT अलार्म मैसेज छोटे होते हैं, लेकिन अगर आप हर tag बदलाव publish करते हैं (सिर्फ़ अलार्म नहीं), तो cellular कनेक्शन पर bandwidth बढ़ सकती है। एज gateway को सिर्फ़ अलार्म से जुड़े tags फ़िल्टर करने के लिए कॉन्फ़िगर करें।
• सुरक्षा — सभी MQTT कनेक्शन के लिए TLS encryption और certificate-आधारित authentication इस्तेमाल करें। MQTT broker को बिना authentication के कभी इंटरनेट पर खुला न छोड़ें।

आगे पढ़ें

• PLC अलार्म root cause analysis — अलार्म को उनके भौतिक root cause तक कैसे ट्रेस करें
• Allen-Bradley अलार्म मैनेजमेंट गाइड — ControlLogix और CompactLogix में अलार्म पैटर्न
• PLC के लिए AI predictive मेंटेनेंस — proactive मेंटेनेंस के लिए PLC डेटा का इस्तेमाल
• मैन्युफैक्चरिंग के लिए MQTT क्यों — इंडस्ट्रियल IoT के लिए MQTT पर गहराई से जानकारी
• AlarmIQ — AI-आधारित PLC अलार्म डायग्नॉस्टिक्स और root cause ट्रेसिंग
• PulseMQ इनसाइट्स — और इंजीनियरिंग गाइड व तकनीकी लेख