Dynamic Modeling လုပ်နေစဉ်အတွင်း နည်းပညာဆိုင်ရာ သတ်မှတ်ချက်များ လိုအပ်ချက်များကို အလိုအလျောက် အတည်ပြုခြင်း။

ဆောင်ပုဒ်ကို ဆက်လုပ်နေသည်။ "မင်းရဲ့သက်သေကဘာလဲ"တစ်ဖက်က သင်္ချာပုံသဏ္ဍာန်ရဲ့ ပြဿနာကို ကြည့်ရအောင်။ မော်ဒယ်သည် ဘဝ၏အိမ်တွင်းအမှန်တရားနှင့် ကိုက်ညီကြောင်း ကျွန်ုပ်တို့ယုံကြည်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် အဓိကမေးခွန်းကို ဖြေနိုင်သည်- "ကျွန်ုပ်တို့ ဤနေရာတွင် အတိအကျရှိပါသလား" နည်းပညာဆိုင်ရာ အရာဝတ္ထုတစ်ခု၏ မော်ဒယ်တစ်ခုကို ဖန်တီးသောအခါ၊ ဤအရာဝတ္ထုသည် ကျွန်ုပ်တို့၏မျှော်လင့်ချက်များကို ပြည့်မီကြောင်း သေချာစေလိုပါသည်။ ဤရည်ရွယ်ချက်အတွက်၊ လုပ်ငန်းစဉ်များ၏ ဒိုင်းနမစ်တွက်ချက်မှုများကို လုပ်ဆောင်ပြီး ရလဒ်သည် လိုအပ်ချက်များနှင့် နှိုင်းယှဉ်ပါသည်။ ၎င်းသည် ဒစ်ဂျစ်တယ် အမွှာ၊ အတုအယောင် ရှေ့ပြေးပုံစံ စသည်တို့ဖြစ်သည်။ ဒီဇိုင်းအဆင့်မှာ ဖက်ရှင်ကျကျလေးတွေက ကျွန်တော်တို့ စီစဉ်ထားတာကို ဘယ်လိုရအောင်လုပ်ရမလဲဆိုတဲ့ ပြဿနာကို ဖြေရှင်းပေးတယ်။

ကျွန်ုပ်တို့၏စနစ်သည် ကျွန်ုပ်တို့ဒီဇိုင်းရေးဆွဲထားသည်၊ ကျွန်ုပ်တို့၏ဒီဇိုင်းသည် ပျံသန်းမည် သို့မဟုတ် လွင့်နေမည်ကို မည်ကဲ့သို့ လျင်မြန်စွာပြုလုပ်နိုင်မည်နည်း။ ယင်ကောင်က ဘယ်လောက်မြင့်လဲ။ မျောပါရင် ဘယ်လောက်နက်လဲ။

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

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

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

ဥပမာအားဖြင့်၊ ဤသေးငယ်သော်လည်း လက်တွေ့ကျသော လိုအပ်ချက်များကို သုံးသပ်ကြည့်ပါ-

1. ရေသန့်စင်မှုစနစ်သို့ ဝင်ပေါက်ရှိ လေထုအပူချိန်
   ကားပါကင်တွင် - အနှုတ် 35 မှ 35 ºС၊
   ပျံသန်းမှုတွင် - အနုတ် 35 မှ 39 ºС။
2. ပျံသန်းရာတွင် လေထု၏တည်ငြိမ်သောဖိအားသည် 700 မှ 1013 GPa (526 မှ 760 mm Hg) ဖြစ်သည်။
3. ပျံသန်းမှုတွင် SVO လေဝင်ပေါက်ဆီသို့ စုစုပေါင်းလေဖိအားသည် 754 မှ 1200 GPa (566 မှ 1050 mmHg) ဖြစ်သည်။
4. အအေးခံလေထုအပူချိန်
   ကားပါကင်တွင် - 27 ºСထက်မပိုပါ၊ နည်းပညာဆိုင်ရာလုပ်ကွက်များအတွက် - 29 ºСထက်မပိုစေရ၊
   ပျံသန်းမှုတွင် - 25 ºСထက်မပိုပါ၊ နည်းပညာဆိုင်ရာလုပ်ကွက်များအတွက် - 27 ºСထက်မပိုပါ။
