Jste zde

HiL vs. SiL aneb testování softwaru

Antonín Vojáček, 2. Srpen 2021 - 8:21

Stále větší podíl na moderních systémech, ať již průmyslových či spotřebitelských, tvoří software. A je proto stále důležitější a složitější správně, rychle a efektivně otestovat všechny jeho funkce. S tím od první až po konečnou fázi vývoje pomáhají tzv. SiL a HiL systémy.

V současné době již ve většině aplikací přesahuje jeho podíl více než 60% celého systému. A tento podíl bude dále stoupat. Zásadní je tedy efektivní, rychlé a ideálně i plně automatizované testování funkcí softwaru, protože s jeho rostoucím podílem na výrobku či zařízení se stává hlavní i jeho vliv na kvalitu a spolehlivost celého systému.

Aby se odhalily skryté chyby v kódu programu i špatně navržené funkce, je nutné testovat celý software jako celek, nejlépe nezávisle na programovacím prostředí a zejména u rozsáhlejších systémů zcela nezávisle i na osobě programátora či vývojáře (či programátorů a vývojářů). Proto velké firmy mají zvlášť oddělené skupiny vývojářů softwaru (programátorů) a testerů, kteří by měli pracovat ideálně co nejvíce nezávisle. Jejich práci by pak měly spojovat jen oběma těmto skupinám nadřazené požadavky zadání (tzv. requirementy), které by pak výsledné zařízení mělo splňovat a mělo se podle nich chovat.

Testování softwaru

K profesionálnímu testování řídícího softwaru slouží specializované systémy. Ty se snaží z vnějšku přistupovat k jeho funkcím, spouštět je a předkládat jim různé vstupní hodnoty / data, následně pak sbírat vygenerované výsledky, data, hodnoty, signály či povely a analyzovat jejich správnost vzhledem k požadovaným funkcím v zadání či vzhledem k požadovanému správnému a bezpečnému chování deklarovaném v různých standardizovaných normách pro danou oblast aplikace.

Správný testovací postup by neměl vůbec brát v potaz vnitřní strukturu softwaru a jeho provedení, ale nahlížet na něj jen jako na tzv. černou krabici (blackbox), které má mít nějaké předem definované chování a určitým způsobem v definovaných časech reagovat na vnější podněty vytvořením korespondujících vhodných výstupních stavů, dat či hodnot. Důležité jsou nejen samotné stavy výstupů, ale i časy v jakém dané stavy mají nejpozději nastat a také v jaké správné posloupnosti. I tyto informace by mělo mít správné zadání chování softwaru, zejména tam, kde jsou klíčové pro celkové chování systému, ať již z funkčního, tak z bezpečnostního pohledu.

Z pohledu režimů testování je možné je rozdělit na:

Laboratorní / kancelářské testování - testování softwaru bez fyzické přítomnosti okolních mechanických komponent systému a reálného fyzického okolí. Všechny stavy, podmínky a situace se jen simulují virtuálně.
Testbench či výrobní testování - testování funkce softwaru včetně některých mechanických komponent či částí strojů v rámci vývoje či výroby v prostorách výrobce. Zde již se alespoň z části simulují skutečné provozní podmínky.
Provozní testování - testování softwaru již ve zkušebním reálném provozu simulujícím již skutečný budoucí konkrétní provoz systému v podmínkách cílového uživatele.

Příklad využití jednotlivých systémů testování softwaru dle fáze vývoje až k zahájení produkce na příkladu ECU řídicí jednotky automobilu.

Laboratorní / kancelářské testování

