Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
statnice:bakalar:b4b35psr [2025/06/09 09:06] – petrstep | statnice:bakalar:b4b35psr [2025/06/10 18:59] (current) – [Bezpečnostně kritický software] added dudactom | ||
---|---|---|---|
Line 107: | Line 107: | ||
{{: | {{: | ||
===== Bezpečnostně kritický software ===== | ===== Bezpečnostně kritický software ===== | ||
+ | |||
+ | Popište proces vývoje bezpečnostně kritického software: | ||
+ | **fáze vývoje**- | ||
+ | |||
+ | (Dle MIL-STD-882E) | ||
+ | - Zdokumentujte jakým způsobem je dosažena bezpečnost | ||
+ | - Identifikujte a zdokumentujte hazardy | ||
+ | - Zhodnoťe a zdokumentujte rizika | ||
+ | - Identifikujte a zdokumentujte způsoby jak snížit jejich závažnost | ||
+ | - Snižte rizika | ||
+ | - Prověřte, validujte a zdokumentujte dosažená snížení rizik | ||
+ | - Akceptujte setrvávající rizika a zdokumentujte je | ||
+ | - " | ||
+ | |||
+ | |||
+ | **způsoby zmírňování nepřiměřeného rizika** | ||
+ | |||
+ | Snížení rizik lze docílit následujícími kroky: | ||
+ | |||
+ | (MIL-STD-882E, | ||
+ | |||
+ | - Eliminujte hazardy skrze design | ||
+ | - Redukujte rizika skrze design | ||
+ | - Zapracujte " | ||
+ | - Doplňte varovná zařízení | ||
+ | - Zapracujte podpisy, školení, procedury, osobní ochranné pomůcky | ||
+ | |||
+ | ** safety standardy ** | ||
+ | MIL-STD-882E, | ||
+ | |||
+ | |||
+ | ** Co je to ”safety integrity level”(SIL)? | ||
+ | |||
+ | Obecně jde o relativní úroveň snížení rizikovosti uplatněním bezpečnostních nároků. | ||
+ | Standard IEC 61508 upravuje úrovně vyžadovaného ochrany proti systematickému selhání v " | ||
+ | Obecně - čím vyšší vyžadovaná úroveň SIL, tím nižší je tolerance na " | ||
+ | |||
+ | ** Jak a kdy se určí? ** | ||
+ | |||
+ | Jak: | ||
+ | |||
+ | - Identifikace hazardů - (např HAZOP) | ||
+ | - Přiřazení pravděpodobnosti jednotlivých hazardů | ||
+ | - Identifikace mechanismů jim zabraňujícím | ||
+ | - Identifikace dopadů hazardů | ||
+ | - Identifikace vážnosti dopadů | ||
+ | - Výpočet třídy rizika (1-nepřípustné až 4-zanedbatelné) | ||
+ | - Identifikace třídy SIL | ||
+ | |||
+ | Obecně chceme docílit třídy rizika 4. Systémy se třídou SIL1 mohou snížit rizika o jednu třídu, Systémy se třídou SIL4 mohou snížit | ||
+ | |||
+ | Kdy: | ||
+ | |||
+ | SIL se obecně určuje již při plánování - je to jeden z podstatných kroků analýzy bezpečnosti. | ||
+ | |||
+ | |||
+ | ** Jak se různý SIL projeví při vývoji a testování systému? ** | ||
+ | |||
+ | Různé úrovně SIL mají různé nároky - například je třeba pro různé úrovně je vyžadována různá úroveň kontroly korektního fungování a to od formy důkazu korektnosti až po množství lidí, kteří systém zkontrolují. Dále je podstatná míra jejich nezávislosti. Stejně tak jsou doporučené praktiky pro různé úrovně SIL. | ||
+ | |||
+ | |||
===== Rozvrhnutelnost a analýza doby odezvy ===== | ===== Rozvrhnutelnost a analýza doby odezvy ===== | ||
Line 170: | Line 231: | ||
{{: | {{: | ||
+ | * Je rozvrhovatelné pokud Ri <= Di | ||
** Vliv sdílených zdrojů ** | ** Vliv sdílených zdrojů ** | ||
Line 177: | Line 239: | ||
===== Sdílené zdroje v systémech reálného času ===== | ===== Sdílené zdroje v systémech reálného času ===== | ||
+ | Sdílení zdrojů v systémech reálného času může představovat potenciálně velký problém ve zpoždění vykonání úlohy a tak i nedodržení limitu pro vykonání. Tento problém může být způsoben hlavně dvěma důvody – Inverze priority a inverze deadlinu. | ||
+ | |||
+ | **Inverze priorit ** je stav, kdy úloha s vyšší prioritou je blokován úlohou s nižší prioritou. K tomuto standarndě dochází díky sdílenému zámku. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ** Deadline Inversion ** je stav, kdy je úloha blokována úlohou s pozdějším časovým limitem splnění. | ||
+ | |||
+ | Jako řešení můžeme uvažovat několik protokolů (// | ||
+ | |||
+ | ** Priority Inheritance Protocol** | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | Obecně - protokol dědění priorit, jak nasvědčuje název, pracuje na principu při kterém kdy dochází k blokaci inverzí priority, blokující podúloha zdědí prioritu blokované po dobu vykonávání kritické sekce. | ||
+ | |||
+ | a ** Priority Ceiling Protocol ** | ||
+ | |||
+ | Tento protokol zajišťuje, | ||
+ | U tohoto protokolu rozdělujeme dvě jeho formy: | ||
+ | |||
+ | **Original PCP** | ||
+ | |||
+ | pravidla: | ||
+ | - Každá úloha má svou statickou prioritu | ||
+ | - Každá úloha má dynamickou prioritu, která je maximem vlastní statické a zděděné statické priority. | ||
+ | - Každá kritická sekce/zdroj má stanovenou maximální prioritu úloh, které do ní vstupují | ||
+ | - Úloha může vstoupit do kritické sekce pouze pokud je jeho dynamická priorita vyšší než systémové maximum. To je stanoveno jako maximální hodnota z priorit aktuálně uzavřených kritických sekcí. | ||
+ | |||
+ | příklad: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | ** Immediate PCP** | ||
+ | pravidla: | ||
+ | - Každá úloha má svou statickou prioritu | ||
+ | - Každá kritická sekce/zdroj má stanovenou maximální prioritu úloh, které do ní vstupují | ||
+ | - Každá úloha má dynamickou prioritu, která je maximem vlastní statické a kritické sekce, do které vstoupila | ||
+ | |||
+ | Díky tomu, pokud je úloha blokována, je to pouze na začátku. | ||
+ | V moment, kdy je již vykonáván, | ||
+ | |||
+ | příklad: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | Obecně - IPCP je jednodušší na implementaci, | ||
+ | |||
+ | (Pozn. na tohle se mě docela detailně ptal Sojka na ústní když jsem chtěl Ačko, takže tady to asi nebude tak žhavé...) | ||
+ | |||
+ | Pro systémy s dynamickými prioritami existuje protokol ** Stack Resource Policy **, což je zobecnění PCP. Zajímavost je, že umožňuje //stack sharing//. | ||
===== Čím se liší RTOS od obecného operačního systému ===== | ===== Čím se liší RTOS od obecného operačního systému ===== | ||