Автоматична проверка на изискванията на TOR в процеса на динамична симулация

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

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

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

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

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

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

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 kg/h,
   в полет - не по-малко от 660 kg/h.
6. Температурата на въздуха в инструменталните отделения е не повече от 60 ºС.
7. Количеството фина свободна влага в охлаждащия въздух е не повече от 2 g/kg сух въздух.

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

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

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

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

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

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

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

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

1. код на източника на изисквания Р-изисквания ТЗ;
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 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 g/kg сух въздух

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

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

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

Проектът за проверка на изискванията в този случай се превръща в същия проект за алгоритъм и е свързан с пакета на модела. А в режим на динамично моделиране извършва анализ за съответствие с изискванията на техническите спецификации.

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

Фигура 1. Пример за дизайн на проект за проверка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Блокът съдържа два входни порта, параметър и условие.

Първият се захранва с параметъра, който се проверява. В този случай „Външна температура“.

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

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

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

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

Параметрите на този блок са:

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

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

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

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

• 0 – rНяма, стойността не е дефинирана;
• 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