5. လေအေးစီးဆင်းမှု-
   ရပ်ထားသည့်အခါ - အနည်းဆုံး 708 kg/h၊
   ပျံသန်းရာတွင် - 660 ကီလိုဂရမ် / နာရီထက်မနည်း။
6. စက်ခန်းအတွင်းရှိ လေအပူချိန်သည် 60 ºС ထက်မပိုပါ။
7. အအေးခံလေထဲတွင် အစိုဓာတ်ကင်းစင်သော ပမာဏသည် ခြောက်သွေ့သောလေ၏ 2 g/kg ထက် မပိုစေရပါ။

ဤကန့်သတ်ထားသော သတ်မှတ်ချက်များအတွင်း၌ပင်၊ စနစ်တွင် ကွဲပြားစွာ ကိုင်တွယ်ရန် လိုအပ်သော အမျိုးအစား နှစ်ခု အနည်းဆုံး ရှိပါသည်။

• စနစ်၏လည်ပတ်မှုအခြေအနေများအတွက်လိုအပ်ချက်များ (အပိုဒ် 1-3);
• စနစ်အတွက် parametric လိုအပ်ချက်များ (အပိုဒ်ငယ် 3-7)။

စနစ်လည်ပတ်မှုအခြေအနေ လိုအပ်ချက်
မော်ဒယ်ဖန်တီးနေစဉ်အတွင်း စနစ်အတွက် ပြင်ပအခြေအနေများကို နယ်နိမိတ်အခြေအနေများအဖြစ် သို့မဟုတ် ယေဘုယျစနစ်၏လည်ပတ်မှုရလဒ်အဖြစ် သတ်မှတ်နိုင်ပါသည်။
Dynamic Simulation တွင်၊ သတ်မှတ်ထားသော လည်ပတ်မှုအခြေအနေများကို simulation လုပ်ငန်းစဉ်ဖြင့် အကျုံးဝင်ကြောင်း သေချာစေရန် လိုအပ်ပါသည်။

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

သတ်မှတ်ချက်များနှင့် ကုဒ်နံပါတ်များ

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

လိုအပ်ချက်ကုဒ်သည် လိုအပ်ချက်၏ အမှာစာနံပါတ်ကို ကိုယ်စားပြုသည့် နံပါတ်တစ်ခု ဖြစ်နိုင်သည်၊ သို့မဟုတ် ၎င်းတွင် လိုအပ်ချက်အမျိုးအစားကုဒ်၊ ၎င်းနှင့်သက်ဆိုင်သည့် စနစ် သို့မဟုတ် ယူနစ်အတွက် ကုဒ်တစ်ခု၊ ကန့်သတ်ချက်ကုဒ်၊ တည်နေရာကုဒ်နှင့် အခြားအရာများ ပါဝင်နိုင်သည်။ အင်ဂျင်နီယာ စိတ်ကူးနိုင်သည်။ (ကုဒ်နံပါတ်အသုံးပြုမှုအတွက် ဆောင်းပါးကို ကြည့်ပါ)

Table 1 သည် လိုအပ်ချက်များ coding ၏ ရိုးရှင်းသော ဥပမာကို ပေးသည်။

1. လိုအပ်ချက်များ၏အရင်းအမြစ်၏ကုဒ် R-requirements TK;
2. ကုဒ်အမျိုးအစားလိုအပ်ချက်များ E - လိုအပ်ချက်များ - ပတ်ဝန်းကျင်ဆိုင်ရာ ကန့်သတ်ချက်များ၊ သို့မဟုတ် လည်ပတ်မှုအခြေအနေများ
   S - စနစ်ကထောက်ပံ့ပေးလိုအပ်ချက်များ;
3. လေယာဉ်အခြေအနေကုဒ် 0 – မည်သည့်၊ G – ရပ်ထားသည်၊ F – ပျံသန်းနေစဉ်၊
4. ရုပ်ပိုင်းဆိုင်ရာပါရာမီတာအမျိုးအစားကုဒ် T – အပူချိန်၊ P – ဖိအား၊ G – စီးဆင်းမှုနှုန်း၊ စိုထိုင်းဆ H;
5. လိုအပ်ချက်၏နံပါတ်စဉ်။

