IoT Hub मैसेज रूटिंग बनाम Event Grid — टेलीमेट्री और इवेंट एक ही समस्या क्यों नहीं हैं

एक तापमान रीडिंग, एक कंपन नमूना, एक मशीन चक्र और एक डिवाइस डिस्कनेक्ट, इन सभी को इवेंट के रूप में वर्णित किया जा सकता है, लेकिन ये एक ही आर्किटेक्चरल समस्या का प्रतिनिधित्व नहीं करते। औद्योगिक IoT और विनिर्माण वातावरण में, निरंतर टेलीमेट्री और असतत इवेंट्स के बीच भ्रम पैदा होने से शोर-भरे वर्कफ़्लो, अधूरे उत्पादन इतिहास, अनावश्यक प्रसंस्करण और ऐसे सिस्टम बन सकते हैं जो पर्याप्त संदर्भ के बिना प्रतिक्रिया करते हैं।

इस एपिसोड में, हम एक वास्तविक विनिर्माण परिदृश्य के माध्यम से Azure IoT Hub Message Routing और Azure Event Grid के बीच आर्किटेक्चरल अंतर का विश्लेषण करते हैं। एक प्रेस लाइन औद्योगिक गेटवे के माध्यम से तापमान, कंपन, चक्र गणना, ऊर्जा खपत और मशीन-स्थिति की जानकारी लगातार भेजती है। ये माप एक परिचालन इतिहास बनाते हैं, जिसका बाद में इंजीनियर, डेटा टीमें, रखरखाव टीमें और उत्पादन सिस्टम विश्लेषण कर सकते हैं। डिवाइस डिस्कनेक्ट अलग है, क्योंकि यह एक ऐसे बदलाव का प्रतिनिधित्व करता है जिस पर किसी अन्य सिस्टम या व्यक्ति को प्रतिक्रिया देने की आवश्यकता हो सकती है।

टेलीमेट्री एक रिकॉर्ड है, अलर्ट नहीं
टेलीमेट्री समय के साथ दोहराए गए मापों का प्रतिनिधित्व करती है। अकेला तापमान मान या कंपन माप आमतौर पर स्वयं बहुत कम बताता है। वास्तविक जानकारी अनुक्रम में निहित है: मान कितनी तेज़ी से बदले, रुकने से ठीक पहले मशीन क्या कर रही थी, नेटवर्क बाधा के दौरान माप गायब हुए या नहीं, और क्या पिछले उत्पादन चक्रों में भी यही व्यवहार दिखा था।

विशिष्ट औद्योगिक टेलीमेट्री में शामिल हैं:
• तापमान, कंपन, दबाव, ऊर्जा खपत और धारा खपत
• मशीन अवस्थाएँ जैसे चल रही, निष्क्रिय, रुकी हुई, या खराब
• चक्र गणना, उत्पादन काउंटर और प्रक्रिया माप
• स्रोत टाइमस्टैम्प, डिवाइस पहचानकर्ता, अनुक्रम संख्याएँ और सहसंबंध जानकारी

ये रिकॉर्ड बाद में स्थिति निगरानी, गुणवत्ता जाँच, ऊर्जा विश्लेषण, OEE गणना, Microsoft Fabric एनालिटिक्स, Power BI रिपोर्टिंग और उत्पादन अनुकूलन का समर्थन कर सकते हैं। इसीलिए टेलीमेट्री को रिटेंशन, रीप्ले, डुप्लिकेट प्रबंधन, स्वतंत्र उपभोक्ताओं और उत्पादन समयरेखा के विश्वसनीय पुनर्निर्माण के तरीके की आवश्यकता होती है।

टेलीमेट्री डेटा प्लेन के रूप में IoT Hub Message Routing
Azure IoT Hub नियंत्रित डिवाइस-से-क्लाउड सीमा प्रदान करता है। डिवाइस और गेटवे अपनी स्वयं की पहचान के साथ प्रमाणित होते हैं, डिवाइस-से-क्लाउड संदेश भेजते हैं, डिवाइस-प्रबंधन स्थिति बनाए रखते हैं, और नियंत्रित क्लाउड-से-डिवाइस संचार में भाग ले सकते हैं।

