कनेक्टिविटी का अर्थ इंटीग्रेशन नहीं है — आपकी कनेक्टेड फैक्ट्री अब भी सही सवालों के जवाब क्यों नहीं दे पाती

एक कनेक्टेड फ़ैक्टरी मशीन के सिग्नल मिलीसेकंड में पहुँचा सकती है, फिर भी वह उन परिचालन सवालों का जवाब नहीं दे पाती जो सचमुच मायने रखते हैं। एक पैकेजिंग मशीन रुकती है, PLC खराबी की रिपोर्ट करता है, OPC UA उस घटना को उजागर करता है, MQTT उसे वितरित करता है, और डैशबोर्ड तुरंत अपडेट हो जाता है। मेंटेनेंस टीम को अलर्ट मिलता है और सब कुछ जुड़ा हुआ दिखता है। फिर प्लानर पूछता है कि अब कौन सा ग्राहक शिपमेंट जोखिम में है, और अचानक इस सवाल का जवाब MES डेटा, ERP रिकॉर्ड, मेंटेनेंस इतिहास, गुणवत्ता स्थिति, उत्पादन मात्रा, डिलीवरी प्रतिबद्धताओं और अक्सर एक स्प्रेडशीट में मिलता है। इस episode का केंद्र यही अंतर है: कनेक्टिविटी सिग्नल को आगे पहुँचाती है, जबकि इंटीग्रेशन अर्थ, बाधाओं, स्वामित्व, समय और परिणामों को आपस में जोड़ता है।

कनेक्टिविटी सिग्नल पहुँचाती है — इंटीग्रेशन अर्थ को जोड़ता है
OPC UA, MQTT, edge gateways, brokers और आधुनिक औद्योगिक कनेक्टिविटी प्लेटफ़ॉर्म महत्वपूर्ण समस्याएँ हल करते हैं। वे मशीन डेटा को सुलभ बनाते हैं, ट्रांसपोर्ट को मानकीकृत करते हैं, point-to-point कनेक्शनों को कम करते हैं और मशीनों, एप्लिकेशनों व क्लाउड सेवाओं के बीच इवेंट्स के आवागमन को संभव बनाते हैं। लेकिन किसी अलार्म को ट्रांसपोर्ट करने से उसका व्यावसायिक परिणाम स्पष्ट नहीं होता। एक fault code बिल्कुल सही पहुँच सकता है, सही timestamp रख सकता है और कुछ ही सेकंड में हर subscriber तक पहुँच सकता है। फिर भी प्लानर को यह नहीं पता चलता कि रुकी हुई मशीन किसी तात्कालिक ऑर्डर को प्रभावित करती है या नहीं, क्या स्वीकृत इन्वेंटरी पहले से मौजूद है, क्या वर्तमान आउटपुट quality hold पर है, या कोई दूसरा संसाधन उसकी जगह ले सकता है। इन सवालों के जवाब के लिए आर्किटेक्चर को मशीन, सक्रिय ऑपरेशन, वर्क ऑर्डर, उत्पाद, सामग्री की स्थिति, गुणवत्ता की स्थिति, मेंटेनेंस जानकारी और ग्राहक की माँग के बीच संबंधों की ज़रूरत होती है।

