ਮਸ਼ੀਨ ਡੇਟਾ 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 सीमा को नियंत्रित रखें
मशीन कनेक्टिविटी को उत्पादन नेटवर्क को कॉर्पोरेट या क्लाउड वातावरण का विस्तार नहीं बनाना चाहिए। औद्योगिक नेटवर्कों को नियंत्रित सीमाओं की आवश्यकता होती है, आमतौर पर विभाजन (segmentation) और एक औद्योगिक DMZ सहित, ताकि स्वीकृत एज सिस्टम उपकरणों से संवाद कर सकें बिना एंटरप्राइज़ एप्लिकेशन को नियंत्रकों तक सीधी पहुँच दिए।

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

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

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

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

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

एक अच्छा यूनिफ़ाइड नेमस्पेस संपत्तियों की पहचान का एक स्थिर तरीका और शासित परिचालन इवेंट प्रकाशित करने का तरीका प्रदान कर सकता है, साथ ही स्रोत प्रणालियों को अपने रिकॉर्ड का स्वामित्व रखने देता है।

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

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

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