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

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

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

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

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

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

На пример, размотрите овај мали, али реалистичан скуп захтева:

1. Температура атмосферског ваздуха на улазу у систем за пречишћавање воде:
   на паркингу - од минус 35 до 35 ºС,
   у лету - од минус 35 до 39 ºС.
2. Статички притисак атмосферског ваздуха у лету је од 700 до 1013 ГПа (од 526 до 760 мм Хг).
3. Укупан ваздушни притисак на улазу у СВО усисник ваздуха у лету је од 754 до 1200 ГПа (од 566 до 1050 мм Хг).
4. Температура ваздуха за хлађење:
   на паркингу - не више од 27 ºС, за техничке блокове - не више од 29 ºС,
   у лету - не више од 25 ºС, за техничке блокове - не више од 27 ºС.
5. Проток ваздуха за хлађење:
   када је паркиран - најмање 708 кг/х,
   у лету - не мање од 660 кг / х.
6. Температура ваздуха у одељцима за инструменте није већа од 60 ºС.
7. Количина фине слободне влаге у ваздуху за хлађење није већа од 2 г/кг сувог ваздуха.

Чак и у оквиру овог ограниченог скупа захтева, постоје најмање две категорије којима се у систему треба другачије руковати:

• захтеви за услове рада система (клаузуле 1-3);
• параметарски захтеви за систем (клаузуле 3-7).

Захтеви за услове рада система
Спољни услови за систем који се развија током моделирања могу се специфицирати као гранични услови или као резултат рада општег система.
У динамичкој симулацији потребно је обезбедити да наведени услови рада буду обухваћени процесом симулације.

Параметарски системски захтеви
Ови захтеви су параметри које обезбеђује сам систем. Током процеса моделирања, ове параметре можемо добити као резултате прорачуна и уверити се да су захтеви испуњени у сваком конкретном прорачуну.

Идентификација и кодирање захтева

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

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

Табела 1 даје једноставан пример кодирања захтева.

1. шифра извора захтева Р-захтеви ТК;
2. шифра врста захтева Е – захтеви – параметри животне средине, односно услови рада
   С - захтеви које обезбеђује систем;
3. код статуса ваздухоплова 0 – било који, Г – паркиран, Ф – у лету;
4. шифра типа физичког параметра Т – температура, П – притисак, Г – брзина протока, влажност Х;
5. серијски број захтева.

ID Захтеви	Опис	Параметар
РЕГТ01	Температура амбијенталног ваздуха на улазу у систем воденог хлађења: на паркингу - од минус 35ºС. до 35 ºС.
РЕФТ01	Температура атмосферског ваздуха на улазу у систем ПВО: у лету - од минус 35 ºС до 39 ºС.
РЕФП01	Статички атмосферски притисак ваздуха у лету је од 700 до 1013 хПа (од 526 до 760 мм Хг).
РЕФП02	Укупан ваздушни притисак на улазу у СВО усисник ваздуха у лету је од 754 до 1200 хПа (од 566 до 1050 мм Хг).
РСГТ01	Температура ваздуха за хлађење: када се паркира не више од 27 ºС
РСГТ02	Температура расхладног ваздуха: на паркингу, за техничке јединице не више од 29 ºС
РСФТ01	Температура расхладног ваздуха у лету не већа од 25 ºС
РСФТ02	Температура расхладног ваздуха: у лету, за техничке јединице не више од 27 ºС
РСГГ01	Проток ваздуха за хлађење: када је паркиран не мањи од 708 кг/х
РСФГ01	Проток ваздуха за хлађење: у лету не мање од 660 кг/х
РС0Т01	Температура ваздуха у одељцима за инструменте не већа од 60 ºС
РСХ01	Количина фине слободне влаге у ваздуху за хлађење није већа од 2 г/кг сувог ваздуха

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

За сваки захтев за пројектовање постоји алгоритам за процену кореспонденције пројектних параметара и параметара наведених у захтеву. Углавном, сваки контролни систем увек садржи алгоритме за проверу захтева једноставно подразумевано. Чак их и сваки регулатор садржи. Ако температура изађе ван граница, клима уређај се укључује. Дакле, прва фаза сваке регулативе је провера да ли параметри испуњавају захтеве.

А пошто је верификација алгоритам, онда можемо користити исте алате и алате које користимо за креирање контролних програма. На пример, окружење СимИнТецх вам омогућава да креирате пакете пројеката који садрже различите делове модела, који се изводе у облику засебних пројеката (објектни модел, модел управљачког система, модел окружења, итд.).

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

Могући пример дизајна система приказан је на слици 1.

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

Као и за контролне алгоритме, захтеви се могу саставити као скуп листова. За погодност рада са алгоритмима у окружењима за структурно моделовање као што су СимИнТецх, Симулинк, АмеСим, користи се могућност креирања вишеслојних структура у облику подмодела. Ова организација омогућава груписање различитих захтева у скупове како би се поједноставио рад са низом захтева, као што је то учињено за алгоритме управљања (види слику 2).

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

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

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

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

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

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

