MISKOLCI EGYETEM
Gépészmérnöki Kar
Általános Informatikai Tanszék

A Miskolci Közlekedési RT.
forgalomirányító információs rendszerének kialakítása a végállomásokon

Diplomamunka feladat

 

 

Perlaki Attila

1998

 

 

 Diplomaterv

Tartalomjegyzék

1. Bevezetés

A városi tömegközlekedés minősége alapvetően befolyásolja a város életét. Hatással van a helyi gazdaságra és politikára, a közhangulatra. Műszeres mérésekkel és számításokkal igazolható változást okoz a város forgalmi áteresztőképességére, s ezen keresztül a levegőszennyezettségre. A fejlett városi közlekedés létesítményei a városképet is módosítják. Mindezek ellenére nehéz jó mérőszámot találni annak megjelölésére, hogyan végzi munkáját a tömegközlekedést ellátó cég.

A mérőszámnak, vagy mérőszámoknak minőségi és mennyiségi adatokat is kell szolgáltatniuk. A legfontosabb mennyiségi mérőszám az utaskilométer. Ez, egy megadott időszakban, az elszállított összes utas által utazásonként megtett távolságok összege, amely viszonyítható a járművek által ugyanazon időszak alatt teljesített férőhely-kilométeréhez, ami az útvonalhosszak és az egymást követő járművek férőhely-kapacitásának szorzata. Ebből kifejezhető egy kihasználtsági mutatószám is, amely már minőségi jelző. A kihasználtság alacsony volta gazdaságtalan működést von maga után, az egy határon túl növő kihasználtság, azaz a zsúfoltság, pedig az utazási körülmények minőségét rontja.

A közlekedés szervezettsége két másik minőségi mérőszámmal jellemezhető. Az egyik összefügg a kihasználtsággal, ugyanis a követési időköz, a következő járat érkezéséig hátralévő idő alapvetően meghatározza a vonal kapacitását (adott időn belül elszállítható utasok számát), egyben pedig jelzi, ütemes, kiszámítható menetrend meghatározása szükséges. (A menetrend jellemzőiről később.) A másik mérőszám nem más, mint a menetrend megbízhatósága. A minőségi mérőszámok a vállalatot felügyelő önkormányzat számára szolgálnak tájékoztatásul.

Bármilyen jól tervezett is egy menetrend, a forgalom sajátosságai folytán gyakorta rendkívüli események történnek, amelyre előzetesen csak részben lehet felkészülni. A rendkívüli esemény nem jelent feltétlenül balesetet. Egyszerű forgalmi dugó, hirtelen jelentkező utastömeg (pl. egy előre be nem jelentett rendezvény után), kedvezőtlen időjárás, műszaki hiba, s még más okok is szükségessé tehetnek menetirányítói beavatkozást. Ennek időigénye, azaz a reakcióidő (az esemény bekövetkeztétől az intézkedés megkezdéséig eltelt idő) és a rendkívüli helyzet elhárítására szolgáló idő (az esemény bekövetkeztétől a helyzet normalizálásáig eltelt idő) szintén mérőszám.

A fentiekből következik, hogy a tömegközlekedés minőségi ellátásához fejlett és megbízható kommunikációs, illetve információs rendszer szükséges. A rendszer nagy területen elosztott, sok egyedi jellegzetességet tartalmazó, egymástól eltérő felhasználási célokra szolgáló elemek összessége. Fejlesztése a folyamatosan változó környezetben valójában sosem ér véget.

2. A városi tömegközlekedési rendszer vizsgálata

A városi tömegközlekedést szorgalmazók az egyéni (személygépjárművel való) közlekedéssel szemben az alábbi paraméterekben tapasztalható, esetenként sokszorosan kedvezőbb értékeket sorolják fel:

Az előnyök egy része a járművek befogadóképességéből, más része pedig a tömegközlekedés szervezettségéből adódik. Utóbbit megfelelő adatgyűjtésen alapuló tervezés és hatékony felügyeleti rendszer képes biztosítani. [1]

2.1 A felügyeleti rendszerek működésének elemzése

A felügyeleti rendszerek célja:

A forgalom-felügyelet és a forgalomszervezés kölcsönös visszacsatolásban végzi feladatát. A forgalomszervezés munkáját a felügyelet által begyűjtött friss és régebbi adatok alapján végzi, amelyek az utazási igények jellemzőit tartalmazzák. Ezek figyelembevételével kell a forgalomszervezésnek a menetrendet újra és újra átalakítania, amely viszont a felügyelet számára alapvető. Ehhez járulnak még a menetrendet rövid távon befolyásoló eseményekről szóló információk. A felügyelet részben a menetrendben foglalt forgalmi terv betartására törekszik, illetve adott esetben azt felülbírálva igyekszik a szolgáltatást a lehetőségekhez mérten a legjobb színvonalon fenntartani. Megkülönbözteti a zavarokat súlyosságuk szerint, attól függően, milyen szinten kell beavatkozni és mennyi ideig tart ez a beavatkozás. Az ismétlődően előforduló azonos típusú zavarok mindenképpen forgalomszervezési hibára utalnak. Ezeket és a forgalom normális menetére jellemző adatokat a felügyelet a forgalomszervezés számára továbbítja. [11], [12], [13], [14]

A felügyeleti informatikai rendszer teljes kiépítettség esetén képes minden jármű egyedi beazonosítására és állapotának illetve környezetének (pl. forgalmi helyzet) lekérdezésére. Jelentős kutatások folynak ilyen rendszerek kifejlesztésére és fokozatos üzembe helyezésére Japánban, az Egyesült Államokban és az Európai Közösségen belül. A vizsgálatok egyértelműen kimutatták, hogy a közúti forgalomban részt vevő járművek teljes bekapcsolása okozza a legtöbb nehézséget, míg a zártpályás járművek (pl. metró) automatizált üzeme már élő gyakorlat. [2], [10]

2.1.1 Menetrend szerinti egyenletes forgalom biztosítása

A menetrend és a hozzá tartozó egyéb információk (gépjárművezetők és járműveik beosztása, munkarendje, stb.) képezik alapját a forgalomirányítás rutinjának. A menetrend alapján indulnak ki a szolgálatot teljesítő járművek a központi telepről, végzik a irányító végállomások felügyelete mellett a szállítási feladatokat és térnek vissza üzemzáráskor.

A menetrend lényegében egyfajta programterv, részletességétől függően egy vagy több pontban meghatározza, milyen időpontokban milyen irányban közlekedő járműnek kell megjelennie. Az időpontokon túl egyéb adatokat, korlátozásokat is tartalmazhat, ez az adott közlekedési ágazat sajátosságaitól függ. Az utazóközönség számára készített menetrend nem tartalmaz mindent, egyes esetekben még konkrét időpontokat sem, csupán egy tájékoztató információt arról, mennyi időn belül kell a következő járatnak érkeznie. (Ez a sűrűn egymást követő járműveknél, pl. a metrónál jellemző.) A menetrend betartásának legfontosabb feltétele a pontos idő ismerete és a menetrendben meghatározott érkezési és indulási idők eltérés nélküli végrehajtása.

A feladat nagy mértékben automatizálható. Első lépés a kötött menetrend bevezetése, mert így a forgalom összehangolása és a végállomási szolgálat munkája is könnyebbé válik, maga a forgalom pedig kiszámíthatóbbá, bár kevésbé rugalmassá. Második lépcsőben a menetrendre olyan jelzőrendszer épül rá, amely emberi felügyelet nélkül is képes a rutinforgalom összehangolására. Ezek kiegészíthetők adatgyűjtő berendezésekkel. A helyi rendszerek hálózatba köthetők és központi, második szintű irányítást tesznek lehetővé, amely az első szinten kiválthatja az emberi munkát. A központi rendszer térinformatikai (GIS) támogatást kaphat, amely a rutintól eltérő helyzetekben mutatja meg igazi hasznosságát. Az automatizálás ezen részének csúcsa az emberi közreműködést nem igénylő szállítójárművek (pl. vezető nélküli metrószerelvények, robottaxik) menetrend szerinti vagy meghívásos üzemeltetése. [2], [4], [9], [31]

2.1.2 Rendkívüli események gyors kezelése

A rendkívüli események kezelését a gyors és pontos helyzetfelmérés és az elhárításhoz szükséges adatok rendelkezésre állása segíti elő. Nem integrált rendszerek esetén egy helyi forgalmi zavar továbbterjedésének megakadályozása (lokalizálás) sem mindig valósítható meg. A jelenlegi rendszerek általában részben integráltak, a kommunikációs kapcsolat kiépült, de a helyileg megoldható problémáknál súlyosabb esetekben a központ beavatkozása nagy késlekedést okoz, továbbá a szükséges adatok nehezen visszakereshetők, jórészt a szolgálatteljesítők memóriáján, gyakorlottságán és intuícióján múlik a megoldás.

Egy térinformatikai rendszerre alapozott felügyeleti rendszerben mindazon adatoknak rendelkezésre kell állniuk, amelyek egy rendkívüli forgalmi helyzet megoldásához szükségesek. A GIS (forgalmi szempontból változatlannak tekinthető) adatbázisát a forgalmi adatgyűjtő rendszer folyamatosan vagy ütemezetten érkező adatai teszik áttekinthető, "élő" rendszerré, ahol lehetőség van a teljes forgalmi terület on-line megfigyelésére és a legtöbb helyzetben a gyors, nem ritkán automatikus válasz (pl. terelőút kijelölése) megadására.

A rendkívüli események kezeléséhez a következő alapkérdéseket kell tisztázni:

Mindegyik kérdés felvethet olyan válaszokat, amelyet nem lehet automatikusan kezelni, a feladat ezen része tehát csak részben automatizálható. Érdekes kérdés, milyen eredménnyel lehet erre a feladatra szakértői rendszereket alkalmazni.

2.1.3 Adatgyűjtés a forgalomszervezés javításáért

Az adatgyűjtés két alapvető érdeket szolgál. Rövid távon visszacsatol a felügyelet felé, hosszú távon pedig a forgalomszervezés számára segít optimalizálni a teljes szállítási feladatot.

A forgalom szervezése rendkívül összetett feladat, mivel az ideális menetrendhez sosem áll rendelkezésre megfelelő mennyiségű erőforrás. Az utazási szokásokból kialakult forgalmi görbéhez igazodó menetrendet a járművezetők munkabeosztását meghatározó szabályok is befolyásolják. Az üresen futott kilométerek minimalizálása befolyásolja az eltérő forgalmi jellegzetességgel rendelkező vonalak közötti járműátcsoportosítást, összetettebb menetrendet, végállomások közötti be- és kiállást igényel. Az egyidőben jelentkező utazási csúcsszakaszokhoz méretezett járműszám völgyidőszakban kihasználatlanul álló járműveket eredményez. Mindezeket részben a kialakult gyakorlat és az intuíció, részben már bevált optimum-számítási eszközök felhasználása segítségével veszik figyelembe a menetrend meghatározásánál.

A legfőbb probléma a forgalmi adatok mennyisége és megbízhatósága. Jelenleg a közlekedési vállalatok sokszor elégtelen, elavult adatok alapján kénytelenek dolgozni, mivel a teljes körű adatgyűjtés (utas- és forgalomszámlálás) költsége nagy és ezt csak esetileg, lehetőség szerint szokásos forgalmi szituációban lehet viszonylag ritkán elvégezni, s csak statisztikai módszerekkel lehet kezelni. Ehhez más, részleges adatok járulnak, főleg a forgalmi szolgálat részéről. Egy komplex felügyeleti rendszer kiépítésekor azonban lehetőség van állandó adatgyűjtő alrendszer megvalósítására.

2.2 A felügyeleti és az információs rendszer kapcsolatának vizsgálata

A felügyelet alapvetően két, egymástól nem tökéletesen elválasztható rendszert használhat. Az egyik irodatechnikai jellegű, a másik forgalomautomatizálási. Ezek együtt alkotnak osztott informatikai rendszert. A helyi megvalósítás során elemeik mindkét jellegzetességet tartalmazhatják.

A rendszer egyik része elsősorban adatokat gyűjt, szolgáltat és feldolgoz, míg a másik riaszt és beavatkozást segíti. Egy indító-berendezés például az adatbázisrendszerre támaszkodva végzi a rutin forgalomirányítási feladatot és amennyiben kiépítettsége lehetővé teszi, adatokat gyűjt, viszont forgalmi szempontból közlekedésirányító automata.

Az információs rendszer irodatechnikai részei:

Az információs rendszer közlekedésautomatikai részei:

A rendszer felépítése hierarchikus. A központi rendszer fogja össze az irányító végállomási rendszereket, az irányító végállomások a hozzájuk tartozó járműveket és a forgalomirányító, illetve adatgyűjtő berendezéseket.

Amennyiben lehetséges, a rendszerrel együttműködhet a városi közlekedési forgalomirányítás, amely a közúti forgalomirányító jelzőlámpákat felügyeli. Ez lehetővé tesz például zöldfázist, vagy elsőbbség biztosítását tömegközlekedési járművek részére (ezek eredményességéről a szakirodalomban is ellentmondó vélemények olvashatók).

A központ szerepe a megfigyelés és az eseti beavatkozás, míg a végállomások végzik a tényleges irányítási és adminisztrációs feladatokat.

3. A végállomások működésének elemzése és információs rendszerük feladatai

A végállomások két, jól elkülöníthető feladatot látnak el:

Az első feladatcsoport több teljesen automatizálható elemet tartalmaz, míg a második megfelel az irodai munkavégzésnek és az ott megszokott támogatást igényli.

3.1 A szükséges adatok és szolgáltatások felmérése

3.1.1 Menetirányító feladatok

A végállomás menetirányító feladatai:

A központ menetirányító feladatai:

Látható, hogy bár különböző szinten dolgoznak, lényegében hasonló feladatokat látnak el a központban és a végállomásokon is. A felhasznált adatok és szolgáltatások is sok esetben közösek. [11], [13], [14]

3.1.2 Adatbázisok

Menetrendi adatbázis:

Beosztások:

Tájékoztató és naplózott adatok:

Az utóbbi csoport a menetlevelek kivételével kizárólag ún. szabadszöveges típusúak, míg az első két csoport szabályos relációs adatbázisok. A menetlevél feldolgozása külön feladat, a rendszert csupán ezek megfelelő kiadása és begyűjtése terheli. A menetlevél vezetése rendkívüli eseteket kivéve nem szükséges, hiszen egyezik a forgalmi tervvel (járművezetői menetrend), rendkívüli esetben pedig a feladat a járművezetőé. Ez automatizálható pl. a teherforgalomban már kipróbált GPS segítségével, vagy helyileg megvalósított járműkövetési rendszerrel (lásd később). A menetlevelek feldolgozása a rendszeren kívül történik.

3.1.3 Szolgáltatások

A végállomásokon:

A központban:

Ezekhez csatlakozhat egy, a rendkívüli esetekre kidolgozott szakértői rendszer, amely az adatbázisokra (beleértve a térinformatikait is) és a típusos rendkívüli események elhárítási módjait tartalmazó tudásbázisra támaszkodva automatikusan, vagy tanácsadó üzemmódban segítheti a forgalmi szolgálatot.

3.2 Az információs rendszer szolgáltatásainak kidolgozása

3.2.1 Emberi beavatkozást normál helyzetben nem igénylő feladatok

3.2.1.1 Indítás és érkeztetés, naplózás és riasztás

A feladat a menetrend által meghatározott időben szükséges indítási procedúra végrehajtása, illetve a visszaérkezés regisztrálása és a menetrendben előírtaktól való eltérés esetén a riasztás beindítása, valamint minden indulás és érkezés naplózása.

3.2.1.2 Utastájékoztatás