एक बार टेलीमेट्री संदेश IoT Hub तक पहुँचने के बाद, Message Routing तय करता है कि वह डेटा कहाँ जाना चाहिए। Routing संदेश गुणों, सिस्टम गुणों, संदेश बॉडी के हिस्सों और डिवाइस ट्विन जानकारी का निरीक्षण कर सकता है। इससे डाउनस्ट्रीम उपभोक्ताओं तक पहुँचने से पहले उत्पादन टेलीमेट्री, ऊर्जा माप, डायग्नोस्टिक्स या अन्य संदेश वर्गों को अलग करना संभव हो जाता है।
एक सामान्य आर्किटेक्चर इस प्रकार दिख सकता है: औद्योगिक गेटवे → Azure IoT Hub → Message Routing → Event Hubs या Storage → प्रसंस्करण → Microsoft Fabric।

एक उपभोक्ता लगभग-वास्तविक समय विश्लेषण कर सकता है, जबकि दूसरा कच्चा आर्काइव रखता है। एक तीसरा उपभोक्ता Microsoft Fabric के लिए क्यूरेटेड परिचालन डेटा तैयार कर सकता है। हर उपभोक्ता हर टेलीमेट्री रीडिंग को वर्कफ़्लो इनवोकेशन में बदले बिना स्वतंत्र रूप से काम कर सकता है।

क्रम क्यों मायने रखता है
औद्योगिक टेलीमेट्री अनुक्रम के प्रति विशेष रूप से संवेदनशील है। कल्पना कीजिए कि एक मशीन रिपोर्ट करती है कि वह चल रही अवस्था में प्रवेश कर गई, फिर कई चक्र गणनाएँ भेजीं, फिर एक प्रक्रिया विचलन और अंत में रुकी हुई अवस्था। यदि इन रिकॉर्ड्स का गलत पुनर्निर्माण होता है, तो डाउनस्ट्रीम सिस्टम यह निष्कर्ष निकाल सकता है कि मशीन रुकी होने पर भी उत्पाद बना रही थी, या यह कि प्रक्रिया विचलन तब हुआ जब उत्पादन पहले ही समाप्त हो चुका था।

यही समस्या डाउनटाइम गणना, OEE, उत्पादन गणना और स्थिति निगरानी को भी प्रभावित करती है। इसलिए आपको यह अंतर करना होगा कि स्रोत ने कब कुछ देखा, IoT Hub ने संदेश कब प्राप्त किया, और डाउनस्ट्रीम सिस्टम ने उसे कब संसाधित किया।

एक मजबूत टेलीमेट्री आर्किटेक्चर को इन बातों पर विचार करना चाहिए:
• स्रोत टाइमस्टैम्प और क्लाउड प्राप्ति टाइमस्टैम्प
• एसेट या कार्यभार के अनुरूप स्थिर पार्टिशनिंग
• डुप्लिकेट पहचान के लिए संदेश ID या अनुक्रम संख्याएँ
• ऐसे इडेम्पोटेंट उपभोक्ता जो एट-लीस्ट-वन्स डिलीवरी को संभाल सकें

नेटवर्क बाधाएँ इसे विशेष रूप से महत्वपूर्ण बनाती हैं। गेटवे टेलीमेट्री को बफ़र कर सकता है और कनेक्टिविटी लौटने पर भेज सकता है, यानी Azure पर पहुँचने का समय वास्तविक मशीन टाइमस्टैम्प से काफी बाद का हो सकता है।

Event Grid एक अलग समस्या हल करता है
Azure Event Grid प्रकाशन-और-सदस्यता सूचनाओं के इर्द-गिर्द डिज़ाइन किया गया है। हज़ारों रीडिंग से मशीन की स्थिति लगातार पुनर्निर्मित करने के बजाय, Event Grid रुचि रखने वाले सिस्टम को बताता है कि कुछ बदला है और सदस्यों को प्रतिक्रिया देने का अवसर देता है।
IoT वातावरण के उदाहरणों में डिवाइस निर्माण, डिवाइस हटाना, कनेक्शन, डिस्कनेक्शन, या सावधानी से चुनी गई टेलीमेट्री-आधारित स्थितियाँ शामिल हैं। डिवाइस-निर्मित इवेंट एसेट ऑनबोर्डिंग प्रक्रिया शुरू कर सकता है। डिवाइस-डिस्कनेक्टेड इवेंट तकनीकी जाँच शुरू कर सकता है। पहचानी गई इंजीनियरिंग स्थिति रखरखाव वर्कफ़्लो को सक्रिय कर सकती है।

विशिष्ट सदस्यों में शामिल हैं:
• Azure Functions
• Logic Apps
• Webhooks
• सुरक्षा वर्कफ़्लो
• एसेट-प्रबंधन सिस्टम
• परिचालन एप्लिकेशन

