متحرڪ ماڊلنگ دوران ٽيڪنيڪل وضاحتن جي ضرورتن جي خودڪار تصديق

موضوع کي جاري رکڻ ”تنهنجو ڪهڙو ثبوت آهي؟اچو ته ٻئي پاسي کان رياضياتي ماڊلنگ جي مسئلي کي ڏسو. بعد ۾ اسان کي يقين ڏياريو ويو آهي ته ماڊل زندگي جي گهر جي سچائي سان لاڳاپيل آهي، اسان بنيادي سوال جو جواب ڏئي سگهون ٿا: "ڇا، حقيقت ۾، اسان وٽ هتي آهي؟" جڏهن هڪ ٽيڪنيڪل اعتراض جو نمونو ٺاهي، اسان عام طور تي پڪ ڪرڻ چاهيون ٿا ته هي اعتراض اسان جي اميدن تي پورو لهندو. هن مقصد لاء، عمل جي متحرڪ حساب ڪتاب ڪيا ويا آهن ۽ نتيجن جي ضرورتن سان مقابلو ڪيو ويو آهي. هي هڪ ڊجيٽل ٽوئن آهي، هڪ مجازي پروٽوٽائپ، وغيره. فيشن وارا ننڍڙا ماڻهو جيڪي، ڊزائن اسٽيج تي، اهو مسئلو حل ڪن ٿا ته ڪيئن يقيني بڻايون ته اسان حاصل ڪيو جيڪو اسان رٿيو آهي.

اسان ڪيئن جلدي پڪ ڪري سگهون ٿا ته اسان جو سسٽم بلڪل اهو آهي جيڪو اسان ٺاهيو، ڇا اسان جي ڊيزائن اڏامي يا فلوٽ ٿيندي؟ ۽ جيڪڏهن اهو اڏامي، ڪيترو بلند؟ ۽ جيڪڏهن اهو تري ٿو، ڪيترو ڊگهو؟

هي آرٽيڪل ٽيڪنيڪل عمارت جي ضرورتن جي تعميل جي تصديق جي خودڪار تي بحث ڪري ٿو جڏهن ٽيڪنيڪل سسٽم جي متحرڪ ماڊل ٺاهي رهيا آهن. مثال طور، اچو ته هڪ جهاز جي ايئر کولنگ سسٽم لاء ٽيڪنيڪل وضاحتن جي هڪ عنصر کي ڏسو.

اسان انهن ضرورتن تي غور ڪريون ٿا جيڪي عددي طور تي ظاهر ڪري سگهجن ٿيون ۽ رياضياتي طور تي هڪ مخصوص حساب ڪتاب جي ماڊل جي بنياد تي تصديق ٿيل آهن. اهو واضح آهي ته اهو صرف ڪنهن به ٽيڪنيڪل سسٽم لاء عام گهرجن جو حصو آهي، پر اهو انهن جي جانچ ڪرڻ تي آهي ته اسان وقت، اعصاب ۽ پئسا خرچ ڪندا آهيون اعتراض جي متحرڪ ماڊل ٺاهڻ تي.

جڏهن هڪ دستاويز جي صورت ۾ ٽيڪنيڪل گهرجن کي بيان ڪندي، ڪيترن ئي قسمن جي مختلف ضرورتن کي فرق ڪري سگهجي ٿو، جن مان هر هڪ جي ضرورتن جي مڪمل ٿيڻ جي خودڪار تصديق جي ٺهڻ لاء مختلف طريقن جي ضرورت آهي.

مثال طور، هن ننڍڙي پر حقيقي ضرورتن جي سيٽ تي غور ڪريو:

1. پاڻي جي علاج واري نظام جي داخلا تي فضائي هوا جو گرمي پد:
   پارڪنگ لاٽ ۾ - مائنس 35 کان 35 ºС تائين،
   پرواز ۾ - مائنس 35 کان 39 ºС تائين.
