Automatická kontrola požadavků TZ během dynamického modelování

Pokračujeme v tématu „Jaké jsou vaše důkazy?“, podívejme se na problém matematického modelování z jiného úhlu. Poté, co se ujistíme, že model odpovídá tvrdé pravdě života, můžeme odpovědět na základní otázku: „Co vlastně máme?“ Při vytváření modelu technického objektu se obvykle snažíme ujistit, že tento objekt splní naše očekávání. K tomu se provádějí dynamické výpočty procesů a výsledek se porovnává s požadavky. To je digitální dvojník, virtuální prototyp a další moderní pojmy, které v projektové fázi řeší, jak zajistit, abychom dostali to, co jsme plánovali.

Jak rychle můžeme zjistit, že naše systém je přesně to, co projektujeme? Bude létat nebo plavat naše konstrukce? A pokud poletí, jak vysoko? A pokud bude plavat, jak hluboko?

V tomto článku se zabýváme automatizací kontroly dodržování technických požadavků při vytváření dynamických modelů technických systémů. Jako příklad se podíváme na prvek technického zadání pro systém vzduchového chlazení letadla.

Zaměřujeme se na ta požadavky, které lze vyjádřit číselně a matematicky zkontrolovat na základě konkrétního výpočtového modelu. Je jasné, že je to pouze část obecných požadavků na jakýkoli technický systém, ale právě na jejich kontrolu utrácíme čas, nervy a peníze na vytváření dynamických modelů objektu.

Při popisu technických požadavků ve formě dokumentu lze vymezit několik druhů různých požadavků, z nichž každý vyžaduje různá přístupy pro formování automatické kontroly dodržování požadavků.

Například vezměme takovou malou, ale reálnou sadu požadavků:

1. Teplota atmosférického vzduchu na vstupu do chladícího systému:
   na stojánce − od mínus 35 do 35 ºC,
   v letu − od mínus 35 do 39 ºC.
2. Statický tlak atmosférického vzduchu během letu − od 700 do 1013 hPa (od 526 do 760 mm rt. st.).
3. Celkový tlak vzduchu na vstupu do vzduchového filtru chladicího systému v letu − od 754 do 1200 hPa (od 566 do 1050 mm rt. st.).
4. Teplota chladícího vzduchu:
   na stojánce − maximálně 27 ºC, pro technické bloky − maximálně 29 ºC,
   v letu − maximálně 25 ºC, pro technické bloky − maximálně 27 ºC.
5. Spotřeba chladicího vzduchu:
   na parkovišti − minimálně 708 kg/h,
   v letu − minimálně 660 kg/h.
6. Teplota vzduchu v přístrojových odhazích − maximálně 60 ºC.
7. Množství jemnozrnné volné vlhkosti v chladicím vzduchu − maximálně 2 g/kg suchého vzduchu.

I v této omezené sadě požadavků je možné vyčlenit alespoň dvě kategorie, které je nutné ve systému zpracovávat odlišně:

• požadavky provozních podmínek systému (p. p. 1-3);
• parametrické požadavky na systém (p. p. 3-7).

Požadavky provozních podmínek systému
Vnější podmínky pro vyvíjený systém při modelování mohou být stanoveny jako okrajové podmínky nebo jako výsledek práce celého systému.
Při dynamickém modelování je nutné se ujistit, že zadané provozní režimy jsou pokryty procesem modelování.

Parametrické požadavky na systém
Tyto požadavky představují parametry zajišťované samotným systémem. V průběhu modelování můžeme tyto parametry získat jako výsledky výpočtu a ujistit se, že požadavky jsou splněny v každém konkrétním výpočtu.

Identifikace a kódování požadavků

Pro usnadnění práce s požadavky doporučují existující standardy přiřadit každému požadavku identifikátor. Při přiřazení identifikátorů je velmi žádoucí používat jednotný systém kódování.

Kód požadavku může být jednoduše číslem odrážejícím pořadové číslo požadavku, nebo může obsahovat kód typu požadavku, kód systému nebo agregátu, na který se vztahuje, kód parametru, kód umístění a mnoho dalšího, co si inženýr dokáže představit. (variant použití kódování viz článek)

