ISO 26262

ISO 26262  je mezinárodní norma pro funkční bezpečnost silničních vozidel. Norma byla připravena k vydání technickou komisí ISO / TC 22 / SC 32 "Elektrické, elektronické součásti a typy systémů obecně" Mezinárodní organizace pro normalizaci a dosud prošla 2 vydáními: první - v listopadu 2011 [ 1] a druhý - v prosinci 2018 [2] .

Celý název normy je „Silniční vozidla – Funkční bezpečnost“.

Rozsah normy

Ačkoli název normy uvádí, že se vztahuje na funkční bezpečnost silničních vozidel, v praxi je její rozsah omezen na elektrické a/nebo elektronické systémy související s výkonem funkcí souvisejících s bezpečností a instalované na sériově vyráběných silničních vozidlech. Příklady takových systémů jsou elektronické systémy řízení trakce, vysokonapěťové měniče, elektronické ovládání řízení a brzd, reléové logické obvody.

Norma se nevztahuje na mopedy a unikátní systémy speciálních vozidel, jako jsou elektronické podpůrné systémy pro handicapované řidiče. Je povoleno používat normu ve spojení s normami funkční bezpečnosti v jiných průmyslových oblastech, což je částečně pokryto v části 8 normy.

Struktura normy

Nejnovější vydání normy se skládá z 12 částí:

Stručný přehled některých částí normy

Část 1 - Slovní zásoba

První část normy představuje pojmy a definice, které se budou v budoucnu aktivně používat. Norma, spolu s převzatými termíny z IEC 61508, má některé velmi charakteristické a na některých místech specifické termíny a koncepty automobilového průmyslu, jejichž pochopení je rozhodující pro dobré čtení následujících kapitol.

Funkční bezpečnost  - absence nepřijatelné úrovně rizika spojeného s nebezpečím způsobeným nesprávným funkčním chováním elektronických / elektrických systémů.

Koncept funkční bezpečnosti v rámci normy opakuje myšlenky obsažené v normě IEC 61508, která je považována za „mateřskou“ normu ve vztahu k ISO 26262, to znamená, že když tato norma vznikla, vycházela z velké části z tehdy existujících IEC. 61508.

Část 2 - Řízení funkční bezpečnosti

Druhá část normy popisuje zásady řízení funkční bezpečnosti v rámci podniku a v rámci projektu, a to jak ve fázi vývoje, tak ve fázi výroby, provozu, údržby a vyřazování z provozu. Je uveden podrobnější popis postupů pro přípravu a provádění auditu funkční bezpečnosti, posouzení funkční bezpečnosti a potvrzujících přezkumů.

Diagram ukazuje strukturu části 2 normy. Běžně jej lze rozdělit na 3 části: projektově nezávislou a projektově závislou část řízení funkční bezpečnosti a také řízení funkční bezpečnosti při výrobě, provozu, údržbě a vyřazování z provozu.

Projektově nezávislá část řízení funkční bezpečnosti je zaměřena na vytváření a udržování kultury bezpečnosti, systému řízení kvality, pravidel, procesů, přístupů k zajištění funkční bezpečnosti, řízení nesrovnalostí funkční bezpečnosti a kompetence specialistů podílejících se na vývoji zařízení.

Pro dosažení funkční bezpečnosti vyvíjených zařízení je nutné mít v organizaci zaveden systém managementu kvality (QMS) , přičemž QMS může být postaven na základě libovolného standardu. Takže ISO 9001 , IATF 16949 nebo ASPICE lze použít jako standard pro QMS. Přítomnost QMS v organizaci zajišťuje, že procesy popsané v ISO 26262 budou stavět na stávajících procesech pro vývoj kvalitních zařízení, čímž se dosáhne jejich funkční bezpečnosti na správné úrovni spolehlivosti a kvality. Při absenci QMS je implementace ISO 26262 v organizaci nepravděpodobným a časově náročným úkolem.