Az utastájékoztatás célja, hogy az utast a céljához vezető viszonylatokhoz útbaigazítsa, illetve tájékoztassa az indulási időpontokról, ezzel segítve a megfelelő viszonylat kiválasztását. Az utastájékoztatás alapja az utasmenetrend és a végállomási menetrend, a rendszer mindkettőt használja. Az információszolgáltatás bővíthető az utasokat is érintő forgalmi utasítások megfelelően átformált közlésével. A tájékoztatás formája vizuális és beszédalapú is lehet.

3.2.1.3 Járműazonosítás és követés

Alapvetően három eset különböztethető meg:

(1) A legegyszerűbb a járműérzékelés. Mivel az autóbusz és villamos-végállomások általában közforgalomtól elzárt területen fekszenek, az adott helyen álló, vagy áthaladó jármű érzékelése általában kielégítő megoldást ad, a külső forgalomban azonban nem használható, csak nagyon kivételes esetben.

(2) A járműazonosítás egyedi megkülönböztetést tesz lehetővé a megfelelő eszközökkel. Ez már lehetőséget biztosít a végállomásokon és a forgalomban is a jármű egyértelmű beazonosítására. Megfelelő számú ellenőrzőpont telepítésével az egész városra kiterjedően képet kaphatunk a járművek mozgásáról, azonban ez a megoldás sem alkalmas folyamatos (on-line) megfigyelésre, mert irreálisan sok ellenőrzőpontot igényelne.

(3) A járműkövetés olyan megoldást alkalmaz, amely segítségével a jármű minden időpillanatban azonosítható és tartózkodási helye meghatározható. Ilyen, műholdakat alkalmazó, rendszereket nemzetközi szállítmányozási vállalatok már eredményesen használnak.

A megfelelő adatgyűjtő hálózatra látványos vizualizáló rendszer építhető rá, amellyel egyben a forgalomszervezés tipikus hibái (pl. rossz járatcsatlakozások, torlódások, rendszeres késések) kiszűrhetők.

A forgalom vizualizációjára hagyományos módon (forgalom- és utasszámlálás) beszerzett adatokkal is lehetőség van, ekkor a teljes forgalmi helyzet "visszajátszása" történik. A szimuláció során az is megvizsgálható, hogy milyen hatással járna a menetrend módosítása.

3.2.2 Számítógéppel támogatható feladatok

3.2.2.1 Rendkívüli forgalmi helyzetek kezelése

Bármilyen szokásostól eltérő esetben a programvezérelt forgalomirányítást felül kell bírálni. A rendszernek a lehető leggyorsabb, könnyen és hatékonyan használható felhasználói felülettel kell rendelkeznie a beavatkozások elvégzésére, ugyanakkor megbízhatónak és védettnek a helytelen kezeléssel szemben. Ehhez könnyen áttekinthető adatmegjelenítést és egyszerű, logikus adatbevitelt kell megvalósítani.

A beavatkozások kommunikációs igénnyel járnak, részben tájékozódás, részben adatcsere miatt. A meglevő kommunikációs hálózat pedig a napi szokásos adatforgalmat (következő napi beosztás, menetrendi változások, jelentések, stb.) is biztosítja. A kommunikációs résznek a lehető legmesszebbmenőkig el kell fednie a kommunikáció technikai oldalát (LAN, modemes vagy rádiós kapcsolat) a felhasználó elöl.

3.2.3.2 Napi adminisztráció

(1) Beosztáskezelés és menetlevél-kiadás

A beosztáskezelés lényege, hogy a két forrásból (forda, napi beosztás) automatikusan elkészülő jegyzéket a tényleges helyzettel összevetve (valóban megjelent-e mindenki dolgozni?) és a szükséges változásokat bevezetve a menetlevél kiadás automatikus folyamata indítható.

(2) Jegyzőkönyvek vezetése és naplózás

Gyakorlatilag szövegszerkesztési feladatokról és űrlapok kitöltéséről van szó, amely a legtöbb irodai munkának is része. Az eltérés annyi, hogy az elkészült anyagokról nyilvántartást kell vezetni, azaz ezek egyedi azonosítói a megfelelő adatbázisba kerülnek, s ott visszakereshetők.

3.2.3 A rendszer karbantartása

A megvalósítástól függően szükséges kidolgozni a rendszerhez olyan segédprogramokat, amelyek használata a hibakeresést és hibakezelést végzik. Ezek vagy automatikusan végzik feladatukat, vagy a karbantartó személyzet szervizcsomagjának részét képezik.

3.3 A szükséges hardver és szoftver alrendszerek meghatározása

A szükséges alrendszerek:

A rendszert részben szabványos személyi számítógépekre (egy teljesítményhatár felett a központban erős szerver is szükséges), részben ezeket kiegészítő, vagy önálló működésre alkalmas céleszközökre, az ezeket összekötő kommunikációs hálózatokra és működtető szoftverekre lehet felépíteni.

3.3.1 Menetirányítói alrendszer

Alapja egy folyamatos üzemre képes személyi számítógép, kommunikációs lehetőségekkel és vezérlési feladatokhoz szükséges bővítőkártyákkal.

A szoftver alapvetően két részből áll. Egy állandóan működő alaprendszerből, amely folyamatosan végzi a menetrendi feladatokat és az adatgyűjtést és egy kezelői felületből, amellyel a beavatkozások és az adminisztráció végezhető. A folyamatosan futó részt DOS esetén rezidens programként célszerű megírni, Linux esetén daemonként. A további feladatok önálló programokból álló készletből válogatható össze, vagy írhatók meg, s csak egy alapfelület szükséges, amely ezek hívását végzi. A web-alapú megoldások megfelelő infrastruktúrát igényelnek, de egységes, könnyen bővíthető rendszert eredményeznek.

3.3.2 Járműfigyelő (azonosító és követő) alrendszer

Az alrendszer adatgyűjtő berendezésekre alapul, amelyek önálló hálózatot alkotnak, s ennek adatait gyűjtik a végállomási, vagy a központi számítógépen a megfelelő interfészen át.

A járműfigyelő rendszer kiválasztása elemeinek költséges volta miatt általában gazdasági, s csak másodsorban műszaki kérdés, amely jelen esetben is nyitva maradt. A tervezés során fel kell készülni bármilyen lehetséges rendszer beintegrálására. A rendszerrel szemben támasztott követelmény mindössze annyi, hogy rendelkezzék számítógéppel való adatcserére alkalmas felülettel.

3.3.3 Utastájékoztatási alrendszer

Számos lehetőség áll rendelkezésre mind vizuális, mind beszédalapú tájékoztató rendszer megvalósítására. Az utastájékoztató alrendszernek (intelligenciájától függően) fogadnia, vagy lekérdeznie kell az utasok számára rendelkezésre bocsátott információkat, valamilyen kommunikációs csatlakozással. Az egyszerűbb megoldások csak egyirányú, a bonyolultabb (és költségesebb) megoldások párbeszédes adatszolgáltatásra képesek. A rendszer egésze szempontjából másodlagos a választott utastájékoztató alrendszer megvalósítása, ha tud számítógéppel kommunikálni. [3], [30]

Érdekes és hasznos lehetőség az utastájékoztató rendszert egyben reklámcélokra is igénybe venni, ami a rendszer üzemeltetésének költségeit csökkentheti, vagy fedezheti.

Figyelembe kell venni, hogy az utastájékoztató rendszer végpontjai fokozottan ki vannak téve a rongálódás veszélyének.

3.3.4 Kommunikáció és adatkezelés

Az alrendszerek elemei között és a rendszer egészén belül is szükséges kommunikációs hálózat kiépítése. A folyamatirányításban (DCS) jól ismert kétszintű hálózat választása célszerű. A hálózat kiépítésének legnagyobb problémája a nagy távolság és az ebből eredő költségvonzat. A konkrét megvalósítás a piacon kapható megoldások közül az, amelyiket a legkedvezőbb teljesítmény/ár arány jellemzi. [27]

4. Az információs rendszer rendszerterve

4.1 A különböző változatok elemzése és összehasonlítása

Az előző fejezetben ismertetett feladatok megkönnyítésére számos megoldást dolgoztak ki. Meg kell keresni azokat a megoldásokat, amelyek a leginkább megközelítik a felvázolt igényeket és lehetőségeket.

4.1.1 Lehetséges megoldások

4.1.1.1 Központi felügyeleti rendszerek

Központi felügyeleti rendszerekre már korábban szükség volt, mint ahogy a ma ismert adatgyűjtési és megjelenítési módok rendelkezésre álltak. Az első ilyen központok tehát a beszédközpontú (és telex, távíró, stb. alapú) információcserére hagyatkoztak, az információkat kézzel megrajzolt diagramokon, esetleg maketteken követték nyomon. Az ilyen központok kis iróniával a világháborús filmekben látott hadműveleti központokra hasonlítottak (ami végül is érthető, mert szervezési és irányítási feladatról volt szó).

A fejlődés az automatizáció minél magasabb szintjének elérésével volt egyenlő. Megjelentek a videokamerákat alkalmazó, képernyőfalas központok (főleg a nagyvárosi forgalmi csomópontokat felügyelő rendszereknél), illetve a sokféle egyedi, általában jelzőfényekkel teli térképtáblás megoldások. Az adatfeldolgozásra néhol először analóg számítógépeket használtak.

A felügyeleti rendszerekre nincs szabvány megoldás, nagyságuk és eltérő környezeti körülményeik miatt megvalósításuk egyedi feladat. Korszerűnek ma már csak a számítógépek hálózataira alapozott megoldás tekinthető. [8], [9], [15]

4.1.1.2 Helyszíni felügyeleti rendszerek

A helyszíni rendszerek két alapvető feladatot látnak el: irányítanak és/vagy adatot gyűjtenek.

Az irányítás lehet:

Az adatgyűjtés lehet:

Az irányítás és adatgyűjtés konkrét megvalósítása helyzethez igazodó. Az irányítást sokszor valamilyen jelzőlámparendszer végzi, de lehet a járművet közvetlenül befolyásoló (és azt szükség esetén automatikusan leállító) eszköz (pl. a MÁV vonatbefolyásoló rendszere). Begyűjtendő adat pedig lehet egy adott járművön utazók száma (ezt például a légrugókba épített nyomásmérők tudják, nem túl pontosan, de informatívan mérni), egy adott kereszteződés forgalmi terhelése (hurokkal vagy optikai érzékelővel), stb.

4.1.1.3 Tájékoztató rendszerek

A tájékoztató rendszerek két alapvető módon közölhetnek információt:

A közlés módja lehet:

Mindegyik rendszer valamilyen adatbázis alapján jelenít meg információkat.

4.1.1.4 Járműérzékelés és járműazonosítás

A járműérzékelés lehet:

A járműazonosítás lehet:

4.1.2 Megvalósított rendszerek

Az ismertetésre kerülő rendszerek egyike sem tekinthető teljes, vagy változtatás nélkül adaptálhatónak, viszont mindegyik tartalmaz olyan elemet, amely valamilyen módon megvalósítható, vagy a jövőben megfontolásra érdemes.

4.1.2.1 Központi felügyeleti rendszerek

Kassa

A szlovák DPMK cég Kassa tömegközlekedését látja el. Az általuk használt felügyeleti rendszert a térképtáblás megoldás jellemzi, ezen találhatók a rendszer állapotát jellemző jelzőfények. Hasonló elven működött Miskolcon a város hatáskörébe tartozó közlekedési jelzőlámparendszer is. A berendezések alapvetően önállóan működnek, csak jelentenek a központ felé, illetve központilag átkapcsolhatók valamely állapotukba (több fix programból a kiválasztottba). Ez a laza csatolású rendszer nem váltotta be a hozzá fűzött reményeket, s így karbantartását is elhanyagolták. A nyolcvanas évek végére mindkét rendszer elemeire esett szét, a központot selejtezték.

Értékelés: A rendszer előnye a szemléletes megjelenítés, amely átvételre érdemes.

4.1.2.2 Helyszíni felügyeleti rendszerek

Miskolc, végállomási irányítás

Az MKV (ma MVK RT.) a nyolcvanas évektől kezdte egyedi végállomási rendszereit kiépíteni, eleinte a felügyeleti rendszertől teljesen függetlenül. (Utóbbi elsősorban a humán kommunikációs technikában, pl. CB hálózat, fejlődött.)

A régebbi végállomási rendszerek gyakorlatilag fix programvezérlésű indító/érkeztető automaták voltak. Első bevezetett megvalósításuk diszkrét alkatrészekből állt (Szondi György utca 101/B v.á.), ennek továbbfejlesztéseként egy katalógus-áramkörökből (főleg 74-es sorozatú IC-kből és EPROM-okból) felépített, részben már kézzel is befolyásolható berendezés volt. Három példány épült ebből, egy a Tiszai pályaudvar autóbusz-végállomását, egy a villamos-végállomását, egy pedig az időközben megszűnt Majális-park végállomását segítette. Ez a berendezés soros porton át már egy VISINFORM tájékoztatótáblát is kezelni tudott.

A nyolcvanas évek végén bemutatásra került egy kisméretű, mikroprocesszorral vezérelt kártya, amely képes volt a korábban csak szekrény méretben kivitelezhető berendezés összes funkcióját ellátni. Ezt a berendezést külső, forgalmi szolgálattal nem rendelkező végállomásokra szánták, de végül csak a sikeresen vizsgázott deszkamodell készült el. A tervezés tapasztalatait később felhasználták egy hasonló funkciójú, de fejlettebb technológiájú berendezéshez, amelynek egy példányát az Arany János utcában, a 38-as viszonylat indításához használnak.

A Tiszai pályaudvaron működő berendezés elavulása és működtetésének problémái új rendszer tervezését tették szükségessé, amely eleme a fejlesztés alatt álló felügyeleti és információs rendszernek. (Lásd később részletesen.)

Értékelés: A fejlesztendő rendszernek alkalmazkodnia kell a régebbi változatok alapján kialakult kezelői gyakorlathoz.

Budapest, 4-es autóbuszvonal, közlekedési lámpák befolyásolása

A BKV abból a felismerésből kiindulva, hogy a tömegközlekedési járművek sok időt (és ezzel feleslegesen elpazarolt üzemanyagot) veszítenek a vonali megállóhelyek közelében található forgalomirányító jelzőlámpák miatt, melyek tilos jelzése újabb megállásra és várakozásra kényszerítik a járművek, kísérletet kezdett egy lámpabefolyásoló rendszerrel. A kijelölt jelzőlámpás kereszteződésekben az itt áthaladó vonalak járművein a KKVMF által kifejlesztett infraadó és -vevő berendezéseket szerelt fel. A lámpákhoz csatolt rendszer felismeri, ha autóbusz jelentkezett be és a helyi sajátosságoknak megfelelően pluszidőt ad a jármű áthaladásához. Megfelelő kiépítettség esetén akár 10-15%-os menetidő-csökkenés is elérhető, ám a kísérletek során csak 3-5%-ot mértek. [5], [6], [7]

Értékelés: Nyitva kell hagyni a lehetőséget az ilyen irányú továbbfejlesztésre.

4.1.2.3 Tájékoztató rendszerek

Visinform utastájékoztató rendszer

A MÁV (és a MALÉV is) több helyen alkalmaz Visinform szövegmegjelenítő eszközt, amelyekkel sportlétesítményekben is találkozhatunk. Az eszköz egyik nagy előnye, hogy csak állapotváltoztatáskor igényel energiát, képpontjai kétállapotúak. A fluoreszcens festéknek köszönhetően a nagy méretű kijelző messziről is jól olvasható. A táblához olyan illesztőrendszert szállítanak, amely bármely számítógépről soros porton át vezérelhető. Egyetlen hátránya a magas ár.

Két változata ismert. Az egyik előre feliratozott táblákból álló készletet tartalmaz, ebből "pörög ki" a kívánt szöveg. A megjelenítés esztétikus, de csak a készletből választható ki. A másik pixelekből állítja össze a szöveget, ami kevésbé szép, de bármilyen információ megjelenítésére alkalmas. A MÁV és a MALËV mindkét megoldást alkalmazza, a sportcsarnokok kijelzői pixelesek.

