Тақырыпты жалғастыру , математикалық модельдеу мәселесін екінші жағынан қарастырайық. Модель өмірдің нақты шындыққа сәйкес келетініне көз жеткізгеннен кейін, біз негізгі сұраққа жауап бере аламыз: «бұл жерде бізде не бар?» Техникалық объектінің үлгісін жасау кезінде біз әдетте бұл нысанның біздің күткенімізге сай келетініне көз жеткізгіміз келеді. Осы мақсатта процестердің динамикалық есептеулері жүргізіледі және нәтиже талаптармен салыстырылады. Бұл сандық егіз, виртуалды прототип және т.б. Дизайн кезеңінде біз жоспарлаған нәрсеге қол жеткізе алатынымызға қалай көз жеткізу мәселесін шешетін сәнді кішкентай балалар.
Жүйенің дәл біз жобалағандай екеніне қалай тез көз жеткізуге болады, біздің дизайн ұшады ма, әлде қалқып кете ме? Ал ұшатын болса, қанша биіктікте? Ал егер ол қалқып кетсе, қаншалықты терең?
Бұл мақалада техникалық жүйелердің динамикалық үлгілерін құру кезінде техникалық ғимараттың талаптарына сәйкестігін тексеруді автоматтандыру қарастырылады. Мысал ретінде ұшақтың ауаны салқындату жүйесінің техникалық сипаттамасының элементін қарастырайық.
Біз нақты есептеу үлгісіне негізделген сандық және математикалық тексеруге болатын талаптарды қарастырамыз. Бұл кез келген техникалық жүйеге қойылатын жалпы талаптардың бір бөлігі ғана екені түсінікті, бірақ оларды тексеру үшін біз объектінің динамикалық үлгілерін жасауға уақыт, жүйке және ақша жұмсаймыз.
Құжат түріндегі техникалық талаптарды сипаттау кезінде әр түрлі талаптардың бірнеше түрін бөлуге болады, олардың әрқайсысы талаптардың орындалуын автоматты түрде тексеруді қалыптастырудың әртүрлі тәсілдерін талап етеді.
Мысалы, осы шағын, бірақ нақты талаптар жиынтығын қарастырыңыз:
- Су тазарту жүйесіне кіре берістегі атмосфералық ауа температурасы:
тұрақта - минус 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-талаптар ТҚ;
- талаптардың код түрі Е - талаптар - қоршаған ортаның параметрлері, немесе жұмыс жағдайлары
S – жүйемен қамтамасыз етілген талаптар; - әуе кемесінің күй коды 0 – кез келген, G – тұрақта, F – ұшуда;
- физикалық параметр түрінің коды T – температура, P – қысым, G – ағын жылдамдығы, H ылғалдылығы;
- талаптың сериялық нөмірі.
| ID талаптар |
сипаттамасы | Параметр |
| REGT01 | Суды салқындату жүйесіне кіре берістегі қоршаған ауа температурасы: тұрақта - минус 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) болса, онда сынақ шарттары орындалмайды. Бұл есептеу шарттарын ескеру үшін қажет. Біздің жағдайда бұл кіріс модель күйіне байланысты тексеруді қосу немесе өшіру үшін пайдаланылады. Модельдеу кезінде әуе кемесі жерде болса, онда ұшуға қатысты талаптар тексерілмейді, ал керісінше - егер әуе кемесі ұшуда болса, онда стендте жұмыс істеуге қатысты талаптар тексерілмейді.
Бұл енгізуді үлгіні орнату кезінде де пайдалануға болады, мысалы, есептеудің бастапқы кезеңінде. Модель қажетті күйге келтірілгенде, тексеру блоктары өшіріледі, бірақ жүйе қажетті жұмыс режиміне жеткенде, тексеру блоктары қосылады.
Бұл блоктың параметрлері:
- шекаралық шарттар: тексеру қажет жоғарғы (Жоғары шек) және төменгі (Төменгі шек) диапазон шектері;
- секундтарда шекаралық диапазондарда (TimeInterval) қажетті жүйенің экспозиция уақыты;
- Сұраныс идентификаторы ReqName;
- Ауқымнан асып кету рұқсаты Out_range - бұл тексерілген диапазоннан асатын мән талапты бұзу екенін анықтайтын логикалық айнымалы.
Кейбір жағдайларда сынақ мәнінің шығысы жүйенің белгілі бір шегі бар екенін және оның жұмыс ауқымынан тыс жұмыс істеуі мүмкін екенін көрсетеді. Басқа жағдайларда шығыс жүйе белгіленген мәндерді ауқымда сақтай алмайтынын білдіреді.
Сурет 6. Диаграммадағы сипатты тексеру блогы және оның параметрлері.
Осы блокты есептеу нәтижесінде шығыста Нәтиже айнымалысы қалыптасады, ол келесі мәндерді қабылдайды:
- 0 – rNone, мән анықталмаған;
- 1 – rОрындалды, талап орындалды;
- 2 – rFault, талап орындалмаған.
Блок суреті мыналарды қамтиды:
- идентификатор мәтіні;
- өлшеу шектері параметрлерінің цифрлық дисплейлері;
- параметр күйінің түс идентификаторы.
Блоктың ішінде өте күрделі логикалық қорытынды тізбегі болуы мүмкін.
Мысалы, 6-суретте көрсетілген қондырғының жұмыс температурасының диапазонын тексеру үшін ішкі схема 7-суретте көрсетілген.
Сурет 7. Температура диапазонын анықтау қондырғысының ішкі диаграммасы.
Схема блогының ішінде блок параметрлерінде көрсетілген қасиеттер қолданылады.
Талаптарға сәйкестікті талдаудан басқа, блоктың ішкі диаграммасында модельдеу нәтижелерін көрсету үшін қажетті график бар. Бұл графикті есептеу кезінде қарау үшін де, есептеуден кейінгі нәтижелерді талдау үшін де пайдалануға болады.
Есептеу нәтижелері блоктың шығысына беріледі және бір уақытта бүкіл жоба бойынша нәтижелер негізінде құрылатын жалпы есеп файлында жазылады. (8-суретті қараңыз)
Модельдеу нәтижелері бойынша жасалған есептің мысалы берілген пішімге сәйкес жасалған html файлы болып табылады. Пішімді белгілі бір ұйым қабылдаған пішімге ерікті түрде конфигурациялауға болады.
Схема блогының ішінде блок параметрлерінде көрсетілген қасиеттер қолданылады.
Талаптарға сәйкестікті талдаудан басқа, блоктың ішкі диаграммасында модельдеу нәтижелерін көрсету үшін қажетті график бар. Бұл графикті есептеу кезінде қарау үшін де, есептеуден кейінгі нәтижелерді талдау үшін де пайдалануға болады.
Есептеу нәтижелері блоктың шығысына беріледі және бір уақытта бүкіл жоба бойынша нәтижелер негізінде құрылатын жалпы есеп файлында жазылады. (8-суретті қараңыз)
Модельдеу нәтижелері бойынша жасалған есептің мысалы берілген пішімге сәйкес жасалған html файлы болып табылады. Пішімді белгілі бір ұйым қабылдаған пішімге ерікті түрде конфигурациялауға болады.
Сурет 8. Модельдеу нәтижелеріне негізделген есеп файлының мысалы.
Бұл мысалда есеп пішіні тікелей жоба сипаттарында конфигурацияланады және кестедегі пішім ғаламдық жоба сигналдары ретінде орнатылады. Бұл жағдайда SimInTech өзі есепті орнату мәселесін шешеді, ал нәтижелерді файлға жазу блогы есеп файлына жазу үшін осы жолдарды пайдаланады.
Сурет 9. Жаһандық жоба сигналдарында есеп пішімін орнату
Талаптар үшін сигналдар базасын пайдалану.
Сипат параметрлерімен жұмысты автоматтандыру үшін сигналдар базасында әрбір типтік блок үшін стандартты құрылым құрылады. (10-суретті қараңыз)
Сурет 10. Сигнал деректер қорындағы талаптарды тексеру блогының құрылымының мысалы.
Сигнал базасы мыналарды қамтамасыз етеді:
- Жүйе талаптарының барлық қажетті параметрлерін сақтау.
- Белгіленген параметрлерден және ағымдағы модельдеу нәтижелерінен бар жоба талаптарын ыңғайлы қарау.
- Сценарийлік бағдарламалау тілін пайдаланып бір блокты немесе блоктар тобын орнату. Сигнал базасындағы өзгерістер диаграммадағы блок қасиетінің мәндерінің өзгеруіне әкеледі.
- Мәтіндік сипаттамаларды, техникалық сипаттамаларға сілтемелерді немесе талаптарды басқару жүйесінде идентификаторларды сақтау.
Талаптар үшін сигналдық дерекқор құрылымдары үшінші тараптың талаптарды басқару жүйесімен жұмыс істеу үшін оңай конфигурациялануы мүмкін.Талаптарды басқару жүйелерімен өзара әрекеттесуінің жалпы диаграммасы 11-суретте көрсетілген.
Сурет 11. Талаптарды басқару жүйесімен өзара әрекеттесу диаграммасы.
SimInTech сынақ жобасы мен талаптарды басқару жүйесі арасындағы өзара әрекеттесу реті келесідей:
- Техникалық тапсырма талаптарға бөлінген.
- Техникалық процесстерді математикалық модельдеу арқылы тексеруге болатын техникалық шарттар талаптары анықталған.
- Таңдалған талаптардың атрибуттары SimInTech сигналдар базасына стандартты блоктар құрылымында беріледі (мысалы, максималды және ең төменгі температура).
- Есептеу процесі кезінде құрылым деректері блок-конструкторлық диаграммаларға беріледі, талдау жүргізіледі және нәтижелер сигналдар базасында сақталады.
- Есептеу аяқталғаннан кейін талдау нәтижелері талаптарды басқару жүйесіне беріледі.
3-тен 5-ке дейінгі талаптар қадамдары дизайнға және/немесе талаптарға өзгерістер енгізілгенде және өзгерістердің әсерін қайта сынау қажет болғанда жобалау процесі кезінде қайталануы мүмкін.
Қорытындылар.
- Жүйенің құрылған прототипі техникалық шарттар талаптарына сәйкестігіне қолданыстағы үлгілерді талдау уақытын айтарлықтай қысқартуды қамтамасыз етеді.
- Ұсынылған тестілеу технологиясы бұрыннан бар динамикалық үлгілерді пайдаланады және SimInTech ортасында орындалмағандарды қоса, кез келген динамикалық үлгілер үшін де пайдаланылуы мүмкін.
- Пакеттік деректерді ұйымдастыруды пайдалану үлгіні әзірлеумен қатар талаптарды тексеру пакеттерін жасауға немесе тіпті осы пакеттерді үлгі әзірлеуге арналған техникалық сипаттамалар ретінде пайдалануға мүмкіндік береді.
- Технологияны қолданыстағы талаптарды басқару жүйелерімен елеулі шығындарсыз біріктіруге болады.
Соңына дейін оқығандар үшін
Ақпарат көзі: www.habr.com