ID လိုအပ်ချက်	ဖေါ်ပြချက်	parameter သည်
REGT01	ရေအေးပေးစနစ်သို့ဝင်ပေါက်ရှိပတ်ဝန်းကျင်လေအပူချိန်- ကားရပ်နားရာနေရာရှိ - အနှုတ် 35ºС မှ။ 35 ºСအထိ။
REFT01	လေကြောင်းရန်ကာကွယ်ရေးစနစ်သို့ဝင်ပေါက်ရှိလေထုအပူချိန် - အနုတ် 35 ºСမှ 39 ºС။
REFP01	ပျံသန်းရာတွင် တည်ငြိမ်သောလေထုဖိအားသည် 700 မှ 1013 hPa (526 မှ 760 mm Hg) ဖြစ်သည်။
REFP02	ပျံသန်းမှုတွင် SVO လေဝင်ပေါက်ဆီသို့ စုစုပေါင်းလေဖိအားသည် 754 မှ 1200 hPa (566 မှ 1050 mmHg) ဖြစ်သည်။
RSGT01	အအေးခံလေထုအပူချိန်- ရပ်ထားသည့်အခါ 27 ºС ထက်မပိုစေရ။
RSGT02	အအေးခံလေထုအပူချိန်- 29 ºС ထက်မပိုသော နည်းပညာဆိုင်ရာ ယူနစ်များအတွက် ကားရပ်နားရန်နေရာ
RSFT01	ပျံသန်းရာတွင် လေအေးပေးစက်အပူချိန် 25 ºС ထက်မပိုစေရ။
RSFT02	အအေးခံလေထုအပူချိန်- ပျံသန်းမှုတွင်၊ နည်းပညာယူနစ်များအတွက် 27 ºС ထက်မပိုပါ။
RSGG01	အအေးခံလေစီးဆင်းမှု- ရပ်ထားသည့်အခါ 708 ကီလိုဂရမ်/နာရီထက် မနည်း
RSFG01	အအေးခံလေစီးဆင်းမှု- ပျံသန်းမှုတွင် 660 ကီလိုဂရမ်/နာရီထက် မနည်း
RS0T01	စက်ခန်းအတွင်း လေအပူချိန် 60 ºС ထက်မပိုစေရ။
RSH01	အအေးခံလေထဲတွင် အစိုဓာတ်ကင်းစင်သော ပမာဏသည် ခြောက်သွေ့သောလေ၏ 2 g/kg ထက် မပိုစေရပါ။

လိုအပ်ချက်များ အတည်ပြုခြင်းစနစ် ဒီဇိုင်း။

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

အတည်ပြုခြင်းသည် အယ်လဂိုရီသမ်တစ်ခုဖြစ်သောကြောင့်၊ ထိန်းချုပ်မှုပရိုဂရမ်များဖန်တီးရန် ကျွန်ုပ်တို့အသုံးပြုသည့် တူးလ်များနှင့် တူးလ်များကို ကျွန်ုပ်တို့အသုံးပြုနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ SimInTech ပတ်ဝန်းကျင်သည် သင့်အား သီးခြားပရောဂျက်များ (object model၊ control system model၊ environment model စသည်) ဖြင့် လုပ်ဆောင်သည့် model ၏ အစိတ်အပိုင်းများစွာပါဝင်သော ပရောဂျက်ပက်ကေ့ဂျ်များကို ဖန်တီးနိုင်စေပါသည်။

ဤကိစ္စတွင် လိုအပ်ချက်များ အတည်ပြုခြင်း ပရောဂျက်သည် တူညီသော အယ်လဂိုရီသမ် ပရောဂျက်ဖြစ်လာပြီး မော်ဒယ်ပက်ကေ့ခ်ျသို့ ချိတ်ဆက်ထားသည်။ နှင့် dynamic modeling mode တွင် ၎င်းသည် နည်းပညာဆိုင်ရာ သတ်မှတ်ချက်များ၏ လိုအပ်ချက်များနှင့် လိုက်လျောညီထွေဖြစ်စေရန်အတွက် ခွဲခြမ်းစိတ်ဖြာမှုကို လုပ်ဆောင်သည်။

