متحرک ماڈلنگ کے دوران تکنیکی وضاحتوں کی ضروریات کی خودکار تصدیق

تھیم کو جاری رکھنا ’’تمہارا ثبوت کیا ہے؟‘‘، آئیے دوسری طرف سے ریاضیاتی ماڈلنگ کے مسئلے کو دیکھتے ہیں۔ جب ہمیں یقین ہو جائے کہ ماڈل زندگی کی ہوم اسپن سچائی سے مطابقت رکھتا ہے، تو ہم اس اہم سوال کا جواب دے سکتے ہیں: "ہمارے پاس یہاں کیا ہے؟" کسی تکنیکی چیز کا ماڈل بناتے وقت، ہم عام طور پر اس بات کو یقینی بنانا چاہتے ہیں کہ یہ چیز ہماری توقعات پر پورا اترے گی۔ اس مقصد کے لیے، عمل کے متحرک حسابات کیے جاتے ہیں اور نتائج کا تقاضوں کے ساتھ موازنہ کیا جاتا ہے۔ یہ ایک ڈیجیٹل جڑواں، ایک ورچوئل پروٹو ٹائپ وغیرہ ہے۔ فیشن کے چھوٹے لڑکے جو، ڈیزائن کے مرحلے پر، اس مسئلے کو حل کرتے ہیں کہ اس بات کو کیسے یقینی بنایا جائے کہ ہم نے جو منصوبہ بنایا ہے اسے حاصل کریں۔

ہم کس طرح جلدی سے اس بات کو یقینی بنا سکتے ہیں کہ ہمارا سسٹم بالکل وہی ہے جو ہم ڈیزائن کرتے ہیں، کیا ہمارا ڈیزائن اڑ جائے گا یا تیرے گا؟ اور اگر یہ اڑتا ہے تو کتنا اونچا؟ اور اگر تیرتا ہے تو کتنا گہرا؟

یہ مضمون تکنیکی نظام کے متحرک ماڈلز بناتے وقت تکنیکی عمارت کی ضروریات کی تعمیل کی تصدیق کے آٹومیشن پر بحث کرتا ہے۔ مثال کے طور پر، آئیے ہوائی جہاز کے ایئر کولنگ سسٹم کے لیے تکنیکی تفصیلات کے ایک عنصر کو دیکھتے ہیں۔

ہم ان تقاضوں پر غور کرتے ہیں جن کا عددی طور پر اظہار کیا جا سکتا ہے اور حساب کے مخصوص ماڈل کی بنیاد پر ریاضیاتی طور پر تصدیق کی جا سکتی ہے۔ یہ واضح ہے کہ یہ کسی بھی تکنیکی نظام کے لیے عمومی تقاضوں کا صرف ایک حصہ ہے، لیکن یہ ان کی جانچ پڑتال پر ہے کہ ہم شے کے متحرک ماڈل بنانے میں وقت، اعصاب اور پیسہ صرف کرتے ہیں۔

تکنیکی تقاضوں کو دستاویز کی شکل میں بیان کرتے وقت، مختلف تقاضوں کی کئی اقسام میں فرق کیا جا سکتا ہے، جن میں سے ہر ایک کو تقاضوں کی تکمیل کی خودکار تصدیق کی تشکیل کے لیے مختلف طریقوں کی ضرورت ہوتی ہے۔

مثال کے طور پر، ضروریات کے اس چھوٹے لیکن حقیقت پسندانہ سیٹ پر غور کریں:

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)۔

سسٹم آپریٹنگ حالات کی ضروریات
ماڈلنگ کے دوران تیار کیے جانے والے نظام کے بیرونی حالات کو باؤنڈری کنڈیشنز کے طور پر یا عام سسٹم کے آپریشن کے نتیجے میں بیان کیا جا سکتا ہے۔
متحرک تخروپن میں، یہ یقینی بنانا ضروری ہے کہ مخصوص آپریٹنگ حالات تخروپن کے عمل میں شامل ہوں۔

پیرامیٹرک سسٹم کی ضروریات
یہ ضروریات خود سسٹم کے ذریعہ فراہم کردہ پیرامیٹرز ہیں۔ ماڈلنگ کے عمل کے دوران، ہم ان پیرامیٹرز کو حساب کے نتائج کے طور پر حاصل کر سکتے ہیں اور اس بات کو یقینی بنا سکتے ہیں کہ ہر مخصوص حساب میں تقاضے پورے ہوں۔

ضروریات کی شناخت اور کوڈنگ

ضروریات کے ساتھ کام کرنے میں آسانی کے لیے، موجودہ معیار ہر ضرورت کے لیے ایک شناخت کنندہ کو تفویض کرنے کی تجویز کرتے ہیں۔ شناخت کنندگان کو تفویض کرتے وقت، یہ ایک متحد کوڈنگ سسٹم کا استعمال کرنا انتہائی ضروری ہے۔

