Nos az utóbbi hetekben ha volt időm utánajártam jobban a témának. Ha egy egész időszakot nézünk mondjuk 2000 és 2020 között akkor amíg az első 10 évben a SAFETY volt a mérvadó, úgy az utóbbi tízben és főleg 2015 után a SECURITY. Safety: bizonyos kezelési hibákat használ ki vagyis az emberi tényezőket. Kezelő személyzettel kapcsolatos félrevezetés, hamis tevékenység vagy akar kezdeti tervezési, tesztelési és éles üzemeltetéskori tudatlansági hibák voltak főleg a célkeresztben. Ellenben a Security valamilyen (al)rendszernek, vagy annak egyes részeinek gyengeségét használja ki.
Aki ismer esetlegesen ETCS bevezetése előtti más európai országokban már működő vonatbefolyásolást azt tudja, hogy ETCS működési elveiben legjobban a német LZB-hez hasonlít. Aki nem tudja annak röviden annyit, hogy járműveken megtalálható alkotóelemek és funkciók, a pályán használt blokkok, valamint a pálya melletti egységek, központok, hatótávolság elvei is nagyon hasonlóak.
Tanulva az LZB betegségeiből próbáltak az ETCS vezetése esetében (90-es években) hasonló fázisokat bevezetni. pl. Kompones-Konfornitás-Integráció-Rendszer és üzembe helyezési tesztek, a teszt fázisok részletes folyamatokkal definiálva. Figyelembe vették az idő múlásával az egyes elemek biztonsági fenyegetettségének növekedését és azt is, hogy a technikai eszközök - ideértve a kommunikációt is - hogyan fog elavulni. Milyen életciklusokat kell figyelembe venni. Komolyabb fordulat 2000-es évek elején jött elő amikor is a SUBSET 037-ben elkezdődött a titkosítás és hitelesítés alapkövének letétele. Amikor is nagysebességű rendszereknél (L2 és később L3) esetében az adatok védelme központok és végpontok között elengedhetetlen. Míg L1 esetében mint opciót fogalmazták meg
Rizikó analizíst végeztek el, hogy hol és milyen módon sebezhetőek az ETCS rendszer egyes alrendszerei vagy maga az egész folyamat.
A balízok és pályamenti elemek bizonyultak a legerősebbeknek. Hiszen ezek buherálása szakértelmet igényel és ráadásul nagyon sok egyidejű erőforrás kell hozzá. Szaktudás: amíg egy mezei ember ránéz a sínekre balíz az darabra megy addig egy szakember tudja a típusát, annak jelentőségeit, kódolást (rövid v. hosszú távirat forma) EVC által elfogadott tűréshatárokat, linkelést és az egész technikai hátteret akkor tudja, hogy balízok által becsapni a járművet vagy járműveket alapos szaktudás mellett belső információk és több balíz (csoport) egyidejű buherálása venné igénybe. Mondjuk ha a történelmet nézzük egy vár bevételéhez is egy tucat ember kellett, akkor egy ilyen sikeres akcióhoz is min egy kisebb hadsereget tudok elképzelni.
Nagyobb sanszot látok az OBU és RBC valamint az RBC és OBU közötti kommunikációban. Ezáltal tettem fel pár kérdést és írtam eseteket a 161-es hozzászólásban. Jelen állás szerint a Man-in-the-Middle tud valamilyen módon potenciális veszélyhelyzeteket kialakítani. Hogyan?
pl.: adat lehallgatás-hamisítás legitim rendszer színlelése, esetlegesen Social Enginering (teljes v. részfeladatok átvétele mint legitim ember) trójai módszerrel fiktív szakemberek, komponensek becsempészése. A legnagyobb gond az amikor a behatoló olyan valós vagy színlelt dolgot tesz amivel nagyon erősen frekventált vonalakon nagy visszaesést tud produkálni. Esetlegesen rosszabb esetben teljes KO -> olyan mint DoS támadás az ismert IT világban. Ekkor pl. ETCS szintváltáskor, vagy több vonatbefolyás egyidejű használatakor tud fatális eredményeket produkálni. Szintváltás látszólag lezajlott, de mégsem lehetett volna. Nem helytálló nyugtázási üzenetek küldése vagy pálya menti jelzők sötét üzemének flasch positive hatásai.
SUBSET 037-re visszatérve a kezdeti gondolatok, hogy 3DES titkosítás, biztonság, stb. egy ideig volt elég. Később rájöttek arra, hogy a kulcsokat lehet manipulálni, emiatt jött a képbe a tanúsítványkiadó és tanúsítványok. Ahogy a kezdeti Offline terjesztés sem volt egy járható út.
Napjainkban már ez a folyamat is így működik mint a nagyvilági IT esetében a PKI és CA. Tömeges kulcs előállítás tanúsítvánnyal, online terjesztés és szükség esetében visszavonás.
Aki valamennyire ismeri az ETCS-t az tudja a SIL szinteket és jelentőségeit. Nos a Security terület is megkapta a maga négy SL szintjét az ETCS világában.
2016-tól - ha már szóba kerültek a DIN/EN szabványok pl. 50159-es - más szabványokat és más módszereket is bevezettek a vasúti biztonság szavatolására. A vasúti biztosítóberendezések üzemeltetésében résztvevők körét kibővítették Cyberbiztonsági szakemberekkel a vasúti infrastruktúrák esetében. Itt már a DIN/EN 501xy felül más szabványokkal dolgoznak, ezen erősebb prioritást élveznek. Legalábbis nyugaton ezt tapasztalom azóta és elsődleges feladat volt olyan terv felállítása, hogy ha egy normál állapotban bekövetkezik valami negatív akkor arra milyen gyorsan tud valaki reagálni és milyen gyorsan állítható vissza a normál az előtti vagy egy új biztonságos üzemi állapot. Mivel jelenleg nincs még központilag szabályozva, hogy ETCS biztonságának szavatolására ki és milyen eszközöket használjon v. használhat, ezért mindenki saját maga oldja meg. Ez jelenleg egyéni belátás szerint amit egyes helyeken a szaktudás milyensége és a pénztárca vastagsága határoz meg. Idővel már nem lesz ennyire szabad keze senkinek sem. ERA itt is egységes szabályozásra készül.
A 155-ös hozzászólásban már említettem az ERA és a francia titkosszolgálat tevékenységeit. Nos azóta is évente megvannak a vizsgálatok és adatok. Én tudom pl. összességében mennyi éves szinten teljes vasút informatika rendszerek fenyegetettsége és ebből mennyi ami konkrét ETCS incidens. Jelenleg ezen adatokat nem kell publikálni, így a közember olyanokat tud esetleg ami hagyományos szabotázs lehet pl. egy fanatikus drótkötéllel német DB ICE szerelvényt akart siklasztani.
Az eredményeket, a próbálkozások sokaságát és típusait mérlegelve már három gyártó dobott piacra olyan termékeket amivel az eseményeket meg lehet figyelni, időben riasztani és esetleg ellen lépéseket tenni. Ezen termékek egyike sem tud 100% biztonságot nyújtani. Ennek oka az, hogy a teljes infrastruktúra így néz ki:
Tehát ha a technikai intézkedések halmazát nézzük akkor a három termék mindegyike megfelelő. Ha a ehhez jön az infrastrukturális akkor az egyik ⅓, a másik ⅔ részben jó, a harmadik nem tudja kezelni. Az üzemeltetési intézkedéseket részben pedig csak egy termék tudja. Természetesen vannak termékek amik a hiányzó részeket tudják teljes egészében. De ezek külön egységként kezelve ronthatják a biztonsági szinteket, azok megítélését.
Jó helyen gondolod a PKI és a CA alkalmazását. Ezekre a dolgokra már van termék amivel tömegesen lehet a szükséges elemeket előállítani, terjeszteni, ellenőrizni és szükség esetén visszavonni. De ez a téma csak egy a sok között ahol védeni kell/kellene az adatok integritását.
Mivel nem ismerem az ETCS működését (ezért voltak a kérdéseim) így nehéz válaszolni.
Sima IT esetén pl. valamiféle "mutual authenitcation"-t próbálnék alkalmazni, amikor a kommunikációban mindkét fél azonosítja magát (A > B illetve B > A) és ha mindketten meggyőződtek a másik fél hitelességéről, akkor folytatódhat a kommunikáció.
Ha ez mondjuk (maradva sima IT-nál) mTLS -t alkalmaznának, akkor ez szélsőséges esetben azt jelentené, hogy minden baliznak van saját egyedi tanúsítványa, amit ismer az összes mozdony és minden mozdony egyedi tanúsítványát ismeri minden baliz. Ez pedig igen nagy számú tanúsítványt jelent és ezeket karban is kell tartani (kiadás, visszavonás). Mozdonyon könnyű, balízon nehéz (persze mehetne végig a vonalon "programozó" mozdony, ami megcsinálja a frissítést, de nem tűnik jó ötletnek).
Nem IT-s rádiótechnikában ezt nem tudom, hogyan szokás megoldani, főleg nagy sebességgel mozgó jelforrások (álló baliz fölött elhúzó szerelvény) esetén, de ha mondjuk WIFI-nek fognám fel a dolgot, akkor egy WPA2 + CCMP protokol nem tűnik rossz ötletnek (kérdés, van-e rá idő).
"nem tudom, várja-e egyáltalán, hogy a pálya X pontján pl. egy balíznak kellene lennie és ha nincs ott, akkor reagál?"
Keresi, és elég pontosan tudja is, hogy hol kell lennie a következő balíznak (_Nyúlván a kerékcsúszás/kerékperdülés miatt mm-re pontosan nem tudhatja a saját helyét két balíz között a jármű, de elég pontosan megtalálja magát). Ha nem jön a balíz, vagy nem az jön, aminek kéne, akkor arra fel van készítve a technika.
azt, hogy magyar vasútnál milyen módon védekeznek esetleges támadások ellen nem tudom megmondani. De azt, hogy ahol már évek óta van ETCS és elég nagy forgalmat bonyolítanak le vele, ott tudom.
De az, hogy RBC központba akarunk valamit vagy a pálya mellett - jogos munkának álcázva - már nagyon idejétmúlt módszer lenne a nagy átlagot nézve.
> Fórumtárs leírt egy olyan alapelvet amit az ERA - valamint mivoltából a francia titkosszolgálat -
> a kettőezres évek elejétől kezdett el vizsgálni.
Nem ástam bele magam rettentő mélyen a témába, de amiket találtam pár éves cikkeket, ott is még csak proposal szintjén feszegettek bizonyos kérdéseket, hogy hát van esélye az olyan hekkelésnek, amikor nem csákánnyal verik szét az eszközt és hát ezt-azt-amazt tenni kellene ellene.
Csak kíváncsi vagyok, hogy ha már itthon éppen bevezetés alatt van (volt) az ETCS, akkor mennyire modern rendszert építenek és hol tart most a tudomány.
Köszi a választ, nem kötözködni akarok, csak most megint ráérek. :)
> Szóval ahhoz, hogy valamit el tudj rontani, fizikailag kell ott lenned,
Ez szerintem pont a vasútnál könnyítés. Úgy értem, egy cég szerverszobájába/géptermébe nehéz bemenni. Egy fényjelzőt, balízt meg megtalálsz kint a pusztában, ahol a kutya nem jár. Felveszel valami láthatósági mellényt, viszel egy csákányt meg egy talicskát és te vagy a pályamunkás. Senki rád nem néz mégegyszer.
Spec eszközök és szoftver: és ezek megszerezhetetlenek? Nem hiszem.
> Speciális tudás, hardver és szofter nélkül a legtöbb amit csinálni tudsz, hogy kikapcsolod.
Mondjuk az is valami. Vagy csak mellé teszek valami zavaró berendezést, ami elnyomja a jelét. Gondolom a vevőegység erre fel van készülve (nem tudom, várja-e egyáltalán, hogy a pálya X pontján pl. egy balíznak kellene lennie és ha nincs ott, akkor reagál?).
> Ezen kívül a táviratok épségét a fedélzet is ellenőrzi, illetve a balízcsoportok egymásutániságát és távolságát > is ellenőrzi pl. linkeléssel. Az emberi hibák a tesztelés során felfedődnek.
Értem. Akkor ez azt jelenti, hogy ha lemásolok (valahogy, mindegy hogyan) egy balízt és átrakom egy másik pályára, vagy megcserélem a sorrendjüket ugyanazon a pályán, akkor azt e fedélzeti eszköz kiszúrja?
> Szabotás [..] Az egyetemen azt tanítják, hogy az ellen nem tudunk és nem is akarunk védekezni, megbízunk a kollégáikban
Azért ez kb. az ősbűn. :)
Szóval röviden nekem az a problémám, hogy rengeteg olyan eszköz van a rendszerben, ami látszólag nincs rendesen elzárva, megvédve, nincs szem előtt, könnyen hozzáférhető.
"A vasúti biztonságkritikus kommunikációról alapvetően az EN50159 szabvány szól."
szerény véleményem szerint 50159-es már egy idejétmúlt régi nem éppen ETCS konform. Ha valaki 2020 végén csakis 50159-esre hagyatkozva épít és üzemeltet egy rendszert akkor egy nagyon specifikus részhalmazra fókuszál csak. Nagy űrt hagy az egész rendszerben. Az ETCS ma már ennél több részhalmazból tevődik össze. Szerintem egy ideje már ISO 27000, DIN/ISO 27001 nélkül nem lehet biztonságos ETCS-ről beszélni.
Miért is?
GSM-R esetében FTN fedélzeti egységek esetében EVC -> OBU
Fórumtárs leírt egy olyan alapelvet amit az ERA - valamint mivoltából a francia titkosszolgálat - a kettőezres évek elejétől kezdett el vizsgálni. Az idő múlásával pedig IT biztonsági cégeket is bekapcsoltak. A 154. hozzászólásban vázolt manipulálási elv az első időszakban jött elő, azonban az idő múlásával elkezdték vizsgálni a GSM-R és mögöttes rendszerek sérülékenységét. 2015-2017 között a francia titkosszolgálat és meg nem nevezett etikus hekkeléssel foglalkozó cégek megdöbbentő eredményeket produkáltak.
Olyan emberek akik hozzáférhettek ennek a jelentésnek tartalmához - ezen adatokat diszkréten kezelve - valamint más köznapibb tényekből adódóan nem is olyan rég dobtak piacra egy első és igazi valós időben dolgozó biztonsági megoldást GSM-R és ETCS megfigyelésére és biztonsági incidensek kiszűrésére.
Nagyon érdekes témát feszegetsz, lehet hogy a szaklapban (Vasúti Vezetékvilág, ex. Vezetékek Világa) is találsz vonatkozó cikkeket a témában.
A vasúti biztonságkritikus kommunikációról alapvetően az EN50159 szabvány szól.
A kiberbiztonságot általában zárt rendszerekkel szoktuk megoldani, azaz az adott hálózatra csak az ott található eszközök kapnak hozzáférést. Ez fizikailag saját ereket, sötétszálakat jelent, illetve bizonyos esetekben az MPLS-t is el szoktuk fogadni ilyen hálózatnak. Ezért aztán a "hekkelés" nem jellemző vasúti hálózatokra.
Szóval ahhoz, hogy valamit el tudj rontani, fizikailag kell ott lenned, ezt pedig a klasszikus informatikus hekkerek nem szokták csinálni. :)
Ha fizikailag nézed a dolgokat, akkor a balízok programozásához speciális eszközök kellenek. Szükséged van a szoftverre, amivel előállítod a balíz tartalmát, illetve speciális hardverekre is, amivel hozzáférsz a balízhoz. Ezek gyártóspecifikusak, tehát egy Siemens programozóval nem tudsz Ansaldo balízt programozni.
A LEU-k a fizikai beavatkozás ellen kulcsra zárt szekrényekben vagy házikókban laknak, szoftver szempontjából meg gyártóspecifikusan lehet csatlakozni hozzájuk. Általában hálózathoz sem csatlakoznak, távolról nem lehet őket programozni. Speciális tudás, hardver és szofter nélkül a legtöbb amit csinálni tudsz, hogy kikapcsolod.
Az ETCS balíztelegramokra igaz továbbá, hogy specifikusan vannak kódolva, a bitek csak bizonyos mintázatokban érvényesek (ennek elsődleges célja az átviteli hibák kiszűrése). Erről a Subset-036-ban olvashatsz bővebben, elérhető az ERA weblapján.
Ezen kívül a táviratok épségét a fedélzet is ellenőrzi, illetve a balízcsoportok egymásutániságát és távolságát is ellenőrzi pl. linkeléssel. Az emberi hibák a tesztelés során felfedődnek.
Jogosan merülhet fel a kérdés, hogy mi van akkor, ha véletlenül az előző verziójú balíztáviratot tölti be a műszerész a balízba? Ez ellen eljárásrendekkel, megfelelő konfiguráció menedzsmenttel és a tesztjegyzőkönyvek ellenőrzésével lehet védekezni.
Mindezek mellett a vasút területén általánosan bevett biztonsági stratégia a fail-safe rendszerek alkalmazása, azaz ha valami nem úgy működik, ahogy attól elvárnánk, akkor az a biztonságos, akadályozó állapotba kerül, megállítjuk a vonatokat, vörösre kapcsoljuk a jelzőket, stb.
A véletlenszerű emberi hibák ellen teszteléssel védekezünk, például amikor hozzányúlunk egy vezetékhez, akkor utána megnézzük hogy minden a helyén van, és nem a zöld fény világít a vörös helyett.
Esetleg lehet még említeni a felcserélhetetlenségi dugaszokat és csapokat is, ezek is csak a véletlen hibák ellen védenek, ha valaki "átprogramozza" ezeket, akkor bármilyen egységet be tud tenni bárhova.
Itt merül fel a szabotázs kérdése, azaz mi van akkor ha direkt el akarok rontani valamit. Az egyetemen azt tanítják, hogy az ellen nem tudunk és nem is akarunk védekezni, megbízunk a kollégáikban, illetve nem dolgozhatnak egyedül sem általában (ez munkavédelmi kérdés is persze), de az egyre szofisztikáltabb rendszerek a biztonságkritikus emberi beavatkozás lehetőségét is egyre jobban szűkítik.
Például ha van jelfeladás, akkor onnan is meggyőződhet a mozdonyvezető a jelző állapotáról, és észreveheti ha nem egyezik a két állapot.
De szerintem az informatikában is ez a helyzet, nem adunk hozzáférést olyannak akiben nem bízunk meg.
Semmi közöm a vasúthoz, csak ide tévedtem, olvasgattam egy kicsit és IT security-val foglalkozóként felmerült bennem a kérdés, hogy mennyire biztonságos a vasúti biztonság? Hogyan van megvédve rosszindulatú beavatkozás ellen?
Nekem itt minden új volt ezért elkezdtem guglizni (ETCS, balíz) de nem igazán találtam választ arra, hogy mi akadályozza meg pl. a statikusan lerakott jelzók (pl. balíz) átprogramozását, hogy hamis adatot közöljenek, vagy pl. ezen jelzők lemásolását és a másolatok elhelyezését a pálya más szakaszaira (mint amikor az út szélén vki viccből egy 1-est ragaszt a 30-as sebességkorlátozó tábla elejére. a sofőr jót röhög a viccen, az autó viszont ha pl. nem tájékozódik térképről is, akkor leolvassa, hogy 130-cal lehet menni és zamek).
De ugyanez a kérdésem igaz a régi vezérlő rendszerekre (pl. térközjelzők, fényjelzők) is. Mi védte őket a hekkeléstől? Vagy csak nem volt szokás ilyesmi miatt aggódni?
Természetesen adott vasúti társaságok ebben a tekintetbe külön fejezeteket szentelnek M_NVCONTACT és fékezési módszerekkel kapcsolatban. Legalábbis német nyelvterületen 2007-2012 között elég sok dokumentum és oktatási anyag keletkezett.
"Ha nem jön a központtól info, adat M_NVCONTACT SRS alap: nincs szabályozva Svájc: fékezés Németország: fékezés Csehek: fékezés"
Azért csak annyit írni, hogy fékezés... Nem mindegy, hogy üzemi fékkel vagy Trip móddal... A kettőből kivergődni nem feltétlen ugyanúgy kell, ha helyre áll az RBC-vel a kapcsolat.
A honlap teljesen jó, a NID_C=416 esetében a mai napig ezek a nemzeti értékek kerülnek feladásra. Ez jelenleg a Budapest-Hegyeshalom-Rajka vonalat jelenti.
Más kérdés, hogy Magyarországéi továbbá a 417, 418 és 419 értékek is, és ott más értékek kerülnek alkalmazásra.
Egyébkét van a RSSB-nek egy remek dokumentuma arra, hogy milyen szempontok alapján érdemes a nemzeti értékeket meghatározni, javaslom elolvasni akinek van ideje rá és érdekli.
Nem tudom, majd utána kell nézni. Igazából a "keleti" blokkban csak cseh adataim vannak mert ott volt meló az utóbbi időben. Illetve azokat írtam össze amivel napi szinten találkozom úgymond. Nagyon sok meló volt német területen a Bremskurve és tolerancia meg fékszámítással kapcsolatban.
Korábban voltak feladataim Skandináv országokkal is emiatt vannak ismerősebb nemzeti értékeim.
a nagytopicos nemzeti érték vitához szólok itt hozzá. Aki tudja magyar értékeket az írja meg.
A nemzeti értékekben - meg amúgy ETCS területén - svájci vasút jár az élen. Íme néhány adat összehasonlításként:
Általános értékek
SH üzemmód, adat VNVSHUNT SRS alap: 30 km/h Svájc: L1: 60 km/h, L2: 40 km/h Németország: 40 km/h Csehek: 40 km/h
OS üzemmód, adat V_NVONSIGHT SRS alap: 30 km/h Svájc: L1: 40 km/h, L2: 40 km/h Németország: 40 km/h Csehek: 100 km/h
SR üzemmód, adat V_NVSTFF SRS alap: 40 km/h Svájc: L1: 40 km/h, L2: 40 km/h Németország: 40 km/h Csehek: 40 km/h
LS üzemmód, adat V_NVLIMITSUPERV Vmax
SRS alap: 100 km/h Svájc: L1: helyfüggő, L2: helyfüggő Németország: 160 km/h Csehek: 100 km/h
UN üzemmód, adat V_NVUNFIT Vmax
SRS alap: 100 km/h Svájc: L1: 160 km/h, L2: 160 km/h Németország: 50 km/h Csehek: 100 km/h Megjegyzem ez a mód egy sok helyen már nem alkalmazott
Release Speed, adat NVREL SRS alap: 40 km/h Svájc: L1: 25 km/h, L2: 40 km/h Németország: L1: 40 km/h, L2: 20 km/h Csehek: 20 km/h
Visszaguruláci tolerancia, adat D_NVROLL SRS alap: 2 m Svájc: L1: 10 m, L2: 10 m Németország: 5 m Csehek: 8 m
Vmax Override esetében, adat V_NVALLOWOVTRP SRS alap: 0 km/h Svájc: L1: 5 km/h, L2: 0 km/h Németország: 40 km/h Csehek: 40 km/h
Vmax Overried után menetengedély végéig, adat V_NVSUPOVTRP SRS alap: 30 km/h Svájc: L1: 40 km/h, L2: 40 km/h Németország: 40 km/h Csehek: 40 km/h
Overried megtehető táv, adat D_NVOVTRP SRS alap: 200 m Svájc: L1: 200 m, L2: 200 m Németország: L2: 400 m és még van NTC esetében csak 5 m Csehek: 350 m
Overried idő, adat T_NVOVTRP SRS alap: 60 másodperc Svájc: L1: 255 másodperc, L2: 255 másodperc Németország: L2: 255 másodperc és még van NTC esetében csak 5 másodperc Csehek: 100 másodperc
Maximálisan megengedett visszatolási érték, adat D_NVPOTRP SRS alap: 200 m Svájc: L1: 10 m, L2: 10 m Németország: 5 m Csehek: 8 m
SR esetében megtehető maximális táv, adat D_NVSTFF SRS alap: nincs korlátozva Svájc: nincs korlátozva Németország: nincs korlátozva Csehek: nincs korlátozva
Mozdonyvezetői azonosító megadása, adat M_NVDERUN SRS alap: nincs korlátozva Svájc: nincs korlátozva Németország: nincs korlátozva Csehek: nem megengedett
RBC távirat időkiesési értéke, adat T_NVCONTACT SRS alap: nincs szabályozva Svájc: nincs 40 másodperc Németország: 40 másodperc Csehek: 180 másodperc
Ha nem jön a központtól info, adat M_NVCONTACT SRS alap: nincs szabályozva Svájc: fékezés Németország: fékezés Csehek: fékezés
Baliz elhelyezési tolerancia, adat Q_NNVLOCACC SRS alap: 12 m Svájc: L1: 20 m, L2: 20 m Németország: 12 m Csehek: kidolgozás alatt
Bremkurve specifikus adatok, ahol főleg a német nyelvterületet ismerem.
Gamma-modell ami a régi SRS2-esben volt, fékezés hatását egy régi modell alapján lehetett megadni
Lambda-model ami SRS3 alapú és tudja a fékszázalékot is kezelni
Ezek alapján jött a DMI-re a Bremskurve.
Ezek alapján jöttek ki az eltérő nemzeti értékek:
Guidance Curve, adat Q_NVGUIPERM SRS alap: nem megengedett Svájc: nem megengedett Németország: csak L2 engedi meg Csehek: kidolgozás alatt Finnek: megengedett
SBI és SBF, adat Q_NVSBTSMPERM és Q_NVSBFBPERM SRS alap: megengedett Svájc: nem megengedett Németország: nem megengedett Csehek: nem megengedett Finnek: megengedett
Mikor oldja fel kényszerfékezés után a fékrendszert, adat Q_NVEMRRLS SRS alap: megállás után Svájc: megállás után Németország: ha a megengedett sebesség alá csökken Csehek: ha a megengedett sebesség alá csökken
Sebesség mérési kompenzáció, adat Q_NVINHSMICPERM SRS alap: nem megengedett Svájc: L1: megengedett, L2: nem megengedett Németország:megengedett Csehek: nem megengedett
vonat típus, adat Q_NVKVINTSET németeknél L1, L2 különböző értékekkel, fontos VDE pályákon: Tunnelbegegnungsverbot
A többi érték lambda meg gamma Bremskurve miatti korrekciós és tolerancia képletek miatt lettek kialakítva Akit érdekel jelezze és megírom. Bár sok hatvány meg gyök miatt rajzolni jobb
Igen ezek útátjárókkal kapcsolatban feladott adatok. A németek első körben kitették úgymond, hogy majd megoldják ezeket blokkos elő meg főjelzős csomagokkal. A praxis meg később visszahozta racionálisabb verzióba. Van más ország ahol meg más történt, a legtöbb esetben DMI kapcsán és jobbításon felül a hiba korrekciók is szép számmal benne vannak A Baselinek-ben. Vagyis van amikor annyi, hogy hamar követi Release 2, stb. stb.
Szívesen és én köszönöm az összefoglalást. Félreértés ne essék, hogy a 131. számú hozzászólásban leírtak egyeznek a cikkben vázolt műszaki leírással. Ez a cikk csak egy "előszele" az egésznek. Amit én írtam abban szó van kábelcseréről sőt gerinc és hálózati struktúra átalakításról is. Nem hiába kellett optikai mux is pl. és spec balízok.
A teszt projektbe egyre több jelentkező van. Többet szeretnék a hamarosan elavultnak mondható GSM-R-t leváltani. Továbbá a DCRG 2015-ös jelentését csak kevesen vették komolyan biztonsági szempontból. Egy újabb jelentést amit természet tudósok készítettek 2017-ben kezdtek el újabb gondolatokat gerjeszteni. Azaz nem a rádiós kapcsolat lenne a jövőben a legjobb megoldás.
Nem tudom hogy ezek a betűszavak pontosan mit jelentenek, és a gugli se volt a segítségemre ma este.
Ha viszont ez az, amire gondolok, akkor sorompók által feladott, és adott esetben visszavont TSR-ek Magyarországon is sztenderd megoldások L1 elven (vezérelt balízokkal) fedezett vonali illetve RBC által fedezett mindenféle sorompók esetében.
Picit belemenve a részletekbe, csak hogy tisztábban lásson a közönség is, hogy miről is van szó:
Biztberbe integrált balíztávirat-generálás (a centralizált megoldás továbbfejlesztése). Abból kiindulva, hogy nem szól a cikk sok kilométer balízkábel lefektetéséről, gondolom a LEU-kat lecserélik egy "soros-IfC átalakítóra".
Ennek folyománya a pályaleíró adatbázis gyors cseréjének lehetősége, illetve ennek is a biztberbe való integrálása. Ezek után csak a balízokat kell programozni a pályamentén.
C interfészen keresztüli diagnosztika (és nem down-link balíz, félreértés ne essék) - az Alstomnak már évek óta van erre terméke.
Központi TSR menedzsment, egy előre definiált szakaszokra alkalmazható és egy előre megtervezett esetekre való, előre felprogramozható megoldás. - Szintén ismert megoldás, spanyoloknál centralizált megoldásban, vagy az Alstom esetében decentralizált, LEU távfrissítéssel megoldott módszerrel.
Egyszerűsített jelzők, szabad ETCS-ben vagy megállj - a spanyoloknál léteznek régebb óta is már ETCS jelzésképek, és nem gyújtják ki a karácsonyfát, itt már nem is lesz karácsonyfa. Egyébként már Magyarországon is sok helyen alkalmazzák a "jelző jelzése nem ekvivalens a feladott ETCS távirattal elvet", aminek továbbgondolása ez a megoldás.
Peronszéli indulásjelző - angoloknál a hasonló funkciót betöltő "OFF indikátor" régi hagyomány.
ETCS-hívó, ha a jelzőt nem lehet szabadra vezérelni, akkor is kimegy a menetengedély a balízba, a vonatot meg felhatalmazzák a jelző meghaladására.
Mérnöki módszerekkel, az ismert és ismeretlen vonatokra optimalizált, kellő mennyiségű infill balíz.
Vágányzári üzem, azaz minden balíz csak fejlécet továbbít egy körzetben.
Szóval összességében vették az ETCS-ben elérhető, L1 szinten releváns "best practice" megoldásokat, és összegyúrtak belőle egy tök jó rendszert egy király koncepció mentén. Tetszik, köszi a cikket még egyszer.
