Automaatne TSh nõuete kontroll dünaamilise modelleerimise protsessis.

Jätkates teemat „Millised on teie tõendid?“, vaatame matemaatilise modelleerimise probleemi teiselt poolt. Pärast seda, kui oleme veendunud, et mudel vastab elu karmile tõele, saame vastata põhiküsimusele: „mida me siin tegelikult omame?“. Luues tehnilise objekti mudelit, soovime tavaliselt veenduda, et see objekt vastab meie ootustele. Selleks tehakse dünaamilisi arvutusi ja tulemused võrreldakse nõudmistega. See ongi digitaalne kaksik, virtuaalne prototüüp ja muud sarnased asjad, mis projekteerimise etapis lahendavad probleemi, kuidas saavutada, et saaksime seda, mida plaanisime.

Kuidas me saame kiiresti veenduda, et meie süsteem on just see, mida me projekteerime, kas see lendab või uju, meie konstruktsioon? Ja kui lendab, siis kui kõrgele? Ja kui uju, siis kui sügavale?

Selles artiklis käsitletakse tehnilise hoone nõuete täitmise kontrollimise automatiseerimist, kui luuakse dünaamilisi tehniliste süsteemide mudeleid. Näitena vaatame õhusõiduki õhukonditsioneerimise süsteemi tehnilise ülesande elementi.

Vaatleme neid nõudeid, mida saab numbriliselt väljendada ja matemaatiliselt kontrollida konkreetse arvutusmudeli alusel. Selge on, et need on vaid osa igasugustest nõuetest, mis kehtivad igasugustele tehnilistele süsteemidele, kuid just nende kontrollimiseks kulutame aega, närve ja raha objekti dünaamiliste mudelite loomisele.

Tehniliste nõuete dokumenteerimisel võib eristada erinevaid nõuete tüüpe, millest igaühel on erinevad lähenemisviisid automaatse nõuete täitmise kontrollimiseks.

Näiteks vaatame sellist väikest, kuid reaalselt olemasolevat nõuete komplekti:

1. Õhu temperatuur süsteemi sissepääsul:
   seisundis − vahemikus miinus 35 kuni 35 ºC,
   lennates − vahemikus miinus 35 kuni 39 ºC.
2. Kliimaõhu staatiline rõhk lennates − vahemikus 700 kuni 1013 GPa (alates 526 kuni 760 mm Hg)
3. Kliimaõhu kogurõhk süsteemi õhukanalis lennates − vahemikus 754 kuni 1200 GPa (alates 566 kuni 1050 mm Hg).
4. Külma õhu temperatuur:
   seisundis − mitte rohkem kui 27 ºC, tehniliste plokkide jaoks − mitte rohkem kui 29 ºC,
   lennul − mitte rohkem kui 25 ºC, tehniliste plokkide jaoks − mitte rohkem kui 27 ºC.
5. Jahutusõhu tarbimine:
   parkimise ajal − mitte vähem kui 708 kg/h,
   lennul − mitte vähem kui 660 kg/h.
6. Õhu temperatuur instrumentide sektsioonides − mitte rohkem kui 60 ºC.
7. Peene dispergeeritud vaba niiskuse hulk jahutusõhus − mitte rohkem kui 2 g/kg kuiva õhu.

Isegi selle piiratud nõudmiste kogumi seast võib välja tuua vähemalt kaks kategooriat, mida süsteemis tuleb erinevalt töödelda:

• süsteemi kasutamise tingimuste nõuded (p-p. 1-3);
• süsteemi parameetrilised nõuded (p-p. 3-7).

Süsteemi kasutamise tingimuste nõuded
Arendatava süsteemi välis tingimused modelleerimisel võivad olla määratud kui piirangutingimused või kui üldise süsteemi töö tulemus.
Dünaamilise modelleerimise puhul tuleb veenduda, et määratud töörežiimid katavad modelleerimisprotsessi.

Süsteemi parameetrilised nõuded
Need nõuded esindavad parameetreid, mida tagab süsteem ise. Modelleerimise käigus saame nende parameetrite kui arvutustulemuste ja veenduda, et nõuded on iga konkreetse arvutuse puhul täidetud.

Nõuete identifitseerimine ja kodeerimine

Nõudete mugavamaks käsitlemiseks soovitavad olemasolevad standardid igale nõudmisele identifikaatori määramist. Identifikaatorite määramisel on väga soovitatav kasutada ühtset kodeerimissüsteemi.

Nõude kood võib olla lihtsalt number, mis kajastab nõude järjestusnumbrit, või võib sisaldada nõude tüübi koodi, süsteemi või seadme, millele see kehtib, parameetri koodi, asukoha koodi ja palju muud, mida insener suudab ette kujutada. (kodeerimise kasutusnäide vt artiklist)

