Теманы улантуу , математикалык моделдөө маселесин экинчи тараптан карап көрөлү. Модель жашоонун ачык чындыкка дал келгенине ынангандан кийин, биз негизги суроого жооп бере алабыз: "бул жерде бизде эмне бар?" Техникалык объекттин моделин түзүүдө биз адатта бул объект биздин күтүүлөрүбүзгө жооп берерине ынангыбыз келет. Бул үчүн процесстердин динамикалык эсептөөлөрү жүргүзүлүп, натыйжа талаптар менен салыштырылат. Бул санариптик эгиз, виртуалдык прототип, ж.б. модалуу кичинекей балдар, алар долбоорлоо баскычында, биз пландаштырган нерсеге жетүүгө кантип ынануу маселесин чечет.
Системабыздын биз долбоорлогондой экенине кантип тез ынансак болот, биздин дизайн учуп кетеби же калкып кетеби? Ал эми учса, канча бийиктикте? Ал эми сүзүп кетсе, канчалык терең?
Бул макалада техникалык системалардын динамикалык моделдерин түзүүдө техникалык имараттын талаптарына шайкештигин текшерүүнү автоматташтыруу каралат. Мисал катары, учактын аба муздатуу системасынын техникалык спецификациясынын элементин карап көрөлү.
Биз белгилүү бир эсептөө моделинин негизинде сандык жана математикалык текшерүүгө мүмкүн болгон талаптарды карап көрөлү. Бул кандайдыр бир техникалык системага коюлган жалпы талаптардын бир гана бөлүгү экени түшүнүктүү, бирок аларды текшерүүгө биз объекттин динамикалык моделдерин түзүүгө убакытты, нервдерди жана акчаны сарптайбыз.
Документ түрүндө техникалык талаптарды сыпаттоодо ар кандай талаптардын бир нече түрүн бөлүп көрсөтүүгө болот, алардын ар бири талаптардын аткарылышын автоматтык түрдө текшерүүнү түзүү үчүн ар кандай ыкмаларды талап кылат.
Мисалы, бул кичинекей, бирок реалдуу талаптардын топтомун карап көрөлү:
- Суу тазалоо системасынын кире беришиндеги атмосфералык абанын температурасы:
унаа токтотуучу жайда - минус 35тен 35 ºСге чейин,
учууда - минус 35тен 39 ºСге чейин. - Учуудагы атмосфералык абанын статикалык басымы 700дөн 1013 ГПага чейин (526дан 760 мм рт.ст.га чейин).
- Учуудагы SVO аба соргучунун кире беришиндеги жалпы аба басымы 754дөн 1200 ГПага чейин (566дан 1050 мм рт.ст.га чейин) түзөт.
- Муздатуу абасынын температурасы:
унаа токтотуучу жайда - 27 ºС ашык эмес, техникалык блоктор үчүн - 29 ºС ашык эмес,
учуу учурунда - 25 ºС ашык эмес, техникалык блоктор үчүн - 27 ºС ашык эмес. - Муздатуу аба агымы:
токтоп турганда - кеминде 708 кг/саат,
учууда - 660 кг/сааттан кем эмес. - Прибор бөлүмдөрүндөгү абанын температурасы 60 ºС ашпайт.
- Муздаткыч абадагы майда эркин нымдуулуктун өлчөмү кургак абанын 2 г/кгдан ашпайт.
Бул чектелген талаптардын алкагында да, системада башкача каралышы керек болгон жок дегенде эки категория бар:
- системанын иштөө шарттарына талаптар (1-3-пункттар);
- системага параметрдик талаптар (3-7-пункттар).
Системанын иштөө шарттарына талаптар
Моделдөө учурунда иштелип жаткан система үчүн тышкы шарттар чектик шарттар катары же жалпы системанын иштешинин натыйжасы катары көрсөтүлүшү мүмкүн.
Динамикалык симуляцияда көрсөтүлгөн иштөө шарттары моделдөө процесси менен камтылышын камсыз кылуу зарыл.
Параметрдик системага талаптар
Бул талаптар системанын өзү тарабынан берилген параметрлер болуп саналат. Моделдөө процессинде биз бул параметрлерди эсептөөнүн натыйжасы катары ала алабыз жана ар бир конкреттүү эсептөөдө талаптар аткарылганына ынанабыз.
Талаптарды аныктоо жана коддоо
Талаптар менен иштөөнү жеңилдетүү үчүн колдонуудагы стандарттар ар бир талапка идентификатор берүүнү сунуштайт. Идентификаторлорду дайындоодо бирдиктүү коддоо системасын колдонуу абдан максатка ылайыктуу.
Талаптын коду талаптын иретинин номерин билдирген жөн гана сан болушу мүмкүн же талаптын түрүнүн кодун, ал тиешелүү системанын же бирдиктин кодун, параметр кодун, жайгашкан жер кодун жана инженер башка нерсени элестете алат. (коддоштурууну колдонуу үчүн макаланы караңыз)
1-таблица талаптарды коддоонун жөнөкөй мисалын берет.
- талаптардын булагынын коду R-талаптар ТК;
- талаптардын код түрү E - талаптар - экологиялык параметрлер, же иштөө шарттары
S - система тарабынан каралган талаптар; - аба кемесинин абалы коду 0 – каалаган, G – токтоп турат, F – учуудо;
- физикалык параметр түрү коду T – температура, P – басым, G – агымынын ылдамдыгы, нымдуулук H;
- талаптын сериялык номери.
| ID талаптар |
баяндоо | параметр |
| RGT01 | Суу муздатуу системасына кире бериштеги абанын температурасы: унаа токтотуучу жайда - минус 35ºС. 35 ºС чейин. | |
| REFT01 | Абадан коргонуу системасынын кире беришиндеги атмосфералык абанын температурасы: учуу учурунда - минус 35 ºСден 39 ºСге чейин. | |
| REFP01 | Учуудагы атмосфералык абанын статикалык басымы 700дөн 1013 гПага чейин (526дан 760 мм рт.ст.га чейин). | |
| REFP02 | Учуудагы SVO аба соргучунун кире беришиндеги жалпы аба басымы 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 секунддан ашпоого тийиш.
Мында талаптардын долбоорлоо диаграммасына старттардын санына жана жалпы иштөө убактысына каршы туруу алгоритми кошулат.
Типтүү талаптарды текшерүү блогу.
Ар бир стандарттык талапты белгилөө кутучасы белгилүү бир түрдөгү талаптын аткарылышын эсептөө үчүн иштелип чыккан. Мисалы, экологиялык талаптарга токтоп турганда жана учуп баратканда айлана-чөйрөнүн иштөө температураларынын диапазону кирет. Бул блок моделдеги абанын температурасын параметр катары кабыл алышы керек жана бул параметр көрсөтүлгөн температура диапазонун камтыганын аныкташы керек./p>
Блок эки киргизүү портун камтыйт, параметр жана шарт.
Биринчиси текшерилип жаткан параметр менен азыктанат. Бул учурда, "Тышкы температура".
Экинчи портко логикалык өзгөрмө берилет - текшерүү жүргүзүү шарты.
Эгерде TRUE (1) экинчи киргизүүдө кабыл алынса, анда блок талапты текшерүү эсебин жүргүзөт.
Эгерде экинчи киргизүү ЖАЛГАН (0) алса, анда сыноо шарттары аткарылбайт. Бул эсептөө шарттарын эске алуу үчүн зарыл. Биздин учурда, бул киргизүү моделдин абалына жараша текшерүүнү иштетүү же өчүрүү үчүн колдонулат. Эгерде симуляция учурунда аба кемеси жерде болсо, анда учуу менен байланышкан талаптар текшерилбейт, ал эми тескерисинче - аба кемеси учуп жүрсө, анда стендде иштөөгө тиешелүү талаптар текшерилбейт.
Бул киргизүү моделди орнотууда да колдонулушу мүмкүн, мисалы, эсептөөнүн баштапкы этабында. Модель талап кылынган абалга келтирилгенде, текшерүү блоктору өчүрүлөт, бирок система талап кылынган иштөө режимине жеткенде, текшерүү блоктору күйгүзүлөт.
Бул блоктун параметрлери болуп төмөнкүлөр саналат:
- чек ара шарттары: текшерүү керек болгон жогорку (UpLimit) жана төмөнкү (DownLimit) диапазондун чектери;
- чек ара диапазондорунда талап кылынган системанын экспозиция убактысы (TimeInterval) секундада;
- Сурам ID ReqName;
- диапазондон ашууга уруксат берүү Out_range - бул логикалык өзгөрмө, ал текшерилген диапазондон ашкан маани талаптын бузулушу болуп саналат.
Кээ бир учурларда, сыноо маанисинин чыгышы системанын кандайдыр бир маржага ээ экендигин жана анын иштөө диапазонунан тышкары иштеп жатканын көрсөтөт. Башка учурларда, чыгаруу система белгиленген чектерди диапазондо сактай албасын билдирет.
Сүрөт 6. Диаграммадагы типтүү касиетти текшерүү блогу жана анын параметрлери.
Бул блокту эсептөөнүн натыйжасында чыгарууда Натыйжа өзгөрмөсү түзүлөт, ал төмөнкү маанилерди алат:
- 0 – rNone, мааниси аныкталган эмес;
- 1 – Бүттү, талап аткарылды;
- 2 – rFault, талап аткарылган жок.
Блок сүрөтү төмөнкүлөрдү камтыйт:
- идентификатор тексти;
- өлчөө чектеринин параметрлеринин санариптик дисплейлери;
- параметр статусунун түс идентификатору.
Блоктун ичинде өтө татаал логикалык жыйынтык схемасы болушу мүмкүн.
Мисалы, 6-сүрөттө көрсөтүлгөн агрегаттын иштөө температурасынын диапазонун текшерүү үчүн ички схема 7-сүрөттө көрсөтүлгөн.
Сүрөт 7. Температура диапазонун аныктоо бирдигинин ички схемасы.
Схема блогунун ичинде блоктун параметрлеринде көрсөтүлгөн касиеттер колдонулат.
Блоктун ички диаграммасы талаптарга шайкештигин талдоодон тышкары, симуляциянын натыйжаларын көрсөтүү үчүн зарыл болгон графикти камтыйт. Бул графикти эсептөө учурунда көрүү үчүн да, эсептөөдөн кийин натыйжаларды талдоо үчүн да колдонсо болот.
Эсептөө натыйжалары блоктун чыгышына берилет жана бир эле учурда бүткүл долбоор боюнча жыйынтыктардын негизинде түзүлүүчү жалпы отчет файлында жазылат. (8-сүрөттү караңыз)
Симуляциянын натыйжаларынын негизинде түзүлгөн отчеттун мисалы катары берилген форматка ылайык түзүлгөн html файлы саналат. Форматты белгилүү бир уюм кабыл алган форматка каалагандай конфигурациялоого болот.
Схема блогунун ичинде блоктун параметрлеринде көрсөтүлгөн касиеттер колдонулат.
Блоктун ички диаграммасы талаптарга шайкештигин талдоодон тышкары, симуляциянын натыйжаларын көрсөтүү үчүн зарыл болгон графикти камтыйт. Бул графикти эсептөө учурунда көрүү үчүн да, эсептөөдөн кийин натыйжаларды талдоо үчүн да колдонсо болот.
Эсептөө натыйжалары блоктун чыгышына берилет жана бир эле учурда бүткүл долбоор боюнча жыйынтыктардын негизинде түзүлүүчү жалпы отчет файлында жазылат. (8-сүрөттү караңыз)
Симуляциянын натыйжаларынын негизинде түзүлгөн отчеттун мисалы катары берилген форматка ылайык түзүлгөн html файлы саналат. Форматты белгилүү бир уюм кабыл алган форматка каалагандай конфигурациялоого болот.
8-сүрөт. Модуляциянын натыйжаларына негизделген отчет файлынын мисалы.
Бул мисалда отчет формасы түздөн-түз долбоордун касиеттеринде конфигурацияланган жана таблицадагы формат глобалдык долбоор сигналдары катары коюлган. Бул учурда SimInTech өзү отчетту орнотуу маселесин чечет жана натыйжаларды файлга жазуу блогу отчет файлына жазуу үчүн бул саптарды колдонот.
Сүрөт 9. Глобалдык долбоордун сигналдарында отчеттун форматын орнотуу
талаптар үчүн сигнал базасын колдонуу.
Мүлктүн орнотуулары менен иштөөнү автоматташтыруу үчүн ар бир типтүү блок үчүн сигналдар базасында стандарттуу структура түзүлөт. (10-сүрөттү караңыз)
Сүрөт 10. Сигнал базасындагы талаптарды текшерүү блогунун структурасынын мисалы.
Сигнал базасы төмөнкүлөрдү камсыз кылат:
- Бардык керектүү система талаптарынын параметрлерин сактоо.
- Белгиленген параметрлерден жана учурдагы моделдөө натыйжаларынан учурдагы долбоордун талаптарын ыңгайлуу көрүү.
- Сценарий программалоо тилин колдонуу менен бир блокту же блоктордун тобун орнотуу. Сигнал базасындагы өзгөрүүлөр диаграммада блоктун касиетинин баалуулуктарынын өзгөрүшүнө алып келет.
- Тексттик сүрөттөмөлөрдү, техникалык мүнөздөмөлөргө шилтемелерди же талаптарды башкаруу системасындагы идентификаторлорду сактоо.
Талаптар үчүн сигналдар базасынын структураларын үчүнчү тараптын талаптарды башкаруу системасы менен иштөө үчүн оңой конфигурациялоого болот.Талаптарды башкаруу системалары менен өз ара аракеттенүүнүн жалпы диаграммасы 11-сүрөттө берилген.
Сүрөт 11. Талаптарды башкаруу системасы менен өз ара аракеттенүү диаграммасы.
SimInTech тест долбоору менен талаптарды көзөмөлдөө тутумунун ортосундагы өз ара аракеттенүүнүн ырааттуулугу төмөнкүдөй:
- Техникалык тапшырмалар талаптарга бөлүнөт.
- Техникалык шарттардын талаптары аныкталган, алар техникалык процесстерди математикалык моделдөө жолу менен текшерилет.
- Тандалган талаптардын атрибуттары SimInTech сигналдар базасына стандарттык блоктордун түзүмүндө (мисалы, максималдуу жана минималдуу температура) өткөрүлүп берилет.
- Эсептөө процессинде структуралык маалыматтар блок-конструктордук схемаларга өткөрүлүп берилет, талдоо жүргүзүлөт жана натыйжалар сигналдар базасында сакталат.
- Эсептөө аяктагандан кийин, талдоо натыйжалары талаптарды башкаруу системасына өткөрүлүп берилет.
Талаптардын 3-5-кадамдары долбоорлоо процессинде долбоорго жана/же талаптарга өзгөртүүлөр киргизилгенде жана өзгөртүүлөрдүн таасирин кайра текшерүү керек болгондо кайталанышы мүмкүн.
Корутунду.
- Түзүлгөн системанын прототиби техникалык шарттардын талаптарына ылайык келүүсү үчүн колдонуудагы моделдердин талдоо убактысын олуттуу кыскартууну камсыз кылат.
- Сунушталган тестирлөө технологиясы мурунтан эле бар динамикалык моделдерди колдонот жана ал тургай SimInTech чөйрөсүндө аткарылбаган бардык динамикалык моделдер үчүн да колдонулушу мүмкүн.
- Пакеттик маалыматтарды уюштурууну колдонуу моделди иштеп чыгууга параллелдүү талаптарды текшерүү пакеттерин түзүүгө, ал тургай бул пакеттерди моделди иштеп чыгуу үчүн техникалык мүнөздөмө катары колдонууга мүмкүндүк берет.
- Технологияны учурдагы талаптарды башкаруу системалары менен олуттуу чыгымдарсыз интеграциялоого болот.
Аягына чейин окугандар үчүн
Source: www.habr.com