Hodnocení železničních systémů podle Evropských standardů. Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze

Transkript

1 Hodnocení železničních systémů podle Evropských standardů Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze

2 Obecné požadavky Přechod do bezpečnějšího stavu při poruše Náhodné (vada materiálu, vnější vlivy) a systematické poruchy (chyby návrhu) Životní cyklus Mikroprocesorové systémy RAMS

3 Drážní zařízení Označení EN Náplň normy Stanovení a prokázání bezporuchovosti, pohotovosti, udržovatelnosti a bezpečnosti (RAMS) EN EN Elektronické zabezpečovací systémy Software pro drážní řídicí a ochranné systémy Zajištění a prokázání vlastností

4 EN definování procesu managementu řízení bezporuchovosti, pohotovosti, udržovatelnosti a bezpečnosti Vychází z ISO 9000 Nezabývá se vlastním návrhem zařízení

5 EN Software pro drážní řídící a ochranné systémy Musí být užívána současně s EN a EN Doporučuje kombinace technik Vychází z IEC , ale doplňuje některé specifické detaily železniční techniky

6 EN HW železničních systémů Doporučuje některá řešení Definuje požadavky na tyto systémy a Prokázání bezpečnosti HW části systému

7 SIL Safety Integrity Level Definováno původně v IEC Tam je uveden i vztah k THR

8 Hodnocení bezpečnosti drážního systému EN , kap. 5 Doklad o řízení jakosti Doklad o řízení bezpečnosti Technická zpráva bezpečnosti

9 Doklad o řízení jakosti Dokladuje napĺnění požadavků EN Jednoznačné důkazy, že zařízení je navrženo a provozováno v souladu s EN Životní cyklus dle vodopád Činnosti, role a organizační struktura Definované postupy, systém řízení jakosti Verifikační a validační procesy Jednoznačná zodpovědnost za etapy

10 Doklad o řízení jakosti

11 Doklad o řízení jakosti Problematická role provozovatele Má plnit první 4 etapy životního cyklu Koncepce Definice systému a podmínky použití Analýza rizika Požadavky na systém Struktura provozních předpisů z historických důvodů neodpovídá struktuře norem EN , 128 a 129 Řešení je převáděno na dodavatele, což způsobuje na obou stranách finanční ztráty

12 Doklad o řízení jakosti Hodnltilel bezpečnosti nezávislé hodnocení Orgán pro otázky bezpečnosti národní orgán Problém neúplné definice kompetencí Českého drážního úřadu ve stávající legislativě, který proto funkce orgánu pro otázky bezpečnosti nemůže vykonávat

13 Doklad o řízení bezpečnosti EN , kap. 5.3 definuje strukturu a náplň Má dokládat trvalé řízení bezpečnosti Vlastní proces řízení bezpečnosti je devinován v normě EN Musí být definována Organizace bezpečnosti Plán bezpečnosti Záznamy o nebezpečí Specifikace požadavků na bezpečnost Plán bezpečnosti Plán ověřování

14 Technická zpráva bezpečnosti Definuje EN , kap. 5.4 Člení se na kapitoly Úvod Zajištění psrávné fukce za provozu Vliv poruchových stavů Provoz s vnějšími vlivy Podmínky použití vztahující se k bezpečnosti Provozníověření bezpečnosti

15 Začlenění vývoje SW do procesu vývoje celého systému Provázanost současné řady norem EN , 128 a 129 není dokonalá Především není jasně definované postavení životního cyklu vývoje SW v životním cyklu vývoje systému Ve všech normách je užíván životní cyklus typu water-fall, který je z praktického hlediska velmi problematický

16 Začlenění vývoje SW do procesu vývoje celého systému Norma EN pouze požaduje následující vstupní dokumenty Popis architektury systému (viz EN 50129, příloha B.2.1), Plán bezpečnosti (viz EN 50129, EN 50126), Specifikace požadavků na systém (viz EN 50129, příloha B.2.3.), Specifikace požadavků na bezpečnost systému (viz EN 50129, příloha B2.4).

17 Situace je ještě horší Norma EN se neodkazuje na konkrétní dokumenty, ale na kapitoly TZB Nejsou definovány etapy LC, kdy mají jednotlivé části TZB vzniknout TZB totiž vzniká až do 6. etapy návrh a zavedení

18 Návrh řešení Plán bezpečnosti - 2. etapě Definice systému a podmínky použití Popis architektury systému - 4. etapa Požadavky na systém (pod názvem funkční struktura) Specifikace požadavků na systém - 4. etapa Požadavky na systém Specifikace požadavků na bezpečnost systému 4. etapa Požadavky na systém

19 Začlenění LC SW do LC aplikace První etapa LC dle EN musí následovat až po 4. etapě LC dleen50126 Životní cyklus dle EN pak pokračuje etapou návrh a zavedení, které v normě EN odpovídají etapy 8 specifikace požadavků na SW 9 architektura SW 10 návrh a realizace SW 11 Ověřování a testování SW 12 Integrace SW a HW 13 validace SW

20 Začlenění LC SW do LC aplikace Smysluplnost paralelního vývoje HW a SW Je třeba definovat skutečný postup vývoje

21 2. Rozpor zavádění systému Norma považuje za následující kroky hodnocení SW, provoz a údržbu, o výrobě vcelku logicky nehovoří, neb u SW splývá s výrobou příslušného HW. Naproti tomu norma pokládá za následující kroky: Návrh a zavedení Výrobu Instalaci Validaci systému Přejímku Provoz a údržbu

22 Shrnutí S ohledem na značnou obecnost, částečně nejednoznačnost a nejednotnost předmětných EN norem je obtížné nalézt konsenzus mezi zúčastněnými stranami, zvláště vývojáři a assessory (hodnotiteli bezpečnosti). Je zapotřebí definovat alespoň na národní úrovni závazný výklad sporných ustanovení těchto norem v duchu známých britských yellow books.

23 Shrnutí Jedině tak lze zabezpečit bezproblémový přechod na nové, značně sofistikované a složité technologie, umožňující ale vyšší komfort i bezpečnost, protož teprve při schvalování těchto nových, komplexních systémů se z těchto dříve okrajových otázek se vzhledem k rostoucímu významu procesů a postupů pro výslednou bezpečnost systému stávají zásadní problémy.

24 Děkuji za pozornost