मैन्युफैक्चरिंग के लिए MQTT बनाम OPC-UA:
कौन-सा प्रोटोकॉल बेहतर है?

प्रकाशित 24 मार्च 2026 · पढ़ने में 8 मिनट

अगर आप किसी मैन्युफैक्चरिंग IoT प्रोजेक्ट के लिए कम्युनिकेशन प्रोटोकॉल चुन रहे हैं, तो चर्चा में दो नाम छाए रहते हैं: MQTT और OPC-UA। दोनों प्रोडक्शन में परखे जा चुके हैं। दोनों के बड़े ecosystem हैं। और दोनों एक ही बुनियादी समस्या हल करते हैं — मशीनों से डेटा उन सिस्टम तक पहुँचाना जिन्हें उसकी ज़रूरत है।

लेकिन दोनों का तरीका बुनियादी तौर पर अलग है। MQTT एक हल्के मैसेजिंग ट्रांसपोर्ट के रूप में डिज़ाइन हुआ। OPC-UA एक व्यापक औद्योगिक interoperability framework के रूप में। सोच का यही फ़र्क़ सब कुछ तय करता है: bandwidth की खपत, क्लाउड के लिए तैयारी, डिप्लॉयमेंट की जटिलता, और हर प्रोटोकॉल से बनने वाले आर्किटेक्चर के प्रकार।

यह लेख दोनों प्रोटोकॉल को ईमानदारी से खोलकर देखता है — ख़ूबियाँ, कमज़ोरियाँ, और वे असली स्थितियाँ जहाँ हर एक सही बैठता है। हम दोनों को साथ इस्तेमाल करने के तेज़ी से आम होते पैटर्न पर भी बात करेंगे।

MQTT: हल्की publish-subscribe मैसेजिंग

MQTT (Message Queuing Telemetry Transport) 1999 में IBM के Andy Stanford-Clark ने satellite links पर तेल पाइपलाइनों की मॉनिटरिंग के लिए बनाया था। डिज़ाइन की शर्तें बेहद कड़ी थीं: अविश्वसनीय नेटवर्क, सीमित bandwidth, और बहुत कम processing power वाले डिवाइस। यह विरासत आज भी इस प्रोटोकॉल की पहचान है।

MQTT कैसे काम करता है

MQTT एक केंद्रीय broker के साथ publish-subscribe मॉडल इस्तेमाल करता है। डिवाइस नाम वाले topics पर मैसेज publish करते हैं (जैसे plant/line-1/saw-04/temperature)। दूसरे सिस्टम अपने काम के topics को subscribe करते हैं। सारी routing broker संभालता है — publishers और subscribers कभी सीधे बात नहीं करते।

यह अलगाव बहुत ताक़तवर है। अपना cycle count publish करने वाले PLC को यह जानने की ज़रूरत नहीं कि वह डेटा एक सिस्टम इस्तेमाल कर रहा है या पचास। आप publisher का कॉन्फ़िगरेशन छुए बिना नए subscribers (historian, OEE calculator, मेंटेनेंस अलर्ट सिस्टम) जोड़ सकते हैं।

मुख्य विशेषताएँ

बहुत कम overhead। MQTT का fixed header सिर्फ़ 2 bytes का है। पूरा CONNECT packet लगभग 20 bytes का होता है। इसकी तुलना HTTP requests से करें, जिनके सिर्फ़ headers ही अक्सर 500 bytes से ज़्यादा होते हैं।
Binary payloads। MQTT, payload के फ़ॉर्मेट से बँधा नहीं है। आप JSON, Protobuf, raw binary या कुछ भी भेज सकते हैं। प्रोटोकॉल कोई serialization फ़ॉर्मेट थोपता नहीं।
Quality of Service levels। QoS 0 (at most once), QoS 1 (at least once) और QoS 2 (exactly once) से आप हर मैसेज के स्तर पर डिलीवरी की गारंटी और परफ़ॉर्मेंस के बीच संतुलन चुन सकते हैं।
Retained messages और Last Will। Retained message से नए subscribers को सबसे ताज़ा वैल्यू तुरंत मिल जाती है। Last Will and Testament (LWT) से broker बता सकता है कि कोई डिवाइस अचानक डिस्कनेक्ट हुआ।
Native क्लाउड सपोर्ट। AWS IoT Core, Azure IoT Hub, Google Cloud IoT और HiveMQ Cloud सभी managed MQTT brokers देते हैं। न gateways, न protocol translation — डिवाइस सीधे जुड़ते हैं।

