Jelen cikk a SIEMENS és THALES vállalkozók RBC központjainak komplex rendszerét és vizsgálhatóságának lehetőségeit mutatja be. A funkcionális tesztek során alkalmazott rendszerek lehetnek valós, emulált és szimulált rendszerek. A vizsgálati fázis jellege határozza meg, hogy mely rendszer, alrendszer, rendszermodul kerül elemzés és kiértékelés alá. Szimuláció során a szóban forgó rendszerelem úgy működik, mint ahogy a valóságban ez elvárható, de ezt más működési folyamaton keresztül éri el. Emulációról akkor beszélünk, ha a valós hardverhez írt tényleges biztosítóberendezési szoftver egy arra felvértezett szoftverkörnyezetben tesztelhető. Ilyenkor lehetőség van a biztosítóberendezési és ETCS funkciók hiteles és tanúsított vizsgálatára.
A Technológiai Központban rendszerspecifikus teszteket végzünk emulált környezetben. A funkcionális teszteket projektspecifikus adatbázis-vizsgálat előzi meg.A vállalkozók biztosítják számunkra a MÁV hivatalos input dokumentum követelményrendszerében és technológiában definiált adatbázisokat, generikus dokumentumokat, előterveket, kiviteli terveket. Rengeteg adat statikus és kiértékelő vizsgálata vár a tesztelőre, mely tartalmazza a transzparens balíz adatokat (balíz telegramok, aszpektek), a projektben szállított RBC központ konfigurációját és a topológiát leképező adatbázist, rendszerfelépítést, projektspecifikus változókat, nemzeti értékeket.
A projektálás vizsgálatok első fázisa a felsorolt technológiai csoportokat, vizsgálatokat tartalmazza:
- programozásra kerülő fix balíz adatok,
- programozásra kerülő vezérelt balíz adatok,
- RBC pályaadatok konzisztenciája,
- RBC kezelőfelület előtervi megfelelősége.
Az ETCS Level 2 szint irányítóközpontja az RBC (Radio Blokk Center), célszámítógépek redundánsan kiépített hálózata:
- Tartalmazza az RBC körzetbe tartozó valamennyi állomás és állomásköz vágányútelemeit és topográfiai adatait.
- Állandó interfészeken keresztül kapcsolatot tart a körzetébe tartozó valamennyi biztosítóberendezéssel.
- Ha egy jármű ETCS Level 2 szinten üzemelő fedélzeti berendezéssel az RBC körzetben közlekedik, akkor az OBU (OnBoard Unit) és az RBC között kétirányú kapcsolat épül fel GSM-R rádiós hálózaton keresztül.
- Az RBC-hez csatlakozik a kezelői munkaállomás HMI számítógépe (Human – MachineInterface). Ezen a kezelőfelületen a forgalmi szolgálattevő kötelező érvényűen konfigurálhat menetengedély-visszavonást, felsővezetéki korlátozásokat és lassan bejárható pályarészeket az ETCS mozdonyvezető számára.
Az első fázisban az RBC adatbázisát vizsgáljuk meg, hogy hibátlanul leképezi-e az előtervben megfogalmazottakat:
- Az előterv PoE (Point of Elements) adatbázisából az érintett állomások és vonalszakaszok valamennyi ETCS szempontból lehetséges vágánytopológiáját és vágányútelemét betöltik az RBC-be, előzetes projektálással. Ez egy előre beprogramozott statikus adatbázis, időben már nem változik. A PoE adatbázis geodéziai felmérésén alapuló pozíció-adatokat tartalmaz.
- Az RBC az interfészein keresztül folyamatos kapcsolatban áll az állomási és vonali biztosítóberendezésekkel. Így folyamatosan aktualizálja a statikus adatbázisát, tehát a legpontosabban leírja a pillanatnyilag beállított vonat-vágányutak tényleges topológiáját. Ez alapján állítja elő a Menetengedélyt (MA), amelyet majd kiküld az ETCS vonatnak.
Az RBC-be betöltött adatbázis zárt, védett. Generikus és projekt-specifikus részből áll össze, amelyekhez nem lehet hozzáférni. (PC számítógépek alkalmazásaival nem olvashatók.)
A projektáló program (tool-nak nevezik) miközben előállítja az RBC adatbázist, olyan biztonságigazolt kimenetekkel is rendelkezik, amelyek előállítják a vizsgálófájlokat. A biztonságigazolt fájlok hitelesek és nagyteljesítményű PC számítógépek alkalmazásaival vizsgálhatók, ezért a vizsgálat alapjául ezek szolgálnak.
Tehát a vizsgálat I. fázisa összehasonlítás alapú: az előterv adatait referenciának tekintve vizsgáljuk az RBC adatbázisának megfelelőségét.
Hogyan alakul ki az RBC adatbázis, milyen szerkezetben, milyen adatokat tartalmaz? (csak elméleti, áttekintő szintű ismertetés)
Az előterv torzított helyszínrajza kezdőponttól (KP) – végpontig (VP) növekvő szelvényszám mentén ábrázolja az állomások és az állomásközök vágányelemeit. Gárdony állomás példáján mutatjuk be (1. ábra).
1. ábra – Gárdony állomás torzított helyszínrajza
A rajz kétdimenziós, hossz- és keresztirányú kiterjedését csak nagyon bonyolultan lehetne feldolgozni digitális adatbázisba, ezért szükséges két változtatás.
A torzrajz leegyszerűsítése. A lényeges vágányszakaszok és vágányútelemek kiválasztása a feleslegesek elhagyásával (2. ábra).
2. ábra – Gárdony állomás leegyszerűsített topográfia rajza
A leegyszerűsített topológia felbontása csomópontokra és élelemekre (3. ábra).
3. ábra – Gárdony állomás felbontása csomópontokra és élelemekre
Az így létrejött topológiai láncoknak csak hosszirányú kiterjedésük van, ezért leírhatók táblázatos formában. A csomópontok pozícióit, az él-elemek hosszát az előterv geodéziai felmérésén alapuló Km-értékek adják meg (4. ábra).
4. ábra – Gárdony állomás topológiája táblázatos adatbázisban (III. vágány, részlet)
Az eddig ismertetett folyamatban a balízok csak olyan részletességgel szerepelnek, mint a többi vágányúti elem. (Csak az azonosítójukés a pozíciójuk szerepel.) Tehát szükség van egy további adatbázisra, amely a balíz-táviratokat tartalmazza tételesen, sorrólsorra. Ez a táblázat formájú adatbázis szintén teljes körű vizsgálat alá kerül.
Ezután kezdődik az a folyamat, amelyben a projektáló program további adatok bedolgozásával létrehozza az RBC adatbázisát, valamint a biztonságkritikus vizsgálófájlokat.
Az RBC adatbázis összetett struktúrájában hatalmas mennyiségű adatot kezel. Pl. Ferencváros RBC adatbázis megközelítőleg 32 ezer sorból áll, úgy, hogy némelyik sorban több (sok-sok) változó értéke található. Az előtervvel megfelelő egyezését kell validálni részben algoritmusokkal (szűrés-összehasonlítás), részben manuálisan, a „józan ész” használatával.Itt a „józan ész” nem cinikus kifejezés: a vizsgálónak sosem szabad elveszni a változók és számértékeik halmazában, a legfontosabb szemlélet: „Hogyan fog közlekedni a vonat?”
A vizsgálat során minden változó, és értéke átesik egy szűrésen: egyezik-e az előtervben tervezett értékkel? Három halmaz keletkezik:
- Egyezik, rendben van. Ezt zöld színnel jelöljük.
- Egyértelműen látszik, hogy hibás, így nem fog működni. Vörös színű. (Előfordulnak egyszerű elírások, félrenézések is, ez arra utal, hogy a projektálás befejezésekor, a kiszállítás előtt még lenne mit szűrni, ellenőrizni a szállítónak.)
- Sárgával jelöljük azokat, amiket csak észrevételként, kérdésként szerepeltetünk a hibajegyek között. Ha a szállító elfogadható magyarázattal tudja lezárni ezt a hibajegyet, mi elfogadjuk.
A 2. és 3. észrevétel bekerül abba a hibalistába, amelyet a MÁV Zrt. hivatalosan megküld a szállító felé. Az így észrevett eltérésekkel elejét vehetjük, hogy a későbbi vizsgálat során kelljen megakadnunk valami rejtett hiba miatt. Ez különösen érvényes a III. fázis járműves futásaira, mert azoknak nagyon komoly forgalmi és anyagi következményei lehetnek.
A 3. sárga halmaz jelzi, hogy az ETCS még egy új szakág, mindnyájan tanuljuk, ki-ki a maga szintjén. Néha nincs egyértelmű válasz, időnként közös szállító–MÁV workshop keretében igyekszünk megtalálni a megfelelő megoldást.
A részletes adatbázis-vizsgálat az előkövetelménye a második fázis megkezdésének. Laborkörnyezetben tesztelhetővé válnak az ETCS funkciók a vállalkozók által szállított tesztkörnyezetben. A tesztek során a funkcionális üzemi eseteket az üzemeltetési koncepció, illetve a Technológiai Központ által meghatározott technológiai lista szerint vizsgáljuk. A menetengedély (MovementAuthority) kiszámításának metódusa és szoftverfolyamata kerül leképezésre „fekete-doboz” vizsgálat során. Az RBC önmaga nem minősül biztosítóberendezésnek, hisz ezt a biztonsági szintet a hozzá kapcsolódó elektronikus, vagy illesztőszámítógépen keresztül kapcsolt Domino típusú biztosítóberendezés látja el. Azonban bizonyos szempontból mégis biztosítóberendezésként kell rá tekinteni, mert a nemzeti jelfeladó vonatbefolyásoló rendszerekkel ellentétben biztonságkritikus objektuminformációkból számítja a belső szoftver a menetengedélyt, illetve határozza meg a hosszokat, pozícióadatokat, sebességinformációkat. Mivel az RBC bizonyos szempontból biztosítóberendezésnek minősül, fontos az RBC-biztber interfész részletes vizsgálata is, melyet a helyszínen a vállalkozó végez el és biztosítja számunkra a szükséges tesztriportokat, ugyanakkor a Technológiai Központban mi elvégezzük ezen interfész telegramvizsgálatát, illetve az objektumazonosításokat a teljes vonalra. Szükséges esetben rendelkezésünkre áll a Thales bécsi laborja, ahol az Elektra-DAKO-RBC csatornák vizsgálata történik valós Elektra berendezés felhasználásával. Szükséges megvizsgálni, hogy minden egyes biztber objektum a megfelelő működést látja el, a 7-es váltó tényleg 7-es váltóként szerepel az érintett állomáson, ténylegesen balra/jobbra terel, vagy épp nincs végállása. Ugyanígy történik a főjelzők és foglaltsági szakaszok vizsgálata is, ahol a jelzőkön minden egyes aspektet megvizsgálunk (szabad, megállj jelzés, hívó/hívásfeloldó, érvénytelen jelzés, zavarjelzés). A foglaltsági szakasz esetében meghatározható, hogy a foglaltság vonat általi (foglaltsági sorrend), vagy valamely objektum zavara, hamis foglaltsága hozta létre. A funkcionális vizsgálathoz tartozik még az RBC kezelőfelület (MMI/HMI/HIS/ControlGuide) funkcionális és konformitás vizsgálata is. Ennek során fontos végignézni, hogy az egész vonalon minden állomási objektum a megfelelő helyen, a megfelelő elnevezéssel szerepel, a legördülő menük rendelkezésre állnak, az objektumokhoz tartozó elvárt funkciók rendelkezésre állnak. Minden szakaszon létrehozhatóak lassújelek, illetve felsővezetéki korlátozások. A vállalkozó által szállított hivatalos „RBC üzenetszövegek”, dokumentumban definiált kijelzési szövegek és szimbólumok rendelkezésre állnak és előidézhetőek a különböző forgalmi szituációk során.
A vizsgálatok harmadik fázisa a helyszíni tesztek, melyekkel párhuzamosan vagy azt megelőzően gyártói tesztek is zajlanak. A harmadik fázis során a LEU egységek vizsgálata történik, fix és transzparens balízok telepítésének vizsgálata, pozícióvizsgálatok. A balíz programozó tool-lal történnek a vizsgálatok, az üzemeltető csak „kofferesvizsgálatnak” nevezi. A „koffer” a helyszínen a balízra helyezendő mérőműszer: a jármű balízantennáját emulálja. Ez annyit tesz, hogy a programozó tool-lal leellenőrizzük, hogy a megfelelő balíznak helyes-e az azonosítója, megfelelő irányban olvassa-e ki a jármű, és a megfelelő telegramokat tartalmazza-e hexadecimális formában. A projektált adatok és a pályamenti elemek vizsgálata után kezdődnek a tesztfutások a már korábban ETCS fedélzeti berendezéssel felszerelt, levizsgáztatott tesztjárművekkel, melyekbe ideiglenesen tesztkulcsokat tölt a vállalkozó a rendelkezésre álló key-management rendszerével. A tesztkulcsokat mindenképp el kell távolítani a járműből, és deaktiválni kell az RBC központban a vizsgálatok lebonyolítása után. A martonvásári vonalon a járműves vizsgálatok Siemens Taurus, illetve Stadler Flirt típusú járművekkel történtek.
Magyarországon két fő pilot projekt vizsgálata zajlik 2012 óta több fázisban, a Siemens Budapest–Székesfehérvár (FEFE) projekt, mely magába foglalja a két nagy D70-es állomást, Kelenföldet és Ferencvárost is. Három darab RBC központ áll rendelkezésre Martonvásár, illetve Ferencváros/Kelenföld nagyállomásokon. Az adatbázis- és funkcionális vizsgálatokat mindhárom RBC központra egyenként el kell végezni. A mai napig a vállalkozó13 verziót szállított le. Hét verziót teljeskörűen levizsgált a Technológiai Központ, hisz a vizsgálatok során olyan hibákat tártunk fel, melyek a rendszerek újrakonfigurálását és újra projektálását várták el. A FEFE projekt a KLSV (Kelenföld kizár – Székesfehérvár kizár) projektben már elindult, amikor a vállalkozó egy martonvásári RBC-t szállított le biztosítóberendezési projekt keretein belül, az első három RBC verziót ekkor vizsgálta a Technológiai Központ. Majd egy közbenső, előteljesített projekt „Tárnok–Gárdony tesztszakasz” keretében újabb két martonvásári RBC verziót vizsgáltunk le. A teljes FEFE projekt három RBC központtal 2015 második felében került átadásra, vizsgálatra. A 9. szoftververzió után stabilizálódott a rendszer működése, és a projektált adatok vizsgálata során is egyre kevesebb hiba merült fel, így nem volt szükség újabb teljes körű vizsgálatokra, csupán delta/különbözeti vizsgálatokra. A harmadik fázisú jelentés átadása a közeljövőben megtörténik, és egy rework után sor kerülhet az üzembe helyezésre is.
A második pilot ETCS rendszert a Thales szállítja a Bajánsenye–Boba projekt keretében 1 RBC központtal. A vizsgálatok során, 2015 első felében megtörtént az adatbázisok vizsgálata, illetve az előzetesen bemutatott tesztkörnyezeten Bécsben a biztosítóberendezési interfész vizsgálata valós Elektra rendszeren. Mivel a vállalkozó a rendszert egy projekt keretén belül szállította, nem volt szükséges több verziót levizsgálni a különböző változások után. A vállalkozó csak a fő baseline és projektálás változások után jelentette vizsgálatra készre a rendszert. A funkcionális vizsgálatokat 2017 negyedik negyedévében ellenőrzi le újra a Technológiai Központ az első fázisú jelentés átadása után. A harmadik fázisú helyszíni tesztek jövő év januárjától várhatóak. Az üzembe helyezésre szintén a harmadik fázis sikeres és a rendszer biztonságkritikus hibáktól mentes állapota után kerülhet sor.
Az 5. és 6. számú ábrákon egy rövid, de kellő részletességű blokkvázlat látható a vállalkozók ETCS teszt-környezeteiről.
5. ábra – Siemens tesztberendezés
6. ábra –Thales tesztberendezés
A Siemens berendezésben a TuS (Test und Simulation) alrendszer felelős a teljes rendszer működéséért, a funkciók szinkronizációjáért, a különböző programok eseményvezérelt működéséért és az eltérő protokollok közötti kommunikációjáért. A FALKO részegység felel a forgalomspecifikus üzemi szcenáriók futtatásáért, melyben út-idő-távolság diagram is számítható kapacitástervezés során. Az RBC ControlGuide szoftver az OC500-as szoftvercsomagból fejlődött ki, számos ország vasúti, illetve metróprojektjeiben használták mint kezelőfelületet. Ez a kezelőfelület jelenik meg a KÖFI központokban, forgalmi vonalirányítók asztala előtt, ahol nyomon30 vonat ETCS működését, az érvényes menetengedélyeket, aktivált lassúmeneteket és pályakorlátozásokat. A GeSim szoftvermodul látja el az elektronikus biztosítóberendezés emulációt, mely során a helyszínre is telepített valós biztber szoftver van betöltve egy megfelelő és kompatibilis szoftverkörnyezetbe, hogy a szükséges biztber funkciók rendelkezésre álljanak az ETCS vizsgálatok során. A Simis IS szoftverlogika és SIL4-es biztonsági szint rendelkezésünkre áll kétcsatornás kialakításban a laboratóriumi tesztek alatt. A Koppelrechner a Domino típusú biztosítóberendezések illesztőszámítógépe, ahol a különböző objektumállapotokat ismétlőjelfogókon keresztül nyerjük ki, és továbbítjuk az RBC felé. Az RBC ezek után úgy látja a D70 típusú berendezést bizonyos technikai szempontból, mintha az egy Simis IS típusú elektronikus berendezés lenne. Ez a rendszer csak a helyszínen vizsgálható. A laborban rendelkezésre áll egy Koppelrechner szimulátor, melyen emulált RBC kommunikáció tesztelhető a Kelenföld és Ferencváros RBC központok felé. A biztosítóberendezési objektumállapotok megfelelő formátumban kerülnek továbbításra az RBC központok felé A tesztrendszer tartalmaz egy hardveres OBU fedélzeti berendezést, EVC fedélzeti számítógéppel, balízantennával, illetve JRU hatósági adatrögzítővel. Ez a fedélzeti berendezés egyenértékű a Stadler-Flirt motorvonatokon üzemelő ETCS berendezéssel. Megtalálható egy Alcatel Lucent típusú routeren keresztül az optikai összeköttetés valós GSM-R hálózat felé, melynek MSC központja a Horog utcában található, illetve a Technológiai Központ távközlős helyiségeiben. Rendelkezésünkre áll két SIM kártya is tesztkulcsokkal, így az ETCS funkcionális tesztjeinket valós GSM-R hálózaton keresztül is megvalósítjuk. Kiegészítésként hadd említsem meg, hogy a Bajánsenye–Boba projekt integrációs tesztjének egy részét a Technológiai Központban elhelyezett valós OBU-val és tesztkulcsokkal is elvégeztük valós GSM-R hálózaton keresztül. A tesztberendezés tartalmaz még valós Messma DMI modult is, mely egyenértékű a mozdonyvezetők által is használt fedélzeti ETCS irányítópulttal. Az ismertetett tesztlaborról a 7. ábrán láthatunk fotót.
- ábra – Siemens tesztlabor a Technológiai Központban
A Thales tesztberendezésben a fő elemvezérlő és processzvezérlő feladatokat a TVS (Test and Verification System) látja el. A szoftverfolyamatok szinkronizálásáért felelős, illetve az üzemi szcenáriók futtatását is ezeken a gépeken végezzük. Tartalmaz még szcenárió-, illetve topológiaszerkesztő modulokat is, melyekben megvalósítható akár új balízok projektálása, illetve az üzenetek kiértékelése. A szcenáriót analizáló szoftvercsomagban egy üzemi eset vizsgálata során megtalálhatóak egyben a jármű üzenetei (külön JRU megléte nem szükséges), illetve az RBC központ üzenetei, a mozdonyvezető kezelései, illetve a meghaladott balízok azonosítói a jármű által kiolvasott csomagokkal. A BoBa projektben a valós helyszínen AKF kezelőfelületeket telepített a Thales a biztosítóberendezésekhez, melyek a tesztberendezésben nem állnak rendelkezésre, helyettük EBO2 típusú elektronikus kezelőfelületet használ a rendszer. Ezért szükséges egy element-mapping vizsgálat az AKF kezelőfelület adatbázisából kinyert objektumok azonosítói, illetve a projektált funkciók felhasználásával. Fontos, hogy minden objektum a megfelelő X.25 telegramokat kommunikálja az RBC központ felé, a DAKO status readeren keresztül. Ez egyben egy naplózó rendszer is, ahol a különböző biztber objektumok állapotait RBC objektum állapotokhoz rendeli a rendszer. Az RBC kezelőfelületet HIS-ként nevezi a vállalkozó, a forgalmi vonalirányító irodájában ténylegesen ez a munkaállomás áll rendelkezésre az ETCS vonatok lassújelek és pályakorlátozások létrehozására. A Thales MOM parkban telepített laborjában virtuális Elektra berendezésekkel vizsgálhatóak az ETCS funkciók, míg a bécsi laborban valós Elektra biztosítóberendezések állnak rendelkezésre, melybe a 4 kezelési körzet bármelyike betölthető. A DAKO status readeren dinamikusan nyomon követhetőek a biztosítóberendezési objektumok állapotváltozásai, a telegramfolyamok a különböző csatornákon, illetve zavartatásvizsgálat is elvégezhető, mely érinti az ETCS menetengedély-számítási folyamatokat is. Az OMS szerver rögzíti ténylegesen az RBC központ csatornáin megjelenő üzenetfolyamokat, ez szükséges mind a laboratóriumi, mind a helyszíni vizsgálatokhoz. Egy külön monitoron a jelfogóhelyiségben látható pl. az összes főjelző jelzési képének változása vagy az optikák zavarállapota. Kiolvasható még az RBC és a jármű fedélzeti berendezése közötti kommunikáció valós adatfolyamként, hexadecimálisan kódolt, illetve kiértékelhető formában is. Az ismertetett tesztlaborról a 8. ábrán láthatunk fotót.
8. ábra –Thales tesztlabor a MOM Parkban
A tesztberendezéseken végzett ETCS v
izsgálatok lehetőséget biztosítanak a biztonságkritikus üzemi esetek kipróbálására, egyben költséghatékony megoldás mind az üzemeltető, mind a vállalkozó részére. A funkcionális tesztek 70-80 százaléka elvégezhető laboratóriumi környezetben a forgalom tényleges bevonása és zavartatása nélkül. Ugyanakkor a rendelkezésre álló vizsgálati időkeretet hatékonyan ki lehet használni, hiszen a karbantartási idők is lényegesen alacsonyabbak, mintha a vizsgálatokat valós rendszeren végeznénk. Az RBC központok Magyarország-specifikus funkciói dióhéjban: tolatás, szintátmenet nemzeti STM/EVM szintről ETCS Level1/2 szintre, RBC által fedezett állomási sorompók, balízzal fedezett vonali sorompók, állomási indítású vonali sorompók RBC és balíz által fedezve, permisszív közlekedés, hívójelzés/hívásfeloldó, ideiglenes sebességkorlátozások, felsővezetéki korlátozások, részben felhasznált vágányút sérülés, RBC-k közti átmenet.
A 9. és 10. ábrákon egy Siemens berendezésen vizsgált ETCS L2 menetengedély látható több alrendszer szempontjából.
9. ábra – FALKO menetvezérlő
10. ábra –GeSim elektronikus biztosítóberendezés emuláció
A FALKO modulon, mely csak a tesztberendezésen áll rendelkezésre, egy vonat látható a martonvásári RBC körzetben, Tárnok állomáson. A vonat FullSupervision (FS), teljes felügyeleti üzemmódban közelíti a bejárati jelzőt. A 10. ábrán a beállított vágányút GeSimSimis IS biztosítóberendezési emulációja látható lezárt érintett és oldalvédelmi váltókkal. Az RBC a menetengedély számítása során a váltóállapotokat is figyelembe veszi. A GeSim segítségével lehetőségünk van az összes olyan biztonságkritikus biztber eseményt előállítani, amely a valóságban előfordulhat, így megvizsgálhatjuk a reakciókat, következményeket. Az ábrán látható a GeSim ECC szint is, mely a központi Simis számítógépeket képezi le, megtalálhatóak a valós rendszer alapján az összes elemvezérlő kártya (váltók, jelzők, térközi objektumok). Ez a komponens beolvassa a biztosítóberendezési állapotokat, és közvetlenül az RBC-re kapcsolódik.
A 11. ábrán Ferencváros állomás látható, ahol a vonat érvényes FS menetengedéllyel közlekedik. Az AXON-6M gyártmányú D70 biztosítóberendezés szimulátor lehetővé teszi a Domino típusú állomások tesztelését ETCS környezetben. Lehetőségünk van szintén biztonságkritikus objektumállapotok során tesztelni az ETCS rendszer működését a Koppelrechner által kinyert információk alapján.
- ábra – AXON-6M Domino70 szimulátor (FC)
A 12. ábrána TrackPresentation (TuS) alrendszer látható, ahol egy RBC-k közötti határátmenetet valósítottunk meg Kelenföld és Martonvásár körzetek között. A vonat behalad a fogadó RBC körzetébe érvényes FS menetengedéllyel, és nyomon tudjuk követni a szükséges sebességváltozásokat, melyek a pályára érvényesek. A fogadó RBC úgynevezett RRI (RouteRelatedInformations) üzenetekkel továbbítja a szükséges menetengedély-információkat az átadó RBC-nek, hogy az „RBC átmenet” működés során előreláthatóan biztonságosan és transzparens módon történjenek a folyamatok.
- ábra –TrackPresentation– RBC handover
A 13. ábrán a mozdonyvezető ETCS DMI kijelzője látható. A hívójelzés kivezérlése után OS (On-sight) üzemmódba kerül és 15 km/h-val haladhat tovább a céljelző felé. A hívójelzés váltózavar miatt került kivezérlésre. A vonat közelít a kijárati jelző felé, majd miután 400m-re megközelítette a szabad állású kijárati jelzőt, úgynevezett TAF (TrackAhead Free) eljárás során FS menetengedélyhez jut a pályára maximálisan megengedett sebességgel. A TAF felhívást a mozdonyvezetőnek nyugtáznia kell, csak utána lép érvénybe. Itt kettős nyugtázást követel meg az ETCS működés, hogy a mozdonyvezető megbizonyosodjon róla: „Az előttes pályarész szabad”.
13. ábra – Látra közlekedés, TAF eljárás
Az RBC kezelőfelületeken a vonatszimbólumok láthatóak a hozzájuk rendelt érvényes menetengedélyekkel. Ezeket a kezelőfelület zöld színnel jelölni. A sárga színnel jelölt téglalapok lassújeleket jelölnek, melyeket az operátor egyenként felvesz hektométertőlhektométerig, illetve aktiválnia és nyugtáznia is kell, hogy érvényesüljenek. A 14. és 15. ábrákon látható a martonvásári RBC kezelőfelületen létrehozott és aktivált lassúmenet-táblázat. Fontos, hogy csak új menetengedélyben érvényesülnek a lassújelek. A későbbiek során rendelkezésre áll majd egy tool, mely képes lesz a FOR rendszerből kinyert, Excel formátumú lassújeltáblázatokat importálni az RBC kezelőfelületbe.
- ábra – RBC kezelőfelület, lassújeltáblázat
A 15. ábrán látható topológia a lassújeleket sárga színnel jelöli a kezelőfelületen a maximálisan megengedett sebesség megjelölésével. A vonatszám és az ETCS üzemmód fekete-fehér, míg a vonatra érvényes menetengedély zöld színnel látható. Az ábra alján lévő folyamat bemutatja egy lassújel létrehozását. Ki kell tölteni a szakaszra vonatkozó hektométer adatokat,a lassújel irányát, a maximálisan megengedett sebességet és egy rövid leírást. Ezután a jobb alsó sarokban lévő checklist-en jóvá kell hagyni a lassújelben definiált értékeket. Ezt a biztonsági funkciót a lassújel aktiválásánál újra véghez kell vinni.
- ábra – RBC kezelőfelület, lassújel létrehozása
Az üzemi forgatókönyvek vizsgálata után lehetőségünk van egy külön számítógépen a kiolvasott JRU adatok elemzésére. (Ez azt modellezi, mintha próbafutások után a jármű fedélzeti adatrögzítőjét elemeznénk.) A dinamikus sebességprofil, küldött és fogadott RBC üzenetek (a részletes csomagtartalmakkal együtt SRS szerint) az RBC és jármű között lebonyolított üzenetváltások egytőlegyig megtekinthetőek a toolban. Fontos még figyelembe venni a kiolvasott balízadatokat, mozdonyvezető általi kezeléseket és a legkorlátozóbb sebességprofilt stb.
A 16. és 17. ábrákon Thales rendszeren vizsgált ETCS funkciók láthatóak. A Virtuális Elektra EBO2 kezelőfelületén egy vonatszimbólum látható, mely Zalaszentiván állomáson áll a VI. számú fogadóvágányon. A kijárati jelző szabad jelzési képet mutat. A vonat a jelző meghaladása után érvényes FullSupervision menetengedélyhez jut.
16. ábra – Virtuális EBO2 kezelőfelület
17. ábra – Virtuális Elektra biztosítóberendezés szimuláció
A fő különbség a Siemens és Thales tesztberendezések között, hogy a Thales berendezés valós EBO2 kezelőfelületet használ a forgalomirányításra, míg a Siemens berendezésen ez a FALKO funkciók által automatikusan ÖJÜ jelleggel működik.
A Virtuális Elektra berendezésnek van egy elemvezérlő része, az EPS, ahol lehetőség nyílik a különböző biztosítóberendezési objektumok „bitmanipulációjára”, mely során az objektum által felvett és RBC felé közvetített állapotok változtathatóak, például egy főjelzőmegállj, szabad jelzése, vagy akár egy hívójelzés, vagy érvénytelen jelzési kép. Mivel az ETCS rendszerek főként a főjelzők jelzési képei alapján biztosítják a vonat számára a menetengedélyt, a főjelzők bitmanipulációja, vagy akár egy váltó-állapotváltozás módosítja a menetengedély jellegét. Egy zavarállapot végkifejlete ebből adódóan lehet UeS (Unconditionalemergency Stop), feltétel nélküli vészmegállítás vagy CeS (Conditionalemergency Stop), feltételes vészmegállítás, attól függően, hogy a jármű hol helyezkedik el a főjelzőhöz képest.
18. ábra – Virtuális Elektra elemvezérlő
Ideiglenes sebességkorlátozás is létrehozható állomási sorompó „bitmanipulációjával”, ilyenkor az RBC által fedezett sorompó zavarállapotát értékeli ki az ETCS rendszer, és 15 km/h (zavar) vagy 120 km/h (hiba) sebességkorlátozást állít be a sorompó pozíciójára. A számított menetengedély erre a pozícióra egy SSP-vel lesz érvényes. Amennyiben a sorompó zavarállapota megszűnik, a sebességprofilt deaktiválja az RBC, és újra a maximális sebesség lép érvénybe. A sorompók zavarállapotát úgynevezett UnivScannerek segítségével is elő lehet állítani, előre definiált ETCS telegramként. A 18. és 19. ábrák a „bitmanipulációk” lehetőségeit mutatják be.
- ábra – Állomási sorompóbitmanipulációja
A 20. ábrán az RBC kezelőfelülete látható (HIS). Ezt a számítógépes munkahelyet a forgalomirányítók részére telepítik majd.
- ábra – RBC kezelőfelület, HIS
Az ETCS kezelőfelület kicsit másként alakul, mint a másik vállalkozónál. A különböző állomások különböző ablakokban jeleníthetőek meg a jobb áttekinthetőség érdekében. Ezzel többmonitoros munkaállomás is könnyen létrehozható.
A Thales tesztberendezésben rendelkezésre áll egy járműhöz két DMI ablak is. Az egyik megjelenítési funkciót tölt be, mely nagyon jó közelítéssel hasonlít a valós ETCS fedélzeteken lévő DMI-hoz. A másik adminisztrátori jogosultságokkal rendelkezik, és a legelemibb OBU funkciókat is lehet rajta módosítani, ezáltal bármilyen járműtípus szimulációja rendelkezésre áll a tesztkörnyezetben. Az ETCS parancsok manuálisan is megadhatóak az adminisztrátori felületen (pl. Start of Mission, Tolatási engedély, End of Mission, Nyugtázások, Vonatadatok módosítása, TAF stb.).
21. ábra – DMI fedélzeti megjelenítő és kezelőfelület
A Technológiai Központban végzett projektálási és funkcionális ETCS, RBC vizsgálatok lehetővé teszik a különböző forgalmi szituációk reprodukálását a forgalom tényleges zavartatása nélkül, üzemi költségek jelentős mértékű megtakarításával. Biztonságkritikus üzemi esetek (jelzőzavar, váltóvégállás elvesztése, részben felhasznált vágányút sérülése, sorompózavarok) is vizsgálhatóak a valós/emulált biztosítóberendezések működésébe való beavatkozással, illetve a jármű beállításai is rendelkezésre állnak. A komplex hardver és szoftver komponensek rendelkezésre állására a gyártók vállalnak garanciát, a verziók mindig naprakészek az aktuális baseline, illetve projektálási adatok és országspecifikus funkciók betöltésével. Az üzembe helyezések után is rendelkezésre állnak a laboratóriumok, hogy a menet közben felmerülő hiányosságokat, hibákat vagy új funkciókat vizsgálni lehessen, vagy a nem egyértelmű fogalmi szituációk reprodukálásának lehetőségével. A Technológiai Központban rendelkezésre áll majd a jövőben mind a Siemens, mind a Thales oldaláról ETCS és RBC diagnosztikai munkaállomás, melyek segítségével betekintést nyerhetünk az alrendszerek rendeltetésszerű működésébe.
Ertl Tamás – Horváth Gábor
Ez a cikk a Vasúti VezetékVilág 2017/4-es számában jelent meg.
