Nastavak teme , pogledajmo problem matematičkog modeliranja s druge strane. Nakon što smo se uvjerili da model odgovara domaćoj životnoj istini, možemo odgovoriti na glavno pitanje: “Što, zapravo, imamo ovdje?” Prilikom izrade modela tehničkog objekta obično želimo biti sigurni da će taj objekt ispuniti naša očekivanja. U tu svrhu provode se dinamički proračuni procesa i rezultat se uspoređuje sa zahtjevima. Ovo je digitalni blizanac, virtualni prototip itd. modni mališani koji u fazi dizajna rješavaju problem kako osigurati da dobijemo ono što smo planirali.
Kako se možemo brzo uvjeriti da je naš sustav upravo ono što dizajniramo, hoće li naš dizajn letjeti ili lebdjeti? I ako leti, koliko visoko? I ako pluta, koliko duboko?
U ovom se članku govori o automatizaciji provjere usklađenosti sa zahtjevima tehničke zgrade pri izradi dinamičkih modela tehničkih sustava. Kao primjer, pogledajmo element tehničke specifikacije za sustav zračnog hlađenja zrakoplova.
Razmatramo one zahtjeve koji se mogu numerički izraziti i matematički verificirati na temelju određenog proračunskog modela. Jasno je da je to samo dio općih zahtjeva za bilo koji tehnički sustav, ali upravo na njihovu provjeru trošimo vrijeme, živce i novac za izradu dinamičkih modela objekta.
Pri opisivanju tehničkih zahtjeva u obliku dokumenta može se razlikovati nekoliko vrsta različitih zahtjeva, od kojih svaki zahtijeva različite pristupe za formiranje automatske provjere ispunjenja zahtjeva.
Na primjer, razmotrite ovaj mali, ali realan skup zahtjeva:
- Temperatura atmosferskog zraka na ulazu u sustav za pročišćavanje vode:
na parkiralištu - od minus 35 do 35 ºS,
u letu - od minus 35 do 39 ºS. - Statički tlak atmosferskog zraka u letu je od 700 do 1013 GPa (od 526 do 760 mm Hg).
- Ukupni tlak zraka na ulazu u SVO usisnik zraka u letu je od 754 do 1200 GPa (od 566 do 1050 mm Hg).
- Temperatura zraka za hlađenje:
na parkiralištu - 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 zraka 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 rashladnom zraku nije veća od 2 g/kg suhog zraka.
Čak i unutar ovog ograničenog skupa zahtjeva, postoje najmanje dvije kategorije s kojima se u sustavu treba drugačije postupati:
- zahtjevi za radne uvjete sustava (točke 1-3);
- parametarski zahtjevi za sustav (točke 3-7).
Zahtjevi za uvjete rada sustava
Vanjski uvjeti za sustav koji se razvija tijekom modeliranja mogu se specificirati kao rubni uvjeti ili kao rezultat rada općeg sustava.
U dinamičkoj simulaciji potrebno je osigurati da navedeni radni uvjeti budu obuhvaćeni procesom simulacije.
Zahtjevi parametarskog sustava
Ovi zahtjevi su parametri koje osigurava sam sustav. Tijekom procesa modeliranja te parametre možemo dobiti kao rezultate proračuna i osigurati da su zahtjevi zadovoljeni 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 dodjele identifikatora vrlo je poželjno koristiti jedinstveni sustav kodiranja.
Šifra zahtjeva može biti jednostavno broj koji predstavlja redni broj zahtjeva ili može sadržavati šifru za vrstu zahtjeva, šifru za sustav ili jedinicu na koju se odnosi, šifru parametra, šifru lokacije i bilo što drugo što inženjer može zamisliti. (pogledajte članak za korištenje kodiranja)
Tablica 1 daje jednostavan primjer kodiranja zahtjeva.
- šifra izvora zahtjeva R-zahtjevi TK;
- šifra tip zahtjeva E - zahtjevi - parametri okoliša, odnosno radni uvjeti
S - zahtjevi koje osigurava sustav; - kod statusa zrakoplova 0 – bilo koji, G – parkiran, F – u letu;
- kod vrste fizičkog parametra T – temperatura, P – tlak, G – brzina protoka, vlažnost H;
- serijski broj zahtjeva.
| ID Zahtjevi |
Opis | Parametar |
| REGT01 | Temperatura okolnog zraka na ulazu u sustav vodenog hlađenja: na parkiralištu - od minus 35ºS. do 35 ºS. | |
| REFT01 | Temperatura atmosferskog zraka na ulazu u sustav protuzračne obrane: u letu - od minus 35 ºS do 39 ºS. | |
| REFP01 | Statički atmosferski tlak zraka u letu je od 700 do 1013 hPa (od 526 do 760 mm Hg). | |
| REFP02 | Ukupni tlak zraka na ulazu u SVO usisnik zraka u letu je od 754 do 1200 hPa (od 566 do 1050 mm Hg). | |
| RSGT01 | Temperatura zraka za hlađenje: kada je parkirano ne više od 27 ºS | |
| RSGT02 | Temperatura zraka za hlađenje: na parkiralištu, za tehničke jedinice ne više od 29 ºS | |
| RSFT01 | Temperatura zraka za hlađenje u letu ne prelazi 25 ºS | |
| RSFT02 | Temperatura zraka za hlađenje: u letu, za tehničke jedinice ne više od 27 ºS | |
| RSGG01 | Protok zraka za hlađenje: kada je parkiran ne manje od 708 kg/h | |
| RSFG01 | Protok zraka za hlađenje: u letu ne manje od 660 kg/h | |
| RS0T01 | Temperatura zraka u odjeljcima za instrumente nije veća od 60 ºS | |
| RSH01 | Količina fine slobodne vlage u rashladnom zraku nije veća od 2 g/kg suhog zraka |
Dizajn sustava za provjeru zahtjeva.
Za svaki projektni zahtjev postoji algoritam za procjenu podudarnosti projektnih parametara i parametara navedenih u zahtjevu. Uglavnom, bilo koji kontrolni sustav uvijek sadrži algoritme za provjeru zahtjeva jednostavno prema zadanim postavkama. Čak ih i svaki regulator sadrži. Ako temperatura prijeđe granice, uključuje se klima uređaj. Stoga je prva faza svake regulacije provjera ispunjavaju li parametri zahtjeve.
A budući da je provjera algoritam, tada možemo koristiti iste alate i alate koje koristimo za izradu kontrolnih programa. Na primjer, okruženje SimInTech omogućuje kreiranje projektnih paketa koji sadrže različite dijelove modela, izvedene u obliku zasebnih projekata (model objekta, model upravljačkog sustava, model okoline itd.).
Projekt provjere zahtjeva u ovom slučaju postaje isti projekt algoritma i povezan je s paketom modela. A u načinu dinamičkog modeliranja provodi analizu sukladnosti sa zahtjevima tehničkih specifikacija.
Mogući primjer dizajna sustava prikazan je na slici 1.
Slika 1. Primjer dizajna projekta verifikacije.
Baš kao i za upravljačke algoritme, zahtjevi se mogu sastaviti kao skup listova. Radi praktičnosti rada s algoritmima u okruženjima strukturnog modeliranja kao što su SimInTech, Simulink, AmeSim, koristi se mogućnost stvaranja struktura na više razina u obliku podmodela. Ova organizacija omogućuje grupiranje različitih zahtjeva u skupove kako bi se pojednostavio rad s nizom zahtjeva, kao što je učinjeno za algoritme upravljanja (vidi sliku 2).
Slika 2. Hijerarhijska struktura modela provjere zahtjeva.
Na primjer, u slučaju koji se razmatra, razlikuju se dvije skupine: zahtjevi za okolinu i zahtjevi izravno za sustav. Stoga se koristi dvorazinska struktura podataka: dvije grupe od kojih je svaka list algoritma.
Za povezivanje podataka s modelom koristi se standardna shema za generiranje signalne baze podataka koja pohranjuje podatke za razmjenu između dijelova projekta.
Prilikom izrade i testiranja softvera u ovu bazu podataka stavljaju se očitanja senzora (analoga senzora stvarnog sustava) koje koristi upravljački sustav.
Za probni projekt, svi parametri izračunati u dinamičkom modelu mogu se pohraniti u istu bazu podataka i na taj način koristiti za provjeru jesu li zahtjevi ispunjeni.
U tom slučaju, sam dinamički model može se izvršiti u bilo kojem sustavu za matematičko modeliranje ili čak u obliku izvršnog programa. Jedini uvjet je prisutnost softverskih sučelja za izdavanje podataka modeliranja vanjskom okruženju.
Slika 3. Povezivanje projekta verifikacije sa složenim modelom.
Primjer lista za provjeru osnovnih zahtjeva prikazan je na slici 4. Sa stajališta programera, to je konvencionalni proračunski dijagram na kojem je algoritam za provjeru zahtjeva grafički prikazan.
Slika 4. List za provjeru zahtjeva.
Glavni dijelovi lista za provjeru opisani su na slici 5. Algoritam za provjeru formiran je slično dijagramima dizajna kontrolnih algoritama. S desne strane nalazi se blok za čitanje signala iz baze podataka. Ovaj blok pristupa bazi podataka signala tijekom simulacije.
Primljeni signali se analiziraju kako bi se izračunali uvjeti provjere zahtjeva. U tom slučaju radi se analiza visine kako bi se odredila pozicija zrakoplova (da li je parkiran ili leti). U tu svrhu možete koristiti druge signale i izračunate parametre modela.
Uvjeti provjere i parametri koji se provjeravaju prenose se u standardne blokove provjere, u kojima se ti parametri analiziraju na usklađenost sa zadanim zahtjevima. Rezultati se bilježe u bazi podataka signala na takav način da se mogu koristiti za automatsko generiranje kontrolne liste.
Slika 5. Struktura obrasca za provjeru zahtjeva.
Parametri koji se testiraju ne moraju nužno koristiti signale sadržane u bazi podataka, koji su kontrolirani parametrima izračunatim tijekom procesa simulacije. Ništa nas ne sprječava da izvršimo dodatne izračune u okviru zahtjeva nacrta, baš kao što izračunavamo uvjete provjere.
Na primjer, ovaj zahtjev:
Broj aktiviranja sustava korekcije tijekom leta do cilja ne smije biti veći od 5, a ukupno vrijeme rada sustava korekcije ne smije biti veće od 30 sekundi.
U ovom slučaju, algoritam za suzbijanje broja pokretanja i ukupnog vremena rada dodaje se u projektni dijagram zahtjeva.
Tipični blok provjere zahtjeva.
Svaki okvir za potvrdu standardnog zahtjeva dizajniran je za izračunavanje ispunjenja zahtjeva određene vrste. Na primjer, ekološki zahtjevi uključuju niz radnih temperatura okoline kada je vozilo parkirano i tijekom leta. Ovaj blok mora primiti temperaturu zraka u modelu kao parametar i odrediti pokriva li taj parametar navedeni temperaturni raspon./p>
Blok sadrži dva ulazna porta, param i condition.
Prvi se napaja parametrom koji se provjerava. U ovom slučaju, "Vanjska temperatura".
Booleova varijabla se isporučuje drugom portu - uvjet za izvođenje provjere.
Ako se na drugom ulazu primi TRUE (1), tada blok izvodi izračun provjere zahtjeva.
Ako drugi unos dobije FALSE (0), tada uvjeti ispitivanja nisu ispunjeni. To je neophodno kako bi se mogli uzeti u obzir uvjeti izračuna. U našem slučaju, ovaj unos se koristi za omogućavanje ili onemogućavanje provjere ovisno o stanju modela. Ako je zrakoplov tijekom simulacije na zemlji, tada se ne provjeravaju zahtjevi koji se odnose na let, i obrnuto - ako je zrakoplov u letu, tada se ne provjeravaju zahtjevi koji se odnose na rad u stajanju.
Ovaj se unos također može koristiti prilikom postavljanja modela, na primjer u početnoj fazi izračuna. Kada se model dovede u traženo stanje, blokovi za provjeru su onemogućeni, ali čim sustav dođe u željeni način rada, blokovi za provjeru se uključuju.
Parametri ovog bloka su:
- rubni uvjeti: gornje (UpLimit) i donje (DownLimit) granice raspona koje se moraju provjeriti;
- potrebno vrijeme izloženosti sustava na graničnim rasponima (TimeInterval) u sekundama;
- ID zahtjeva ReqName;
- dopuštenost prekoračenja raspona Out_range je Booleova varijabla koja određuje je li vrijednost koja prelazi označeni raspon kršenje zahtjeva.
U nekim slučajevima izlaz testne vrijednosti pokazuje da sustav ima određenu rezervu i da možda radi izvan svog radnog raspona. U drugim slučajevima, izlaz znači da sustav ne može zadržati zadane vrijednosti unutar raspona.
Slika 6. Tipični blok provjere svojstava u dijagramu i njegovi parametri.
Kao rezultat izračuna ovog bloka, na izlazu se formira varijabla Rezultat koja ima sljedeće vrijednosti:
- 0 – rNišta, vrijednost nije definirana;
- 1 – rDone, zahtjev je ispunjen;
- 2 – rFault, zahtjev nije ispunjen.
Slika bloka sadrži:
- tekst identifikatora;
- digitalni prikazi parametara mjernih granica;
- identifikator boje statusa parametra.
Unutar bloka može postojati prilično složen sklop logičkog zaključivanja.
Na primjer, za provjeru raspona radne temperature jedinice prikazane na slici 6, unutarnji krug prikazan je na slici 7.
Slika 7. Unutarnji dijagram jedinice za određivanje raspona temperature.
Unutar bloka sklopa koriste se svojstva navedena u parametrima bloka.
Osim analize usklađenosti sa zahtjevima, interni dijagram bloka sadrži graf potreban za prikaz rezultata simulacije. Ovaj se grafikon može koristiti i za pregled tijekom izračuna i za analizu rezultata nakon izračuna.
Rezultati izračuna se prenose na izlaz bloka i istovremeno se bilježe u datoteku općeg izvješća, koja se kreira na temelju rezultata za cijeli projekt. (vidi sliku 8)
Primjer izvješća kreiranog na temelju rezultata simulacije je html datoteka kreirana prema zadanom formatu. Format se može proizvoljno konfigurirati na format koji prihvaća određena organizacija.
Unutar bloka sklopa koriste se svojstva navedena u parametrima bloka.
Osim analize usklađenosti sa zahtjevima, interni dijagram bloka sadrži graf potreban za prikaz rezultata simulacije. Ovaj se grafikon može koristiti i za pregled tijekom izračuna i za analizu rezultata nakon izračuna.
Rezultati izračuna se prenose na izlaz bloka i istovremeno se bilježe u datoteku općeg izvješća, koja se kreira na temelju rezultata za cijeli projekt. (vidi sliku 8)
Primjer izvješća kreiranog na temelju rezultata simulacije je html datoteka kreirana prema zadanom formatu. Format se može proizvoljno konfigurirati na format koji prihvaća određena organizacija.
Slika 8. Primjer datoteke izvješća na temelju rezultata simulacije.
U ovom primjeru, obrazac izvješća je konfiguriran izravno u svojstvima projekta, a format u tablici postavljen je kao globalni signali projekta. U ovom slučaju SimInTech sam rješava problem postavljanja izvješća, a blok za upisivanje rezultata u datoteku koristi te retke za upisivanje u datoteku izvješća.
Slika 9. Postavljanje formata izvješća u signalima globalnog projekta
Korištenje baze podataka signala za potrebe.
Za automatizaciju rada s postavkama svojstava, standardna struktura se stvara u bazi podataka signala za svaki tipični blok. (vidi sliku 10)
Slika 10. Primjer strukture bloka provjere zahtjeva u bazi podataka signala.
Baza signala pruža:
- Pohranjivanje svih potrebnih parametara sistemskih zahtjeva.
- Pogodan pregled postojećih projektnih zahtjeva iz specificiranih parametara i trenutnih rezultata modeliranja.
- Postavljanje jednog bloka ili grupe blokova pomoću skriptnog programskog jezika. Promjene u bazi podataka signala dovode do promjena u vrijednostima svojstava bloka u dijagramu.
- Pohranjivanje tekstualnih opisa, poveznica na stavke tehničkih specifikacija ili identifikatora u sustavu upravljanja zahtjevima.
Strukture baze podataka signala za zahtjeve mogu se jednostavno konfigurirati za rad sa sustavom upravljanja zahtjevima treće strane. Opći dijagram interakcije sa sustavima upravljanja zahtjevima prikazan je na slici 11.
Slika 11. Dijagram interakcije sa sustavom upravljanja zahtjevima.
Redoslijed interakcije između SimInTech test projekta i sustava kontrole zahtjeva je sljedeći:
- Projektni zadatak raščlanjen je na zahtjeve.
- Identificirani su zahtjevi tehničke specifikacije koji se mogu verificirati matematičkim modeliranjem tehničkih procesa.
- Atributi odabranih zahtjeva prenose se u bazu signala SimInTech u strukturi standardnih blokova (primjerice maksimalna i minimalna temperatura).
- Tijekom procesa proračuna podaci o strukturi se prenose u dijagrame blok dizajna, provodi se analiza i rezultati se pohranjuju u bazu podataka signala.
- Nakon završetka izračuna, rezultati analize se prenose u sustav upravljanja zahtjevima.
Koraci zahtjeva od 3 do 5 mogu se ponoviti tijekom procesa projektiranja kada dođe do promjena u dizajnu i/ili zahtjevima i kada je potrebno ponovno ispitati utjecaj promjena.
Zaključci.
- Izrađeni prototip sustava omogućuje značajno smanjenje vremena analize postojećih modela za usklađenost 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 one koji se ne izvode u SimInTech okruženju.
- Korištenje organizacije skupnih podataka omogućuje vam stvaranje paketa za provjeru zahtjeva paralelno s razvojem modela ili čak korištenje ovih paketa kao tehničkih specifikacija za razvoj modela.
- Tehnologija se može integrirati s postojećim sustavima upravljanja zahtjevima bez značajnih troškova.
Za one koji čitaju do kraja,
Izvor: www.habr.com