V tabulce 1 je uveden jednoduchý příklad kódování požadavků.

1. kód zdroje požadavků R – požadavky TDD;
2. kód typu požadavků E – požadavky – parametry vnějšího prostředí, nebo provozní podmínky
   S – požadavky zajišťované systémem;
3. kód stavu letadla 0 – libovolný, G – na parkovišti, F – v letu;
4. kód typu fyzikálních parametrů T – teplota, P – tlak, G – průtok, vlhkost H;
5. pořadové číslo požadavku.

Projekt systému kontroly požadavků.

Pro každé stanovené požadované hodnoty existuje algoritmus pro vyhodnocení shody vypočtených parametrů s uvedenými požadovanými hodnotami. V zásadě každé řídicí systém obsahuje algoritmy pro kontrolu požadavků, jednoduše proto, že to je výchozí nastavení. Dokonce i každý regulátor je má. Pokud teplota překročí stanovené limity, zapne se klimatizace. První krok jakéhokoli řízení tedy spočívá v kontrole shody parametrů s požadavky.

A protože kontrola je algoritmus, mohou se použít stejné nástroje a nástroje, které používáme k vytvoření řídicích programů. Například prostředí SimInTech umožňuje vytvářet balíčky projektů, které obsahují různé části modelu provedené jako samostatné projekty (model objektu, model řídicího systému, model prostředí atd.).

Projekt kontroly požadavků se tedy stává stejným projektem algoritmů a je připojen k balíčku modelu. A v režimu dynamického modelování provádí analýzu shody s požadavky TZ.

Příkladem prezentace projektu systému je znázorněno na obrázku 1.

Obrázek 1. Příklad prezentace projektu kontroly.

Stejně jako pro algoritmy řízení mohou být požadavky formulovány jako sada listů. Pro usnadnění práce s algoritmy v prostředích strukturálního modelování, jako jsou SimInTech, Simulink, AmeSim, se využívají možnosti vytváření vícestupňových struktur ve formě submodelů. Taková organizace umožňuje seskupit různé požadavky do sad pro zjednodušení práce s množinou požadavků, jak se to dělá pro algoritmy řízení (viz obr. 2).

Obrázek 2. Hierarchická struktura modelu ověřování požadavků.

Například v tomto případě jsou vyčleněny dvě skupiny: požadavky pro prostředí a požadavky přímo na systém. Proto se používá dvoustupňová datová struktura: dvě skupiny, z nichž každá je listem algoritmu.

Pro připojení dat k modelu se používá standardní schéma tvorby databáze signálů, ve které jsou uchovány údaje pro výměnu mezi částmi projektu.

Při vytváření a testování softwaru se do této databáze vkládají údaje ze senzorů (analogů skutečných senzorů systému), které jsou používány řídicím systémem.
Pro projekt testování se v této databázi mohou ukládat jakékoliv parametry vypočítané v dynamickém modelu a tímto způsobem se mohou používat pro ověřování splnění požadavků.

Samotný dynamický model může být v tomto případě realizován v jakémkoliv systému matematického modelování nebo dokonce ve formě spustitelného programu. Jedinou podmínkou je mít programová rozhraní pro výstup dat z modelování do externího prostředí.

Obrázek 3. Připojení projektu ověřování ke komplexnímu modelu.

Příklad základního listu ověřování požadavků je zobrazen na obrázku 4. Z pohledu vývojáře se jedná o běžné výpočtové schéma, na kterém je graficky znázorněn algoritmus ověřování požadavků.

Obrázek 4. List ověřování požadavků.

Hlavní části listu ověřování jsou popsány na obrázku 5. Algoritmus ověřování je sestavován analogicky k výpočtovým schématům algoritmů řízení. V pravé části se nachází blok čtení signálů z databáze. V tomto bloku dochází k dotazu na databázi signálů během modelování.

Přijaté signály se analyzují za účelem výpočtu podmínek ověřování požadavků. V daném případě se provádí analýza výšky pro určení polohy letadla (zda je na parkovišti nebo ve vzduchu). K tomuto účelu lze také využít další signály a vypočítané parametry modelu.

