Automaatne nõuete kontrollimine TSh nõuete käigus dünaamilise modelleerimise protsessis

Jätkates teemat „Millised on teie tõendid?“, vaatame matemaatilise mudeldamise probleemi teisest küljest. Pärast seda, kui oleme kinnitanud, et mudel vastab elu igapäeva tõele, saame vastata põhiprobleemile: „mida me siis tegelikult omame?“ Luues tehnilise objekti mudeli, tahame enamasti veenduda, et see objekt vastab meie ootustele. Selleks viiakse läbi dünaamilisi arvutusi ja tulemus võrdleb meie nõudmistega. See on digitaalne kaksik, virtuaalne prototüüp ja muud moodsad asjad, mis disainietapis lahendavad ülesande, kuidas saavutada soovitud tulemusi.

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

Selles artiklis käsitletakse tehnilise objekti nõuete kontrollimise automatiseerimist dünaamiliste tehniliste süsteemide mudelite loomisel. Näiteks vaatame lennuki õhukonditsioneerimise süsteemi tehnilise ülesande elementi.

Käsitleme neid nõudeid, mida on võimalik numbriliselt väljendada ja matemaatiliselt kindlaks teha, tuginedes konkreetsele arvutusmudelile. Selge on see, et see on ainult osa kõigist nõudmistest, mis kehtivad igale tehnilisele süsteemile, kuid just nende nõuete kontrollimiseks me kulutame aega, närve ja raha dünaamiliste objektimudelite loomisel.

Tehniliste nõuete kirjeldamisel dokumendi vormis saab eristada mitmeid erinevaid nõuete liike, millest igaühel on eri lähenemisviisid automaatse nõuete täitmise kontrollimise korraldamiseks.

Näiteks vaatame sellist väikest, kuid tõelist nõuete kogumit:

1. Õhuhulga temperatuur sisenemisel SVO-sse:
   seisakus – vahemikus miinus 35 kuni 35 ºC,
   lennul – vahemikus miinus 35 kuni 39 ºC.
2. Staaticu õhurõhk lennul – vahemikus 700 kuni 1013 GPa (vahemikus 526 kuni 760 mm rt. st.).
3. Kogurõhk õhu sisenemisel SVO õhu sisselaskeava – vahemikus 754 kuni 1200 GPa (vahemikus 566 kuni 1050 mm rt. st.).
4. Jahutusõhu temperatuur:
   seisakus – mitte rohkem kui 27 ºC, tehniliste plokkide puhul – mitte rohkem kui 29 ºC,
   lennul – mitte rohkem kui 25 ºC, tehniliste plokkide puhul – mitte rohkem kui 27 ºC.
5. Jahutusõhu voog:
   seisakus – 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. Mikroskoopilise vaba niiskuse hulk jahutusõhus – mitte rohkem kui 2 g/kg kuiva õhku.

I isegi selle piiratud nõuete kogumi puhul saab välja tuua vähemalt kaks kategooriat, mida tuleb süsteemis erinevalt töödelda:

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

Süsteemi töötingimuste nõuded
Välised tingimused projekteeritavale süsteemile modelleerimisel võivad olla määratud kas piirangutingimustena või üldsüsteemi tegevuse tulemusena.
Dünaamilise modelleerimise korral tuleb veenduda, et määratud töörežiimid katab modelleerimisprotsess.

Süsteemi parameetrilised nõuded
Need nõuded esindavad parameetreid, mida tagab süsteem ise. Modelleerimise käigus saame need parameetrid arvutuse tulemustena ning veendumiseks, et nõuded on täidetud iga konkreetse arvutuse puhul.

Nõuete tuvastamine ja kodeerimine

Mugavuse huvides nõuete töötlemisel soovitatakse olemasolevates standardites iga nõudega seostada identifikaator. Identifikaatorite määramisel on väga soovitatav kasutada ühtset kodeerimisse süsteemi.

Nõude kood võib olla lihtsalt number, mis peegeldab nõude järjekorranumbrit, või see võib sisaldada nõude tüübi koodi, süsteemi või seadme koodi, millele see kehtib, parameetri koodi, asukoha koodi ja palju muud, mida insener suudab ette kujutada. (kodeerimise kasutusvariandi nägemiseks vaata artiklit)

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

1. nõude allika kood R - nõuete TЗ;
2. nõuete tüübi kood E – nõuded – välist keskkonna parameetrid või töötingimused
   S — nõuded, mida tagab süsteem;