2. اڏام ۾ هوا جو جامد دٻاءُ 700 کان 1013 GPa (526 کان 760 mm Hg تائين) آهي.
3. پرواز ۾ SVO ايئر انٽيڪ جي داخلا تي ڪل ايئر پريشر 754 کان 1200 GPa (566 کان 1050 mm Hg تائين) آهي.
4. ٿڌي هوا جو گرمي پد:
   پارڪنگ جي جڳھ ۾ - 27 ºС کان وڌيڪ نه، ٽيڪنيڪل بلاڪ لاء - 29 ºС کان وڌيڪ نه،
   پرواز ۾ - 25 ºС کان وڌيڪ نه، ٽيڪنيڪل بلاڪ لاء - 27 ºС کان وڌيڪ نه.
5. ٿڌي هوا جو وهڪرو:
   جڏهن پارڪ - گهٽ ۾ گهٽ 708 ڪلوگرام / ايڇ،
   پرواز ۾ - 660 ڪلوگرام / ايڇ کان گهٽ ناهي.
6. اوزار جي ڪمري ۾ هوا جي گرمي پد 60 ºС کان وڌيڪ نه آهي.
7. ٿڌي هوا ۾ سٺي آزاد نمي جو مقدار 2 گرام / ڪلوگرام خشڪ هوا کان وڌيڪ ناهي.

جيتوڻيڪ ضرورتن جي هن محدود سيٽ جي اندر، گهٽ ۾ گهٽ ٻه ڀاڱا آهن جن کي سسٽم ۾ مختلف طريقي سان سنڀالڻ جي ضرورت آهي:

• سسٽم جي آپريٽنگ حالتن لاء گهرجون (شق 1-3)؛
• سسٽم لاءِ پيرا ميٽرڪ گهرجن (شق 3-7).

سسٽم جي آپريٽنگ حالتن جي گهرج
ماڊلنگ جي دوران ترقي يافته نظام لاء خارجي حالتون حد جي حالتن جي طور تي يا عام سسٽم جي آپريشن جي نتيجي ۾ بيان ڪري سگھجن ٿيون.
متحرڪ تخليق ۾، ان کي يقيني بڻائڻ ضروري آهي ته مخصوص آپريٽنگ حالتون نقلي عمل سان ڍڪيل آهن.

Parametric سسٽم گهرجون
اهي گهرجون خود سسٽم طرفان مهيا ڪيل پيٽرولر آهن. ماڊلنگ جي عمل جي دوران، اسان حاصل ڪري سگھون ٿا اهي پيرا ميٽرز حساب جي نتيجن جي طور تي ۽ پڪ ڪري سگهون ٿا ته گهربل ضرورتون هر مخصوص حساب ڪتاب ۾ پوريون ڪيون وڃن.

ضرورتن جي سڃاڻپ ۽ ڪوڊنگ

ضرورتن سان ڪم ڪرڻ جي آسانيءَ لاءِ، موجوده معيار سفارش ڪن ٿا ته هر ضرورت لاءِ هڪ سڃاڻپ ڪندڙ مقرر ڪيو وڃي. سڃاڻپ ڪندڙ کي تفويض ڪرڻ وقت، هڪ متحد ڪوڊنگ سسٽم استعمال ڪرڻ تمام ضروري آهي.

گهربل ڪوڊ صرف هڪ نمبر ٿي سگهي ٿو جيڪو ضرورت جي آرڊر نمبر جي نمائندگي ڪري ٿو، يا ان ۾ گهربل قسم جو ڪوڊ، سسٽم يا يونٽ جو ڪوڊ جنهن تي اهو لاڳو ٿئي ٿو، هڪ پيرا ميٽر ڪوڊ، هڪ مقام ڪوڊ، ۽ ٻيو ڪجهه به انجنيئر تصور ڪري سگهي ٿو. (انڪوڊنگ جي استعمال لاءِ مضمون ڏسو)

جدول 1 ضرورتن جي ڪوڊنگ جو ھڪڙو سادو مثال مهيا ڪري ٿو.

1. ضرورتن جي ذريعن جو ڪوڊ R-Requirements TK؛
2. ضرورتن جو ڪوڊ قسم اي - گهرجون - ماحولياتي معيار، يا آپريٽنگ حالتون
   S - سسٽم پاران مهيا ڪيل گهرجن؛
