औद्योगिक डेटा मॉडल क्या है

एक फैक्ट्री बहुत बड़ी मात्रा में डेटा इकट्ठा कर सकती है, फिर भी एक बुनियादी ऑपरेशनल सवाल का जवाब देने में उसे कठिनाई हो सकती है: इस घटना से वास्तव में क्या प्रभावित होता है?

ERP को ग्राहक ऑर्डर, मटेरियल, नियोजित तारीखें और इन्वेंटरी पता होती है। MES को पता होता है कि शॉप फ्लोर पर क्या निष्पादित हो रहा है। PLC और SCADA मशीन की स्थितियों, अलार्म और प्रोसेस मानों को जानते हैं। मेंटेनेंस को एसेट की स्थिति और सर्विस इतिहास पता होता है। क्वालिटी को इंस्पेक्शन और रिलीज़ स्थिति पता होती है। इंजीनियरिंग को प्रोडक्ट की परिभाषा पता होती है। समस्या आमतौर पर डेटा की कमी नहीं होती। समस्या यह है कि ये सिस्टम एक ही फैक्ट्री का वर्णन अलग-अलग नामों, ID, स्थितियों और नियमों के साथ करते हैं।

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

बहुत सारे सिस्टम — साझा अर्थ नहीं
एक आधुनिक प्लांट में लगभग हर महत्वपूर्ण काम के लिए पहले से विशेष सिस्टम होते हैं। ERP मांग और प्रतिबद्धताओं का प्रबंधन करता है। MES निष्पादन का प्रबंधन करता है। PLC उपकरणों को नियंत्रित करते हैं। SCADA मशीन की स्थितियाँ दिखाता है। हिस्टोरियन प्रोसेस डेटा संग्रहीत करते हैं। मेंटेनेंस सिस्टम एसेट और सर्विस कार्य का प्रबंधन करते हैं। क्वालिटी सिस्टम इंस्पेक्शन रिकॉर्ड रखते हैं, और Power BI रिपोर्टिंग के लिए जानकारी को जोड़ सकता है।

हर सिस्टम का अपना कारण है। समस्या तब शुरू होती है जब वही वास्तविक दुनिया की वस्तु हर सिस्टम में अलग-अलग दिखती है। एक मशीन ERP में work center, मेंटेनेंस में asset number, MES में resource, कंट्रोल सिस्टम में OPC UA nodes के समूह और शॉप फ्लोर पर एक बिल्कुल अलग दोस्ताना नाम के रूप में दर्ज हो सकती है।

एक इंडस्ट्रियल मॉडल सभी सिस्टम को एक ही identifier इस्तेमाल करने के लिए मजबूर नहीं करता। इसके बजाय वह रिकॉर्ड करता है कि वे संदर्भ एक ही भौतिक या तार्किक वस्तु से कैसे संबंधित हैं। इससे फैक्ट्री को एक स्थिर पहचान परत मिलती है, बिना उन स्थानीय संरचनाओं को नष्ट किए जिनकी हर स्रोत सिस्टम को ज़रूरत है।

इंडस्ट्रियल डेटा मॉडल वास्तव में क्या है
इंडस्ट्रियल डेटा मॉडल नियमों का एक साझा समूह है जो बताता है कि फैक्ट्री में क्या मायने रखता है और ये चीज़ें एक-दूसरे से कैसे जुड़ती हैं।

यह व्यावहारिक सवालों का जवाब देता है, जैसे प्रोडक्शन ऑर्डर किसे माना जाए, प्रोडक्ट revision क्या दर्शाता है, work center और भौतिक एसेट में क्या अंतर है, मटेरियल कब रिलीज़ होता है, और किसी मशीन का "उपलब्ध" होना वास्तव में क्या अर्थ रखता है।

मॉडल इन बातों का वर्णन कर सकता है:
• ऑब्जेक्ट प्रकार और पहचान
• गुण और स्थितियाँ
• फैक्ट्री ऑब्जेक्ट्स के बीच संबंध
• स्रोत-सिस्टम संदर्भ
• प्रभावी तिथियाँ और versions
• संबंधों से जुड़ी शर्तें
• परिभाषाओं और नियमों का स्वामित्व