3. lennuki oleku kood 0 – iga, G – seisakus, F – lennul;
4. füüsikaliste parameetrite tüübi kood T – temperatuur, P – rõhk, G – voog, niiskus H;
5. nõude järjekorranumber.

Nõuete kontrollimise süsteemi projekt.

Iga arvutusnõude jaoks on olemas sobivuse hindamise algoritm, mis hindab arvutatud parameetreid ja nõutavaid parameetreid. Üldiselt sisaldab iga juhtimisseade alati automaatselt nõuete kontrollimise algoritme. Isegi iga reguleerija sisaldab neid. Kui temperatuur ületab piiri, käivitatakse konditsioneer. Seega on igasuguse reguleerimise esimene etapp parameetrite vastavuse kontrollimine nõudmistele.

Ja kuna kontroll on algoritm, siis saab kasutada samu vahendeid ja tööriistu, mida me kasutame juhtimisprogrammide loomisel. Näiteks SimInTech'i keskkond võimaldab luua projektide pakette, mis sisaldavad erinevaid mudeli osi, mis on esitatud eraldi projektidena (objekti mudel, juhtimisseadmise mudel, keskkonna mudel jne).

Nõuete kontrollimise projekt muutub selles kontekstis samasuguseks algoritmide projektiks ja ühendatakse mudeli paketi külge. Ja dünaamilise modelleerimise režiimis toimub nõuete vastavuse analüüs.

Võimalik näide süsteemi projekti esitamisest on toodud joonisel 1.

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

Samamoodi nagu juhtimisalgoritmide jaoks, saab nõudeid esitada lehtede kogumina. Mugavuse huvides algoritmide töötlemisel struktuurse modelleerimise keskkondades nagu SimInTech, Simulink, AmeSim kasutatakse mitmetasandiliste struktuuride loomi submudelina. Selline organisatsioon võimaldab rühmitada erinevaid nõudeid kogumiteks, et hõlbustada töö tegemist nõuete hulgaga, nagu seda tehakse juhtimisalgoritmide 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 otse süsteemile. Seetõttu kasutatakse kaheastmelist andmestruktuuri: kaks gruppi, millest igaüks on algoritmi leht.

Andmete ühendamiseks mudeliga kasutatakse standardset signaalide andmebaasi loomise skeemi, kus hoitakse andmeid projekti osade vaheliseks vahetamiseks.

Programmi loomise ja testimise käigus pärinevad sellele andmebaasi sensorite näidud (reaalsete sensorite analoogid süsteemis), mida juhtimisseade kasutab.
Testimisprojekti jaoks võib samas andmebaasis salvestada kõik parameetrid, mis arvutatakse dünaamilises mudelis, ja seega kasutada nõuete täitmise kontrollimiseks.

Dünaamiline mudel võib selles kontekstis olla loodud mis tahes matemaatilise modelleerimise süsteemis või isegi käitatava programmiga. Ainus nõue on programmiliideste olemasolu, et edastada modelleerimise andmed väliskeskkonda.

Joonis 3. Kontrollimise projekti ühendamine kompleksse mudeliga.

Näide põhilehe nõuete kontrollimisest on esitatud joonisel 4. Arendaja vaatenurgast esindab see tavalist arvutusplaani, kus graafiliselt on esitatud nõuete kontrollimise algoritm.

Joonis 4. Nõuete kontrollimise leht.

Põhilised osad nõuete kontrollimislehe kohta on esitatud joonisel 5. Kontrollimise algoritm vormitakse sarnaselt juhtimisalgoritmide arvutusskeemidele. Paremal küljel asub signaalide lugemise plokk andmebaasist. Selles plokis toimub signaalide andmebaasi ligipääs modelleerimise ajal.

Saadud signaalid analüüsitakse nõuete kontrollimise tingimuste määramiseks. Antud juhul viiakse läbi kõrguse analüüs lennuki asukoha määramiseks (kas see on maapinnal või õhus). Selleks võib kasutada ka muid signaale ja mudelites arvutatud parameetreid.

Kontrollimise tingimused ja kontrollitavad parameetrid edastatakse tüüpilistesse kontrolliblokidesse, kus analüüsitakse nende parameetrite andmeid vastavuse osas kehtestatud nõuetele. Tulemused salvestatakse signaalide andmebaasi selliselt, et neid saab kasutada automaatse kontrollnimekirja koostamiseks.

Joonis 5. Nõuete kontrollimise kalkuleerimislehe struktuur.

