Hodnocení železničních systémů podle Evropských standardů Doc. Dr. Ing. Tomáš Brandejský Ing. Martin Leso, PhD Fakulta dopravní ČVUT v Praze
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
Drážní zařízení Označení
Náplň normy
EN 50126
Stanovení a prokázání bezporuchovosti, pohotovosti, udržovatelnosti a bezpečnosti (RAMS)
EN 50129
Elektronické zabezpečovací systémy
EN 50128
Software pro drážní řídicí a ochranné systémy
Zajištění a prokázání vlastností
EN 50 126 • 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í
EN 50 128 • Software pro drážní řídící a ochranné systémy • Musí být užívána současně s EN 50 126 a EN 50 128 • Doporučuje kombinace technik • Vychází z IEC 61508-3, ale doplňuje některé specifické detaily železniční techniky
EN 50 129 • • • •
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
SIL • Safety Integrity Level • Definováno původně v IEC 61 508 • Tam je uveden i vztah k THR
Hodnocení bezpečnosti drážního systému • • • •
EN 50 129, kap. 5 Doklad o řízení jakosti Doklad o řízení bezpečnosti Technická zpráva bezpečnosti
Doklad o řízení jakosti • Dokladuje napĺnění požadavků EN 50 126 • Jednoznačné důkazy, že zařízení je navrženo a provozováno v souladu s EN 50 126 • Životní cyklus dle 50126 – 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
Doklad o řízení jakosti
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 50 126, 128 a 129 • Řešení je převáděno na dodavatele, což způsobuje na obou stranách finanční ztráty
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
Doklad o řízení bezpečnosti • EN 50 129, 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 50 126 • 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í
Technická zpráva bezpečnosti • Definuje EN 50 129, 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
Začlenění vývoje SW do procesu vývoje celého systému • Provázanost současné řady norem EN 50 126, 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ý
Začlenění vývoje SW do procesu vývoje celého systému • Norma EN 50 128 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).
Situace je ještě horší • Norma EN 50 128 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í
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“
Začlenění LC SW do LC aplikace • První etapa LC dle EN 50128 musí následovat až po 4. etapě LC dleEN50126 • Životní cyklus dle EN 50126 pak pokračuje etapou návrh a zavedení, které v normě EN 50128 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
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
2. Rozpor – zavádění systému • Norma 50128 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 50126 pokládá za následující kroky: • Návrh a zavedení • Výrobu • Instalaci • Validaci systému • Přejímku • Provoz a údržbu
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“.
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.
Děkuji za pozornost
