मशीन डेटा Microsoft Fabric तक कैसे पहुँचता है - OPC UA से रियल-टाइम एनालिटिक्स तक

मशीन अलार्म, सेंसर मान, उत्पादन काउंटर और खराबी की घटनाओं को क्लाउड तक पहुँचाना पहले से कहीं आसान हो गया है। OPC UA मशीन सिग्नल को उजागर करता है, एज लेयर उसे एकत्र करती है, MQTT उसे स्थानीय रूप से वितरित कर सकता है, और Microsoft Fabric उस परिणामी स्ट्रीम को अंतर्ग्रहण और विश्लेषित कर सकता है। कठिन हिस्सा डेटा पहुँचने के बाद शुरू होता है: आप कच्चे टेलीमेट्री को किसी वास्तविक निर्णय का समर्थन करने लायक उत्पादन संदर्भ में कैसे बदलते हैं?

यह एपिसोड फैक्ट्री फ्लोर से Microsoft औद्योगिक डेटा स्टैक तक एक मशीन सिग्नल का सफ़र दिखाता है। यह OPC UA से शुरू होता है, एज और MQTT से गुजरता है, Azure और Microsoft Fabric में सुरक्षित रूप से प्रवेश करता है, और फिर देखता है कि Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, रखरखाव डेटा और उत्पादन संदर्भ एक साथ कैसे जुड़ते हैं। लक्ष्य केवल एक और टेलीमेट्री पाइपलाइन दिखाना नहीं है। यह समझाना है कि मशीन डेटा के उत्पादन, रखरखाव, गुणवत्ता और योजना के लिए उपयोगी बनने से पहले क्या होना आवश्यक है।

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

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

OPC UA — जहाँ सिग्नल डेटा पथ में प्रवेश करता है
OPC UA उपकरणों से जानकारी तक पहुँचने के लिए एक मानकीकृत औद्योगिक इंटरफ़ेस प्रदान करता है, जिससे हर क्लाउड एप्लिकेशन को मालिकाना कंट्रोलर प्रोटोकॉल समझने की आवश्यकता नहीं होती। एक सर्वर वेरिएबल, मशीन स्थितियाँ, अलार्म, घटनाएँ, मेथड, टाइमस्टैम्प, गुणवत्ता जानकारी और कभी-कभी संरचित उपकरण मॉडल उजागर कर सकता है।

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

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

OT सीमा को नियंत्रित रखें
मशीन कनेक्टिविटी उत्पादन नेटवर्क को कॉर्पोरेट या क्लाउड वातावरण का विस्तार नहीं बनना चाहिए। औद्योगिक नेटवर्क को नियंत्रित सीमाओं की आवश्यकता होती है, जिसमें आमतौर पर सेगमेंटेशन और एक औद्योगिक DMZ शामिल होता है, ताकि अनुमोदित एज सिस्टम उपकरणों से संवाद कर सकें बिना एंटरप्राइज़ एप्लिकेशन को कंट्रोलर तक सीधी पहुँच दिए।

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

सर्टिफिकेट, फ़ायरवॉल नियम, ट्रस्ट संबंध, समाप्ति प्रबंधन और स्वामित्व को भी एक-बार की कॉन्फ़िगरेशन के बजाय परिचालन प्रक्रियाओं के रूप में लेना होगा।

एज को डेटा बेहतर बनाना चाहिए — व्यावसायिक अर्थ गढ़ना नहीं
एज लेयर मशीन वातावरण और व्यापक डेटा प्लेटफ़ॉर्म के बीच स्थित है। इसकी पहली ज़िम्मेदारी कनेक्शन है, लेकिन यह जानकारी को प्लांट से बाहर जाने से पहले फ़िल्टर, नॉर्मलाइज़, बफ़र, समृद्ध और रूट भी कर सकती है।

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

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

