थोडक्यात उत्तर: beverage plant मधील सर्वात उपयुक्त agent हा robot operator नसतो. तो एक संयमी analyst असतो जो प्रत्येक shift च्या शेवटी stop log वाचतो, OEE losses ची क्रमवारी लावतो, labeller चे glue unit या आठवड्यात सहा वेळा line थांबवून गेले आहे हे लक्षात घेतो, maintenance system तपासतो, कोणताही उघडा work order नाही हे पाहतो आणि planner ने मंजूर करावा म्हणून पुराव्यासह एक work order चा मसुदा बनवतो. हाच agent flush time कमी करणाऱ्या changeover क्रमाचाही मसुदा बनवू शकतो. त्याला सुरक्षित बनवतो तो model नव्हे, तर architecture: Purdue model च्या IT बाजूला replicated OT data ला read-only प्रवेश, PLCs किंवा SCADA कडे कोणताही मार्ग नाही, फक्त मसुदे तयार करणारी write tools, प्रत्येक tool call चा audit log, आणि live होण्याआधी replay चाचण्या.

AGENT कुठे राहतो, आणि तो कुठपर्यंत पोहोचू शकतो स्तर 4-5 · ENTERPRISE IT OEE loss agent DMZ read-only replica: historian tags, MES stops स्तर 3 · SITE OPERATIONS historian · MES · CMMS · LIMS स्तर 0-2 · PROCESS आणि CONTROL sensors · PLCs · SCADA · HMIs वाचतो फक्त मसुदे CMMS मसुदा control मध्ये write चा मार्ग नाही GUARDRAILS 1. OT data फक्त read-only, DMZ मार्गे 2. PLC किंवा SCADA मध्ये कधीही write नाही 3. write tools फक्त मसुदे बनवतात 4. प्रत्येक मसुदा माणूस मंजूर करतो 5. प्रत्येक tool call चा audit log 6. go-live आधी replay evals 7. step, cost आणि rate मर्यादा 8. एका switch ने बंद होतो MODEL चुकू शकतो · ती चूक स्वस्त राहील याची खात्री ARCHITECTURE करते
Agent business systems सोबत बसतो, plant data ची replica वाचतो आणि फक्त मसुदे तयार करू शकतो. Process control त्याच्या आवाक्याबाहेर आहे, आणि ते जाणूनबुजून तसे रचलेले आहे.

प्रत्येक plant मध्ये अशा losses ची एक यादी असते जी सगळ्यांना माहीत असते आणि जिच्या मागे लागायला कुणालाच वेळ नसतो. एका shift मध्ये डझनभर वेळा तीस सेकंदांसाठी थांबणारा labeller. नेहमी वीस मिनिटे जास्त चालणारा changeover. बाहेरचे तापमान 35 अंशांच्या पुढे गेले की trip होणारा pump. प्रत्येक loss लहान असतो. पण एकत्र पाहिले तर OEE waterfall वरचा सर्वात मोठा खांब बहुतेक वेळा तोच असतो.

या मालिकेतील तिसऱ्या लेखात agents कसे काम करतात ते समजावले होते. हा सातवा लेख एका agent ला याच losses वर कामाला लावतो, आणि त्याच्या भोवतीच्या कुंपणांवर किमान तेवढाच वेळ घालवतो.

OEE loss agent, टप्प्याटप्प्याने

नीट मर्यादा आखलेला agent प्रत्येक shift च्या शेवटी काय करतो ते असे. प्रत्येक टप्पा म्हणजे एखाद्या चाचणी केलेल्या query ला किंवा नियंत्रित system ला केलेला tool call.

  1. Losses ची क्रमवारी. MES replica मधून shift चे stops काढा आणि ते six big losses नुसार आणि asset नुसार गटात लावा. Labeller चे glue unit सहा stops मध्ये मिळून 31 मिनिटांसाठी जबाबदार आहे.
  2. पुनरावृत्ती तपासा. गेल्या दोन आठवड्यांकडे मागे वळून पाहा. तोच fault code 23 वेळा आला आहे, आणि वाढतो आहे.
  3. Asset पाहा. CMMS ला query करा: glue unit वरचा शेवटचा work order चार आठवड्यांपूर्वी बंद झाला, “cleaned nozzles”. आत्ता कोणताही उघडा order नाही.
  4. Signals पाहा. प्रत्येक stop च्या आसपास historian replica मधून glue temperature tag काढा. बहुतेक stops च्या अगदी आधी ते त्याच्या setpoint band च्या खाली घसरते.
  5. कृतीचा मसुदा. CMMS मध्ये work order चा मसुदा तयार करा: asset, लक्षण, ते 23 stops, chart link सह temperature pattern, आधीचा work order, सुचवलेली priority. Status: draft, planner च्या प्रतीक्षेत.
  6. अहवाल. Shift handover मध्ये एक ओळ जोडा: “L2 labeller glue unit साठी draft WO तयार, temperature वारंवार घसरते, link पाहा.”

