Nastavljam temu , pogledajmo problem matematičkog modeliranja s druge strane. Nakon što se uvjerimo da model odgovara domaćoj istini života, možemo odgovoriti na glavno pitanje: „šta, zapravo, imamo ovdje?“ Kada kreiramo model tehničkog objekta, obično želimo da budemo sigurni da će ovaj objekat ispuniti naša očekivanja. U tu svrhu provode se dinamički proračuni procesa i rezultat se upoređuje sa zahtjevima. Ovo je digitalni blizanac, virtuelni prototip itd. moderni mali momci koji u fazi dizajna rješavaju problem kako da dobijemo ono što smo planirali.
Kako možemo brzo biti sigurni da je naš sistem upravo ono što dizajniramo, hoće li naš dizajn letjeti ili plutati? A ako leti, koliko visoko? A ako pluta, koliko duboko?
Ovaj članak govori o automatizaciji provjere usklađenosti sa zahtjevima tehničke zgrade pri kreiranju dinamičkih modela tehničkih sistema. Kao primjer, pogledajmo element tehničke specifikacije za sistem vazdušnog hlađenja aviona.
Razmatramo one zahtjeve koji se mogu numerički izraziti i matematički provjeriti na osnovu specifičnog proračunskog modela. Jasno je da je to samo dio općih zahtjeva za svaki tehnički sistem, ali upravo na njihovu provjeru trošimo vrijeme, živce i novac na kreiranje dinamičkih modela objekta.
Prilikom opisivanja tehničkih zahtjeva u obliku dokumenta može se izdvojiti nekoliko vrsta različitih zahtjeva, od kojih svaki zahtijeva različite pristupe za formiranje automatske provjere ispunjenosti zahtjeva.
Na primjer, razmotrite ovaj mali, ali realističan skup zahtjeva:
- Temperatura atmosferskog vazduha na ulazu u sistem za prečišćavanje vode:
na parkingu - od minus 35 do 35 ºS,
u letu - od minus 35 do 39 ºS. - Statički pritisak atmosferskog vazduha u letu je od 700 do 1013 GPa (od 526 do 760 mm Hg).
- Ukupni vazdušni pritisak na ulazu u SVO usisnik vazduha u letu je od 754 do 1200 GPa (od 566 do 1050 mm Hg).
- Temperatura rashladnog vazduha:
na parkingu - ne više od 27 ºS, za tehničke blokove - ne više od 29 ºS,
u letu - ne više od 25 ºS, za tehničke blokove - ne više od 27 ºS. - Protok vazduha za hlađenje:
kada je parkiran - najmanje 708 kg/h,
u letu - ne manje od 660 kg/h. - Temperatura zraka u odjeljcima za instrumente nije veća od 60 ºS.
- Količina fine slobodne vlage u vazduhu za hlađenje nije veća od 2 g/kg suvog vazduha.
Čak i unutar ovog ograničenog skupa zahtjeva, postoje najmanje dvije kategorije s kojima se u sistemu treba drugačije rukovati:
- zahtjevi za uslove rada sistema (klauzule 1-3);
- parametarski zahtjevi za sistem (klauzule 3-7).
Uslovi rada sistema
Eksterni uslovi za sistem koji se razvija tokom modeliranja mogu se specificirati kao granični uslovi ili kao rezultat rada opšteg sistema.
U dinamičkoj simulaciji, potrebno je osigurati da su navedeni uvjeti rada obuhvaćeni procesom simulacije.
Parametarski sistemski zahtjevi
Ovi zahtjevi su parametri koje obezbjeđuje sam sistem. Tokom procesa modeliranja, ove parametre možemo dobiti kao rezultate proračuna i osigurati da su zahtjevi ispunjeni u svakom konkretnom proračunu.
Identifikacija i kodiranje zahtjeva
Radi lakšeg rada sa zahtjevima, postojeći standardi preporučuju dodjeljivanje identifikatora svakom zahtjevu. Prilikom dodjeljivanja identifikatora, vrlo je poželjno koristiti objedinjeni sistem kodiranja.
Šifra zahtjeva može biti jednostavno broj koji predstavlja broj narudžbe zahtjeva ili može sadržavati kod za vrstu zahtjeva, kod za sistem ili jedinicu na koju se primjenjuje, kod parametra, kod lokacije i bilo šta drugo što inženjer može zamisliti. (pogledajte članak za korištenje kodiranja)
Tabela 1 daje jednostavan primjer kodiranja zahtjeva.
- šifra izvora zahtjeva R-zahtjevi TK;
- šifra vrsta zahtjeva E - zahtjevi - parametri okoline, odnosno radni uslovi
S - zahtjevi koje obezbjeđuje sistem; - statusni kod aviona 0 – bilo koji, G – parkiran, F – u letu;
- šifra tipa fizičkog parametra T – temperatura, P – pritisak, G – brzina protoka, vlažnost H;
- serijski broj zahtjeva.
| ID zahtjevi |
Opis | Parametar |
| REGT01 | Temperatura ambijentalnog vazduha na ulazu u sistem vodenog hlađenja: na parkingu - od minus 35ºS. do 35 ºS. | |
| REFT01 | Temperatura atmosferskog vazduha na ulazu u sistem protivvazdušne odbrane: u letu - od minus 35 ºS do 39 ºS. | |
| REFP01 | Statički atmosferski pritisak u letu je od 700 do 1013 hPa (od 526 do 760 mm Hg). | |
| REFP02 | Ukupni vazdušni pritisak na ulazu u SVO usisnik vazduha u letu je od 754 do 1200 hPa (od 566 do 1050 mm Hg). | |
| RSGT01 | Temperatura rashladnog zraka: kada je parkiran ne više od 27 ºS | |
| RSGT02 | Temperatura rashladnog vazduha: na parkingu, za tehničke jedinice ne više od 29 ºS | |
| RSFT01 | Temperatura rashladnog zraka u letu ne veća od 25 ºS | |
| RSFT02 | Temperatura rashladnog vazduha: u letu, za tehničke jedinice ne više od 27 ºS | |
| RSGG01 | Protok rashladnog zraka: kada je parkiran ne manji od 708 kg/h | |
| RSFG01 | Protok rashladnog zraka: u letu ne manji od 660 kg/h | |
| RS0T01 | Temperatura vazduha u odjeljcima za instrumente ne veća od 60 ºS | |
| RSH01 | Količina fine slobodne vlage u vazduhu za hlađenje nije veća od 2 g/kg suvog vazduha |
Dizajn sistema za verifikaciju zahtjeva.
Za svaki projektni zahtjev postoji algoritam za procjenu korespondencije projektnih parametara i parametara navedenih u zahtjevu. Uglavnom, svaki kontrolni sistem uvijek sadrži algoritme za provjeru zahtjeva jednostavno po defaultu. Čak ih i svaki regulator sadrži. Ako temperatura izađe izvan granica, klima uređaj se uključuje. Dakle, prva faza svake regulative je provjera da li parametri ispunjavaju zahtjeve.
A pošto je verifikacija algoritam, onda možemo koristiti iste alate i alate koje koristimo za kreiranje kontrolnih programa. Na primjer, SimInTech okruženje omogućava kreiranje projektnih paketa koji sadrže različite dijelove modela, koji se izvode u obliku zasebnih projekata (objektni model, model upravljačkog sistema, model okruženja, itd.).
Projekat verifikacije zahteva u ovom slučaju postaje isti projekat algoritma i povezan je sa paketom modela. A u načinu dinamičkog modeliranja vrši analizu usklađenosti sa zahtjevima tehničkih specifikacija.
Mogući primjer dizajna sistema prikazan je na slici 1.
Slika 1. Primjer dizajna projekta verifikacije.
Kao i za algoritme upravljanja, zahtjevi se mogu sastaviti kao skup listova. Za praktičnost rada sa algoritmima u okruženjima za strukturno modeliranje kao što su SimInTech, Simulink, AmeSim, koristi se mogućnost kreiranja struktura na više nivoa u obliku podmodela. Ova organizacija omogućava grupisanje različitih zahteva u skupove kako bi se pojednostavio rad sa nizom zahteva, kao što je urađeno za algoritme upravljanja (vidi sliku 2).
Slika 2. Hijerarhijska struktura modela verifikacije zahtjeva.
Na primjer, u slučaju koji se razmatra razlikuju se dvije grupe: zahtjevi za okruženje i zahtjevi direktno za sistem. Stoga se koristi struktura podataka na dva nivoa: dvije grupe, od kojih je svaka list algoritma.
Za povezivanje podataka sa modelom koristi se standardna šema za generisanje signalne baze podataka u kojoj se pohranjuju podaci za razmjenu između dijelova projekta.
Prilikom kreiranja i testiranja softvera, očitavanja senzora (analoga senzora realnog sistema) koje koristi upravljački sistem stavljaju se u ovu bazu podataka.
Za testni projekat, svi parametri izračunati u dinamičkom modelu mogu se pohraniti u istoj bazi podataka i tako koristiti za provjeru da li su zahtjevi ispunjeni.
U ovom slučaju, sam dinamički model se može izvršiti u bilo kojem sistemu matematičkog modeliranja ili čak u obliku izvršnog programa. Jedini uslov je prisustvo softverskih interfejsa za izdavanje podataka modeliranja u eksterno okruženje.
Slika 3. Povezivanje projekta verifikacije sa složenim modelom.
Primjer lista za verifikaciju osnovnih zahtjeva prikazan je na slici 4. Sa stanovišta programera, to je konvencionalni proračunski dijagram na kojem je grafički predstavljen algoritam za verifikaciju zahtjeva.
Slika 4. List za provjeru zahtjeva.
Glavni dijelovi kontrolnog lista su opisani na slici 5. Algoritam za provjeru je formiran slično projektnim dijagramima kontrolnih algoritama. Na desnoj strani nalazi se blok za čitanje signala iz baze podataka. Ovaj blok pristupa bazi signala tokom simulacije.
Primljeni signali se analiziraju da bi se izračunali uslovi verifikacije zahteva. U tom slučaju se vrši analiza visine radi utvrđivanja položaja aviona (da li je parkiran ili u letu). U tu svrhu možete koristiti druge signale i izračunate parametre modela.
Uslovi verifikacije i parametri koji se proveravaju prenose se u standardne verifikacione blokove, u kojima se ovi parametri analiziraju na usklađenost sa specificiranim zahtevima. Rezultati se bilježe u bazi podataka signala na način da se mogu koristiti za automatsko generiranje kontrolne liste.
Slika 5. Struktura obračunskog lista za verifikaciju zahtjeva.
Parametri koji se testiraju ne koriste nužno signale sadržane u bazi podataka, koji su kontrolirani parametrima izračunatim tokom procesa simulacije. Ništa nas ne sprečava da izvršimo dodatne proračune u okviru zahteva nacrta, kao što izračunavamo uslove verifikacije.
Na primjer, ovaj zahtjev:
Broj aktiviranja sistema korekcije tokom leta do cilja ne bi trebalo da prelazi 5, a ukupno vreme rada sistema korekcije ne bi trebalo da prelazi 30 sekundi.
U ovom slučaju, algoritam za suprotstavljanje broja pokretanja i ukupnog vremena rada dodaje se u dizajn dijagram zahtjeva.
Blok verifikacije tipičnih zahtjeva.
Svaki okvir za potvrdu standardnog zahtjeva dizajniran je da izračuna ispunjenost zahtjeva određenog tipa. Na primjer, ekološki zahtjevi uključuju raspon radnih temperatura okoline kada se parkirate iu letu. Ovaj blok mora primiti temperaturu zraka u modelu kao parametar i odrediti da li ovaj parametar pokriva specificirani temperaturni raspon./p>
Blok sadrži dva ulazna porta, param i uslov.
Prvi se unosi parametrom koji se provjerava. U ovom slučaju, „Spoljna temperatura“.
Na drugi port se dostavlja Boolean varijabla - uslov za izvođenje provjere.
Ako se na drugom ulazu primi TRUE (1), tada blok izvodi proračun provjere zahtjeva.
Ako drugi ulaz dobije FALSE (0), tada uslovi testiranja nisu ispunjeni. Ovo je neophodno kako bi se uslovi proračuna mogli uzeti u obzir. U našem slučaju, ovaj ulaz se koristi za omogućavanje ili onemogućavanje provjere ovisno o stanju modela. Ako je vazduhoplov u toku simulacije na zemlji, onda se ne proveravaju zahtevi koji se odnose na let, i obrnuto – ako je letelica u letu, onda se ne proveravaju zahtevi vezani za rad na stajalištu.
Ovaj ulaz se također može koristiti prilikom postavljanja modela, na primjer u početnoj fazi proračuna. Kada se model dovede u potrebno stanje, blokovi za provjeru su onemogućeni, ali čim sistem dostigne traženi način rada, blokovi za provjeru se uključuju.
Parametri ovog bloka su:
- granični uslovi: gornje (UpLimit) i donje (DownLimit) granice opsega koje se moraju provjeriti;
- potrebno vrijeme izlaganja sistema na graničnim rasponima (TimeInterval) u sekundama;
- ID zahtjeva ReqName;
- dopuštenost prekoračenja opsega Out_range je Boolean varijabla koja određuje da li vrijednost koja prelazi provjereni raspon predstavlja kršenje zahtjeva.
U nekim slučajevima, izlaz testne vrijednosti ukazuje da sistem ima određenu marginu i da možda radi izvan svog radnog raspona. U drugim slučajevima, izlaz znači da sistem nije u stanju da zadrži zadate vrednosti unutar opsega.
Slika 6. Tipični blok za provjeru svojstava u dijagramu i njegovi parametri.
Kao rezultat izračunavanja ovog bloka, na izlazu se formira varijabla Rezultat, koja uzima sljedeće vrijednosti:
- 0 – rNema, vrijednost nije definirana;
- 1 – rGotovo, uslov je ispunjen;
- 2 – rGreška, zahtjev nije ispunjen.
Slika bloka sadrži:
- tekst identifikatora;
- Digitalni prikazi parametara granica mjerenja;
- identifikator boje statusa parametra.
Unutar bloka može postojati prilično složen logički sklop zaključivanja.
Na primjer, za provjeru opsega radne temperature jedinice prikazanog na slici 6, unutrašnji krug je prikazan na slici 7.
Slika 7. Interni dijagram jedinice za određivanje temperaturnog opsega.
Unutar bloka kola se koriste svojstva specificirana u parametrima bloka.
Pored analize usklađenosti sa zahtjevima, interni dijagram bloka sadrži graf neophodan za prikaz rezultata simulacije. Ovaj grafikon se može koristiti i za pregled tokom izračunavanja i za analizu rezultata nakon proračuna.
Rezultati proračuna se prenose na izlaz bloka i istovremeno se bilježe u opći izvještaj koji se kreira na osnovu rezultata za cijeli projekat. (vidi sliku 8)
Primjer izvještaja kreiranog na osnovu rezultata simulacije je html datoteka kreirana prema datom formatu. Format se može proizvoljno konfigurirati na format koji je prihvatila određena organizacija.
Unutar bloka kola se koriste svojstva specificirana u parametrima bloka.
Pored analize usklađenosti sa zahtjevima, interni dijagram bloka sadrži graf neophodan za prikaz rezultata simulacije. Ovaj grafikon se može koristiti i za pregled tokom izračunavanja i za analizu rezultata nakon proračuna.
Rezultati proračuna se prenose na izlaz bloka i istovremeno se bilježe u opći izvještaj koji se kreira na osnovu rezultata za cijeli projekat. (vidi sliku 8)
Primjer izvještaja kreiranog na osnovu rezultata simulacije je html datoteka kreirana prema datom formatu. Format se može proizvoljno konfigurirati na format koji je prihvatila određena organizacija.
Slika 8. Primjer datoteke izvještaja na osnovu rezultata simulacije.
U ovom primjeru, obrazac izvještaja je konfigurisan direktno u svojstvima projekta, a format u tabeli je postavljen kao globalni projektni signali. U ovom slučaju, SimInTech sam rješava problem podešavanja izvještaja, a blok za upisivanje rezultata u datoteku koristi ove linije za pisanje u datoteku izvještaja.
Slika 9. Postavljanje formata izvještaja u globalnim projektnim signalima
Korištenje baze podataka signala za zahtjeve.
Za automatizaciju rada sa postavkama svojstava, kreira se standardna struktura u bazi podataka signala za svaki tipični blok. (vidi sliku 10)
Slika 10. Primjer strukture bloka za provjeru zahtjeva u bazi podataka signala.
Baza podataka signala pruža:
- Pohranjivanje svih potrebnih parametara sistemskih zahtjeva.
- Pogodan pregled postojećih zahtjeva projekta prema specificiranim parametrima i trenutnim rezultatima modeliranja.
- Postavljanje jednog bloka ili grupe blokova pomoću skriptirajućeg programskog jezika. Promjene u bazi podataka signala dovode do promjena vrijednosti svojstava bloka na dijagramu.
- Pohranjivanje tekstualnih opisa, veza do stavki tehničkih specifikacija ili identifikatora u sistemu upravljanja zahtjevima.
Strukture baze podataka signala za zahtjeve mogu se lako konfigurirati za rad sa sistemom upravljanja zahtjevima treće strane.Opšti dijagram interakcije sa sistemima upravljanja zahtjevima je predstavljen na slici 11.
Slika 11. Dijagram interakcije sa sistemom upravljanja zahtjevima.
Redoslijed interakcije između SimInTech test projekta i sistema kontrole zahtjeva je sljedeći:
- Projektni zadaci su raščlanjeni na zahtjeve.
- Identifikovani su zahtjevi tehničkih specifikacija koji se mogu provjeriti matematičkim modeliranjem tehničkih procesa.
- Atributi odabranih zahtjeva se prenose u SimInTech bazu podataka signala u strukturi standardnih blokova (na primjer, maksimalna i minimalna temperatura).
- Tokom procesa proračuna, podaci o strukturi se prenose u blok projektne dijagrame, vrši se analiza i rezultati se pohranjuju u bazu podataka signala.
- Kada je proračun završen, rezultati analize se prenose u sistem upravljanja zahtjevima.
Koraci zahtjeva od 3 do 5 mogu se ponoviti tokom procesa dizajna kada dođe do promjena u dizajnu i/ili zahtjevima i uticaj promjena treba ponovo testirati.
Zaključci.
- Stvoreni prototip sistema omogućava značajno smanjenje vremena analize postojećih modela radi usaglašenosti sa zahtjevima tehničkih specifikacija.
- Predložena tehnologija testiranja koristi već postojeće dinamičke modele i može se koristiti čak i za sve dinamičke modele, uključujući i one koji se ne izvode u SimInTech okruženju.
- Korišćenje paketne organizacije podataka omogućava vam da kreirate pakete za verifikaciju zahteva paralelno sa razvojem modela, ili čak da koristite ove pakete kao tehničke specifikacije za razvoj modela.
- Tehnologija se može integrirati sa postojećim sistemima upravljanja zahtjevima bez značajnih troškova.
Za one koji pročitaju do kraja,
izvor: www.habr.com