elektronikus jegy alapÚ utasszÁmlÁlÓ rendszer …

MISKOLCI EGYETEM

GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR

Automatizálási és Infokommunikációs Intézet

Villamosmérnöki (BSc) alapszak

ELEKTRONIKUS JEGY ALAPÚ

UTASSZÁMLÁLÓ RENDSZER FEJELSZTÉSE

Szakdolgozat

Kiss Márton Bence

QTG8C6

Miskolc, 2020

Kiss Márton Bence – Szakdolgozat 2

Tartalomjegyzék

BEVEZETÉS _______________________________________________________________________________ 3 1.

UTASSZÁMLÁLÓ RENDSZEREK _______________________________________________________ 5 2.

2.1. Manuális rendszerek ________________________________________________________________ 5

2.2. Automata rendszerek________________________________________________________________ 6 2.2.1. Nyomásmérésen alapuló technológiák __________________________________________________ 6 2.2.2. Kamera és infravörös érzékelők a buszon _______________________________________________ 7 2.2.3. Jegyalapú megoldások_____________________________________________________________________ 8

A MEGLÉVŐ INFRASTRUKTÚRA ____________________________________________________ 10 3.

3.1. Járművek _____________________________________________________________________________ 10

3.2. Jegykezelő ____________________________________________________________________________ 12

3.3. OBU ____________________________________________________________________________________ 13

3.4. Kültéri Kijelző _______________________________________________________________________ 13

3.5. MobilON alkalmazás ________________________________________________________________ 15

3.6. A koronavírus hatásai ______________________________________________________________ 16

A RENDSZER ELMÉLETE _____________________________________________________________ 17 4.

4.1. Az E-jegyek alapja ___________________________________________________________________ 19 4.1.1. Az NFC ____________________________________________________________________________________ 19 4.1.2. A másik út, az RFID ______________________________________________________________________ 20 4.1.3. Mikrovezérlő, valamint NFC kártya választás _________________________________________ 21

4.2. A GDPR és egyéb aggályok _________________________________________________________ 27

4.3. A Rendszer működése ______________________________________________________________ 29

SZIMULÁCIÓ ELKÉSZÍTÉSE __________________________________________________________ 35 5.

5.1. Jegy és bérlettípusok _______________________________________________________________ 35

5.2. Az MVK pénztármodul ______________________________________________________________ 38

5.3. Jegykezelő modul____________________________________________________________________ 39

5.4. Ellenőr modul ________________________________________________________________________ 41

5.5. Websocket ____________________________________________________________________________ 42

5.6. A programok _________________________________________________________________________ 45

5.7. LabVIEW Program ___________________________________________________________________ 48

ÖSSZEFOGLALÁS ______________________________________________________________________ 52 6.

SUMMARY ______________________________________________________________________________ 53 7.

IRODALOMJEGYZÉK __________________________________________________________________ 54 8.

ÁBRAJEGYZÉK __________________________________________________________________________ 57 9.


BEVEZETÉS 1.

A szakdolgozatomban feladatul tűztem ki egy olyan jövőbe mutató, mégis jelenleg

rendelkezésre álló eszközök segítségével létrehozható utasszámláló rendszernek az

elméleti megvalósítását, aminek rengeteg pozitív hozadéka lehet egy város

tömegközlekedésének az életébe. Milyen jó is volna, ha pontosan tudnánk azt, hogy az

érkező buszon van-e még ülőhely, vagy érdemesebb megvárni az öt perccel később

érkező, de ugyanaddig közlekedő járatot. A folyamatosan, valósidőben figyelt adatokat

mindenki tudná hasznosítani, kapacitások szabadulnának fel a helyi közlekedési

rendszerben, amiket könnyedén, az igényeket pontosan, naprakészen ismerve tudná az

adott közlekedési vállalat felmérni és kielégíteni.

A szakdolgozatom alapötletét egy másfél évvel ezelőtti londoni utazás valamint az

egyetemre járás mindennapos nehézségei adták. A másik elgondolkodtató ok az volt,

amikor egyik nap az egyetemre menet először egy 12-es autóbusz érkezett a megállóba,

majd mögötte nagyjából fél perccel egy 22-es jelzésű. A 12-es majdnem 100%-os

kihasználtságon közlekedett, a 22-esen már távolról is jól kivehető volt, hogy szabad

ülőhelyekkel is rendelkezik. Meglepettségemre csak másodmagammal vártam meg a

később érkező járatot, a többi egyetem irányába igyekvő ember próbált feljutni az

elsőként megálló buszra, amire nehezen szálltak fel a tömeg miatt. Ez nem fordulhatott

volna elő, ha valós időben is látják a várakozók a buszok aktuális kihasználtságát.

Kiindulási alapként a Miskolc Városi Közlekedési Zrt. jelenlegi járműparkját és

eszközeit használtam fel. A dolgozat témájához meg kell ismerni az aktuálisan

rendelkezésre álló utasszámláló rendszereket, ezek hatékonyságát összehasonlítani,

levonni a szükséges tanulságokat aszerint, hogy ésszerűen melyik az, ami optimálisan

alkalmazható a tárgyalt szisztéma körében.

A rendszer már a meglevő helyi utastájékoztató rendszereket használná fel. Ennek

okán a dolgozatomban felmérem a jelenlegi infrastruktúrát, a szükséges, beszerzendő

eszközöket költség és hatékonyság szempontjából.

Szintén a vizsgálandó témák közé tartozik a nem olyan régiben bevezetésre került,

az Európai Unió új általános adatvédelmi rendelete (GDPR), az ennek való teljes körű

megfelelés a rendszer kiépítése során. Ez 2019-ben abszolút nem elhanyagolható

sarkalatos pontja a kivitelezésnek, hiszen rengeteg információbiztonságot veszélyeztető

dolog léphet fel, akár szándékos adatlopások, akár véletlen nyilvánosságra kerülő


személyes adatok tekintetében. Ezeket az esetleges biztonsági réseket már több világcég

is megsínylette, gondolok itt a Facebookra például.

A jövőben létrehozandó NFC alapú jegy- és bérletkezelés szimulációjához

szükséges eszközök kiválasztása szintén a kutatás témája. Értem ez alatt egy

mikrokontroller beszerzését, mely képes arra, hogy az általam elgondolt logikus és

átlátható rendszert kezelje, valamint NFC kompatibilis legyen és megfelelő nagyságú

adathalmazt legyen képes tárolni, írni és olvasni. Ennek a szimulációs rendszernek az

összerakása alkatrészekből, a működéshez szükséges programok megírása lesz az utolsó

lépés a szakdolgozatomban.


UTASSZÁMLÁLÓ RENDSZEREK 2.

Az utasszámlálási tevékenység célja, hogy a személyszállítással foglalkozó

vállalkozás, vagy állami, önkormányzati tulajdonú cég a kihasználatlan járatok

megszűntetésével, vagy azok ritkításával költségcsökkentést érjen el. További cél az

utasok igényeinek felmérése, ahol szükséges, a meglévő járatok sűrítése, vagy akár új

járatok létrehozása és ezáltal újabb utasok tömegközlekedésben való részvételének

előidézése.

Az utasszámlálás lehet keresztmetszeti vagy célforgalmi számlálás. A

keresztmetszeti számlálásnál egy keresztmetszeten, egy aluljáró kimeneti pontján, egy

megállóban le és felszálló utasok számát rögzíti a számlálóbiztos. Ez történhet

papíralapon, kikérdezéssel, vagy valamilyen eszköz segítségével. Az eszköz lehet a

járművön helyet foglaló biztosnál, a jegykiadóban, vagy egyéb, a járművön elhelyezett

mérőeszközzel. Így megállapítható például, hogy szükség van-e ezen megállóhely

üzemeltetésére. A célforgalmi számlálás célja, hogy megtudjuk, mely irányok a

legnagyobb kapacitásúak az adott viszonylaton (viszonylat: a közúti járművek indulási

és végállomása közötti, az egymás után elhelyezkedő, a szolgáltatási előírásban rögzített

megállási helyeket magába foglaló szakasz.), tehát ez a „honnan-hová” számlálás. Itt

használatos még a kétjegyes rendszer, ami annyit tesz, hogy az utazóközönség kap egy

számmal ellátott kis papírdarabot, majd abban a megállóban, ahol leszállt, odaadja egy

számlálóbiztosnak. Továbbá megkülönböztethetünk manuális és automatikus számlálást

is, valamint a jegyet, mint eszközt felhasználjuk-e a számláláshoz, vagy nem.

2.1. Manuális rendszerek

A legkezdetlegesebb és igen egyszerű formája az utasszámlálásnak, amikor

embereket alkalmazunk a járaton, vagy a megállókban. Ők papíralapon, vagy különböző

segédeszközök segítségével becslik meg a járművön utazó személyek számát. Mivel

tényleg becslésről van szó, ezért hatalmas a bizonytalansági ráta, nő a hibafaktor, a

pontosság sem kielégítő. Budapesti tanulmányaim alatt volt szerencsém találkozni ilyen

jellegű utasszámlálással, ami egy napos diákmunka volt. A BKV (Budapesti

Közlekedési Vállalat) megbízásából az M3-as metróvonal utasainak számára voltunk

kíváncsiak, reggel 8 és délután 16 óra között. Általában két-három ember ment ki a

megállókba, majd a metró érkezése előtt gyors becslést adtunk a felszállni kívánó

utasokra. Ez viszonylag pontosnak volt mondható, hiszen szépen lassan érkeznek az

emberek a két metrószerelvény közlekedése közötti időintervallumban. A nehézség


abban rejlett, hogy a leszálló utasokat is meg kellett számolni, itt a tömeg egyszerre

indul el a kijáratok irányába, nincs elég idő a pontos számláláshoz, gyakran csak

körülbelüli értékeket tudtunk mondani a leszálló emberek mennyiségére. Ezt a manuális

módszert minél hamarabb ki kell váltani a megfelelő technológia alkalmazásával, és

csak az automata rendszer referenciaértékének meghatározásához használni.

2.2. Automata rendszerek

2.2.1. Nyomásmérésen alapuló technológiák

Az egyik legrégebbi automatizált módszer az utasszámlálásnál a nyomásmérés, ez a

jegyeket nélkülözi a számlálásban. A lényege, hogy a légrugók terheléséből számít egy

értéket. Az érzékelő felfüggesztésnél van elhelyezve és egy elektropneumatikus szelep

segítségével küldi a jeleket a központi egységnek. Hatékonysága már 80% körüli is

lehet, ami már kielégítőnek vehető, viszont hangsúlyozandó, hogy a tényleges utasszám

gyakran eltérhet a valóságtól, hiszen egy átlagos emberi testtömegre vezetjük vissza azt,

hogy hány személy tartózkodik a járművön. Egy óvodás csoport felszállása máris olyan

problémát eredményezhet, ami nem várt eredményt hozhat és a valóságban a busz

sokkal terheltebb lesz, mint amire számítanánk a mért értékből. Ez néhány MAN SG

263 és SL 223 buszon alkalmazott módszer volt a korábbiakban itt Miskolcon, viszont

jelenlegi használatáról nincsenek információim.

A nyomásmérést lehet manapság már hatékonyabban is használni, hiszen elérhetőek

olyan, kvázi „szőnyegek”, amiket a busznak az ajtaja után szerelünk fel közvetlenül. Az

adott területnek a nyomását érzékeli, és így az előző megoldás legnagyobb hibafaktorát,

az átlagszámításból származó pontatlanságot ki is tudjuk szűrni, hiszen minden egyes

lépést külön-külön érzékel a mérőeszközünk. Normális karbantartás és használat esetén

ez a rendszer 95% körüli pontossággal dolgozik, ami nagyszerűnek mondható.

Természetesen ezt a rendszert is ki lehet játszani, hiszen egy súlyosabb bőrönd már

lehet, hogy meghaladja azt a súlyt, aminél a rendszer úgy fogja gondolni, hogy ez egy

ember. További hátrányként kell még említeni a lassabb utas cserét, mivel, ha egyszerre

több ember áll az adott felületen, már nem biztos, hogy jó értéket kapunk vissza. A

mechanikai részek karbantartás igényesek lehetnek, főleg takarítás szempontjából. A

gyakori és nagy utas cserét lebonyolító helyi járatokon ennek alkalmazását nem tartom

kifizetődőnek, helyközi járatokon viszont abszolút jó megoldás. [1]


2.2.2. Kamera és infravörös érzékelők a buszon

Az alább bemutatandó megoldások még továbbra sem használják fel a jegyet, mint

számlálásra alkalmazható eszközt. A belső kamera rendszere a busznak (CCTV) egy új

és talán nem annyira használatos módja a számlálásnak. Itt a közlekedési vállalat

munkatársai egy irodában hozzáférnek a buszok fedélzeti kameráinak képeihez valós

időben, és így nyerik ki az adatokat. A módszer egészen pontosnak mondható, hiszen

két megálló között megszámolható az összes utas egyenként, viszont több ember

alkalmazása szükséges hozzá. Ugyan valós idejű a mérés, de kampányszerű, a

folyamatos adatgyűjtés és megfigyelés nem lehetséges abból kifolyólag, hogy irreálisan

sok embert kellene alkalmazni, valamint nekik is folyamatos figyelemre lenne

szükségük a kívánt pontosság eléréséhez. Referenciaérték beállításához viszont teljes

mértékben alkalmas. További probléma ezzel a rendszerrel, hogy munkaerő

megtakarítással nem jár, sőt akár még növelheti is a költségeket az újabb