Sparkplug B: औद्योगिक स्तर का MQTT

साधारण MQTT, payload स्ट्रक्चर या topic के नामों पर कुछ नहीं कहता। औद्योगिक इस्तेमाल के लिए Sparkplug B specification (अब Eclipse Foundation का standard) वह जोड़ता है जिसकी मैन्युफैक्चरिंग को ज़रूरत है: एक तय topic namespace (spBv1.0/groupId/NBIRTH/nodeId), डिवाइस lifecycle management के लिए birth/death certificates, datatypes और टाइमस्टैम्प के साथ metric definitions, और नेटवर्क बंद होने के दौरान store-and-forward के लिए state management।

Sparkplug B, MQTT को एक सामान्य मैसेजिंग प्रोटोकॉल से उद्योग के लिए ख़ास बने डेटा इंफ्रास्ट्रक्चर में बदल देता है — और नीचे का हल्का ट्रांसपोर्ट वैसा ही रहता है।

OPC-UA: व्यापक औद्योगिक interoperability

OPC-UA (Open Platform Communications Unified Architecture) को OPC Foundation ने 2008 में OPC Classic (जो COM/DCOM-आधारित और सिर्फ़ Windows पर चलता था) के उत्तराधिकारी के रूप में जारी किया। इसे industrial automation के लिए सार्वभौमिक interoperability standard के रूप में डिज़ाइन किया गया।

OPC-UA कैसे काम करता है

OPC-UA मुख्य रूप से client-server मॉडल इस्तेमाल करता है। OPC-UA सर्वर एक address space देता है — nodes का एक hierarchical tree, जो variables, objects, methods और data types को दर्शाता है। Clients इस address space को browse करते हैं, वैल्यू पढ़ते हैं, commands लिखते हैं, बदलावों को subscribe करते हैं और methods call करते हैं।

OPC-UA specification में एक नया pub-sub extension (Part 14) भी है, जो MQTT जैसा broker-आधारित कम्युनिकेशन संभव बनाता है। फिर भी client-server मॉडल की तुलना में OPC-UA Pub/Sub का इस्तेमाल अभी सीमित है।

मुख्य विशेषताएँ

Rich information modeling। OPC-UA का address space उसकी सबसे बड़ी ताक़त है। हर data point के साथ context होता है: engineering units, value ranges, data types, दूसरे nodes से संबंध, और अर्थ। आप सिर्फ़ data points नहीं, पूरी मशीन के स्ट्रक्चर को मॉडल कर सकते हैं।
बिल्ट-इन सुरक्षा। OPC-UA प्रोटोकॉल के स्तर पर X.509 certificate-आधारित authentication, message signing और encryption तय करता है। सुरक्षा वैकल्पिक नहीं है — यह specification का हिस्सा है।
Companion specifications। इंडस्ट्री समूह ख़ास क्षेत्रों के लिए मानकीकृत information models प्रकाशित करते हैं: पैकेजिंग मशीनों के लिए PackML, injection molding के लिए Euromap, identification सिस्टम के लिए AutoID। इन मॉडलों का मतलब है कि Vendor A की PackML-अनुरूप मशीन वही डेटा स्ट्रक्चर देती है जो Vendor B की।
Method calls। OPC-UA में remote procedure calls का सीधा सपोर्ट है। Client तय input/output arguments के साथ सर्वर पर कोई method चला सकता है (जैसे "start cycle" या "acknowledge alarm")।
Platform से स्वतंत्र। OPC Classic के उलट, OPC-UA Linux, Windows और embedded सिस्टम पर चलता है। C, C++, .NET, Java, Python और JavaScript के लिए SDK मौजूद हैं।

जटिलता की क़ीमत

OPC-UA की व्यापकता की एक क़ीमत है। पूरा specification 14+ parts और हज़ारों पन्नों में फैला है। सही information model के साथ OPC-UA सर्वर खड़ा करने में काफ़ी इंजीनियरिंग मेहनत लगती है। Client implementations को session management, subscription lifecycles, secure channel negotiation और certificate management संभालना पड़ता है। सीमित संसाधनों वाले एज डिवाइसों के लिए यह overhead भारी पड़ सकता है।

आमने-सामने तुलना