Projektově specifická část řízení funkční bezpečnosti se zabývá mnoha aspekty projektu vývoje zařízení v organizaci a zahrnuje plánování vývoje, pravidla pro přezkoumání a změny, distribuované řízení vývoje, vytváření bezpečnostních případů, audity funkční bezpečnosti, hodnocení funkční bezpečnosti a potvrzující kontroly.

Plánování a koordinace bezpečnosti jsou klíčovými aspekty jakéhokoli projektu vývoje zařízení a jsou v odpovědnosti manažera funkční bezpečnosti. Má právo delegovat některé úkoly na jiné specialisty s příslušnými kompetencemi, zůstává však odpovědný za sestavení bezpečnostního plánu, jeho aktuálnost a aktualizaci aktuálního stavu vývoje. Je důležité, aby všechny akce uvedené v plánu byly sděleny příslušným odpovědným osobám (odpovědnost může být formalizována ve formě matice RASIC).

Bezpečnostní pouzdro musí být vyvinuto v souladu s bezpečnostním plánem . Účelem tohoto dokumentu je prokázat, že v rámci tohoto projektu bylo dosaženo funkční bezpečnosti. Provedení úkolu se provádí díky správně sestaveným bezpečnostním argumentům, tedy vysvětlením „proč lze toto zařízení považovat za funkčně bezpečné“. Každý argument se zpravidla skládá ze 4 úrovní: jádro a 3 úrovně.

K ověření bezpečnosti zařízení se používají tři přístupy: potvrzující kontroly, audity funkční bezpečnosti a hodnocení funkční bezpečnosti.

Konfirmační posudky se používají ve vztahu k jednotlivým výsledkům práce/úkolů a mají potvrdit dostatečnost a přiměřenost těchto výsledků z hlediska jejich budoucího využití při tvorbě bezpečnostního případu. Potvrzující kontroly jsou přechodnými milníky v životním cyklu funkční bezpečnosti zařízení ve vývoji a musí být dokončeny před zahájením výroby (stejně jako před zahájením hodnocení bezpečnosti). Každou potvrzující kontrolu může provést jeden nebo více specialistů na funkční bezpečnost, během nichž potvrzující kontrola kontroluje správnost, úplnost, integritu a dostatečnost produktu/dokumentu předloženého ke kontrole. Příloha C části 2 normy poskytuje některé podrobnosti o hlavních podrobnostech procesu potvrzujícího přezkumu.

Audit funkční bezpečnosti zkoumá, zda vývojové procesy pro elektrické a/nebo elektronické systémy relevantní pro výkon funkcí souvisejících s bezpečností odpovídají normě ISO 26262 z hlediska vývojových procesů v ní popsaných. Doporučeno pro zařízení s ASIL B mezi bezpečnostními cíli a povinné pro zařízení s ASIL C a ASIL D. Na základě výsledků auditu jsou poskytnuta doporučení pro vývojáře zařízení, včetně doporučení pro odstranění případných nesrovnalostí.

Posouzení funkční bezpečnosti kontroluje úplnost a kvalitu bezpečnostního pouzdra vytvořeného pro vyvíjené zařízení. Kromě auditu se doporučuje i hodnocení pro zařízení s ASIL B mezi bezpečnostními cíli a je povinné pro zařízení s ASIL C a ASIL D. Struktura parametrů, které mají být hodnoceny pro posouzení funkční bezpečnosti, je poměrně podrobně popsána v příloze D, část 2 normy. Na základě výsledků posouzení se vytvoří závěr o dosažení, nedosažení nebo podmíněném dosažení funkční bezpečnosti zařízením. V případě podmíněného dosažení jsou jasně uvedeny podmínky, za kterých je zařízení považováno za funkčně bezpečné. V případě závěru o neúspěchu jsou uvedeny důvody a požadované úpravy, po kterých se hodnocení opakuje.

Část 3 - Koncepční fáze

