Kvalifikace kompilátoru, certifikace a ISO 26262

Pokud by kvalifikace nástroje pro využití v aplikaci s definovanou funkční bezpečností nemohla spadat do kompetencí dodavatele takového nástroje, jak by to asi vypadalo? Bližší pohled na kvalifikační proces dle normy ISO 26262 tento zdánlivý paradox vysvětluje. Proces zde přitom začíná stanovením úrovně ASIL (Automotive Safety Integrity Level) pro vaši aplikaci a také TCL (Tool Confidence Level) vyžadované pro každý nástroj, který hodláte použít. Určováním ASIL pro danou aplikaci se však kvůli rozsahu článku zabývat nebudeme.

Stanovení TCL u použitých nástrojů

Pokud vyvíjíme něco v souladu s bezpečnostními požadavky dle normy ISO 26262, bude standard vyžadovat, aby veškeré softwarové nástroje, které zde během vývoje použijeme, měly k dispozici příslušnou evidenci. U žádného z nástrojů by proto neměla existovat hrozba, že zde vnese chybu, která bude nakonec v provozu znamenat nějaké nebezpečí. I ten nejlepší záměr, pokud jde o bezchybné fungování, může totiž ztroskotat díky nevhodným nástrojům. Klíčové je přitom právě slovo „nepravděpodobné“, spíše než „nemožné“. Smysl toho všeho tedy spočívá v posilování důvěry, že nástroj z pohledu bezpečnosti nevytváří chyby, a ne v tom, že pracuje zcela dokonale. V případě C kompilátorů si zřejmě budeme vybírat a konečné rozhodnutí dále ještě podřídíme řadě kritérií. Stěžejní je však přesvědčení, že zvolený kompilátor do návrhu nevnáší chyby.

Abychom lépe dokázali stanovit, jak dalece budeme nástroj analyzovat, přichází na řadu vyhodnocování rizik (Tool Classification). V tomto případě pokaždé zvažujeme dva aspekty (viz také tab. 1), tedy dopad na bezpečnost návrhu (Tool Impact nebo též TI) a pravděpodobnost, že chyba může vzniknout a nebýt přitom odhalena (Tool error Detection, resp. TD). TI a TD zde přitom nejsou ovlivněny tím, jak často byl daný nástroj používán, příp. jaká firma jej vyrobila. Nebezpečí se pak neomezuje pouze na hrozby v přímém směru, ale do hry vstupují rovněž informace ovlivňující výběr nebo též výsledky testu. Detekce chyby může být pochopitelně zapracována přímo v nástroji, nicméně TD by mělo rovněž zahrnovat zhodnocení a testování prováděné později v průběhu vývojového procesu. Riziko lze minimalizovat tehdy, použijeme-li nástroje pouze v souladu s jejich předpokládaným účelem a podmínkami pro využití, což je obvykle popsáno v uživatelské příručce, příp. též bezpečnostním manuálu. Stojí za zmínku, že nástroje v případě TCL1 žádnou kvalifikaci nevyžadují.

Kvalifikace nástroje v závislosti na ASIL a TCL

Norma ISO 26262 rozlišuje pro každou TCL čtyři metody, pokaždé s ohledem na ASIL dané aplikace – viz také tab. 2.

Rostoucí jistota, pokud jde o využití, však není bezbřehá a dotýká se pouze naprosto stejné verze shodného nástroje a v totožné aplikaci. Jestli se to ale týká vaší situace, máte to mít. Druhá metoda, coby zhodnocení vývojového procesu, vyžaduje hlubší pohled na takový proces přímo u dodavatele vašeho nástroje. To je samozřejmě možné, nicméně ne zas tak moc pravděpodobné. Tedy s výjimkou certifikačních orgánů třetí strany, které mohou k těmto, zpravidla chráněným, informacím získat přístup během auditů.

Třetí metodou je validace softwarového nástroje. Jedná se přitom o spolehlivý způsob, jak zajistit náležité fungování softwaru. V závislosti na konkrétním nástroji však může být úroveň odborných znalostí nezbytných k osvědčení nástroje skutečně vysoká. Kompilátory zcela nepochybně spadají právě do této kategorie. A kvalifikace se konečně stává mnohem jednodušší, pokud byl nástroj vyvíjen v souladu s bezpečnostními standardy. Procesy, které bezpečnostním standardům vyhovují, jsou však stále relativně novou záležitostí a spousta nástrojů bude až příliš vyspělá na to, aby tuto skutečně novou metodu kvalifikace využila.

Osvědčení o kvalifikaci

Pokud jde o prováděnou kvalifikaci, musíte být při předkládání auditorovi samozřejmě spokojeni i s maličkostmi. Jak jsme již ale uvedli, člověk by pak musel být kvalifikovaným odborníkem na validace kompilátoru, aby dokázal rozhodnout, zda stovky či tisíce testů, ke kterým zde dochází, třeba jako v případě kompilátorů MPLAB XC navržených s ohledem na funkční bezpečnost, budou skutečně zapotřebí a rovněž zde mohou stačit.

Spolehlivá cesta, jak potvrdit kvalifikaci nástrojů, vede přes certifikace třetích stran a akteditované orgány, jako je TÜV SÜD. Taková organizace zde může přispět obrovskými zkušenostmi a také odbornými znalostmi, pokud jde o funkční bezpečnost, stejně jako certifikaci nástroje. Na základě využití vyčerpávajících informací a také „trefných“ auditů přímo na místě pak taková třetí strana pracuje s informacemi získanými od poskytovatele nástrojů, včetně definic a dokumentace k procesům, metodiky a výsledků potvrzování, bezpečnostního plánu nebo analýzy FMEA (Failure Mode and Effects Analysis) a manuálu funkční bezpečnosti. Bude tak možné zajistit, že veškeré dokumenty, pokud jde o podmíněnou klasifikaci či kvalifikaci, dodané prodejcem konkrétního nástroje, vyhovují vysokým a také nekompromisním standardům pro dosažení požadovaného cíle.

Microchip a požadavky kladené na funkční bezpečnost

Společně s certifikátem od TÜV SÜD a zprávami, které vše řádně dokládají, má společnost Microchip k dispozici veškerou, výše zmiňovanou dokumentaci, společně s právě vydanými kompilátory MPLAB XC pracujícími s ohledem na funkční bezpečnost – to celé v jednom praktickém balíčku. Nechybí zde ani dokumenty z pohledu klasifikace a kvalifikace pro MPLAB X IDE a MPLAB debuggery a programátory. Vzhledem k tomu, že produkty MPLAB XC podporují veškeré mikrokontroléry (MCU) od společnosti Microchip, bude každý MCU od Microchipu zahrnut ve zmíněném řešení funkční bezpečnosti. Společnost Microchip tak z hlediska požadavků na příslušnou funkční bezpečnost vývojářům pomáhá zjednodušit proces kvalifikace vývojového nástroje.