Laboratorní/ kancelářské testování je prvním stupněm testování během vývoje řídicího softwaru, protože jednak dovoluje zjistit co nejvíce nedostatků v co nejkratším čase a pak dovoluje odstranit i hlavní kritické chyby, které by v již nějaké více reálné simulaci mohly způsobit nějakou destrukci, ať testované části či i testovacího provozu. Obvykle probíhá v několikrát se opakujícím kolečku typu vývojář -> tester -> manažer -> vývojář, kdy tester zjišťuje odchylky v chování, manažer pak definuje zda jsou nedostatkem a pak případně na ně vývojář reaguje opravami / úpravami. Testovací postupy, ať již prováděné automaticky nějakým naprogramovaným testovacím systémem, nebo postupným "ručním" nastavováním a analýzou testera, by proto měly probíhat dle předem definovaných, sepsaných a odsouhlasených postupů (tzv. test cases), aby byly vždy prováděny stejně i při opakovaném testování. Pouze pak jsou jejich výsledky vždy navzájem spolehlivě porovnatelné a umožňují zjistit skutečný stav úprav.

Na základě používaných testovacích prostředků vznikly v zásadě dva hlavní testovací principy označované jako:

SiL = Software in the Loop - testování chování funkcí softwaru zcela nezávisle na hardwaru.
HiL = Hardware in the Loop - testování částí nebo i kompletního chování softwaru ve spojení s hardwarem.

I když jde o dva rozdílné principy, základní přístup obou systémů je podobný. Vždy jde o testování chování řídicího / aplikačního softwaru v tzv. uzavřené smyčce (in the Loop), kde v přesně definované časové posloupnosti a za předem přesně definovaných výchozích podmínek (tzv. preconditions) se aktivují definované signálové vstupy blackbox testovaného systému a v definovaných časech a posloupnosti očekávají signálové výstupy, které se následně v korelaci s nastavenými vstupy vyhodnotí. Případně se na jejich základě rovnou opět znovu aktivují / změní podmínky / vstupy testovaného systému a cyklus se opakuje. Testovaný software je tedy "zapojen" ve smyčce testovacího systému.

Příklad testovací smyčky HiL systému dSPACE pro simulaci a testování funkcí autonomního řízení vozidel.

SiL testování

SiL systém představuje principiálně, finančně i prostorově výrazně méně náročné řešení a proto je využívané obvykle jako první stupeň testování softwaru. Představuje možnost základního testování funkcí a částí softwaru přímo na PC bez nutnosti použití nějakého reálného hardwaru budoucího zařízení. Využívá se zde jak plně softwarové virtuální simulace reálného prostředí v okolí řídící jednotky, tak i stejně virtuální simulace hardwaru samotné řídící jednotky, obvykle společně na jednom testovacím počítači. Zde se tedy přirozeně netestuje žádný skutečný hardware budoucí řídicí jednotky.

V první fázi se často testují a analyzují jen části programu realizující tzv. aplikační vrstvu (Appl. Software), tedy úroveň realizující samotné řídící funkce, ale neobsahující v sobě již nižší úrovně softwaru (tzv. Basic software BSW a Middleware) související s během na konkrétním hardwaru, například práci s pamětí, komunikačními rozhraními, základní zpracování signálů ze vstupů (například ze senzorů), běh základního operačního systému jednotky, vytížení jader CPU v jednotlivých režimech apod. Toto testování dokáže zkoušet samotnou principiální funkci chování řízení či zpracování signálů, například reakci změny výstupních proměnných na změnu hodnot naměřené teploty, ale neumožňuje například měřit rychlosti zpracování, rychlosti reakcí vstupů či výstupů, či skutečné vytížení budoucího používaného CPU, prostě se skutečným hardwarem řídící jednotky svázané vlastnosti. K běhu testů se využívají možnosti operačního softwaru, CPU a paměti daného testovacího PC, na kterém SiL testování probíhá. Simulační PC software (simulační prostředí) například mění hodnoty vstupní proměnné teploty na základě nějaké přednastavené křivky a pak zaznamenává, vykresluje v grafu, případně animuje chování výstupů na obrazovce PC. Případně může ve zpětné vazbě měnit vstupy testovacího režimu (modelu).

Moderní SiL PC software (zde například dSPACE VEOS) již umožňuje do sebe nahrát i modely chování dynamiky vozidla, model funkce motoru, parametry hardwaru ECU řídicí jednotky apod. pro kompletní virtuální testování celkové funkce softwaru ECU jednotky.

