Tęsiant temą , pažvelkime į matematinio modeliavimo problemą iš kitos pusės. Įsitikinus, kad modelis atitinka sugalvotą gyvenimo tiesą, galime atsakyti į pagrindinį klausimą: „ką mes čia tiksliai turime? Kurdami techninio objekto modelį dažniausiai norime įsitikinti, kad šis objektas pateisins mūsų lūkesčius. Tuo tikslu atliekami dinaminiai procesų skaičiavimai ir rezultatas lyginamas su reikalavimais. Tai skaitmeninis dvynys, virtualus prototipas ir kt. madingi vaikinai, kurie projektavimo etape sprendžia problemą, kaip užtikrinti, kad gautume tai, ką planavome.
Kaip galime greitai įsitikinti, kad mūsų sistema yra būtent tokia, kokią mes projektuojame, ar mūsų dizainas skris ar plauks? O jei skrenda, kokio aukščio? O jei plūduriuoja, kokio gylio?
Šiame straipsnyje aptariamas techninio pastato reikalavimų atitikties patikros automatizavimas kuriant dinaminius techninių sistemų modelius. Kaip pavyzdį pažvelkime į orlaivio oro aušinimo sistemos techninės specifikacijos elementą.
Atsižvelgiame į tuos reikalavimus, kurie gali būti išreikšti skaitiniais ir matematiškai patikrinti remiantis konkrečiu skaičiavimo modeliu. Akivaizdu, kad tai tik dalis bendrųjų reikalavimų bet kuriai techninei sistemai, tačiau būtent juos tikrinant skiriame laiko, nervų ir pinigų dinaminiams objekto modeliams kurti.
Techninius reikalavimus aprašant dokumento forma, galima išskirti keletą skirtingų reikalavimų tipų, kurių kiekvienas reikalauja skirtingų požiūrių formuojant automatinį reikalavimų vykdymo patikrinimą.
Pavyzdžiui, apsvarstykite šį nedidelį, bet realų reikalavimų rinkinį:
- Atmosferos oro temperatūra prie įėjimo į vandens ruošimo sistemą:
automobilių stovėjimo aikštelėje - nuo minus 35 iki 35 ºС,
skrydžio metu - nuo minus 35 iki 39 ºС. - Statinis atmosferos oro slėgis skrydžio metu yra nuo 700 iki 1013 GPa (nuo 526 iki 760 mm Hg).
- Bendras oro slėgis prie įėjimo į SVO oro įsiurbimo angą skrydžio metu yra nuo 754 iki 1200 GPa (nuo 566 iki 1050 mm Hg).
- Aušinimo oro temperatūra:
automobilių stovėjimo aikštelėje - ne daugiau kaip 27 ºС, techniniuose blokuose - ne daugiau kaip 29 ºС,
skrydžio metu - ne daugiau kaip 25 ºС, techniniams blokams - ne daugiau kaip 27 ºС. - Aušinimo oro srautas:
stovint – ne mažiau 708 kg/val.
skrydžio metu – ne mažiau 660 kg/val. - Oro temperatūra prietaisų skyriuose yra ne aukštesnė kaip 60 ºС.
- Smulkios laisvos drėgmės kiekis aušinamame ore yra ne didesnis kaip 2 g/kg sauso oro.
Netgi pagal šį ribotą reikalavimų rinkinį yra bent dvi kategorijos, kurias sistemoje reikia tvarkyti skirtingai:
- sistemos veikimo sąlygų reikalavimai (1-3 punktai);
- parametriniai reikalavimai sistemai (3-7 punktai).
Sistemos veikimo sąlygų reikalavimai
Modeliavimo metu kuriamos sistemos išorinės sąlygos gali būti nurodytos kaip ribinės sąlygos arba kaip bendros sistemos veikimo rezultatas.
Dinaminio modeliavimo metu būtina užtikrinti, kad modeliavimo procesas apimtų nurodytas veikimo sąlygas.
Parametrinės sistemos reikalavimai
Šie reikalavimai yra parametrai, kuriuos pateikia pati sistema. Modeliavimo proceso metu šiuos parametrus galime gauti kaip skaičiavimo rezultatus ir įsitikinti, kad kiekviename konkrečiame skaičiavime yra laikomasi reikalavimų.
Reikalavimai identifikavimui ir kodavimui
Kad būtų lengviau dirbti su reikalavimais, esami standartai rekomenduoja kiekvienam reikalavimui priskirti identifikatorių. Priskiriant identifikatorius, labai pageidautina naudoti vieningą kodavimo sistemą.
Reikalavimo kodas gali būti tiesiog skaičius, nurodantis reikalavimo užsakymo numerį, arba jame gali būti reikalavimo tipo kodas, sistemos arba įrenginio, kuriam jis taikomas, kodas, parametro kodas, vietos kodas ir visa kita, ką gali įsivaizduoti inžinierius. (žr. straipsnį apie kodavimo naudojimą)
1 lentelėje pateikiamas paprastas reikalavimų kodavimo pavyzdys.
- reikalavimų šaltinio kodas R-reikalavimai TK;
- kodas reikalavimų tipas E - reikalavimai - aplinkos parametrai, arba eksploatavimo sąlygos
S – sistemos pateikti reikalavimai; - orlaivio būsenos kodas 0 – bet koks, G – stovėjęs, F – skrendantis;
- fizikinio parametro tipo kodas T – temperatūra, P – slėgis, G – srautas, drėgmė H;
- reikalavimo serijos numeris.
| ID Reikalavimai |
aprašymas | Parametras |
| REGT01 | Aplinkos oro temperatūra prie įėjimo į vandens aušinimo sistemą: automobilių stovėjimo aikštelėje - nuo minus 35ºС. iki 35ºС. | |
| REFT01 | Atmosferos oro temperatūra prie įėjimo į oro gynybos sistemą: skrydžio metu - nuo minus 35 ºС iki 39 ºС. | |
| REFP01 | Statinis atmosferos oro slėgis skrydžio metu yra nuo 700 iki 1013 hPa (nuo 526 iki 760 mm Hg). | |
| REFP02 | Bendras oro slėgis prie įėjimo į SVO oro įsiurbimo angą skrydžio metu yra nuo 754 iki 1200 hPa (nuo 566 iki 1050 mm Hg). | |
| RSGT01 | Aušinimo oro temperatūra: stovint ne aukštesnė kaip 27 ºС | |
| RSGT02 | Aušinimo oro temperatūra: automobilių stovėjimo aikštelėje, techniniams mazgams ne aukštesnė kaip 29 ºС | |
| RSFT01 | Aušinimo oro temperatūra skrydžio metu ne aukštesnė kaip 25 ºС | |
| RSFT02 | Aušinimo oro temperatūra: skrendant, techniniams mazgams ne aukštesnė kaip 27 ºС | |
| RSGG01 | Aušinimo oro srautas: stovint ne mažiau 708 kg/val | |
| RSFG01 | Aušinimo oro srautas: skrydžio metu ne mažesnis kaip 660 kg/val | |
| RS0T01 | Oro temperatūra prietaisų skyriuose ne aukštesnė kaip 60 ºС | |
| RSH01 | Smulkios laisvos drėgmės kiekis aušinamame ore yra ne didesnis kaip 2 g/kg sauso oro |
Reikalavimų patikros sistemos projektavimas.
Kiekvienam projektavimo reikalavimui yra sukurtas projektinių parametrų ir reikalavime nurodytų parametrų atitikimo įvertinimo algoritmas. Apskritai bet kurioje valdymo sistemoje pagal numatytuosius nustatymus visada yra reikalavimų tikrinimo algoritmai. Ir net bet kuriame reguliatoriuje jų yra. Jei temperatūra išeina už ribų, oro kondicionierius įsijungia. Taigi pirmasis bet kokio reguliavimo etapas – patikrinti, ar parametrai atitinka reikalavimus.
Ir kadangi patikrinimas yra algoritmas, galime naudoti tuos pačius įrankius ir įrankius, kuriuos naudojame kurdami valdymo programas. Pavyzdžiui, SimInTech aplinka leidžia kurti projektų paketus su įvairiomis modelio dalimis, vykdomus atskirų projektų pavidalu (objekto modelis, valdymo sistemos modelis, aplinkos modelis ir kt.).
Reikalavimų patikros projektas šiuo atveju tampa tuo pačiu algoritmo projektu ir yra prijungtas prie modelio paketo. O dinaminio modeliavimo režimu atlieka atitikimo techninių specifikacijų reikalavimams analizę.
Galimas sistemos projektavimo pavyzdys parodytas 1 paveiksle.
1 pav. Patikrinimo projekto pavyzdys.
Kaip ir valdymo algoritmams, reikalavimus galima sudaryti kaip lapų rinkinį. Darbo su algoritmais patogumui struktūrinio modeliavimo aplinkose, tokiose kaip SimInTech, Simulink, AmeSim, naudojama galimybė kurti kelių lygių struktūras submodelių pavidalu. Ši organizacija leidžia sugrupuoti įvairius reikalavimus į rinkinius, kad būtų supaprastintas darbas su daugybe reikalavimų, kaip tai daroma valdymo algoritmams (žr. 2 pav.).
2 pav. Reikalavimų patikros modelio hierarchinė struktūra.
Pavyzdžiui, nagrinėjamu atveju išskiriamos dvi grupės: reikalavimai aplinkai ir reikalavimai tiesiogiai sistemai. Todėl naudojama dviejų lygių duomenų struktūra: dvi grupės, kurių kiekviena yra algoritmo lapelis.
Duomenims prijungti prie modelio naudojama standartinė signalų duomenų bazės generavimo schema, kurioje saugomi duomenys, skirti keistis tarp projekto dalių.
Kuriant ir testuojant programinę įrangą, į šią duomenų bazę patalpinami valdymo sistemos naudojami jutiklių (realių sistemos jutiklių analogų) rodmenys.
Bandomojo projekto atveju bet kurie dinaminiame modelyje apskaičiuoti parametrai gali būti saugomi toje pačioje duomenų bazėje ir taip naudojami norint patikrinti, ar tenkinami reikalavimai.
Šiuo atveju pats dinaminis modelis gali būti vykdomas bet kurioje matematinio modeliavimo sistemoje ar net vykdomosios programos pavidalu. Vienintelis reikalavimas yra programinės įrangos sąsajų, skirtų modeliavimo duomenims perduoti į išorinę aplinką, buvimas.
3 pav. Patikrinimo projekto prijungimas prie kompleksinio modelio.
Pagrindinių reikalavimų patikros lapo pavyzdys pateiktas 4 pav. Kūrėjo požiūriu, tai įprastinė skaičiavimo diagrama, kurioje grafiškai pateikiamas reikalavimų tikrinimo algoritmas.
4 pav. Reikalavimų patikros lapas.
Pagrindinės patikros lapo dalys aprašytos 5 pav. Patikrinimo algoritmas suformuotas panašiai kaip valdymo algoritmų projektinės diagramos. Dešinėje pusėje yra blokas signalams nuskaityti iš duomenų bazės. Šis blokas modeliavimo metu pasiekia signalų duomenų bazę.
Gauti signalai analizuojami, siekiant apskaičiuoti reikalavimų patikrinimo sąlygas. Šiuo atveju atliekama aukščio analizė, siekiant nustatyti orlaivio padėtį (ar jis stovi, ar skrenda). Šiuo tikslu galite naudoti kitus signalus ir apskaičiuotus modelio parametrus.
Tikrinamos patikros sąlygos ir parametrai perkeliami į standartinius patikros blokus, kuriuose analizuojama šių parametrų atitiktis nurodytiems reikalavimams. Rezultatai įrašomi į signalų duomenų bazę taip, kad juos būtų galima naudoti automatiškai generuojant kontrolinį sąrašą.
5 pav. Reikalavimų patikros skaičiavimo lapo struktūra.
Testuojami parametrai nebūtinai naudoja duomenų bazėje esančius signalus, kurie valdomi modeliavimo proceso metu apskaičiuotais parametrais. Niekas netrukdo atlikti papildomų skaičiavimų pagal projekto reikalavimų rėmus, kaip ir skaičiuojame patikros sąlygas.
Pavyzdžiui, šis reikalavimas:
Korekcijos sistemos įjungimų skaičius skrydžio į taikinį metu neturi viršyti 5, o bendras korekcijos sistemos veikimo laikas neturi viršyti 30 sekundžių.
Tokiu atveju į reikalavimų projektinę schemą pridedamas paleidimų skaičiaus ir bendro veikimo laiko skaičiavimo algoritmas.
Tipinių reikalavimų tikrinimo blokas.
Kiekvienas standartinio reikalavimo žymės langelis skirtas tam tikro tipo reikalavimo įvykdymui apskaičiuoti. Pavyzdžiui, aplinkosaugos reikalavimai apima įvairią aplinkos darbinę temperatūrą stovint ir skrendant. Šis blokas turi gauti modelio oro temperatūrą kaip parametrą ir nustatyti, ar šis parametras apima nurodytą temperatūros diapazoną./p>
Bloke yra du įvesties prievadai, parametras ir sąlyga.
Pirmasis tiekiamas su tikrinamu parametru. Šiuo atveju „Išorinė temperatūra“.
Į antrąjį prievadą pateikiamas Būlio kintamasis – patikrinimo atlikimo sąlyga.
Jei antrajame įėjime gaunama TRUE (1), tada blokas atlieka reikalavimo patikros skaičiavimą.
Jei antroji įvestis gauna FALSE (0), tada bandymo sąlygos nėra tenkinamos. Tai būtina, kad būtų galima atsižvelgti į skaičiavimo sąlygas. Mūsų atveju ši įvestis naudojama patikrai įjungti arba išjungti, atsižvelgiant į modelio būseną. Jeigu simuliacijos metu orlaivis yra ant žemės, tuomet su skrydžiu susiję reikalavimai netikrinami, ir atvirkščiai – jei orlaivis skrenda, tuomet su eksploatavimu stende susiję reikalavimai netikri.
Ši įvestis taip pat gali būti naudojama nustatant modelį, pavyzdžiui, pradiniame skaičiavimo etape. Kai modelis perkeliamas į reikiamą būseną, tikrinimo blokai išjungiami, tačiau kai tik sistema pasiekia reikiamą darbo režimą, patikrinimo blokai įjungiami.
Šio bloko parametrai yra šie:
- ribinės sąlygos: viršutinės (UpLimit) ir apatinės (DownLimit) diapazono ribos, kurias būtina patikrinti;
- reikalinga sistemos ekspozicijos trukmė ribiniuose diapazonuose (TimeInterval) sekundėmis;
- Užklausos ID ReqName;
- leistinumas viršyti diapazoną Out_range yra Būlio kintamasis, kuris nustato, ar reikšmė, viršijanti patikrintą diapazoną, yra reikalavimo pažeidimas.
Kai kuriais atvejais bandymo vertės išvestis rodo, kad sistema turi tam tikrą atsargą ir gali veikti už savo veikimo diapazono ribų. Kitais atvejais išvestis reiškia, kad sistema negali išlaikyti nustatytų verčių diapazone.
6 pav. Tipiškas savybių tikrinimo blokas diagramoje ir jo parametrai.
Apskaičiavus šį bloką, išvestyje susidaro kintamasis Rezultatas, kuris įgauna šias reikšmes:
- 0 – rNėra, reikšmė neapibrėžta;
- 1 – rAtlikta, reikalavimas įvykdytas;
- 2 – rGedimas, reikalavimas neįvykdytas.
Bloko paveikslėlyje yra:
- identifikatoriaus tekstas;
- skaitmeniniai matavimo ribinių parametrų ekranai;
- parametro būsenos spalvos identifikatorius.
Bloko viduje gali būti gana sudėtinga loginių išvadų grandinė.
Pavyzdžiui, norint patikrinti įrenginio veikimo temperatūros diapazoną, parodytą 6 paveiksle, vidinė grandinė parodyta 7 paveiksle.
7 pav. Temperatūros diapazono nustatymo vieneto vidinė diagrama.
Grandinės bloko viduje naudojamos bloko parametruose nurodytos savybės.
Vidinėje bloko schemoje yra ne tik atitikties reikalavimams analizė, bet ir grafikas, reikalingas modeliavimo rezultatams atvaizduoti. Šis grafikas gali būti naudojamas tiek peržiūrai skaičiavimo metu, tiek rezultatams po skaičiavimo analizuoti.
Skaičiavimo rezultatai perduodami į bloko išvestį ir tuo pačiu metu įrašomi į bendrą ataskaitos failą, kuris sukuriamas pagal viso projekto rezultatus. (žr. 8 pav.)
Ataskaitos, sukurtos remiantis modeliavimo rezultatais, pavyzdys yra html failas, sukurtas pagal nurodytą formatą. Formatas gali būti savavališkai sukonfigūruotas pagal tam tikros organizacijos priimtą formatą.
Grandinės bloko viduje naudojamos bloko parametruose nurodytos savybės.
Vidinėje bloko schemoje yra ne tik atitikties reikalavimams analizė, bet ir grafikas, reikalingas modeliavimo rezultatams atvaizduoti. Šis grafikas gali būti naudojamas tiek peržiūrai skaičiavimo metu, tiek rezultatams po skaičiavimo analizuoti.
Skaičiavimo rezultatai perduodami į bloko išvestį ir tuo pačiu metu įrašomi į bendrą ataskaitos failą, kuris sukuriamas pagal viso projekto rezultatus. (žr. 8 pav.)
Ataskaitos, sukurtos remiantis modeliavimo rezultatais, pavyzdys yra html failas, sukurtas pagal nurodytą formatą. Formatas gali būti savavališkai sukonfigūruotas pagal tam tikros organizacijos priimtą formatą.
8 pav. Ataskaitos failo pavyzdys, pagrįstas modeliavimo rezultatais.
Šiame pavyzdyje ataskaitos forma sukonfigūruojama tiesiogiai projekto ypatybėse, o lentelės formatas nustatytas kaip visuotiniai projekto signalai. Šiuo atveju SimInTech pati išsprendžia ataskaitos nustatymo problemą, o rezultatų įrašymo į failą blokas naudoja šias eilutes įrašydamas į ataskaitos failą.
9 pav. Ataskaitos formato nustatymas visuotiniuose projekto signaluose
Signalų duomenų bazės naudojimas reikalavimams.
Norint automatizuoti darbą su nuosavybės parametrais, kiekvienam tipiniam blokui signalų duomenų bazėje sukuriama standartinė struktūra. (žr. 10 pav.)
10 pav. Reikalavimo patikros bloko struktūros pavyzdys signalų duomenų bazėje.
Signalų duomenų bazė suteikia:
- Visų būtinų sistemos reikalavimų parametrų saugojimas.
- Patogus esamų projekto reikalavimų peržiūra iš nurodytų parametrų ir esamų modeliavimo rezultatų.
- Vieno bloko arba blokų grupės nustatymas naudojant scenarijų programavimo kalbą. Signalų duomenų bazės pakeitimai lemia bloko savybių reikšmių pokyčius diagramoje.
- Tekstinių aprašymų, nuorodų į techninių specifikacijų elementus ar identifikatorių saugojimas reikalavimų valdymo sistemoje.
Signalų duomenų bazių struktūras reikalavimams galima nesunkiai sukonfigūruoti dirbti su trečiosios šalies reikalavimų valdymo sistema Bendra sąveikos su reikalavimų valdymo sistemomis schema pateikta 11 pav.
11 pav. Sąveikos su reikalavimų valdymo sistema diagrama.
SimInTech bandymo projekto ir reikalavimų valdymo sistemos sąveikos seka yra tokia:
- Darbo sąlygos suskirstytos į reikalavimus.
- Nustatyti techninių specifikacijų reikalavimai, kuriuos galima patikrinti matematiniu techninių procesų modeliavimu.
- Pasirinktų reikalavimų atributai perkeliami į SimInTech signalų duomenų bazę standartinių blokų struktūroje (pavyzdžiui, maksimali ir minimali temperatūra).
- Skaičiavimo proceso metu struktūros duomenys perkeliami į blokinio projekto diagramas, atliekama analizė ir rezultatai saugomi signalų duomenų bazėje.
- Atlikus skaičiavimus, analizės rezultatai perkeliami į reikalavimų valdymo sistemą.
3–5 reikalavimų žingsniai gali būti kartojami projektavimo proceso metu, kai įvyksta projekto ir (arba) reikalavimų pakeitimų ir pakeitimų poveikį reikia išbandyti iš naujo.
Išvados.
- Sukurtas sistemos prototipas leidžia žymiai sutrumpinti esamų modelių analizės laiką, kad jie atitiktų techninių specifikacijų reikalavimus.
- Siūloma testavimo technologija naudoja jau esamus dinaminius modelius ir gali būti naudojama net bet kokiems dinaminiams modeliams, įskaitant tuos, kurie neatliekami SimInTech aplinkoje.
- Naudojant paketinį duomenų organizavimą, kartu su modelio kūrimu galite kurti reikalavimų tikrinimo paketus arba netgi naudoti šiuos paketus kaip technines modelio kūrimo specifikacijas.
- Ši technologija gali būti integruota su esamomis reikalavimų valdymo sistemomis be didelių išlaidų.
Tiems, kurie perskaitė iki galo,
Šaltinis: www.habr.com