1 Spolehlivost automatizační techniky

Pojem spolehlivost automatizační techniky je nutné chápat v širším kontextu, zejména jako schopnost plnit bezpečně a pohotově požadované funkce.Tento požadavek musí být zohledňován ve všech fázích životního cyklu automatizačního systému, počínaje stanovením koncepce systému přes definici systému, formulování požadavků na systém, návrh systému, jeho integraci, ověření, validaci až po následný provoz a údržbu.

Spolehlivost systému (dependability), jak je chápána v tomto příspěvku, vyjadřuje míru, do jaké se uživatel může spolehnout, že systém funguje tak, jak je stanoveno, že je v daných podmínkách a v daném časovém úseku použitelný, a že je bezpečný. Spolehlivostí se zde rozumí kombinace bezporuchovosti, pohotovosti, udržovatelnosti a bezpečnosti. Používá se pro ni zkratka RAMS (Reliability, Availability, Maintainability, Safety), která charakterizuje dlouhodobou činnost systému. Takto definované spolehlivosti se dosahuje užíváním ověřených technických koncepcí, metod, nástrojů a postupů během celého životního cyklu systému. Jednotlivé prvky spolehlivosti RAMS jsou definovány takto:

• bezporuchovost (reliability) – schopnost objektu plnit požadovanou funkci v daných podmínkách a v daném časovém intervalu. Tato funkce je charakterizována takovými parametry, jako jsou střední doba mezi poruchami MTBF (Mean Time Between Failures), intenzita poruch apod.;
• pohotovost (availability) – schopnost produktu být ve stavu schopném plnit požadovanou funkci v daných podmínkách v daném časovém okamžiku nebo v daném časovém intervalu, za předpokladu, že jsou zajištěny požadované vnější prostředky; pohotovost je zde určována zejména bezporuchovostí a udržovatelností;
• udržovatelnost (maintainability) – schopnost systému být modifikován za účelem opravy vad, zlepšení vlastností nebo jiných atributů, nebo přizpůsobení jinému prostředí; charakteristickými parametry jsou např. MTTR (Mean Time to Recovery), MTTM (Mean Time to Maintenance) apod.;
• bezpečnost (safety) – neexistence nepřípustných úrovní rizik vzniku škody nebo ohrožení zdraví. Je zřejmé, že pohotovost a bezpečnost spolu velmi úzce souvisejí a vzájemně se ovlivňují. Je možné to chápat tak, že nedostatky v těchto dvou složkách nebo chybné řešení konfliktů mezi požadavky na bezpečnost a pohotovost mohou zabránit vytvoření spolehlivého systému. Při hodnocení bezpečnosti, resp. bezpečnostních funkcí, musí řešitelé vycházet z hodnocení rizik, které požadovaná funkce může ovlivnit. Hodnocení rizik a míra přijetí rizik implikuje stanovení úrovně integrity bezpečnosti, která bude definována níže.

2 Bezpečnost automatizovaného systému

Programovatelná elektronická zařízení a systémy jsou ve stále větší míře nasazovány v aplikacích, ve kterých může jejich porucha způsobit materiální škody, zranění nebo ztráty na životech. A to ne pouze v zařízeních „tradičních“ rizikových oborů, jako jsou letectví, nukleární energetika, drážní zabezpečovací systémy, lékařské přístroje či náročné technologie, ale stále více i v „obyčejných“ zařízeních, jako jsou mikrovlnné trouby, automobily atd. Do řídicích systémů jsou alokovány bezpečnostní funkce (safety function), které zaručí, že se řízené zařízení/systém uvedou do bezpečného stavu nebo zůstanou v bezpečném stavu (fail-safe) při výskytu konkrétních nebezpečných událostí (těch, které jsou pokryty bezpečnostními funkcemi). Takto koncipovaný systém je nazýván systém se vztahem k bezpečnosti (safety-related system). Sám musí být navržen jako bezpečný. Pro programovatelné elektronické systémy se vztahem k bezpečnosti platí v ČR obecný (generický) standard ČSN EN 61508. Z něho jsou odvozeny standardy pro různé aplikační oblasti (např. standardy pro drážní zařízení).

3 Integrita bezpečnosti

Bezpečnost systému, kterou ovlivňují jeho jednotlivé komponenty (hardware, software, mechanické prvky atd.), je nejvýznamněji určována interakcí těchto komponent. Pravděpodobnost, že systém za všech stanovených podmínek bude po definovanou dobu uspokojivě provádět bezpečnostní funkce, se označuje jako integrita bezpečnosti (safety integrity). Integrita bezpečnosti je určována kombinací:

• kvantifikovaných prvků obvykle spojených s hardwarem, kde se vyskytují náhodné poruchy;
• nekvantifikovatelných prvků obvykle spojených se softwarem, dokumentací apod., kde se vyskytují systematické chyby.

Pro hardware jsou obvykle postupy a metody pro zajištění bezpečnosti zažity jak na systémové úrovni, tak v oblasti návrhu obvodů, kde probíhá ověřování, předepsané zkoušky, ověřování vlivů prostředí a dalších. Jedná se např. o ověřování parametrů typovými zkouškami, používání analýz typu FMECA (Failure Mode, Effects and Criticality Analysis), FTA (Final Type Approval), výpočty zatížení jednotlivých součástek či výpočty spolehlivosti. Problematičtější je situace v softwaru, a to nejen na systémové a aplikační úrovni včetně tzv. firmwaru, ale dotýká se i programovatelných obvodů typu FPGA a také tzv. generického softwaru, který může být použit pro různé instalace pouze zajištěním dat pro specifické použití (např. různé konfigurátory) .

Úroveň integrity bezpečnosti bezpečnostních funkcí (Safety IntegrityLlevel – SIL) je vyjádřena číslem z intervalu 1 až 4. SIL. Vyšší číslo značí vyšší úroveň integrity bezpečnosti. Čím nebezpečnější mohou být důsledky poruchy bezpečnostních funkcí, tím vyšší musí být stanovená úroveň integrity bezpečnosti. Například v systému řízení lokomotivy je předepsána pro řízení smyku/skluzu úroveň integrity SIL 3 a pro předání hodnoty rychlosti strojvůdci také SIL 3. Cílové míry poruch pro jednotlivé úrovně bezpečnosti jsou stanoveny normou – např. pro SIL 4 je pravděpodobnost nebezpečné poruchy za hodinu 10–9 až 10–8.

4 Chyby, vady, poruchy

Ke spolehlivosti se vztahují následující základní termíny:

• chyba (error) – odchylka od stanoveného návrhu, která by mohla mít za následek nezamýšlené chování systému nebo poruchu;
• vada/poruchový stav (fault) – abnormální podmínka, která může vést k chybě nebo k poruše;
• porucha (failure) – ukončení schopnosti funkční jednotky plnit požadovanou funkci v důsledku chyby nebo vady.

Vady mohou být systematické nebo náhodné. V softwaru jsou vždy systematické vady. Software se používáním nepokazí, ale chyby jsou již ve specifikaci, návrhu nebo implementaci. Hardware může být realizován podle chybného návrhu, což vede k systematickým vadám, ale během činnosti se může projevit náhodná vada.

Právě vadám je věnována velká pozornost při vývoji spolehlivých systémů s vysokou úprovní integrity. Jsou vypracovány techniky pro:

• předcházení vadám (fault avoidance) – zabránění zanesení chyb do systému během jeho návrhu,
• detekci vad (fault detection) – detekce vad během činnost systému a minimalizace jejich efektu,
• toleranci k vadám (fault tolerance) – schopnost systému poskytovat službu tak, jak bylo specifikováno, i za přítomnosti vad.

Při realizaci bezpečných systémů nelze opomenout žádný z následujících kroků.

5 Kroky při realizaci bezpečného systému

5.1 Koncepce návrhu bezpečného systému

Nejprve je třeba stanovit základní koncepci návrhu bezpečného systému, ve které jsou důsledně odděleny kanály systému se vztahem k bezpečnosti a bez něj. Kanál (channel) je prvek (hardwarový či softwarový) nebo skupina prvků provádějící nezávisle danou funkci. Platí, že porucha kteréhokoli prvku kanálu způsobí vždy poruchu celého kanálu. V bezpečném návrhu je funkce realizována buď jediným kanálem, který je chráněn použitím dostatečných prostředků pro řízení nebezpečí (např. hlídací obvody watchdog, lifesign atd.), jež jsou součástí kanálu, nebo je použito více kanálů, které na sebe dohlížejí.

5.2 Bezpečné metody při tvorbě softwaru

Druhým krokem je stanovit a používat bezpečné metody a postupy při tvorbě softwaru. Je třeba si uvědomit podstatné faktory ohrožující úroveň bezpečnosti programového vybavení. Vedle faktorů již uvedených jsou to dále:

• nedostatečné znalosti (nestačí pouze schopnost programování);
• rychlý rozvoj programátorských technik, změny vývojových prostředí, změny nástrojů;
• nemožnost provedení úplných testů.