Podmínky ověřování a ověřované parametry se předávají do typických bloků ověřování, ve kterých se provádí analýza dat těchto parametrů na shodu se stanovenými požadavky. Výsledky se zapisují do databáze signálů tak, aby je bylo možné využít k automatickému vytvoření kontrolního seznamu.

Obrázek 5. Struktura výpočtového listu ověřování požadavků.

Jako ověřované parametry není nutné používat signály obsažené v databázi, které jsou řízeny parametry vypočítanými v průběhu modelování. Nic nebrání provádět další výpočty v rámci projektových požadavků, stejně jako vypočítáváme podmínky ověřování.

Například takový požadavek:

Počet zapnutí korekčního systému během letu k cíli nesmí překročit číslo 5, a celkový čas provozu korekčního systému nesmí překročit 30 sekund.

V tomto případě se do výpočtového schématu projektových požadavků přidává algoritmus počítadla počtu zapnutí a celkového času provozu.

Typický blok ověřování požadavků.

Každý typický blok ověřování požadavků je určen k výpočtu splnění požadavku určitého typu. Například v požadavcích na prostředí je uveden rozsah pracovních teplot okolního vzduchu na parkovišti a ve vzduchu. Tento blok by měl přijmout jako parametr teplotu vzduchu v modelu a určit, zda tento parametr pokrývá daný teplotní rozsah.

Blok obsahuje dva vstupní porty, param a condition.

Na první je přiváděn ověřovaný parametr. V tomto případě "Teplota vnějšího prostředí".

Na druhý port je přiváděna booleovská proměnná – podmínka pro provedení ověřování.

Pokud na druhý vstup přijde TRUE (1), blok provede výpočet ověřování požadavku.

Pokud na druhý vstup přijde FALSE (0), podmínky kontroly se neprocházejí. To je nutné pro zohlednění podmínek výpočtu. V našem případě se tento vstup používá k zapnutí nebo vypnutí kontroly podle stavu modelu. Pokud je letadlo během modelování na zemi, požadavky vztahující se k letu se nekontrolují, a naopak – pokud je letadlo ve vzduchu, nekontrolují se požadavky spojené s provozem na stání.

Tento vstup lze také použít při nastavování modelu, například na počáteční fázi výpočtu. Když se model dostane do požadovaného stavu, bloky kontroly jsou vypnuté, ale jakmile systém přejde do požadovaného režimu, bloky kontroly se zapnou.

Jako parametry tohoto bloku se zadávají:

• hranice podmínek: horní (UpLimit) a dolní (DownLimit) mezí, které mají být kontrolovány;
• požadovaný čas setrvání systému na mezích (TimeInterval) v sekundách;
• identifikátor požadavku ReqName;
• přípustnost překročení mezí Out_range – logická proměnná, která určuje, zda je porušením požadavku výstupní hodnota za kontrolovanou oblast.

V některých případech překročení kontrolované hodnoty znamená, že systém má rezervu a může pracovat mimo pracovní oblasti. V jiných případech překročení znamená, že systém nezvládá udržet stanovené parametry v mezích.

Obrázek 6. Typový blok kontroly vlastnosti na schématu a jeho parametry.

Výsledkem výpočtu tohoto bloku je varianta Result, která přijímá následující hodnoty:

• 0 – rNone, hodnota není definována;
• 1 – rDone, požadavek je splněn;
• 2 – rFault, požadavek není splněn.

Obrázek bloku obsahuje:

• text identifikátoru;
• digitální zobrazení parametrů mezí měření;
• barevný identifikátor stavu parametru.

Uvnitř bloku může být dostatečně složitá schéma logického odvození.

Například pro kontrolu pracovního rozsahu teplot bloku, uvedeného na obrázku 6, je vnitřní schéma znázorněno na obrázku 7.

Obrázek 7. Vnitřní schéma bloku určení rozsahu teplot.

Uvnitř bloku schémat se používají vlastnosti stanovené v parametrech bloku.
Kromě analýzy souladu s požadavky obsahuje vnitřní schéma bloku graf potřebný k zobrazení výsledků modelování. Tento graf lze využít jak pro prohlížení během výpočtu, tak pro analýzu výsledků po výpočtu.

Výsledky výpočtu jsou předávány na výstup bloku a zároveň zapisovány do společného souboru zprávy, který je vytvářen na základě výsledků celého projektu. (viz obr. 8)