3. جهاز جي اسٽيٽس ڪوڊ 0 - ڪو به، G - پارڪ، F - پرواز ۾؛
4. جسماني پيٽرولر جو قسم ڪوڊ T - گرمي پد، P - دٻاء، G - وهڪري جي شرح، نمي H؛
5. گهربل سيريل نمبر.

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 kg/h کان گهٽ ناهي
RSFG01	ٿڌي هوا جو وهڪرو: اڏام ۾ 660 kg/h کان گهٽ ناهي
RS0T01	اوزار خاني ۾ هوا جي گرمي پد 60 ºС کان وڌيڪ ناهي
RSH01	ٿڌي هوا ۾ سٺي آزاد نمي جو مقدار 2 گرام / ڪلوگرام خشڪ هوا کان وڌيڪ ناهي

ضرورتن جي تصديق سسٽم ڊيزائن.

هر ڊيزائن جي گهرج لاءِ هڪ الورورٿم هوندو آهي جنهن ۾ ڊيزائن جي پيراميٽرن جي مطابقت ۽ ضرورتن ۾ بيان ڪيل پيرا ميٽرز جو اندازو لڳايو وڃي. وڏي ۽ وڏي، ڪنهن به ڪنٽرول سسٽم ۾ هميشه صرف ڊفالٽ جي ضرورتن جي جانچ ڪرڻ لاء الگورتھم شامل آهن. ۽ جيتوڻيڪ ڪنهن به ريگيوليٽر انهن تي مشتمل آهي. جيڪڏهن گرمي پد جي حدن کان ٻاهر وڃي ٿي، ايئر ڪنڊيشنر ڦري ٿو. اهڙيء طرح، ڪنهن به ضابطي جو پهريون مرحلو چيڪ ڪرڻ آهي ته ڇا پيٽرولر گهرجن گهرجن کي پورا ڪن ٿا.

۽ جيئن ته تصديق هڪ الگورٿم آهي، پوءِ اسان اهي ئي اوزار ۽ اوزار استعمال ڪري سگهون ٿا جيڪي اسان ڪنٽرول پروگرام ٺاهڻ لاءِ استعمال ڪندا آهيون. مثال طور، SimInTech ماحول توهان کي پروجيڪٽ پيڪيجز ٺاهڻ جي اجازت ڏئي ٿو جنهن ۾ ماڊل جي مختلف حصن تي مشتمل آهي، الڳ منصوبن جي صورت ۾ عمل ڪيو ويو آهي (آبجیکٹ ماڊل، ڪنٽرول سسٽم ماڊل، ماحولياتي ماڊل، وغيره).

ضرورتن جي تصديق جو منصوبو هن معاملي ۾ ساڳيو الگورتھم منصوبو بڻجي ويندو آهي ۽ ماڊل پيڪيج سان ڳنڍيل آهي. ۽ متحرڪ ماڊلنگ موڊ ۾، اهو ٽيڪنيڪل وضاحتن جي گهرجن جي تعميل لاء هڪ تجزيو انجام ڏئي ٿو.

سسٽم ڊيزائن جو هڪ ممڪن مثال شڪل 1 ۾ ڏيکاريل آهي.

شڪل 1. هڪ تصديق واري منصوبي جي ڊيزائن جو مثال.

بس ڪنٽرول الورورٿمز وانگر، گهربل شيٽ جي سيٽ جي طور تي ٺاهي سگھجن ٿيون. ڍانچي ماڊلنگ ماحول ۾ الگورتھم سان ڪم ڪرڻ جي سهولت لاءِ جيئن SimInTech، Simulink، AmeSim، ذيلي ماڊلز جي صورت ۾ ملٽي ليول ڍانچي ٺاهڻ جي صلاحيت استعمال ڪئي ويندي آهي. هن تنظيم کي مختلف ضرورتن کي گروپن ۾ شامل ڪرڻ ممڪن بڻائي ٿو ضرورتن جي هڪ صف سان ڪم کي آسان ڪرڻ لاءِ، جيئن ڪنٽرول الگورتھم لاءِ ڪيو ويندو آهي (ڏسو تصوير 2).