A MÁV kísérletezett kisebb állomásain más megoldásokkal is, így például Nyíregyházán egy időben egy HC kategóriájú gép (egy Commodore 64-es) és egy magasan rögzített nagyképernyős televízió dolgozott utastájékoztató berendezésként. Bár a rendszer működött, nem tekinthető igazi megoldásnak.

Értékelés: A Visinform a gyakorlatban jól bevált, alkalmazandó megoldás.

Zürich, komplex utastájékoztató rendszer

A zürichi vasúti főpályaudvar nagyságán kívül változatos információszolgáltató rendszeréről is ismert. Az utasok tájékozódását az alábbi eszközök segítik:

Ezek jó része Budapest nagyobb pályaudvarain is működik már, kisebb-nagyobb engedményeket téve a szolgáltatás minőségében. Ami a zürichi példában figyelemre méltó, az a rendszer egységes logikája és gördülékenysége, amely sajnos a magyar változatot kevésbé jellemzi.

Értékelés: Törekedni kell hasonlóan jól felépített tájékoztató rendszer kiépíthetőségére.

4.1.2.4 Érzékelés, azonosítás

Budapest, Cinkota, járműazonosítás

A budapesti Cinkota üzemegység a járművek azonosítására mágneses kódolvasást használt, kizárólag a telepen belül, a ki- és bejárati kapuknál, valamint az üzemanyagkútnál. A tapasztalatok azt mutatták, hogy a rendszer az elektromos zavarokra nagyon érzékeny és a megbízhatósága sem érte el a kívánt szintet.

Értékelés: Bár kimondottan autóbuszokra fejlesztették ki, ez a megoldás nem vált be.

BME, az ISM sáv használata

Az egyébként autóriasztók és távirányítós játékok részére fenntartott rádiósáv alkalmas rövid azonosító-információk átvitelére, erre dolgoztak ki példát a BME-n. A megoldás zavarvédelme azonban nem kifogástalan. [25]

Értékelés: A fejlesztés egy későbbi változatának felhasználása megfontolandó.

Budapest, 4-es autóbuszvonal, infraadós azonosítás

A helyszíni felügyeleti rendszereknél már említett infraadó és -vevő berendezések is alkalmasak azonosításra. Itt azonban a láthatóságot és a zavaró fények kiszűrését kell biztosítani, ami nem minden esetben valósítható meg. [6]

Értékelés: Korlátai ellenére alkalmazása megfontolandó.

Varsó, kártyás járműazonosítás

Varsóban az azonosítást részben továbbra is emberi segítséggel végzik, egyfajta kártyarendszerrel. A módszer valóban működőképes, ám korszerűtlen és korlátozott. Varsóban az üzemanyag-vételezés és a telepi, valamint a végállomási jelentkezéseknél használják, funkcióját tekintve menetlevél helyettesítőként.

Értékelés: Forgalmi járműazonosításra nem, de menetlevél-helyettesítőként használata megfontolandó.

TIRIS, Texas Instruments Inc., azonosítás

A TIRIS közvetlen kontaktust nem igénylő azonosítórendszer. Olyan kártyákkal üzemel, amelyek kicsiny rádióadóként üzemelnek, s saját kódjukat sugározzák. Ötletes módon az ehhez szükséges energiát az ajtót védő készülék által kibocsátott rádiófrekvenciás jelből állítják elő, saját energiaforrásuk nincs és csak szükség esetén, a beléptetőrendszer közvetlen közelében működnek. A rendszert számos, egymástól nagyon eltérő területen alkalmazzák a haszonállatok megjelölésétől a raktári rendszereken át a beléptető rendszerekig. [23]

A Miskolci Egyetem Informatikai Intézete a számítógépes laborok folyamatos üzeme és a jogosulatlan belépés megakadályozása céljából alkalmaz ilyen beléptetőrendszert. Ez a rendszer csak kis távolságokon át működőképes, max. 25-35 cm távolságból olvas, ez a gyártó adatlapja szerint 200-240 cm távolságig növelhető, míg a tömegközlekedés számára 4-5 méter lenne megfelelő. Minden más tulajdonsága (egyszerű, kompakt, olcsó, tápellátást nem igényel, elterjedt) kedvező.

Értékelés: Meg kell vizsgálni, miképpen alkalmazható a fenti korlát figyelembe vételével ez az azonosítótípus.

4.1.2.5 Terepi számítógéphálózat

A rendszer legköltségesebb része a városban szétszórt végállomások bekötése a hálózatba. A vállalati gyakorlatban alkalmazott megoldások a nagy távolságok miatt nem kerülhetnek szóba. A rendszernek nyitottnak kell lennie a továbbfejlesztésre is, azaz valamilyen szabványos megoldást kell alkalmazni.

NavelCord, TelComTec, telefonos adatkommunikáció

A NavelCord olyan, nem folytonos kommunikáción alapuló távfelügyeleti rendszer, amely alapkiépítésű PC-k távoli vezérlését is lehetővé teszi. Főképp telefonos, ritkábban rádiós kommunikációs kapcsolatban használják. Minimális követelményeket támaszt a hardverrel szemben. Sajnos integrálása meglévő rendszerekbe nehéz.

Értékelés: Az alapvető kommunikációhoz szükségtelen, a teljes rendszerbe pedig nem illeszkedik, viszont példa arra, hogy rossz hálózati infrastruktúra esetén is lehetséges jól működő adatátviteli hálózatot létrehozni.

TotalTel, nagysebességű vezeték nélküli átvitel

Kábelfektetés nélkül, gyorsan kiépíthető, nagyobb távolságú (10-60km), nagysebességű hálózat építhető ki rádiókapcsolaton alapuló rendszerrel. A kiépítéshez hatósági engedélyek (pl. frekvenciaengedély) szükséges és az adattovábbító berendezések költségesek. A rendszer alkalmas az Ethernet és az ISDN hálózatokkal való együttműködésre.

Értékelés: Városi körülmények között csak kivételes esetben indokolható használata, inkább a meglevő infrastruktúra használata ajánlott.

Nyíregyháza, kábeltévé alapú adattovábbítás

A nagyobb városokban lefektetett kábeletévé-hálózatok is felhasználhatók adattovábbításra. A nyíregyházi tapasztalatok szerint ez a megoldás a csak adattovábbítási célra létesített hálózatoknál jóval lassabb, de a telefonos kapcsolatnál nagyságrenddel gyorsabb működésre képes. [26]

Értékelés: A kábeltévé-hálózat Miskolcon is kiépült, a rendszer adatforgalmi igénye pedig alacsony, így használata megfontolandó.

4.1.3 Összefoglaló értékelés

Központi irányítási rendszereket jellemzően a miskolcinál nagyobb közlekedési vállalatok fejlesztettek ki, jelentős támogatással. Ezek beszerzése és adaptálása túl költséges lenne és képességeiket helyileg nem lehetne kihasználni. A saját fejlesztésű rendszerek pedig nem érték el a megfelelő fejlettségi szintet.

A helyi irányítás folyamatos fejlesztéseként kialakult egy számítógép-alapú megoldás, amely továbbfejleszthető és hálózatba integrálható.

Az utastájékoztatásnak mára jól kialakult típusai léteznek, ezek közül a táblás információszolgáltatás alkalmazása ajánlott, a beszédalapú és az internet-alapú alkalmazása megfontolandó.

A járműazonosítás és követés továbbra is nyitott kérdés, elsősorban költségvonzata miatt. Megfontolandó több lépcsőben fejleszteni, elsőként csupán jelenlét-érzékelést megvalósítva. Az azonosítók közül a passzívak költség és üzembiztonsági okokból, míg az aktívak (pl. rádiós vagy infrás) a lehetséges egyéb adatszolgáltatás (pl. utasszám) miatt előnyösek.

A kommunikációs kapcsolatot első lépésben a meglevő infrastruktúrára (telefon) lehet alapítani, de ezzel csak off-line kapcsolat valósítható meg alacsony költséggel. Állandó kapcsolatra alacsony sebességű bérelt vonal felelne meg, illetve valamilyen meglevő (egyre inkább internet-használatra szolgáló) csatorna egy részének felhasználása.

4.2 A kidolgozandó változat kiválasztása és megvalósíthatósági vizsgálata

4.2.1 Elvárások

A rendszer felépítésénél mindenképpen figyelembe kell venni, hogy a fejlesztés évekre nyúlik el és az elképzelések, valamint a felhasználható eszközök változnak. A rendszert tehát olyan elemekből kell felépíteni, amelyek önálló, illetve a tervezettnél alacsonyabb szintű kapcsolat esetén is az adott feladatot a lehető legjobban ellátják, nyitottak a fejlesztésre és bővítésre.

Elvárás továbbá, hogy a beruházási, karbantartási és üzemeltetési költségek a lehető legalacsonyabbak legyenek, annak ellenére, hogy ezek gyakran egymásnak is ellentmondanak, továbbá kizárhatják a legkorszerűbb megoldások teljes körű alkalmazását.

4.2.2 Pénzügyi és technikai megszorítások

A rendszer első változata megvalósításának egyik jellemző eleme volt, hogy a szükséges új alkatrészek beszerzési költsége az eddig megvalósított elemeknél elhanyagolható volt, jórészt egyéb területeken is használt, illetve lecserélésre kerülő egységeket kellett felhasználni. A végállomási rendszer alapját képező számítógépek olyan 3-6 éves IMB AT-k voltak, amelyek az irodai munkához már korszerűtlenek voltak, ám várható élettartamuk még több év, teljesítményük pedig a rendszer számára megfelelő volt.

További pénzügyi megszorítás volt a rendszerhez kifejlesztett kiegészítő berendezések kapun belüli gyárthatósága, amely komoly technikai és technológiai korlátot jelent. A vállalat elektronikai feladatokat végző csoportja elsősorban az URH alapú kommunikációs rendszer karbantartását végzi, kevés szabad kapacitása és nagyon korlátozott eszközállománya van. Konkrét példa ennek figyelembe vételére, hogy az összes tervezett nyomtatott áramköri lap egyoldalas, egyrétegű, kézzel kirajzolható és amatőr körülmények közt legyártható.

A megszorításokat a vállalat kockázatvállalási képességének szinte teljes hiánya és a legyártandó berendezések alacsony száma (összesen kevesebb, mint tíz szóba jöhető telepítési hely létezik jelenleg a városban) indokolja.

4.2.3 Eszközök

A feladat megvalósításához rendelkezésre álló eszközök jórészt korszerűtlenek. Az elektronikai feladatok kisipari körülmények közt folytathatók, több alapvető műszer hiányzik. A programfejlesztés eszközei és a platform több, mint tíz évesek. Mindezek ellenére egyetlen nélkülözhetetlen elem sem hiányzott a rendszer felépítésének megkezdéséhez, s ahol a tervek nem kerültek megvalósításra, ott főleg pénzügyi, kisebb részben technikai, vagy beszerzési okok játszottak közre.

A második változat a már magánszemélyek részére is elérhető internetes megoldásokra alapul.

4.2.4 Továbbfejlesztési lehetőségek

A rendszer különböző részei különböző állapotban vannak. Egyes részek csupán tervek, mások gyártásra várnak, egy nagyobb egység pedig készen van, üzemel, de bővíthető. A továbbfejlesztés tulajdonképpen folyamatos munka, egyrészt a rendszer teljes kiépülése, másrészt az elavuló és működésképtelenné váló egységek kiváltása a célja. A tervezés során az adaptálhatóságot is figyelembe kellett venni, hogy más jellegű forgalomi környezetbe is integrálható legyen a rendszer (Debrecennel és Kassával folytak tájékozódó jellegű tárgyalások).

A rendszer első változatának megvalósításából levont tapasztalatok alapján lehet megkezdeni a következő, költségesebb, de teljesítő képesebb változatának kifejlesztését (6. fejezet).

4.3 A hardver és szoftver rendszerterv elkészítése

A rendszer lehetőleg nagy tömegben gyártott, olcsó, újra felhasználható elemeket kell, hogy tartalmazzon. Mind a hardver, mind a szoftver ennek figyelembevételével határozandó meg.

4.3.1 Hardver

A rendszerben felhasználásra kerülő számítógépek IBM kompatibilisek. Ahol lehet, alacsony számítási teljesítményű változatokat kell felhasználni, mert ezek állnak szabadon rendelkezésre a cégen belül. (Ezek először az AT-k, majd néhány év múlva a 386-osok.) Emiatt a platform az első változatban a DOS, a másodikban a Linux (vagy Java futtatásra alkalmas egyéb rendszer, pl. Windows 95).

A számítógépeknek és az egyéb kiegészítő berendezéseknek mostoha körülmények közt kell folyamatos üzemben működniük, szennyezett, elektromos zavarokkal terhelt környezetben. A kiegészítő berendezések könnyen és gyorsan javítható kivitelűeknek kell lenniük. Erre a kártyás megoldás adódott, ahol a hibás egység egyszerűen kicserélhető, a javítás pedig a telepen történik.

A menetirányítói épületen kívüli berendezéseket mechanikailag ellenállóra, időjárásállóra kell tervezni.

A rendszer elemei:

4.3.1.1 Menetirányítói számítógép

(1) Végállomási gép

Az első változatban minimum DOS V3.3x futtatására alkalmas, legalább 640k RAM és 20Mbyte HDD kapacitású, floppyegységgel, 2 soros és 2 párhuzamos porttal rendelkező, tetszőleges monitorral ellátott (CGA nem ajánlott, de használható) PC szükséges a feladat ellátásához. A megjelenítés nem grafikus. A második változatban Linux futtatására alkalmas 386-os gép, 4M RAM-mal és 200Mbyte HDD-vel, valamint a már említett portokkal.

A portok kiosztása: 

COM1: utastájékoztató egység.
COM2: az alrendszerek közti kommunikáció (vagy hálózati kártya).
LPT1: a jelzőlámpa-vezérlő és az érzékelők (bővítőkártyás változat is lehet).
LPT2: nyomtató.

(2) Központi gép

Hálózati és osztott működésre alkalmas nagyteljesítményű PC, 16M RAM, min. 2G HDD, grafikus nagyfelbontású monitor, kettős hálózatkezelés (vállalati és terepi), szünetmentes tápegység. CD-ROM és szalagos backup egység ajánlott.

4.3.1.2 Utastájékoztató egység

Választás szerinti. A Visinform táblarendszer több változata kipróbálásra került, eredménnyel. Ezek a soros porton át kommunikálnak. Lehetséges a tájékoztatást monitoron megjeleníteni, vagy beszédszintézissel előállítani, utóbbira is történtek kísérletek. Eddig nem alkalmazott berendezés illesztése csupán a szükséges meghajtó-program megírását igényli.

Az utastájékoztatásra ajánlott tábla feliratainak 25-35 méterről is jól olvashatónak kell lenni. A táblán általában két oszlopban célszerű az időpontokat kiírni, ez soronként 2x4 karakter, 4 vagy 5 sorban, s külön sorban a pontos idő. Amennyiben feliratokat is szeretnénk megjeleníteni, úgy a két oszlop közé és az oszlopok szélére is célszerű karakteregységet elhelyezni, így soronként 11 betű áll rendelkezésre üzenetek megjelenítésére.

A központi rendszert kiegészítő utastájékoztató rendszer speciális, miután ott fizikailag nincs utasforgalom. Egyrészt itt működhet egy telefonon át hívható beszédszintetizátoros egység, másrészt itt lehet a bázisa egy internet alapú, napra kész információszolgálatnak.

4.3.1.3 Jelzőlámpa-rendszer


Jelzőlámpa elhelyezése

Kisfeszültségű, a közlekedésben használt jelzőfényekből megépíthető, olcsó, bevált megoldás, mely az előző rendszerekből került átvételre.

4.3.1.4 Érzékelők

Választás szerinti. Attól függőn, hogy érzékelnek, vagy azonosítanak is, más a számítógéppel való kommunikáció módja, utóbbi esetben saját illesztőkártyát igényel. A konkrét típushoz szükséges az illesztőprogram megírása is.

