Duke vazhdojmë temën , le të shohim problemin e modelimit matematikor nga një këndvështrim tjetër. Pasi të ketë përfunduar që modeli i përket realitetit të jetës, mund të përgjigjemi në pyetjen kryesore: «çfarë kemi këtu, në të vërtetë?». Kur krijojmë një model të një objekti teknik, zakonisht dëshirojmë të sigurohemi që ky objekt do të përmbushë pritshmëritë tona. Për këtë bëhen llogaritjet dinamikore të proceseve dhe rezultati krahasohet me kërkesat. Kjo është ajo që quhet binjak dixhital, prototip virtual dhe gjëra të tjera moderne, të cilat në fazën e projektimit zgjidhin detyrën se si të arrijmë të kemi atë që kemi planifikuar.
Si mund ta sigurojmë shpejt që sistemi ynë është pikërisht ajo që po projektojmë, do të fluturojë apo do të notojë, ndërtimi ynë? Nëse fluturon, sa lart? Nëse noton, sa thellë?
Në këtë artikull shqyrtohet automatizimi i verifikimit të përmbushjes së kërkesave të një ndërtese teknike gjatë krijimit të modeleve dinamikore të sistemeve teknike. Si një shembull, le të shohim një element të detyrës teknike për sistemin e ftohjes me ajër të një aparati fluturues.
Ne shqyrtojmĂ« ato kĂ«rkesa qĂ« mund tĂ« shprehen numĂ«rish dhe tĂ« verifikohen matematikisht mbi bazĂ«n e njĂ« modeli tĂ« caktuar llogaritar. ĂshtĂ« e qartĂ« se kjo Ă«shtĂ« vetĂ«m njĂ« pjesĂ« e kĂ«rkesave tĂ« pĂ«rgjithshme pĂ«r çdo sistem teknik, por pikĂ«risht pĂ«r verifikimin e tyre ne shpenzojmĂ« kohĂ«, nerva dhe para pĂ«r tĂ« krijuar modele dinamike tĂ« objektit.
Kur përshkruhen kërkesat teknike në formën e dokumenteve, mund të distinctoren disa lloje të ndryshme kërkesash, çdo njëra prej të cilave kërkon qasje të ndryshme për formimin e verifikimit automatik të përmbushjes së kërkesave.
Për shembull, le të shqyrtojmë një grup të vogël, por të vërtetë kërkesash:
- Temperatura e ajrit atmosferik në hyrje të sistemit të ftohjes me ajër:
nĂ« parkim - nga minus 35 deri nĂ« 35 ÂșC,
nĂ« fluturim - nga minus 35 deri nĂ« 39 ÂșC. - Presioni statik i ajrit atmosferik nĂ« fluturim - nga 700 deri nĂ« 1013 GPa (nga 526 deri nĂ« 760 mm Hg).
- Presioni i plotë i ajrit në hyrje të pompës së ajrit në fluturim - nga 754 deri në 1200 GPa (nga 566 deri në 1050 mm Hg).
- Temperatura e ajrit të ftohjes:
nĂ« parkim - jo mĂ« shumĂ« se 27 ÂșC, pĂ«r blloqet teknike - jo mĂ« shumĂ« se 29 ÂșC,
nĂ« fluturim â jo mĂ« shumĂ« se 25 ÂșC, pĂ«r blloqet teknike â jo mĂ« shumĂ« se 27 ÂșC. - Shpenzimi i ajrit tĂ« ftohjes:
nĂ« parkim â jo mĂ« pak se 708 kg/h,
nĂ« fluturim â jo mĂ« pak se 660 kg/h. - Temperatura e ajrit nĂ« ndarjet e instrumenteve â jo mĂ« shumĂ« se 60 ÂșC.
- Sasia e lagĂ«shtirĂ«s sĂ« imĂ«t tĂ« lirĂ« nĂ« ajrin e ftohjes â jo mĂ« shumĂ« se 2 g/kg ajri tĂ« thatĂ«.
Edhe në një set të tillë të kufizuar kërkesash, mund të dallohen të paktën dy kategori që duhet të trajtohen ndryshe në sistem:
- kërkesat e kushteve të funksionimit të sistemit (nënpika 1-3);
- kërkesat parametrike ndaj sistemit (nënpika 3-7).
Kërkesat e kushteve të funksionimit të sistemit
Kushtet ekstreme për sistemin në zhvillim mund të përcaktohen si kushte kufizuese, ose si rezultat i funksionimit të përgjithshëm të sistemit.
Në modelimin dinamik është e nevojshme të sigurohet që regjimet e caktuara të funksionimit përfshihen në procesin e modelimit.
KĂ«rkesat parametrike ndaj sistemit
Këto kërkesa përbëjnë parametrat që sigurohen nga vetë sistemi. Gjatë procesit të modelimit ne mund të marim këto parametra si rezultate të llogaritjes dhe të sigurohemi që kërkesat plotësohen në çdo llogaritje të veçantë.
Identifikimi dhe kodifikimi i kërkesave
Për lehtësi në punë me kërkesat, standartet ekzistuese rekomandojnë caktimin e një identifikatori për secilën kërkesë. Kur caktohen identifikatorë, është shumë e dëshirueshme të përdoret një sistem i njejtë kodimi.
Kodi i kërkesës mund të jetë thjesht një numër që pasqyron numrin rendor të kërkesës, ose mund të përmbajë kodin e tipit të kërkesës, kodin e sistemit ose agregatit të cilit i referohet, kodin e parametrave, kodin e vendndodhjes dhe shumë më tepër që inxhinieri mund të imagjinojë. (për një shembull të përdorimit të kodifikimit shiko artikullin)
Në tabelën 1 është paraqitur një shembull i thjeshtë i kodifikimit të kërkesave.
- kodi i burimit të kërkesave R - kërkesat e PZ;
- kodi i tipit tĂ« kĂ«rkesave E â kĂ«rkesat â parametrat e mjedisit, ose kushtet e funksionimit
S â kĂ«rkesat qĂ« sigurohen nga sistemi; - kodi i gjendjes sĂ« avionit 0 â çdo gjĂ«, G â nĂ« parkim, F â nĂ« fluturim;
- kodi i tipit tĂ« parametrave fizike T â temperatura, P â presioni, G â shpenzimi, lagĂ«shtia H;
- numri rendor i kërkesës.
| ID KĂ«rkesat | PĂ«rshkrimi | Parametri |
| REGT01 | Temperatura e ajrit atmosferik nĂ« hyrje tĂ« SVO: nĂ« parkim â nga minus 35ÂșC deri nĂ« 35 ÂșC. | |
| REFT01 | Temperatura e ajrit atmosferik nĂ« hyrje tĂ« SVO: nĂ« fluturim â nga minus 35 ÂșC deri nĂ« 39 ÂșC. | |
| REFP01 | Tensioni statik i ajrit atmosferik në fluturim nga 700 deri në 1013 hPa (nga 526 deri në 760 mmHg). | |
| REFP02 | Tensioni total i ajrit në hyrje të filtrit të ajrit SVO në fluturim nga 754 deri në 1200 hPa (nga 566 deri në 1050 mmHg). | |
| RSGT01 | Temperatura e ajrit tĂ« ftohjes: nĂ« parkim jo mĂ« shumĂ« se 27 ÂșC. | |
| RSGT02 | Temperatura e ajrit tĂ« ftohjes: nĂ« parkim, pĂ«r bloket teknike jo mĂ« shumĂ« se 29 ÂșC. | |
| RSFT01 | Temperatura e ajrit tĂ« ftohjes nĂ« fluturim jo mĂ« shumĂ« se 25 ÂșC. | |
| RSFT02 | Temperatura e ajrit tĂ« ftohjes: nĂ« fluturim, pĂ«r bloket teknike jo mĂ« shumĂ« se 27 ÂșC. | |
| RSGG01 | Shkalla e fluksit të ajrit të ftohjes: në parkim jo më pak se 708 kg/h. | |
| RSFG01 | Shkalla e fluksit të ajrit të ftohjes: në fluturim jo më pak se 660 kg/h. | |
| RS0T01 | Temperatura e ajrit nĂ« sallat e instrumenteve jo mĂ« shumĂ« se 60 ÂșC. | |
| RSH01 | Sasia e lagështisë shumë të imët në ajrin e ftohjes jo më shumë se 2 g/kg ajri të thatë. |
Projekti i sistemit të verifikimit të kërkesave.
Për çdo kërkesë të llogaritur ekziston një algoritëm për vlerësimin e përputhshmërisë së parametrave të llogaritur dhe atyre të caktuara në kërkesë. Në thelb, çdo sistem menaxhimi gjithmonë përmban algoritme verifikimi kërkesash thjesht si një rregull. Edhe çdo rregullator i përmban ato. Nëse temperatura kalon kufirin, kondicioneri ndizet. Pra, faza e parë e çdo rregullimi është kontrolli i përputhshmërisë së parametrave me kërkesën.
Dhe pasi verifikimi është një algoritëm, mund të përdoren të njëjtat mjete dhe instrumente që përdorim për të krijuar programe menaxhimi. Për shembull, mjedisi SimInTech lejon krijimin e paketave të projekteve që përmbajnë pjesë të ndryshme të modelit, të realizuara si projekte të veçanta (modeli i objektit, modeli i sistemit të menaxhimit, modeli i ambientit etj.).
Projekti i verifikimit të kërkesave në këtë rast bëhet një projekt algoritmetik dhe lidhet me paketën e modelit. Në mënyrë dinamike, ai realizon analizë të përputhshmërisë me kërkesat e specifikimit teknik.
Një shembull i mundshëm për përshkrimin e projektit të sistemit është paraqitur në figurën 1.
Figura 1. Shembulli i përshkrimit të projektit të verifikimit.
Po të njëjtën mënyrë si për algoritmet e menaxhimit, kërkesat mund të paraqiten si një set fletësh. Për lehtësinë e punës me algoritmet në mjediset e modelimit strukturor si SimInTech, Simulink, AmeSim, përdoren mundësitë e krijimit të strukturave shumë-nivelëshe në formën e nënmodeleve. Kjo organizim lejon grupimin e kërkesave të ndryshme në sete për të simplifikuar punën me masivin e kërkesave, ashtu siç bëhet për algoritmet e menaxhimit (shih. figurën 2).
Figura 2. Struktura hierarkike e modelit të verifikimit të kërkesave.
Për shembull, në rastin në shqyrtim janë identifikuar dy grupe: kërkesa për ambientin dhe kërkesa direkte për sistemin. Prandaj përdoret një strukturë të dhënash me dy nivele: dy grupe, secila prej të cilave është një fletë algoritmi.
Për t'i lidhur të dhënat me modelin, përdoret një skemë standarde e formimit të bazës së të dhënave të sinjaleve, ku ruhen të dhënat për shkëmbimin midis pjesëve të projektit.
Gjatë krijimit dhe testimit të softuerit, në këtë bazë vendosen leximet e sensorëve (analogët e sensorëve realë të sistemit), që përdoren nga sistemi i menaxhimit.
Për projektin e testimit, në të njëjtën bazë të dhënash mund të ruhet çdo parametrar, që llogaritet në modelin dinamik, dhe kështu të përdoret për verifikimin e përmbushjes së kërkesave.
Modeli dinamik në këtë rast mund të realizohet në çdo sistem modelimi matematikor ose madje si një program ekzekutues. Kërkesa e vetme është që të ekzistojnë ndërfaqe programore për të nxjerrë të dhëna për modelimin në ambientin e jashtëm.
Figura 3. Lidhja e projektit të verifikimit me modelin kompleks.
Shembulli i fletës bazë të verifikimit të kërkesave përfaqësohet në figurën 4. Nga këndvështrimi i zhvilluesit, ajo paraqet një skemë të zakonshme llogaritëse, në të cilën në mënyrë grafike paraqitet algoritmi i verifikimit të kërkesave.
Figura 4. Fleta e verifikimit të kërkesave.
Pjesët kryesore të fletës së verifikimit janë përshkruar në figurën 5. Algoritmi i verifikimit formohet në mënyrë të ngjashme me skemat llogaritative të algoritmeve të menaxhimit. Në anën e djathtës ndodhet blloku i leximit të sinjaleve nga baza e të dhënave. Në këtë bllok ndodh qasja në bazën e të dhënave të sinjaleve gjatë modelimit.
Signalet e marrë janë analizuar për të llogaritur kushtet e verifikimit të kërkesave. Në këtë rast, bëhet analiza e lartësisë për të përcaktuar pozitat e avionit (nëse ndodhet në qëndrim apo në fluturim). Për këtë qëllim, mund të përdoren edhe sinjalet e tjera dhe parametrat e modelit të llogaritur.
Kushtet e verifikimit dhe parametrat e verifikuar transmetohen në blloket standarde të verifikimit, ku kryhet analiza e të dhënave të këtyre parametrave për përputhshmëri me kërkesat e caktuara. Rezultatet regjistrohen në bazën e të dhënave të signaleve në një mënyrë që mund të përdoren për formimin automatik të një liste kontrolli.
Figura 5. Struktura e fletës të llogaritjes së verifikimit të kërkesave.
Për parametrat e verifikimit, nuk është e nevojshme të përdoren vetëm sinjalet që ndodhen në bazën e të dhënave, të cilat drejtohen nga parametrat e llogaritur gjatë procesit të modelimit. Asgjë nuk e pengon projektimin e llogarive të tjera siç bëjmë për kushtet e verifikimit.
Për shembull, një kërkesë e tillë:
Numri i aktivizimeve të sistemit korrigjues gjatë fluturimit drejt qëllimit nuk duhet të kalojë numrin 5, dhe koha totale e funksionimit të sistemit korrigjues nuk duhet të kalojë 30 sekonda.
Në këtë rast, në skemën llogaritëse të projektit të kërkesave, shtohet algoritmi i numërimit të aktivizimeve dhe kohës totale të funksionimit.
Blloku standard i verifikimit të kërkesave.
Ădo bllok standard i verifikimit tĂ« kĂ«rkesave Ă«shtĂ« i destinuar pĂ«r llogaritjen e pĂ«rmbushjes sĂ« njĂ« kĂ«rkese tĂ« caktuar. PĂ«r shembull, nĂ« kĂ«rkesat pĂ«r ambientin, paraqitet njĂ« gamĂ« temperaturash punuese tĂ« ajrit ambient gjatĂ« qĂ«ndrimit dhe fluturimit. Ky bllok duhet tĂ« marrĂ« si parametĂ«r temperaturĂ«n e ajrit nĂ« model dhe tĂ« pĂ«rcaktojĂ« nĂ«se ky parametr mbulon gamĂ«n e kĂ«rkuar tĂ« temperaturĂ«s.
Blloku ka dy porte hyrëse, param dhe condition.
Në portin e parë shkon parametri i verifikuar. Në këtë rast, "Temperatura e ambientit të jashtëm".
NĂ« portin e dytĂ« shkon njĂ« variable logjike â kushti i pĂ«rmbushjes sĂ« verifikimit.
Nëse në hyrjen e dytë arrin TRUE (1), atëherë blloku kryen llogaritjen e verifikimit të kërkesës.
Nëse hyrja e dytë merr FALSE (0), atëherë kushtet e kontrollit nuk përmbushen. Kjo është e nevojshme që të mund të merret parasysh kushtet e llogaritjes. Në rastin tonë, kjo hyrje përdoret për të aktivizuar ose çaktivizuar kontrollin në përputhje me gjendjen e modelit. Nëse AI është në tokë gjatë modelimit, kërkesat lidhur me fluturimin nuk kontrollohen, dhe anasjelltas - nëse AI është në fluturim, nuk kontrollohen kërkesat që lidhen me operacionin në parkim.
Kjo hyrje gjithashtu mund të përdoret gjatë konfigurimit të modelit, për shembull në fazën fillestare të llogaritjes. Kur modeli vendoset në gjendjen e kërkuar, bloket e kontrollit janë të çaktivizuara, por sapo sistemi arrin mënyrën e kërkuar të funksionimit, bloket e kontrollit aktivizohen.
Si parametra të këtij bloku caktohen:
- kushtet kufizuese: kufiri më i lartë (UpLimit) dhe kufiri më i ulët (DownLimit) të intervaleve që duhet të kontrollohen;
- koha e kërkuar e qëndrimit të sistemit në intervalet kufizuese (TimeInterval) në sekonda;
- identifikatori i kërkesës ReqName;
- pranueshmëria e daljes jashtë intervalit Out_range - një variabël booleane që përcakton nëse dalja e vlerës përjashtohet përmbushjen e kërkesës.
Në disa raste, dalja e vlerës së kontrolluar do të thotë se sistemi ka rezerva dhe mund të funksionojë jashtë intervalit të punës. Në raste të tjera, dalja do të thotë se sistemi nuk arrin të mbajë parametrat e caktuar brenda intervalit.
Figura 6. Bloku tipik i kontrollit të pronës në diagram dhe parametrat e tij.
Si rezultat i llogaritjes së këtij bloku, formohet variabla Result, e cila merr vlerat e mëposhtme:
- 0 â rNone, vlera nuk Ă«shtĂ« e pĂ«rcaktuar;
- 1 â rDone, kĂ«rkesa plotĂ«sohet;
- 2 â rFault, kĂ«rkesa nuk plotĂ«sohet.
Imazhi i blokut përfshin:
- tekstin e identifikatorit;
- shfaqjet numerike të parametrave të kufijve të matjes;
- identifikuesin e ngjyrës së gjendjes së parametrave.
Brenda blokut mund të ndodhen skema të mjaftueshme komplekse të përfundimit logjik.
Për shembull, për të kontrolluar intervalin e temperaturave të blokut të ilustruar në figurën 6, skema e brendshme paraqitet në figurën 7.
Figura 7. Skema e brendshme e blokut për përcaktimin e intervalit të temperaturave.
Brenda skemës së blokut përdoren pronësi, të caktuara në parametrat e blokut.
Përveç analizës së përputhshmërisë me kërkesat, skema e brendshme e bllokut përmban një grafik, i nevojshëm për paraqitjen e rezultateve të modelimit. Ky grafik mund të përdoret si për shikimin gjatë llogaritjes, ashtu edhe për analizën e rezultateve pas llogaritjes.
Rezultatet e llogaritjes dërgohen në daljen e bllokut dhe njëkohësisht regjistrohen në një skedar të përgjithshëm raporti, i cili krijohet mbi bazën e rezultateve për të gjithë projektin. (shih. fig. 8)
Shembulli i raportit, i krijuar sipas rezultateve të modelimit, është një skedar html, i krijuar sipas një formati të caktuar. Formati mund të konfigurohet në mënyrë arbitrare në formatin e pranuar në organizatë përkatëse.
Brenda skemës së blokut përdoren pronësi, të caktuara në parametrat e blokut.
Përveç analizës së përputhshmërisë me kërkesat, skema e brendshme e bllokut përmban një grafik, i nevojshëm për paraqitjen e rezultateve të modelimit. Ky grafik mund të përdoret si për shikimin gjatë llogaritjes, ashtu edhe për analizën e rezultateve pas llogaritjes.
Rezultatet e llogaritjes dërgohen në daljen e bllokut dhe njëkohësisht regjistrohen në një skedar të përgjithshëm raporti, i cili krijohet mbi bazën e rezultateve për të gjithë projektin. (shih. fig. 8)
Shembulli i raportit, i krijuar sipas rezultateve të modelimit, është një skedar html, i krijuar sipas një formati të caktuar. Formati mund të konfigurohet në mënyrë arbitrare në formatin e pranuar në organizatë përkatëse.
Figura 8. Shembulli i skedarit të raportit sipas rezultateve të modelimit.
Në këtë shembull, konfigurimi i formatit të raportit bëhet direkt në pronësitë e projektit, ndërsa formati në tabelë caktohet si sinjale globale të projektit. Në këtë rast, SimInTech vetë zgjidh problemin e konfigurimit të raportit, dhe blloku i regjistrimit të rezultateve në skedar përdor këto rrjeshta për të shkruar në skedarin e raportit.
Figura 9. Konfigurimi i formatit të raportit në sinjalet globale të projektit
Përdorimi i bazës së të dhënave të sinjaleve për kërkesat.
Për automatizimin e punës me konfigurimet e pronësive për çdo bllok tipik, krijohet një strukturë tipike në bazën e të dhënave të sinjaleve. (shih. fig. 10)
Figura 10. Shembulli i strukturës së bllokut të verifikimit të kërkesave në bazën e të dhënave të sinjaleve.
Baza e të dhënave të sinjaleve siguron:
- Ruajtjen e të gjitha parametrave të nevojshëm për kërkesat ndaj sistemit.
- Shikimin e lehtë të kërkesave ekzistuese në projekt nga parametrat e caktuar dhe rezultatet aktuale të modelimit.
- Konfigurimin e një blloku, grupi bllokesh duke përdorur një gjuhë programimi skenarësh. Ndryshimet në bazën e të dhënave të sinjaleve çojnë në ndryshimin e vlerave të pronësive të bllokut në skemë.
- Ruajtjen e përshkrimeve tekstuale, lidhjeve me pikat e TDR ose identifikuesve në sistemin e menaxhimit të kërkesave.
Strukturat e bazës së të dhënave të sinjaleve për kërkesat mund të konfigurohen lehtësisht për të punuar me një sistem të jashtëm të menaxhimit të kërkesave. Schema e përgjithshme e ndërveprimit me sistemet e menaxhimit të kërkesave paraqitet në figurën 11.
Figura 11. Schema e ndërveprimit me sistemin e menaxhimit të kërkesave.
Sekuenca e ndërveprimit të projektit provues SimInTech me sistemin e menaxhimit të kërkesave është si vijon:
- Dokumenti i kërkesës ndahet në kërkesa.
- Identifikohen kërkesat e dokumentit të kërkesës që mund të verifikohen nëpërmjet modelimit matematikor të proceseve teknike.
- Atributet e kërkesave të identifikuara transmetohen në bazën e të dhënave të sinjaleve SimInTech në struktura të blloqeve tipike (p.sh., temperatura maksimale dhe minimale).
- Në procesin e llogaritjes, të dhënat e strukturave dërgohen në skemat llogaritëse të blloqeve, bëhet analiza dhe rezultatet ruhet në bazën e të dhënave të sinjaleve.
- Pas përfundimit të llogaritjes, rezultatet e analizës transmetohen në sistemin e menaxhimit të kërkesave.
Fazat e punĂ«s me kĂ«rkesat 3 â 5 mund tĂ« pĂ«rsĂ«riten gjatĂ« procesit tĂ« projektimit, kur ndodhin ndryshime nĂ« ndĂ«rtim dhe (ose) kĂ«rkesa, dhe pĂ«r pasojĂ«, Ă«shtĂ« e nevojshme njĂ« verifikim i ri i ndikimit tĂ« ndryshimeve tĂ« bĂ«ra.
PĂ«rfundime.
- Prototipi i krijuar i sistemit siguron një reduktim të konsiderueshëm të kohës së analizës së modeleve ekzistuese për sa i përket përputhjes me kërkesat e dokumentit të kërkesës.
- Teknologjia e propozuar për testimin përdor modelet dinamike ekzistuese dhe mund të përdoret madje edhe për të gjitha modelet dinamike, përfshirë ato të kryera jo në ambientin SimInTech.
- Përdorimi i organizimit në grupe të të dhënave lejon krijimin e paketave për verifikimin e kërkesave, paralelisht me zhvillimin e modeleve, ose madje përdorimin e këtyre paketave si një kërkesë teknike për zhvillimin e modeleve.
- Teknologjia mund të integrohet pa shpenzime të konsiderueshme me sistemet ekzistuese të menaxhimit të kërkesave.
Për ata që e lexuan deri në fund,
Burimi: habr.com
