Автоматична проверка на изискванията на ТЗ по време на динамично моделиране

Продължавайки темата «Какви са вашите доказателства?», ще разгледаме проблема с математическото моделиране от друга перспектива. След като се уверим, че моделът отговаря на суровата реалност, можем да отговорим на основния въпрос: «какво точно имаме тук?». Създавайки модел на технически обект, обикновено искаме да се уверим, че той ще отговори на нашите очаквания. Затова се извършват динамични изчисления на процесите и резултатите се сравняват с изискванията. Това е цифровият двойник, виртуалният прототип и други модерни концепции, които в етапа на проектиране решават задачата как да постигнем това, което планираме.

Как можем бързо да се уверим, че нашата система е именно това, което проектираме, ще лети ли или ще плува? А ако лети, то колко високо? А ако плава, колко дълбоко?

В тази статия се разглежда автоматизацията на проверката на спазването на изискванията на техническата сграда при създаване на динамични модели на технически системи. Например, ще разгледаме елемента на техническото задание за системата за въздушно охлаждане на летателен апарат.

Разглеждаме изискванията, които могат да бъдат изразени числено и проверени математически на основата на конкретен изчислителен модел. Ясно е, че това е само част от общите изисквания към всяка техническа система, но именно за проверката им ние отделяме време, нерви и средства за създаване на динамични модели на обекта.

При описването на техническите изисквания под формата на документ можем да разграничим няколко вида различни изисквания, всяко от които изисква различни подходи за автоматична проверка на спазването им.

Например, да разгледаме такъв малък, но реален набор от изисквания:

1. Температура на атмосферния въздух на входа на СВО:
   на стоянка − от минус 35 до 35 ºС,
   в полет − от минус 35 до 39 ºС.
2. Статично налягане на атмосферния въздух по време на полет − от 700 до 1013 ГПа (от 526 до 760 ммHg).
3. Общо налягане на въздуха на входа на всмучващия отвор на СВО по време на полет − от 754 до 1200 ГПа (от 566 до 1050 ммHg).
4. Температура на охлаждащия въздух:
   на стоянка − не повече от 27 ºС, за техническите блокове − не повече от 29 ºС,
   при полет − не повече от 25 ºС, за техническите модули − не повече от 27 ºС.
5. Разход на охлаждащия въздух:
   на паркинг − не по-малко от 708 кг/ч,
   при полет − не по-малко от 660 кг/ч.
6. Температурата на въздуха в приборните отсекове − не повече от 60 ºС.
7. Количество на финодисперсната свободна влага в охлаждащия въздух − не повече от 2 г/кг сух въздух.

Дори в такъв ограничен набор от изисквания могат да се отличат поне две категории, които трябва да се обработват по различен начин в системата:

• изисквания за условията на експлоатация на системата (п.п. 1-3);
• параметрични изисквания към системата (п.п. 3-7).

Изисквания за условията на експлоатация на системата
Външните условия за проектираната система при моделиране могат да бъдат зададени като граници, или като резултат от работата на общата система.
При динамично моделиране е необходимо да се уверите, че зададените режими на работа са покрити от процеса на моделиране.

Параметрични изисквания към системата
Тези изисквания представляват параметри, осигурявани от самата система. В процеса на моделиране можем да получим тези параметри като резултати от изчисленията и да се уверим, че изискванията са изпълнени във всяко конкретно изчисление.

Идентификация и кодиране на изискванията

За удобство при работа с изискванията, съществуващите стандарти препоръчват да се присвоява идентификатор на всяко изискване. При присвояването на идентификатори е много желателно да се използва единична система за кодиране.

Кодът на изискването може да бъде просто число, отразяващо поредния номер на изискването, или може да съдържа код на типа изискване, код на системата или агрегата, към който се отнася, код на параметъра, код на местоположението и много друго, което инженерът може да си представи. (вариант за използване на кодиране виж в статията)

В таблица 1 е представен прост пример за кодиране на изисквания.