AZURE IOT EDGE बनाम AZURE IOT OPERATIONS
एपिसोड औद्योगिक एज वर्कलोड चलाने के लिए दो Microsoft दृष्टिकोणों की तुलना करता है।
Azure IoT Edge तब अच्छा काम करता है जब आवश्यकता एक गेटवे या व्यक्तिगत उपकरण के आसपास केंद्रित हो। कंटेनराइज़्ड मॉड्यूल जानकारी एकत्र कर सकते हैं, स्थानीय तर्क लागू कर सकते हैं, डेटा बफ़र कर सकते हैं और Azure IoT Hub के माध्यम से ऊपर भेज सकते हैं। एक परिभाषित सेल या छोटे वर्कलोड के लिए, जहाँ संगठन हल्का परिचालन ढाँचा चाहता है, यह एक व्यावहारिक विकल्प हो सकता है।

Azure IoT Operations को अधिक साइट-स्तरीय औद्योगिक डेटा वातावरण के रूप में रखा गया है। यह Azure Arc-सक्षम Kubernetes वातावरण पर चलता है और इसमें OPC UA कनेक्टिविटी, MQTT, डेटा फ़्लो, और एसेट या डिवाइस प्रबंधन से संबंधित क्षमताएँ शामिल हैं। यह तब अधिक समझदारी भरा हो सकता है जब किसी साइट पर कई लाइनें, कई मशीन विक्रेता, स्थानीय उपभोक्ता हों, और कई प्लांट में एक शासित एज पैटर्न दोहराने की आवश्यकता हो।

निर्णय इस आधार पर नहीं होना चाहिए कि किस प्लेटफ़ॉर्म की सुविधा-सूची सबसे लंबी है। यह इस आधार पर होना चाहिए कि संगठन किस परिचालन मॉडल को सँभालने के लिए तैयार है। Azure IoT Operations व्यापक साइट-स्तरीय क्षमताएँ देता है, लेकिन इसके साथ Kubernetes, Arc, क्लस्टर संचालन, निगरानी, स्टोरेज, पैचिंग और रिकवरी की ज़िम्मेदारियाँ भी आती हैं।

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

इससे कई बिंदु-से-बिंदु निर्भरताएँ हट जाती हैं। एक नया एप्लिकेशन PLC या OPC UA सर्वर में एक और सीधा लिंक बनाए बिना किसी अनुमोदित टॉपिक की सदस्यता ले सकता है।

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

यूनिफ़ाइड नेमस्पेस एक अनुबंध है — केवल टॉपिक ट्री नहीं
Unified Namespace पैटर्न औद्योगिक सिस्टमों में एक साझा परिचालन अनुबंध प्रदान कर सकता है। उपयोगी बात केवल एक विशाल MQTT पदानुक्रम होना नहीं है। मूल्य इस पर सहमति से आता है कि एसेट की पहचान कैसे होगी, इवेंट कैसे आकार लेंगे, डेटा का स्वामी कौन है, स्कीमा कैसे बदलेंगे, और विभिन्न तथ्यों के लिए कौन से सिस्टम प्रामाणिक हैं।

एक अच्छा Unified Namespace एसेट की पहचान करने और शासित परिचालन इवेंट प्रकाशित करने का स्थिर तरीका दे सकता है, जबकि स्रोत सिस्टम अपने रिकॉर्ड का स्वामित्व बनाए रखते हैं।

वह अनुबंध निम्नलिखित चीज़ें परिभाषित करना चाहिए:
• एसेट पहचान
• इवेंट प्रकार
• मैसेज संरचना
• टाइमस्टैम्प नियम
• गुणवत्ता जानकारी
• स्वामित्व
• सुरक्षा
• संस्करण प्रबंधन
• परिवर्तन प्रबंधन

MQTT अनुबंध को परिवहन कर सकता है, लेकिन MQTT अनुबंध नहीं बनाता।

OPC UA नोटिफ़िकेशन से MQTT इवेंट तक
OPC UA नोटिफ़िकेशन को MQTT इवेंट में बदलना केवल प्रोटोकॉल अनुवाद नहीं है। कनेक्टर को