Vyšší úroveň SiL testování pak představuje simulace celé tzv. virtuální řídicí jednotky. Zde speciálně k tomu určený PC software dokáže na základě zadaných parametrů finálního hardwaru a kompletního kódu softwaru řídící jednotky virtualizovat její celkový běh na dostatečně výkonném testovacím počítači. Umožňuje tak otestovat kompletní chod softwaru jako celek, včetně simulace chování OS řídící jednotky, její paměti, komunikačních driverů apod. virtualizované jako další programový blok v aplikační vrstvě. Použijeme-li zde výše zmíněný příklad s řízením teploty, tak zde je již možné otestovat, že se v simulované RAM či EEPROM (NV paměti) zapíší příslušné hodnoty na příslušná konkrétní adresovaná paměťová místa, že při datové komunikaci se na virtuální rozhraní sběrnice vyšle paket obsahující správné hodnoty a správou adresou virtuální jednotky větráku, nebo že se například v EEPROM paměti data omylem nepřepíší jinými daty při vypnutí a zapnutí řídící jednotky a jejím bootování. Sice zde nelze zcela přesně testovat reálné časové reakce, ale moderní SiL testovací simulátory při běhu na dostatečně výkonných PC dokáží částečně simulovat i správný běh na jednotlivých simulovaných jádrech budoucího CPU z pohledu priorit běhu jednotlivých modulů a požadovaných přerušení. Opět se zde využívá jen prostředků hardwaru testovacího PC a jeho OS, takže zde nelze ověřit skutečně všechny real-time funkce softwaru a OS řídící jednotky.

Moderní SiL systém dSPACE VEOS již umí velmi přesně simulovat i hardware řídicích jednotek, simulovat signály různých senzorů, provozních situací a podmínek, a tak poskytuje velmi plynulý přechod mezi SiL a HiL testováním.

HiL testování

Opravdu skutečné real-time testování chování řídicí jednotky, jak jejího softwaru, tak již i jejího hardwaru, může provádět až HiL systém. Ten představuje již finančně i provozně náročnější režim testování, který však lépe vypovídá o skutečné spolehlivosti a správném běhu celého softwaru. Dokáže totiž testovat nahraný (naflashovaný) hardware řídící jednotky simulací skutečného elektromechanické chování budoucího reálného okolí v různých podmínkách a za různých situací, dle nastavení / naprogramování tzv. fyzikálního modelu okolí.

U dlouhodobých nebo technicky náročných projektů je pak používání HiL systému finančně a hlavně časově výhodnější než fyzická realizace testovacích podmínek / testovacího prostředí. Zejména to platí o chování bezpečnostních či různých limitních ochranných funkcí řídicího softwaru na hraně i za hranou provozních podmínek (např. teplotních, napěťových a proudových apod.), které by reálně opakovaně realizovat mohlo být i skutečně velmi nebezpečné. Další nemalou výhodou je možnost testovat a ladit skutečnou funkčnost softwaru ještě dříve, než je k dispozici celý provozní hardware stroje či zařízení. Lze tedy dostatečně kvalitně odladit řídicí jednotku a její software paralelně s vývojem a výrobou hardwaru stroje. A vzhledem k rostoucí složitosti softwaru a často dlouhým dodacím lhůtám některých komponent, je nutné v dnešní době začínat s vývojem aplikačního softwaru často dříve než samotných hradwarových komponent stroje.

Příklad již velmi složitého HiL testovacího systému pro testování funkcí ECU řídicí jednotky pro autonomní řízení využívající i simulací toku informací z kamerových, radarových a LiDARových senzorů.

HiL systém je obvykle v základu tvořen následujícími částmi:

ovládacím PC (u méně náročných systémů kancelářským PC, u profesionálních systémů průmyslovým PC),
testovací výpočetní CPU jednotkou pracující v reálném čase (PLC či PAC jednotky u méně náročných systémů nebo u profesionálních systémů specializovaným HiL hardwarem),
vstupními a výstupními kartami a komunikačními rozhraními pro simulaci signálů a datové komunikace,
napájecími zdroji pro simulaci skutečných napětí v cílové aplikaci.

