Працягваючы тэму , паглядзім на праблему матэматычнага мадэлявання з другога боку. Пасля таго як мы пераканаліся, што мадэль адпавядае сярмяжнай праўдзе жыцця, можна адказваць на асноўнае пытанне: "а што, уласна, мы тут маем?". Ствараючы мадэль тэхнічнага аб'екта, мы, як правіла, жадаем пераканацца, што гэты аб'ект будзе адпавядаць нашым чаканням. Для гэтага і праводзяцца дынамічныя разлікі працэсаў і вынік параўноўваецца з патрабаваннямі. Гэта і ёсць лічбавы двайнік, віртуальны прататып і іншае. модныя шнягі, якія на стадыі праектавання вырашаюць задачу, як зрабіць так, каб мы атрымалі тое, што планавалі.
Як жа нам хутка пераканаецца што наша сістэма гэта менавіта тое што мы праектуем, ці паляціць ці паплыве, ці наша канструкцыя? А калі паляціць тое як высока? А калі паплыве, дык як глыбока?
У дадзеным артыкуле разглядаецца аўтаматызацыя праверкі выканання патрабаванняў тэхнічнага будынка пры стварэнні дынамічных мадэляў тэхнічных сістэм. У якасці прыкладу паглядзім на элемент тэхнічнага задання для сістэмы паветранага ахаладжэння лятальнага апарата.
Мы разглядаем тыя патрабаванні, якія можна выказаць лікава і праверыць матэматычна на падставе канкрэтнай разліковай мадэлі. Зразумела, што гэта толькі частка агульных патрабаванняў да любой тэхнічнай сістэмы, але менавіта на іх праверку мы і марнуем час, нервы і грошы на стварэнне дынамічных мадэляў аб'екта.
Пры апісанні тэхнічных патрабаванняў у выглядзе дакумента можна вылучыць некалькі відаў розных патрабаванняў, кожнае з якіх патрабуе розных падыходаў для фарміравання аўтаматычнай праверкі выканання патрабаванняў.
Напрыклад, разгледзім вось такі маленькі, але рэальны набор патрабаванняў:
- Тэмпература атмасфернага паветра на ўваходзе ў СВА:
на стаянцы − ад мінус 35 да 35 ºС,
у палёце – ад мінус 35 да 39 ºС. - Статычны ціск атмасфернага паветра ў палёце - ад 700 да 1013 гПа (ад 526 да 760 мм рт. Арт.).
- Поўны ціск паветра на ўваходзе ў паветразаборнік СВА ў палёце - ад 754 да 1200 гПа (ад 566 да 1050 мм рт. Ст.).
- Тэмпература астуджальнага паветра:
на стаянцы − не больш за 27 ºС, для тэхнічных блокаў − не больш за 29 ºС,
у палёце - не больш за 25 ºС, для тэхнічных блокаў - не больш за 27 ºС. - Выдатак астуджальнага паветра:
на стаянцы − не менш за 708 кг/г,
у палёце - не менш за 660 кг/г. - Тэмпература паветра ў прыборных адсеках – не больш за 60 ºС.
- Колькасць дробнадысперснай свабоднай вільгаці ў ахаладжальным паветры - не больш за 2 г/кг сухога паветра.
Нават у такім абмежаваным наборы патрабаванняў можна вылучыць прынамсі дзве катэгорыі, якія трэба па-рознаму апрацоўваць у сістэме:
- патрабаванні ўмоў эксплуатацыі сістэмы (п.п. 1-3);
- параметрычныя патрабаванняў да сістэмы (п.п. 3-7).
Патрабаванні ўмоў эксплуатацыі сістэмы
Вонкавыя ўмовы для распрацоўванай сістэмы пры мадэляванні могуць задавацца як межавыя ўмовы, або як вынік працы агульнай сістэмы.
Пры дынамічным мадэляванні неабходна пераканацца, што зададзеныя рэжымы працы пакрываюцца працэсам мадэлявання.
Параметрычныя патрабаванні да сістэмы
Дадзеныя патрабаванні ўяўляюць сабой параметры, якія забяспечваюцца самой сістэмай. У працэсе мадэлявання мы можам атрымаць дадзеныя параметры як вынікі разліку і пераканацца, што патрабаванні выконваюцца ў кожным канкрэтным разліку.
Ідэнтыфікацыя і кадоўка патрабаванняў
Для зручнасці працы з патрабаваннямі існуючыя стандарты рэкамендуюць ажыццявіць прысваенне ідэнтыфікатара кожнаму патрабаванню. Пры прысваенні ідэнтыфікатараў вельмі пажадана выкарыстоўваць адзіную сістэму кадавання.
Код патрабавання можа быць проста лікам, якія адлюстроўваюць парадкавы нумар патрабавання, а можа змяшчаць у сабе код тыпу патрабаванні, код сістэмы або агрэгата, да якога ён прымяняецца, код параметру, код размяшчэння і многае іншае, што можа ўявіць сабе інжынер. (варыянт выкарыстання кадавання глядзі ў артыкуле)
У табліцы 1 прыведзены просты прыклад кадавання патрабаванняў.
- код крыніцы патрабаванняў R- патрабаванні ТЗ;
- код тып патрабаванняў Е - патрабаванні - параметры навакольнага асяроддзя, або ўмовы эксплуатацыі
S - патрабаванні забяспечваюцца сістэмай; - код стану самалёта 0 - любое, G - на стаянцы, F - у палёце;
- код тыпу фізічных параметраў T - тэмпература, P - ціск, G - выдатак, вільготнасць H;
- нумар парадкавы патрабаванні.
| ID Патрабаванні |
Апісанне | Параметр |
| REGT01 | Тэмпература атмасфернага паветра на ўваходзе ў СВА: на стаянцы - ад мінус 35 ºС. да 35 ºС. | |
| REFT01 | Тэмпература атмасфернага паветра на ўваходзе ў СВА: у палёце - ад мінус 35 ºС да 39 ºС. | |
| REFP01 | Статычны ціск атмасфернага паветра ў палёце ад 700 да 1013 гПа (ад 526 да 760 мм рт. Арт.). | |
| REFP02 | Поўны ціск паветра на ўваходзе ў паветразаборнік СВА ў палёце ад 754 да 1200 гПа (ад 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 секунд.
У гэтым выпадку ў разліковую схему праекту патрабаванняў дадаецца алгарытм лічыльніка колькасці ўключэнняў і агульнага часу працы.
Тыпавы блок праверкі патрабаванняў.
Кожны тыпавы бок праверкі патрабаванняў прызначаны для разліку выканання патрабавання вызначанага тыпу. Напрыклад, у патрабаваннях да асяроддзя прысутнічае дыяпазон працоўных тэмператур навакольнага паветра на стаянцы і ў палёце. Дадзены блок павінен атрымаць у якасці параметру тэмпературу паветра ў мадэлі і вызначыць ці пакрывае дадзены параметр зададзены дыяпазон тэмператур.
Блок змяшчае два ўваходных порта, 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, створаны па зададзеным фармаце. Фармат можа быць адвольным чынам настроены на фармат, прыняты ў канкрэтнай арганізацыяй.
Унутры блока схемы выкарыстоўваюцца ўласцівасці, зададзеныя ў параметрах блока.
Акрамя аналізу адпаведнасці патрабаванняў унутраная схема блока ўтрымоўвае графік, неабходны для высновы вынікаў мадэлявання. Дадзены графік можа быць скарыстаны як для прагляду падчас разліку, так і для аналізу вынікаў пасля разліку.
Вынікі разліку перадаюцца на выхад блока і адначасова запісваюцца ў агульны файл справаздачы, які ствараецца на падставе вынікаў па ўсім праекце. (гл. мал. 8)
Прыклад справаздачы, створанай па выніках мадэлявання, уяўляе сабой файл html, створаны па зададзеным фармаце. Фармат можа быць адвольным чынам настроены на фармат, прыняты ў канкрэтнай арганізацыяй.
Малюнак 8. Прыклад файла справаздачы па выніках мадэлявання.
У дадзеным прыкладзе настройка формы справаздачы выконваецца непасрэдна ва ўласцівасцях праекта, а фармат у табліцы задаецца як глабальныя сігналы праекта. У гэтым выпадку SimInTech сам вырашае задачу налады справаздачы, а блок запісу вынікаў у файл выкарыстоўвае гэтыя радкі для запісу ў файл справаздачы.
Малюнак 9. Настройка фармату справаздачы ў глабальных сігналах праекта
Выкарыстанне базы дадзеных сігналаў для патрабаванняў.
Для аўтаматызацыі працы з наладамі ўласцівасцяў для кожнага тыпавога блока ствараецца тыпавая структура ў базе дадзеных сігналаў. (гл. мал. 10)
Малюнак 10. Прыклад структуры блока праверкі патрабаванні ў базе даных сігналаў.
База дадзеных сігналаў, забяспечвае:
- Захоўванне ўсіх неабходных параметраў патрабаванняў да сістэмы.
- Зручны прагляд існуючых у праекце патрабаванняў з зададзеных параметраў і бягучых вынікаў мадэлявання.
- Настройку аднаго блока, групы блокаў з выкарыстаннем скрыптовай мовы праграмавання. Змены ў базе дадзеных сігналаў прыводзяць да змены значэнняў уласцівасцяў блока на схеме.
- Захоўванне тэкставых апісанняў, спасылкі на пункты ТЗ ці ідэнтыфікатары ў сістэме кіравання патрабаваннямі.
Структуры базы дадзеных сігналаў для патрабаванняў могуць быць лёгка настроены на працу з іншай сістэмай кіравання патрабаваннямі, Агульная схема ўзаемадзеяння з сістэмамі кіравання патрабаванняў прадстаўлена на малюнку 11.
Малюнак 11. Схема ўзаемадзеяння з сістэмай кіравання патрабаванняў.
Паслядоўнасць узаемадзеяння тэставага праекта SimInTech з сістэмай кіравання патрабаванні наступная:
- Тэхнічнае заданне разбіваецца на патрабаванні.
- Вылучаюцца такія патрабаванні тэхнічнага задання, якія могуць быць правераны шляхам матэматычнага мадэлявання тэхнічных працэсаў.
- Атрыбуты выдзеленых патрабаванняў перадаюцца ў базу дадзеных сігналаў SimInTech у структуры тыпавых блокаў (напрыклад, максімальная і мінімальная тэмпература).
- У працэсе разліку дадзеныя структур перадаюцца ў разліковыя схемы блокаў, выконваецца аналіз і вынікі захоўваюцца базу даных сігналаў.
- Пасля завяршэння разліку вынікі аналізу перадаюцца ў сістэму кіравання патрабаваннямі.
Этапы працы з патрабаваннямі 3 - 5 могуць паўторацца падчас працэсу праектавання, калі адбываюцца змены ў канструкцыі і (або) патрабаваннях і, адпаведна, неабходна паўторная праверка ўплыву занесеных змен.
Высновы.
- Створаны прататып сістэмы забяспечвае значнае скарачэнне часу аналізу існуючых мадэляў, на прадмет адпаведнасці патрабаванням ТЗ.
- Прапанаваная тэхналогія тэсціравання выкарыстоўвае ўжо існуючыя дынамічныя мадэлі і можа быць выкарыстана нават для любых дынамічных мадэляў, у тым ліку выкананых не ў асяроддзі SimInTech.
- Выкарыстанне пакетнай арганізацыі дадзеных дазваляе ствараць пакеты праверкі патрабаванняў, раўналежна з распрацоўкай мадэляў, ці нават выкарыстоўваць дадзеныя пакеты ў якасці тэхнічнага задання на распрацоўку мадэляў.
- Тэхналогія можа быць без істотных затрат інтэграваная з існуючымі сістэмамі кіравання патрабаваннямі.
Для тых хто дачытаў да канца,
Крыніца: habr.com