تأیید خودکار الزامات TOR در فرآیند شبیه سازی پویا

ادامه موضوع شواهد شما چیست؟، بیایید از طرف دیگر به مسئله مدل سازی ریاضی نگاه کنیم. پس از اینکه متقاعد شدیم که این مدل با حقیقت زندگی خانگی مطابقت دارد، می‌توانیم به سؤال اصلی پاسخ دهیم: "در اینجا دقیقاً چه چیزی داریم؟" هنگام ایجاد یک مدل از یک شی فنی، معمولاً می خواهیم مطمئن شویم که این شیء انتظارات ما را برآورده می کند. برای این منظور محاسبات دینامیکی فرآیندها انجام شده و نتیجه با الزامات مقایسه می شود. این یک دوقلو دیجیتال، یک نمونه اولیه مجازی و غیره است. بچه های کوچولو شیک که در مرحله طراحی، این مشکل را حل می کنند که چگونه مطمئن شویم به آنچه برنامه ریزی کرده ایم می رسیم.

چگونه می توانیم به سرعت مطمئن شویم که سیستم ما دقیقاً همان چیزی است که طراحی می کنیم، آیا طرح ما پرواز می کند یا شناور؟ و اگر پرواز کند، چقدر بلند است؟ و اگر شناور است چقدر عمق دارد؟

این مقاله در مورد اتوماسیون تأیید انطباق با الزامات یک ساختمان فنی هنگام ایجاد مدل های پویا از سیستم های فنی بحث می کند. به عنوان مثال، اجازه دهید به یک عنصر از مشخصات فنی یک سیستم خنک کننده هوای هواپیما نگاه کنیم.

ما آن دسته از الزاماتی را در نظر می گیریم که می توانند به صورت عددی بیان شوند و بر اساس یک مدل محاسباتی خاص به صورت ریاضی تأیید شوند. واضح است که این تنها بخشی از الزامات کلی برای هر سیستم فنی است، اما برای بررسی آنها است که زمان، اعصاب و هزینه را برای ایجاد مدل های پویا از شی صرف می کنیم.

هنگام توصیف الزامات فنی در قالب یک سند، می توان چندین نوع الزامات مختلف را متمایز کرد که هر یک به رویکردهای متفاوتی برای تشکیل تأیید خودکار برآورده شدن الزامات نیاز دارند.

به عنوان مثال، این مجموعه کوچک اما واقعی از الزامات را در نظر بگیرید:

1. دمای هوای اتمسفر در ورودی سیستم تصفیه آب:
   در پارکینگ - از منفی 35 تا 35 ºС،
   در پرواز - از منفی 35 تا 39 ºС.
2. فشار ساکن هوای اتمسفر در پرواز از 700 تا 1013 گیگا پاسکال (از 526 تا 760 میلی متر جیوه) است.
3. کل فشار هوا در ورودی ورودی هوای SVO در پرواز از 754 تا 1200 گیگا پاسکال (از 566 تا 1050 میلی متر جیوه) است.
4. دمای هوای خنک کننده:
   در پارکینگ - حداکثر 27 ºС، برای بلوک های فنی - بیش از 29 ºС،
   در پرواز - بیش از 25 º C، برای بلوک های فنی - بیش از 27 º C.
5. جریان هوای خنک کننده:
   هنگام پارک - حداقل 708 کیلوگرم در ساعت،
   در پرواز - نه کمتر از 660 کیلوگرم در ساعت.
6. دمای هوا در محفظه ابزار بیش از 60 درجه سانتیگراد نیست.
7. مقدار رطوبت آزاد ریز در هوای خنک کننده بیشتر از 2 گرم بر کیلوگرم هوای خشک نیست.

حتی در این مجموعه محدود از الزامات، حداقل دو دسته وجود دارد که باید به طور متفاوت در سیستم مدیریت شوند:

• الزامات شرایط عملیاتی سیستم (بند 1-3)؛
• الزامات پارامتریک برای سیستم (بندهای 3-7).

الزامات شرایط عملیاتی سیستم
شرایط خارجی برای سیستم در حال توسعه در طول مدل سازی می تواند به عنوان شرایط مرزی یا در نتیجه عملکرد سیستم عمومی مشخص شود.
در شبیه سازی پویا، لازم است اطمینان حاصل شود که شرایط عملیاتی مشخص شده توسط فرآیند شبیه سازی پوشش داده شده است.

الزامات سیستم پارامتریک
این الزامات پارامترهایی هستند که توسط خود سیستم ارائه می شوند. در طول فرآیند مدل‌سازی، می‌توانیم این پارامترها را به عنوان نتایج محاسباتی بدست آوریم و اطمینان حاصل کنیم که الزامات در هر محاسبه خاص برآورده شده است.

