Automatizovaná kontrola požiadaviek technickej špecifikácie v procese dynamického modelovania

Pokračujúc v téme „Aké sú vaše dôkazy?“, pozrime sa na problém matematického modelovania z inej perspektívy. Po tom, čo sme sa uistili, že model zodpovedá základnej pravde života, môžeme odpovedať na základnú otázku: „Čo vlastne máme?“ Pri vytváraní modelu technického objektu chceme zvyčajne zabezpečiť, že tento objekt bude zodpovedať našim očakávaniam. Za týmto účelom sa vykonávajú dynamické výpočty procesov a výsledok sa porovnáva s požiadavkami. To je digitálny dvojník, virtuálny prototyp a ďalšie módne záležitosti, ktoré v štádiu projektovania riešia úlohu, ako zabezpečiť, aby sme dostali to, čo sme plánovali.

Ako môžeme rýchlo zistiť, či náš systém je presne to, čo projektujeme, vzlietne alebo sa potopí naša konštrukcia? A ak vzlietne, ako vysoko? A ak sa potopí, ako hlboko?

V tomto článku sa skúma automatizácia kontroly splnenia požiadaviek technického zadania pri vytváraní dynamických modelov technických systémov. Ako príklad sa pozrieme na prvok technického zadania pre systém vzdušného chladenia lietajúceho aparátu.

Sústreďujeme sa na tie požiadavky, ktoré je možné vyjadriť číselne a overiť matematicky na základe konkrétneho výpočtového modelu. Je zrejmé, že to je len časť všeobecných požiadaviek na akýkoľvek technický systém, ale práve na ich overenie strácame čas, nervy a peniaze na vytvorenie dynamických modelov objektu.

Pri opise technických požiadaviek vo forme dokumentu je možné vyčleniť niekoľko typov rôznych požiadaviek, z ktorých každá vyžaduje rôzne prístupy na vytvorenie automatickej kontroly splnenia požiadaviek.

Napríklad, pozrime sa na takúto malú, ale reálnu sadu požiadaviek:

1. Teplota atmosferického vzduchu na vstupe do SVO:
   na státí − od mínus 35 do 35 ºC,
   v letu − od mínus 35 do 39 ºC.
2. Statický tlak atmosferického vzduchu v letu − od 700 do 1013 GPa (od 526 do 760 mm Hg).
3. Celkový tlak vzduchu na vstupe do nasávania SVO v lete − od 754 do 1200 GPa (od 566 do 1050 mm Hg).
4. Teplota chladného vzduchu:
   na parkovisku − nie viac ako 27 ºC, pre technické bloky − nie viac ako 29 ºC,
   v lete − nie viac ako 25 ºC, pre technické bloky − nie viac ako 27 ºC.
5. Spotreba chladiaceho vzduchu:
   na parkovisku − nie menej ako 708 kg/h,
   v lete − nie menej ako 660 kg/h.
6. Teplota vzduchu v prístrojových oddieloch − nie viac ako 60 ºC.
7. Množstvo jemnozrnnej voľnej vlhkosti v chladiacom vzduchu − nie viac ako 2 g/kg suchého vzduchu.

Aj v takom obmedzenom súbore požiadaviek je možné vyčleniť aspoň dve kategórie, ktoré je potrebné spracovávať v systéme rôznymi spôsobmi:

• požiadavky na prevádzkové podmienky systému (b. p. 1-3);
• parametrické požiadavky na systém (b. p. 3-7).

Požiadavky na prevádzkové podmienky systému
Externé podmienky pre vyvíjaný systém pri modelovaní môžu byť stanovené ako okrajové podmienky, alebo ako výsledok činnosti celkového systému.
Pri dynamickom modelovaní je potrebné zabezpečiť, že zadané prevádzkové režimy sú pokryté procesom modelovania.

Parametrické požiadavky na systém
Tieto požiadavky predstavujú parametre zabezpečené samotným systémom. V procese modelovania môžeme získať tieto parametre 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 jednoduchšiu prácu s požiadavkami existujúce normy odporúčajú priradiť každému požiadavku identifikátor. Pri priraďovaní identifikátorov je veľmi žiaduce použiť jednotný kódovací systém.

Kód požiadavky môže byť jednoducho číslom odrážajúcim poradové číslo požiadavky, alebo môže obsahovať kód typu požiadavky, kód systému alebo agregátu, na ktorý sa vzťahuje, kód parametra, kód umiestnenia a mnoho ďalšieho, čo si dokáže inžinier predstaviť. (variant použitia kódovania pozri v článku)