စနစ်ဒီဇိုင်း၏ ဖြစ်နိုင်ခြေရှိသော ဥပမာကို ပုံ 1 တွင် ပြထားသည်။

ပုံ 1။ အတည်ပြုခြင်းပရောဂျက်တစ်ခု၏ ဒီဇိုင်းနမူနာ။

ထိန်းချုပ်မှု အယ်လဂိုရီသမ်များကဲ့သို့ပင်၊ လိုအပ်ချက်များကို စာရွက်များအစုတစ်ခုအနေဖြင့် ရေးဆွဲနိုင်သည်။ SimInTech၊ Simulink၊ AmeSim ကဲ့သို့သော structural modeling ပတ်၀န်းကျင်တွင် algorithms ဖြင့် အလုပ်လုပ်ရာတွင် အဆင်ပြေစေရန်အတွက်၊ submodels ပုံစံဖြင့် multi-level structures များကို ဖန်တီးနိုင်မှုကို အသုံးပြုပါသည်။ ဤအဖွဲ့အစည်းသည် ထိန်းချုပ်မှုဆိုင်ရာ အယ်လဂိုရီသမ်များအတွက် လုပ်ဆောင်ထားသည့်အတိုင်း လိုအပ်ချက်များစွာဖြင့် အလုပ်ကို ရိုးရှင်းလွယ်ကူစေရန် အမျိုးမျိုးသောလိုအပ်ချက်များကို အစုံလိုက်စုဖွဲ့နိုင်စေသည် (ပုံ။ 2 ကိုကြည့်ပါ)။

ပုံ 2. လိုအပ်ချက်များ အတည်ပြုခြင်း မော်ဒယ်၏ အထက်အောက် ဖွဲ့စည်းပုံ။

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

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

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

ဤကိစ္စတွင်၊ ဒိုင်းနမစ်မော်ဒယ်ကိုယ်တိုင်က မည်သည့်သင်္ချာပုံစံပုံစံစနစ်တွင်မဆို သို့မဟုတ် executable program ပုံစံဖြင့်ပင် လုပ်ဆောင်နိုင်သည်။ တစ်ခုတည်းသောလိုအပ်ချက်မှာ ပြင်ပပတ်ဝန်းကျင်သို့ မော်ဒယ်ဒေတာထုတ်ပေးရန်အတွက် ဆော့ဖ်ဝဲလ်အင်တာဖေ့စ်များ ရှိနေခြင်းပင်ဖြစ်သည်။

ပုံ 3။ အတည်ပြုခြင်းပရောဂျက်ကို ရှုပ်ထွေးသောပုံစံနှင့် ချိတ်ဆက်ခြင်း။

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

ပုံ 4. လိုအပ်ချက်များ စစ်ဆေးချက်စာရွက်။

ချက်စာရွက်၏ အဓိက အစိတ်အပိုင်းများကို ပုံ 5 တွင် ဖော်ပြထားပါသည်။ စစ်ဆေးသည့် အယ်လဂိုရီသမ်ကို ထိန်းချုပ်မှု အယ်လဂိုရီသမ်များ၏ ဒီဇိုင်းပုံကြမ်းများအတိုင်း ဖွဲ့စည်းထားသည်။ ညာဘက်တွင် ဒေတာဘေ့စ်မှ အချက်ပြမှုများကို ဖတ်ရန် ဘလောက်တစ်ခုရှိသည်။ ဤပိတ်ဆို့မှုသည် သရုပ်ဖော်မှုအတွင်း အချက်ပြဒေတာဘေ့စ်ကို ဝင်ရောက်သည်။

