လေယာဉ်နှင့် ရထားရဲ့ predictive maintenance: AI က အစိတ်အပိုင်း မပျက်ခင်ကတည်းက ဘယ်လိုသိသလဲ
နောက်ဆုံးမော်ဒယ်က ထုတ်တဲ့ ဒေတာပမာဏက အရင်မျိုးဆက်ရဲ့ 50 ဆဖြစ်ပြီး၊ Rolls-Royce က digital twin နဲ့ engine ဘယ်တော့ ဂိုဒေါင်ဝင်ရမလဲ ခန့်မှန်းကာ၊ EASA က 2020 ကတည်းက AI roadmap ရေးခဲ့သည်။ ဤဆောင်းပါးက လေကြောင်းနှင့် ရထားရဲ့ predictive maintenance ဘယ်လိုအလုပ်လုပ်လဲ၊ ဘာလို့ anomaly detection က lifespan prediction ထက် အရင်ဖြစ်ရမလဲနှင့် developer အများဆုံးနင်းမိတဲ့ censored data နှင့် work-order label တွင်းနှစ်ခုကို ဖွင့်ဆိုထားသည်။
မနက် တစ်နာရီ လေးဆယ်၊ လေဆိပ်ဘေးက ဂိုဒေါင်မှာ "ဖြုတ်ကြည့်ရအောင်" ဆိုတဲ့ စကားကို ဘယ်သူမှ မကြားချင်ဘူး
မနက် တစ်နာရီ လေးဆယ်၊ လေဆိပ်တောင်ဘက်က ဂိုဒေါင်တစ်ခုမှာ မီးလင်းနေတယ်။ နောက်နေ့မနက် ပျံရမယ့် narrow-body ခရီးသည်တင်လေယာဉ်တစ်စင်း ရပ်ထားတယ်၊ engineer က screen ပေါ်မှာ တုန်ခါနေတဲ့ vibration curve ကို ကြည့်နေတယ်၊ တန်ဖိုးက ခွင့်ပြုနယ်ပယ်အတွင်း ရှိနေဆဲပေမဲ့၊ လားရာက သုံးပတ်အရင်နဲ့ နည်းနည်း မတူတော့ဘူး။
နောက်ဆုံးဆုံးဖြတ်ချက်က လက်တွေ့ကျတယ်: အခု ဖွင့်ကြည့်မလား? ဖွင့်ရင်၊ ဒီလေယာဉ် နက်ဖြန်မနက် မပျံနိုင်၊ ခရီးစဉ်ကို ချိန်ညှိရ, ခရီးသည်ကို နှစ်သိမ့်ရ, စရိတ် ဂဏန်းခြောက်လုံးက စ။ မဖွင့်ဘဲ တကယ်ဖြစ်သွားရင်၊ အဖိုးအခက လုံးဝမတူတဲ့ အတိုင်းအတာ။
ဒါက predictive maintenance တကယ်ဖြေရှင်းရမယ့် ပြဿနာဖြစ်တယ်။ "AI က dashboard ကြည့်ပေးတာ" မဟုတ်ဘဲ၊ "အချက်အလက်မလုံလောက်တဲ့ အခြေအနေမှာ၊ လောင်းကစားတစ်ခုကို confidence interval ရှိတဲ့ ဆုံးဖြတ်ချက်တစ်ခု ဖြစ်စေတာ" ဖြစ်တယ်။ လေယာဉ်လည်း ဒီလို၊ အမြန်ရထားရဲ့ bogie လည်း ဒီလို၊ wafer စက်ရုံရဲ့ စက်လည်း ဒီလိုပဲ။
ဖြစ်ရပ်နောက်ခံ
maintenance ဆိုတာ၊ engineering အရ အကြမ်းအားဖြင့် သုံးမျိုးရှိတယ်။
ပထမက ပျက်မှ ပြင် (reactive), စရိတ်အနိမ့်ဆုံးပေမဲ့ အန္တရာယ်အမြင့်ဆုံး, ပျက်ရင် အသက်မသေတဲ့အရာနဲ့သာ သင့်တော်တယ်။ ဒုတိယက ပုံမှန်ကာကွယ် (time-based), လေကြောင်းလုပ်ငန်း ကြာရှည်လုပ်တဲ့ A check, C check, ရထားရဲ့ ပုံမှန်ပြုပြင်ခြင်း cycle က ဒီအမျိုးအစား, ပျံသန်းချိန်, တက်ဆင်းအကြိမ်ရေ သို့မဟုတ် မိုင်နဲ့ trigger လုပ်တယ်။ တတိယက condition-based နှင့် predictive maintenance, sensor data နဲ့ "ဒီအစိတ်အပိုင်း အခု ကျန်းမာရေး ဘယ်လိုလဲ, ဘယ်လောက်ကြာ ခံနိုင်လဲ" ကို ဆုံးဖြတ်တာ။
ဒုတိယနည်းက ဘေးကင်းပေမဲ့၊ ဖြုန်းတီးမှု အံ့ဩစရာ။ ပုံမှန်လဲတဲ့ logic က "အစိတ်အပိုင်းအားလုံး တူညီစွာ ပင်ပန်းတယ်" လို့ ယူဆတာ၊ တကယ်တော့ တူညီ bearing ကို လမ်းကြောင်း, ရာသီဥတု, မောင်းနှင်အလေ့အထ မတူတဲ့ ယာဉ်တွေမှာ တပ်ရင်၊ သက်တမ်း အဆများဆ ကွာနိုင်တယ်။ စောလွန်း လဲရင် သုံးလို့ရနေတဲ့ အစိတ်အပိုင်းကို လွှင့်ပစ်တာ, နောက်ကျ လဲရင် ဘယ်သူမှ မကြုံချင်တဲ့ အခြေအနေ။
ဒီပြောင်းလဲမှုကို တွန်းအားပေးတာက data ပမာဏ။ Lufthansa Technik ရဲ့ AVIATAR platform က တရားဝင်ရှင်းလင်းချက်မှာ "နောက်ဆုံးမော်ဒယ်က ထုတ်တဲ့ ဒေတာပမာဏက အရင်မျိုးဆက်ရဲ့ 50 ဆ" ဟု ဆိုကာ၊ platform ကိုယ်တိုင်ကို "client တွေ ရှုပ်ထွေးတဲ့ fleet ကို real-time စီမံ, single component ရဲ့ ပျက်စီးနိုင်ခြေကို ခန့်မှန်း" ဟု သတ်မှတ်တယ်။ ဒီစကားက စဉ်းစားထိုက်တယ်၊ အဓိကက fleet dashboard မဟုတ်ဘဲ single component ရဲ့ ပျက်စီးနိုင်ခြေ ဖြစ်တယ်။
engine ဘက်လည်း တူတယ်။ Rolls-Royce က digital twin ကို ရှင်းရာမှာ ရှင်းရှင်းရေးတယ်: ဒီ twin က "virtual world မှာ တကယ့် engine ကို တောင်ပံမှာတပ်ပြီး လည်ပတ်သလို လည်ပတ်ကာ၊ engine ရဲ့ လည်ပတ်မှုအခြေအနေကို ဆုံးဖြတ်ပြီး၊ ဘယ်တော့ maintenance လိုနိုင်လဲ ခန့်မှန်းတယ်"၊ ဒါက IntelligentEngine vision ရဲ့ တစ်စိတ်တစ်ပိုင်း။
ဥပဒေဘက်က များစွာထင်ထားထက် ပိုစောလှုပ်ရှားခဲ့တယ်။ European Union Aviation Safety Agency (EASA) က 2020 ခုနှစ် ဖေဖော်ဝါရီ 7 ရက်မှာ AI Roadmap 1.0 ထုတ်, 2023 ခုနှစ် မေ 10 ရက်မှာ 2.0 ထုတ်, 2024 ခုနှစ် မတ် 6 ရက်မှာ AI Concept Paper Issue 2 ထုတ်ကာ၊ Level 1 နှင့် Level 2 machine learning application လမ်းညွှန်ပေးတယ်၊ EASA က MLEAP (Machine Learning Application Approval) သုတေသန project ကိုလည်း လုပ်ကာ၊ machine learning system ကို ဘယ်လို verify/approve လုပ်မလဲ ကိုင်တွယ်တယ်။ EASA ကိုယ်တိုင်က ဒီ roadmap ကို "living document" ဟုဆိုကာ၊ နှစ်စဉ် update လုပ်မယ်၊ အဓိကမူက "လေကြောင်းမှာ AI ကို လူသားဗဟိုပြု ချဉ်းကပ်မှု" ဖြစ်တယ်။
ဒီ supply chain ကို ကမ္ဘာအနှံ့ ကုမ္ပဏီများ ပါဝင်တယ်။ EGAT (EVA Air Technic) က 1998 ခုနှစ်မှာ EVA Air နှင့် GE ပူးပေါင်းတည်ထောင်ကာ၊ base က Taoyuan နိုင်ငံတကာလေဆိပ်၊ website က FAA, EASA နှင့် ဂျပန် JCAB ရဲ့ Part-145 maintenance workshop အသိအမှတ်ပြု ရှိကြောင်းနှင့် လေကြောင်းကုမ္ပဏီ 40 ကျော်ကို ဝန်ဆောင်ကြောင်း ဖော်ပြတယ်။ maintenance လုပ်ငန်းမှာ လက်တွေ့အောင်မြင်မှုရှိတယ်။
ဤအကြိမ် အဓိကအချက်များ
- signal ရင်းမြစ်က model ထက် အရေးကြီး: လေကြောင်းဘက်မှာ ACARS ပို့တဲ့ engine status message, QAR flight data ရှိပြီး၊ industrial နှင့် ရထားဘက်က တပ်ဆင်ထားတဲ့ vibration နှင့် temperature sensor ကို အားကိုးတယ်။ Augury က "ကိုယ်ပိုင် wireless sensor + machine learning" လမ်းကိုသွားပြီး၊ TRACTIAN ကလည်း IoT vibration နှင့် temperature sensing ကို AI anomaly detection နဲ့ ချိတ်ရောင်းတယ်။
- anomaly detection အရင်လုပ်, lifespan prediction နောက်ထား: "ဒီစက်က သူ့ရဲ့ ပြီးခဲ့တဲ့လနဲ့ မတူဘူး" ကို အရင်ထုတ်နိုင်ပြီးမှ remaining useful life (RUL) ကို ပြောပါ။ မအောင်မြင်တဲ့ project အများစုက အစီအစဉ်ပြောင်းပြန်ဖြစ်တာ။
- ခန့်မှန်းပြီးရင် work order ထဲ ထည့်နိုင်ရမယ်: ကြိုတင်သတိပေးချက်က maintenance schedule, အစိတ်အပိုင်း inventory နှင့် လူအားစီစဉ်မှုနဲ့ မချိတ်ရင်၊ တန်ဖိုးက သုည။ C3 AI လိုမျိုး enterprise platform အလေးထားတဲ့ prebuilt application ရဲ့ အဓိကကလည်း နောက်ပိုင်း schedule နှင့် inventory optimization မှာ ရှိတယ်။
- image inspection ပျံ့နှံ့လာနေတယ်: track geometry, overhead line, fuselage surface damage ကို camera နဲ့ model နဲ့ တစ်ခေါက်စကင်ဖတ်တာက၊ လူတက်ကြည့်တာထက် မြန်ပြီး ဘေးကင်းတယ်။
- ဥပဒေက maintenance interval ကို တိုက်ရိုက်ပြောင်းခွင့်မပေး: model က လဲတာ ရွှေ့လို့ရတယ်ဆိုပေမဲ့၊ သင် ရွှေ့နိုင်တယ်လို့ မဆိုလိုဘူး။ maintenance plan ပြောင်းလဲမှုက airworthiness authority ရဲ့ လုပ်ငန်းစဉ်ကို လျှောက်ရမယ်၊ ဒါက လေကြောင်းနှင့် ရထားက သာမန်ထုတ်လုပ်ရေးနဲ့ အကြီးဆုံးကွာခြားချက်ဖြစ်တယ်။
ဈေးကွက်သက်ရောက်မှု ခွဲခြမ်းစိတ်ဖြာ
သုံးစွဲသူများ
သင်ခံစားရမှာက အချိန်မှန်နှုန်းနှင့် ရုတ်တရက်ဖျက်သိမ်းမှု။ predictive maintenance ကောင်းကောင်းလုပ်တဲ့ fleet က "ပြင်ပ station မှာ ရုတ်တရက်ကိုင်တွယ်ရမယ့်" ပြဿနာကို၊ ကြိုတင်ပြီး ည base maintenance အချိန်မှာ ပြီးအောင်လုပ်တယ်၊ ခရီးသည်ဘက်မှာ "စက်ချို့ယွင်းလို့ နောက်ကျ" တစ်ခါ လျော့သွားတာ တွေ့ရမယ်။
ဒါပေမဲ့ အလွန်အကျွံ မမျှော်လင့်ပါနဲ့။ maintenance ကြိုတင်သတိပေးချက်က "လက္ခဏာရှိတဲ့ တဖြည်းဖြည်းဆုတ်ယုတ်မှု" ကိုသာ ကိုင်တွယ်နိုင်ကာ၊ ရုတ်တရက် external object damage, ငှက်ဝင်တိုက်, ရာသီဥတု လိုမျိုးကို မတတ်နိုင်ဘူး။ နောက်ကျမှုအကြောင်းရင်းတွေထဲ၊ စက်ပြဿနာက မကြာခဏ အများဆုံးမဟုတ်ဘူး။
လုပ်ငန်းအသုံးချ
ဒီမှာ ထုတ်လုပ်ရေးလုပ်ငန်း မကြာခဏ လျစ်လျူရှုတဲ့ အချက်တစ်ခုရှိတယ်: လေကြောင်းနှင့် ရထားရဲ့ predictive maintenance methodology က စက်ရုံ equipment နဲ့ နီးပါးတူညီ တစ်ခုတည်း။ motor, pump, compressor, fan, spindle, vibration spectrum, အပူတက်လားရာ, current signature, နေရာပြောင်းပေမဲ့ logic မပြောင်းဘူး။
ကျွန်တော့်အကြံက ပြောင်းပြန်လုပ်ပါ။ model ဝယ်ဖို့ မလောဘဲ၊ သုံးလ သုံးခုကို အရင်ပြီးအောင်လုပ်ပါ: တစ်, maintenance work order digital လုပ်ပြီး "ဘာလဲလဲ, ဘာလို့လဲ, အဲဒီတုန်းက လက္ခဏာဘာလဲ" မှတ်တမ်းတင်ပါ, နှစ်, sensor ကို တကယ်ပျက်မယ့်, ပျက်ရင်နာမယ့် equipment မှာ တပ်ပါ, အများဆုံးတပ်တာ မဟုတ်ဘူး, သုံး, အစီအစဉ်မဲ့ ရပ်ဆိုင်းမှုတစ်ခုရဲ့ တကယ့်စရိတ်က ဘယ်လောက်လဲ ရှင်းရှင်းသတ်မှတ်ပါ။ ဒီကိန်းဂဏန်း တွက်မထုတ်နိုင်ရင်၊ နောက်က ROI အားလုံး ခံစားချက်နဲ့သာ ဖြစ်မယ်။
developer များ
ဒါက Kaggle နဲ့ တော်တော်မတူတဲ့ ပြဿနာ၊ လက်တွေ့တွင်း အနည်းငယ်ပြောမယ်။
data က အလွန်အမင်း မညီမျှသလို truncated (censored) ဖြစ်တယ်၊ equipment အများစုက observation ကုန်တဲ့အထိ မပျက်သေးဘူး၊ ဒါကို စာရင်းအင်းမှာ right-censored data လို့ခေါ်ကာ၊ binary classifier ထဲ တိုက်ရိုက်ထည့်ရင် တိကျပုံရပေမဲ့ တကယ် အသုံးမဝင်တဲ့ model ရမယ်။ survival analysis, Weibull distribution လိုမျိုး tool အဟောင်းတွေက ဒီမှာ deep learning ထက် ပိုအသုံးဝင်တယ်။
label က maintenance work order ကနေလာပြီး၊ work order က လူရေးတာ: တူညီ ချို့ယွင်းမှုတစ်ခုကို ရေးနည်း ငါးမျိုးရှိ, timestamp က မှတ်ပုံတင်ချိန်ဖြစ်နိုင်, ဖြစ်ချိန်မဟုတ်ဘဲ။ feature engineering ကလည်း domain knowledge စားတယ်၊ vibration signal ကို FFT, envelope demodulation လုပ်ရ, ရှာတာက သီးခြား frequency ရဲ့ sideband ဖြစ်ပြီး၊ raw waveform ကို network ထဲ ထည့်ရုံနဲ့ မဖြစ်ဘူး။
evaluation metric ကို ပိုသတိထားပါ။ accuracy က အဓိပ္ပာယ်မဲ့ဖြစ်ပြီး၊ ကြည့်ရမှာက PR-AUC, ပျမ်းမျှ ကြိုတင်သတိပေးချိန်, နှင့် false alarm တစ်ခါ ဘယ်လောက်ကုန်လဲ ဖြစ်တယ်၊ လေကြောင်းလုပ်ငန်းမှာ မလိုအပ်ဘဲ ဖြုတ်စစ်တဲ့ စရိတ် တစ်ခါက model တစ်နှစ် ချွေတာတဲ့ ငွေထက် ပိုမြင့်နိုင်တယ်။ နောက်ဆုံး deployment: site network ညံ့, compute အကန့်အသတ်ရှိ, model က edge မှာ run ရလေ့ရှိကာ၊ ဘာလို့ warning ထုတ်လဲ ရှင်းပြနိုင်ရဦးမယ်၊ audit က မေးမှာမို့။ prompt နှင့် data စီစဉ်ခြင်း အခြေခံကို လေ့ကျင့်ချင်ရင်၊ site ရဲ့ prompt library နှင့် task library ကို အရင်လှန်ကြည့်နိုင်တယ်။
အနာဂတ်ဖွံ့ဖြိုးမှုလားရာ
နောက်သုံးနှစ်၊ သုံးခုကို ကျွန်တော် ကြည့်ကောင်းတယ်။
တစ်ခုက time series နှင့် vibration signal ရဲ့ foundation model။ လက်ရှိ အများစုက equipment တစ်ခုကို model တစ်ခု train နေဆဲ, cross-device transfer စွမ်းရည် ညံ့တယ်၊ pretrained model က equipment သစ် cold start အတွက် လိုတဲ့ data ပမာဏကို တစ်အဆင့် လျှော့ချနိုင်ရင်၊ မိတ်ဆက်အတားအဆီး တစ်ခုလုံး ပြောင်းမယ်။
နှစ်ခုက ဥပဒေ တဖြည်းဖြည်း ဖြေလျှော့။ EASA က Level 1 နှင့် Level 2 machine learning application ကို လမ်းညွှန်ထဲ ရေးပြီးဖြစ်ကာ၊ roadmap နှစ်စဉ် update လုပ်တယ်၊ "AI အကူ maintenance ဆုံးဖြတ်ချက်" မှာ ရှင်းလင်းတဲ့ verify လမ်းရှိလာတဲ့အခါ၊ MRO လုပ်ငန်းက သူ့ကို maintenance plan ထဲ တကယ်ရေးဝံ့မယ်။
သုံးခုက အခွင့်အလမ်းက အလယ်အလွှာမှာ။ MRO လက်တွေ့အောင်မြင်မှု, semiconductor equipment ရဲ့ utilization ဖိအား, sensor နှင့် industrial control supply chain ရှိတဲ့ ဒေသတွေမှာ၊ တကယ်ရှားတာက model မဟုတ်ဘဲ၊ "equipment ကိုလည်းနားလည်, data ကိုလည်းနားလည်" တဲ့လူ ဖြစ်တယ်၊ ဒီလိုလူ လုံလောက်အောင်မရှိသေးဘဲ၊ လစာကလည်း ရှားပါးမှုကို မထင်ဟပ်သေးဘူး။
TheAI Academy အနှစ်ချုပ်နှင့် သုံးသပ်ချက်
ကျွန်တော် predictive maintenance project ကို ကြည့်တဲ့အခါ၊ အောင်ရှုံးကို တစ်ခွန်းတည်းမေးတယ်: ဒီ warning ထုတ်ပြီးနောက်၊ ဘယ်သူ ဘာလုပ်မလဲ? မဖြေနိုင်ရင်၊ ဘယ်လောက်တိကျအောင်လုပ်လုပ် အလကား။
ဒီနယ်ပယ်ရဲ့ အဆွဲဆောင်ဆုံးက၊ machine learning ရဲ့ အရိုးရှင်းဆုံးအပိုင်းကို ရင်ဆိုင်ခိုင်းတာ: data ညစ်, positive sample နည်း, model က ရှင်းပြနိုင်ရ, မှားရင် တာဝန်ခံရ။ သူမှာ demo day ရဲ့ အံ့ဩသံမရှိပေမဲ့၊ လေယာဉ် အချိန်မှန်ပျံနိုင်မလား, ရထား tunnel ထဲ ရပ်သွားမလား ကို တိုက်ရိုက် ထင်ဟပ်တယ်။
predictive maintenance ရဲ့ တန်ဖိုးက prediction မှာ မဟုတ်ဘဲ၊ maintenance ကို "လောင်းကစား" ကနေ "တွက်ချက်မှု" ဖြစ်စေတာ ဖြစ်တယ်။
စာဖတ်ပရိသတ်အတွက် တိကျတဲ့ အကြံ: သင် engineer ဆိုရင်၊ survival analysis, signal processing နှင့် work order data cleaning ကို ဖြည့်ပါ၊ ဒီသုံးခုရဲ့ ဈေးကွက်တန်ဖိုးက LLM application တစ်ခု ထပ်ရိုက်တာထက် အများကြီးမြင့်တယ်။ သင် ထုတ်လုပ်ရေး manager ဆိုရင်၊ ဒီလ တစ်ခု အတည်ပြုပါ, သင့် maintenance work order ထဲ "လက္ခဏာ" မှတ်တမ်းတင်ထားလား။ မရှိရင်၊ ဘယ် predictive maintenance ဝယ်ယူမှုမဆို စောလွန်းသေးတယ်။
ဒေတာ ရင်းမြစ်
မေးလေ့ရှိသောမေးခွန်းများ
predictive maintenance နဲ့ ပုံမှန်ပြုပြင်ခြင်း ဘာကွာလဲ?
ပုံမှန်ပြုပြင်ခြင်းက ပျံသန်းချိန်, တက်ဆင်းအကြိမ်ရေ သို့မဟုတ် မောင်းနှင်မိုင်နဲ့ trigger လုပ်ကာ၊ အစိတ်အပိုင်းအားလုံး တူညီစွာ ပင်ပန်းတယ်လို့ ယူဆတယ်၊ predictive maintenance ကတော့ sensor data နဲ့ တစ်ခုချင်း equipment ရဲ့ လက်ရှိ ကျန်းမာရေးအခြေအနေကို ဆုံးဖြတ်တယ်။ တူညီအစိတ်အပိုင်းကို လမ်းကြောင်းနှင့် ပတ်ဝန်းကျင် မတူတဲ့နေရာမှာ တပ်ရင်၊ သက်တမ်း အဆများဆ ကွာနိုင်ကာ၊ ဒါက ပုံမှန်ပြုပြင်ခြင်း ဖြုန်းတီးမှု (သို့မဟုတ် အန္တရာယ်) ရဲ့ ရင်းမြစ်ဖြစ်တယ်။
model က လဲတာ ရွှေ့လို့ရတယ်ဆိုရင်၊ ရွှေ့လို့ရပြီလား?
မရဘူး။ လေကြောင်းနှင့် ရထားရဲ့ maintenance plan ပြောင်းလဲမှုက airworthiness သို့မဟုတ် အုပ်ချုပ်ရေးအာဏာပိုင်ရဲ့ လုပ်ငန်းစဉ်ကို လိုက်နာရမယ်၊ model output က ဆုံးဖြတ်ချက် input သာ ဖြစ်နိုင်တယ်။ ဒါက ဒီလုပ်ငန်းနှစ်ခုက သာမန်ထုတ်လုပ်ရေးနဲ့ အကြီးဆုံးကွာခြားချက်ဖြစ်ပြီး၊ မိတ်ဆက်တဲ့အခါ အလွယ်ဆုံး လျှော့တွက်ခံရတဲ့ အချိန်ကုန်စရိတ်လည်း ဖြစ်တယ်။
EASA က လေကြောင်း AI ကို ဘယ်အထိ စည်းမျဉ်းချပြီးလဲ?
EASA က 2020 ခုနှစ် ဖေဖော်ဝါရီ 7 ရက်မှာ AI Roadmap 1.0, 2023 ခုနှစ် မေ 10 ရက်မှာ 2.0 ထုတ်ပြီး၊ 2024 ခုနှစ် မတ် 6 ရက်မှာ AI Concept Paper Issue 2 ထုတ်ကာ၊ Level 1 နှင့် Level 2 machine learning application လမ်းညွှန်ပေးကာ၊ MLEAP သုတေသန project က machine learning system ရဲ့ verify/approve ကို ကိုင်တွယ်တယ်။ EASA က roadmap ကို နှစ်စဉ်update လုပ်တဲ့ living document ဟု ဆိုတယ်။
predictive maintenance model ဖွံ့ဖြိုးတဲ့အခါ အဖြစ်များဆုံး အမှားက ဘာလဲ?
အဖြစ်များဆုံးက right-censored data ကို လျစ်လျူရှုတာ၊ equipment အများစုက observation ကုန်တဲ့အထိ မပျက်သေးဘဲ၊ binary classification တိုက်ရိုက်လုပ်ရင် တိကျပုံရပေမဲ့ တကယ်အသုံးမဝင်တဲ့ model ရမယ်။ နောက်တစ်ခုက accuracy ကို metric အဖြစ်ထားတာ, ကြည့်ရမှာက PR-AUC, ပျမ်းမျှ ကြိုတင်သတိပေးချိန်, နှင့် false alarm တစ်ခါချင်းရဲ့ တကယ့်စရိတ်ဖြစ်တယ်။
အလတ်စား ထုတ်လုပ်ရေးလုပ်ငန်းက မိတ်ဆက်ချင်ရင်၊ ပထမခြေလှမ်း ဘာလုပ်ရမလဲ?
maintenance work order ကို digital လုပ်ပြီး ဘာလဲလဲ, ဘာလို့လဲ, အဲဒီတုန်းက လက္ခဏာဘာလဲ မှတ်တမ်းတင်ပါ, ပြီးရင် sensor ကို တကယ်ပျက်မယ့်, ပျက်ရင်နာမယ့် equipment မှာသာ တပ်ပါ, နောက်ဆုံး အစီအစဉ်မဲ့ ရပ်ဆိုင်းမှုတစ်ခုရဲ့ တကယ့်စရိတ်ကို တွက်ထုတ်ပါ။ ဒီသုံးခုမလုပ်ဘဲ၊ ဘယ် model ဝယ်ယူမှုမဆို ROI အကဲဖြတ်ရ ခက်တယ်။