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.
Myslím, že bonusové odměny pro klíčové manažery SŽ 100-200 tis.Kč za zvládnutí tak náročných procesů jsou oproti jiným státním institucím /viz bonusy šéfů MOTOLA, ČEZu nebo třeba řadového poslance atd.) směšně nízké, a to nemluvím o soukr firmách, kde jsou v řádu hodně vyšších statisíců.
Dobrý stavbyvedoucí má leckdy roční odměnu i vyšší.
Neboli by si vedení SŽ, a to i na OŘ, zasloužilo větší uznání !
To do roku 2027 SŽ stihne vybudovať aspon druhú koľaj VoChoc, či napriklad aspon dalšiu tratovú koľaj alebo viac aspoň v niektorych usekoch alebo aspoň VRT Bechovice-Poříčany ? A pripade ďalšie odb. alebo výhybne po vzore Rajhradu, či Adamova na 1. a 2. TŽK? Teraz kapacitu zachraňoval „archaický a predražený AB s farbičkovačom“. A po roku 2027 pri akejkoľvek poruche ETCS/GSM-R (nielen tejto špecifickej ktorá vznikla teraz) už teda bude oproti súčasnosti po tých dvoch rokoch dostatočná kapacita pre núdzové prípady? Čo sa za tie necelé 3 roky zmení na sieti do tej miery, že teraz sa ešte traťové navestidlá… Číst vice »
Spíš to bude o tom že vyladí funkčnost ETCS / GSM-R aby se podobná chyba neopakovala, nebo upraví krizove procesy aby rychleji prepli na zálohu a mohli jet normálně.
Očekávám, že to dopadne tak, že se nakonec omilostní i oddílová návěstidla, ale zruší se LVZ, tedy dojde k nahrazení kolejových obvodů počítači náprav. Tady se hodně ušetří, stále ale půjde jezdit 100 km/h. Tedy se bude jezdit se zpožděním, ale jezdit se bude dát moci. Vzhledem k přebytku kapacity bych ale očekával, že oddílová návěstidla AB zmizí z úseku Benešov u Prahy – Tábor – Ševětín. Oddílová návěstidla už se zřizovat nově (vyjma úseku Radotín – Karlštejn) nikde nebudou. A naopak očekávám, že se přestane blbnout s modrobílým světem, který se konečně pošle do míst, kam slunce nikdy nesvítí.
Mohly jezdit jen 100 km/h? Ještě před třemi měsíci mohly jezdit podle návěstidel 160
Už to tady bylo několikrát. Pakliže nefunguje základní rádiové spojení (nešlo se zaregistrovat do GSM-R), tak se jezdí 100 km/h vždy.
…asi bez kódu, ne?
I s kódem. Nedá se dovolat = vmax 100. Aby v situaci, kdy výpravčí místo general stopu vytáčí fírův mobil, stihl ten mobil párkrát zazvonit.
Spolehlivost 99,1 %, to je hodně velká slabota.
Aktuálně činí 99,46 % a půjde to ještě určitě nahoru – minimálně do konce dubna budou probíhat úpravy technologie zab.zař. v úseku Pardubice – Česká Třebová.
Je to sice stále náběh i když se zavedl výhradní provoz a vyplatil odměny, sice jenom drobné 😜 Přesto bych pro rutinní provoz čekal aspoň 3 devítky a pro výhradní spíše 4.
Chyba v databázi, výpadek rádiového spojení a jako preventivní opatření náhrada serveru v půlce životnosti. Teď ještě vyměnit vodu v plovoucí podlaze a bude to dávat ucelený smysl.
O jakou přesně šlo chybu v databázi? Nějaké přetečení? Bug v databázi? Můžeme se to dozvědět?
Taky jsem se nic nedozvěděl. Chtějí vyměnit servery, takže je to hardwarová chyba? Nějaká redunadance systému nepomohla? Nebo je to jen chyba softwaru, případně nebyla správně hlídaná integrita stávajících dat? Přehrání pomohlo, takže harwdare by měl být v pořádku…
Pokud meli zalozni server v Prerove, proc trva 4 hodiny nez se udela failover na zalozni server?
Máte to v článku.
Jsem zvědavý jak tohle funguje třeba v Číně, že nefunkční železnice kvůli prkotině x hodin. Jestli management dostane taky miliony odměny nebo spíš basu.
On tomu pomohl i kolaps centrálních rozkazů, když zpravovací stanice mají vytisknout desítky nových rozkazů a ono ejhle, CR se kousnou a vytvoření jednoho rozkazu najednou trvá šest minut místo obvyklých nižších desítek sekund… Samozřejmě, psát/diktovat se dá i ruční rozkaz, ale i tam to trvá dlouho.
To ten signál vypadl jen u nás? Nebo má každý stát svůj?
Vraťte ty odměny, vy lemplové! Ne za ten výpadek, ale za těch pět hodin okna! NESKUTEČNÝ!!!
Vem si prášek.
Tak servery v Praze jsou v polovině životnosti,??? Vždyť se to teprve testuje. To tedy nemají dlouhou životnost
To jsou servry GSM-R. To funguje již několik let.
Pokud vím od IT specialistů průměrná doba obnovy IT systémů především díky stálým inovacím systému jsou 4 roky, u serverů to může být o něco málo více, ale rozhodně je to v řádech let, ne desítek let, takže půlka životnosti 3-4 roky není nemožná, zvláště pokud se jedná o GSM-R signál, který běží v ČR déle než ETCS.
Průměrná doba obnovy IT systémů je 3+ let, protože účetně odepsané jsou za 3 roky a i když se trochu se škudlí, provozujte něco, co je po záruce/mimo podporu.
Urcite nekdo co 3 roky bude delat upgrade systemu. Vy jste asi ve fakt velky firme v IT nikdy nebyl.Jinak byste nepsal takovy moudra, Povim Vam tajemstvi, jsou firmy a hodne velky, ktery maj i urcity systemy jeste na Cobolu a Pascalu…
No, bude, pokud jsou na to nastavené procesy a firemní kultura obecně. Pokud mám držet SLA, tak prostě nepojedu na nepodporovaném a obtížně servisovatelném železe, to je šílenství. Vykopávek jsem viděl taky dost, ale nevydávejme to za standard, natož žádoucí stav. Spoustu archiválií a inhouse obskurností pak stojí za to nahrnout do virtualizovaného prostředí, pokud to aspoň trochu jde, než „hlavně na to nesahat“ a furt trnout, kdy se s tím něco stane. Ale už jsme asi dost daleko od tématu. (Podnikové systémy pro řekněme spíš větší firmy mě živí, ta minulá měla nějakých 110 tisíc zaměstnanců, současná je zase… Číst vice »
A videl jste nekdy bankovni system nebo firmu plne na SAPu? A kolik stoji ruzne upgrade, implementace a reimplementace.
Ony i archaicke sw sice umi behat na novem zeleze, ale to o te nepodpore bych formuloval dost opatrne.
U nas běhá cca 40 ks technologickych pc jeste na win xp 🙂
Ubuntu server má v LTS verzi dobu podpory 10 let
sedlacekjaroslav7@gmail.com
Jardo, těsně vedle, ale nevzdávej to!
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
tak třeba je to po dobu testování benevolentnější… ale také by mne to zajímalo
Doba testování probíhala minulý rok, teď už funguje ostrý provoz.
Tak se to sice jmenuje, ale reálně je to spíš takové postupné zvykání si a vyhodnocování…
Však ono to těch hodně devítek má, problém je, že vy je neumíte spočítat.
GSMR (kde nastala ta chyba) tu běží už hodně let. Jestli připouštíte 43 minut za měsíc (tedy 2 hodiny výpadku a cca 3 měsíce a tedy 8 hodin výpadku za rok) a GSMR tu běží od roku 2009, tak za těch 15 let má „nárok“ na 120 hodin výpadku.
Jenom doplním: Plně zálohované systémy mívají běžně i více než 6devítkovou dostupnost (pohotovost).
Dovolil bych si nesouhlasit. Těch 6 devitek je spíše marketingová chiméra. Nějaká zcela „nemožná“ chyba obsluhy, nezalohované čerpadlo nafty dieselagregátu v souběhu s výpadkem konektivity, narušení integrity dat, ke které absolutně nemůže dojít,….Ale bohužel pro ETCS jsou zatím nedosažitelné ani ty devítky 3.
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
Proč by nebyl spolehlivý? Vždyť mobilní signál je jedna z posledních věcí co vám vypadne při nějakém kolapsu napájení nebo datových center.
Je to dano principem prenosu dat radiovym kanalem. GSM pouziva takove mechanismy kodovani (digitalni modulace) a sdileni kanalu, ktere nejsou prilis robustni. Naproti tomu novejsi celularni technologie pouzivaji principy mnohem robustnejsi (obecne mechanismy rozprostreneho spektra, ktere je mnohem odolnejsi napriklad na zaruseni). Krome problemu spolehlivosti je tu i riziko bezpecnosti. Priznavam, ze nevim, jak presne se z pohled u technologie GSM-R lisi od bezneho GSM, ale u bezneho GSM lze relativne snadno pomoci SDR = „software defined radio“ vybudovat falesnou GSM sit a mobilni stanice do ni „nalakat“. SDR je zarizeni za par stovek dolaru, ktere ktere ma pouze RF… Číst vice »
Vám se nikdy nestalo, že jste vytočil tel. číslo, a aniž by se ozval vyzváněcí tón, tak se hovor ukončil? Nebo Vás někdo nesprdnul, že mu neberete telefony, přitom jej máte celou dobu před sebou a zapnutý?
Mě už několikrát, jak služební tak soukromej
Jenze lze ocekavat, ze si SZ neplati podporu od prvni urovne ale treba az treti uroven podpory (to vyjde radovne levneji, ale potrebujes mit vlastni lidi kteri alespon tusi co delaji). No a pak spoleha na to, ze ten tebou placeny clovek na dohledu a mistni podpore dokaze alespon identifikovat nefunkcni cast systemu a nespoleha jen na to ze „se to samo prepne do Olomooce“… no a nekdy to nevyjde. Pak nastoupi ta treti uroven podpory ktera ma reakcni dobu treba 20min, ale jen na to ze zvedne telefon, pak teprve rozlepi oci, prelusti ceskou anglictinu a zacne zapinat pocitac… Číst vice »
Pokud máte ve smlouvě na páteřní prvky 6 hodin, pak ano vejde se to. Řeší to domácí pohotovost a 24 hodinový datový dohled. Přidejte dojezdový čas technika který je schopen řeši poruchu na místě nejdřív za hodinu od te doby než to k němu doputuje. V pracovní dny to lze řešit rychleji, máte k dispozici i víc pracovníků.
Tak jsme aspoň konečně zase první na světě!👌😀 Odměny jsou zcela oprávněné a překvapuje mě, že nejsou o řád vyšší…😉
To jsou ty další nezveřejňované bonusy co všichni dostali 😂😂😂
Chápu správně, že se rozbil server a současně nezávisle na tom vypadlo GSM-R?
Ne. Jen to každý „zjednodušil“ do novin trochu jinak.
Ne rozbily se dva servery na cdp (hlavni a zalozni) prez ktery se do site registruji gsm-r na lokomotive. Cili i pokud se telefon prihlasil do site, nepropadlo cislo vlaku, takze etcs o nem nevedela
To CDP je nějaká nadstavba nad vlastním GSM-R nebo její součást (něco jako HLR u klasické GSM sítě)?
CDP je chráněná dílna, alias Centrální dispečerské pracoviště
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.
Hustý, nezávidím strojvůdcům a cestujícím v roli pokusných králíků…
Není GSM-R jako GSM-R, rádiová síť a data pro ETCS jsou oddělená.
Jo, já takhle 20min. stál s odvěšenou mašinou v Ústí nad Orlicí, a pak jsem ještě dostal vynadaný, že se neumím hlásit podle předpisů, protože, když se to konečně podařilo, tak 2 min. se nikdo ze sluchátka neozýval
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.
Tak proč ted tvrdí že šlo o chybu v databázi etcs? To že není spojení není chyba databáze.
ETCS žádnou chybu nemělo, jen se tam ta lokomotiva nemohla přihlásit. Chyba byla v GSM-R které provádí spojení lokomotivy a Radioblokové centrály ETCS.
Protože tomu asi někdo nerozumí. Registrovat se musíte už do sítě GSM-R, a to zřejmě selhalo.
Z logiky věci tam přece jen jedna chyba byla, a to systému by mělo být podezřelé, že se mu žádný vlak do databáze nehlásí, úplně nejlépe by měl diagnostikovat, že nemá signál z GSM-R, na to, kolik systém stojí, se jedná o prkotinu.
Detekce výpadku systému ovšem nezabrání výpadku systému ..
Ale správná diagnostika zkrátí dobu do obnovení provozu.
Bohužel (bohužel pro Vás, ne že by to tak bylo špatně), informace o tom, kde koho v té síti hledat, aby mohl být spojen, je právě v databázi.
Ale pak to tedy nebyla databáze ETCS, ale databáze GSM-R, do které se nešlo přihlásit.
Takže Hlava-22
Protože každý vidí jen to svoje a blekotá..
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.
Záleží jak se ověřuje, že data v databázi jsou v pořádku (tedy kompletní, je jich správný počet, pravidelně se aktualizují a přibývají nová). Pokud tohle nic nehlídá, tak se může tvářit že je to v phodě, i když fungují jen stávající vlaky a nově přihlašované to nebere.
Č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éž.
To nikdy nemůže z logického hlediska fungovat. Velet může vždycky jen jeden. Milisekundy zpoždění přenosu stačí k totálnímu chaosu.
Velí vždy jen jeden, ale databáze mají běžně okamžitou replikaci dat na další servery, takže můžete hned přepnout na takovou horkou zálohu a jet dál bez výpadku. Milisekundy snad třeba nejsou, tohle není finanční systém.
sice se mluvi o “databazi” , ale tady bych si (byt je to jen domnenka) pod zjednodusenym pojmem “databaze” tak uplne nepredstavoval nejaky “sql server” do ktereho jdou (az ktereho) inserty a selecty na vlaky, ale jako mnohem komplexnejsi infrastrukturu a funkcnost…
takze to ani zdaleka nebude o nejake replikaci dat:
Replikace dat je ovšem něco jiného. A to, co popisujete, bez výpadku není, protože nejprve musíte bezpečně odpojit původní master a až pak můžete povolit zapisovat záloze.
Jen pro srandu, občas se kousnul slave server od iz, protože os widows server chrouplo v kouli a zakazal sam od sebe zapis dat co mu posilal master
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.
Ví se to, ale neřeknou to. Protože do výpadku se něco nevědělo a teď se to náhodou provalilo. Možná by nebylo od věci se zeptat Kontronu jak to s GSMR je.
Klasika – takové malé šróbek byl povolené, jenom vědět keré…
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é.
Jasně, spiknutí je globální, že?
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í…
L0 neznamená žádné zabezpečení, jede se v módu UN – nevybavená trať – v současné době aktivováno mezi Drahotuše – Lipník n. Bečvou, balízy (PZV) jsou umístěny před návěstidly. Pokud vlak projede návěstidlo s návěstí Stůj tak ho to sestřelí. To samé v případě poruchy traťové časti (balízy/PZV) o které je informován na DMI.
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
Docela zajímavá inspirace, ale ne zadarmo. Spíš se naskýtá otázka, proč na konvenční sítí nemáme všude pouze L1 a jen na vysokorychlostních tratích se neuvažuje s L2 a pokud možno s fallbackem na L1. Stejně se nakonec dojde k tomu, že se návěstidla ponechají trvale, protože je lepší mít systém i s touto zálohou, když už návěstidla pro posun je třeba ponechat.
V Dánsku mají myslím obojí. Na rychlé trati jsou někde jen lokalizační značky (vjezdová návěstidla pochopitelně zůstala), na S bahnu zůstala všechna, ale jsou zabalena do pytle (celkem polstrovaného, asi proti rozbití vandaly).
L1 tu propustnpost snižuje ještě víc než L2.
Víte, a v tom je základ zakopaného psa. Bylo zpožděno sice jen 4% vlaků, ale kdyby se to přepočetlo na počty cestujících, možná bychom se dostali až téměř ke 20%, protože on je rozdíl, když na nějaké regionální trati jede vagonek s 15 cestujícími, a nebo na koridoru jede vlak, který mívá 4-7 vozů se 100 míst k sezení v každém voze a je byť jen z poloviny obsazený. Pokud se to statisticky bere takto, tak je potom 5 hodin výpadku bez problémů, pokud by se to bralo na počty cestujících, ale i počty vlaků na trati, tak je i… Číst vice »
Tak ono se z principu na regionálkách nic moc stát nemohlo. Kolik regionálek má TR nad 100 km/hod v takové délce, aby se tam projevilo výraznější zpoždění.
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.
Čti:“chyba byla způsobena aktualizací serveru“ 🙂
Podobně, jako chybná aktualizace zabezpečení Windows serverů od CrowdStrike složila letištní odbavovací systémy.
Mohla být třeba chyba v řadiči diskového pole, to pak je výměna železa nejlepším řešením.
To měla relé v reléovkách, že fungovala buď dobře, nebo vůbec. Existuje pro to zvláštní termín: prvek s nesymetrickým projevem poruchy. Ale počítače tohle nemají, ty mívají poruchy, které se jednou projeví tak, jindy onak a někdy vůbec. Čili vůbec neplatí, že HW porucha buď je, nebo není. Vyměnit celý počítač preventivně a teprve pak případně zkoumat, co se v něm dělo, je docela dobrá strategie. Bezvadný rezervní počítač musím mít připravený stejně. Okamžitou výměnou riskuju akorát to, že jsem měnil „zbytečně“, pokud je chyba jinde a projeví se i s tím rezervním počítačem, což je taky cenná informace. I… Číst vice »
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.
Doufám, že tento názor nemají kompetentní osoby.
Naštěstí nemají. Poznáte to jednoduše. Představte si, kolikrát je česká železnice větší, než Temelín. Vynásobte si tím koeficientem náklady na výstavbu Temelína. A pak přemýšlejte, jestli SŽ v posledních letech utratila takovou částku. Řízení primárního okruhu reaktoru je řádově jednodušší než jakékoli zabezpečení na železnici, snad kromě štafetového kolíku. A zároveň je reaktor řádově větší riziko. Mimochodem, celá situace, o které je řeč, spočívala v tom, že se systém přepl do bezpečného základního stavu (vlaky nejezdily) – a tady se řeší, proč nouzové zprovoznění trvalo tak dlouho. Opravdu byste chtěl, aby po nouzovém odstavení, když se nepodaří během hodiny najít… Číst vice »
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í.
Jenže ETCS (kromě L3) není traťovina ale jenom přenáší informace (návěsti) z traťové/staniční zabezpečovačky na vlak. Pokud by se podařilo na stejnou kolej dát autorizaci (zelenou návěst) z obou stran, není věcí ETCS aby je nepouštělo. Pokud by ze stejného staničního zabezpečovače dostal jeden vlak informaci návěstidlem, „druhý přes Prahu, třetí přes Přerov,“ čtvrtý výpravkou, není to chyba.
Jinak beru, pokud nelze věřit GSM-R registracím, asi nelze vyloučit že pod stejným číslem vlaku je v síti víc mašin, a mohlo by mít blbé následky aby všechny dostaly stejnou autorizaci k jízdě.
Pokud registrace do GSMR funguje, tak se dva vlaky pod stejným číslem do systému nezaregistrují. Systém bere jen čísla, neřeší, že jedno je „dnešní“ a druhé „včerejší“.
Jenže redundance je to co právě rychle přepíná, jenže automaticky. V ideálním případě vůbec nevíte, která část systímu řeší danou úlohu a klidně dochází k tomu, že každou úlohu řeší jena strana. Ruční přepnutí, pak nezmnamená nic jiného než odpojení jedné půlky, která se stala nestabilní a samotná redundance to nezvládla. Pro představu při HW redundanci procesorů se jedná o prosté vytažení za provozu jednoho z nich. Přičemž systém musí zůstat stabilní a nehavarovat. Jde to obejít i hardwerově, ale správně by to měl obsloužit software.
Jenže tady se nebavíme o systému, kde je víc prvků a nějaký rozhodčí, který rozhoduje, který prvek je aktivní. Protože ten rozhodčí je pak SPOF. Tady se (doufám) bavíme o distribuovaném systému, kde žádný jeden rozhodčí není.
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.
Monitoring to má, ale jak víte že to hlídá všechny podstatné parametry a že to dělá správně? Už bylo mnoho incidentů, kdy se systém (i u velkých korporací) tvářil v pohodě, ale část ho nefungovala a to dost podstatně, jen to nikdo neviděl. Dnes jsou systémy tak komplexní, že není divu, když se na něco „zapomene“, protože to je neznámá neznámá, se kterou se nepočítalo ani při návrhu toho monitoringu a problém ukázala až praxe.
„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.
Protože prvotně byl výpadek GSM-R na celé síti. Nemožnost jízdy pod ETCS byl následek výpadku.
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.
Co zkusit přečíst článek nejdřív do konce a pak házet rozumy…?
Č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!
Zkuste si příště nejprve zjistit základní fakta a základy slušného chování.
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. 🙂
Mám známého výpravčího, který říkal. Zlatá elektromechanika. Když potřebuji elektřinu, tak si jí vyrobím klikou.
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.
Zásoby pohonných hmot má stát v rezervách tuším na 90 dnů a v případě potřeby se bude prioritizovat tam, kde to je potřeba, takže ta nafta hned nedojde. Nezávislý zdroj elektřiny je taky dobrý, ale ze solárek ve stanicích toho moc nenabijete, základ je mít mnoho decentralizovaných zdrojů s dostatečnou kapacitou a taky odolnou přenosovou síť. Nejlíp na tom je člověk s elektromobilem u domku, kde má na střeše soláry (na auto to stačí), ideálně ještě větrník a pořádnou baterii alespoň na týden plného provozu domácnosti.