Příklad zprávy vytvořené na základě výsledků modelování představuje html soubor, který je vytvořen podle zadaného formátu. Formát může být libovolně nastaven podle standardu přijatého konkrétní organizací.

Uvnitř bloku schémat se používají vlastnosti stanovené v parametrech bloku.
Kromě analýzy souladu s požadavky obsahuje vnitřní schéma bloku graf potřebný k zobrazení výsledků modelování. Tento graf lze využít jak pro prohlížení během výpočtu, tak pro analýzu výsledků po výpočtu.

Výsledky výpočtu jsou předávány na výstup bloku a zároveň zapisovány do společného souboru zprávy, který je vytvářen na základě výsledků celého projektu. (viz obr. 8)

Příklad zprávy vytvořené na základě výsledků modelování představuje html soubor, který je vytvořen podle zadaného formátu. Formát může být libovolně nastaven podle standardu přijatého konkrétní organizací.

Obrázek 8. Příklad souboru zprávy na základě výsledků modelování.

V tomto příkladu je nastavení formy zprávy prováděno přímo v vlastnostech projektu, zatímco formát je určen v tabulce jako globální signály projektu. V tomto případě SimInTech automaticky řeší úkol nastavení zprávy, a blok zapisování výsledků do souboru využívá tyto řetězce pro zápis do zprávy.

Obrázek 9. Nastavení formátu zprávy v globálních signálech projektu.

Použití databáze signálů pro požadavky.

Pro automatizaci práce se nastavením vlastností pro každý typový blok se vytváří typová struktura v databázi signálů. (viz obr. 10)

Obrázek 10. Příklad struktury bloku kontroly požadavku v databázi signálů.

Databáze signálů zajišťuje:

• Uložení všech potřebných parametrů požadavků na systém.
• Pohodlné zobrazení existujících v projektu požadavků z daných parametrů a aktuálních výsledků modelování.
• Nastavení jednoho bloku, skupiny bloků pomocí skriptovacího programovacího jazyka. Změny v databázi signálů vedou ke změně hodnot vlastností bloku v schématu.
• Uložení textových popisů, odkazy na body TZ nebo identifikátory v systému správy požadavků.

Struktury databáze signálů pro požadavky mohou být snadno nastaveny pro práci s externím systémem správy požadavků, obecné schéma interakce se systémy správy požadavků je uvedeno na obrázku 11.

Obrázek 11. Schéma interakce se systémem správy požadavků.

Sekvence interakce testovacího projektu SimInTech se systémem řízení požadavků je následující:

1. Technická specifikace se dělí na požadavky.
2. Jsou vyčleněny takové požadavky technické specifikace, které lze ověřit pomocí matematického modelování technických procesů.
3. Atributy vyčleněných požadavků jsou předávány do databáze signálů SimInTech ve strukturách typových bloků (například maximální a minimální teplota).
4. Během výpočtu jsou data struktur předávána do výpočtových schémat bloků, provádí se analýza a výsledky se ukládají do databáze signálů.
5. Po dokončení výpočtu jsou výsledky analýzy předány do systému řízení požadavků.

Fáze práce s požadavky 3 — 5 se mohou opakovat během procesu návrhu, když dochází ke změnám ve konstrukci a (nebo) požadavcích a je tedy nezbytné zopakovat kontrolu vlivu provedených změn.

Závěry.

• Vytvořený prototyp systému zajišťuje významné zkrácení času analýzy stávajících modelů z hlediska shody s požadavky technické specifikace.
• Navrhovaná technologie testování využívá již existující dynamické modely a může být použita i pro jakékoli dynamické modely, včetně těch, které nejsou vytvořeny v prostředí SimInTech.
• Použití paketové organizace dat umožňuje vytvářet balíčky kontrolních požadavků paralelně s vývojem modelů, nebo dokonce použít tyto balíčky jako technickou specifikaci pro vývoj modelů.
• Technologie může být bez výrazných nákladů integrována s existujícími systémy řízení požadavků.

Pro ty, kteří dočetli až do konce, odkaz na video s demonstrací práce prototypu.

Zdroj: habr.com