ضرورت کا کوڈ محض ایک عدد ہو سکتا ہے جو ضرورت کے آرڈر نمبر کی نمائندگی کرتا ہو، یا اس میں ضرورت کی قسم کے لیے کوڈ، سسٹم یا یونٹ کے لیے ایک کوڈ جس پر یہ لاگو ہوتا ہے، ایک پیرامیٹر کوڈ، مقام کا کوڈ، اور انجینئر کچھ اور سوچ سکتا ہے۔ (انکوڈنگ کے استعمال کے لیے مضمون دیکھیں)

جدول 1 ضروریات کوڈنگ کی ایک سادہ مثال فراہم کرتا ہے۔

1. ضروریات کے ماخذ کا کوڈ R-ضروریات TK؛
2. کوڈ کی قسم کی ضروریات E - ضروریات - ماحولیاتی پیرامیٹرز، یا آپریٹنگ حالات
   S - سسٹم کی طرف سے فراہم کردہ ضروریات؛
3. ہوائی جہاز کا اسٹیٹس کوڈ 0 - کوئی بھی، جی - پارک، 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 کلوگرام فی گھنٹہ سے کم نہ ہو۔
RSFG01	ٹھنڈک ہوا کا بہاؤ: پرواز میں 660 کلوگرام فی گھنٹہ سے کم نہیں۔
RS0T01	آلے کے کمپارٹمنٹ میں ہوا کا درجہ حرارت 60 ºС سے زیادہ نہیں۔
RSH01۔	ٹھنڈی ہوا میں ٹھیک مفت نمی کی مقدار 2 جی/کلوگرام خشک ہوا سے زیادہ نہیں ہے۔

تقاضوں کی تصدیق کے نظام کے ڈیزائن.

ہر ڈیزائن کی ضرورت کے لیے ڈیزائن کے پیرامیٹرز اور ضرورت میں بیان کردہ پیرامیٹرز کی خط و کتابت کا اندازہ لگانے کے لیے ایک الگورتھم ہوتا ہے۔ بڑے پیمانے پر، کسی بھی کنٹرول سسٹم میں صرف ڈیفالٹ کے ذریعے ضروریات کی جانچ کے لیے ہمیشہ الگورتھم ہوتے ہیں۔ اور یہاں تک کہ کوئی بھی ریگولیٹر ان پر مشتمل ہے۔ اگر درجہ حرارت حد سے باہر جاتا ہے، تو ایئر کنڈیشنر آن ہو جاتا ہے۔ اس طرح، کسی بھی ضابطے کا پہلا مرحلہ یہ جانچنا ہے کہ آیا پیرامیٹرز ضروریات کو پورا کرتے ہیں۔

اور چونکہ تصدیق ایک الگورتھم ہے، اس لیے ہم وہی ٹولز اور ٹولز استعمال کر سکتے ہیں جو ہم کنٹرول پروگرام بنانے کے لیے استعمال کرتے ہیں۔ مثال کے طور پر، SimInTech ماحول آپ کو ماڈل کے مختلف حصوں پر مشتمل پروجیکٹ پیکجز بنانے کی اجازت دیتا ہے، جو علیحدہ پروجیکٹس (آبجیکٹ ماڈل، کنٹرول سسٹم ماڈل، ماحولیات کا ماڈل، وغیرہ) کی شکل میں بنائے جاتے ہیں۔

اس معاملے میں ضروریات کی توثیق کا منصوبہ ایک ہی الگورتھم پروجیکٹ بن جاتا ہے اور ماڈل پیکیج سے منسلک ہوتا ہے۔ اور متحرک ماڈلنگ موڈ میں یہ تکنیکی وضاحتوں کی ضروریات کی تعمیل کے لیے تجزیہ کرتا ہے۔

سسٹم ڈیزائن کی ایک ممکنہ مثال تصویر 1 میں دکھائی گئی ہے۔

تصویر 1. تصدیقی منصوبے کے ڈیزائن کی مثال۔

بالکل اسی طرح جیسے کنٹرول الگورتھم کے لیے، ضروریات کو شیٹس کے سیٹ کے طور پر تیار کیا جا سکتا ہے۔ سٹرکچرل ماڈلنگ ماحول جیسے SimInTech، Simulink، AmeSim میں الگورتھم کے ساتھ کام کرنے کی سہولت کے لیے، ذیلی ماڈلز کی شکل میں ملٹی لیول ڈھانچے بنانے کی صلاحیت کا استعمال کیا جاتا ہے۔ یہ تنظیم مختلف ضروریات کو سیٹوں میں گروپ کرنا ممکن بناتی ہے تاکہ ضرورتوں کی ایک صف کے ساتھ کام کو آسان بنایا جا سکے، جیسا کہ کنٹرول الگورتھم کے لیے کیا جاتا ہے (تصویر 2 دیکھیں)۔