လက်ခံရရှိသော အချက်ပြမှုများကို လိုအပ်ချက်များ စိစစ်ခြင်း အခြေအနေများကို တွက်ချက်ရန် ခွဲခြမ်းစိတ်ဖြာပါသည်။ ဤကိစ္စတွင်၊ လေယာဉ်၏တည်နေရာကိုဆုံးဖြတ်ရန် (ရပ်ထားသလား၊ ပျံသန်းနေသလား) ကိုဆုံးဖြတ်ရန် အမြင့်ပိုင်းခွဲခြမ်းစိတ်ဖြာမှုကို လုပ်ဆောင်သည်။ ဤရည်ရွယ်ချက်အတွက်၊ သင်သည် မော်ဒယ်၏ အခြားအချက်ပြမှုများနှင့် တွက်ချက်ထားသော ဘောင်များကို အသုံးပြုနိုင်သည်။

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

ပုံ 5။ လိုအပ်ချက်များ အတည်ပြုခြင်း တွက်ချက်မှု စာရွက်ဖွဲ့စည်းပုံ။

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

ဥပမာအားဖြင့်၊ ဤလိုအပ်ချက်

ပစ်မှတ်သို့ ပျံသန်းစဉ် တည့်မတ်မှုစနစ်၏ အသက်ဝင်မှု အရေအတွက်သည် 5 ထက် မပိုသင့်ဘဲ၊ အမှားပြင်စနစ်၏ စုစုပေါင်းလည်ပတ်ချိန်သည် စက္ကန့် 30 ထက် မပိုသင့်ပါ။

ဤကိစ္စတွင်၊ စတင်သည့်အရေအတွက်နှင့် စုစုပေါင်းလည်ပတ်ချိန်ကို တန်ပြန်ရန်အတွက် အယ်လဂိုရီသမ်တစ်ခုအား လိုအပ်ချက်များ၏ ဒီဇိုင်းပုံကြမ်းတွင် ထည့်သွင်းထားသည်။

ပုံမှန်လိုအပ်ချက်စိစစ်ရေးပိတ်ဆို့

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

ဘလောက်တွင် input port နှစ်ခု၊ param နှင့် condition ပါရှိသည်။

ပထမတစ်ခုကို ကန့်သတ်ချက်စစ်ဆေးပြီး ကျွေးသည်။ ဤကိစ္စတွင် "ပြင်ပအပူချိန်" ။

Boolean variable ကို ဒုတိယ port သို့ ပံ့ပိုးပေးသည် - စစ်ဆေးမှုကို လုပ်ဆောင်ရန် အခြေအနေ။

ဒုတိယထည့်သွင်းမှုတွင် TRUE (1) ကို လက်ခံရရှိပါက၊ ဘလောက်သည် လိုအပ်ချက် အတည်ပြုတွက်ချက်မှုကို လုပ်ဆောင်သည်။

အကယ်၍ ဒုတိယထည့်သွင်းမှုသည် FALSE (0) ကို လက်ခံရရှိပါက စမ်းသပ်မှုအခြေအနေများနှင့် မကိုက်ညီပါ။ တွက်ချက်မှုအခြေအနေများကို ထည့်သွင်းတွက်ချက်နိုင်ရန် လိုအပ်ပါသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ မော်ဒယ်၏အခြေအနေပေါ်မူတည်၍ စစ်ဆေးမှုကို ဖွင့်ရန် သို့မဟုတ် ပိတ်ရန် ဤထည့်သွင်းမှုကို အသုံးပြုပါသည်။ အကယ်၍ လေယာဉ်သည် သရုပ်ဖော်မှုအတွင်း မြေပြင်ပေါ်တွင် ရှိနေပါက၊ ပျံသန်းမှုနှင့် ပတ်သက်သည့် လိုအပ်ချက်များကို စစ်ဆေးခြင်း မပြုရ၊ အပြန်အလှန်အားဖြင့် လေယာဉ်သည် ပျံသန်းနေပါက၊ မတ်တပ်ရပ်သည့်နေရာတွင် လည်ပတ်ခြင်းနှင့် ပတ်သက်သည့် လိုအပ်ချက်များကို စစ်ဆေးမည်မဟုတ်ပါ။

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

ဤဘလောက်၏ ကန့်သတ်ချက်များမှာ-