számlálóbiztosok esetleges felvétele. Az emberek számára is negatívan hathat, hogy

folyamatosan meg vannak figyelve, hiába fogadják el a buszon vagy villamoson való

utazással azt, hogy róluk képanyag készülhet, ezért valóban felvethet némi etikai

kérdést ennek a módszernek az alkalmazása. Így a várt utasszám növekedés elmaradhat,

sőt akár még többen fordulhatnak el a közösségi közlekedés használatától.

Az ajtók felé is szerelhetőek sztereókamerák, ilyen berendezés látható az 1. ábrán, ami

képes megkülönböztetni a le- és felszálló utasokat, a mozgási irányukat elemezni, el

tudja különíteni az emberi alakokat még zsúfoltság esetén is. A pontossága 96% feletti

is lehet, amiből látható, hogy az egyik legjobb elérhető megoldás. A berendezés csak

nyitott ajtónál számol. Ami ellene szól az a relatíve magas költség, viszont semmilyen

más rendszert nem kell mellé alkalmazni, képes az adatokat akár Excelbe, akár

adatbázisba menteni a központi egységről. Ethernet interfészen keresztül vannak

felfűzve az ajtóba kerülő szenzorok, tehát a kommunikáció és az adatátvitel igen gyors.

[2]

1. ábra: Sztereó kamera [2]


Az infravörös érzékelő talán a jelenleg legelterjedtebb utasszámláló berendezés.

Előnye egyértelműen a könnyű implementációból, az igénytelenségéből és a magas

pontosságából ered. Az ajtó felé felszerelt eszközökben nincsenek mozgó alkatrészek,

ezért elromlani sem fog könnyedén. Az utasnak gyakran fel sem tűnik, hogy éppen

utasszámlálás folyik a járművön. Az utóbbi években hatalmas fejlődésen mentek át a

rendszerek és már 3D-ben is képesek leképezni az egész teret, így már 90%, vagy

kevéssel afeletti hatékonyság is megvalósítható velük. A 2. ábrán látható

berendezésekhez hasonlóak egyes CNG buszon is megtalálhatóak, sajnos a logikát

abban, hogy mi alapján választanak ki egy-egy buszt arra a célra, hogy ilyen eszközzel

felszereljék, nem ismerem. A számlálás az ajtó záródása után történik meg. A német

telephelyű Iris cég Irma Matrix terméke már felhő alapú tárolást is támogat, ezáltal

folyamatosan valósidőben elérhetőek a terheltségi adatok akár az utasok számára is egy

applikáción keresztül. Úgy gondolom ennek a gyorsasága és elérhetősége igazi 21.

századi megoldás. Zavaró tényező lehet, hogy az elektrosztatikus jelek zavarhatják az

érzékelő jeleinek a vételét, valamint a jármű, szintén infravörös jellel működő ajtózáró

eszközei is hibát okozhatnk. Az elektronikus jegyrendszerrel összekötve már a bliccelők

számát is meg tudjuk mondani. [3]

2. ábra Infrakapu [3]

2.2.3. Jegyalapú megoldások

A jegykiadó automata is képes lehet számolni az utasokat, ám nem túl jó megoldás,

hiszen a bérlettel utazók eltűnnek a rendszerből, így kötelező egy másik módszer

használatával együtt alkalmazni. Ha nincsen minden buszban ilyen jegykiadó, akkor

már csak adott járatokon tudunk mérni. Ez a probléma felmerült nem olyan régen az


ÉMKK Zrt.-nél, amikor is a tiszaújvárosi, ilyen jegykiadóval felszerelt buszok járták

végig egész Borsod-Abaúj-Zemplén megyét, kellemetlenséget okozva ezzel sofőrnek,

irányítóknak, szerelőknek, és persze az utasoknak is. Ettől jobb megoldás, amikor a

jegykezelőbe van integrálva az utasszámláló modul. Ilyenkor a bérletkártyákat, mint a

bankkártyát a pénzfelvételkor beledugjuk a kezelőbe és utána mehetünk tovább.

Hátránya, hogy lassítja az utascserét valamint mindenkinek személyre szóló kártyával

működne csak. A vezeték nélküli kommunikációs eszközök elérhetőségének idejében a

legjobb megoldás lehet ezek alkalmazása a jegykezelőknél is. [4]


A MEGLÉVŐ INFRASTRUKTÚRA 3.

A következőkben bemutatásra kerülnek az MVK Zrt. kötelékébe tartozó, jelenleg

elérhető eszközök és rendszerek.

3.1. Járművek

Az alábbi két táblázatban az autóbuszok darabszáma és főbb paraméterei vannak

feltüntetve, ezek azon járműveket is tartalmazzák, amelyek esetleg tartósan le vannak

állítva alkatrészre várás, vagy egyéb ok miatt.

1. táblázat

MVK zrt járműállomány

Kivitel Alacsonypadló NFC képes

jegykezelő

MAN SL 223 Szóló Nem Nem

MAN SG 263 Csuklós Nem Nem

MAN NL 223 Szóló Igen Nem

Neoplan N4522 Centroliner Csuklós Igen Nem

MAN LIONS CITY A40

CNG Csuklós Igen Igen

MAN LIONS CITY A21

CNG Szóló Igen Igen

Enterprise Plasma Midi Igen Nem

2. táblázat

MVK zrt járműállomány

WiFi Beltéri utastájékoztató

monitor Darabszám

MAN SL 223 Nem Nem 9

MAN SG 263 Elenyésző

számban Nem 29

MAN NL 223 Nem Nem 6

Neoplan N4522

Centroliner Igen Elenyésző számban 35

MAN LIONS CITY

A40 CNG Igen Igen 35

MAN LIONS CITY

A21 CNG Igen Igen 40

Enterprise Plasma Nem Nem

1db,

üzemképtel

en


Ezen járművek nagy része nincsen felszerelve semmilyen utasszámláló

berendezéssel. Kivételt képeznek a már említett nyomásmérésen alapuló rendszerrel

ellátott magas padlós, régebbi SG és SL szériás MAN autóbuszok, néhány CNG szériás

autóbuszon pedig az ajtókhoz felszerelt kamerával figyelik az utasmozgást. Ezen felül

kiemelendő, hogy közel minden autóbusz vezeték nélküli interneteléréssel van ellátva.

3. ábra: Egy CNG-s busz [5]


3.2. Jegykezelő

A lengyel R&G által gyártott KRG-6KB0 típusú jegykezelők már NFC

kompatibilisek, ezek az összes CNG buszon elérhetőek. A 4. ábrán a citromsárga színű

rész az, ahová a kártyát érinteni kell. A jegykezelőbe a jegyet behelyezve papírszemét

egyáltalán nem keletkezik, lyukasztás helyett bizonyos információkat nyomtat a jegyre.

A többi buszba, amelyeken nem elérhető, sajnos be kellene szerezni ezeket az

eszközöket. Egy gyors számolás után kiderül, hogy nagyjából 300 darab ilyen készülék

megvételére lenne szükség a teljes lefedettséghez, ha minden régebbi busz, minden

ajtajához akarunk tenni egy ilyen berendezést.

4. ábra: Jegykezelő egy CNG-s buszon


3.3. OBU

A magyar HC-Linear által gyártott OBU (On-Board-Unit) egy modern eszköz,

amely már az összes buszban megtalálható. Az 5. ábrán egy Miskolcon is használatos

OBU látható. Többek között az utastájékoztatást is elvégzi a megállólista és a

helymeghatározás alapján, a német Bustec által gyártott beltéri TFT (LCD) kijelzőkön

(vékonyréteg-tranzisztoros folyadékkristályos kijelző). Ez az eszköz kommunikál a

központi szerverrel és a GPS műholdakkal, képes elfogadni az elektronikus jegyeket is.

Valamint a buszsofőrnek is rengeteg hasznos információval szolgál, például az eltérést a

menetidőtől (menetidő: A kiinduló végállomásról való elindulástól az érkező

végállomásra való megérkezés közötti időtartam). A szerepe a fedélzeti berendezésnek

abban lehet, hogy a rendszernek szüksége lehet a busz egyedi azonosítójára, valamint a

járatszámra a működéshez, az OBU pedig ezen adatok birtokában van jelenleg is, sőt a

sofőrt is tudja azonosítani. Telefonként is működhet, valamint a diszpécser üzeneteket

tud küldeni a sofőrnek, ami akkor hasznos, ha mondjuk valami késés miatt a fordulóba

egy másik állomási tartalék buszt kell küldeni, hogy ne okozzon további késéseket a

járaton.

5. ábra: Az OBU [2]

3.4. Kültéri Kijelző

Szintén a HC-Linear fejlesztése a kültéri kijelző, minden nagyobb forgalmú

megállóban megtalálható a városban. GPRS segítségével kommunikál a szerverrel, és

folyamatosan frissíti az érkezési időket (maximum 5 másodperces késéssel) a

megállókban. Ezek mellett a pontos időt és a hőmérsékletet is jelzi. A nagyfelbontású


LED mátrix technológiás kijelzők képesek arra is a már említett funkciókon kívül, hogy

a vak és gyengén látó utasok számára hanggal mondja be az aktuális menetrendi

információkat. Egyéb fontos üzeneteket, terelésekről, kimaradásokról, havária

eseményekről is kiírathat a diszpécser a táblákra. A havária egy olyan, előre nem látható

esemény, ami zavart hoz létre a közlekedés rendszerében, késésekhez, kimaradásokhoz

vezet. Általában valamiféle természeti jelenség okozza, de lehet emberi tevékenység is a

kiváltó esemény, például baleset. A 6. ábrán egy ilyen kijelzőről készült a fotó, az egyéb

információk közlésére közvetlenül a Miskolc szó feletti LED-ek használatosak. Sajnos

jelenleg nem minden megállóban elérhető ez a szolgáltatás, valamint többféle méretben

vannak felszerelve szerte a városban. Ennek a bővítése ugyan nem alapkövetelmény a

rendszer használatához, hiszen az igazán jelentős utasforgalmat lebonyolító megállók

mindegyikében megtalálható a kijelző tábla, ugyanakkor a későbbiekben megfelelő

források rendelkezésre állása esetén javasolt azokba a megállókba való kihelyezése,

ahol jelenleg még nem elérhető ez az eszköz.

6. ábra: Utastájékoztató tábla


3.5. MobilON alkalmazás

A miskolci hivatalos menetrendi applikáció Android rendszerekre MobilON

nevezetű alkalmazás. A hivatalos adatbázis alapján működő program mindenkinek

elérhető ingyenesen. 2020 márciusában lett lecserélve a TransIT néven futó alkalmazás,

egy, a Miskolci Zöld Nyíl projekt után bevezetett új arculathoz illeszkedő applikációra.

Az egyik legfontosabb változás az, hogy a menetrendje képes arra, hogy az aktuálisan

kimaradó járatokat is jelezze a nap folyamán, sajnálatos módon erre többször láttam már

példát. Megjeleníti térképen a járatok aktuális pozícióját, jelzi az esetleges eltérésüket a

menetrendhez képest és a megállóba érkezés valós várható idejét. A 7. ábrán az

alkalmazás működés közben látható, amint a 14-es járat aktuális pozícióját jeleníti meg.

Újdonság, hogy a megállóra lépve láthatjuk a Google térkép Street View

szolgáltatásával a megállót. Utazástervezést, valamint a statikus menetrendeket is

elérhetjük, minden egyes megállóra szűrve. Az adatok folyamatosan aktualizálva

vannak, bár erről személy szerint negatív tapasztalataim vannak és gyakran lemarad

egy-egy frissítéskor pár menetrend. A program alapjául a General Transit Feed

Specification (GTFS) menetrend-adatbázis szolgál, amely bárki számára ingyenesen

letölthető az aktuális vonali információkkal az MVK Zrt. honlapjáról. Ez azt jelenti,

hogy bárki tud szerkeszteni magának egy Androidos menetrend applikációt, aki

szeretne. Az e-jeggyel kapcsolatos, alkalmazás fejlesztéséhez tartozó gondolataimat a

saját rendszer megvalósítása alatt fejtem ki. [2] [5]

7. ábra: A MobilON alkalmazás


3.6. A koronavírus hatásai

Amikor elkezdtem a szakdolgozat írni, akkor még álmaimban sem gondoltam

volna, hogy egy világjárvány nehezíti meg a munkámat, valamint előidéz olyan

változásokat a mindennapi életben, és így a közösségi közlekedésben is hazánkban, amit

mindenféleképpen egy, a védés idejében is naprakész szakdolgozatban kötelességemnek

tartok megemlíteni. Történt hát, hogy a veszélyhelyzet kihirdetése után márciusban

bevezették a járművezetők védelme érdekében a hátsó ajtós felszállási rendet az

autóbuszokon. Ez ellehetetlenítette a sofőröknél történő jegyvásárlási lehetőségét, ami a

helyközi, Volánbusz Zrt. által üzemeltetett vonalakon ugyan sokkal komolyabb

problémát eredményezett, de mint a dolgozatomból kiderül, Miskolcon is a helyi

utazások egy nem elhanyagolható része helyszíni jegyváltással történik a buszvezetőnél

megvett jegyekkel. Hogy mégse maradjanak jegy nélkül az utasok, ezért a Nemzeti

Mobilfizetési Zrt. Közlekedési Mobiljegy applikációja elérhetővé vált az egész

országban a tatabányai tesztüzemet követően, tehát országszerte lehet már elektronikus

jegyeket használni azóta. Március 27-én pedig Miskolc és az MVK Zrt. is csatlakozott

azokhoz a városokhoz, vállalatokhoz, ahol a helyi közlekedés is benne van az

