Автоматска верификација на барањата за технички спецификации при динамичко моделирање

Продолжување на темата „Кои се вашите докази?, да го погледнеме проблемот со математичкото моделирање од другата страна. Откако ќе се увериме дека моделот одговара на домашната вистина на животот, можеме да одговориме на главното прашање: „што, точно, имаме овде? Кога креираме модел на технички објект, обично сакаме да бидеме сигурни дека овој објект ќе ги исполни нашите очекувања. За таа цел се вршат динамички пресметки на процесите и резултатот се споредува со барањата. Ова е дигитален близнак, виртуелен прототип итн. модерни мали момци кои во фазата на дизајнирање го решаваат проблемот како да се погрижиме да го добиеме она што го планиравме.

Како можеме брзо да се увериме дека нашиот систем е токму она што го дизајнираме, дали нашиот дизајн ќе лета или ќе лебди? И ако лета, колку високо? И ако плови, колку длабоко?

Оваа статија ја разгледува автоматизацијата на верификацијата на усогласеноста со барањата на техничката зграда при креирање динамични модели на технички системи. Како пример, да погледнеме елемент од техничката спецификација за систем за ладење на воздух на авион.

Ги разгледуваме оние барања кои можат да се изразат нумерички и да се потврдат математички врз основа на специфичен модел на пресметка. Јасно е дека ова е само дел од општите барања за секој технички систем, но токму на нивна проверка трошиме време, нерви и пари за создавање динамични модели на објектот.

Кога се опишуваат техничките барања во форма на документ, може да се разликуваат неколку видови различни барања, од кои секоја бара различни пристапи за формирање на автоматска проверка на исполнувањето на барањата.

На пример, разгледајте го овој мал, но реален сет на барања:

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. код на изворот на барањата R-барања 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 g/kg сув воздух

Дизајн на системот за верификација на барањата.

За секое барање за дизајн постои алгоритам за проценка на кореспонденцијата на параметрите на дизајнот и параметрите наведени во барањето. Во голема мера, секој контролен систем секогаш содржи алгоритми за проверка на барањата едноставно стандардно. Па дури и секој регулатор ги содржи. Ако температурата излезе надвор од границите, клима уредот се вклучува. Така, првата фаза од секоја регулатива е да се провери дали параметрите ги исполнуваат барањата.

И бидејќи верификацијата е алгоритам, тогаш можеме да ги користиме истите алатки и алатки што ги користиме за создавање контролни програми. На пример, околината SimInTech ви овозможува да креирате проектни пакети кои содржат различни делови од моделот, извршени во форма на посебни проекти (модел на објект, модел на контролен систем, модел на околина итн.).

Проектот за верификација на барањата во овој случај станува истиот алгоритамски проект и е поврзан со моделот пакет. И во режимот на динамичко моделирање врши анализа за усогласеност со барањата на техничките спецификации.

Можен пример за дизајн на системот е прикажан на слика 1.

Слика 1. Пример за дизајн на проект за верификација.

Исто како и за контролните алгоритми, барањата може да се изготват како збир на листови. За погодност за работа со алгоритми во средини за структурно моделирање како што се SimInTech, Simulink, AmeSim, се користи можноста за создавање структури на повеќе нивоа во форма на подмодели. Оваа организација овозможува групирање на различни барања во множества за да се поедностави работата со низа барања, како што се прави за контролните алгоритми (види Сл. 2).

Слика 2. Хиерархиска структура на моделот за верификација на барањата.

На пример, во случајот што се разгледува, се разликуваат две групи: барања за животната средина и барања директно за системот. Затоа, се користи структура на податоци на две нивоа: две групи, од кои секоја е лист од алгоритмот.

За поврзување на податоците со моделот, се користи стандардна шема за генерирање на база на податоци за сигнали, која ги складира податоците за размена помеѓу делови од проектот.

При креирање и тестирање на софтвер, читањата на сензорите (аналози на реални системски сензори) што ги користи контролниот систем се сместени во оваа база на податоци.
За тест проект, сите параметри пресметани во динамичкиот модел може да се складираат во истата база на податоци и на тој начин да се користат за да се провери дали барањата се исполнети.