इससे कई सिस्टम एक ही उत्पादन स्थिति के अलग-अलग पहलुओं का वर्णन कर सकते हैं, बिना उन्हें किसी भ्रामक एकल स्थिति में समेटे। ERP में कोई ऑर्डर release हो सकता है, जबकि उसका वर्तमान MES operation अब भी blocked हो। कोई मशीन यांत्रिक रूप से स्वस्थ हो सकती है फिर भी अनुपलब्ध हो सकती है क्योंकि आवश्यक फिक्स्चर गायब है। ये सभी तथ्य एक साथ सही हो सकते हैं।

मॉडल डेटा प्लेटफ़ॉर्म नहीं है
Microsoft Fabric, SQL डेटाबेस, हिस्टोरियन, डेटा लेक और अन्य प्लेटफ़ॉर्म जानकारी को संग्रहीत करने, स्थानांतरित करने, शासित करने और विश्लेषण करने के लिए उपयोगी हैं। लेकिन केवल रिकॉर्ड एक साथ रखे होने से कोई भी प्लेटफ़ॉर्म यह तय नहीं कर सकता कि आपकी फैक्ट्री में work center का क्या अर्थ है।

आप ERP ऑर्डर, MES निष्पादन रिकॉर्ड, मेंटेनेंस इवेंट, क्वालिटी परिणाम और मशीन टेलीमेट्री को एक Lakehouse में लोड कर सकते हैं और फिर भी यह उत्तर न दे पाएँ कि कोई विशेष ऑर्डर शिफ्ट समाप्त होने से पहले दूसरी मशीन पर जा सकता है या नहीं।
वह उत्तर संबंधों पर निर्भर करता है।

कौन सा प्रोडक्ट revision शामिल है? कौन सा operation अगला चलना चाहिए? उस operation के लिए कौन से संसाधन स्वीकृत हैं? किन टूलिंग की ज़रूरत है? क्या ऑपरेटर योग्य है? क्या मशीन की वर्तमान स्थिति काम की अनुमति देती है? क्या वैकल्पिक route के साथ कोई इंस्पेक्शन नियम जुड़ा है?
प्लेटफ़ॉर्म उन संबंधों को होस्ट और क्वेरी कर सकता है, लेकिन उन्हें परिभाषित तो फैक्ट्री को ही करना होगा।

टेबल अकेले अक्सर कठिन क्यों हो जाते हैं
रिलेशनल टेबल समस्या नहीं हैं। ERP, MES, मेंटेनेंस और कई मैन्युफैक्चरिंग एप्लिकेशन रिलेशनल मॉडल पर निर्भर करते हैं क्योंकि वे transactions और संरचित रिकॉर्ड के लिए उत्कृष्ट हैं।

कठिनाई तब आती है जब उत्पादन के सवाल कई ऐसे संबंधों को पार करते हैं जो समय के साथ बदलते हैं।
एक प्रोडक्ट revision के लिए कई operations की ज़रूरत हो सकती है। एक operation कई संसाधनों पर स्वीकृत हो सकता है। एक मशीन केवल कुछ प्रोडक्ट families, tooling संयोजनों, आकार सीमाओं या इंस्पेक्शन आवश्यकताओं का समर्थन कर सकती है। ऑपरेटर की योग्यताएँ समाप्त हो सकती हैं। इंजीनियरिंग बदलाव पहले से स्वीकृत route को अमान्य कर सकते हैं।

यह सब टेबल में दर्शाया जा सकता है, लेकिन तर्क अक्सर रिपोर्ट, SQL क्वेरी, स्प्रेडशीट और स्थानीय अपवाद सूचियों में बिखर जाता है। अलग-अलग रिपोर्ट फिर वही फैक्ट्री संबंध अलग-अलग तरीके से दोबारा बनाती हैं।