شڪل 2. ضرورتن جي تصديق واري ماڊل جي درجه بندي جي جوڙجڪ.

مثال طور، غور هيٺ ڪيس ۾، ٻن گروپن ۾ فرق آهي: ماحول لاء گهرجون ۽ گهرجون سڌي نظام لاء. تنهن ڪري، هڪ ٻه-سطح ڊيٽا جي جوڙجڪ استعمال ڪيو ويندو آهي: ٻه گروپ، جن مان هر هڪ الورورٿم جو هڪ پتي آهي.

ڊيٽا کي ماڊل سان ڳنڍڻ لاء، هڪ معياري اسڪيم هڪ سگنل ڊيٽابيس ٺاهڻ لاء استعمال ڪيو ويندو آهي، جيڪو پروجيڪٽ جي حصن جي وچ ۾ مٽائڻ لاء ڊيٽا محفوظ ڪري ٿو.

سافٽ ويئر ٺاهڻ ۽ جانچ ڪرڻ وقت، سينسرز جي پڙهائي (حقيقي سسٽم سينسر جا اينالاگ) جيڪي ڪنٽرول سسٽم پاران استعمال ڪيا ويا آهن هن ڊيٽابيس ۾ رکيل آهن.
ٽيسٽ پروجيڪٽ لاءِ، متحرڪ ماڊل ۾ ڳڻپ ڪيل ڪي به پيٽرولر ساڳي ڊيٽابيس ۾ محفوظ ڪري سگھجن ٿا ۽ اهڙيءَ طرح چيڪ ڪرڻ لاءِ استعمال ڪيو وڃي ٿو ته ضرورتون پوريون ٿيون آهن.

انهي صورت ۾، متحرڪ ماڊل پاڻ کي ڪنهن به رياضياتي ماڊلنگ سسٽم ۾ يا هڪ قابل عمل پروگرام جي صورت ۾ پڻ انجام ڏئي سگهجي ٿو. صرف گهرج آهي سافٽ ويئر انٽرفيس جي موجودگي کي خارجي ماحول کي ماڊلنگ ڊيٽا جاري ڪرڻ لاءِ.

شڪل 3. تصديق واري منصوبي کي پيچيده ماڊل سان ڳنڍيندي.

بنيادي ضرورتن جي تصديق واري شيٽ جو هڪ مثال شڪل 4 ۾ پيش ڪيو ويو آهي. ڊولپر جي نقطي نظر کان، اهو هڪ روايتي حساب ڪتاب آهي جنهن تي گهرج جي تصديق الورورٿم کي گرافي طور تي پيش ڪيو ويو آهي.

شڪل 4. گهربل چيڪ شيٽ.

چيڪ شيٽ جا مکيه حصا تصوير 5 ۾ بيان ڪيا ويا آهن. چيڪ الگورٿم اهڙي طرح ٺهيل آهي جيئن ڪنٽرول الگورٿم جي ڊيزائن ڊاگرامس سان. ساڄي پاسي ڊيٽابيس مان سگنل پڙهڻ لاء هڪ بلاڪ آهي. هي بلاڪ تخليق دوران سگنل ڊيٽابيس تائين رسائي ڪري ٿو.

حاصل ڪيل سگنلن جي ضرورتن جي تصديق جي حالتن جي حساب سان تجزيو ڪيو وڃي ٿو. انهي حالت ۾، اوچائي تجزيو ڪيو ويندو آهي جهاز جي پوزيشن کي طئي ڪرڻ لاء (ڇا اهو پارڪ يا پرواز ۾ آهي). هن مقصد لاء، توهان استعمال ڪري سگهو ٿا ٻين سگنلن ۽ ماڊل جي حساب ڪتاب جي ماپ.