V tabuľke 1 je uvedený jednoduchý príklad kódovania požiadaviek.

1. kód zdroja požiadaviek R- požiadavky TZ;
2. kód typu požiadaviek E – požiadavky – parametre vonkajšieho prostredia, alebo prevádzkové podmienky
   S — požiadavky zabezpečované systémom;
3. kód stavu lietadla 0 – akýkoľvek, G – na parkovisku, F – v lete;
4. kód typu fyzických parametrov T – teplota, P – tlak, G – prietok, vlhkosť H;
5. poradové číslo požiadavky.

Projekt systému kontroly požiadaviek.

Pre každú vypočítanú požiadavku existuje algoritmus hodnotenia zhody vypočítaných parametrov a parametrov stanovených v požiadavke. V podstate každá riadiaca sústava vždy obsahuje algoritmy kontroly požiadaviek z princípu. A dokonca aj každý regulátor ich má. Ak teplota prekročí hranicu, zapne sa klimatizácia. Takže prvá fáza akéhokoľvek riadenia je kontrola zhody parametrov s požiadavkou.

A keďže kontrola je algoritmus, je možné použiť tie isté prostriedky a nástroje, ktoré používame na tvorbu riadiacich programov. Napríklad prostredie SimInTech umožňuje vytvárať balíky projektov, ktoré obsahujú rôzne časti modelu vykonané vo forme samostatných projektov (model objektu, model riadenia, model okolia atď.).

Projekt kontroly požiadaviek sa v tomto prípade stáva rovnakým projektom algoritmov a je pripojený k modelovému balíku. A v režime dynamického modelovania vykonáva analýzu súladu s požiadavkami technickej dokumentácie.

Možný príklad zobrazenia projektu systému je uvedený na obrázku 1.

Obrázok 1. Príklad zobrazenia projektu kontroly.

Rovnako ako pre algoritmy riadenia, aj požiadavky je možné zdokumentovať vo forme súboru listov. Pre uľahčenie práce s algoritmami v prostrediach štrukturálneho modelovania, ako sú SimInTech, Simulink, AmeSim, sa využívajú možnosti vytvárania viacúrovňových štruktúr vo forme submodelov. Takáto organizácia umožňuje skupinovať rôzne požiadavky do súborov na zjednodušenie práce s rozsahom požiadaviek, ako sa to robí pre algoritmy riadenia (pozri obr. 2).

Obrázok 2. Hierarchická štruktúra modelu overovania požiadaviek.

Napríklad, v zvažovanom prípade sú vyčlenené dve skupiny: požiadavky na prostredie a požiadavky priamo na systém. Preto sa využíva dvojúrovňová štruktúra údajov: dve skupiny, z ktorých každá je listom algoritmu.

Na prepojenie údajov s modelom sa používa štandardné schéma formovania databázy signálov, v ktorej sú uložené údaje pre výmenu medzi časťami projektu.

Počas vytvárania a testovania softvéru sú do tejto databázy uložené hodnoty senzorov (analogických reálnym senzorom systému), ktoré využíva systém riadenia.
Pre projekt testovania môžu byť v tej istej databáze uložené akékoľvek parametre, ktoré sa vypočítavajú v dynamickom modeli, a takto sa môžu použiť na overenie splnenia požiadaviek.

Samotný dynamický model môže byť v tomto prípade realizovaný v akomkoľvek systéme matematického modelovania alebo dokonca vo forme vykonateľného programu. Jedinou požiadavkou je existencia programových rozhraní na predávanie údajov z modelovania do vonkajšieho prostredia.

Obrázok 3. Prepojenie projektu overovania na komplexný model.

Príklad základného listu overovania požiadaviek je uvedený na obrázku 4. Z pohľadu vývojára predstavuje bežnú výpočtovú schému, na ktorej je graficky zobrazený algoritmus overovania požiadaviek.

Obrázok 4. List overovania požiadaviek.

Hlavné časti listu overovania sú opísané na obrázku 5. Algoritmus overovania sa formuje analogicky s výpočtovými schémami algoritmov riadenia. V pravej časti sa nachádza blok čítania signálov z databázy. V tomto bloku dochádza k prístupu k databáze signálov počas modelovania.

Prijaté signály sa analyzujú na určenie podmienok overovania požiadaviek. V tomto prípade sa vykonáva analýza výšky na určenie polohy lietadla (či je na stojánke alebo vo vzlete). Na tento účel je možné použiť aj iné signály a vypočítané parametre modelu.

