Automatické ověřování požadavků TOR v procesu dynamické simulace

Pokračování tématu "Jaké jsou vaše důkazy?", podívejme se na problém matematického modelování z druhé strany. Poté, co se přesvědčíme, že model odpovídá podomácku utvářené pravdě života, můžeme odpovědět na hlavní otázku: „Co přesně tady máme?“ Při tvorbě modelu technického objektu se většinou chceme ujistit, že tento objekt splní naše očekávání. Za tímto účelem jsou prováděny dynamické výpočty procesů a výsledek je porovnáván s požadavky. Jedná se o digitální dvojče, virtuální prototyp atd. módní malí kluci, kteří ve fázi návrhu řeší problém, jak zajistit, že dostaneme to, co jsme plánovali.

Jak se můžeme rychle ujistit, že náš systém je přesně to, co navrhneme, bude náš design létat nebo plavat? A když letí, jak vysoko? A pokud plave, jak hluboko?

Tento článek pojednává o automatizaci ověřování shody s požadavky technické budovy při vytváření dynamických modelů technických systémů. Jako příklad se podívejme na prvek technické specifikace pro systém chlazení vzduchu letadla.

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

Při popisu technických požadavků ve formě dokumentu lze rozlišit několik typů různých požadavků, z nichž každý vyžaduje jiný přístup k vytvoření automatického ověřování plnění požadavků.

Zvažte například tento malý, ale realistický soubor požadavků:

1. Teplota atmosférického vzduchu na vstupu do systému úpravy vody:
   na parkovišti - od minus 35 do 35 ºС,
   za letu - od minus 35 do 39 ºС.
2. Statický tlak atmosférického vzduchu za letu je od 700 do 1013 GPa (od 526 do 760 mm Hg).
3. Celkový tlak vzduchu na vstupu do sání vzduchu SVO za letu je od 754 do 1200 GPa (od 566 do 1050 mm Hg).
4. Teplota chladicího vzduchu:
   na parkovišti - ne více než 27 ºС, pro technické bloky - ne více než 29 ºС,
   za letu - ne více než 25 ºС, pro technické bloky - ne více než 27 ºС.
5. Průtok chladicího vzduchu:
   při parkování - nejméně 708 kg/h,
   za letu - ne méně než 660 kg/h.
6. Teplota vzduchu v přístrojových prostorech není vyšší než 60 ºС.
7. Množství jemné volné vlhkosti v chladicím vzduchu není větší než 2 g/kg suchého vzduchu.

I v rámci tohoto omezeného souboru požadavků existují alespoň dvě kategorie, se kterými je třeba v systému zacházet odlišně:

• požadavky na provozní podmínky systému (kapitoly 1-3);
• parametrické požadavky na systém (odstavce 3-7).

Požadavky na provozní podmínky systému
Vnější podmínky pro vyvíjený systém během modelování mohou být specifikovány jako okrajové podmínky nebo jako výsledek provozu obecného systému.
Při dynamické simulaci je nutné zajistit, aby zadané provozní podmínky byly pokryty simulačním procesem.

Parametrické systémové požadavky
Tyto požadavky jsou parametry poskytované samotným systémem. Během procesu 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 snadnou práci s požadavky doporučují stávající normy každému požadavku přiřadit identifikátor. Při přidělování identifikátorů je velmi žádoucí používat jednotný systém kódování.

Kód požadavku může být jednoduše číslo, které představuje objednací číslo požadavku, nebo může obsahovat kód pro typ požadavku, kód pro systém nebo jednotku, na kterou se vztahuje, kód parametru, kód umístění a cokoliv jiného si inženýr dokáže představit. (použití kódování viz článek)

Tabulka 1 poskytuje jednoduchý příklad kódování požadavků.

1. kód zdroje požadavků R-požadavky TK;
2. kód typ požadavků E - požadavky - parametry prostředí, případně provozní podmínky
   S - požadavky poskytované systémem;
3. kód stavu letadla 0 – jakékoli, G – zaparkované, F – za letu;
4. fyzikální parametr typ kód T – teplota, P – tlak, G – průtok, vlhkost H;
5. sériové číslo požadavku.