Пример листа за верификацију основних захтева представљен је на слици 4. Са тачке гледишта програмера, то је конвенционални дијаграм прорачуна на коме је графички представљен алгоритам верификације захтева.

Слика 4. Лист за проверу захтева.

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

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

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

Слика 5. Структура обрачунског листа верификације захтева.

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

На пример, овај захтев:

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

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

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

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

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

Први се напаја са параметром који се проверава. У овом случају, „Спољна температура“.

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

Ако се на другом улазу прими ТРУЕ (1), тада блок врши прорачун верификације захтева.

Ако други улаз добије ФАЛСЕ (0), онда услови теста нису испуњени. Ово је неопходно како би се услови прорачуна могли узети у обзир. У нашем случају, овај улаз се користи за омогућавање или онемогућавање провере у зависности од стања модела. Ако је ваздухоплов у току симулације на земљи, онда се не проверавају захтеви који се односе на лет, и обрнуто – ако је ваздухоплов у лету, онда се не проверавају захтеви који се односе на рад у мировању.

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

Параметри овог блока су:

• гранични услови: горње (УпЛимит) и доње (ДовнЛимит) границе опсега које се морају проверити;
• потребно време излагања система у граничним опсегима (ТимеИнтервал) у секундама;
• ИД захтева РекНаме;
• дозвољеност прекорачења опсега Оут_ранге је Булова променљива која одређује да ли вредност која прелази проверени опсег представља кршење захтева.

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

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

Као резултат израчунавања овог блока, на излазу се формира променљива Резултат, која узима следеће вредности:

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

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

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

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

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

Слика 7. Унутрашњи дијаграм јединице за одређивање температурног опсега.

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

Резултати прорачуна се преносе на излаз блока и истовремено се снимају у општу датотеку извештаја, која се креира на основу резултата за цео пројекат. (види слику 8)

Пример извештаја креираног на основу резултата симулације је хтмл датотека креирана према датом формату. Формат се може произвољно конфигурисати на формат који је прихватила одређена организација.

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

Резултати прорачуна се преносе на излаз блока и истовремено се снимају у општу датотеку извештаја, која се креира на основу резултата за цео пројекат. (види слику 8)

Пример извештаја креираног на основу резултата симулације је хтмл датотека креирана према датом формату. Формат се може произвољно конфигурисати на формат који је прихватила одређена организација.

Слика 8. Пример фајла извештаја на основу резултата симулације.

У овом примеру, образац извештаја је конфигурисан директно у својствима пројекта, а формат у табели је постављен као глобални пројектни сигнали. У овом случају, СимИнТецх сам решава проблем подешавања извештаја, а блок за уписивање резултата у датотеку користи ове линије за писање у датотеку извештаја.

Слика 9. Подешавање формата извештаја у глобалним пројектним сигналима

Коришћење базе података сигнала за захтеве.

Да би се аутоматизовао рад са поставкама својстава, у бази сигнала се креира стандардна структура за сваки типични блок. (види слику 10)

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

База података сигнала пружа:

• Чување свих потребних параметара системских захтева.
• Погодан преглед постојећих захтева пројекта из специфицираних параметара и тренутних резултата моделирања.
• Подешавање једног блока или групе блокова помоћу програмског језика за скриптовање. Промене у бази сигнала доводе до промена вредности својстава блока на дијаграму.
• Чување текстуалних описа, веза до ставки техничких спецификација или идентификатора у систему управљања захтевима.

Структуре базе података сигнала за захтеве могу се лако конфигурисати за рад са системом управљања захтевима треће стране Општи дијаграм интеракције са системима за управљање захтевима је представљен на слици 11.

Слика 11. Дијаграм интеракције са системом управљања захтевима.

Редослед интеракције између СимИнТецх тест пројекта и система контроле захтева је следећи:

1. Пројектни задаци су подељени на захтеве.
2. Идентификовани су захтеви техничких спецификација који се могу верификовати математичким моделирањем техничких процеса.
3. Атрибути изабраних захтева се преносе у СимИнТецх базу сигнала у структури стандардних блокова (на пример, максимална и минимална температура).
4. Током процеса прорачуна, подаци о структури се преносе у блок пројектне дијаграме, врши се анализа и резултати се чувају у бази података сигнала.
5. Када се прорачун заврши, резултати анализе се преносе у систем управљања захтевима.

Кораци захтева од 3 до 5 могу се поновити током процеса пројектовања када дође до промена у дизајну и/или захтевима и утицај промена треба поново да се тестира.

Закључци.

• Створени прототип система обезбеђује значајно смањење времена анализе постојећих модела ради усаглашености са захтевима техничких спецификација.
• Предложена технологија тестирања користи већ постојеће динамичке моделе и може се користити чак и за све динамичке моделе, укључујући и оне који се не изводе у СимИнТецх окружењу.
• Коришћење пакетне организације података омогућава вам да креирате пакете за верификацију захтева паралелно са развојем модела, или чак да користите ове пакете као техничке спецификације за развој модела.
• Технологија се може интегрисати са постојећим системима управљања захтевима без значајних трошкова.

За оне који читају до краја, линк до видео снимка који показује како прототип функционише.

Извор: ввв.хабр.цом