ഒരു ഫാക്ടറി മനസ്സിലാക്കാത്ത AI അതിനെ എങ്ങനെ ഒപ്റ്റിമൈസ് ചെയ്യും?

ဘောင်ကြီးမ်အမှန်တကယ်ပိတ်သွားသည်ဟု ထုတ်လုပ်မှုအလယ်တွင် စက်တစ်လုံးရပ်တန့်သွားသည်ဆိုပါစို့။ ERP က ဖောက်သည်အမှာစာများနှင့် ပို့ဆောင်ရမည့်ရက်များကို သိသည်။ MES က မည်သည့်လုပ်ငန်းစဉ်ရပ်တန့်သွားသည်ကို သိသည်။ ပြုပြင်ထိန်းသိမ်းရေးက ပြုပြင်မှုအခြေအနေကို သိသည်။ စက်အလွှာက ချွတ်ယွင်းမှုကုဒ်နှင့် တိကျသောအချိန်ကို သိသည်။ ထို့နောက် လူတစ်ဦးက ရိုးရှင်းသောမေးခွန်းကို မေးသည်– ယခု ကျွန်ုပ်တို့ ဘာလုပ်သင့်သနည်း။

AI သည် အလာမ်ကို အနှစ်ချုပ်ပေးနိုင်သည်၊ ယခင်ရပ်နားမှုပုံစံများကို ရှာဖွေနိုင်သည်၊ ဘာဖြစ်နိုင်ခြေရှိသည်ကို ရှင်းပြနိုင်သည်။ သို့သော် ထုတ်လုပ်နေသော ပစ္စည်းမည်သည်ကို၊ မည်သည့်အမှာစာများက ထို လုပ်ငန်းစဉ်ပေါ်တွင် မှီခိုနေသည်ကို၊ မည်သည့်စက်များက အတည်ပြုထားသော အစားထိုးစက်များဖြစ်သည်ကို၊ ကိရိယာများ အဆင်သင့်ရှိမှုကို၊ မည်သည့်အော်ပရေတာများ အရည်အချင်းပြည့်မီသည်ကို၊ အရည်အသွေးနှင့် လုပ်ငန်းစဉ်စည်းမျဉ်းများ မည်သို့ကျင့်သုံးသည်ကို နားမလည်လျှင် တုံ့ပြန်မှုကို လုံခြုံစွာ အကောင်းဆုံးဖြစ်အောင် လုပ်နိုင်မည်မဟုတ်ပါ။

ထိုအရာသည် အဓိကအားဖြင့် AI ပြဿနာမဟုတ်ပါ။ စက်ရုံ‌အကြောင်းအရာ (factory context) ပြဿနာဖြစ်သည်။

ဒေတာသည် အကြောင်းအရာနှင့် အတူတူမဟုတ်ပါ

စက်ရုံများသည် ဒေတာများစွာကို ထုတ်လုပ်ပြီးသားဖြစ်သည်။ ERP၊ MES၊ ပြုပြင်ထိန်းသိမ်းရေး၊ အရည်အသွေး၊ historian၊ PLC၊ IoT platform နှင့် spreadsheet များတွင် အသုံးဝင်သော အချက်အလက်များ ရှိနေသည်။

ပြဿနာမှာ ထိုအချက်အလက်များသည် မကြာခဏ ဆက်စပ်မှုမရှိဘဲ ကျန်ရစ်ခြင်းဖြစ်သည်။ စက်ရပ်တန့်ကုဒ်တစ်ခုတည်းက ထုတ်လုပ်နေချိန်၊ changeover၊ ပြုပြင်မှု သို့မဟုတ် တင်းကျပ်သော လုပ်ငန်းစဉ်ပြတင်းပေါက်ရှိသော batch အတွင်း ဖြစ်ခဲ့သည်ဟု မပြောနိုင်ပါ။ လိုအပ်သော fixture မရှိခြင်း သို့မဟုတ် အရည်အချင်းပြည့်မီသော အော်ပရေတာ ဆိုင်ဖ်တွင် မရှိခြင်းကြောင့် စက်တစ်လုံးသည် အလုပ်မရှိဟု ထင်ရသော်လည်း အသုံးမပြုနိုင်ဖြစ်နေနိုင်သည်။

Context ဆိုသည်မှာ ဖြစ်ရပ်ကို ၎င်းကို ဝန်းရံထားသော လည်ပတ်မှုအခြေအနေနှင့် ဆက်စပ်ပေးခြင်းဖြစ်သည်။