Tabelis 1 on toodud lihtne näide nõuete kodeerimisest.

1. nõuete allika kood R - nõuded TSeal;
2. nõuete tüüpide kood E – nõuded – väliskeskkonna parameetrid või kasutamise tingimused
   S − nõuded, mida süsteem tagab;
3. Lennuki oleku kood 0 – ükskõik, G – parkimisel, F – lennul;
4. füüsikaliste parameetride tüübi kood T – temperatuur, P – rõhk, G – vool, niiskus H;
5. nõude järjestikune number.

Nõuete kontrollimise süsteemi projekt.

Iga arvutatud nõude jaoks on olemas vastavuse hindamise algoritm, mis hindab arvutatud parameetreid ja nõudes määratud parameetreid. Suures plaanis sisaldab iga juhtimissüsteem alati endas nõuete kontrollimise algoritme lihtsalt vaikimisi. Ning isegi iga regulatiivne organ sisaldab neid. Kui temperatuur ületab piiri, lülitub sisse konditsioneer. Seega on igasuguse reguleerimise esimene etapp parameetrite vastavuse kontroll nõudele.

Ja kuna kontrollimine on algoritm, siis saab kasutada samu vahendeid ja tööriistu, mida me kasutame juhtimisprogrammide loomisel. Näiteks SimInTech keskkond võimaldab luua projektipakette, mis sisaldavad erinevaid mudeli osi, mis on teostatud eraldi projektidena (objekti mudel, juhtimismudeli, keskkonna mudel jne).

Nõuetele vastavuse kontrollimise projekt muutub sel juhul samasuguseks algoritmide projektiks ja on ühendatud mudelipaketiga. Ja dünaamilise modelleerimise režiimis viiakse läbi nõuete vastavuse analüüs.

Võimalik näide süsteemi projekti kujundamisest on esitatud joonisel 1.

Joonis 1. Näide nõuete kontrollimise projekti kujundamisest.

Sama nagu juhtimismehhanismide jaoks saab nõudeid esitada lehtede kogumina. Mugavuse huvides töötamiseks mudelite simuleerimise keskkondades, nagu SimInTech, Simulink, AmeSim, kasutatakse võimalusi luua mitmetasandilisi struktuure submudelidena. Selline korraldus võimaldab grupeerida erinevaid nõudeid kogudeks, et lihtsustada nõuete hulgaga töötamist, nagu seda tehakse juhtimismehhanismide puhul (vt joonis 2).

Joonis 2. Nõuete kontrollimise mudeli hierarhiline struktuur.

Näiteks antud juhul on välja toodud kaks gruppi: keskkonna nõuded ja nõuded süsteemile endale. Seetõttu kasutatakse kaht tasandit andmestruktuuri: kahte gruppi, millest igaüks on algoritmi leht.

Andmete ühendamiseks mudeliga kasutatakse standardset signaalide andmebaasi vormimise skeemi, kus hoitakse projekti osade vahel vahetatavaid andmeid.

Tarkvara loomisel ja katsetamisel sisestatakse sellesse andmebaasi sensori näitajad (reaalsete süsteemi sensorite analoogid), mida kasutatakse juhtimisse süsteemis.
Testimise projekti jaoks võib samas andmebaasis salvestada kõik parameetrid, mis arvutatakse dünaamilises mudelis, ja neid kasutada nõuete täitmise kontrollimiseks.

Dünaamiline mudel võib sel juhul olla loodud mis tahes matemaatilise modelleerimise süsteemis või isegi täidetud programmina. Ainus nõue on olemasolu programmiliideste andmete edastamiseks modelleerimisest väliskeskkonda.

Joonis 3. Kontrollimise projekti ühendamine kompleksse mudeliga.

Näide põhilisest nõuete kontrollimise lehest on esitatud joonisel 4. Arendaja vaatepunktist on see tavaline arvutusskeem, millel on graafiliselt esitatud nõuete kontrollimise algoritm.

Joonis 4. Nõuete kontrollimise leht.

Nõuete kontrollimise lehe põhiosad on esitatud joonisel 5. Kontrollimise algoritm moodustatakse sarnaselt juhtimismehhanismide arvutusskeemidega. Paremal küljel asub plokk signaalide lugemiseks andmebaasist. Selles plokis toimub andmebaasi signaalide juurde pääsemine modelleerimise ajal.

Saadud signaalid analüüsitakse nõuete kontrollimise tingimuste määramiseks. Antud juhul viiakse läbi kõrguse analüüs, et määrata, kas lennuk on pargitud või õhus. Selleks saab kasutada ka muid signaale ja mudeli arvutatud parameetreid.