Ajánlott megoldások:

Jelenlét-érzékelés esetén az indítóhelyekre telepítendők az érzékelők, azonosítás esetén a végállomás járműforgalmi be- és kijárataihoz.

4.3.1.5 Kommunikációs egység

(1) Végállomásokon

Rádiós vagy telefonos modem. Ezek kezelése szabványos. LAN alkalmazása a nagy távolság miatt nem valósítható meg, internet/intranet alapú működéshez pedig a rendszer elemeinek teljesítőképessége jelen pillanatban nem elegendő, a második változatban azonban feltétel.

(2) Központban

Szükséges egy többvonalas kapcsolat működtetésére alkalmas fogadóhely (kezdetben egy vonallal is el lehet indulni, de a járműkövető rendszert ez nem tudja kiszolgálni) és külön kapcsolat a vállalati hálózathoz (LAN) és azon át később az internethez.

4.3.1.6 Járműfigyelő rendszer (érzékelők és kommunikáció)

Választás szerint. Az azonosítóknak képeseknek kell lenniük a járművek egyértelmű azonosítására az összes szokásos forgalmi helyzetben, s ezen információk eljuttatását a kommunikációs rendszernek a lehető leggyorsabban biztonságban továbbítania kell.

Ajánlott megoldások:

Optikai (infra) megoldásnál a láthatóságot kell megoldani. Az infraadó és -vevő egy kúpszögben képes adni és venni. Az adatok (biztonság kedvéért min. háromszor ismételt) átvitelére rendelkezésre álló idő 30ş-os látószög, jobbra 15ş-os tájolás, max. 72km/h sebesség, min. 0.5m távolság és max. 20m hatótáv esetén kb. 0.9s. Ha a szükséges adatblokk 80bit, akkor ennek háromszor ismételt átküldéséhez a szabványos 300Baud adatátviteli sebesség megfelel. Általában ennek többszöröse, 1200 vagy 2400Baud is könnyen megvalósítható. [6]

TIRIS rendszernél az adatok (biztonság kedvéért min. háromszor ismételt) átvitelére rendelkezésre álló idő max. 72km/h sebesség, min. 0.5m távolság és max. 2.5m hatótáv esetén kb. 0.25s. Ha a szükséges adatblokk 80bit és a kártya energiával való feltöltése félútig megtörténik (az adóegység teljesítménye nagyobb), akkor a háromszor ismételt átküldéséhez a szabványos 1200Baud adatátviteli sebesség megfelel. A TIRIS rendszer kimondottan gépjárművekre kifejlesztett változata 512 bites kártyát tartalmaz, az adatátvitel sebessége pedig elérheti a 300kbit/s értéket is, ami nagyságrendekkel jobb, mint a fentiekben számított. (A gyártó 100mph sebességre tesztelte a rendszert.) [23]

4.3.2 Szoftver

A szoftver írásakor figyelembe kell venni, hogy a rendszer képlékeny, ezért fel kell készülni a módosítási igényekre. Lehetőség szerint olyan önálló és önmagában is lehetőleg működőképes elemekből álljon a rendszer szoftver oldala, amely az eszközök cseréjekor az eltéréseket lehetőleg programmódosítás nélkül, konfigurálás, illetve megfelelő csereprogram segítségével is megoldható.

A szükséges szoftverelemek:

4.3.2.1 Végállomási forgalom-felügyelet

A szoftver ezen része több, funkcionálisan egyszerű, főleg hardvervezérlő programrészt tartalmaz. Ezek és feladataik részletesen:

(1) Indítás és érkeztetés

A rutinnak a megfelelő porton keresztül a megfelelő kódokat kell küldenie az indítási procedúra lefolytatásához. A kódok az alkalmazott hardvermegoldástól függenek.

Az indítási procedúrához szükséges bemenő adatok:

A szokásos indítási procedúra a miskolci városi autóbuszoknál:

t=-120... 0 s

A járművezetői pihenőhelyiségben a viszonylatot (pl. 31-es) jelző szám mellett figyelmeztető lámpa bekapcsolása.

t= -40... 0 s

Az indítóhely oszlopán elhelyezett jelzőn sárga figyelmeztetőjelzés megjelenítése.

t= 0... 10 s

Az indítóhely oszlopán zöld jelzés, igény esetén rövid kezdőhangjelzéssel.

A jelzők alaphelyzetben sötétek.

Amennyiben a kiépítés járműérzékelő vagy járműazonosító alrendszert is tartalmaz, a procedúra időben ( 0 s ) nem jelentkező jármű esetén az alábbiak szerint módosul:

t= 0...180 s

Az indítóhely sárga fénye figyelemfelhívó villogó jelzést ad. Amennyiben ezen idő alatt a jármű bejelentkezik, szabályosan végrehajtja a tíz másodperces zöldfázist, ha nem, a járatot törli. Első esetben "késett", második esetben "kimaradt" jelzéssel naplózza a rendszer az eseményt.

A szokásos indítási procedúra a miskolci villamosoknál:

t=-120... 0 s

A járművezetői pihenőhelyiségben a viszonylatot (pl. 2-es) jelző szám mellett figyelmeztető lámpa bekapcsolása.

t= 0... 10 s

A szakaszbiztosítón zöld jelzés, igény esetén rövid kezdőhangjelzéssel.

A pihenőtéri jelzők alaphelyzetben sötétek, az indítóhelyi vasúti szabványú szakaszbiztosító jelzőlámpa alaphelyzetben vörös fényű.

Az érkeztetés szintén a menetrend szerint történik, de külön jelzés nélkül, csupán naplózva. Amennyiben a jármű a megadott időben (általában a viszonylat hosszától és jellegzetességétől függően 2-4 perc ráhagyással) nem érkezik meg, vagy az előírtnál nagyobb eltéréssel fut be, azt a rendszer külön jelezheti a menetirányítónak.

(2) Utastájékoztatás

A rutin megvalósítása az alkalmazott hardvertől függ. A rutin által felhasznált adatok:

(3) Járműazonosítás és követés

A rutin megvalósítása az alkalmazott hardvertől függ. A rutin által felhasznált adatok:

(4) Naplózás

A rutin a programban kezdeményezett, vagy megtörtént összes eseményt regisztrálja egy külön adatbázisba.

(5) Menetirányító riasztása és tájékoztatása

A rutin célja a legfontosabb információk állandó megjelenítése és bármilyen rendellenes esemény esetén riasztása, pl. hangjelzéssel. A rutin által felhasznált adatok:

4.3.2.2 Végállomási adminisztratív funkciók

A szoftver ezen része önálló, kívánságra betölthető programokból áll.

(1) Információkérés és beavatkozás

A program a folyamatosan működő forgalom-felügyeleti program adatainak kezelését teszi több szempont szerint lehetővé, valamint lehetőséget nyújt a beavatkozásra.

A végállomásokon előforduló gyakoribb beavatkozások:

Ezek közül az első három eset általában műszaki vagy forgalmi okok miatt "elveszett" vagy késő jármű miatt fordul elő. Ezek rövid távú, egy-két indítást befolyásoló intézkedések, a menetrend egészét nem érintik. Ennyi idő alatt a végállomásnak (esetleg központi segítséggel) pótolnia kell a kiesést, akár tartalékjármű beállításával.

Ideiglenes menetrend két okból léphet érvénybe. Első esetben előre meghirdetett és a forgalomszervezés által kidolgozott menetrendre kell egy napra, vagy meghatározott időre áttérni, pl. nagyobb ünnepekkor. Ez a menetrend lényegében nem tér el a szokásostól, legfeljebb az áttérés és a visszaállás igényel jóváhagyást, valamint a változásra fel kell hívni az utazóközönség figyelmét. A második eset a forgalom kritikus helyzetében áll elő, amikor már nincs mód további tartalékokat beállítani (pl. télen, sorozatos műszaki hibák és a rossz útviszonyok miatt megnövekedett menetidők miatt). Ekkor a menetirányító "hevenyészet" menetrendet alkot, amelynek elsődleges célja az ütemes közlekedés fenntartása. [14]

tk = tf / n

A rendelkezésre álló járműveinek számával (n) osztania kell a teljes viszonylati fordulóidőt (tf) és a kapott értéket egész számra kerekítve kell indítási időközként kezelnie (pl. 5 jármű 60 perces fordulóidő esetén 12 percenkénti indítást tesz lehetővé). Ennek az esetnek egy másik változata, amikor nem kevesebb, hanem több jármű áll rendelkezésre és az utasok száma is indokolttá teszi a többletkapacitás bevetését. A számítási módszer ugyanaz.

A viszonylat felfüggesztését ellehetetlenült forgalmi viszonyok esetén kell elrendelni.

Minden tevékenység naplózásra kerül.

(2) Beosztás és menetlevél-kezelés

A program célja, hogy a szolgálatot teljesítő járművezetők munkanyilvántartása a valóságnak megfeleljen, a menetirányító tájékozott legyen a hozzá beosztott járművezetők pontos szolgálati helyéről, munkakezdéséről és végzéséről, váltásuk és munkahelyi szünetük idejéről, az esetleges napi átszerelésekről (egyik vonalról másikra, egyik végállomásról másikra), végállomásra érkezésükről és indulásukról, a beosztott járművekről, és hogy a menetlevelek adminisztrációja és kiadása csak másodpercekig tartson. A program "adatmalom" jelleggel fut, azaz a bemenő adatokat feldolgozza és kimeneti adatokat gyárt belőle, naponta általában egyszer. Az informálódáshoz szükséges adatokat a menetrendi tömbhöz csatolja, amely az információkérést kiszolgáló programból olvasható.

(3) Jegyzőkönyvek vezetése

Gyakorlatilag ez szövegszerkesztés, mindössze az elkészült állományok egy nyilvántartási rendszerbe is bekerülnek.

4.3.2.3 Egyéb végállomási funkciók

(1) Kommunikáció-kezelés

Ennek a rutinnak mindössze annyi a feladata, hogy felépítsen, fenntartson és lezárjon egy adatcsere-folyamatot, amely során a megfelelő adatállományok adását és vételét lebonyolítja.

(2) Tesztelő, konfiguráló, rendszerindító és egyéb segédprogramok

A tesztprogramok a csatlakoztatott hardveregységek működésének ellenőrzését teszik lehetővé nem szakember számára is.

A konfiguráló programok a rendszer igény szerinti átállítását teszik lehetővé.

A rendszerindítás a különböző részprogramok konfigurációnak megfelelő betöltődését, alapállapotba kerülését és megfelelő elindulását biztosítják. Ezt a számítógép rendszerindításához kell kötni, azaz ez a program együtt indul a számítógép hasonló funkciójú programjaival.

A rendszer üzemeltetéséhez szükség lehet további programokhoz is, ám ezek nem képezik szorosan a rendszer részét (pl. defragmentáló, víruskereső, stb. programok).

4.3.2.4 Központi rendszer (a végállomásitól eltérő elemek)

A központi rendszer logikailag nagyon hasonló a végállomásihoz, de egyes részeket más súllyal kezel. Itt csupán a nagyobb eltérések kerülnek kiemelésre.

(1) Indítás és érkeztetés (be és kiálló járművek)

A telepi kiindulásnak és beérkezésnek speciális menetrendje van, amely más leválogatási módszerrel készül el, mint a végállomási. Nincs szükség továbbá indítási procedúrára sem, pusztán tájékoztatásra és naplózásra.

(2) Járműazonosítás és követés

A központ az egész üzemterületen (városban) figyeli és gyűjti az adatokat.

(3) Grafikus megjelenítés

A begyűjtött adatok nagy mennyisége miatt szükséges azok vizualizációja. Mivel egyébként is térinformatikai jellegű alkalmazás, ehhez csatlakozhat egy GIS adatbázis is.

(4) Rendkívüli események levezénylését szolgáló rendszer

Ez a rész a begyűjtött információk, a rendelkezésre álló adatbázisok, a végállomásokkal meglévő kommunikációs kapcsolat és egy szakértői rendszer együttesét képzi. Gyakorlatilag ez a rendszer csúcsprogramja, s ennek megvalósítása tart majd a legtovább, jelenleg részletes megtervezése sem időszerű.

5. Az információs rendszer első változatának megtervezése és megvalósítása

5.1 Hardvertervezés

5.1.1 Főbb kiegészítőegységek rövid leírása

5.1.1.1 Visinform utastájékoztató tábla

A Visinform megjelenítők hardveres szempontból önálló intelligens egységnek számítanak. A rendszer szempontjából a kommunikáció fizikai és protokoll kérdései tisztázandók.

Eddig három típus került alkalmazásra, ezek jellemzői:

A működtetés az (1) típusnál a megjeleníteni kívánt karakterek soros portra küldését jelenti. A (2) és (3) típusnál a megjeleníteni kívánt információt a meghajtó-program megszakításon át való hívásával lehet kiküldeni. [22], [38], [39], [40]

5.1.1.2 Lámpavezérlés

A rendszerhez szükséges saját fejlesztés. A berendezés a printerporton keresztül vezérelhető, teljesítmény-kimeneteiről 12V-os izzók hajthatók meg. Kártyás felépítésű, egy kártya két lámpacsoportot szolgál ki, csoportonként három (tartózkodói, sárga és zöld) jelzőlámpával. A kártyák maximális száma 16, ez 32 lámpacsoport kiépítését teszi lehetővé, de ritkán szükséges 10-nél több.

A lámpacsoport jelzésképe a kártya átalakításával megváltoztatható, erre a Tiszai pu. villamos-végállomásra telepített berendezés a példa.

A lámpavezérlő kártyái egy buszrendszerbe kapcsolódnak. Ez 4 bites címet és 4 bites adatot tartalmaz. A kártyák egyedi címmel rendelkeznek, a nekik címzett adatot fogadják és tárolják, állapotukat annak megfelelően megváltoztatják. [16], [17], [18], [19], [20], [21], [22], [37], [38], [39], [40]

5.1.1.3 Jelenlét-érzékelés, járműazonosítás

A rendszer adatkapcsolattal rendelkező intelligens eszköz alkalmazására ad lehetőséget.

5.1.1.4 Telefon és rádiókapcsolat, off-line kapcsolat

Az adatátvitel az első változatban off-line, a szükséges adatok floppy-n érkeznek. Telefonos modem alkalmazása azonnal megoldható, a végállomások telefonkapcsolattal rendelkeznek. Rádiós kapcsolat megoldható, CB rendszerű rádiókapcsolat rendelkezésre áll. [24], [28], [29]

5.1.2 Részletes leírás

5.1.2.1 Berendezéslista


Végállomási alapkiépítés vázlata

5.1.2.2 Részegységek

INDI-PWRTápegység
INDI-LAXLámpavezérlő kártya
INDI-CKLLámpavezérlő állapotjelző
INDI-VILVillamos-végállomási indító-időzítő
INDI-VLDVillamos-végállomási állapotjelző
INDI-TSTKártyateszter

Jelzőlámpa-vezérlő blokkvázlata Villamos-v.á. kiegészítő blokkvázlata
Tesztelő-berendezés blokkvázlata

5.2 Szoftvertervezés

A rendszer működtetése a központban és a végállomásokon futó programok feladata. Az első változat C-ben íródott, DOS alá. Több olyan függvényt tartalmaz, amely a hardvert alacsony szinten, BIOS-on át, vagy közvetlenül éri el. Ezek a rutinok logikailag önálló speciális driverek. [22], [37], [38], [39]

A program forrása több, funkciók szerint elkülönített, részből áll:
indi.c programmag
indi'sc.cképernyőkezelő rutinok
indi'db.cadatkezelő rutinok (két változat szöveges és dBase állományokra)
indi'sh.cállapotmegjelenítés rutinjai
indi'sp.cutastájékoztató berendezés vezérlőrutinjai
indi'pp.clámpavezérlő rutinjai
indi'ky.ckezelői beavatkozások kiszolgálórutinjai
indi'us.cmenetrendi táblázat kezelőrutinjai
indi'mi.cmenetrendi folyamat vezérlőrutinjai

