മെഷീൻ ഡാറ്റ 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 एक अनुबंध है — केवल टॉपिक ट्री नहीं

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

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

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

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

OPC UA नोटिफिकेशन से MQTT इवेंट तक

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