Teema jätkamine , vaatame matemaatilise modelleerimise probleemi teisest küljest. Kui oleme veendunud, et mudel vastab kodukootud elutõele, saame vastata põhiküsimusele: "mis meil siin täpsemalt on?" Tehnilise objekti mudeli loomisel tahame tavaliselt veenduda, et see objekt vastab meie ootustele. Selleks viiakse läbi protsesside dünaamilised arvutused ja võrreldakse tulemust nõuetega. See on digitaalne kaksik, virtuaalne prototüüp jne. moodsad väikesed poisid, kes lahendavad projekteerimisetapis probleemi, kuidas tagada, et saame selle, mida plaanisime.
Kuidas saame kiiresti veenduda, et meie süsteem on täpselt see, mida me kujundame, kas meie disain lendab või ujub? Ja kui see lendab, siis kui kõrgele? Ja kui see hõljub, siis kui sügavale?
Käesolevas artiklis käsitletakse tehnohoone nõuetele vastavuse kontrollimise automatiseerimist tehnosüsteemide dünaamiliste mudelite loomisel. Näitena vaatleme lennuki õhujahutussüsteemi tehnilise kirjelduse elementi.
Arvestame neid nõudeid, mida saab konkreetse arvutusmudeli alusel arvuliselt väljendada ja matemaatiliselt kontrollida. On selge, et see on vaid osa üldistest nõuetest mis tahes tehnilistele süsteemidele, kuid nende kontrollimisel kulutame aega, närve ja raha objekti dünaamiliste mudelite loomisele.
Dokumendi vormis tehniliste nõuete kirjeldamisel võib eristada mitut tüüpi erinevaid nõudeid, millest igaüks nõuab erinevat lähenemist nõuete täitmise automaatse kontrolli kujundamiseks.
Näiteks kaaluge seda väikest, kuid realistlikku nõuete kogumit:
- Atmosfääri õhutemperatuur veetöötlussüsteemi sissepääsu juures:
parklas - miinus 35 kuni 35 ºС,
lennu ajal - miinus 35 kuni 39 ºС. - Atmosfääriõhu staatiline rõhk lennu ajal on 700–1013 GPa (526–760 mm Hg).
- Õhu kogurõhk SVO õhuvõtuava sissepääsu juures lennu ajal on 754–1200 GPa (566–1050 mm Hg).
- Jahutusõhu temperatuur:
parklas - mitte üle 27 ºС, tehniliste plokkide puhul - mitte üle 29 ºС,
lennu ajal - mitte üle 25 ºС, tehniliste plokkide puhul - mitte üle 27 ºС. - Jahutusõhu vool:
pargituna - vähemalt 708 kg/h,
lennu ajal - mitte vähem kui 660 kg / h. - Õhutemperatuur instrumentide sektsioonides ei ületa 60 ºС.
- Peene vaba niiskuse kogus jahutusõhus ei ületa 2 g/kg kuiva õhu kohta.
Isegi selle piiratud nõuete hulgas on vähemalt kaks kategooriat, mida tuleb süsteemis erinevalt käsitleda.
- nõuded süsteemi töötingimustele (punktid 1-3);
- parameetrilised nõuded süsteemile (punktid 3-7).
Süsteemi töötingimuste nõuded
Modelleerimise käigus arendatava süsteemi välistingimusi saab määrata piirtingimustena või üldsüsteemi toimimise tulemusena.
Dünaamilise simulatsiooni puhul on vaja tagada, et simulatsiooniprotsess hõlmaks kindlaksmääratud töötingimusi.
Parameetrilised süsteeminõuded
Need nõuded on süsteemi enda pakutavad parameetrid. Modelleerimise käigus saame need parameetrid arvutustulemustena ja veenduda, et igas konkreetses arvutuses on täidetud nõuded.
Nõuded identifitseerimine ja kodeerimine
Nõuetega töötamise hõlbustamiseks soovitavad olemasolevad standardid määrata igale nõudele identifikaatori. Identifikaatorite määramisel on väga soovitav kasutada ühtset kodeerimissüsteemi.
Nõude kood võib olla lihtsalt number, mis tähistab nõude järjekorranumbrit, või see võib sisaldada nõude tüübi koodi, süsteemi või üksuse koodi, millele see kehtib, parameetri koodi, asukohakoodi ja kõike muud, mida insener ette kujutab. (kodeeringu kasutamise kohta vaadake artiklit)
Tabelis 1 on lihtne näide nõuete kodeerimisest.
- nõuete allika kood R-nõuded TK;
- nõuete kooditüüp E - nõuded - keskkonnaparameetrid ehk töötingimused
S - süsteemi poolt pakutavad nõuded; - õhusõiduki olekukood 0 – suvaline, G – pargitud, F – lennu ajal;
- füüsikalise parameetri tüübi kood T – temperatuur, P – rõhk, G – vooluhulk, niiskus H;
- nõude seerianumber.
| ID Nõuded |
Kirjeldus | Parameeter |
| REGT01 | Välisõhu temperatuur vesijahutussüsteemi sissepääsu juures: parklas - alates miinus 35ºС. kuni 35 ºС. | |
| REFT01 | Atmosfääri õhutemperatuur õhutõrjesüsteemi sissepääsu juures: lennu ajal - miinus 35 ºС kuni 39 ºС. | |
| REFP01 | Staatiline atmosfääriõhu rõhk lennu ajal on 700–1013 hPa (526–760 mm Hg). | |
| REFP02 | Kogu õhurõhk SVO õhuvõtuava sissepääsu juures lennu ajal on 754–1200 hPa (566–1050 mm Hg). | |
| RSGT01 | Jahutusõhu temperatuur: pargituna mitte üle 27 ºС | |
| RSGT02 | Jahutusõhu temperatuur: parklas, tehnosõlmedel mitte üle 29 ºС | |
| RSFT01 | Jahutusõhu temperatuur lennu ajal mitte üle 25 ºС | |
| RSFT02 | Jahutusõhu temperatuur: lennu ajal, tehnilistel üksustel mitte üle 27 ºС | |
| RSGG01 | Jahutusõhu vool: seistes vähemalt 708 kg/h | |
| RSFG01 | Jahutusõhu vool: lennu ajal mitte vähem kui 660 kg/h | |
| RS0T01 | Õhutemperatuur instrumentide sektsioonides mitte üle 60 ºС | |
| RSH01 | Peene vaba niiskuse kogus jahutusõhus ei ületa 2 g/kg kuiva õhu kohta |
Nõuete kontrollisüsteemi projekteerimine.
Iga projekteerimisnõude jaoks on olemas algoritm projekteerimisparameetrite ja nõudes määratud parameetrite vastavuse hindamiseks. Üldiselt sisaldab iga juhtimissüsteem alati vaikimisi nõuete kontrollimise algoritme. Ja isegi iga regulaator sisaldab neid. Kui temperatuur väljub piiridest, lülitub konditsioneer sisse. Seega on iga regulatsiooni esimene etapp kontrollida, kas parameetrid vastavad nõuetele.
Ja kuna kontrollimine on algoritm, siis saame kasutada samu tööriistu ja tööriistu, mida kasutame juhtimisprogrammide loomisel. Näiteks SimInTechi keskkond võimaldab luua mudeli erinevaid osi sisaldavaid projektipakette, mis täidetakse eraldi projektidena (objektimudel, juhtimissüsteemi mudel, keskkonnamudel jne).
Nõuete kontrollimise projekt muutub sel juhul samaks algoritmiprojektiks ja ühendatakse mudelipaketiga. Ja dünaamilises modelleerimisrežiimis teostab see tehniliste kirjelduste nõuetele vastavuse analüüsi.
Süsteemi disaini võimalik näide on näidatud joonisel 1.
Joonis 1. Taatlusprojekti kujunduse näide.
Nii nagu juhtimisalgoritmidele, saab nõuded koostada lehtede komplektina. Struktuurimudelite keskkondades nagu SimInTech, Simulink, AmeSim algoritmidega töötamise mugavuse huvides kasutatakse võimalust luua alammudelite kujul mitmetasandilisi struktuure. See korraldus võimaldab rühmitada erinevaid nõudeid komplektidesse, et lihtsustada tööd paljude nõuetega, nagu seda tehakse juhtimisalgoritmide puhul (vt joonis 2).
Joonis 2. Nõuete kontrollimise mudeli hierarhiline struktuur.
Näiteks vaadeldaval juhul eristatakse kahte rühma: nõuded keskkonnale ja nõuded otseselt süsteemile. Seetõttu kasutatakse kahetasandilist andmestruktuuri: kaks rühma, millest igaüks on algoritmi leht.
Andmete ühendamiseks mudeliga kasutatakse signaalide andmebaasi genereerimise standardskeemi, mis salvestab andmed projekti osade vaheliseks vahetamiseks.
Tarkvara loomisel ja testimisel paigutatakse sellesse andmebaasi juhtimissüsteemis kasutatavate andurite (reaalsüsteemi andurite analoogid) näidud.
Testprojekti puhul saab kõik dünaamilises mudelis arvutatud parameetrid salvestada samasse andmebaasi ja seega kontrollida, kas nõuded on täidetud.
Sel juhul saab dünaamilist mudelit ise täita mis tahes matemaatilises modelleerimissüsteemis või isegi käivitatava programmi kujul. Ainus nõue on tarkvaraliideste olemasolu modelleerimisandmete väljastamiseks väliskeskkonda.
Joonis 3. Kontrolliprojekti ühendamine kompleksmudeliga.
Põhinõuete kontrollimise lehe näide on toodud joonisel 4. Arendaja seisukohast on tegemist tavapärase arvutusdiagrammiga, millel on graafiliselt esitatud nõuete kontrollimise algoritm.
Joonis 4. Nõuete kontrollleht.
Kontrolllehe põhiosad on kirjeldatud joonisel 5. Kontrollialgoritm on moodustatud sarnaselt juhtimisalgoritmide projekteerimisskeemidele. Paremal pool on blokk signaalide lugemiseks andmebaasist. See plokk pääseb simulatsiooni ajal ligi signaalide andmebaasile.
Vastuvõetud signaale analüüsitakse nõuete kontrollimise tingimuste arvutamiseks. Sel juhul tehakse kõrguse analüüs, et määrata lennuki asukoht (kas see on pargitud või lennul). Sel eesmärgil saate kasutada muid signaale ja mudeli arvutatud parameetreid.
Kontrollitavad taatlustingimused ja parameetrid kantakse üle standardsetesse taatlusplokkidesse, milles analüüsitakse nende parameetrite vastavust etteantud nõuetele. Tulemused salvestatakse signaalide andmebaasi nii, et neid saab kasutada automaatselt kontrollnimekirja koostamiseks.
Joonis 5. Nõuete tõendamise arvutuslehe struktuur.
Testitavad parameetrid ei pruugi kasutada andmebaasis sisalduvaid signaale, mida juhitakse simulatsiooniprotsessi käigus arvutatud parameetritega. Miski ei takista meil nõuete eelnõu raames täiendavaid arvutusi tegemast, nii nagu me arvutame välja taatlustingimused.
Näiteks see nõue:
Parandussüsteemi aktiveerimiste arv sihtmärgini lennu ajal ei tohiks ületada 5 ja parandussüsteemi kogu tööaeg ei tohiks ületada 30 sekundit.
Sel juhul lisatakse nõuete projekteerimisskeemile käivitamiste arvu ja kogu tööaja arvestamise algoritm.
Tüüpiliste nõuete kontrollimise plokk.
Iga standardnõude märkeruut on mõeldud teatud tüüpi nõude täitmise arvutamiseks. Näiteks hõlmavad keskkonnanõuded mitmesuguseid ümbritseva õhu töötemperatuure pargimisel ja lennu ajal. See plokk peab parameetrina vastu võtma mudeli õhutemperatuuri ja määrama, kas see parameeter katab määratud temperatuurivahemiku./p>
Plokis on kaks sisendporti, param ja tingimus.
Esimene söödetakse kontrollitava parameetriga. Sel juhul "Välistemperatuur".
Teisele pordile antakse Boole'i muutuja - see on kontrollimise tingimus.
Kui teises sisendis saadakse TÕENE (1), teostab plokk nõuete kontrollimise arvutuse.
Kui teine sisend saab VÄÄR (0), ei ole testitingimused täidetud. See on vajalik arvutustingimuste arvestamiseks. Meie puhul kasutatakse seda sisendit kontrolli lubamiseks või keelamiseks sõltuvalt mudeli olekust. Kui lennuk on simulatsiooni ajal maas, siis lennuga seotud nõudeid ei kontrollita ja vastupidi - kui lennuk on lennus, siis seismisel lendamisega seotud nõudeid ei kontrollita.
Seda sisendit saab kasutada ka mudeli seadistamisel, näiteks arvutamise algfaasis. Kui mudel viiakse nõutavasse olekusse, blokeeritakse kontrollplokid, kuid niipea, kui süsteem jõuab nõutavasse töörežiimi, lülitatakse kontrollplokid sisse.
Selle ploki parameetrid on järgmised:
- piirtingimused: ülemised (UpLimit) ja alumised (DownLimit) vahemiku piirid, mida tuleb kontrollida;
- nõutav süsteemi kokkupuuteaeg piirvahemikes (TimeInterval) sekundites;
- Päringu ID ReqName;
- vahemiku ületamise lubatavus Out_range on Boole'i muutuja, mis määrab, kas kontrollitud vahemikku ületav väärtus on nõude rikkumine.
Mõnel juhul näitab testväärtuse väljund, et süsteemil on teatud varu ja see võib töötada väljaspool oma töövahemikku. Muudel juhtudel tähendab väljund seda, et süsteem ei suuda seadeväärtusi vahemikus hoida.
Joonis 6. Tüüpiline omaduste kontrollimise plokk skeemil ja selle parameetrid.
Selle ploki arvutamise tulemusena moodustatakse väljundis muutuja Tulemus, mis võtab järgmised väärtused:
- 0 – rPuudub, väärtus pole määratletud;
- 1 – rValmis, nõue on täidetud;
- 2 – rRike, nõue ei ole täidetud.
Ploki pilt sisaldab:
- tunnustekst;
- mõõtepiiride parameetrite digitaalsed kuvarid;
- parameetri oleku värviidentifikaator.
Ploki sees võib olla üsna keeruline loogilise järelduse ahel.
Näiteks joonisel 6 näidatud seadme töötemperatuuri vahemiku kontrollimiseks on sisemine vooluahel näidatud joonisel 7.
Joonis 7. Temperatuurivahemiku määramisühiku siseskeem.
Skeemiploki sees kasutatakse ploki parameetrites määratud omadusi.
Ploki siseskeem sisaldab lisaks nõuetele vastavuse analüüsile simulatsioonitulemuste kuvamiseks vajalikku graafikut. Seda graafikut saab kasutada nii arvutamise ajal vaatamiseks kui ka tulemuste analüüsimiseks pärast arvutamist.
Arvutustulemused edastatakse ploki väljundisse ja salvestatakse samaaegselt üldaruande faili, mis koostatakse kogu projekti tulemuste põhjal. (vt joonis 8)
Simulatsiooni tulemuste põhjal koostatud aruande näiteks on etteantud formaadi järgi loodud html-fail. Vormingu saab suvaliselt konfigureerida vormingule, mille konkreetne organisatsioon on aktsepteerinud.
Skeemiploki sees kasutatakse ploki parameetrites määratud omadusi.
Ploki siseskeem sisaldab lisaks nõuetele vastavuse analüüsile simulatsioonitulemuste kuvamiseks vajalikku graafikut. Seda graafikut saab kasutada nii arvutamise ajal vaatamiseks kui ka tulemuste analüüsimiseks pärast arvutamist.
Arvutustulemused edastatakse ploki väljundisse ja salvestatakse samaaegselt üldaruande faili, mis koostatakse kogu projekti tulemuste põhjal. (vt joonis 8)
Simulatsiooni tulemuste põhjal koostatud aruande näiteks on etteantud formaadi järgi loodud html-fail. Vormingu saab suvaliselt konfigureerida vormingule, mille konkreetne organisatsioon on aktsepteerinud.
Joonis 8. Simulatsioonitulemustel põhineva aruandefaili näide.
Selles näites on aruande vorm konfigureeritud otse projekti atribuutides ja tabelis olev vorming on seatud globaalsete projektisignaalidena. Sel juhul lahendab SimInTech ise aruande seadistamise probleemi ja tulemuste faili kirjutamise plokk kasutab neid ridu aruandefaili kirjutamiseks.
Joonis 9. Aruande vormingu seadistamine globaalsetes projektisignaalides
Signaalide andmebaasi kasutamine nõuete jaoks.
Atribuutide seadistustega töö automatiseerimiseks luuakse signaalide andmebaasis iga tüüpilise ploki jaoks standardstruktuur. (vt joonis 10)
Joonis 10. Näide nõuete kontrollploki struktuurist signaalide andmebaasis.
Signaalide andmebaas pakub:
- Kõigi vajalike süsteeminõuete parameetrite salvestamine.
- Mugav olemasolevate projektinõuete vaatamine määratud parameetrite ja praeguste modelleerimistulemuste põhjal.
- Ühe ploki või plokkide rühma seadistamine skriptimise programmeerimiskeele abil. Muudatused signaali andmebaasis toovad kaasa muutused diagrammi ploki omaduste väärtustes.
- Tekstikirjelduste, tehniliste kirjelduste üksuste linkide või identifikaatorite salvestamine nõuete haldussüsteemis.
Nõuete jaoks mõeldud signaaliandmebaasi struktuure saab hõlpsasti seadistada töötama koos kolmanda osapoole nõuetehaldussüsteemiga Nõuetehaldussüsteemidega suhtlemise üldskeem on toodud joonisel 11.
Joonis 11. Nõuetehaldussüsteemiga koostoime skeem.
SimInTechi testprojekti ja nõuete juhtimissüsteemi vaheline interaktsiooni järjekord on järgmine:
- Lähteülesanne on jaotatud nõueteks.
- Määratakse kindlaks tehniliste kirjelduste nõuded, mida saab kontrollida tehniliste protsesside matemaatilise modelleerimisega.
- Valitud nõuete atribuudid kantakse SimInTechi signaalide andmebaasi standardplokkide struktuuris (näiteks maksimaalne ja minimaalne temperatuur).
- Arvutusprotsessi käigus kantakse struktuuriandmed plokkprojekteerimisskeemidele, teostatakse analüüs ning tulemused salvestatakse signaalide andmebaasi.
- Kui arvutus on lõppenud, kantakse analüüsi tulemused nõuete haldussüsteemi.
Nõuete etappe 3 kuni 5 võib projekteerimisprotsessi ajal korrata, kui projektis ja/või nõuetes tehakse muudatusi ja muudatuste mõju on vaja uuesti testida.
Järeldused.
- Süsteemi loodud prototüüp võimaldab oluliselt vähendada olemasolevate mudelite analüüsiaega tehniliste kirjelduste nõuetele vastavuse tagamiseks.
- Kavandatav testimistehnoloogia kasutab juba olemasolevaid dünaamilisi mudeleid ja seda saab kasutada isegi mis tahes dünaamiliste mudelite jaoks, sealhulgas nende puhul, mida SimInTechi keskkonnas ei tehta.
- Pakettandmete korraldamise kasutamine võimaldab paralleelselt mudeli väljatöötamisega luua nõuete kontrollimise pakette või isegi kasutada neid pakette mudeliarenduse tehniliste spetsifikatsioonidena.
- Tehnoloogiat saab ilma oluliste kuludeta integreerida olemasolevate nõuete haldussüsteemidega.
Neile, kes loevad lõpuni,
Allikas: www.habr.com