Kontrollimise tingimused ja kontrollitavad parameetrid edastatakse tüüpilistesse kontrollplokkidesse, kus analüüsitakse nende parameetrite vastavust määratud nõuetele. Tulemused salvestatakse signaalide andmebaasi nii, et neid saab kasutada automaatse kontroll-loendi koostamiseks.

Joonis 5. Nõuete kontrollimise arvutusskeemi struktuur.

Kontrollitavate parameetritena ei pea tingimata kasutama andmebaasis sisalduvaid signaale, mis on juhitavad modellerimise käigus arvutatud parameetritega. Projekti nõuete raames ei takista miski täiendavate arvutuste tegemist, just nagu arvutame kontrollimise tingimusi.

Näiteks selline nõue:

Korrektuurisüsteemi aktiveerimise arv lennu ajal eesmärgini ei tohi ületada 5 ning kogu korrektuurisüsteemi tööaeg ei tohi ületada 30 sekundit.

Sellisel juhul lisatakse nõuete projekti arvutusskeemi aktiveerimise ja kogu tööaja loenduri algoritm.

Tüüpiline nõuete kontrollimise blokk.

Iga tüüpiline nõuete kontrollimise blokk on ette nähtud teatud tüüpi nõuete täitmise arvutamiseks. Näiteks keskkonna nõuetes on õhutemperatuuri vahemik, mis on kehtiv nii pargitud kui ka lennu ajal. See blokk peab saama parameetrina õhutemperatuuri mudelis ja määrama, kas see parameeter katab määratud temperatuuride vahemiku.

Blokk sisaldab kahte sisendporti, param ja condition.

Esimesele antakse kontrollitav parameeter. Antud juhul 'Väline temperatuur'.

Teisele porti antakse boolean muutuja – kontrollimise täitmise tingimus.

Kui teisele sisendile tuleb TRUE (1), siis blokk arvutab nõude kontrollimise.

Kui teine sisend annab FALSE (0), siis kontrollimise tingimusi ei täideta. See on vajalik, et arvesse võtta arvutuste tingimusi. Meie juhul kasutatakse seda sisendit, et sisse või välja lülitada kontrollimist olenevalt mudeli seisundist. Kui õhusõiduk on mudelimise ajal maapinnal, siis lennuga seotud nõuded ei kehti, ja vastupidi - kui õhusõiduk on lennul, siis ei kontrollita parkimisprotsessidega seotud nõudeid.

Seda sisendit saab kasutada ka mudeli seadistamisel, näiteks arvutuste algfaasis. Kui mudel seatakse nõutud olekusse, on kontrollblokid välja lülitatud, kuid niipea kui süsteem jõuab soovitud töörežiimi, aktiveeritakse kontrollblokid.

Selle ploki parameetriteks on:

• piirangutingimused: ülemine (UpLimit) ja alumine (DownLimit) piiri ulatus, mida tuleb kontrollida;
• nõutav aja pikkus, mille süsteem peab veetma piiri ulatuses (TimeInterval) sekundites;
• nõude identifikaator ReqName;
• lubatav väljumine ulatusest Out_range – boolean muutuja, mis määratleb, kas nõude rikkumine on seotud väärtuse väljundiga kontrollitud ulatusest.

Mõnel juhul tähendab kontrollitava väärtuse väljumine, et süsteemil on varu ja see suudab töötada väljaspool tööulatust. Teistes olukordades tähendab väljumine, et süsteem ei suuda hoida määratud parameetreid ulatuse piires.

Joonis 6. Tüüpiline kontrollplokk omaduse skeemil ja selle parameetrid.

Selle ploki arvutamise tulemuseks on väljundimuutuja Result, millel on järgmised väärtused:

• 0 – rNone, väärtus ei ole määratud;
• 1 – rDone, nõue on täidetud;
• 2 – rFault, nõue ei ole täidetud.

Ploki pildil on:

• identifikaori tekst;
• numbrilised kuvamised mõõtmispiiride parameetritest;
• parameetri oleku värvi identifikaator.

Ploki sees võib asuda piisavalt keeruline loogilise tuletuse skeem.

Näiteks, et kontrollida ploki tööulatuse temperatuuri, mis on esitatud joonisel 6, on sisemine skeem esitatud joonisel 7.

Joonis 7. Temperatuuride ulatuse määratlemise ploki sisemine skeem.

Ploki skeemides kasutatakse ploki parameetrites määratletud omadusi.
Lisaks nõuetele vastavuse analüüsile sisaldab sisemine ploki skeem graafikut, mis on vajalik modelleerimise tulemuste väljundiks. Seda graafikut saab kasutada nii arvutamise ajal vaatamiseks kui ka arvutamise järgselt tulemustega tutvumiseks.

Arvutustulemused edastatakse ploki väljundisse ja salvestatakse samal ajal üldisesse aruande faili, mis koostatakse kogu projekti tulemustest. (vt joonis 8)