1. код на източника на изисквания R- изисквания на ТЗ;
2. код на типа изисквания E – изисквания – параметри на външната среда, или условия на експлоатация
   S — изисквания, осигурявани от системата;
3. код на състоянието на самолета 0 – всякакво, G – на паркинг, F – при полет;
4. код на типа физически параметри T – температура, P – налягане, G – разход, влажност H;
5. номер на поредното изискване.

Проект на система за проверка на изискванията.

За всяко изчислително изискване има алгоритъм за оценка на съответствието между изчислените параметри и зададените в изискването. По същество, всяка система за управление винаги съдържа алгоритми за проверка на изискванията просто по подразбиране. И дори всеки регулатор ги съдържа. Ако температурата надвиши пределите, климатикът се включва. Така първият етап на всяко регулиране – проверка на съответствието на параметрите с изискването.

А тъй като проверката е алгоритъм, може да се използват същите средства и инструменти, които използваме за създаване на управленски програми. Например, средата SimInTech позволява създаването на пакети проекти, съдържащи различни части на модела, изпълнени като отделни проекти (модел на обекта, модел на системата за управление, модел на околната среда и т.н.).

Проектът за проверка на изискванията в този случай става същият проект на алгоритми и се свързва с пакета на модела. И в динамичния моделирен режим извършва анализ на съответствието на изискванията на ТЗ.

Възможен пример за оформление на проекта на системата е показан на рисунка 1.

Рисунка 1. Пример за оформление на проекта за проверка.

Също както за алгоритмите за управление, изискванията могат да се оформят под формата на набор от листи. За удобство при работа с алгоритмите в среди за структурно моделиране като SimInTech, Simulink, AmeSim се използват възможностите за създаване на многостепенни структури под формата на субмодели. Тази организация позволява групирането на различни изисквания в набори за улесняване на работата с набора от изисквания, както се прави за алгоритмите за управление (вж. рис. 2).

Рисунок 2. Йерархична структура на модела за проверка на изисквания.

Например, в разглеждания случай са отделени две групи: изисквания за околната среда и изисквания, свързани непосредственно с системата. Затова се използва двустепенна структура на данните: две групи, всяка от които е лист на алгоритъма.

За свързване на данните с модела се използва стандартна схема за формиране на база от данни за сигнали, в която се съхраняват данни за обмен между частите на проекта.

При създаването и тестването на софтуер в тази база се поставят показанията на сензорите (аналози на реални сензори на системата), които се използват от системата за управление.
За проекта за тестване в същата база данни могат да се съхраняват всякакви параметри, изчислявани в динамичния модел, и така да се използват за проверка на изпълнението на изискванията.

Самият динамичен модел в този случай може да бъде реализиран в която и да е система за математическо моделиране или дори под формата на изпълним програма. Единственото изискване – наличие на софтуерни интерфейси за извеждане на данни за моделиране във външната среда.

Рисунок 3. Свързване на проекта за проверка с комплексен модел.

Примерът на основния лист за проверка на изисквания е представен на рисунка 4. От гледна точка на разработчика, той представлява обикновена изчислителна схема, на която в графичен вид е представен алгоритъмът за проверка на изискванията.

Рисунок 4. Лист за проверка на изисквания.

Основните части на листа за проверка са описани на рисунка 5. Алгоритъмът за проверка се формира аналогично на изчислителните схеми на алгоритмите за управление. В дясната част се намира блок за четене на сигнали от базата данни. В този блок се осъществява достъп до базата данни за сигнали по време на моделирането.

Получените сигнали се анализират за изчисляване на условията за проверка на изискванията. В разглеждания случай се извършва анализ на височината, за да се определи позицията на самолета (дали е на стоянка или е в полет). За тази цел могат да се използват и други сигнали и изчислени параметри на модела.

Условията за проверка и проверяваните параметри се предават в типови блокове за проверка, в които се анализират данните на тези параметри за съответствие с зададените изисквания. Резултатите се записват в базата данни на сигналите по такъв начин, че да могат да се използват за автоматично генериране на чеклист.

