4.10.2017 Testování a certifikace zařízení odbavovacích a informačních systémů ve veřejné dopravě Ing. Milan Sliacky

Osnova Úvod do certifikace Procesní model – zúčastněné strany Procesní model – vztahy Certifikace – základní procesy Certifikace – předpoklady Certifikace – ukázky vybraných dokumentů Testování v laboratoři – výhody

Certifikace – smysl a definice 4.10.2017 Certifikace – smysl a definice Smysl certifikace: zajistit, aby zařízení daného typu korektně fungovalo v rámci daného systému. Pozn.: v případě existence standardu zajišťující interoperabilitu mezi různými systémy EOC je cílem certifikace zajistit tuto interoperabilitu. Obecná definice: ověřit a deklarovat shodu testovaného zařízení se stanovenými standardy (= technickými specifikacemi). standard – definovaný předpisem, nebo jen obecně akceptovaná pravidla, parametry, vlastnosti, funkce, procesy, …

Certifikace – způsob provedení formou tzv. ověřovacích testů ověřuje se zařízení konkrétního typu (k certifikaci) ověřuje se vůči standardům (platným pro daný systém) Druhy testů: laboratorní na testovacím systému případně s pomocí vhodných testovacích nástrojů a/nebo provozní (na reálném systému) na odstaveném vozidle (v depu) na vozidle zařazeném do běžného provozu

Certifikace – požadavky Věrohodnost (důvěra k výsledkům certifikace) Ověřovací testy nezávislým subjektem Oddělení procesu testování a certifikace Jednoznačnost (ověřitelnost a transparentnost testů) podrobná dokumentace (postupy, návody, scénáře) ověřování vůči stanoveným standardům Opakovatelnost (garance výsledků) ověřovací testy samotných postupů testování (validace postupů) podrobný protokol o testování (s uvedením všech relevantních údajů)

Certifikace – specifika 4.10.2017 Certifikace – specifika U některých druhů testů nelze ověřit všechny případy, které v praxi mohou nastat, výsledek certifikace proto nemůže garantovat stoprocentní funkčnost testovaného/certifikovaného zařízení ve všech případech, které mohou v reálném provozu nastat. Příčiny: složitost problematiky – např. existuje mnoho variant datových nosičů, profilů cestujícího, jízdních dokladů, nastavení palubního počítače neúplnost vstupních informací – není např. znám zdrojový kód SW palubního počítače – přistupuje se k němu proto jako k tzv. černé skřínce (blackbox) složitost roste geometrickou řadou 2 nosiče (Klasik, Desfire) 4 profily (student, dospělý, zaměstnanec, dárce krve) 3 druhy jízdního dokladu 24 testů

Standardizace – stávající stav množství proprietárních technických specifikací jednotlivá zařízení jsou vzájemně nekompatibilní technické specifikace nejsou veřejně dostupné Pro certifikaci to znamená testovat resp. ověřovat velké množství standardů (s tím souvisí příprava scénářů, metod, postupů a také HW a SW). Ideální resp. cílový stav: Existence několika málo všeobecně uznávaných nebo závazných standardů (bez duplicit), vůči kterým pak lze ověřovat efektivně.

Standardizace – VDV 301 (IBIS IP) Adaptace mezinárodní normy VDV 301 (IP protokol pro vozidlovou sběrnici) pro prostředí ČR. Aktivně řeší ROPID ve spolupráci s CDV a dalšími partnery.

Procesní model – přímo zapojené strany 4.10.2017 Procesní model – přímo zapojené strany Garant standardu (GS): Garantuje a zároveň vyžaduje dodržování standardu Provozovatel systému: dopravní podnik, koordinátor IDS, Standardizační entita (SE) Ověřovací pracoviště/laboratoř (OL): Subjekt provádějící ověřovací testy v laboratorním prostředí Žadatel o certifikaci (Ž): Subjekt, který formálně podává žádost o certifikaci Dopravce (D), dodavatel (DO), výrobce zařízení (VZ) zkušenosti s PMDP: Ž = VZ !!!

Procesní model – vztahy 4.10.2017 Procesní model – vztahy Garant standardu Žadatel o certifikaci a) Ověřovací laboratoř b) c) d) Možnosti uspořádání vztahů: GS uděluje certifikáty a provádí testy - stávající stav GS uděluje certifikáty, testy zadává OL OL provádí testy přímo pro Z, ale certifikáty uděluje GS OL provádí testy i uděluje certifikáty

Procesní model – vztahy – porovnání variant 4.10.2017 Procesní model – vztahy – porovnání variant Var. Výhody Nevýhody A Jednoduché pro Ž (komunikuje pouze s jedním subjektem) Náročné pro GS (testy, certifikace, administrativa) chybí nezávislé ověření B Nezávislé ověření prostřednictvím OL Méně náročné pro GS (administrativa s Ž, uděluje certifikát, neprovádí testování) C Výhodné pro GS (pouze uděluje certifikát) Výhodné pro OL (pouze ověřuje) Provozní testy provádí přímo GS Složitější pro Ž (komunikuje se dvěma subjekty) D Výhodné pro GS (pouze podpora OL) OL musí posoudit splnění kritérií pro udělení certifikátu – může být složité Problém s provozními testy Menší garance nezávislosti (pouze 1 subjekt) nejvýhodnější

