Az intelligens utazás magyar módija

Weben keresztül kommuniáló közlekedési információs rendszert fejlesztett ki két magyar cég. A legkülönbözőbb forrásokból adatokat fogadni és feldolgozni képes megoldás motorja lehet az összes utastájékoztató alkalmazásnak a közösségi közlekedés bármely formájában.

A Traffic Information System (TIS) névre hallgató, webes közlekedési rendszer kikísérletezése az NKTH pályázatán nyert el támogatást. A Polygon Informatikai Kft. és a ByBloSys Kft. szoros együttműködésében készült, 60 millió forintos, két és fél éven át tartó fejlesztéssel egy olyan háttérrendszer jött létre, mely képes átfogó közlekedési tájékoztatást adni − közölte a Polygon projektvezetője. Verebély Károly elmondta, a szoftver motorja lehet a közeljövő számtalan, akár összes utastájékoztató alkalmazásának a közösségi közlekedés bármely formája, a turistainformáció, taxi vagy más logisztikai területeken.

Káosz a köbön. (forrás: flickr.com)

Minden további nélkül megvalósítható például, hogy mobilinternet segítségével bárki már a késő esti buszon utazva ellenőrizze, megvárja-e a villamos vagy Hév csatlakozás, miközben a valós idejű információs rendszer a járatok szervezőinek, diszpécsereinek is segít egymáshoz igazítani az egyes közlekedési eszközöket. Ugyanígy megoldható, hogy a megállóban várakozók Bluetooth-on keresztül kapjanak értesítést egy járat kimaradásáról. De a TIS-re csatlakozva − ha ilyen irányú fejlesztésekre jelentkezik igény −, bármely turista a saját telefonjáról megtervezheti, hogyan közelíti meg látnivalókat, ott konkrétan mire kíváncsi, és képeken azt is megnézheti, mit kínál számára az adott nevezetesség. Mindezt a most kifejlesztett háttérrendszer, és a jövőben hozzá készített kiegészítő alkalmazások teszik lehetővé.

A rendszer vázlatos működése viszonylag egyszerű − vázolta a szakember. A leendő üzemeltetők, például a Volán társaságok, vagy a BKV bejuttatják a járműveik, menetrendjük releváns adatait a szoftverbe. Az „összefésüli” ezeket, és az utasok, vagy más felhasználók számára lényeges információként továbbítja. Így lesz a menetrend és a GPS jel kapcsolatából a késésről szóló tájékoztatás, a feltöltött fényképekből, útvonaladatokból és programinformációkból pedig turistatájékoztatás.

A gyakorlatban azonban ehhez az egyértelmű működéshez rengeteg fejlesztés, munkaóra tartozik. A fenti példákon kívül számtalan rendszer eltérő jeleit kell értelmezni és feldolgozva továbbítani. Természetesen, amikor a jelenlegi projekt alapján majd valós eszközök fejlesztésére, készítésére, vagyis a „piacosításra” kerül sor, mindegyiket optimalizálni kell majd az adott feladathoz, de ez már alig jelent munkát az alapfejlesztés mértékéhez képest – hangsúlyozza a szakértő.

A Traffic Information System-ről

(ITextreme)

A projekt legnagyobb eredménye az üzenet- és eseménykezelő háttérrendszernek a kifejlesztése, mely alkalmas a közlekedési szektorra jellemző heterogén informatikai rendszerek összekapcsolására, valamint az ilyen környezetben keletkező nagy mennyiségű üzenet kezelésére. Ez egy interfész adatbázissal rendelkező, közlekedésinformatikára szabott szolgáltatás busz megoldás, ami elérhető standard webszolgáltatásokkal, és megteremti az érintett alkalmazások aszinkron kommunikációját.

A háttérrendszer meghatározó eleme az IBM WebSphere Message Queue (MQ) alkalmazás. Az MQ egy piacvezető, üzenetalapú köztes réteg (MOM, message oriented middleware). Legfőbb alkalmazási területe az alacsony függésben álló alkalmazások közötti aszinkron kommunikáció megoldása. Ez lényegében azt jelenti, hogy az aszinkron kommunikációra épülő architektúrákban működő alkalmazások nem tudnak egymásról, az összes résztvevő rendszer lényegében függetlenül működik. Kibocsát és fogad üzeneteket, de ezek tartalma az alapműködésre nincs hatással. Egy aszinkron üzenetküldésre épülő alkalmazásnak elég tudnia azt, hogy az adott üzenet el lett küldve az érintett alkalmazásoknak, hogy azzal mi történik, már nem vizsgálja.