Ve fázi konceptu začíná vlastní vývoj zařízení (položky), která je předmětem výzkumu / vývoje v ISO 26262. Zařízení jsou elektrické a/nebo elektronické systémy související s výkonem funkcí souvisejících s bezpečností. Zařízení je systém nebo soubor systémů, na které se vztahuje norma ISO 26262 a které plně nebo částečně realizují funkce vozidla. Mezi takové funkce může patřit například funkce pohybu vozidla, kde výpočet hodnoty točivého momentu v závislosti na různých parametrech je její součástí a je realizován regulátorem kontroly trakce, což je zase zařízení.

Pro úplné pochopení myšlenky zařízení je uveden architektonický diagram části vozidla s označením zařízení na něm, jejich funkcí a funkcí pohybu vozidla a jejich vztahu.

Popis zařízení, jeho funkcí, vztahů s jinými zařízeními, předběžná architektura a vlastnosti a další aspekty, které lze definovat v rané fázi vývoje, se nazývá definice položky. Definice zařízení je hlavním dokumentem, od kterého začíná vývoj jakéhokoli zařízení v souladu s normou ISO 26262.

Na základě definice zařízení, přesněji řečeno funkcí zařízení v ní uvedených, slouží k určení nebezpečných událostí, které mohou vzniknout nesprávným provozem zařízení. K tomu se provádí analýza rizik a hodnocení rizik (analýza rizik a hodnocení rizik), během nichž se zjišťují nebezpečí nesprávného chování zařízení, nebezpečné události, které po nich následují (pro které je stanovena kritičnost) a bezpečnostní cíle. jsou určeny.

Vezměme si jako příklad regulátor trakce automobilu. Jednou z funkcí takového regulátoru bude výpočet hodnoty točivého momentu v závislosti na různých parametrech, jako je rychlost vozu a velikost tlaku na plynový pedál. Tato funkce nemusí fungovat správně, konkrétně při nulové rychlosti vozidla a bez sešlápnutí plynového pedálu může dojít k mimovolnému generování točivého momentu. Toto chování regulátoru kontroly trakce je nesprávné funkční chování . Dojde-li k takovému nesprávnému funkčnímu chování, vzniká nebezpečí  – neúmyslné zrychlení a toto nebezpečí v kombinaci s různými provozními podmínkami a prostředím, například stojící vozidlo v pěší zóně, může vést k nebezpečným událostem (někdy označovaným jako rizikové faktory ). Jednou z takových nebezpečných událostí může být vážné zranění chodců v důsledku čelní srážky vozidla s nimi. Pro takovou nebezpečnou událost se odhaduje velikost závažnosti této nebezpečné události, která se nazývá riziko. Tato úroveň rizika je v normě stanovena pomocí úrovně integrity automobilové bezpečnosti (ASIL) , která se vypočítává z matice rizik uvedené v normě na základě analýzy možnosti vzniku nebezpečné události, závažnosti jejích následků a pravděpodobnosti. jeho zamezení v důsledku jednání řidiče nebo jiných účastníků silničního provozu. Tato úroveň se pohybuje od ASIL A až po ASIL D, přičemž druhá je považována za nejvyšší.

Pokud je velikost rizika přijatelná (úroveň QM) v rámci projektu, má se za to, že funkční bezpečnost systému je ve vztahu k této nebezpečné události zajištěna. Pokud ne (ASIL A až ASIL D), je nutný další vývoj nebezpečné události, aby se určily bezpečnostní ochranné mechanismy, aby se snížila velikost jejího rizika na přijatelnou úroveň a zajistila se funkční bezpečnost.

Prvním krokem po analýze nebezpečí a posouzení rizik je vytvoření bezpečnostních cílů. Navzdory názvu jsou bezpečnostními cíli požadavky na vysokou úroveň zabezpečení, které zajišťují, že dané zařízení je bezpečné. Bezpečnostní cíle jsou definovány na základě analýzy všech nebezpečných situací, které může nesprávné funkční chování zařízení vytvořit, a poměrně často (ale ne vždy) jsou tvrzení opačná než nebezpečí, která generují nebezpečné události. Ve výše uvedeném příkladu bylo nebezpečím „neúmyslné zrychlení“, takže bezpečnostním cílem mohlo být „vozidlo nesmí neúmyslně zrychlit“.