Podmienky overovania a overované parametre sa odovzdávajú do štandardných blokov overovania, v ktorých sa vykonáva analýza dátových parametrov na zhodu so stanovenými požiadavkami. Výsledky sa zapisujú do databázy signálov tak, aby sa dali použiť na automatické generovanie kontrolného zoznamu.

Obrázok 5. Štruktúra výpočtového listu overovania požiadaviek.

Ako overované parametre nemusíte použiť signály, ktoré sú obsiahnuté v databáze a spravované parametrami vypočítanými počas modelovania. Nič nezabrání vykonať dodatočné výpočty v rámci projektu požiadaviek, rovnako ako vypočítavame podmienky overovania.

Napríklad, takáto požiadavka:

Počet zapnutí korekčného systému počas letu do cieľa nesmie presiahnuť číslo 5 a celkový čas prevádzky korekčného systému nesmie presiahnuť 30 sekúnd.

V tomto prípade sa do výpočtovej schémy projektu požiadaviek pridáva algoritmus počítadla počtu zapnutí a celkového času prevádzky.

Štandardný blok overovania požiadaviek.

Každý štandardný blok overovania požiadaviek je určený na výpočet splnenia požiadavky konkrétneho typu. Napríklad, v požiadavkách na prostredie je prítomný rozsah pracovných teplôt okolia na stojánke a vo vzlete. Tento blok by mal získať teplotu vzduchu v modeli ako parameter a určiť, či tento parameter pokrýva stanovený rozsah teplôt.

Blok obsahuje dva vstupné porty, param a condition.

Na prvý sa dodáva overovaný parameter. V tomto prípade „Teplota vonkajšieho prostredia“.

Na druhý port sa dodáva boolovská premenná – podmienka splnenia overovania.

Ak na druhý vstup príde TRUE (1), blok vykoná výpočet overovania požiadavky.

Ak na druhý vstup príde FALSE (0), podmienky kontroly sa nevyhodnocujú. Je to potrebné na zohľadnenie podmienok 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 modelovania na zemi, tak sa nevyhodnocujú požiadavky týkajúce sa letu, a naopak – ak je lietadlo vo vzduchu, nekontrolujú sa požiadavky spojené s činnosťou na parkovisku.

Tento vstup sa dá tiež využiť pri nastavení modelu, napríklad v počiatočnej fáze výpočtu. Keď sa model dostane do požadovaného stavu, bloky kontroly sú vypnuté, ale akonáhle systém prejde na požadovaný prevádzkový režim, bloky kontroly sa zapnú.

Ako parametre tohto bloku sú stanovené:

• hranice podmienok: horný (UpLimit) a dolný (DownLimit) limit rozsahov, ktoré sa majú kontrolovať;
• požadovaný čas výdrže systému na hraniciach rozsahov (TimeInterval) v sekundách;
• identifikátor požiadavky ReqName;
• dovoľuje výstup za rozsah Out_range – boolean premenná, ktorá určuje, či je porušením požiadavky výstup hodnoty za kontrolovaný rozsah.

V niektorých prípadoch výstup kontrolovanej hodnoty znamená, že systém má rezervu a môže fungovať mimo pracovného rozsahu. V iných prípadoch výstup znamená, že systém nezvláda udržiavať stanovené parametre v rámci rozsahu.

Obrázok 6. Typový blok kontroly vlastnosti na schéme a jeho parametre.

V dôsledku výpočtu tohto bloku sa na výstupe vytvorí premenná Result, ktorá nadobúda nasledujúce hodnoty:

• 0 – rNone, hodnota nie je definovaná;
• 1 – rDone, požiadavka je splnená;
• 2 – rFault, požiadavka nie je splnená.

Obrázok bloku obsahuje:

• text identifikátora;
• digitálne zobrazenia parametrov limitov merania;
• farebný identifikátor stavu parametra.

Vnútri bloku môže byť dostatočne zložitá schéma logického vyhodnocovania.

Napríklad, na kontrolu pracovného rozsahu teplôt bloku uvedeného na obrázku 6, je vnútorná schéma znázornená na obrázku 7.

Obrázok 7. Vnútorná schéma bloku určenia teplotného rozsahu.

Vnútri bloku schémy sú použité vlastnosti stanovené v parametroch bloku.
Okrem analýzy súladu požiadaviek obsahuje vnútorná schéma bloku graf, ktorý je potrebný na zobrazenie výsledkov modelovania. Tento graf môže byť použitý 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 zapisujú do spoločného súboru reportu, ktorý sa vytvára na základe výsledkov z celého projektu. (pozri obr. 8)