ထို context တွင်–

• ပိုင်ဆိုင်မှုနှင့် အရင်းအမြစ်အမှတ်သညာ
• လက်ရှိလုပ်ငန်းစဉ်နှင့် အလုပ်အမှာစာ
• ထုတ်ကုန်နှင့် revision
• Route နှင့် အခြား route များ
• ပစ္စည်းနှင့် batch အခြေအနေ
• ကိရိယာများနှင့် fixture များ
• ကျွမ်းကျင်မှုနှင့် shift လွှမ်းခြုံမှု
• အရည်အသွေးကန့်သတ်ချက်များ
• ပြုပြင်ထိန်းသိမ်းမှု အခြေအနေ
• စွမ်းရည်နှင့် downstream မှီခိုမှုများ
• ဖောက်သည်ကတိကဝတ်များ

တို့ ပါဝင်သည်။

ဒက်ရှ်ဘုတ်များသည် မလုံလောက်ပါ

Power BI နှင့် လုပ်ငန်းလည်ပတ်မှု ဒက်ရှ်ဘုတ်များသည် အဘယ်အရာပြောင်းလဲခဲ့သည်ကို ပြသရာတွင် အလွန်ကောင်းမွန်သည်။ ရပ်နားချိန်၊ တိုးလာသော တန်းစီမှု၊ နောက်ကျသော အမှာစာများ၊ scrap သို့မဟုတ် ရရှိနိုင်သော စွမ်းရည်ကို ဖော်ပြနိုင်သည်။

သို့သော် ပြဿနာကို ပြသခြင်းနှင့် ထုတ်လုပ်မှုက နောက်ဘာလုပ်သင့်ကို ဆုံးဖြတ်ခြင်းသည် မတူပါ။ ဒက်ရှ်ဘုတ်တစ်ခုက အခြားစက်တစ်လုံး ရရှိနိုင်သည်ဟု ပြနိုင်သော်လည်း ထိုစက်သည် လက်ရှိထုတ်ကုန် revision အတွက် အတည်ပြုထားခြင်း ရှိမရှိ၊ fixture ကို ကြိုတင်ကြိုးစားထားပြီး ဖြစ်မဖြစ်၊ အရည်အသွေးက လွှဲပြောင်းမှုကို အတည်ပြုရမည်လား၊ အလုပ်ကို ရွှေ့ခြင်းက downstream တွင် bottleneck အသစ်ဖန်တီးမည်လား ဟူသည်များကို အလိုအလျောက် မသိပါ။

အစီရင်ခံစာများတွင် အထူးတွက်ချက်မှု ဒါဇင်နှင့်ချီ ပါဝင်ပြီး စီမံသူများက ရွေးချယ်စရာများကို စမ်းသပ်ရန် ရလဒ်ကို Excel သို့ ထပ်မံ export လုပ်နေလျှင် လိုအပ်နေသည်မှာ မကြာခဏ အခြား visualization မဟုတ်ပါ။ ထိုဆုံးဖြတ်ချက်နောက်ကွယ်ရှိ စက်ရုံစည်းမျဉ်းများ၏ ရှင်းလင်းသော မော်ဒယ်ဖြစ်သည်။

ခန့်မှန်းခြင်းသည် optimization မဟုတ်ပါ

ခန့်မှန်းခြင်းက စက်တစ်လုံး ချို့ယွင်းနိုင်ခြေရှိကြောင်း သို့မဟုတ် အမှာစာတစ်ခု နောက်ကျနိုင်ခြေမြင့်ကြောင်း ပြောနိုင်သည်။ ထိုအချက်များသည် အသုံးဝင်သော်လည်း ဘာလုပ်ရမည်ကို မပြောပါ။

Optimization ၏ အလုပ်မှာ မတူညီသည်။ ၎င်းသည် စက်ရုံ၏ စည်းမျဉ်းများနှင့် ကန့်သတ်ချက်များနှင့် ဆန့်ကျင်၍ ဖြစ်နိုင်သော လုပ်ဆောင်ချက်များကို အကဲဖြတ်သည်။

ဥပမာ– စက်ချို့ယွင်းပြီးနောက် optimizer သည် ထိခိုက်သော အလုပ်ကို မူလစက်တွင် ဆက်ထားနိုင်သလား၊ အတည်ပြုထားသော အစားထိုးစက်သို့ ရွှေ့နိုင်သလား၊ sequence ကို ပြောင်းနိုင်သလား၊ သို့မဟုတ် အချိန်ပိုလုပ်နိုင်သလား ဟု စမ်းသပ်နိုင်သည်။