Modelleerimise tulemustel põhinev aruande näide on HTML-fail, mis on loodud ettenähtud vormingus. Vormingut saab vastavalt konkreetse organisatsiooni vajadustele vabalt kohandada.

Ploki skeemides kasutatakse ploki parameetrites määratletud omadusi.
Lisaks nõuetele vastavuse analüüsile sisaldab sisemine ploki skeem graafikut, mis on vajalik modelleerimise tulemuste väljundiks. Seda graafikut saab kasutada nii arvutamise ajal vaatamiseks kui ka arvutamise järgselt tulemustega tutvumiseks.

Arvutustulemused edastatakse ploki väljundisse ja salvestatakse samal ajal üldisesse aruande faili, mis koostatakse kogu projekti tulemustest. (vt joonis 8)

Modelleerimise tulemustel põhinev aruande näide on HTML-fail, mis on loodud ettenähtud vormingus. Vormingut saab vastavalt konkreetse organisatsiooni vajadustele vabalt kohandada.

Joonis 8. Aruande faili näide modelleerimise tulemustest.

Antud näites viiakse aruande vormi seadistamine läbi otse projekti omadustes ning vorming määratakse tabelis kui projekti globaalne signaal. Sellisel juhul lahendab SimInTech ise aruande seadistamise ülesande, ning tulemuste faili salvestamise plokk kasutab neid ridu aruande faili kirjutamiseks.

Joonis 9. Aruande vormingu seadistamine projektis globaalsete signaalide kaudu.

Signaalide andmebaasi kasutamine nõuete jaoks.

Iga tüüploodi omaduste seadistamise töö automatiseerimiseks luuakse signaalide andmebaasis tüüpiline struktuur. (vt joonis 10)

Joonis 10. Näide nõude kontrollimise ploki struktuurist signaalide andmebaasis.

Signaalide andmebaas tagab:

• Kõikide süsteemile esitatud nõuete vajalikud parameetrid.
• Olemasolevate nõuete mugava vaatamise projekti antud parameetrite ja praeguste modelleerimise tulemuste põhjal.
• Ühe ploki, plokkide grupi seadistamise skriptikeele kasutamine. Muudatused signaalide andmebaasis muudavad ploki omaduste väärtusi skeemil.
• Tekstiliste kirjelduste, viidete Tõnniks jne või identifikaatorite säilitamine nõuete juhtimissüsteemis.

Nõuete signaalide andmebaasi struktuure saab hõlpsasti kohandada koostööks kolmanda osapoole nõuete juhtimissüsteemidega. Üldine skeem suhtlemiseks nõuete juhtimissüsteemidega on esitatud joonisel 11.

Joonis 11. Skeem nõuete juhtimissüsteemiga suhtlemiseks.

SimInTech'i testiprojekti interaktsiooni järjestus nõuete haldamise süsteemiga on järgmine:

1. Tehniline ülesanne jagatakse nõueteks.
2. Tuvastatakse sellised tehnilise ülesande nõuded, mida saab kontrollida matemaatilise modelleerimise abil.
3. Tuvastatud nõuete atribuudid edastatakse SimInTech'i signaalide andmebaasi tüüpiliste plokkide struktuuridesse (näiteks maksimaalne ja minimaalne temperatuur).
4. Arvutamise käigus edastatakse struktuuride andmed plokkide arvutusdiagrammidesse, tehakse analüüs ja tulemused salvestatakse signaalide andmebaasi.
5. Arvutamise lõppedes edastatakse analüüsi tulemused nõuete haldamise süsteemi.

Nõuetega töötamise etapid 3–5 võivad projekteerimise käigus korduda, kui konstruktsioonis ja (või) nõuetes toimuvad muudatused ning seetõttu on vajalik muudatuste mõju uuesti kontrollida.

Järeldused.

• Loodud süsteemi prototüüp tagab olemasolevate mudelite analüüsi aega märgatavalt lühendamise, arvestades nõuete vastavust tehnilisele ülesandele.
• Pakettide andmete korraldamise tehnoloogia kasutab juba olemasolevaid dünaamilisi mudeleid ja seda saab kasutada isegi mistahes dünaamiliste mudelite puhul, sealhulgas neid, mis ei ole loodud SimInTech'i keskkonnas.
• Andmepakettide kasutamine võimaldab nõuete kontrollimise pakettide loomist koos mudelite arendamisega või isegi kasutada neid pakette tehnilise ülesandena mudelite arendamiseks.
• Tehnoloogiat saab olemasolevate nõuete haldamise süsteemidega integreerida oluliste kuludeta.

Kellele see huvi pakub, siit leiate lingi prototüübi töö demonstreerimise videole.

Allikas: habr.com