मूल आर्किटेक्चरल अंतर सरल है: टेलीमेट्री पूछती है कि एसेट क्या कर रहा है, जबकि इवेंट पूछता है कि क्या बदला और क्या किसी को प्रतिक्रिया देनी चाहिए।

इवेंट्स को जाँच शुरू करनी चाहिए, वास्तविकता तय नहीं करनी चाहिए
Event Grid को आम तौर पर एक सूचना तंत्र माना जाना चाहिए, भौतिक दुनिया की अंतिम प्रामाणिक स्थिति नहीं। इवेंट डिलीवरी दोहराई जा सकती है, और सदस्य को इवेंट को बिना जाँचे अंतिम वर्तमान स्थिति के रूप में आँख मूंदकर नहीं मानना चाहिए।
इसलिए डिवाइस-डिस्कनेक्टेड इवेंट आमतौर पर एक स्थिति जाँच को ट्रिगर करना चाहिए। एक Azure Function वर्तमान डिवाइस स्थिति सत्यापित कर सकता है, हाल की टेलीमेट्री की जाँच कर सकता है, प्रासंगिक रजिस्ट्री जानकारी देख सकता है, और फिर तय कर सकता है कि जाँच खुली रहनी चाहिए या नहीं।

हैंडलर इन पर आधारित होने चाहिए:
• इडेम्पोटेंट प्रसंस्करण
• वर्तमान-स्थिति सत्यापन
• इवेंट पहचान और टाइमस्टैम्प
• परिणामी कार्रवाई के लिए स्पष्ट रूप से परिभाषित स्वामित्व

यह मायने रखता है क्योंकि डुप्लिकेट इवेंट से डुप्लिकेट टिकट, डुप्लिकेट अलर्ट या परस्पर विरोधी परिचालन रिकॉर्ड नहीं बनने चाहिए।

डिवाइस डिस्कनेक्ट का मतलब यह नहीं कि मशीन रुक गई
औद्योगिक IoT में सबसे महत्वपूर्ण अंतरों में से एक क्लाउड कनेक्टिविटी, डेटा-संग्रह स्वास्थ्य और उत्पादन स्थिति के बीच का अंतर है। यदि एक औद्योगिक गेटवे IoT Hub से डिस्कनेक्ट होता है, तो क्लाउड ने उस गेटवे की दृश्यता खो दी है। इसका स्वतः अर्थ यह नहीं कि भौतिक मशीन रुक गई।

PLC स्थानीय रूप से उपकरण को नियंत्रित करता रह सकता है जबकि गेटवे अस्थायी रूप से कनेक्टिविटी खो देता है। उत्पादन सामान्य रूप से चल सकता है, और गेटवे टेलीमेट्री को बफ़र करके बाद में अपलोड भी कर सकता है। इसका उल्टा भी हो सकता है: गेटवे Azure से जुड़ा रह सकता है जबकि उसका PLC या स्थानीय उपकरण से संपर्क विफल हो गया हो।

इसलिए एक उपयोगी आर्किटेक्चर क्लाउड कनेक्शन स्थिति, गेटवे स्वास्थ्य, मशीन उत्पादन स्थिति और MES वर्क-ऑर्डर स्थिति को अलग रखता है। केवल इन स्रोतों को मिलाकर ही व्यवसाय यह तय कर सकता है कि तकनीकी कनेक्टिविटी समस्या ने वास्तव में उत्पादन को प्रभावित किया या नहीं।

IoT Hub में फ़िल्टरिंग बनाम Event Grid में फ़िल्टरिंग
दोनों तकनीकें फ़िल्टरिंग का समर्थन करती हैं, लेकिन उनका उद्देश्य अलग है। IoT Hub Message Routing फ़िल्टरिंग यह तय करती है कि कौन से परिचालन संदेश किसी विशिष्ट डेटा पथ में प्रवेश करें। Event Grid सदस्यता फ़िल्टरिंग यह तय करती है कि कोई विशेष सदस्य कौन सी सूचनाएँ प्राप्त करे।

उदाहरण के लिए, उत्पादन टेलीमेट्री एक Event Hubs स्ट्रीम में जा सकती है जबकि ऊर्जा डेटा दूसरे गंतव्य पर। साथ ही, एक सहायता वर्कफ़्लो केवल किसी विशेष से डिस्कनेक्टेड इवेंट्स की सदस्यता ले सकता है।