Kontrollitavate parameetriteks ei ole tingimata signaalid, mis on andmebaasis, mis on juhitud mudelites arvutatavate parameetrite poolt. Miski ei takista projekti nõuete raames täiendavate arvutuste tegemist, samamoodi nagu me arvutame kontrollimise tingimusi.

Näiteks selline nõue:

Korrigeerimissüsteemi sisselülitamiste arv lennu ajal sihtkohta ei tohi ületada 5 ning korrigeerimissüsteemi koguaeg ei tohi ületada 30 sekundi.

Sellisel juhul lisatakse nõuete projekti kalkulatsiooniskeemile sisselülitamiste arvu ja koguaega arvestav algoritm.

Tüüpiline nõuete kontrollimise blokk.

Iga tüüpiline nõuete kontrollimise blokk on loodud teatud tüüpi nõude täitmise arvutamiseks. Näiteks keskkonnanõuetes on esitatud ümbritseva õhu töötemperatuuride vahemik maapinnal ja õhus. See blokk peab saama mudelist õhu temperatuuri parameetrina ning määrama, kas see katab määratud temperatuuride vahemiku.

Blokk sisaldab kahte sisendporti, param ja condition.

Esimesele antakse kontrollitav parameeter. Antud juhul „Väline temperatuur”.

Teisele portile antakse boolean muutuja – kontrollimise tingimus.

Kui teisele sisendile tuleb TRUE (1), siis blokk viib läbi nõude kontrollimise arvutuse.

Kui teisele sisendile tuleb FALSE (0), siis kontrollimise tingimusi ei täideta. See on vajalik, et arvestada arvutamise tingimusi. Meie juhul kasutatakse seda sisendit, et lülitada kontrollimist sisse või välja sõltuvalt mudeli olekust. Kui õhusõiduk on modelleerimise ajal maapinnal, ei kontrollita lennuga seotud nõudeid, ja vastupidi – kui õhusõiduk on õhus, ei kontrollita maapinna tööga seotud nõudeid.

Seda sisendit saab kasutada ka mudeli seadistamisel, näiteks arvutuse algfaasis. Kui mudel viiakse nõutavasse olekusse, on kontrolliblokid välja lülitatud, kuid niipea kui süsteem jõuab nõutud töörežiimi, lülitatakse kontrolliblokid sisse.

Selle bloki parameetriteks on:

• piiritingimused: ülemine (UpLimit) ja alumine (DownLimit) piirmäärad, mida tuleb kontrollida;
• nõutav viibimise aeg süsteemile piirvahemike juures (TimeInterval) sekundites;
• nõude identifikaator ReqName;
• lubatav väljapääs vahemikust Out_range – boolean muutuja, mis määratleb, kas nõude rikkumine on väärtuse väljapääs kontrollitavast vahemikust.

Mõnedes juhtudel tähendab kontrollitava väärtuse väljapääs, et süsteemil on reserve ja see suudab töötada väljaspool töövahemikku. Teistes olukordades tähendab väljapääs, et süsteem ei suuda hoida määratud parameetreid vahemikus.

Joonis 6. Tüüpiline omaduse kontrollimise blokk diagrammil ja selle parameetrid.

Antud bloki arvutuse tulemusena tekib väljundis muutuja Result, millel on järgmised väärtused:

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

Bloki joonisel on:

• identifikaatori tekst;
• piiride mõõtmise parameetrite digitaalne kuvamine;
• parameetri oleku värviline identifikaator.

Bloki sees võib olla piisavalt keeruline loogilise järelduse skeem.

Näiteks, et kontrollida temperatuuride töövahemikku, mis on toodud joonisel 6, on sisemine skeem esitatud joonisel 7.

Joonis 7. Temperatuuride vahemiku määramise bloki sisemine skeem.

Bloki skeemis kasutatakse omadusi, mis on määratud bloki parameetrites.
Lisaks nõuete vastavuse analüüsile sisaldab ploki sisemine skeem graafikut, mis on vajalik simulatsiooni tulemuste kuvamiseks. Seda graafikut saab kasutada nii arvestuse ajal kui ka tulemuste analüüsimiseks pärast arvutust.

Arvutuse tulemused edastatakse ploki väljundisse ja salvestatakse samal ajal üldisesse aruanne faili, mis luuakse kogu projekti tulemuste alusel. (vt joonis 8)

Simulatoritulemuste alusel loodud aruande näidis on html-fail, mis on loodud ettenähtud vormingus. Vormingut saab vabalt kohandada konkreetse organisatsiooni aktsepteeritud formaadi järgi.