Рисунка 5. Структура на изчислителния лист за проверка на изискванията.

Като проверявани параметри не е задължително да се използват сигналите, съдържащи се в базата данни, които се управляват от параметрите, изчислявани в процеса на моделиране. Нищо не пречи в рамките на проекта за изисквания да се извършат допълнителни изчисления, както ние изчисляваме условията за проверка.

Например, такова изискване:

Броят на включванията на коригиращата система по време на полет до целта не трябва да надвишава 5, а общото време на работа на коригиращата система не трябва да надвишава 30 секунди.

В този случай в изчислителната схема на проекта за изисквания се добавя алгоритъм за броене на включванията и общото време на работа.

Типов блок за проверка на изискванията.

Всеки типов блок за проверка на изискванията е предназначен за изчисляване на изпълнението на изискване от определен тип. Например, в изискванията към околната среда присъства диапазон от работни температури на околния въздух на стоянка и в полет. Този блок трябва да получи температурата на въздуха в модела и да определи дали тази температура попада в зададения диапазон.

Блокът съдържа два входни порта, param и condition.

На първия се подава проверяваният параметър. В този случай "Температура на външната среда".

На втория порт се подава булева променлива – условие за изпълнение на проверката.

Ако на втория вход постъпи TRUE (1), то блокът извършва изчисление за проверка на изискването.

Ако на втория вход получавате FALSE (0), условията за проверка не се изпълняват. Това е необходимо, за да може да се вземат предвид условията за изчисление. В нашия случай този вход се използва, за да се включва или изключва проверката в зависимост от състоянието на модела. Ако ЛА по време на моделирането е на земята, изискванията, свързани с полет, не се проверяват и обратно – ако ЛА е в полет, изискванията, свързани с работа на стоянка, не се проверяват.

Този вход също може да се използва при настройка на модела, например на началния етап на изчисление. Когато моделът бъде приведен в необходимото състояние, блоковете за проверка са изключени, но веднага щом системата влезе в необходимия режим на работа, блоковете за проверка се включват.

Като параметри на този блок са зададени:

• гранични условия: горен (UpLimit) и долен (DownLimit) предел на диапазоните, които трябва да бъдат проверени;
• изискваното време на задържане на системата на граничните диапазони (TimeInterval) в секунди;
• идентификатор на изискването ReqName;
• допустимост на изхода извън диапазона Out_range – булева променлива, която определя дали изходът извън проверявания диапазон е нарушение на изискванията.

В някои случаи изходът на проверяваното значение означава, че системата има запас и може да работи извън работния диапазон. В други случаи изходът означава, че системата не успява да поддържа зададените параметри в пределите на диапазона.

Рисунка 6. Типов блок за проверка на свойството на схемата и неговите параметри.

В резултат на изчислението на този блок на изхода се формира променлива Result, която приема следните стойности:

• 0 – rNone, стойността не е определена;
• 1 – rDone, изискването се изпълнява;
• 2 – rFault, изискването не се изпълнява.

Изображението на блока съдържа:

• текст на идентификатора;
• цифрови показания на параметрите на пределите на измерванията;
• цветен идентификатор на състоянието на параметъра.

Вътре в блока може да има доста сложна схема за логическо извеждане.

Например, за проверка на работния диапазон на температурата на блока, показан на рисунка 6, вътрешната схема е представена на рисунка 7.

Рисунка 7. Вътрешна схема на блока за определяне на температурния диапазон.

Вътре в блоковите схеми се използват свойства, зададени в параметрите на блока.
Освен анализа на съответствието на изискванията, вътрешната схема на блока съдържа графика, необходима за извеждане на резултатите от моделирането. Този график може да бъде използван както за преглед по време на изчислението, така и за анализ на резултатите след него.

Резултатите от изчислението се предават на изхода на блока и едновременно се записват в общ файл на отчета, който се създава на базата на резултатите от целия проект. (вж. рис. 8)