• နယ်နိမိတ်အခြေအနေများ- စစ်ဆေးရမည့် အထက် (UpLimit) နှင့် အောက် (DownLimit) အပိုင်းအခြား ကန့်သတ်ချက်များ၊
• နယ်နိမိတ်အပိုင်းအခြားများ (TimeInterval) တွင် စက္ကန့်ပိုင်းအတွင်း လိုအပ်သော စနစ်ထိတွေ့ချိန်၊
• ID တောင်းဆိုရန် ReqName;
• အပိုင်းအခြား Out_range ကို ကျော်လွန်ခြင်း၏ ခွင့်ပြုချက်သည် စစ်ဆေးထားသော အပိုင်းအခြားထက်ကျော်လွန်သည့် တန်ဖိုးသည် လိုအပ်ချက်ကို ချိုးဖောက်ခြင်းရှိမရှိ ဆုံးဖြတ်ပေးသည့် Boolean variable တစ်ခုဖြစ်သည်။

အချို့ကိစ္စများတွင်၊ စမ်းသပ်မှုတန်ဖိုးထွက်ရှိမှုသည် စနစ်တွင် အချို့သောအနားသတ်များရှိပြီး ၎င်း၏လည်ပတ်မှုအပိုင်းအခြားပြင်ပတွင် လုပ်ဆောင်နေနိုင်သည်ကို ညွှန်ပြသည်။ အခြားကိစ္စများတွင်၊ အထွက်တစ်ခုသည် စနစ်သည် သတ်မှတ်အမှတ်များကို အကွာအဝေးအတွင်း မထားရှိနိုင်ဟု ဆိုလိုသည်။

ပုံ 6. ပုံကြမ်းနှင့် ၎င်း၏ ဘောင်များတွင် ပုံမှန် ပိုင်ဆိုင်မှု စစ်ဆေးခြင်း ပိတ်ဆို့ခြင်း။

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

• 0 – rNone၊ တန်ဖိုး သတ်မှတ်မထားပါ။
• 1 – ပြီးပြီ၊ လိုအပ်ချက်ကို ပြည့်မီပြီ၊
• 2 – rFault၊ လိုအပ်ချက်ကို မဖြည့်ဆည်းပေးနိုင်ပါ။

ဘလောက်ပုံတွင်-

• သတ်မှတ်ထားသော စာသား၊
• ဒစ်ဂျစ်တယ် တိုင်းတာခြင်း ကန့်သတ်ဘောင်များ ၊
• ကန့်သတ်မှုအခြေအနေ၏အရောင်သတ်မှတ်မှု။

ဘလောက်အတွင်းတွင် အတော်လေး ရှုပ်ထွေးသော ယုတ္တိဗေဒ အနုမာနပတ်လမ်း ရှိနိုင်ပါသည်။

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

ပုံ 7။ အပူချိန်အပိုင်းသတ်မှတ်ခြင်းယူနစ်၏ အတွင်းပိုင်းပုံ။

circuit block အတွင်းတွင် block parameters များတွင် သတ်မှတ်ထားသော ဂုဏ်သတ္တိများကို အသုံးပြုပါသည်။
လိုအပ်ချက်များနှင့်အညီ ခွဲခြမ်းစိတ်ဖြာခြင်းအပြင်၊ ဘလောက်၏အတွင်းပိုင်းပုံကြမ်းတွင် သရုပ်ဖော်မှုရလဒ်များကိုပြသရန်အတွက် လိုအပ်သောဂရပ်ပါရှိသည်။ ဤဂရပ်ကို တွက်ချက်နေစဉ်အတွင်း ကြည့်ရှုရန်နှင့် တွက်ချက်ပြီးနောက် ရလဒ်များကို ပိုင်းခြားစိတ်ဖြာရန်အတွက် နှစ်မျိုးလုံးအသုံးပြုနိုင်ပါသည်။