alkalmazásban. Természetesen a hirtelen bevezetés, valamint az egyébként is a vírus

miatt teljesen megváltozott napi élet nem tett jót a projektnek. Sok hiba, fizetési

nehézségek, bizonyos jegy- és bérlettípusok hiánya tette kellemetlenné az alkalmazás

használatát, ezen viszont azóta a szoftverfejlesztőknek hála, sokat javítottak. Ami

viszont abszolút nincs megoldva, az a jegyek érvényesítése és érvényességének

vizsgálata. Az alkalmazás QR kódot generál a MÁV rendszeréhez hasonlóan. Nem lehet

minden megállóban ellenőr, a sofőr nem nézheti meg jelenleg, - illetve a legfrissebb

hírek szerint 2020. május 11-től Pest megye és Budapest kivételével visszaáll az első

ajtós felszállási rend és a buszsofőrök újra adhatnak ki papíralapú jegyeket - tehát a

bliccelés egy új fajtája jelenik meg ezzel, hiszen elég egy darab jegyet megvenni,

amennyiben senki nem érvényesíti, tekinti meg a jegyünket és azzal 12 órán keresztül

félelem nélkül utazhatunk. Azt gondolom, hogy a bevételkiesés egyébként most talán a

legkisebb rossz lehet, az egyáltalán nem utazó emberek egyébként is sokkal nagyobb

mínuszt produkálnak, mint azok, akik bliccelnek. Kíváncsian várom ennek a megoldását

tehát május 11-től, mivel az általam elképzelt NFC-s megoldásnak hasonló hátulütője

nem lenne. Sajnos az alkalmazásról nem tudok képet közölni, mivel le vannak tiltva a

képernyőfelvétel készítési lehetőségek benne, biztonsági okokból.


A RENDSZER ELMÉLETE 4.

A következőkben az általam kigondolt rendszert fogom ismertetni egészen a

kezdetektől. Fontos felhívnom rá a figyelmet, hogy nem valami teljesen újat szeretnék

kitalálni, hiszen sok helyen már évek óta működnek hasonló módszerek a

közlekedésben, bár nem feltétlenül vannak felhasználva az utasszámlálásra az eszközök,

noha képesek lennének rá. Célom az, hogy minél kevesebb befektetéssel, a helyi

tömegközlekedést segítő rendszer alapjait fektessem le.

Londonban a helyi közlekedési vállalat, a Transport for London (TfL) a világ egyik

legfejlettebb és szakmabeliek által ideálisnak tartott városi és elővárosi közösségi

közlekedési rendszerét üzemelteti az év minden napján. Az Oyster card Pay as you go

rendszere megkönnyíti a rengeteg ember gyorsabb átjutását a validációs pontokon,

valamint rendkívül fontos, hogy a zónahatárok segítségével nem fordulhat az elő, hogy

ugyanannyit kell fizetnem akkor is, ha csak egy megállót utazom, mint ha végállomástól

végállomásig közlekednék. Ez véleményem szerint egy olyan lehetőség, ami rengeteg

plusz utast tud bevonni a tömegközlekedés használatába, olyan módon, hogy olcsóbbá

és egyszerűbbé teszi au utazást. London tehát egy etalonként használható város, ami

ugyan összevethetetlenül nagyobb Miskolctól majd tízmilliós népességével, viszont

maga a rendszer nagy része implementálható városunkba is. [6]

A rendszer maga tehát a meglévő eszközöket is használná, hiszen így érhető el az,

hogy a beruházás összege kevesebb legyen attól, mintha minden eszközt újonnan

kellene megvásárolni, integrálni, valamint beüzemelni, ami figyelembe véve a város

anyagi helyzetét talán a legfontosabb dolog. Az alábbi ábrán azt mutatom be, hogy

miként áramolna az információ a meglevő, valamint a beszerzendő eszközök és

humánerőforrás között.


8. ábra: A rendszer blokkvázlata

Köztudott tény, hogy a forgalmi, vagy egyéb más okból megkéső busz egyre többet

és többet fog késni, hiszen a megállókba már azok az utasok is megjelennek, akik a

következő busszal mentek volna el. Ez azt eredményezi, hogy a késésben levő járat több

embert fog szállítani, ami komoly zsúfoltságot eredményez, több idő kell az

utascseréhez, ezáltal növelve a késést. A mai rohanó világban, minden egyes perc

számít és szeretjük, ha minél pontosabban, precízebben be tudjuk osztani a saját

időnket, de ez nem csak a mi kívánalmunk. A közlekedési társaságok is érdekeltek

abban, hogy a buszok kihasználtsága kielégítő legyen, de közben utasbarát is. A már

említett példában a 22-es autóbuszt megérte ugyan közlekedtetni, de az időpont

hibádzott. Ezt okozhatta a nem megfelelő menetrendi hangolás, vagy a már előbb

tárgyalt késési opció. A 22-es autóbusz a szakdolgozat befejezésének időpontjában

ideiglenesen kikerült a menetrendből.

A város szerkezete nagyon érdekes, van egy erőteljes kelet-nyugati tengely,

valamint egy észak-déli, ezek által nem egészen lefedve pedig az ország egyik

legnagyobb lakótelepe, az Avas. Az észak-déli vonalon többek között kórházak,

valamint egyetemünk is megtalálható, amelyek egyenként is jelentősen növelnék a

megforduló emberek számát, de így még komolyabb kapacitásokat igényelnek. A

mindenkori városvezetés célja lehet az, hogy folyamatosan növeljék a közösségi

közlekedésben résztvevők számát, hiszen a vállalat így egyre kevesebb saját forrást

igényel. A kisebb, vagy teljesen megszűnő dugók, a csökkenő környezeti terhelés


szintén rengeteg előnnyel jár, valamint egy sokkal élhetőbb települést eredményez. Egy

olyan megoldást kell hát találni, amivel pénzt spórolhatunk meg, át tudjuk csábítani a

potenciális utasokat a tömegközlekedési eszközökre, ahelyett, hogy autóba üljenek.

Ehhez viszont sok munka, kemény, pontos célok és elsősorban elhatározás szükséges.

Az rendszer bevezetése után sem állhat meg az élet, hiszen újabb és újabb kihívások

kerülhetnek felszínre, ami a menetrendi struktúra megváltozásával járhat, tehát járatok

szűnhetnek meg, vagy vonódhatnak össze, esetleg új járatok indulhatnak.

4.1. Az E-jegyek alapja

4.1.1. Az NFC

A negyedik ipari forradalom a szemünk előtt zajlik, ami tegnap még

elképzelhetetlennek tűnt, mára valós alternatíva, használható és elérhető megoldás. Az

innováció folyamatos, valójában 20-25 évvel ezelőtt ez az ötletem még fel sem

merülhetett volna, hiszen az eszközök nem is léteztek, vagy ha igen, elég kezdetleges

formában. Az Oyster Card rendszerét például 1998-ban kezdték el tervezni.

Ilyen például az NFC technológia is, melynek a szabványba vétele 2003-ra

datálható. Az NFC (Near Field Communication – Kis hatótávú kommunikáció), a

biztonságos, kis hatótávúvá korlátozott, RFID-n (Radio Frequency IDentification, azaz

Rádiófrekvenciás azonosítás) alapuló kommunikációs eljárás. Az NFC-s kártyán,

mérete egy bankkártyáéval megegyező lehet, egy parányi IC (intergrált áramkör) foglal

helyet, amelyben egy teljesen egyedi 7 bites azonosító található. A kártya része még egy

feltekercselt antenna, ami ha az olvasó berendezés jelét befogja, akkor felébreszti az

addig energia nélkül alvó állapotban levő integrált áramkört és visszajelzést ad. A

technológia viszonylagos biztonságosságát az adja, hogy a kártyát közel kell tartani a

leolvasóhoz. Nagyjából 20 centiméterre távolodhatunk el az olvasótól maximum,

esetünkben az NFC képes jegykezelőtől, tehát csak az veheti igénybe, akinél a kártya ott

van az adott időpillanatban. Az NFC technológia nem alkalmas nagysebességű

adatátvitelre, de ebben az esetben nincs is akkora mennyiségű adat, ami miatt erre

szükség lenne. Az adatkapcsolat így is elég gyorsan felépül és a járműre való

felhasználás akadálymentes lebonyolításához tökéletesen alkalmas.

Az NFC technológia további jellemzői:

Az NFC egy nyílt platformú technológia, amelynek különböző paramétereit az

NFC Forum szabályozza.


Az NFC technológia az RFID-re alapul és annak egy továbbfejlesztése,

specifikált változata. 13,56 MHz frekvencián üzemel.

Az NFC kommunikáció hatótávolsága nagyjából 20 cm, azonban a kapcsolat

minőségének optimalizálásának érdekében javasolt a készülékeket

összeérinteni.

Az NFC szabvány különféle sebességű átviteleket enged meg, például 106

kbps, 212 kbps és 424 kbps, valamint a lentebb tárgyalandó kártyának 848

kbps.

Az NFC kommunikáció alapelve rendkívül hasonló az RFID-s technológiához,

résztvevői minden esetben egy kezdeményező (initiator) és egy cél (target), kétirányú

kommunikáció esetén felváltva veszik fel ezeket a szerepeket a felek. Létezik olvasó/író

- tag (címke) kommunikáció – amikor egy olvasókészülék kiolvassa a célpont címkéből

a tárolt információt vagy újat/másikat ír a címke memóriájába. Esetünkben ez a módszer

lesz alkalmazva. Card emulation mode, (kártya emulációs mód) ez a fordítottja az

olvasó üzemmódnak, ekkor az aktív NFC készülék passzív címkeként viselkedik és egy

másik olvasókészülék számára szolgáltat információt, továbbá van a p2p (peer to peer)

kommunikáció. Amikor a kommunikáló felek mindkét tagja aktív olvasó eszköz és

felváltva kommunikálnak, az épp olvasó elektromágneses mezejét modulálja a

pillanatnyilag passzív címkeként viselkedő készülék, majd cserélnek. [7] [8]

4.1.2. A másik út, az RFID

A két technológia rendkívül hasonló, mégis alapelvükben és felhasználási

területükben különböznek. Az RFID technológia lényege, hogy közepes távolságról

(akár néhány méterről) azonosítható legyen egy megjelölt termék (csomag, szállítmány,

jármű), így függetlenítve a mozgás irányától és sebességétől, a fényviszonyoktól és

további zavaró tényezőktől a kód leolvasását és az azonosítást, pusztán a leolvasó

berendezés előtti elhaladás szükséges. A biztonság másodlagos, mert az információ nem

bizalmas jellegű, ritkán áll érdekében bármelyik félnek a csalás. A leolvasott fél mindig

csak egy azonosítót tartalmaz, melyet leolvasás-kéréskor kisugároz, és ezzel azonosítja

magát.

Az NFC technológiában azonban létfontosságú a biztonság, hiszen itt pénzügyi

műveletekről is lehet szó (PayPass), vagy egyéb pénzzel és személyes adatokkal

összefüggő információkról, amik nem jó, ha illetéktelen kezekbe kerülnek, ezért itt nem


engedhető meg, hogy bizonyos távolságon kívülről is olvasható legyen az eszköz. Az

egyik legalapvetőbb biztonsági intézkedés a működéséből fakad. Egy RFID címkét 5-10

méterről is ki lehet olvasni, és ahogy már fentebb említettem, az NFC kiolvasási

távolsága minimális. Ez az egyik legfontosabb, alapvető különbség egyébként közöttük.

A titkosítás többféleképpen is fellelhető az eszközökben. A teljesség igénye nélkül

megvédhetem az adataimat különféle jelszavakkal, aláírásokkal, kódokkal. A titkosítás

kiterjedhet az NFC-s eszköz memória blokkjára, ahol kriptográfiával vagy egyéb

módszerrel védik az adatainkat, de ha éppen folyik a kommunikáció két eszköz között,

akkor van lehetőség a kommunikációs csatorna titkosítására is. Persze lehetőségünk van

a kártya lezárására is, így nem lehet új adatot enélkül a kulcs nélkül felírni rá. Az NFC

technológia segítségével két olvasókészülék képes kommunikálni egymással, például

kapcsolat-átadáskor válik ez fontossá, amikor olyan, magasabb szintű kommunikációs

csatornát kívánunk megnyitni a két készülék között, amelyek használata során egy

előzetes kulcs megosztása szükséges (például Bluetooth vagy WiFi). Ha ezt a kulcsot

NFC kommunikáción osztjuk meg a két készülék között, akkor elkerüljük a lehetőségét

annak, hogy illetéktelen kezébe jusson a kulcs, valamint rengeteget egyszerűsödik a

csatlakozási folyamat, hiszen nem kell manuálisan begépelni a gyakran igen komplex

jelszavakat. [7] [8] [9] [10]

4.1.3. Mikrovezérlő, valamint NFC kártya választás

A mikrovezérlő kiválasztásában egyértelműen a könnyű beszerezhetőség, az NFC

könnyű implementálása volt a cél. Az STM32L433RC-P NUCLEO megfelelt a

kritériumoknak és a tanszék rendelkezik is ezen eszközzel.[11] Ugyanakkor a

programozásakor több akadály is felmerült, ami miatt az Arduino Leonardo

használatára váltottam. A Leonardo az ATmega32u4 16MHz-es alapra épül, ami képes

USB-n keresztül kommunikálni, 2db soros porton kersztül. 20 digitális I/O és 12 analóg

bemenettel rendelkezik. Könnyedén programozható az Arduino IDE felületen keresztül,