شکل 2. تقاضوں کی توثیق کے ماڈل کا درجہ بندی کا ڈھانچہ۔

مثال کے طور پر، زیر غور معاملے میں، دو گروہوں کو ممتاز کیا جاتا ہے: ماحول کے لیے تقاضے اور نظام کے لیے براہ راست تقاضے۔ لہذا، ایک دو سطحی ڈیٹا ڈھانچہ استعمال کیا جاتا ہے: دو گروہ، جن میں سے ہر ایک الگورتھم کا ایک پتی ہے۔

ڈیٹا کو ماڈل سے منسلک کرنے کے لیے، سگنل ڈیٹا بیس بنانے کے لیے ایک معیاری اسکیم استعمال کی جاتی ہے، جو پروجیکٹ کے حصوں کے درمیان تبادلے کے لیے ڈیٹا کو اسٹور کرتی ہے۔

سافٹ ویئر بناتے اور جانچتے وقت، سینسرز کی ریڈنگ (حقیقی نظام کے سینسر کے اینالاگ) جو کنٹرول سسٹم کے ذریعے استعمال ہوتے ہیں اس ڈیٹا بیس میں رکھے جاتے ہیں۔
ٹیسٹ پروجیکٹ کے لیے، ڈائنامک ماڈل میں شمار کیے گئے کسی بھی پیرامیٹرز کو ایک ہی ڈیٹا بیس میں اسٹور کیا جا سکتا ہے اور اس طرح یہ جانچنے کے لیے استعمال کیا جاتا ہے کہ آیا ضروریات پوری ہوتی ہیں۔

اس صورت میں، ڈائنامک ماڈل کو خود کسی بھی ریاضیاتی ماڈلنگ سسٹم میں یا ایک قابل عمل پروگرام کی شکل میں بھی عمل میں لایا جا سکتا ہے۔ واحد ضرورت بیرونی ماحول کو ماڈلنگ ڈیٹا جاری کرنے کے لیے سافٹ ویئر انٹرفیس کی موجودگی ہے۔

تصویر 3. تصدیقی پروجیکٹ کو پیچیدہ ماڈل سے جوڑنا۔

بنیادی تقاضوں کی توثیق شیٹ کی ایک مثال شکل 4 میں پیش کی گئی ہے۔ ڈویلپر کے نقطہ نظر سے، یہ ایک روایتی حساب کا خاکہ ہے جس پر تقاضوں کی تصدیق کا الگورتھم تصویری طور پر پیش کیا گیا ہے۔

چترا 4. تقاضے چیک شیٹ۔

چیک شیٹ کے اہم حصوں کو شکل 5 میں بیان کیا گیا ہے۔ چیک الگورتھم کنٹرول الگورتھم کے ڈیزائن ڈایاگرام کی طرح تشکیل دیا گیا ہے۔ دائیں طرف ڈیٹا بیس سے سگنل پڑھنے کے لیے ایک بلاک ہے۔ یہ بلاک تخروپن کے دوران سگنل ڈیٹا بیس تک رسائی حاصل کرتا ہے۔

ضروریات کی تصدیق کی شرائط کا حساب لگانے کے لیے موصول ہونے والے سگنلز کا تجزیہ کیا جاتا ہے۔ اس صورت میں، ہوائی جہاز کی پوزیشن کا تعین کرنے کے لیے اونچائی کا تجزیہ کیا جاتا ہے (چاہے وہ کھڑا ہو یا پرواز میں)۔ اس مقصد کے لیے، آپ ماڈل کے دوسرے سگنلز اور حسابی پیرامیٹرز استعمال کر سکتے ہیں۔

جانچ کی جا رہی تصدیقی شرائط اور پیرامیٹرز کو معیاری تصدیقی بلاکس میں منتقل کر دیا جاتا ہے، جس میں ان پیرامیٹرز کو مخصوص تقاضوں کی تعمیل کے لیے تجزیہ کیا جاتا ہے۔ نتائج کو سگنل ڈیٹا بیس میں اس طرح ریکارڈ کیا جاتا ہے کہ انہیں خود بخود چیک لسٹ بنانے کے لیے استعمال کیا جا سکتا ہے۔

شکل 5. تقاضوں کی توثیق کیلکولیشن شیٹ کا ڈھانچہ۔

جن پیرامیٹرز کی جانچ کی جائے گی وہ ضروری طور پر ڈیٹا بیس میں موجود سگنلز کا استعمال نہیں کرتے ہیں، جنہیں نقلی عمل کے دوران شمار کیے گئے پیرامیٹرز کے ذریعے کنٹرول کیا جاتا ہے۔ کچھ بھی ہمیں مسودہ کی ضروریات کے فریم ورک کے اندر اضافی حساب کتاب کرنے سے نہیں روکتا، جیسا کہ ہم تصدیق کی شرائط کا حساب لگاتے ہیں۔

