HARA produktu

Hazard & Risk Analysis je úvodním krokem rozhodování o zařazení výrobku do třídy bezpečnosti. Systémová podpora vám pomůže udělat a dokumentovat analýzu i její průběh

• HARA nebo FMEA?
• Jak provádět HARA analýzu
  • Opatření musí mít praktické výstupy
• Proč je pro HARA užitečná systémová podpora
  • Dokladování HARA
  • Věcná provázanost
• Může vás zajímat

Výsledky HARA analýzy jsou rozhodující pro posouzení, zda výrobek může být vyvíjen v režimu "běžného" řízení kvality (QM-úroveň), nebo musí vývoj probíhat podle některé z úrovní ASIL A - D nebo SIL (podle typu standardu; dále uvádíme pro jednoduchost společné (A)SIL)

HARA nebo FMEA?

HARA i FMEA pracují s podobnými pojmy a hodnocením výrobku, ale jejich základ je v principu odlišný. Zásadní rozdíl mezi HARA a FMEA je v době realizace a podrobnosti analýzy. Z hlediska postupu zpracování HARA odpovídá standardu HAZOP (Hazard and operability study).

HARA analýzu provádíme v projektu na samém začátku, kdy není známa jeho detailní analýza. Základem posouzení jsou proto jeho potenciální dopady na provoz.

V rámci HARA analýzy je klíčovou otázkou: K jakému ohrožení může vlivem posuzovaného dílu dojít?

FMEA analýzu provádíme na základě detailní analýzy a vycházíme z možných selhání jednotlivých součástek a dílů, ze kterých se posuzovaný produkt skládá.

Klíčovou otázkou FMEA analýzy je: Co se může porouchat a co to může způsobit?

Pro FMEA a HARA je pro analýzu společné, že hodnocení probíhá v kontextu

• Hodnocení způsobených rizik. Příklad: Riziko vážného úrazu
• Posuzování rizikovosti na základě posouzení, jak často nastávají podmínky, kdy ohrožení může nastat. Příklad: Jízda/provoz v noci

Jak provádět HARA analýzu

HARA analýzu zde popisujeme na základě standardu ISO 26262-3. Postup je ale shodný i pro jiné standardy, např. Mil Std 882D.

Základní kroky HARA analýzy jsou

1. Identifikace produktu, pro který se HARA analýza provádí.
2. Popis prostředí, ve kterém je využíván, zejména co je v jeho okolí a může být produktem ovlivněno
3. Provozní režimy, ve kterých je využíván a četnost dané hrozby
4. Jaké hrozby může v jednotlivých režimech způsobit
5. Celkové posouzení (rating) hrozby dané součinem hrozby, pravděpodobnosti situace

Výsledkem analýzy jsou

• Návrhy opatření, které snižují hrozby
• Zařazení do třídy bezpečnosti ASIL / SIL (Podle typu použité normy)

Opatření musí mít praktické výstupy

Opatření, aby mělo smysl, se musí promítnout do konkrétních požadavků, které design splňuje. Typickými příkladem opatření je:

Redundance

Redundance je zdvojení prvku, který může selhat.
Nejzřetelnějším příkladem jsou světla aut, které jsou zdvojené i s velkou částí interní logiky. Redundance se používá víc, než se na první pohled zdá. Nejsou to jenom blikače v zrcátku (duplikují přední blikače) ale např. nezávislá čidla, dopočítávání hodnoty z jiných údajů - např. kombinace dat z jiných čidel apod. Zdvojení se využívá i u kontrolek oznamujících problém řidiči.

Bezpečnostní režim (Safety mode)

Základem bezpečnostního režimu je rozpoznání závady, potenciální závady nebo rizika, že k závadě dojde a přepnutí do bezpečnostního režimu.

Příkladem bezpečnostního režimu je snížení výkonu motoru elektrického vozu, když teplota baterie překročí stanovený práh.

Zvýšení spolehlivosti

Zvýšením spolehlivosti se rozumí použití takových materiálů, dílů a výrobních postupů, u kterých je menší riziko, že selžou. Spolehlivost je přitom důležitá u všech 3 základních součástí dílů - HW / SW / ME (hardware, software, mechanické součásti).

I když to zní banálně, zvýšení spolehlivosti dílu rozhodně banální není. Příklady jsou

• Pro hardware: použití součástek s vyšší ochranou proti elmgmt. rušení, teplotní odolností apod.
• Pro software: používání pravidel bezpečného programování, garantované knihovny a co nejjednodušší kód
• Mechanická část: Odolnější materiály, přesnější montáž

Pro všechny případy společně platí samozřejmě i různé výstupní kontroly.

Proč je pro HARA užitečná systémová podpora

Technicky vzato je hlavním výstupem HARA analýza zejména myšlenkový procesu. Nicméně HARA analýza stejně jako FMEA nestojí osamoceně, ale je vytvářena v kontextu celého projektu, který ovlivňuje a do kterého zapadá:

Dokladování HARA

• Musí být dokumentováno, kdo se analýze podílel
• Na přezkoumání HARA jsou kladeny explicitní požadavky (musí být nezávislé), takže i řešitelé i posuzovatelé analýzy musí být doloženi
• Musí existovat důkazy, že skutečně proběhla - např. podle standardu ISO 26262 má být řízena systémem řízení procesů
• Požadavky musí být přezkoumatelné - musí pro ně existovat racionální zdůvodnění, že skutečně pomohou

Věcná provázanost

• Každé opatření, které z HARA vznikne, se stává safety požadavkem na výrobek, nebo výrobní postup
• Safety požadavky musí být součástí traceability systému a dokumentovány od svého vzniku až po jejich implementaci
• Traceability je oboustranná - musí tedy být možné i zpětně dohledat, jaké důvody v rámci HARA analýzy vedly k rozhodnutí daný požadavek vytvořit.

Se systémovou i procesní podporou HARA v AyMINE budete mít nejenom kvalitní dokumentaci, ale i provázanost s produktovou dokumentací a projektem. A taky procesní podporu.

Může vás zajímat

• Potřebujete pro nový výrobek ISO 26262 normu? Zvažte naše školení standardu.
• O FMEA analýze píšeme zde a o tom, jak udělat produktovou FMEA zde.