फ़ीचर	MQTT	OPC-UA
Bandwidth	बहुत कम (2-byte fixed header)	ज़्यादा (rich metadata के साथ XML या binary encoding)
Latency	एक मिलीसेकंड से कम में publish	कुछ मिलीसेकंड (session + subscription overhead)
Cloud native	हाँ — AWS IoT Core, Azure IoT Hub, GCP में native	सीमित — gateways या protocol translation चाहिए
Scalability	हर broker cluster पर लाखों concurrent connections	हर सर्वर पर सैकड़ों sessions (व्यावहारिक सीमा)
Information model	बिल्ट-इन नहीं; Sparkplug B मानकीकृत semantics जोड़ता है	Types, methods, events के साथ समृद्ध बिल्ट-इन address space
सुरक्षा	TLS encryption + username/password या certificate auth	X.509 certificates + message signing + encryption
Implementation की जटिलता	सरल — <20 लाइनों में connect, subscribe, publish	जटिल — sessions, channels, certificates, address space
एज डिवाइस सपोर्ट	Microcontrollers (ESP32, Arduino) पर चलता है	ज़्यादा CPU/RAM चाहिए (कम से कम embedded Linux)

MQTT कब इस्तेमाल करें

जब आपके आर्किटेक्चर में क्लाउड कनेक्टिविटी, बहुत बड़ा scale या हल्का एज डिप्लॉयमेंट प्राथमिकता हो, तो MQTT बेहतर विकल्प है। ख़ास स्थितियाँ जहाँ MQTT आगे है:

Greenfield IoT प्रोजेक्ट। जब आप शून्य से शुरू कर रहे हों, तो MQTT सेंसर से क्लाउड तक सबसे सरल रास्ता देता है। न gateway layers, न protocol translation, न संभालने के लिए middleware सर्वर।
Cloud-first आर्किटेक्चर। अगर आपकी data pipeline AWS, Azure या GCP से होकर चलती है, तो MQTT वहाँ का native ट्रांसपोर्ट है। आपके डिवाइस बिल्ट-इन authentication, authorization और message routing वाले managed cloud brokers से सीधे जुड़ते हैं।
बहुत सारे डिवाइस। जब आप कई प्लांट्स में सैकड़ों या हज़ारों सेंसर, PLC और एज डिवाइस जोड़ रहे हों, तो MQTT brokers वह concurrency संभाल लेते हैं जो OPC-UA सर्वर नहीं संभाल पाते। एक अकेला HiveMQ cluster लाखों connections बनाए रख सकता है।
Edge-to-cloud data pipelines। MQTT की store-and-forward क्षमता (ख़ासकर Sparkplug B के साथ) का मतलब है कि नेटवर्क बंद होने पर एज डिवाइस डेटा buffer करते हैं और कनेक्टिविटी लौटने पर उसे replay करते हैं। अविश्वसनीय इंटरनेट वाले प्लांट्स के लिए यह बेहद ज़रूरी है।
Unified Namespace (UNS) आर्किटेक्चर। UNS पैटर्न — जिसे Walker Reynolds और Industry 4.0 समुदाय ने लोकप्रिय बनाया — प्लांट के सारे डेटा के लिए एक अकेले MQTT broker को केंद्रीय तंत्रिका तंत्र की तरह इस्तेमाल करता है। हर सिस्टम एक ही namespace पर publish और subscribe करता है। Sparkplug B के साथ MQTT ख़ास इसी पैटर्न के लिए बना है।

OPC-UA कब इस्तेमाल करें

जब आपको rich information modeling, मशीन-स्तर की interoperability, या मौजूदा OPC इंफ्रास्ट्रक्चर से integration चाहिए, तो OPC-UA बेहतर विकल्प है। ख़ास स्थितियाँ:

OPC Classic वाले brownfield माहौल। अगर आपके प्लांट में पहले से OPC Classic (OPC-DA, OPC-HDA) चलता है, तो OPC-UA पर जाना स्वाभाविक अपग्रेड है। Semantics, information models और tooling साथ आ जाते हैं। MQTT पर जाने के लिए आपको अपना data model शुरू से दोबारा बनाना पड़ेगा।
Rich information modeling की ज़रूरत। जब आपको चाहिए कि हर data point के साथ उसकी engineering unit, value range, data type, access level और दूसरे variables से संबंध हों — और यह मॉडल runtime पर browse किया जा सके — तो OPC-UA के address space का कोई मुक़ाबला नहीं।
Shop floor पर machine-to-machine कम्युनिकेशन। Method calls वाला OPC-UA का client-server मॉडल मशीनों के बीच सीधे संवाद के लिए अच्छा है: एक मशीन दूसरी की state पूछे, operations ट्रिगर करे, या process parameters का आदान-प्रदान करे। MQTT भी यह कर सकता है, लेकिन इसके लिए application-स्तर पर ज़्यादा लॉजिक चाहिए।
Companion specifications का पालन। अगर आपकी इंडस्ट्री के लिए कोई प्रकाशित OPC-UA companion specification है (PackML, Euromap 77/83, PADIM आदि), तो OPC-UA इस्तेमाल करने से उस specification के अनुरूप किसी भी डिवाइस के साथ plug-and-play interoperability मिलती है। पैकेजिंग, प्लास्टिक और फ़ार्मास्यूटिकल मैन्युफैक्चरिंग में यह ख़ास तौर पर क़ीमती है।
पारंपरिक SCADA integration। ज़्यादातर आधुनिक SCADA सिस्टम (Ignition, WinCC, FactoryTalk) में native OPC-UA clients होते हैं। अगर आपका आर्किटेक्चर SCADA सिस्टम के इर्द-गिर्द है, तो OPC-UA सबसे मज़बूत integration देता है।

क्या दोनों साथ इस्तेमाल कर सकते हैं?

हाँ — और कई प्लांट ऐसा करते हैं। सबसे आम hybrid पैटर्न कुछ ऐसा दिखता है:

एज पर OPC-UA। PLC और मशीन कंट्रोलर shop floor नेटवर्क पर OPC-UA सर्वर देते हैं। SCADA सिस्टम और HMI रियल-टाइम visualization और control के लिए OPC-UA clients के रूप में जुड़ते हैं।
North-south ट्रांसपोर्ट के लिए MQTT। एक एज gateway (जैसे Ignition Edge, Kepware या कोई custom bridge) OPC-UA डेटा को subscribe करके MQTT broker पर दोबारा publish करता है। वहाँ से डेटा क्लाउड services, historians, MES सिस्टम और analytics प्लेटफ़ॉर्म तक जाता है।

यह आर्किटेक्चर आपको दोनों की ख़ूबियाँ देता है: shop floor की interoperability के लिए OPC-UA की rich modeling और method calls, और एज से ऊपर की हर चीज़ के लिए MQTT का हल्का ट्रांसपोर्ट और native क्लाउड कनेक्टिविटी। Gateway दोनों के बीच अनुवाद करता है, आमतौर पर किसी industrial PC या एज सर्वर पर चलते हुए।

इसकी क़ीमत बढ़ी हुई जटिलता है: अब आपको दो protocol stacks संभालने होंगे, और gateway एक संभावित single point of failure बन जाता है। Greenfield प्रोजेक्ट्स में शुरू से अंत तक MQTT (PLC से क्लाउड तक) इस्तेमाल करने से यह translation layer पूरी तरह हट जाती है।

PulseMQ ने MQTT + Sparkplug B क्यों चुना

PulseMQ शुरू से ही Sparkplug B के साथ MQTT पर बना है। हमारा आर्किटेक्चर PLC को MQTT के ज़रिए सीधे AWS IoT Core से जोड़ता है — न OPC-UA सर्वर, न gateways, न middleware। इससे मशीन से क्लाउड डैशबोर्ड तक एक सेकंड से कम में डेटा पहुँचता है, और संभालने के लिए इंफ्रास्ट्रक्चर बहुत कम रहता है। Sparkplug B वे औद्योगिक semantics (birth/death certificates, metric definitions, state management) देता है जो साधारण MQTT में नहीं हैं, और प्रोटोकॉल को इतना हल्का रखता है कि वह Ethernet port वाले किसी भी PLC पर चल सके।

हम MQTT का इस्तेमाल कैसे करते हैं और हमें क्यों लगता है कि आधुनिक मैन्युफैक्चरिंग के लिए यही सही ट्रांसपोर्ट है, इसे गहराई से समझने के लिए हमारा MQTT क्यों पेज देखें।

अपनी मशीनें जोड़ने के लिए तैयार हैं?

देखिए कि PulseMQ, MQTT + Sparkplug B से रियल-टाइम OEE, job ट्रैकिंग और मटीरियल traceability कैसे देता है — बिना middleware के।

डेमो का अनुरोध करें