تصديق جي شرطن ۽ پيٽرولن جي چڪاس ڪئي پئي وڃي معياري تصديق واري بلاڪ ڏانهن منتقل ڪيا ويا آهن، جن ۾ انهن پيٽرولن جو تجزيو ڪيو ويو آهي مخصوص گهرجن جي تعميل لاء. نتيجن کي سگنل ڊيٽابيس ۾ رڪارڊ ڪيو ويو آهي انهي طريقي سان ته اهي خودڪار طور تي هڪ چيڪ لسٽ ٺاهڻ لاء استعمال ڪري سگھجن ٿيون.

شڪل 5. ضرورتن جي جوڙجڪ جي تصديق جي حساب ڪتاب جي شيٽ.

ٽيسٽ ٿيڻ جا پيرا ميٽر لازمي طور تي ڊيٽابيس ۾ موجود سگنلن کي استعمال نٿا ڪن، جيڪي سميوليشن جي عمل دوران حساب ڪيل پيرا ميٽرز ذريعي ڪنٽرول ڪيا وڃن ٿا. ڪجھ به اسان کي مسودي جي ضرورتن جي فريم ورڪ اندر اضافي حساب ڪتاب ڪرڻ کان روڪي ٿو، جيئن اسين تصديق جي شرطن کي ڳڻيو ٿا.

مثال طور، هي گهرج:

ھدف ڏانھن پرواز دوران اصلاحي نظام جي چالون جو تعداد 5 کان وڌيڪ نه ٿيڻ گھرجي، ۽ اصلاحي نظام جي ڪل آپريٽنگ وقت 30 سيڪنڊن کان وڌيڪ نه ھجڻ گھرجي.

انهي صورت ۾، شروع جي تعداد کي منهن ڏيڻ لاء هڪ الگورتھم ۽ مجموعي آپريٽنگ وقت جي ضرورتن جي ڊيزائن جي شڪل ۾ شامل ڪيو ويو آهي.

عام ضرورتن جي تصديق واري بلاڪ.

هر معياري گهربل چيڪ باڪس هڪ خاص قسم جي گهرج جي پورو ٿيڻ جي حساب سان ٺهيل آهي. مثال طور، ماحولياتي گهرجن ۾ شامل آهي وسيع آپريٽنگ گرمي پد جي حد تائين جڏهن پارڪ ۽ پرواز ۾. هن بلاڪ کي لازمي طور تي ماڊل ۾ هوائي گرمي پد حاصل ڪرڻ گهرجي ۽ اهو طئي ڪرڻ گهرجي ته ڇا هي پيٽرولر مخصوص درجه حرارت جي حد کي ڍڪي ٿو. </p>

بلاڪ ۾ ٻه ان پٽ بندرگاهن، پرم ۽ حالت شامل آهن.

پهرين هڪ کي کارايو ويندو آهي پيٽرول سان چڪاس ڪيو پيو وڃي. هن معاملي ۾، "ٻاهرين گرمي پد".

هڪ Boolean variable ٻئي بندرگاهن کي فراهم ڪيو ويو آهي - چيڪ ڪرڻ لاءِ شرط.

جيڪڏهن صحيح (1) ٻئي ان پٽ تي ملي ٿي، ته پوءِ بلاڪ هڪ گهربل تصديق جي حساب ڪتاب کي انجام ڏئي ٿو.

جيڪڏهن ٻيو ان پٽ FALSE (0) وصول ڪري ٿو، ته پوءِ ٽيسٽ جون شرطون پوريون نه ٿيون ٿين. اهو ضروري آهي ته حساب جي حالتن کي حساب ۾ ورتو وڃي. اسان جي حالت ۾، هي ان پٽ استعمال ڪيو ويندو آهي چيڪ کي فعال يا غير فعال ڪرڻ لاءِ ماڊل جي حالت جي لحاظ سان. جيڪڏهن جهاز سميوليشن دوران زمين تي آهي، ته پوء پرواز سان لاڳاپيل گهرجن جي جانچ نه ڪئي وئي آهي، ۽ ان جي برعڪس - جيڪڏهن جهاز پرواز ۾ آهي، پوء اسٽينڊ تي آپريشن سان لاڳاپيل گهرجن جي جانچ نه ڪئي وئي آهي.