တွက်ချက်မှုရလဒ်များကို block ၏ output သို့ပို့ပြီး ပရောဂျက်တစ်ခုလုံးအတွက် ရလဒ်များအပေါ်အခြေခံ၍ ဖန်တီးထားသည့် အထွေထွေအစီရင်ခံစာဖိုင်တစ်ခုတွင် တစ်ပြိုင်နက်မှတ်တမ်းတင်ထားသည်။ (ပုံ ၈ ကိုကြည့်ပါ)

simulation ရလဒ်များကို အခြေခံ၍ ဖန်တီးထားသော အစီရင်ခံစာ၏ ဥပမာသည် ပေးထားသော ဖော်မတ်အရ ဖန်တီးထားသော html ဖိုင်တစ်ခုဖြစ်သည်။ ဖော်မတ်သည် အဖွဲ့အစည်းတစ်ခုမှ လက်ခံထားသော ဖော်မတ်သို့ နိုင်ထက်စီးနင်း စီစဉ်သတ်မှတ်နိုင်သည်။

circuit block အတွင်းတွင် block parameters များတွင် သတ်မှတ်ထားသော ဂုဏ်သတ္တိများကို အသုံးပြုပါသည်။
လိုအပ်ချက်များနှင့်အညီ ခွဲခြမ်းစိတ်ဖြာခြင်းအပြင်၊ ဘလောက်၏အတွင်းပိုင်းပုံကြမ်းတွင် သရုပ်ဖော်မှုရလဒ်များကိုပြသရန်အတွက် လိုအပ်သောဂရပ်ပါရှိသည်။ ဤဂရပ်ကို တွက်ချက်နေစဉ်အတွင်း ကြည့်ရှုရန်နှင့် တွက်ချက်ပြီးနောက် ရလဒ်များကို ပိုင်းခြားစိတ်ဖြာရန်အတွက် နှစ်မျိုးလုံးအသုံးပြုနိုင်ပါသည်။

တွက်ချက်မှုရလဒ်များကို block ၏ output သို့ပို့ပြီး ပရောဂျက်တစ်ခုလုံးအတွက် ရလဒ်များအပေါ်အခြေခံ၍ ဖန်တီးထားသည့် အထွေထွေအစီရင်ခံစာဖိုင်တစ်ခုတွင် တစ်ပြိုင်နက်မှတ်တမ်းတင်ထားသည်။ (ပုံ ၈ ကိုကြည့်ပါ)

simulation ရလဒ်များကို အခြေခံ၍ ဖန်တီးထားသော အစီရင်ခံစာ၏ ဥပမာသည် ပေးထားသော ဖော်မတ်အရ ဖန်တီးထားသော html ဖိုင်တစ်ခုဖြစ်သည်။ ဖော်မတ်သည် အဖွဲ့အစည်းတစ်ခုမှ လက်ခံထားသော ဖော်မတ်သို့ နိုင်ထက်စီးနင်း စီစဉ်သတ်မှတ်နိုင်သည်။

ပုံ 8. သရုပ်ဖော်မှုရလဒ်များအပေါ်အခြေခံ၍ အစီရင်ခံစာဖိုင်၏နမူနာ။

ဤဥပမာတွင်၊ အစီရင်ခံစာပုံစံကို ပရောဂျက်ဂုဏ်သတ္တိများတွင် တိုက်ရိုက်ပြင်ဆင်သတ်မှတ်ထားပြီး ဇယားရှိဖော်မတ်ကို ကမ္ဘာလုံးဆိုင်ရာ ပရောဂျက်အချက်ပြမှုများအဖြစ် သတ်မှတ်ထားသည်။ ဤကိစ္စတွင်၊ SimInTech ကိုယ်တိုင်က အစီရင်ခံစာကို သတ်မှတ်ခြင်းဆိုင်ရာ ပြဿနာကို ဖြေရှင်းပေးပြီး ဖိုင်တစ်ခုသို့ ရလဒ်များရေးသားရန်အတွက် ဘလောက်သည် အစီရင်ခံစာဖိုင်တွင် ရေးသားရန် ဤစာကြောင်းများကို အသုံးပြုသည်။

ပုံ 9. ကမ္ဘာလုံးဆိုင်ရာ ပရောဂျက်အချက်ပြမှုများတွင် အစီရင်ခံစာပုံစံကို သတ်မှတ်ခြင်း။