Celý postup by měl vycházet z předpokladu, že neexistuje postup, který by zaručil prokázání nepřítomnosti vad v softwarovém systému, zejména nepřítomnost poruch specifikace a návrhu a že cílem je minimalizovat počet těchto poruch. Postupy užívané při návrhu softwaru by měly respektovat alespoň tyto principy:

• metoda návrhu shora dolů;
• modularita;
• ověřování každé etapy životního cyklu vývoje;
• ověřené moduly a knihovny modulů;
• jasná dokumentace;
• prověřitelné dokumenty;
• validační testování;
• nezávislé testování.

5.3 Zvážení úrovně rizik

Důležitým krokem je zvážení a ohodnocení úrovně rizik (risk) a nebezpečí (hazard). Riziko je kombinací závažnosti poškození a pravděpodobnosti, že k tomuto poškození dojde. Tento termín je často chápán nesprávně jako „potenciálně nebezpečná situace“ nebo „stav systému, který může vést k nehodě“. Správný termín k označení tohoto stavu je nebezpečí. Do stavu nebezpečí se systém může dostat následkem poruchy nebo je to důsledek chyby v některé z etap vývoje systému.

5.4 Stanovení míry integrity bezpečnosti ve vztahu k riziku

Požadovaná integrita bezpečnosti musí mít takovou úroveň, aby bylo zajištěno, že četnost poruch systémů se vztahem k bezpečnosti bude tak malá, že zabrání tomu, aby četnost nebezpečných událostí překročila hodnotu požadovanou pro splnění přípustného rizika, nebo že systémy související s bezpečností upraví následky poruchy na rozsah požadovaný ke splnění přípustného rizika.

5.5 Klasifikace přípustnosti rizika

Přípustnost rizika (tolerability) je typicky definována čtyřmi kvalitativními úrovněmi. Pro klasifikaci rizika podle tohoto atributu se používá matice, jejíž příklad je znázorněn na obrázku. Písmena (A, B, C, D) vyjadřují třídu rizika:

• třída A – nepřípustné riziko;
• třída B – nežádoucí riziko, přípustné pouze v případě, že snížení rizika je neproveditelné nebo v případě, že náklady jsou výrazně neúměrné dosaženému zlepšení;
• třída C – přípustné riziko v případě, že náklady na snížení rizika by přesáhly dosažené zlepšení;
• třída D – zanedbatelné riziko.

5.6 Řídit se životním cyklem bezpečnosti

Životní cyklus bezpečnosti je definován jako technický rámec pro systematické zajišťování všech činností vedoucích k dosažení požadované úrovně integrity bezpečnosti. Cyklus tvoří posloupnost kroků, z nichž prvním je analýza nebezpečí a rizik. V analýze je třeba zvážit:

• každou určenou nebezpečnou událost a složky, které k ní přispívají,
• nutné snížení rizika pro každou nebezpečnou událost,
• opatření provedená pro snížení nebo odstranění nebezpečí a rizik.

Udržování informací a výsledků z této analýzy je hlavním podkladem pro prokazování a zjišťování pokroku při řešení problémů bezpečnosti. Vedle analýzy nebezpečí a rizik jsou dalšími kroky životního cyklu bezpečnosti:

• specifikace požadavků celkové bezpečnosti – pro každé určené nebezpečí se určují bezpečnostní funkce, pro každou z nich se stanoví požadavky integrity bezpečnosti;
• přiřazení bezpečnostních požadavků – specifikují se systémy související s bezpečností a přiřadí se jim bezpečnostní funkce;
• návrh a realizace systémů souvisejících s bezpečností (může jich být více),
• potvrzení platnosti bezpečnosti – potvrzení, že systémy splňují specifikaci požadavků bezpečnosti.

5.7 Zpracování dokladu bezpečnosti

Doklad bezpečnosti (safety case) je soubor dokumentů, které prokazují, že produkt vyhovuje stanoveným bezpečnostním požadavkům. To znamená, že systém je dostatečně bezpečný pro zamýšlené použití v daném prostředí. Doklad bezpečnosti by měl obsahovat odpovědi na následující otázky:

• co se může porouchat, co může nefungovat (identifikace a analýza nebezpečí),
• jak vážné mohou být následky (hodnocení rizika),
• jaká opatření byla přijata, aby k tomu nedošlo (řízení rizika),
• co je třeba provést, když to nastane (opatření pro mimořádné situace).

Doklad bezpečnosti nemusí být jen výsledkem rozsáhlých teoretických analýz. Důkazy bezpečnosti mohou mít různou formu:

• předchozí použití;
• soulad se standardy, certifikace;
• výpočty;
• testování;
• simulace;
• analytické metody (např. HAZOPS, FMECA, FTA atd.);
• expertní přezkoumání, ověřené postupy.