ID Požadavky	popis	Parametr
REGT01	Teplota okolního vzduchu na vstupu do vodního chladicího systému: na parkovišti - od minus 35ºС. až 35ºС.
REFT01	Teplota vzduchu na vstupu do systému protivzdušné obrany: za letu - od minus 35 ºС do 39 ºС.
REFP01	Statický atmosférický tlak vzduchu za letu je od 700 do 1013 hPa (od 526 do 760 mm Hg).
REFP02	Celkový tlak vzduchu na vstupu do sání vzduchu SVO za letu je od 754 do 1200 hPa (od 566 do 1050 mm Hg).
RSGT01	Teplota chladicího vzduchu: při parkování ne více než 27 ºС
RSGT02	Teplota chladicího vzduchu: na parkovišti, u technických jednotek ne více než 29 ºС
RSFT01	Teplota chladicího vzduchu za letu ne více než 25 ºС
RSFT02	Teplota chladicího vzduchu: za letu, u technických jednotek ne více než 27 ºС
RSGG01	Průtok chladicího vzduchu: při parkování nejméně 708 kg/h
RSFG01	Průtok chladicího vzduchu: za letu nejméně 660 kg/h
RS0T01	Teplota vzduchu v přístrojových prostorech ne vyšší než 60 ºС
RSH01	Množství jemné volné vlhkosti v chladicím vzduchu není větší než 2 g/kg suchého vzduchu

Návrh systému ověřování požadavků.

Pro každý návrhový požadavek existuje algoritmus pro posouzení shody návrhových parametrů a parametrů specifikovaných v požadavku. Celkově vzato, každý řídicí systém vždy obsahuje algoritmy pro kontrolu požadavků jednoduše standardně. A dokonce je obsahuje každý regulátor. Pokud teplota překročí limity, klimatizace se zapne. První fází každé regulace je tedy kontrola, zda parametry splňují požadavky.

A protože verifikace je algoritmus, můžeme použít stejné nástroje a nástroje, jaké používáme k vytváření řídicích programů. Prostředí SimInTech umožňuje například vytvářet balíčky projektů obsahující různé části modelu, prováděné ve formě samostatných projektů (model objektu, model řídicího systému, model prostředí atd.).

Projekt ověřování požadavků se v tomto případě stává stejným projektem algoritmu a je připojen k modelovému balíčku. A v režimu dynamického modelování provádí analýzu shody s požadavky technických specifikací.

Možný příklad návrhu systému je na obrázku 1.

Obrázek 1. Příklad návrhu ověřovacího projektu.

Stejně jako u řídicích algoritmů lze požadavky sestavit jako sadu listů. Pro usnadnění práce s algoritmy v prostředí strukturálního modelování, jako je SimInTech, Simulink, AmeSim, se využívá možnost vytvářet víceúrovňové struktury ve formě podmodelů. Tato organizace umožňuje seskupovat různé požadavky do sad pro zjednodušení práce s řadou požadavků, jako je tomu u řídicích algoritmů (viz obr. 2).

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

Například v posuzovaném případě se rozlišují dvě skupiny: požadavky na prostředí a požadavky přímo na systém. Proto se používá dvouúrovňová datová struktura: dvě skupiny, z nichž každá je listem algoritmu.

Pro připojení dat k modelu se používá standardní schéma pro generování databáze signálů, která ukládá data pro výměnu mezi částmi projektu.

Při vytváření a testování softwaru jsou do této databáze umístěny odečty senzorů (analogy senzorů reálného systému), které používá řídicí systém.
Pro testovací projekt mohou být jakékoli parametry vypočítané v dynamickém modelu uloženy ve stejné databázi a tak použity ke kontrole, zda jsou požadavky splněny.

Samotný dynamický model lze v tomto případě spustit v libovolném matematickém modelovacím systému nebo dokonce ve formě spustitelného programu. Jediným požadavkem je přítomnost softwarových rozhraní pro vydávání modelovacích dat do externího prostředí.

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

Příklad listu pro ověření základních požadavků je uveden na obrázku 4. Z pohledu vývojáře se jedná o konvenční výpočtový diagram, na kterém je graficky znázorněn algoritmus ověřování požadavků.