Po vygenerování všech bezpečnostních cílů je každý z cílů analyzován podle primární architektury zařízení, zda by mohlo dojít k narušení daného bezpečnostního cíle. K tomu je vynikající jakákoli deduktivní analýza, jako je analýza stromu poruch, STPA nebo HAZOP.

Na základě výsledků stanovení důvodů porušení bezpečnostního cíle je vytvořena strategie hlášení poruch a snižování funkčnosti. Tato strategie (obvykle v grafické podobě) přesně ukazuje, co je třeba udělat pro odhalení poruch, které vedou k porušení bezpečnostního cíle, a upozornit na to ostatní zařízení a řidiče. Zásady také popisují bezpečné stavy zařízení a vozidla, do kterých jsou převedeny, aby nedošlo k porušení bezpečnostních cílů. Tato strategie je základem pro tvorbu požadavků na funkční bezpečnost . Tyto požadavky odpovídají na otázku „co je třeba udělat, aby nedošlo k porušení bezpečnostních cílů?“, nebo, vzhledem k příkladu, který zvažujeme, „co je třeba udělat, aby vozidlo neúmyslně nezrychlilo?“.

Příkladem bezpečnostního funkčního požadavku by bylo: "Jakékoli neúmyslné zrychlení vozidla nad 0,3 g po dobu delší než 100 ms způsobené regulátorem trakce musí být detekováno a zabráněno." Při menších hodnotách zrychlení nebo trvání jeho výskytu můžeme předpokládat, že bezpečnostní cíl není narušen, protože riziko není příliš velké (pravděpodobně bude nízká závažnost poškození, což povede k nízké úrovni ASIL).

Bezpečnostní funkční požadavky dědí úroveň bezpečnostních cílů ASIL, která je odvozuje z výsledků hodnocení rizik. Je důležité pochopit, že jsou to požadavky, které určují, co je třeba udělat pro zajištění bezpečnosti, a úroveň ASIL určuje pouze soubor metod používaných v budoucnu při vývoji zařízení. Čím vyšší je úroveň ASIL, tím je vývoj náročnější na provádění různých analytických, verifikačních a validačních prací. Jako příklad uveďme tabulku 1 uvedenou v části 4 normy s možnými metodami analýzy spolehlivosti a bezpečnosti architektury systému na vysoké úrovni.

Analýza architektury systému
Metody ASIL
A B C D
jeden Deduktivní analýza o + ++ ++
2 Indukční analýza ++ ++ ++ ++

o - pro tuto metodu není požadováno, aby byla povinná nebo volitelná;

+ — použití této metody se doporučuje

++ - tato metoda je vysoce doporučena

Tabulka ukazuje, že na různých úrovních ASIL se k analýze architektury systému používají různé přístupy a jejich kombinace. V případě deduktivní analýzy, jako je analýza stromu poruch, se tedy použití této metody důrazně doporučuje pouze u ASIL C a ASIL D, na rozdíl od induktivní analýzy, řekněme analýzy režimů poruch a účinků, která se důrazně doporučuje pro jakékoli Hodnota ASIL.

Vytvoření seznamu požadavků na funkční bezpečnost dokončuje fázi koncepce. Tyto požadavky jsou v kombinaci se základními požadavky na zařízení zohledněny při dalším podrobném studiu zařízení, jeho architektury, softwaru a hardwaru.

Část 4 - Vývoj na systémové úrovni

První polovina této části normy je věnována vývoji zařízení na systémové úrovni z architektonického hlediska.