ဖြစ်နိုင်သော plan တစ်ခုသည် အမှန်တကယ်အခြေအနေများကို လေးစားရမည်။ ဘေးကင်းရေးကန့်သတ်ချက်များ၊ လုပ်ငန်းစဉ်အတည်ပြုချက်များ၊ ပစ္စည်းကိုက်ညီမှု၊ အော်ပရေတာ လက်မှတ်၊ ကိရိယာများ၊ အရည်အသွေးကန့်သတ်ချက်များ၊ ပြုပြင်ထိန်းသိမ်းမှုပြတင်းပေါက်များနှင့် sequence စည်းမျဉ်းများသည် အခြားစက်တစ်လုံး လွတ်နေဟု ထင်ရသောကြောင့် ပျောက်ကွယ်သွားမည် မဟုတ်ပါ။

AI၊ OPTIMIZATION နှင့် စည်းမျဉ်းများ၏ တာဝန်မတူပါ

Generative AI သည် စီမံသူများကို အခြေအနေကို နားလည်ရန်၊ ဆက်စပ်အချက်အလက်များကို ရှာဖွေရန်၊ ရွေးချယ်စရာများကို နှိုင်းယှဉ်ရန်၊ trade-off များကို ရှင်းပြရန်နှင့် အသုံးဝင်သော handover ကို ဖန်တီးရန် ကူညီနိုင်သည်။

ခန့်မှန်းမော်ဒယ်များက အန္တရာယ်ကို ခန့်မှန်းသည်။ Optimization engine များက ဖြစ်နိုင်သော schedule များကို ရှာဖွေသည်။ Deterministic စည်းမျဉ်းများက အဆိုပြုထားသော လုပ်ဆောင်ချက်သည် သိရှိထားသော ထုတ်လုပ်မှုအခြေအနေများကို လေးစားသည်ကို စစ်ဆေးသည်။

ဤအစိတ်အပိုင်းများသည် အတူတကွ အလုပ်လုပ်နိုင်သော်လည်း တစ်ခုနှင့်တစ်ခု မရောထွေးသင့်ပါ။ ဘာသာစကားမော်ဒယ်သည် ယုံကြည်ဖွယ်ကောင်းသော ရှင်းလင်းချက်ကို ထုတ်နိုင်သည်။ သို့သော် ထိုအရာက ထုတ်လုပ်မှု plan သည် လက်တွေ့ဆောင်ရွက်နိုင်ကြောင်း အထောက်အထား မဖြစ်ပါ။

ထုတ်ကုန်၊ လုပ်ငန်းစဉ်၊ အရင်းအမြစ်

အသုံးဝင်သော စက်ရုံမော်ဒယ်တစ်ခုသည် Product၊ Process နှင့် Resource မှ စတင်သည်။

Product သည် ထုတ်လုပ်နေသော အရာကို ဖော်ပြသည်။ revision၊ ပစ္စည်း၊ batch စည်းမျဉ်းများနှင့် ဖောက်သည်အတွက် လိုအပ်ချက်များ ပါဝင်သည်။

Process သည် ထုတ်လုပ်ရန် လိုအပ်သော လုပ်ငန်းများ၊ sequence၊ setup အခြေအနေများ၊ စစ်ဆေးမှုများ၊ အစားထိုးလမ်းကြောင်းများနှင့် စည်းမျဉ်းများကို ဖော်ပြသည်။

Resource သည် ထိုအလုပ်ကို လုပ်ဆောင်နိုင်သည့်အရာများကို ဖော်ပြသည်။ စက်၊ ကိရိယာ၊ fixture၊ မီးဖို၊ စမ်းသပ်ဌာန၊ သယ်ယူပို့ဆောင်ရေးကိရိယာ သို့မဟုတ် လူတစ်ဦးလည်း ဖြစ်နိုင်သည်။

အရေးကြီးသည်မှာ ၎င်းတို့ကြားရှိ ဆက်နွယ်မှုဖြစ်သည်။

မေးခွန်းသည်–

"ဘယ်စက်က လစ်လပ်နေလဲ?" မဟုတ်ပါ။

အသုံးဝင်သော မေးခွန်းမှာ–