amihez rengeteg tesztprogram lelhető fel a Githubon, így az egész programnyelv (ami

C/C++ alapú) elsajátítható ezek alapján. Természetesen az is nagyon fontos volt, hogy

az NFC olvasót össze tudjam kapcsolni vele, valamint az ESP8266 is hozzáköthető

legyen, mert ezek nélkül nem válthattam volna erre a vezérlőre. Az ESP8266-n

keresztül kapcsolódhatok egy WiFi hálózatra, ezen keresztül megvalósítva az

utasszámlálást. [12]


9. ábra: Arduino Leonardo

A mikrovezérlőhöz kell egy NFC Shield, ez létesít majd kapcsolatot az NFC-s

kártyával. Az X-NUCLEO-NFC04A1 az Arduino Leonardo vezérlővel is kompatibilis

elvileg, de az ST mikrovezérlővel sikerült működésre bírni. I2C (Inter-Integrated

Circuit) kommunikációval kapcsolhatjuk hozzá. Ez a szabvány egy soros

buszkommunikáció, amelyben több mester és szolga is megtalálható. Az NFC tag egy

dinamikus M24SR64-Y panel és eköré van építve egy Arduino UNO R3 csatlakozó,

ami az egységnek a tápellátását biztosítja, 64 kbit EEPROM memóriával rendelkezik. A

már említett NFC és I2C szabványon kívül RFID-val is tud kommunikálni, valamint 3

LED is visszajelzést ad az eszköz állapotáról. [13]


10. ábra: NFC04A1

A piacon elérhető, legnépszerűbb NFC-s okos kártyák a MiFare termékcsalád.

Gyártójuk az NXP Semiconductors (volt Philips Semiconductors), akik a piacnak több

mint felét uralják. Itt néztem hát körbe, hogy melyik az a kártya és milyen áron, ami

tökéletesen megfelelne az elvárásoknak. A termékcsaládnak több tagja van, a Classic,

Plus, Ultralight, DESFire. Ezek a kártyák többek között a már említett Oyster card

alapjai is, de használják Malajziában, Hollandiában is utazáshoz többek között.

A választás a DESFire EV2-re esett volna eredetileg, mivel a titkosítási módszerei

sokkal fejlettebbek, mint bármelyik másiknak. A kártya az Advanced Encryption

Standard-nek (AES) és a TDES (Triple Data Encryption Standard) titkosítást is ismeri,

ezzel megfelel az EAL5+ szabványnak is, ahol az EAL7 az elérhető legmagasabb szint.

Több féle memóriamérettel rendelhető, 2, 4, 8 kilobájt EEPROM lehet, ebből

véleményem szerint a 4 kilobájt elegendő. A kommunikáció sebessége akár 848 kbps is

lehet. Különösen ajánlják fejlett közösségi közlekedési rendszerekben való

alkalmazásokhoz. A kártya szélsőséges körülményeknek is ellenáll, gondolok itt a


hőmérsékletre, hiszen közvetlen napfénnyel találkozhat. A gyártó szerint 500000

műveletet képes elvégezni élete során és 25 évig tárolja az információkat. Gyors

körültekintés után kiderül, hogy a legtöbb értékesítő cég 10 év körüli garanciát vállal

rájuk. Eladási áruk 2-3 Euró környékén változik, ami jelenlegi középárfolyamon 650-

1000 Forint. Optimista becslések szerint ebből, ha a város minden lakójával számolunk

és a turistákat is belekalkuláljuk, akkor 200 ezer darabot kell vennie a városnak, ami

120 millió forint. Ha hozzávesszük a már korábban tárgyalt 300 jegykezelő berendezést,

aminek darabára 150 - és 200 ezer forint között változik, akkor a projekt összköltsége

megáll 200 millió forintnál. Ehhez természetesen lehet pályázni különböző forrásokra

az Európai Uniótól, vagy az államtól elég jó eséllyel, így a valós ráfordítás kevesebb

lehet. [14] [15] [16]

11. ábra: A DESFire EV2 chip blokkvázlata [17]

A szimulációhoz azonban nem ezt a kártyát fogom használni, mivel a

Magyarországon történő beszerzése igencsak nehézkes és drága lett volna, a külföldi

oldalakon, ahol az árat is megfelelőnek találtam, csak nagyobb tételeket lehetett

vásárolni, ezért egy kompromisszumos megoldást kellett választanom. Így jutottam el a

Mifare Plus X kártyához, ami 500 Forintos darabárával költségkímélő megoldás volt

számomra. Fontos szempont volt az is, hogy az NFC04A1 modullal mindenképpen

tudjon kommunikálni, erre az alap Mifare Classic kártyák az interneten fellelhető

információk alapján nem képesek, vagy legalábbis nem minden esetben.


12. ábra: A MifarePlusX kártya

Ezenkívül, ha már a szakdolgozatom egyik bekezdése az adatbiztonságról szól,

akkor kötelességemnek éreztem egy olyan NFC-s kártya beszerzését, ami egy bizonyos

fokú biztonsági előírásnak megfelel (Advanced Encryption Standard), tehát ennek a

hiánya szintén nem megfelelővé tette a Classic sorozat kártyáit. Végül ez a biztonsági

követelmény nagyban meghatározta a továbbiakban a szakdolgozatom további

elkészítését. A Mifare Plus X 2 kilobájt-os memóriával rendelkezik, EAL4+ biztonsági

standardnak felel meg, ami ugye egy szinttel kisebb, mint az eredetileg használni kívánt,

valamint az esetleges tényleges megvalósításnál javasolt DESFire kártya. Az írási

életciklusa is kevesebb, hiszen csak 200000 darab írást visel el átlagosan a DESFire

félmilliójával szemben, de ha végiggondoljuk, hogy ez napi 4 utazással is több, mint

100 évig elég, akkor megnyugtató a teljesítménye. Adatmegőrzési garancia egyébként

10 év van rá. A kommunikáció sebessége a már említett 848 kbps-ot is elérheti

megfelelő eszközök esetén. [18]

A kártya megfelel az ISO/IEC 14443 szabványnak is, ami az érintésnélküli kártyák

(tehát nem szükséges bedugni egy olvasóeszközbe, mint mondjuk a bankautomatáknál)


jellemzőit adja meg 4 külön fejezetben, úgy, mint fizikai paraméterek, rádiófrekvencia

teljesítménye és jeltovábbítás, inicializálás és ütközésvédelem, valamint átviteli

protokoll. A fizikai paraméterek azt mondják meg, hogy a kártyákat hogyan kell

gyártani, összeszerelni. A jeltovábbításnál a moduláció, a frekvenciatartomány, amit

használ, a kommunikáció létrehozása és irányai vannak meghatározva. Az inicializálás

pedig magával a kommunikációval foglalkozik csak, a kezdetétől a végéig, miután

létrejött a kapcsolat. Ezek szerint a kártyák lehetnek A, vagy B típusúak. A 13. ábrán az

NFC-s eszközök szabványai láthatóak, amiből kiderül, hogy bizony nem fedi le az

ISO/IEC 14443 szabvány az egész NFC működését a kártyának tehát nem csak ezen

szabványnak kell megfelelni, mivel az NFC kommunikációval kapcsolatban egy másik,

ISO/IEC 18092 szabvány is érvényben van, így ennek az összessége szükséges. Ez

utóbbi nagyon sok mindenben egyezik az ISO/IEC 14443 szabvánnyal, azonban az

átviteli protokoll egyértelműen az NFC-re van definiálva, az üzenetek formai

követelményei, mint a hosszúsága, valamint a kódolása. Továbbá a P2P

kommunikációt, az olvasás/írás módot, valamint az eszközök aktív vagy passzív

állapotát is definiálja a kommunikációban, amire az alap szabvány nem képes. [19] [20]

13. ábra: Az NFC-hez kapcsolódó szabályozások [9]


14. ábra: A Mifare Plus X blokkvázlata [18]

4.2. A GDPR és egyéb aggályok

A General Data Protection Regulation (GDPR), egy új és jelentős adatvédelmi

rendelet, ami 2018-ban lépett hatályba az Európai Unióban. A továbbiakban a rendelet

kiemelten fontos részleteit idézem.

1. A törvény célja

„1. § E törvény célja a hatálya alá tartozó tárgykörökben az adatok kezelésére

vonatkozó alapvető szabályok meghatározása annak érdekében, hogy a természetes

személyek magánszféráját az adatkezelők tiszteletben tartsák, valamint a közügyek

átláthatósága a közérdekű és a közérdekből nyilvános adatok megismeréséhez és

terjesztéséhez fűződő jog érvényesítésével megvalósuljon.

2. A törvény hatálya

2. § (1) E törvény hatálya - a személyes adatok tekintetében a (2)-(6) bekezdésben

meghatározottak szerint - minden olyan adatkezelésre kiterjed, amely személyes adatra,

valamint közérdekű adatra vagy közérdekből nyilvános adatra vonatkozik.

4. A személyes adatok kezelésének alapelvei

4. § (1) Személyes adat kizárólag egyértelműen meghatározott, jogszerű célból, jog

gyakorlása és kötelezettség teljesítése érdekében kezelhető. Az adatkezelésnek minden

szakaszában meg kell felelnie az adatkezelés céljának, az adatok gyűjtésének és

kezelésének tisztességesnek és törvényesnek kell lennie.


(2) Csak olyan személyes adat kezelhető, amely az adatkezelés céljának

megvalósulásához elengedhetetlen, a cél elérésére alkalmas. A személyes adat csak a

cél megvalósulásához szükséges mértékben és ideig kezelhető.

(3) A személyes adat az adatkezelés során mindaddig megőrzi e minőségét, amíg

kapcsolata az érintettel helyreállítható. Az érintettel akkor helyreállítható a kapcsolat, ha

az adatkezelő rendelkezik azokkal a technikai feltételekkel, amelyek a helyreállításhoz

szükségesek.

(4) Az adatkezelés során biztosítani kell az adatok pontosságát, teljességét és - ha az

adatkezelés céljára tekintettel szükséges - naprakészségét, valamint azt, hogy az

érintettet csak az adatkezelés céljához szükséges ideig lehessen azonosítani.

(4a) Az adatkezelés során arra alkalmas műszaki vagy szervezési - így különösen az

adatok jogosulatlan vagy jogellenes kezelésével, véletlen elvesztésével,

megsemmisülésével vagy károsodásával szembeni védelmet kialakító - intézkedések

alkalmazásával biztosítani kell a személyes adatok megfelelő biztonságát.

(5) A személyes adatok kezelését tisztességesnek és törvényesnek kell tekinteni, ha

az érintett véleménynyilvánítási szabadságának biztosítása érdekében az érintett

véleményét megismerni kívánó személy az érintett lakóhelyén vagy tartózkodási helyén

felkeresi, feltéve, hogy az érintett személyes adatait e törvény rendelkezéseinek

megfelelően kezelik és a személyes megkeresés nem üzleti célra irányul. A személyes

megkeresésre a munka törvénykönyve szerinti munkaszüneti napon nem kerülhet sor.”

[21]

Ezek szerint semmi olyan személyes adat nem kerülhet nyilvánosságra, amihez az

adat tulajdonosa nem adta engedélyét. Ilyen személyes adatnak minősül a név, születési

dátum, viszont egyéb, jóval komplikáltabb, eddig nem megfelelően őrzött adatok, mint

az egészségügyi állapot, a politikai beállítottság, a szexuális orientáció, különböző

szokások. Az adatainkat bármikor töröltethetjük, módosíthatjuk, ellenőrizhetjük, vagy

átvihetjük egy másik platformra. A gyerek védelme 16 év alatt sokkal szigorúbb, ez

alatt a kor alatt, csak szülői beleegyezéssel tárolhatjuk az adatait a gyermeknek.

Adatvesztés, támadás esetén a tároló vállalatnak 3 napon belül kell szólni az illetékes

Nemzeti Adatvédelmi és Információszabadság Hatóságnak (NAIH).

Mivel az utazáshoz szükséges valamilyen igazolvány a kedvezménnyel utazóknál,

ezért a közlekedési társaságnak is adatkezelési és tárolási meg kell felelnie. Ez azt


jelenti, hogy a diákigazolvány száma, oktatási azonosítója nem kerülhet fel az E-jegyre

minimális titkosítás nélkül. Ezt a megfelelő titkosítású kártyával, például valamilyen

visszafejthetetlen kódolással, könnyedén ki lehet védeni. A másik megoldás pedig az,

ha az NFC kártyán csak egy bizonyos kód jelzi a megválasztott bérlet típusát és a

kedvezményre jogosító iratokat az ellenőrnek ezentúl is fel kell mutatni, ahogy az

napjainkban is zajlik.

Más kérdés az applikáción keresztül vásárolt jegyek/bérletek kezeléséhez szükséges

személyes adatok kiberbiztonságilag megfelelő védelme. Ehhez használhatjuk a

hasítófüggvényeket (Hash). Nem régen ugyanis a BKK, T-Systems által fejlesztett

rendszere nagyot bukott, hatalmas biztonsági réseket hagytak az adatainkra pályázó

hackerek számára. A regisztrációt bárki tudta törölni akármilyen személyes igazolás

nélkül, hamis jegyeket lehetett készíteni, egy bérletet lehetett sokszorosítani és

mindegyikkel utazni, anélkül, hogy bárkit elkaptak és felelősségre vontak volna a

bizonyos etikus hackeren kívül, aki ezt a hibát felfedezve szólt az illetékeseknek.

Rengeteg probléma, amit figyelembe kell venni egy ilyen rendszer készítésénél. Az