Planner दुसऱ्या दिवशी सकाळी मसुदा पाहतो, priority बदलतो आणि तो release करतो. ज्या कामाला engineer ला एक तास लागला असता ते agent ने दोन मिनिटांत केले, आणि फक्त कुणाला वेळ मिळेल तेव्हा नव्हे, तर प्रत्येक shift मध्ये केले.

Changeover plans: मसुदा, schedule नव्हे

हाच pattern changeovers साठीही चालतो, जे six big losses पैकी दुसरे आहेत. ERP मधील आठवड्याचा production plan आणि products व formats मधील ज्ञात changeover वेळा दिल्या, तर agent असा run क्रम सुचवू शकतो ज्यात flushes आणि format बदल कमी होतील. फिकट बिअर नंतर गडद, गडद नंतर फिकट नव्हे. 330 ml चे runs एकत्र लावा. Plan मुळे टाळता येण्याजोगा changeover करावा लागत असेल तर तेही तो दाखवू शकतो.

तो मसुदा planner कडे देतो, ज्याला agent ला माहीत नसलेल्या गोष्टी माहीत असतात: गुरुवारी पाठवायलाच हवी अशी customer order, रजेवर असलेला operator, वेळेत तयार न होणारी tank. Planner बदल करतो आणि प्रसिद्ध करतो. Agent live schedule ला कधीच हात लावत नाही.

Guardrail 1: Purdue model

बहुतेक beverage plants आपले networks Purdue model च्या धर्तीवर आखतात, आणि IEC 62443 सारखी OT security standards याच विभागणीवर उभी आहेत. तळाशी, स्तर 0 ते 2 मध्ये process, PLCs, SCADA आणि HMIs असतात. स्तर 3 मध्ये site operations: historian, MES, CMMS, LIMS. स्तर 4 आणि 5 म्हणजे enterprise IT. Operations आणि IT यांच्यामध्ये एक demilitarised zone, म्हणजे DMZ, असते, जिथे control network उघडे न करता data शेअर करता येतो.

Agent ची जागा IT बाजूला आहे. तो DMZ मध्ये प्रसिद्ध केलेल्या historian आणि MES data ची replica वाचतो. तो स्तर 0 ते 2 मध्ये खाली कधीही connection उघडत नाही. तुमच्या architecture मध्ये तसे करावे लागणार असेल, तर ती architecture अजून agent साठी तयार नाही.

Guardrail 2: process control मध्ये कोणतेही write नाही

हा मुद्दा स्वतंत्र ओळीचा हक्कदार आहे. Agent जे काही करेल त्याने PLC, SCADA value किंवा process setpoint बदलता कामा नये. Tool मधून नाही, script मधून नाही, “फक्त या एका कमी जोखमीच्या parameter साठी” असेही नाही. Process control चांगल्या कारणांसाठी engineer, validate आणि interlock केलेले असते, आणि 98 टक्के वेळा बरोबर असणारे language model अशा loop मध्ये स्वीकारार्ह नाही जिथे उरलेले 2 टक्के म्हणजे caustic line किंवा दाबाखालील vessel असते.

हे लागू करण्याचा सर्वात सोपा मार्ग म्हणजे ते tool कधी बनवायचेच नाही. Agent पोहोचू शकेल अशा कोणत्याही MCP server वर set_value function नसेल, आणि त्याच्या service account ला OT च्या आसपास कुठेही write हक्क नसतील, तर हा प्रश्नच उद्भवत नाही.

Guardrails 3 ते 8: मसुदे, मंजुरी, logs, evals, मर्यादा, off switch

  • Write tools फक्त मसुदे तयार करतात. CMMS tool draft status मध्ये work order तयार करू शकते. ते तो release करू शकत नाही, बंद करू शकत नाही किंवा release झालेला order बदलू शकत नाही.
  • प्रत्येक मसुदा माणूस मंजूर करतो. फक्त निष्कर्ष नव्हे, तर पुरावा समोर ठेवून. Edit आणि rejection चे दर मोजा, कारण शून्य दर म्हणजे बहुतेक वेळा कुणीच वाचत नाही.
  • प्रत्येक tool call चा audit log. कोणते tool, कोणते inputs, काय परत आले, agent ने कशाचा मसुदा बनवला. एखादा work order का अस्तित्वात आहे असे कुणी विचारले, तर उत्तर log मध्ये असते.
  • Go-live आधी replay evals. गेल्या एक किंवा दोन महिन्यांच्या shifts वर, त्या वेळी जसा data होता तसाच वापरून agent चालवा, आणि त्याच्या मसुद्यांची तुलना planners आणि engineers नी प्रत्यक्षात जे केले त्याच्याशी करा. त्याने पकडलेले खरे प्रश्न, त्याने केलेला गोंगाट आणि चुकीचे ठरले असते असे मसुदे मोजा. Model, prompts किंवा tools बदलतील तेव्हा प्रत्येक वेळी हे पुन्हा करा.
  • Step, cost आणि rate मर्यादा. प्रत्येक run मधील tool calls आणि प्रत्येक shift मधील मसुद्यांवर मर्यादा, जेणेकरून गोंधळलेला agent CMMS मध्ये पूर आणू शकणार नाही.
  • एका switch ने बंद होतो. फक्त IT मधील नव्हे, तर operations मधील कुणीही agent लगेच थांबवू शकतो.

