S Z A K D O L G O Z AT
SIMONYI GYULA 2012
VA S Ú T I FORGALOMIRÁNYÍTÓ RENDSZER
SIMONYI GYULA
SZÁMALK Szakközépiskola Szoftverfejlesztő
Konzulens: Sallai András
Környezet: Java Virtual Machine
N Y I L AT K O Z AT
Alulírott Simonyi Gyula (anyja neve: Antal Ágota, szem. ig. száma: 538472KA) kijelentem, hogy a „Vasúti forgalomirányító rendszer” című szakdolgozat önálló szellemi termék, még nem volt publikálva sehol, és átadom a SZÁMALK Szakközépiskola számára.
Tartalomjegyzék Tartalomjegyzék ............................................................................................................... 5 Bevezetés .......................................................................................................................... 6 A feladat specifikációja .................................................................................................... 7 Az adatbázis modellje....................................................................................................... 9 A fejlesztés eszközei..................................................................................................... 9 Pálya és váltók .............................................................................................................. 9 Jelzők .......................................................................................................................... 10 Vonatok....................................................................................................................... 11 Útválasztás .................................................................................................................. 12 Menetrend ................................................................................................................... 12 A logikai szint modellje.................................................................................................. 14 A fejlesztés eszközei................................................................................................... 14 A használathoz szükséges........................................................................................... 14 Az alkalmazás kerete .................................................................................................. 14 Állomás megnyitása.................................................................................................... 14 A forgalmat megvalósító háttérosztályok ................................................................... 15 Jelzők átállítása ........................................................................................................... 16 Váltók kezelése ........................................................................................................... 17 Vágányutak beállítása ................................................................................................. 17 A felhasználói felület modellje ....................................................................................... 19 Tesztelés.......................................................................................................................... 23 Állomás megnyitása.................................................................................................... 23 Fejlesztési javaslatok ...................................................................................................... 26 Az adatbázis bővítési lehetőségei ............................................................................... 26 A logikai szint bővítési lehetőségei ............................................................................ 27 A felhasználói felület bővítési lehetőségei ................................................................. 28 Felhasznált irodalom....................................................................................................... 29
Bevezetés Napjaink mindennapi eseménye a vasúti közlekedés, legyen az városi, városok közti helyi érdekű, országos vagy nemzetközi viszonylat. Szoftverfejlesztőként hasznosnak tartom, hogy a kötött pályás forgalom bonyolításának alapvető műveleteivel megismertessem e szoftver felhasználóját. Témám megválasztásában nem vesz részt piaci érdekeltség, tekintettel arra, hogy a forgalomirányítást ténylegesen megvalósító eszközök nem állnak rendelkezésemre szoftverfejlesztés céljából. Emiatt munkámat elsősorban oktatási, ismeretterjesztő céllal dogozom ki, a kötött pályás közlekedés iránt érdeklődők számára. Másodsorban személyes jövőképem motivál, melyben a vasúti járművezetés kiemelt helyet foglal el. Koncepcióm alapjául a Magyar Államvasutak Zrt. 2008. április 6-án hatályon kívül helyezett jelzési utasítása szolgál, melynek segítségével szemléltetem a járművezető által az út menti jelzőeszközökről fogadható utasításokat. Helyesebbnek tartottam ehhez igazodni, mint a jelenleg hatályos változathoz, mert dolgozatomba egyes olyan komponenseket emeltem át (elsősorban a főjelzők jelzéseit), melyek e régi verzió mentén logikusabbak, könnyebben érthetők. Szoftverem lehetőséget ad a felhasználónak, hogy egy meghatározott vasútállomás sematikus vágányrajzát látva megfigyelje az előre adott menetrend szerint érkező, induló és áthaladó, szintén jelképes ábrázolású vonatokat, valamint a váltók és fényjelző készülékek állításával befolyásolja azok mozgását, útirányát. Annak érdekében, hogy a vasúti közlekedés iránt érdeklődők minél szélesebb köre próbálhassa ki a kötött pályás forgalomirányítás alapjait, fejlesztőkörnyezetemnek a Java Virtuális Gépet választottam, melyen keresztül a Vasúti Forgalomirányító Rendszert az otthoni felhasználásra leggyakrabban igénybe vett operációs rendszerek egyaránt képesek működtetni.
A feladat specifikációja A Vasúti Forgalomirányító Rendszer egy tetszőleges virtuális vasútállomás vonat- és tolatási mozgásainak irányítására alkalmas. A felhasználói kezelőfelület egy állomásmegfigyelő kamera látképét ábrázoló virtuális monitorból és alapvető forgalomirányító műveleteket kiváltó vezérlőelemekből áll. A szoftver egy MySQL objektumrelációs adatbázisból az operatív memória Java objektumos láncolt adatszerkezetébe tölti a felhasználó által név szerint megadott állomás vágányrajzát, és megjeleníti a virtuális monitoron. A vágányszakaszok hossza tetszőleges, de ha az adatbázisban szereplő hosszúságadatok a vágánykapcsolatokkal összevetve értelmetlenek, akkor az állomás rajza a képernyőn hibásan, értékelhetetlen formában fog megjelenni. Következő lépésként az alkalmazás az adatbázisban rögzített naponta ismétlődő menetrend alapján megkeresi az állomást a nap hátralevő részében érintő vonatok érkezési és indulási idejét, majd az induló vonatokat peron mellett, az érkező vonatokat az állomás valamely bejárati szakaszán helyezi el mind a memóriában, mind a képernyőn. A vonatokat önálló döntéssel bíró járművezetővel ellátott szerelvényként tekintem, melyek szabad jelzésnél adott menesztésre kérdés nélkül meghaladják a vonatmozgást engedélyező jelzőkészülékeket. Szabad tolatásjelzés esetén, ha álló helyzetben vannak, megvárják a tolatási engedélyt, majd azonnal meghaladják a szabad jelzést, és csak az útba eső következő „tilos a tolatás” vagy „megállj” jelzésnél állnak meg. Továbbhaladást tiltó jelzés észlelésekor a vonatok eleje mindig közvetlenül a továbbhaladást tiltó jelző mellett áll meg. Vonatmozgás esetén a meghaladott szabad jelzést adó készülék automatikusan „megállj” jelzésre vált. Nem adható ki vonatmozgást engedélyező jelzés egy jelzőre akkor, ha vele szemben elindulva a beállított vágányút következő vágányszakaszán egy ellentétes irányú jelző szabad jelzést ad. A felhasználói felületről szabályozható minden egyes jelzőkészülék, melyek mindegyike egy-egy vágányszakasz hátsó vagy első jelzője. Hátsó iránynak számítandó a monitor bal széle, első iránynak a monitor jobb széle. A jelzőkön megjelenő jelzésképeknek sebességre vonatkozó utasítása is van, de a vonatok sebességét a szoftver e verziója nem szemlélteti, hanem a legközelebbi „megállj” jelzés vágányszakaszok számában adott távolsága dönti el, milyen szintű szabad jelzés
vezérelhető az adott jelzőre. Az alkalmazás tájékoztatja a felhasználót arról az esetről, ha az aktuális vágányszakasz adott végén nincs fényjelző készülék. Állítható továbbá minden váltó, annak a vágányszakasznak és végpontjának megadásával, amelyre érkezve a bejárandó út folytatása eldöntendő. A képernyőn balról jobbra haladva egyenes iránynak számít a váltó monitor szerinti felső ága, és kitérő iránynak az alsó ága. Jobbról balra haladva fordítva. A váltó nem állítható akkor, ha az elágazást érintő bármelyik vágányszakaszon szabad jelzés látható az elágazás irányába, mert az veszélyezteti a biztonságos közlekedést. Ha egy adott vágányszakasz adott végpontján nincs váltó, a szoftver szintén figyelmeztetést ad. A szoftver a felhasználó kérésére visszajelzést ad az egyes jelzők és váltók állapotáról, illetve lehetőséget ad az összes tolatás, az összes vonatmozgás, vagy az összes közlekedés megtiltására az állomás területén, a vonatkozó jelzőkészülékek „megállj” jelzésbe való kapcsolásával. Két vágányszakasz között automatikusan is beállítható egy útvonal. Ilyenkor a felhasználónak nem kell kézzel állítania az útba eső váltókat, hanem a szoftver az adatbázis útvonalválasztó táblájából megkeresi a legrövidebb összekötő útvonalat (egyes állomásokhoz útválasztási adatok nem tartoznak, ilyenkor az útvonalat kézzel kell beállítani, az útba eső váltók megfelelő irányításával). Ha az út azért nem állítható be automatikusan, mert a két vágányszakasz közötti összes bejárható utat valamely más vonat lefoglalja, arról a szoftver jelentést ad. Jelentést ad arról is, ha egy konkrét váltót vagy jelzőt biztonsági okokból, az adott pillanatban nem lehet átállítani. A felhasználó tetszőleges időpontban bezárhatja az állomást; ekkor az összes jelző továbbhaladást tiltó állapotba kerül, azután a memóriában megszűnik az aktuális állomást reprezentáló adatszerkezet. Bármikor megnyitható egy új állomás: ha ilyenkor egy korábbi még nyitva van, az először automatikusan bezárul. Hibakeresés érdekében tesztelhető az adatbázissal való kapcsolat aktivitása.
Az adatbázis modellje A Vasúti forgalomirányító rendszer adatbázisának megalkotásakor nem törekedtem arra, hogy az alkalmazás logikai szintje annak minden lehetőségét rögtön kihasználja. Igyekeztem egyes fejlesztési terveknek megfelelő adatszerkezeti igényeket előre megvalósítani. A fejlesztés eszközei Az adatbázis kezdeti verziója SQL script formájában készült, később MySQL Workbench 5.2 használatával módosítottam az adatszerkezetet. Az adatbázis megosztásához MySQL Server 5.5-öt veszek igénybe. Pálya és váltók Mindenekelőtt ismernünk kell egy tetszőleges állomás vágányzatának szerkezetét, hogy kialakíthassuk a tárolásához szükséges adatmodellt. Az állomást első lépésként vágányszakaszokra osztjuk, mely a Section (Szakasz) tábla elsődleges kulcsa lesz. Vágányszakasznak tekintjük minden olyan bejárható szakaszát a vágányzatnak, melynek külön célforgalma van, azaz ahova külön-külön terelhetünk vonatokat, forgalomirányító szándéktól függően. Egy vágányszakasz mindkét vége csatlakozhat egy vagy két másik vágányszakaszhoz. Ha egy szakaszhoz csatlakozik, akkor úgy tekintjük, mint a vágányszakasz meghosszabbítását, ha pedig kettőhöz, akkor úgy értelmezzük, hogy a vágányszakasz adott végén váltószerkezet van elhelyezve, amely állapotától függően a folytatást képező egyik vagy másik vágányszakaszra tereli a ráhaladó vonatot. Ha tehát elhagyunk egy vágányszakaszt, legfeljebb négy másik vágányszakasz közül választhatjuk ki utunk folytatását. A specifikáció szóhasználatával ez a bal-hátsó, jobb-hátsó, jobb-első illetve bal-első folytatása az aktuális vágányszakasznak, ez a Section tábla egy-egy leíró mezője lesz, melyek egyúttal hivatkoznak egy-egy, a táblában korábban felvett vágányszakaszra. Az alkalmazás jelen verziójában kikötjük, hogy egy vágányszakaszon egy időben csak egy vonat tartózkodhat, és egy vágányszakasz minimális hossza az összeállítható maximális hosszúságú vonattal egyezik meg. E kereten belül megadható a vágányszakaszok hossza, egy egész szám típusú leíró mező formájában. Megadható továbbá minden szakaszhoz, hogy tartozik-e hozzá peron, és melyik oldalon. A peron összes esetének tárolására elég egy mező, a következő lehetőségekkel: nincs peron, bal
peron, jobb peron, kétoldali peron. A szoftver e verziója logikai szinten csak két eset között tesz különbséget: van peron, vagy nincs peron. Megadható, hogy az adott szakaszhoz
tartozik-e
elektromos
munkavezeték
(felsővezeték),
melynek
igénybevételével az elektromos vontatófejek (villanymozdonyok és elektromos motorvonatok) közlekedni tudnak. Tudnunk kell azt is egy vágányszakaszról, hogy logikailag csatlakozik-e a globális vasúti hálózathoz, tehát hogy az állomás kijárati szakaszai közé sorolható-e. Mivel a MySQL adatbázismotor nem támogatja a logikai adattípust, ezért egy kétesetes, egy karakter hosszú mezőben tárolom ezt az információt. Végül meg kell jelölnünk, hogy melyik jelzőkészüléket szeretnénk a vágányszakasz első, illetve hátsó végére helyezni, ha szükséges egyáltalán. Egy idegen kulcsot helyezünk el, melyen keresztül a Signals (Jelzők) tábla egy sorát választjuk ki. Miután kialakítottuk egy állomás szerkezetét, a Station (Állomás) táblában új állomást veszünk fel a nevével és kezdőszakaszának megjelölésével, ahonnan a felépítés indul majd – utóbbit természetesen az előbb feltöltött Section tábla sorai közül választjuk. Egy állomásnak lehetnek egyéb törzsadatokkal leírható tulajdonságai: ezeket később a fejlesztési tervek között fogom ismertetni. Jelzők Említettem, hogy minden vágányszakasz kezdő- és végpontjához tartozhat egy-egy forgalmat szabályzó jelzőkészülék. Az alkalmazás e verziójában kizárólag fényjelzőket használok, ehhez igazítottam az adatszintű megvalósítást is. A jelzőket aszerint, hogy milyen üzeneteket szeretnék velük továbbítani, típusokra osztjuk. Egy-egy típushoz egyértelműen tartozik a létező üzeneteknek egy halmaza. Először tehát készíteni kell táblát az üzenetek számára (Message), egyszerű elsődleges kulccsal. A legtöbb üzenethez a MÁV jelzési utasítása pontos sebességkorlátozást társít, ezért célszerű egyegy leíró mezőben felvenni, hogy a jelző mellett, mely az adott üzenetet továbbítja, milyen sebességgel szabad elhaladni. Mivel gyakori az olyan típusú jelző, mellyel a következőre jelző állapotára (is) adhatunk információt, mindjárt két olyan mezőt veszek fel, mely egész számú sebességértéket tartalmaz km/h-ban értve. Ha egy ilyen mezőt nem töltök ki, az annyit jelent, hogy az adott üzenet nem ad semmilyen utasítást a sebességre. Célszerű minden üzenethez a szöveges megfogalmazását is eltárolni, hogy a felhasználó hamar felfogja a jelentését, amikor ellenőrzi egy jelző állapotát.
Lássuk, hogyan épül fel egy általános fényjelző készülék. Egyfogalmú jelzőhöz eleve fölösleges elektronikát bevezetni, ezért feltételezzük, hogy egy fényjelzőnek legalább két állapota van. Ezért új táblát nyitunk a jelzők típusai számára, ahol minden típusnak minden adható üzenetéhez megadjuk a jelzés fizikai módját. A tábla neve Uses („Használ”). Értelemszerűen elsődleges kulcsként a jelző típusa, és az adott üzenet együtt szolgál. Mivel fényjelzőkről van szó, egy üzenet egy-egy lámpafej kigyújtását, kioltását, esetleg lassú vagy gyors villogtatását jelenti. Ehhez tudnunk kell, hogy az egyes típusú fényjelzők hány lámpafejjel rendelkeznek, és ezek milyen színűek, illetve milyen alakúak. Erre rendszeresítjük a Lamps (Lámpák) táblát, ahol a jelző típusa az elhelyezkedés fentről lefelé vett sorszámával együtt alkotja az elsődleges kulcsot, mellette pedig egy-egy leíró mező a szín és az alak. Most már megadhatjuk a Uses táblában, hogy például a biztosított főjelző hívójelzéshez használja egyrészt a hozzá tartozó harmadik lámpafejet (ami a Lamps tábla alapján vörös), folyamatos világítással, másrészt az ötödik lámpafejet (ami a Lamps tábla szerint fehér), lassú villogással. Ez természetesen két sor a Uses táblában. Ha olyan üzenetet akarunk rögzíteni, amelyhez egyik lámpafejnek sem kell világítania, akkor elég felvenni egy lámpafejhez, hogy nem világít, hiszen ezt az állapot máskülönben nem tároljuk el egyikről sem. A SignalType tábla információt szolgáltat egy adott típusú jelző szabványos állásáról, melyet az állomás megnyitásakor automatikusan felvesz. Egy vágányszakasz mindig a Signals táblában található konkrét jelző(k)re hivatkozik, melynek típusa leíróként szerepel. Vonatok A fogalomtárnak megfelelően egy vonat összeállításhoz szükségünk van a szerelvényt alkotó kocsikra, illetve vonatszemélyzetre, melyet az adatbázisban egy fővel reprezentálok, aki a mindenkori járművezető. Bár az alkalmazás e verziójában nem kezelek a vezető személyét érintő műveleteket, az adatbázis már biztosítja ehhez a lehetőséget a Driver (Vezető) tábla formájában. Ahhoz, hogy egy vonathoz társíthassuk a vezetőjét, szükségünk van egy törzstáblára (Train) a vonatok számára. Összeállításhoz pedig a kocsik tábláját (Car) vesszük igénybe, melyben rögzítenünk kell az elemi gördülő állományok hosszát, és az eszmei vonat számát, amelybe az adott kocsit soroltuk. Ha nem soroltuk vonatba az adott kocsit (járműtelepen vesztegel), akkor ezt a mezőt üresen hagyjuk. Minden kocsihoz tartozik továbbá egy gyártási típus, ahhoz
pedig új táblában (CarType) a kocsi hossza, funkciója, osztálya, használt üzemanyaga, és hogy van-e rajta vezetőállás. Az üzemanyag lehet elektromosság, gázolaj, gőz vagy semmi (legutóbbi esetben nem töltöm ki a mezőt). Erre szükségünk lesz, ha el akarjuk dönteni, hogy egy adott vágányszakaszra, melyhez nem tartozik felsővezeték, szabad-e terelni egy vonatot. A kocsik hosszából később könnyen meghatározhatjuk a vonat hosszát, amivel gyakran kell számolni akkor, ha megengedünk több vágányszakaszt lefoglaló vonatokat is. Az alkalmazás jelen verziója nem ellenőrzi, hogy egy vonathoz tartozik-e legalább egy vezetőállással felszerelt kocsi, és legalább egy motorkocsi, de a kocsi típusához tartozó leíró adatokat felhasználva ez könnyen eldönthető. A járművek típusát a MÁV-nál használt komplex sorozatjelekkel, a gyártó nevével és az állományba vett középszám-tartománnyal azonosítom. A középszám a gyártási számnak egy csonkított formája, mely azonban az egyéb kulcsmezők mellett elegendő az egyértelműséghez. Útválasztás Most, hogy minden építőelem rendelkezésre áll, foglalkozhatunk az útvonalválasztás megoldásával. Bár az állomás két adott vágányszakasza közötti lehetséges útvonalat keresőalgoritmus is felderíthetné, én az adatszintű megoldást választottam, mely szerint minden vágányszakasz-párhoz, melyek a Section tábla alapján nem szomszédosak, rögzítem az InnerRoute (Belső útirány) táblában, hogy hányadik útvonalnak hányadik eleme melyik vágányszakasz. A felsorolásba nem számítom be az induló és érkező szakaszt, valamint az induló-érkező párokat csak egyszer, sorrendre tekintet nélkül veszem fel. Az utolsó mezőt kivéve mindegyiket szükséges bevonni az elsődleges kulcsba, hogy egy-egy útvonal feltérképezése egyértelmű legyen. Mindez az állomáson belüli útválasztást szolgálja, de perspektivikusan felvettem az OuterRoute (Külső útirány) táblát, mely két állomás közötti útválasztást valósít meg. E tábla adatszerkezetét tekintve ekvivalens az InnerRoute táblával. Menetrend Ahhoz, hogy a pályán ne véletlenszerűen jelenjenek meg a vonatok, hanem valamiféle célforgalmi szándék szerint, készítettem egy táblát, melyben a naponta ismétlődő (azonos) menetrendet tárolom. A menetrend (Timetable tábla) egy tételéhez ismernünk kell a közlekedő vonatot, az induló és érkező állomást, valamint az indulás és érkezés idejét. Egy-egy tétel csak két szomszédos állomás közti menetrendet szabályozza, ezért
ahány megállója van a vonatnak, annyi sort kell hozzá felvenni. Vegyük észre, hogy elsődleges kulcsnak megfelel a vonat és az indulási idő direkt szorzata, mivel egy vonat egy időben nem lehet két helyen. Az alábbi táblák kizárólag arra alkalmasak, hogy azonosítókhoz hosszú nevet rendeljenek:
CarPower (kocsi által használt üzemanyag)
Function (kocsi szolgáltatás szerinti funkciója)
Manufacturer (kocsi gyártója)
Driver (járművezető)
Összefoglalásul alább látható a teljes adatbázis modellje (1. ábra).
1. ábra
A logikai szint modellje Bár a Vasúti forgalomirányító rendszer logikai szintjének adatszerkezetét az imént bemutatott objektumrelációs adatbázisra építem, nem áll szándékomban az alkalmazás e kezdeti verziójában minden adattartalmat felhasználni, melyet az adatbázis őrizni hivatott. Mivel a Java nyelven megírt logikai szint tiszta objektumos adatszerkezete többnyire egyértelmű leképezése az adatbázis objektumrelációs struktúrájának, a statikus modellre vonatkozóan csak az eltéréseket fogom tárgyalni. A fejlesztés eszközei A program logikai szintjét és felhasználói felületét C++ nyelven kezdtem írni, CodeBlocks 10.02 fejlesztőkörnyezet és MinGW 4.1 fordító használatával, azután praktikus okokból eszközöket váltottam: végül Java nyelven készült el a forráskód, melyet Java virtuális gépen futtatható JAR formátumra fordítottam, NetBeans 7.01, Notepad++ 5.8.5 és a standard Java Compiler segítségével. A használathoz szükséges Java Runtime Environment 6.21 vagy későbbi. MySQL Server 5.5 Az alkalmazás kerete A szoftver komponenseit a három rétegnek megfelelően a Java forráskód szintjén is különválasztottam: a UserInterface (felhasználói felület), az Application (logikai szint) és a Database (adatbázis) osztályok formájában, melyek közül a statikus tartalmú Application, a másik kettőnek egy-egy példányát foglalja magába. Az alkalmazás belépési pontja értelemszerűen az Application osztályban található. További osztályt képvisel a biztosítóberendezés (ControlSystem), amely a felhasználói felületről kiadott utasítások ellenőrzését valósítja meg, és egy példánya szintén az Application osztálynak egy attribútuma. Állomás megnyitása A szoftver a futtatást követően megpróbál csatlakozni az előre adott MySQL adatbázishoz – a felhasználónak sem ekkor, sem később nem áll módjában kiválasztani a használni kívánt adatbázist. Sikeres csatlakozás esetén a szoftver rákérdez a megnyitni
kívánt állomásra. A felhasználó az állomás hosszú, ékezetes nevét adja meg, mely alapján a program beolvassa a kért állomás adatait az adatbázisból, és felépíti az adatszerkezetet az operatív tárban. Az állomás vágányszakaszait nem csak láncolt adatszerkezetben, hanem a rájuk mutató hivatkozásokat tömbösen is eltárolom, mert a későbbiekben ez megkönnyíti a keresést, de az állomás felépítési folyamatához is szükségesnek láttam, mint egyfajta átmeneti tárat. Ha az állomás beolvasása sikerült, akkor megpróbálja betölteni a menetrend alapján a vonatokat, melyek a nap hátralevő részében érintik az állomást. Az érkező vonatok az először megtalált szabad bejárati szakaszra kerülnek, amelyek pedig nem férnek el, azok egy láthatatlan statikus objektumra, mely megfelel a vágányszakasz típusának. Későbbi verziókban ez azt a célt szolgálja majd, hogy amint megürül valamelyik bejárati szakasz, ott automatikusan megjelenik az alapértelmezett szakaszon legrégebben várakozó vonat. Jelenleg egyszerre töltődik be az egy napon esedékes vonatok összessége, és amennyit értelemszerűen el lehet helyezni az állomáson, annyit a szoftver megjelenít. A forgalmat megvalósító háttérosztályok A vonatok mozgása jelzők és váltók beállításával lehetséges. Egy vonat menesztés esetén elindul abba az irányba, amerre először szabad vonatmozgásra utaló jelzést kap. A felhasználói felület minden funkcionális eleméhez egy közös, ActionListener interfészt
megvalósító
eseményfigyelő
objektumot
rendeltem,
mely
a
biztosítóberendezésnek egy metódusát hívja meg attól függően, hogy mely objektum váltotta ki a gomblenyomás eseményét. A biztosítóberendezés fő szerepe nem közvetlenül az állomás és vonatok adatszerkezetének manipulálása, hanem az ahhoz szükséges feltételek ellenőrzése, és azok megléte hiányában a felhasználó figyelmeztetése. A vasúti közlekedésben mindenképpen el kell kerülni, hogy azonos vágányon két szerelvény egymással szembetalálkozzon, azonos irányban haladva egyik utolérje a másikat, illetve hogy váltók gyöke felől egymást oldalba kapják. A vonatbiztosító rendszer ezen kívül visszajelzést ad egyes objektumok (jelzők, váltók) állapotáról a felhasználó kérésére. Az adatszerkezeteken végzett változtatásokat maguk az adatszerkezetet megvalósító Station (Állomás) és Train (Vonat) osztályok metódusai végzik. A körülhatárolhatóság végett a szoftver által használt minden olyan osztály, melyet magam írtam, a VFIR
csomag részét képezi. Ezeket az osztályokat vagy egy másik, e csomagon belüli osztályból, vagy az ugyanitt található VFIR.Object gyökérosztályból terjesztettem ki. Amiatt, hogy az állomás alapegysége a vágányszakasz, és minden más objektum valamely vágányszakaszhoz köthető egy adott pillanatban, a metódusok működésében és elnevezésében nagy szerepet kapnak az irányok: minden szakaszról két irányban lehet lehaladni, ezért minden beállított vágányúton külön kell vizsgálnunk az előre és hátra tartó menetirány esetét, az első és hátsó jelzőt, az első és hátsó váltót. Metódusaimban kerültem a mellékhatást: a függvények általában nem végeznek inputoutput műveletet, az eljárásra szánt rutinok pedig nem adnak vissza értéket, hanem a változtatás eredményeit külön függvény meghívásával kell lekérni. Java-osztályaim kialakításakor törekedtem arra, hogy az egyes fogalmak közötti függés megjelenjen a logikai szintű adatszerkezetben, ezért egy olyan osztályt, mely által implementált fogalom egy bizonyos másik fogalom nélkül nem létezik, mindig a másik fogalmat megtestesítő osztályon belül definiáltam. Az adatbázisban találhatók olyan felsorolt típusú adatok, amilyen például a peron fajtája, vagy a lámpafejek színe. A Java nyelv támogatja a felsorolt típusok absztrakt formáját egy, a statikus osztály fogalmához hasonló formában, ezért az SQL-táblákból nyert elemi adattípusok helyett a memóriában speciálisan az adott célokra rendszeresített enumerált típusokkal dolgoztam. Ezeket kivétel nélkül osztályokba ágyaztam, mert mindegyik a rendszer alapfogalmainak valamely attribútumát leíró típus. Mivel az alkalmazás az állomás szerkezetén és a vonatokon végzett minden műveletet a biztosítóberendezés közvetítésével végzi, ezért a továbbiakban a logikai szint felépítését a biztosítóberendezés funkcióinak rövid lényegre törő kifejtésével ismertetem. Jelzők átállítása Egy jelző átállítása a jelzéskép szigorítása esetén éppúgy, mint a megengedőbb jelzésre való áttéréskor, kockázattal jár. Ha éppen szerelvény közlekedik azon a szakaszon, melynek kijáratán a jelzőkészülék szabad jelzést ad, a járművezető hirtelen fékezésre kényszerülhet, hogy a korábban kapott utasítás szerinti féktávolságnál rövidebb úton képes legyen megállni, vagy a jármű sebességét kellően lecsökkenteni. A jelzéskép csökkentése ezért megerősítést igényel. Ennél is súlyosabb eseményt kockáztat a forgalomirányító, ha egy vágányszakasz kijáratán nagyobb sebességet engedélyez, mint amennyiről meg lehet állni a menetirány
szerinti következő szerelvény tartózkodási helyéig. A jelzéskép ezért csak a megelőző vonattól való térközben mért távolsággal azonos számú fokozatig növelhető (az alkalmazás jelen verziójában ez annyiszor 40km/h – de legfeljebb 160 km/h – sebességet jelent, ahány vágányszakasz távolságra a megelőző vonat tartózkodik, függetlenül az útba eső egyes vágányszakaszok hosszától). A hívójelzés arra szolgál, hogy lehetővé tegye a célforgalmat akkor is, ha a követési távolság biztosítása nem lehetséges, azaz a járművezető a következő főjelző állapotára nem kap információt. Az alkalmazható sebesség ennek alapján 15 km/h, amit azonban nem szemléltet az alkalmazás jelen verziója. Mind a hívójelzés, mind a tolatási műveletek engedélyezése csak a haladási irány szerint lezárt vágányúton történhet, hogy a pályán ne léphessen fel váratlan akadály – a biztosítóberendezés tehát csak lezárt vágányútra vezérel ki hívójelzést vagy „szabad a tolatás” jelzést. Utóbbit értelemszerűen a lezárt vágányútba eső jelzőkön mindkét irányban megjeleníti. Váltók kezelése Mivel a váltók meghatározzák a vonatok fizikai útvonalát, ezért a váltók átállítása minden olyan esetben balesetveszélyes, amikor egy mozgásban lévő szerelvény túl közel jut az adott váltóhoz. A váltókra való haladást ezért fedezőjelzőkkel kell szabályozni, melyek jelzésképét a követési távolságon kívül a váltók csúcsreteszének állapota befolyásolja. Ha a váltó csúcsa felől a fedezőjelző szabad jelzést ad, akkor ha a váltó gyökének bármelyik ága felől szintén engedélyezzük a ráhaladást, az két vonat szembeütközését, vagy oldalba kapását eredményezheti. A biztosítóberendezés ezért a váltó három ága közül egyszerre csak egyre enged szabad jelzést vezérelni. Ha a váltó csúcsa felől és a gyök egyik ága felől tilos a ráhaladás, a gyök másik ága felől pedig szabad, de a váltó csúcsretesze nem megfelelő pozícióban van, akkor a váltó gyöke felől érkező vonat mindenképpen felvágja a váltót, ezzel rongálva azt, de nagy eséllyel ki is siklik. A biztosítóberendezés ezért mindaddig nem enged egy váltót átállítani, amíg a váltó három ága közül bármelyiken szabad jelzést mutat a fedezőjelző. Vágányutak beállítása Bármilyen elcsépeltnek és kezdetlegesnek hat az útválasztás adatszintű teljesítése, az állomásokon napjainkban is alkalmaznak váltóállítási táblázatokat azokra az
útvonalakra, melyeken rendszeres forgalom bonyolódik. Hátránya, hogy nagy mennyiségű adatbevitel nélkül a szoftver nem képes meghatározni az útvonalat két nem szomszédos vágányszakasz között. Az én virtuális biztosítóberendezésem is az adatbázisra hagyatkozik ezen a területen, abból azonban csak az elvileg lehetséges útvonalakat gyűjti ki, és az operatív memóriában kialakított vágányzaton dönti el, hogy egy adott útvonal végig bejárható-e, vagy valamelyik szakaszán jármű tartózkodik. A bejárhatók közül a legrövidebbet választja ki, a legrövidebbek közül pedig azt, amelyik először szerepel az adattáblában. Előfordulhat, hogy az eredményül kapott útvonalon bejárásához vonatfordítás szükséges – ilyenkor a vágányút lezárása csak az első irányváltás helyét jelentő vágányszakaszig eredményes: az út további részén a váltókat kézzel kell beállítani.
A felhasználói felület modellje A Vasúti forgalomirányító rendszer felhasználói felülete alapvetően három fő komponensből áll: a keretmenüből, az állomás-megfigyelő kamera látképét kirajzoló virtuális képernyőből, és a felhasználói funkciókat kiváltó gombok alkotta vezérlőpanelből. A keretmenü, és egyáltalán a sablonként használt vezérlőelemek a Java Swing könyvtárcsomag osztályainak felhasználásával készültek. A keretmenüt kivéve a felhasználói elemek csak akkor jelennek meg a képernyőn, ha az adatbázishoz sikerült csatlakozni. Ekkor még a felhasználói funkciókat biztosító gombok tiltott állapotban vannak, mert az állomás, melynek objektumait manipulálniuk kell, e pillanatban még nincs a memóriában, így a gombok használata kritikus kivételt idézhet elő. Egy állomás sikeres betöltése után minden felhasználói művelet elérhetővé válik, kivéve azokat a gombokat, melyek mögött a működést ebben a verzióban nem szándékoztam kidolgozni, ezért ezek az alkalmazás teljes futása alatt tiltva maradnak. A legalapvetőbb felhasználói műveleteket az Állomás és Súgó menü elemei valósítják meg. Az Állomás menü alatt végezhető egy állomás megnyitása és bezárása, az adatbázis-kapcsolat tesztelése és a program elhagyása. A Súgó menüből elérhető a szoftver jelen dokumentációja, illetve névjegye. A monitort egy kétrétegű panellel modellezem, melynek alsó rétegére az állomás megnyitása során az állomás vágányhálózatát tartalmazó egyszerű panel kerül, felső rétegére pedig egy szimpla, de átlátszó panelen a vonatokat jelentő, 3 képpont vastagságú kék vonalak rajzolódnak ki. A vágányszakaszok kirajzolása lépésenként történik, hogy az állomást a memóriában képviselő adatszerkezetet ne kelljen fölöslegesen kétszer bejárni: egyszer felépítéskor, egyszer pedig megjelenítés céljából. Amint tehát egy szakasz összes adata ismert, 1 képpont vastagságú fekete vonallal kirajzolódik a vászonra, számként tárolt adatbázisbeli azonosítójával együtt, hogy a későbbiekben a felhasználó könnyen tudjon rájuk hivatkozni. Valójában nem közvetlenül a panelre, hanem egy azonos méretű logikai, BufferedImage típusú objektumra, amelynek tartalma automatikusan rajzolódik a panelre mindig, mikor a bennfoglaló panel fókuszt kap, vagy mikor az általam alkalmazott repaint() metódus végrehajtódik. Valahányszor egy jelzőt át kell állítani, frissíteni kell az állomás rajzát a megfelelő helyen: egy-egy fekete vagy színes, kitöltött, az adatszerkezetnek megfelelő alakzat
elegendő, hogy akár kigyújtsunk, akár kioltsunk egy lámpát. Ennek sorozata pedig a jelzéskép teljes megváltoztatását teszi lehetővé. Hogy ilyenkor hova kell rajzolni, azt egyrészt az átállítandó jelzőnek a tartalmazó vágányszakaszára mutató pointerével, másrészt a vágányszakaszról a kirajzolás során eltárolt kezdő- és végpont alapján tudom meghatározni. Egy jelző kiválasztásához egyrészt ki kell tölteni a „kezdő térköz” vagy a „végső térköz” mezőt a vágányszakasz azonosító számával, melyen az egyik jelzőt kezelni szeretnénk, másrészt ki kell választani a megfelelő rádiógombok segítségével, hogy a szakaszon elöl vagy hátul áll a számunkra érdekes jelző. A „jelző ellenőrzése” művelet megjeleníti egy üzenetpanelen a jelzéskép által hordozott utasítás pontos megfogalmazását, így aki nem is jegyezné meg eleinte a színes lámpák sorozatának értelmét, azonnal megérti, mit mutat a jelző. A „sebesség +” feliratú gomb segítségével növelhetjük egy fokozattal (40 km/h-val) az adott jelzőn megengedett haladási sebességet, a „sebesség –” pedig egy hasonló fokozattal csökkenti azt. Ebből a sorozatból kimaradnak a speciális jelzések, mint a hívójelzés, a hívójelzés feloldása, vagy tolatásjelzővel egybekötött főjelzők esetén a szabad tolatás: ezeket külön gomb használatával lehet megjeleníteni. A „megállj” gomb azonnal „megállj” vagy „tilos a tolatás” jelzést küld ki az érintett jelzőre, a jelzőkészülék típusától függően. A szoftver jelenleg nem támogatja a villogó jelzések megjelenítését: helyettük folyamatos jelzés látható, amely esetenként megtévesztő lehet. A „jelző ellenőrzése” gomb használatával azonban egyértelmű szöveges üzenet tájékoztat arról, hogy a jelző mellett elhaladó vonatvezető milyen utasítást kap. Az „összes tolatás állj” gombbal az összes tolatásjelzőre „tilos a tolatás” jelzést lehet vezérelni, azonban a főjelzők állapota változatlan marad. Az „összes menesztés állj” gombra ugyanez fordítva érvényes, kivéve, hogy a tolatásjelzővel egybekötött főjelzőn megmarad a „szabad a tolatás” jelzés. A „mindent megállítani” funkció tekintet nélkül a jelzők típusára, az összes jelzőre „megállj”, illetve „tilos a tolatás” jelzést küld. E három funkció megerősítést kíván egy üzenetpanelen, mivel ezek durva beavatkozások a forgalomra vonatkozóan. A váltók átállításához nem kapcsoltam grafikai megjelenítést, mivel összesen két állapot lehetséges, és ezek könnyen megállapíthatók a „váltó ellenőrzése” funkcióval. Egy váltó állapotát a ”váltó átállítása” gomb használatával tudjuk átbillenteni, ha a szükséges feltételek adottak. Ilyenkor, hasonlóan a jelzők átállításához, előzőleg ki kell tölteni a
„kezdő térköz” vagy a „végső térköz” mezőt, viszont itt a váltóra vonatkozó rádiógombok közül kell egyet választani, mely megadja, hogy a szakaszon elöl vagy hátul található az érintett váltó. Egy elágazásban mindig az „Y” alakzat szárát jelentő vágányszakaszt kell megadni a váltó helyéhez. Ha egy funkció csak egy térköz megadását igényli, de mindkét mező ki van töltve, a szoftver mindig a „kezdő térköz” mező tartalmát veszi figyelembe. Ha egyik mező sincs kitöltve,
akkor
az
eseménykezelő
nem
kap
semmilyen
instrukciót,
így a
biztosítóberendezés semmilyen műveletet nem hajt végre. Ha két vágányszakasz között kívánunk útvonalat beállítani, mind a „kezdő térköz”, mind pedig a „végső térköz” mezőt ki kell tölteni, és a „vágányút beállítása” funkcióval az összes útba eső váltó megfelelő irányba áll – természetesen, csak ha a program talált szabad utat a két szakasz között. Az egyes funkciókat elindító gombokat a rugalmasság és bővíthetőség érdekében kategóriánként külön panelekre rendeztem, ezeket pedig együtt egy közös vezérlőpanelre helyeztem. Két térköz megadását igényli továbbá a tolatási engedély és a hívójelzés kiadása egy adott vágányútra. A hívójelzés csak jelzőtől jelzőig, és állomásonként egyszerre csak egy útra adható ki, valamint a főjelzők által adott forgalmi jelzésekhez hasonlóan egy meghatározott irányban engedélyezi a haladást. A tolatási műveletek iránya ezzel szemben egy erre lezárt útvonalon belül határozatlan, illetve nem feltétlenül folyamatos, éppen ezért az alkalmazás jelen verziójában a tolatási engedély csak a jelzőket befolyásolja – a szerelvényeket helyben hagyja. Az állomás fő tengelye a képernyő mentén azért vízszintes irányú, mert a vágányok hossza jellemzően mindig nagyobb, mint két párhuzamos vágány közti távolság, így a standard 4:3 arányú képernyőre ennyivel is nagyobb állomást lehet kirajzolni. Az alkalmazás jelen verziójában a virtuális képernyőn egyszerre el nem férő állomások beolvasása hibás működést eredményez. A vonatok ábrái egy BufferedImage objektumokat tartalmazó listába kerülnek, melynek minden eleme egy vonatot ábrázol. Az egyszerűnek ható kezdeti megjelenítés után a vonatokat mozgatni kell, amikor arra felhatalmazó utasítást kapnak jelzőkészüléken vagy tolatási engedély formájában. Legegyszerűbbnek találtam a java.swing.Timer osztály alkalmazását, mely időzítés alapján egy speciális eseményt vált ki, annak forrását pedig az actionListener objektum meg tudja állapítani. Külön időzítőt használok az előre-, illetve hátrafelé történő mozgatáshoz. Az eseményfigyelő objektum
feladata, hogy leállítsa a megfelelő időzítőt, ezáltal a mozgatandó vonatot reprezentáló vonal animációját, amint a vonat olyan pontra ér, ahonnan a jelzési utasítás szerint nem szabad továbbhaladnia. Az actionlistener feladata továbbá, hogy ha egy vonat elhalad egy jelző mellett, azt a megváltozó vágányfoglaltság alapján a követő vonatok számára a szabványos állásba állítsa, amely jellemzően a „megállj!” vagy a „tilos a tolatás” jelzés. Az alkalmazás jelen verziója egyszerre csak egy szerelvényt képes helyesen mozgatni – több vonat egyidejű menesztése határozatlan eredménnyel járhat. Ezen kívül megtévesztő lehet, hogy a vonatokat reprezentáló vonalak akkor sem fordulnak el, amikor kitérő irányban mozognak, így nem lehet pusztán a képről eldönteni, hogy az adott szerelvény a váltó gyökének melyik ágán tartózkodik. Ezért helyeztem el a felhasználói felületen a „foglaltság ellenőrzése” gombot, amely egyértelmű szöveges tájékoztatást ad a felhasználónak, hogy melyik vágányszakaszt áll a jármű; esetleg mindkettőn – ilyenkor a két vonat ábrája egymást takarja, de menesztés után ismét külön láthatók.
Tesztelés Állomás megnyitása Első dolgunk az alkalmazás futtatása kapcsán, hogy aktív adatbázis-kapcsolat esetén megadjuk a kezelni kívánt állomást. A szövegmezőt üresen hagyva az OK gombra kattintva figyelmeztetést kapunk, hogy nem adtunk meg állomásnevet. Nem létező állomás megadásakor a szoftver tájékoztat, hogy az állományban nem szerepel a megadott nevű állomás. Ha a „mégse” gombra kattintunk, mindenképpen azt a felhívást kapjuk, hogy nem adtunk meg állomásnevet. Ez javítandó a későbbi verziókban: itt nincs szükség üzenetre.
2. ábra
A fenti képernyőt az Állomás menü Megnyitás parancsával is előhívhatjuk. Helyes állomásnév megadása után az alábbi képernyőt látjuk.
3. ábra
A funkciók tesztelése a következő koncepció szerint történik: A jelzőt és a váltót „első” állásba állítjuk. Minden funkciót kipróbálunk úgy, hogy semmit sem írunk a mezőkbe. Minden funkciót kipróbálunk úgy, hogy csak a „kezdő térköz” mezőt töltjük ki. Minden funkciót kipróbálunk úgy, hogy csak a „végső térköz” mezőt töltjük ki. Ugyanezeket végig próbáljuk a jelző és váltó rádiógombjának többi kombinációjával. Menesztünk egy vonatot a szomszédos vágányra, majd vissza – egyenes irányban. Menesztünk egy vonatot a szomszédos vágányra, majd vissza – kitérő irányban. Menesztünk egy vonatot oda-vissza úgy, hogy egyenes és kitérő szakasz is legyen az útvonalban. Addig növeljük a jelzés fokozatát a jelzőn, amíg tudjuk. Addig csökkentjük a jelzés fokozatát a jelzőn, amíg tudjuk. Megpróbálunk kétoldali „megállj” jelzésre meneszteni egy vonatot. Megpróbálunk egy vágányszakasz mindkét oldalán lévő főjelzőre egyidejű szabad jelzést vezérelni. Megpróbálunk egy váltó gyökének mindkét ága felől szabad jelzést adni.
Megpróbálunk egy váltót átállítani, mikor a gyök egyenes és kitérő ága, illetve mikor a csúcs felől szabad jelzést mutat a fedezőjelző. Megpróbálunk egy nem létező váltót ellenőrizni és átállítani. Megpróbálunk egy nem létező jelzőt ellenőrizni és átállítani. Hívójelzést vezérlünk ki úgy, hogy az útvonalban vonat tartózkodik. Megpróbálunk visszavonni egy nem létező hívójelzést. Megpróbálunk egyidejűleg két útvonalra hívójelzést vezérelni. Szabad tolatásjelzést vezérlünk ki úgy, hogy az útvonalban vonat tartózkodik. Egyidejűleg több útvonalra tolatásjelzést vezérlünk. Menesztünk egy vonatot úgy, hogy az induló szakasz egyik oldalon nincs jelző. Menesztünk egy vonatot úgy, hogy a vonat olyan foglalt vágányhoz érkezzen, mely előtt nincs jelző. Megállítjuk az összes menesztést, mikor egy vonat mozgásban van. Megállítjuk az összes tolatást, mikor egy vonat mozgásban van. Minden mozgást megállítunk, mikor egy vonat mozgásban van.
Fejlesztési javaslatok Az adatbázis bővítési lehetőségei Noha a Vasúti Forgalomirányító Rendszer adatbázisa kis mértékben meghaladja az alkalmazás által használt fogalomkört, számos új adat hasznára lehet a rendszernek. A menetrend jelenleg semmi mástól nem függ, mint az adatrögzítő szándékától, a járművezetőkről eltárolható törzsadatok azonban segítenének abban, hogy a vonatok indulása és érkezése az emberi kapacitás függvénye legyen. Már a jelenlegi adatszerkezet is támogatja az állomások globális hálózatba kapcsolását – fizikailag. A vonatok indítása és fogadása azonban megfontolást igényel: az állomások együtt értelmezésével nem lesz mindegy, hogy a szoftver melyik bejárati vágányszakaszra helyezi el az érkező vonatot, és melyik kijárati szakaszról küldi tovább, hiszen lehetséges, hogy két állomás csak egy vágányúttal van összekapcsolva, de az egyes állomásoknak lehet több kijárata. Nyilvánvaló, hogy a szoftver nem tekintheti egyetlen állomásnak az összes állomás összekapcsolt hálózatát (ez esetben semmilyen logikai szintű változtatásra nem volna szükség), mert az egy valószerű ország méretében meghaladná az operatív memória kapacitását egy személyi számítógépen. Ebből a megfontolásból előre létrehoztam egy táblát az állomások közti útválasztás céljára, amely így elkülönül az állomáson belüli útválasztástól. Kínálkozik az alakjelző készülékek bevonása a fényjelzők mellé, hiszen napjaink vasúti közlekedésében is sok helyen megtalálhatók – főleg mellékvonalakon. Ezek számára külön tábla határozná meg, hogy milyen utasítás milyen alakzatot követel meg a jelzőn. Közúti kereszteződések bevezetésével értelmet kaphatnának az önműködő útsorompót ellenőrző fedezőjelzők és a mellékvonali ellenőrző jelzők, melyek használatát az adatbázis már most támogatja. A kocsik összekapcsolása az adatbázis jelen formájában bármilyen kombinációval lehetséges, a valóság azonban egészen más: két gördülő állomány csatolhatósága függ a fékrendszertől, a hajtásvezérlés módszerétől, a csatlómű magasságától, a kocsi szélességétől és sok egyéb tényezőtől. Ilyen adatokkal bővítve a CarType táblát, a vonat-összeállítás a felhasználó számára nagyobb megfontolást igényelhet, amennyiben az alkalmazás kezeli ezeket a paramétereket. A felhasználói feladatok bővülésével megfontolandó a felhasználói szerepek elkülönítése. Külön bejelentkezést igényelne például a forgalomirányító és a járműtelepi szolgálattevő hatásköre, mely által az emberi erőforrás korlátai látványosabbak.
A logikai szint bővítési lehetőségei Az állomások világszerte azért jöttek létre, hogy azonos célforgalmi helyen egyszerre több, egymástól elkülönülő közlekedési műveletet lehessen bonyolítani. Ezért érdemes úgy fejleszteni a vonat-animációt, hogy mindegyik vonat mozgatásának időzítése külön szálat használjon – így a különböző vonatoknak adott utasítások egymást nem hátráltatják majd. Az alkalmazás jelen verziójában csak a tervezés szintjén áll a vonatok általános és állomásonkénti követési távolságának szabályozhatósága. Bár a térközbiztosító berendezés most is alkalmas az utolérés kivédésére, a gyakorlatban jelentősen megnöveli a biztonságot, ha egy „megállj” jelzés után nem mindjárt foglalt vágány következik. Kézenfekvő a több vágányszakaszon át húzódó szerelvények kezelése (különösen tehervonatokra jellemző), melyre az adatbázis most is lehetőséget ad: ehhez azonban a teljes logikai vonatmozgást újra kell tervezni. A peronokon meg lehet különböztetni utasforgalmi és rakodási műveleteket. A tolatási műveletek teljes kidolgozásra szorulnak: legalapvetőbbek a vonatfordítás, a szerelvények összekapcsolása és szétválasztása. Amennyiben megkülönböztetünk forgalmi és járműtelepi vágányokat, járulékos tolatási műveletnek tekinthető a forgalomba állás és a forgalomból kiállás. A felhasználó kényelmének érdekében megfontolandó a számlált kezelési ciklusok bevezetése, mely által a felhasználó ismétlődő műveletekre adhat utasítást – csökkentve ezzel a szükséges beavatkozások gyakoriságát, és az ebből adódó forgalomirányítási kockázatok valószínűségét. A szoftver valószerűségén emelne, ha véletlenszám-generálás segítségével bizonyos váratlan események következnének be az irányított területen, hiszen nem várható el semmilyen gépezettől, hogy végtelenségig kifogástalanul működjön. Az egyes objektumokról (elsősorban jelzőkről és váltókról) egy természetes szám formájában lehetne tárolni a műszaki állapotot. A biztosítóberendezés funkcióinak kiterjesztésével szükségessé válik a felhasználói műveletek naplózása, mely a hibás működéseket is regisztrálva segítené a további fejlesztést.
A felhasználói felület bővítési lehetőségei Elsődleges javítási feladat a vonatmozgás animációjának pontosítása, apróbb hibák javítása. A járműveket reprezentáló vonalakat a kanyarokhoz kell igazítani, mindezt úgy, hogy egy vonat akár több vágányszakaszon keresztül ábrázolható legyen. A különböző üzemű vonatokat és a felsővezetékkel ellátott vágányszakaszokat jól elkülöníthető színekkel kell kiemelni. A jelzőkön láttatni kell a lassú és gyors villogást. A hívójelzés végét jelző lefordított zöld „V” jelet láttatni kell a főjelzőkön. A jelzők típusát az árbocmintázat jelképes ábrázolásával láttatni kell. Váltójelzőket kell elhelyezni minden elágazás csúcsa mellé. Bővítendők a biztosítóberendezés szöveges üzenetei, elsősorban a vizsgált vagy kezelt objektumok azonosítójával és típusleírásával. A logikai szint fejlesztési lehetőségeinél ismertetett funkciókat csak több fül elhelyezésével lehet hiánytalanul elérhetővé tenni; ezeken a műveleteket csoportosítani kell. Az állomás-megfigyelő kamera látképét reprezentáló objektum mellé gördítő sávokat kell elhelyezni, hogy a képernyőn el nem férő állomások is maradéktalanul megtekinthetők legyenek. Ehhez
szükséges az
állomást képviselő objektum
konstruktorának újratervezése. A vágányhálózat megjelenítése jelenleg durva transzformációval (nyírással) történik. Sokkal látványosabb lenne a kiágazások görbékkel való szemléltetése, és a vágányszimmetria valós ábrázolása. Nagy állomások áttekinthetősége érdekében megfontolandó a nagyítás/kicsinyítés lehetősége egy új, „nézet” menüben. Az egyes utasításokhoz a jelzési utasításnak megfelelő kürt- illetve sípjeleket lehet társítani.
Felhasznált irodalom MÁV F.1. jelzési utasítás (régi) MÁV F.1. jelzési utasítás (új) MÁV F.2. forgalmi utasítás MÁV sorozatjelek jelentése Budapesti metró F.1. jelzési utasítás Budapesti metró F.2. forgalmi utasítás HÉV F.1. jelzési utasítás Nagy Viktória: A Siemens-Halske biztosítóberendezés felépítése Java dokumentáció Sallai András Java programozási oktatóanyaga StackOverflow szoftverfejlesztői fórum Hogyan készítsünk önállóan futtatható JAR fájlt? Index metró fórum Index HÉV fórum MÁV személykocsik listája MÁV V43 sorozat MÁV V63 sorozat MÁV M41 sorozat MÁV M61 sorozat MÁV M62 sorozat BVmot motorvonat BVhmot motorvonat BDVmot motorvonat Bzmot motorvonat MDmot motorvonat Siemens Desiro motorvonat