országban ilyen rendszer Debrecenben működik, ott az adatvédelmi nyilatkozat

elfogadása, valamint a captcha (a számítástechnikában olyan automatikus teszt, ami

képes megkülönböztetni az emberi felhasználót a számítógéptől.) kitöltése után a

személyigazolvány szám, vagy diákigazolvány szám megadása kötelező az

azonosításhoz és a biztonságos működéshez (csak az új típusúak használhatóak erre a

célra). A MÁV internetes jegyvételi rendszere pedig a név és születési dátum alapján

azonosítja az utazót. Applikáción keresztül szintén a MÁV rendszere működik eddig a

legmegbízhatóbban. A tavalyi év óta a Vonatinfó alkalmazáson belül lehetséges az E-

jegy vásárlása. Ezt személyesen is többször használtam már, egyedüli hibájának azt

mondanám, hogy az internet kapcsolatot gyakran gyengének érzékeli és így a

jegyvásárlás egyrészt hosszabb időbe telhet, másrészt meghiúsulhat. [16] [21] [22] [23] [25]

4.3. A Rendszer működése

Végül lássuk, hogyan működne a rendszer elképzeléseim szerint. Az utazni kívánó,

egy a mostaninál több helyen létrehozott bérletpénztárba besétál, majd az egyszeri letéti

díj után kap egy kártyát. Erre a kártyára feltöltik a kívánt bérlet, vagy jegytípusokat.

Minden jegy és bérlettípus kapna egy egyedi kétkarakterű azonosítót, ezek szintén

feltöltésre kerülnének a tag-re. Bérlet esetén az érvényességi idő vége szerepelne a

kártyán, év, hó, nap. Jegyeknél bevezetném az érvényességi időt, egy vonaljeggyel 1


órán keresztüli utazást biztosítanék a városban, amiben egy átszállás is benne lehet. Ez

az új jegykategória lenne az úgynevezett átszállójegy, amit későbbiekben pontosan

definiálok. Természetesen az eredeti vonaljegy is megmaradna.

Ezen kívül a járművezetőknél kapható, papír alapú jegyek árát sokkal magasabbra

pozícionálnám, egy átmeneti, nagyjából 6 hónapos tesztidőszak után, mivel az általam

készített, nem reprezentatív kérdőív szerint ez egész magas visszatartó erőt jelentene.

Ezen kérdőív ismertetése később kerül tárgyalásra a dolgozatban. A 2017-es adatok

szerint több, mint 570 ezer jegyet adtak el a sofőrök, ez a szám igen magas, nagyjából

egyharmada az összes eladott jegynek. Látható, hogy az elővételben megvett jegyekhez

képest plusz 100 Forintos különbség nem gondolkodtatja el az embereket, hogy

érdemesebb hamarabb megvenni az utazásra jogosító eszközt. Az, hogy a buszokon

kvázi megszűnne a jegyértékesítés, a menetrendi tartalékidő csökkentésével járhat,

emiatt a buszok tényleges menetideje is csökkenne 1-2 percet. Az első ajtós felszállási

rend mellett a bliccelők száma nagyban csökkenthető lenne, hiszen a rendszer azonnal

szólna, fény és hangjelzéssel, ha valaki nem érvényes eszközzel akarna felszállni a

járműre. Mivel elviekben minden egyes embernek kötelező hozzáérinteni felszálláskor a

kártyáját, vagy alkalmazásban vásárolt jegy esetén az NFC képes okostelefonját a

jegykezelőhöz, ezért akár 100%-os pontossággal is meg tudjuk mondani azt, hogy az

elindulás után hányan tartózkodnak a járművön.

Leszálláshoz egy infravörös érzékelős rendszert vennék igénybe, ez így együtt egy

95% körüli eredményre lenne elég. Természetesen az infravörös érzékelő a felszállókat

is figyeli, ezért a bliccelők számát is meg tudjuk becsülni, ehhez persze egy pontos

algoritmust kell létrehozni, amely eldönti, hogy mekkora különbségnél, melyik eszköz

felszálló utasainak adatszámát vigyük a rendszerbe. Ha az NFC számol több embert,

egyértelműen azt kell preferálni. Ezen adatok megléte után, a buszon lévő OBU, mivel

tudja, hogy melyik típusú buszon van jelen, ki tudja számolni azt, hogy milyen az

aktuális kihasználtság. Ehhez nincsen másra szükség, csak a járművek kapacitására,

valamint az aktuális utasszámra. Ez a szám menne egy központi szerverre, minden

megálló után, azokkal az adatokkal együtt, ami a már most működő valós idejű

követéshez kell. Az adatok a külső kijelzőkön jelennének meg, ahol a jelenlegi

betűméret és struktúra mellé oda férne egy százalékos kijelzés. A kiírás a

következőképpen nézne ki tehát:

Járat-Célállomás-(Kihasználtság százalékban)-Várható érkezési idő.


12 Egyetemváros (81%) 10:43.

Az applikációban is jeleznénk, hogy a járat éppen mennyire van kihasználva. A

folthatás mérésekben már alkalmazott szisztéma szerint járnánk el, és minden aktuálisan

közlekedő busznál egy színes sáv jelenne meg. Ezek a színek a zöld, a sárga, a

narancssárga, és a vörös. A zöld jelentené azt az értéket, ahol még vannak szabad

ülőhelyek a buszon, a sárgánál már pár ember áll, a narancssárgánál már sok ember áll,

a vörös pedig 90% feletti értéknél jelenne meg, ez esetben a busz már igen zsúfolt,

utaslemaradás veszélye áll fent. Ez minden busztípusnál más és más utasszámot

jelentene. Az alábbi táblázatban lehet megtekinteni az adott férőhelyeket és a javasolt

százalékos értékek az alkalmazásban való megjelenítéshez.

3. táblázat

MAN SL

223

MAN SG

263

MAN LIONS CITY

A21 CNG

Ülőhelyek [db] 27 39 31

Állóhelyek [db] 73 111 55

Összesen [db] 100 150 86

Hány % ülőhely a férőhelyek

arányában 27% 26% 36%

Javasolt %-ok a jelrendszerhez

30%-ig 30%-ig 30%-ig

30-60% 30-60% 35-60%

60-90% 60-90% 60-90%

90% felett 90% felett 90% felett

4. táblázat

MAN LIONS CITY

A40 CNG

Neoplan

N4522

Centroliner

MAN

NL223

Ülőhelyek [db] 42 41 29

Állóhelyek [db] 114 97 71

Összesen [db] 156 138 100

Hány % ülőhely a

férőhelyek arányában 27% 30% 29%

Javasolt %-ok a

jelrendszerhez

30%-ig 30%-ig 30%-ig

30-60% 30-60% 30-60%

60-90% 60-90% 60-90%

90% felett 90% felett 90% felett


A folyamatosan monitorozott, valós utasszámok azonban nem csak az utasoknak

jelentenének segítséget, hanem magának a cégnek is. A mérési adatok alapján 2-3

hónapon belül egy kvázi tökéletes menetrendi struktúrát tudnának összerakni, ami

abszolút igazodna az aktuális utazási igényekhez. Ezeknek az igényeknek a változását

gyorsabban tudják lereagálni, mint eddig, sőt, akár a pontszerűen keletkező előre nem

jelezhető zsúfoltságot is tudják szinte azonnal kezelni és mentesítő járatot, vagy

másodrészt indítani. (Ilyen eset lehet egy iskolás osztály utazása). A rendszer további

előnye abban rejlik, hogy akár 10%-os utasszám növekedést jelentene pár hónapon

belül véleményem szerint. Ez főleg azokból az emberekből tevődik össze, akik csak

kényszerből ülnek autóba, akik mindig is azzal utaztak, azoknak az átcsábításához ezek

a fejlesztések sajnos nem elegendőek. Valamint a bliccelők számát is csökkentené, tehát

több bevétele származna a cégnek ebből a lépésből. A megtérülési időt becsléseim

szerint 5-10 év. A költségek csökkenésében a papírok használatának jelentős

visszaszorulása, valamint az esetleges személyi állomány (például kevesebb pénztáros

szükséges a bérletváltó helyeken, ha vannak automaták) leépítése is szerepet játszik. Az

ellenőrök egy olyan alkalmazást kapnának az NFC képes telefonjaikra, ami a beolvasott

kártyákról, vagy telefonokról származó információkat azonnal dekódolják és jelzik, ha

utazásra nem jogosult valaki, vagy ha kedvezményt vett igénybe és ehhez tartozó

jogosultságát igazolnia kell. A beolvasott adat a jelenlegi időbélyeges módszer elemeit

használná fel. A jegykezelő berendezés a kártyára írná az utolsó használat idejét, ebből

lehetne tudni, hogy az illető hozzáérintette-e felszálláskor az eszközét a jegykezelőhöz,

ha nem az bírsággal járna, akár van érvényes jegye/bérlete akár nincs. A jármű

négyjegyű azonosító számát, valamint az aktuális járatot szintén a kártyára írná.

Például: 1672431903312156

Az első négy karakter a 1672 számú busz, a következő két karakter az aktuális

járatot jelöli (43), az utolsó tíz karakter pedig az aktuális dátum, idő (2019. 03. 31.

21:56). A megálló sorszámát nem tartom szükségesnek felíratni, mivel az esetleges

bliccelésnél, majd az ellenőrök észrevételével a gyors érvényesítésnél az aktuális idő

kerül a kártyára, és nehezen lehet kimagyarázni, hogy egy perccel ezelőtt a busz még

két megállóval arrébb járt.

A kérdőívben két kérdést tettem fel. 47 fő válaszolt, a felmérésem nem

reprezentatív, volt, akit a Búza téren szólítottam le ugyan, de többségében az ismerősi


körömből kerültek ki. Az első kérdés így szólt: Mennyi az az összeg, amennyiért már

semmiféleképpen nem vásárolna vonaljegyet a buszsofőrnél? A jelenlegi ár 400 Ft.

15. ábra: Diagram

Az eredmények azt mutatják, hogy a válaszadók 40%-a már most sem él ezzel a

lehetőséggel, előre tervezi utazásait. Ők lesznek azok, akik zökkenőmentesen

átállhatnak a rendszerre. Fontos kiemelni, hogy a jelenlegi ár kétszeresétől többet csak

az emberek 15%-a lenne hajlandó fizetni vészhelyzet esetén. Úgy tűnik, hogy ez egy

lélektani határ, ezért a közlekedési társaságnak ezt a 800 forintos értéket javasolnám az

átmeneti időszakban, utána pedig még további áremeléssel sújtanám azokat, akik nem

hajlandóak kiváltani a kártyát.

A második kérdés a következőképpen hangzott: Mennyi az a maximális összeg, amit

egy E-jegy feltöltésére alkalmas kártyához letéti díjként kifizetne? A kártya leadásával

ez az összeg visszajárna Önnek.

19 40%

5 11%

7 15%

9 19%

5 11%

2 4%

Mennyi az az összeg, amennyiért már semmiféleképpen nem vásárolna vonaljegyet a buszsofőrnél? A jelenlegi ár 400 Ft.

(47 megkérdezett fő)

Már most sem vásároloksoha.

500 Ft

600 Ft

750-800 Ft

900-1000 Ft

Ha úgy adódna, ezektől istöbbért.


16. ábra: Diagram 2

A diagramban jól látszik, hogy az emberek nem szeretnek fizetni semmi esetben, az

összeg pedig nem nagy. Az időlegesen a városban tartózkodók miatt a letéti díj mellett

tettem le a voksom azzal szemben, hogy a kártyát véglegesen, saját tulajdonba kelljen

adni, azaz megvásárolni a cégtől. Ez a letéti díj persze a városlakóknál kicsit többről

szól, mint egy kölcsön, ők nem adják le egy hétvége után, ezért a kártyáért kapott

pénzösszegnek nem kell folyamatosan rendelkezésre állnia, ebből kifolyólag a projekt

árának veszteségét segíthet csökkenteni az adott évben, és ráér lassan visszapótolni a

tartalékot. Természetesen az a pénz sohasem lesz már annyi, mint a befizetéskor, hiszen

a kártyáért letett pénzösszeg az évek során folyamatosan inflálódik, 20 év időtávlatában

már jelentősen csökken az értéke. [5] [23] [26]

24 51%

7 15%

12 26%

3 6%

1 2%

Mennyi az a maximális összeg, amit egy E-jegy feltöltésére alkalmas kártyához letéti díjként kifizetne? A kártya

leadásával ez az összeg visszajárna Önnek. (47 megkérdezett fő)

Ingyen szeretném, habiztosítaná az MVK.

200 Ft körül.

500 Ft körül.

1000 Ft körül.

Ezektől is több.


SZIMULÁCIÓ ELKÉSZÍTÉSE 5.

A szimuláció elkészítéséhez szükségünk lesz három darab különböző

programrészletre, amik az NFC modulon keresztül vagy írást végeznek a kártyánkra,

vagy olvasást. Ez a három a következő:

MVK pénztármodul

Jegykezelő modul

Jegyellenőr modul

Az egyes modulok alapjaiban ugyanazokkal az információkkal dolgoznak, a lényegi

különbség az egyes programok között ezeknek a hozzáférhetősége lesz. Az utolsó,

jegyellenőrző modulnak mobilisnek kell lennie, tehát mindenféleképpen egy Androidos

alkalmazásban való manifesztálódása lenne célszerű, amit egy NFC képes (szerencsére

manapság közel minden okostelefon bír már ezzel a funkcióval) Androidot futtató