လိုအပ်ချက်များအတွက် အချက်ပြဒေတာဘေ့စ်ကို အသုံးပြုခြင်း။

ပိုင်ဆိုင်မှုဆက်တင်များဖြင့် အလိုအလျောက်လုပ်ဆောင်ရန်၊ ပုံမှန်ဘလောက်တစ်ခုစီအတွက် အချက်ပြဒေတာဘေ့စ်တွင် စံဖွဲ့စည်းပုံကို ဖန်တီးထားသည်။ (ပုံ ၁၀ ကိုကြည့်ပါ)

ပုံ 10။ အချက်ပြဒေတာဘေ့စ်ရှိ လိုအပ်ချက် စစ်ဆေးခြင်း ပိတ်ဆို့ခြင်း တည်ဆောက်ပုံ နမူနာ။

Signal ဒေတာဘေ့စ် ပံ့ပိုးပေးသည်-

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

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

ပုံ 11။ လိုအပ်ချက်များ စီမံခန့်ခွဲမှုစနစ်နှင့် အပြန်အလှန်တုံ့ပြန်မှု ပုံကြမ်း။

SimInTech စမ်းသပ်မှုပရောဂျက်နှင့် လိုအပ်ချက်ထိန်းချုပ်မှုစနစ်အကြား အပြန်အလှန်အကျိုးသက်ရောက်မှု အဆင့်ဆင့်မှာ အောက်ပါအတိုင်းဖြစ်သည်။

1. အကိုးအကား စည်းကမ်းချက်များကို လိုအပ်ချက်များအဖြစ် ခွဲထားသည်။
2. နည်းပညာဆိုင်ရာ သတ်မှတ်ချက်များ၏ လိုအပ်ချက်များကို သင်္ချာနည်းကျ စံပြနည်းပညာဆိုင်ရာ လုပ်ငန်းစဉ်များဖြင့် အတည်ပြုနိုင်သည်ကို ဖော်ထုတ်ထားပါသည်။
3. ရွေးချယ်ထားသော လိုအပ်ချက်များ၏ အရည်အချင်းများကို စံလုပ်ကွက်များ၏ ဖွဲ့စည်းပုံရှိ SimInTech အချက်ပြဒေတာဘေ့စ်သို့ လွှဲပြောင်းပေးသည် (ဥပမာ၊ အမြင့်ဆုံးနှင့် အနိမ့်ဆုံးအပူချိန်)။
4. တွက်ချက်မှုလုပ်ငန်းစဉ်အတွင်း၊ တည်ဆောက်ပုံဒေတာကို ဒီဇိုင်းပုံကြမ်းများသို့ လွှဲပြောင်းပြီး၊ ခွဲခြမ်းစိတ်ဖြာမှုကို လုပ်ဆောင်ပြီး ရလဒ်များကို အချက်ပြဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသည်။
5. တွက်ချက်မှုပြီးသည်နှင့်၊ ခွဲခြမ်းစိတ်ဖြာမှုရလဒ်များကို လိုအပ်ချက်စီမံခန့်ခွဲမှုစနစ်သို့ လွှဲပြောင်းပေးသည်။

ဒီဇိုင်းနှင့်/သို့မဟုတ် လိုအပ်ချက်များ အပြောင်းအလဲများ ဖြစ်ပေါ်ပြီး အပြောင်းအလဲများ၏ အကျိုးသက်ရောက်မှုကို ပြန်လည်စမ်းသပ်ရန် လိုအပ်သည့်အခါ လိုအပ်ချက် အဆင့် 3 မှ 5 အထိ ဒီဇိုင်းလုပ်ငန်းစဉ်အတွင်း ထပ်ခါတလဲလဲ လုပ်ဆောင်နိုင်ပါသည်။

ကောက်ချက်။

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

အဆုံးထိဖတ်ချင်သူများအတွက် နမူနာပုံစံ အလုပ်လုပ်ပုံကို ပြသသည့် ဗီဒီယိုတစ်ခုသို့ လင့်ခ်ချိတ်ပါ။

source: www.habr.com