Výstup z koncepční fáze v podobě souboru bezpečnostních funkčních požadavků je hlavním vstupem pro zahájení vývoje zařízení na systémové úrovni. Systémem je v tomto případě samotné zařízení, považované za „černou skříňku“. Pro každý požadavek na funkční bezpečnost je vytvořen jeden nebo více požadavků na technickou bezpečnost . Tyto požadavky, v souladu s výše uvedeným příkladem bezpečnostních funkčních požadavků, odpovídají na otázku „jak by měly být implementovány požadavky koncepční fáze, aby vozidlo neúmyslně nezrychlilo?“.

Odpověď může být:

  1. Na straně ovladače kontroly trakce by měl být instalován mechanismus pro kontrolu věrohodnosti signálu požadavku řidiče na trakce (signál z plynového pedálu), realizovaný porovnáním dvou řídících signálů jdoucích po dvou liniích od pedálu k ovladači.
  2. Pokud se signály navzájem neshodují, řídicí jednotka do 50 ms ovladatelně resetuje požadavek řidiče na trakci.
  3. Na straně regulátoru kontroly trakce by se měla zkontrolovat věrohodnost hodnoty požadovaného krouticího momentu vypočítaného mikrokontrolérem a při nulovém požadavku by regulátor neměl samovolně vytvářet externí požadavek točivého momentu.
  4. Výstupní signál požadavku na krouticí moment do vysokonapěťového měniče musí být odeslán dvěma redundantními datovými linkami.

To jsou jen některé z bezpečnostních technických požadavků, které lze odvodit z výše popsaného bezpečnostního funkčního požadavku. Kromě nich mohou přijít požadavky z různých norem či legislativních dokumentů vysvětlující speciální požadavky na ochranná opatření na straně vyvíjeného zařízení (např. požadavek na opatření k pohlcování přebytečného výkonu na vysokonapěťových zařízeních vyplývá z EHK OSN předpis 100, ale nemusí přímo vyplývat z žádného bezpečnostního funkčního požadavku). Požadavky by měly být rozděleny mezi softwarovou a hardwarovou část systému.

Na základě souboru technických bezpečnostních požadavků je vytvořen popis bezpečnostních mechanismů , které se po jejich podrobném prostudování stanou součástí stávající architektury systému. Ani takto upravená architektura však nemusí být dostatečně bezpečná. Pro ověření bezpečnosti nové architektury zařízení s ochrannými bezpečnostními mechanismy v jejím složení je provedena dodatečná induktivní nebo deduktivní analýza. Na základě výsledků takové analýzy, řekněme FMEA, může být nutné zlepšit nebo doplnit navržené ochranné mechanismy, aby bylo plně dosaženo splnění požadavků na funkční bezpečnost.

Ochranné bezpečnostní mechanismy jsou rozděleny do 3 kategorií – bezpečnostní mechanismy, detekční mechanismy a zmírňující mechanismy. První z nich slouží k úplnému zabránění vzniku poruch, které mohou vést k nebezpečí a nebezpečným událostem, zatímco ostatní, fungující ve spojení, umožňují výskyt takových poruch odhalit a snížit jejich následky tak, aby úroveň rizika zůstala přijatelná. Příklady bezpečnostních mechanismů jsou redundance, detekční mechanismy jsou periodické automatické testování a zmírňující mechanismy jsou algoritmy pro potlačení spontánního točivého momentu. Bezpečnostní mechanismy ve skutečnosti umožňují vypořádat se s náhodnými a systematickými selháními hardwaru a se systematickými selháními softwaru a jejich důsledky.

Každý ochranný mechanismus musí být vybaven prostředky své diagnostiky, aby nedocházelo k situaci, kdy jeho porucha zůstane nepovšimnuta a v podstatě může bez překážek dojít k hlavní poruše, proti které byl tento ochranný mechanismus instalován.

K jasnému oddělení odpovědnosti za implementaci bezpečnostních specifikací a mechanismů ochrany zabezpečení mezi hardwarem a softwarem zařízení se používá formální dokument nazvaný specifikace rozhraní hardware-software. Taková specifikace zachycuje veškeré informační toky mezi softwarem a AO, zejména ty, které se týkají fungování mechanismů ochrany bezpečnosti. Tento dokument je důležitý do budoucna, protože právě s ohledem na něj bude testována softwarová a hardwarová integrace systému a jeho fungování jako celku.

