Výpadek ETCS podrobně: Unikátní chyba se řešila až v Kanadě, prodloužila život návěstidlům
Technologie ETCS. Pramen: ČD - Telematika
Dozvuky sobotního kolapsu na železnici: Návěstidla zůstanou nejméně do roku 2027.
Dozvuky sobotního kolapsu na železnici: Návěstidla zůstanou nejméně do roku 2027.
To jaké mají SLA na ECTS? Kritická infrastruktura mívá na úrovni sítě 99.99 uptime, v energetice klidně i víc devítek.
Každopádně i “pouhých” 99.9 by dovolovalo 43 minut během jednoho měsíce. Jestli přes 4h jsou ok, tak SŽ nemá vůči Telematice ani 99.0%, to čumím :O
5 hodin výpadku se vejde do SLA a dodavatel unikne sankci. To si snad děláte srandu. Autorovi smlouvy přijde normální, že 5 hodin nefungují páteřní tratě? Takové SLA bych čekal u mobilní aplikace do supermarketu, ne u klíčového prvku ETCS…
to je tak, když se spoléhá na nespolehlivé systémy
systém GSM moc spolehlivý není, ovšem životy v civilním sektoru na něm nezávisí – ale tady už je to něco jinýho
nikdy se to nestalo je jak §1 vždycky se to tak dělalo
a ve válečným stavu to bude jedna z prvních věcí, co přestane fungovat
Chápu správně, že se rozbil server a současně nezávisle na tom vypadlo GSM-R?
On to hlavně nebyl první výpadek GSM-R.
Stalo se mi několikrát, že člověk jede, výpadek napájení nebo cokoliv, zmáčkne 2 (volá přímou volbou na GSM-R dispečera/výpravčího) najednou se ozve, volaný účastník není dostupný, zavolejte prosím později.
Jednou mi sami dispečeři z CDP Praha potvrdili, že když se přepínalo z PPV na CDP Kolín, tak se hodinu nedalo dovolat jinak než mobilem. GSM-R fungovalo, ETCS taky, ale na „velín“ se člověk prostě nedovolal.
Není GSM-R jako GSM-R, rádiová síť a data pro ETCS jsou oddělená.
Tak jak teda… Jeden říká že Šlo o chybu v databázi registrace vlaků v systému ETCS, jiný že nefungovalo spojení GSM-R….
1. nefungovalo spojení GMS-R (takže v Mostě,Praze,Děčíně…)Tam ETCS není, jen se radiostanice nemohla zaregistrovat a jelo se na náhradní spojení max 100 km/h.
2.na tratích s ETCS se navíc neaktivoval zabezpečovač, protože nedostal data z RBC, která jdou po GSM-R. Jízda podle návěstidel, na náhradní spojení(mob. telefon) rychlost max. 100 km/h.
Jeden by čekal, že u tak kritického systému bude záloha N+1. vypadne Praha, v řádu milisekund přebírá práci záloha v Přerově.
Tipuju, že Praha se tvářila jako funkční, ale reálně nebyla. Čekal bych, že bude někdo do 15 minut na telefonu, kdo dá autorizaci k přepnutí na zálohu.
a tady jim to přepnutí trvalo 5 hodin. je to většinou první věc, co se udělá, když primární systém nefunguje a neví se nic. takových překvapení ve čtyři ráno jsem zažil celou kariéru..
jednou se to dá pochopit. I my máme v práci takové 100 % zaručeně zálohované systémy a pak si někdo nevšimne, že už je špatná baterie v UPS a lehne to. Ale po takovém výpadku by mělo být přijato natolik robustní opatření, aby se to už neopakovalo. Na druhou stranu, pokud DB přestane ukládat data, systému by měla za krátký moment chybět.
Čistě technicky – bez zpětné vazby neřídím, ale jen ovládám.
No s těma milisekundama bych šetřil. Kontrolovat ze server žije každou milisekundu je blbost. A ještě větší přepínat na zálohu při prvním ztraceném paketu. Taky je potřeba mít jistotu že opravdu umřel server a ne něco po cestě aby pak nezůstaly aktivní oba.
Zrovna tohle není vůbec jednoduchá úloha. Protože vy v tu chvíli potřebujete mít jistotu, že Praha opravdu kompletně vypadla a není nikdo, kdo by jí poslouchal. Pokud by půlka vlaků poslouchala Prahu a půlka Přerov, průšvih by byl takřka jistý.
Proto se to v takových situacích přepíná ručně po té, co se ten odpadlý systém ještě ručně bezpečně odpoví a ověří se, že je opravdu odstaven.
Automatický přechod je také možný, ale rozhodně ne jen se dvěma uzly.
Měl jsem za to, že střediska se zrcadlí. Že v každý moment dělají totéž.
Takže absolutně neví co bylo příčinou, jenom přehráli SW. Přepnutí do Přerova bych čekal v řádu minut, ne hodin. Výměna HW je zoufalost podpory, která neví, co se stalo.
„v řádu minut, ne hodin“ – Třeba to přepnutí bylo v řádu minut, ale řád hodin si vyžádalo nalezení příčiny…
Přepnutí na zálohu v Přerově bylo v řádu hodin. Přepnutí se počítá od prvního zaznamenaného problému, po plné funkčnosti na zálohu.
to by jim to buď 1) začalo znova jezdit nebo 2) stala se ta stejná chyba znovu.
vzhledem k tomu, že v článku se píše, že to přepnuli, a pak to začlo fungovat.. bylo to o dost později.
Jojo GSMR server v Praze a Přerově, ale co takhle kápnout božskou, kde se nachází to hlavní. Možná by se mnozí divili. Pak si tady budeme hrát na zabezpečení a všude se chvástat že je to absolutně dokonalé.
Tak hlavně že si podrž pera rozdaly odměny,teď by ty odměny za ten bordel měly rozdat cestujícím ale na ty se SZ vykasle že co pane svobodo z Dlouhé Třebové ulice niva 437 dva baráky za 60 000 000 Kč ostudo
Odmena za uspesne zavedeni. Zavedeno to bylo.
Ted bych dal druhou odmenu, za uspesne zavedeni nahradniho rizeni 😀
Docela dobře si umím představit, že se něco takového stane, jen tedy jsem docela překvapený, že se nepřepnulo na Přerov mnohem dřív (nebo fakt RCA trvala pět hodin a do té doby nikdo ani netušil?).
A taky jsem tak nějak doufal, že ETCS L2 bude mít nějaký fallback na L1, což očividně neplatí. Ale fajn, vyšetřilo se, jdeme dál.
Jo a k tomu „Sobota představuje vypravení 6625 vlaků, zpožděno jich bylo jen 238″… takže bonus bude jen 96 %? 🙂
L1 používá přepínatelné balízy napojené na SZZ. L2 má jen pevné. Teoreticky to jde udělat, ale výrazně vzroste cena a složitost
A proto se na pravobřežku plánuje L0.
Šetřit se musí, ať to stojí co to stojí.
Co je to za nesmysl? L0 znamená že není žádné zabezpečení…
Pak by to vlastně bylo „L1 s benefity.“
Beru, díky za doplnění.
Tak nějak intuitivně jsem bral to označení „level“ jako určitou indikaci principu progressive enhancement, ne jako zpětně nekompatibilní generaci.
Pokud to připodobníme k současným zabezpečovacím zařízením (tam musíme do Německa, my žádné nemáme) tak L1 je funkčně podobné PZB a L2 LZB. Je to samozřejmě hodně velké zjednodušení. Tím, že u L2 je přenos trvalý, musí být přenosový kanál daleko složitější. Na druhou stranu se všude chce šetřit, takže nikdo neduplikuje tyto kanály.
L1 je funkčně podobné L2, pouze si informace bere bodově z přepínatelných balíz. S PZB je podobný fakt jen ten bodový vstup informací.
„A taky jsem tak nějak doufal, že ETCS L2 bude mít nějaký fallback na L1, což očividně neplatí.“
Používá se to tak na VRT-ce v Belgii – viz níže:
„In 2003 the SNCB selected a consortium to supply ETCS for the next high-speed lines with Level 2 and fallback with Level 1“
Zdroj: https://en.wikipedia.org/wiki/European_Train_Control_System
Něco mi tu nesedí:
1) Šlo o chybu v databázi registrace vlaků v systému ETCS
2) Firma preventivně vymění pražské servery, přestože jsou teprve v polovině životnosti.
Když je chyba v SW, tak řešením je vyměnit HW? Cože?
To mě taky zaujalo, HW chyba prostě buď je, nebo není. Servery nejsou nějaké rezavé trubky, aby se vyplácelo je „preventivně“ měnit. Nehledě na to, že každé pořádné datacentrum funguje tak, že nějaká jednotlivá chyba konkrétního HW prvku nezpůsobí kompletní kolaps a jde ji zpravidla opravit za běhu. Moc nevím, jaký typ problému by se jevilo adekvátní řešit „preventivní výměnou“.
Trochu mi to zní, že buď bylo příliš zjednodušeno nějaké vyjádření, a půjde o SW věc, nebo se dodavatel snaží krýt nesouvisejícím úkonem.
Dál jen další potvrzuje SW problém.
„Chyba se odehrála na plně aktualizovaném serveru, proto bylo těžké odhalit příčinu. Došlo k přehrání softwaru systému, je tak plně funkční i v Praze,“ uvedl Hobza.
Tzv zoufalost podpory, která se snaží vypadat, že něco dělá.
Člověk by čekal že takto kritický důležitý systém bude plně redundantní a dojde k automatickému přepnutí na záložní lokalitu v případě problémů s primární. A ne že to musí někdo udělat ručně po 5 hodinách…
Ale ono to je redundantní. Problém byl, že diagnostika neodhalila, že ten primární systém nefunguje správně a tím pádem se nic nepřeplo.
To je pak špatné, když to neumožňuje rychlé „ruční“ přepnutí. Co když se mi do jednoho systému někdo nabourá a potřebuji tu redundanci odpojit a pustit jen jeden systém. Druhá věc je zda nedej bože nejsou redundantní systémy postavené na stejném SW a stejně naprogramované, případně jen zrcadlené.
Vy víte co tam bylo za problem a proč ta diagnostika nezafungovala a tvářila se, že je všechno v pořádku? Nevíte, tak neplácejte blbosti. Tam se může stát milion věcí. I to co si nedovedete vůbec představit a co ani nedokážete v testech nasimulovat.
O to nejde. Jde o to , proč trvalo hodinu to přepnout. Toho si nikdo nevšiml? Hodinu?
vysvetlwno, proc to (ne)trvalo hodinu, mate dole.
Pochopitelně že to bude na stejném SW. Dokážete si představit tu pakarnu, že by to běželo na různých softwarech? A co se týče dat, tak změny z „živého“ je potřeba co nejrychleji dostat na zálohu.
Dokážu, ono se to u důležitých SW tak i dělá, dokonce mají i skupiny programátorů zakázáno i mezi sebou komunikovat, aby nenapsali něco naprosto stejně a při vší smůle s chybou. Ono by nebylo milé, pokud by selhalo něco reduntantního např. v primárním okruhu reaktoru.
Jenže tohle není primární kruh reaktoru.
Tuto pakarnu si neni treba predstavovat. Takhle to funguje na statnich uradech. Kazdy ma svuj vlastni, navzajem nepropojitelny system 😀 Proto tam musime nosit papiry.
Ne, rychlé přepnutí fakt nechcete. U přepnutí potřebujete hlavně aby bylo spolehlivé, aby byla opravdu jistota, že velí jen jeden. Určitě nechcete, aby z Prahy dostal jeden vlak povolení na jednu kolej a na tu samou kolej by dostal z Přerova povolení jiný vlak v protisměru.
Já naopak doufám, že na to přepnutí je jasně definovaný postup, ve kterém je dost času na prověření, že pražská strana je opravdu bezpečně odpojená a i kdyby zázračně ožila, je izolovaná od řízení.
Tohle jsou naprosté kecy, pardon. Všechno, co je důležité má 24/7 monitoring – jak systému, tak skutečné funkčnosti – operátora, co sleduje parametry systému a v momentě kdy se objeví chyba, volá kompetentního administrátora, co drží pohotovost. Takhle to funguje v každé normální telekomunikační společnosti.
„Jenom“ 236 zpožděných vlaků + samozřejmě to schytaly také obraty, ale tam už SprŽel nezapomněla hlásit „z provozních důvodů dopravce,“ což bude také ve statistikách, takže se jako obvykle vlastně nic nestalo a není důvod si za nějaký čas zase nepřidat nějaké ty odměny 🙂 #mynic
Prosím, netušíte někdo, proč pod národním zabezpečovačem bylo možné jezdit jen 100 km/h? Vždyť před zavedením ECTS se jezdilo i s ním běžně až 160 km/h. Či jak to je?
Výpadek GSM-R jako základního spojení. Proto se jezdilo pouze 100 km/h.
Ale vždyť podle té zprávy výpadek GSM nebyl. Problém byl jinde.
Takže proč se jezdilo 100?
Podle všeho GSM signál fungoval, vozidlová rádiostanice se přihlásila do BTS ta to přijmula zpracovala a poslala na server, ten ale při dotazu na registraci (uložení do DB) neodpověděl, přitom celý server jako HW fungoval, SW mu běžel, jen DB neodpovídala. A teď spekulace proč? Zátěž, teplota, nějak nový bug v architektuře, těžko soudit…
To myslím všichni chápou. Nikdo se neptá, proč se zhroutila databáze.
Otázka zní, proč se jezdilo 100 a ne 160km/h.
Taková lehce doplňková otázka zní, proč nejezdily náklady, když fugoval autoblok a všechny vlaky jezdily 100km/h?
Protože v callcentru nebylo dost lidí…
Vždyť máte odpověď na to, proč se jezdilo jenom 100 km/h hned nad svou zprávou od Brama.
GSM-R se používá jako základní spojení. Při jeho výpadku (který v sobotu byl) se používá nouzové spojení v podobě mobilu strojvedoucího. A při výpadku základního spojení a použití nouzového je rychlost vlaku omezena na maximálně 100 km/h. To platilo i dávno před zahájením výhradního provozu ETCS, se kterým to vůbec nesouvisí.
Jenže některé vlaky (stávající) spojení měly jen je zastavilo ETCS tak proč nemohly po vypnutí ETCS dál 160.
Jestli se nepletu, tak záleží jestli jde o výhradní, nebo smíšený provoz. Ve smíšeném provozu jde po sepsání rozkazu jet max 160 s kódem. Ve výhradním provozu max 100.
To není pravda. Max 100 km/h se jezdilo i z Prady do Děčína, Ústí do Chebu,kde není výhradní, ani nevýhradní provoz- ETCS tam není.
To nevylučuju. Odpovídám jen na otázku proč i s funkčním zaregistrovaným GSM-R může být omezena jízda na max 100.
problém je v tom, že se jezdilo na nouzové spojení, kdyby existovalo náhradní spojení, tak se rychlost neomezuje
Podle mě dispečeři provozu nepochopili že se jim vlaky tím pádem sjednotí a nikdo by nikoho nezdržoval…
Já jsem cestou že Zábřehu do Otrokovic viděl minimálně 3 nákladní vlaky.
Stovkou se jezdilo na všech tratích, kde je základní spojení GSM-R. To je z důvodu předpisu , který říká, že pokud vlak jede na náhradní spojení, je rychlost omezená na 100 km/h i na tratích bez ETCS.
Jinak GSM-R fungovalo, ale radiostanice se nemohly přihlásit-Chyba registrace.
Náhradní, nebo nouzové spojení?
Ve zkratce: při nefunkčnosti základního rádiového spojení nařizuje předpis Z11 neepřekročit rychlost 100 km/h.
Ale kdyby sis přečetl článek, tak GSM (základní spojení) fungovalo. Šlo o chybu v databázi registrace vlaků v systému ETCS.
Takže odpovídáš sice dobře, ale úplně mimo.
GSM fungoval, jenom GSM-R né. Nešlo se zaregistrovat, jezdilo se na nouzové spojení, mobil strojvedoucího. S všemi důsledky nouzového spojení, dneska byl použitý generální stop u rychlíku mezi Budějovicemi a Brnem, v nouzovým spojení zavolá výpravčí na mobil strojvedoucímu ať zastaví…
jenže tam je TRS a ne GSM-R
To jo, a kdyby nebylo funkční trs?
Navíc jsem se snažil vysvětlit, co je nouzové spojení.
Jenže to se tam nepíše. Píše se tam, že GSM-R fungovalo zpočátku jen pro už zaregistrované vlaky. Pro ostatní nefungovalo ETCS proto, že se nemohli zaregistrovat do GSM-R (takže logicky nefungovalo ani jako mobilné spojení).
Ale ten problém byl, že se nešlo registrovat do GSM-R – a že nešlo navázat spojení ETCS s RBC (přes GSM-R) byl až de facto sekundární důsledek, ne?
Já si užíval volný víkend, tak nevím, rád se dozvím.
Jedna funkce GSM-R selhala a tudíž je nutno k celku přístupovat jako k nefunkčnímu. Dispečer ný musel mít nějakou pozitivní zadokumentovánou informaci o tom, že spojení s vlaky přes GSM-R je plně funkční a spolehlivé. Pokud ji neobdrží, pak musí dodržet postupy pro nefunkční základní spojení. Otázky stále jsou, ale úplně jiné než ty vaše.
Potom ano máš pravdu ty stávající registrované vlaky by tedy mohly 160 a ty nové jen 100, ale protože už to všechno stálo tak zavedli 100 pro všechny.
Před pátou ranní těch vlaků bylo zaregistrováno jen pár, problém postupně bobtnal, jak přibývalo nezaregistrovatelných vlaků.
Tak beru vše zpět. Podle toho vyjádření „Šlo o chybu v databázi registrace vlaků v systému ETCS“ jsem nabyl dojmu, že radiostanice fungovaly a byl problém jen s připojením terminálů ETCS.
Ale teď jsem zjistil, že nešly ani radiostanice.
Četl jsem článek pořádně a toho rána jsem se nemohl přihlásit do GSM-R na dvou různých strojích-tudíž pro mě nebylo funkční základní rádiové spojení i když na RDST signál GSM-R byl. Proto mi i diktovali rozkaz, že náhradní spojení bude VOS 12 a nouzové 972 … dle TTP… Takže základní spojení nefungovalo!
pokud by bylo zřízeno náhradní spojení, tak se rychlost neomezuje, ovšem, náhradní spojení na většině tratí zřízeno není, tak se jezdilo na nouzový, a to už rychlostně omezený je
protože neexistuje náhradní spojení a je jen nouzový
Hezky to manekýn okecal a rozumbrada též.
K výpadku došlo těsně po páté hodině, v 6:05 bylo převedeno řízení provozu na původní návěstidla…
Někomu trvalo hodinu, než zjistil, že nejde spojení a přepnul to? Při dvou dohledových centrech, kde je nonstop několik lidí? Není něco špatně? Pochopím deset minut, ale tohle?
Ne, hodinu prepnuti netrvalo. ono v pet rano ten “dopad” nebyl nejspis tak velky, aby to hned prevadeli na navestidla.
pokud nejsi totalne ve “srajdach”, tak take nechas system bezet a snazis se o diagnostiku naprimo – protoze to muze byt klidne nejaka blbost “na pet minut” a krom toho, diagnostika se ti take dela snadneji na systemu pod zatezi.
pokud jim v prubehu hodiny doslo, ze problém je zasadnejsi, tak to prepli.
Já tomu rozumím, jen bych si provozuschopnost takového systému, jako je železnice, představoval asi o něco vyšší…
Tak tohle mi přijde mimo realitu. První věc je přepnout na zálohu, pokud se to už neudělalo automaticky. Debugging ideálně výlučně na systému mimo produkci.
Debugging bych do toho vůbec nepletl. Ne v prvních hodinách. Nejdřív se musí jít vrstvu po vrstvě dolů, nejlépe pod „normální“ zátěží, a zjišťovat ve které vrstvě se co nepovedlo. Jinak můžete jít také do Národní knihovny se zadáním: „V nějaké knize jsou v nějaké větě přehozená dvě slova nebo jiná podobná chyba. Opravte to.“
Debugovat na produkci? Tohle jde snad jen u garážových eshopů a státní správy…
diagnostika != debugging
Nic se nikam nepřepínalo. Návěstidla dosud fungují neustále, nezávisle na tom, zda je k dispozici ETCS. Pouze někomu trvalo delší dobu rozhodnout, že se bude jezdit dle návěstidel, protože jde o problém, který se během pár desítek minut nevyřeší.
Neškodilo by provést malé blackout cvičení. Jak dlouho bude GSM-R fungovat při blackoutu. Jak budou jezdit motorové vlaky s pohonnými hmotami a uhlím a když se zbavíme návěstidel ? Jak dlouho budou fungovat návěstidla bez elektřiny atp. Jsou to otravné detaily a můžeme na to ošklivě dojet v případě rozsáhlejšího problému – třeba v případě války.
Ono ta sobota se jako cvičení dá brát. Za mě je reakce v pořádku, ty 3 roky to s návěstidly zvládnem pak se uvidí. Možná máme štěstí že takový relativně neškodný výpadek nastal takhle brzo. Stát se to za dva roky bez návěstidel a v pracovní den, bylo by to mnohem horší.
Železnice je bez elektřiny nepoužitelná, na to nepotřebujeme cvičení 😂😂
Bez elektřiny není použitelné nic, ani silniční doprava, zažil jsem kolaps jedné křižovatky v Ružomberku. Stálo to asi hodinu a protože jsem byl druhé auto u světel jel jsem pak sám 80 km po zasněžené dálnici na Poprad.
V dnešní době už tomu tak je, ale dokud nebyly nádraží „duchů“ tak to vždy šlo nějak udělat. 🙂
povolenky před pár rokama zrušili
V případě války bude nejodolnější železnice postavená na bateriových HV nabíjených denně (nikoli ovšem nočně) ze solárek v co nejvíce stanicích. Kam se hrabe zásobování naftou upravovanou kdoví kde na jednom místě z ropy dovážené kdoví odkud.