A leírásban a teljes forrásismertetés helyett, amely a program mérete miatt sem célszerű, a szerkezet és a rutinok kapcsolata kerül ismertetésre.

5.2.1 Menetrendkezelés

A programrész feladata a menetrendi adatbázis alapján a megfelelő időben az indítási folyamatokat elindítani és vezérelni, figyelembe véve az érzékelők adatait, a viszonylatok állapotjelzőit (pl. letiltás) és a kezelő által kezdeményezett eseményeket (pl. azonnal indítás).

A program külön kezeli a folyamat vezérlését és a folyamat indításának előkészítését. Az előbbi az indítási procedúra 2-5 perces folyamatát vezérli, viszonylatonként külön-külön, működési szempontból párhuzamosan. Az utóbbi keresést végez az adatbázisban, kezeli az állapotjelzőket és adatot szolgáltat a kezelőnek és az utastájékoztató berendezésnek.

Rutinok:

indi'us.c menetrendi táblázat kezelőrutinjai 

void com_proc( void );  // állapotkezelő

void     lost( int  );  // kimaradt járat kezelője
void dep_next( int  );  // következő indulás keresője
void arr_next( int  );  // következő érkezés keresője
void     runx( int  );  // azonnali indítás
void     tilt( int  );  // letiltás
void     spec( int  );  // átkapcsolás ideiglenes kezelői 
                        // menetrendre
void     plan( int  );  // visszakapcsolás eredeti 
                        // menetrendre

indi'mi.c menetrendi folyamat vezérlőrutinjai 

void dep_rfsh( void );  // indítási folyamat
void arr_rfsh( void );  // érkezési folyamat

A program minden viszonylatról a következő struktúrában tárol adatot: 

struct  LINES_INFO
{
    unsigned char num;          // lámpavezérlőhöz rendelt 
                                // azonosító

    unsigned char whr[ 16 ];    // célállomás

    unsigned int  dep;          // következő indulás ideje
    unsigned int  arr;          // következő érkezés ideje

    unsigned char idd[  6 ];    // következő induló járat 
                                // azonosítója
    unsigned char ida[  6 ];    // következő érkező járat 
                                // azonosítója

    unsigned char lmp;          // jelzőállapot
    unsigned char com;          // folyamatállapot
    unsigned char pos;          // kijelzési pozíció 
                                // képernyőn
    unsigned char shw;          // kijelzési pozíció 
                                // utastájékoztatón
};

A folyamatállapot lehet:

A struktúra globális tömbként került deklarálásra.

5.2.2 Hardvervezérlés

5.2.2.1 Utastájékoztató berendezés

Jelenleg az utastájékoztatás a hardverről szóló részben ismertetett Visinform rendszerrel történik. A programnak csak át kell adnia a megfelelő adatokat a megjelenítéshez, ezért csupán a szükséges adatkonverziót végzi el.

Rutinok: 

void viinit( void  );   // inicializálás
void vioutp( void  );   // adatkiírás
void vi_clr( void  );   // táblatörlés

5.2.2.2 Jelzőlámpa-vezérlés

A jelzőlámpa-vezérlés a hardverről szóló részben ismertetett saját fejlesztésű eszközzel történik. A programnak a folyamatállapotnak megfelelő jelzésképet kell a berendezés kódrendszerének megfelelően összeállítani és kiküldeni.

Rutinok: 

void lminit( void );    // inicializálás
void lmoutp( void );    // jelzés
void lm_clr( void );    // jelzés törlése

5.2.2.3 Érzékelők

Az érzékelők kezelése kétféle lehet, attól függően, hogy csupán jelenlétet érzékelnek, vagy képesek azonosítókód leolvasására is. Utóbbi esetben érkezési naplózás is történik, előbbi esetben pedig feltételeznünk kell, a megfelelő jármű áll indításnál az érzékelő hatókörében. Amennyiben nincs bekötve érzékelő, úgy alapértelmezésben pozitív eredménnyel tér vissza.

Rutinok: 

int dtinit( void );    // inicializálás
int dtread(  int );    // leolvasás

5.2.3 Kezelői felület

A kezelői felület az első változatban nem grafikus, azonban a könnyebb kezelhetőség és informálódás érdekében a megjelenítés felhasználja az IBM kvázigrafikus karaktereit is. A képernyőről a végállomásról induló vagy érkező járatok adatai olvashatók le választás szerint.

A megjelenő járati adatok:

A fejlécben állandóan megjelenő információk:

A láblécben megjelenő információk:

A beavatkozáshoz, vagy információkéréshez a képernyőn látható villogó jel (mutató) segíti kiválasztani a megfelelő viszonylatot. Amennyiben a kezelt járatok száma több, mint amennyi egy képernyőn elfér, az "oldalak" lapozhatók, az oldalszám pedig leolvasható az oldalkeretek tetejéről. A navigációra a nyílbillentyűk szolgálnak.

A menetrendi és a járati lista a kiválasztott adatbázis megjelenítése a képernyőn. Ezt egy gombnyomással kell kérni, majd eltűntetni, benne navigálni, lapozni pedig a nyílbillentyűkkel lehet.

Elérhető funkciók:

Információkérés:

F2

Érkezési idők

shF2

Indulási idők

F3

L

Menetrendlista

shF3

Járatlista

F4

Munkanap / szabadnap váltás

shF4

I

Pontos idő beállítása

Beavatkozási lehetőségek:

F5

K

-

Érkezési idők

F6

+

Indulási idők

F7

A

*

Menetrendlista

F8

T

del

Járatlista

F9

M

Munkanap / szabadnap váltás

shF9

E

Pontos idő beállítása

A kommunikáció a háttérben zajlik, kivéve a teljes adatbáziscserét, amelyhez viszont a rendszert le kell állítani (általában évente kétszer).

Rutinok:

indi'sc.c képernyőkezelő rutinok 

void  shwin( unsigned int );    // ablakok felépítése
void  clwin( unsigned int );    // ablakok törlése
void  uswin( unsigned int );    // ablak megnyitása írásra

indi'sh.c állapotmegjelenítés rutinjai 

void shinit( void );    // megjelenítés alaphelyzete
void  shtab( void );    // járati információk megjelenítése
void  shtmr( void );    // fejléc-információk megjelenítése
void  shtbg( int  );    // időpont megjelenítése
void  shnbg( int  );    // viszonylatszám megjelenítése
void  shmsg( char * );  // üzenetmegjelenítés (lábléc)

indi'ky.c kezelői beavatkozások kiszolgálórutinjai 

void com_rfsh( void );  // folyamatfigyelő és
                        // parancsvégrehajtó rutin
void     selx( void );  // kijelölő rutin
void     selv( void );  // kiválasztó rutin
void     quit( void );  // program befejezés

5.2.4 Naplózás

A program minden benne lezajló eseményt naplóz, ennek napi adatállományait menti. Az adatállomány egyszerű felépítésű, az időpontot, az esemény kódját és az esetleges paramétereket tartalmazza. A számítástechnikai zsargonban "log"-nak is hívott állomány alapján visszajátszható a végállomás egész napi tevékenysége. Minden olyan rutin tartalmaz hívást a naplózó rutinokra, amely kezelői beavatkozást szolgál ki, vagy az érkezéseket és az indulásokat befolyásolja.

Rutinok: 

void chk_dy( int );    // kezelői beavatkozások naplózása
void dep_dy( int );    // indulások naplózása
void arr_dy( int );    // érkezések naplózása

5.2.5 Inicializálás és hibakezelés

A program elindítása után az üzemszerű működési állapotig a következő feladatokat kell ellátnia:

A belső adattáblák (beleértve a megszakításkezelést is) felépítése során a program akkor lép ki, ha súlyos futtatási probléma lép fel. Ilyen lehet valamilyen rendszeridegen rezidens program memóriában léte (ide értve a vírusprogramokat is), amely vagy a memória méretét korlátozza, vagy a program kommunikációját akadályozza a hardverrel.

A paraméterek beolvasása során az általánosan megírt program a helyszíni körülményekhez áll be. A program egyrészt a DOS parancssorból vesz át argumentumokat, másrészt a konfigurációs állományt tölt be.

Parancssori argumentumok (kapcsolók): 

/L      Lámpavezérlő hardver engedélyezése.
/V      Utastájékoztató (Visinform) tábla engedélyezése.
/D      Érzékelők engedélyezése.
/T név  Konfigurációs állomány neve.

Konfigurációs állomány mezői: 

N:Viszonylatszám.
L:Lámpavezérlő kártya címe.
P:Megjelenítési ablak sorszáma a képernyőn.
V:Megjelenítési pozíció az utastájékoztató táblán.
T:Célállomás neve.

A parancssori argumentumokban engedélyezett hardvereszközt a program leteszteli és kilép, ha működést gátló hibát talált. Ekkor a kijavításig a rendszer az adott eszköz letiltásával üzemeltethető. A tesztelést a hardvereszközök "...init" nevű rutinjai végzik.

Az adatállományok beolvasása (beleértve a konfigurációs állományt) az adatbázis-kezelő rutinok feladata. Ekkor történik meg a belső adattáblák adatokkal való feltöltése is.

Ezek után a program üzemszerűen kezd működni. A programindulási idő hossza a bekapcsolt hardvereszközöktől, az adatbázisok számától és a számítógép sebességétől is függ, de legfeljebb 20 másodperc alatt lezajlik.

Rutinok: 

void config( char * );  // konfigurációs állomány olvasása
void dbinit( void );    // menetrendi adatbázis beállítása

void r_head( char *      );  // "fej" információk olvasása
void r_data( char *, int );  // "törzs" adatok olvasása

A programnak kidolgozásra került egy olyan változata, amely a hardverkezelő rutinokat külön tárrezidens programként tartalmazta, ezek folyamatos vezérlését ugyancsak egy rezidens program biztosította. Ez lehetővé tette az egyéb feladatok, pl. szövegszerkesztés elvégzését. A rezidens programok betöltődése és inicializálása hasonló módon történik, mint az eredeti programé, de a betöltést az operációs rendszer végzi, továbbá a kommunikáció formája változik meg, egységesen megszakításokon keresztül zajlik.

5.3 Beüzemelés

5.3.1 A kiépítés lépései

A rendszer kiépítésének lépései nem szigorúan kötött sorrendűek. Bizonyos lépések megelőzhetnek másokat, az alábbi sorrend inkább egy lehetséges variáció:

A rendszer már minimális kiépítettség esetén is több fontos feladatot képes ellátni. A fokozatos kiépítés az egy összegben kifizetendő költségeket mérsékli, továbbá lehetőséget ad a már bevezetett eszközök eredményességének megvizsgálására, tehát csökkenti a kockázatot.

5.3.2 Telepítés, tesztelés, karbantartás, szerviz

A rendszer telepítése a megfelelő hardverelemek összeállítása, tesztelése után a megfelelő programok és adatállományok számítógépre másolását és a konfigurációs állományok megírását jelenti.

Az első verzió program és adatelemei:

A telepítés után tesztüzem előzi meg a végleges üzembe helyezést. Ennek célja az esetleges hardverbizonytalanságok és konfigurációs hibák kiszűrése. A rendszer folyamatos üzemben működik, így szokás ezt az időszakot "égetésként" is emlegetni.

Karbantartásra a hardver oldalon van szükség, de ebbe a számítógép is beleértendő. A karbantartás teendői:

A hardverelemek közül a saját fejlesztésűek cseréje és javítása egyszerű, a hibakereséshez céleszköz (kártyateszter) készült.

A rendszerhez az alábbi kísérődokumentáció tartozik:

5.4 Tapasztalatok

A rendszer fejlesztése több éve tart. A legutóbb, 1998 elején az Újgyőri főtéren üzembe helyezett negyedik példány jelzi, hogy a rendszer sikeresen vizsgázott a gyakorlatban. A folyamatos üzemmel kapcsolatos kezdeti aggályokra a mostoha körülmények közt is évek óta működő berendezések adtak választ. A rendszert a forgalmi szolgálatot teljesítő személyzet is megkedvelte, továbbfejlesztésére is tett javaslatokat.

A fejlesztés során néhány elképzelésről beigazolódott, hogy zsákutcába vezet. Ilyen volt például a DOS-ra való alapozás, vagy a kommunikációs rendszer önálló kifejlesztésének kísérlete. Kiderült, hogy a költségkorlátok miatt a rendszerben egyébként kezdettől meglévő járműazonosítási lehetőségek csak a teljes, városi szinten való kiépülés után valósíthatók meg.

Olyan új rendszerre van szükség, amelynek fejlesztőeszközei támogatják az elosztott rendszerek kifejlesztését, a többszálú működést, a szabványos adatbázisok elérését, az információs hálózatba (internetbe) integrálhatóságot, a felhasználóbarát grafikus környezetet. Mindezeket úgy, hogy a már kifejlesztett eszközök a lehető legkevesebb átalakítást szenvedjék el.

Az utóbbi két év során olyan új számítástechnikai eszközök váltak elérhetővé, amelyek segítségével a fejlesztés során felmerült problémák és nehézségek elháríthatók. A következő fejezetben tehát egy korszerű, második változat tervének ismertetésére kerül sor.

6. Az információs rendszer második változata

Az információs rendszer második változatának megtervezése az alábbi fontosabb számítástechnikai eseményeknek köszönhető:

Az új változat ezek figyelembevételével és a megelőző fejlesztés tapasztalataival, illetve átvehető, átírható elemeinek felhasználásával készült el.

6.1 Az internet/intranet alkalmazások alapjai

6.1.1 Osztott rendszerek jellemzői

Az osztott rendszerek önmagukban intelligens berendezésekből (gyakorlatilag általános célú, vagy speciális számítógépekből) álló hálózatok, amelyek osztoznak a rendszerben található erőforrásokon és kommunikációt folytatnak egymással. Nem szükséges minden funkció ellátására képes központ definiálása, mint a klasszikus hierarchikus rendszerekben.

A kommunikáció fizikai megvalósítása a rendszer szempontjából másodlagos, csupán a sebesség és az elérhetőség befolyásolja a működést, függetlenül attól, hogy ez rádióösszeköttetés, telefonvonal, sodrott érpár, koaxiális kábel, optikai vonal, vagy egyéb, illetve ezek kombinációja.

A legnagyobb probléma, hogy homogén hálózati környezet létrehozása csak teljes egyidejű rendszerkiépítés során történhet problémamentesen, a továbbiakban pedig korlátja lehet a fejlesztésnek. A gyakorlatban a nyílt, inhomogén rendszerek vannak túlsúlyban. [28], [29]

Inhomogén hálózati környezetben megoldandó problémák:

6.1.2 Internet/intranet

Az internet, a "hálózatok hálózata" a világ legnagyobb nyílt rendszere, pontosabban ma már a világhálózat. Célszerű ezért az itt elterjedt és bevált megoldások átvétele, mellyel a külvilággal való kapcsolattartás is egyszerűsödik. Az elmúlt évben intranet néven az interneten bevált megoldások léptek "kapun belülre" a vállalatoknál. Az intranet tehát nem más, mint a szabványos internet megoldások cégen belüli használata, jól elválasztva a külvilágtól. A belső hálózat és a külvilág ún. tűzfalakon át kapcsolódik össze, szigorúan szabályozva mindkét irányban az információk áramlását és a hozzáférési jogokat, védve a cég érdekeit. Nyílt hálózatok esetén fokozottan figyelemmel kell lenni az adatvédelmi és biztonsági kérdésekre.

Az internet a hatvanas években katonai fejlesztésnek indult, majd a kutatási szféra kezelésébe került. Alapgondolata, hogy a rendszer egyes elemeinek kiesése ne okozza a teljes rendszer leállását, eredetileg kimondottan hadászati megfontolásokból következett. Az eredmény egy nem kimondottan koordinált, viszont könnyen fejleszthető és elterjedt megoldás lett, köszönhetően a körülbelül harminc éves fejlesztési munkának.