Obrázek 4. Kontrolní list požadavků.

Hlavní části kontrolního listu jsou popsány na obrázku 5. Kontrolní algoritmus je vytvořen obdobně jako návrhová schémata řídicích algoritmů. Na pravé straně je blok pro čtení signálů z databáze. Tento blok přistupuje během simulace k databázi signálů.

Přijaté signály jsou analyzovány pro výpočet podmínek ověření požadavků. V tomto případě se provádí analýza výšky pro určení polohy letadla (zda je zaparkované nebo za letu). K tomuto účelu můžete využít další signály a vypočítané parametry modelu.

Kontrolované ověřovací podmínky a parametry se přenášejí do standardních ověřovacích bloků, ve kterých jsou tyto parametry analyzovány z hlediska souladu se stanovenými požadavky. Výsledky jsou zaznamenávány do databáze signálů takovým způsobem, že je lze použít k automatickému generování kontrolního seznamu.

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

Parametry, které mají být testovány, nemusí nutně používat signály obsažené v databázi, které jsou řízeny parametry vypočítanými během procesu simulace. Nic nám nebrání provést dodatečné výpočty v rámci návrhu požadavků, stejně jako počítáme podmínky ověření.

Například tento požadavek:

Počet aktivací korekčního systému během letu k cíli by neměl překročit 5 a celková doba provozu korekčního systému by neměla přesáhnout 30 sekund.

V tomto případě je do návrhového diagramu požadavků přidán algoritmus pro počítání počtu startů a celkové doby provozu.

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

Každé zaškrtávací políčko standardního požadavku je určeno k výpočtu splnění požadavku určitého typu. Například požadavky na prostředí zahrnují rozsah okolních provozních teplot při parkování a za letu. Tento blok musí obdržet teplotu vzduchu v modelu jako parametr a určit, zda tento parametr pokrývá zadaný teplotní rozsah./p>

Blok obsahuje dva vstupní porty, param a condition.

První je napájen s kontrolovaným parametrem. V tomto případě „Vnější teplota“.

Na druhý port je dodána booleovská proměnná – podmínka pro provedení kontroly.

Pokud je na druhém vstupu přijata hodnota TRUE (1), pak blok provede výpočet ověření požadavku.

Pokud druhý vstup obdrží FALSE (0), pak podmínky testu nejsou splněny. To je nezbytné, aby bylo možné vzít v úvahu podmínky výpočtu. V našem případě se tento vstup používá k povolení nebo zakázání kontroly v závislosti na stavu modelu. Pokud je letadlo při simulaci na zemi, pak se nekontrolují požadavky týkající se letu a naopak - pokud letadlo letí, pak se nekontrolují požadavky související s provozem na stání.

Tento vstup lze také použít při nastavování modelu, například v počáteční fázi výpočtu. Po uvedení modelu do požadovaného stavu jsou kontrolní bloky deaktivovány, ale jakmile systém dosáhne požadovaného provozního režimu, kontrolní bloky se zapnou.

Parametry tohoto bloku jsou:

• okrajové podmínky: horní (UpLimit) a dolní (DownLimit) limity rozsahu, které je třeba zkontrolovat;
• požadovaná doba expozice systému v hraničních rozsazích (TimeInterval) v sekundách;
• ID požadavku ReqName;
• přípustnost překročení rozsahu Out_range je booleovská proměnná, která určuje, zda hodnota překračující kontrolovaný rozsah je porušením požadavku.

V některých případech výstup testovací hodnoty indikuje, že systém má určitou rezervu a může pracovat mimo svůj provozní rozsah. V ostatních případech výstup znamená, že systém není schopen udržet nastavené hodnoty v rozsahu.

Obrázek 6. Typický blok kontroly vlastností v diagramu a jeho parametry.

V důsledku výpočtu tohoto bloku se na výstupu vytvoří proměnná Result, která nabývá následujících hodnot:

• 0 – rNone, hodnota není definována;
• 1 – rHotovo, 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 poměrně složitý logický inferenční obvod.

Například pro kontrolu rozsahu provozních teplot jednotky zobrazené na obrázku 6 je vnitřní obvod zobrazen na obrázku 7.