लेख 3 मधील autonomy शिडीवर हा agent L2 वर आहे: तो मोकळेपणाने वाचतो आणि मसुदे बनवतो, आणि माणूस मंजुरी देतो. तो तिथेच राहायला हवा.

हे कुठे मोडते

Agent ला data मधील प्रत्येक दोष वारशाने मिळतो. Stop codes अस्पष्ट असतील तर क्रमवारीही अस्पष्ट असेल. CMMS ची asset hierarchy MES शी जुळत नसेल, तर agent stop ला work order शी जोडू शकत नाही. हे आधी दुरुस्त करा. कोणत्याही model पेक्षा ते स्वस्त आहे.

जास्त मसुदे विश्वास संपवतात. प्रत्येक shift ला पंधरा मसुदे काढणाऱ्या agent कडे आठवड्याभरात दुर्लक्ष होईल. एका loss प्रकाराने आणि एका line ने सुरुवात करा, आणि coverage पेक्षा precision साठी tune करा.

Plant मधील मजकुरातून prompt injection. Agent operator notes आणि जुने work orders वाचतो. ते सगळे data म्हणून हाताळा, सूचना म्हणून कधीच नाही, आणि प्रत्येक write tool मंजुरीच्या मागे ठेवा, जेणेकरून एखादी विचित्र नोंद कृतीत बदलू शकणार नाही.

Replica lag. DMZ replica काही तास मागे चालत असेल, तर agent शिळ्या data वर काम करतो. प्रत्येक मसुद्यावर data चा timestamp दाखवा.

मंजुरीचा थकवा. Shift च्या शेवटी चाळीस वेळा approve वर click करणे म्हणजे देखरेख नव्हे. संख्या कमी ठेवा आणि पुरावा स्पष्ट ठेवा.

सारांश

चांगला plant agent हा operator नसून analyst असतो. तो प्रत्येक shift ला losses वाचतो, stop log, historian आणि maintenance इतिहास यांची सांगड घालतो, आणि व्यस्त engineer कधीच हाती घेऊ शकत नाही असा work order किंवा changeover plan चा मसुदा बनवतो. तो सुरक्षित आहे कारण तो कुठे बसतो आणि कशाला हात लावू शकतो यामुळे: Purdue model ची IT बाजू, read-only OT data, फक्त मसुदे बनवणारी write tools, मंजुरी देणारा माणूस, प्रत्येक call चा log, आणि इतिहास replay करून केलेली चाचणी. Model कधी कधी चुकेल. ती चूक एखादा batch नव्हे, तर फक्त नाकारलेला मसुदा एवढ्याच किमतीची राहील याची खात्री architecture करते.

पुढे, आणि शेवटी: roadmap आणि ते कुठे मोडते. Line downtime च्या predictive बाजूसाठी Predicting Packaging Line Downtime and Lifting OEE पाहा. संपूर्ण यादी मालिकेच्या पानावर आहे.

वारंवार विचारले जाणारे प्रश्न

Beverage plant मध्ये AI agent सुरक्षितपणे काय करू शकतो? Production, maintenance आणि quality data वाचणे, कोणते losses महत्त्वाचे आहेत ते ठरवणे, आणि लोकांसाठी कृतींचा मसुदा बनवणे: maintenance work orders, changeover plans, shift summaries, planner ला संदेश. प्रत्येक मसुद्यासोबत त्याचा पुरावा असतो आणि तो मंजुरीची वाट पाहतो. PLCs, SCADA किंवा process setpoints मध्ये लिहिण्याचा कोणताही मार्ग त्याच्याकडे नसावा.

Purdue model म्हणजे काय आणि AI agents साठी तो का महत्त्वाचा आहे? Purdue model ही एक reference architecture आहे जी plant चे networks स्तरांमध्ये विभागते: तळाशी प्रत्यक्ष process आणि त्याचे controllers, सर्वात वर business systems, आणि operations व enterprise IT यांच्यामध्ये एक demilitarised zone. Agent ची जागा IT बाजूला आहे, जिथे तो DMZ मधील replicated data वाचतो. त्याने control स्तरांमध्ये खाली कधीही connection उघडू नये.

AI agent ला plant वर मोकळे सोडण्याआधी त्याची चाचणी कशी करायची? इतिहास replay करा. गेल्या एक किंवा दोन महिन्यांच्या shifts वर, त्या वेळी जसा data होता तसाच वापरून agent चालवा, आणि त्याच्या मसुद्यांची तुलना planners आणि engineers नी प्रत्यक्षात जे केले त्याच्याशी करा. त्याने किती खरे प्रश्न पकडले, किती मसुदे निव्वळ गोंगाट होते, आणि किती चुकीचे ठरले असते ते मोजा. Model, prompts किंवा tools बदलतील तेव्हा प्रत्येक वेळी replay पुन्हा करा.