شناسایی و کدگذاری نیازمندی ها

برای سهولت کار با الزامات، استانداردهای موجود توصیه می کنند که برای هر نیاز یک شناسه اختصاص دهید. هنگام تخصیص شناسه ها، استفاده از یک سیستم کدگذاری یکپارچه بسیار مطلوب است.

کد مورد نیاز می تواند به سادگی یک عدد باشد که نشان دهنده شماره سفارش مورد نیاز است، یا می تواند شامل یک کد برای نوع نیاز، یک کد برای سیستم یا واحدی که برای آن اعمال می شود، یک کد پارامتر، یک کد مکان، و هر چیز دیگری که مهندس بتواند تصور کند. (برای استفاده از رمزگذاری به مقاله مراجعه کنید)

جدول 1 یک مثال ساده از کدگذاری نیازمندی ها را ارائه می دهد.

1. کد منبع الزامات R-requirements TK؛
2. نوع کد الزامات E - الزامات - پارامترهای محیطی یا شرایط عملیاتی
   S - الزامات ارائه شده توسط سیستم؛
3. کد وضعیت هواپیما 0 – هر، G – پارک شده، F – در پرواز.
4. کد نوع پارامتر فیزیکی T – دما، P – فشار، G – سرعت جریان، رطوبت H.
5. شماره سریال مورد نیاز

ID مقررات	شرح	پارامتر
REGT01	دمای هوای محیط در ورودی سیستم خنک کننده آب: در پارکینگ - از منفی 35ºС. تا 35 ºС.
REFT01	دمای هوای اتمسفر در ورودی سیستم دفاع هوایی: در پرواز - از منفی 35 ºС تا 39 ºС.
REFP01	فشار هوای استاتیک اتمسفر در پرواز از 700 تا 1013 hPa (از 526 تا 760 میلی متر جیوه) است.
REFP02	کل فشار هوا در ورودی ورودی هوای SVO در پرواز از 754 تا 1200 hPa (از 566 تا 1050 میلی متر جیوه) است.
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>

بلوک شامل دو پورت ورودی، پارامتر و شرط است.

اولین مورد با بررسی پارامتر تغذیه می شود. در این مورد، "دمای خارجی".

یک متغیر Boolean به پورت دوم ارائه می شود - شرط انجام بررسی.

اگر TRUE (1) در ورودی دوم دریافت شود، بلوک یک محاسبه تأیید نیاز را انجام می دهد.

اگر ورودی دوم FALSE (0) را دریافت کند، شرایط تست برآورده نمی شود. این امر ضروری است تا بتوان شرایط محاسبه را در نظر گرفت. در مورد ما، این ورودی برای فعال یا غیرفعال کردن بررسی بسته به وضعیت مدل استفاده می شود. اگر هواپیما در حین شبیه سازی روی زمین باشد، الزامات مربوط به پرواز بررسی نمی شود و بالعکس - اگر هواپیما در حال پرواز باشد، الزامات مربوط به عملیات در حالت ایستاده بررسی نمی شود.

این ورودی همچنین می تواند هنگام تنظیم مدل، به عنوان مثال در مرحله اولیه محاسبه، استفاده شود. هنگامی که مدل به حالت مورد نیاز در می آید، بلوک های چک غیرفعال می شوند، اما به محض اینکه سیستم به حالت عملیاتی مورد نیاز رسید، بلوک های چک روشن می شوند.

پارامترهای این بلوک عبارتند از:

• شرایط مرزی: محدوده بالا (UpLimit) و پایین (DownLimit) که باید بررسی شوند.
• زمان نوردهی مورد نیاز سیستم در محدوده های مرزی (TimeInterval) بر حسب ثانیه.
• شناسه درخواست ReqName;
• مجاز بودن فراتر رفتن از محدوده Out_range یک متغیر بولی است که تعیین می کند آیا مقدار بیش از محدوده بررسی شده نقض الزامات است یا خیر.

در برخی موارد، خروجی مقدار تست نشان می دهد که سیستم دارای مقداری حاشیه است و ممکن است خارج از محدوده عملیاتی خود کار کند. در موارد دیگر، خروجی به این معنی است که سیستم قادر به حفظ نقاط تنظیم در محدوده نیست.

شکل 6. یک بلوک چک ویژگی معمولی در نمودار و پارامترهای آن.

در نتیجه محاسبه این بلوک، متغیر Result در خروجی تشکیل می شود که مقادیر زیر را می گیرد:

• 0 - rNone، مقدار تعریف نشده است.
• 1 - انجام شد، نیاز برآورده شده است.
• 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