Az internet-megoldások számára nincs előírt fizikai közeg, azaz a hardver és a kommunikációs vonal bármi lehet, ha teljesít bizonyos minimális követelményeket. Az adattovábbítási protokoll a TCP/IP, de alhálózatokban, ha azok megfelelő gateway (átjáró) segítségével kapcsolódnak az internetre, ez sem követelmény (pl. Windows/Novell helyi hálózatok).

Az internet használatához olyan programok szükségesek, amelyek képesek kezelni egy vagy több ún. szolgáltatást és legalább a kapcsolat idejére rendelkeznek internet (IP) címmel. Az elterjedtebb szolgáltatások:
telnet távoli gép használatára;
ftp állomány fel- és letöltésre;
news hírcsoportok kezelésére;
mail levelezésre;
http web-böngészésre.

Ezen kívül számos más szolgáltatás is létezik.

Az IP címek jelenleg 32 bitesek, ez azonban mára kevésnek bizonyult, így bevezetés alatt áll az új, 128 bites IPv6 címrendszer. Ez a Föld minden négyzetcentiméterére milliárdos nagyságrendű egyedi címet biztosít, ez valószínűleg elegendő lesz. [36], [41], [47]

6.1.3 Kliens/szerver modell

Bár nem csak az interneten alkalmazzák a kliens/szerver megoldásokat, gyakran emlegetik együtt a világhálózattal. Miután a kliens/szerver modell lényege, hogy egyes programok kérésekkel fordulhatnak más programokhoz, amelyek ezeket kiszolgálják és az eredményt visszaküldik, látható, hogy mindez hálózati környezetben is működik, csupán az üzenetek nem csupán programok, de gépek között is cserélődnek. A szerverek szolgáltatásai más szerverek szolgáltatásaira épülhetnek (ekkor ők a kliensek). A modell rugalmas, lehetővé teszi az erőforrás-gazdálkodást. A jól meghatározott kapcsolattartási elv miatt könnyen fejleszthető segítségével bármilyen alkalmazás.

A kliens/szerver modell a leggyakrabban az adatbázis-kezelés során használják, de az egész internet működése (pl. címszolgáltatás, routing) is erre alapul. Ebből következik, hogy az adatbázis-kezelő nyelvekben és rendszerekben, valamint az internet alapját képező UNIX változatok programnyelveiben (elsősorban a C-ben) adottak erre az eszközök. Lényegében minden többfeladatos, többfelhasználós rendszer alkalmaz kliens/szerver megoldásokat.

A programfejlesztés egyik új eszköze a Java, amely az összes hálózati környezetben előnyt jelentő jellemző mellé egy eddig nagyon hiányoltat is tartalmaz: maga a futtatható kód, amelyet a fordító generál, is platform-független, tehát ezen programok számára az internet bármely (Java-képes) pontja alkalmazási hely lehet. [41], [42], [43], [44], [45]

6.1.4 Adatbázisok

A hálózati adatbázisok terén is megfigyelhető egyfajta egységesülés. Itt a legutóbbi időkben az SQL rendszer vált kvázi-szabvánnyá. Az SQL maga egy viszonylag nem túl sok elemet tartalmazó lekérdezőnyelv, mely a természetes angol nyelvtanhoz is közel áll. Kliens oldalon így ennek kezelése nagyon egyszerű, viszont robosztus, nagy teljesítményű szervereket igényel. Ennek ellenére új, adatbázis-kezelést is igénylő rendszert lehetőleg SQL képességgel kell fejleszteni. [46], [47]

6.1.5 Biztonsági kérdések, hibakezelés, hibatűrés

Az adatbázisokkal kapcsolatos kérdések jó része biztonsági kérdés. Részint az adatok elérhetősége és illetéktelenektől való elzárása, részint az adatbázisban szereplő adatok nem kívánt megváltozása, sérülése elleni védekezés a megoldandó feladat.

A jogosultsági kérdések kifinomult hozzáférési szinteket hoztak létre, külön jog az olvasási, az írási, a törlési és a szerkezetmódosítási. A jog hatóköre is változatos lehet, a most használatos rendszerekben már mező szintű védelem is létezik.

Az adatbázis adatbiztonsága és konzisztenciája bonyolult tárolási és tranzakció-kezelési kérdéseket vetnek föl. Az adatbázisszerverek erőforrásigénye főleg ebből az igényből fakad. A rendszernek le kell kezelnie az előforduló hibákat, hibatűrően kell működnie, azaz a szolgáltatást igénybe vevőknek nem szabad az esetleges problémákról tudomást szerezni. A rendszernek rendelkeznie kell annyi tartalékkal, amellyel legalább a legfontosabb szolgáltatások fenntarthatók, illetve végső esetben a rendszer korrekten, adatvesztés nélkül le tud állni (elegáns leépülés). [46]

6.1.6 Felhasználói felület

A közhiedelemmel ellentétben ma is van létjogosultsága a nem-grafikus megjelenítési módoknak, főleg az adatrögzítői munkakörökben. Ennek ellenére egy rendszertől ma már elvárható, hogy a felhasználóval grafikus, felhasználóbarát felületen át tartsa a kapcsolatot.

A kilencvenes évek második felére gyakorlatilag három alapvető grafikus környezet maradt talpon:

Kísérletek történtek platform-független grafikai környezet létrehozására (pl. OpenGL), de a sikert a WWW elterjedése hozta el. Ma egy Netscape, vagy egy MS Explorer (nagyjából) ugyanazt a kezelői felületet képes biztosítani a PC-től a munkaállomásokig bármilyen felhasználó számára. A Java pedig többek közt a webnek köszönheti terjedését, mivel alkalmas a webböngésző programokban való futásra is. [44], [45]

6.2 Felhasznált eszközök

A második változat internet alapú rendszer. A rendszer kifejlesztéséhez és működtetéséhez tehát szükség van néhány szoftvereszközre (és természetesen olyan hardverre, amely ezeket futtatni képes).

6.2.1 Operációs rendszer

PC-re alapozott rendszerben az alábbi operációs rendszerek érhetők el:

Felhasználásra olyan operációs rendszert kell választani, amely többfeladatos, többfelhasználós, megbízható, erőforrás-takarékos. Emiatt első közelítésben az NT kivételével az összes nem UNIX alapú megoldás elvetésre kerül, az utolsó feltétel miatt pedig az NT és az SCO UNIX sem alkalmazható. A FreeBSD és a QNX szoftver-ellátottsága nem éri el a Linux-ét, így ez utóbbi a választott operációs rendszer.

Linux

A Linux egy többfeladatos, többfelhasználós operációs rendszer. Olyan UNIX klón, amely megkapta a POSIX kompatibilitás minősítését. A Linux tehát futtatni képes a UNIX-ra írt alkalmazásokat. Folyamatosan fejlesztik az egész világon. Az eredetileg diplomafeladatnak indult, majd az egy ideig kedvtelésből fejlesztett rendszer mára az üzleti életbe is átjutott. Sok esetben használják intézményi szerverként, megbízhatósága igen jó, ismert szoftvergyártók termékeit is megelőzi.

Az információs rendszer szerverfunkcióit Linux operációs rendszeren lehet a leghatékonyabban megvalósítani, de a végállomási gépekre is ennek a rendszernek a telepítése javasolt.

A telepítés menete:

[32], [33], [34], [35], [36]

6.2.2 Webszerver jellemzői

Linuxon elérhető elterjedtebb webszerverek:

Mindhárom stabil, megbízható szerver, ám az első kettő tudásában elmarad az Apache-tól.

Apache

A rendszer épít a web előnyeire, így egy könnyen telepíthető és karbantartható, jól bővíthető webszerverre van szükség. Az elmúlt évek tapasztalatai szerint az Apache megfelelő választás, jól bövíthető szerveroldali alkalmazásokkal (CGI, SSI) és megbízhatóan üzemel.

A telepítés lényegében a megfelelő (legújabb verziójú) csomag letöltése, kitömörítése és a telepítőprogram elindítása. A konfigurálás jól dokumentált leíróállományok módosításával lehetséges. [32], [33], [36], [47]

6.2.3 Adat-báziskezelő jellemzői

Bár Linux alá is több tucat adatbázis-kezelő érhető el, választani olyat kell, amely több platformon is ismert, elterjedt, támogatott. Az ANSI leír egy szabványos adatkezelő nyelvek, az SQL-t, amelyet korlátozottan, vagy teljes egészében több adatbázis-kezelő is ismer. Ezek közül a Hughes Technologies mSQL terméke tűnik ki egyszerűsége miatt.

mSQL

Adatbázis-kezelőnek olyan SQL rendszerű szoftvert kell választani, amely nem igényel a szükségesnél nagyobb erőforrásokat. Az mSQL ilyen korlátozott tudású és igényű program, de az információs rendszer által támasztott követelményeknek tökéletesen megfelel.

A telepítése hosszas hangolást igényel, továbbá kevés programozást is, mivel nem választható el a feladathoz kapcsolódó adatbázisrendszer létrehozásától.

A rendszer egyébként más SQL szerverhez is kapcsolódhat. A vállalati belső rendszerhez szükséges nagyobb teljesítményű (és esetleg más platformon futó) SQL szerver elérése is megoldott. [33], [45], [47]

6.2.4 Programnyelvek jellemzői

Linux alatt minden ismert és igen sok kevéssé ismert programnyelv érhető el. Mivel a Linux UNIX klón, "anyanyelve" a C. A C összes továbbfejlesztése (Object C, C++, Paralel C, Java, stb.), illetve más, általános célú programnyelv (Pascal, Basic, Fortran) is megtalálható a fejlesztői csomagokban. A fejlesztés egy lehetséges későbbi szintjén, a szakértői rendszer megvalósításakor pedig a Lisp és a Prolog is felhasználható.

A fejlesztés során (az SQL-en kívül) gyakorlatilag a "C családból" származó nyelvek kerülnek felhasználásra. A C objektum-orientált továbbfejlesztése a C++, amely kevés megszorítással eredeti (ANSI) C forrásokat is képes fordítani. A következő továbbfejlesztés, a hálózati alkalmazásokra kifejlesztett Java már nem ennyire átjárható, inkább oldalági rokona, mintsem utóda a C++-nak. Ennek ellenére ma ez a legkorszerűbb fejlesztési eszközök egyike, és a régebbi C programok portolása (átírása) általában nem ütközik lényegi nehézségekbe. Maga a Java háromféle változatban ismert: Java program, Java applet és Javascript. Emellett UNIX környezetben még ún. shell scriptek alkalmazása is szükséges lehet.

Az információs rendszer az előző, C-ben írt változatból forráskódot is átvesz. A fejlesztés első változatánál szerencsés választás volt a C nyelv alkalmazása, mivel ez egyben a UNIX alapú rendszerek alapnyelve is, illetve a Javaba átírható, bizonyos részek tehát csekély módosítással átvehetők.

C, C++

Natív kódot eredményez fordítása, így (az eredeti gépi kódú programok kivételével) a lehető leggyorsabb programfutást teszi lehetővé. Előnye még a hardverközeli programozhatóság és a felhasználható programkönyvtárak (library-k) nagy száma. Bizonyos szabályok betartásával hordozható (portábilis) program írható, ez azonban UNIX alatt csak forrásnyelvi szinten igaz, és nem a lefordított kódra. A grafikus és az elosztott rendszerek fejlesztése kiegészítők nélkül nehézkes. [36], [37]

Java

A Java igazi platform-független nyelv, programjai változtatás nélkül futnak bármely Java-képes rendszer alatt. Nem natív, hanem egy köztes, ún. byte-kódba fordítható le, azaz a futtatás interpreter elvű. Ebből következik a Java legnagyobb hátránya, a viszonylagos lassúsága. Ezt a Java-futtató környezet (Java-engine, JVM Java Virtual Machine) úgy képes részben ellensúlyozni, hogy számos, erőforrás-igényes, időkritikus részletet eleve natív kódban tartalmaz, a Java program csupán hívja ezeket a rutinokat (Javaban osztályok és metódusok).

A Java futtatása az alábbi elterjedt platformokon lehetséges:

A Java programok futtatásához szükséges a Java-interpreter megléte, bár ezt a szolgáltatást az operációs rendszer is nyújthatja (pl. Linux). A Java programot alkotó osztályok könnyen lecserélhetők, ami a fejlesztést és a bővítést könnyítik meg. [41], [42], [43], [44], [45]

Scriptek

Kiegészítésképpen szükség lehet az operációs rendszerben néhány feladat egyszerű megfogalmazására, erre valók a scriptek. Linux alatt az elterjedt shell-ek (ksh, bsh, csh, zsh, bash, tcsh) közül a legkönnyebben programozható bash-t érdemes választani. [36]

Az mSQL szintén scriptekkel (természetesen a sajátjával) vezérelhető.

6.2.5 Felhasználói felület alapja

A felhasználói felület alapja UNIX rendszerek alatt az X Window. Ennek programozása nagyon körülményes, helyette valamilyen segédeszköz, például a Motif alkalmazása terjedt el. Azonban ez is meglehetősen összetett és költséges fejlesztőeszköz.

HTML

A web elterjedésével egy nagyon egyszerű felhasználói felületet leíró nyelv vált elérhetővé, a HTML. A HTML form-jai képesek hívni az őket lekezelő (C, Perl, script) alkalmazásokat, amelyek vagy CGI (Common Gate Interface) segítségével, vagy SSI (Server Side Include) kapcsolódnak a laphoz. Mindkét esetben a kiszolgálógépen futnak a programok. Lehetséges azonban Java applet-ek hozzárendelése is, ekkor a kliens gépén fut majd a program (csökkentve a szerver terhelését). A HTML emellett más eszközöket is tartalmaz (pl. map-ek), mellyel nagyon egyszerűen elkészíthetők a kezeléshez szükséges felületek. Egyetlen kikötés, hogy a kliens oldal rendelkezzen webböngésző programmal (pl. Netscape Navigator, vagy MS Explorer) [30], [31]

Java awt

A felhasználói felület a Java awt (Abstract Window Toolkit) csomagjának felhasználásával készíthető el, úgy, hogy mind appletként, mind önálló alkalmazásként futtatható. (Az appletként való futtatást nehezíti a jelenleg zajló verzióváltás, mivel egyes webböngészők még nem ismerik az új Java leírást.) [44], [45]

6.3 Az információs rendszer alkalmazásai

6.3.1 A rendszer áttekintő vázlata

A Java szigorúan objektum-orientált nyelv, így meg kell határozni a szükséges osztályokat és interfészeket. Ezek három alapvető csoportba sorolhatók:

Az adatkezelés és a hardverek vezérlése különálló ún. thread-ekben fut, folyamatosan. Ezen kívül az adatokhoz korlátozottan kívülről is hozzá lehet férni (pl. utasmenetrend lekérdezése interneten át). A felhasználói felület grafikus, eseményvezérelt.


Felhasználói felület általános felosztása

A felhasználói felülethez felhasznált Java csomagok: 

java.awt.*;
java.awt.event.*;
java.applet.*;
java.lang.System;

Az adatkezeléshez felhasznált Java csomagok: 

java.net.*;
java.io.*;
java.rmi.*;
java.sql.*;

A hardvervezérléshez felhasznált Java csomagok: 

java.io.*;
java.applet.*;
java.lang.System;

A rendszer egymással együttműködő, de könnyen lecserélhető önálló osztályokból és ezek metódusaiból épül fel, ezek lefordított változata a .class. Amennyiben egy ilyen osztály tartalmazza a main, illetve az init, start, stop metódusokat, akkor önálló alkalmazásként, illetve weben át használható appletként is használható. Ugyanazt az osztályt tehát a célnak megfelelően többen is többféleképpen futtathatják. Ebből következik az is, hogy a rendszer vezérlése (a megfelelő jogosultságok esetén) távolról is történhet, így a csekély forgalmú korahajnali, délelőtti és éjszakai időszakokban akár emberi felügyelet nélkül, központi felügyelettel üzemelhet egy végállomási rendszer. [41], [42], [43], [44], [45]

