మెషిన్ డేటా 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 इवेंट में बदलना केवल प्रोटोकॉल अनुवाद से अधिक है। कनेक्टर को