مثال کے طور پر، یہ ضرورت:

ہدف کی طرف پرواز کے دوران اصلاحی نظام کے فعال ہونے کی تعداد 5 سے زیادہ نہیں ہونی چاہیے، اور اصلاحی نظام کا کل آپریٹنگ وقت 30 سیکنڈ سے زیادہ نہیں ہونا چاہیے۔

اس صورت میں، شروع کی تعداد اور کل آپریٹنگ وقت کا مقابلہ کرنے کے لیے ایک الگورتھم کو ضروریات کے ڈیزائن ڈایاگرام میں شامل کیا جاتا ہے۔

عام تقاضوں کی تصدیق کا بلاک۔

ہر معیاری ضرورت کے چیک باکس کو ایک خاص قسم کی ضرورت کی تکمیل کا حساب لگانے کے لیے ڈیزائن کیا گیا ہے۔ مثال کے طور پر، ماحولیاتی تقاضوں میں پارکنگ اور پرواز کے دوران محیطی آپریٹنگ درجہ حرارت کی ایک رینج شامل ہوتی ہے۔ اس بلاک کو ماڈل میں ہوا کا درجہ حرارت بطور پیرامیٹر حاصل کرنا چاہیے اور اس بات کا تعین کرنا چاہیے کہ آیا یہ پیرامیٹر درجہ حرارت کی مخصوص حد کا احاطہ کرتا ہے۔</p>

بلاک میں دو ان پٹ پورٹس، پرم اور کنڈیشن شامل ہیں۔

پہلے کو پیرامیٹر کی جانچ پڑتال کے ساتھ کھلایا جاتا ہے۔ اس صورت میں، "بیرونی درجہ حرارت".

ایک بولین متغیر دوسری پورٹ کو فراہم کیا جاتا ہے - چیک کرنے کی شرط۔

اگر TRUE (1) دوسرے ان پٹ پر موصول ہوتا ہے، تو بلاک ضرورت کی تصدیق کا حساب کرتا ہے۔

اگر دوسرا ان پٹ FALSE (0) وصول کرتا ہے، تو ٹیسٹ کی شرائط پوری نہیں ہوتی ہیں۔ یہ ضروری ہے تاکہ حساب کتاب کی شرائط کو مدنظر رکھا جا سکے۔ ہمارے معاملے میں، یہ ان پٹ ماڈل کی حالت کے لحاظ سے چیک کو فعال یا غیر فعال کرنے کے لیے استعمال کیا جاتا ہے۔ اگر سمولیشن کے دوران ہوائی جہاز زمین پر ہے، تو پرواز سے متعلق ضروریات کی جانچ نہیں کی جاتی ہے، اور اس کے برعکس - اگر طیارہ پرواز میں ہے، تو اسٹینڈ پر آپریشن سے متعلق ضروریات کی جانچ نہیں کی جاتی ہے۔

یہ ان پٹ ماڈل کو ترتیب دیتے وقت بھی استعمال کیا جا سکتا ہے، مثال کے طور پر حساب کے ابتدائی مرحلے میں۔ جب ماڈل کو مطلوبہ حالت میں لایا جاتا ہے، تو چیک بلاکس کو غیر فعال کر دیا جاتا ہے، لیکن جیسے ہی سسٹم مطلوبہ آپریٹنگ موڈ تک پہنچتا ہے، چیک بلاکس کو آن کر دیا جاتا ہے۔

اس بلاک کے پیرامیٹرز یہ ہیں:

• حد کی شرائط: اوپری (UpLimit) اور نچلی (Down Limit) رینج کی حدیں جن کی جانچ ہونی چاہیے۔
• باؤنڈری رینجز (ٹائم انٹرول) میں سیکنڈوں میں سسٹم کی نمائش کا وقت؛
• درخواست ID ReqName؛
• حد سے تجاوز کرنے کی اجازت Out_range ایک بولین متغیر ہے جو اس بات کا تعین کرتا ہے کہ آیا چیک شدہ حد سے زیادہ قدر ضرورت کی خلاف ورزی ہے۔

بعض صورتوں میں، ٹیسٹ ویلیو آؤٹ پٹ سے پتہ چلتا ہے کہ سسٹم میں کچھ مارجن ہے اور ہوسکتا ہے کہ وہ اپنی آپریٹنگ رینج سے باہر کام کر رہا ہو۔ دوسرے معاملات میں، آؤٹ پٹ کا مطلب یہ ہے کہ سسٹم سیٹ پوائنٹس کو رینج میں رکھنے سے قاصر ہے۔

تصویر 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