Ma már interneten bankolunk, az egészségügyi labor itt küldi el leleteinket a kezelőorvosunknak, sőt lassan már a hűtőszekrényünk is felkapcsolódik a hálózatra. A mi szakmánk földrajzilag elosztott rendszer, így természetesen adódik, hogy ez a fajta digitalizáció minket is utol fog érni. A kérdés az, hogy hogyan?
Nem vagyok távközlős. Ezért mindig elveszettnek érzem magam a sok három- és négybetűs rövidítés között, amelyek a távközlős szövegekben olyan gyakoriak. (A hivatkozott irodalmakban a feloldások megtalálhatóak.) Egy kicsit szeretnék segíteni azoknak a biztosítóberendezéssel foglalkozó kollégáknak, akik hozzám hasonlóan kevésbé otthonosan mozognak ezen a területen. Másrészt viszont a távközlési területen dolgozó kollégáknak is szeretném kicsit bemutatni, hogy amikor a biztosítóberendezési kollégák fogalmazzák meg az igényeiket, akkor mi is az, ami valójában különleges igényt jelent egy biztosítóberendezési összeköttetés konfigurálásakor, és miért van szükség erre. Az erősáramú területen dolgozó kollégák is érezhetik érintettségüket, hiszen a FET rendszer kommunikációs hálózat igénybevételi szempontból egészen hasonló helyzetben van, mint a biztosítóberendezések.
A mai biztosítóberendezési alkalmazások egyre inkább tartalmaznak olyan összeköttetéseket, amelyek különböző távközlési szabványokon nyugszanak. Ma már jellemző, hogy mindent, ami lehetséges, IP alapú hálózatra terelünk. Itt nem csak a KöFi jellegű kapcsolatokra kell gondolni, az elektronikus biztosítóberendezési részrendszerekben az IP használata egész mélyen is lehet: például a távoli tengelyszámláló pont és annak kiértékelő egysége között is lehet ilyen alapon szervezett kapcsolat. Az IP alapú hálózatok kezdenek annyira természetessé válni, mint annak idején a rézdrót. Ha egy fejlődési lépcsővel visszább tekintünk, akkor azt láthatjuk, hogy ahogy egyre több rézkábel eret lehetett egyre nagyobb távolságon lefektetni, úgy terjedtek el a biztosítóberendezésekben is az ilyen nagy távolságra kinyújtóztatott áramkörök. Ehhez hozzátartozik, hogy a jelfogós biztosítóberendezések belső szerkezete is eleve áramkörökre épül. Az elektronikus biztosítóberendezés belső moduljai eleve táviratokkal kommunikálnak egymással, így természetesen adódik náluk az ennek megfelelő hálózatok használata.
Az, hogy valami IP hálózaton működik, jól hangzik, de ezzel még nem mondtunk sokat – folytatva az előbbi metaforát, körülbelül csak annyit, mintha egy jelfogós áramkörről azt mondanánk: „rézdróton megy”. Az ördög a részletekben lakik: ugyanúgy, ahogy ekkor is illik leírni, hogy váltakozó vagy egyenáramú-e a kör, 96V vagy 48V stb., az IP hálózaton megvalósított forgalom is további specifikációt igényel. Cikkemben ezeket a kérdéseket járom kicsit körül.
A bevezetőben megkezdett metafora a rézdrót és az IP hálózat közt redundancia tekintetében nem folytatható. A redundáns átvitel a jelfogós áramköröknél nem jellemző, ott egy-egy pont-pont kapcsolatról beszélhetünk. Ebből adódik, hogy a jelfogókkal megvalósított ’hálózatok’ nagyjából csillag topológiájúnak tekinthetők, de úgy, hogy több különböző ponthoz vezető szár ugyanabban a törzskábelben fut. Általánosságban könnyen beláthatóan teljesül, hogy egy ilyen áramkör meghibásodása csak egy objektum működését korlátozza. (A kábelvágás egy másik eset…)
Ezzel szemben az újabb, némiképp elavult szóhasználattal „soros átvitelű” hálózatokon a gyűrű topológia az elterjedt. Ez már a kábelvágások ellen is védelmet nyújt. A gyűrűn elhelyezkedő, a végpontokat kiszolgáló berendezések szükség esetén (ha ezek hibája ellen is védekezni szeretnénk) megkettőzhetőek (a gyűrű két szomszédos eleme egy helyben is lehet), vagy a távközlésben is vannak már olyan berendezések, amelyek redundáns kivitelűek kétszeres áramellátási betápláló ponttal.
Egy ’sima’ végfelhasználóhoz képest azonban a biztosítóberendezés maga is általában két kimenetet szolgáltat, mert a távközlő végberendezés és a biztosítóberendezés közötti rövid „LAN kábel” (FTP, UTP) zavara ellen is szeretnénk védekezni. Ezt a két kimenetet jelöltem az 1. ábrán „A” és „B” betűjellel. A biztonságos működéshez általában elég, ha legalább az egyik kapcsolat (mondjuk az A-A) működik, a másikra csak a rendelkezésre állás növelése érdekében van szükség, vagyis ha valami történne az A-A kapcsolattal, akkor a két biztosítóberendezés áttér a B-B használatára. Emiatt a távközlő rendszeren belül az A-A kapcsolatot fölösleges túlbiztosítani, hiszen ez által a B-B úgysem spórolható meg. Itt hívom fel a figyelmet arra, hogy az 1. ábrán ábrázolt két átviteli útvonalnak nincs köze a biztonsági szempontból alkalmazott belső (diverz felépítésű) két biztonsági feldolgozó csatorna fogalmához. Ez utóbbiakhoz kapcsolódik egyébként a „2oo2” = „two out of two” = „kettőből kettő” vagy hasonlóan 2oo3 jelölés. Ebből a szempontból ezt nevezhetnénk 1oo2 –nek, bár e tekintetben nem szokás ezt a jelölést használni. A táviratok biztonságát általában nem kettőzés, hanem olyan protokollok biztosítják, amelyek védelmet adnak a távirat integritás sérülése, meghamisítása, valamint elavulása ellen.
A biztosítóberendezések a későbbiekben még kicsit részletesebben bemutatott protokollok mentén maguk diagnosztizálják és szabályozzák, hogy a két kapcsolat közül melyik működőképes, vagy éppen melyik legyen az „aktív”. (Természetesen az egyébként passzív kapcsolat hibáját is jelzik.) Ilyen módon a biztosítóberendezési végfelhasználói igény gyakorlatilag egy pont-pont összeköttetés az A-A pontok közt: jelöljük ezúttal primer („pri”) átviteli útnak; és egy másik, az előzőtől független eszközökön és topológiai útvonalon megvalósuló összeköttetés a B-B pontok között, nevezzük szekundernek („sec”). Mivel ezek önmagukban egymás tartalékai, a távközlő berendezésekben e két összeköttetéshez (ha az eltérő topológia biztosított) további tartalékolás nem szükséges. Ez alapján a bekezdés elején említett gyűrű topológia is feleslegessé válik, ezt jelöltem az ábrán a gyűrű alsó és felső részén pontozott vonallal. Ez a kérdéskör már más vasutaknál felmerült, egy a DB-nél (Deutsche Bahn = Német Államvasutak) alkalmazott topológiát mutat a 2. ábra. [1]
Egy vonalszakasz esetében általában nemcsak egyetlen pár biztosítóberendezés kommunikál egymással pont-pont-szerűen, hanem több berendezés is, mindegyik többirányú kapcsolati igénnyel. Ezért természetesen adódik az igény, hogy ezeket a különböző kapcsolatokat vonjuk össze egy hálózatba; esetleg, ha már amúgy is IP vagy más szabványos alapú összeköttetésekről van szó, terheljük rá őket más meglévő hálózatra, mint amilyen az SDH volt korábban, vagy lesz újabban az MPLS. Bizonyos esetekben az is előfordul, hogy a gyűrű egyik szárát (primer) meg lehet oldani a szomszédos berendezések közötti technológiai célú „sötét” üvegszál felhasználásával, de ilyenkor is felmerül a szekunder útvonal, vagy a gyűrű bezárásának igénye. Ha van két üvegszálas kábel lefektetve (egy a földben, alépítményben, egy másik a felsővezetéki oszlopsoron) az adott vonal mentén, szóba kerülhet e kettő használata. Ha erre nincs lehetőség, vagy nem elégszünk meg az így biztosított redundanciával, akkor viszont marad a megkerülő vasútvonalak mentén lévő üvegszálas hálózat. Az üvegszálak mennyisége azonban véges, a biztosítóberendezések keltette forgalom pedig nem nagy, így ilyenkor is természetes megoldásnak tűnik egy létező trönk-hálózat (SDH vagy MPLS, Gigabit-Ethernet) felhasználása.
Mielőtt rátérnék arra, hogy milyen feltételek mellett lehet egy biztosítóberendezési „biztonságkritikus” adatátvitelt egy olyan hálózatra terelni, amely más célokat is szolgál, egy kis elméleti kitérő következik, valamint néhány biztosítóberendezési protokoll rövid ismertetése.
3 A rétegmodell (protocol stack)
Az adatátvitelben használatos különböző protokollokat a szerint szokás osztályozni, hogy melyik rétegben működnek. Ez az osztályozás abban is támpontot ad, hogy ezeket minimálisan hogyan kell egymásba ágyazni. Az eredeti osztályozást az OSI állította fel 1983-ban. (3. ábra, baloldal) A TCP (UDP) – IP technológia nem eme szabvány mentén lett kifejlesztve, így némi eltérés kimutatható az OSI által megfogalmazott rétegződéshez képest, de ez most nem zavaró. Az OSI rétegek neveit mutatja a 3. ábra A oszlopa. [2]
A biztosítóberendezési adatátvitelekre is jól alkalmazható ez a protokoll-rétegmodell. A fölső rétegeknél az alkalmazási és az internet réteg közé kerül a biztonsági réteg. (B oszlop) [3] Szerepében hasonlít ugyan az OSI-ban itt elhelyezkedő rétegekre, de funkcionalitásában leginkább itt érhető tetten az ágazati szabványnak való megfelelés okozta specialitás. A biztonsági réteg fog felelni a 7. fejezetben részletezett szabályok megvalósításáért, valamint az előző pontban részletezett redundáns kapcsolódás kezeléséért. Ebben a rétegben működik tipikusan az OCS SAHARA protokoll, amelyet a következő pontban fogok bemutatni. Hasonlóan értelmezhető a titkosításért felelős réteg is, amelyre nyílt hálózaton való átvitelkor van szükség.
Ökölszabályként elmondható, hogy a vasúti alkalmazásokban a szállítási réteg (pl. IP vagy buszrendszer) alatti rétegeket megvalósító elemek általában kereskedelmi forgalomban kapható (=COTS) univerzális célú megoldások. (De ez nem jelenti azt, hogy bármi lehet, bizonyos feltételeket azért teljesíteni kell.) E szállítási rétegtől fölfelé van helye a speciálisan ágazati célra fejlesztett, igazolt megoldásoknak.
Ebben a fejezetben csak ízelítőül megemlítek néhányat az ismertebbek, de legfőképpen a nyíltabbak közül. Az a helyzet ugyanis, hogy a legtöbb gyártó a saját moduljai közé többnyire saját protokollokat fejlesztett. Ezek többnyire a fölsőbb rétegekben működnek, az alsóbb rétegekben pedig valamelyik meglévő ipari (nem vasúti) megoldásra támaszkodnak. E saját protokollok többnyire jogi értelemben is sajátok, így ehelyütt legfeljebb a megemlítésükre szorítkozhatok: Ilyen az Alstomnál az „FSFB2”, a Hymánál a „Safe Ethernet”. Sok cég ezt annyira belügyként kezeli, hogy még a felhasználó/üzemeltető se nagyon tud róla, legfeljebb arról, hogy IP vagy CAN busz, vagy mi az alsóbb réteg. Ez nem csak a nagy gyártókra igaz, gondoljunk csak a kisebb hazai szereplők saját fejlesztésű elektronikus termékeire is! E cikkben sokkal izgalmasabbak a valamelyest nyíltabb hozzáférésű protokollok. Következzék ezekből egy csokorral.
Ezek a rendszerek tipikusan egy nagyobb területen elhelyezkedő és emiatt sokféle (többnyire állomási) biztosítóberendezéssel állnak kapcsolatban. A különböző állomási berendezések egy felsőbb szintű rendszerbe kötését gazdaságosan csak egységesítés mellett lehet megoldani. Ebből fakadóan az interfészt alapvetően a bizt.ber. fölé települő rendszer definiálja, hiszen az új igény e rendszer telepítőjénél lép fel. Ez az egységesítés megtörtént például a FOR interfész feltétfüzet formájában. [4] Ez részletesen az alkalmazási réteget definiálja. A FOR maga ugyan nem tekinthető biztosítóberendezési rendszernek, de a vele kapcsolatban álló állomási berendezések igen. Ebből következik, hogy ennek az interfésznek valamiféle tűzfal jelleget is kell öltenie; erre még a későbbi fejezetekben visszatérek.
Mielőtt a távközlős kollégák felhördülnek vagy kinevetnek, leszögezem: szándékosan pont nélkül írtam, mert nem keverendő össze az X.25-tel. A közük egymáshoz annyi, hogy az X25 az alkalmazási rétegben működik az alsóbb rétegben eredendően X.25-tel (3. ábra D oszlop), újabban IP-vel. Az X25 protokolt az ÖBB (Osztrák Államvasút) definiálta 1987-ben, leülve három nagy berendezésgyártóval (Scheidt&Bachmann, Siemens, Thales). Jellemzően KöFi, illetve ellenmenet-biztosítási funkciókra van kiokosítva. [5] Az eredeti protocoll stack nem tartalmaz elkülönülten biztonsági réteget, mint amilyen a következő pontban szerepel, ezért a mai szabványnak csak úgy tud megfelelni, ha a 8.1 fejezetben bemutatandó nagyon zárt, vagyis I. osztályú belső hálózat épül az X.25 számára. Ezt tükrözi a 3. ábra szürke mezője.
Az OCS annyit tesz, hogy „One chanel safe”, vagyis egy csatornán (is) biztonságos. Ezt úgy kell érteni, hogy az átviteli út, vagy az üzenetküldés kettőzése, ismétlése csak a rendelkezésre állást szolgálja, de önmagában egy üzenet is ki tudja elégíteni a 7. fejezetben részletezett biztonsági követelményeket. Egy megvalósítási lehetőség például, hogy az üzenetet mindkét csatorna generálja, de a ténylegesen kiküldött üzenetbe az A csatorna bájtjaihoz, a B csatornában generálódott CRC kódot illesztik hozzá. Ez tipikusan az alkalmazási réteg alatt, de a hálózati réteg fölött működik. (3. ábra C oszlop) [3]
Az egyik első ilyen a Sahara névre hallgatott, amelyet a Siemens és a Thales dolgozott ki közösen. A majd a 6. fejezetben tárgyalt Eulynx projekt ezt karolta fel, fejlesztette tovább és tette nyílttá új név alatt, ez a Rasta. A 3. ábrán már bemutatott rétegmodellen látható az Eulynx projekt egy másik protokollja is, a „Kisa” nevű, amely lehetővé teszi a nyílt hálózaton való átvitelt is. (Ez utóbbi problémakörről mint hot topic-ról, azaz forró ügyről később még lesz szó.)
Az Európai Unió vesszőparipája az átjárhatóság, amit a vasút területén idegen szóval interoperabilitásnak mondanak. Ennek kulcseleme a pálya és a jármű kapcsolata, ideértve mindenféle kommunikációt, így a vonatbefolyásolásét is. Az ETCS életre hívásakor, 1993-ban specifikáltak jó néhány kapcsolatot. (Pl. balíz – balízantenna; RBC – OBU GSM-R-en keresztül.) [6] Ezeknek az interfészeknek az az érdekessége, hogy a specifikációik teljesen nyíltan hozzáférhetőek. [7] Az EU némelyiket csak funkcionális szinten (vagyis kvázi csak a protokoll stack legfölső rétegeire) definiálta, némelyiket egész pontosan a fizikai réteggel bezárólag. Azokat definiálták nagyon részletesen, amelyeknél biztosra vehető, hogy amikor egy jármű külföldi pályára téved, egész más gyártói környezetbe, az adott kapcsolatnak akkor is nagy biztonsággal el kell látnia a feladatát.
Ebből a szempontból van köztük kakukktojás is, ilyen a pálya oldalon az RBC-NRBC kapcsolat. (Ez két szomszédos pályaszakaszt felügyelő RBC-k közt biztosítja a vonat ’átadását’, megállás nélküli áthaladását.) Ennek az interoperabilitásban közvetlenül nincs szerepe, a kapcsolat résztvevői előre pontosan megismerhetők: csak a két telepített RBC-re tartozik, mégis bevonták a szabványosított interfészek körébe. Vajon miért?
Az előző pontban bemutatott protokollok működésének van egy fontos feltétele: szükséges hozzá, hogy a kapcsolat mindkét végén lévő berendezés értse, beszélje. Ez az alapvető feltétel mint létező feltétel akkor válik mindenki számára nyilvánvalóvá, illetve húsba vágóvá, amikor nem adott. Tipikusan ez történik, amikor két különböző gyártó berendezését kell összekötni. Ez természetesen adódik az egyes projektek földrajzi határán az ellenmenet biztosítás kapcsán, vagy egy későbbi időpontban történő bővítéskor, például egy új útátjáró biztosításakor, vagy RBC telepítésekor.
Vegyük például, amikor egy vonali sorompó kezelését és visszajelentését (esetleg állomási indítását is) illeszteni kell egy állomási berendezéshez. Az XJ jelfogós D55-ös technológiában erre kialakult egy interfész, egy protokoll, amit nevezhetünk 1+1 vezetékesnek; de én ehelyütt az állomási fogadó egység neve után csak VSV (+VSK) protokollként fogok hivatkozni rá. [8] A fiatalabb vonali sorompók (Scheidt & Bachmann, UTB Műszerautomatika stb.) kénytelenek voltak ezt megtanulni, ha D55 állomáshoz csatlakoztatták őket. Az idősebb, pl. Siemens-Halske állomási berendezések is megtanulták (kis pult és vasszekrény segítségével), ha később vonali sorompót kötöttek be hozzájuk. Végül a szintén fiatalabb elektronikus állomási biztosítóberendezések (Thales Elektra vagy Siemens Simis-IS) is kénytelenek voltak megtanulni kezelni a VSV (VSK) jellegű interfészeket, ha meglévő vonalakhoz csatlakoztatták őket. Az csak ez után következett, hogy elektronikus vonali sorompó találkozott elektronikus állomási biztosítóberendezéssel. Ekkor már mind a kettő beszélte a VSV-t, de ha eredendően különböző gyártók különböző országokban fejlesztették őket, akkor egyáltalán nem biztos, hogy ezen kívül bármilyen más modernebb közös nevező, vagyis közös protokoll található. Nincs ez másképp Németországban sem, ahol nemrég tettek lépéseket azért, hogy lehetővé váljon elektronikus sorompó berendezés összekötése elektronikus állomási berendezéssel nem jelfogós, hanem IP alapon. [9]
Hasonló a helyzet a két szomszédos állomást összekötő blokk, vagyis ellenmenet és utolérés kizáró berendezés esetében. Az új elektronikus állomási biztosítóberendezéseknek itt is először a meglévő szomszéd állomásokhoz, jelfogós vonalakhoz kellet illeszkednie, így mindkét berendezésben kifejlesztették a ’8+n vezetékes’ protokollt. (A 75 Hz-es „Önműködő térköz-biztosítóberendezés” alapáramköre 8 vezetékes, azonban ez többször továbbfejlesztésre került, pl. emeltsebességű alkalmazásra és ezzel együtt a szükséges vezetékek száma is növekedett.) [8] Csak az utolsó 10 évben fordult elő, hogy két, különböző gyártótól származó elektronikus állomási biztosítóberendezés között kell blokk-kapcsolatot létesíteni. Itt is elmondható, hogy többnyire a már ismert jelfogós alapokon valósulnak meg ezek a kapcsolatok, például Óbuda (MÁV, Siemens) – Aquincum (BHÉV, Thales) vagy Székesfehérvár (MÁV, Thales) – Ódinnyés (MÁV, Siemens) között. Itt viszont akad pozitív példa is! Tudok olyat mondani Magyarországon, ahol egy Siemens és egy Thales állomási berendezés közt létesült ellenmenet és utolérés kizárás egyetlen jelfogó felhasználása nélkül! Hol? Szentgotthárd (GYSEV, Thales) – Jennersdorf (ÖBB, Siemens) állomások között.
Mi tette ezt lehetővé? Az, hogy annak idején, bő 20 évvel ezelőtt az ÖBB előírta egy feltétfüzetben [5], hogy a hozzá elektronikus berendezést szállító gyártóknak milyen protokollt kell teljesíteniük. Ez a már ismertetett X25 protokoll. Igaz, hogy az X25 mára némiképp elavult, de ettől még a probléma megoldásának módját érdemes tanulmányozni.
6 Kompatibilitás és az Európai Unió
Az Európai Unió a maga szabályozási erejével és pénzügyi forrásaival ott lép fel, ahol a szabad piac feltételei nem adottak. De most nem az interoperabilitást fogom elővenni: különböző berendezések összekötése szempontjából egy érdekes helyzet a nagyobb pályavasúti cégeknél áll fenn: Itt a probléma abból fakad, hogy a nagyobb hálózatokon több generációjú és többféle gyártótól származó berendezések üzemelnek. Ezeket a közlekedés biztosítására egymással (és újabban központi üzemirányító rendszerekkel is) egyre gazdagabb funkcionalitással szeretnénk összekötni. Mindez igaz az elektronikus rendszerekre, de a jelfogósakra is, amennyiben az összeköttetéseik mindenféle átalakító segítségével egyre inkább az üvegszálas, ill. IP technológiák felé terelődik. A gond az, hogyha egy vonalrészre egy gyártó betette a lábát (értsd: komoly tőkét képviselő berendezéseket telepített), akkor a szomszédos vonalrészek illesztése, vagy a meglévő bármiféle bővítése teljes mértékben az adott gyártótól függ. Ez egy monopolisztikus helyzetet eredményez, ami nincs jó hatással a piacra. Egy másik probléma, hogyha ennek a komplex berendezésnek egy alkatrészét, modulját már nem gyártják, akkor hogyan lehet újra cserélni anélkül, hogy az egész berendezést kéne jelentősen átépíteni. Mindez oda vezetett, hogy több pályavasúti cég arra jutott, hogy a rendszerek határain lévő interfészeket szabványosítaniuk és minden potenciális gyártó számára hozzáférhetővé kell tenniük. Ha ezt az elejétől fogva a beruházásaikban megkövetelik, akkor a később épülő berendezések csatlakoztatása, és a bővítés is nyitott versenyben folytatható. Gyártói oldalról ennek akkor van előnye, ha ezt a standard interfészt minél több helyen el lehet adni, vagyis nem kell országonként néhány tíz berendezésre újabb és újabb komoly fejlesztéseket fordítani, hanem az egyszer kifejlesztett termék minél nagyobb példányszámban eladható. Ez is az árak csökkenéséhez és ez által a vasút versenyképességének növeléséhez vezet. [10]
E hosszú bevezető után nézzük meg, mire is jutottak konkrétan. A dolgok mai állása szerint tíz pályavasút-társaság összefogott és 2014-ben létrehozta az Eulynx nevű szervezetet. E társaságok név szerint az alábbiak:
- DB Netz – Németország;
- SNCF – Franicaország;
- Network Rail – Egyesült Királyság;
- Infrabel – Belgium;
- ProRail – Hollandia;
- CFL – Luxemburg;
- Trafikverket – Svédország;
- Bane NOR – Norvégia;
- FTA – Finnország;
- SZ – Szlovénia.
A cikk leadásakor érkezett a hír, hogy tizenegyedikként az SBB – Svájc is csatlakozik.
E keretek között kidolgoztak egy biztosítóberendezési referenciamodellt, és specifikálták a modulok közötti interfészeket egészen az alkalmazási rétegig bezárólag. A dokumentációcsomag 1. verzióját Baseline1 jelöléssel 2017. március 31-én adták ki. [11] Minden rendszer, alrendszer felé megállapítottak egy ún. „SCI”-t. Ez már erősen szabványosítaná az alkalmazási réteget is (lásd 3. ábra C oszlop [12]), ezáltal a funkcionalitásra is erős befolyással bír. A referenciamodell az SCI-kkel a 4. ábrán látható. [10]
Az idézett dátumokból is látható, hogy ezek viszonylag új fejlemények, de a jövőben meghatározóvá válhatnak. Tekintettel a magyar piac ilyen szempontból kicsi voltára és az európai gyártók berendezéseinek jelenlétére, ennek hatása talán hozzánk is begyűrűzik. Végezetül egy szót megér az Eulynx előzménye is: A német vasút (DB Netz) már korábban felismerte a fenti problémát, és „Neupro” (= „Neuausrichtung der Produktionssteuerung der DB Netz AG” = A termelésirányítás újfajta összehangolása a DB pályavasúti üzletágánál) néven indított projektet 2006 körül. [13] Az interfészek szabványosítása tekintetében ez a projekt olvadt be az említett Eulynx-be.
7 Szabvány és elmélet a biztosítóberendezési adatátvitelben
Az előbbi pontokban bemutatásra került jó néhány protokoll, illetve a különböző gyártók által szállított rendszerrészek összekapcsolhatóságával kapcsolatos probléma. Rendszeresen felmerül a más célra épített adatátviteli hálózatok használhatóságának a kérdése is. Mi az, amit valahol a mélyben minden ilyen hálózatnak, illetve biztosítóberendezési protokollnak teljesítenie kell, az a dolog biztonsági aspektusa. Ehhez a XXI. században nehéz önszerveződő gazdasági alapon közelíteni, ezért ennek biztosításához hívhatóak segítségül a szabványok. Témánk esetében ez elsősorban az EN 50159:2010 jelű család. [14] Ennek értelmezése egy-egy konkrét alkalmazási esetre nem biztos, hogy teljesen egyértelmű, de mindenképpen alapít egy közös nyelvet és iránymutatást a termékfejlesztők számára. A hálózatépítők, -üzemeltetők sem hagyhatják figyelmen kívül, mert az ebben leírt feltételek folyamatos biztosítása az ő kezükben van.
A szabvány fő koncepciója, hogy minden, a biztosítóberendezési adatátvitelben részt vevő hálózatot a szabványban definiált három osztály valamelyikébe sorolja. Ez a három osztály – konyhanyelven fogalmazva – a zártságában különbözik egymástól. Ezért az egyik kulcskérdés, hogy egy-egy meglévő vagy kiépülő hálózatot melyik kategóriába tartozónak tekintünk. Ehhez adott néhány döntési kritérium.
A szabvány definiál tipikus ’hálózatmeghibásodási’ avagy ’távirat-rongálódási’ eseteket. Azt is leírja, hogy melyik meghibásodási forma melyik kategóriára jellemző, vagyis, hogy mennyire kell számítani rá, védekezni ellene az adott kategóriájú hálózatot használó biztosítóberendezési protokollokban.
Persze azt is hozzáteszi, hogy az egyes hibatípusok veszélyességét és az ellenük alapított védelmet egy konkrét megvalósításkor az EN 50129 koncepciójának megfelelően kockázatelemzéssel kell alátámasztani. Ezt megteszik a termékfejlesztők, majd ennek megfelelően hozzák létre a terméket. A (biztonsági) alkalmazási feltételek (SAC) között rögzítik és átadják, hogy az adott termék milyen hálózatra köthető. Tehát aki a terméket alkalmazni, telepíteni, használni szeretné, annak ezt kell teljesítenie, amikor annak adatátviteli kapcsolatait tervezi egy-egy kivitelezési projektben.
A három hálózati kategóriát a szabványban csak sorszámozzák, illetve, hogy a szabvány korábbi változatával összeegyeztethető legyen, utal a „nyílt” és a „zárt” elnevezésekre. Sajnos az a tapasztalatom, hogy a Magyarországon elterjedt szóhasználat, a hazai értelmezés ezt nem pontosan tükrözi. Ezért az itt mellékelt két táblázat fejlécének második sorában látható módon én is eltérek az előtte zárójelben feltüntetett, a szabvány által favorizált jelölésektől.
A problémák, értelmezési nehézségek természetesen a határoknál adódnak. Ha figyelembe vesszük az előző pontban a rétegmodellről elmondottakat, akkor juthatunk olyan következtetésre, hogyha mondjuk az MPLS hálózatban, ami az IP réteg alatt működik, létrehozunk egy VLAN-t, akkor az a speciálisan az IP réteg fölött megjelenő biztosítóberendezési protokollok szempontjából I. osztályú hálózatnak tekinthető. Ez azonban téves következtetés. Ebben az esetben a kockázat elemzés, a biztonsági követelmények meghatározása és a fejlesztés során úgy kell eljárni, ahogy az a II. osztályhoz elő van írva. Az más kérdés, hogy egy-egy hibaeset, vagy az az elleni védekezés, vagy a rá vonatkozó SAC teljesítése könnyen belátható, de ettől még a validálás során, illetve a biztosítóberendezési termék biztonsági ügyében (safety case) a II. osztályú hálózathoz tartozó eljárást kell követni. Hasonló a helyzet a SDH esetén is. Ebből is látható, hogy a távközlési gyakorlatban elterjedt tunel-ezési technikákat a biztosítóberendezési kapcsolatokra csak óvatosan lehet alkalmazni. A következő pontokban még kitérek rájuk.
A belső hálózat validálhatóságának alapja általában az erőteljes túlméretezés. Ugyanez az út a nem teljesen, minden paraméterében determinált II. osztályú hálózatnál nem járható. Itt már a gyártói validáció során több esetre kell gondolni, illetve nem is annyira a biztonság, hanem inkább a kívánt magas rendelkezésre állási igény kielégítése érdekében a gyártó kénytelen bizonyos hálózati szolgáltatási paraméterek (QoS) meglétét a hálózattól megkövetelni. E követelmények betartását aztán esetenként tanúsítani kell. Ennek egy szaftos példája, amikor az ÖBB a korábban kiépített országos GSM-R hálózatát elkezdte az ETCS L2 számára használni, és az ETCS specifikációkban előírt tanúsítást kellett elvégeznie [15].
Most a szabványban szereplő három kategória gyakorlati megvalósítását veszem górcső alá egyenként.
8.1 Belső (I. osztályú) hálózat
Belső hálózat tipikusan egy-egy berendezés moduljai között egy-egy rack szekrényen belül van kialakítva; tehát többnyire az egész belső hálózat a jelfogó helyiségen belül marad, így az illetéktelen behatolás elleni védelem mechanikusan biztosítható (t.i. akárki nem léphet be a jelfogóba). A kis távolságokból adódóan nem okoz gondot annyi kizárólagosan csak ’saját’ használatú kábelt kiépíteni, amennyi éppen szükséges. Könnyű belátni, hogy ebben az esetben az előző pontban megfogalmazott ide vonatkozó kritériumok könnyen teljesíthetőek, és a termék (vagyis az adott belső hálózatot alkalmazó rendszer) a hálózattal együtt az egész életciklusában jól kézben tartható; az alkalmazás már a generikus termék (gyártói) létrehozása során jól validálható.
Ezek a hálózatok ránézésre általában ugyanúgy kereskedelmi forgalomban elterjedt IP ethernet switch-ekből állnak, mint amilyenek a később tárgyalandó zárt és nyílt hálózatok részei is lehetnek. Ezért az a távközlési hálózat tervezőjének, majd az üzemeltetőjének a felelőssége, hogy még véletlenül se kerüljön nem megengedett kapcsolat a belső hálózatra. Egyszerűbben fogalmazva: oda semmi ne legyen bedugva, ami nem oda való! (Ellenkező esetben minden bizonnyal éppen megsértünk egy biztonsági alkalmazási feltételt, vagyis SAC-ot.)
Egy fokkal nehezebb a helyzet, ha ezt a belső, vagy eredetileg csak belsőnek szánt hálózatot nagyobb földrajzi szélességre, mondjuk egy húsz-harminc kilométeres vonalszakaszra kell kiterjeszteni. Ilyen távolságokon ma már általános az optikai kapcsolat használata. Ha mind a primer, mind a kerülő útirány sötét szálakon biztosítható, akkor szerencsénk van. A gond a nagy felújítási projekteken ott szokott fellépni, hogy általában van még az adott terméken kívül még öt másik, amely hasonló igényekkel lép föl pont ugyanazokon a viszonylatokon. Mindegyiknek külön-külön szálat biztosítani elég pazarló megoldás, így hát jogosan merül fel az igény ezeknek az alrendszerhálózatoknak az összevonására. Csakhogy innentől egy-egy termék (gyártója), illetve annak validációja szempontjából ez már nem belső, hanem csak zárt (II. osztályú) hálózatnak tekinthető.
Van-e megoldás arra, hogy hogyan lehet egy eredetileg belsőnek tervezett hálózat számára tunelt biztosítani egy (legalább II. osztályú) zárt hálózaton? Van. Ha jobban megnézzük az 1. táblázatot, akkor az derül ki, hogy az egyik esetben a hálózat és karakterisztika szigorú rögzítése a garancia, a másik esetben a protokollba épített védelmi mechanizmusok. A legnagyobb fejfájást a II. osztályú hálózatban a késett távirat késett voltának felismerése okozza a fogadó oldalon. Ha a tunel két végére egy olyan dobozt teszünk, amely felfedezi és elnyeli, vagyis a belső hálózatba nem adja tovább a késett csomagokat, az megoldást jelenthet a felvázolt problémára: ugyanis a táviratvesztés ellen könnyebb védelmi mechanizmust gyártani, kockázatelemezni és igazolni. Mondhatni, „Az inkább később, mint soha.” közmondás itt fordítva érvényesül, kb. úgy, ahogy egy hangverseny kezdésekor: „Ha késik, akkor inkább már ne is jöjjön be a terembe.” Ebből látszik is, hogy ez a módszer akkor működhet jól, ha a tunelt adó zárt hálózat egyébként elég robosztus, és viszonylag ritkán adódik benne késés, ami az előbbiek miatt táviratvesztést okoz. Egy érdekes eset lehetne itt az SDH, amely konstrukciójából adódóan nem késik.
8.2 Zárt (II. osztályú) hálózat
Üzemeltetői szempontból, illetve a kulcsrakész projektek által szállítandó termékek MÁV rendszerébe integrálása szempontjából sokkal érdekesebbek azok az összeköttetések, ahol a gyártó eleve a zárt hálózati, vagyis a II. kategóriájú hálózati kritériumot fogalmazza meg. Azok a termékek, amelyek ilyen igénnyel lépnek fel, egy közös hálózatba, illetve már más célból létező hálózatba terelhetőek. Konkrét példát említve: a mostanában települő elektronikus biztosítóberendezések, KöFi-k ilyen kapcsolatait a GSM-R projektben épülő MPLS hálózatra lehetne terhelni. Mi kell ehhez?
– Egyrészt műszaki tervezési szempontból a biztosítóberendezés szállítójának és a hálózatot konfigurálónak meg kell egyezni az elvárt és biztosított tervezési, szolgáltatási paraméterekben (QoS). Ezek tipikusan az átviteli idők, sávszélesség paraméterei az egész rendszertől elvárt rendelkezésre állás biztosítása érdekében. A megegyezés kétoldalú: A biztosítóberendezési oldalról elég pontosan definiálni kell(ene) az igényeket, várható forgalmat. Távközlős oldalról pedig megnyugtató biztonsággal igazolni kell e követelmények mindenkori teljesítését.
– Másrészt a távközlési hálózat üzemeltetőjének igazolnia, szavatolnia kell a „zártságot” a biztosítóberendezési felhasználó számára. Más szavakkal: biztosítania kell őt arról, hogy ezen a hálózaton keresztül nem kell hackertámadástól (!) tartania. Ha a hálózatot nem a kivitelező építi ki, hanem a megrendelő bocsátja rendelkezésre, akkor a zártságot neki kell igazolnia. T. i. a feltételek mindenkori teljesítését az üzemeltető és nem a kivitelező tudja garantálni.
Ehelyütt teszek egy fontos kitérőt a QoS paraméterek és az általuk befolyásolt biztosítóberendezési funkciók összefüggéseire, mert ezt tipikusan olyan területnek érzem, ahol könnyű téves következtetésekre jutni. Legyen a kipécézett paraméter a távirat átvitelének ideje. Az eddigi biztosítóberendezési átviteltechnikákban (pl. rézkábelek végein üzemelő jelfogók) azt szoktuk meg, hogy ez gyakorlatilag egy állandó, ráadásul elhanyagolhatóan kicsi érték. Így például, amikor az a kérdés, hogy egy útátjárótól milyen messze kell tenni a behatási pontjait, akkor ezzel nem is nagyon számolunk külön. Jobb esetben beleértjük a sorompó reakcióidejébe (ha számolunk vele egyáltalán, hiszen a MÁV 102676/1983 9A rendelete, amely alapján a behatási pont helyét alapesetben számítjuk, ilyet elő sem ír), és konstansnak tekintjük. Ha követelmény, hogy ennek az útátjárónak a nem lezárt állapota visszahasson a vonatra, akkor a behatási pont kitűzésénél figyelembe kell venni a vonatbefolyásoló berendezés működési idejét is. EVM esetében ezt is többnyire konstansnak tekintjük, kiválasztva az adott helyzetre megfelelő értéket egy táblázatból.
Ha a vonatbefolyásoló berendezés rádiós táviratokat használ (most tekintsünk el attól, hogy az csak III. osztályúnak tekinthető, mert az itt tárgyalt probléma II. osztályú hálózatra is értelmezhető, csak kevésbé szemléletes), amely sikertelen kézbesítés esetén újra próbálkozik a küldéssel, akkor kicsit más a helyzet: Az esetek 99,… százalékában ez elsőre sikerül neki, a fennmaradó kevés esetben (pl. amikor villámlik) pedig lehet, hogy jelentős késéssel. A késés maximális mértéke persze biztonsági reakciók által felülről korlátozva van, és ez által definiálható. De mire méretezzük az útátjáró behatási pontját? Ha a lehetséges maximális átviteli időt vesszük figyelembe, akkor nagyon messze kell tennünk a behatási pontot, ami az esetek 99,… százalékában fölöslegesen korai záráshoz vezet. Az persze nyilván nem hagyható, hogyha villámlik, akkor az a vonat az értesítés késedelme miatt fékezés nélkül fehér sorompóra futhasson. Ha a funkcionalitást a vonatbefolyásoló és a sorompóberendezés között a merev függésű jelzőhöz hasonlóan határozzuk meg – vagyis a vonat fehér sorompó esetén olyan jelzést kap, hogy lassítani kell –, és sikeres behatás esetén ezt a korlátozást vonjuk vissza, akkor merőben más a helyzet. Ilyenkor normális, az esetek 99,… százalékát kielégítő behatási pont kitűzés mellett a vonatok nagy többsége időben, még a fékezés megkezdése előtt értesül arról, hogy erre nincs szükség, a sorompó rendben lecsukódott. Az a néhány vonat, amelyik nyári zivatar idején közlekedik, és ezért náluk a sorompóra vonatkozó sebességkorlátozást nem lehet visszavonni, fékezni fog. Véleményem szerint ez a megoldás egy optimális kompromisszum lehet: a behatás se kerül túl messze, ezzel az esetek nagy többségében a normális előzárási idő tartható, és a néhány kilógó eset biztonsága is szavatolva van némi vonatkésés árán. A tervezői kihívást a 99,… szám meghatározása jelenti! A szám meghatározásánál érdemes figyelembe venni a hozzátartozó valószínűségi változó eloszlásának tulajdonságait is.
A fenti példa zárt hálózati szolgáltatási paraméterei szempontjából azt mutattam be ezzel, hogy nem mindegy, hogy az átlagos, vagy a legrosszabb átviteli időről beszélünk-e. Ez igaz a többi hálózati szolgáltatási paraméter esetében is. Hasonló problémába futhatunk bele pl. egy rendszer(rész, pl. KöFe) újraindításakor is, amikor az hirtelen átlagon felül terheli meg a hálózatot.
8.3 Nyílt (III. osztályú) hálózat
Lépjünk eggyel kijjebb, mi a helyzet a II. és a III. kategória határán? Ismerünk olyan helyzeteket, ahol az egyébként II. osztályú (rész)hálózatokban elhelyezkedő, II. kategóriára alkalmas biztosítóberendezéseket, illetve az őket tartalmazó (rész)hálózatokat kell összekötni, de ez csak egy nyílt (III. osztályú) hálózaton keresztül lehetséges. (Például a MÁV intranet hálózatában kiosztott IP végpontokból alkotott VLAN az EN50159 szerint inkább III. kategóriájú hálózatnak tűnik.) Ehhez tunelhez a védett hálózat kapujába valamiféle tűzfalszerűséget kell állítani, amely egyúttal a titkosítást is el tudja látni. Az nyitott kérdés marad, hogy egy ilyen tűzfal mennyire „erős”, vagyis egy a nyílt hálózatból induló rosszindulatú támadás mennyire tudja feltörni, mennyire jut át rajta. Jobb esetben csak a kapcsolat szakad meg a biztonsági hálózatrészek között, mondjuk egy túlterheléses támadáskor.
Nyílt hálózat alkalmazása biztonságkritikus (SIL4) vasúti alkalmazásban eddig nem volt túl jellemző. Az egyik első rendszer, amelyet már elve így terveztek, az ETCS (L2)! A rádiós átvitelt (GSM-R) mindenképpen III. osztályú hálózatnak kell tekinteni, mert egy megfelelő rádiókészülékkel bárki bele tud hallgatni a mozdony és a pályaberendezés (RBC) közti beszélgetésbe. Az ETCS L2 rendszerben védekezésül hitelesítési kulcsokat definiáltak. Ahhoz, hogy egy mozdony felvegye a kapcsolatot azzal az RBC-vel, amelynek a területére behalad, előzetesen ismerniük kell egymás hitelesítési kulcsát. (A mozdonynak az RBC-ét, az RBC-nek a mozdonyét.) De hogyan kerül a kulcs előzetesen a berendezésbe? Ehhez kell egy szervezeti egység, amely üzemelteti a KMC-t, ahol a kulcsok generálása történik, majd gondoskodik ezek célba juttatásáról. [16] Ez a tevékenység kritikus, hiszen ha illetéktelenek kezébe kerül a kulcs, akkor azok képesek lehetnek egy valós jármű felé RBC-t szimulálva téves parancsokat adni. Ezért elsősorban ez a célba juttatás USB-n, pendrive avagy memory stick segítségével offline történik. (De még a pendrive-on se pőrén, hanem egy további ún. szállítási kulccsal titkosítva.)
Sok RBC és sok jármű üzemeltetése esetén ez az offline módszer eléggé körülményes, ezért fölmerült egy online verzió kidolgozásának ötlete is, ahol az RBC-k hálózaton, praktikusan intraneten, tehát egy másik nyílt hálózaton keresztül kapják meg a kulcsokat. Ma ez még Németországban is csak álom. [17]
Idáig jutva most már az Olvasó számára is világos a kép: a különböző hálózatok egyre inkább összekapcsolódnak, és ezeken a kiterjedt hálózatokon egyre több biztosítóberendezési objektum jelenik meg. Ráadásul az eddig csak egy-egy berendezésen belül kezelt esszenciálisan biztonságkritikus információk is egyre gyakrabban kerülnek nagyobb hálózatokban átvitelre. Itt két fontos momentumot kell megemlíteni. Az egyik, hogy a többféle hálózattal egyidőben kapcsolatban lévő, különböző hálózatok határán elhelyezkedő berendezések mennyire tudnak tűzfalként viselkedni. A másik, hogy ha egy támadás bekövetkezik, akkor az mikor és milyen pontossággal fedeződik fel az üzemeltető számára.
A tűzfal jellegű viselkedés egy a ma már a MÁV-nál is aktuális esete, hogy a diagnosztikai célú hálózatból mennyire lehet visszahatni a diagnosztizálandó berendezésre. Pont e visszahatás-mentesség, illetve a diagnosztika felöli feltörhetetlenség biztosítása érdekében alkalmaz a Thales mind a mai napig RS232/485 átvitelt a Webride diagnosztikai PC és az Elektra DGP számítógépe között. Általában is érdemes a biztonságkritikus adatokat továbbító hálózatok – mint belső vár –köré, több körben falat vonni az általános internet felől nézve. Így strukturálja a DB is az egész intranetét. [17]
Az előbbi egyfajta passzív védekezés a behatolás ellen, míg a Thales –kihasználván a katonai, hírszerzési portfólióját is – kínál megoldásokat az aktív védelemre is, vagyis arra, hogy időben felfedezzük és ezáltal akár meg is hiúsítsunk egy kiber-támadást, még mielőtt az nagyobb károkat okozna. Történtek már ilyen támadások közlekedési infrastruktúrák ellen, de ezek eddig szerencsére csak nem tervezett leállásokhoz vezettek. Bár egy kiterjedtebb leállás, ha balesethez talán nem is, de komoly üzleti bizalomvesztéshez és bevételkieséshez biztosan vezethet. [18]
A cikk keretén belül megpróbáltam eljutni a rézdróton összekötött SH blokkelemektől a nyílt hálózatot használó biztosítóberendezési alkalmazásokig. A biztosítóberendezési szakmának ma ez a terület a legdinamikusabban fejlődő része. Ez meglátszik a friss és gazdag irodalmon is. Egyre-másra jönnek elő az újabb fejlemények. A vasútnak már régen is volt hadászati jelentősége, és ez igaz marad a kiber-hadviselés korában is, amit ma még csak ízlelgetünk. Lemaradnunk nem szabad.
[1] Hans Kraft: „Netzwerkarchitekturen im Kontext von SwISS und NeuPro” Signal + Draht 2013/12
[2] Wikipedia: „OSI model” https://en.wikipedia.org/wiki/OSI_model (2017. 07. 03-án)
[3] Alcatel-Siemens: „Protocol Definition: Safe, highly available and redundant protocol (SAHARA Protocol)” 2.2 verzió 2006. 10. 18.
[4] Prolan Irányítástechnikai Zrt.: „FOR és biztosítóberendezések közötti interfész Feltétfüzet” FORIF-104, 118. verzió 2014. 05. 26.
[5] ÖBB: „Pflichtenheft X25 Schnittstelle” Version 2.0; 1993. 03. 22.
[6] Wikipedia: „European Train Control System” https://en.wikipedia.org/wiki/European_Train_Control_System (2017.07.03-án)
[7] http://www.era.europa.eu/Core-Activities/ERTMS/Pages/Current-Legal-Reference.aspx (2017. 07. 03-án)
[8] Németh László „Vonali biztosítóberendezések” MÁV Rt. Vezérigazgatóság, 2000
[9] Stephan Wallasch, Harald Dambietz, Michael Lehmann: „Standardschnittstelle zwischen elektronischem Stellwerk und Bahnübergangssicherungsanlage” Signal + Draht 2015/4
[10] Frans Heinen: „Eulynx, The next generation signalling strategy for Europe” Signalling Seminar IRSE ITC – JR East 2016. 04. 07.
[11] https://eulynx.eu/index.php/home2/21-baseline-1-released (2017. 07. 03-án)
[12] Dr. Bernd Elsweiler: „Beyond ETCS – Interoperable interfaces and more” IRSE News 2014/198 (2014. márc.)
[13] DB Netz AG.: „Mit Neupro auf neuen Wegen” Netnachrichten 2009/1 (2009. márc.)
[14] CENELEC: EN 50159 „Railway applications. Communication, signalling and processing systems. Safety-related communication in transmission systems” 2011.
[15] Roman Herunter,Gerhard Fritze: „Die EU-Prüfung des GSM-R-Netzes der ÖBB-Infrastruktur AG entsprechend der TSI ZZS” Signal + Draht 2016/6
[16] UNISIG: Subset-038 2.3.0 „Off-line Keymanagement FIS” 2010.
[17] Stefan Seither: „ETCS online key management” Signal + Draht 2016/9
[19] Christian Kispert, Alexander Szőnyi: „Thales CyberRail: Security in safety critical infrastructures” Signal + Draht 2016/6
Kővári Mátyás
A cikk a Vasúti VezetékVilág 2017. szeptemberi számában jelent meg.