A felhasználói felület három részre oszlik. A fejrészben az összefoglaló információk jelennek meg. A törzsrészben nyílnak a különböző alkalmazások ablakai. A lábrészben a menü gombjai helyezkednek el és a rendszer üzenetei (adatolvasás, hibajelzések, stb.) olvashatók.

Az adatkezelő (és így a teljes rendszer) a menetrendi adatbázisokra támaszkodik. A belső adattábla logikája hasonló az első változat LINES_INFO struktúrájához: 

public class Lines
{
  int signPos;          // lámpavezérlő azonosítója
  int cellPos;          // kijelzési pozíció képernyőn
  int showPos;          // pozíció utastájékoztatón

  String termName;      // célállomás

  int depTime;          // következő indulás ideje
  int arrTime;          // következő érkezés ideje

  String nextDepId;     // köv. induló járat azonosítója
  String nextArrId;     // köv. érkező járat azonosítója

  boolean signWarn;     // jelzőállapot
  boolean signYellow;
  boolean signGreen;

  Status status;       // folyamatállapot

  public Lines()
  {
    ...
  }
};

6.3.2 Az alkalmazások

6.3.2.1 Indítás és érkeztetés

Az indítás és érkeztetés folyamata megegyezik az előző változatban ismertetettel. A kezelés a grafikus környezet miatt könnyebb, csupán a megfelelő menügomb megnyomását kell kezdeményezni. A menetrendi információk szűrten is lekérhetők csak viszonylatra (viszonylatszámot tartalmazó gomb), járatra (járatszámot tartalmazó gomb), külső végállomásra (végállomás nevét tartalmazó gomb) szűkítve, alapértelmezésben pedig a saját végállomás (az alábbi ábrán a Repülőtér) adatai olvashatók. A beavatkozások is innen kérhetők.

A kijelzés a menetrend és az azonosítók adatai alapján frissül.


Indítások képernyője


Érkezések képernyője

6.3.2.2 Jelzőlámpa-vezérlés és utastájékoztatás

Ezen részek lényegében az előző változatból kerültek átvételre, funkciójuk és működésük nem változott. Miután külön thread-ben futnak, csupán a megfelelő adatok leolvasásához szükséges részt kellett módosítani (Lines class).

A lámpavezérlést kezelő osztály (természetesen a hardver csekély módosításával) kötöttpályás járművek végállomásain a váltók vezérlését is megoldhatja. Ekkor a megjelenítési rész egy vázlatos végállomási térképpel is bővül, amelyen a vágányok váltóinak és jelzőinek állapota tekinthető meg együtt.

6.3.2.4 Járműazonosítás és követés

A járműazonosítás szintén önálló thread, a Lines classt bővíti az épp beazonosított járművek azonosítójával és észlelési idejével. Ez naplózásra kerül, valamint riasztást generál, amennyiben nem a menetrend szerinti jármű, vagy nem időben jelent meg.

6.3.2.5 Naplózás

A naplózás adatkezelése hasonló az előző változathoz, viszont önálló threadben fut és az információkat eseménykezelőn (event manager) keresztül kapja meg.

6.3.2.6 Kommunikáció és adatgyűjtés

A kommunikáció és általában az adatforgalom a háttérben zajlik, főleg a java.net.* és java.io.* metódusainak hívásával, s a képernyőn csak néhány üzenet kiírását végzi el (pl. menetrend frissítve, hálózat elérhetetlen, stb.).

6.3.2.7 Riasztás és tájékoztatás

A riasztás és tájékoztatás a képernyőablak alsó részét (láb) használja, itt jeleníti meg üzeneteit. Riasztást az érzékelők, vagy egy másik végállomási (vagy a központi) rendszer generálhat.

6.3.2.8 Rendkívüli események levezénylése

Rendkívüli eseményt részben maga a rendszer is jelezhet, részben pedig egyéb információk (telefon, URH) alapján lehet kezdeményezni. A központban a megfelelő riasztás olyan programrészeket is aktiválhat, amelyek jelenleg még nem képezik a rendszer részét (pl. szakértői alrendszer), de ezek beépítésére a lehetőség adott.

6.3.2.9 Információkérés és beavatkozás

Az információkérés és beavatkozás a képernyőablak középső részét (törzs) használja, ide kérhetők az indulások, érkezések, a menetrendek és a beosztások adatai. A megvalósított funkciók (pl. járatcsere) az előző változattal egyeznek meg, de használatuk a grafikus megjelenítésnek köszönhetően egyszerűsödött. Ez is a java eseménykezelőjére, a java.awt.event.* csomag ActionListener() és ActionPerformed() metódusaira épül.

6.3.2.10 Jegyzőkönyvek vezetése

A jegyzőkönyvek vezetése új funkció. Rövid, szabadszöveges állományok megszerkesztésére ad lehetőséget, amelyek az internet e-mail-ként azonnal továbbíthatók a központba a megfelelő azonosító és technikai információkkal együtt. A java kiemelten támogatja ezen ún. user-interface funkciókat, jelen esetben a TextArea() awt metódust.


Jegyzőkönyv képernyője

6.3.2.11 Beosztás és menetlevél-kezelés

A beosztás és menetlevél-kezelés új szolgáltatás. Lényegében a beosztás két lista automatikus leválogatása (részletes leírás a 3. fejezetben), valamint az esetleges aktuális változások kézi bevitele (járatszám, műszakszám, járműazonosító, dolgozói azonosító). A menetlevél ezen információk alapján kerül helyben kinyomtatásra.

6.3.2.12 Tesztelő, konfiguráló, rendszerindító és egyéb segédprogramok

A rendszerindítás és karbantartás az operációs rendszer (részben szintén távvezérelhető) programjai segítségével történik. A java alkalmazások általános indítókódja a mellékletben (E) megtalálható.

6.4 A rendszer továbbfejlesztési lehetőségei

A rendszer jelenlegi alkalmazási körében két nagy fejlesztési lehetőséggel rendelkezik. Az egyik a térinformatikai kiegészítés, a másik a szakértői rendszerrel való döntéstámogatás.

Az információs rendszerhez kapcsolódó térinformatikai kiegészítés és az erre épülő szakértői rendszer a rendkívüli események gyors, részben automatikus kezelésével javíthatná (méghozzá látványosan) az egész teljesítményét.

További fejlesztési lehetőségek inkább a jelenlegitől eltérő környezetben merülhetnek fel. Zártpályás rendszerű járműveknél lehetséges a járműfigyelő és követő rendszer továbbfejlesztése automatikus járművezérlés felé (pl. metró).

Az információs rendszer elvi felépítése nem zárja ki, hogy más közüzemi feladatokhoz is adaptálható legyen (közúti jelzőlámpa-felügyeleti rendszer, felvonók távfelügyelete, rendszeres szállítási feladatok felügyelete (pl. szemétgyűjtés), áram, víz, gáz, stb. távfelügyeleti rendszere), mivel gyakorlatilag ezek mind diszpécser-feladatok.

A rendszer a későbbiekben alkalmassá tehető az ún. meghívásos közlekedtetésre, azaz kiépíthetők olyan feltételes megállók, melyeket csak akkor érintenek a járatok, ha erre igény jelentkezik, s csak azon járatok, amelyekre jelentkezik. Ez alacsony forgalmú, de jelenleg a városi hálózatba be nem kötött területek közlekedési szükségleteit is kielégítheti. A buszjárat hívható a megállóból, de weben át előre meg is "rendelhető".

7. Összefoglalás

Az információs rendszer fejlesztése sokfordulós játszmához hasonlatos. A kezdeti automatizálási igényekből komplex rendszer alakult ki. A munka sok szakirány ismeretanyagát egyesíti a közlekedéstudománytól az irányítástechnikáig, a méréstechnikától a kommunikációig, a hálózattechnikától az adatbázis-kezelésig. Nem "tiszta" feladat abban az értelemben, hogy egy megadott feladatot kell "algoritmizálni". A környezet folyamatosan változik, figyelemmel kell kísérni az új technológiákat és alkalmazni, de eközben együtt kell élni a tegnap (és a tegnapelőtt) megoldásaival is.

Köszönetnyilvánítás

Örömmel mondok köszönetet mindazoknak, akik a hosszú fejlesztési munkában segítettek. A diplomaterv elkészítéséhez tervezésvezetőm, dr. Terstyányszky Gábor és konzulensem, Drótos Dániel nyújtott közvetlen segítséget, nekik és Ficsór Lajosnak programozás-elméleti és programozás-technikai ismereteim jó részét köszönhetem. Az adatbázisokkal kapcsolatos hasznos tanácsokért és ismeretekért dr. Kovács Lászlónak, dr. Vitéz Gábornénak, Bodnár Józsefnek és Fülep Dávidnak tartozom hálával. Bodnár Józsefnek külön meg kell köszönnöm a Java-nyelvi oktatásokat, Dávidnak pedig a Linux-os fejlesztésekben való együttműködést. Az internet lehetőségeinek felismerését Drótos Lászlónak és Mörk Péternek köszönhetem. A Linuxban való elmélyedésem elsősorban Linus Torvalds és a köré szerveződött nemzetközi gárda munkájának eredménye, a kezdeti ballépéseken pedig Csáky István és Czakó Krisztián segített át. A rendszer első (és nulladik) változatát Fleskó Gáborral, Ujvári Sándorral és Sáfrány Istvánnal együtt dolgoztuk ki, az automatika továbbfejlesztéseit Lóránt István és Lastóczy Ernő készítette, s ezen munkában nekem is helyet szorítottak. Meg kell említenem Lord Clive Sinclairt, mert a hardvertervezés nem egy trükkjét az általa tervezett számítógépek tanulmányozása közben sajátítottam el. Végezetül köszönöm dr. Balla Lászlónak, hogy biztosította számomra a diplomatervezéshez szükséges időt. Ezúton kérek elnézést mindazoktól, akik ebből a felsorolásból kimaradtak. Sok apró, de nélkülözhetetlen ismeret származik tőlük, akár tudtukon kívül is, s ezt is köszönöm.

Melléklet

A. Kapcsolási rajzok


A.1. ábra: Lámpavezérlő egység egy kártyája


A.2. ábra: Villamos-végállomási segédindító (két oldalból egy)


A.3. ábra: Tápfeszültség-stabilizátor

Megjegyzés: az ellenőrzőjelzőkhöz, mivel csupán LED-eket és illesztő-ellenállásokat tartalmaznak, csak nyomtatott áramköri rajzok készültek.

B. Nyomtatott áramköri rajzok

B.1. ábra: Jelzőlámpa-vezérlő kártyája B.2. ábra: Ell.jelzők (alapváltozat)
B.3. ábra: Villamos végállomási segédindító B.4. ábra: Vill.-v.á. ell.jelzők
B.5. ábra: Tápfeszültség-stabilizátor B.6. ábra: Kártyateszter ell.jelzők

C. Alkatrészjegyzék

INDI-PWR Tápegység

U1

Stabilizátor IC

7805

1 db hűtőbordával

D

Graetz-híd

1 db

C1

Kondenzátor

1000µ

1 db

C2

Kondenzátor

470µ

1 db

INDI-LAX Lámpavezérlő kártya

U1

Memória IC

74LS373

1 db

U2,U3

Dekóder IC

74LS139

2 db

T1

Tranzisztor

BC182

1 db

R1

Bázisellenállás

3k

1 db

R2

Feszültségosztó ellenállás

1k

1 db

Rx

Illesztő-ellenállások

1k

8 db

C1

Szűrőkondenzátor

100n

1 db

SSTRx

Szilárdtest-relék

D2-0201-D

6 db

IF1

Adatcsatlakozó

9p. D. tűs

1 db

IF2

Kimenetvezérlő- és tápcsatlakozó

6p. DS121 kés

1 db

INDI-CKL Lámpavezérlő állapotjelző

LED

piros

max. 16 db

LED

sárga

max. 16 db

LED

zöld

max. 16 db

R

Illesztő-ellenállások

1k

max. 3x16 db

INDI-VIL Villamos-végállomási indító-időzítő

U1

Időzítő IC

NE556

1 db

Z

Zener

ZY-12

1 db

D

Graetz-híd

1 db

Rx1

Ellenállások

1M

2 db

Rx2, Rx3

Ellenállások

24k

4 db

R1

Ellenállás

600

1 db

Cx1

Kondenzátorok

10µ

2 db

Cx2

Kondenzátorok

10n

2 db

C1

Kondenzátor

100n

1 db

SSTRx

Szilárdtestrelék

D2-0201-D

2 db

B1,2

Nyomógombok

2 db

Programváltó

1 db

INDI-VLD Villamosvégállomási állapotjelző

LED

kétszínű

2 db

R1,R2

Illesztőellenállások

1k

2 db

INDI-TST Kártyateszter

LED

piros

2 db

LED

sárga

2 db

LED

zöld

2 db

R

Illesztő-ellenállások

1k

6 db

Kódtárcsa

min. 4 állású

2 db

IF1

Adatcsatlakozó

9p. D. tűs

1 db

IF2

Kimenetvezérlő- és tápcsatlakozó

6p. DS121 kés

1 db

D. Bekötési útmutató


D.1 ábra: Jelzőfény-vezérlő adatcsatlakozó bekötés


D.2. ábra: Visinform adatcsatlakozó bekötése


D.3. ábra: Jelzőfény-vezérlő illesztőegység elemeinek összekötése


D.4. ábra: Kártyateszter

E. Hardver-vezérlő programrészletek

Jelzőlámpa-vezérlés


E.1. ábra: Jelzőlámpa-vezérlőkód felépítése

Jelzőlámpa-csoport vezérlése (C változat): 

  for( i = 0; i < LAMPS; i++ )  // kódtömb alaphelyzet
  {
    lc[ i ] = 0;
  }

  #define POS_L  ( li[ i ].pos & 0x0F )  // adatbitek
  #define POS_A  ( li[ i ].pos & 0x10 )  // kártya 'A'
  #define POS_B !( li[ i ].pos & 0x10 )  // kártya 'B'

  for( i = 0; i < LINES; i++ )  // kódtömb feltöltése
  {
    if( POS_A ) switch( LMP )   // kártya 'A' kódolás
    {
         // hangjelzés
    case BEEP:
         // zöld
    case GREEN:  lc[POS_L] |= LMP_A_GREEN  ; break; 
         // sárga villogó
    case BLINK:  lc[POS_L] |= LMP_A_BLINK  ; break; 
         // sárga
    case YELLOW: lc[POS_L] |= LMP_A_YELLOW ; break; 
         // tartózkodói
    case CYAN:   lc[POS_L] |= LMP_A_WARNING; break; 
         // nincs jelzés
    case BLACK:  lc[POS_L] |= LMP_A_BLACK  ; break; 
    }

    if( POS_B ) switch( LMP )  // kártya 'B' kódolása
    {
    case BEEP:
    case GREEN:  lc[POS_L] |= LMP_B_GREEN  ; break;
    case BLINK:  lc[POS_L] |= LMP_B_BLINK  ; break;
    case YELLOW: lc[POS_L] |= LMP_B_YELLOW ; break;
    case CYAN:   lc[POS_L] |= LMP_B_WARNING; break;
    case BLACK:  lc[POS_L] |= LMP_B_BLACK  ; break;
    }
  }

  for( i = 0; i < LAMPS; i++ )  // kódtömb kiírása
  {
    fprintf((FILE *)stdprn, "%c%c", 
            (i << 4)|lc[i], 0xF0|lc[i] );
  }
}

Visinform kommunikáció


E.2.ábra: Soros port BIOS beállító-kódjai

Adathossz

00

4 bit

01

6 bit

10

7 bit

11

8 bit

Stopbit hossza

0

1 bit

1

2 bit

Paritás

x0

nincs paritás

01

páros paritás

11