eszközre telepítenénk, és az ellenőrök könnyen, gyorsan használhatnák.

5.1. Jegy és bérlettípusok

Még mielőtt belekezdenék az egyes modulok részletes ismertetésébe, lássuk, hogy

milyen jegy és bérlettípusokkal képzelem el a rendszer működését.

Vonaljegy

Átszállójegy

Napijegy

Nyugdíjas jegy

Havi bérlet

30 napos bérlet

Félhavi bérlet

Hétvégi jegy

Szemeszter bérlet

Éves bérlet

Csoportos jegy

Ez 11 különféle típus, ezeket mind egy kétjegyű kóddal látnám el, 01 és 11 között. A

bérlettípusokhoz mindenképpen szükséges a kedvezményeket igazoló dokumentum,

vagy az arcképes igazolvány. A vonaljegy ára maradna a jelenlegi 300 Ft, ebből 10

darabonként - mint gyűjtőjegy - kedvezményt adnánk az árból. Minden érintésnél a


darabszám rekordja eggyel csökkenne, ameddig nem nulla, addig folyamatosan

biztosítja az utazást, amit pedig zöld LED-del jelez a rendszer.

Az átszállójegy árát valahová két db vonaljegy ára alá kell pozicionálni, mondjuk

500 Ft-ra. Ez a jegytípus egy időlimittel is rendelkezik, amit az első kezelésnél kap a

jegykezelőtől, majd ezt követően 60 percig lehet érvényesíteni a következő járaton.

A napijegy igazából egy bérlettípus, hiszen 24 órán keresztül korlátlan utazást

biztosít a járműveken.

A nyugdíjas jegy egy újdonság, mivel 65 éves kor felett a 85/2007. (IV. 25.) Korm.

Rendelet a közforgalmú személyszállítási utazási kedvezményekről foglaltakban

szerint, minden nyugdíjkorhatárt elért magyar állampolgár, vagy EU tagország esetleg

külföldi, de Magyarországon nyugdíjat kapó személy jogosult a 100%-os

kedvezményre, tehát utazása ingyenes. Elég hozzá a személyazonosságát és ily módon

az életkorát igazoló dokumentum felmutatása. Esetünkben azonban az utasszámláláshoz

elengedhetetlen, hogy az ingyen utazó idősek is érvényesítsenek egy kártyát a

felszálláskor. Ehhez természetesen egy irreálisan távoli lejáratú időpontot kell

érvényességi időnek megadni, mondjuk az évszázad végét. [25]

A csoportos jegy egy talán ismeretlen típus még, itt minimum 8 fő, de maximum 40

főig egy napi jegyet kínálunk, kedvezményes áron a szimpla 24 órás jegyhez képest.

Fontos előnye, hogy elég egy darab kártyát kiváltani, hiszen egy rekordba itt be lesz

írva az együtt utazók száma. A különféle bérletekhez nem fűznék komolyabb

magyarázatot, az alábbi táblázat remekül összefoglalja az adottságokat.

5. táblázat Jegyek kódjai

Típus Kódszám Érvényességi idő

Vonaljegy 01 Korlátlan

Átszállójegy 02

Első és második

kezelés között

maximum 60 perc

telhet el

Napijegy 03 A kezdő dátumtól

számított 24 óráig

Hétvégi jegy 04

A kezdő dátumtól

számított max. 72

óráig, csak pénteken

elérhető

Félhavi bérlet 05

A kezdő dátumtól

számított 15. napig

24:00


30 napos bérlet 06

A kezdő dátumtól

számított 30. napig

24:00

Hóközi bérlet 07 Következő hónap 5.

24:00

Szemeszter bérlet 08 Folyó év február 5.

vagy július 5. 24:00

Éves bérlet 09 Következő év

január 5. 24:00

Csoportos jegy 10 A kezdő dátumtól

számított 24 óráig

Nyugdíjas jegy 11 Korlátlan ideig

6. táblázat Jegyek kódjai

Típus Ár Kedvezmény

Vonaljegy 300 Ft

10 darabonként egy

darabárnyi

kedvezmény

Átszállójegy 500 Ft Nincs

Napijegy 1 500 Ft Nincs

Hétvégi

jegy 2 750 Ft Nincs

Félhavi

bérlet 3 500 Ft

50% elérhető az arra

jogosultaknak

30 napos

bérlet 6 000 Ft


jogosultaknak

Hóközi

bérlet 6 000 Ft


jogosultaknak

Szemeszter

bérlet 27 000 Ft

Fél havi kedvezmény

a rendes bérlethez

képest,


jogosultaknak

Éves bérlet 63 000 Ft

1,5 hónapnyi

kedvezmény


jogosultaknak

Csoportos

jegy 1000 Ft/fő Nincs

Nyugdíjas

jegy Ingyenes 100%


5.2. Az MVK pénztármodul

Ez a modul teszi lehetővé az NFC-s kártyára való jegy, vagy bérlet feltöltését.

Ilyenkor csak írás történik a kártyára. A pénztárosnak jelezzük, hogy milyen terméket

szeretnénk vásárolni, az 5. és 6. táblázatban kigondolt jelzések alapján ő beüti ennek a

kétjegyű kódját, majd amennyiben a leendő utas rendelkezik már NFC-s kártyával,

átnyújtja azt és rátöltik, amennyiben nincsen még neki ilyen, mivel mondjuk nem helyi

lakos, vesz egyet a forgókészletből. A rátöltést követően a fizetés után visszakapja az

utas a kártyát és így már érvényes utazásra jogosító eszközzel távozhat.

Könnyen belátható, hogy a folyamat kiszervezhető jegyautomatákba is. Ez abszolút

megfontolandó lépés lenne már középtávon is, hiszen ezek beszerzése, üzemeltetése pár

éven belül olcsóbbá válhat, mint a munkaerő bérigénye. További előnye lenne ennek,

hogy a nap bármely szakaszában elérhető, nincs kötve a bérletpénztárak munkaidejéhez

a vásárlásunk, valamint a város bármely pontján létesíteni tudunk ilyen automatákat,

természetesen a nagyobb átszállási csomópontokba, valamint forgalmas megállókba

érdemes a kihelyezésük. A szimulációban az egyik gomb segítségével lépkedünk a

programunk ciklusának paraméterein, amik megegyezőek a jegy és bérlettípusok

előbbiekben felvázolt kétjegyű kódjával. Tehát minden egyes típushoz egy külön

programrészlet tartozik, pontosan annyi, ahány paraméterből áll a ciklusunk. Ezt

követően a program veszi az aktuális időt, majd ebből számít egy lejáratot (már

amelyiknek van persze). Tehát az érintéssel a következő adatok kerülnek felírásra: A

lejárati idő, valamint a kódszáma a jegynek. Alább látható a modulnak a sematikus

ábrázolása.


17. ábra: A pénztár modul

5.3. Jegykezelő modul

A jegykezelőnek alkalmasnak kell lennie, mind az írásra, mind az olvasásra, hiszen

egyrészt be kell tudni olvasni az érvényességet, valamint egy időbélyeget is rá kell írni a

kártyára. Először tehát azt kell eldönteni, hogy milyen típusú jeggyel van dolgunk,

olyannal, aminek van felhasználási ideje, vagy olyan, aminek nincs. Itt is segítségünkre

lesz az 5. és a 6. táblázat a megértéshez. Amennyiben csak sima vonaljegyet

használunk, a kódja alapján azonosítja a program, majd a mennyiségi rekordban a

darabszámát eggyel csökkenti. Amennyiben ez nulla már, akkor a vörös LED villan fel,

amennyiben még több, a zöld. Ilyenkor ugrunk az új ciklusba és írunk a kártyára. Itt

több dolgot is állíthatóvá kell tennünk, hiszen nem mindegy, hogy melyik buszon

utazunk, nem mindegy az se melyik járaton. A fentebb már említett formátumot

használva a járatnak a száma, valamint az erre bejelentkezett busz egyedi azonosítója

képezi az írandó adatot, az aktuális dátummal kiegészülve. A busznak az azonosítója el


van tárolva az OBU-ban, ahogy az aktuális járatszám is, ezek egyébként még a

MobilON alkalmazásban is megjelennek, tehát az adatok már most is hozzáférhetőek,

ahogy a pontos idő is, nem kell csak a jelenlegi eszközök adottságát kihasználni a kód

generálásához a jegykezeléskor. Hogy adatokat spóroljunk, nincsen szükség arra, hogy

másodpercre pontosan adjuk meg a dátumot a kártyának, a percből is elég egyértelműen

meg lehet mondani, hogy mi az utas valóban mikor érvényesítette a jegyét.

A bérletnél kicsit egyszerűbb a helyzet, hiszen ott csak annak a kódja, valamint egy

lejárati idő van feltöltve a kártyára, ezt kell az aktuális idővel összehasonlítani. Ha a

pontos idő korábban van a lejáratnál, a LED zölden világít, ha nem, akkor vörösen,

tehát az eszközünk nem érvényes. Az írás része itt is ugyanaz lesz, mint a vonaljegynél,

ami egyedül azért szükséges, mert ugyan lehet, hogy az utas jogosult a jármű

használatára az érvényes bérlettel, viszont a pontos utasszámlálási adatokhoz kötelezővé

kell tenni a kártyaérintést, ezt pedig csak annak elmaradása esetén büntetéssel lehet

elkerülni. Természetesen az időbélyeg, amit kap, alkalmas arra, hogy ellenőrzés esetén

tudjuk, hogy mikor lett lehúzva a kártya utoljára.

Külön érdekességgel bír az átszállójegy megoldása, hiszen a fentebb taglaltak

alapján ennek a jegynek az első érvényesítéstől kezdve 60 percen belül el kell jutni a

következő érvényesítési pontig. Természetesen a jegyvásárlásnál itt is egy tömbbe

beleírt darabszámot adunk meg, majd ezt csökkentjük az első kezelésnél eggyel.

Viszont ez még nem jó a következő, második érvényesítéshez. Ezt úgy tudjuk megtenni,

hogy a kártyának ugyanarra a memória területére, ahová a bérletnek a lejárati ideje

kerül, beírjuk az első kezelés idejét, és innentől kezdve a jegy úgy működik, mintha

bérlet lenne, tehát a jegykezelés után átalakul. Az alábbi ábrán látható a sematikus

működési ábrája a modulnak.


18. ábra: A jegykezelő modul

5.4. Ellenőr modul

Az ellenőröknek a feladata nem változna alapjaiban, csak a körülmények

változnának meg. A modul rendkívül egyszerűen működne. Egy Androidos alkalmazás

futna az ellenőrök szolgálati okostelefonján, ami természetesen NFC képes.

Ellenőrzéskor elkérik a kártyát az utastól, az átnyújtja, majd beolvassa. Erről az


érvényesítéskor feltöltődött generált kódot kapja meg. Ebből kinyerhető mind a kezelés

ideje, mind az adott viszonylat és a busz azonosítója. Ha az utasnak kedvezményt

tartalmazó bérlete van, akkor pedig jelez az alkalmazás, hogy kérje el az ezt igazoló

dokumentumot. A szakdolgozathoz sajnos nem készül ilyen Androidos program, mivel

a tudásom ilyen tekintetben abszolút hiányosnak tekinthető, esetleg a mesterképzés

végén továbbviszem ezt az ötletet. Alább az ellenőr modul sematikus ábrája jelenik

meg.

19. ábra: Ellenőr modul

5.5. Websocket

A Websocket egy protokoll, amin keresztül kommunikálhatunk. Jellemzője a full

duplex kapcsolat, ami ugyanabban az időben kétirányú adatforgalmat képes

lebonyolítani a csatornán, valamint az, hogy egy darab TCP csatorna elég így hozzá. A


Comet technológiák helyettesítésére hozták létre az évtized elején, az RFC 6455

szabványban leírtak szerint. Számomra nagyon fontos tulajdonsága, hogy valósidejű

adatcserére is alkalmas, valamint egyetlen eszközzel megvalósítható, hiszen csak az

ESP8266 szükséges hozzá. További előnye, hogy képes titkosított adatokat is küldeni,

ezért a kliens - aki kéri a kommunikációt - csak maszkolva küldheti az adategységekbe

(frame) beosztott üzeneteket. Amint az előbb említve volt, van egy kliens, valamint egy

szerver is. Amikor a kapcsolat létrejön a kézfogás (handshake) után, a kliens elküldi az

adatot, majd a csatornát bontják. Ha hibát észlel valamelyik, akkor mindkét fél képes

arra, hogy a kommunikációt bontsák, például ha nincsen maszkolva egy üzenet a

klienstől. A kliens a kapcsolat elején küld request-et a szervernek, ami lehet ily módon

HTTP alapú, amit a szerver ugyanilyen módon nyugtáz, majd innentől kezdve szabadon

megy a kommunikáció a két eszköz között. A HTTP-vel szemben előnye így az, hogy

nem kell minden esetben hosszú fejléceket küldeni, emiatt takarékosabb és gyorsabb

üzemelést biztosít. A böngészők támogatják a protokollt, amin keresztül küldhetjük az

adatainkat, egy HTTP szerver létrehozása után a 80-as (standard) porton keresztül

lehetséges a Websocket szerver elindítása is, mivel ez a webszerver már a tűzfalon át

van engedve, tehát nem fog letiltani a böngésző a kapcsolódáskor. Az adatok általában

string típusúak a böngészők használatakor, de szerencsére JSON segítségével bármit

küldhetünk rajta keresztül, a bináris adatok egyébiránt támogatva vannak a Websocket

által. A JSON (JavaScript Object Notation) egy szövegalapú szabvány

