छोटा जवाब: बेवरेज प्लांट में सबसे काम का एजेंट कोई रोबोट ऑपरेटर नहीं है। वह एक धैर्यवान एनालिस्ट है जो हर शिफ़्ट के आख़िर में स्टॉप लॉग पढ़ता है, OEE नुकसानों को क्रम में रखता है, देखता है कि लेबलर के ग्लू यूनिट ने इस हफ़्ते छह बार लाइन रोकी, मेंटेनेंस सिस्टम जाँचता है, कोई खुला वर्क ऑर्डर नहीं पाता और सबूत के साथ एक मसौदा बनाता है जिसे प्लानर मंज़ूर करे। यही एजेंट ऐसा चेंजओवर क्रम भी बना सकता है जो फ़्लश का समय घटाए। इसे सुरक्षित मॉडल नहीं, आर्किटेक्चर बनाता है: Purdue मॉडल की IT वाली तरफ़ रेप्लिकेट किए OT डेटा तक सिर्फ़ पढ़ने की पहुँच, PLC या SCADA तक कोई रास्ता नहीं, लिखने वाले टूल जो सिर्फ़ मसौदे बनाते हैं, हर टूल कॉल का ऑडिट लॉग, और लाइव होने से पहले रीप्ले टेस्ट।
हर प्लांट में नुकसानों की एक सूची होती है जिनके बारे में सब जानते हैं और जिनके पीछे जाने का समय किसी के पास नहीं। वह लेबलर जो एक शिफ़्ट में दर्जन भर बार तीस सेकंड के लिए रुकता है। वह चेंजओवर जो हमेशा बीस मिनट ज़्यादा खिंचता है। वह पंप जो बाहर का तापमान 35 डिग्री पार करते ही ट्रिप हो जाता है। हर एक छोटा है। मिलकर वे अक्सर OEE वॉटरफ़ॉल का सबसे बड़ा बार होते हैं।
इस सीरीज़ की तीसरी पोस्ट ने बताया था कि एजेंट कैसे काम करते हैं। यह सातवीं पोस्ट एक एजेंट को इन नुकसानों पर काम पर लगाती है, और कम से कम उतना ही समय उसके चारों ओर की बाड़ पर लगाती है।
OEE लॉस एजेंट, कदम दर कदम
हर शिफ़्ट के आख़िर में एक ठीक से दायरे में बँधा एजेंट यह करता है। हर कदम किसी टेस्ट की हुई क्वेरी या नियंत्रित सिस्टम को एक टूल कॉल है।
- नुकसानों को क्रम में रखो। MES प्रतिलिपि से शिफ़्ट के स्टॉप निकालो और उन्हें छह बड़े नुकसानों और एसेट के हिसाब से समूहों में रखो। लेबलर का ग्लू यूनिट छह स्टॉप में 31 मिनट का है।
- दोहराव जाँचो। पिछले दो हफ़्ते देखो। वही फ़ॉल्ट कोड 23 बार आया है, और बढ़ रहा है।
- एसेट देखो। CMMS पर क्वेरी: ग्लू यूनिट का आख़िरी वर्क ऑर्डर चार हफ़्ते पहले बंद हुआ था, ‘नोज़ल साफ़ किए’। अभी कोई खुला ऑर्डर नहीं।
- संकेत देखो। हर स्टॉप के आस-पास हिस्टोरियन प्रतिलिपि से ग्लू तापमान का टैग निकालो। ज़्यादातर स्टॉप से ठीक पहले यह अपने सेटपॉइंट बैंड से नीचे गिरता है।
- काम का मसौदा बनाओ। CMMS में एक मसौदा वर्क ऑर्डर बनाओ: एसेट, लक्षण, 23 स्टॉप, चार्ट लिंक के साथ तापमान का पैटर्न, पिछला वर्क ऑर्डर, सुझाई गई प्राथमिकता। स्थिति: मसौदा, प्लानर का इंतज़ार।
- रिपोर्ट करो। शिफ़्ट हैंडओवर में एक लाइन जोड़ो: ‘L2 लेबलर ग्लू यूनिट के लिए मसौदा WO बनाया, बार-बार तापमान गिरना, लिंक देखें।’
अगली सुबह एक प्लानर मसौदे की समीक्षा करता है, प्राथमिकता ठीक करता है और उसे जारी करता है। एजेंट ने दो मिनट में वह किया जिसमें एक इंजीनियर का एक घंटा लगता, और उसने यह हर शिफ़्ट में किया, सिर्फ़ तब नहीं जब किसी के पास समय था।
चेंजओवर प्लान, मसौदे के रूप में, शेड्यूल नहीं
यही ढाँचा चेंजओवर के लिए भी काम करता है, छह बड़े नुकसानों में दूसरा। ERP से हफ़्ते का प्रोडक्शन प्लान और प्रोडक्ट और फ़ॉर्मेट के बीच के ज्ञात चेंजओवर समय मिलने पर एजेंट ऐसा रन क्रम बना सकता है जो फ़्लश और फ़ॉर्मेट बदलाव घटाए। पेल के बाद डार्क बीयर, डार्क के बाद पेल नहीं। 330 ml के रन एक साथ रखो। वह यह भी चिह्नित कर सकता है कि प्लान कहाँ ऐसा चेंजओवर थोपता है जिससे बचा जा सकता था।
वह मसौदा प्लानर को सौंपता है, जो वे बातें जानता है जो एजेंट नहीं जानता: वह कस्टमर ऑर्डर जिसे गुरुवार को जाना ही है, वह ऑपरेटर जो छुट्टी पर है, वह टैंक जो तैयार नहीं होगा। प्लानर एडिट करके प्रकाशित करता है। एजेंट कभी लाइव शेड्यूल को नहीं छूता।
गार्डरेल 1: Purdue मॉडल
ज़्यादातर बेवरेज प्लांट अपने नेटवर्क Purdue मॉडल की तर्ज़ पर बनाते हैं, और IEC 62443 जैसे OT सुरक्षा स्टैंडर्ड इसी अलगाव पर टिके हैं। सबसे नीचे स्तर 0 से 2 में प्रोसेस, PLC, SCADA और HMI हैं। स्तर 3 में साइट ऑपरेशंस हैं: हिस्टोरियन, MES, CMMS, LIMS। स्तर 4 और 5 एंटरप्राइज़ IT हैं। ऑपरेशंस और IT के बीच एक डीमिलिटराइज़्ड ज़ोन, यानी DMZ, होता है, जहाँ कंट्रोल नेटवर्क खोले बिना डेटा साझा किया जा सकता है।
एजेंट की जगह IT वाली तरफ़ है। वह DMZ में प्रकाशित हिस्टोरियन और MES डेटा की प्रतिलिपि पढ़ता है। वह कभी नीचे स्तर 0 से 2 तक कनेक्शन नहीं खोलता। अगर आपके आर्किटेक्चर में उसे ऐसा करना पड़े, तो आर्किटेक्चर एजेंट के लिए तैयार नहीं है।
गार्डरेल 2: प्रोसेस कंट्रोल में कोई लिखाई नहीं
यह अपनी अलग लाइन का हकदार है। एजेंट का कोई भी काम PLC, SCADA वैल्यू या प्रोसेस सेटपॉइंट को नहीं बदलना चाहिए। न किसी टूल से, न किसी स्क्रिप्ट से, न ‘बस इस एक कम जोखिम वाले पैरामीटर के लिए’। प्रोसेस कंट्रोल अच्छी वजहों से इंजीनियर, वैलिडेट और इंटरलॉक किया जाता है, और 98 प्रतिशत समय सही रहने वाला लैंग्वेज मॉडल ऐसे लूप में मंज़ूर नहीं जहाँ बाकी 2 प्रतिशत एक कॉस्टिक लाइन या प्रेशराइज़्ड वेसल है।
इसे लागू करने का सबसे सरल तरीका है वह टूल कभी बनाना ही नहीं। अगर एजेंट की पहुँच वाले किसी भी MCP सर्वर पर कोई set_value फ़ंक्शन नहीं है, और उसके सर्विस अकाउंट के पास OT के आस-पास कहीं भी लिखने के अधिकार नहीं हैं, तो यह सवाल उठता ही नहीं।
गार्डरेल 3 से 8: मसौदे, मंज़ूरियाँ, लॉग, evals, सीमाएँ, बंद करने का स्विच
- लिखने वाले टूल सिर्फ़ मसौदे बनाते हैं। CMMS टूल मसौदा स्थिति में वर्क ऑर्डर बना सकता है। वह उसे जारी, बंद या जारी हो चुके को बदल नहीं सकता।
- हर मसौदा इंसान मंज़ूर करता है। सबूत दिखाकर, सिर्फ़ निष्कर्ष नहीं। एडिट और रिजेक्शन दर ट्रैक कीजिए, क्योंकि शून्य दर का मतलब आमतौर पर यह होता है कि कोई पढ़ ही नहीं रहा।
- हर टूल कॉल का ऑडिट लॉग। कौन-सा टूल, कौन-से इनपुट, क्या लौटा, एजेंट ने क्या मसौदा बनाया। जब कोई पूछे कि कोई वर्क ऑर्डर क्यों है, तो जवाब लॉग में है।
- लाइव होने से पहले रीप्ले evals। एजेंट को पिछले एक या दो महीने की शिफ़्टों पर चलाइए, डेटा उसी रूप में जैसा उस समय था, और उसके मसौदों की तुलना इससे कीजिए कि प्लानरों और इंजीनियरों ने असल में क्या किया। गिनिए कि उसने कितने असली मुद्दे पकड़े, कितना शोर उठाया और कितने मसौदे गलत होते। जब भी मॉडल, प्रॉम्प्ट या टूल बदलें, दोहराइए।
- कदम, लागत और दर की सीमाएँ। हर रन में टूल कॉल और हर शिफ़्ट में मसौदों की एक ऊपरी सीमा, ताकि उलझा हुआ एजेंट CMMS को भर न दे।
- एक स्विच से बंद। ऑपरेशंस में कोई, सिर्फ़ IT में नहीं, एजेंट को तुरंत रोक सकता है।
पोस्ट 3 की ऑटोनॉमी सीढ़ी पर यह एजेंट L2 पर है: वह खुलकर पढ़ता है और मसौदे बनाता है, और इंसान मंज़ूर करता है। उसे वहीं रहना चाहिए।
यह कहाँ टूटता है
एजेंट डेटा की हर समस्या विरासत में पाता है। अगर स्टॉप कोड अस्पष्ट हैं, तो क्रम भी अस्पष्ट होगा। अगर CMMS की एसेट हायरार्की MES से मेल नहीं खाती, तो एजेंट किसी स्टॉप को वर्क ऑर्डर से नहीं जोड़ सकता। इन्हें पहले ठीक कीजिए। ये किसी भी मॉडल से सस्ते हैं।
बहुत ज़्यादा मसौदे भरोसा ख़त्म कर देते हैं। हर शिफ़्ट में पंद्रह मसौदे बनाने वाला एजेंट एक हफ़्ते में अनदेखा किया जाने लगेगा। एक तरह के नुकसान और एक लाइन से शुरू कीजिए, और कवरेज से ज़्यादा सटीकता के लिए ट्यून कीजिए।
प्लांट के टेक्स्ट से प्रॉम्प्ट इंजेक्शन। एजेंट ऑपरेटर नोट्स और पुराने वर्क ऑर्डर पढ़ता है। उस सबको डेटा मानिए, कभी निर्देश नहीं, और हर लिखने वाले टूल को मंज़ूरी के पीछे रखिए ताकि कोई अजीब नोट किसी काम में न बदल सके।
प्रतिलिपि में देरी। अगर DMZ प्रतिलिपि घंटों पीछे चलती है, तो एजेंट बासी डेटा पर काम करता है। हर मसौदे पर डेटा का टाइमस्टैम्प दिखाइए।
मंज़ूरी की थकान। शिफ़्ट के आख़िर में चालीस बार approve क्लिक करना निगरानी नहीं है। मात्रा कम और सबूत साफ़ रखिए।
निचोड़
प्लांट का अच्छा एजेंट एक एनालिस्ट है, ऑपरेटर नहीं। वह हर शिफ़्ट में नुकसान पढ़ता है, स्टॉप लॉग, हिस्टोरियन और मेंटेनेंस इतिहास को जोड़ता है, और वह वर्क ऑर्डर या चेंजओवर प्लान बनाता है जिस तक व्यस्त इंजीनियर कभी पहुँच नहीं पाता। वह सुरक्षित है क्योंकि वह कहाँ बैठा है और क्या छू सकता है: Purdue मॉडल की IT वाली तरफ़, सिर्फ़ पढ़ने लायक OT डेटा, सिर्फ़ मसौदे बनाने वाले टूल, मंज़ूरी देता इंसान, हर कॉल लॉग में, इतिहास दोबारा चलाकर परखा हुआ। मॉडल कभी-कभी गलत होगा। आर्किटेक्चर पक्का करता है कि गलत होने की कीमत एक रिजेक्ट हुआ मसौदा हो, कोई बैच नहीं।
अगली, और आख़िरी: रोडमैप और यह कहाँ टूटता है। लाइन डाउनटाइम के प्रेडिक्टिव पहलू के लिए देखिए Predicting Packaging Line Downtime and Lifting OEE। पूरी सूची सीरीज़ पेज पर है।
अक्सर पूछे जाने वाले सवाल
बेवरेज प्लांट में AI एजेंट सुरक्षित रूप से क्या कर सकता है? प्रोडक्शन, मेंटेनेंस और क्वालिटी डेटा पढ़ना, यह निकालना कि कौन-से नुकसान मायने रखते हैं, और लोगों के लिए कामों का मसौदा बनाना: मेंटेनेंस वर्क ऑर्डर, चेंजओवर प्लान, शिफ़्ट सार, प्लानर को संदेश। हर मसौदा अपने सबूत के साथ आता है और मंज़ूरी का इंतज़ार करता है। उसके पास PLC, SCADA या प्रोसेस सेटपॉइंट में लिखने का कोई रास्ता नहीं होना चाहिए।
Purdue मॉडल क्या है और AI एजेंटों के लिए यह क्यों मायने रखता है? Purdue मॉडल एक रेफ़रेंस आर्किटेक्चर है जो प्लांट के नेटवर्क को स्तरों में बाँटता है, नीचे भौतिक प्रोसेस और उसके कंट्रोलर से लेकर ऊपर बिज़नेस सिस्टम तक, और ऑपरेशंस और एंटरप्राइज़ IT के बीच एक डीमिलिटराइज़्ड ज़ोन होता है। एजेंट की जगह IT वाली तरफ़ है, जहाँ वह DMZ से रेप्लिकेट किया डेटा पढ़ता है। उसे कभी नीचे कंट्रोल स्तरों तक कनेक्शन नहीं खोलना चाहिए।
प्लांट पर छोड़ने से पहले AI एजेंट को कैसे परखें? इतिहास को दोबारा चलाइए। एजेंट को पिछले एक-दो महीने की शिफ़्टों पर चलाइए, डेटा उसी रूप में जैसा उस समय था, और उसके मसौदों की तुलना इससे कीजिए कि प्लानरों और इंजीनियरों ने असल में क्या किया। मापिए कि उसने कितने असली मुद्दे पकड़े, कितने मसौदे शोर थे, और कितने गलत होते। जब भी मॉडल, प्रॉम्प्ट या टूल बदलें, रीप्ले दोहराइए।