Budapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki Kar Közlekedésüzemi Tanszék
Az elektronikus jegyrendszerek által szolgáltatott adatok feldolgozási lehetőségeinek vizsgálata
Diplomaterv
Zsiborás Róbert QB6WEI
2012
Tartalomjegyzék Bevezetés ......................................................................................................................4 I. Az elektronikus jegyrendszerek működése .................................................................6 I.1. Az elektronikus jegyrendszerek története, felépítése ............................................6 I.2. A jegyrendszerek működésének változatai ......................................................... 10 I.3. A Transmodel szabvány .................................................................................... 14 I.3.1. Hálózatleírás és verzió menedzsment .......................................................... 16 I.3.2. Taktikai tervezés ......................................................................................... 16 I.3.3. Személyzeti beosztás .................................................................................. 17 I.3.4. Üzemeltetési felügyelet és vezérlés ............................................................. 17 I.3.5. Utasinformáció ........................................................................................... 18 I.3.6. Viteldíjbeszedés .......................................................................................... 18 I.3.7 Menedzsment információ és statisztika ........................................................ 18 I.3.8. A szabvány további részei........................................................................... 19 II. A jegyrendszerek bevezetésére vonatkozó hazai törekvések, külföldi példák ........... 22 II.1. A budapesti rendszer ........................................................................................ 22 II.1.1. A budapesti bevezetés első lépései, rendszer követelmények ..................... 22 II.1.2. Informatikai háttér ..................................................................................... 24 II.1.3. Utasmédia típusok ..................................................................................... 24 II.1.4. Díjfizetési módok ...................................................................................... 26 II.1.5. Regisztráció menete .................................................................................. 26 II.1.6. Használat ................................................................................................... 27 II.1.7. Értéknövelt szolgáltatások ......................................................................... 29 II.1.8. Előnyök, hátrányok ................................................................................... 29 II.2. Egyéb hazai törekvések .................................................................................... 30 II.3. Oyster card – Egyesült Királyság, London........................................................ 31 II.3.1. Az Oyster card története ............................................................................ 31 II.3.2. Informatikai háttér ..................................................................................... 31 II.3.3. Utasmédia típusok ..................................................................................... 31 II.3.4. Díjfizetési módok ...................................................................................... 32 II.3.5. A regisztráció menete ................................................................................ 33 II.3.6. Használat ................................................................................................... 34 II.3.7. Értéknövelt szolgáltatások ......................................................................... 35 II.3.8. Előnyök, hátrányok ................................................................................... 35 II.4. OV-Chipkaart – Hollandia ............................................................................... 36 II.4.1. Az OV-Chipkaart története ........................................................................ 36 1
II.4.2. Informatikai háttér ..................................................................................... 36 II.4.3. Utasmédia típusok ..................................................................................... 36 II.4.4. Díjfizetési módok ...................................................................................... 37 II.4.5. Regisztráció menete .................................................................................. 38 II.4.6. Használat ................................................................................................... 38 II.4.7. Értéknövelt szolgáltatások ......................................................................... 39 II.4.8. Előnyök, hátrányok ................................................................................... 39 II.5. Chicago card – Egyesült Államok, Chicago ...................................................... 40 II.5.1. A Chicago card története ........................................................................... 40 II.5.2. Informatikai háttér ..................................................................................... 40 II.5.3. Utasmédia típusok ..................................................................................... 41 II.5.4. Díjfizetési módok ...................................................................................... 41 II.5.5. A regisztráció menete ................................................................................ 41 II.5.6. Használat ................................................................................................... 42 II.5.7. Értéknövelt szolgáltatások ......................................................................... 42 II.5.8. Előnyök, hátrányok ................................................................................... 42 II.6. A rendszerek összehasonlítása .......................................................................... 43 III. Az elektronikus jegyrendszer adatbázis modellje ................................................... 44 III.1. A modell felépítésének megalapozása, általános sémák ................................... 45 III.2. A Scwäbisch Hall-i rendszer mintarekordja ................................................. 50 III.3. A tárgyi vizsgálathoz készített logikai modell ................................................. 51 III.3.1. A felhasználói adatok ............................................................................... 54 III.3.2. A hálózati adatok ..................................................................................... 54 III.3.3. Járművezénylési adatok............................................................................ 56 III.3.4. Utazási adatok .......................................................................................... 58 III.4. A tárgyi vizsgálathoz készített fogalmi modell ................................................ 58 IV. Az adatbázis elemzése és az adatok feldolgozása ................................................... 62 IV.1. A célforgalmi mátrix előállítása ...................................................................... 63 IV.2. A megállóhelyi terheltség vizsgálata, járműkapacitás kihasználása ................. 65 IV.3. A csúcsóra, a csúcsórai utasforgalom meghatározása ...................................... 71 IV.4. A hálózaton történő átszállások ....................................................................... 73 IV.5. Utasok visszatérési ideje ................................................................................. 76 IV.6. Viszonylatok forgalma irányonként ................................................................ 76 IV.7. Késések egy adott menet során ....................................................................... 77 IV.8. Az utazásokkal kapcsolatos statisztikai adatok ................................................ 78 IV.9. A lekérdezések eredményének térképi megjelenítése ...................................... 79 2
IV.10. Az alkalmazás értékelése, a tovább fejlesztés lehetősége ............................... 84 Összefoglalás .............................................................................................................. 86 Forrásjegyzék .............................................................................................................. 89 Ábrajegyzék ................................................................................................................ 91 Táblázatjegyzék .......................................................................................................... 92 Mellékletek ................................................................................................................. 93
3
Bevezetés Napjaink nagyvárosainak életében központi helyen szerepel a városi közlekedés kérdése. Az egyéni közlekedés szerepvállalása jóval a kívánatos szint felett helyezkedik el, tehát ösztönözni kell a közösségi közlekedési szolgáltatások igénybevételét. A közösségi közlekedés színvonala azonban mind a járműveket, mind az infrastruktúrát tekintve az elvárt alatt marad. A közösségi közlekedés tarifarendszere nem felel meg teljesen a mai igényeknek, a díjszabás nem teljesítményarányos és a megfelelő jegy beszerzése is hosszú időt vehet igénybe. Az elektronikus jegyrendszerek hazánkban még
nem
kerültek
bevezetésre,
azonban
aktualitásuk
egyre
nyilvánvalóbb.
Bevezetésüknek számtalan előnye van mind a felhasználók, mind az üzemeltetők szempontjából, megoldható a teljesítményarányos díjfizetés és nagy segítséget nyújt a közlekedésszervezésben is. Az elektronikus jegyrendszerek bevezetésével egy alternatív lehetőség nyílik meg az utazóközönség szokásainak megismerésére. Ezen rendszerek elsődleges funkciója ugyan az utasokra kirótt díjak beszedésének és az egyes díjtételek értékesítésének könnyítése, de olyan, az elszámoláshoz nélkülözhetetlen adatokat is tárolnak, amelyek a megvalósult utazásokat jellemzik. Ebből kifolyólag lehetőség van az utasadatok feldolgozására és kiértékelésére, aminek eredményeképpen képet kaphatunk a felhasználók utazási szokásairól és igényeiről, összehasonlítva ezeket a vállalat rendelkezésre álló kapacitásaival. A jegyrendszerek másik nagy előnye, hogy a rendszerek segítségével az utazó közönség is könnyebben hozzájuthat a számára fontos információkhoz. A fent említett előnyöket már sok helyen felismerték, és hazánkban is egyre több helyen merülnek fel a bevezetéssel kapcsolatos gondolatok. Ezek közül kiemelendő a 2014-es fővárosi bevezetés. Egy korábbi dolgozatom során a díjbeszedő rendszereket hasznosságuk, illetve felmerülő költségeik szempontjából vizsgáltam. Hasznosságuk nem kétséges, de az mélyebb kutatást igényel, hogy a különféle rendszerek adataiból hogyan állíthatók elő olyan információk, amelyek a közlekedéstervezést és az üzemeltetést segítik. Jelen dolgozatomban erre kerestem a választ.
4
Az első
lépés
az elektronikus
jegyrendszerek háttéradatbázis struktúrájának
megismerése volt, melyre előírást a Transmodel nevű szabvány ad, ami a helyi sajátosságoknak is teret enged. A második lépés során a külföldön működő rendszerek sajátosságaival foglalkoztam. Feltártam a már működő rendszerek eszközeit, működési elvét, illetve azt, hogy az egyes rendszerek milyen díjtételeket támogatnak, hiszen ez nagyban befolyásolhatja a szolgáltatott adatok formátumát. A külföldi rendszerek mellett hazai törekvésekről is gyűjtöttem információkat. A következő fejezet az adatmodell létrehozását tárgyalja mind fogalmi, mind logikai szinten, melyhez szükséges a működéshez nyilvántartandó adatok meghatározása is. Alapvetően a be- és kijelentkezést (CICO) igénylő rendszerek adatfeldolgozási problémáira összpontosítottam. A dolgozat utolsó részében adatbáziskezelő szoftverek segítségével vizsgáltam meg a rendszer adatainak feldolgozási lehetőségeit lekérdezések segítségével, melyeket mind táblázatos, mind grafikus formában elérhetővé tettem. A kutatás során céljaim közé tartozott az adatmodell kidolgozása és megvalósítása mellett egy olyan alkalmazás készítése, aminek segítségével az adatok feldolgozása egyszerű, a tervezést segítő adatokat szemléletesen tárja a felhasználó elé. Célom, hogy az alkalmazás alapja legyen egy későbbi továbbfejlesztett változatnak, ami valós adatokkal működik, és a tervezéshez szükséges adatokat szolgáltat.
5
I. Az elektronikus jegyrendszerek működése
Az elektronikus jegyrendszerek kialakulása, előzményrendszereinek története ma már csaknem négy évtizedre nyúlik vissza. Az elektronikus jegyrendszerek meglehetősen összetett és bonyolult rendszerek, támogatásukra, a működés hátterében minden esetben egy jól felépített informatikai rendszer, elszámoló adatbázis és egyéb más, informatikai és kommunikációs rendszerek állnak. A fejezetben áttekintem a jegyrendszerek felépítését, a hozzá tartozó eszközöket, a jegyérvényesítés típusait, végül a Transmodel szabványt mutatom be.
I.1. Az elektronikus jegyrendszerek története, felépítése
Az első alkalmazott jegyrendszerek a papíralapú, manapság is használt hagyományos, jegyrendszerek
voltak.
A
jegyrendszerekkel
kapcsolatban
egyre
több
igény
fogalmazódott meg, szükség volt új technológiák kidolgozására. Az 1970-es években kezdtek el először mágneses technológiát alkalmazó jegyeket gyártani, amelyeket két típusba lehet besorolni. Az első esetben, egy automata olvassa le a mágnescsíkon tárolt információkat. A másik esetben, az utasnak kell a kártyát végighúznia a leolvasó készüléken. E kettő közül az első terjedt el nagyobb mértékben. Ez volt a legelső lépés, a mai intelligens jegyrendszerek kialakulásához, azonban a kártya adta lehetőségeket nem aknázták ki teljesen. A kártya legnagyobb előnye az volt, hogy nem feltétlenül kellett készpénz a jegy megvásárlásához, hanem a kártya össze volt kötve a felhasználó bankszámlájával. A közlekedési vállalatok számára nagy előnyt jelentett, hogy nem kellett a korábbi mértékben papíralapú jegyeket nyomtatni, és a készpénzes fizetések aránya is csökkenni kezdett.[1] Az érintésmentes kártyák a ’90-es években kezdtek elterjedni. Ennek a technológiának sok előnye van a korábbiakkal szemben, így meglehetősen gyorsan helyettesítették az előzőeket. A kártyák RFID (Radio Frequency IDentification) vagy NFC (Near Field Communication) technológián alapuló kommunikációt alkalmaznak[1]. Ezekben a
6
kártyákban található egy kis hurokantenna, és egy mikroszámítógép is, melyek a leolvasókészülék gerjesztő jelei hatására képesek továbbítani az információt a központ felé. [12] Az intelligens kártyákat használó rendszereket megkülönböztethetjük aszerint, hogy az adatok frissítése a kártyára, vagy valamilyen szerver alapú háttérrendszerre történik [11]. A jelenlegi kártyák viszonylag nagy mennyiségű adat, akár hosszú távú eltárolására is képesek [12]. A kártyára való adatrögzítésnek komoly hátránya, hogy a letárolt adatok különbözhetnek a központban és a kártyán, egy esetleges hibás működés következtében. Ekkor tehát adatinkonzisztencia alakul ki, aminek a kijavítása meglehetősen fáradtságos. Az egyre nagyobb mértékű mobiltelefon-használat hatására kifejlesztették az elektronikus menetdíjszedésnek azt a változatát is, amelynél a felhasználó a saját telefonja segítségével veheti meg a jegyet. Egy adott formátumú SMS-t küldésével, a jegy árát levonják a felhasználó kártyájáról, vagy hozzáíródik a hó végi számlákhoz. A mobiltelefonos jegyértékesítés a következő években újabb fordulatot is vehet az NFC technológiát
támogató okostelefonok elterjedésével [11]. Ezek a készülékek
tulajdonképpen a kártyák alternatívái lehetnek majd. A világon több különféle szabvány alakult ki, amelyek az ilyen rendszerek kialakítására tartalmaznak előírásokat. Ettől függően más lehet a rendszerek struktúrája, működése. A következőekben bemutatom azokat az alapvető eszközöket, amelyek szükségesek a rendszer működéséhez. (1. ábra) [4],[13],[15]
A felhasználói eszköz: Ezek általában kártyák, vagy mobiltelefonok. A kártyák esetében szigorú szabályokhoz, szabványokhoz (pl. ITSO TS-1000-2) van kötve a kártyán tárolt adatstruktúra. Kártya lehet duálinterfészes, vagy csak érintkezésmentes interfésszel felszerelve. A kártyák olvasási távolságát illetően a következő típusokat különböztetjük meg[1],[4],[13],[15]: o Érintőkártyás
(contact-based)
technológia:
Ebben
az
esetben
szükséges a kártya hozzáérintése a leolvasó készülékhez. (pl.: mágnes csíkos kártyák)
7
o Proximity kártya (ISO 14443 szerint): A technológia lehetővé teszi az érintésmentes eszközkezelést. A távolság erősen korlátozott, optimális körülmények között is csak maximum 10 cm. (pl.: passzív RFID) o Vicinity technológia (ISO 15693 szerint): Az ilyen eszközök alkalmazása már nagyobb olvasási távolságot is lehetővé tesz. Maximális hatótávolság ebben az esetben elérheti az 1 métert is. o Nagy távolságú eszközkezelés (Long-, wide-range): A viszonylagosan nagy továbbítási távolság egy a felhasználói eszközben lévő áramforrás meglétét teszi szükségessé. Két technológia ötvöződik ebben az eszközben, az egyik az induktív csatolás, a második a rádiófrekvenciás adattovábbítás. Az induktív csatolás segítségével lehet aktiválni a kártyát a járműre való felszálláskor, ezután továbbítódnak a felhasználó adatai a központ felé. (pl.: aktív RFID)
A kártyát megszemélyesítő eszközök: A kártyák használatba vétele előtt el kell végezni a kártyák inicializálását, valamint a nem átruházható kártyák esetében a kártyák megszemélyesítését. A megszemélyesítés különböző személyes adatok fizikai és/vagy elektronikus feltüntetését jelenti a kártyán, mint pl. fénykép, név, kedvezmény kódja. Utazási kedvezmény igénybevételekor (diák, nyugdíjas stb.) ennek tényét fel kell tüntetni a megszemélyesített kártyán, mellyel ellenőrizni lehet a jogosultságot.
Az utasmédiával kommunikáló egységek: Ezek tipikusan a jegypénztárakban működő terminálok, feltöltő automaták, ellenőri eszközök, jegyérvényesítő készülékek. A készülékek képesek adatokat írni és/vagy leolvasni a kártyákról. Ezek a terminálok tartják a kapcsolatot a központi adatbázissal.
Fedélzeti terminálok: A járművön lévő érvényesítő, értékesítő készülékekkel kommunikáló, azok adatait begyűjtő és tároló eszköz, melyről alkalmanként (nap vagy műszak végén) letöltésre kerülnek a tárolt adatok a telephelyi terminálba. A fedélzeti eszköz a jegyek ellenőrzése, érvényesítése, valamint az utazás hosszával arányos díjak kiszámítása (kétszeri jegy érvényesítés esetén lehetséges) végett szükségesek. A díjszámításhoz szükséges helymeghatározás GPS (Global Positioning System), AVM (Automatizált Vonali Megfigyelés) vagy egyéb a szolgáltató által alkalmazott rendszerek segítségével lehetséges.
8
Telephelyi terminálok: A járműveken lévő fedélzeti terminálokból a tranzakciók adatait naponta vagy naponta többször le kell tölteni egy, a telephelyen lévő eszközbe, mely azután továbbítja ezeket az adatokat a központi rendszer felé. A telephelyi terminál biztosítja az adatáramlást az ellentétes irányban is. Ezen keresztül kerülnek feltöltésre például a feketelistán lévő kártyák adatai a fedélzeti terminálokba, és azon keresztül a fedélzeti készülékekbe.
A központi adattárolás
elvű
működés
esetén,
minden
jegyérvényesítés során közvetlen kommunikáció történik a központtal. Ezen rendszereknél, a fedélzeti eszközök és a telephelyi terminál között GPRS vagy WiFi kapcsolatot biztosítanak.
Rendszer központ: A központi rendszerbe érkeznek be a kártyákkal végzett műveleteket tartalmazó adatok. A rendszernek ezen a szintjén tartják nyilván a felhasználók számláit, és dolgozzák fel a különböző érvényesítési folyamatok során létre jövő adatokat. A központban pénzügyi elszámolásokat, kimutatásokat készítenek, valamint az utazásokkal kapcsolatos adatokat vizsgálják. Az adatokból
képzett
információk
segítségével
fontos
döntéseket
lehet
alátámasztani mind gazdasági, mind forgalomszervezési téren.
1. ábra Az elektronikus jegyrendszerek általános felépítése
9
I.2. A jegyrendszerek működésének változatai
Az elektronikus jegyrendszerek utasok számára leginkább szembetűnő különbségei, a jegyek érvényesítési módjában nyilvánulnak meg. Nagyon fontos, hogy ez a procedúra ne vegyen sok időt igénybe, könnyen elvégezhető legyen, ne legyen könnyen kijátszható, és még az idősebb korosztály számára is egyértelmű legyen a használata. Az új megoldások mellett jellemző, hogy a hagyományos jegyek használatát továbbra is lehetővé teszik a szolgáltatók. Jegyérvényesítés szerint három alapvető típust különböztetünk meg. [2],[4] Check in/Check out (CICO): Ez volt az első típus, mely kihasználta a smartcard-ok adta lehetőségeket, és automatikusan idő és távolság alapján számította ki a viteldíjakat. A felhasználónak kell érvényesítenie a kártyát közvetlenül a felszállás után. Az utasok a bejáratnál elhelyezett érvényesítő készülékekhez lépve odaérintik a kártyát a megjelölt helyre, és megtörténik az adatok cseréje. A kártyán letárolhatják a korábbi utazások adatait is. A felhasznált díjtermék érvényességének ellenőrzése az ellenőröknél lévő kártyaolvasók segítségével történik. A rendszer egyik hátránya, hogy a felszállás pillanatában nem lehet megmondani, hogy egy kártyán elég pénz van-e az adott utazáshoz, hiszen a viteldíj kiszámítása és levonása a leszállásnál történik. Normális esetekben a rendszerek figyelmeztetik a felhasználót, hogy kevés pénz van feltöltve, de az is elképzelhető, hogy nem tudja elvégezni a kijelentkezést, míg nem tölti fel a kártyát a járműveken elhelyezett eszközök segítségével. Néhány rendszerben meghatároztak minimális vagy maximális árakat, amik egy adott utazáshoz tartoznak. Ha ez az összeg nem áll rendelkezésre a kártyán, akkor nem is kezdheti meg az utazást a felhasználó. A check in csak egy előző check out esetén kivitelezhető. Ha a felhasználó, nem jelentkezik ki leszálláskor, úgy a következő járműnél történő felszálláskor megbírságolják. Ugyanilyen okok miatt, a járművön töltött időt is rögzítik. A rendszer jellemzője, hogy teljes mértékben lehetővé teszi a teljesítmény alapú díjszabást. A kétszeri érvényesítés miatt, a rendszerekben alkalmazhatóak a távolság, idő, távolság-idő alapú díjszabási metódusok. A tarifa változhat a nap folyamán, egyes
10
rendszereknél a megállapított csúcsidőszakokban akár, magasabb lehet a viteldíj egy adott utazásra, tehát. Sok városban zónákra osztják a közlekedési hálózatot, és a zóna jellegétől (zöld övezet, ipari park) függően különböző viteldíjakat állapítanak meg, egységnyi távolságra, vagy a kiindulási és cél zónák között állapítanak meg egy általános tarifát. Az ismertetett díjszámítási eljárásokat általában az utólagos fizetés során alkalmazzák, emellett lehetőség van a különféle bérletek igénybevételére is. A viteldíjak általában egy alapdíjból és egy számított díjból adódnak. [2],[4]
Check in (CI): A rendszer módosított változata a csak bejelentkezést igénylő rendszerek is meglehetősen elterjedtek. A leszállások alkalmával itt semmiféle jegyérvényesítési procedúrára nincs szükség, ennek következtében a járművön eltöltött idő és a megtett távolság alapján történő díjszámítás nem alkalmazható. Ilyen rendszerek esetében a szolgáltató által előre meghatározott időalapú díjtételek valamelyike kerül elszámolásra.
Walk in/walk out (WIWO): Az előzőeknél innovatívabb megoldás, bár alapötlete nagyban hasonlít a CICO rendszerekéhez. Az utazások díja automatikusan áll elő a megtett távolság és a járműveken töltött idő alapján. A rendszer alapja a felhasználó, illetve a felhasználónál lévő azonosító eszköz mozgása. Az utasoknak tehát nem kell semmiféle műveletet végezni ahhoz, hogy az utazásuk regisztrálva legyen a rendszerben. A rendszer így hatékonyabban működik, hiszen automatikusan számítja az utazás díját. Az automatikus működés a jármű minden egyes ajtajánál két antennát igényel, melyek képesek arra, hogy felülírják a kártya státuszát. A két antenna azonos frekvencián sugároz. Az egyik antenna az állomás azonosítóját továbbítja, a másik pedig a pontos időt és a járműazonosítót. [2],[4]
11
2. ábra WIWO rendszer sematikus ábrája (forrás:[2])
A rendszer sematikus ábrája a 2. ábrán látható. A felszállásnál a jeleket AB sorrendben kapja a kártya, leszállásnál pont fordítva, ebből tehát egyértelműen megállapítható, hogy az illető épp fel- vagy leszállást végez. A kommunikáció egyik oldalát már ismerjük, azonban a kártyának is kell adatokat közölnie az antennákkal. A kártya átadja a státuszát és az azonosítóját az antennáknak, ahonnan az adatok a fedélzeti adatbázisba kerülnek. Ezen adatbázis adatait időnként a központi adatbázisok felé továbbítják. Ha az adattovábbítás sikeresen véget ért, akkor egy visszaigazoló jel újra passziválja a kártyát. A kártya képes akár 200 utazás adatait tárolni, amelyek segítségével hibásnak vélt számlázás esetén egyértelműen megállapíthatók a ténylegesen megtett utazások. Az előző rendszerrel ellentétben itt nincs pénz a kártyákon, hanem hó végi számlázás történik. A bliccelés lehetősége fennáll, ha a felhasználó a két (A és B) mező között marad (zsúfoltság a járművön), ezért a két mező helye az ajtó nyitásakor és zárásakor felcserélődik. A díjszámítás metodikája CICO rendszerekéhez hasonló. [2],[4]
Be In/Be Out (BIBO): Ennek a rendszernek két változata valósult meg a gyakorlatban, melyet két példán keresztül mutatok be. Az egyik Genovából, a másik pedig Baselből származik. A genovai rendszer a WIWO rendszerhez hasonlóan működik. Ugyanúgy megjelenik a két alacsonyfrekvenciás mező (A és B), de működik egy magas frekvenciás mező is, amit a járművön található leolvasó készülékek hoznak létre, és a jármű egészére kiterjed (3. ábra). Ebben az esetben tehát, a magas frekvenciás jel a járműben található kártyák információit kérdezi le, szabályos időközönként. Az ’A’ és ’B’ jelű mezők arra szolgálnak, hogy megkülönböztessék a felhasználókat aszerint, hogy a járművön áll, vagy csak elhalad mellette.
12
3. ábra A BIBO rendszer egy lehetséges megvalósítása (forrás:[2])
A baseli rendszer struktúrájában sokkal szembetűnőbb különbségeket fedezhetünk fel. Ebben az esetben a három különböző mező helyett kettő található (4. ábra). Egy aktiválási terület, és egy másik, ahol a kártyák adatait a megállók között leolvassák. A BIBO rendszerekben használt eszközök hasonlatosak a WIWO rendszerekben használtakhoz. A kártyáknak beágyazott energiaforrásuk van, amely segítségével passzívból aktív állapotba kerülhetnek.
4. ábra A BIBO rendszer egy másik lehetséges megvalósítása (forrás:[2])
A BIBO rendszerek legfőbb előnye az, hogy a működéshez használt algoritmus jóval egyszerűbb, és a szükséges infrastruktúra kiépítése is olcsóbb, a WIWO rendszer költségeihez képest. A működési elvből kifolyólag csökkenteni lehet az infrastruktúrát járművenként egy antennára is akár. Negatívumok a kártya energia ellátásánál léphetnek fel. A rendszer által előállított adatok nagyon hasonlóak a CICO rendszerek adataihoz, így itt is fennállnak a korábban ismertetett díjszámítási eljárások lehetőségei. [2],[4]
13
Az egyes rendszerek által elérhető információkat az 1. táblázat tartalmazza. 1. táblázat Az elektronikus jegyrendszerek által szolgáltatott adatok Működés
Viszonylat
Felszállás helye
CI
elérhető
elérhető
CICO
elérhető
elérhető
WIWO
elérhető
elérhető
BIBO
elérhető
elérhető
Utazási lánc
Hely azonosítás alapja
nem érhető el
megállóhely
elérhető
megállóhely
elérhető
elérhető
megállóhely
elérhető
elérhető
megállóköz
Leszállás helye átszálláskor állapítható meg elérhető
I.3. A Transmodel szabvány
A közlekedési szolgáltatók fő célja a hatékony működés, illetve a közlekedési rendszerrel kapcsolatos megbízható információk elérése. A felsorolt célok elérésének kulcsa az integrált szemléletmód, vagyis, hogy a háttéralkalmazásoknak együtt kell működniük. Adatok keletkeznek különböző területeken, melyeket aztán fel kell dolgozni, de a keletkezés és a feldolgozás helye nem feltétlenül egyezik meg. Annak érdekében, hogy a rendszerek átjárhatóak legyenek, együttműködésre legyenek képesek, a rendszerek hátterét szabványosítani szükséges. Ezért kezdődött meg a Transmodel szabvány kifejlesztése (CEN TC278 vagy EN12896), mely egy referencia adatmodell a közösségi közlekedés számára[6]. A szabvány átfogó fogalmi modellt biztosít, ami többek között a következő területekre fogalmaz meg előírásokat: utastájékoztatási rendszerek, közlekedési rendszer infrastruktúra, menetrend, díjszabás, díjtermék érvényesítés.[5] A szabvány meghatározza a tömegközlekedési szolgáltatók által alkalmazott támogató rendszerek alapadatainak struktúráját, adatigényét. Az alapadatok meghatározásán kívül szükség van az adatok közötti kapcsolatok meghatározására is, méghozzá a vállalat működési modelljének megfelelően. A Transmodel referencia adatmodell különösen alkalmas ilyen jellegű feladatok megoldására. Az adat architektúra nyitott is lehet, így a különböző fejlesztésű szoftverek között is kapcsolatot lehet teremteni, ezáltal lehetővé válik az adatok továbbítása a közlekedési vállalat különböző részlegei felé. A
14
közlekedési vállalatok akkor is tudják alkalmazni a szabványt, ha régebbi rendszereik más struktúrájú adatbázisokat használnak. A szabvány moduláris felépítésű, és a modularitást a tervezendő rendszerek számára is előírja. A modularitás nagy előnye, hogy a rendszer hibáit ki lehet javítani anélkül, hogy a rendszert leállítsák. [5] A referencia adatmodell elsődleges célja, hogy jól definiált, strukturált formában dokumentálja a közlekedési vállalat információ igényeit. Alapot szolgáltat az adatbázis fizikai és logikai felépítéséhez, emellett támogatja a tömegközlekedési vállalatok által használt szoftverek fejlesztését, ezek integrálását. A szabvány leírása a következő részekből áll össze:
Fődokumentum
Entitás definíció
Konzisztencia és integritás feltételek
Adatmodellezési útmutató
Funkcionális modell
A fődokumentum meghatározza azokat az alapadatokat, amelyek az adatbázis felépítéséhez kellenek. A szabvány megkülönbözteti a statikus, előre definiált adatokat és a valós idejű adatokat. Az alap adatok a következőek:
Hálózatleírás,
Verziómenedzsment.
Az alapelemek meghatározása mellett a funkcionális területek adatigényének meghatározása is sorra kerül. A dokumentum sorra veszi az egyes modulokat, bemutatja azok működését, meghatározza a modul felépítéséhez használandó entitásokat és a köztük fennálló kapcsolatokat. A szabványban tárgyalásra kerülő funkcionális területek[5]:
Taktikai tervezés,
Személyzet beosztás,
Üzemeltetési felügyelet és vezérlés,
15
Utas információ,
Viteldíj beszedés,
Menedzsment információ és statisztika.
I.3.1. Hálózatleírás és verzió menedzsment A referencia adatmodell e modulja szolgál arra, hogy leírja az alaphálózatot, definiálja azt a területet, ahol a szolgáltató működik. A hálózat leírás további rétegekre osztható, a rétegek egymásra épülnek. A legalsó réteg az alaphálózat rétege, mely a valós utcahálózatot írja le. A hálózatot háromféle adattípusból lehet felépíteni, ezek a pont, vonal, és a sokszög. Az alaphálózatra ültethetők rá a megállóhelyek (pont típusú réteg), a járművek által bejárt útvonalak, a viszonylatok (vonal típusú réteg) és a rezsi futások útvonala. Ahhoz, hogy a geoadatbázis megfelelően működjön, a kapcsolatokat ezek között a táblák között is meg kell határozni. (pl.: meg kell határozni, hogy adott utcában melyik viszonylatok járnak, és a viszonylatokhoz kapcsolni kell megállókat is.) Az alaphálózat leírására a GDF (Geographic Data File)[5] szabvány ad útmutatást. Az adatok összekapcsolhatóak térinformatikai szoftverekkel, amelyek a feldolgozást nagyban megkönnyítik. A verzió menedzsment modul, a szolgáltatás térbeni és időbeni tulajdonságaival kapcsolatos (viszonylat hálózat, menetrend) változások nyilvántartásáért felelős. [5],[6] I.3.2. Taktikai tervezés Az adatmodell taktikai tervezésről szóló része határozza meg azokat az információkat, amelyek a járműves utazások felvételéhez szükségesek, amiket a szolgáltatás részeként biztosítania kell a szolgáltatónak, valamint a járművek és a járművezetők beosztásához szükségesek. A szolgáltatás biztosítása nem csak abból áll, hogy a járművek egyik végállomásról a másikra viszik az utasokat, hanem a szolgálati utakat is ütemezni kell. A szolgálati utak alatt a rezsifutást értjük, ekkor a járművek nem szállítanak utasokat, a menet egy részén vagy egészén. Ezek tipikusan a garázsba való beállást, illetve a kiállást jelentik. A modell az egyes járatokat nap típusokhoz rendeli hozzá, nem konkrét dátumokhoz, ami jelentősen egyszerűsíti a beosztást, és az adatbázis is könnyebben kezelhető így. A nap típus olyan besorolása adott napnak, melyben azonos szolgáltatás nyújt a vállalat (pl.: munkanap tanév tartama alatt). Ezek mellett még sok más adattípus
16
is van ebben a részben, melyek az üzemidőt, fordulóidőket, várakozási időket, ütemezett átszállásokat írják le. A modell a sorrendi jegyzékezés folyamatához szükséges adatkövetelményt is meghatározza. A sorrendi jegyzékezés olyan folyamat, amikor a járművezetők feladatait sorba rendezik azért, hogy a munkaelosztás kedvezőbb legyen és a törvényi előírásoknak is megfeleljen. [5],[6] I.3.3. Személyzeti beosztás A referencia modell kezeli a személyzet beosztást és a járművezető menedzsment információ igényeit is két fő feladat tekintetében:
fizikai járművezetők rendelése, a logikai járművezetők helyébe járművezetők teljesítményének feljegyzése.
Az első feladatban a járművezetőket kiosztják az üzemeltetési napra, amit az egész tervezési időszakra vonatkozóan elkészítenek. Ezután a tervet akkor kell módosítani, ha a munkatársak valamelyike hiányzik, személyes preferenciák úgy kívánják, vagy az irányító személyzet szeretné. Rövid távú változtatások is elképzelhetők nem tervezett hiányzások esetében. A
valós
járművezetői
tevékenységek
dokumentációját
a
járművezető
teljesítményirányításnál használják, hogy a valós és terv adatokat összehasonlíthassák. Az itt nyilvántartott információk alapján történik a járművezetők bérének kiszámítása is. [5],[6] I.3.4. Üzemeltetési felügyelet és vezérlés Az üzemeltetési felügyelet és vezérlés modul ölel fel minden olyan tevékenységet, amik a közlekedési folyamat részei. Minden üzemeltetési nap beszerzési alapját termelési tervnek nevezik, és minden rendelkezésre álló forrás tervezett munkájából állnak össze. A
közlekedési
irányítási
folyamat
feltételezi,
hogy
a
rendszer
megfelelő
rendszerességgel érzékeli a közlekedési rendszerben szereplő objektumokat. Ennek segítségével a valós idejű adatok összehasonlíthatók az adatbázisban letárolt statikus adatokkal. A valós idejű adatok beérkezéséért a városokban kiépített AVM, vagy GPS helymeghatározó technológiával működő rendszerek felelnek. [5],[6]
17
I.3.5. Utasinformáció A referencia adatmodell utasinformációs résszel is rendelkezik. Ez a modul, nem az üzemeltető oldaláról közelíti meg az adatokat, hanem az utasoknak szolgáltatott, tájékoztatás céljára továbbadott adatokkal foglalkozik. A szabvány meghatározza az adatoknak azon körét, melyekkel az utasokat kell ellátni a valós és a tervezett szolgáltatásról, és azokat is, melyek a szolgáltatásban bekövetkező változásokkal kapcsolatosak. Ez a modul tehát túlmutat a hagyományos menetrendi információkon, de a dinamikus adatokat nem tudja figyelemmel kísérni. Az utasinformációs rendszer alapadatai a referencia adatmodellen belül szét vannak szórva. [5],[6] I.3.6. Viteldíjbeszedés A viteldíjbeszedéssel foglalkozó modul, a lehető legáltalánosabban próbálja leírni a szükséges információkat és azok kapcsolatát. Erre amiatt van szükség, mert a viteldíjak megszabásának módja, a büntetések mértékének meghatározása, illetve érvényesítési műveletek az egyes szolgáltatóknál nagyon nagy különbségeket mutathatnak. A különbségek nem feltétlen országok között vannak hanem, az adott ország különböző szolgáltatói között is akár. Ennek a komplexitásnak tükrében az adatmodell az absztrakt, általános koncepciókra összpontosít, melyek a jegyrendszerek magvát adják. A referencia modell az alapkoncepciók leírását a hozzáférési jogok definiálásával kezdi, melyek
vonatkozhatnak
immateriális
díjtermékekre,
melyek
valamilyen
úti
dokumentumokhoz vannak kötve, melyek csomagokat alkotva kerülnek eladásra. Ellenőrzéseket lehet kötni az említett úti dokumentumokhoz, hogy azokat érvényesíteni lehessen. Árkomponensek is köthetőek bizonyos hozzáférési jogokhoz (pl. nyugdíjas), akciós csomagokhoz. [5],[6] I.3.7 Menedzsment információ és statisztika Az adatmodell menedzsment információkra és statisztikai adatokra vonatkozó része, további adatleírásokat biztosít, melyek az előző részek adatelemeitől függetlenül szükségesek lehetnek. A statisztikai információk minden a rendszerben található objektumról
előállíthatóak.
Számos
információ
előállítható
az
üzemeltetéssel
kapcsolatosan, a menetrendből, illetve a tény és terv adatokból: [5],[6]
események, feljegyzések melyek leírják a valós útvonalakat és az ezekből számított szolgáltatási teljesítményt,
18
a tervezett változások jelenlegi státusza, ezek hatásai a minőségi szolgáltatásra nézve, a szolgáltatások kihasználtsági foka.
I.3.8. A szabvány további részei A szabvány megértéséhez szükséges a további kiegészítő dokumentumok vizsgálata is. A fődokumentum leírja az egyes modell-részek működését és szerepét valamint felvázolja, az adott rész adatszükségleteit, az adatok közötti kapcsolatokat, mindezt egy relációs adatbázisban megjelenítve. A fődokumentum az entitások egymáshoz való viszonyán kívül nem mutat többet. [6] Az entitások pontos definícióját az „A” jelű függelékből érthetjük meg. A függelék, először megnevezi az ismertetésre kerülő adattáblát, majd egy rövid leírást közöl róla. Meghatározza, hogy melyik másik objektum halmazába tartozik, mi azonosítja. A különböző entitások leírása az entitásokhoz tartozó attribútumok leírásával zárul. Az egyes attribútumok használata lehet kötelező jellegű, vagy opcionális[7]. A szabvány „B1” jelű függeléke a referencia adatbázis konzisztenciájának és integritásának fenntartása végett készült el. Egy adatbázis akkor működik megfelelően, ha az adatbázison belül nincsenek duplikációk, vagyis redundáns adatok. Ez hibalehetőséget hordoz magában, hiszen ha valamelyik alapadatot meg kell változtatni, akkor az összes helyen meg kell ezt tenni. Ha ez nem történik meg, akkor az adatok ellentmondásba kerülhetnek, és az adatokat feldolgozó függvények a rossz adatokra hivatkozhatnak. Ennek elkerülése végett hozott feltételeket közli a függelék, illetve az adatintegritás megtartása érdekében az egyes entitásokhoz leírására és azonosítására korlátozásokat ír elő. [8] A szabvány értelmezéséhez és felhasználásához szükséges, hogy az olvasó némi adatbáziskezelési ismeretek birtokában legyen. A „B2” jelű kiegészítés egy ilyen oktató jellegű kiegészítés. A dokumentum szinte az alapoktól kezdve ismerteti meg a felhasználóval a referencia modell felépítésének sémáját. A dokumentum definiálja a fogalmi modell fogalmát, a logikai modell fogalmát, valamint az adattáblák fogalmát is. Ezek után sorra veszi a referencia adatmodellben szereplő kapcsolat típusokat, azokat a való életből vett példákon keresztül mutatja be. A dokumentum beszámol még az adatbázis tervezés fontosságáról, és azok optimalizálásáról is. A dokumentumban
19
megjelennek még az egyes adattípusokhoz rendelt altípusok is, zárásként a táblák közötti kapcsolatok kerülnek részletesebb bemutatásra. [9] A szabvány „B3” jelzésű függeléke a funkcionális modell leírásával foglalkozik. Az előző részek a szolgáltató különböző tevékenységeinek ellátásához szükséges adatokat definiálták, de most a tevékenységek szempontjából mutatja be a modellt. A leírás rávilágít arra, hogy az egyes tevékenységek ellátása a különböző vállalatoknál nagyon különböző lehet, ami a szükséges adatokat befolyásolhatja. A referencia adatmodell felhasználása tehát sokkal inkább lehetséges, mint az ebben a dokumentumban leírt funkcionális modell. Ennél fogva a funkcionális modell inkább támogató jelleggel került az adatmodell mellé. A dokumentum azonosítja a szolgáltató tevékenységi területeit (pl: utasinformáció, viteldíjbeszedés), majd az egyes területekhez tartozó feladatokat osztályozza aszerint, hogy azok a stratégiai tervezéshez, taktikai tervezéshez, működtetéshez vagy a statisztikai adatokhoz tartoznak-e (5. ábra). Az egyes területekről azután rövid leírást készít, és meghatározza, hogy a terület kimenő adatai milyen tervezési folyamatokhoz járulhatnak hozzá. [10]
5. ábra A szabvány által lefedett funkciók (forrás: [10])
20
Az utolsó, „C” jelű kiegészítés a szabvánnyal kapcsolatos módosításokat tárja az olvasó elé. A kiegészítés rávilágít, hogy a legfőbb változások az előző verzióhoz viszonyítva csak addicionális jelleggel bírnak, melyeket a szabvánnyal szemben támasztott követelmények miatt volt szükséges beiktatni. Az elektronikus jegyrendszerek hazai bevezetése során, ugyancsak a TRANSMODEL szabvány rendelkezései az irányadóak, ahogy az már 2009-ben, az ROP keretében kiírt „Közösségi közlekedés fejlesztése” című projektekben volt. [5]
21
II. A jegyrendszerek bevezetésére vonatkozó hazai törekvések, külföldi példák
Egyre nagyobb szükség van arra, hogy a tömegközlekedést minél korszerűbb eszközpark szolgálja ki, könnyen elérhető legyen, használata minél egyszerűbb és átláthatóbb legyen mindenki számára. Fontos az is, hogy a közösségi közlekedésben alkalmazott
díjrendszer
lehetővé
tegye
a
teljesítményarányos
díjfizetést,
alkalmazkodjon a felhasználói igényekhez. A jól működő díjrendszer az egyik kulcsa, a közösségi közlekedés térhódításának, ennek azonban az elektronikus jegyrendszerek bevezetése az alapja. A hazai bevezetés ötlete viszonylag régen, 2002-ben megfogalmazódott. Az akkori Gazdasági és Közlekedési Minisztérium, és az Informatikai és Hírközlési Minisztérium összefogása révén megkezdett munka célja egy, az EU előírásoknak megfelelő országos kártyakövetelmény rendszer kidolgozása volt, mely biztosítja a helyi, környéki, helyközi közlekedésbeli használatot, valamint a parkolásban való alkalmazást is. A kártya rendszer neve Elektra Hungária. A rendszer jól átgondolt rendszerstruktúrát tartalmaz, de gyakorlati bevezetése nem valószínű. [31] A fejezetben a hazai bevezetéssel kapcsolatos újabb törekvéseket és három külföldi példát mutatok be részletesen.
II.1. A budapesti rendszer
II.1.1. A budapesti bevezetés első lépései, rendszer követelmények A Budapesti Közlekedési Központ (BKK) 2011-ben készített egy tanulmányt, mely sorra veszi a jelenlegi díjrendszer jellemzőit, hibáit, meghatározza az elektronikus jegyrendszerrel szemben támasztott követelményeket, majd számba veszi a rendszerek lehetséges felépítéseit. A különböző rendszerek összehasonlítása után a tanulmány készítői megállapítják a javasolt rendszer főbb tulajdonságait. Az előzetes tervek szerint a fővárosban 2014-ben kezdődik meg az új elektronikus jegyrendszer bevezetése.
22
A
tervezett
elektronikus
jegyrendszerrel
szemben
támasztott
legfontosabb
követelmények: [11]
Értékesítési csatornák számának növelése. Meg kell teremteni az internetes, távértékesítés, illetve távkiszolgálási rendszert és az érintés nélküli bankkártyák használatának lehetőségét.
Az értéknövelt szolgáltatások nyújtása. Ezek a szolgáltatások, kényelmes ügyintézést,
illetve
többlet
információkat
is
biztosítanak.
Értéknövelt
szolgáltatás lehet, ha az utasnak nem kell minden hónapban magának meghosszabbítania a bérletét, hanem az automatikusan megtörténik, utazásokról szóló elszámolások kiállítása, személyre szabott információk nyújtása.
A közlekedési rendszer használatát leíró adatok gyűjtése. Az új rendszer segítségével a tervezéshez felhasználható adatok birtokába kerül a szolgáltató. Az utazási adatok mellett az eladott díjtermékekre vonatkozó információk is pontosabbak lesznek, mely jó alapot szolgáltat arra az esetre, ha a díjstruktúrát a felhasználói igényekhez akarják igazítani, vagy az adott rendszerre vonatkozó optimumot szeretnék megállapítani.
A hagyományos bérletek, jegyek megtartása mellett, innovatív díjtételek bevezetésének lehetősége. A rendszer alapvetően három csoportra fókuszál: a tömegközlekedést mindennap használók, eseti felhasználók, turisták. A jegyrendszernek átláthatónak kell lennie, illetve kezelnie kell az idő alapú jegyeket, ami lehetővé teszi a többszöri átszállást ugyanazzal a jeggyel.
A
napi
díjplafon
bevezetésének
lehetősége.
Bizonyos
számú
jegy
megvásárlása után a rendszer, automatikusan napijegyként könyveli el a vásárlásokat (plusz költség nélkül), így az utas mindig a számára legkedvezőbb árat fizeti meg.
Az utasok automatikus beléptetése, jogosulatlan felhasználók kiszűrése. A jegyrendszerek bevezetésével lehetővé válik a zárt peronos utazási módok esetén a beléptetés automatizálása. A beléptetés kulcsa a felhasználónál lévő utasmédia lesz. A metróállomásokon dolgozó ellenőrök így átcsoportosíthatóak lesznek a felszíni közlekedés járműveire. A buszokon a járművezető is bevonható az ellenőrzés folyamatába, itt az első ajtós felszállás bevezetése lesz szükséges.
23
A kedvezményekre való jogosultság kezelése, a hamisításból eredő károk visszaszorítása.
A
jelenlegi
papíralapú
jegyek
viszonylag
könnyen
hamisíthatóak. Az elektronikus jegyrendszerek által alkalmazott informatikai technológia erre egy jó megoldás az adat titkosítási eljárásokkal kiegészülve. A bevezetendő rendszernek fennakadás nélkül kezelnie kell a kedvezményes díjtételeket is. II.1.2. Informatikai háttér A tanulmány kimondja, hogy a vizsgált rendszerek (smart kártya, mobiltelefonos, mágnes csíkos, szerver alapú) egyike sem felel meg önmagában azoknak a követelménynek, amiket a rendszerrel szemben támasztott a BKK. A megfelelő rendszer tehát a vizsgált rendszerek ötvözetéből áll majd elő. Az ötvözendő rendszereknek architektúrájukban a lehető legközelebb kell állniuk, és szinte teljes mértékben integrálhatónak kell lenniük. A feltételeknek a központi adattárolás elvén működő (szerveralapú), érintésmentes kártyával és/vagy az érintésmentes bankkártyával működő rendszer felel meg. [11] A rendszer informatikai felépítése:
Központi rendszer o ügyfél adatbázis o tarifa-számító modul o elszámolási modul
Utasmédiák
Önkiszolgáló automaták
Érvényesítő készülékek
Beléptető kapuk
Ellenőri készülékek
Internetes önkiszolgáló felület
Mobiltelefonos alkalmazás
Vezetékes mobilhálózati kommunikáció
II.1.3. Utasmédia típusok A tanulmány által javasolt utasmédiákat a következő csoportokba sorolhatjuk [11]:
24
BKK kártya: A BKK által kibocsájtott kártya egyedi sorszámmal ellátott utasmédia lesz. A BKK kártyák segítségével több fajta díjtermék lesz igénybe vehető. A kártyán több fajta számla attribútuma fog megjelenni, emiatt az aktuális utaznál érvényes számla lesz terhelve, de mindig a bérlet típusú termékek lesznek előtérbe helyezve. A BKK kártyáknak három fő típusa lesz megkülönböztetve: o Teljesárú díjtermékek igénybevételére jogosító, fényképpel, névvel megszemélyesített kártya, o Kedvezményes díjtermékek igénybevételére jogosító megszemélyesített BKK kártya, o Anonim BKK kártya, amivel a díjtermékeknek csak korlátozott (pl.: napi jegy, heti jegy) körét lehet igénybe venni.
Harmadik fél által kibocsájtott kártya: A rendszerben lehetőség nyílik majd a harmadik fél (akár különböző szolgáltatók) által kibocsájtott kártyák használatára is, ami már felveti a tarifa közösség, illetve egy országos rendszer kiépítésének gondolatát is. o NEK kártya: A Nemzeti Egységes Kártya rendszerben kibocsátott kártyák helyettesíthetik a BKK kártyákat, illetve alkalmasak lesznek a személyre szóló kedvezmények igazolására is. Az első használat előtt a kártyát be kell majd jegyezni a BKK rendszerébe. A NEK kártyához PIA és PAYG termékek meghatározott körét lehet majd hozzá rendelni, a díjtermékek kifizetése bankkártyával, vagy a BKK rendszerében nyilvántartott egyenleg segítségével lesz lehetséges. A kedvezményre való
jogosultságok
ellenőrzése,
a
központi
rendszerben
lévő
nyilvántartás automatikus vizsgálatával fog megtörténni. o Érintés nélküli bankkártya: Harmadik fél által kibocsátott kártyának számít a bankok által kibocsátott érintés nélküli bankkártya is. A kártya valószínűleg csak a PAYG termékek megvásárlására lesz alkalmas. Ezek a kártyák nem igényelnek majd a BKK rendszerében történő regisztrációt.
Smart Paper: Az alkalmi utasoknak lehetőségük lesz Smart Paper típusú jegyek megvásárlására. A termék tulajdonképpen a mai vonaljegyek
25
megfelelője lesz, azonban a kártya érvényességi idején belül korlátlan átszállásra fog jogosítani, mely ez alatt az idő alatt átruházható lesz. Az érvényességi idő lejárta után, nem lehet vele utazni, de újra tölteni sem lehet majd.
NFC technológiát támogató mobiltelefon: Az NFC mobiltelefonok lehetnek az utasmédia 4. fajtája. A technológia még csak mostanában kezd elterjedni. Egyenlőre nem meghatározható az, hogy ez a média milyen díjtételek lesz képes kezelni. [11]
II.1.4. Díjfizetési módok A rendszerben két fajta díjtételt különböztetünk meg:
Előre fizetett: Payed in Advance. Ezek a díjtermékek jellemzően a bérletek.
Utólag fizetett: Pay as You Go. Ilyen típusúak a kártyával érvényesíthető jegyek. [11]
II.1.5. Regisztráció menete Majdnem minden esetben regisztráció előzi meg a kártya kézhezvételét. Az utasnak először a személyes adatairól kell nyilatkoznia, igazolnia kell a kedvezményekre való jogosultságot, esetleg fényképet kell mellékelnie. A kártya kiváltásáért a felhasználónak meg kell fizetnie a kártya kiváltási díjat, anonim kártya esetén a kártya letéti díjat is. A kártyaregisztráció során az ügyfélszámára számlanyitás történik. Ezen a számlán tárolják a későbbiekben megvásárolt bérleteket, illetve a számlára befizetett összeget. Ez a művelet elvégezhető lesz az ügyfélszolgálatokon, illetve az internetes felületen is. A megszemélyesített kártyákat csak később személyesen, posta útján lehet majd átvenni. Az átvétel után a kártya még nem lesz azonnal használható, hanem egy aktiválási procedúrán kell majd átesnie. A kártya eltűnése esetén a felhasználói kártya, a forgalomban lévő bankkártyákhoz hasonlóan letiltható lesz. A NEK kártyák használatba vétele az előzőekhez hasonlóan fog történni. A kártyák opcionálisan regisztrálhatóak lesznek a BKK internetes felületén, melynek segítségével a felhasználó plusz szolgáltatásokat fog tudni igénybe venni.
26
Az érintkezés nélküli bankkártyák esetében nincs szükség semmiféle előzetes regisztrációra. Itt közvetlenül a bankkártyához kapcsolt folyószámláról vonódik le az összeg. A Smart Paper-ek esetében a felhasználó ugyanúgy utazhat, mint a régi vonaljegy esetében. Egy utazásra előkészített kártyát kap az utas, melyet érvényesíteni kell és a termék érvényességének lejártával vissza lehet juttatni a BKK-hoz, vagy ki lehet dobni. Az anonim kártyák esetében már más a helyzet. A kártyákat a vásárlás pillanatában rendelik össze az utas által kiválasztott díjtermékekkel. Az adminisztrációs feladatok ebben a feladatban jelentősen leegyszerűsödnek, de a gyors adatkommunikáció elengedhetetlen lesz ebben az esetben. [11] II.1.6. Használat Az utazások megkezdése előtt fel kell tölteni a PAYG számlát, vagy PIA terméket kell vásárolni. A BKK és a NEK kártyák esetében a bérletek és egyéb előre fizetendő termékek az értékesítési csatornák bármelyikén megvásárolhatóak a feltölteni kívánt kártyaszám megadásával. Az utólag fizetendő termékek akkor vásárolhatóak meg, ha megfelelő pénzmennyiség áll rendelkezésre a számlán, ekkor a kártyát egyszerűen csak a kijelölt olvasóhoz kell tartani, ami automatikusan levonja, a szolgáltatásért meghatározott összeget. Az érvényesítési folyamatok ismertetése előtt fontos megjegyezni, hogy a közlekedési hálózat nem lesz olyan értelemben zónákra osztva, mint London. Budapest egy zónaként fog megjelenni a rendszerben, a többi zóna a várost körülvevő gyűrűk lesznek. A különféle közlekedési módok szerint különböző lehet a jegyérvényesítés menete. Az érvényesítések szinte teljes mértékben meghatározzák, hogy a tranzakciók során keletkezett adatokból milyen többletinformációkat lehet majd a rendszerből kiszűrni. A zárt és nyílt peronokon többféleképpen is el lehet helyezni az érvényesítő készüléket. Ebből kifolyólag megkülönböztethető: [11]
Kapus be- és kiléptetés
Járműfedélzeti érvényesítés
Peronon történő érvényesítés
27
Jegyvizsgálói/ellenőri érvényesítés
Kapus be- és kiléptetés: A metró és földalatti hálózaton továbbra is a zárt peronos megoldást kívánja a BKK alkalmazni új, automatikus beléptető kapuk segítségével. A tanulmány alapjában véve csak a beléptetés szükségességét állapítja meg, a kiléptetést opcióként említi, és abban az esetben tartja szükségesnek, ha az utazás zónaátlépéssel jár. A check out abban az esetben lenne fontos, ha a PAYG termékek esetében lehetőség lenne a szakaszjegyek váltására, vagyis a kilométer alapú, megálló alapú díjazást is beiktatnák az új rendszerbe. A metró vonalak meghosszabbítása, HÉV-vel való összekötés esetén szintén szükségessé válna a kijelentkezés. Járműfedélzeti érvényesítés: A tanulmány megkülönbözteti az elsőajtós és az összajtós felszállást. Az elsőajtós felszállás esetén a felhasználók mindjárt a sofőr elé helyezett terminálon érvényesítik a kártyát. Ebben az esetben a sofőr ellenőriz, és ha a kártya nem érvényes, le is szállíthat. A zónahatárt nem átlépő utazásoknál elegendő lesz a beszálláskori bejelentkezés, azonban a másik zónába irányuló utazások esetén valahogyan meg kell határozni az utazás célját. Ez történhet a leszálláskori kijelentkezéssel, és történhet úgy, hogy a sofőr minden kártya esetében megkérdezi, és a terminálon rögzíti. Az utóbbi változat technikai feltételei jóval összetettebbek, és a művelet időigénye miatt sem javasolható. Az összajtós felszállás esetében minden ajtóhoz legalább egy működőképes kártyaolvasó berendezést kell telepíteni. Ebben az esetben csak a PAYG termék típussal utazó felhasználók lennének kötelesek érvényesíteni a kártyájukat, a PIA típusú termékek használói csak az alkalomszerű ellenőrzések során. A bejelentkezések menete teljes mértékben megegyezik a korábban ismertetettekkel. Abban az esetben, ha felhasználó nem rendelkezik érvényes jeggyel, akkor a leolvasó ezt visszajelzi, de a sofőr nem fogja tudni leszállítani, tehát az utas lelkiismeretére van bízva a döntés. Peronon történő jegyérvényesítés: A négy HÉV vonal esetében a tanulmány nem fogalmaz meg egy egységes koncepciót a vonalakon történő jegyérvényesítéssel kapcsolatosan, de a külföldön már megszokott Check In- Check Out elv látszik itt célra vezetőnek, mely a peronon elhelyezett érvényesítő készülékkel valósítható meg. A
28
rendszer bevezetése a vonalak és megállókialakítások különbözősége miatt további vizsgálatot igényel. Jegyvizsgálói/ellenőri érvényesítés: Az ismertetett érvényesítési módszerek miatt szükséges megtartani a szúrópróbaszerű ellenőrzéseket is. Ekkor az ellenőrök blokkolják a fedélzeti jegyérvényesítő készülékeket, és a kézi ellenőrző készülék segítségével leolvassák a kártyákat. A készülék alkalmas annak megállapítására, hogy a felhasználó érvényesítette-e a kártyáját, rendelkezik-e az utazáshoz szükséges díjtermékkel. Az ellenőrök készüléke az ellenőrzéshez szükséges információkat akár a központi adatbázisból, akár a fedélzeti adatbázisból is megkaphatja. A jogosulatlan felhasználókról lista készül, amit feldolgozva kiróhatóak a büntetések. [11] II.1.7. Értéknövelt szolgáltatások Értéknövelt szolgáltatásként említhetjük az elveszett kártyák letiltását, az értékesítési csatornák bővítését. A rendszer innovatív díjtételeket kínál majd, és az internetes felületen az utazásokkal kapcsolatos információkat, utazás nyilvántartást talál majd a felhasználó. II.1.8. Előnyök, hátrányok A rendszer média érvényesítési eljárásai utasbarátnak mondhatóak, megpróbálják a bliccelés lehetőségét minimálisra csökkenteni. Emiatt a tanulmány készítői a csak felszálláskori érvényesítést tartják a legtöbb esetben elfogadhatónak, az előzetes díjszabási séma is ezt a változatot támasztja alá. Egy ekkora városban talán tényleg ez tűnik reálisnak, de egy ilyen rendszer kiépítése esetén az utazási szokások megismerése nem lesz teljes körű, és csak hiányos adatokat fog tudni szolgáltatni. Díjbeszedésre
maradéktalanul
alkalmas
lesz
a
rendszer,
de
az
utasmédia
érvényesítéséből származó adatokat, csak nehézségek árán lehet majd felhasználni a közlekedési rendszer optimalizálásában. Véleményem szerint szükséges lenne olyan akciók, kedvezmények, esetleg kikérdezések elvégzése, melynek során az utazások végcélja is megismerhető lenne. Ekkor már valamennyivel teljesebb képet kaphatna a szolgáltató a rendszerben történő utazásokról, de szükséges volna olyan eljárások kidolgozása, ami a téves végcélok megadását szűrné ki (adattisztítás). [11]
29
II.2. Egyéb hazai törekvések
2011-ben, Szolnokon indult el a helyi közlekedési vállalatnál az „e-menetjegy” nevű rendszer tesztüzeme. A tesztüzem 2011. december 31-ig tartott, a rendszer első használói helyi lakosok voltak, elsősorban a helyi kismamák kapták meg a rendszer használatához szükséges kártyákat. [16] A rendszer nagyon hasonlóan működött, az előbb vázolt budapesti elképzelésekhez. A kártyára többféle díjtétel tölthető fel, a díjtételek vásárlása történhetett személyesen a jegypénztáraknál, valamint interneten is. Az internetes vásárlások esetén, a kártyát el kellett vinni a kijelölt helyre, és a kihelyezett termináloknál automatikusan rákerült a kártyára a befizetett összeg. Ennek fényében kijelenthető, hogy ennél a rendszernél nem beszélhetünk szerver alapúságról. A szerver alapú megvalósítás esetén a kártyát nem kell még külön feltölteni, hanem az adott kártyaleolvasó készülék veszi fel a szerverrel a kapcsolatot és ellenőrzi a szükséges összeg rendelkezésre állását. A rendszer a járműre való felszálláskor igényel jegyérvényesítést, leszálláskor érvényesítési műveletre nincs szükség. A kártyaolvasó viszonylag gyorsan dolgozik, de a kártya gyors elrántásakor, vagy a szükséges összeg hiányában hibajelzést ad, vizuális és akusztikus formában. A helyi tapasztalatok azt mutatták, hogy az utascsere folyamata meggyorsítható, de a tesztüzem alatt nem volt mindenkinek elsőre érhető a használata. A kártyaolvasókat az első ajtóhoz telepítették, ugyanis a nem mozgáskorlátozott utasok csak itt szállhatnak fel, így az is előfordulhat, hogy a középső ajtón felszálló utasok, nagy tömeg esetén egyáltalán nem is érvényesítik a kártyáikat. A tesztüzem nyilvánvalóan alkalmas volt arra a célra, hogy a lakosságot közelebb hozzák az elektronikus jegyrendszerek világához, de arról nem sikerült információt szereznem, hogy mennyire tudták felhasználni a keletkezett utazási adatokat a tervezéshez. Véleményem szerint a tesztüzem alatt keletkezett adatokat fel lehetne használni arra, hogy a kismamák, mint mozgásukban korlátozott személyek (babakocsi miatt) közlekedési szokásairól képet kapjunk. [16],[17]
30
II.3. Oyster card – Egyesült Királyság, London
II.3.1. Az Oyster card története A londoni elektronikus jegyrendszer 2003 júliusában került bevezetésre, a TfL (Transport for London) által. A rendszert először Londonban vezették be, majd a Londont magába foglaló Nagy-London tartományban is üzembe állt. Szinte minden londoni közösségi közlekedési módot a bevezetett elektronikus jeggyel, vagyis az Oyster card-dal lehet igénybe venni. Az igénybe vehető közlekedési módok a következőek: metró, busz, földalatti (DLR), elővárosi vasutak (London Overground), villamosok, néhány folyami hajó, és a legtöbb vasúti szolgáltatás a londoni viteldíj zónán belül. [26] A rendszer 2003-as bevezetése során a szolgáltatásoknak még csak korlátozott köre volt elérhető, de a további funkciók a bevezetést követő időszakokban folyamatosan léptek működésbe. 2012 júliusára már több mint 43 millió regisztrált felhasználója volt a rendszernek és a londoni utazások több, mint 80%-át az Oyster kártya használatával végezték. [18],Hiba! A hivatkozási forrás nem található. II.3.2. Informatikai háttér A rendszer talán legszembetűnőbb része maga az utasmédia, az Oyster kártya. A kártya egy kb. 80 mm hosszú plasztik kártya, ami RFID rendszerben működik. A kártya megfelel az ISO/IEC 14443 szabvány A és B típusának. A két típus ugyanazt az adatátviteli protokolt használja, fő különbség köztük, hogy a kódolási sémák mások. A kártyák akkor aktiválódnak, amikor a kártya belekerül az olvasó elektromos mezejébe. A rendszer ekkor kiolvassa kártyán található információkat, megállapítja, hogy engedélyezhető-e az utazás, és ha szükséges információt ír vissza a kártyára. Az információk olvasása során a személyes információk rejtve maradnak, melyről különböző titkosítási eljárások gondoskodnak. A rendszer aszinkron működésű, hiszen az aktuális számlaegyenleg, és az egyes díjtermékek érvényességi információi a kártyán kerülnek letárolásra. A központi adatbázis frissítése periodikusan történik.[1],[18],[25] II.3.3. Utasmédia típusok A londoni rendszer többféle utasmédia kezelésére képes. A használatban lévő kártyák között találhatóak megszemélyesített kártyák, nem megszemélyesített kártyák (6. ábra). 31
Ezektől a típusoktól elkülönül a turisták számára gyártott kártyatípus. A kártyák különböző díjtételek tárolására alkalmasak. A havi, vagy hosszabb időtartamra szóló bérletek, valamint a különféle kedvezmények csak a regisztrált kártyán tárolhatók. A heti jegyek, vonaljegyek bármelyik nem regisztrált kártya segítségével igénybe vehetők. [18]
6. ábra A londoni Oyster card (forrás: [18])
II.3.4. Díjfizetési módok A kártya egyenlegek feltöltése minden metróállomáson, és automatánál lehetséges (7. ábra). Internetes és telefonos kártyafeltöltésre is van mód, ekkor a feltöltés tényleges helyét előre ki kell választani.
7. ábra Kártyakiadó és feltöltő automaták Londonban (forrás: [23])
A kártyákon egyszerre háromféle bérlet tárolására van lehetőség. A londoni közlekedési hálózat zónákra van osztva, ez alól egyedül a busz kivétel. A bérletek csak abban a zónában érvényesek, amelyeket a kártyákon engedélyezik. Ha a felhasználó ezen zónákból, valamelyik másik zónába lép át, akkor a rendszer automatikusan a PAYG egyenlegről veszi le a megfelelő összeget. Természetesen, ha ilyen jellegű átlépés nem
32
történik, akkor ez a számla érintetlen marad. A metróra, földalattira, és az elővárosi vasútra váltott bérlet a buszokra is érvényes minden zónában, azonban a villamosokra, csak akkor, ha a megfelelő zónákra érvényes bérlettel rendelkezik a felhasználó. A kártya tartalmazhat előre váltott termékeket és funkcionálhat elektronikus pénztárcaként is. A PAYG módon fizetendő szolgáltatások igénybevételekor automatikusan, azonnal levonódik az összeg a kártyáról. Az utólagos fizetési mód nem mindegyik közlekedési mód esetében azonos, a felhasználóknak eltérő fizetési procedúrákat kell követniük. A kártyán maximum 90 £ tárolható, a számla természetesen újra tölthető az arra kijelölt állomásokon, automatáknál, és az internetes felhasználói felületen. Az egyes utazások megkezdésekor még nem lehet tudni, hogy az adott utazás mennyibe fog kerülni, ennél fogva a számla akár negatív értéket is mutathat. Az internetes felületen történő feltöltés nem teljesen aknázza ki az on-line vásárlás adta lehetőségeket. Ez annak köszönhető, hogy a rendszer igazából nem szerver alapú, hanem az utas számlájához tartozó információk a kártyán kerülnek letárolásra. Az internetes vásárlás esetén tehát meg lehet venni az utas számára megfelelő díjterméket, de aztán ki kell választani egy feltöltési pontot, ahol a felhasználó ténylegesen feltölti az előre meghatározott összeget vagy bérletet. A kiválasztható feltöltési pontok a fixen telepített automaták, eladási pontok, illetve megállók lehetnek. A díjtermék a befizetést követő napon vehető át. Amennyiben, a felhasználó nem tudja adott időre feltölteni a kártyáját, akkor a rendszer még 7 napig ott tartja a terméket. Ha a 7 nap elteltével sem kerül a felhasználói kártyára a díjtermék, akkor az összeget automatikusan visszatérítik a felhasználó számára. A bérletek esetében annyi változás történik, hogy a bérlet érvényességi idejének kezdete előtt 5 nappal már feltölthető az adott bérlet, az érvényességi idő kezdete után még 2 napig a kijelölt ponton marad a bérlet. Az átvétel elmaradása esetén a befizetett összeg, a következő 14 nap során fog a felhasználó számlájára visszaíródni. [18] II.3.5. A regisztráció menete A kártyák használatba vétele előtt a felhasználói médiákat regisztrálni kell, ami bármelyik metróállomáson, Oyster értékesítő irodában, illetve utazási információs irodában lehetséges. A személyes regisztráción kívül lehetőség van internetes és
33
telefonos regisztrációra is. A regisztráció során lehetőség van bármilyen díjtétel megvásárlására, és egyéb szolgáltatások megvásárlására is. A kártya regisztráció során letéti díj megfizetésére van szükség, amit a kártya visszaszolgáltatása esetén visszatérítenek. A regisztráció után minden féle díjtétel elérhető, hiányos regisztráció esetén a kártyán csak heti jegy és PAYG jegyeket lehet tárolni. [18] II.3.6. Használat A rendszer használata igen egyszerű. A felhasználók kártyáikat a kihelyezett sárga színű olvasókhoz érintik. A metró igénybevétele minden esetben be- és kijelentkezést igényel. A legtöbb állomáson automatikus beléptető rendszerrel biztosítják a gyalogos forgalom zavartalan áramlását (8. ábra), de néhány állomáson ez nem volt kivitelezhető. Ahol nem telepítettek automatikus kapukat, ott is kihelyezték az olvasókat, tehát itt az utasnak nem szabad elfelejtenie, hogy a kijelentkezést is végre kell hajtani. Az átszállásos utazások során nincs szükség újabb érvényesítésre, csak az utazás végeztével, a metró területének elhagyásakor. A metró területen tehát a klasszikus Check in-check out elv érvényesül, azonban ez nem így működik a buszokon. A buszokon csak egy felszálláskori jegyérvényesítésre van szükség. Ebben az esetben az utasok a sofőr melletti ajtón szállnak fel, és a fedélzeti terminálhoz kell a kártyájukat érinteni. A buszokon tehát nem a megtett út függvényében történik a díjbeszedés, hanem egy egységes díjrendszer érvényesül, ami tulajdonképpen a magyar gyakorlat vonaljegyének felel meg.
8. ábra Metró megállóban, buszon lévő fedélzeti terminálok (forrás: [23])
A villamosok esetén hasonló a módszer. Azok az utasok, akik a PAYG fizetési móddal utaznak, vagyis nincs a villamosokra érvényes bérletük, kötelesek a villamoson
34
ugyanúgy érvényesíteni a jegyüket, mint a buszokon. A bérlettel rendelkezőknek, ellentétben a buszos utazással, nem kell érvényesíteni a jegyüket. Ez pusztán azért van így, mert itt nincs lehetőség arra, hogy a villamos vezető ellenőrizze a jegyek érvényességét. Az Oyster kártyával igénybe lehet venni a folyami buszokat is. Ebben az esetben a hajónál lévő ellenőr kézi készüléke szolgál leolvasóként. [18],[23] II.3.7. Értéknövelt szolgáltatások A rendszer egyik értéknövelt szolgáltatása, hogy a PAYG számla automatikusan is feltölthető (Auto top up). Különböző értékhatárok választhatók ki, és ha a megnevezett összeg alá esik a számla, akkor a beléptető kapukhoz érintve a kártyát automatikusan feltölti azt a hozzá kapcsolt bankszámláról. A rendszerben életbe lépett az úgynevezett Fare capping nevezetű díjszámítási módszer, mely biztosítja, hogy bizonyos számú utazás után a rendszer automatikusan napi jegyet számláz ki, amivel aztán a jegy lejártáig korlátlan számú utazást lehet végezni. Az utazások az Oyster kártya használatával jóval olcsóbban kivitelezhetőek, mint a hagyományos jegyekkel. A rendszer képes kezelni a régebbi mágnescsíkos jegyeket is, a beléptető kapuknak külön erre a célra beépített olvasójuk is van. Az utazásokról és az aktuális egyenlegről jelentést lehet kérni a kihelyezett érintőképernyős jegyeladó automaták segítségével. Az adatok on-line lekérdezése is lehetséges, de csak azokról a tranzakciókról kaphat az utas információkat, melyek 8 hétnél nem régebbiek, és a kártya számlához való csatlakozása után történnek. A rendszer a büntetések automatikus kiszabására is fel van készítve. Az utasokat a maximális PAYG utazás árával sújtják, abban az esetben, ha a be- és ki jelentkezéssel valamilyen formában visszaélnek. Ha bebizonyosodik, hogy a büntetés kiszabása nem jogos, akkor az összeget visszatérítik az ügyfél számlájára.[18] II.3.8. Előnyök, hátrányok A rendszer gyűjti az utazásokról szóló adatokat, melyeket a TfL munkatársai feldolgoznak, és a begyűjtött adatok segítségével elemzik az utazási láncokat. A
35
rendszer megszemélyesített kártyákat is kezel, lehetőség van a kártya letiltásra is. Hasznos szolgáltatás az automatikus kártyafeltöltés lehetősége is. Gyengeségként említhető, hogy a zónarendszer nem egységes. Az egyes állomásokon, más helyeken kell az érvényesítési műveleteket elvégezni. A rendszer nem szerver alapú, emiatt számos előny nem aknázható ki.
II.4. OV-Chipkaart – Hollandia
II.4.1. Az OV-Chipkaart története Az OV-Chipkaart név a hollandiai közösségi közlekedésben bevezetett érintésmentes kártyarendszert és az arra épülő elektronikus jegyrendszert jelöli. A rendszer 2011. novemberében teljes egészében felváltotta a korábbi Strippenkaart nevű rendszert. A rendszer egész Hollandiában elterjedt, egyfajta közlekedési szövetség alakult ki. [27] II.4.2. Informatikai háttér A rendszer érintés nélküli, energiaforrás szempontjából passzív chipkártyákkal működik, a londoni rendszerhez hasonlóan RFID rendszerben. A megszemélyesített és a nem megszemélyesített kártyák MIFARE CLASSIC 4K típusok, melyek beépített processzorának viszonylag nagy a számítási kapacitása. Az eldobható kártyák esetében a MIFARE ULTRALIGHT típust alkalmazzák, mivel a végzett műveletek nem kívánják meg a bonyolultabb típus használatát. A megszemélyesített, és nem megszemélyesített kártyák képesek a titkosítási eljárásokkal való együttműködésre, de az eldobható kártyák nem. Az adatok áramlását tekintve, ugyanaz a folyamat zajlik le, mint a londoni rendszerben. [25],[29] II.4.3. Utasmédia típusok A rendszer először a papír alapú jegyek alternatívájaként jelent meg a közlekedésben, de mára teljes egészében leváltotta azt. A rendszer három féle kártyát különböztet meg. Ezek a következőek: [19]
Eldobható kártya: Az eldobható kártyák azok számára jelentenek megoldást, akik csak alkalomszerűen veszik igénybe a szolgáltatásokat, mivel adott napra
36
biztosít korlátlan utazási lehetőséget. A kártya keménypapírból készül nem feltölthető, nem funkcionál elektronikus pénztárcaként. A kártya bármelyik jegyárusítónál, automatánál, de a buszokon és a villamosokon is kiváltható.
Nem megszemélyesített kártya: A nem megszemélyesített kártyák azoknak az utasoknak jelentenek megoldást, akik valamivel rendszeres időközönként használják a rendszer szolgáltatásait, de nem naponta. A kártya többször is felhasználható, elektronikus pénztárca funkciója van és egy egyenlege, amiről a megtett kilométerek alapján kiszámított összeget vonja le a rendszer. A kártya átruházható, akár több felhasználó is használhatja, de nem azonos időben. A kártya csak a néhány napig érvényes bérletjegyeket képes kezelni, letéti díj ellenében kapható kézhez, de azonnal használható.
Megszemélyesített kártya: A megszemélyesített médián már a hosszabb érvényességi idővel rendelkező bérletjegyek is tárolhatók (9. ábra), ennél fogva nem lehet a kártyát átruházni. A kártya attribútumok között találhatunk olyanokat is, amelyek engedélyezésével a kedvezmények mértékét lehet beállítani.
9. ábra Megszemélyesített OV-Chipkaart (forrás: [19])
II.4.4. Díjfizetési módok A rendszer kezelni tudja a PAYG és a PIA típusú termékeket egyaránt. Az igénybe vett számlák közti váltás automatikusan történik. A londoni rendszerrel szemben fontos különbség, hogy a rendszer nem zónákra van osztva. Emiatt a rendszer mindig a megtett kilométerek alapján számítja ki az aktuálisan fizetendő összeget. A fizetendő díj két részből áll össze, az egyik egy mindig fellépő fix díj, a másik rész pedig az utazás hossza alapján kikalkulált díj. A kilométerre eső egységnyi díjak Hollandia egyes régióiban különbözőek lehetnek. A kedvezményre jogosultak (diákok, nyugdíjasok) ennek az összegnek csak a 70%-át fizetik meg. [19]
37
II.4.5. Regisztráció menete Regisztrációra csak a megszemélyesített kártyák igénylése esetén van szükség. A média több csatornán keresztül is igényelhető, személyesen a megállókban, interneten. Az igénylés folyamatát egy űrlap kitöltése képezi, amelyen a személyes adatok megadása mellett, fotó benyújtása, feltöltése is szükséges. A kártyára rákerül a felhasználó képe, valamint néhány személyes adat is. Kedvezmények a 4-11 év közötti gyermekeknek, diákok és a nyugdíjasok kártyáin engedélyezhetők. A megszemélyesített kártya csak a holland lakosok által igényelhetőek. A kártyát aztán később postán keresztül kézbesítik ki.[19],[20] II.4.6. Használat A rendszer klasszikus CICO elven működik, beszállásnál és leszállásnál is jegyérvényesítést igényel (10. ábra). A kijelentkezés minden olyan esetben szükséges, ha a felhasználó közlekedési módot vált, vagy befejezi az utazást. Tehát ez a rendszer nem az utazások teljes egészét rögzíti, hanem az utazások egyes viszonylatokra vonatkozó szeleteit. Például, ha valaki munkába igyekszik, de közben reggelit szeretne vásárolni magának, és ehhez két különböző viszonylatot is igénybe vesz, akkor a rendszer ezt két külön utazásnak fogja elkönyvelni.
10. ábra Kártyaolvasó készülékek, az OV-Chipkaart rendszerben (forrás: [27])
A rendszer felszálláskor megvizsgálja, hogy a felhasználó számláin van-e az adott utazásnak megfelelő bérlet, ha van, akkor nem von le semmit, ha nincs akkor itt is a PAYG számlát terheli a rendszer. A levont díj függ a választott közlekedési módtól, illetve a közlekedési szolgáltatótól. A felszálláskor a rendszer előleget helyez letétbe, és a leszálláskor számítódik ki a ténylegesen megfizetendő összeg. Amennyiben a felhasználó nem jelentkezik ki, akkor a rendszer automatikusan visszaélésnek könyveli
38
el az esetet és a fizetendő díj többszörösét rója az utasra. Előfordulhat olyan eset is, amikor a kijelentkezéshez felhasznált olvasó működésképtelen, ekkor az utas jelezheti a hibát a szolgáltató felé és a szolgáltató vissza fogja fizetni az összeget. A zárt peronos metró és elővárosi vasutak esetében a felhasználók automatikus beléptető kapukon keresztül jutnak az állomás területére. A kapuk akkor nyílnak ki, ha a kártyáról letétbe helyezhető az alapdíj. A legtöbb metró- és vasút állomáson ilyen megoldást alkalmaznak, de vannak olyan megállók, ahol az olvasók nem a kapukkal együtt kerültek kialakításra. Itt is köteles az utas érvényesíteni a kártyáját ki- és beszálláskor. A buszok esetében az első ajtón kell felszállni, és a sofőr mellett elhelyezett olvasókészüléket kell használni. A sofőr így láthatja, hogy az adott utas érvényes jeggyel rendelkezik-e. Az utazás végeztével ugyanúgy, ahogyan a metróban, leszálláskor is érvényesíteni kell kártyát, hogy a rendszer kiszámíthassa az utazás díját. A visszaélések visszaszorítása végett, az ellenőrök mobil eszközökkel ellenőrizhetik az utasok kártyáit. A készülék kijelzi a felszállás helyét és azt, ha a felhasználó idő előtt kijelentkezett. Ekkor az ellenőr jogosult a megfelelő büntetés kiszabására. Előfordulhat olyan eset is, amikor a felhasználó nem jelentkezik ki egy adott járműről, ekkor a letétbe helyezett összeg elveszik, és a következő utazásnál újabb letét elhelyezése válik szükségessé. Az érvényesítések során az olvasók minden esetben kijelzik az utazás során levont összeget és a rendelkezésre álló összeget. Amennyiben a felhasználó bérletjeggyel utazik, akkor az olvasó csak egy üdvözlő üzenetet ír ki. [19],[20] II.4.7. Értéknövelt szolgáltatások Értéknövelt szolgáltatások csak a megszemélyesített kártyákhoz köthetőek. A kártyák eltűnése esetén blokkolni lehet a hozzájuk kapcsolt számlákat. A PAYG számla kapcsolható a felhasználó bankszámlájához, és automatikusan tölthető. [19],[20] II.4.8. Előnyök, hátrányok A rendszer legfőbb pozitívuma, hogy a díjszámítás adaptív módon történik, vagyis teljesítményarányos. A rendszer kialakításának köszönhetően az utazási szokások
39
felmérhetőek. Elérhetőség szempontjából fontos, hogy bizonyos kártyák átruházhatóak. A felhasználó ellenőrizheti korábbi utazásait, a szolgáltató honlapján. A CICO rendszerek hátránya lehet, hogy a felhasználók bizonyos esetekben nem a megfelelő megállónál jelentkeznek ki, hanem a szükségesnél előbb. Ez visszaélés, hiszen a rendszer kevesebbet számláz ekkor. A CICO elv nem oldható meg minden közlekedési mód esetében. Probléma a rendszerrel kapcsolatosan, hogy a kijelentkezések alkalmával nem mindig a helyes összeget vonja le a rendszer, illetve a kedvezményeket nem mindig képes kezelni. A rendszer nem szerver alapú. A feltöltések indíthatók az interneten, de a kártyát a kiválasztott eszköznél kell feltölteni.
II.5. Chicago card – Egyesült Államok, Chicago
II.5.1. A Chicago card története A chicagói elektronikus jegyrendszer 1997-ben kezdett el működni. Akkoriban még a régebbi mágnes csíkkal ellátott jegyekkel váltották fel a hagyományos papírjegyeket. A mágnes csíkos jegyeket aztán kisebb lépésekben 2000-től kezdve váltotta le a smart kártyákat alkalmazó megoldás. 2004-re alakult ki a mostani rendszer, ami már az egyéni számlákhoz kapcsolódó érintésmentes kártyákat használja. [28] II.5.2. Informatikai háttér A kártyák azonos elven működnek az előző rendszerek által alkalmazott kártyákkal. A Chicago Card és a Chicago Card Plus között különbségként jelenik meg, hogy a „Plus” jelzésű
kártyák
szerver
alapú
működést
biztosítanak,
azok
a
felhasználó
bankszámlájához vannak kötve. A Chicago Card esetében a kártya tárolja az adatokat. [21]
40
II.5.3. Utasmédia típusok Két fajta kártya létezik:
Chicago Card - Kék kártya
Chicago Card Plus - Kék-arany kártya
Chicago Card igo – Zöld fehér kártya
A kék kártya elektronikus pénztárca funkcióval rendelkezik, amit a kijelölt helyszíneken (CTA feltöltő automatái) lehet feltölteni. A kártyák általában megszemélyesített kártyák, amelyeket elvesztés, lopás esetén a szolgáltató pótol. A kék-arany színű, „plus” kártyák a felhasználó bankszámlájához kapcsolódnak és a fizetendő díjakat onnan írják jóvá. Ezek a kártyák a kék kártyákkal ellentétben szolgálhatnak 30 napos bérletként is. A bérlet lejártakor a bérlet automatikusan feltöltődik a felhasználó számlájáról. E megoldás miatt, ezek a kártyák minden esetben megszemélyesített kártyák. Az igo kártya hozzáférést biztosít a helyi car-sharing rendszerhez is. [21] II.5.4. Díjfizetési módok A rendszer a korábban már említett PAYG és PIA típusú díjtételeket támogatja. A rendszer érdekessége, hogy a kártyák alapállapotában nem tölthető fel rájuk bérlet. Ez csak abban az esetben lehetséges, ha felhasználó a kártyájához plusz szolgáltatásként megveszi ezt a funkciót. Ekkor lehetővé válik a bérlettárolás a kártyán. A kártyán ekkor 30 napos bérletjegyek tárolása lehetséges, de a 30 mindig az adott hónap elejétől számítandó, tehát függetlenül attól, hogy a felhasználó mikor érvényesítette a kártyáját. Emiatt fordulhat elő az, hogy a 30 napos időszak alatt akár kétszer is érvényesíteni kell a kártyát. A kártyák elektronikus pénztárcaként is funkcionálhatnak. A PAYG számlán tárolható legkisebb összeg 5 cent, a maximálisan tárolható pedig 300 dollár. [21] II.5.5. A regisztráció menete A regisztráció menete nagymértékben megegyezik az előzőekben bemutatottakkal. A kártyák igényelhetők személyesen a szolgáltató kirendeltségein, telefonon, interneten. A regisztráció egy űrlap kitöltésével teljesíthető. A kártya a regisztrációt követő 7-10 napon belül érkezik a megadott címre. A regisztráció más felhasználó nevében is elvégezhető.[21]
41
II.5.6. Használat A kártyák használata meglehetősen egyszerű, a feltöltés követően azonnal használható. A zárt peronos metrónál automatikus kapukat helyeztek el, melyek az előzőekhez hasonlóan olvasókkal vannak felszerelve. Azokhoz érintve a kártyát a kapu automatikusan kinyílik és az utazás megkezdhető. A buszok esetében a fedélzeten elhelyezett leolvasó terminál végzi el ugyanezt a feladatot. Az egyes utazások végeztével kijelentkezés nem szükséges. A rendszer automatikusan vonja le a megszabott összegeket az utazások során. A rendszer csak CI rendszer szerint működik. [21] II.5.7. Értéknövelt szolgáltatások A rendszer érdekessége a korábbiakban bemutatottakhoz képest az, hogy egy időben egyszerre akár hét utas tud használni egy kártyát a vonatos és a buszos utazások esetében egyaránt. A kártyáról minden utas belépésekor a meghatározott teljesáru jegynek megfelelő összeget vonja le a rendszer. A vasútállomásokon minden utasnak külön-külön oda kell érintenie a kártyát a kapu olvasójához, így az együtt utazó felhasználók egymás után tudnak belépni az állomás területére. A buszos utazások esetében a sofőr engedi fel az utasokat a fedélzetre. Kikötés a csoportos használat esetén, hogy az utasoknak egy helyen kell megkezdeniük és befejezniük az utazást. Nem kivitelezhető egy kártyával az, hogy az utazás vagy az átszállás során csatlakoznak a csoporthoz. Nem okoz gondot, ha a kártya elveszik, ellopják. A központi nyilvántartásban tárolják az egyes felhasználók számláinak egyenlegét. Abban az esetben, ha a felhasználó bejelenti a kártya eltűnését, akkor a szolgáltató pótolja egy olyan kártyával, aminek tulajdonságai megegyeznek, annak a kártyának a tulajdonságaival, amelyik eltűnt. [21] II.5.8. Előnyök, hátrányok A kialakított rendszer legnagyobb előnye a csoportos utazás lehetősége. Emellett további pozitívum, hogy a rendszer bizonyos kártyái szerver alapú működést biztosítanak, megkönnyítve a vásárlási és feltöltési folyamatokat.
42
A rendszer egyik nagy hiányossága, hogy a kedvezményeket nem tudják a kártyákon rögzíteni. A szolgáltató egyébként létrehozott a diákok, nyugdíjasok, mozgássérültek számára elérhető díjtételeket is, de ezek a Chicago Card-on kívül értendők. A kártyákon tárolt bérletek tulajdonképpen havi bérletnek felelnek meg, amelyek érvényessége nem függ a vásárlás időpontjától. A kártya típusokon tárolható díjtételek különbözősége miatt, nehézkes lehet az adott felhasználó számára megfelelő kártya kiválasztása. Az egyes kártya típusok közötti váltások során az egyes meglévő díjtételek nem vihetők át a meglévő kártyára, emiatt számos felhasználó rákényszerül arra, hogy egyszerre több kártyát is tartson magánál, ami minden esetben többlet kiadást jelent.
II.6. A rendszerek összehasonlítása A 2.táblázatban az ismertetett jegyrendszerek összehasonlítása látható. 2. táblázat A vizsgált rendszerek összehasonlítása
Bevezetés ideje
Informatikai háttér
Budapesti elektronikus jegyrendszer Várhatóan 2014
Központi adattárolás
Oyster card
OV- Chipkaart
Chicago card
2003
2011
2004
Kártyán való adattárolás/ Központi adattárolás (Auto top up)
Kártyán való adattárolás/ Központi adattárolás (Auto top up)
Kártyán való adattárolás/ Központi adattárolás (Auto top up)
Regisztrált, nem regisztrált kártyák Smart Paper NFC mobiltelefonok
Regisztrált, nem regisztrált kártyák Papíralapú jegyek
Regisztrált, nem regisztrált kártyák Eldobható kártya
Regisztrált, nem regisztrált kártyák
Díjfizetési módok
PIA és PAYG
PIA és PAYG
PIA és PAYG
PIA és PAYG
Regisztráció Használat
Személyesen, interneten, telefonon CICO, CI elv szerint
Személyesen, interneten, telefonon CICO, CI elv szerint
Személyesen, interneten, telefonon CICO elv szerint
Személyesen, interneten, telefonon CI elv szerint
Értéknövelt szolgáltatások
Kártyaletiltás, Viteldíj maximum, Elszámolás
Fare capping, Auto top up, Elszámolás
Kártyaletiltás, Automata feltöltés, Elszámolás Utazási szokások vizsgálhatók Teljesítmény arányos díjszabás (PAYG)
Egy kártyával többen is utazhatnak Kártyaletiltás
Utasmédia típusok
Erősség
Gyengeség
Egyszerű használat, Utasbarát feltételek, Átláthatóság
Az utazási adatok gyűjtésének korlátai
Utazási szokások vizsgálhatók Kedvezőbb díjszabás Szokásokhoz alkalmazkodó kártya struktúra Nem teljesen szerver alapú Nem egységes zóna rendszer A kártyák nem mindenhova érvényesek Néhol külön álló érvényesítő készülékek
Nem teljesen szerver alapú a rendszer CICO elv visszaélésre adhat lehetőséget
Csoportos utazás
Kedvezményeket nem kezeli a rendszer Havi bérletek érvényessége független a vásárlás időpontjától
43
III. Az elektronikus jegyrendszer adatbázis modellje
Kevés információt találtam azzal kapcsolatosan, hogy az érvényesítések során keletkező adatokat miként használják fel. Az e-jegy rendszerek használata során nagyon sok adat keletkezik, melyek a rendszerek bevezetése előtt rendkívül nehezen voltak elérhetőek. Ezek az információk csak a háztartás felvételek segítségével voltak előállíthatóak, de a felvételek torzíthatnak, pillanatfelvételszerű eredményt produkálnak és nem utolsó szempontként költségesek, felvételük és feldolgozásuk időigényes. Az adatok frissítése időről-időre szükséges, a megfelelő minta előállításához az adott település lakosságának magas százalékát kell kikérdezni, ami további probléma. Ennek alternatívájaként használhatóak az elektronikus jegyrendszerek által szolgáltatott adatok. A dolgozatom további részében kifejezetten az e-jegyrendszerben keletkező utazási adatok tárolásával és azok feldolgozásával foglalkozom. A fenti célok eléréséhez a valós adatbázis egy modelljét kellett elkészítenem. Az adatbázis modell elkészítése során a korábban bemutatott Transmodel szabvány előírásaira, valamint egy működő rendszer mintarekordjára támaszkodtam. A modell felépítését a logikai modell megalkotásával kezdtem, és folytattam a fogalmi modell létre hozásával, ami a kaposvári tömegközlekedési hálózat egy részét reprezentálja. A modellel kapcsolatos alapvető lehatárolások:
CICO elven működő rendszer leképezése (minden utasra vonatkozik) Utaskategóriák megkülönböztetése Zóna beosztás leképezése Járművezénylési terv és a menetrend leképezése Az utazások során használt díjtételek nincsenek megkülönböztetve
A dolgozatnak nem célja a különféle díjszámítási módok összehasonlítása és kidolgozása, azonban a témakör, az adatmodellben többletfunkcióként szerepel.
44
III.1. A modell felépítésének megalapozása, általános sémák Belátható, hogy a Transmodel szabvány (a továbbiakban szabvány) rendkívül szerteágazó, a minden szabványágat érintő, teljes adatbázis megvalósítása nem szükséges ahhoz, hogy az utazási adatokat modellezni lehessen. A fenti lehatárolások miatt a modell nem teljesen egyezik meg a szabványban bemutatottakkal. A működőképes modell megalkotásához néhol egyszerűsítenem kellett. Ebben a pontban a feladatomhoz kapcsolódó, az utazásiadatokkal kapcsolatos modult elemzem részletesen. A szabvány menedzsment információkkal foglalkozó modulja, azokat a funkciókat mutatja be, melyek a szolgáltatás minőségének ellenőrzésére irányulnak. A modul alapvetően kétféle adattípust használ fel:
tervezés során létrejövő elméleti adatok (menetrend), a napi teljesítményt leíró adatok (utasszám).
A modul célja, hogy a menetrend értékeléséhez, valamint a hálózat, utasok általi igénybevételének megállapításához szükséges alapadatokra adjon előírást, és vázolja a lehetséges adatkapcsolatokat. Az adatok felvételének módjára nem közöl előírást a szabvány, ennek fényében olyan adatok kerültek bele, ami a felhasznált technológiától függetlenül mérhetők. A referencia modell (szabvány) csak az alapadatokat határozza meg, az adatok feldolgozására, valamint az adatok csoportosítására nem tesz kikötést.[6] Az említett részen belül az aktuális utazásokat leíró adatmodult használtam fel kiindulásként. A modul egy adatkapcsolati ábrában foglalja össze, az utazások tárolásához szükséges adatokat. Az adattáblák között
látható adatkapcsolatot szimbolizáló vonalak
szaggatottak, ez hivatott jelezni az opcionális jellegüket[6]. Az adatmodul középpontjában maga az utazás (RECORDED PT TRIP1 vagy RECORDED RIDE) áll. A szabvány itt megkülönbözteti a „RIDE” és a „TRIP” fogalmát. Az utazásokat tehát két féleképpen is el lehet tárolni. (lásd 11. ábra)
1
Zárójelben, nagybetűs jelöléssel a 11.ábra vonatkozó egységei kerülnek meghivatkozásra.
45
FARE SECTION
the end section of
the start of
the end of
starting at
the start section of
the start of TARIFF ZO NE
POINT IN JO URNEY PATTERN # OR DE R
the end zone of
the start zone of
the start zone of
composed of
on
the end zone of
included in
made up of
STOP POINT
JO URNEY PATTERN # ID
the end of the start of from
from to
the end of
from
from
to
used for
to
from to
RECORDED PT TRIP
RECORDED RIDE
# ID
# ID
composed of the result of
made on
from to
to
made on
the result of part of
date of
made using
made on
date of
OPERATING DAY
DATED VEHICLE JOURNEY
# CA LEN DAR # DA TE
# ID
date of
dated on
operated by
monitored as operating resulting in
resulting in
VALIDATED ACCESS
covered by
the start of
monitored as using used for
MO NITO RED VEHICLE JOURNEY # ID
11. ábra A Transmodel szabvány, utazásokat leíró modulja (forrás: [6])
A „RIDE”-ot definiálhatjuk olyan utazásszeletként, amit az utas végrehajt egy járművön bármiféle átszállás nélkül. Ezekből az utazásszeletekből összeállhat a komplett utazási lánc is. A „TRIP” egy teljes utazási láncot jelent, ami magában foglalhat több viszonylatot is. A legtöbb rendszer csak az egyes utazásszeleteket tárolja. A saját modellemben én is ezt a megoldást választottam. Ha a rendszer nem az egyes szeleteket tárolja el, akkor előbb az utazási lánc részleteit fel kell dolgozni, azokat össze kell rendelni. Az utazások táblához több más tábla kapcsolódik. Az utazások rögzítésénél meg kell jeleníteni a fel- és leszállás helyét. Ezt megtehetjük úgy, hogy a megállókat
46
(STOP POINT), vagy azokat a zónákat (TARIFF ZONE) jelenítjük meg az utazási rekordban, ahová az adott megálló esik. Ebben az esetben a kapcsolat „Egy” oldalán a megállók, vagy a zónák táblának kell állnia, hiszen egy adott megálló több utazásban is szerepelhet, de egy utazás során legfeljebb két megállót kell rögzíteni. A zóna és a megállók együttes megjelenítésére is lehetőség van. Ha mind a kettő objektum megjelenítésre kerül az utazás rekordjában, akkor a feltüntetett kapcsolatok közül csak az egyik maradhat meg, tehát vagy a megállók tábla kapcsolódik közvetlenül az utazásokhoz, vagy a zóna tábla. Ha mindkét kapcsolat megmaradna körhivatkozás alakulna ki, ami viszont nem megengedett a relációs adatbázisokban. A megállók tábla felfogható a zónák tábla részhalmazaként is. A zónák és a megállók között lévő kapcsolat „Több-Több” kapcsolatként jelenik meg a referencia modellben, ami nem szerencsés megoldás. A legtöbb esetben egy megálló, csak egy zónában helyezkedik el, ebben az esetben „Egy-Több” kapcsolat létesítése is elegendő. Az ábrában megjelenített kapcsolattípus modellezésére abban az esetben lehet szükség, ha a szolgáltatási terület zónabeosztása nem egységes, akár közlekedési módok szerint változhat, tehát egy megálló több zónának is része. A rögzített utazás (RECORDED RIDE vagy PT TRIP) kapcsolatban állhat, a járművezénylési tervet leíró adattáblákkal. Itt is több lehetőség van az adatkapcsolatok kialakítását illetően. Az utas által lebonyolított utazás része lehet egy a szolgáltató által megfigyelt
menetnek
(MONITORED
VEHICLE
JOURNEY).
A
menetek
megfigyelésére számos lehetőség kínálkozik, a szabvány nem ír elő semmilyen konkrét módszert. Erre a feladatra tehát alkalmas a járműveken elhelyezett fedélzeti számítógép, és a vele kommunikáló kártyaleolvasó készülékekből képzett eszközrendszer. Az utas által igénybe vett menet azonosítása közvetlenül a kártyaérvényesítése során is megtörténhet, de akár utólagos adatfeldolgozás során is meghatározható. A megfigyelt menet beletartozik az adott napra betervezett menetek közé (DATED VEHICLE JOURNEY). A tervezett menetek pedig egy adott naphoz (OPERATING DAY) vannak hozzárendelve. Az utazás napja megjelenhet a rögzített utazás rekordjában, de akár áttételesen, a menetek tábláján keresztül is megállapítható. Az utazás napját magába foglaló táblának más funkciója is lehet. Ezen a táblán keresztül megkülönböztethetők az év egyes időszakai (pl.: tanév), melyekhez más és más
47
teljesítményszintet rendelhet hozzá a szolgáltató. A meneteket tartalmazó tábla hozzákapcsolható a menet sémákat tartalmazó táblához. A menet séma (JOURNEY PATTERN), az entitás definíciók szerint összeállítható a rezsifutásokból (DEAD RUN) és azokból a menetekből, amelyek során utasokat szállítanak (SERVICE RUN) [6][7]. A menetsémát azonosíthatjuk a fordákkal. A szabvány szerint ennek az objektumnak az eltárolása nem kötelező, mivel más objektumok uniójából előállítható. A menet sémákhoz hozzárendelhetünk még pontokat reprezentáló objektumokat (POINT IN JOURNEY PATTERN) is. Ezek a pontok lehetnek megállóhelyek, vagy valamiféle időzítési pontok. A pontok meghatározott sorrend alapján következnek az egyes menetsémákon. Az utazáshoz kapcsolódhat a „viteldíj szakasz” (FARE SECTION) nevű tábla, ami a menetséma felosztása a viteldíjakra nézve. A definíciók között megtalálható az is, hogy ezt az entitást a viteldíjrendszer egyes elemeinek azonosítására használják. Az utazásokhoz valamilyen módon hozzá kell rendelni az utasokat is, de legalább meg kell állapítani, hogy milyen díjtétel révén veszik igénybe a szolgáltatást. Ezt a célt szolgálja a „hitelesített hozzáférés” (VALIDATED ACCESS) tábla. A tábla adatai tulajdonképpen a felhasználói eszközökön tárolt díjtermékek érvényességének ellenőrzéséből jönnek létre. A tábla felfogható az „érvényesíthető elemek” nevű tábla részhalmazaként is. [7] A referencia adatmodell meghatározza azokat az attribútumokat, melyek eltárolása javasolt az adott táblákban. Ezeket a kikötéseket az 3. táblázat foglalja össze: 3. táblázat Az utazási adatokat rögzítő modul adattáblái, attribútumai (forrás:[7])
Tábla név Tariff Zone
Stop Points Operating Day
Attribútumai Azonosító Leírás Neve Azonosító Neve Felszálláshoz Leszálláshoz Naptár
Megjegyzés Elsődleges kulcs Opcionális Nem opcionális Elsődleges kulcs Opcionális Opcionális Opcionális Elsődleges kulcs
48
Tábla név
Operating Day Dated Vehicle Journey Journey Pattern Point in Journey Pattern Monitored Vehicle Journey Fare Section Validated Access Recorded PT Trip Recorded Ride
Attribútumai
Megjegyzés
Dátum Üzemkezdet Üzem vége
Másodlagos kulcs Opcionális Opcionális
Azonosító Indulási idő Azonosító Neve Rendeltetés Felszállás Leszállás Azonosító
Elsődleges kulcs Opcionális Elsődleges kulcs Opcionális Elsődleges kulcs Opcionális Opcionális Elsődleges kulcs
Point in Journey Pattern azonosítja Azonosító Elsődleges kulcs Dátum Opcionális Neve Opcionális Azonosító Elsődleges kulcs Azonosító Elsődleges kulcs
A táblázatban szerepelnek olyan entitások, amelyek attribútumai megegyeznek más objektumokéval. Ez annak köszönhető, hogy a modul bizonyos objektumoknak csak a részhalmazait használja fel. Ilyen relációk figyelhetőek meg a következő esetekben:
Point -› Stop points Zone -› Tariff zones
Ebben az esetben a felhasznált objektum átvehet bizonyos attribútumokat a felette álló objektumtól. A Fare Section táblához külön nem nevez meg a szabvány attribútumokat, hanem az előző példákhoz hasonlóan visszahivatkozik a Point in Journey Pattern táblára[7]. Itt azonban nem halmaz és részhalmaz viszonyáról van szó, hanem arról, hogy a Fare Section-t, a Point in Journey Pattern megfelelő elemeinek segítségével lehet azonosítani. A Recorded PT Trip és a Recorded Ride nevű tábláknál csak az azonosításra szolgáló attribútum jelenik meg kötelező jelleggel[7]. A táblának valójában több attribútuma is van, melyekben általában a hozzájuk kapcsolódó táblák adatai fognak megjelenni. A két
49
táblában lehetőség van a kapcsolódó tábláktól független attribútumok megjelenítésére is. A szabvány megfelelő részét feltárva kép alkotható arról, hogy a megtervezendő adatmodellnek milyen elveket kell majd követnie. A referencia modell nagyon sok részletet függőben hagy, csak kevés attribútumot nevez meg. Kérdéses volt, hogy a fenti modell milyen lekérdezések támogatására lenne alkalmas, és hogy az adatmodellnek milyen többletfunkciókat kell majd betöltenie. III.2. A Scwäbisch Hall-i rendszer mintarekordja
Az adatbázis megtervezésében nagy segítségemre volt, hogy megvizsgálhattam egy már működő rendszer által előállított utazást leíró rekordot. 4. táblázat A Schwäbisch Hall-i rendszer mintarekordja (forrás: [3]) Kódolt kártyaszám 105094 Felsz. megállló neve Schulzentrum
Felsz. megálló
Hó
Év
CheckIn ideje
CheckOut ideje
Viszonylat
11
2009
2009.11.02.12:06
2009.11.02.13:09
1
101072
Lesz. megálló
Lesz. megállló
kódja
neve
Zóna kód
Zóna neve
442002
Grüner ba.
1010
Ammertsweiler
Zóna kód
1010
Zóna neve Schwäbisch Hall
kódja
A Transmodel referencia adatbázisát és a táblázatban lévő mintarekordot tekintve, megfigyelhetőek az azonosságok és a különbségek. A mintarekord első attribútuma egy kódolt szám, ami az utazáshoz felhasznált kártya egyedi azonosítója. A rekord azonosítására ez önmagában nem elegendő, valamilyen egyedi információra van szükség. A kártyaszám ismétlődhet, hiszen egy felhasználó valószínűleg többször utazik, emiatt a szám több utazást is jelölhet. Erre az egyik megoldás az lehet, ha több, a rekordban szereplő adatból összetett kulcsot képzünk. A másik megoldás, ha a rekord adatai mellé hozzáveszünk egy azonosítót. Azonosságként említhető, hogy a rekordban megjelennek a fel- és leszállóhelyek, valamint a megállóhelyekhez kapcsolódó zóna információk. A megállók és a zónák esetében megjelenik a név és az azonosítószám is. Mindkét adat megjelenítése egy rekordban nem feltétlenül szükséges, hiszen a kód segítségével visszakereshető a megálló vagy a zóna neve. A szabványhoz képest
50
különbség, hogy a rekordban megjelenik a viszonylatszám, valamint a be- és kijelentkezés pontos ideje is. A mintaadat jó alapot nyújt a modell megtervezéséhez. A szabvánnyal kiegészítve jól felhasználható. A mintarekordban látható attribútumok jó kiindulási alapot szolgáltatnak az utazásokat leíró táblák, valamint az alapadatokat tartalmazó táblák elkészítéséhez.
III.3. A tárgyi vizsgálathoz készített logikai modell
A szabvány és a mintarekord alapján elkészített adatmodellemet az MS Access 2007 alkalmazás segítségével hoztam létre. Az előző részben bemutatott szabványmodul és a mintarekord segítségével, meghatároztam, hogy az adatbázisnak milyen kimeneti adatokat kell szolgáltatnia, valamint az adatszolgáltatáshoz szükséges táblákat. Az adatbázis 12 táblából áll, melyek között találunk több kapcsoló táblát és virtuális táblát is. Az adatbázisban található táblák egymással kizárólag „Egy-Több” kapcsolatban állnak. A kapcsolat „Egy” oldalán azok a táblák találhatók, amelyek az alapadatokat szolgáltatják, a kapcsolat „Több” oldalán találhatóak azok a táblák, amelyek az alapadatokból származnak valamilyen módon. A táblák és a kapcsolatok létrehozásánál mindig az alaptáblákat hoztam létre először. Ezután következett a származtatott adatokat tartalmazó táblák leképezése. A két objektum közötti kapcsolatokat úgy definiáltam, hogy a származtatott tábla megfelelő attribútuma alatt az alaptáblára való hivatkozást helyeztem el. (Lásd 12. ábra) Az alapadatokat tartalmazó táblák létrehozása után következhettek a kapcsolatok „Több” oldalán szereplő táblák. Ezek a táblák számos attribútuma az alaptáblák attribútumaiból jön. A táblák között megfigyelhetünk több kapcsolótáblát és virtuális táblát is. A virtuális táblákra azért volt szükség, mert bizonyos táblák adatait több tábla veszi át. Az Access nem tud ilyen kapcsolatokat kezelni, éppen ezért az adott táblát megsokszorozza, és úgy kezeli, mintha az adott tábla csak egy másik táblával állna kapcsolatban. A kapcsoló táblákra akkor van szükség, ha egy adott objektumhoz akarunk kapcsolni több más objektumot (egy tábla adott eleméhez, több elemet egy másik táblából). 51
12. ábra Az adatbázis tábla szerkezete, adatkapcsolatai
52
Utasadatok
Járművezénylési adatok
Utazási adatok
Hálózati adatok
A táblák definiálása után meg kellett határozni a táblákban tárolni kívánt attribútumokat is, melyeket táblázatos formában az 1. mellékletben bemutatok. Az attribútumok meghatározása során törekedtem arra, hogy felesleges adatokat ne tároljak el, ne legyen redundancia. Az egyes attribútumok hosszának meghatározása nagyon fontos a bonyolult adatbázisok megalkotásánál. A kelleténél hosszabb adatok jelentős tárkapacitást emészthetnek fel, a felvett adatok számának növekedése esetén. A modell elkészítése során ez nem jelentett problémát, hiszen az adatbázis szerkezete egyszerűbb, mint a valódi jegyrendszereket működtető adatbázisoké. Csak ott törekedtem a mezőhosszok korlátozására, ahol valamilyen egységesítés volt szükséges (pl: szig. számok). A megfelelő attribútumtípusok és -hosszak megállapítása mellett, érvényességi szabályokat kellett meghatározni, azaz egyes mezők kitöltését kötelezővé kell tenni. Az érvényességi szabályok felállítására azért volt szükség, mert ezek segítségével az adatok felvételénél elkövethető hibák mennyisége csökken. A táblák létrehozása után a táblakapcsolatok pontos beállítására került a sor. Az attribútum beállításoknál alkalmaztam az Access keresés varázsló funkcióját is. Ez a funkció nagyban megkönnyíti az adatintegritás megtartását, hiszen így automatikusan csak olyan adatokat tudtam felvenni bizonyos táblákba, amelyek a vele kapcsolatban lévő táblákban már rögzítve voltak. A modellben nem különülnek el térben az egyes adatbázis elemek, nem decentralizált, egygépes alkalmazásról van szó. A modell nem kommunikál semmiféle külső eszközzel, amely adatok előállítására volna képes. Emiatt volt szükség, bizonyos egyszerűsítések, kiegészítések beépítésére. A modellben már csak a feldolgozó központban található összesített adattáblákat jelenítettem meg. Az egyes táblák funkciói párhuzamba állíthatók, a rendszert felépítő elemekkel is. Az adatmodell egyes részei tehát megfelelnek a szabványban bemutatott tábla szerkezet elvárásainak. Az adatbázis több részre osztható. Az „Utaskategória” az „Utasadatok” táblák együttesen teszik ki, a rendszer utasadatokkal kapcsolatos részét. Az adatbázis magában
53
foglalja a közlekedési alaphálózat egyfajta leképezését is. Ezt a funkciót a „Viszonylat, Megállóhelyek, Zóna, Viszonylatkapcsoló” táblák töltik be. A harmadik fő egység az adatbázison belül, a járművezénylési adatokat kezelő rész. A járművezénylési adatokat a „Menetek, Járművek, Forda, Forda_menet_kapcs” táblák tartalmazzák. Az adatbázis magját, az „Utazások” tábla képezi. Ebben a táblában kerülnek rögzítésre az utasok által végzett utazások adatai. III.3.1. A felhasználói adatok Az „Utaskategóriák” táblára a rendszerben szereplő utasok csoportosíthatósága miatt volt szükség, illetve a díjszámításhoz szükséges kedvezmények tárolása miatt is. Az utasok csoportosítása abban az esetben is segítség, ha az egyes „Utaskategóriák” térbeli és időbeli mozgását külön szeretnénk megfigyelni. Az „Utaskategóriák” tábla csak három attribútumot tartalmaz. Az első szolgál az adott kategória azonosítására. A táblában fel van még tüntetve az egyes kategóriák neve, valamint a kategóriához tartozó kedvezmények mértéke. III.3.2. A hálózati adatok Az adatbázis működésének alapja, hogy a modellezni kívánt szolgáltatási terület alaphálózatának elemeit is magában foglalja. Több ilyen objektumot is megfigyelhetünk a táblaszerkezetben, ezek a zónák, a megállóhelyek, és a viszonylatok. Az adatbázisban az objektumok geometriai jellegének nem tulajdonítottam nagyobb jelentőséget, mivel nem térinformatikai adatbázis létrehozásáról van szó. A hálózat leképezés nem terjed ki a vonal típusú objektumok leképezésére sem. A „Zóna” tábla öt attribútumot tartalmaz. Az első attribútum az azonosítást végzi, a továbbiak a zónát leíró adatokat tartalmazzák. Ez a tábla képes az egyes zónákhoz különböző viteldíjakat párosítani, ha a díjszámítási rendszer úgy kívánja. Az ismertetett szabvány előírásaihoz képest pluszként jelenik meg a „Zóna” és a „Zóna költségek” nevű táblák kapcsolata. A táblák segítségével, adott zónák közötti viteldíjakat szabhatunk meg. A „Zóna” táblával azonosítható, hogy az utas melyik zónából indul és, hogy hová érkezik. A „Zóna költségek” táblában tulajdonképpen egy honnan-hová mátrixot képeztem le, ami a zónák közötti átlépési költségeket foglalja
54
össze. A tábla attribútumaival azonosíthatók a mátrix egyes elemei. A „kiinduló zóna” adja a mátrix sorait, míg az „érkezési zóna” az oszlopait adja, az „ár” a mátrix celláiban található értékeket reprezentálja. Az indulási és érkezési zóna megállapításával a „Zóna költségek” táblából kerül megállapításra a számlázandó összeg. Látható, hogy a mátrixot leképező tábla kapcsolatban áll egy „Zóna_1” nevű táblával is, ami egy virtuális tábla. A táblák közötti kapcsolat „Egy” oldalán állnak a zónákat leíró táblák, a „Több” oldalon pedig a „Zóna költség” áll, mivel itt kell definiálni a zónák közti viszonyokat. A táblák használata nem szükséges feltétlenül, de ezzel lehetőség nyílik arra, hogy a díjszámítási rendszer paramétereit finomítsuk, vagy különböző díjszámítási módszereket hasonlítsunk össze. A zóna adatokat leíró táblához hozzákapcsoltam a „Megállóhelyek” nevű táblát. A tábla attribútumai között megtaláljuk az egyedi azonosítót tartalmazó mezőt, valamint a megálló egyéb tulajdonságait leíró mezőket. A táblában az adott megálló nevét, a megállót magába foglaló zóna azonosítószámát tartom nyilván. A tábla kapcsolatban áll a zóna adatokat tároló entitásokkal, az azonos nevű mezők révén, ez a tábla képezi a kapcsolat „Több” oldalát. A „Leírás” nevű attribútum alatt lehetőség van a környező forgalomvonzó létesítmények eltárolására is. A hálózati adatok közé kerül a „Viszonylatok” megnevezésű tábla is. A tábla mezői között elsődleges kulcsot és további leíró attribútumokat találhatunk. A viszonylatok tábla eltárolása azért volt célszerű, mert így a későbbiekben egyszerűen lehet majd hivatkozni egy adott vonalra, ha az arra vonatkozó adatokra vagyunk kíváncsiak. A
„Viszonylatok”
és
a
„Megállóhelyek”
táblák
kapcsolatban
állnak
a
„Viszonylatkapcsoló” táblával. A tábla azt a célt szolgálja, hogy a megállókat hozzá lehessen rendelni az egyes viszonylatokhoz. Az összerendelés elvégezhető lenne a két tábla közül valamelyikben oly módon, hogy további attribútumokat veszünk fel. Ebben az esetben annyi plusz mező felvételére van szükség, ahány viszonylat érint egy megállót, és ezt előre tudnunk kell. A kapcsolótáblában viszont a rekordok jelentenek egy-egy kapcsolatot, melyek köre bármikor bővíthető. A hálózat átszervezése esetén ez könnyebbséget jelent.
55
A viszonylatkapcsoló segítségével lehetővé válik, hogy az egyes megállókról olyan adatokat is eltároljunk, amelyek az adott viszonylattól függenek. Ilyen paraméter lehet az adott megálló végállomástól vett távolsága, vagy a sorszáma. Ez azt eredményezi, hogy azokat a megállókat, amelyek több viszonylat részei, többször kell felvenni. A tábla részét képezi a „Zóna_határ” nevű attribútum is, melyet csak azoknál a kapcsolatoknál kell kitölteni, amelyek egy adott viszonylaton zónahatár előtti megállót jelentenek. Ez akkor lehet fontos, ha a szolgáltató a különböző zónák esetében, különböző viteldíjakat határoz meg. III.3.3. Járművezénylési adatok A járművezénylési adatokat leíró részben két táblát találunk, melyek függetlenek a többitől. A „Járművek” táblában lehetősége van a felhasználónak eltárolni az adott szolgáltató járműveinek paramétereit. A tábla kötelezően kitöltendő mezője az első attribútum, mely a táblában elsődleges kulcsként szolgál. A további mezőkben rögzíthető a járművek jellege (busz, metró, villamos, stb.), típusa, férőhelyek száma, és további a járműveket jellemző adatok. A tábla utolsó mezője az egyes járművekre vonatkozó futásköltség. Ha a felhasználó rendelkezik ilyen adatokkal, akkor könnyen ki lehet mutatni, hogy egy adott menet veszteséget vagy nyereséget termel. A tábla a fordákat rögzítő táblával áll kapcsolatban. A való életben, adott napon egy jármű egy fordával van összerendelve. Az előzetes összerendelés változhat a munkanap során abban az esetben, ha egy jármű lerobban, vagy épp egy különjáratot kell vinnie. Ilyen jellegű változásokra a modell felépítésekor nem tértem ki. A kapcsolat „Egy” oldalán a járművek szerepelnek, hiszen egy jármű több fordát is kiszolgálhat különböző napokon. A „Forda” tábla csak arra szolgál jelen esetben, hogy a járművekkel való összerendelést biztosítsa, ezért csak az elengedhetetlenül fontos attribútumokat rögzítettem a táblában. A forda elmaradhatatlan elemei a napi menetek, amelyeket külön objektumként kezelve tároltam el a „Menetek” nevű táblában. A tábla mezői az előzőekhez hasonlóan alakulnak. Az elsődleges kulcs a „Menet_Az” nevű mező. A menetek leírására felhasználom a viszonylat, a sorszám, indulás, érkezés, és az irány nevű mezőket. A sorszám mindig adott viszonylaton belül értendő a könnyebb azonosítás végett. A tábla elsődleges kulcsa kapcsolódik a „Forda_menet_kapcs” táblához. A táblában tehát a
56
menterendben szereplő összes menetet fel kell tüntetni. Ezek után a fordák és a menetek összerendelhetőek. Az adatmodellben található másik kapcsolótábla a „Forda_menet_kapcs” nevű tábla. Ez arra szolgál, hogy az egyes meneteket egyértelműen egy adott fordához lehessen rendelni. Erre azért van nagy szükség, hogy a menetek változása, másik fordához való átcsoportosítása esetén az adatok könnyen kezelhetőek maradjanak. A másik oka a kapcsolótábla használatának a megállóhelyek problémaköréhez hasonlatos. Ha az összerendelést egy táblában oldanánk meg, akkor annyi mezőt kellene még létrehozni, amennyi menet a fordában van. Felvetődik az a probléma is, hogy az egyes rekordok hosszúságának azonosnak kell lennie, tehát tudni kell a maximális menetszámot egy fordán belül. Ezzel a megoldással nagy tárhelyet különíthetünk el feleslegesen. Ezt a megoldást itt sem tartottam használhatónak, és inkább egy új kapcsolótáblával oldottam meg a problémát. A tábla segítségével egyértelműen megállapítható, hogy melyik menet, melyik fordába tartozik bele. A tábla attribútumait úgy állapítottam meg, hogy az összerendelést lehetővé tegyék, egyéb a kapcsolatot leíró mezők nem szerepelnek a táblában. A modellbeli járművezénylési terveket nem kívántam hozzárendelni minden egyes naptári naphoz. Inkább azt a megoldást választottam, hogy a fordákat különböztetem meg aszerint, hogy az adott forda munkanapra, vagy munkaszüneti napra vonatkozik. A megkülönböztetés történhet egyszerűen a forda számok, nevek szerint. A fordákat és a meneteket összekapcsoló táblában pedig ennek megfelelően kell a kapcsolatokat meghatározni. A járművezénylést tartalmazó részben többletként szerepel egy, a járművek adatait tartalmazó tábla, annak ellenére, hogy az alapvető, utazásokkal kapcsolatos vizsgálatokhoz nem lenne szükséges. Az objektum megjelenítését ennek ellenére mindenképpen szükségesnek tartottam, hiszen célom, hogy összevessem a keresleti oldalt a kínálattal. A járművek paramétereinek megjelenítésével ez lehetővé válik, meghatározhatjuk az egyes menetek kihasználtságát, megállapíthatjuk, hogy az utas- és férőhely kilométerek egymáshoz képest milyen viszonyban állnak egymással. Összefüggéseket kereshetünk az egyes utascsoport viselkedése és a különböző
57
járműtípusok között, valamint a megfelelő lekérdezések segítségével javaslatot tehetünk arra, hogy egy adott vonalra milyen járműtípust érdemes beszerezni. III.3.4. Utazási adatok Az adatmodell magját az „Utazások” tábla képezi. Ide kerülnek a be- és kijelentkezés révén létrejövő utazási adatok. Ebben a táblában tulajdonképpen az előző pontokban tárgyalt alapadatok ismétlődnek természetesen aszerint, hogy az utasok milyen utazási láncokat képeztek. A tábla tehát több másik táblával áll kapcsolatban és minden esetben a kapcsolat „Több” oldalán áll. A tábla első mezője, az adott utazás azonosítását végzi. A tábla „Utas” nevű mezője, az „Utasadatok” nevű táblából veszi át az utas azonosítóját. A táblában megjelennek az utazás időbeli paraméterei is úgymint, az utazás napja, az utazás kezdete és az utazás vége. Ezeknek a mezőknek a kitöltése teljesen független a többi táblától, mivel ezeket az adatokat általában az érvényesítő készülékek rendszerórája segítségével állítják elő. A fel- és leszállóhelyek azonosítására a „Viszonylatkapcsoló” táblát használtam fel. A viszonylat jelzése nem jelenik meg külön az utazási rekordokban, mivel akkor körkapcsolat jönne létre a táblák között. A rekordban tehát, a viszonylat és a megálló kapcsolatát jelző azonosító áll, amiből könnyen visszakereshetőek a viszonylatra vonatkozó adatok. A leszállóhelyet egy virtuális tábla azonosítja, mivel két attribútum a táblában ugyanarra hivatkozik. A rekordot az a mező zárja, ami az adott utazásra érvényes forda és menet kapcsolatának azonosítóját tartalmazza.
III.4. A tárgyi vizsgálathoz készített fogalmi modell
Az előző részben bemutatott logikai modell nem lenne teljes, ha csak önmagában állna. A logikai modell minden esetben valamilyen valóságos rendszert hivatott leképezni, adattáblák és a köztük fennálló kapcsolatok révén. A fogalmi modell határozza meg azt, hogy a logikai modell a valóságnak mely részeit képezi le és azt, hogy a leképezés milyen lehatárolásokkal történik. Dolgozatomban a kaposvári tömegközlekedési alaphálózat egy részét modelleztem le, mivel ez a hálózat jól átlátható, könnyen modellezhető, helyismeretemből kifolyólag jól ismerem (13. ábra). A kaposvári tömegközlekedési hálózaton jelenleg 27 viszonylat működik. A városban kötöttpályás 58
viszonylat nincs, az összes vonal kiszolgálása buszokkal történik. A viszonylatok jó része reggeltől estig közlekedik, azonban vannak olyan viszonylatok is, amelyek csak a nap adott szakaszában járnak. A viszonylatok közül hatot választottam ki, melyek a munkanap teljes hosszában működnek. A leképezett viszonylatok a következőek: [22]
3-as viszonylat: Helyi autóbusz állomás – Egyenesi út 8-as viszonylat: Helyi autóbusz állomás – Toponár, buszforduló 9-es viszonylat: Helyi autóbusz állomás – Arany János tér 11-es viszonylat: Helyi autóbusz állomás – Kaposfüred, buszforduló 12-es viszonylat: Helyi autóbusz állomás – Sopron utca 15-ös viszonylat: Helyi autóbusz állomás - Lonkahegy
A hálózatot zónákra osztottam fel, annak érdekében, hogy az adatbázis által szolgáltatott utazási adatokról átfogóbb képet kapjak, így az egyes zónákból induló vagy azokba érkező utazások „kötegelhetők”. A felosztás alapján 7 különböző zónát jelöltem ki. Egyes jegyrendszereknél ennek külön jelentősége van, a díjszabás tekintetében is, hogy milyen zónaátlépések vannak. Sok városban vannak autómentes zónák, csökkentett emissziós zónák, lakóövezetek, üzleti negyedek, és az egyes zónákbeli viteldíj más és más lehet, attól függően, hogy a közlekedési vállalat, milyen díjpolitikát alkalmaz. A kaposvári hálózat a valóságban nincs zónákra osztva. A rendszerben nem különböztetem meg az utasokat aszerint, hogy milyen díjtermékkel utaznak. Az adatmodell alkalmas távolság alapú (zónánként változó km tarifa szerint), és zóna átlépés alapú viteldíjak megállapítására is. Az egyes zónákhoz tartoznak a modellben megjelenített megállóhelyek. Jelen esetben az egész hálózatra egységes zónafelosztás érvényes, tehát egy megálló csak egy zónához tartozik. A megállóhelyek minden esetben valamelyik zóna határán belül helyezkednek el, zónahatáron lévő megállóhely nem szerepel az általam készített modellben.
A
modellben
kizárólag,
a
kiválasztott
viszonylatokhoz
tartozó
megállóhelyek kerültek rögzítésre. Az általam készített adatmodell a Check in- Check Out, illetve a Check in rendszerben működő elektronikus jegyrendszerek leképezésére alkalmas, mivel az adatfelvételek során a be- és kijelentkezést igénylő rendszer működését szimuláltam. Minden egyes utazási rekordnál ismert a felszállás és a leszállás helye.
59
A valós rendszerek nyilvántartják azokat az utasokat is, akik a leszállások során nem érvényesítik a kártyájukat. A modell adatbázisban természetesen erre is van lehetőség, azonban az ellenőrök által végrehajtott ellenőrzések kezelésére a szimuláció során nem volt lehetőségem. Az ellenőrök által felhasznált gépek a kártyák adatait ellenőrzik. Az, hogy melyik kártyán éppen milyen adatok vannak, csak nagyon nehézkesen modellezhető, és a tervezéshez felhasználható adatokat nem szolgáltatna. Az általam készített adatmodell szempontjából a rendszer ezen része tehát nem volt fontos, de a valódi rendszereknél ez elengedhetetlen. Az adatmodellben a kaposvári közlekedési szolgáltató járműparkjában található járművek paramétereit használtam fel: 5. táblázat A modell adatbázisban megjelenő járműtípusok (forrás :[30])
Férőhelyek
Ajtók száma
IK 260
76
3
Mozgás korlátozott helyek 0
IK 415
90
3
0
szóló
IK 280
148
4
0
csuklós
Nabi
90
3
1
szóló
Nabi Sirius
104
3
1
szóló
Mercedes 345
166
4
1
csuklós
Típus
Jármű jellege szóló
A valós rendszerekhez hasonlóan, a modellben több utaskategóriát határoztam meg:
Kedvezmény nélküli (teljesárú menetjeggyel utazók) Nyugdíjas (ingyen utazók) Diák (50 %-os kedvezménnyel utazók) Mozgáskorlátozott, Vakok, stb.
A kategóriák megkülönböztetése jelen esetben nem csak az optimális díjszabás módszerének megállapítása miatt történik. Az adott utasra érvényes kategória megjelenítése plusz információ lehet, ha az utasok mozgását vizsgáljuk. Külön vizsgálhatjuk az egyes kategóriák mozgását térben, időben egyaránt.
60
13. ábra A modellben leképezett hálózat és zónák
61
IV. Az adatbázis elemzése és az adatok feldolgozása
A bemutatott hálózat adatainak adatbázisba foglalása révén lehetőség nyílik az adatok egyszerű módszerekkel történő feldolgozására. Az adatok könnyű feldolgozásának céljából, a forgalomszervezési kérdések vizsgálatára lekérdezéseket hoztam létre, melyek bármikor előhívhatók és paraméterezhetők. A létrehozott lekérdezéseket csoportokba oszthatjuk aszerint, hogy azok milyen jellegű információkat tárnak a felhasználó elé. Ezek a csoportok a következőek:
Utasforgalmi adatok
Kihasználtsági, teljesítmény adatok
Utazási szokásokkal kapcsolatos adatok
Díjszámításhoz szükséges adatok
Az egyes lekérdezési csoportok között lehetnek átfedések. Az egyes lekérdezések lefuttatása önmagában is hordoz információt, de ahhoz, hogy az utazásokról árnyaltabb képet kapjunk, célszerű egyszerre több lekérdezést is lefuttatni, és a kapott válaszokat együttesen kiértékelni. Az általam létrehozott alkalmazásban kereszttáblás- és választó lekérdezések egyaránt szerepelnek. Az adatbáziskezelő alkalmazások segítségével több más típusú lekérdezés létrehozására is van lehetőség, pl.: frissítő, táblakészítő, hozzáfűző, valamint törlő lekérdezések.
A frissítő és törlő
lekérdezéseket
csak nagy körültekintéssel
alkalmazhatók, hiszen ezek az eljárások pontosan azokat az adatokat írhatják felül, vagy törölhetik, amelyeket az utazási szokások megismerése, vagy a pénzügyi elszámolás miatt szeretnénk később feldolgozni. A dolgozat során készített alkalmazásban szereplő adatok csak a lekérdezések bemutatását szolgálják, melyek a TRENECON COWI Kft. által elvégzett 2009-es kaposvári utasszámlálás eredményein alapulnak [30]. Az adatokhoz teljes hozzáférést kaptam, de azokat módosítás nélkül a tárgyi modellben nem lehetett felhasználni, hiszen az utasszámlálás nem az egyének utazását követi nyomon, hanem egy adott menet során fel- és leszálló utasok számát határozza meg. Az utasszámlálás során több, az utasra
62
jellemző paraméter nem kerül rögzítésre, ami viszont az alkalmazás működése és az adatok kiértékelése szempontjából szükséges lett volna. A TRENECON COWI Kft. adatbázisa és a Kaposvári Tömegközlekedési Zrt. honlapján található adatok segítségével összeállítottam, a viszonylatok, megállóhelyek, menetek listáját az egyes táblák attribútumainak megfelelően. Ezt követően feltöltöttem a „Viszonylatkapcsoló” nevű táblát, a megadott alapadatokkal. Az utasokra jellemző paraméterek a MS Excel nevű program, véletlenszám generátora segítségével készültek el. Az egyes fordákhoz, hozzárendeltem a meneteket, valamint a járműveket. Nem kaptam adatokat arra vonatkozólag sem, hogy egy adott menetet milyen típusú járművel szolgálnak ki, ezért a járművek és fordák párosítása is véletlenszerűen történt. Ezek után az „Utazások” nevű táblát kellett feltölteni. Az adott megállóhelyen fel- és leszálló utasszámok alapján áramlatokat képeztem az egyes megállóhelyek között, majd az utazásokhoz egy menetazonosítót rendeltem hozzá. Az adatok felvétele, generálása során többször feltételezésekkel kellett élnem, így az adatok a valóságtól eltérhetnek. A modellben található utazási adatok egy kora reggeli időszakot ölelnek fel. Egy nap során kb. 10.000 utazás történik a kaposvári hálózaton. Ilyen nagyságrendű adatmennyiség kézi előállítására nem volt lehetőségem, a szűkös időkeret miatt. Az adatmodellben jelenleg 273 db utazási rekord található. A legtöbb lekérdezés eredménye táblázatos, diagramos formában érhető el. A szemléletesebb megjelenítés kedvéért elkészítettem a fogalmi modellben található hálózat geoadatbázisát is. A térképes alkalmazás elkészítése után, kapcsolatot létesítettem az Access és egy GIS szoftver között is, majd a lekérdezések egy részét térképes formában is megjelenítettem.
IV.1. A célforgalmi mátrix előállítása
A közlekedéstervezés és közlekedésmodellezés alapkérdései közé tartozik, hogy a hálózaton közlekedő utasok honnan-hova utaznak. Az egyes utazások kiinduló és végpontjainak ismeretében elvégezhetőek a különböző ráterhelési feladatok. A kikérdezésekkel és egyéb mérési módszerekkel a területre vonatkozó célforgalmi
63
mátrixot csak becsülni lehet, azonban a jegyrendszerekben rögzített adatok segítségével ez nagyon könnyen előállítható. Az „Utazások” nevű táblában tehát rögzítésre kerülnek az egyes utazások kiinduló és cél állomásai, amiből a célforgalmi mátrixot kereszttáblás lekérdezés segítségével állíthatjuk elő. A mátrix sorait a felszálló helyek, a mátrix oszlopait pedig a leszállóhelyek azonosítói képezik. A megállóhely szintű felosztás nagyon részletes, egyes esetekben felesleges lehet, ezért elkészítettem a mátrix azon verzióját is, amelyben kiindulási és cél zónák adják a mátrixot. A zónák mátrixban való megjelenítéséhez szükséges volt az „Utazások ‹- Viszonylatkapcsoló ‹- Megállóhelyek ‹- Zóna” táblák közötti adatkapcsolatok kihasználása. A mátrix egyes celláiban található számok az egyes zónák között történő utazások száma, melyek megállapítása utazókhoz köthető azonosítók megszámlálásával történik. A lekérdezés egyszerű lefuttatása azonban a rendszerben található összes utazási rekordot számításba veszi. A lekérdezések paraméterezésével nem csak egy megbízható célforgalmi mátrixot állíthatunk elő, hanem egy adott időszakra vonatkozó mátrixot is. A
kereszttáblás
lekérdezés
önmagában
nem
paraméterezhető,
hanem
csak
segédlekérdezések segítségével lehet megoldani a problémát. A segédlekérdezés célja, hogy az „Utazások” táblában lévő rekordok előzetes szűrésen essenek át. Az utazás napja mellett további paramétereket adhatunk hozzá a lekérdezéshez, mely lehet egy bizonyos időintervallum. A lekérdezést elkészítettem az időszerinti paraméterezés mellett úgy is, hogy az utaskategóriák szerint történjen az adatok szűrése. Ez az egyes utaskategóriák hálózaton történő mozgásának megfigyelése miatt hasznos, így az utazási szokásokat behatóbban lehet tanulmányozni. Megfigyelhető, hogy a különböző kategóriába tartozó utasok mely zónák között utaznak a legnagyobb arányban, és a nap melyik időszakában. (Pl.: diákok utazása az iskolákhoz, nyugdíjasok, mozgásukban korlátozottak). Látható, hogy a mátrix jól leírja a hálózaton történő utasmozgásokat, melyek alapján az egyes zónákról megállapítható, hogy mekkora utasforgalmat generálnak és mekkora forgalmat nyelnek el. A lekérdezés tehát alapja lehet egy későbbi közlekedési modell elkészítésének, valamint az adatok követésével a szolgáltatónak lehetősége van
64
felkészülni az adott zónák közötti utasáramlatok kezelésére. A kategóriák szerinti vizsgálat segítségével lehetővé válik, hogy az egyes kategóriák igényeinek kedvezzünk, olyan szempontból, hogy a számukra megfelelő járműveket osztjuk be, az általuk igénybe vett viszonylatokra. A 14. ábrán példa látható, az alkalmazás által előállított célforgalmi mátrixokra. A mátrixban az összes utaskategória utazásai benne vannak. Látható, hogy a hajnali időszakban a Belváros nevű zóna forgalma a legmagasabb. Itt indul az időszak legtöbb utazása és ide is irányul. Ez annak köszönhető, hogy a legtöbb viszonylat végállomása itt található, és a város legfontosabb átszállási pontja is. Látható, hogy a belvárosba a legtöbben a Donnerből, valamint az Északi városrészből érkeznek. A Belvárosból a legtöbben Toponár zónájába utaznak. A mátrixból látszik, hogy az utasoknak csak kis része utazik adott zónán belül. Az utazások legnagyobb része két különböző zóna között történik, ez adódhat a kis megállóhely távolságokból is.
14. ábra A célforgalmi mátrix megjelenése a készített alkalmazásban
IV.2. A megállóhelyi terheltség vizsgálata, járműkapacitás kihasználása
Az egyes utasáramlatokkal párhuzamban megállapíthatók az egyes megállók terhelései is, azaz, hogy adott megállóban mennyien szállnak le és fel. A lekérdezés alapjaként az „Utazások‹- Viszonylatkapcsoló‹- Megállóhelyek” táblák szolgálnak. A lekérdezést több változatban készítettem el. A lekérdezés paraméteres változatában egy adott viszonylatra, azon belül adott menetre vonatkozóan kapjuk meg az egyes megállókban fel- és leszálló utasok számát. A lekérdezést több lépcsőn keresztül hoztam létre, mivel 65
nagyon összetett keresésekre és kapcsolatokra volt szükség a szemléletes jelentés létrehozása végett. Az első lépés a felhasználó által vizsgálni kívánt menet során történő utazások leválogatása volt. Ezután két irányban indultam tovább. Először a menet során történt felszállásokat, majd egy másik lekérdezésben a leszállásokat gyűjtöttem össze, a következőképpen. A lekérdezésben a következő táblák kapcsolatát használtam ki: „Adott menet utazásai (lekérdezés) ‹- Viszonylatkapcsoló ‹- Megállóhelyek”. Alapesetben a keresőmotor csak azoknál a megállóknál jelenít meg adatokat, amelyeknél történik le vagy felszállás. Keveredés történhet, ha egy adott megállónál csak az egyik művelet történik meg. Tehát szükség van a menet megállóinak fix listájára, annak érdekében, hogy az adatokat helyesen lehessen az adatbázisból összegyűjteni. A fix lista kialakításához irányított tábla kapcsolat alkalmazására volt szükség, a „Viszonylatkapcsoló” tábla és a lekérdezés között. Az irányított kapcsolat a „Viszonylatkapcsoló” minden rekordját szerepelteti, vagyis a menet összes megállója megjeleníthető. A harmadik lépés a fel- és leszállókat gyűjtő lekérdezések kapcsolása volt, valamint a megálló lista szűrése irány szerint. A lekérdezés eredménye egy olyan táblázat, melyben a fel- és leszálló utasok külön oszlopban jelennek meg, a menet irányának megfelelő megállókhoz rendelve. A 15., 16. ábrán a 12-es viszonylat, 3. menetére vonatkozó megállóterhelési adatok láthatóak.
15. ábra A megállóterhelési jelentés
66
16. ábra A megállóterhelés diagramos formában
A lekérdezés másik változatában, az alkalmazásban leképezett összes megálló listája és a megállókban fel- és leszálló utasok száma is megjelenik. A lekérdezés lefuttatásához, a vizsgálni kívánt nap és időszak megadására van szükség. A lekérdezés további módosításával a szolgáltató számára rendkívül fontos, kapacitás kihasználtsági információkat is előállíthatjuk. A megállóterheléssel foglalkozó lekérdezésben megállapítható
az egyes
megállókban történő
utasmozgás.
A
kapacitáskihasználás megállapításához minden, az adott megállót megelőző megállóban történő utasmozgást összegezni kell, majd osztani a jármű férőhely kapacitásával. Képletszerűen:
A kapacitáskihasználás megállóközre értelmezendő, de mivel a modell adatbázisban nem hoztam létre ezeket külön objektumként, az adatok a megállóhelyek viszonylatában jelennek meg. A lekérdezés fix paraméterének használtam fel a menet megállóinak sorszámát, így lehetővé vált, hogy adott sorszámú megállóhoz az összes előző megállóban történt utasmozgást is figyelje a rendszer, majd ezeket a számokat megállónként összegeztem. A lekérdezés több paraméter kézi megadását is igényli ezek: a vizsgált nap, viszonylat, menet. A lekérdezés a 17. ábrán látható formában ad választ a kapacitás-kihasználtságokra. 67
17. ábra A kapacitáskihasználtság megjelenése a készített alkalmazásban(részlet)
A táblázatos formától sokkal átláthatóbban közli az adatokat a 18. ábrán látható diagramos megjelenítés. Ebben az esetben tehát az adott megállónál megjelenő érték a megnevezett és az utána következő megálló közti szakaszra értendő. A 18. ábra szintén a 12-es viszonylat 3. menetét mutatja be. Látható, hogy a menet a legnagyobb kihasználtságot a 4. és az 5. megálló között éri el, de ekkor is csak 5-6% közötti kihasználtságról van szó.
18. ábra A kapacitáskihasználás diagramos megjelenítése
A két lekérdezést több döntési helyzetben is segítségül hívhatjuk. Ha külön vizsgáljuk a megállóterheléssel foglalkozó lekérdezéseket, képet kaphatunk arról, hogy az egyes megállóhelyek milyen szerepet töltenek be a hálózaton. Megfigyelhetővé válik az utasáramlás pontos lefolyása is. Ha lekérdezést több viszonylatra lefuttatjuk, akkor felfedezhetjük a hálózat legfontosabb átszállóhelyeit is. A fel- és leszálló utasok számából megállapíthatjuk a szükséges megállóhelyi infrastruktúrát is (utasváró típusa
68
mérete, peron tulajdonságok). A hálózat összes megállóhelyét feltüntető lekérdezés bemenetként szolgálhat, térinformatikai alkalmazásokhoz. A lekérdezések eredménye így akár térképes formában is megjeleníthető, így az utasáramlás sokkal behatóbban vizsgálható. A kapacitáskihasználást feltáró lekérdezés segítségével megállapítható, hogy az egyes viszonylatok menetein milyen típusú járműre van szükség. Az alacsony kihasználtságú, ám nagy kapacitású járműveket átcsoportosíthatjuk azokra a menetekre, melyek kihasználtsága jóval nagyobb. Ha a szolgáltató járműbeszerzés előtt áll, akkor igényeknek megfelelő járművek kiválasztása egyszerűsödik. A két lekérdezés segítségével akár a menetek átszervezésére is lehetőség van. Ha menet bizonyos szakaszán nagyon alacsony a kihasználtság, vagy egyáltalán nincs utas a fedélzeten, akkor a menetet le lehet rövidíteni, vagy más menetvonalat is ki lehet alakítani. Lehetőség nyílik akár az expressz járatok kialakítására is. Ha megfigyelhető bizonyos viszonylatok esetében, hogy némelyik járatra több megállóhelyen nincs fel- leszálló, akkor a menetek során csak a legterheltebb megállókat kell meghagyni. Az alkalmazásban helyet kaptak olyan lekérdezések is, melyek nem a meneteket, hanem magukat a fordákat jellemzik. Ezek a lekérdezések azért fontosak, mert átlátható képet adnak sok egymás követő menetről is. Az alkalmazás segítségével meg lehet állapítani, hogy a fordák menetei során átlagosan mekkora a járművek kihasználtsága (19. ábra), valamint készült olyan lekérdezés is, ami részleteiben mutatja be a menetekre vonatkozó adatokat (20. ábra). A fordák szempontjából fontos adat lehet, hogy a fordába tartozó menetek során mennyi utas veszi igénybe a szolgáltatást. A lekérdezés számára a vizsgálni kívánt fordaszámot, valamint a napot kell megadni, az eredmények táblázatos és diagramos formában is elérhetőek. Ha a lekérdezéseket huzamosabb időn keresztül futtatjuk, akkor lehetőségünk van a járműkapacitásbeli igények és a kínálat egyensúlyba helyezésére. A fordára és a menetekre vonatkozó adatok segítségével kiszűrhetőek az üresjáratok is. A 19. ábrán a 26-os forda átlagos kihasználtsági adatai láthatók. Az „x” tengelyen feltüntetett számok a menetek azonosító számai. Látható, hogy a reggeli időszakban a forda menetei közül a 165-ös menet kihasználtsága a legnagyobb. Ugyanez derül ki a 20. ábráról, azonban itt láthatjuk, hogy a menet kihasználtsága erősen ingadozó. A
69
menet első felében az utasok gyűjtése történik, és a második felében a főbb forgalomvonzó létesítmények közelében, egyszerre többen hagyják el a járműveket. A további menetekhez nem történt adatfelvétel, így azoknál nem jelennek meg a kihasználtsági adatok.
19. ábra A fordára vonatkozó átlagos kihasználási adatok
20. ábra Adott forda kihasználtsága, a menetek során
70
IV.3. A csúcsóra, a csúcsórai utasforgalom meghatározása
A közlekedési hálózatok értékelése során az egyik legfontosabb kérdés, hogy az utasforgalom maximálisan milyen mértékű és mikor van a legnagyobb forgalom. Az ilyen jellegű adatok segítségével megállapítható, hogy a hálózaton maximálisan mekkora szállítási kapacitásra van szükség, és az is, hogy mikor. Az általam készített alkalmazásban több lekérdezés is foglalkozik a témával. Az első megközelítés, hogy a csúcsórát a teljes hálózatra vonatkozóan próbáljuk megállapítani. A lekérdezés paraméterezést igényel, hiszen mindig egy adott napra vonatkozóan akarjuk megállapítani a csúcsórát. A felhasználónak csak a vizsgálni kívánt napot kell megadnia. A lekérdezés elkészítéséhez létre kellett hoznom egy időparamétereket tartalmazó táblát, melyben a nap 15 perces intervallumait tároltam el. A táblában tárolt intervallumokhoz a lekérdezés hozzárendeli az adott intervallumban induló utazásokat. Az idő szerinti paraméterezés így fix, de a vizsgálati időtartam változtatására nincs szükség, mivel az üzemkezdet és az üzemzárási idő általában ugyanakkor van az egyes napokon. Az első lépés a segédlekérdezés létrehozása volt, aminek segítségével az egyes utazásokat osztályoztam aszerint, hogy melyik intervallumba esnek. Az utazások kezdeti időpontjára korlátozó feltételt adtam meg, tehát azok az utazások kerülnek bele egy adott intervallumba, amelyek később vagy pontosan akkor kezdődnek, mint az intervallum, de ennek az időpontnak korábbinak vagy egyenlőnek kell lennie az adott intervallum végétől. Szükséges, hogy mindkét feltételt teljesítse az időpont, mert ha ez nem történik meg, akkor az összes annál korábban kezdődő vagy később végződő intervallumba beszámítaná a program. Itt még azonban nem szerepel az összes intervallum, csak azok, amelyekben utazás történik ezért szükség volt egy második lekérdezésre is, melyben a segédlekérdezéshez az intervallumokat tartalmazó táblát társítottam, irányított kapcsolattal. A lekérdezés önmagában nem állapítja meg a csúcsóra idejét, de a szükséges adatokat előállítja. A 15 perces intervallumokra vonatkozó adatokat az Access-ből exportálva átvihetjük más táblázatkezelő alkalmazásokba, ahol az intervallumokból összegeket
71
képzünk, mindig 4 negyedórából. Ezt az időablakot mozgatva a maximális értéket adó óra lesz tehát a csúcsóra. A jelentésekhez további paramétereket adva még részletesebben vizsgálhatjuk meg a forgalom lefolyását az idő függvényében. Az utaskategóriát, és a viszonylatokat hozzáadva megállapíthatjuk, hogy a csúcsórában mely kategóriák a legaktívabbak, vagy melyek a legterheltebb viszonylatok. Az eredmények diagramos és táblázatos formában is elérhetőek, ezek a 21. és a 22. ábrán láthatóak. A lekérdezés másik változata egy adott viszonylaton állapítja meg a csúcsórát. A csúcsórák megállapítása mindig egy teljes nap adatai alapján történik. A rendszerben azonban csak a kora reggeli időszakra vonatkozó adatok találhatóak meg. Ha csak ezt az időszakot vizsgáljuk, akkor a 4:30 - 5:29- ig tartó időszak a legforgalmasabb. Látható, hogy az egyes viszonylatok teljesítménye nem azonos. Az említett időszakban a legnagyobb utasforgalomra a 8-as, a 11-es, valamint a 15-ös viszonylatokon lehet számítani.
21. ábra A csúcsóra meghatározásához szükséges jelentés táblázatos formája (részlet)
72
22. ábra A csúcsóra meghatározásához szükséges jelentés diagramos formája
IV.4. A hálózaton történő átszállások
A hálózaton történő utasáramlatok megfigyelése szempontjából fontos, hogy képet kapjon a szolgáltató arról, hogy a rendszerben regisztrált utasok, milyen könnyen érik el úti céljukat. Az utasok nagy többsége nem preferálja azokat az utazási formákat, melyek igénybe vétele során akár többször át kell szállni. Az átszállás ténye mellett még az is visszatartó erő lehet, ha a két utazás közti várakozási idő aránytalanul nagy az eljutási időhöz képest. Ezen kérdések megválaszolására több lekérdezés is készült. Probléma lehet annak megállapítása, hogy az alkalmazás mit tekintsen átszállásnak. A probléma onnan ered, hogy az adatbázis az egyes utazásokat külön objektumként kezeli, és alaphelyzetben nem köti össze őket semmi. Az átszállásokat úgy tudjuk leképezni a lekérdezésekben, ha azokat a rekordokat válogatjuk ki, amelyek utas azonosítója ismétlődik. Az átszállás mindig két különböző viszonylat között történik, tehát csak azok az utazások jönnek szóba, melyeknél a le- vagy felszállás helyéből visszakeresett viszonylatazonosító különbözik. Ezeket az utazásokat még tovább kell szűrnünk, hiszen meg kell határoznunk azt a két utazás között eltelt időtartamot, melyet még az átszállás alatti várakozásnak minősítünk. Ez az időtartam különböző városokban, nagyon eltérő
73
lehet. Budapest viszonylatában általános az 5-10 perces átszállási idő a legforgalmasabb viszonylatok körében, azonban Kaposváron nem ritka a 30-40 perces várakozási idő sem. A legcélszerűbb megadni azt a maximális időt, ami alatt bármelyik viszonylatról bármelyik másikra át lehet szállni. Az első lekérdezést úgy készítettem el, hogy az átszállást egy rekordként jelenítse meg a jelentés. Itt megjelennek az átszállás részletei is, az első utazás vége, a második utazás eleje, a hozzájuk tartozó időpontok, és a megállóhelyek, valamint a viszonylatok. A lekérdezés adatainak segítségével az átszállások ideje részletesen, vagy átlagolva is megadható. A lekérdezés a legfontosabb átszállóhelyeket is bemutatja. A nagy városok esetében ezekből több is van, Kaposvár esetében csak néhány akad. A 23. ábrán, a helyi autóbusz állomás jelenik meg, mint fő átszállási pont, ami valóságnak teljes mértékben megfelel. A még jobb átláthatóság érdekében az első lekérdezés felhasználásával egy kereszttáblás formát is készítettem, ami azt mutatja be, hogy az egyes viszonylatok között mennyi átszállás történik az adott napon. A lekérdezés felhívja a figyelmet azokra a viszonylatpárokra, melyek között az átszállások döntő többsége lejátszódik. A viszonylatok menetrendjei így tudatosabban vizsgálhatók, a menetrendek egymáshoz igazíthatók és, az átszállások ideje jelentősen csökkenthető (24. ábra). A harmadik átszállással kapcsolatos lekérdezés arányaiban mutatja be a kérdést. A lekérdezés úgy működik, hogy az adott napon közlekedő utasok számát határozza meg elsőként, majd az első lekérdezés eredménylistájában megszámolja, hogy az adott utas hányszor szerepel. A lekérdezés létrehozásához szükség volt egy paramétertábla létrehozására is. Ebben a táblában átszállás-számokat rögzítettem, maximálisan 4-et. A kaposvári hálózaton, annak kis mérete miatt nagyon valószínű, hogy ennél több átszállást nem hajtanak végre egy utazás során. Utolsó lépésként a lekérdezés az átszállás-számokhoz utasszámokat rendel, és azok százalékos arányát számítja ki. A lekérdezések megalkotásához több helyen irányított kapcsolat alkalmazására volt szükség. Az arányokból (25. ábra) jól látható, hogy az utasok milyen arányban kénytelenek átszállni egyik viszonylatról a másikra.
74
A lekérdezés lefuttatása azonban nem feltétlenül elegendő a helyzet korrekt bemutatásához. Kaposvár erre talán az egyik legjobb példa, hiszen egy olyan város, ahol a napi utazások számához képest kevés átszállás történik, de ennek nem feltétlenül az a magyarázata, hogy az utasoknak csak egy eszközt kell igénybe venniük az utazásaik során. Az az eset is fennállhat, hogy az átszállás közbeni várakozás lenne túl hosszú, és az utas inkább gyalogolni kényszerül, akár nagyobb távolságokat is. Az átszállások helyzetét tehát, más módszerekkel is meg kell vizsgálni ahhoz, hogy hű képet kapjunk a helyzetről, az utasok döntéseiről (pl.: háztartásfelvételek).
23. ábra Az átszállások részleteit megjelenítő jelentés
24. ábra A viszonylatok közötti átszállásokat bemutató jelentés
25. ábra Az átszállások számának megoszlása
Az ábrákon (23-25. ábra) látható, hogy a reggeli időszak egyetlen átszállási pontja, a helyi autóbusz pályaudvar volt. Minden átszállás a 11-es viszonylatról történt, 15-en a 8-as viszonylatra szálltak át, 2-en pedig a 12-esre. A 25. ábrán látszik, hogy 232 fő utazott az időszakban, ebből 215-en átszállás nélkül, 17-en egy átszállással értél el uticéljukat. 75
IV.5. Utasok visszatérési ideje
A CICO elven működő jegyrendszerek által tárolt adatok révén lehetőség van az egyének utazási szokásainak felderítésére is. Megfigyelhető, hogy az egyes utasok melyik zónában kezdik meg a napi utazásaikat, és melyik zóna az adott napi utolsó útjuk célja. Az egyes utasokhoz visszatérési időket rendelhetünk hozzá, ami a napi utolsó leszállás és a napi első felszállás idejének különbségéből számítódik ki. Az időkülönbséget csak akkor érdemes kiszámolni, ha az utas visszatér a saját zónájába, és az oda tartozó megállóhelyek valamelyikén kijelentkezést hajt végre. Nem szükséges kikötni, hogy a fel- és leszállóhelyek egyezzenek meg, hiszen az utas hazatérése során egyéb teendőit is elvégezheti (bevásárlás). Az eltelt időből következtetéseket lehet levonni arra vonatkozóan, hogy az utas a nap során milyen céllal indult útnak. A visszatérési időn kívül megfigyelhető, hogy az utasok indulási és érkezési időpontjai milyen időablakban mozognak. Minél kisebb ez az ablak, annál valószínűbb, hogy az adott utas napi rendszerességgel végzi ugyanazt az utazást, tehát feltételezhető, hogy az illető dolgozni, vagy iskolába jár. A néhány órás visszatérési idő arra enged következtetni, hogy az utas valamilyen ügyintézés, bevásárlás, egészségügyi okok miatt utazik. A rendszeresség és az érintett megállóhelyek további támpontokat adhatnak.
IV.6. Viszonylatok forgalma irányonként
A hálózaton történő utasáramlást és a viszonylatok szerepét jól jellemzi, hogy mikor, melyik irányba szállít több utast. A lekérdezés két paraméter megadását igényli, ezek a vizsgálni kívánt nap és a viszonylatjelzés. A lekérdezés segítségével jól láthatóvá válik az ingamozgás, amit az utasok végeznek nap, mint nap. A 26. ábrán a 3-as viszonylat adatai láthatók. Az irányokat számokkal jelöltem meg, az 1-es irány a helyi autóbusz pályaudvarról indul, a 2-es irány pedig oda érkezik. Látható, hogy a viszonylat szerepe ebben az időszakban az utasok gyűjtése és a belvárosba való eljuttatása.
76
26. ábra Adott viszonylat által szállított utasok irányonként
IV.7. Késések egy adott menet során
A jegyrendszerek be- és kijelentkezési adatai alkalmasak annak megállapítására, hogy a menetek során van-e késés. A „Viszonylatkapcsoló” táblában tárolásra került az a relatív időérték percben, amennyi idő alatt a menetrend szerint adott megállóhoz ér a jármű. Ezt az értéket és a „Menetek” táblában tárolt indulási értéket felhasználva, minden menetre megkapjuk a menetrendszerinti időpontokat. A késés értéke kimutatható azoknál a megállóknál, amelyeknél be- és kijelentkezési művelet történik (27. ábra). A késés értéke az adott megállóban történő első le- vagy felszállás időpontjából, és a menetrendszerinti időpontok különbségéből becsülhető. Ezek az értékek nyilvánvalóan nem annyira pontosak, mint egy járműkövető rendszernél és hátrányként említhetjük, hogy az értékek nem valósidőben jelennek meg. Ezzel feltételezzük azt is, hogy az utas mindig közvetlenül a leszállás előtt jelentkezik ki, a felszállók máskor nem is tudják ezt megtenni. Feltételezzük továbbá azt is, hogy az ajtónyitás a megállóban való megállás után közvetlenül történik. Azokban a megállókban ahol nem történik le- vagy felszállás azokban a megállókban nem állapítható meg a késés mértéke, így azzal feltételezéssel kell élnünk, hogy az előző megállóban felhalmozott késés marad, vagyis a két megálló között arányosított 77
értékeket veszünk figyelembe. A lekérdezés eredményéből következtetések vonhatók le arra nézve, hogy a késések miért alakulnak ki. A megálló-terhelési lekérdezések segítségével képet kaphatunk az adott megállóban lejátszódó utascsere-folyamatokról. Az így kapott adatok elemzéséből, a megálló környezetének és a forgalmi jellemzők ismeretében (jelzőlámpás csomópont, útfelújítás stb.), megtudható a késések oka.
27. ábra A késéseket megjelenítő lekérdezés diagramos formája
A 27. ábrán a 8-as viszonylat egy menetének késése látható. A diagram tanulsága szerint, a jármű pontosan indult el a helyi autóbuszállomásról és nem vett fel utasokat egészen a 6. megállóig. Itt az első ki- vagy bejelentkezés 4 perccel azután történt, ahogy az menetrend szerint lehetséges lenne. A tendencia tovább folytatódott a 10. megállóig, ahol már 5 perces késésben volt a jármű. A késésből 4 percet sikerült lefaragni a következő 3 megálló során. Az utolsó három megállóról nincs információnk, hiszen ott nem történt fel-, leszállás.
IV.8. Az utazásokkal kapcsolatos statisztikai adatok Az alkalmazás több statisztikai jellegű információ előállítására is alkalmas. Megállapítható, hogy az utasok átlagosan hány megállót utaznak az egyes viszonylatokon. A megállószám arányaiban is vizsgálható, vagyis a megtett megállószámhoz utasszámokat rendel az alkalmazás, adott viszonylaton, adott napon.
78
Az átlagos utazási hossz mellett érdekes, hogy az utasok mennyi időt tartózkodnak a járműveken a nap különböző szakaszaiban. Ezek az értékek bepillantást nyújtanak abba, hogy az utasok mennyire használják ki az egyes viszonylatokat. Következtetéseket vonhatunk le arra vonatkozólag, hogy az utasok mire használják a vonalakat. Kisvárosi példákat tekintve az utasok inkább a hosszabb utazásokra veszik igénybe a hálózatot, mivel a követési időközök olyan nagyok lehetnek, hogy a pár megállónyi távolságra lévő uticélokat más eszközökkel, akár gyalog közelítik meg. A lekérdezések segítségével lépéseket tehetünk, a rövidtávú utazások előmozdítása érdekében is.
IV.9. A lekérdezések eredményének térképi megjelenítése Bizonyos esetekben a táblázatos és diagramos adatmegjelenítés sem elegendő az eredmények bemutatásához. Ebben az esetben a legkézenfekvőbb, ha a lekérdezések eredményeit térképes formában tárjuk a felhasználó elé. A térképes megjelenítéshez szükség van egy, a fogalmi modellnek megfelelően felépített térinformatikai adatbázis meglétére. Az adatbázis több rétegből áll össze, melyek között pont, vonal, esetleg a sokszög típusú réteg is megtalálható. A fogalmi modellem térinformatikai adatbázisának megalkotásához a Quantum GIS nevű szabadon felhasználható programot alkalmaztam. A kaposvári utcahálózatot leképező vektorréteget, az interneten elérhető Open Street Map nevű projekt segítségével szereztem be. A projekt célja egy szabadon szerkeszthető és felhasználható térkép készítése az egész világról. Ezt az állományt ezután a GIS (Geographic Information System) alkalmazásomba töltöttem be, majd egy megfelelő koordináta rendszert rendeltem hozzá. Az utcahálózat a többi réteg viszonyítási alapja lett minden szempontból, ez alapján helyeztem el a többi rétegen található objektumokat. Minden réteg ugyanazzal a koordináta rendszerrel párosul, így a rétegek nem csúsznak egymásra, méretarányuk azonos. Ahhoz, hogy a lekérdezések eredményei megjeleníthetőek legyenek térképes formában, kapcsolatot kell létesíteni a két alkalmazás között. Az Access lehetőséget biztosít a futtatott lekérdezések eredményeinek exportálására DBF formátumban. A GIS alkalmazásokban, a különböző rétegek adatait több fájl tárolja el. A fájlok egy része a
79
megjelenítésért felelős, és van egy DBF kiterjesztésű is, ami tulajdonképpen az attribútumtábla adatait tartalmazza. A két fájl felcserélésével behívhatók az Access-ben kapott eredmények a térképes felületen is. Az adatok problémamentes megjelenítéséhez szükség volt a lekérdezések átalakítására, mert az eredmény listában megjelenő objektumok sorrendje nem lehet tetszőleges, és az összes objektumnak szerepelnie kell. Az eredmény listában olyan sorrendben kell megjelennie az objektumoknak, mint amilyen sorrendben a GIS alkalmazásban rögzítettük őket, így az adat sorok a megfelelő objektumra fognak vonatkozni. A lekérdezések átalakítása után, a GIS alkalmazásban hoztam létre a szükséges rétegeket. Minden lekérdezést különálló réteg szolgál ki, melyek a GIS alkalmazásban tetszés szerint ki-, bekapcsolhatóak. Az első lekérdezés, amelynek eredményét térképen ábrázoltam a 3-as viszonylat megálló terhelését mutatja be. A térképes megjelenítéshez szükséges volt a megállók felvétele a térképre, majd azokat azonosítóval láttam el. A megállókra vonatkozó lekérdezés eredményét exportáltam a megfelelő helyre, majd megnyitottam GIS alkalmazásban. A megállók jelölése a fel- és leszálló utasok száma szerint változik, ezt a réteg megjelenítési tulajdonságai között lehet beállítani. A lekérdezés térképes ábrázolása a 28. ábrán látható.
28. ábra Megállóterhelés ábrázolása térképes formában (felszállók)
80
Az ábráról leolvasható, hogy a legforgalmasabb megállók a 2. meneten, az Egyenesi úti forduló, az Egyenesi utca 42., a Kölcsey utcában lévő megállóban szállnak fel a legtöbben. A leszállók a 29. ábrán láthatók. Látható, hogy az utazások nagy része a Helyi autóbusz állomáson ért véget.
29. ábra Megállóterhelés ábrázolása térképes formában (leszállók)
A
kapacitáskihasználásra
vonatkozó
lekérdezések
sokkal
szemléletesebben
bemutathatók, ha térképen ábrázoljuk. Az adatmodellben ugyan megállóhelyekre vonatkozóan kerül bemutatásra a témakör, de mivel megállóközökről van szó, a GIS alkalmazásban szakaszokra osztottam a viszonylatot és ezekhez párosítottam az adatbázisban található objektumokat. A szakaszokat a fedélzeten lévő utasok számának megfelelően jelöli a rendszer. A 3-as viszonylat, 2. menet kapacitás kihasználtságának adatai a 30. ábrán láthatóak. A színes szakaszok az éppen fedélzeten lévő utasok számát jelölik, és eszerint változik a szakaszok vastagsága is. Kékkel jelöltem a menetet kiszolgáló jármű férőhely kapacitását, így látható a kapacitáskihasználás mértéke is. Ezt az objektumot egy különálló lekérdezés, valamint egy különálló réteg fájl szolgálja ki.
81
A lekérdezés az adott menet férőhely kapacitását határozza meg, a rétegen pedig a viszonylat megfelelő irányú útvonala látható. Az ábra tanulsága szerint egy gyűjtő menetről van szó, mivel a kapacitás kihasználás a belváros felé közeledve nő. A fő úti célok a Berzsenyi felüljáró, és a Helyi autóbusz állomás, ami a belváros közelségének köszönhető. Az adatbázis szerint a menetet egy 90 fős autóbusz szolgálta ki, aminek láthatóan jóval nagyobb kapacitása a szükségesnél. A menetet kevesebb férőhellyel rendelkező jármű is ki tudja szolgálni.
30. ábra A kapacitáskihasználás térképi megjelenítése
Utolsóként a viszonylatok irányonkénti forgalmát bemutató lekérdezést készítettem el térképes formában. A kiszolgáló lekérdezés megszámlálja az irányonként elszállított utasokat, ehhez a GIS alkalmazásban 2-2 vonal típusú objektum társul, ami a viszonylatok irányok szerinti útvonalát mutatja be. A lekérdezés eredménye határozza meg a vonalak vastagságát, szemléltetve az utasforgalom nagyságát. Az eredmény a 31. ábrán látható.
82
31. ábra A belvárosból kimenő forgalom
32. ábra A belvárosba irányuló forgalom
83
A két ábra szemléletesen bemutatja, hogy a reggeli forgalomban a belváros irányába több utas érkezik. Ez persze nem mondható el az összes viszonylatról, mivel egyes vonalak mentén nagy forgalmat generáló létesítmények is találhatóak (pl. 8-as viszonylat: Kaposvári Villamossági Gyár, Kaposvári Ipari Park). A viszonylatok menetvonalán lévő számok, az elszállított utasok számát jelentik.
IV.10. Az alkalmazás értékelése, a tovább fejlesztés lehetősége
Az alkalmazás elkészültével összegeztem a modell megalkotása során szerzett tapasztalataimat. Megállapítottam, hogy a választott feldolgozási módszer, és az adatmodell alkalmas különféle forgalomszervezési kérdések megválaszolására. Az elkészített lekérdezések jól bemutatják azt, hogy a jegyrendszerekben keletkező adatokból milyen nagy mennyiségű és sokrétűen felhasználható információt lehet nyerni. Az elkészült alkalmazás valós utasadatok hiányában egyelőre csak iránymutatást ad arra nézve, hogy a közlekedési rendszerben mely paraméterek vizsgálata lehetséges az ejegyrendszerekből, amelyek szükségesek a közösségi közlekedési rendszer folyamatos optimalizálásához. A lekérdezések eredményei alapján számos következtetés vonható le a közlekedési rendszer teljesítményét illetően, valamint az utazási szokásokra nézve. Az alkalmazás segítségével lehetővé válik az üresfutások, valamint a teljesítménybeli szűkkeresztmetszetek kiszűrése. Az alkalmazás tovább fejlesztési irányaként az optimalizáló eljárásokkal való bővítést, a GIS alkalmazásokkal való szorosabb, automatizált együttműködés megvalósítását, valamint az utasforgalom előrebecslésére irányuló eljárások megalkotását említeném meg. Az adatbázisban lévő utasadatok, statisztikai alapon történő vizsgálata lehetővé teszi, hogy az egyén utazási szokásait megismerjük. Ennek érdekében megvizsgálhatók, az utasok által képzett utazási láncok felépítése, az utazások gyakorisága és az, utazási időablakok mértéke. Ezekből a paraméterekből következtetéseket vonhatunk le például azzal kapcsolatosan, hogy az utazások milyen céllal történnek [14]. Az azonos 84
paraméterekkel rendelkező utasokat csoportba foglalhatjuk és törzsutasokat jelölhetünk meg
egy
adott
meneten,
valamint
megállapítható
a
menet
utasszámának
változékonysága is. Az utasszámok vagy kapcsolódó bevételek alakulásának, illetve további jellemzők előrebecsléséhez egy jövőbeni tendenciák feltételezésére alkalmas matematikai modell létrehozását látom szükségesnek.
85
Összefoglalás
Diplomadolgozatom
témája
az
elektronikus
jegyrendszerek
felépítésének,
működésének, adatbázisának bemutatása, a tárolt adatok feldolgozási lehetőségeinek vizsgálata egy általam elkészített és adatokkal feltöltött, kaposvári helyi közösségi közlekedést leképező adatmodell segítségével. Célom volt, egy az adatok tárolására és feldolgozására alkalmas adatbázis kidolgozása, valamint a forgalomszervezési kérdéseket és az utazási szokásokat vizsgáló mintalekérdezések megalkotása és eredményeik bemutatása. A dolgozat első részében a rendszerek általános felépítésével foglalkoztam. Bemutattam az egyes alkotóelemek feladatát, a többi elemmel való kapcsolatát. Megvizsgáltam a rendszerek működésének négy lehetséges alapelvét (CI, CICO, WIWO, BIBO), és összehasonlítottam őket aszerint, hogy milyen jellegű adatokat lehet használatuk esetén tárolni. Megállapítottam, hogy a be- és kijelentkezést, valamint a jelenlétet vizsgáló ejegyrendszerek részletesebb adatokat biztosítanak, mint a csak bejelentkezést igénylő rendszerek. Az e-jegyrendszerek működési elveinek megismerése után a háttéradatbázis struktúrájára előírást adó Transmodel szabványt vizsgáltam. Megismertem a szabványt felépítő dokumentumok tartalmát az egyes funkcionális területekre bontva. A jegyrendszerekkel kapcsolatos általános tudnivalók feltárása után, a hazai bevezetéssel kapcsolatos törekvésekkel, valamint a már működő külföldi példák megismerésével foglalkoztam. A rendszereket egy egységes szempontrendszer szerint vizsgáltam meg. Hazai részről bemutatásra került a budapesti koncepció, a Szolnokon 2011-ben működtetett pilot-rendszer, a londoni, a hollandiai, és a chicagoi példa. A fejezet
végén
a
rendszereket
táblázatos
formában
összehasonlítottam,
és
megállapítottam, hogy a bevezetésre kerülő budapesti rendszer – a tervek szerint legalább annyi előnyt biztosít majd, mint a nyugati példák. A dolgozat elkészítése során végig az a gondolat vezérelt, hogy az elektronikus jegyrendszerek nem csak díjbeszedő eszközként funkcionálhatnak, hanem alternatív lehetőséget nyújtanak az utazási igények, valamint az utazási szokások megismerésére. 86
E gondolat mentén haladva a Transmodel szabvány, statisztikai és menedzsment információk tárolásával foglalkozó részével kezdtem el mélyebben foglalkozni. A be- és kijelentkezések során, utazásokat leíró adatok generálódnak a rendszerben, melyeket feldolgozva értékes információhoz juthatunk. A szabványnak tehát a rögzített használati adatait szabályozó modulját vizsgáltam meg, abból a célból, hogy segítségével meghatározzam a saját adatmodellem megvalósításához szükséges objektumok körét. Ezek után vizsgáltam egy működő jegyrendszerből származó mintarekordot is. A dolgozat következő részében megalkottam a Check in, Check out elvű jegyrendszert leképező, adatfeldolgozásra alkalmas adatbázisom, logikai és fogalmi modelljét. Elkészítettem az adattáblákat, meghatároztam a táblákat alkotó attribútumokat, elsődleges kulcsokat jelöltem ki. A táblák között kapcsolatokat létesítettem, így az adatbázis már alkalmas volt az adatok fogadására. A dolgozat negyedik részében az adatmodellbe importált adatok feldolgozásának lehetőségeit
vizsgáltam
meg.
Az
adatok
feldolgozásának
legegyszerűbb
és
leghatékonyabb módja, a lekérdezések alkalmazása volt. Az elkészült alkalmazás segítségével vizsgálhatóvá válnak az utazási igények, célforgalmi mátrix állítható elő, az idő és utascsoport függvényében. Az alkalmazás lehetőséget biztosít a megállóterhelés vizsgálatára, valamint a járműkapacitás kihasználás megfigyelésére, az adatokat menetekre, viszonylatokra és akár fordákra vonatkozóan is le lehet hívni. Az alkalmazás segítségével megállapítható a napi csúcsforgalmak ideje, az egyes időszakokban keletkező utasforgalom nagysága, változatos paraméterek függvényében. Az adatmodell lehetőséget biztosít az utazási szokások beható vizsgálatára, a hálózaton történő átszállások, visszatérési idők elemzésére, amelyek segítségével az utasok egyedi utazási láncai építhetők fel. Elemezhető az napi utasáramlás, irányonkénti utasforgalom, az egyes viszonylatok szerepe a nap különböző időszakaiban, valamint a késések adott menetek során. Az alkalmazás segítségével különféle statisztikai adatok megállapítására is módunk van. Az adatfeldolgozás eredménye táblázatos és diagramos formában érhető el. A megalkotott adatmodell mellé készítettem geoadatbázist is, mely lehetőséget biztosít néhány lekérdezés eredményének térképes ábrázolására. Az alkalmazás létrehozásának, adatfeltöltésének és kiértékelésének elkészültével értékeltem a kutatás eredményeit, megállapítottam milyen erősségei és milyen
87
hiányosságai vannak az alkalmazásnak és a választott feldolgozási módszernek. Az általam készített alkalmazással kapcsolatban végül további fejlesztési lehetőségeket fogalmaztam meg, amelyek a széleskörű felhasználást alapozhatják meg.
88
Forrásjegyzék [1].Mezghani M.: Study on electronic ticketing in public transport (2008), EMTA, URL: http://www.emta.com/IMG/pdf/EMTA-Ticketing.pdf [2].M. Eugenia, G. Valdecasas, R. Endsuleit, J. Calmet: State of the Art in Electronic Ticketing (2002), Institut für Algorithmen und Kognitive Systeme Universität Karlsruhe, URL: http://www.digbib.ubka.uni-karlsruhe.de/volltexte [3].Verebélyi B.: E-ticketing utasfelvételi adatok feldolgozása közlekedéstervező programcsomag segítségével Közlekedés Tudományi Szemle, 2010. október [4].Csiszár Cs.: Integrált díjbeszedő rendszer a személyközlekedésben. Közlekedéstudományi Szemle. LIV.évf. 12. szám Budapest, 2004. [5].Közlekedéstudományi Intézet: A helyi és helyközi közösségi közlekedés Transmodel szabványú menetrendi és hálózati adatokat tartalmazó adatbázis készítés és minősítés feltétel-rendszere- A Transmodel szabvány megvalósítandó követelményeinek meghatározása a ROP projektekben, egységes szakmai útmutató a szabvány értelmezéséhez URL: http://www.kti.hu/uploads/KMK/2011/Transmodel%20Tud%C3%A1st%C3%A1r/ KMK%20Transmodel%20szolg%C3%A1ltat%C3%A1s/Transmodel_kovetelmen yek110422.pdf [6].European Prestandard Rev.: ENV 12896, Reference Data Model for Public Transport, Main Document, Paris, 2001 URL: http://www.transmodel.org/en/cadre1.html [7].European Prestandard Rev.: ENV 12896, Reference Data Model for Public Transport, Appendix A Paris, 2001 URL: http://www.transmodel.org/en/cadre1.html [8].European Prestandard Rev.: ENV 12896, Reference Data Model for Public Transport, Appendix B1 Paris, 2001 URL: http://www.transmodel.org/en/cadre1.html [9].European Prestandard Rev.: ENV 12896, Reference Data Model for Public Transport, Appendix B2 Paris, 2001 URL: http://www.transmodel.org/en/cadre1.html [10].European Prestandard Rev.: ENV 12896, Reference Data Model for Public Transport, Appendix B3 Paris, 2001 URL: http://www.transmodel.org/en/cadre1.html [11].Budapesti Közlekedési Központ: BKK Elektronikus Jegyrendszer, Megvalósíthatósági Vizsgálat, 2011. december, URL.: http://www.bkk.hu/wpcontent/uploads/2012/01/eticketing_megvaltan.pdf [12].P.T.Blythe: Improving Public Transport Ticketing Trough Smart Cards, Municipal Engineer 157, March, 2004, URL: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.7895&rep=rep1&ty pe=pdf [13].Koós András: Elektra Budapest BKV Zrt., URL:http://www.hscf.net/029esemenyek/029_261215Koos_szakmai_nap1207.pdf
89
[14].J.Ortúzar, L.Willumsen: Modelling Transport, John Wiley & Sons Ltd. 2011, ISBN: 978-0-470-76039-0 [15].Stratis Vezetői és Informatikai Tanácsadó Kft: Elektronikus jegyrendszer bevezetése, iránymutatás az ITSO eszközök költségeinek számításához URL: http://www.elektrahungaria.hu/ [16].http://index.hu/video/2011/06/26/szolnok/, megtekintés ideje 2012. 11.20. [17].http://www.jaszkunvolan.hu/index.php?option=com_content&view=article&id=1 85:penztargep-palyazat&catid=37:hirek&Itemid=108, megtekintés ideje 2012. 11. 28. [18].http://www.tfl.gov.uk/, megtekintés ideje: 2012. 11. 20. [19].www.ov-chipkaart.nl, megtekintés ideje: 2012. 11. 20. [20].http://www.ov-chipkaart.nl/reizen/gebruikovchipkaart/films/, megtekintés ideje 2012. 11. 24. [21].http://www.chicago-card.com, megtekintés ideje: 2012. 11. 20. [22].http://www.ktrt.hu/, megtekintés ideje: 2012. 11. 27. [23].http://oystercard.webege.com/, megtekintés ideje: 2012. 11. 22. [24].http://nfctimes.com/news/transport-london-discard-mifare-classic-seeks-desfiresims, megtekintés ideje: 2012. 12. 02. [25].http://www.mifare.net/, megtekintés ideje: 2012. 11. 15. [26].http://en.wikipedia.org/wiki/Oyster_card, megtekintés ideje 2012. 10. 01. [27].http://en.wikipedia.org/wiki/OV-chipkaart, megtekintés ideje 2012. 10.05. [28].http://en.wikipedia.org/wiki/Chicago_Card, megtekintés ideje 2012. 10.06. [29].http://www.cwhonors.org/viewCaseStudy.asp?NominationID=258, megtekintés ideje 2012. 12. 02. [30].(TRENECON) COWI Kft.: Kaposvár Közösségi közlekedési Színvonalának Javítása Infrastrukturális Fejlesztésekkel, Megvalósíthatósági Tanulmány, 2010. május [31].http://www.hscf.net/039ikf_hirex/039_270123bkk_tbs.htm, megtekintés ideje: 2012. 12. 04.
90
Ábrajegyzék 1. ábra Az elektronikus jegyrendszerek általános felépítése ...........................................9 2. ábra WIWO rendszer sematikus ábrája (forrás:[2]) .................................................. 12 3. ábra A BIBO rendszer egy lehetséges megvalósítása (forrás:[2]) ............................. 13 4. ábra A BIBO rendszer egy másik lehetséges megvalósítása (forrás:[2]) ................... 13 5. ábra A szabvány által lefedett funkciók (forrás: [10]) ............................................... 20 6. ábra A londoni Oyster card (forrás: [18]) ................................................................. 32 7. ábra Kártyakiadó és feltöltő automaták Londonban (forrás: [23]) ............................. 32 8. ábra Metró megállóban, buszon lévő fedélzeti terminálok (forrás: [23]) ................... 34 9. ábra Megszemélyesített OV-Chipkaart .................................................................... 37 10. ábra Kártyaolvasó készülékek, az OV-Chipkaart rendszerben ................................ 38 11. ábra A Transmodel szabvány, utazásokat leíró modulja ......................................... 46 12. ábra Az adatbázis tábla szerkezete, adatkapcsolatai................................................ 52 13. ábra A modellben leképezett hálózat és zónák ....................................................... 61 14. ábra A célforgalmi mátrix megjelenése a készített alkalmazásban .......................... 65 15. ábra A megállóterhelési jelentés ............................................................................ 66 16. ábra A megállóterhelés diagramos formában .......................................................... 67 17. ábra A kapacitáskihasználtság megjelenése a készített alkalmazásban(részlet) ....... 68 18. ábra A kapacitáskihasználás diagramos megjelenítése ........................................... 68 19. ábra A fordára vonatkozó átlagos kihasználási adatok ............................................ 70 20. ábra Adott forda kihasználtsága, a menetek során .................................................. 70 21. ábra A csúcsóra meghatározásához szükséges jelentés táblázatos formája (részlet) 72 22. ábra A csúcsóra meghatározásához szükséges jelentés diagramos formája ............. 73 23. ábra Az átszállások részleteit megjelenítő jelentés ................................................. 75 24. ábra A viszonylatok közötti átszállásokat bemutató jelentés ................................... 75 25. ábra Az átszállások számának megoszlása ............................................................. 75 26. ábra Adott viszonylat által szállított utasok irányonként ......................................... 77 27. ábra A késéseket megjelenítő lekérdezés diagramos formája .................................. 78 28. ábra Megállóterhelés ábrázolása térképes formában (felszállók) ............................ 80 29. ábra Megállóterhelés ábrázolása térképes formában (leszállók) .............................. 81 30. ábra A kapacitáskihasználás térképi megjelenítése ................................................. 82 31. ábra A belvárosból kimenő forgalom ..................................................................... 83 32. ábra A belvárosba irányuló forgalom ..................................................................... 83
91
Táblázatjegyzék 1. táblázat Az elektronikus jegyrendszerek által szolgáltatott adatok ............................ 14 2. táblázat A vizsgált rendszerek összehasonlítása ....................................................... 43 3. táblázat Az utazási adatokat rögzítő modul adattáblái, attribútumai .......................... 48 4. táblázat A Schwäbisch Hall-i rendszer mintarekordja .............................................. 50 5. táblázat A modell adatbázisban megjelenő járműtípusok ......................................... 60
92
Mellékletek 1.
melléklet: Az adatmodell attribútumai Tábla név Utaskategória
Utasadatok
Viszonylat
Attribútum neve
Attribútum típus
Hossz
Kategória_Az
Szám
Hosszú egész
Kategória_neve
Szöveg
20
Kedvezmény
Szám
Hosszú egész
Utas_Az
Számláló
Hosszú egész
Neve
Szöveg
Szül_dátum
Dátum/Idő
Cím
Szöveg
50 Formátumból adódik 80
Szig_szám
Szöveg
8
Kategória
Szám
Hosszú egész
Számla_Az
Szám
Hosszú egész
Viszonylat_Az
Szám
Hosszú egész
Száma
Szám
Hosszú egész
Szám
Egyszeres
Végállomás1
Szöveg
80
-
Végállomás2
Szöveg
80
-
Megalloh_Az
Számláló
Hosszú egész
Elsődleges kulcs
Neve
Szöveg
80
A „v” betűk a vissza irányt jelentik
Zóna
Szám
Hosszú egész
Zóna táblából jön
Leírás
Feljegyzés
Nincs meghatározva
A megállóhellyel kapcsolatos kieg. információk
Zóna_Az
Számláló
Hosszú egész
Elsődleges kulcs
Neve
Szöveg
80
-
Leírás
Feljegyzés
Nincs meghatározva
Km_díj
Szám
Hosszú egész
Csúcs időn kívüli km díj
Km_díj_csúcs
Szám
Hosszú egész
Csúcs idei km díj
Költség_az
Szám
Hosszú egész
Elsődleges kulcs
Hossza
Megállóhelyek
Zóna
Zóna_költség
Megjegyzés Elsődleges kulcs Rögzített 2 tizedes Elsődleges kulcs ÉÉÉÉ-HH-NN A kategória táblából átvett érték A számlák táblával áll kapcsolatban Elsődleges kulcs Automatikus tizedesek
Egyéb infók feljegyzésére
93
Tábla név Zóna_költség
Viszonylatkapcsoló
Menetek
Járművek
Forda
Attribútum neve
Attribútum típus
Hossz
Megjegyzés
Kiinduló_zóna
Szám
Hosszú egész
-
Érkezési_zóna
Szám
Hosszú egész
-
Ár
Szám
Hosszú egész
-
Kapcsolat
Számláló
Hosszú egész
Elsődleges kulcs
Viszonylat
Szám
Hosszú egész
Megálló neve
Szám
Hosszú egész
Viszonylat táblából jön Megállóhelyek táblából jön
Iránya
Szám
Hosszú egész
Sorszáma
Szám
Hosszú egész
Távolsága
Szám
Hosszú egész
Zóna_határ
Szám
Hosszú egész
Idő
Dátum/Idő
Rövid idő
MM:SS
Köv_megálló_köz
Szám
Hosszú egész
-
Menet_Az
Szám
Hosszú egész
Elsődleges kulcs
Viszonylat
Szám
Hosszú egész
-
Sorszám
Szám
Hosszú egész
-
Indulás
Dátum/idő
Érkezés
Dátum/idő
Irány
Szám
Hosszú egész
1 v. 2
Jármű_Az
Szám
Hosszú egész
Elsődleges kulcs
Pályaszám
Szöveg
20
-
Busz/Metró
Szöveg
20
Milyen járműről van szó?
Típus
Szöveg
50
-
Gyártási év
Szám
Hosszú egész
-
Férőhelyek
Szám
Hosszú egész
-
Ajtó_szám
Szám
Hosszú egész
-
Mozg_korl_hely
Szám
Hosszú egész
-
Km_költség
Szám
Hosszú egész
-
Forda_szám
Szám
Hosszú egész
Elsődleges kulcs
Formátumból adódik Formátumból adódik
1, vagy 2 Adott viszonylatra vonatkozóan Adott viszonylatra vonatkozóan Adott viszonylatra vonatkozóan
ÓÓ:PP ÓÓ:PP
94
Tábla név Forda Forda_menet_kapcs
Utazások
Attribútum neve
Attribútum típus
Hossz
Megjegyzés Jármű táblából jön
Jármű
Szám
Hosszú egész
Azonosító
Szám
Hosszú egész
Forda
Szám
Hosszú egész
Menet
Szám
Hosszú egész
Utazás_Az
Számláló
Hosszú egész
Utas
Szám
Hosszú egész
Utazás_nap
Dátum/Idő
Formátumból adódik
Utazás_kezdete
Dátum/Idő
Formátumból adódik
ÓÓ:PP
Felszállóhely
Szám
Hosszú egész
A viszonylatkapcsoló táblából jön
Utazás_vége
Dátum/Idő
Formátumból adódik
ÓÓ:PP
Leszállóhely
Szám
Hosszú egész
Menet
Szám
Hosszú egész
Elsődleges kulcs Forda táblából jön Menet táblából jön Elsődleges kulcs Az utasadatok táblából jön ÉÉÉÉ-HH-NN
A viszonylatkapcsoló táblából jön Forda_menet_ka pcs táblából jön.
95
