Nadaljevanje teme , poglejmo problem matematičnega modeliranja z druge strani. Ko se prepričamo, da model ustreza domorodni resnici življenja, lahko odgovorimo na glavno vprašanje: »kaj pravzaprav imamo tukaj?« Pri izdelavi modela tehničnega predmeta se običajno želimo prepričati, da bo ta objekt izpolnil naša pričakovanja. V ta namen se izvajajo dinamični izračuni procesov in rezultat primerja z zahtevami. To je digitalni dvojček, virtualni prototip itd. modni malčki, ki že v fazi načrtovanja rešujejo problem, kako poskrbeti, da bomo dobili tisto, kar smo načrtovali.
Kako se lahko hitro prepričamo, da je naš sistem natanko takšen, kot ga načrtujemo, ali bo naš dizajn letel ali lebdel? In če leti, kako visoko? In če plava, kako globoko?
Ta članek obravnava avtomatizacijo preverjanja skladnosti z zahtevami tehnične zgradbe pri ustvarjanju dinamičnih modelov tehničnih sistemov. Kot primer si poglejmo element tehnične specifikacije za sistem zračnega hlajenja letala.
Upoštevamo tiste zahteve, ki jih je mogoče numerično izraziti in matematično preveriti na podlagi specifičnega računskega modela. Jasno je, da je to le del splošnih zahtev za kateri koli tehnični sistem, vendar za njihovo preverjanje porabimo čas, živce in denar za ustvarjanje dinamičnih modelov predmeta.
Pri opisu tehničnih zahtev v obliki dokumenta lahko ločimo več vrst različnih zahtev, od katerih vsaka zahteva različne pristope za oblikovanje avtomatskega preverjanja izpolnjevanja zahtev.
Na primer, razmislite o tem majhnem, a realnem nizu zahtev:
- Temperatura atmosferskega zraka na vhodu v sistem za čiščenje vode:
na parkirišču - od minus 35 do 35 ºС,
med letom - od minus 35 do 39 ºС. - Statični tlak atmosferskega zraka med letom je od 700 do 1013 GPa (od 526 do 760 mm Hg).
- Skupni zračni tlak na vhodu v dovod zraka SVO med letom je od 754 do 1200 GPa (od 566 do 1050 mm Hg).
- Temperatura hladilnega zraka:
na parkirišču - ne več kot 27 ºС, za tehnične bloke - ne več kot 29 ºС,
med letom - ne več kot 25 ºС, za tehnične bloke - ne več kot 27 ºС. - Pretok hladilnega zraka:
pri parkiranju - najmanj 708 kg/h,
med letom - ne manj kot 660 kg / h. - Temperatura zraka v prostorih za instrumente ni višja od 60 ºС.
- Količina fine proste vlage v hladilnem zraku ne presega 2 g/kg suhega zraka.
Tudi znotraj tega omejenega nabora zahtev obstajata vsaj dve kategoriji, ki ju je treba v sistemu obravnavati drugače:
- zahteve za pogoje delovanja sistema (klavzule 1-3);
- parametrične zahteve za sistem (klavzule 3–7).
Zahteve glede pogojev delovanja sistema
Zunanji pogoji za sistem, ki se razvija med modeliranjem, so lahko določeni kot robni pogoji ali kot rezultat delovanja splošnega sistema.
Pri dinamični simulaciji je treba zagotoviti, da so navedeni pogoji delovanja zajeti v procesu simulacije.
Parametrične sistemske zahteve
Te zahteve so parametri, ki jih zagotovi sam sistem. V procesu modeliranja lahko te parametre pridobimo kot rezultate izračuna in poskrbimo, da so zahteve izpolnjene pri vsakem posameznem izračunu.
Identifikacija in kodiranje zahtev
Za lažje delo z zahtevami obstoječi standardi priporočajo dodelitev identifikatorja vsaki zahtevi. Pri dodeljevanju identifikatorjev je zelo zaželena uporaba enotnega kodirnega sistema.
Koda zahteve je lahko preprosto številka, ki predstavlja številko naročila zahteve, ali pa lahko vsebuje kodo za vrsto zahteve, kodo za sistem ali enoto, na katero se nanaša, kodo parametra, kodo lokacije in kar koli drugega, kar si inženir lahko zamisli. (glej članek o uporabi kodiranja)
Tabela 1 prikazuje preprost primer kodiranja zahtev.
- šifra vira zahtev R-zahteve TK;
- šifra vrsta zahtev E - zahteve - okoljski parametri, oziroma obratovalni pogoji
S - zahteve, ki jih zagotavlja sistem; - statusna koda letala 0 – kateri koli, G – parkiran, F – v letu;
- koda tipa fizičnega parametra T – temperatura, P – tlak, G – pretok, vlažnost H;
- zaporedno številko zahteve.
| ID Zahteve |
Opis | Parameter |
| REGT01 | Temperatura zunanjega zraka na vhodu v sistem vodnega hlajenja: na parkirišču - od minus 35ºС. do 35 ºС. | |
| REFT01 | Temperatura atmosferskega zraka na vhodu v sistem zračne obrambe: med letom - od minus 35 ºС do 39 ºС. | |
| REFP01 | Statični atmosferski zračni tlak med letom je od 700 do 1013 hPa (od 526 do 760 mm Hg). | |
| REFP02 | Skupni zračni tlak na vhodu v dovod zraka SVO med letom je od 754 do 1200 hPa (od 566 do 1050 mm Hg). | |
| RSGT01 | Temperatura hladilnega zraka: pri parkiranju ne več kot 27 ºС | |
| RSGT02 | Temperatura hladilnega zraka: na parkirišču, za tehnične enote ne več kot 29 ºС | |
| RSFT01 | Temperatura hladilnega zraka med letom ne presega 25 ºС | |
| RSFT02 | Temperatura hladilnega zraka: med letom, za tehnične enote ne več kot 27 ºС | |
| RSGG01 | Pretok hladilnega zraka: v parkiranem stanju ne manj kot 708 kg/h | |
| RSFG01 | Pretok hladilnega zraka: med letom ne manj kot 660 kg/h | |
| RS0T01 | Temperatura zraka v prostorih za instrumente ne presega 60 ºС | |
| RSH01 | Količina fine proste vlage v hladilnem zraku ne presega 2 g/kg suhega zraka |
Zasnova sistema za preverjanje zahtev.
Za vsako projektno zahtevo obstaja algoritem za ocenjevanje ujemanja projektnih parametrov in parametrov, navedenih v zahtevi. Na splošno vsak nadzorni sistem vedno vsebuje algoritme za preverjanje zahtev preprosto privzeto. In celo kateri koli regulator jih vsebuje. Če temperatura preseže meje, se klimatska naprava vklopi. Tako je prva faza vsake regulacije preverjanje, ali parametri izpolnjujejo zahteve.
In ker je preverjanje algoritem, potem lahko uporabljamo ista orodja in orodja, ki jih uporabljamo za ustvarjanje nadzornih programov. Na primer, okolje SimInTech vam omogoča ustvarjanje projektnih paketov, ki vsebujejo različne dele modela, izvedene v obliki ločenih projektov (model objekta, model nadzornega sistema, model okolja itd.).
Projekt preverjanja zahtev v tem primeru postane isti projekt algoritma in je povezan s paketom modela. V načinu dinamičnega modeliranja pa izvede analizo skladnosti z zahtevami tehničnih specifikacij.
Možen primer zasnove sistema je prikazan na sliki 1.
Slika 1. Primer zasnove projekta verifikacije.
Tako kot za nadzorne algoritme je mogoče zahteve sestaviti kot niz listov. Za udobje dela z algoritmi v okoljih strukturnega modeliranja, kot so SimInTech, Simulink, AmeSim, se uporablja zmožnost ustvarjanja večnivojskih struktur v obliki podmodelov. Ta organizacija omogoča združevanje različnih zahtev v nize za poenostavitev dela z nizom zahtev, kot je storjeno za nadzorne algoritme (glej sliko 2).
Slika 2. Hierarhična struktura modela preverjanja zahtev.
Na primer, v obravnavanem primeru ločimo dve skupini: zahteve za okolje in zahteve neposredno za sistem. Zato se uporablja dvonivojska podatkovna struktura: dve skupini, od katerih je vsaka list algoritma.
Za povezavo podatkov z modelom se uporablja standardna shema za generiranje podatkovne baze signalov, ki hrani podatke za izmenjavo med deli projekta.
Pri izdelavi in testiranju programske opreme se odčitki senzorjev (analogi senzorjev realnega sistema), ki jih uporablja krmilni sistem, vnesejo v to bazo podatkov.
Za testni projekt je mogoče vse parametre, izračunane v dinamičnem modelu, shraniti v isto bazo podatkov in jih tako uporabiti za preverjanje, ali so zahteve izpolnjene.
V tem primeru se lahko sam dinamični model izvede v katerem koli sistemu za matematično modeliranje ali celo v obliki izvršljivega programa. Edina zahteva je prisotnost programskih vmesnikov za izdajanje podatkov modeliranja v zunanje okolje.
Slika 3. Povezava projekta preverjanja s kompleksnim modelom.
Primer lista za preverjanje osnovnih zahtev je predstavljen na sliki 4. Z vidika razvijalca je to običajen računski diagram, na katerem je grafično predstavljen algoritem za preverjanje zahtev.
Slika 4. Kontrolni list zahtev.
Glavni deli kontrolnega lista so opisani na sliki 5. Algoritem preverjanja je oblikovan podobno kot načrtovalni diagrami kontrolnih algoritmov. Na desni strani je blok za branje signalov iz baze podatkov. Ta blok dostopa do podatkovne baze signalov med simulacijo.
Prejeti signali se analizirajo za izračun pogojev preverjanja zahtev. V tem primeru se opravi analiza višine, da se določi položaj letala (ali je parkirano ali v letu). V ta namen lahko uporabite druge signale in izračunane parametre modela.
Pogoji preverjanja in parametri, ki se preverjajo, se prenesejo v standardne bloke preverjanja, v katerih se ti parametri analizirajo glede skladnosti z določenimi zahtevami. Rezultati so zabeleženi v podatkovni bazi signalov na tak način, da jih je mogoče uporabiti za samodejno ustvarjanje kontrolnega seznama.
Slika 5. Struktura lista za izračun preverjanja zahtev.
Parametri, ki jih je treba testirati, ne uporabljajo nujno signalov v bazi podatkov, ki jih nadzirajo parametri, izračunani med postopkom simulacije. Nič nam ne preprečuje, da v okviru osnutka zahtev izvedemo dodatne izračune, tako kot izračunamo pogoje preverjanja.
Na primer, ta zahteva:
Število aktivacij korekcijskega sistema med letom do cilja ne sme presegati 5, skupni čas delovanja korekcijskega sistema pa ne sme presegati 30 sekund.
V tem primeru se načrtovalnemu diagramu zahtev doda algoritem za uravnavanje števila zagonov in skupnega časa delovanja.
Blok za preverjanje tipičnih zahtev.
Vsako potrditveno polje standardne zahteve je zasnovano za izračun izpolnjevanja zahteve določene vrste. Na primer, okoljske zahteve vključujejo razpon delovnih temperatur okolice med parkiranjem in med letom. Ta blok mora prejeti temperaturo zraka v modelu kot parameter in ugotoviti, ali ta parameter pokriva določeno temperaturno območje./p>
Blok vsebuje dva vhodna vrata, param in condition.
Prvi se napaja s parametrom, ki se preverja. V tem primeru "Zunanja temperatura".
Drugim vratom je dostavljena logična spremenljivka - pogoj za izvedbo preverjanja.
Če je na drugem vhodu prejet TRUE (1), potem blok izvede izračun preverjanja zahteve.
Če drugi vnos prejme FALSE (0), preskusni pogoji niso izpolnjeni. To je potrebno, da se lahko upoštevajo pogoji izračuna. V našem primeru se ta vnos uporablja za omogočanje ali onemogočanje preverjanja glede na stanje modela. Če je letalo med simulacijo na tleh, se zahteve v zvezi z letom ne preverjajo in obratno - če je letalo v letu, se zahteve v zvezi z delovanjem v mirovanju ne preverjajo.
Ta vnos se lahko uporabi tudi pri nastavitvi modela, na primer v začetni fazi izračuna. Ko je model preveden v zahtevano stanje, so kontrolni bloki onemogočeni, vendar takoj, ko sistem doseže želeni način delovanja, se kontrolni bloki vklopijo.
Parametri tega bloka so:
- robni pogoji: zgornja (UpLimit) in spodnja (DownLimit) meja območja, ki ju je treba preveriti;
- zahtevani čas izpostavljenosti sistema na mejnih območjih (TimeInterval) v sekundah;
- ID zahteve ReqName;
- dopustnost preseganja obsega Out_range je logična spremenljivka, ki določa, ali je vrednost, ki presega označeni obseg, kršitev zahteve.
V nekaterih primerih izhod preskusne vrednosti kaže, da ima sistem nekaj rezerve in morda deluje izven svojega delovnega območja. V drugih primerih izhod pomeni, da sistem ne more obdržati nastavljenih točk v območju.
Slika 6. Tipičen blok za preverjanje lastnosti v diagramu in njegovi parametri.
Kot rezultat izračuna tega bloka se na izhodu oblikuje spremenljivka Rezultat, ki ima naslednje vrednosti:
- 0 – rBrez, vrednost ni definirana;
- 1 – rDone, zahteva je izpolnjena;
- 2 – rNapaka, zahteva ni izpolnjena.
Slika bloka vsebuje:
- besedilo identifikatorja;
- Digitalni prikazovalniki parametrov merilnih meja;
- barvni identifikator stanja parametra.
Znotraj bloka je lahko precej zapleteno logično sklepno vezje.
Na primer, če želite preveriti območje delovne temperature enote, prikazane na sliki 6, je notranji tokokrog prikazan na sliki 7.
Slika 7. Notranji diagram enote za določanje temperaturnega območja.
Znotraj bloka vezja se uporabljajo lastnosti, določene v parametrih bloka.
Poleg analize skladnosti z zahtevami notranji diagram bloka vsebuje graf, potreben za prikaz rezultatov simulacije. Ta graf se lahko uporablja tako za ogled med izračunom kot za analizo rezultatov po izračunu.
Rezultati izračuna se prenesejo na izhod bloka in se hkrati zabeležijo v datoteko splošnega poročila, ki se ustvari na podlagi rezultatov za celoten projekt. (glej sliko 8)
Primer poročila, ustvarjenega na podlagi rezultatov simulacije, je datoteka html, ustvarjena v danem formatu. Format je mogoče poljubno konfigurirati v format, ki ga sprejema določena organizacija.
Znotraj bloka vezja se uporabljajo lastnosti, določene v parametrih bloka.
Poleg analize skladnosti z zahtevami notranji diagram bloka vsebuje graf, potreben za prikaz rezultatov simulacije. Ta graf se lahko uporablja tako za ogled med izračunom kot za analizo rezultatov po izračunu.
Rezultati izračuna se prenesejo na izhod bloka in se hkrati zabeležijo v datoteko splošnega poročila, ki se ustvari na podlagi rezultatov za celoten projekt. (glej sliko 8)
Primer poročila, ustvarjenega na podlagi rezultatov simulacije, je datoteka html, ustvarjena v danem formatu. Format je mogoče poljubno konfigurirati v format, ki ga sprejema določena organizacija.
Slika 8. Primer datoteke poročila na podlagi rezultatov simulacije.
V tem primeru je obrazec poročila konfiguriran neposredno v lastnostih projekta, oblika v tabeli pa je nastavljena kot signali globalnega projekta. V tem primeru SimInTech sam reši problem nastavitve poročila, blok za zapisovanje rezultatov v datoteko pa uporablja te vrstice za pisanje v datoteko poročila.
Slika 9. Nastavitev oblike poročila v signalih globalnega projekta
Uporaba podatkovne baze signalov za zahteve.
Za avtomatizacijo dela z nastavitvami lastnosti se v podatkovni zbirki signalov ustvari standardna struktura za vsak tipičen blok. (glej sliko 10)
Slika 10. Primer strukture bloka za preverjanje zahtev v bazi podatkov signalov.
Podatkovna baza signalov zagotavlja:
- Shranjevanje vseh potrebnih parametrov sistemskih zahtev.
- Priročen pregled obstoječih projektnih zahtev iz določenih parametrov in trenutnih rezultatov modeliranja.
- Nastavitev enega bloka ali skupine blokov z uporabo skriptnega programskega jezika. Spremembe v zbirki signalov vodijo do sprememb vrednosti lastnosti bloka v diagramu.
- Shranjevanje besedilnih opisov, povezav do postavk tehničnih specifikacij ali identifikatorjev v sistemu za upravljanje zahtev.
Strukture baze podatkov signalov za zahteve je mogoče enostavno konfigurirati za delo s sistemom za upravljanje zahtev tretje osebe. Splošni diagram interakcije s sistemi za upravljanje zahtev je predstavljen na sliki 11.
Slika 11. Diagram interakcije s sistemom za upravljanje zahtev.
Zaporedje interakcije med testnim projektom SimInTech in sistemom za nadzor zahtev je naslednje:
- Projektna naloga je razdeljena na zahteve.
- Identificirane so zahteve tehničnih specifikacij, ki jih je mogoče preveriti z matematičnim modeliranjem tehničnih procesov.
- Atributi izbranih zahtev se prenesejo v bazo signalov SimInTech v strukturi standardnih blokov (npr. najvišja in najnižja temperatura).
- Med postopkom izračuna se strukturni podatki prenesejo v diagrame načrtovanja blokov, izvede se analiza in rezultati se shranijo v podatkovno bazo signalov.
- Ko je izračun končan, se rezultati analize prenesejo v sistem za upravljanje zahtev.
Koraki zahtev od 3 do 5 se lahko med postopkom načrtovanja ponovijo, ko pride do sprememb načrta in/ali zahtev in je treba ponovno preizkusiti vpliv sprememb.
Sklepi.
- Ustvarjen prototip sistema zagotavlja znatno skrajšanje časa analize obstoječih modelov za skladnost z zahtevami tehničnih specifikacij.
- Predlagana tehnologija testiranja uporablja že obstoječe dinamične modele in se lahko uporablja tudi za vse dinamične modele, vključno s tistimi, ki se ne izvajajo v okolju SimInTech.
- Uporaba paketne organizacije podatkov vam omogoča ustvarjanje paketov za preverjanje zahtev vzporedno z razvojem modela ali celo uporabo teh paketov kot tehnične specifikacije za razvoj modela.
- Tehnologijo je mogoče integrirati z obstoječimi sistemi upravljanja zahtev brez večjih stroškov.
Za tiste, ki preberete do konca,
Vir: www.habr.com