A WebSpehere Message Queue tehát egy univerzális, robosztus üzenetkezelési keretrendszer, mely aszinkron módon össze tud kapcsolni egymással gyakorlatilag bármilyen informatikai alkalmazást, biztosítva, hogy a fogadó fél egyszer és csak egyszer kapja meg a küldött üzenetet. Természetesen ahhoz, hogy egy-egy célfeladat esetében ez az összekapcsolás zökkenőmentes legyen, komoly fejlesztésekre van szükség.

Az MQ szoftver három fő elemből áll: a Message Queue Manager (MQM) – üzenetsor menedzser; a Message Queue Interface (MQI) – üzenetsor interfész; Message Queue Objects – üzenetsor objektumok. Az üzenetsor menedzser az MQ magja, ez felelős az objektumok kezeléséért, a témák (lásd publish/subscribe üzenetküldési módozat) létrehozásáért, karbantartásáért, feliratkozások fogadásáért stb. Az interfész felel az üzenetsor menedzser eléréséért. Az objektumok pedig azok az elemek, amik működés közben keletkeznek, az üzleti logika kívánságai szerint. Ide tartoznak maguk az üzenetek, témák, feliratkozások, csatornák stb.

Emellett ezek az üzenetek kétféle módon is útjukra indulhatnak a központból aszerint, hogy a rendszer egyetlen fogadónak (point-to-point), vagy többeknek (publish/subscribe) szánja. Az egyetlen fogadónak szánt üzeneteknél beszélhetünk egyszeri küldésről (send and forget) illetve olyanról, amire a küldő választ vár (request/reply). A több felhasználónak szánt üzenetek esetében beszélhetünk állapotinformációkról (a fogadó csak alapinformációról és annak változásairól értesül) és eseményinformációkról (a fogadó automatikusan értesül minden, a témához tartozó eseményről).

Belátható, hogy a háttérrendszer kalibrálása során ahhoz, hogy alkalmas legyen az adott, nagyon heterogén információk feldolgozására és továbbítására, minden egyes várható eseménynél meg kell határozni a fogadók körét, az esemény típusát, az egyes perifériák jogosultságait, stb. Emellett a rendszert meg kell „tanítani”, miként kezeljen egyes elektronikus jeleket, mint pld. a gps koordináták, vagy a menetrendi jelzések. Az MQ által kezelhető üzenetek ugyanis két részből állnak. Egyfelől van egy adattartalmuk (törzs), melyet e rendszernek nem feltétlenül kell értelmeznie, és egy leíró rész (fej), ami viszont csak az MQ számára fontos, és amiben az üzenet besorolását segítő tulajdonságok vannak, mint verziószám, azonosító, prioritás, az üzenet élettartama (érvényessége), a küldő adatai, a céladatok, stb.

Összességében az MQ alapú háttérrendszer felel a közlekedést érintő hihetetlen nagyszámú információ leválogatásáért és célba juttatásáért. A TIS Projekt ebben a megközelítésben nem más, mint egy rendszer, mely begyűjti a közlekedés adatait, és azokat úgy csoportosítja, hogy kiszolgálják a felhasználók speciális igényeit. Így lesznek a menetrendekből és GPS koordinátákból számított érkezési vagy késési információk, vagy a térképadatokból és fényképarchívumból az útvonalra és a látványosságok fényképeire is kiterjedő turistainformációk.

Természetesen ahhoz, hogy a megfelelő, naprakész adatok eljussanak a háttérrendszerhez, majd azon keresztül a fogyasztóhoz, jelentős input berendezésekre és végpontokra van szükség. Ezek kiépítése, száma, működése mindig függ a felhasználás módjától, ezért a TIS projektnek ez nem volt feladata. A tesztelés, a működés szimulálására, bemutatására azonban elkészült egy közlekedési szimulátor alkalmazás, mely az input oldalt modellezi, és egy utastájékoztató rendszert imitáló eszköz, melyen keresztül ellenőrizhető a háttérrendszer működése. Maga a rendszer pedig nem közvetlenül, hanem egy köztes alkalmazással kapcsolódik az egyes alkalmazások, vagyis a közlekedési szimulátor és az utastájékoztató közé, ami később megkönnyíti a csatlakoztatását a különböző Enterprise Service Bus megoldásokhoz. Végezetül egy ábra, mely példákkal szemlélteti, hogy a TIS rendszeren belül az információáramlásért felelős MQ program milyen perifériákat láthat el adatokkal. Az ábrán látszik, hogy a felhasználók köre, mivel az eszköz az interneten is képes adatszolgáltatásra, igen széles, beleértve a legkülönbözőbb mobilnetes, vagy bluetooth-os alkalmazási lehetőségeket is.

Forrás: NKTH, Polygon, ByBloSys (nincs elérhető honlapja)

Ötlet: itBonline, ITextreme