Примерът за отчет, създаден на базата на резултатите от моделирането, представлява html файл, създаден по зададен формат. Форматът може да бъде настроен произволнo на формата, приет в конкретната организация.

Вътре в блоковите схеми се използват свойства, зададени в параметрите на блока.
Освен анализа на съответствието на изискванията, вътрешната схема на блока съдържа графика, необходима за извеждане на резултатите от моделирането. Този график може да бъде използван както за преглед по време на изчислението, така и за анализ на резултатите след него.

Резултатите от изчислението се предават на изхода на блока и едновременно се записват в общ файл на отчета, който се създава на базата на резултатите от целия проект. (вж. рис. 8)

Примерът за отчет, създаден на базата на резултатите от моделирането, представлява html файл, създаден по зададен формат. Форматът може да бъде настроен произволнo на формата, приет в конкретната организация.

Рисунок 8. Пример на файл отчет по резултатите от моделирането.

В този пример, настройката на формата на отчета се извършва директно в свойствата на проекта, а форматът в таблицата се задава като глобални сигнали на проекта. В този случай SimInTech сам решава задачата за настройка на отчета, а блокът за запис на резултатите в файл използва тези редове за запис в отчета.

Рисунок 9. Настройка на формата на отчета в глобалните сигнали на проекта.

Използване на база данни от сигнали за изисквания.

За автоматизация на работата с настройки на свойствата за всеки типичен блок, се създава типична структура в базата данни на сигналите. (вж. рис. 10)

Рисунок 10. Пример на структурата на блока за проверка на изисквания в базата данни на сигналите.

Базата данни на сигналите осигурява:

• Съхранение на всички необходими параметри на изискванията към системата.
• Удобен преглед на съществуващите в проекта изисквания от зададените параметри и текущите резултати от моделирането.
• Настройка на един блок, група блокове с използване на скриптов език за програмиране. Промените в базата данни на сигналите водят до промяна на стойностите на свойствата на блока в схемата.
• Съхранение на текстови описания, връзки към точки в ТЗ или идентификатори в системата за управление на изискванията.

Структурите на базата данни на сигналите за изисквания могат лесно да бъдат настроени за работа с външна система за управление на изискванията. Общата схема на взаимодействие с системите за управление на изискванията е представена на рис. 11.

Рисунок 11. Схема на взаимодействие с системата за управление на изискванията.

Последователността на взаимодействието на тестовия проект SimInTech със системата за управление на изискванията е следната:

1. Техническото задание се разделя на изисквания.
2. Избират се такива изисквания от техническото задание, които могат да бъдат проверени чрез математическо моделиране на техническите процеси.
3. Атрибутите на избраните изисквания се предават в базата данни на сигналите SimInTech в структури на типични блокове (например, максимална и минимална температура).
4. В процеса на изчисление данните от структурите се предават в изчислителните схеми на блоковете, извършва се анализ и резултатите се запазват в базата данни на сигналите.
5. След завършване на изчислението, резултатите от анализа се предават в системата за управление на изискванията.

Етапите на работа с изискванията 3 — 5 могат да се повторят по време на процеса на проектиране, когато настъпват промени в конструкцията и (или) изискванията и, съответно, е необходима повторна проверка на влиянието на внесените промени.

Изводи.

• Създаденият прототип на системата осигурява значително съкращаване на времето за анализ на съществуващите модели относно съответствието с изискванията на ТЗ.
• Предлаганата технология за тестване използва вече съществуващите динамични модели и може да бъде използвана дори за всякакви динамични модели, включително тези, извършени не в средата SimInTech.
• Използването на пакетна организация на данните позволява създаване на пакети за проверка на изискванията паралелно с разработването на модели, или дори използване на тези пакети като техническо задание за разработване на модели.
• Технологията може да бъде интегрирана без значителни разходи с съществуващите системи за управление на изискванията.

За тези, които стигнаха до края, линк към видео с демонстрация на работата на прототипа.

Източник: habr.com