هي ان پٽ پڻ استعمال ڪري سگهجي ٿو جڏهن ماڊل کي ترتيب ڏيو، مثال طور حساب جي شروعاتي اسٽيج تي. جڏهن ماڊل کي گهربل حالت ۾ آندو ويندو آهي، چيڪ بلاڪ بند ڪيا ويندا آهن، پر جيئن ئي سسٽم گهربل آپريٽنگ موڊ تي پهچي ٿو، چيڪ بلاڪ کي چالو ڪيو ويو آهي.

ھن بلاڪ جا پيرا ميٽر آھن:

• حد جون حالتون: اپر (UpLimit) ۽ لوئر (DownLimit) حد جون حدون جيڪي چيڪ ٿيڻ گهرجن؛
• گهربل سسٽم جي نمائش جو وقت حد جي حدن تي (TimeInterval) سيڪنڊن ۾؛
• درخواست جي ID ReqName؛
• حد کان وڌي وڃڻ جي اجازت Out_range هڪ Boolean variable آهي جيڪو اهو طئي ڪري ٿو ته ڇا چيڪ ڪيل حد کان وڌيڪ قيمت گهربل جي خلاف ورزي آهي.

ڪجهه حالتن ۾، امتحان جي قيمت جي پيداوار اشارو ڪري ٿي ته سسٽم کي مارجن آهي ۽ شايد ان جي آپريٽنگ رينج کان ٻاهر ڪم ڪري رهيو آهي. ٻين حالتن ۾، هڪ پيداوار جو مطلب آهي ته سسٽم سيٽ پوائنٽن کي حد اندر رکڻ جي قابل ناهي.

شڪل 6. هڪ عام ملڪيت چيڪ بلاڪ ڊاگرام ۽ ان جي پيٽرولن ۾.

ھن بلاڪ جي حساب جي نتيجي ۾، نتيجو متغير ٺاھيو ويو آھي ٻاھر تي، جيڪو ھيٺين قدر وٺندو آھي:

• 0 - ڪو به نه، قدر بيان نه ڪيو ويو آهي؛
• 1 - rDone، گهرج پوري ڪئي وئي آهي؛
• 2 - rFault، گهرج پوري نه ڪئي وئي آهي.

بلاڪ تصوير تي مشتمل آهي:

• سڃاڻپ ڪندڙ متن؛
• ماپ جي حدن جي ماپن جي ڊجيٽل ڊسپلي؛
• رنگ جي سڃاڻپ ڪندڙ پيٽرولر جي حالت.

بلاڪ جي اندر ٿي سگهي ٿو بلڪه پيچيده منطقي انفرنس سرڪٽ.

مثال طور، تصوير 6 ۾ ڏيکاريل يونٽ جي آپريٽنگ درجه حرارت جي حد کي جانچڻ لاء، اندروني سرڪٽ کي شڪل 7 ۾ ڏيکاريل آهي.

شڪل 7. درجه حرارت جي حد مقرر ڪرڻ واري يونٽ جو اندروني خاڪو.

سرڪٽ بلاڪ جي اندر، بلاڪ جي پيٽرولن ۾ بيان ڪيل ملڪيت استعمال ٿيل آهن.
ضرورتن جي تعميل جي تجزيي ڪرڻ کان علاوه، بلاڪ جي اندروني آريگرام ۾ هڪ گراف شامل آهي جيڪو تخليقي نتيجن کي ظاهر ڪرڻ لاء ضروري آهي. هي گراف ٻنهي جي حساب سان ڏسڻ لاءِ ۽ حساب کان پوءِ نتيجن جو تجزيو ڪرڻ لاءِ استعمال ٿي سگهي ٿو.

حساب ڪتاب جا نتيجا بلاڪ جي ٻاھرين ڏانھن منتقل ڪيا ويا آھن ۽ گڏوگڏ ھڪڙي عام رپورٽ فائل ۾ رڪارڊ ڪيا ويا آھن، جيڪا پوري منصوبي جي نتيجن جي بنياد تي ٺاھي وئي آھي. (ڏسو تصوير 8)