एक अलार्म, कई सिस्टम, कोई पूरा जवाब नहीं
यह episode एक पैकेजिंग मशीन के अलार्म को उन सिस्टमों के माध्यम से ट्रेस करता है जिनमें आम तौर पर उत्पादन की कहानी के अलग-अलग हिस्से रखे जाते हैं। PLC को पता है कि मशीन पर क्या हुआ। MES समझता है कि कौन सा ऑपरेशन और वर्क ऑर्डर सक्रिय है। ERP को माँग, due dates, इन्वेंटरी और ग्राहक प्रतिबद्धताओं की जानकारी है। मेंटेनेंस सेवा इतिहास और बकाया कार्य जानता है। Quality तय करती है कि तैयार आउटपुट वास्तव में release किया जा सकता है या नहीं। हर सिस्टम अपने स्तर पर सही हो सकता है, फिर भी पूरी फ़ैक्टरी के रूप में वह परिचालन सवाल का जवाब नहीं दे पाती। यहीं इंसान इंटीग्रेशन की परत बन जाता है: कोई MES देखता है, कोई ERP खोलता है, मेंटेनेंस सेवा इतिहास खोजता है, quality release की स्थिति जाँचती है, और अंत में कोई व्यक्ति सारी जानकारी हाथ से जोड़ता है। यह तरीका तब तक चलता है जब तक निर्णय तेज़ी से नहीं लेने होते, सिस्टम नहीं बदलते, या वह व्यक्ति उपलब्ध न हो जो सभी छिपी हुई mappings को समझता है।

Unified Namespace: बेहतर हाईवे, फ़ैक्टरी का नक्शा नहीं
Unified Namespace कई सीधे system-to-system कनेक्शनों को एक साझा publish-and-subscribe वातावरण से बदलकर इस स्थिति को काफ़ी सुधार सकता है। मशीनें और एप्लिकेशन जानकारी एक बार publish करते हैं, उपभोक्ता अपनी ज़रूरत की जानकारी subscribe करते हैं, और नए सिस्टम उपकरण से बिना एक और कस्टम कनेक्शन बनाए जुड़ सकते हैं। इससे plumbing कम होती है, लेकिन संदर्भ (context) अपने आप नहीं बनता। MQTT topic संरचना बता सकती है कि जानकारी कहाँ से आई, पर यह तय नहीं कर सकती कि कौन सा production order सक्रिय था, कौन सी सामग्री शामिल थी, कौन सी quality स्थिति लागू थी, या कौन सी ग्राहक डिलीवरी उस ऑर्डर पर निर्भर है। MES, ERP, quality और मशीन के इवेंट्स को एक ही broker में publish करने से उनके बीच के संबंध अपने आप नहीं बनते। वे संबंध अब भी मॉडल किए जाने चाहिए और उनका प्रबंधन (governance) होना चाहिए।

टैग नामकरण का जाल
अच्छे नामकरण नियम लोगों को डेटा खोजने में मदद करते हैं, लेकिन नाम पहचान नहीं होते। एक सिस्टम मशीन को Packer7 कह सकता है, मेंटेनेंस PK07 इस्तेमाल कर सकता है, ERP का production-resource कोड कुछ और हो सकता है, और क्लाउड प्लेटफ़ॉर्म उसी उपकरण को device identity से जानता हो। ये सभी रिकॉर्ड एक ही भौतिक एसेट को दर्शा सकते हैं। शासित (governed) पहचान के बिना संगठन धीरे-धीरे mapping tables, कस्टम scripts, रिपोर्ट-विशिष्ट अनुवाद और अप्रलेखित धारणाएँ बना लेते हैं। फिर मशीन स्थानांतरित होती है, दोबारा बनती है, उसका नाम बदलता है या उसे नया controller मिलता है, और डेटा प्रवाह चलता रहता है जबकि संबंध चुपचाप गलत हो जाते हैं। मानव-पठनीय नाम लोगों के लिए उपयोगी हैं, पर समय के साथ सिस्टमों को जोड़े रखने वाली चीज़ स्थिर पहचान है।