Certifikace – smluvní vztahy – cíle Vztah OL - GS: garantovat součinnost GS vůči OL při činnosti laboratoře garantovat závazek OL provádět ověř. testy pro GS garantovat součinnost OL vůči GS při udělení certifikátů vhodná forma: smlouva (o spolupráci) Vztah Ž – OL: garantovat závazek OL realizovat zakázku pro Ž garantovat závazek Ž poskytnout součinnost pro OL garantovat závazek Ž vůči OL zaplatit sjednanou cenu vhodná forma: nabídka + objednávka Vztah Ž – GS: závazek GS k udělení certifikátu na základě úspěšně provedených testů vhodná forma: závazné prohlášení na webu

Strany nepřímo zapojené do certifikace Autor standardu: konzultační role (v případě specifických situací), rozvoj standardu (přidání nových funkcí) Dodavatelé/výrobci dalších zařízení: částí ověřovacího systému (u EOC např. kontaktní místo, clearing, …) ověřovacích nástrojů (SW pro monitoring komunikace pro sběrnici, SW pro vyčtení obsahu bezkontaktní čipové karty, …) další zařízení zapojená v systému (v případě tzv. křížových testů obdobná zařízení jako testované, ale od jiných výrobců, v případě testovaných sestav např. infopanely, …)

Nepřímo zapojené strany – vztahy 4.10.2017 Nepřímo zapojené strany – vztahy Garant standardu Žadatel o certifikaci Ověřovací laboratoř Autor standardu Další dodavatel 1  Další dodavatel n Nutná vazba Existující vazba Doporučená vazba S ohledem na složitost vztahu OL s dalšími dodavateli je vhodné křížové testy provádět až u provozních testů. U laboratorních testů je lepší se soustředit na ověření maxima možných variant, nastavení, druhů nosičů apod. Pozn.: doporučená vazba slouží pro urychlení (a zlevnění) procesu certifikace.

Ověřovací laboratoř a interoperabilita EOC 4.10.2017 Ověřovací laboratoř a interoperabilita EOC Ověřovací laboratoř VaV projekt TB0100MD008 - Interoperabilita a standardizace systémů elektronického odbavení cestujících ve veřejné dopravě, r. 2014 Konečný stav migrační fáze Standardizace EOC, zdroj: VaV projekt TB0100MD008

Základní procesy certifikace (varianta C) 4.10.2017 Základní procesy certifikace (varianta C) Provedení zkoušky (forma komerční zakázky) První zkouška (Ž – OL) Opakovaná zkouška (Ž – OL) Udělení certifikátu (ze strany GS): přezkoumání protokolů (Ž – (OL) – GS) provozní testy (Ž – GS) udělení nebo rozšíření *) certifikátu (Ž – GS) Provozní procesy OL: Pravidelné ověřování shody testovacího prostředí vůči standardu (OL – GS) Akreditace OL ze strany GS (OL – GS) Příprava nových metod a postupů (OL – GS) *) pro rozšíření certifikátu mohou být provozní testy dostačující

Certifikace – předpoklady 4.10.2017 Certifikace – předpoklady Aby mohla být vyžadována povinnost certifikace (ze strany GS), musí být stanovena: zařízení/periferie, které jsou předmětem certifikace požadované konfigurace/sestavy těchto zařízení testované parametry, vlastnosti, funkce nebo procesy akceptovaný rozsah hodnot měřených parametrů, popsány vlastnosti, funkce nebo procesy parametry testovacího prostředí certifikační testy (scénáře, metody, postupy) postup certifikace a role jednotlivých stran Povinnost certifikace musí být vyžadována smluvně! Kdy začít vyžadovat certifikáty: V rámci VŘ na nového dopravce – součástí nových smluv Nebo u stávajících dopravců v okamžiku prodloužení stávajících smluv

Příklady definovaných periferií - PID 4.10.2017

Příklady definovaných vlastností/funkcí - PID 4.10.2017

Postup certifikace periferie - PID 4.10.2017 pro všechny přímo zainteresované strany (Ž, OL, GS)

Výhody testování v laboratoři úspora času (a nákladů) vše na jednom místě a pod jednou střechou testování na laboratorním systému eliminováno riziko vzniku škod na reálném (živém) systému možnosti specifických úprav lab. systému (simulace kolizních stavů) „neomezené“ možnosti testování kombinací/variant vst. podmínek Laboratoř OIS na FD ČVUT

Děkuji za pozornost Ing. Milan Sliacky vedoucí Laboratoře OIS, FD ČVUT sliacky@fd.cvut.cz www.fd.cvut.cz, www.ois.fd.cvut.cz Mobil: +420 603 842 727 Tel.: +420 224 359 975 Konviktská 20, 110 00 Praha 1