Pokračovanie v téme , pozrime sa na problém matematického modelovania z druhej strany. Keď sa presvedčíme, že model zodpovedá domáckej pravde života, môžeme odpovedať na hlavnú otázku: „Čo tu vlastne máme?“ Pri tvorbe modelu technického objektu sa väčšinou chceme uistiť, že tento objekt bude spĺňať naše očakávania. Na tento účel sa vykonávajú dynamické výpočty procesov a výsledok sa porovnáva s požiadavkami. Ide o digitálne dvojča, virtuálny prototyp atď. módni chlapci, ktorí vo fáze návrhu riešia problém, ako zabezpečiť, aby sme dostali to, čo sme si naplánovali.
Ako sa môžeme rýchlo uistiť, že náš systém je presne taký, aký navrhujeme, bude náš dizajn lietať alebo plávať? A ak letí, ako vysoko? A ak pláva, ako hlboko?
Tento článok pojednáva o automatizácii overovania zhody s požiadavkami technickej budovy pri vytváraní dynamických modelov technických systémov. Ako príklad sa pozrime na prvok technickej špecifikácie systému chladenia vzduchu v lietadle.
Zvažujeme tie požiadavky, ktoré je možné numericky vyjadriť a matematicky overiť na základe konkrétneho výpočtového modelu. Je jasné, že toto je len časť všeobecných požiadaviek na akýkoľvek technický systém, ale práve na ich kontrolu vynakladáme čas, nervy a peniaze na vytváranie dynamických modelov objektu.
Pri popise technických požiadaviek vo forme dokumentu je možné rozlíšiť niekoľko typov rôznych požiadaviek, z ktorých každá vyžaduje iný prístup k tvorbe automatického overovania plnenia požiadaviek.
Zvážte napríklad tento malý, ale realistický súbor požiadaviek:
- Teplota vzduchu na vstupe do systému úpravy vody:
na parkovisku - od mínus 35 do 35 ºС,
za letu - od mínus 35 do 39 ºС. - Statický tlak atmosférického vzduchu počas letu je od 700 do 1013 GPa (od 526 do 760 mm Hg).
- Celkový tlak vzduchu na vstupe do sania vzduchu SVO za letu je od 754 do 1200 GPa (od 566 do 1050 mm Hg).
- Teplota chladiaceho vzduchu:
na parkovisku - nie viac ako 27 ºС, pre technické bloky - nie viac ako 29 ºС,
za letu - nie viac ako 25 ºС, pre technické bloky - nie viac ako 27 ºС. - Prietok chladiaceho vzduchu:
pri parkovaní - najmenej 708 kg/h,
za letu - nie menej ako 660 kg / h. - Teplota vzduchu v prístrojových priestoroch nie je vyššia ako 60 ºС.
- Množstvo jemnej voľnej vlhkosti v chladiacom vzduchu nie je väčšie ako 2 g/kg suchého vzduchu.
Aj v rámci tohto obmedzeného súboru požiadaviek existujú najmenej dve kategórie, s ktorými je potrebné v systéme zaobchádzať odlišne:
- požiadavky na prevádzkové podmienky systému (články 1-3);
- parametrické požiadavky na systém (články 3-7).
Požiadavky na prevádzkové podmienky systému
Vonkajšie podmienky pre vyvíjaný systém počas modelovania môžu byť špecifikované ako okrajové podmienky alebo ako výsledok činnosti všeobecného systému.
Pri dynamickej simulácii je potrebné zabezpečiť, aby boli špecifikované prevádzkové podmienky pokryté procesom simulácie.
Parametrické systémové požiadavky
Tieto požiadavky sú parametre, ktoré poskytuje samotný systém. Počas procesu modelovania môžeme tieto parametre získať ako výsledky výpočtu a uistiť sa, že požiadavky sú splnené v každom konkrétnom výpočte.
Identifikácia a kódovanie požiadaviek
Pre uľahčenie práce s požiadavkami existujúce normy odporúčajú priradiť ku každej požiadavke identifikátor. Pri prideľovaní identifikátorov je veľmi žiaduce použiť jednotný systém kódovania.
Kód požiadavky môže byť jednoducho číslo, ktoré predstavuje číslo objednávky požiadavky, alebo môže obsahovať kód pre typ požiadavky, kód pre systém alebo jednotku, na ktorú sa vzťahuje, kód parametra, kód umiestnenia a čokoľvek iné si inžinier dokáže predstaviť. (pozrite si článok o použití kódovania)
Tabuľka 1 poskytuje jednoduchý príklad kódovania požiadaviek.
- kód zdroja požiadaviek R-požiadavky TK;
- kód druh požiadaviek E - požiadavky - parametre prostredia, prípadne prevádzkové podmienky
S - požiadavky poskytované systémom; - kód stavu lietadla 0 – akékoľvek, G – zaparkované, F – za letu;
- kód typu fyzikálneho parametra T – teplota, P – tlak, G – prietok, vlhkosť H;
- sériové číslo požiadavky.
| ID Požiadavky |
Popis | Parameter |
| REGT01 | Teplota okolitého vzduchu pri vstupe do vodného chladiaceho systému: na parkovisku - od mínus 35ºС. do 35ºС. | |
| REFT01 | Teplota vzduchu pri vstupe do systému protivzdušnej obrany: počas letu - od mínus 35 ºС do 39 ºС. | |
| REFP01 | Statický atmosférický tlak vzduchu počas letu je od 700 do 1013 hPa (od 526 do 760 mm Hg). | |
| REFP02 | Celkový tlak vzduchu na vstupe do sania vzduchu SVO za letu je od 754 do 1200 hPa (od 566 do 1050 mm Hg). | |
| RSGT01 | Teplota chladiaceho vzduchu: pri parkovaní nie viac ako 27 ºС | |
| RSGT02 | Teplota chladiaceho vzduchu: na parkovisku, pre technické jednotky nie viac ako 29 ºС | |
| RSFT01 | Teplota chladiaceho vzduchu počas letu nie viac ako 25 ºС | |
| RSFT02 | Teplota chladiaceho vzduchu: počas letu, pre technické jednotky nie viac ako 27 ºС | |
| RSGG01 | Prietok chladiaceho vzduchu: pri odstavení nie menej ako 708 kg/h | |
| RSFG01 | Prietok chladiaceho vzduchu: za letu nie menej ako 660 kg/h | |
| RS0T01 | Teplota vzduchu v prístrojových priestoroch nie je vyššia ako 60 ºС | |
| RSH01 | Množstvo jemnej voľnej vlhkosti v chladiacom vzduchu nie je väčšie ako 2 g/kg suchého vzduchu |
Návrh systému overovania požiadaviek.
Pre každú konštrukčnú požiadavku existuje algoritmus na posúdenie zhody konštrukčných parametrov a parametrov špecifikovaných v požiadavke. Vo všeobecnosti každý riadiaci systém vždy štandardne obsahuje algoritmy na kontrolu požiadaviek. A dokonca ich obsahuje každý regulátor. Ak teplota prekročí limity, klimatizácia sa zapne. Prvou fázou každého nariadenia je teda kontrola, či parametre spĺňajú požiadavky.
A keďže verifikácia je algoritmus, môžeme použiť rovnaké nástroje a nástroje, aké používame na vytváranie riadiacich programov. Prostredie SimInTech umožňuje napríklad vytvárať balíky projektov, ktoré obsahujú rôzne časti modelu, vykonávané vo forme samostatných projektov (model objektu, model riadiaceho systému, model prostredia atď.).
Projekt overovania požiadaviek sa v tomto prípade stáva rovnakým projektom algoritmu a je pripojený k modelovému balíku. A v režime dynamického modelovania vykoná analýzu zhody s požiadavkami technických špecifikácií.
Možný príklad návrhu systému je znázornený na obrázku 1.
Obrázok 1. Príklad návrhu overovacieho projektu.
Rovnako ako v prípade riadiacich algoritmov môžu byť požiadavky zostavené ako súbor listov. Pre pohodlie práce s algoritmami v prostrediach štrukturálneho modelovania ako SimInTech, Simulink, AmeSim sa využíva možnosť vytvárať viacúrovňové štruktúry vo forme podmodelov. Táto organizácia umožňuje zoskupovať rôzne požiadavky do sád na zjednodušenie práce s celým radom požiadaviek, ako je to v prípade riadiacich algoritmov (pozri obr. 2).
Obrázok 2. Hierarchická štruktúra modelu overovania požiadaviek.
Napríklad v posudzovanom prípade sa rozlišujú dve skupiny: požiadavky na prostredie a požiadavky priamo na systém. Preto sa používa dvojúrovňová dátová štruktúra: dve skupiny, z ktorých každá je listom algoritmu.
Na pripojenie dát k modelu sa používa štandardná schéma generovania signálovej databázy, ktorá uchováva dáta na výmenu medzi časťami projektu.
Pri vytváraní a testovaní softvéru sa do tejto databázy umiestňujú hodnoty snímačov (analógy snímačov reálneho systému), ktoré riadiaci systém používa.
Pre testovací projekt môžu byť akékoľvek parametre vypočítané v dynamickom modeli uložené v rovnakej databáze a tak použité na kontrolu, či sú splnené požiadavky.
V tomto prípade môže byť samotný dynamický model vykonaný v akomkoľvek matematickom modelovacom systéme alebo dokonca vo forme spustiteľného programu. Jedinou požiadavkou je prítomnosť softvérových rozhraní na vydávanie modelovacích údajov do externého prostredia.
Obrázok 3. Pripojenie overovacieho projektu ku komplexnému modelu.
Príklad listu overenia základných požiadaviek je uvedený na obrázku 4. Z pohľadu vývojára ide o konvenčný výpočtový diagram, na ktorom je graficky znázornený algoritmus overovania požiadaviek.
Obrázok 4. Kontrolný list požiadaviek.
Hlavné časti kontrolného listu sú popísané na obrázku 5. Kontrolný algoritmus je vytvorený podobne ako návrhové schémy riadiacich algoritmov. Na pravej strane je blok na čítanie signálov z databázy. Tento blok pristupuje počas simulácie k databáze signálov.
Prijaté signály sa analyzujú na výpočet podmienok overenia požiadaviek. V tomto prípade sa vykoná analýza výšky na určenie polohy lietadla (či je zaparkované alebo za letu). Na tento účel môžete použiť ďalšie signály a vypočítané parametre modelu.
Kontrolované podmienky overovania a parametre sa prenášajú do štandardných overovacích blokov, v ktorých sa tieto parametre analyzujú z hľadiska súladu so špecifikovanými požiadavkami. Výsledky sa zaznamenávajú do databázy signálov takým spôsobom, že ich možno použiť na automatické generovanie kontrolného zoznamu.
Obrázok 5. Štruktúra výpočtového listu overenia požiadaviek.
Parametre, ktoré sa majú testovať, nemusia nevyhnutne používať signály obsiahnuté v databáze, ktoré sú riadené parametrami vypočítanými počas procesu simulácie. Nič nám nebráni vykonať dodatočné výpočty v rámci návrhu požiadaviek, rovnako ako vypočítame podmienky overenia.
Napríklad táto požiadavka:
Počet aktivácií korekčného systému počas letu k cieľu by nemal presiahnuť 5 a celkový prevádzkový čas korekčného systému by nemal presiahnuť 30 sekúnd.
V tomto prípade je do návrhového diagramu požiadaviek pridaný algoritmus na meranie počtu štartov a celkového prevádzkového času.
Typický blok overenia požiadaviek.
Každé začiarkavacie políčko štandardnej požiadavky je určené na výpočet splnenia požiadavky určitého typu. Napríklad environmentálne požiadavky zahŕňajú rozsah prevádzkových teplôt okolia pri parkovaní a počas letu. Tento blok musí prijať teplotu vzduchu v modeli ako parameter a určiť, či tento parameter pokrýva špecifikovaný teplotný rozsah./p>
Blok obsahuje dva vstupné porty, param a condition.
Prvý je napájaný s kontrolovaným parametrom. V tomto prípade „Externá teplota“.
Na druhý port je dodaná boolovská premenná – podmienka vykonania kontroly.
Ak sa na druhom vstupe prijme TRUE (1), potom blok vykoná výpočet overenia požiadavky.
Ak druhý vstup dostane FALSE (0), podmienky testu nie sú splnené. Je to potrebné, aby bolo možné zohľadniť podmienky výpočtu. V našom prípade sa tento vstup používa na zapnutie alebo vypnutie kontroly v závislosti od stavu modelu. Ak je lietadlo počas simulácie na zemi, tak sa nekontrolujú požiadavky týkajúce sa letu a naopak - ak lietadlo letí, tak sa nekontrolujú požiadavky týkajúce sa prevádzky na státí.
Tento vstup je možné použiť aj pri nastavovaní modelu, napríklad v počiatočnej fáze výpočtu. Keď sa model dostane do požadovaného stavu, kontrolné bloky sa deaktivujú, ale akonáhle systém dosiahne požadovaný prevádzkový režim, kontrolné bloky sa zapnú.
Parametre tohto bloku sú:
- okrajové podmienky: horné (UpLimit) a dolné (DownLimit) limity rozsahu, ktoré musia byť kontrolované;
- požadovaný čas expozície systému v hraničných rozsahoch (TimeInterval) v sekundách;
- ID požiadavky ReqName;
- prípustnosť prekročenia rozsahu Out_range je booleovská premenná, ktorá určuje, či hodnota presahujúca kontrolovaný rozsah je porušením požiadavky.
V niektorých prípadoch výstup testovacej hodnoty naznačuje, že systém má určitú rezervu a môže pracovať mimo svojho prevádzkového rozsahu. V iných prípadoch výstup znamená, že systém nie je schopný udržať nastavené hodnoty v rozsahu.
Obrázok 6. Typický blok kontroly vlastností v diagrame a jeho parametre.
V dôsledku výpočtu tohto bloku sa na výstupe vytvorí premenná Result, ktorá nadobúda tieto hodnoty:
- 0 – rNone, hodnota nie je definovaná;
- 1 – rHotovo, požiadavka je splnená;
- 2 – rPorucha, požiadavka nie je splnená.
Obrázok bloku obsahuje:
- text identifikátora;
- digitálne zobrazenie parametrov limitov merania;
- farebný identifikátor stavu parametra.
Vo vnútri bloku môže byť pomerne zložitý logický inferenčný obvod.
Napríklad, aby ste skontrolovali rozsah prevádzkovej teploty jednotky znázornenej na obrázku 6, vnútorný obvod je znázornený na obrázku 7.
Obrázok 7. Vnútorná schéma jednotky určenia teplotného rozsahu.
Vo vnútri bloku obvodu sa používajú vlastnosti špecifikované v parametroch bloku.
Okrem analýzy súladu s požiadavkami obsahuje vnútorný diagram bloku aj graf potrebný na zobrazenie výsledkov simulácie. Tento graf je možné použiť ako na prezeranie počas výpočtu, tak aj na analýzu výsledkov po výpočte.
Výsledky výpočtu sa prenášajú na výstup bloku a súčasne sa zaznamenávajú do súboru všeobecnej správy, ktorý sa vytvára na základe výsledkov za celý projekt. (pozri obr. 8)
Príkladom správy vytvorenej na základe výsledkov simulácie je html súbor vytvorený podľa daného formátu. Formát je možné ľubovoľne nakonfigurovať na formát akceptovaný konkrétnou organizáciou.
Vo vnútri bloku obvodu sa používajú vlastnosti špecifikované v parametroch bloku.
Okrem analýzy súladu s požiadavkami obsahuje vnútorný diagram bloku aj graf potrebný na zobrazenie výsledkov simulácie. Tento graf je možné použiť ako na prezeranie počas výpočtu, tak aj na analýzu výsledkov po výpočte.
Výsledky výpočtu sa prenášajú na výstup bloku a súčasne sa zaznamenávajú do súboru všeobecnej správy, ktorý sa vytvára na základe výsledkov za celý projekt. (pozri obr. 8)
Príkladom správy vytvorenej na základe výsledkov simulácie je html súbor vytvorený podľa daného formátu. Formát je možné ľubovoľne nakonfigurovať na formát akceptovaný konkrétnou organizáciou.
Obrázok 8. Príklad súboru správy založeného na výsledkoch simulácie.
V tomto príklade je formulár správy nakonfigurovaný priamo vo vlastnostiach projektu a formát v tabuľke je nastavený ako globálne signály projektu. V tomto prípade samotný SimInTech rieši problém nastavenia reportu a blok na zápis výsledkov do súboru využíva tieto riadky na zápis do súboru reportu.
Obrázok 9. Nastavenie formátu správy v signáloch globálneho projektu
Použitie databázy signálov pre požiadavky.
Pre automatizáciu práce s nastavením vlastností je v databáze signálov pre každý typický blok vytvorená štandardná štruktúra. (pozri obr. 10)
Obrázok 10. Príklad štruktúry bloku kontroly požiadaviek v databáze signálov.
Databáza signálov poskytuje:
- Uloženie všetkých potrebných parametrov systémových požiadaviek.
- Pohodlné prezeranie existujúcich požiadaviek projektu zo špecifikovaných parametrov a aktuálnych výsledkov modelovania.
- Nastavenie jedného bloku alebo skupiny blokov pomocou skriptovacieho programovacieho jazyka. Zmeny v databáze signálov vedú k zmenám hodnôt vlastností bloku v diagrame.
- Ukladanie textových popisov, odkazov na položky technických špecifikácií alebo identifikátorov v systéme riadenia požiadaviek.
Databázové štruktúry signálov pre požiadavky možno jednoducho nakonfigurovať tak, aby spolupracovali so systémom správy požiadaviek tretej strany. Všeobecný diagram interakcie so systémami správy požiadaviek je uvedený na obrázku 11.
Obrázok 11. Schéma interakcie so systémom riadenia požiadaviek.
Postupnosť interakcie medzi testovacím projektom SimInTech a systémom kontroly požiadaviek je nasledovná:
- Zadávacie podmienky sú rozdelené do požiadaviek.
- Identifikujú sa požiadavky technických špecifikácií, ktoré možno overiť matematickým modelovaním technických procesov.
- Atribúty zvolených požiadaviek sa prenášajú do databázy signálov SimInTech v štruktúre štandardných blokov (napríklad maximálna a minimálna teplota).
- Počas procesu výpočtu sa údaje o štruktúre prenesú do blokových návrhových diagramov, vykoná sa analýza a výsledky sa uložia do databázy signálov.
- Po dokončení výpočtu sa výsledky analýzy prenesú do systému riadenia požiadaviek.
Kroky požiadaviek 3 až 5 sa môžu zopakovať počas procesu navrhovania, keď sa vyskytnú zmeny v návrhu a/alebo požiadavkách a je potrebné znovu otestovať vplyv zmien.
Závery.
- Vytvorený prototyp systému poskytuje výrazné skrátenie času analýzy existujúcich modelov na zhodu s požiadavkami technických špecifikácií.
- Navrhovaná testovacia technológia využíva už existujúce dynamické modely a môže byť použitá aj pre akékoľvek dynamické modely, vrátane tých, ktoré nie sú vykonávané v prostredí SimInTech.
- Použitie dávkovej organizácie dát vám umožňuje vytvárať balíky na overenie požiadaviek súbežne s vývojom modelu alebo dokonca použiť tieto balíky ako technické špecifikácie pre vývoj modelu.
- Technológiu je možné integrovať s existujúcimi systémami riadenia požiadaviek bez výrazných nákladov.
Pre tých, ktorí čítajú do konca,
Zdroj: hab.com