تخليق جي نتيجن جي بنياد تي ٺاهيل رپورٽ جو هڪ مثال هڪ ڏنل فارميٽ جي مطابق ٺاهيل html فائل آهي. فارميٽ کي ترتيب ڏئي سگھجي ٿو ھڪڙي خاص تنظيم پاران قبول ڪيل فارميٽ ۾.

سرڪٽ بلاڪ جي اندر، بلاڪ جي پيٽرولن ۾ بيان ڪيل ملڪيت استعمال ٿيل آهن.
ضرورتن جي تعميل جي تجزيي ڪرڻ کان علاوه، بلاڪ جي اندروني آريگرام ۾ هڪ گراف شامل آهي جيڪو تخليقي نتيجن کي ظاهر ڪرڻ لاء ضروري آهي. هي گراف ٻنهي جي حساب سان ڏسڻ لاءِ ۽ حساب کان پوءِ نتيجن جو تجزيو ڪرڻ لاءِ استعمال ٿي سگهي ٿو.

حساب ڪتاب جا نتيجا بلاڪ جي ٻاھرين ڏانھن منتقل ڪيا ويا آھن ۽ گڏوگڏ ھڪڙي عام رپورٽ فائل ۾ رڪارڊ ڪيا ويا آھن، جيڪا پوري منصوبي جي نتيجن جي بنياد تي ٺاھي وئي آھي. (ڏسو تصوير 8)

تخليق جي نتيجن جي بنياد تي ٺاهيل رپورٽ جو هڪ مثال هڪ ڏنل فارميٽ جي مطابق ٺاهيل html فائل آهي. فارميٽ کي ترتيب ڏئي سگھجي ٿو ھڪڙي خاص تنظيم پاران قبول ڪيل فارميٽ ۾.

شڪل 8. هڪ رپورٽ فائل جو مثال نقلي نتيجن جي بنياد تي.

هن مثال ۾، رپورٽ فارم سڌو سنئون پروجيڪٽ جي ملڪيت ۾ ترتيب ڏني وئي آهي، ۽ ٽيبل ۾ فارميٽ گلوبل پروجيڪٽ سگنل جي طور تي مقرر ڪيو ويو آهي. انهي صورت ۾، SimInTech پاڻ کي رپورٽ قائم ڪرڻ جو مسئلو حل ڪري ٿو، ۽ فائل کي لکڻ جي نتيجن لاء بلاڪ رپورٽ فائل کي لکڻ لاء اهي لائين استعمال ڪري ٿو.

شڪل 9. گلوبل پروجيڪٽ سگنلن ۾ رپورٽ فارميٽ کي ترتيب ڏيڻ

ضرورتن لاءِ سگنل ڊيٽابيس استعمال ڪرڻ.

ملڪيت جي سيٽنگن سان ڪم کي خودڪار ڪرڻ لاء، هڪ معياري جوڙجڪ ٺاهي وئي آهي سگنل ڊيٽابيس ۾ هر عام بلاڪ لاء. (ڏسو تصوير 10)

شڪل 10. هڪ سگنل ڊيٽابيس ۾ گهربل چيڪ بلاڪ جي جوڙجڪ جو مثال.

سگنل ڊيٽابيس مهيا ڪري ٿو:

• سڀني ضروري سسٽم جي ضرورتن جي پيٽرولن کي محفوظ ڪرڻ.
• موجوده پروجيڪٽ جي ضرورتن کي آسان ڏسڻ سان مخصوص پيٽرولن ۽ موجوده ماڊلنگ جا نتيجا.
• اسڪرپٽنگ پروگرامنگ ٻولي استعمال ڪندي ھڪڙي بلاڪ يا بلاڪ جي ھڪڙي گروپ کي ترتيب ڏيڻ. سگنل ڊيٽابيس ۾ تبديليون تبديلين جي ڪري بلاڪ ملڪيت جي قدرن ۾ ڊراگرام ۾.
• ٽيڪسٽ وضاحتن کي محفوظ ڪرڻ، ٽيڪنيڪل وضاحتن جي شين جي لنڪ يا ضرورتن جي انتظامي نظام ۾ سڃاڻپ ڪندڙ.