Kromě požadavků na technickou bezpečnost je důležité formulovat obecnou představu o požadavcích na výrobu, provoz, údržbu a vyřazování zařízení z provozu, protože tyto požadavky mohou ovlivnit implementaci ochranných bezpečnostních mechanismů. Pokud například potřebujete podpořit rychlou obnovu zařízení ve vozidle, použití pojistek může tento požadavek značně zkomplikovat.

Druhá polovina této části je věnována testování integrace systému do jednoho celku a do vozidla a také jeho testování na shodu s různými požadavky (včetně požadavků na bezpečnost).

Norma navrhuje takovou testovací strukturu, ve které se nejprve používá hotový software a hardware a testuje se jejich integrace, tedy sestavení do jednoho systému - zařízení. Dále je testován úspěšný provoz tohoto zařízení a jeho integrace do většího systému nebo vozidla. V tomto případě je z hlediska funkční bezpečnosti nejprve kontrolována správná činnost všech ochranných bezpečnostních mechanismů umělým zaváděním poruch a následně soulad zařízení s předloženými požadavky na technickou a funkční bezpečnost. Na úrovni celého vozidla se ověřuje, že zařízení v případě poruchy neporuší bezpečnostní cíle, které byly pro něj dříve určeny (ověření bezpečnosti)

Integrační a kvalifikační testování zařízení na všech úrovních lze provádět v různých prostředích:

Část 5 - Vývoj na úrovni hardwaru

Tato část normy řeší požadavky na funkční bezpečnost na úrovni hardwaru. Na základě analýzy ochranných mechanismů, které je třeba implementovat, a technických požadavků na funkční bezpečnost je nutné určit, co přesně a jak je třeba udělat na úrovni hardwarové komponenty zařízení, aby byla zajištěna správná úroveň bezpečnosti obecně.

Požadavky na funkční bezpečnost na hardwarové úrovni obsahují zpravidla podrobné parametry nutné pro implementaci ochranných bezpečnostních mechanismů, jako jsou časové limity pro činnost watchdogů, frekvence kontrol integrity paměti atd. Všechny tyto požadavky jsou zohledněny zohledněte ve fázi vývoje regulátoru elektrického obvodu a při vývoji topologie desky a při výběru základny součástek. Vzhledem k tomu, že k systematickým selháním může docházet na úrovni hardwaru i během vývoje systémové architektury, vyžaduje hardware také další indukční nebo deduktivní analýzu, která odhalí zranitelnosti v navrhované hardwarové architektuře řadiče, které mohou vést k porušení bezpečnostních cílů na úroveň celého systému.

Takové zranitelnosti se nazývají selhání a některé z nich mohou vést k porušení bezpečnostních cílů. Jediná porucha je porucha, na kterou se nevztahuje bezpečnostní ochranný mechanismus, která přímo vede k porušení bezpečnostního cíle. Dvojitá porucha  je porucha, která v kombinaci s jinou nezávislou poruchou vede k porušení bezpečnostního cíle. Zobecněná verze dvojitého selhání je vícenásobné selhání, avšak vícenásobné selhání úrovně 3 a vyšší jsou podle ISO 26262 považovány za nepravděpodobné, a proto bezpečné. Latentní porucha  je vícenásobná porucha, jejíž přítomnost není detekována bezpečnostním ochranným mechanismem a není vnímána řidičem. Předpokládá se, že při aplikaci různých mechanismů bezpečnostní ochrany zůstanou tzv. zbytkové poruchy , tedy poruchy, které nejsou kryty mechanismy bezpečnostní ochrany a vedou k porušení cílů bezpečnosti. Pro různé ASIL by však procento zbytkových poruch nemělo překročit hodnotu specifikovanou v normě.