"ဤထုတ်ကုန်နှင့် အမှာစာအတွက် လိုအပ်သော နောက်လုပ်ငန်းကို အတည်ပြုထားသော လုပ်ငန်းစဉ်၊ ကိရိယာ၊ ပစ္စည်း၊ အရည်အသွေး၊ ဝန်ထမ်းနှင့် အချိန်ကိုက်ညီမှု အခြေအနေများအောက်တွင် ဘယ်ရရှိနိုင်သော အရင်းအမြစ်က လုပ်ဆောင်နိုင်သလဲ?" ဖြစ်သည်။

Knowledge graph ကို ပွ်ကြွားမှုမပါဘဲ

Knowledge graph သည် ထိုဆက်စပ်နေသော စက်ရုံဆက်နွယ်မှုများကို ကိုယ်စားပြုရန် နည်းလမ်းတစ်ခု ပေးသည်။

စက်များ၊ လုပ်ငန်းများ၊ အမှာစာများ၊ ကိရိယာများနှင့် ပစ္စည်းများကို သီးခြား record များအဖြစ် မသိမ်းဘဲ graph က ၎င်းတို့ကြား ဆက်နွယ်မှုများကိုပါ ကိုယ်စားပြုသည်။

စက်တစ်လုံးသည် လုပ်ငန်းတစ်ခုကို လုပ်နိုင်သည်။ လုပ်ငန်းသည် route တစ်ခုပိုင်သည်။ route သည် ထုတ်ကုန် revision တစ်ခုပိုင်သည်။ အလုပ်အမှာစာသည် ထို route ကို လိုအပ်သည်။ လုပ်ငန်းအတွက် fixture လိုအပ်နိုင်သည်။ fixture သည် လက်ရှိအခြားအလုပ်တစ်ခုအတွက် ကတိပြုထားနိုင်သည်။

ဤသည်က "ဘာကြောင့် ဤအမှာစာကို Machine 7 သို့ မရွှေ့နိုင်သနည်း" ကဲ့သို့သော မေးခွန်းများကို ရှင်းပြရန် ပို၍ လွယ်ကူစေသည်။

အဖြေသည် ရိုးရိုး "မဖြစ်နိုင်ပါ" ဟု မဖြစ်သင့်ပါ။

Machine 7 သည် လုပ်ငန်းကို ပံ့ပိုးသော်လည်း လိုအပ်သော fixture မရှိခြင်း၊ ထုတ်ကုန် revision အတွက် အတည်ပြုချက်မရှိခြင်း သို့မဟုတ် downstream အရည်အသွေးအခြေအနေက route ကို ပိတ်ဆို့နေခြင်းကို ရှင်းပြသင့်သည်။

Digital twin တွင် ရည်ရွယ်ချက် လိုအပ်သည်

တိုက်ရိုက်ဒက်ရှ်ဘုတ်သည် digital twin ဖြစ်ခြင်း အလိုအလျောက် မဟုတ်ပါ။

အသုံးဝင်သော twin သည် ရုပ်ပိုင်းဆိုင်ရာလည်ပတ်မှု၏ သတ်မှတ်ထားသော အစိတ်အပိုင်းတစ်ခုကို ကိုယ်စားပြုပြီး ဖွဲ့စည်းပုံ၊ အခြေအနေ၊ စည်းမျဉ်းများနှင့် မူရင်းဒေတာကို သီးခြားရည်ရွယ်ချက်တစ်ခုအတွက် ဆက်စပ်ပေးသည်။

ပိုင်ဆိုင်မှု twin တစ်ခုသည် ပြုပြင်ထိန်းသိမ်းမှုဆုံးဖြတ်ချက်များကို ပံ့ပိုးနိုင်သည်။ လိုင်း twin တစ်ခုသည် flow နှင့် bottleneck များကို နားလည်ရာတွင် ကူညီနိုင်သည်။ ထုတ်လုပ်မှုစနစ် twin တစ်ခုသည် စက်ပစ္စည်းအခြေအနေကို အမှာစာများ၊ route များ၊ ပစ္စည်းများ၊ လူများ၊ အရည်အသွေးစည်းမျဉ်းများနှင့် ပို့ဆောင်မှုကတိကဝတ်များနှင့် ဆက်စပ်နိုင်သည်။

အရေးကြီးသောမေးခွန်းမှာ "ကျွန်ုပ်တို့တွင် digital twin ရှိပါသလား" မဟုတ်ပါ။