इंडस्ट्रियल मॉडल एक साझा संबंध परत प्रदान करता है, ताकि नियमों को एक बार परिभाषित, शासित और पुनः उपयोग किया जा सके, न कि हर बार जब कोई कठिन उत्पादन सवाल पूछे तब उन्हें दोबारा खोजा जाए।

PPR — Product, Process, Resource

एक व्यावहारिक शुरुआती संरचना PPR है: Product, Process, Resource।
Product बताता है: हम क्या बना रहे हैं?
Process बताता है: काम किस प्रकार होना चाहिए?
Resource बताता है: वास्तविक उत्पादन परिस्थितियों में उस काम को कौन कर सकता है?

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

प्रोडक्ट केवल part number से अधिक है
एक प्रोडक्ट परिभाषा में प्रोडक्ट परिवार, विशिष्ट variant, revision, bill of material, ग्राहक कॉन्फ़िगरेशन, मटेरियल आवश्यकताएँ, इंस्पेक्शन आवश्यकताएँ और क्वालिटी नियम शामिल हो सकते हैं।
यह इसलिए मायने रखता है क्योंकि एक ही मोटे part number वाले दो रिकॉर्ड आपस में विनिमेय नहीं हो सकते। एक नए revision में सख्त tolerance, अलग प्रोसेस पैरामीटर, एक और इंस्पेक्शन चरण, या उच्च क्षमता वाले उपकरण की आवश्यकता हो सकती है।

PLM जैसे इंजीनियरिंग सिस्टम डिज़ाइन के उद्देश्य के स्वामी हो सकते हैं। ERP मटेरियल मास्टर और planning version रख सकता है। MES उत्पादन परिभाषा रख सकता है। क्वालिटी इंस्पेक्शन प्लान का रखरखाव कर सकती है।
इंडस्ट्रियल मॉडल उन संदर्भों को जोड़ता है ताकि उत्पादन एक कहीं अधिक महत्वपूर्ण सवाल का उत्तर दे सके, न कि केवल "यह कौन सा part number है?"।

वह उत्तर दे सकता है: क्या हम वर्तमान में लागू नियमों के अंतर्गत सही revision बना रहे हैं?

Process बताता है कि काम कैसे होना चाहिए
Process पक्ष उत्पादन के माध्यम से स्वीकृत route का वर्णन करता है। इसमें केवल मशीनों की सूची से अधिक शामिल है।

यह operation sequence, setup आवश्यकताएँ, इंस्पेक्शन बिंदु, प्रतीक्षा समय, rework मार्ग, स्वीकृतियाँ, handoffs और वे शर्तें बता सकता है जो काम जारी रहने से पहले पूरी होनी चाहिए।
नियोजित process परिभाषा बताती है कि काम कैसे होना चाहिए। MES निष्पादन डेटा दर्ज करता है कि किसी विशिष्ट ऑर्डर के लिए वास्तव में क्या हुआ।
दोनों मायने रखते हैं।

नियोजित process के बिना आप यह तय नहीं कर सकते कि निष्पादन स्वीकृत route का पालन करता था या नहीं। निष्पादन इतिहास के बिना आप यह नहीं सीख सकते कि उत्पादन के दौरान वास्तव में क्या हुआ।

Resource का अर्थ क्षमता है — केवल मशीन नहीं
एक उत्पादन संसाधन मशीन, लाइन, workstation, टूल, फिक्स्चर, ऑपरेटर, टेस्ट रिग, परिवहन प्रणाली या काम करने के लिए आवश्यक कोई अन्य क्षमता हो सकता है।
यह अंतर महत्वपूर्ण है क्योंकि कोई मशीन तकनीकी रूप से उपलब्ध हो सकती है, फिर भी operation असंभव बना रह सकता है।

आवश्यक फिक्स्चर कहीं और उपयोग में हो सकता है। किसी टूल का calibration समाप्त हो सकता है। एकमात्र योग्य ऑपरेटर वर्तमान शिफ्ट में उपस्थित न हो। कोई मशीन प्रोडक्ट परिवार का समर्थन करती हो लेकिन वर्तमान revi