S těmito aspekty souvisí skutečnost, že hardware vyžaduje výpočet metrik, které vykazují přijatelnou úroveň systematických a náhodných selhání. Tabulky 4, 5 a 6 udávají cílové hodnoty metrik náhodného selhání.

Tabulka s cílovými hodnotami pro metriky náhodného selhání
ASIL A ASIL B ASIL C ASIL D
Metrika jednotlivých a zbytkových poruch - ≥ 90 % ≥ 97 % ≥ 99 %
Metrika latentního dvojitého selhání - ≥ 60 % ≥ 80 % ≥ 90 %
Pravděpodobnost porušení bezpečnostního cíle v důsledku náhodných poruch - < 1/h < 1/h < 1/h

Výraz pro metriku jednotlivých a zbytkových poruch (SPF):

kde  je míra poruch pro jednotlivé poruchy;

 — poruchovost u zbytkových poruch;

 — poruchovost pro všechny poruchy;

 — poruchovost pro bezpečné poruchy;

 — poruchovost u dvojitých poruch.

Výraz pro metriku dvojitého latentního selhání (LF) je:

kde  je míra selhání pro dvojitá latentní selhání;

 — poruchovost u dvojitě zjistitelných poruch;

 — četnost poruch u dvojnásobných poruch, které řidič vnímá;

Při výpočtu pravděpodobnosti porušení bezpečnostního cíle v důsledku náhodných poruch (PMHF) se bere v úvahu celková míra všech poruch, které mohou nějakým způsobem vést k porušení bezpečnostního cíle (takové poruchy zahrnují všechny nebezpečné poruchy). Hodnotu PMHF lze zhruba vypočítat pomocí následujícího vzorce:

,

kde  - životnost vozidla, v praxi se rovná 15 až 20 letům.

Provedení hardwarové architektury a splnění metrických cílů je pouze částí práce zajištění funkční bezpečnosti zařízení. Kromě toho je vyžadován testovací cyklus hardwaru, který lze podmíněně rozdělit na 2 komponenty:

  1. Zkoušky zaměřené na ověření správnosti a úplnosti splnění hardwarových požadavků na funkční bezpečnost:
    • elektrické testování ochranných bezpečnostních mechanismů;
    • funkční testování bezpečnostních ochranných mechanismů;
    • testy s umělým zaváděním poruch;
  2. Testy zaměřené na kontrolu spolehlivosti a odolnosti hardwaru vůči vlivům prostředí a zvýšenému zatížení:
    • testy vlivu faktorů prostředí (klimatické testy);
    • rozšířené funkční testování;
    • statistický test;
    • testy při zvýšené pracovní zátěži;
    • destruktivní testy v superkritických provozních režimech;
    • statické mechanické zkoušky (ohýbání);
    • dynamické mechanické zkoušky (vibrace);
    • vynucené (zrychlené) testy;
    • testy chemické odolnosti a bezpečnosti;
    • EMC a ESD testy.

Výsledky zkoušek spolu s metrickými výpočty jsou argumenty pro implementaci požadavků na funkční bezpečnost hardwaru a jsou jednou ze součástí bezpečnostního odůvodnění.

Část 6 - Vývoj na úrovni softwaru

Tato část normy řeší požadavky na funkční bezpečnost na úrovni softwaru. Na základě analýzy ochranných mechanismů, které vyžadují implementaci a technických požadavků na funkční bezpečnost, je nutné určit, co přesně a jak dělat na úrovni softwarové komponenty zařízení, aby byla zajištěna náležitá úroveň zabezpečení v Všeobecné.

Požadavky na funkční bezpečnost na softwarové úrovni obsahují zpravidla podrobný popis algoritmů pro činnost ochranných mechanismů, jakou logiku použít pro spouštění ochranných mechanismů a jaké povolené množství výpočetního výkonu je nutné dodržet. Všechny tyto požadavky jsou brány v úvahu ve fázi vývoje softwarové architektury. Vzhledem k tomu, že k systematickým poruchám může docházet jak na softwarové úrovni, tak i na hardwarové úrovni a při vývoji architektury celého systému, vyžaduje softwarová část také dodatečnou induktivní nebo deduktivní analýzu, která umožní identifikovat zranitelná místa v navrhované softwarové architektuře regulátoru, která může vést k narušení bezpečnostních cílů na úrovni celého systému.