páratlan paritás

Sebesség

000

110 Baud

001

150 Baud

010

300 Baud

011

600 Baud

100

1200 Baud

101

2400 Baud

110

4800 Baud

111

9600 Baud

Visinform utastájékoztató tábla vezérlése (C változat): 

#define BSIZE   4
#define VHDLS   2
#define VLINES 10

#define VSIZE ( ( VHDLS +  LINES ) * BSIZE + 1 )
#define VIEND ( ( VHDLS + VLINES ) * BSIZE     )

#define SET     0                       /* Config RS232 */
#define OUT     1                       /* Output RS232 */
#define INP     2                       /* Input  RS232 */
#define STA     3                       /* Status RS232 */

#define VISC    ( BAUD_1200 | DS7 | PBE | SB2 )

#define VTMR ( i == -2 )
#define VSPC ( i == -1 )
#define VDEP ( i >=  0 )

/*      DEP  li[ i ].dep */
/*      SHW  li[ i ].shw */

/*      TH   sti.tm_hour  */
/*      TM   sti.tm_min   */

void vioutp()
{
  extern struct tm sti;
  extern struct LINES_INFO li[];
  char vibuff[ VSIZE ];
  int  i,  n;

  for( i=-VHDLS; i<LINES; i++ ) if(( i<0 ) || (SHW) )
  {
    char conv[ 5 ];

    if( VTMR ) n =  TH * 100 + TM;
    if( VSPC ) n =  -1;
    if( VDEP ) n = DEP ? DEP % 2400 : -1;

    if( n>-1 )
    {
      sprintf( (char *)conv, "%2d%02d", n / 100, n % 100 );
    }
    else
    {
      sprintf( (char *)conv, "----" );
    }

    strncpy( (char *)vibuff + (VDEP? SHW: i+VHDLS) * BSIZE,
             (char *)conv, BSIZE );
  }

  bioscom( OUT, 0x0C, COM1 ); delay( 200 );

  for( i=0; i<VIEND; i++ ) bioscom( OUT, vibuff[i], COM1 );

  return;
}

Meghajtó-programok beillesztése DOS alá

TSR rutinbeépítés (C változat): 

#if !defined( EXTRA_AREA )
#define EXTRA_AREA 0
#endif

#define TSR_SIZE (_SS+(_SP+EXTRA_AREA)/16-_psp)
#define EOI outportb(0x20, 0x20)

unsigned sc(unsigned);
void far *xi( int, void (interrupt *)());
void interrupt nullf(void);

enum { NOHEAP, ALLHEAP, ALLSTACK };

unsigned sc(rt)                // méretszámítás
unsigned rt;
{
  extern unsigned _psp,        // PSP szegmenscím
                  __heapbase,  // heap offsetcím
                  _heaplen,    // heap mérete
                  _stklen;     // stack mérete
  unsigned used;               // használt terület mérete
  struct SREGS sregs;          // szegmensregiszterek

  segread(&sregs);             // sz.regiszterek olvasása

  switch( rt )
  {
  case ALLSTACK:               // hozzáadva heap és stack
    used = (((__heapbase+16+_heaplen+_stklen)>>4)+sregs.ds)-_psp;
    break;
  case ALLHEAP:                // hozzáadva heap
    used = (((__heapbase+16+_heaplen        )>>4)+sregs.ds)-_psp;
    break;
  case NOHEAP:                 // csak a programkód
    used = (((__heapbase + 16               )>>4)+sregs.ds)-_psp;
    break;
  }

  return used;                 // területméret visszaadása
}

void far *xi(iv, uf)           // beépítés
int iv;
void (interrupt *uf)(void);
{
  void far *lf;                // eredeti IT vektor

  if(uf == NULL ) return NULL; // érvénytelen IT vektor
  if(uf == nullf)   uf = NULL; // "üres" IT vektor

  disable();                   // megszakítás tiltása
  lf = getvect(iv);            // eredeti IT vektor 
                               // leolvasása
  setvect(iv, uf);             // új IT vektor beállítása
  if(lf == NULL) lf = nullf;   // ha eredeti nincs, "üres"
  enable();                    // megszakítás engedélyezése

  return lf;                   // eredeti IT vektor 
                               // visszaadása
}

void interrupt nullf() {}      // "üres"

Web-kompatibilitás biztosítása

Önállóan és weben át egyaránt futtatható alkalmazás belépőkódja (Java változat): 

import java.applet.Applet;
import java.awt.*;

public class Indi extends Applet
{
  FrameWindow myFrame = new FrameWindow("INDI R2 (V6.0)");

///////////////////////
// Application start

  public static void main(String args[])
  {
    Indi myFrameIndi = new Indi();
    myFrameIndi.myFrame.setCursor(new 
                        Cursor(Cursor.HAND_CURSOR));
    myFrameIndi.myFrame.show();
  }

//////////////////
// Applet start

  public void init()
  {
    Object frame = getParent();
    while(!(frame instanceof Frame )) 
    {
      frame = ((Component)frame).getParent();
    }
    ((Frame)frame).setCursor(new 
                   Cursor(Cursor.HAND_CURSOR));
  }

  public void start()
  {
    myFrame.show();
  }

  public void stop()
  {
    myFrame.setVisible(false);
  }
}

F. Adatbázis-táblák

Menetrendi táblák:

Útvonalterv:

Viszonylatazonosító

chr(6)

Viszonylatverzió

chr(6)

Leírás

text

Megállók, idő- és távolságadatok:

Fej

Viszonylatazonosító

chr(6)

Viszonylatverzió

chr(6)

Törzs

Pozíciószám

chr(6)

Név

chr(20)

Távolság b vá.-tól [perc]

int

Távolság b.vá.-tól [m]

int

Végállomási indítási és érkeztetési jegyzék:

Fej

Végállomás-azonosító

chr(6)

Végállomás neve

chr(20)

Menetrendi verzió

chr(6)

Érvényes (első nap)

date

Érvényes (utolsó nap)

date

Napi érvényesség

chr(7)

Törzs

Viszonylatazonosító

chr(6)

Járatazonosító

chr(6)

Érkezés

chr(4)

Tevékenység

chr(20)

Indulás

chr(4)

Járművezetői menetrend:

Fej

Járatazonosító

chr(6)

Műszakkód

chr(1)

Menetrendi verzió

chr(6)

Érvényes (első nap)

date

Érvényes (utolsó nap)

date

Napi érvényesség

chr(7)

Kiegészítő info

text

Törzs

Belső v.á.-ra érkezés

chr(4)

Belső v.á.-n tevékenység

chr(20)

Belső v.á.-ról indulás

chr(4)

Külső v.á.-ra érkezés

chr(4)

Külső v.á.-n tevékenység

chr(20)

Külső v.á.-ról indulás

chr(4)

Utasmenetrend

Fej

Viszonylatazonosító

chr(6)

Érvényes (első nap)

date

Érvényes (utolsó nap)

date

Napi érvényesség

chr(7)

Kiegészítő info

text

Törzs1 (menetrendtábla)

Belső v.á.-ról indulás

chr(4)

Külső v.á.-ról indulás

chr(4)

Törzs2 (megállótábla)

Megálló elérés ideje

int

Megálló neve

chr(10)

Beosztások:

Járművezetői forda (állandó szolgálati beosztási terv).

Fej

Fordaazonosító

chr(6)

Érvényes (első nap)

date

Érvényes (utolsó nap)

date

Napi érvényesség

chr(7)

Kiegészítő info

text

Törzs

Járatazonosító

chr(6)

Műszakkód

chr(1)

Járműazonosító

chr(8)

Dolgozói azonosító

chr(8)

Tartalékos és beugró járművezetők napi beosztása.

Fej

Dátum

date

Törzs

Járatazonosító

chr(6)

Műszakkód

chr(1)

Járműazonosító

chr(8)

Dolgozói azonosító

chr(8)

Naplózott adatok:

Forgalmi utasítások:

Fej

Utasításazonosító

chr(10)

Érvényes (első nap)

date

Érvényes (utolsó nap)

date

Leírás

text

Törzs

Érintett viszonylatok

chr(6)

Jelentések:

Dátum és idő

chr(10)

Hely

chr(20)

Dolgozói azonosító

chr(8)

Leírás

text

Menetlevelek:

Fej:

Járatazonosító

chr(6)

Műszakkód

chr(1)

Járműazonosító

chr(8)

Dolgozói azonosító

chr(8)

Kilométer

real

Üzemanyag [liter]

real

Törzs

Ellenőrzőpont azonosító

chr(8)

Idő

chr(6)

Példa távoli SQL szerver elérésére (Javamsql csomag alapján): 

import java.net.URL;
import java.sql.*;

class Select {
  public static void main(String argv[]) {
    try {
      Class.forName("com.imaginary.sql.msql.MsqlDriver");
      String url =
        "jdbc:msql://athens.imaginary.com:1114/db_test";
      Connection con = 
        DriverManager.getConnection(url,"borg","");
      Statement stmt = con.createStatement();
      ResultSet rs =
        stmt.executeQuery("SELECT * from test 
                           ORDER BY test_id");
      ResultSetMetaData meta = rs.getMetaData();

      System.out.println("Got results:");
      while(rs.next()) {
        int a = rs.getInt("test_id");
        String str = rs.getString("test_val");
        System.out.print(" key= " + a);
        System.out.print(" str= " + str);
        System.out.print("\n");
      }
      stmt.close();
      DatabaseMetaData dbmd = con.getMetaData();
      rs = dbmd.getTables(null, null, null, null);
      while( rs.next() ) {
        System.out.println("Table: "
        +rs.getString("TABLE_NAME"));
      }
      con.close();
    }
    catch( Exception e ) {
      System.out.println(e.getMessage());
      e.printStackTrace();
    }
  }
}

Irodalomjegyzék

Közlekedéstudomány:

[1] Lukács András: Miért részesítsük előnyben a tömegközlekedést? Városi Közlekedés 1992/6, 346.o., KTE

[2] Dr.techn.Werner Gobiet: A geoinformációs rendszer technológiája és a városi közlekedés tervezése. Városi Közlekedés 1992/6, 326.o.

[3] Nemzetközi szemle (utastájékoztatás magnókazettán, mesterséges beszédhang, dombornyomású feliratok vakok számára) [London Underground Limited Press Information nyomán] Városi Közlekedés 1988/2, 108.o., KTE

[4] A VI. Városi Közlekedési Konferencia. Városi Közlekedés 1988/2, 94.o., KTE.

[5] Dr.Gyárfás András: Infra-összeköttetések tapasztalatai a közlekedés automatizációjában. Városi Közlekedés 1990/3, 153.o., KTE

[6] Czégel Sándor, Dr. Papp György, Rétlaki László: A tömegközlekedés előnyben részesítése a forgalomirányító jelzőlámpák befolyásolásával. Városi Közlekedés 1988/2, 89.o., KTE

[7] Hanspeter Oehrli: A tömegközlekedés előnyben részesítése jelzőlámpás csomópontokon -- zürichi tapasztalatok. Városi Közlekedés 1991/2, 97.o., KTE

[8] Varga Attila, Kiss Géza, Clement János, Németh Tibor: A SIGNELIT a közlekedésirányítás szolgálatában. Városi Közlekedés 1991/2, 83.o., KTE

[9] Dr.Klár András: Tel-Aviv közúti közlekedésének néhány jellemzője. Városi Közlekedés 1989/6, 353.o., KTE

[10] Dr.techn.Szabó Dezső: Nem hagyományos forgalom-lebonyolítási módok. Városi Közlekedés 1989/2, 84.o., KTE

[11] A menetirányítás munkája és kapcsolatai. MKV Forgalomirányítási o. 1984

[12] A tömegközlekedési forgalomirányítás fogalma, követelményei és alapelvei. MKV Forgalomirányítási o. 1984

[13] Forgalmi zavarok osztályozása és elhárítása. MKV Forgalomirányítási o. 1984

[14] A rendkívüli forgalom fogalma, megszervezése és lebonyolítása. MKV Forgalomirányítási o. 1984

[15] BON. Control Systems for Public Local Transportation. MBB München & CLI Aachen 1989

Elektronika:

[16] Dr.-Ing Ulrich Tietze, Dr.-Ing. Christoph Schenk: Analóg és digitális áramkörök. Műszaki könyvkiadó 1990

[17] Krizsán György: A ZILOG mikroprocesszor családok. LSI Atsz 1984

[18] Dr. Ajtonyi István: Vezérléstechnika II. Tankönyvkiadó 1988

[19] Dr. Ajtonyi István: Vezérléstechnika gyakorlatok és adatgyűjtemény. Tankönyvkiadó 1986

[20] Bánhidi László, Oláh Miklós, Gyuricza István, Kiss Mátyás, Rárkai László, Szecső Gusztáv: Automatika mérnököknek. Tankönyvkiadó 1992

[21] Magyari Béla: Digitális IC-k. Műszaki Könyvkiadó 1982

[22] Boér László, Dóra Gyula, Fenyő László, Seres Attila: Az IBM PC belső felépítése. LSI-Atsz 1989

[23] TIRIS. Texas Instruments Inc. http://www.ti.com

Kommunikáció, hálózatok:

[24] Géher Károly főszerk.: Híradástechnika. Műszaki Könyvkiadó 1993

[25] Eged Bertalan, Gelencsér István, Soós Csaba: Vezeték nélküli linkek és modemek az ISM sávokban. NETWORKSHOP 1998

[26] Bíró Sándor, Bódi Antal: Kábeltévé alapú Intelligens Város kísérleti projekt eredményei Nyíregyházán. NETWORKSHOP 1998

[27] Dr. Jónap Károly: Az elosztott intelligenciájú, egységes felépítésű folyamatirányító rendszerek struktúrája. Folyamatirányító rendszerek (DCS) III. találkozó 1997

[28] Andrew S. Tanenbaum: Számítógép-hálózatok. Novotrade Kiadó/Prentice Hall 1992

[29] James Martin, Kathleen K. Chapman: Lokális hálózatok. Novotrade Kiadó/Prentice Hall 1992

[30] Perlaki Attila, Dr. Vitéz Gáborné: Interaktív térképek és beszélő Gopher. RICOMNET előadás. 1995

[31] Herdon Miklós, Tamás János: Térinformatika a World Wide Weben -- szoftver-technológiák. NETWORKSHOP 1998

Operációs rendszerek:

[32] Stefan Strobel, Thomas Uhl: Linux. Kossuth 1996

[33] Linux Developer's Resource CD-ROM. InfoMagic, Inc. 1998

[34] Szalai Károly: A Debian Linux és telepítése. CHIPtár 9. Vogel Publishing 1997

[35] Czakó Krisztián: Kapocs a rendszerek között. (Együttműködés Linux és Microsoft/Novell rendszerek között.) NETWORKSHOP 1998

[36] Linux. http://www.linux.org

Programozástechnika:

[37] Benkő Tiborné, Poppe András, Benkő László: Turbó C++ programozása IBM PC-n. LSI 1991

[38] Kiss Zoltán, Tóth Bertalan: IBM PC assembly összefoglaló és példatár. BME Mérnöktovábbképző Int. 1994

[39] Peter Norton: Az IBM PC programozása. Műszaki Könyvkiadó 1992

[40] László József: Perifériák programozása Pascal és assembly nyelven. ComputerBooks 1997

[41] Csizmazia Balázs: Hálózati alkalmazások készítése. Kalibán BT 1998

[42] Jason J. Manger: A Java programozási nyelv. Panem - McGraw-Hill 1996

[43] Móricz Attila: Java programozási nyelv I-II. LSI 1997

[44] Java 1.1 útikalauz programozóknak. ELTE TTK Hallgatói alapítvány 1997

[45] Java SDK 1.1.3. Sun Microsystems. http://www.sun.com

[46] Halassy Béla: Az adatbázis-tervezés alapjai és titkai. IDG Hungary 1994

[47] Jeff Rove: Building Internet Database Servers with CGI. New Riders Publishing 1996