"ဤ twin က မည်သည့်အသုံးပြုသူ၊ ဆုံးဖြတ်ချက်နှင့် အချိန်ပြတင်းပေါက်ကို ပံ့ပိုးသလဲ" ဖြစ်သည်။

ပိုင်ဆိုင်မှုအမှတ်သညာသည် အခြေခံဖြစ်သည်

ရုပ်ပိုင်းစက်တစ်လုံးတွင် အမှတ်သညာများစွာ ရှိနိုင်သည်။

ပြုပြင်ထိန်းသိမ်းမှုက asset နံပါတ်ကို သုံးနိုင်သည်။ MES က production resource ကို သုံးသည်။ ERP က work center ကို သုံးသည်။ IoT အလွှာက controller သို့မဟုတ် tag path ကို မြင်သည်။

ထိုအမှတ်သညာများကို ပျောက်ကွယ်စေရန် မလိုပါ။ သို့သော် ၎င်းတို့၏ဆက်နွယ်မှုများကို အုပ်ချုပ်ရမည်။

AI စနစ်က တူညီသော စက်အမည်နှစ်ခုသည် ရုပ်ပိုင်း asset တစ်ခုတည်းဖြစ်သည်ဟု ခန့်မှန်းပါက၊ ဒေတာကို နည်းပညာအရ သန့်ရှင်းနေသော်လည်း နောက်ဆက်တွဲဆုံးဖြတ်ချက်အားလုံး မှားနိုင်သည်။

ထို့ကြောင့် asset mapping များတွင် ပိုင်ရှင်၊ ထိရောက်သည့်ရက်စွဲများ၊ မူရင်းအရင်းအမြစ်ကိုးကားချက်များနှင့် ပြောင်းလဲမှုစီမံခန့်ခွဲမှု လိုအပ်သည်။

ကန့်သတ်ချက်များသည် ဒေတာ၏ အစိတ်အပိုင်းဖြစ်သည်

Route တစ်ခုသည် နည်းပညာအရ ဖြစ်နိုင်သော်လည်း ထုတ်လုပ်မှုအတွက် လက်မခံနိုင်ပါ။

Hard constraints တွင်–

• ဘေးကင်းရေးကန့်သတ်ချက်များ
• အတည်ပြုထားသော recipe များ
• ပစ္စည်းကိုက်ညီမှု
• စက်စွမ်းရည်
• အော်ပရေတာ လက်မှတ်
• အရည်အသွေး release
• ကိရိယာရရှိနိုင်မှု
• ပြုပြင်ထိန်းသိမ်းမှုကန့်သတ်ချက်များ

တို့ ပါဝင်နိုင်သည်။

အခြားကန့်သတ်ချက်များသည် အကြွင်းမဲ့ ကန့်သတ်ချက်များမဟုတ်ဘဲ trade-off များကို ကိုယ်စားပြုသည်။ အရေးပေါ်ပို့ဆောင်မှုကို ကာကွယ်ရန် changeover တစ်ခု ထပ်ပေါင်းခြင်းသည် လက်ခံနိုင်သည်။ ဖောက်သည်တစ်ဦးအတွက် အချိန်ပိုလုပ်ခွင့်ပြုသော်လည်း အခြားဖောက်သည်အတွက် မခွင့်ပြုနိုင်ပါ။

စနစ်သည် ထို trade-off များကို opaque အကြံပြုချက်အတွင်း ဝှက်ထားမည့်အစား ဖော်ပြသင့်သည်။

သန့်ရှင်းသော ဒေတာသည် လိုအပ်သော်လည်း လုံလောက်မှု မရှိပါ

တိကျသော timestamp များ၊ ပြည့်စုံသော event များ၊ စံသတ်မှတ်ထားသော identifier များနှင့် ယုံကြည်ရသော interface များသည် အရေးကြီးပါသည်။

သို့သော် ပြီးပြည့်စုံစွာ သန့်ရှင်းသော ဇယားတစ်ခုသည်ပင် "ရရှိနိုင်" "ပြီးမြောက်" သို့မဟုတ် "စွမ်းရည်" ဆိုသည်မှာ ဘာကိုဆိုလိုသည်ကို ရှင်းမပြနိုင်ပါ။ စက်တစ်လုံးသည် စက်ပိုင်းဆိုင်ရာအရ ရရှိနိုင်သော်လည်း လက်ရှိလုပ်ငန်းအတွက် မရရှိနိုင်နိုင်ပါသည်။ P