Zároveň se taková analýza obvykle provádí pro každou softwarovou komponentu zvlášť: analýza pro aplikační software, analýza pro systémový software, analýza pro operační systém nebo nízkoúrovňový software atd. Účelem analýzy je také zvýraznit závislé selhání modulů Software, kdy výpadky jedné funkce vedou ke kaskádovým poruchám všech závislých funkcí. To je důležité zejména při použití softwarových modulů s různými úrovněmi ASIL v jejich požadavcích.

Klíčová pozornost při vývoji softwaru je věnována použití programovacího jazyka a pravidel kódování. Za prvé, standard doporučuje používat pouze ty jazyky, které splňují řadu kritérií, jako je podpora silného a statického psaní . Navíc pouze z tohoto požadavku vyplývá praktická nemožnost použití některých programovacích jazyků jako je Python . Pokud jde o pravidla programování v různých jazycích, existuje mnoho různých pokynů a normativních dokumentů, které upravují pravidla pro psaní kódu v konkrétním programovacím jazyce při vývoji zařízení souvisejících s bezpečností. Jedním z příkladů takových pokynů je série dokumentů pravidel MISRA pro C a C++ .

Podobně jako vývoj systému vyžaduje vývoj softwaru také ověření a validaci softwaru na různých úrovních. Takže u regulátoru trakce to bude testování na úrovni jednotky, na úrovni softwarových modulů (sestavení jednotek), na úrovni softwarových vrstev a na úrovni celého firmwaru. V každé fázi se provádí statická analýza kódu, kontrola absence runtime chyb, kontrola fungování algoritmů ochranných mechanismů a mnoho dalšího. Současně probíhá integrační i kvalifikační testování v různých prostředích:

Důležitou roli při testování hraje shromažďování testovacího pokrytí pro doložení pokrytí celé řady funkcí softwaru testy.

Vztah k jiným standardům

Norma ISO 26262 je v současnosti jednou z nejmladších a nejstrukturovanějších norem funkční bezpečnosti, protože nabízí mnoho příkladů v působivém objemu a má strukturu podobnou klasickému V-modelu. Tato norma však pokrývá pouze nesprávné chování funkcí vyvíjených zařízení a nabízí přístup k jejich odstranění.

S rozvojem technologií v oblasti bezpilotních prostředků se ukázalo, že kromě klasického nesprávného funkčního chování se některá zařízení mohou v určité situaci chovat i zcela korektně, což je nicméně z hlediska vozidla nežádoucí. nebo řidič. Příkladem toho je kamera, která snímá a rozpoznává objekty na silnici. Při nesprávném rozpoznání může taková kamera vést bezpilotní prostředek, na kterém je nainstalována, k nesprávným, ale technicky správným rozhodnutím, což může následně vést k nehodě.

K řešení takových případů vydala ISO v roce 2019 normu ISO/PAS 21448 [3] , která se poměrně snadno integruje s ISO 26262 a pokrývá dříve problematické oblasti související se zabezpečením objektivních funkcí.

Kromě toho je ve vývoji také norma ISO 21434, která se strukturou podobnou ISO 26262 bude muset obsahovat přístupy k zajištění informační bezpečnosti vozidel.

Poznámky

  1. ↑ ISO 26262-1:  2011 . ISO (11. 1. 2011). Datum přístupu: 20. dubna 2020.
  2. ↑ ISO 26262-1:  2018 . ISO (12. 1. 2018). Datum přístupu: 20. dubna 2020.
  3. ↑ ISO/PAS 21448:2019  (anglicky) . ISO . Datum přístupu: 28. června 2020.

Literatura