ضرورتن لاءِ سگنل ڊيٽابيس جي جوڙجڪ کي آساني سان ترتيب ڏئي سگھجي ٿو ٽئين پارٽي جي ضرورتن جي انتظام واري نظام سان ڪم ڪرڻ لاءِ. ضرورتن جي انتظام جي نظام سان رابطي جو هڪ عام خاڪو تصوير 11 ۾ پيش ڪيو ويو آهي.

شڪل 11. ضرورتن جي انتظام جي نظام سان رابطي جو خاڪو.

SimInTech ٽيسٽ پروجيڪٽ ۽ گهربل ڪنٽرول سسٽم جي وچ ۾ رابطي جو سلسلو هن ريت آهي:

1. حوالن جا شرط ضرورتن ۾ ورهايل آهن.
2. ٽيڪنيڪل وضاحتن جي ضرورتن جي نشاندهي ڪئي وئي آهي جيڪي ٽيڪنيڪل پروسيس جي رياضياتي ماڊلنگ ذريعي تصديق ڪري سگھجن ٿيون.
3. منتخب ٿيل گهرجن جون خاصيتون معياري بلاڪ جي جوڙجڪ ۾ SimInTech سگنل ڊيٽابيس ڏانهن منتقل ڪيا ويا آهن (مثال طور، وڌ ۾ وڌ ۽ گهٽ ۾ گهٽ درجه حرارت).
4. حساب ڪتاب جي عمل دوران، ساخت جي ڊيٽا منتقل ڪئي وئي آهي بلاڪ ڊزائين ڊراگرام، تجزيو ڪيو ويندو آهي ۽ نتيجن کي هڪ سگنل ڊيٽابيس ۾ محفوظ ڪيو ويندو آهي.
5. هڪ دفعو ڳڻپيوڪر مڪمل ٿيڻ کان پوء، تجزيي جا نتيجا گهربل انتظامي نظام ڏانهن منتقل ڪيا ويا آهن.

ضرورتن جا مرحلا 3 کان 5 تائين ڊيزائين جي عمل دوران ورجائي سگهجن ٿا جڏهن ڊيزائن ۽/يا ضرورتن ۾ تبديليون اچن ٿيون ۽ تبديلين جي اثر کي ٻيهر جانچڻ جي ضرورت آهي.

نتيجو.

• سسٽم جي ٺاهيل پروٽوٽائپ کي ٽيڪنالاجي وضاحتن جي گهرجن جي تعميل لاء موجوده ماڊل جي تجزيو جي وقت ۾ هڪ اهم گهٽتائي فراهم ڪري ٿي.
• تجويز ڪيل ٽيسٽنگ ٽيڪنالاجي اڳ ۾ ئي موجود متحرڪ ماڊل استعمال ڪري ٿي ۽ ڪنهن به متحرڪ ماڊلز لاءِ به استعمال ٿي سگهي ٿي، بشمول جيڪي SimInTech ماحول ۾ نه ڪيل آهن.
• بيچ ڊيٽا آرگنائيزيشن کي استعمال ڪندي توهان کي ماڊل ڊولپمينٽ سان متوازي ضرورتن جي تصديق پيڪيجز ٺاهڻ جي اجازت ڏئي ٿي، يا انهن پيڪيجز کي ماڊل ڊولپمينٽ لاءِ ٽيڪنيڪل وضاحتن جي طور تي پڻ استعمال ڪريو.
• ٽيڪنالاجي کي ضم ٿي سگھي ٿو موجوده ضرورتن جي انتظام جي سسٽم سان بغير اهم خرچن جي.

آخر تائين پڙهڻ وارن لاءِ، هڪ وڊيو ڏانهن لنڪ ڏيکاريو ته ڪيئن پروٽوٽائپ ڪم ڪري ٿو.

جو ذريعو: www.habr.com