Во овој случај, самиот динамички модел може да се изврши во кој било систем за математичко моделирање или дури и во форма на извршна програма. Единствениот услов е присуството на софтверски интерфејси за издавање податоци за моделирање во надворешната средина.

Слика 3. Поврзување на проектот за верификација со сложениот модел.

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

Слика 4. Лист за проверка на барањата.

Главните делови од листот за проверка се опишани на слика 5. Алгоритмот за проверка е формиран слично како и дизајнерските дијаграми на контролните алгоритми. На десната страна има блок за читање сигнали од базата на податоци. Овој блок пристапува до базата на податоци за сигнали за време на симулацијата.

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

Условите за проверка и параметрите што се проверуваат се пренесуваат во стандардни блокови за верификација, во кои овие параметри се анализираат за усогласеност со наведените барања. Резултатите се запишуваат во базата на податоци за сигнали на таков начин што тие можат да се користат за автоматско генерирање на листа за проверка.

Слика 5. Структура на пресметковниот лист за верификација на барањата.

Параметрите што треба да се тестираат не мора да користат сигнали содржани во базата на податоци, кои се контролираат со параметри пресметани за време на процесот на симулација. Ништо не не спречува да вршиме дополнителни пресметки во рамките на нацрт-барањата, исто како што ги пресметуваме условите за верификација.

На пример, ова барање:

Бројот на активирања на системот за корекција за време на летот до целта не треба да надминува 5, а вкупното време на работа на системот за корекција не треба да надминува 30 секунди.

Во овој случај, на дизајнерскиот дијаграм на барањата се додава алгоритам за пресметување на бројот на стартови и вкупното време на работа.

Блок за верификација на типични барања.

Секое поле за избор на стандардни барања е дизајнирано да го пресмета исполнувањето на барањето од одреден тип. На пример, еколошките барања вклучуваат опсег на работни температури на околината кога се паркирани и во лет. Овој блок мора да ја прими температурата на воздухот во моделот како параметар и да одреди дали овој параметар го покрива наведениот температурен опсег./p>

Блокот содржи две влезни порти, пара и состојба.

Првиот се напојува со параметарот што се проверува. Во овој случај, „Надворешна температура“.

Булова променлива се доставува до втората порта - услов за извршување на проверката.

Ако ВИСТИНА (1) се прими на вториот влез, тогаш блокот врши пресметка за верификација на барањата.

Ако вториот влез добие FALSE (0), тогаш условите за тестирање не се исполнети. Ова е неопходно за да може да се земат предвид условите за пресметка. Во нашиот случај, овој влез се користи за да се овозможи или оневозможи проверката во зависност од состојбата на моделот. Ако леталото е на земја за време на симулацијата, тогаш не се проверуваат барањата поврзани со летот, и обратно - ако леталото е во лет, тогаш не се проверуваат барањата поврзани со работа на стој.

Овој влез може да се користи и при поставување на моделот, на пример во почетната фаза на пресметка. Кога моделот е доведен во потребната состојба, блоковите за проверка се оневозможени, но штом системот го достигне потребниот режим на работа, блоковите за проверка се вклучуваат.

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

• гранични услови: горните (UpLimit) и долните (DownLimit) граници на опсегот што мора да се проверат;
• потребното време на изложеност на системот на граничните опсези (Временски интервал) во секунди;
• Барање ID ReqName;
• дозволивоста за надминување на опсегот Out_range е Булова променлива која одредува дали вредноста што го надминува проверениот опсег е прекршување на барањето.

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

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

Како резултат на пресметката на овој блок, на излезот се формира променливата Result, која ги зема следните вредности:

• 0 – rНишто, вредноста не е дефинирана;
• 1 – r Готово, условот е исполнет;
• 2 – rGault, условот не е исполнет.

Сликата на блокот содржи:

• идентификациски текст;
• дигитални прикази на параметрите на мерните граници;
• идентификатор на боја на статусот на параметарот.

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

На пример, за да се провери опсегот на работна температура на единицата прикажана на слика 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