adatkommunikációra, ami kis méretű és programnyelv független. Alapjait a JavaScript

programnyelvből veszi, viszont nagyon hasonló a C C++ nyelvekhez is a felépítése. Két

nagy részből áll, az egyik az Object, ami egy nevet és egy értéket ad meg párban,

sorrendiség nélkül, egyfajta rekordot tehát, a másik az Array, ami ezeket sorrendbe

állítja, tehát úgy működik, mint egy tömb. [27] [28]

A Websocket az ESP8266 nevű kis eszközön keresztül fog működni, ami egy

viszonylag új WiFi csatlakozásra képes eszköz. Szerencsére vannak Arduino

könyvtárak hozzá, lehet már használni vele, így nem okoz majd problémát.

Összekapcsolásához mindössze 6db vezeték szükséges. Érdekessége, hogy sokkal

erősebb processzor dolgozik az ESP8266-ban, mint az Arduinoban, ennek az egyik fő

oka az, hogy csatlakozni tudunk így az internethez. Abszolút előnye, hogy a piacon az

egyik legolcsóbb internetképes eszköz. [29]


20. ábra: Az ESP8266

Az ESP-vel tehát felkapcsolódtam a saját WiFimre, ami egy jelerősítője az eredeti

itthoni WiFinek, egy program segítségével, amit a GitHub oldalán találtam, majd azt

szerettem volna, hogy az aktuális időt tudja RTC nélkül. Miután az Arduino fejlesztői

környezetében leszedtem a szükséges könyvtárakat, kiválasztottam a pontos típusát az

ESP-nek, majd jöhetett a feltöltés az eszközre. Az időt, valamint másodpercenként

pontokat is kiír a soros monitor a program futása közben. Kíváncsi voltam, hogy mit

tesz akkor, ha éppen bekapcsolom a mikrohullámú sütőnket, így tesztelve a megadott

WiFi hiányát. Valami oknál fogva ilyenkor a jelerősítőről elmegy a jel, valamint a

rendes WiFin sincs internet kapcsolatom. Valószínűleg hasonló tartományban

sugároznak, csak egy vékony fal választja el őket egymástól, ilyenkor nem is működik a

program megfelelően, hiszen folyamatosan csatlakozni kíván. Erről a 21-es ábrán

láthatunk egy képet, ahogy a soros monitort megnyitva láthatjuk az információkat. [32]


21. ábra: Nincs internet, nincs csatlakozás

5.6. A programok

A programok összeírása és vázolása rengeteg időt vett igénybe, mivel eléggé

bonyolult és összetett rendszerről van szó. A pénztár modulban egy írás művelet zajlik

az előzetesen beállított paraméterek alapján, miután a kártyán az NFC-s eszközünkhöz

érintjük. Ehhez tudni kell az általam választott kártya memóriáját, hogy melyik szabad,

és melyik van fenntartva a működéséhez szükséges elemeknek. Rövid kutatás után

kiderült, hogy a négyes blokktól a harminckettesig lesz hozzáférésem a memóriához,

ezért a következőket találtam ki az átláthatóság jegyében:

4-es blokk a jegy vagy bérlet típusának tárolása

5-ös blokk a darabszám, értelemszerűen bérletnél 1

6-os blokk az érvényességi idő, sima jegynél üresen hagyva

7-es blokk a legutóbbi érvényesítés generált kódja 1672190331215643

Ezeknek a területeknek az írása és olvasása a két sarkalatos pontja a programnak.

A pénztármodul egyik részletén fogom elmagyarázni ennek a működését. Az

alapelvünk az, hogy manuálisan beírjuk a kívánt jegy vagy bérlettípust a kódba, utána

megadjuk a darabszámot, valamint az érvényességi időt is.


22. ábra: A programkód modellje


A programrészletből látszik, hogy miután kiválasztottuk a kívánt típust, ezt a négyes

memóriaterületre írjuk majd be, a jegyellenőr modulnak innen kell majd kiolvasnia.

A jegyellenőr modul egy olvasás művelettel indul, ami alapján megvizsgáljuk, hogy

jegye vagy bérlete van a tulajdonosnak. Ha jegye, akkor az ötös memóriaterületre írt

darabszámot csökkentjük eggyel, ha nincs beleírva semmi, akkor kilép a program

hibával. Amennyiben bérlettel utazik, az olvasás után lekérjük az időt, majd eltároljuk

azt, összehasonlítjuk a hatos memóriaterületen tárolt érvényességi idővel, és ha az

nagyobb, akkor tovább engedjük a rendszert. Ezek után következik az írás művelet, ahol

az egyedileg megadott járműazonosító, az eltárolt idő, valamint a szintén manuálisan

bevitt járatszám segítségével generálunk egy kódot, amit a hetes memóriaterületre írunk

a pénztár modulban használt módszer alapján.

23. ábra: Az ESP8266 összekapcsolása a Leonardoval [31]

Sajnos a kártyán több módszert is tesztelve, kiderült, hogy már a kezdetektől

titkosítva van, ezért csak egy 300 dolláros eszközzel, valamint egy szintén fizetős

programmal tudnám testreszabni. A MiFare kártyák gyártója által kiadott hivatalos NFC

TagWriter by NXP applikáció segítségével szerettem volna a kártyákra próbaszerűen

adatokat felírni, majd azokat visszaolvasni, viszont, ahogy a lentebbi

képernyőfelvételeken is látszik, ezeket nem tudtam megtenni. Ehhez egyébként a saját

OnePlus 3T típusú NFC képes okos telefonomat használtam segítségként. Magát a

kártyát helyesen üresnek érzékelte, valamint gond nélkül felismerte, viszont sem a

formázás, sem az írás nem volt sikeres. Az oka annak, hogy nem kívántam másik


kártyát, például egy MiFare Classic-ot használni, az, hogy ellentmondana minden

kutatásomnak a biztonság terén, sőt a memóriakezelése is eltérő, mivel máshol vannak

eltárolva az UID-k, valamint a nem hozzáférhető területek. [23]

24. ábra: Az alkalmazással sem lehet írni a kártyára

Tehát maradt a mobilkészülékem, mint az egyszerű NFC-s adatátvitelnek a kis

tesztelésére alkalmas eszköz a későbbiekre, vagy majd egy olyan kártya beszerzése, ami

ugyan a biztonsági előírásoknak nem felel meg, de szimulálható vele az írás-olvasás.

5.7. LabVIEW Program

A LabVIEW egy, a National Instruments által készített grafikus fejlesztői környezet.

Mivel számtalan tantárgyból találkoztam a programmal, valamint egy félévben

szabadon választható tárgyként is hallgattam, hogy mélyebb ismeretekre tegyek szert

belőle, ezért nem volt kérdés, hogy alkalmazni fogom a szimulációk elkészítésénél.

Vezetékekből és grafikus blokkokból épül fel maga a program része, amit a program

futása közben nem látunk. Viszont jó kiindulási alapot tesz lehetővé, ha mégis

megnyitjuk, hiszen nyomon követhetjük az adatfolyamot rajta egy kattintás után,

ilyenkor a program futása lelassul. A programban kiválaszthatunk pár tetszőleges


busztípust, járatot, valamint fiktív jelzőszámot a busznak. Ehhez tesszük hozzá az

aktuális időt és egy gomb megnyomására ezek az adatok a már korábban ismertetett

formátumban elmentésre kerülnek egy fájlba. Ahogy szimuláljuk az utasok belépését,

úgy nő az aktuális busztípushoz igazítottan skálázott kijelző a képernyőn, szintén a

megadott színtartományokkal operálva.

25. ábra: A bérlettípus nem érvényes

Egy clusterbe gyűjtöttem a változtatható adatokat, mint a jármű azonosítója, a

járatszám, vagy a bérlet típusa. Természetesen nem vittem fel feleslegesen az összes

valóban megforduló járatot és buszt, hiszen ezeket bármikor percek alatt lehet pótolni,

egyedül leszabályozást adtam a jármű azonosítónak, hogy csak nullától nagyobb,

valamint 2000 alatti számot engedjen beírni. A 0-ás bérlettípushoz rendeltem hozzá az

érvénytelen utazást, ilyenkor a piros LED gyullad ki. Amint a bérlettípus érvényessé

válik, a zöld LED kezd el világítani, valamint folyamatosan, ameddig a gomb nyomva

van, növekszik az utasszám. Ez a tank nevezetű elemet fogja mozgatni. Nem túl

bonyolult beállítások után a már ismertetett színkódokat kapja meg a tank elem, ami az

adott autóbusztípusra van skálázva. Jelenleg négy különböző busztípus felvéve a

szimulációba, ezek a leggyakrabban előfordulóak Miskolcon. A zöld 30% alatti, a sárga

30- és 60% közötti, a narancssárga 60- és 90% közötti, a piros pedig 90% feletti

kihasználtságot jelez. Ezekhez a programban a fill color (kitöltési szín) property node-ot


kellett állítani egy case ciklusban, amit az aktuális százalékos kihasználtság helyi

változója vezérel, függően attól, hogy milyen értéket kapunk. Hogy szemléletesebb

legyen, az aktuális utasszámot egy indicatorral is kijeleztem, valamint a százalékos

kihasználtság is megjelenik mellette. A 25. ábrán egy átlagosan kihasznált buszt

láthatunk 12-es járaton, 31 fővel a fedélzeten.

26. ábra: A busz kihasználtsága jól látható

A .csv kiterjesztésű fájlba pedig el kell menteni az adatokat. Ehhez az aktuális időt

kérdezi le a program, óra, perc, másodperc megosztásban, valamint a clusterből

kiszedem az unbundle by name függvény segítségével a járműazonosító valamint a

járatszám adatokat. Mivel menteni string formátumot érdemes, ezért át kellett

konvertálnom ezeket az adatokat, majd tömbbe helyezni és hozzájuk tenni egy-egy

nevet, hogy értelmezhető legyen az excel táblában az adat. Hogy jobban átlátható

legyen egy pontosvesszővel, valamint egy enterrel tagoltatom az adatokat, amit a kívánt

útvonalon elérhető fájlba ment folyamatosan. Ezt a fájlt automatikusan is létrehozza a

célhelyen, ha még nincsen kész a program futásakor, innentől kezdve viszont

folyamatosan írja bele az adatokat. Az fájlba beírt adatokról a 26-os ábrán láthatunk egy

képernyőmentést. Magát a LabVIEW programkódot, azaz a VI-t a mellékletekben lehet

megtekinteni.


27. ábra: A csv fájl és a mentett adatok


ÖSSZEFOGLALÁS 6.

Hatalmas élvezettel vágtam bele a kutatómunkába, hiszen ez az a terület, ami

gyermekkorom óta folyamatosan érdekel. Maga a rendszer véleményem szerint

átlátható és könnyedén megvalósítható lenne, köszönhetően a viszonylag fejlett

infrastruktúrának. A szakdolgozat során nem várt akadályokba ütköztem többször is, és

ugyan nem teljes mértékben, de végül sikerült az eredeti elgondolásaimat elérni. A

legtöbb nehézséget a szakirodalmak hiánya, valamint a szimulációs eszközök

használata, továbbá a programok elkészítése okozta. A mesterképzés alatt egy

összefogó gazdasági megvalósítási tervet is elkészítenék a most felvázolt rendszernek,

hiszen egyrészt itt vannak még egyértelmű hiányosságaim, másrészt egy valódi rendszer

egyik alapköve az, hogy mennyiért és hogyan lehet igazán jól, gazdaságosan

megvalósítani. Az Androidos alkalmazás megírása szintén nagy kihívás, ám ehhez is

vannak ötleteim és a jövőben szeretném elkészíteni. És végezetül, ahogy már írtam is, a

szimulációban a szerver elkészítése is feladatom lesz. Természetesen legnagyobb

örömömre az szolgálna, ha mire befejezem a mesterképzést, tőlem függetlenül már

bevezetésre kerülne egy elektronikus jegyrendszer, amit valóban lehetne

továbbfejleszteni az utasszámlálás irányába, nem csak szavak szintjén. Ehhez az első

lépések a koronavírus járványnak köszönhetően már megindultak. A kérdőívet is tovább

bővíteném, valamint növelném a mintát, amiből átfogó képet kaphatnék arról, hogy egy

miskolci lakos hogyan is gondolkozik a témáról, hiszen akárhogyan is, de értük lenne,

nekik szól a rendszer. Ennek során általában pozitív visszajelzést kaptam a témáról,

sokszor kérdezték, hogy tud-e erről az MVK Zrt., mert tetszett nekik az elgondolásom.

Úgy gondolom, hogy megtaláltam ebben a szakdolgozatban a megfelelő kihívást és

rengeteg újdonságot tanulhattam meg. Mivel folyamatosan fejlődő technológiáról van

szó, ezért szükséges a rendszer monitorozása, valamint fejlesztése a jövőben.


SUMMARY 7.

It was a great pleasure for me to start my research because this is an area that I have

been constantly interested in since my childhood. In my opinion, the system itself would

be transparent and easy to implement due to the relatively advanced infrastructure here

in Miskolc. During the dissertation I encountered unexpected obstacles several times,

and not completely, but I managed to achieve my original ideas. Most of the difficulties

were caused by the lack of source, the use of simulation tools and the preparation of

programs. During the master's degree, I would also draw up a comprehensive economic

implementation plan for the system I have outlined, since on the one hand I have clear

shortcomings in my profession and on the other hand one of the cornerstones of a real

system is how much and how well it can be implemented economically. Writing an

Android app is also a big challenge, but I have some ideas for that and I want to make it