ERP और MES के काम अलग हैं
ERP और MES आपस में संबंधित हैं, पर उन्हें एक ही सिस्टम नहीं माना जाना चाहिए। ERP व्यावसायिक और योजना स्तर पर काम करता है, जिसमें माँग, आपूर्ति, इन्वेंटरी, ग्राहक प्रतिबद्धताएँ, production orders और वित्तीय परिणाम शामिल हैं। MES निष्पादन के करीब काम करता है, जिसमें ऑपरेशन, उत्पादन संसाधन, ऑपरेटर, downtime, मात्रा, सामग्री की खपत और फ़र्श पर कार्य की वास्तविक प्रगति शामिल है। जब ये ज़िम्मेदारियाँ स्पष्ट रहती हैं और सिस्टम जानबूझकर आपस में जोड़े जाते हैं, बजाय इसके कि एक प्लेटफ़ॉर्म पर सब कुछ थोपा जाए, तब आर्किटेक्चर अधिक भरोसेमंद बनता है। मशीन रिपोर्ट कर सकती है कि उत्पादन पूरा हो गया है, जबकि quality ने आउटपुट को अभी भी hold पर रखा है। MES किसी ऑपरेशन को पूरा दिखा सकता है, जबकि ERP ने अभी finished goods receipt post नहीं किया है। ये सभी स्थितियाँ मान्य हो सकती हैं, क्योंकि वे एक ही उत्पादन प्रक्रिया के अलग-अलग क्षणों का वर्णन करती हैं।

डेटा सिग्नल है — संदर्भ आसपास की फ़ैक्टरी है
तापमान का मान डेटा है। संदर्भ बताता है कि किस sensor ने उसे उत्पन्न किया, कौन सी मशीन में वह sensor है, कौन सा उत्पाद चल रहा था, कौन सी recipe लागू थी, कौन सी इकाई इस्तेमाल हुई, क्या sensor कैलिब्रेटेड था, और उस उत्पादन रन के लिए कौन सी परिचालन सीमा स्वीकार्य थी। यही बात मशीन-डाउन इवेंट पर लागू होती है। सिग्नल बताता है कि कुछ रुक गया है। संदर्भ बताता है कि कौन सा ऑपरेशन प्रभावित हुआ, कौन सा ऑर्डर चल रहा था, कौन सी सामग्री इस्तेमाल हो रही थी, क्या बना हुआ आउटपुट वास्तव में उपलब्ध है, क्या कोई दूसरा संसाधन उसका स्थान ले सकता है, और कौन सी ग्राहक प्रतिबद्धता अब जोखिम में हो सकती है। उपयोगी औद्योगिक संदर्भ में आम तौर पर ये शामिल होते हैं: • एसेट संदर्भ — भौतिक चीज़ क्या है और वह कहाँ स्थित है • प्रक्रिया संदर्भ — संसाधन वास्तव में क्या कर सकता है • ऑर्डर संदर्भ — कौन सा कार्य अभी चल रहा है • सामग्री संदर्भ — कौन से lots और components शामिल हैं • गुणवत्ता संदर्भ — आउटपुट released, restricted या held है या नहीं • समय संदर्भ — इवेंट होने के समय कौन से संबंध मान्य थे एक बार ये संबंध मौजूद हो जाएँ, तो वही मशीन इवेंट योजना और निर्णय लेने के लिए कहीं अधिक उपयोगी बन जाता है।

Schema, ontology और graph अलग-अलग चीज़ें हैं
Schema किसी रिकॉर्ड का आकार परिभाषित करता है। वह asset ID, event timestamp, fault code, work-order ID या engineering unit जैसे fields को अनिवार्य कर सकता है। Ontology पूरी फ़ैक्टरी में इस्तेमाल होने वाली अवधारणाओं और संबंधों का साझा अर्थ परिभाषित करता है। Graph इन जुड़ी हुई इकाइयों को संग्रहीत और query करने का व्यावहारिक तरीका देता है। उदाहरण के लिए, एक मशीन production line से संबंधित हो सकती है, एक sensor किसी component को measure कर सकता है, एक operation किसी work order का हिस्सा हो सकता है, एक material lot उस operation के दौरान खपत हो सकता है, और तैयार आउटपुट की quality स्थिति हो सकती है। Graph इन संबंधों को आसानी से traverse करने देता है, लेकिन केवल graph database चुन लेने से सार्थक संबंध नहीं बनते। उनकी गुणवत्ता मॉडल, स्वामित्व, समय, पहचान और उन लिंक्स के आसपास के governance से आती है।

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