Vazhdimi i temës , le të shohim problemin e modelimit matematik nga ana tjetër. Pasi të jemi të bindur se modeli korrespondon me të vërtetën e krijuar nga shtëpia e jetës, mund t'i përgjigjemi pyetjes kryesore: "çfarë, saktësisht, kemi këtu?" Kur krijojmë një model të një objekti teknik, ne zakonisht duam të sigurohemi që ky objekt të përmbushë pritjet tona. Për këtë qëllim, kryhen llogaritjet dinamike të proceseve dhe rezultati krahasohet me kërkesat. Ky është një binjak dixhital, një prototip virtual, etj. djem të vegjël në modë, të cilët, në fazën e projektimit, zgjidhin problemin se si të sigurohemi që të marrim atë që kemi planifikuar.
Si mund të sigurohemi shpejt që sistemi ynë është pikërisht ai që ne projektojmë, a do të fluturojë dizajni ynë apo do të notojë? Dhe nëse fluturon, sa lart? Dhe nëse noton, sa thellë?
Ky artikull diskuton automatizimin e verifikimit të përputhshmërisë me kërkesat e një ndërtese teknike kur krijoni modele dinamike të sistemeve teknike. Si shembull, le të shohim një element të specifikimit teknik për një sistem ftohjeje ajri avioni.
Ne konsiderojmë ato kërkesa që mund të shprehen numerikisht dhe të verifikohen matematikisht bazuar në një model specifik llogaritjeje. Është e qartë se kjo është vetëm një pjesë e kërkesave të përgjithshme për çdo sistem teknik, por është për kontrollin e tyre që ne shpenzojmë kohë, nerva dhe para për të krijuar modele dinamike të objektit.
Kur përshkruhen kërkesat teknike në formën e një dokumenti, mund të dallohen disa lloje kërkesash të ndryshme, secila prej të cilave kërkon qasje të ndryshme për formimin e verifikimit automatik të përmbushjes së kërkesave.
Për shembull, merrni parasysh këtë grup të vogël, por realist kërkesash:
- Temperatura e ajrit atmosferik në hyrje të sistemit të trajtimit të ujit:
në parking - nga minus 35 në 35 ºС,
në fluturim - nga minus 35 në 39 ºС. - Presioni statik i ajrit atmosferik gjatë fluturimit është nga 700 në 1013 GPa (nga 526 në 760 mm Hg).
- Presioni total i ajrit në hyrje të marrjes së ajrit SVO gjatë fluturimit është nga 754 në 1200 GPa (nga 566 në 1050 mm Hg).
- Temperatura e ajrit të ftohjes:
në parking - jo më shumë se 27 ºС, për blloqe teknike - jo më shumë se 29 ºС,
në fluturim - jo më shumë se 25 ºС, për blloqet teknike - jo më shumë se 27 ºС. - Rrjedha e ajrit ftohës:
kur parkohet - të paktën 708 kg / orë,
në fluturim - jo më pak se 660 kg / orë. - Temperatura e ajrit në ndarjet e instrumenteve nuk është më shumë se 60 ºС.
- Sasia e lagështisë së imët të lirë në ajrin ftohës nuk është më shumë se 2 g/kg ajër të thatë.
Edhe brenda këtij grupi të kufizuar kërkesash, ekzistojnë të paktën dy kategori që duhet të trajtohen ndryshe në sistem:
- kërkesat për kushtet e funksionimit të sistemit (klauzolat 1-3);
- kërkesat parametrike për sistemin (klauzolat 3-7).
Kërkesat për kushtet e funksionimit të sistemit
Kushtet e jashtme për sistemin që zhvillohet gjatë modelimit mund të specifikohen si kushte kufitare ose si rezultat i funksionimit të sistemit të përgjithshëm.
Në simulimin dinamik, është e nevojshme të sigurohet që kushtet e specifikuara të funksionimit të mbulohen nga procesi i simulimit.
Kërkesat parametrike të sistemit
Këto kërkesa janë parametra të ofruara nga vetë sistemi. Gjatë procesit të modelimit, ne mund t'i marrim këto parametra si rezultate të llogaritjes dhe të sigurohemi që kërkesat janë përmbushur në secilën llogaritje specifike.
Identifikimi dhe kodimi i kërkesave
Për lehtësinë e punës me kërkesat, standardet ekzistuese rekomandojnë caktimin e një identifikuesi për secilën kërkesë. Gjatë caktimit të identifikuesve, është shumë e dëshirueshme të përdoret një sistem kodimi i unifikuar.
Kodi i kërkesës mund të jetë thjesht një numër që përfaqëson numrin e rendit të kërkesës, ose mund të përmbajë një kod për llojin e kërkesës, një kod për sistemin ose njësinë në të cilën zbatohet, një kod parametri, një kod vendndodhjeje, dhe çdo gjë tjetër që inxhinieri mund të imagjinojë. (shih artikullin për përdorimin e kodimit)
Tabela 1 jep një shembull të thjeshtë të kodimit të kërkesave.
- kodi i burimit të kërkesave R-kërkesat TK;
- lloji i kodit të kërkesave E - kërkesat - parametrat mjedisorë, ose kushtet e funksionimit
S - kërkesat e ofruara nga sistemi; - kodi i statusit të avionit 0 – çdo, G – i parkuar, F – në fluturim;
- Kodi i tipit të parametrit fizik T – temperatura, P – presioni, G – shpejtësia e rrjedhjes, lagështia H;
- numri serial i kërkesës.
| ID Kërkesat |
Përshkrim | Parametër |
| REGT01 | Temperatura e ajrit të ambientit në hyrje të sistemit të ftohjes së ujit: në parking - nga minus 35ºС. deri në 35 ºС. | |
| REFT01 | Temperatura e ajrit atmosferik në hyrje të sistemit të mbrojtjes ajrore: në fluturim - nga minus 35 ºС në 39 ºС. | |
| REFP01 | Presioni statik i ajrit atmosferik gjatë fluturimit është nga 700 në 1013 hPa (nga 526 në 760 mm Hg). | |
| REFP02 | Presioni total i ajrit në hyrje të marrjes së ajrit SVO gjatë fluturimit është nga 754 në 1200 hPa (nga 566 në 1050 mm Hg). | |
| RSGT01 | Temperatura e ajrit të ftohjes: kur parkohet jo më shumë se 27 ºС | |
| RSGT02 | Temperatura e ajrit të ftohjes: në parking, për njësitë teknike jo më shumë se 29 ºС | |
| RSFT01 | Temperatura e ajrit të ftohjes në fluturim jo më shumë se 25 ºС | |
| RSFT02 | Temperatura e ajrit të ftohjes: në fluturim, për njësitë teknike jo më shumë se 27 ºС | |
| RSGG01 | Rrjedha e ajrit ftohës: kur është e parkuar jo më pak se 708 kg/h | |
| RSFG01 | Rrjedha e ajrit ftohës: në fluturim jo më pak se 660 kg/h | |
| RS0T01 | Temperatura e ajrit në ndarjet e instrumenteve jo më shumë se 60 ºС | |
| RSH01 | Sasia e lagështisë së imët të lirë në ajrin ftohës nuk është më shumë se 2 g/kg ajër të thatë |
Dizajni i sistemit të verifikimit të kërkesave.
Për çdo kërkesë të projektimit ekziston një algoritëm për vlerësimin e korrespondencës së parametrave të projektimit dhe parametrave të specifikuar në kërkesë. Në përgjithësi, çdo sistem kontrolli përmban gjithmonë algoritme për kontrollimin e kërkesave thjesht si parazgjedhje. Dhe madje çdo rregullator i përmban ato. Nëse temperatura shkon jashtë kufijve, kondicioneri ndizet. Kështu, faza e parë e çdo rregullimi është të kontrollojë nëse parametrat i plotësojnë kërkesat.
Dhe meqenëse verifikimi është një algoritëm, atëherë ne mund të përdorim të njëjtat mjete dhe mjete që përdorim për të krijuar programe kontrolli. Për shembull, mjedisi SimInTech ju lejon të krijoni paketa projektesh që përmbajnë pjesë të ndryshme të modelit, të ekzekutuara në formën e projekteve të veçanta (modeli i objektit, modeli i sistemit të kontrollit, modeli i mjedisit, etj.).
Projekti i verifikimit të kërkesave në këtë rast bëhet i njëjti projekt algoritmi dhe lidhet me paketën e modelit. Dhe në modalitetin e modelimit dinamik kryen një analizë për përputhjen me kërkesat e specifikimeve teknike.
Një shembull i mundshëm i dizajnit të sistemit është paraqitur në Figurën 1.
Figura 1. Shembull i projektimit të një projekti verifikimi.
Ashtu si për algoritmet e kontrollit, kërkesat mund të hartohen si një grup fletësh. Për lehtësinë e punës me algoritme në mjediset e modelimit strukturor si SimInTech, Simulink, AmeSim, përdoret aftësia për të krijuar struktura me shumë nivele në formën e nënmodeleve. Ky organizim bën të mundur grupimin e kërkesave të ndryshme në grupe për të thjeshtuar punën me një sërë kërkesash, siç bëhet për algoritmet e kontrollit (shih Fig. 2).
Figura 2. Struktura hierarkike e modelit të verifikimit të kërkesave.
Për shembull, në rastin në shqyrtim, dallohen dy grupe: kërkesat për mjedisin dhe kërkesat drejtpërdrejt për sistemin. Prandaj, përdoret një strukturë e të dhënave me dy nivele: dy grupe, secila prej të cilave është një fletë e algoritmit.
Për të lidhur të dhënat me modelin, përdoret një skemë standarde për gjenerimin e një baze të dhënash sinjali, e cila ruan të dhënat për shkëmbim midis pjesëve të projektit.
Gjatë krijimit dhe testimit të softuerit, leximet e sensorëve (analogë të sensorëve të sistemit real) që përdoren nga sistemi i kontrollit vendosen në këtë bazë të dhënash.
Për një projekt testimi, çdo parametër i llogaritur në modelin dinamik mund të ruhet në të njëjtën bazë të dhënash dhe kështu të përdoret për të kontrolluar nëse kërkesat janë përmbushur.
Në këtë rast, vetë modeli dinamik mund të ekzekutohet në çdo sistem modelimi matematikor ose edhe në formën e një programi të ekzekutueshëm. Kërkesa e vetme është prania e ndërfaqeve softuerike për lëshimin e të dhënave të modelimit në mjedisin e jashtëm.
Figura 3. Lidhja e projektit të verifikimit me modelin kompleks.
Një shembull i një fletë verifikimi të kërkesave bazë është paraqitur në figurën 4. Nga këndvështrimi i zhvilluesit, është një diagram konvencional llogaritës në të cilin paraqitet grafikisht algoritmi i verifikimit të kërkesave.
Figura 4. Fleta e kontrollit të kërkesave.
Pjesët kryesore të fletës së kontrollit janë përshkruar në figurën 5. Algoritmi i kontrollit është formuar në mënyrë të ngjashme me diagramet e projektimit të algoritmeve të kontrollit. Në anën e djathtë ka një bllok për leximin e sinjaleve nga baza e të dhënave. Ky bllok akseson bazën e të dhënave të sinjalit gjatë simulimit.
Sinjalet e marra analizohen 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 pozicionin e avionit (nëse është i parkuar apo në fluturim). Për këtë qëllim, mund të përdorni sinjale të tjera dhe parametra të llogaritur të modelit.
Kushtet e verifikimit dhe parametrat që kontrollohen transferohen në blloqet standarde të verifikimit, në të cilat këto parametra analizohen për pajtueshmërinë me kërkesat e specifikuara. Rezultatet regjistrohen në bazën e të dhënave të sinjaleve në mënyrë të tillë që të mund të përdoren për të gjeneruar automatikisht një listë kontrolli.
Figura 5. Struktura e fletës së llogaritjes së verifikimit të kërkesave.
Nuk është e nevojshme të përdoren sinjalet që gjenden në bazën e të dhënave si parametra të testuar, të cilët kontrollohen nga parametrat e llogaritur gjatë procesit të simulimit. Asgjë nuk na pengon të bëjmë përllogaritje shtesë në kuadër të draft kërkesave, ashtu siç llogarisim kushtet e verifikimit.
Për shembull, kjo kërkesë:
Numri i aktivizimeve të sistemit të korrigjimit gjatë fluturimit në objektiv nuk duhet të kalojë 5, dhe koha totale e funksionimit të sistemit të korrigjimit nuk duhet të kalojë 30 sekonda.
Në këtë rast, një algoritëm për përballimin e numrit të fillimeve dhe kohës totale të funksionimit i shtohet diagramit të projektimit të kërkesave.
Blloku i verifikimit të kërkesave tipike.
Kutia e kontrollit për çdo kërkesë standarde është projektuar për të llogaritur përmbushjen e një kërkese të një lloji të caktuar. Për shembull, kërkesat mjedisore përfshijnë një sërë temperaturash të funksionimit të ambientit kur parkohen dhe gjatë fluturimit. Ky bllok duhet të marrë temperaturën e ajrit në model si parametër dhe të përcaktojë nëse ky parametër mbulon intervalin e specifikuar të temperaturës./p>
Blloku përmban dy porte hyrëse, parametrin dhe gjendjen.
E para ushqehet me parametrin që kontrollohet. Në këtë rast, "Temperatura e jashtme".
Një variabël Boolean i jepet portit të dytë - kushti për kryerjen e kontrollit.
Nëse TRUE (1) merret në hyrjen e dytë, atëherë blloku kryen një llogaritje të verifikimit të kërkesave.
Nëse hyrja e dytë merr FALSE (0), atëherë kushtet e testimit nuk plotësohen. Kjo është e nevojshme në mënyrë që kushtet e llogaritjes të mund të merren parasysh. Në rastin tonë, kjo hyrje përdoret për të aktivizuar ose çaktivizuar kontrollin në varësi të gjendjes së modelit. Nëse avioni është në tokë gjatë simulimit, atëherë kërkesat që lidhen me fluturimin nuk kontrollohen, dhe anasjelltas - nëse avioni është në fluturim, atëherë kërkesat që lidhen me funksionimin në qëndrim nuk kontrollohen.
Kjo hyrje mund të përdoret gjithashtu gjatë konfigurimit të modelit, për shembull në fazën fillestare të llogaritjes. Kur modeli sillet në gjendjen e kërkuar, blloqet e kontrollit çaktivizohen, por sapo sistemi arrin modalitetin e kërkuar të funksionimit, blloqet e kontrollit ndizen.
Parametrat e këtij blloku janë:
- kushtet kufitare: kufijtë e gamës së sipërme (UpLimit) dhe të poshtëm (DownLimit) që duhet të kontrollohen;
- koha e kërkuar e ekspozimit të sistemit në intervalet kufitare (TimeInterval) në sekonda;
- ID-ja e kërkesës Emri i kërkesës;
- lejueshmëria e tejkalimit të diapazonit Out_range është një variabël Boolean që përcakton nëse një vlerë që tejkalon intervalin e kontrolluar është një shkelje e kërkesës.
Në disa raste, dalja e vlerës së testimit tregon se sistemi ka njëfarë diferencë dhe mund të funksionojë jashtë diapazonit të tij të funksionimit. Në raste të tjera, një dalje do të thotë që sistemi nuk është në gjendje të mbajë pikat e vendosura brenda intervalit.
Figura 6. Një bllok tipik i kontrollit të vetive në diagram dhe parametrat e tij.
Si rezultat i llogaritjes së këtij blloku, në dalje formohet ndryshorja Result, e cila merr vlerat e mëposhtme:
- 0 – rAsnjë, vlera nuk është përcaktuar;
- 1 – rBërë, kërkesa plotësohet;
- 2 – rFault, kërkesa nuk plotësohet.
Imazhi i bllokut përmban:
- teksti identifikues;
- ekranet dixhitale të parametrave të kufijve të matjes;
- identifikuesi i ngjyrës së statusit të parametrit.
Brenda bllokut mund të ketë një qark mjaft kompleks konkluzionesh logjike.
Për shembull, për të kontrolluar diapazonin e temperaturës së funksionimit të njësisë së paraqitur në figurën 6, qarku i brendshëm tregohet në figurën 7.
Figura 7. Diagrami i brendshëm i njësisë së përcaktimit të intervalit të temperaturës.
Brenda bllokut të qarkut, përdoren vetitë e specifikuara në parametrat e bllokut.
Përveç analizimit të përputhshmërisë me kërkesat, diagrami i brendshëm i bllokut përmban një grafik të nevojshëm për shfaqjen e rezultateve të simulimit. Ky grafik mund të përdoret si për shikimin gjatë llogaritjes ashtu edhe për analizimin e rezultateve pas llogaritjes.
Rezultatet e llogaritjes transmetohen në daljen e bllokut dhe regjistrohen njëkohësisht në një skedar raporti të përgjithshëm, i cili krijohet në bazë të rezultateve për të gjithë projektin. (shih Fig. 8)
Një shembull i një raporti të krijuar bazuar në rezultatet e simulimit është një skedar html i krijuar sipas një formati të caktuar. Formati mund të konfigurohet në mënyrë arbitrare në formatin e pranuar nga një organizatë e caktuar.
Brenda bllokut të qarkut, përdoren vetitë e specifikuara në parametrat e bllokut.
Përveç analizimit të përputhshmërisë me kërkesat, diagrami i brendshëm i bllokut përmban një grafik të nevojshëm për shfaqjen e rezultateve të simulimit. Ky grafik mund të përdoret si për shikimin gjatë llogaritjes ashtu edhe për analizimin e rezultateve pas llogaritjes.
Rezultatet e llogaritjes transmetohen në daljen e bllokut dhe regjistrohen njëkohësisht në një skedar raporti të përgjithshëm, i cili krijohet në bazë të rezultateve për të gjithë projektin. (shih Fig. 8)
Një shembull i një raporti të krijuar bazuar në rezultatet e simulimit është një skedar html i krijuar sipas një formati të caktuar. Formati mund të konfigurohet në mënyrë arbitrare në formatin e pranuar nga një organizatë e caktuar.
Figura 8. Shembull i një skedari raporti bazuar në rezultatet e simulimit.
Në këtë shembull, forma e raportit konfigurohet drejtpërdrejt në vetitë e projektit dhe formati në tabelë vendoset si sinjale globale të projektit. Në këtë rast, vetë SimInTech zgjidh problemin e konfigurimit të raportit, dhe blloku për shkrimin e rezultateve në një skedar përdor këto rreshta për të shkruar në skedarin e raportit.
Figura 9. Vendosja e formatit të raportit në sinjalet globale të projektit
Përdorimi i një baze të dhënash sinjalesh për kërkesat.
Për të automatizuar punën me cilësimet e vetive, krijohet një strukturë standarde në bazën e të dhënave të sinjalit për çdo bllok tipik. (shih Fig. 10)
Figura 10. Shembull i strukturës së një blloku të kontrollit të kërkesave në një bazë të dhënash sinjalesh.
Baza e të dhënave të sinjalit ofron:
- Ruajtja e të gjithë parametrave të nevojshëm të kërkesave të sistemit.
- Shikim i përshtatshëm i kërkesave ekzistuese të projektit nga parametrat e specifikuar dhe rezultatet aktuale të modelimit.
- Vendosja e një blloku ose një grupi blloqesh duke përdorur një gjuhë programimi skriptimi. Ndryshimet në bazën e të dhënave të sinjalit çojnë në ndryshime në vlerat e vetive të bllokut në diagram.
- Ruajtja e përshkrimeve të tekstit, lidhjeve me artikujt e specifikimeve teknike ose identifikuesit në sistemin e menaxhimit të kërkesave.
Strukturat e bazës së të dhënave të sinjalit për kërkesat mund të konfigurohen lehtësisht për të punuar me një sistem të menaxhimit të kërkesave të palëve të treta Një diagram i përgjithshëm i ndërveprimit me sistemet e menaxhimit të kërkesave është paraqitur në figurën 11.
Figura 11. Diagrami i ndërveprimit me sistemin e menaxhimit të kërkesave.
Sekuenca e ndërveprimit midis projektit të testit SimInTech dhe sistemit të kontrollit të kërkesave është si më poshtë:
- Termat e referencës ndahen në kërkesa.
- Identifikohen kërkesat e specifikimeve teknike që mund të verifikohen me modelim matematikor të proceseve teknike.
- Atributet e kërkesave të zgjedhura transferohen në bazën e të dhënave të sinjalit SimInTech në strukturën e blloqeve standarde (për shembull, temperatura maksimale dhe minimale).
- Gjatë procesit të llogaritjes, të dhënat e strukturës transferohen në diagramet e projektimit të bllokut, kryhet analiza dhe rezultatet ruhen në një bazë të dhënash sinjalesh.
- Pasi të përfundojë llogaritja, rezultatet e analizës transferohen në sistemin e menaxhimit të kërkesave.
Kërkesat hapat 3 deri në 5 mund të përsëriten gjatë procesit të projektimit kur ndodhin ndryshime në dizajn dhe/ose kërkesa dhe ndikimi i ndryshimeve duhet të ritestohet.
Përfundime.
- Prototipi i krijuar i sistemit siguron një reduktim të ndjeshëm në kohën e analizës së modeleve ekzistuese për përputhjen me kërkesat e specifikimeve teknike.
- Teknologjia e propozuar e testimit përdor modele dinamike tashmë ekzistuese dhe mund të përdoret edhe për çdo model dinamik, përfshirë ato që nuk kryhen në mjedisin SimInTech.
- Përdorimi i organizimit të të dhënave të grupit ju lejon të krijoni paketa të verifikimit të kërkesave paralelisht me zhvillimin e modelit, ose edhe t'i përdorni këto paketa si specifikime teknike për zhvillimin e modelit.
- Teknologjia mund të integrohet me sistemet ekzistuese të menaxhimit të kërkesave pa kosto të konsiderueshme.
Për ata që lexojnë deri në fund,
Burimi: www.habr.com