Do takové sestavy se pak na vstupní /výstupní a komunikační rozhraní testovací jednotky připojuje samotný testovaný vzorek řídící jednotky i s nahraným softwarem. Zařízení HiLu pak simuluje chování "budoucího okolí", tedy elektrických a fyzikálních vlastností komponent vlastního stroje/zařízení i okolních provozních podmínek stroje (typicky např. teplota). Na základě vytvořeného a do PC HiLu nahraného modelu simulace prostředí pak HiL systém nastavuje a stimuluje vstupy, výstupy a komunikační rozhraní testované řídicí jednotky, jak je budou stimulovat a zatěžovat skutečné senzory, akční členy nebo připojená digitální zařízení. V tomto směru se v profesionálních systémech v mnoha případech využívá modelovacího softwaru Matlab Simulink.

Příklad nabídky možné výbavy HiL systéma dSPACE různými kartami vstupů, výstup, komunkačních rozhraní a řízení napájení.

Ovládací PC HiLu obvykle slouží k nahrávání, správě a nastavování parametrů / vlastností modelu a i k ukládání a archivaci nahraných výsledků / signálů z testování pro jejich následné detailní "off-line" vyhodnocení. Tedy pro úkoly již nevyžadující běh v reálném čase v řádu milisekund či i desítek a stovek mikrosekund, se kterým má klasické PC problémy. Tyto funkce pak zajišťuje rychlá CPU jednotka pracující v reálném čase na úrovni stovek mikrosekund, do které je program modelu nahrán. Pro ovládání a běh modelu pak slouží speciální software, pak například dSPACE ControlDesk. Pro vytvoření samotného modelu simulace okolí řídící jednotky pak často slouží software Matlab Simulink.

Ovládací software HiL systému, zde například dSPACE ConrolDesk, slouží k běhu simulace okolí testované řídicí jednotky a také k zadání povelů nebo zobrazování/ukládání výsledků simulace a testování.

Z výše uvedeného je patrné, že lze vytvořit základní vlastní specializovaný HiL testovací systém i pomocí univerzálních komponent (například modulárních PLC jednotek, nastavitelných zdrojů a kancelářského PC), ten je vhodný zejména pro málo náročné aplikace a projekty, nebo využít HiL zařízení specializovaných výrobců, jako například společnosti dSPACE. Ty se využívají u vývoje náročných komplexních projektů (např. pro vývoj dopravních systémů a prostředků). Takové specializované HiL testovací systémy pak mohou stát i několik miliónů Kč.

Závěr - HiL vs. SiL

Z výše uvedeného popisu je patrné, že hlavní rozdíl mezi SiL a HiL přístupem je v zapojení reálných elektrických signálů do režimu simulace. Případně někdy i základních pohyblivých mechanických komponent a na ně navázaných senzorů či akčních prvků. Nicméně základ je v tom, že HiL systém dokáže již dostatečně věrně simulovat i různé časové, frekvenční či elektromagnetické jevy, které prostě v SiL testování není možné realizovat. V HiL se tedy testuje nejen reakce samotného celkového softwaru na jeho všech úrovních (basic softwaru, middlewaru i aplikačního softwaru), ale i jeho spojení se samotným hardwarem na úrovni základní basic vrstvy softwaru, tedy na úrovni využívání a správy komunikačních driverů, správy RAM i EPROM (NVRAM) pamětí, vzorkování a taktování digitálních i analogových vstupů a výstupů celé budoucí řídící jednotky.

Z toho je patrné, že pro HiL testování je již nutné mít k dispozici alespoň nějaký reálný testovací vzorek budoucí řídící jednotky, ideálně pak již tvořený konkrétními budoucími hardwarovými komponentami. Čím se testovaný hardware řídící jednotky se softwarem více blíží budoucímu reálnému hardwaru vyráběné či dodávané řídící jednotky, tím jsou pak výsledky HiL testování více reálně relevantní.