Obrázek 7. Vnitřní schéma jednotky pro stanovení teplotního rozsahu.

Uvnitř bloku obvodu se používají vlastnosti uvedené v parametrech bloku.
Kromě analýzy shody s požadavky obsahuje vnitřní diagram bloku graf nezbytný pro zobrazení výsledků simulace. Tento graf lze použí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 se přenášejí na výstup bloku a současně se zaznamenávají do souboru obecné zprávy, který je vytvořen na základě výsledků za celý projekt. (viz obr. 8)

Příkladem sestavy vytvořené na základě výsledků simulace je html soubor vytvořený podle daného formátu. Formát lze libovolně konfigurovat na formát akceptovaný konkrétní organizací.

Uvnitř bloku obvodu se používají vlastnosti uvedené v parametrech bloku.
Kromě analýzy shody s požadavky obsahuje vnitřní diagram bloku graf nezbytný pro zobrazení výsledků simulace. Tento graf lze použí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 se přenášejí na výstup bloku a současně se zaznamenávají do souboru obecné zprávy, který je vytvořen na základě výsledků za celý projekt. (viz obr. 8)

Příkladem sestavy vytvořené na základě výsledků simulace je html soubor vytvořený podle daného formátu. Formát lze libovolně konfigurovat na formát akceptovaný konkrétní organizací.

Obrázek 8. Příklad souboru zprávy založeného na výsledcích simulace.

V tomto příkladu je formulář sestavy konfigurován přímo ve vlastnostech projektu a formát v tabulce je nastaven jako globální signály projektu. Samotný SimInTech v tomto případě řeší problém s nastavením reportu a blok pro zápis výsledků do souboru využívá tyto řádky k zápisu do souboru reportu.

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

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

Pro automatizaci práce s nastavením vlastností je pro každý typický blok vytvořena standardní struktura v databázi signálů. (viz obr. 10)

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

Databáze signálů poskytuje:

• Uložení všech potřebných parametrů systémových požadavků.
• Pohodlné prohlížení stávajících požadavků projektu ze zadaných parametrů a aktuálních výsledků modelování.
• Nastavení jednoho bloku nebo skupiny bloků pomocí skriptovacího programovacího jazyka. Změny v databázi signálů vedou ke změnám hodnot vlastností bloku v diagramu.
• Ukládání textových popisů, odkazů na položky technických specifikací nebo identifikátorů v systému správy požadavků.

Struktury databáze signálů pro požadavky lze snadno nakonfigurovat tak, aby spolupracovaly se systémem správy požadavků třetí strany.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 řízení požadavků.

Posloupnost interakce mezi testovacím projektem SimInTech a systémem řízení požadavků je následující:

1. Zadávací podmínky jsou rozděleny do požadavků.
2. Jsou identifikovány požadavky technických specifikací, které lze ověřit matematickým modelováním technických procesů.
3. Atributy vybraných požadavků jsou přeneseny do databáze signálů SimInTech ve struktuře standardních bloků (například maximální a minimální teplota).
4. Během procesu výpočtu se data struktury přenesou do blokových návrhových diagramů, provede se analýza a výsledky se uloží do databáze signálů.
5. Po dokončení výpočtu se výsledky analýzy přenesou do systému řízení požadavků.

Kroky 3 až 5 požadavků lze opakovat během procesu návrhu, když dojde ke změnám návrhu a/nebo požadavků a je třeba znovu otestovat dopad změn.

Závěry.

• Vytvořený prototyp systému poskytuje výrazné zkrácení doby analýzy stávajících modelů pro shodu s požadavky technických specifikací.
• Navržená testovací technologie využívá již existující dynamické modely a lze ji použít i pro jakékoli dynamické modely, včetně těch, které nejsou prováděny v prostředí SimInTech.
• Použití dávkové organizace dat vám umožňuje vytvářet balíčky pro ověřování požadavků paralelně s vývojem modelu, nebo dokonce tyto balíčky používat jako technické specifikace pro vývoj modelu.
• Technologie může být integrována se stávajícími systémy řízení požadavků bez výrazných nákladů.

Pro ty, kteří dočetli až do konce, odkaz na video ukazující, jak prototyp funguje.

Zdroj: www.habr.com