Bloki skeemis kasutatakse omadusi, mis on määratud bloki parameetrites.
Lisaks nõuete vastavuse analüüsile sisaldab ploki sisemine skeem graafikut, mis on vajalik simulatsiooni tulemuste kuvamiseks. Seda graafikut saab kasutada nii arvestuse ajal kui ka tulemuste analüüsimiseks pärast arvutust.

Arvutuse tulemused edastatakse ploki väljundisse ja salvestatakse samal ajal üldisesse aruanne faili, mis luuakse kogu projekti tulemuste alusel. (vt joonis 8)

Simulatoritulemuste alusel loodud aruande näidis on html-fail, mis on loodud ettenähtud vormingus. Vormingut saab vabalt kohandada konkreetse organisatsiooni aktsepteeritud formaadi järgi.

Joonis 8. Näidisaruande fail simulatori tulemustest.

Selles näites tehakse aruande vormi seadistus otse projekti omadustes ja vorming määratakse tabelis globaalsete signaalidena. Sellisel juhul lahendab SimInTech aruande seadmise probleemi iseseisvalt ning tulemuste faili salvestamise plokk kasutab neid ridu aruanne faili kirjutamiseks.

Joonis 9. Aruande vormingu seadistamine projekti globaalsetes signaalides

Nõuete signaalide andmebaasi kasutamine.

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

Joonis 10. Näidis nõudeontrolploki struktuur signaalide andmebaasis.

Signaalide andmebaas tagab:

• Kõigi vajalike nõuete parameetrite salvestamine süsteemile.
• Mugav olemasolevate nõuete vaatamine projekti määratud parameetritest ja praegustest simulatsiooni tulemustest.
• Üksiku ploki, plokkide rühmade seadistamine skriptikeele abil. Muudatused signaalide andmebaasis viivad ploki omaduste väärtuste muutumiseni skeemil.
• Tekstiliste kirjelduste, viidates tehniliste ülesannete punktidele või identifikaatoritele nõuete haldamise süsteemis salvestamine.

Nõuete signaalide andmebaasi struktuurid saavad lihtsasti seadistuda koostööks kolmandate osapoolte nõuete haldamise süsteemidega. Üldine interaktsiooniskeem nõuete haldamise süsteemidega on esitatud joonisel 11.

Joonis 11. Vastastikuse mõju skeem nõuete haldamise süsteemiga.

SimInTech testprojekti ja nõuete haldamise süsteemi vaheline interaktsioon järgib järgmisi etappe:

1. Tehniline ülesanne jaguneb nõueteks.
2. Erakordsed nõuded tehnilisest ülesandest, mida saab kontrollida matemaatilise modelleerimise abil, tuuakse esile.
3. Erakordsete nõuete atribuudid edastatakse SimInTech signaalide andmebaasi tüüplahenduse struktuuridesse (nt maksimaalne ja minimaalne temperatuur).
4. Arvutuse käigus edastatakse struktuuri andmed blokke arvutusskeemidesse, viiakse läbi analüüs ja tulemused salvestatakse signaalide andmebaasi.
5. Arvutuse lõppedes edastatakse analüüsi tulemused nõuete haldamise süsteemi.

Nõuetega tegelemise etapid 3–5 võivad korduda projekteerimisprotsessi ajal, kui konstruktsioonis ja (või) nõuetes toimuvad muudatused ning seega on vajalik täiendav kontroll tehtud muudatuste mõju üle.

Järeldused.

• Loodud süsteemi prototüüp võimaldab oluliselt vähendada olemasolevate mudelite analüüsi aega nõuete vastavuse kontrollimiseks.
• Pakutud testimise tehnoloogia kasutab juba olemasolevaid dünaamilise mudelid ja võib olla kasutatav isegi kõigi dünaamiliste mudelite jaoks, sealhulgas mitte SimInTech keskkonnas loodud mudelite jaoks.
• Andmete pakettide kasutamine võimaldab luua nõuete kontrollimise pakette paralleelselt mudelite väljatöötamisega või isegi kasutada neid pakette tehnilise ülesande loomiseks mudelite väljatöötamiseks.
• Tehnoloogia saab integreerida ilma oluliste kuludeta olemasolevate nõuete haldamise süsteemidega.

Küsimustele, mis blokeerisid lugemist, siin on link prototüübi töö demostreerimise video juurde.

Allikas: habr.com