Príklad reportu, vytvoreného na základe výsledkov modelovania, predstavuje súbor html, vytvorený podľa zadaného formátu. Formát môže byť svojvoľne prispôsobený formátu, ktorý je prijatý v konkrétnej organizácii.

Vnútri bloku schémy sú použité vlastnosti stanovené v parametroch bloku.
Okrem analýzy súladu požiadaviek obsahuje vnútorná schéma bloku graf, ktorý je potrebný na zobrazenie výsledkov modelovania. Tento graf môže byť použitý 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 zapisujú do spoločného súboru reportu, ktorý sa vytvára na základe výsledkov z celého projektu. (pozri obr. 8)

Príklad reportu, vytvoreného na základe výsledkov modelovania, predstavuje súbor html, vytvorený podľa zadaného formátu. Formát môže byť svojvoľne prispôsobený formátu, ktorý je prijatý v konkrétnej organizácii.

Obrázok 8. Príklad súboru reportu na základe výsledkov modelovania.

V tomto príklade sa nastavenie formy reportu vykonáva priamo v vlastnostiach projektu, zatiaľ čo formát sa v tabuľke určuje ako globálne signály projektu. V tomto prípade si SimInTech sám rieši problém nastavenia reportu a blok zápisu výsledkov do súboru využíva tieto riadky na zápis do reportu.

Obrázok 9. Nastavenie formátu reportu v globálnych signáloch projektu

Použitie databázy signálov pre požiadavky.

Na automatizáciu práce s nastaveniami vlastností pre každý typový blok sa vytvára typová štruktúra v databáze signálov. (pozri obr. 10)

Obrázok 10. Príklad štruktúry bloku kontroly požiadavky v databáze signálov.

Databáza signálov zabezpečuje:

• Uloženie všetkých potrebných parametrov požiadaviek na systém.
• Pohodlné prezeranie existujúcich požiadaviek v projekte zo zadaných parametrov a aktuálnych výsledkov modelovania.
• Nastavenie jedného bloku, skupiny blokov pomocou skriptovacieho jazyka. Zmeny v databáze signálov vedú k zmene hodnôt vlastností bloku na schéme.
• Uloženie textových popisov, odkazy na body TŽ alebo identifikátory v systéme riadenia požiadaviek.

Štruktúry databázy signálov pre požiadavky môžu byť ľahko prispôsobené na prácu s externým systémom riadenia požiadaviek. Celková schéma interakcie so systémami riadenia požiadaviek je znázornená na obrázku 11.

Obrázok 11. Schéma interakcie so systémom riadenia požiadaviek.

Sekvencia interakcie testovacieho projektu SimInTech so systémom správy požiadaviek je nasledujúca:

1. Technická úloha sa rozdelí na požiadavky.
2. Vyberú sa také požiadavky technickej úlohy, ktoré je možné overiť matematickým modelovaním technických procesov.
3. Atribúty vybraných požiadaviek sú predávané do databázy signálov SimInTech v štruktúrach typických blokov (napríklad maximálna a minimálna teplota).
4. Počas výpočtu sa údaje štruktúr odovzdávajú do výpočtových schém blokov, vykonáva sa analýza a výsledky sú uložené do databázy signálov.
5. Po dokončení výpočtu sú výsledky analýzy odovzdané do systému správy požiadaviek.

Etapy práce s požiadavkami 3 – 5 sa môžu opakovať počas procesu projektovania, keď dôjde k zmenám v konštrukcii a (alebo) požiadavkách a, podľa toho, je potrebná opätovná kontrola vplyvu zavedených zmien.

Záver.

• Vytvorený prototyp systému zabezpečuje významné skrátenie času analýzy existujúcich modelov z hľadiska dodržiavania požiadaviek TZO.
• Navrhovaná technológia testovania využíva už existujúce dynamické modely a môže byť použitá dokonca aj pre akékoľvek dynamické modely, vrátane tých, ktoré nie sú vytvorené v prostredí SimInTech.
• Používanie balíčkovej organizácie údajov umožňuje vytvárať balíky na overovanie požiadaviek súčasne s vývojom modelov, alebo dokonca využiť tieto balíky ako technickú úlohu na vývoj modelov.
• Technológia môže byť bez významných nákladov integrovaná s existujúcimi systémami správy požiadaviek.

Pre tých, ktorí dočítali až do konca, odkaz na video s demonštráciou práce prototypu.

Zdroj: habr.com