د موضوع دوام راځئ چې له بل اړخ څخه د ریاضياتي ماډلینګ ستونزې ته وګورو. وروسته له دې چې موږ باوري شو چې ماډل د ژوند د کور حقیقت سره مطابقت لري، موږ کولی شو اصلي پوښتنې ته ځواب ووایو: "څه شی، واقعیا، موږ دلته لرو؟" کله چې د تخنیکي څیز ماډل جوړ کړئ، موږ معمولا غواړو ډاډ ترلاسه کړو چې دا اعتراض به زموږ هیلې پوره کړي. د دې هدف لپاره ، د پروسو متحرک محاسبې ترسره کیږي او پایله یې د اړتیاو سره پرتله کیږي. دا یو ډیجیټل دوه ګونی دی، یو مجازی پروټوټایپ، او نور. د فیشن وړ کوچني هلکان چې د ډیزاین په مرحله کې، دا ستونزه حل کوي چې څنګه ډاډ ترلاسه کړو چې موږ هغه څه ترلاسه کوو چې موږ پلان کړي.
موږ څنګه کولی شو په چټکۍ سره ډاډ ترلاسه کړو چې زموږ سیسټم په ریښتیا هغه څه دی چې موږ یې ډیزاین کوو، ایا زموږ ډیزاین به پرواز یا تیر شي؟ او که پرواز کوي، څومره لوړ؟ او که تیریږي، څومره ژور؟
دا مقاله د تخنیکي سیسټمونو متحرک ماډلونو رامینځته کولو پرمهال د تخنیکي ودانۍ اړتیاو سره د موافقت تصدیق اتومات کولو په اړه بحث کوي. د مثال په توګه، راځئ چې د الوتکې د هوا یخولو سیسټم لپاره د تخنیکي مشخصاتو یو عنصر وګورو.
موږ هغه اړتیاوې په پام کې نیسو چې د شمیرې له مخې څرګند کیدی شي او په ریاضي کې د ځانګړي محاسبې ماډل پراساس تصدیق کیدی شي. دا روښانه ده چې دا یوازې د هر تخنیکي سیسټم لپاره د عمومي اړتیاو برخه ده، مګر دا د دوی په چک کولو کې ده چې موږ د شیانو متحرک ماډلونو په جوړولو کې وخت، اعصاب او پیسې مصرفوو.
کله چې د سند په بڼه تخنیکي اړتیاوې بیانوي، د مختلفو اړتیاو ډیری ډولونه توپیر کیدی شي، چې هر یو یې د اړتیاوو د بشپړولو اتوماتیک تایید لپاره مختلف طریقې ته اړتیا لري.
د مثال په توګه، د اړتیاو دا کوچنۍ خو حقیقي سیټ په پام کې ونیسئ:
- د اوبو د درملنې سیسټم ته د ننوتلو په وخت کې د اتموسفیر هوا تودوخه:
په پارکینګ کې - له منفي 35 څخه تر 35 ºС پورې ،
په الوتنه کې - له منفي 35 څخه تر 39 ºС پورې. - په الوتنه کې د اتموسفیر هوا جامد فشار له 700 څخه تر 1013 GPa (526 څخه تر 760 mm Hg پورې) دی.
- په الوتنه کې د SVO هوایی انټیک ته په ننوتلو کې د هوا ټول فشار له 754 څخه تر 1200 GPa (566 څخه تر 1050 mm Hg پورې) دی.
- د هوا د تودوخې درجه:
په پارکینګ کې - له 27 ºС څخه ډیر نه ، د تخنیکي بلاکونو لپاره - له 29 ºС څخه ډیر نه ،
په الوتنه کې - له 25 ºС څخه ډیر نه ، د تخنیکي بلاکونو لپاره - له 27 ºС څخه ډیر نه. - د سړې هوا جریان:
کله چې پارک شوی وي - لږترلږه 708 kg/h،
په الوتنه کې - له 660 کیلوګرامه / ساعت څخه کم نه. - د وسیلې په برخو کې د هوا تودوخه له 60 ºС څخه زیاته نه ده.
- په سړه هوا کې د وړیا رطوبت اندازه له 2 g/kg وچه هوا څخه زیاته نه وي.
حتی د دې محدودو اړتیاو دننه، لږترلږه دوه کټګورۍ شتون لري چې په سیسټم کې په مختلف ډول اداره کولو ته اړتیا لري:
- د سیسټم د عملیاتي شرایطو لپاره اړتیاوې (فقرې 1-3)؛
- د سیسټم لپاره پارامیټریک اړتیاوې (د 3-7 بند).
د سیسټم عملیاتي شرایطو اړتیاوې
د ماډلینګ پرمهال رامینځته شوي سیسټم لپاره بهرني شرایط د حد شرایطو یا د عمومي سیسټم عملیاتو پایله کې مشخص کیدی شي.
په متحرک سمولیشن کې، دا اړینه ده چې ډاډ ترلاسه شي چې مشخص عملیاتي شرایط د سمولو پروسې لخوا پوښل شوي.
د پارامیټریک سیسټم اړتیاوې
دا اړتیاوې د سیسټم لخوا چمتو شوي پیرامیټونه دي. د ماډلینګ پروسې په جریان کې ، موږ کولی شو دا پیرامیټونه د محاسبې پایلو په توګه ترلاسه کړو او ډاډ ترلاسه کړو چې اړتیاوې په هر ځانګړي محاسبه کې پوره کیږي.
د اړتیاو پیژندنه او کوډ کول
د اړتیاو سره د کار کولو اسانتیا لپاره، موجوده معیارونه وړاندیز کوي چې هرې اړتیا ته یو پیژندونکی وټاکي. کله چې پیژندونکي وټاکئ، نو دا خورا مطلوب دی چې د متحد کوډ کولو سیسټم وکاروئ.
د اړتیا کوډ کیدای شي په ساده ډول یو شمیر وي چې د اړتیا د ترتیب شمیره استازیتوب کوي، یا دا د اړتیا ډول لپاره کوډ لري، د سیسټم یا واحد لپاره کوډ چې دا پلي کیږي، د پیرامیټر کوډ، د موقعیت کوډ، او بل څه چې انجینر یې تصور کولی شي. (د کوډ کولو کارولو لپاره مقاله وګورئ)
جدول 1 د اړتیاو کوډ کولو ساده مثال وړاندې کوي.
- د اړتیاو د سرچینې کوډ R-Requirements TK؛
- د کوډ ډول اړتیاوې E - اړتیاوې - د چاپیریال پیرامیټونه، یا عملیاتي شرایط
S - د سیسټم لخوا چمتو شوي اړتیاوې؛ - د الوتکې حالت کوډ 0 – کوم، G – پارک شوی، F – په الوتنه کې؛
- د فزیکي پیرامیټر ډول کوډ T - تودوخه، P - فشار، G - د جریان کچه، رطوبت H؛
- د اړتیا سیریل نمبر.
| ID اړتیاو |
شرح | پارسيم |
| REGT01 | د اوبو یخولو سیسټم ته د ننوتلو په وخت کې د هوا تودوخه: په پارکینګ کې - له منفي 35ºС څخه. تر 35ºС پورې | |
| REFT01 | د هوا دفاعي سیسټم ته د ننوتلو په وخت کې د اتموسفیر هوا تودوخه: په الوتنه کې - له منفي 35 ºС څخه تر 39 ºС پورې. | |
| REFP01 | په الوتنه کې د جامد اتموسفیر هوا فشار له 700 څخه تر 1013 hPa (د 526 څخه تر 760 mm Hg پورې) دی. | |
| REFP02 | په الوتنه کې د SVO هوایی انټیک ته په ننوتلو کې د هوا ټول فشار له 754 څخه تر 1200 hPa (د 566 څخه تر 1050 mm Hg پورې) دی. | |
| RSGT01 | د یخ هوا تودوخه: کله چې پارک د 27 ºС څخه ډیر نه وي | |
| RSGT02 | د یخ هوا تودوخه: په پارکینګ کې ، د تخنیکي واحدونو لپاره له 29 ºС څخه ډیر نه وي | |
| RSFT01 | په الوتنه کې د هوا تودوخه د 25 درجو څخه ډیر نه وي | |
| RSFT02 | د یخ هوا تودوخه: په الوتنه کې، د تخنیکي واحدونو لپاره له 27 ºС څخه ډیر نه | |
| RSGG01 | د یخ هوا جریان: کله چې پارک شوی وي له 708 کیلو ګرامه / ساعت څخه کم نه وي | |
| RSFG01 | د یخ هوا جریان: په الوتنه کې له 660 kg/h څخه کم نه وي | |
| RS0T01 | په وسایلو کې د هوا تودوخه د 60 درجې څخه ډیر نه وي | |
| RSH01 | په سړه هوا کې د وړیا رطوبت اندازه له 2 g/kg وچه هوا څخه زیاته نه وي |
د اړتیاو تایید سیسټم ډیزاین.
د هرې ډیزاین اړتیا لپاره د ډیزاین پیرامیټونو او په اړتیا کې مشخص شوي پیرامیټرې د مطابقت ارزولو لپاره الګوریتم شتون لري. په لویه کچه، د کنټرول هر سیسټم تل د اړتیاو چک کولو لپاره الګوریتم لري په ساده ډول په ډیفالټ. او حتی کوم تنظیم کونکي دوی لري. که چیرې تودوخه د حد څخه بهر وي، د هوا کنډیشنر بدلیږي. په دې توګه، د هرې مقررې لومړۍ مرحله دا ده چې وګوري چې آیا پیرامیټونه اړتیاوې پوره کوي.
او څرنګه چې تایید یو الګوریتم دی، نو موږ کولی شو ورته وسایل او وسایل وکاروو چې موږ یې د کنټرول پروګرامونو جوړولو لپاره کاروو. د مثال په توګه، د SimInTech چاپیریال تاسو ته اجازه درکوي د پروژې کڅوړې رامینځته کړئ چې د ماډل مختلف برخې لري، د جلا پروژو په بڼه اجرا شوي (د اعتراض ماډل، د کنټرول سیسټم ماډل، د چاپیریال ماډل، او نور).
پدې حالت کې د اړتیاو تایید پروژه ورته الګوریتم پروژه کیږي او د ماډل کڅوړې سره وصل کیږي. او د متحرک ماډلینګ حالت کې دا د تخنیکي مشخصاتو اړتیاو سره مطابقت لپاره تحلیل ترسره کوي.
د سیسټم ډیزاین احتمالي مثال په 1 شکل کې ښودل شوی.
شکل 1. د تصدیق پروژې ډیزاین بیلګه.
لکه د کنټرول الګوریتمونو په څیر، اړتیاوې د شیټونو سیټ په توګه چمتو کیدی شي. د ساختماني ماډلینګ چاپیریالونو کې د الګوریتمونو سره د کار کولو اسانتیا لپاره لکه SimInTech، Simulink، AmeSim، د فرعي ماډلونو په بڼه د څو کچې جوړښتونو رامینځته کولو وړتیا کارول کیږي. دا سازمان دا ممکنه کوي چې مختلف اړتیاوې په سیټونو کې ګروپ کړي ترڅو د اړتیاو د لړۍ سره کار ساده کړي، لکه څنګه چې د کنټرول الګوریتم لپاره ترسره کیږي (وګورئ انځور. 2).
شکل 2. د اړتیاو د تایید ماډل درجه بندي جوړښت.
د مثال په توګه، په پام کې نیول شوي قضیه کې، دوه ګروپونه توپیر لري: د چاپیریال اړتیاوې او د سیسټم لپاره مستقیم اړتیاوې. له همدې امله، د دوه کچې ډاټا جوړښت کارول کیږي: دوه ډلې، چې هر یو یې د الګوریتم پاڼی دی.
د ماډل سره د ډیټا وصل کولو لپاره ، د سیګنال ډیټابیس رامینځته کولو لپاره معیاري سکیم کارول کیږي ، کوم چې د پروژې برخو ترمینځ د تبادلې لپاره ډیټا ذخیره کوي.
کله چې د سافټویر رامینځته کول او ازموینه کول ، د سینسر لوستل (د ریښتیني سیسټم سینسرونو انلاګونه) چې د کنټرول سیسټم لخوا کارول کیږي پدې ډیټابیس کې ځای په ځای شوي.
د ازموینې پروژې لپاره ، کوم پیرامیټونه چې په متحرک ماډل کې محاسبه شوي په ورته ډیټابیس کې زیرمه کیدی شي او پدې توګه د دې لپاره کارول کیږي چې ایا اړتیاوې پوره کیږي.
په دې حالت کې، متحرک ماډل پخپله په هر ریاضياتي ماډلینګ سیسټم کې یا حتی د اجرا وړ پروګرام په بڼه اجرا کیدی شي. یوازینۍ اړتیا بهرنۍ چاپیریال ته د ماډلینګ ډیټا صادرولو لپاره د سافټویر انٹرفیس شتون دی.
شکل 3. د تایید پروژې پیچلې ماډل سره نښلول.
د لومړنیو اړتیاو د تایید پاڼې یوه بیلګه په 4 شکل کې وړاندې کیږي. د پراختیا کونکي له نظره، دا د دودیز محاسبې ډیاګرام دی چې د اړتیاو تصدیق کولو الګوریتم په ګرافیک ډول وړاندې کیږي.
شکل 4. د اړتیاوو چک پاڼه.
د چیک شیټ اصلي برخې په 5 شکل کې تشریح شوي. د چک الګوریتم د کنټرول الګوریتم ډیزاین ډیاګرامونو سره ورته جوړ شوی. په ښي خوا کې د ډیټابیس څخه د سیګنالونو لوستلو لپاره یو بلاک شتون لري. دا بلاک د سمولو پرمهال سیګنال ډیټابیس ته لاسرسی لري.
ترلاسه شوي سیګنالونه د اړتیاو تصدیق شرایطو محاسبه کولو لپاره تحلیل شوي. په دې حالت کې، د الوتکې د موقعیت معلومولو لپاره د لوړوالی تحلیل ترسره کیږي (که چیرې دا پارک وي یا په الوتنه کې). د دې هدف لپاره، تاسو کولی شئ د ماډل نور سیګنالونه او حساب شوي پیرامیټونه وکاروئ.
د تایید شرایط او پیرامیټرې چې معاینه کیږي د معیاري تصدیق بلاکونو ته لیږدول کیږي، په کوم کې چې دا پیرامیټونه د ټاکل شوي اړتیاو سره مطابقت لپاره تحلیل کیږي. پایلې د سیګنال ډیټابیس کې په داسې ډول ثبت شوي چې دوی په اتوماتيک ډول د چک لیست رامینځته کولو لپاره کارول کیدی شي.
شکل 5. د اړتیاو د تایید محاسبه پاڼه جوړښت.
هغه پیرامیټونه چې ازمول کیږي لازمي ندي چې په ډیټابیس کې موجود سیګنالونه وکاروي ، کوم چې د سمولو پروسې په جریان کې محاسبه شوي پیرامیټرو لخوا کنټرول کیږي. هیڅ شی موږ ته د مسودې اړتیاو په چوکاټ کې د اضافي محاسبې ترسره کولو مخه نه نیسي، لکه څنګه چې موږ د تصدیق شرایط محاسبه کوو.
د مثال په توګه، دا اړتیا:
هدف ته د الوتنې په جریان کې د سمون سیسټم د فعالیتونو شمیر باید له 5 څخه ډیر نه وي، او د سمون سیسټم ټول عملیاتي وخت باید د 30 ثانیو څخه زیات نشي.
په دې حالت کې، د پیل شمیرې او ټول عملیاتي وخت سره د مبارزې لپاره الګوریتم د اړتیاو ډیزاین ډیاګرام کې اضافه شوی.
د عادي اړتیاو تایید بلاک.
د هر معیاري اړتیا چیک باکس د یو ځانګړي ډول اړتیا پوره کولو محاسبه کولو لپاره ډیزاین شوی. د مثال په توګه، د چاپیریال اړتیاو کې د محیطي عملیاتي تودوخې یو لړ لړۍ شامله ده کله چې پارک او پرواز کې. دا بلاک باید په ماډل کې د هوا تودوخې د پیرامیټر په توګه ترلاسه کړي او معلومه کړي چې ایا دا پیرامیټر د تودوخې ټاکل شوې حد پوښي.
په بلاک کې دوه ان پټ بندرونه شامل دي، پارم او حالت.
لومړی یې د پیرامیټر چیک کولو سره تغذیه کیږي. په دې حالت کې، "بهرنۍ تودوخه".
د بولین متغیر دوهم بندر ته چمتو کیږي - د چک ترسره کولو حالت.
که چیرې ریښتیا (1) په دویم ان پټ کې ترلاسه شي، نو بلاک د اړتیا تصدیق محاسبه ترسره کوي.
که دوهم ان پټ FALSE (0) ترلاسه کړي، نو بیا د ازموینې شرایط نه پوره کیږي. دا اړینه ده چې د محاسبې شرایط په پام کې ونیول شي. زموږ په قضیه کې، دا آخذه د موډل حالت پورې اړه لري د چک فعال یا غیر فعالولو لپاره کارول کیږي. که الوتکه د سمولو په جریان کې په ځمکه کې وي، نو د الوتنې اړوند اړتیاوې نه چک کیږي، او برعکس - که الوتکه په الوتنې کې وي، نو بیا په موقف کې د عملیاتو پورې اړوند اړتیاوې نه چک کیږي.
دا آخذه هم کارول کیدی شي کله چې ماډل ترتیب کړئ، د بیلګې په توګه د محاسبې په لومړي پړاو کې. کله چې موډل اړین حالت ته راوړل شي، د چک بلاکونه غیر فعال شوي، مګر هرڅومره ژر چې سیسټم اړین عملیاتي حالت ته ورسیږي، د چک بلاکونه فعال شوي.
د دې بلاک پیرامیټونه په لاندې ډول دي:
- د حد شرایط: پورتنۍ (UpLimit) او ښکته (DownLimit) حد محدودیتونه چې باید وڅیړل شي؛
- په ثانيو کې د حدودو په حدودو کې د سيسټم د اړتيا وړ وخت (TimeInterval)؛
- د ID ReqName غوښتنه وکړئ؛
- د حد څخه د تیریدو جواز Out_range یو بولین متغیر دی چې دا ټاکي چې ایا د چک شوي حد څخه ډیر ارزښت د اړتیا څخه سرغړونه ده.
په ځینو مواردو کې، د ازموینې ارزښت محصول ښیي چې سیسټم یو څه حاشیه لري او ممکن د خپل عملیاتي حد څخه بهر فعالیت وکړي. په نورو قضیو کې، یو محصول پدې معنی دی چې سیسټم نشي کولی سیټ پوائنټونه په حد کې وساتي.
شکل 6. په ډیاګرام او د هغې پیرامیټونو کې د ملکیت چیک بلاک.
د دې بلاک د محاسبې په پایله کې، د پایلې متغیر په محصول کې رامینځته کیږي، کوم چې لاندې ارزښتونه اخلي:
- 0 - هیڅ نه، ارزښت ندی تعریف شوی؛
- 1 - بشپړ شوی، اړتیا پوره شوې؛
- 2 - r غلطي، اړتیا نه پوره کیږي.
د بلاک انځور کې شامل دي:
- پیژندونکی متن؛
- د اندازه کولو محدودیتونو پیرامیټونو ډیجیټل ښودل؛
- د پیرامیټر حالت رنګ پیژندونکی.
د بلاک دننه ممکن یو پیچلي منطقي تحلیل سرکټ وي.
د مثال په توګه، په 6 شکل کې ښودل شوي واحد د عملیاتي تودوخې رینج چک کولو لپاره، داخلي سرکټ په 7 شکل کې ښودل شوی.
شکل 7. د حرارت درجه ټاکلو واحد داخلي ډیاګرام.
د سرکټ بلاک دننه، د بلاک پیرامیټونو کې مشخص شوي ملکیتونه کارول کیږي.
د اړتیاو سره مطابقت تحلیل کولو سربیره، د بلاک داخلي ډیاګرام د سمولو پایلو ښودلو لپاره اړین ګراف لري. دا ګراف دواړه د محاسبې پرمهال د لیدو لپاره او د محاسبې وروسته د پایلو تحلیل لپاره کارول کیدی شي.
د محاسبې پایلې د بلاک محصول ته لیږدول کیږي او په ورته وخت کې د عمومي راپور فایل کې ثبت شوي، کوم چې د ټولې پروژې د پایلو پراساس رامینځته کیږي. (8 انځور وګورئ)
د سمولو پایلو پراساس رامینځته شوي راپور یوه بیلګه د html فایل دی چې د ورکړل شوي فارمیټ مطابق رامینځته شوی. بڼه کیدای شي په خپلسري ډول د یوې ځانګړې ادارې لخوا منل شوي شکل ته ترتیب شي.
د سرکټ بلاک دننه، د بلاک پیرامیټونو کې مشخص شوي ملکیتونه کارول کیږي.
د اړتیاو سره مطابقت تحلیل کولو سربیره، د بلاک داخلي ډیاګرام د سمولو پایلو ښودلو لپاره اړین ګراف لري. دا ګراف دواړه د محاسبې پرمهال د لیدو لپاره او د محاسبې وروسته د پایلو تحلیل لپاره کارول کیدی شي.
د محاسبې پایلې د بلاک محصول ته لیږدول کیږي او په ورته وخت کې د عمومي راپور فایل کې ثبت شوي، کوم چې د ټولې پروژې د پایلو پراساس رامینځته کیږي. (8 انځور وګورئ)
د سمولو پایلو پراساس رامینځته شوي راپور یوه بیلګه د html فایل دی چې د ورکړل شوي فارمیټ مطابق رامینځته شوی. بڼه کیدای شي په خپلسري ډول د یوې ځانګړې ادارې لخوا منل شوي شکل ته ترتیب شي.
شکل 8. د سمولو پایلو پر بنسټ د راپور فایل بیلګه.
په دې مثال کې، د راپور فورمه په مستقیم ډول د پروژې ملکیتونو کې ترتیب شوې، او په جدول کې بڼه د نړیوالې پروژې نښې په توګه ټاکل شوې. په دې حالت کې، SimInTech پخپله د راپور ترتیب کولو ستونزه حل کوي، او فایل ته د پایلو لیکلو لپاره بلاک د راپور فایل ته لیکلو لپاره دا کرښې کاروي.
شکل 9. د نړیوال پروژې سیګنالونو کې د راپور بڼه ترتیب کول
د اړتیاو لپاره د سیګنال ډیټابیس کارول.
د ملکیت تنظیماتو سره د کار اتومات کولو لپاره ، د هر ځانګړي بلاک لپاره د سیګنال ډیټابیس کې یو معیاري جوړښت رامینځته شوی. (د 10 شکل وګورئ)
شکل 10. د سیګنال ډیټابیس کې د اړتیا چیک بلاک جوړښت بیلګه.
د سیګنال ډیټابیس چمتو کوي:
- د ټولو اړین سیسټم اړتیاو پیرامیټونو ذخیره کول.
- د ټاکل شوي پیرامیټونو او اوسني ماډلینګ پایلو څخه د موجوده پروژې اړتیاو اسانه لید.
- د سکریپټینګ پروګرام کولو ژبې په کارولو سره د یو بلاک یا د بلاکونو ګروپ تنظیم کول. د سیګنال ډیټابیس کې بدلونونه په ډیاګرام کې د بلاک ملکیت ارزښتونو کې د بدلون لامل کیږي.
- د متن توضیحاتو ذخیره کول ، د اړتیاو مدیریت سیسټم کې د تخنیکي مشخصاتو توکو یا پیژندونکو سره اړیکې.
د اړتیاو لپاره د سیګنال ډیټابیس جوړښتونه په اسانۍ سره د دریمې ډلې اړتیاو مدیریت سیسټم سره کار کولو لپاره تنظیم کیدی شي. د اړتیاو مدیریت سیسټمونو سره د متقابل عمل عمومي ډیاګرام په 11 شکل کې وړاندې شوی.
شکل 11. د اړتیاو مدیریت سیسټم سره د متقابل عمل ډیاګرام.
د SimInTech ازموینې پروژې او د اړتیا کنټرول سیسټم تر مینځ د متقابل عمل ترتیب په لاندې ډول دی:
- د حوالې شرایط په اړتیاو ویشل شوي.
- د تخنیکي مشخصاتو اړتیاوې په ګوته شوي چې د تخنیکي پروسو ریاضیاتی ماډلینګ لخوا تایید کیدی شي.
- د ټاکل شوي اړتیاو ځانګړتیاوې د معیاري بلاکونو په جوړښت کې د SimInTech سیګنال ډیټابیس ته لیږدول کیږي (د بیلګې په توګه، اعظمي او لږترلږه تودوخه).
- د محاسبې پروسې په جریان کې ، د جوړښت ډیټا د بلاک ډیزاین ډیاګرامونو ته لیږدول کیږي ، تحلیل ترسره کیږي او پایلې په سیګنال ډیټابیس کې زیرمه کیږي.
- یوځل چې محاسبه بشپړه شي ، د تحلیل پایلې د اړتیاو مدیریت سیسټم ته لیږدول کیږي.
د اړتیاو مرحلې له 3 څخه تر 5 پورې ممکن د ډیزاین پروسې په جریان کې تکرار شي کله چې ډیزاین او / یا اړتیاو کې بدلونونه رامینځته کیږي او د بدلون اغیزې باید بیا ازموینه وشي.
پایلې
- د سیسټم رامینځته شوی پروټوټایپ د تخنیکي مشخصاتو اړتیاو سره مطابقت لپاره د موجوده ماډلونو تحلیل په وخت کې د پام وړ کمښت چمتو کوي.
- وړاندیز شوی ټیسټ ټیکنالوژي دمخه موجود متحرک ماډلونه کاروي او حتی د هر متحرک ماډلونو لپاره هم کارول کیدی شي ، پشمول هغه چې د SimInTech چاپیریال کې ندي ترسره شوي.
- د بیچ ډیټا تنظیم کارول تاسو ته اجازه درکوي د ماډل پراختیا سره موازي د اړتیاو تایید کڅوړې رامینځته کړئ ، یا حتی دا کڅوړې د ماډل پراختیا لپاره د تخنیکي مشخصاتو په توګه وکاروئ.
- ټیکنالوژي د پام وړ لګښتونو پرته د موجوده اړتیاو مدیریت سیسټمونو سره مدغم کیدی شي.
د هغو کسانو لپاره چې تر پایه یې لوستل
سرچینه: www.habr.com