in the future. And finally, as I have already written, I will also be tasked with building

the server in the simulation. Of course, I would be delighted to have an electronic

ticketing system, independently of me, that could really be upgraded to passenger

counting, not just at the word level, by the time I finish my masters degree. The first

steps for this have already begun thanks to the coronavirus epidemic. I would also

expand the questionnaire and enlarge the sample, which would give me a

comprehensive picture of how a resident of Miskolc thinks about the topic, as it would

be for them anyway. In the course of this I usually got positive feedback on the whole

topic, they were often asked if MVK Zrt. Knows about it because they liked my idea. I

think I found the right challenge in this thesis and learned a lot of new things. As this

technology is constantly evolving, the system needs to be monitored and improved in

the future.


IRODALOMJEGYZÉK 8.

[1] Utasszámláló rendszerek: https://www.intelligenttransport.com/transport-

articles/3116/automatic-passenger-counting-systems-for-public-transport/ (Utoljára

ellenőrizve: 2019.04.07.)

[2] Hazai utasszámláló rendszerek

http://linear.hu/hu/content/utassz%C3%A1ml%C3%A1l%C3%B3-modul (Utoljára


[3] Infrakapuk: https://www.iris-sensing.com/products/irma-matrix/ (Utoljára


[4] Volánfórum: https://forum.index.hu/Article/showArticle?t=9130684 (Utoljára


[5] Az MVK Zrt. járműállománya: http://mvkzrt.hu/jarmuallomanya u(Utoljára


[6] Oyster Card: https://en.wikipedia.org/wiki/Oyster_card (Utoljára ellenőrizve:

2019.04.07.)

[7] Mi az NFC?: https://en.wikipedia.org/wiki/Near-field_communication (Utoljára


[8] Korsós Péter: Autonóm NFC-olvasó eszköz tervezése és építése.

http://diplomaterv.vik.bme.hu/hu/Theses/Autonom-NFColvaso-eszkoz-tervezese-es-

epitese (Utoljára ellenőrizve: 2019.04.07.)

[9] NFC specifikációk: https://nfc-forum.org/what-is-nfc/about-the-technology/

(Utoljára ellenőrizve: 2019.11.26.)

[10] NFC biztonság: https://nfc-forum.org/our-work/nfc-forum-security-faqs/ (Utoljára


[11] STM Mikrovezérlő: https://www.st.com/en/microcontrollers-

microprocessors/stm32l433cc.html#tools-software

[12] Arduino Leonardo: https://www.arduino.cc/en/Main/Arduino_BoardLeonardo


https://www.intelligenttransport.com/transport-articles/3116/automatic-passenger-counting-systems-for-public-transport/

https://www.intelligenttransport.com/transport-articles/3116/automatic-passenger-counting-systems-for-public-transport/

http://linear.hu/hu/content/utassz%C3%A1ml%C3%A1l%C3%B3-modul

https://www.iris-sensing.com/products/irma-matrix/

https://forum.index.hu/Article/showArticle?t=9130684

http://mvkzrt.hu/jarmuallomanya

https://en.wikipedia.org/wiki/Oyster_card

https://en.wikipedia.org/wiki/Near-field_communication

http://diplomaterv.vik.bme.hu/hu/Theses/Autonom-NFColvaso-eszkoz-tervezese-es-epitese

http://diplomaterv.vik.bme.hu/hu/Theses/Autonom-NFColvaso-eszkoz-tervezese-es-epitese

https://nfc-forum.org/what-is-nfc/about-the-technology/

https://nfc-forum.org/our-work/nfc-forum-security-faqs/

https://www.st.com/en/microcontrollers-microprocessors/stm32l433cc.html%23tools-software

https://www.st.com/en/microcontrollers-microprocessors/stm32l433cc.html%23tools-software

https://www.arduino.cc/en/Main/Arduino_BoardLeonardo


[13] NFC Shield: https://www.st.com/en/ecosystems/x-nucleo-nfc04a1.html (Utoljára


[14] Desfire kártya: https://www.mifare.net/wp-content/uploads/2015/02/MIFARE-

DESFire-family.pdf

[15] Kártya ára:

https://www.cardomatic.de/epages/64510967.sf/en_GB/?ObjectPath=/Shops/64510967/

Products/%22DESFire%20EV2%22


[16]http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2010/HF-

reports/SardiGyorgy.pdf (Utoljára ellenőrizve: 2019.04.07.)

[17] MiFare kártyák: https://www.nxp.com/docs/en/data-

sheet/MF3DX2_MF3DHX2_SDS.pdf?pspll=1 (Utoljára ellenőrizve: 2019.04.07.)

[18] MiFare PlusX kártya:https://www.nxp.com/docs/en/data-

sheet/MF1PLUSX0Y1_SDS.pdf (Utoljára ellenőrizve: 2019.11.02.)

[19] ISO szabvány: https://www.iso.org/obp/ui/#iso:std:iso-iec:14443:-4:ed-4:v1:en


[20] ISO szabvány: https://bitexperts.com/Question/Detail/3360/difference-between-iso-

14443-and-iso-18092-i-e-rfid-vs-nfc (Utoljára ellenőrizve: 2019.11.02.)

[21] GDPR bevezetése:

https://index.hu/velemeny/2018/05/17/gdpr_hasznossag_vallalkozasok_cegek_adatvede

lem_ugyfelbaratsag_koltsegcsokkentes_bizalom/ (Utoljára ellenőrizve: 2019.04.07.)

[22] GDPR

bevezetése:https://index.hu/aktak/gdpr_adatvedelem_szemelyes_adatok_rendelet_vallal

kozasok_birsag_europai_unio/ (Utoljára ellenőrizve: 2019.04.07.)

[23] Budapesti elektronikus jegy: https://rigo.bkk.hu/ (Utoljára ellenőrizve:

2019.04.07.)

[24] GDPR szövege: https://www.adatvedelmirendelet.hu/a-rendelet-szovege/ (Utoljára


https://www.st.com/en/ecosystems/x-nucleo-nfc04a1.html

https://www.mifare.net/wp-content/uploads/2015/02/MIFARE-DESFire-family.pdf

https://www.mifare.net/wp-content/uploads/2015/02/MIFARE-DESFire-family.pdf

https://www.cardomatic.de/epages/64510967.sf/en_GB/?ObjectPath=/Shops/64510967/Products/%22DESFire%20EV2%22

https://www.cardomatic.de/epages/64510967.sf/en_GB/?ObjectPath=/Shops/64510967/Products/%22DESFire%20EV2%22

http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2010/HF-reports/SardiGyorgy.pdf

http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2010/HF-reports/SardiGyorgy.pdf

https://www.nxp.com/docs/en/data-sheet/MF3DX2_MF3DHX2_SDS.pdf?pspll=1

https://www.nxp.com/docs/en/data-sheet/MF3DX2_MF3DHX2_SDS.pdf?pspll=1

https://www.nxp.com/docs/en/data-sheet/MF1PLUSX0Y1_SDS.pdf

https://www.nxp.com/docs/en/data-sheet/MF1PLUSX0Y1_SDS.pdf

https://www.iso.org/obp/ui/#iso:std:iso-iec:14443:-4:ed-4:v1:en

https://bitexperts.com/Question/Detail/3360/difference-between-iso-14443-and-iso-18092-i-e-rfid-vs-nfc

https://bitexperts.com/Question/Detail/3360/difference-between-iso-14443-and-iso-18092-i-e-rfid-vs-nfc

https://index.hu/velemeny/2018/05/17/gdpr_hasznossag_vallalkozasok_cegek_adatvedelem_ugyfelbaratsag_koltsegcsokkentes_bizalom/

https://index.hu/velemeny/2018/05/17/gdpr_hasznossag_vallalkozasok_cegek_adatvedelem_ugyfelbaratsag_koltsegcsokkentes_bizalom/

https://index.hu/aktak/gdpr_adatvedelem_szemelyes_adatok_rendelet_vallalkozasok_birsag_europai_unio/

https://index.hu/aktak/gdpr_adatvedelem_szemelyes_adatok_rendelet_vallalkozasok_birsag_europai_unio/

https://rigo.bkk.hu/

https://www.adatvedelmirendelet.hu/a-rendelet-szovege/


[25] Közlekedési kedvezmények: https://net.jogtar.hu/jogszabaly?docid=a0700085.kor


[26]Eladott jegyek Miskolcon:

http://mvkzrt.hu/sites/default/files/dokumentumok/kozerdeku_adatok/2018_05_16_201

7_evi_ksz_beszamolo.pdf (Utoljára ellenőrizve: 2019.04.07.)

[27] Websocket adatai: https://tools.ietf.org/html/rfc6455 (Utoljára ellenőrizve:

2019.11.02.)

[28] JSON adatai: http://www.json.org/ (Utoljára ellenőrizve: 2019.11.26.)

[29] ESP8266: https://butykoltem.blog.hu/2016/07/27/csinald_magad_iot_esp8266


[29] NFC segédkönyvtár: https://github.com/nfc-tools (Utoljára ellenőrizve:

2019.11.26.)

[30] ESP segédkönyvtár: https://github.com/esp8266/Arduino (Utoljára ellenőrizve:

2019.11.26.)

[31] Arduino összekapcsolása ESP8266-tal: https://microcontrollerelectronics.com/wp-

content/uploads/2014/12/esp8266_rst.png (Utoljára ellenőrizve: 2019.11.02.)

[32] ESP8266 programja és az idő lekérdezése: https://github.com/scanlime/esp8266-

Arduino/blob/master/tests/Time/Time.ino (Utoljára ellenőrizve: 2020.04.22.)

https://net.jogtar.hu/jogszabaly?docid=a0700085.kor

http://mvkzrt.hu/sites/default/files/dokumentumok/kozerdeku_adatok/2018_05_16_2017_evi_ksz_beszamolo.pdf

http://mvkzrt.hu/sites/default/files/dokumentumok/kozerdeku_adatok/2018_05_16_2017_evi_ksz_beszamolo.pdf

https://tools.ietf.org/html/rfc6455

http://www.json.org/

https://butykoltem.blog.hu/2016/07/27/csinald_magad_iot_esp8266

https://github.com/nfc-tools

https://github.com/esp8266/Arduino

https://microcontrollerelectronics.com/wp-content/uploads/2014/12/esp8266_rst.png

https://microcontrollerelectronics.com/wp-content/uploads/2014/12/esp8266_rst.png

https://github.com/scanlime/esp8266-Arduino/blob/master/tests/Time/Time.ino

https://github.com/scanlime/esp8266-Arduino/blob/master/tests/Time/Time.ino


ÁBRAJEGYZÉK 9.

1. ábra: Sztereó kamera [2] ........................................................................................................... 7

2. ábra Infrakapu [3] ...................................................................................................................... 8

3. ábra: Egy CNG-s busz [5] ......................................................................................................... 11

4. ábra: Jegykezelő egy CNG-s buszon ........................................................................................ 12

5. ábra: Az OBU [2] ...................................................................................................................... 13

6. ábra: Utastájékoztató tábla ..................................................................................................... 14

7. ábra: A MobilON alkalmazás ................................................................................................... 15

8. ábra: A rendszer blokkvázlata ................................................................................................. 18

9. ábra: Arduino Leonardo .......................................................................................................... 22

10. ábra: NFC04A1 ...................................................................................................................... 23

11. ábra: A DESFire EV2 chip blokkvázlata [17] ........................................................................... 24

12. ábra: A MifarePlusX kártya .................................................................................................... 25

13. ábra: Az NFC-hez kapcsolódó szabályozások [9] ................................................................... 26

14. ábra: A Mifare Plus X blokkvázlata [18]................................................................................ 27

15. ábra: Diagram ........................................................................................................................ 33

16. ábra: Diagram 2 ..................................................................................................................... 34

17. ábra: A pénztár modul .......................................................................................................... 39

18. ábra: A jegykezelő modul ...................................................................................................... 41

19. ábra: Ellenőr modul ............................................................................................................... 42

20. ábra: Az ESP8266 ................................................................................................................... 44

21. ábra: Nincs internet, nincs csatlakozás ................................................................................. 45

22. ábra: A programkód modellje ............................................................................................... 46

23. ábra: Az ESP8266 összekapcsolása a Leonardoval [31] ........................................................ 47

24. ábra: Az alkalmazással sem lehet írni a kártyára .................................................................. 48

25. ábra: A bérlettípus nem érvényes ......................................................................................... 49

26. ábra: A busz kihasználtsága jól látható ................................................................................. 50

27. ábra: A csv fájl és a mentett adatok ...................................................................................... 51


1. Melléklet – LabVIEW


2. Melléklet – ESP programkód

#include <ESP8266WiFi.h>

#include <time.h>

const char* ssid = "Saját wifi neve";

const char* password = "Saját wifi jelszava";

int timezone = 3;

int dst = 0;

void setup() {

Serial.begin(115200);

Serial.setDebugOutput(true);

WiFi.mode(WIFI_STA);

WiFi.begin(ssid, password);

Serial.println("\nKapcsolodva a wifihez");

while (WiFi.status() != WL_CONNECTED) {

Serial.print(".");

delay(1000);

}

configTime(3 * 3600, 0, "pool.ntp.org", "time.nist.gov");

Serial.println("\nVár az időre");

while (!time(nullptr)) {

Serial.print(".");

delay(1000);

}

Serial.println("");

}

void loop() {

time_t now = time(nullptr);

Serial.println(ctime(&now));

delay(1000);

}

elektronikus jegy alapÚ utasszÁmlÁlÓ rendszer …

Documents