A MALÉV ÉS A MAGYAR POLGÁRI REPÜLÉS INFORMATIKAI TÖRTÉNETE A KEZDETEKTŐL NAPJAINKIG

A MALÉV ÉS A MAGYAR POLGÁRI REPÜLÉS INFORMATIKAI TÖRTÉNETE A KEZDETEKTŐL NAPJAINKIG

TARTALOM ÖSSZEFOGLALÓ írta Dr. Gonda Zsuzsanna és Ballai János

ALAPVETÉSEK, A REPÜLÉSI INFORMATIKA SAJÁTOSSÁGAI a fejezetet írta Dr. Gonda Zsuzsanna

A MAGYAR REPÜLÉSI INFORMATIKA NAGY FEJEZETEI, MÉRFÖLDKÖVEK Rendszerenként: az automatizálás hatása a repülési szakmára, munkafolyamataira   

írták: Esterházy Béláné, Berényi Gábor Ágota, Ballai János, Nagy Tibor, Vaszkó András, Dr. Gonda Zsuzsanna, Csányi István (szerzők bemutatva a megfelelő fejezeteknél) a rendszerenkénti általános ismertetőket írta Dr. Gonda Zsuzsanna szerkesztette (és szerkeszti a jövőben is ): Ballai János és Dr. Gonda Zsuzsanna

MELLÉKLETEK: MALÉV informatika áttekintő táblázat SITA története Idegen kifejezések és rövidítések dekódolása Ajánlott irodalom és háttéranyagok írta és szerkesztette Ballai János és Dr. Gonda Zsuzsanna a felhasznált képek nem jogdíjasak, publikus forrásokból erednek, azonosítható személyeket nem ábrázolnak

Ballai János, repülőmérnök, a MALÉV Számítástechnikai Osztály megalapítója és vezetője 1975-től 1991-ig. A SITA Service Development Committee MALÉV részéről választott tagja(1977-1982-ig) – 18 légitársaság képviselete közös fejlesztési kérdésekben a SITA 200 polgári légitársaságát. A SAGIL fejlesztés projekt vezetője 1981 – 1983 között Dr. Gonda Zsuzsanna, rendszerszervező, a MALÉV Informatikai Vezetője 1993-1997 között, igazgatóhelyettes a Forgalmi és Repülési Igazgatóságokon, számos nagy rendszer bevezetésének részese, a MALÉV SITA delegátusa. 1997-et követően a SITA, a SABRE Airline Solutions cégeknél dolgozott vezetőként külföldön, majd a Lufthansa Systemsnél Budapesten. Könyvet írt a repülési informatikáról és megalapozta a tantárgy oktatását a BME-n. Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 1

ÖSSZEFOGLALÓ egy nyitott végű tanulmányhoz Kevés olyan területe van a polgári magyar informatikának, amelynek ez előnyeit emberek nagy tömegei élvezik közvetlenül, de szinte semmiféle szakirodalom, még média hivatkozás sem áll rendelkezésre évtizedeken keresztül. Publikusan szinte egyáltalán nem ismertek a termék- és szolgáltató nevek, technológiák, a bevezetési sikerek és mérföldkövek, a közreműködők, a project tapasztalatok és a nemzetközi dimenziók. A repülési informatika kétségkívül ilyennek tekinthető, holott a rendszerek képessége és minősége alapvetően meghatározta a MALÉV és partnerei, sőt a magyar repülőterek utasainak a kiszolgálását, a légi járatok teljesítésének szakszerűségét, hatékonyságát és biztonságát, de még a kísérők, családtagok tájékozódását is. Jelen tanulmányunk az Óbudai Egyetem magyar informatika történetet rögzítő átfogó nemes törekvése részeként íródott s így először vetettük papírra a repülési informatika dicső eseményeit, mérföldköveit, Magyarországon a maga idejében egyedülálló és példa nélküli fejlettségű technológiai és szolgáltatási sajátosságait. Az olvasó ebből megismerheti, hogy milyen funkcionális domainek köré rendeződött a világ repülési informatikája, milyen sajátos globális szolgáltatói megoldások és architektúrák alakultak ki és az automatizálás hogyan változtatta meg a munkafolyamatokat, milyen előnyöket és korábban soha nem lévő lehetőségeket hozott be a légiközlekedésbe. A globális dimenziókon túlmenően azt is leírtuk, mivel egészítette ki a MALÉV és a magyar informatika a nemzetközi szolgáltatásokat, hol alakultak ki saját magyar fejlesztésű vagy integrált megoldások és 1975-től kezdve 2012-ig milyen generációs váltásokat értünk meg. A történet fő lépései:  Malév újjászervezésének megkezdése (1975)  a Malév kereskedelmi céljainak támogatására beindított informatikai fejlesztés, elsődlegesen az utas helyfoglalás, ülőhely kapacitás gazdálkodás, majd a tarifálás és a jegykiadás automatizálása a teljes belföldi és külföldi hálózaton, globális szakmai és technikai integráció  a MALÉV repülőtéri munkafolyamatainak automatizálása, az utasforgalom, földi kiszolgálás, járatinformációs szolgáltatás, légi áruszállítás, navigáció és műszaki feladatok informatikai fejlesztésének megkezdése és folyamatos bővítése – a minőség és szabványosítás elvének maximális megvalósítása

 komplex és magas szintű rendszerek bevezetése a menetrendszerkesztés, operatív üzemirányítás, hajózó személyzet vezénylés területén, majd a bevétel optimalizálásban és nemzetközi elszámolásokban Leírásunk célja mindezen tudás közkinccsé tétele; bemutatjuk a fejlesztés eredményeit a biztonság, a minőség növelése, az integráció és a Malév informatikai kultúrájára való kihatásuk szempontjából. Büszkén hivatkozunk arra, hogy a MALÉV Kelet-és Közép Európa informatikailag legmagasabban fejlettebb légitársasága volt, aki több rendszert világelsőként vezetett be és meghatározó szerepe volt a nemzetközi informatikai közösségekben is. A MALÉV sajnálatos 2012 februári megszűnése után Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 2

ez a tudás nem veszett el és bízunk benne, hogy lesz még magyar légitársaság, aki hasznosítja az elődök tapasztalatait és tovább viszi a zászlót a nemzetközi arénában, de főként saját berkeiben haladó informatikai kultúrát teremt újra. A mai informatikai technológiai platformon egyre nagyobb annak a valószínűsége is, hogy idővel ismét magyar termékek vagy tudáselemek integrálódnak be a repülési informatika globális szolgáltatásaiba. Történelmi visszatekintés alapján igen nagy bátorság, sőt hősiesség kellett ahhoz a MALÉV vezetők részéről, hogy az 1970-es években következetesen nyugati eredetű és külföldön host-olt informatikai rendszereket szerezzenek be kemény valutáért, biztosítsák az ehhez szükséges külföldi kiutazásokat, oktatásokat, a fejlesztési fórumokon a folyamatos részvételt. Tiszteljük meg őket azzal, hogy nevüket ezen tanulmányban megemlítjük (sajnos, legtöbbjük már eltávozott az élők sorából): 







Fazekas József MALÉV Vezérigazgató Első /Általános Helyettese - aki nemcsak a számítástechnikai-informatikai területet felügyelte, hanem az összes repülőtéri MALÉV szakszolgálatot, akik a nemzetközi rendszerek felhasználói voltak. Tagja volt a SITA Igazgatóságnak több ciklusban és minden nemzetközi informatikai projectet ő hagyott jóvá, biztosítván az anyagi fedezetet és a maximális vezetési támogatást Pataki Zoltán MALÉV Forgalmi Igazgató - élharcosa volt annak, hogy az általa évtizedekig felügyelt utas- és árukezelés, forgalmi kiszolgálás, üzemirányítás szervezete, kiszolgálási technológiája elérje a haladó nemzetközi színvonalat és ennek a megvalósításához egyértelműen látta az informatikai rendszerek szerepét Nádor Ferenc SITA Magyarország alapítója és Igazgatója, korábban MALÉV Vezérigazgató Helyettes - aki erős hittel fáradhatatlanul küzdött azért, hogy a nemzetközi informatikai és telekommunikációs szolgáltatásokat a MALÉV adaptálja és munkafolyamataiba beépítse Nagy Judit a SITA Magyarországi Igazgatója, Nádor Ferenc utódja, további hathatós támogatást nyújtott a Malév informatikai fejlesztésinek bővítéséhez, a telepített rendszerek üzemeltetéséhez valamint teljes világhálózat internetes migrációjához.

Természetesen illendő megemlíteni azokat az informatikusokat, project vezetőket és szakterületi képviselőket, akiket érintett az automatizálás. Jelen tanulmány szerzői azt a kreatív álláspontot alakították ki, hogy aki méltó tartalommal hozzájárult ezen anyaghoz - mindez ideig és a jövőben annak a neve így szerepel ezen a dicsőségtáblán. Tehát most egy nyitott végű, dinamikusan fejlesztendő írásművet indítunk. Mi, az első verzió szerzői, kezdeményezzük, hogy a jövőben további kollégáink is csatlakozzanak a történetíráshoz az alábbi szempontok és szabályok betartásával : 1. kizárólag olyan személy írását fogadjuk el, akinek valós, bizonyított, közvetlen és pozitív szerepe volt egy konkrét repülési informatikai rendszer kiválasztásában, bevezetésében, betanításában, továbbfejlesztésében, integrálásában, a szakterületi szervezet és munkafolyamatok illesztésében. pályázhatnak informatikusok, szakterületi vezetők, felhasználók - bárki, aki hiteles képet tud adni egy komplett munkafolyamatról 2. a történeti (tehát nem technikai) célú tanulmány az Egyetem hallgatói és a nem informatikus, nem repülési szakmabeli olvasók számára érthető módon írja le a folyamatokat az automatizálás előtt és után, az eredményeket, a nehézségeket és a tanulságokat. célszerű a történetet a teljes MALÉV repülési tevékenységi és fejlődési spektrumában is elhelyezni.

Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 3

A POLGÁRI REPÜLÉSRŐL ÁLTALÁBAN

A polgári repülés három alappilléren nyugszik az alábbiak szerint: 1. Különböző típusú nagyságú repülőgépek megtervezése és üzemeltetése utas és áruszállítás céljaira 2. Földi és légi irányítás – navigáció 3. Utas és áruszállítási, földi kiszolgálás feladatok tervezése, végrehajtása Mind három területet informatikai, automatizálási rendszerek támogatják, mely rendszerek az elmúlt 50-60 évben ugrásszerű fejlődésen mentek keresztül. Ebben a tanulmányban a MALÉV informatikai rendszereinek fejlődését kívánjuk bemutatni, a fenti további két pontot csak a teljesség kedvéért említettük meg. A magyar repülési informatika történetét egy dinamikusan fejleszthető domain-ben alakítjuk ki, kommentálása, bővítése lehetséges a szerkesztőkön keresztül (Ballai-Gonda). Különböző látószögek elfogadottak, tehát informatikai szakemberek, felhasználók, vezetők leírhatják gondolataikat a saját nézőpontjukból.

ALAPVETÉSEK, A REPÜLÉSI INFORMATIKA SAJÁTOSSÁGAI - RÖVIDEN

A polgári informatika kétségkívül legkorábban kialakult és az egyik legmagasabb kulturális szintet elérő területe a repülési informatika. Ugyanakkor szakirodalma rendkívül kevés, a legtöbb forrás inkább csak kereskedelmi szempontból és a gyártó cégekhez kapcsolódva készült, és ezáltal nem tekinthető neutrálisnak és rendszerező igényűnek. Mivel a repülés viszonylagosan nagy távolságok között valósul meg, lényeges az indító és fogadó repülőterek és szolgálatok közötti kommunikációs lehetőségek biztosítása. A kezdetben minden telex üzenetek cseréjével valósult meg szabvány formátumban, kódolással, tartalommal és szavatolt üzenettovábbítási technológiával (legnagyobb szolgáltatók és globális virtuális hálózat üzemeltetők: Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 4

USÁ-ban az ARINC, a világ többi részén a SITA). Mára a sajátos és hagyományos repülési üzenetszabványok mellett az XML platformon is minden előállítható. A későbbiekben a nagygépes (host-olt) rendszerek és is képesek voltak ezeket a szabvány üzeneteket feldolgozni illetve kimenő irányban generálni. A hostok elérése a légiközlekedésben kizárólagosan használt speciális P1024 hálózati protokoll alkalmazásával történt (1024B az IBM hostok, 1024C a Unisys hostok elérésére). Ezek köré olyan hatékonyan épült fel a szolgáltatási vertikum, hogy a légitársaságok a világ bármely pontjára csak megrendelték ezeket a bekötéseket s így minden irodájukat és szolgálati helyszínüket záros határidőn (napokon) belül be tudtak kötni az utasforgalomba illetve a szükséges többi automatizált munkafolyamatba. Az X.25 csomagkapcsolt hálózati technológia volt az első nem a repülési szakmának dedikált megoldás, amelyet más iparágak is használtak, s ezáltal leomlott a fal a repülési és más iparágak telekommunikációs platformjai között. Természetesen az ezredfordulón az internet mindent forradalmasított, habár a vártnál sokkal lassabban váltotta ki a hagyományos hálózatokat. Ez a folyamat ma sem fejeződött be, mert nem mindenhol költséghatékony az internet és az IP hálózatok által kínált funkcionális előnyök (pl. grafikus megjelenítés) sok munkaterületen igazából nem lényegesek. A munkaállomások szintjén az ún. buta terminál (zöld vagy kék képernyő) - kövér kliens PC – sovány kliens PC - táblagép – mobil – mindezek kombinációja - fejlődési út követhető nyomon. Egy társaságon és technológián belül jellemző a végberendezések globális szabványosodása. A légiközlekedés rengeteg nagy értékű speciális hardware-t igényelt a (pl. jegy- és beszállókártya nyomtatók, olvasók, több rendszerhez hozzáférést biztosító repülőtéri berendezések és infrastruktúra stb.)

A repülési informatika történelem kezdetét 1953-tól számítunk, amikor az IBM és az American Airlines megállapodtak egy számítógépes utas-helyfoglalási rendszer kialakításáról, amelyet a terv szerint meg is alkottak és sikeresen bevezettek. Jellemzően nagy globális légitársaságok voltak csak képesek arra, hogy jelentős, több ezer emberév fejlesztői kapacitást igénylő gigantikus rendszereket Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 5

kifejlesszenek, de később ők is saját rendszerházaikon keresztül más légitársaságok számára elkezdték ezeket értékesíteni (pl. American Airlines/SABRE, Lufthansa/Lufthansa Systems). Ezzel párhuzamosan megalakult néhány neutrális szolgáltató (vendor), aki k a légitársaságok számára ajánlott rendszereket fejlesztettek és üzemeltettek (pl. magasan a legnagyobb és legsikeresebb a SITA, akit eredetileg telekommunikációs feladatkörrel az ENSZ hozott létre 1949-ben, hogy a II. világháború rombolásai után fellendítse a légiközlekedést). A repülési informatika a kezdetektől fogva olyan infrastruktúrán alapult, hogy képes volt a központi rendszerek szolgáltatásait globálisan teríteni akkor, amikor ez más iparágakban még elképzelhetetlen volt. Az email-t is itt találták fel évtizedekkel azelőtt, hogy az világszerte elterjedt volna. Ez oly módon alakult ki, hogy a telex levelezéshez intelligens PC alapú előtét rendszert illesztettek, amely egyre több funkcióra lett képes. Technikai értelemben az internet kialakulásáig, gyakorlati megvalósítás szintjén az ezredfordulóig a repülési informatika sajátos, csak az iparágra jellemző megoldásokon alapult (hálózati protokollok, rendszerek közötti kommunikációs megoldások), ugyanakkor a polgári repülésen belül minden teljes mértékben szabványosítva volt, van és lesz, annak érdekében, hogy a légitársaságok, repülőterek, kiszolgálási partnerek és az utazási irodák egymással egy nyelven tudjanak kommunikálni és alkalmazási rendszereik tökéletesen együttműködjenek. Ez azt is jelentette, hogy véges számú nagyhatalmú globális szolgáltató (8-10) dominálta a piacot nagy értékű, igényes, hatalmas üzleti tapasztalatot integráló applikációs termékkel, amelyek egyben céltudatosan kialakított rendszerkultúrát és légitársasági csoportosulást is képviseltek. A későbbiekben az internetes világban megjelentek bátor és kisebb vállalkozók is, erősen differenciálva a piacot pl. a fapados légitársaságok speciális informatikai igényeinek kielégítésével avagy az internetes utas helyfoglalási rendszerek , middleware-ek és interface-ek teljes hadának előállításával. A repülési informatika rendszereinek szolgáltatási architektúrája alapvetően osztott (shared) mainframe-es (nagygépes) központok szolgáltatásain alapul, ahová az egyes felhasználók biztonságosan és gazdaságosan csatlakoznak ún. multihost (többfelhasználós) üzemmódban, amely azt garantálja, hogy mindenkinek saját partíciója van (utas rendszerek ma is így működnek). A 90-es évek információtechnológiai fejlődése több területen lehetővé tette a client- server architektúrák alkalmazását az operations control (légitársasági üzemirányítás), crew (hajózó személyzet) területeken, az MRO (repülőgép műszaki karbantartás) rendszerek pedig leggyakrabban lokálisak. Természetesen web hozzáférés biztosított ma már mind az utasok mind a légitársasági alkalmazottak részére és ahol a funkcionalitás megkívánja, ott a mobil integráció széles körben elterjedt és ez új távlatokat nyitott meg az utasokkal való kapcsolatban. Hiba lenne azonban azt gondolni, hogy a modernebb hálózati és applikációs megoldások rendelkezésre állása kiváltotta a régebbi és öregedőnek titulált technológiákat. A mai napig a régi és új békés és harmonikus együttélése zajlik, amely azt is bebizonyította, hogy vannak olyan területek és funkciók, amelyekben verhetetlen a (közben többször megújult) mainframe-es platform (pl. nagytömegű egyszerű tranzakciók gyors feldolgozása és globális terítése), illetve az új technológia nem értékarányos áros érhető el (pl. IP hálózat sokkal drágább, mint a hagyományos). Ez meglepetésként és csalódásként érintette azokat, akik az ezredfordulón túlságosan is hittek az új hostos, applikációs és hálózati technológia gyors elterjedésében és főleg azokat az új üzleti belépőket, akik a hagyományos nagy szolgáltatók körébe merészkedtek és próbálkoztak új rendszerek kialakításával.


oldal 6

A repülési informatika alapvetően az alábbi légitársasági és repülőtéri funkciókat automatizálta (megjegyezvén, hogy a szokásos vállalati pénzügyi és adminisztrációs rendszereket nem szoktuk ezen témakör alatt taglalni, mert ezek nem tekinthetők sajátosnak a repülés szempontjából):



  

        

PASSENGER MANAGEMENT - utas helyfoglalás, törzs utas, jegy, tarifázás, integrálás az utazási ügynökségi rendszerekkel (GDS Global Distribution Systems), később internetes és mobil megoldások utasok és utazási ügynökségek részére FLIGHT PLANNING - járatok navigációs útvonaltervezése, üzemanyag optimalizálás POGGYÁSZKERESÉS – elirányított és gazda nélküli poggyászok párosítása, adminisztráció DEPARTURE CONTROL - járatok indítása, utasok jegykezelése, repülőgépek terhelés- és egyensúly számítása, későbbiekben utasok önkiszolgáló moduljai interneten, kioszk állomásokon vagy kézi mobil eszközökön keresztül CARGO - légi áruszállítás MAINTENANCE AND ENGINEERING, MRO - repülőgépek műszaki karbantartásának tervezése, operatív megoldása és ennek háttérrendszerei SCHEDULING - menetrendszerkesztés OPERATIONS CONTROL - légitársasági operatív üzemirányítás CREW MANAGEMENT - hajózó személyzetek repülési (és más) szolgálatra való beosztása, havi és napi tervezés REVENUE ACCOUNTING - nemzetközi jegy- és cargo bevétel elszámolása és elosztása REVENUE (YIELD ) MANAGEMENT - bevételek optimalizálása, fajlagos előnyszámítás AIRPORT PLATFORMS - repülőtéri munkahelyekről több légitársasági rendszerhez való hozzáférés, újabban utas-önkiszolgálás (CUTE, CUSS, KIOSK technológiák) FIDS – repülőtéri járatinformációs rendszerek (indulás-érkezés, kapu, állóhely)

A történelmi kialakulás sorrendjében és nagyságrend szempontjából mindenképpen elsődlegesek az utas rendszerek. Navigációs applikáció, flight planning nélkül senki nem tud járatot teljesíteni, így ezen két robusztus rendszer megléte alapfeltétel minden légitársaság számára. A felsoroltakon kívül van még kb. egy tucat kisebb (de általában drága) applikáció, melyek alkalmazása erősen függ a Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 7

légitársaság méretétől, működési modelljétől és fejlettségi szintjétől és igényességétől (pl. Revenue Integrity, Market Information System, Resource Planning ). A repülési informatika rendszereit és globális kultúráját néhány dolog szignifikánsan jellemzi, ezáltal lényegesen megkülönbözteti a többi ipar informatikájától: 













teljes körű, magas szintű és tökéletes szabványosítás a különböző applikációk, a hálózatok és az üzenetküldő platformok között minden irányban és dimenzióban – annak érdekében, hogy minden résztvevő tudjon egymással kommunikálni (megjegyezvén, hogy a rendszerek elsősorban üzeneteken keresztül érintkeznek és nyilvánvalóan az adat- és folyamat struktúrák is megegyeznek vagyis konformak) a sikeres rendszereket a felhasználók jellemzően nem maguk állítják elő, hanem dominánsan erre szakosodott nemzetközi szolgáltatóktól vásárolnak/bérelnek megoldásokat shared / ASP vagy licence alapon (néha büróként). A nemzetközileg elterjedt rendszerek ezáltal hatalmas üzleti tapasztalaton és konszenzuson alapulnak. a légiközlekedésen belül nagy szabvány informatikai tagolódásban, domainekben gondolkodnak és a kapcsolódó rendszereket ezek köré fejlesztik (ezen domainek megfelelnek az előzőekben felsorolt kategóriáknak, pl. .utas, flight planning, cargo stb.) más iparágakkal ellentétben itt a felhasználók alkalmazkodnak a rendszerekhez és nem fordítva, azaz nem állítanak el számtalan hasonló funkciójú egyedi rendszert. Ez azt is jelenti, hogy a sikeres nemzetközi rendszerek mértékadó, követendő magas üzleti színvonalat és húzóerőt képviselnek a szervezetet és munkafolyamatokat illetően, sokszor kisebb és kezdő légitársaságok ezen alaptechnológia mentén indulnak el. a repülésben igen nagy jelentősége van a rendszerek/portfoliók és szolgáltatók körül kialakult nemzetközi felhasználói fórumoknak, akik nemcsak a szolgáltatásokat, hanem a repülési munkafolyamatokat és szabványokat is erősen befolyásolják/meghatározzák a repülési informatika mindenkor mérföldekkel az adott ország informatikai színvonala előtt járt, innovációban és gyors megvalósításban ma is jeleskedik, de szakirodalmi feldolgozás híján ennek kicsi a nyilvánossága, ezáltal a közvetlen pozitív kihatása más informatikai tevékenységekre a repülési informatika korábban fél évszázadig sajátos és kizárólagos technikai platformja az évezred fordulóra átmigrált a világban általános alkalmazott internetre és applikációi folyamatosan alkalmassá válnak a nyitott alapokon való rendszer független működtetésre napjainkban a repülési informatika nagy változásokon megy keresztül a szakma üzleti környezetének drasztikus változásai miatt, elsősorban a drasztikusan más modellt kialakító fapados légitársaságok igényeit kell kielégíteni, megfelelni az újszerű eladandó termékeknek (pl. jobb ülőhely, elit váró használata, nagyobb poggyászkeret stb.), új alapokra kell helyezni a légitársaságok és utazási rendszerek kapcsolatát és maximálisan ki kell aknázni az internetet és a mobil eszközök, sőt a közösségi rendszerek kínálta lehetőségeket az utasokkal való kapcsolatrendszerben.


oldal 8

A MAGYAR REPÜLÉSI INFORMATIKA NAGY FEJEZETEI A MALÉV sajnálatos és tragikus 2012. februári megszűnése után írva ezt a tanulmányt úgy érezzük, még inkább súlyosbítja a veszteséget annak a megállapítása, hogy a MALÉV Kelet-és Közép Európa legjobban automatizált légitársasága is volt és úttörő szerepet játszott számos nemzetközi fejlesztésben. A cég szakmai utód nélküli felszámolása – több más mellett - hatalmas informatikai szellemi és valós potenciál továbbá előnyös nemzetközi pozíció elveszejtését is jelentette. Repülési informatikai tanulmányunk nem csak a MALÉV, mint az eddig egyetlen sikeres magyar nemzeti légitársaság eredményeire összpontosít, mert ma már a polgári repülés szervezete erősen tagolódott, külön vannak repülőterek, földi kiszolgáló vállalatok, természetesen légi rányitás, de a „hőskorban” ez még mind csak a MALÉV volt. Az 1970-es években, amikor az igazi automatizálás elkezdődött, több olyan – később repülőtéri vagy kiszolgálási rendszer is a MALÉV berkein belül valósult meg, amelyek később már szervezetileg máshova tartoztak. A szocializmus viszonyai között rendkívül haladó és bátor informatikai politikát folytatott a MALÉV, elsőként csatlakozott több nagy nemzetközi rendszerhez, majd kiváló eredményei alapján komoly befolyást ért el globális szolgáltatóknál és légitársasági felhasználói közösségekben. A szocialista légitársaságok laza szövetsége az ún. Berlini Egyezmény tagjai sok esetben a MALÉV példája alapján merítették a bátorítást, hogy ugyanazon nemzetközi applikációkhoz csatlakozzanak, többüket a MALÉV tanított be, sőt az Egyezmény a Malév-et bízta meg koncepciós és koordinációs szereppel. A MALÉV és más szocialista légitársaságok nemzetközi rendszerekben való részvételét 2 pikáns kérdés bonyolította: 1. mivel ASP/osztott szolgáltatásokról volt szó bizonyos (kevésbe szakmai ) szervek kétségeiket fejezték ki azzal kapcsolatban, hogy a magyar utasok és a légitársaság ügyfeleinek adatait, utazási terveit fizikailag külföldön lévő szervereken és adatállományokban tárolják (a táboron kívül…). Voltak olyan (nem magyar) országok is, akik ezen vélt biztonság érdekében központokat importáltak és telepítettek le a saját területükön, de ezek a megoldások néhány éven belül megbuktak, mert sem funkcionális sem üzemeltetési szempontból nem volt előnyös az egyedi megoldás. Az eddig rögzített történelem nem jegyzett fel semmiféle problémát, visszaélést ezzel kapcsolatban így ez a félelem hamar elhalt (de még ma is él vagy újraszületett a világ más pontjain…..) Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 9

2. a „Nyugat” oldaláról nézve felmerült, hogy az osztott szolgáltatások révén akkoriban tiltólistán szereplő magas szintű technológiát (pl. COCOM listás) exportálnak „Keletre”, sőt a végberendezések/terminálok fizikailag is ide kerültek. nagy nemzetközi rugalmassággal sikerült azonban erre is felmentést szerezni, s ez mindkét fél konstruktív hozzáállását bizonyította. ennek kapcsán azonban pl. hazánkban nem engedték a repülés informatika eredményeit publikálni. A nemzetközi szolgáltatók által kialakított kultúrák és köréjük csoportosult légitársasági felhasználói köröket illetően a MALÉV – nagyon helyesen és ésszerűen - a neutrális, kooperatív alapon működő SITÁ-t választotta, amelynek meghatározó tagja lett. Kölcsönösen gyümölcsöző szakmai és pénzügyi együttműködés alakult ki , voltak nagy közös projectek, fejlesztések (Raycheck, SAGIL műszaki rendszer, FIDS járatinformáció, Cargo management reporting), a MALÉV több nagy SITA rendszer világelső referencia felhasználója volt (Gabriel Utas helyfoglalás, Cargo, Opera Operations Control). Később színesebbé vált a paletta, belépett az operatív területen a Lufthansa Systems és a Jeppesen, sőt erre szakosodott magyar rendszerház is (CCS Hungary) a szolgáltatók körébe.

FEJEZETEK, MÉRFÖLDKÖVEK

UTASRENDSZEREK –HELYFOGLALÁS, JEGY-, TARIFÁLÁS, ELEMZŐ RENDSZEREK Minden légitársaságnál az automatizálás az utas rendszerekkel indul. Európai viszonylatban korán 1975-ben a MALÉV világelsőként sikerrel bevezette a SITA cég Gabriel termékcsaládját, amely az USA Atlanta városban működő számítóközpont (Unisys mainframe) osztott szolgáltatásain alapult és SITA hálózaton keresztül elérhető volt a világ minden pontján működő MALÉV iroda és partner számára. Teljes körűen automatizálódott az utasok helyfoglalása és a rendszer tökéletes integrációt biztosított más légitársaságok és utazási irodák rendszereivel világszerte. Érdekes megemlíteni, hogy ennek a Gabriel rendszernek később több korszerűsített verziója készült el és a legjobb időkben 162 tagja volt, ami magasan meghaladja az utána következőket (20 tag). A Gabriel a későbbiekben az internet elterjedésével rengeteg modullal és képességgel bővült, ma is 120 légitársaság használja. Az utas helyfoglaláson keresztül csatlakozott a MALÉV a repülés nagy társa, az utazási ipar ügynökségi rendszereihez, az igazi nagy informatikai gigászokhoz (GDS Global Distribution Systems), akik a MALÉV járatok üléshelyeinek eladását biztosítják világszerte (történelmileg legismertebbek: Galileo/Travelport, SABRE, Amadeus, Abacus,Worldspan ) illetve később az internetes portálokhoz.

Esterházy Béláné, Katalin az utas helyfoglalási rendszer úttörője, sok évtizedes MALÉV-es vezetője és jól ismert, befolyásos nemzetközi szakértője az alábbiakban foglalja össze az eseményeket, elsősorban az üzleti folyamatokban bekövetkezett változásokat. Katalin így élte meg a 70-es évek

Magyarországán még csoda-számba menő komputerizálást, majd az ezt követő állandó fejlődést.


oldal 10

HELYFOGLALÁS / JÁRAT-ELLENŐRZÉS / BEVÉTEL OPTIMALIZÁLÁS MI EZ A TEVÉKENYSÉG, MIÉRT VAN (VOLT) RÁ SZÜKSÉG? A repülőgép üléshelye „romlandó árucikk”, amennyiben üresen marad – nem vették meg – az elveszett hasznot jelent a légitársaság szempontjából. Az utas szempontjából pedig fontos, hogy ha megvette a jegyét egy adott járatra és időpontra, akkor el is tudjon utazni. Ilyen egyszerűnek tűnik, de persze a gyakorlatban bonyolult folyamatok húzódnak meg a háttérben.

Az őskor A jegyeladó hölgy a jegyiroda kurblis (!) telefonjáról felveszi az utas adatait egy „utaskartonra”, majd átszól a „booking” irodába és kéri, hogy a kolleganő foglaljon helyet az X járat/dátum/viszonylatra, bediktálja az utas nevét, címét, telefon elérhetőségét (ha egyáltalán van telefonja). A booking irodában kézírással rögzítik ezeket az adatokat a „diagramokra” (minden járat/dátumhoz tartozik egy előre lefektetett kartoték, amelyeken az adat-változásokat áthúzással, esetleg radírral módosítják).Tehát két helyen keletkeznek azonos adatok. Évente kétszer módosítják a menetrendet (téli és nyári menetrend), ezen belül igen ritka a változás, általában van idő megrajzolni a diagramokat. Ha nem MALÉV járatra is történik foglalás, akkor még a telex útján történő helylekérés / válasz folyamata is beindul és napokat vesz igénybe.

Változtassunk, de miért? A fent leírt procedúra pontatlan, időigényes, az adatok nehézkesen, magas hiba-százalékkal, nehezen változtathatóak, egyszóval: nem versenyképes a „nyugati” légitársaságokkal, amelyek egyre nagyobb teret nyernek magyar piacon is. Kapacitás-kihasználásunk optimalizálásához is használható eszközre van szükségünk.

Automatizálunk - elhatározás és döntés Igen, nincs más logikus válasz, ha nem akarunk végleg lemaradni a versenyben. Ez 1974-re világossá vált, automatizálni kell a helyfoglalási és járat-ellenőrzési rendszerünket. Hogyan? Lehetőségeink: 1.Olyan számítógépet (mainframe) használunk, amely Magyarországon beszerezhető (nincs COCOM listán) és kifejlesztjük saját rendszerünket (software). Egy „szakértő” az R40 computert javasolja. 2.Igénybe veszünk olyan profi szolgáltatást, amely kifejlesztett software-rel és know howval rendelkezik és képes egyidejűleg kiszolgálni több kis vagy közepes méretű légitársaság igényeit egymástól teljesen leválasztott rendszerben (shared system). Nyilvánvaló, hogy az 1. számú megoldás gyakorlatilag, elfogadható idő-kereten belül, megoldhatatlan. A józan ész természetesen a 2. számú megoldást diktálja. Fontos szempont, hogy semleges szervezet üzemeltesse a main frame-et. Ilyen semleges szervezet a SITA (l. a bevezetésben), de – oh jaj! - ez a mainframe (UNISYS 484) az USA-ban, Atlantában található és az „ellenség” így hozzáférhetne az utas-lista adatainkhoz. Komoly politikai ellenállásba Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 11

ütközik ez az elképzelés, azonban a SITA itteni képviselője rendelkezik – szerencsére – olyan meggyőző erővel és befolyással, hogy végül is győz a józan ész, sőt a MALÉV-en kívül még másik három „szocialista” légitársaság is 1974-ben aláírja a vonatkozó GABRIEL szerződést a SITÁ-val.

TANÁCSADÁS / KONZULTÁCIÓK Megjelentek a SITA szakemberei, hogy megtanulmányozzák az akkori helyfoglalási eljárásainkat és alig titkoltan elborzadnak a látottaktól. Céljuk az, hogy előkészítsék a majdani átállást és tanácsaikkal segítsék az új helyfoglalási folyamatok kialakítását, rávilágítsanak az automatizálás nyújtotta új lehetőségekre. Kialakult egy team, amelynek magam is részese voltam, tanulmányoztuk a specifikációt, kérdeztünk, tanácsokat kértünk és mi voltunk azon szerencsések, akik Párizsban először megtanulhatták a rendszer használatát. Életünkben akkor láttunk először komputert, azaz olyan dumb/buta terminál berendezést, amelyeket a MALÉV használt az új rendszer bevezetését követően. Fantasztikus csoda volt, hogy egy kód beütésével kérdeztem és Atlantából a válasz néhány másodperc múlva ott volt a képernyőn!

ÁTÁLLÁS ELŐKÉSZÍTÉSE Szervezési / logisztika feladatok:  az új munkafolyamatoknak megfelelő új munkahelyek kialakítása / clusterek meghatározása  alkalmassá tenni a közvetlen ügyfél-szolgálat és a háttér munkák céljait szolgáló helyiségeket Budapesten, a repülőtéren és a külföldi képviseleteken a terminál berendezések fogadására  lokális hálózat kialakítása  megteremteni a lokális hálózat és a SITA main frame közötti kapcsolatot. Egy-egy adatátviteli vonalat két telefonvonal jelentette, tehát így kapcsolódtunk: MALÉV lokális hálózat  Magyar Posta telefonvonal  SITA központ  SITA vonalak (magyarországi és európai)  Atlanti Óceánban húzódó telefon-kábel  USA adatátviteli vonalak  SITA Központ / Atlanta  felszerelni a terminál berendezéseket (CRT-k, nyomtatók, modemek, szerverek) Megjegyzés:ebben az időben a MALÉV gyakorlatilag nem rendelkezett informatikus szakemberekkel, ezeket a feladatokat a SITA mérnökei látták el, akik maguk is akkor tanultak bele a szakmába. Emberi erőforrás  irányító / szervező team kiválasztása  oktatók kiválasztása  oktatók oktatása / vizsga  a munkafolyamatok kidolgozása az automatizálás nyújtotta lehetőségek és a helyi szabályozások és a nemzetközi repülési standardok (AIRIMP) figyelembevételével  az átállás munka-fázisokra bontott pontos menetrendjének kidolgozása  MALÉV training manual-ek kidolgozása  munkatársak oktatása / vizsga  feladatok /differenciált szintű jogosítások kiosztása Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 12

ÁTÁLLÁS (CUTOVER) Az előzetesen egyeztetett alapadatok és MALÉV paraméterek (user parameter) betáplálása a Gabriel rendszerbe SITA/ATLANTA által történt. Egy hétvégén éjjel-nappali műszakokban manuálisan kellett minden járatot felépíteni és minden utas adatot bevinni a rendszerbe. 1975. november 1-től a MALÉV átállt a Gabriel rendszerre

ELŐNYÖK Az ügyfelek kiszolgálása kulturáltabbá vált, automatikus figyelmeztetés alapján (queue üzenetek) lehetővé vált az utasok kiértesítése menetrend-változáskor, fizetési határidő lejártakor, stb. Minden egyes foglalás egy automatikus, egyedi azonosító kódot (record locator) kapott, amellyel a későbbi ügyintézés során, sőt visszamenőleg is könnyen visszakereshető lett a foglalási rekordjuk. A nemzetközi légitársaságokkal történő kölcsönös üzenetváltás lényegesen felgyorsult. A járatok ellenőrzése különböző funkciókkal (space control function) hatékonyabbá vált, real time módban lehetett áttekinteni a járatok foglalási számait, bizonyos előre beállított paraméterek alapján queue üzenetek figyelmeztettek nagy létszámú (csoportos) igényekre, a járatok telítettségi fokára, lefoglalt, de ki nem fizetett helyek számára, egyes járatszakaszokra maximálisan megengedett üléshelyszámra (limit sale), stb. Ezek alapján lehetett dönteni az esetleges kapacitás-módosításról, illetőleg kiegészítő járat beállításáról, szükség szerint. Így a kapacitás-kihasználási mutatóinkat (load factor) hatékonyabban tudtuk növelni. A rendszer tehát figyelmeztetett, de az embernek kellett a döntéseket meghoznia. Hasznosnak bizonyult továbbá a riportok, azaz összegyűjtött és paraméterek szerint leválogatott adatok kigyűjtése, amelyek segítették a döntések előkészítését.

KOCKÁZATOK / HÁTRÁNYOK A legfőbb problémát, a kezdeti időkben az adatátvitel lassúsága, sőt időnkénti leállása okozta. Nem lehetett tudni, hogy mennyi ideig tart. Ezért úgy az ügyfelek, mint a munkatársak bizalma megrendült a rendszerben és nem lehetett az elvárt hatékonysággal dolgozni. Bizonyos, fontosabb adatokat kénytelenek voltunk ezért manuálisan is nyilvántartani, és ez persze soha nem lehetett pontos. Kezdetben nem rendelkeztünk megfelelő mentési technikákkal sem.

FEJLŐDÉS / FEJLESZTÉSEK A légiközlekedés fejlődése, a felhasználók fokozódó igényei arra késztették a SITA GABRIEL irányítóit, hogy mind több program-fejlesztést hajtsanak végre, valamint az adatátvitel minőségén is lényegesen kellett javítani. Ehhez a Felhasználói Értekezlet jelentette a megfelelő fórumot, amelyen a felhasználók képviselői valamint a SITA GABRIEL vezetői és szakértői vettek részt. Az értekezlet „játékszabályai” demokratikusnak voltak tekinthetőek, így nem csak a felhasználók, de a GABRIEL fejlesztői is sokat profitálhattak, Voltak azonban olyan fejlesztési javaslatok, amelyeket „nem kifizetődő” megjegyzéssel eleve elutasítottak. 1981-re már csak új platform / mainframe és teljesen új software lett az elfogadható Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 13

megoldás, amelynek részleteit szintén a felhasználók való konzultáció segítségével alakítottak ki. Olyan mértékű volt a változtatás, hogy ennek bevezetése egy újabb Cutovert eredményezett, amelyre 1982 nyarán tavaszán került sor. Ettől kezdve a további fejlesztési igényekre már soha nem mondtak nemet, azonban „beárazták” a kéréseket, amelyeket a felhasználók nem tudtak mindig vállalni.

KAPCSOLÓDÓ RENDSZEREK A helyfoglalási rendszert követték a további, kapcsolódó rendszerek, például a repülőtéren alkalmazott járatindítási rendszere (RAYCHECK, LOADSTAR, SITA DEPARTURE CONTROL) TARIFA és TICKETING, YIELD MANAGEMENT ( IATA YM, STRATEGY, PROS) valamint további, a helyfoglalási rendszerhez már nem szorosan kapcsolódó rendszerek, mint például, LOAD CONTROL, FIDS, stb. L. külön fejezetek. A helyfoglalási rendszereknek kompatibilisnek kellett lenniük a globális ügynökségi rendszerekhez (GDS), mint például a GALILEO, AMADEUS, SABRE, stb. A GDS-ek jelentősége azonban mind inkább elhalványul az internetes eladások térnyerésével. Tehát ma már egy légitársaságnak a saját web oldalaira és az azokon keresztül történő repülőjegy eladásokra, illetve az azokhoz kapcsolódó szolgáltatásokra kell elsősorban figyelmet fordítani. A webes felületek hátterében futnak az erre a célra kifejlesztett programok (például: a booking engine.)

YIELD/REVENUE MANAGEMENT RENDSZER (FAJLAGOS BEVÉTEL/ ELŐNY) Az 1990-es évek során vezettük be a IATA, majd a STRATEGY Yield Management rendszert, később a PROS-t. A bevétel-optimalizáló rendszer az adott légitársaság, múltban keletkezett adatait dolgozza fel és ezekre alapozva hozza meg az előrejelzéseit. Így tehát a különböző tarifákhoz kötődő helyfoglalási osztályokra (RBD) allokálandó helyek számát, a túlkönyvelés mértékét, az adott kapacitáson felül még eladható helyek számát (kapacitás bővítése). Az előrejelzés (forecast) alapján javasolja a szükséges módosításokat és - fejlettebb szintű, integrált rendszer esetén - automatikusan viszi át ezeket a változtatásokat a helyfoglalási rendszer járat-rekordjaira (inventory). Amennyiben azonban a légitársaság szolgáltatásainak minősége, menetrendje, flottája, árpolitikája, disztribúciós rendszere (saját eladási szervezetén kívüli ügynöki hálózat, internetes eladások), stb. nem felelnek meg az ügyfelek elvárásainak, a versenyképesség követelményeinek, NEM TEKINTHETŐ CSODAFEGYVERNEK! Lásd. a MAGYAR LÉGIKÖZLEKEDÉSI VÁLLALAT szomorú végét.

MAIN FRAME VS. PC MEGOLDÁSOK A légiközlekedési iparágban mind inkább bekövetkezett öldöklő verseny (open sky, low cost légitársaságok, benzin-ár robbanás, stb.) komoly szemlélet-váltásra kényszerítette a hagyományos szereplőket is. Egyre több adatot kell egyre gyorsabban és mind szofisztikáltabb eszközökkel feldolgozni. Most már a mennyiségi mutatók jelentőségével szemben sokkal fontosabbá vált a bevétel optimalizálása, a profit növelése, a veszteségek minimalizálása. Ehhez nyújt segítséget az intelligens terminálok elterjedése, az IP technológia térnyerése, általában a robbanás-szerű informatikai fejlődés, a nagy mennyiségű adatok feldolgozása egyre inkább lokálisan történik, egyedi szükségletek szerint. Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 14

JEGYKEZELÉSI-JÁRATINDITÁSI RENDSZEREK, DCS TÖRTÉNELEM Néhány év múlva 1978-ben került sor az utas- és forgalmi kiszolgálást drámaian forradalmasító Járatindítási rendszer Departure Control/ DCS első verziójának telepítésére Ferihegyen Raycheck néven, lokálisan telepített stand – alone számítógép, a Raytheon hardware és szoftver technológiáját alapul véve. A stand –alone rendszer a SITA hálózaton kommunikált az atlantai utas és helyfoglalási rendszerrel, letöltötte a napi aktuális menetrend szerinti járatokat a helyfoglalási adatokkal és a lokális rendszeren futó programok automatizálták az utasok jegykezelését, a beszállókártyák kiadását, a beszállítási folyamatot továbbá a repülőgépek terhelés- és egyensúlyszámítását. A szervezetet utasforgalmi, forgalmi és üzemi rányitási oldalon drasztikusan módosítani kellett, elsősorban új döntési csomópontok kialakításával, s pl. ennek eredményeként alakult ki az Operations Control/Ügyeletes Forgalmi Igazgatói intézmény. A DCS rendszereknek idővel újabb verziói kerültek telepítésre, Loadstar/SDCS terméknéven, a SITA osztott szolgáltatásain alapulva, majd a repülőtéri utaskezelés hatékonyságának növelésére létrejött a CUTE Common Use Terminal platform (mai terméknevén CUPPS és CUSS), amely lehetővé tette, hogy ugyanarról a munkaállomásról különböző légitársaságok rendszereihez hozzáférjenek , liberalizálva a MALÉV és a külföldi légitársaságok kapcsolatrendszerét. A DCS rendszer ugrásszerű en felgyorsította az utas és járat indítási folyamatokat. Ez a technikai fejlesztés magával hozta a kiszolgáló szervezet korszerűsítését, egyszerűsítését és nagymértékben növelte a MALÉV versenyképességét más légitársaságokkal szemben.

Ballai János a MALÉV Informatikai Osztály alapítója és Vezetője 1975-tól 1991-ig az alábbiakban emlékezik erre a hőskorra:

AUTOMATIKUS JEGYKEZELÉSI ÉS JÁRATINDÍTÁSI RENDSZEREK - DCS – RAYCHECK SYSTEM 1978 BEVEZETÉS A MALÉV 1975-ben vezette be a GABRIEL helyfoglalási rendszert (lásd helyfoglalási rendszer leírása), mely az USA atlantai központjából nyújtotta ezt a szolgáltatást. A rendszer bevezetése jelentős minőségi eredményt hozott az utas helyfoglalás és a hozzá kapcsolódó szolgáltatások tekintetében. Világossá vált, hogy a repülőtéri utas kiszolgálási és járatindítási folyamatok manuálisan kezelése már nem felelnek meg az utasforgalmi követelményeknek. A repülőtéri utasforgalom gyors növekedése kényszerítette ki ezen a területe is az automatikus rendszer bevezetését. A MALÉV piackutatást végzett és a SITA (lásd SITA leírását) által szolgáltatott RAYCHECK rendszert választotta ki az utas kezelés és járatindítási folyamatok automatizálására.


oldal 15

A RAYCHECK RENDSZER ARHITEKTÚRÁJA, a Ferihegy1-es terminálon telepítve To Reservation System Interprocessor Communication PTS-1200 128K + Discs

PTS-1200 128K +Discs

System Consoles S WI T C H

1015B

1015B

Supervision-Load control

Displays

Printers

1020B

1020B

1020B

Check-in 1

Check in 2…… Check in 12

Displays

Displays

Printers

Printers

Boarding Pass Boarding Pass Printers Printers

Displays

Printers

Boarding Pass Printers

1020B

Second Airport

Displays

Printers

Boarding Pass Printers


oldal 16

A Raycheck rendszer vezérlését két parallel működésű stand-alone - PTS-1200-as számítógép biztosította. A két számítógép egy interprocessor communication interfészen keresztül volt összekötve, a két gép párhuzamosan minden adatot(adatbázis és szoftver) duplikálva tartotta, mely maximális biztonságot nyújtott az operatív folyamatok működésében. Mindegyik Raycheck processorhoz csatlakozott egy – egy system console (1920-24X80) képernyővel. A vezérlő terminál szerepe volt a start-up, close down(járat megnyitása, lezárása) és további vezérlő funkciók végzése. A PTS-1200 processor rendelkezett 2 X 10 Mbyte, vagy 3X2.6 Mbyte cartridge merev lemezzel, ezek tárolták a felhasználói adatokat (járat, utas..stb.) és az operációs rendszert is. A cluster controller 4 vezetékes kommunikációs vonalon csatlakozott a PTS-1200-hoz – 4800 bit/sec sebességgel - és biztosította a terminálok távoli csatlakozását és. A cluster controllerek csatlakoztatták; display terminálok, nyomtatók, boarding pass (beszálló kártya) nyomtatókat. A Raycheck felhasználói programot a Raytheon Data System (RDS) fejlesztette ki és a légiflotta típusoktól függően testre szabással lehetett bevezetni éles üzemben. Megjegyzendő, hogy ebben az időben a fentiekben letelepített berendezések COCOM listán szerepeltek, szigorú ellenőrzés alatt lehetett üzemeltetni és tilos volt minden publikáció. A másik probléma volt, hogy összesen két postai vonal ment ki Bécsig és a kommunikáció elég gyakran akadozott.

A RAYCHECK RENDSZERREL KEZELT FOLYAMATOK RÖVID LEÍRÁSA UTAS JEGY- ÉS POGGYÁSZKEZELÉS A napi aktuális menetrend alapján a rendszer lehívta az atlantai központból az aktuális utas listát járatszám szerint. A Ferihegy 1 terminálon 12 jegykezelő pult került kiépítésre – egy utas kezelése átlagosan 2 perc volt – minden pult rendelkezett display terminállal, nyomtatóval, boarding pass nyomtatóval, u.n. baggage tag nyomtatóval. Az adott pulton egy adott járat került megnyitásra az adott járatra vonatkozó helyfoglalási listával. Az utas jegyadatainak bevitele után a rendszer érvényesítette a jogos helyfoglalást , az ültetés, csomagfelvétel, baggage tag/címke nyomtatás megtörtént-a rendszer folyamatosan real-time módba mutatta járat feltöltésének aktuális állapotát. Mikor az utas lista betöltésre került a helyi Raycheck rendszerben ezután már lokális helyfoglalást is lehetett kezdeményezni

JÁRATFELTÖLTÉS- FÖLDI KISZOLGÁLÁS Az u.n. ramp officer ellenőrizte a cargo és üzemanyag feltöltést az adott géptípusnak megfelelő előírások valamint a rendszer által folyamatosan szolgáltatott információk alapján. Szoros kapcsolatban dolgozott a load control irodával, így a szükséges terhelés elosztással kapcsolatos korrekciókat közösen hajtották végre.


oldal 17

LOAD CONTROL / FORGALMI IRODA A load control iroda feladata a rakodás feltöltés folyamatos figyelése a rendszer által szolgáltatott információk alapján. Amikor a gép telje feltöltése megtörtént az adott géptípus műszaki előírása alapján meg kell határozni a repülőgép súlypontját, melynek a típustól függően egy adott intervallumban kell esnie a repülőgép adott fizikai helyén. Ennek repülésbiztonsági szempontból van jelentősége-a repülőgép stabilitását mutatja meg. A MALÉV flotttája a szovjet TU típusú gépekből állt. A TU gépek számítási módszerei eltérnek a nyugati típusuktól, így az alkalmazási szoftvert ennek megfelelően módosítani kellett. Összefoglalva belátható, hogy egy utas kezelési, járatindítási folyamat milyen összehangolt munkát kíván és mind ezen feladatokat igen rövid idő alatt kell végrehajtani. Mivel a repülés veszélyes üzem, ezért minden repüléssel kapcsolatos alkalmazói program éles üzemben való bevezetését a légügyi hatóság engedélyezi – A Raycheck bevezetése előtt a manuális és az automatikus rendszer párhuzamosan futott állandó ellenőrzés és a kritikus adtok, számítások összehasonlítása mellett.

A RAYCHECK BEVEZETÉSÉNEK EREDMÉNYEI A rendszer bevezetése minőségi és repülésbiztonsági folyamatokat automatizált, folyamatos monitorozást biztosított és nagy előrelépés volt a jelentősen növekedett utasforgalom kulturált, gyors és biztonságos kezelésében. Másodsorban a rendszer bevezetése nagy mértékben növelte a kiszolgáló személyzet informatikai ismereteit és elősegítette a további bonyolult rendszerek adaptálását, használatát


oldal 18

Berényi Gábor Ágota, a légitársasági és repülőtéri rendszerek nemzetközi informatikai szakértője, a MALÉV, a Budapest Airport és egy kiszolgáló cég informatikai szolgálatainak vezetője, aki a SITÁ-nál is dolgozott, az alábbiakban foglalja össze a DCS további generációnak történetét:

DCS (DEPARTURE CONTROL SYSTEM) RENDSZER A járatindítási rendszer második generációja a SITA által kifejlesztett termék volt, LOADSTAR fantázianév alatt. Az új rendszer bevezetése a 2-es terminál megnyitása miatt vált szükségessé, mivel az addig használt rendszer már nem elégítette ki azokat az igényeket, amelyek a két terminálos üzemelés során felmerültek. Ez a rendszer „hostolt” üzemmódban működött, ami azt jelentette, hogy a rendszer a SITA tulajdonában lévő és általa Atlantában üzemeltetett számítógépen működött, és a Malév (ill. a többi felhasználó légitársaság) felhasználói a SITA által kialakított telekommunikációs hálózaton keresztül a munkaállomások használatával, a megfelelő jogosítások birtokában tudtak hozzáférni a rendszerhez. Egy ilyen rendszer használatának a MALÉV esetében több előnye is volt: egyrészt használhatott olyan hardver eszközöket, amelyek Magyarországra a COCOM lista miatt nem lettek volna behozhatóak, másrészt sem a szoftver fejlesztésére, sem pedig annak üzemeltetésére nem kellett alkalmazotti stábot fenntartania. Emellett persze egy DCS nagyságrendű rendszer sem olyan, amit saját magának ki tudott volna fejleszteni és később üzemeltetni egy MALÉV típusú légitársaság, bár voltak erre gondolatkísérletek. Néhány nagyobb légitársaság első körön magának fejlesztett (mint például a Lufthansa vagy a Swissair) később önálló céggé alakítva az ezt kifejlesztő részlegét, megjelent a piacon önálló szolgáltatóként. A SITA DCS járatindítási rendszer amellett, hogy fejlett szoftver termék volt; használata esetén megkövetelte, hogy a kiszolgálási technológia is a világban elfogadott és használt folyamatokhoz alkalmazkodjon. A szükséges folyamatos fejlesztés lehetősége is rendelkezésre állt, mivel a felhasználói fórumokon(„User Meeting” a rendszert használó légitársaságok közösen meghatározhatták a fejlesztési irányt és konkrét módosítási igényeket is megfogalmazhattak. A SITA DCS rendszer bevezetésében a MALÉV úttörő szerepet játszott és a környező országok légitársaságai ezen tapasztalatokra, véleményekre is alapozva döntöttek később a felhasználói csoporthoz való csatlakozásról. Egy ilyen kialakítás mellett párhuzamosan több légitársaság használta a rendszert, de minden légitársaságnak, külön „partíciója” volt, teljesen függetlenek és nem átjárhatóak voltak az adatbázisok. Ez lehetővé tette azt is, hogy kisebb – légitársaság specifikus – eltérések legyenek a különböző légitársaságok által használt verziók között. A járatindítási rendszernek alapvetően két fő funkciója különíthető el: az utas felvétel és a súly-és súlypontszámítás.


oldal 19

Ezeknek a funkcióknak az ellátásához szükség van a külvilággal, más rendszerekkel, más légiközlekedési szereplőkkel való kommunikációra. Az utas felvétel elvégzéséhez szükséges ismernünk az egyes járatokra jegyet váltott utasok adatait. Ezek az adatok a helyfoglalási rendszerekben találhatóak meg, tehát szükséges ezen adatok átvitele ezekből a rendszerekből az adott repülőtér utas felvételi rendszerébe. A másik típusú kapcsolat pedig arra vonatkozik, hogy az adott repülőtéren egy járatra vonatkozóan keletkezett adatokat a következő állomás (ill. célállomás) tudomására kell hozni. Ilyenek az utaslétszámra és a repülőgép terhelésére vonatkozó adatok. Mind a bejövő, mind a kimenő adatok tekintetében az üzenetváltás teljes mértékben automatizálva és egységes formában történik, amelyhez szükséges szabványokat a IATA előírások szabályozzák.

UTASFELVÉTEL A DCS rendszer egy adott járatra vonatkozóan megkapja a légitársaság helyfoglalási rendszeréből az utas listát, amely az utasok nevén kívül egyéb speciális jellemzőket (pl.:kíséret nélküli gyermek, vegetáriánus étkezés,…) kívánságokat; valamint az esetleges átszállásra vonatkozó adatokat is tartalmaz. Ezen adatok alapján történik meg az utasok felvétele, ahol aktuális információkkal is ki kell egészíteni a helyfoglalásból már ismert adatokat. Ilyen a feladott csomagok darabszáma és súlya, valamint módosítani lehet egyéb, az utas felvétel során felmerült adatokat. Mivel a rendszer végigkíséri az utas felvétel folyamatát, így a következő ponton a repülőgépre való beszállításnál is van funkciója. Egyrészt a beszállító kapunál lehet látni, hogy hány utas és milyen összetételben várható; másrészt ellenőrizni lehet, hogy ténylegesen hány utas szállt be, így kiderül az is, hogy van-e olyan utas, aki jelentkezett a járatra, de nem szállt fel a repülőre. Ennek különösen repülésbiztonsági szempontból van jelentősége, hiszen az utas csomagja nem maradhat a repülőgépen, ha ő maga nem utazik.

SÚLY- ÉS SÚLYPONTSZÁMÍTÁS Az utas kezelés során a rendszerbe bevitt adatok alapján a rendszer automatikusan számolja és ellenőrzi a repülőgép súlyát és súlyponti helyzetét és probléma esetén figyelmezetést ad. Az utas felvétel befejezése után pedig elkészíti a végleges adatok alapján a repülőgép terhelésére és súlyponthelyzetére vonatkozó számításokat és az adatok megfelelősége esetén előállítja a szükséges dokumentumokat és automatikusan generált IATA szabvány üzeneteken keresztül értesíti a következő állomást a várható utasokról és a gép terheléséről.

A RENDSZER HASZNÁLATÁT KISZOLGÁLÓ SZERVEZETEK A légiközlekedésben szokásos folyamatokat kiszolgáló rendszerek esetében az azt használó szervezeteknek némiképp alkalmazkodnia kellett a rendszer elvárásaihoz. Ennek megfelelően a MALÉV-nek is ki kellett alakítania a megfelelő struktúrát, amely a rendszer adottságainak lehető legjobb kihasználásához vezethet.


oldal 20

Ennek egyik eleme az SZRK (Számítógépes Rendszerellenőrző Központ), amelynek feladata a rendszer alapadatainak betáplálása, karbantartása, a napi adatok ellenőrzése és a járatok kezelése során esetlegesen felmerülő problémák kezelése volt. Ez a feladatkör úgy bővült, ahogy a MALÉV újabb és újabb rendszereket vezetett be, mert ezeknek a rendszerfelügyelete és üzemeltetése szintén ehhez a szervezethez került.

HARDVER ESZKÖZÖK FEJLŐDÉSTÖRTÉNETE A technika fejlődésével párhuzamosan a felhasználók által használt hardver eszközök is folyamatosan fejlődtek. Az általánosan használatos dokument printereken túlmenően a rendszer különleges, a rendszer funkcionalitását támogató printereket is használt. Ezek az első körön a beszállókártya és a poggyászcímke nyomtató voltak. Ezeket a nyomtatókat kifejezetten ezekre a feladatokra tervezték, speciális papírral és formátummal működtek. Ezeket az eszközöket is folyamatosan fejleszteni kellett annak megfelelően, ahogy azt az iparág megkövetelte. Amikor bevezették a beszállókártya hátoldalán lévő mágnes csíkot, amely tartalmazta ugyanazokat az adatokat, ami szövegesen is felkerült az első oldalra, az ilyen nyomtatásra alkalmas beszállókártya nyomtatót is ki kellett fejleszteni. A mágnes csíkon lévő információ arra adott lehetőséget, hogy a beszállítás során ez olvasható legyen – ezek az eszközök a „gate reader” nevet kapták. Így a rendszert ezzel az eszközzel összekötve fel lehetett gyorsítani és az emberi tévedés lehetőségétől meg lehetett szabadítani (ha nem is teljesen) a beszállítás folyamatát. A következő fejlesztési lépés volt, hogy a helyfoglalás során keletkezett jegy a későbbiekben a repülőtéren már beszállókártyaként is használható legyen. Ezt nevezik ATB-nek (Automated Ticket and Boarding). A MALÉV sajnálatosan sosem vezette be a saját irodáiban ezt a technológiát, gyakorlatilag kihagyta ezt a fejlődési fázist. A repülőtéren ettől függetlenül megjelentek utasok ATB jeggyel, akik más irodában vették a jegyet, így a repülőtérnek ezek kezelésére is fel kellett készülnie. A poggyászcímke nyomtatóknál egy jelentős lépés volt, amikor bevezették a vonalkód használatát. Ekkor az utas felvétel során kinyomtatott poggyászcímke tartalmazta a csomagot egyértelműen azonosító vonalkódot. Ez két irányban is segítette az adatok használatát. egyrészt a poggyászazonosítás ennek alapján egy vonalkód olvasóval automatizálható volt és erre támaszkodva alakultak ki a poggyászazonosító rendszerek : Baggage sortation, Baggage Reconciliation; másrészt az elveszett poggyász esetén a poggyászazonosítást is egyszerűsítette. További fejlesztési lépés volt a CUTE (Common Use Terminal Equipment) eszközök bevezetése. Ez már azt a fejlesztési irányt támogatta, hogy egyre több feladat elvégzését az utasra bízzuk. Ezeken az eszközökön keresztül az utas maga végzi el az utas felvételi lépéseket, nyomtatja ki automatikusan a beszállókártyáját. Az internet elterjedésével természetesen a légiközlekedés által használt informatikai rendszerek fejlesztése is ebbe az irányba fordult. Elsőként a helyfoglalási rendszerek használták ki ezt a lehetőséget, a fapados légitársaságok belépésével pedig olyan légitársaságok is születtek, ahol kizárólag internetes helyfoglalás lehetséges. Mostanra pedig a beszállókártya nyomtatása is megtörténhet otthon, tehát az utas majd a beszállító kapunál fog csak jelentkezni az utazásra. ….. és a fejlesztésekben is határ a csillagos ég ……. Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 21

DCS

PNL

Reservation

Magyarázat: Reservation-Utashelyfoglalás PNL-Passenger Name List - Utaslista DCS – Departure Control System - Járatindítási Rendszer LDM, PFS, PSM - Állomások és rendszerek közötti járatok terheléséről, átszálló és speciális utasokról küldött szabványos üzenetek LDM, PFS, PSM,….

JELENTŐSEBB REPÜLŐTÉRI RENDSZEREK MAGYARORSZÁGON A Raycheck szolgáltatója, ugyanazon Raytheon adta 1981-ben a MALÉV első FIDS Flight Information Display rendszerét is, amely az induló/érkező járatokat jeleníti meg a nagyközönség és a belső szakszolgálatok számára (idő, kapu, pult stb.) Ez lokális rendszer sokáig a légitársaság üzemeltetésében működött, csak a 90-es évek végére került át a Ferihegyi Repülőtér szervezetei hatáskörébe. a MALÉV-es korszakban 1985-ben a 2. generációs FIDS-et a MALÉV és egy SAFIT nevű francia cég közösen fejlesztettek ki, majd a 3. generációs az USA-beli AMRIS cég igen korszerű terméke volt, amelyet pár év múlva felváltott az olasz Ferranti. A FIDS-ek egyszerűen nagyszerű Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 22

rendszerek, amelyek az érkező és induló járatok aktuális adatait jelenítik meg és osztják szét egy reptéren (és környezetén) belül - nagyrészt automatikus interface-ek (gyakorlatilag szabvány telexek) alapján. A későbbiekben a FIDS rendszerek AODB-vé nőtték ki magukat (Airport Operational Database), azaz a különböző légitársaságok adott repülőtéri üzemelési adatait feldolgozva elemzésekre sőt a szolgáltatások számlázásra is alkalmassá váltak. Technikailag egyszerű rendszer a Bagtrac/Worldtracer, azaz a nemzetközi poggyászkereső applikáció (a világ első és egyetlen igazán globális rendszere), de jelentősége óriás az utasok elirányított/elveszett poggyászainak megkeresésében. A MALÉV a világon elsőnek csatlakozott a SITA által integrált, telex és online üzemmódban egyaránt működő megoldáshoz 1980-ban. Később a poggyászkeresés repülőtéri funkcióként is bővült. Ma több mint 450 légitársaság használja egységesen. A nemzetközi repülés biztonságának fokozása érdekében a poggyászkezelés területén több ellenőrző rendszert is kifejlesztettek, biztosítván, hogy utas nélkül poggyász ne kerüljön a repülőgép fedélzetére (Passenger and Baggage Reconciliation). Ez önálló repülőtéri applikáció és termék megjelenését is eredményezte, de több a légitársasági DCS rendszerekkel való hatékony integráció is szükségessé vált. Ezzel párhozamosan egyre inkább előtérbe került a minőségi utas kiszolgálás, azaz a poggyászok elirányításának, elvesztésének a minimalizálása. A poggyászok hatékony kezeléséhez bevezették a rádiófrekvenciás azonosítást is chipeket beépítve az címkékbe illetve a repülőtereken érzékelő berendezéseket és interface-eket telepítve. Érdemes megemlíteni, hogy Ferihegyen kívül a PÉCSI REPTÉR automatizálására is sor került 2003ban, amelyet évekig az AUA osztrák légitársaság használt. Az informatikai megoldásokat a CCS Hungary magyar cég szállította, akik tevékenysége a Cargo fejezetben részletesebben kifejtésre kerül.


oldal 23

Berényi Gábor Ágota, a légitársasági és repülőtéri rendszerek nemzetközi informatikai szakértője, a MALÉV, a Budapest Airport és egy kiszolgáló cég informatikai szolgálatainak vezetője, aki a SITÁ-nál is dolgozott, az alábbiakban írja le a FIDS funkcióit:

FIDS rendszer A rövidítés a Flight Information Display System elnevezésből kialakított betűszó az utastájékoztatási feladatokat ellátó rendszereket jelenti. ddutas tájékoztatás bevezetésére.

A RENDSZEREK FEJLŐDÉSTÖRTÉNETE A mai napig több generációja működött illetve még működik is a repülőtéren. Az első generáció a Rayfids termék volt, amely a Raytheon cég (hasonlóan az első generációs DCS rendszerhez) által kifejlesztett rendszer volt. Általában az ilyen típusú rendszerek lokálisan üzemelnek az adott repülőtér igényeit kiszolgálva. Mivel ebben az időszakban a repülőtér üzemeltetése is a MALÉV tevékenységi körébe tartozott, így ennek a rendszernek a beszerzése és üzemeltetése is a cég feladata volt. A következő generáció a francia SAFIT cég által gyártott, és némileg a MALÉV kívánságainak megfelelően módosított rendszer töltötte be ezt a funkciót. A rendszer Touchstone monitorokkal működött. 1991-ben a SABRE AMRIS FIDS rendszere került bevezetésre. Az adatok megjelenítése kábeltévés hálózaton működött, amelyet a Scientific Atlanta nevű cég fejlesztett ki erre az alkalmazásra. A MALÉV-től független repülőteret üzemeltető cég (LRI) megalakulása után felvetődött a kérdés, hogy egy tipikusan repülőtéri üzemeltetési feladatkörbe tartozó funkciót miért a légitársaság informatikai rendszere lát el. Így került sor a T2B terminál megnyitásával egy időben – már a repülőtér üzemeltetése alatt működő – új FIDS rendszer bevezetésére, amelyet a FERRANTI cég fejlesztett ki. A cég nevének változása miatt jelenleg a rendszer ULTRA FIDS néven üzemel. Erre a rendszerre alapozva fejlesztette ki a későbbiekben a repülőtér az AODB (Airport Operational Data Base) rendszerét.

A RENDSZER ÁLTALÁNOS FUNKCIÓI Az utas tájékoztató rendszerek különböző változatai megegyeztek abban, hogy lokálisan üzemeltett számítógépre vannak telepítve, a szolgálati helyeken adatbevitelre alkalmas munkaállomásokon keresztül lehet a rendszerhez hozzáférni. Az utasok számára dedikált monitorokon és nagy kijelző táblákon keresztül voltak láthatóak az információk. A Ferranti FIDS rendszer esetében bizonyos helyeken speciális TV készülékeken voltak láthatóak az információk.


oldal 24

A ferihegyi repülőtér esetében annyiban volt a tipikustól eltérő a FIDS rendszer használata, hogy ezt a rendszert nem csak az utasok tájékoztatására, hanem a belső szolgálatok informálására is használtuk. Ez gyökeres változást hozott a repülőgépek kiszolgálásának az irányításában, - és ezzel párhuzamosan a szervezetek struktúrájában - mivel az addigi storno rádió készülékeken keresztüli verbális információátadást kiváltotta a FIDS rendszeren keresztül folyamatosan követhető változások alapján történő munkavégzés. Ezt egy példán keresztül úgy lehetne szemléltetni, hogy amikor egy gép leszállt, akkor az előzőleg alkalmazott technológia alapján storno bemondáson keresztül értesítette erről a diszpécser az érintett szolgálatokat, akiknek erre az értesítésre kellett mozdulniuk és elvégezni a technológiában előírt feladataikat. FIDS rendszer bevezetése után ugyanez az adat a rendszerbe került bevitelre és minden további értesítés nélkül a kiszolgáló szervezeteknek a feladataikat ennek az adatnak az ismeretében kellett ellátniuk. Ez ugyanígy igaz volt minden egyes technológia fázisra is, tehát a rendszerben egy pillantással ellenőrizhető lett, valamint ugyanakkor dokumentálható is volt, hogy mely járat(ok)nál folyik éppen a beszállítás, melyek azok, amelyeknél folyik az utasok felvétele, stb. Ez igényelte az egyes kiszolgáló szervezetek technológiájának a megváltoztatását is. Ez a kettős funkció tette lehetővé azt is, hogy ne csak a napi aktuális adatok tekintetében legyen használható a rendszer, hanem mint egy – ugyan kezdetleges – statisztikai adatbázist is használni lehessen. A napi járatkezelések során a tényleges időadatokon kívül az aktuális utas adatok is bekerültek a rendszerbe, így alkalmas volt forgalmi és terhelési adatok gyűjtésére. Ez vezetett ahhoz az elképzeléshez, hogy ez a rendszer legyen az alapja egy későbbiekben kialakítandó AODB rendszernek (Airport Operation DataBase)

UTASTÁJÉKOZTATÁS Az utasok tájékoztatására szolgáló adattartalom a megjelenítés helyszínétől függ. Az utas áramlás útvonalát követve az a cél, hogy minden ponton az ott szükséges adatokat jelenítsük meg. Induló utasok számára az előcsarnokban a járatok indulási idejének a megjelenítése és a járatot kezelő kezelő pultok száma és az esetleges késések megjelenítése a fontos; az utas kezelő pultok feletti monitorokon az adott járat és az osztály megjelölése található; a tranzitban a beszállító kapu megjelenítése és a beszállítás tényének a kiírására van lehetőség. Érkező utasok számára a poggyászszalagok feletti kiírás tájékoztatja az utasokat arról, hogy melyik szalagon fog megérkezni a csomagjuk;az érkezési csarnokban pedig az érkező utasokra várakozók számára mutatja a rendszer a várható és a tényleges érkezési adatokat az esetleges késésre vonatkozó információkkal együtt. Szolgálatok tájékoztatása A repülőgép kiszolgálást ellátó szervezetek számára a fentieken túlmenően még további részletező adatok állnak rendelkezésre, attól függően, hogy az egyes szolgálatok feladataikhoz milyen további információkra van szükség. Ilyenek például az utaslétszámra vagy az áru mennyiségére vonatkozó adatok.


oldal 25

Budapest Airport üzemeltetésében működő FIDS rendszerkapcsolatok (2003)

AODB tervezett kapcsolatrendszere (2003)


oldal 26

SAGIL – REPÜLŐGÉPEK MŰSZAKI KARBANTARTÁSÁNAK TERVEZÉSE ÉS HÁTTÉRRENDSZEREI Kiváló példája a nemzetközi szakértők és a MALÉV saját informatikusai kreatív együttműködésének.

Nagy Tibor, a légitársasági és repülőtéri informatikai rendszerek szervezője, az anyag és alkatrész gazdálkodási folyamatok szakértője , a SAGIL anyag főszerkesztője

Ballai János, repülőmérnök, a MALÉV Számítástechnikai Osztály megalapítója és vezetője 1975-től 1991-ig. A SITA Service Development Commitee MALÉV részéről választott tagja(1977-1982-ig) – 18 légitársaság képviselete közös fejlesztési kérdésekben a SITA 200 polgári légitársaságát. A SAGIL fejlesztés projekt vezetője 1981 – 1983 között Vaszkó András, aki hét év repülőgép szerelői gyakorlat után került az informatikai osztályra, majd közlekedési közgazdász diplomát szerzett. Részt vett a saját fejlesztésű rendszerek kidolgozásában, majd a SAGIL projekt megkezdésétől annak befejezéséig a Rotables control alprojekt vezetője volt. a SAGIL üzemben helyezése után a rendszer felügyeletét karban tartását látta el. Ditrich Tamás: közgazdász, a SAGIL projekt folyamatszervezője anyaggazdálkodási, készlet nyilvántartási területen Szücs Ákos: műszaki főiskola, a SAGIL projekt folyamatszervezője a műszaki nyilvántartás és karbantartás területen

BEVEZETÉS A MALÉV az 50-es évektől 1968-ig belföldi járatokat üzemeltetetett Li-2, IL-14 és IL-18 típusú légcsavaros repülőgépekkel. Az első sugárhajtású, TU-134 típusú gép 1968 decemberében szállt le a Ferihegyi repülőtéren. A TU-134 gépet követte a TU-154 típus, ezek mellett még üzemelt az IL-18 típus is. A 70-es évek elején már komoly 20 gépes flotta biztosította az utas és áruszállítást. A repülőgép gyártó cégek elsősorban repülőgépeik biztonságos üzemeltetése, de másodsorban talán még fontosabb okból a repülésbiztonság érdekében előírták, hogy a repülőgépeken üzemelő bizonyos berendezéseket meghatározott üzemidő teljesítése után függetlenül azok műszaki állapotától ellenőrizni kell. Ez az ellenőrzés lehetett csupán szemrevételezés, a fedélzeten történő műszeres ellenőrzés vagy a berendezés leépítése, laboratóriumba szállítása, ott egy részletes műszaki ellenőrzés, szükség vagy előírás szerint bizonyos részegységek cseréje. Ez természetesen csak ajánlás volt, a gyártó cégeknek sem joguk, sem lehetőségük nem volt annak ellenőrzésére, hogy ajánlásukat végrehajtják-e. A repülőgép üzemeltetés helyzetét tovább szigorította a polgári légügyi hatóság, akinek az előírások végrehajtásának ellenőrzésére, nem csak joga, de lehetősége is volt.


oldal 27

A feladat végrehajtása első ránézésre rutinnak tűnik, de a Malév által üzemeltett 20 repülőgép mindegyikén nagyságrend szerint 1000-1200 ilyen berendezés volt. Belátható, hogy a pontos, precíz adatnyilvántartás manuális, kartonos módszerekkel nem elégítette ki a repülésbiztonsági követelményeket, a hibalehetőség magas volt. Értelemszerűen ilyen feladat napi szintű manuális ügyintézése rengeteg embert igényelt, amelyek munkájában lévő hibalehetőség jelentős repülésbiztonsági kockázattal járt, ezért az informatika elterjedésével már a 70-es évek végén felmerült az igény a nyilvántartás informatikai rendszerrel való támogatására. A Malév Számítástechnikai Osztályát is elsősorban ennek a feladatnak a megoldására hozták létre 1977-ben. Ebben az időszakban egy R-10 típusú számítógép beszerzését engedélyezték, amelyen kísérletek folytak anyaggazdálkodási, műszaki nyilvántartási programokkal. Természetesen a feladat túl komplex, az R-10 ezeknek a követelményeknek nem felelt meg (pár jellemző adat: 64 kByte RAM, 2X5Mbyte disk, ebből 2X2,5Mbyte cserélhető volt – 4 mágnesszalag olvasó, lyukkártya és lyukszalag író olvasó!!!) A MALÉV a SITA szervezet tagjaként tárgyalásokat kezdett a SITA szakembereivel egy közös fejlesztésű M and E rendszer kidolgozásának tárgyában. A tárgyalások eredményeképpen a Malév és a francia SONOVISION cég szerződést írt alá a SITA közreműködésével 1981-ben a rendszer kifejlesztésére, mely S.A.G.I.L. néven futott. S.A.G.I.L. jelentése: System Aviation Gestionnaire Information Logistique, az angol terminológiában Maintenance and Engineering néven ismert. Lényegében mind kettő a repülőgép berendezések állapot figyelését, karbantartás előkészítését, illetve az ehhez szükséges anyagokkal és alkatrészekkel való eszközgazdálkodást jelent. A SAGIL ezt a tevékenységet támogatta az akkor ismert technológia megoldások úttörőjeként egy on-line informatikai megoldással és fájl kezelő rendszerrel. A 80-as évek elején a SITA úgy döntött, hogy támogatja a szovjet repülőgépek anyaggazdálkodását és műszaki nyilvántartását támogató informatikai rendszer kifejlesztését. Mivel a Malév volt a legnyitottabb és a kérdéskörben legelőrébb haladottabb szocialista légitársaság, ezért a Malév Számítástechnikai Osztályát bízták meg a fejlesztés szakmai irányításával. A fejlesztési projektet a Malév vezette, a rendszer definícióit, követelményeit a Malév informatikai, és műszaki szakemberei határozták meg. A SONOVISION felelt a programrendszer kifejlesztéséért. A rendszer Honeywell 6 számítógépre volt tervezve – ebben az időben ez a kategória is COCOM listán szerepelt – amit csak szigorú ellenőrzés mellett lehetett letelepíteni és üzemeltetni.

A rendszer öt integrált, egymásra épülő modulból állt - ezek leírása az alábbiakban olvasható.

1. CATALOG CONTROL MODUL Célja: A rendszerben a MALÉV által használt cikkféleségek beazonosítása és a rájuk jellemző információk tárolása, megjelenítése. Megjegyzendő, hogy a szovjet típusú repülőgépek műszaki dokumentációi ezeket a jellemzőket nem tartalmazták és a berendezések nem az ATA (Air Transmission Association) rendszerben kerültek leírásra. Az ATA egy repüléssel kapcsolatos nemzetközi szabvány, a repülőgépre felépített Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 28

berendezések egységes rendszerben való sorolására. A Catalog Control Modul precíz kidolgozása a teljes rendszer alapjait határozta meg és a fejlesztés legnehezebb és időigényes feladataihoz tartozott. Funkciói: 1.1 Törzsadatok felvitele - CRE A funkció biztosította, hogy a rendszerben használandó új cikkekhez tartozó törzsadatok rögzítésre kerüljenek a megfelelő képernyőkön szereplő mezők kitöltésével. A törzsadatok szintjén az azonosításra szolgáló kulcs mező a 32 karakter hosszúságú Part Number (P/N) mező volt, mely egyértelműen azonosította a cikkféleséget. Ehhez, mint kiegészítő információ az u.n. Identifier (ID.) volt hozzárendelhető, mely az egyébként azonos cikkek közötti technikai megkülönböztetést tette lehetővé. A kulcs mező(k) kitöltése után a rendszer ellenőrizte, hogy létezik-e ilyen azonosítóval már cikk, s ha még ilyen nem volt (egyedi azonosító), akkor engedte meg a többi attribútum rögzítését pl. 10 jegyű MALÉV cikkszám, megnevezés, mennyiségi egység, stb. A törzsadatok között a kulcs mezőn kívül is voltak kötelezően kitöltendő adatok illetve voltak olyanok, melyek kitöltése opcionális volt. Az egyes mezőkbe a felhasználók által berögzített adatokat a rendszer tárolás előtt mindenképpen ellenőrizte, hogy azok típus (Numerikus, alfanumerikus, dátum) kötelezőség illetve értékkészlet (kitüntetett mezők csak előre meghatározott értéket vehettek fel pl., Unit Of measure : darab; Unit of Measure Code : 12) szempontjából megfelelők-e. Amennyiben valamely mező nem felelt meg az ellenőrzési szempontoknak, a rendszer hibaüzenetet küldött a felhasználó számára, s csak a hiba korrigálása után tárolta el az adott P/N-hez tartozó törzsadatokat. A törzsadatok karbantartásáért egy erre a célra létrehozott szervezeti egység az ún. Identification Section volt felelős, s csak az itt dolgozó felhasználóknak volt a rendszerben beállított jogosultsága a CATALOG CONTROL modulban lévő adatok változtatásához. Lekérdezési jogot természetesen a rendszer bármely felhasználója kaphatott. 1.2 Törzsadatok módosítása - MOD A rendszerben tárolt törzsadatok módosításához először az azonosításra szolgáló kulcs mezőt, a 32 karakter hosszúságú Part Number (P/N) mezőt kellett megadni, mely egyértelműen azonosította a cikkféleséget. Ezután a rendszer megjelenítette a képernyőn a kiválasztott cikkhez tartozó törzsadatokat, melyek ezután már tetszés szerint módosíthatóak voltak. A módosított törzsadatok ellenőrzése itt is a felvitelnél már leírt módón történt típus, kötelezőség illetve értékkészlet szempontjából. 1.3 Törzsadatok lekérdezése – INT A törzsadat megjelenítés megkönnyítésére volt lehetőség ún. „browsing”-ra a P/N részleges megadásával, azaz ha az azonosítónak csak az első néhány karakterét töltötte ki a felhasználó, akkor a rendszer megkereste és megjelenítette az így kezdődő cikkeket felsorolás szerűen sorban egymás után a CATM01 képernyőformátumon, s ezután csak ki kellett választani a konkrét cikket, melynek hatására aztán megjelentek a választott P/N-hez eltárolt különféle törzsadatok. 1.4 Törzsadatok törlése - DEL Azzal a funkcióval lehette azon cikkféleségeket törölni a rendszerből, melyeket a légitársaság a továbbiakban már nem kívánt használni (gyártásuk megszűnt, csereszabatos új termék jelent meg a gyártónál, esetleg adatrögzítési hiba miatt rossz P/N tárolódott a rendszerben, stb.) A törlés előtt ellenőrzésre került, hogy az adott termékre vonatkozóan a készlet nulla illetve nincs nyitott rendelésállomány.


oldal 29

2. PROCUREMENT CONTROL MODUL Célja: A MALÉV által használt repülőgépes és jármű-alkatrészek, műszaki berendezések, álló és fogyóeszközök megrendelésére és azok nyilvántartására szolgált. Funkciói: A MALÉV megfelelő beszállítói felé (repülőgépes alkatrészek és berendezések esetén AVIAEXPORT illetve AVIAZAGRANPOSZTAVKA) a megrendelések (Purchase Order) összeállítása és nyilvántartása. A megrendelések összeállítására két lehetőség volt kialakítva a rendszerben: 2.1 Automatikus (batch) rendelés előkészítés Az akkori gyakorlatnak megfelelően a MALÉV különböző csoportok szerint osztályozta áruféleségeit és ezeket (repülőgép alkatrészek, járműalkatrészek, fogyóanyagok, stb.) különböző „anyaggazdálkodóhoz” rendelte. A gazdálkodók a hozzájuk tartozó cikkcsoport jellemzői alapján (ABC analízis, érték, forgási sebesség, utánpótlási idő, stb.), beállítottak a rendszerben egy jelzőkészlet szintet. Kötegelt feldolgozás volt indítható arra, hogy a program hasonlítsa össze az adott cikkféleség raktárkészletét, nyitott rendelésállományát és a rendeléséhez szükséges küszöbértéket. Ha küszöbérték kisebb vagy egyenlő volt az adott cikk raktárkészletével, akkor a program javaslatot tett a megrendelésére. A nyitott rendelésállomány információkat a program a Procurement Control modulból, az aktuális raktárkészlet adatokat pedig az Inventory Control Modul-ból hívta elő, ahol az áruk pontszám szerint tárolódtak a cikkféleségek állapotának megfelelően a következő besorolással: 1 pontos – Új 2 pontos – Használt 3 pontos – Javítható 4 pontos – Selejt Fenti folyamat végén elkészült a rendszerben egy megrendelés tervezet (Order draft), amelyben jellemzően a megrendelendő összeg a jelzőkészlet szint kétszerese volt. Az Order draft az anyaggazdálkodók által előhívható és módosítható illetve törölhető volt, azaz az automatikusan előállított rendelési adatokat felül lehetett bírálni a felhasználó által. A vonatkozó képernyőn keresztül pl. a megrendelési mennyiség, dátum, stb., felülírható volt. Az így előkészített Order draftokból ezután készítette el a rendszer az ún. végleges megrendelést (Purchase Order-t), melyet az adott beszállító felé már el lehetett küldeni. Az így feladott megrendelések adatai eltárolódtak a rendszerben, s lekérdezhetőek voltak a rendszer más felhasználói számára is. 2.2 Prompt megrendelés képernyőn keresztül A megrendelések (Purchase Order-ek) természetesen a gazdálkodók által bármikor összeállíthatóak voltak a megrendelési képernyők adatainak kitöltésével. Ezek az adatok az automatikus rendelésfeladáshoz hasonlóan később módosíthatóak és lekérdezhetőek voltak.


oldal 30

1. INVENTORY CONTROL MODUL

Célja: A MALÉV által használt repülőgépes és jármű-alkatrészek, műszaki berendezések, álló és fogyóeszközök raktározására és a készletek nyilvántartására szolgált. Funkciói: A modul támogatta a megrendelt áruféleségek beérkeztetését, a raktárakba történő be és kivételezési folyamatokat és a raktárkészletek nyilvántartását. 3.1 Áruátvétel A megrendelt áruk beérkeztetéséért az IDÁRO-ban (Idegenáru Átvételi és Raktározási osztály) az Áruátvételi csoport felelt (Receiving Bay). Ez egyrészt mennyiségi, másrészt minőségi átvételből állt a következő módon: . A rendszer összehasonlította a kiküldött megrendelés adatait (Purchase Order) illetve a Szállító által leszállított termékek adatait, melyet az átvevő a beérkeztető képernyőn (RECM01) rögzített a Szállítólevél (Dispatch Note) alapján. Ezután fizikailag ellenőrizték, hogy a leszállított termék valóban a megrendelt mennyiségben (hiánytalanul) és minőségben érkezett-e be. A megfelelő beérkeztetés hatására a rendszerben aktualizálódott a nyitott rendelésállomány, azaz a beérkezett mennyiséggel csökkentette a rendszer a megrendelt mennyiséget. A beérkezett mennyiséggel csökkentette a rendszer a megrendelt mennyiséget, ami normál esetben így ki is nullázódott, ha nem részszállítástól volt szó. A megrendeléstől eltérően vagy hibásan leszállított tételek a reklamációs raktárba kerültek bevételezésre. 3.2 Be és Visszavételezés A beérkeztetett árukat egy ún. Bevételezési jegy kiállításával lehetett az adott Raktárba fizikailag bevételezni. A bizonylatot az Áruátvételi terület tudta kiállítani, de maga a bizonylat abban a fizikai raktárban került kinyomtatásra Mannesmann Tally típusú nyomtatókon, ahol az adott cikk tárolásra került. (A raktárszám, ”Warehouse Number”, törzsadatként szerepelt a Catalog control modulban. A különböző típusú alkatrészek és berendezések a repülőtér fizikailag más és más pontjain elhelyezett raktárakban kerültek tárolásra pl. a nyilvántartásra kötelezett berendezések raktára a 27-es raktár volt.) Amikor az áru fizikailag is megérkezett a raktárba, akkor a raktáros a bizonylatszám alapján előkereste a rendszerben a bevételezési tranzakciót, majd az átvétel után rögzítette a cikk tárolási helyét és jóváhagyta a tranzakciót a rendszerben. Ennek hatására a bevételezett mennyiséggel azonnal megnövekedett a cikk raktárkészlete, a bizonylat egyes példányai pedig az átadónál és az átvevőnél maradtak illetve kerültek további felhasználásra a számviteli terület által. Fenti folyamatot kellett alkalmazni abban az esetben is, ha nem új cikkféleséget vételezett be a raktár, hanem valamely már használt, javítandó vagy leselejtezett áru került leadásra a raktárakba. 3.3 Kivételezés


oldal 31

A folyamat megkezdéseként a SAGIL rendszer felhasználóinak lehetőségük volt az általuk kivenni szándékozott cikk raktárkészlet szintjének képernyőn keresztüli lekérdezésére. Így ellenőrizhették, hogy az adott cikkféleségből van-e raktáron, vagy pedig intézkedniük kell-e a beszerzési terület felé, mert pl. azonnali beszerzés (AOG – Aircraft On Ground) vált szükségessé. A készletadatok megjelenítésének megkönnyítésére itt is volt lehetőség ún. „browsing”-ra a P/N részleges megadásával, azaz ha az azonosítónak csak az első néhány karakterét töltötte ki a felhasználó, akkor a rendszer megkereste és megjelenítette az így kezdődő cikkeket felsorolás szerűen sorban egymás után a képernyő formátumon, s ezután csak ki kellett választani a konkrét cikket, melynek hatására aztán megjelentek a választott P/N-hez eltárolt inventory adatok.

A raktárból kivételezendő árukat egy ún. Kivételezési jegy kiállításával lehetett az adott raktárból kivenni. A bizonylatot az a felhasználó állította ki a rendszerben, akinek az adott cikkre szüksége volt, de a kivét folyamatban volt még egy szereplő, az „utalványozó”, aki jogosult volt a kezdeményezett tranzakciót elutasítani vagy jóváhagyni. Csak az utalványozó által jóváhagyott tételek kerültek kinyomtatásra a vonatkozó raktárban, ahol a folyamat a bevételezéshez hasonlóan zajlott, csak ellenkező előjellel. Amikor az átvevő megérkezett a raktárba, akkor a raktáros a bizonylatszám alapján előkereste a rendszerben a kivételezési tranzakciót, majd az áru átadása után rögzítette a jóváhagyta a tranzakciót a rendszerben. Ennek hatására azonnal a kiadott mennyiséggel a rendszer csökkentette a kiadott cikk raktárkészletét.

A rendszer különböző harántfekvésű listák elkészítésével támogatta a fenti folyamatokhoz kapcsolódó egyéb készletgazdálkodási tevékenységeket is, mint például leltározás, selejtezés.

4. ROTABLES CONTROL – MŰSZAKI NYILVÁNTARTÁS

A repülőgépgyártók és a légügyi hatóság a repülésbiztonság folyamatos, megfelelő szintű fenntartása érdekében előírja, hogy a repülőgépeken üzemelő, meghatározott típusú berendezések üzemadatait figyelni, könyvelni és kell általában berendezés típusonként és egy meghatározott korlát elérése esetén ellenőrizni kell őket még akkor is, ha működésükre nem volt panasz. Az ellenőrzés lehetett szemrevételezés, műszeres ellenőrzés a repülőgép fedélzetén vagy a berendezés leépítése és laboratóriumban történő alapos átvizsgálása, esetlegesen kritikus alkatrészek cseréje – az ellenőrzés típusa különböző korlátok elérése esetén eltérhetett egymástól. Megjegyzendő, hogy a repülőgépre felépített berendezések üzemszerű működésének figyelésére általában két módszer használatos. a nyugati gépeken az állapot szerinti figyelést alkalmazzák – a fedélzeti számítógép folyamatosan gyűjti az adatokat – és ha a paraméterek a megengedett korlátok között marad, a berendezés üzemelhet. A szovjet Tupoljev gépeken a berendezések szigorú időkorlátok között üzemelhettek.

A valóság természetesen ennél bonyolultabb volt, alapvetően két ok miatt: Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 32

-

-

a repülőgépeken lévő ilyen berendezések számossága miatt (a Malév gépeken gépenként 10001200 volt), amelyhez hozzájárult, hogy a raktáron tárolt berendezéseket is bizonyos szempontok miatt nyilván kellett tartani - a Malév 30 000-40 000 ilyen berendezést tartott raktáron. az üzemadat csak egy általánosító, nyilván nem tartható adat volt, helyette nyilván kellett tartani (természetesen tudva, hogy melyik berendezés típusnál mit) az alábbiakat: - repült idő – a felszállás és a leszállás között eltelt idő - üzemidő – bizonyos berendezések nem működtek a teljes repülés idő alatt, ezeknél csak a tényleges üzemidőt kellett nyilvántartani. (pl. az indítóturbina a repülőgép felszállása előtti és leszállása utáni időszakban biztosította az energia ellátást, amely a repülés közben a hajtóművekre szerelt generátorok feladata volt, így működésére a repülés közben nem volt szükség, ugyancsak le kellett könyvelni a földi hajtóműpróbák során a hajtóművek és az indítóturbina ledolgozott üzemidejét - indításszám – a hajtóműveknél és az indítóturbinánál kellet figyelni, mert befolyásoltak az üzemképességüket - leszállásszám – az orr- és a fő-futóművek esetében ez az adat volt a meghatározó

Ennek feladatnak a precíz manuális nyilvántartása már a Malév esetében is gyakorlatilag megoldhatatlan feladat volt az ezzel foglalkozó részleg számára (műszaki nyilvántartás). Jelentős volt a repülésbiztonságot kockáztató hiba, tévesztés. Ezt a problémát oldotta meg a SAGIL rotables control modulja.

Funkciói:

4.1 A berendezés nyilvántartásban vétele/nyilvántartásból való törlése

Amikor a Malév tulajdonába/használatába került egy nyilvántartásra kötelezett berendezés, akkor értelemszerűen az első feladat a berendezés adatainak rendszerbe történő felvitele volt. A catalog control fejezetben bemutatott part number és identifier adatokhoz hozzáillesztették a berendezés egyedi azonosítására szolgáló gyári számot (serial number – S/N). Szükség esetén további adatok is felvitelre kerülhettek (pl. használt berendezés esetén az addigi üzemadatai). Értelemszerűen amikor a berendezés kikerült a Malév tulajdonából vagy selejtezésre került, akkor a berendezést az adataival együtt törölték a rendszerből.

4.2 A berendezések nyomon követése

A berendezések a Malévnál történt nyilvántartásba vétele/nyilvántartásból való törlése közötti időszakban számos többnyire ismétlődő helyszínen voltak megtalálhatók.

Alapesetben a mozgásuk az alábbiak szerint írható le: -

bevételezés a raktárba – a megrendelt berendezéseket raktárra vételezték, természetesen ekkor történt meg a nyilvántartásba vételük felépítés repülőgépre – ettől kezdve kell az üzemadatait könyvelni


oldal 33

-

leépítés a repülőgépről – a berendezés alapesetben közvetlenül, speciális körülmények esetén a raktáron keresztül javításra/ellenőrzésre a laboratóriumba került kiadás a laboratóriumból – két alapeset volt. Ha a repülőgép hosszabb ideig karbantartáson állt, amely alatt a berendezés ellenőrzését el tudták végezni, akkor a berendezést a raktár megkerülése nélkül közvetlenül a műszaknak adták vissza, hogy építse fel újra a repülőgépre. Más esetekben a berendezést leadták a raktárba és egy későbbi időszakban került felépítésre.

Természetesen a berendezés életciklusa során a felépítés – kiadás kört nagyon sokszor megtette. Az adott helyszíneken kinevezett felelősök feladata volt a berendezés mozgásának rögzítése a rendszerben.

4.3 A berendezések üzemadatainak naprakész nyilvántartása

Informatikai szempontból le kellett jelenti az adott járat/hajtóműpróba alatt teljesített üzemadatokat, azokat le kellett rögzíteni, és megoldani, hogy a rendszer automatikusan rákönyvelje azokat a repülőgépre és a felépített berendezésekre (természetesen figyelembe véve, hogy az adott berendezésen milyen adatokat kell nyilvántartani). Rendszerszervezési szempontból kihívás volt olyan bizonylatok elkészítése, elfogadtatása, bevezetése és a legalább formailag megfelelő kitöltés számonkérése, amelyek ezeknek megfeleltek. Két ilyen bizonylat létezett. A hajózó személyzeti jelentés, amely a repülés közbeni adatokat tartalmazta (kitöltésének pontosságát elősegítette az, hogy szerepeltek rajta a repülési feladatot végrehajtó személyek nevei, megteremtve az alapját egy viszonylag precíz számítógépes hajózó nyilvántartásnak és tervezésnek, amely a hajózó személyzet érdeke is volt. A másik bizonylat lényegesen egyszerűbb volt, földi hajtóműpróbák esetén kellett rögzíteni a hajtóművek és az indítóturbina üzemadatait. Összefoglalva: a hajózó jelentés és a hajtómű próba jelentés adatait használva a rendszer az adott lajstromjelű repülőgépre felépített összes berendezésre rákönyvelte az üzemadatokat, így minden felépített berendezésen az aktuális üzemadat volt nyilvántartva. 4.4 Repülőgépek időszakos karbantartásainak előkészítése

A repülésbiztonság érdekében a repülőgépeken adott repült idő elérése időszakos karbantartást kellett végrehajtani. A Malév gyakorlatában ez 75, 300, 900, 1880 óra repült idő után kellett elvégezni – értelemszerűen a két 300 órás karbantartás között sem maradhattak el a 75 órás karbantartások, és így tovább. A karbantartások során olyan elemeket kellett ellenőrizni, amelyek komolyan befolyásolták a repülésbiztonságot – természetesen minél magasabb volt az óraszám, annál alaposabban (pl. futópályán felpattanó kő, madár okozott-e veszélyhelyzetet jelenthető sérülést a repülőgép törzsén, az üzemanyag és az energia vezetékek állapota kifogástalan-e, a repülőgépek törzsére felszerelt antennákat rögzítő csavarok nem lazultak-e meg, stb.) Az időszakos karbantartás végrehajtási ideje 10-12 óra (75 órásnál) és 2-3 hét (1800 óra) között volt.

A korábbi fejezetben említett nyilvántartásra kötelezett berendezéseknél előírt ellenőrzések elvégzésére elméletileg két időpont lehetséges. Első gondolatra logikusnak tűnik, hogy a berendezést az üzemadat korlátig kell üzemeltetni, és akkor kell az előírt ellenőrzést végrehajtani, amikor már bizonyos, hogy a következő járat során ezt a korlátot túllépni. A gyakorlatban ez értelmetlen, mert azzal jár, hogy a repülőgépet akár órákra is ki kellene vonni a forgalomból, amely jelentős bevételtől fosztaná meg a


oldal 34

légitársaságot. A gyakorlati megoldás az, hogy ezeket a feladatokat a repülőgép időszakos karbantartása alatt kell végrehajtani.

A repülőgépek időszakos karbantartásainak előkészítését végző program végtelenül egyszerű volt, de jelentős munkát takarított meg és csökkentette a hibalehetőséget. Az időszakos karbantartást megelőzően ellenőrizte és kilistázta azokat a berendezéseket, amelyek a következő karbantartásig minden bizonnyal túllépik az üzemadat korlátjukat (repült idő esetében ez az adat egyértelmű volt, a többi üzemadat esetében pedig már rövid üzemeltetési tapasztalattal is igen nagy pontossággal lehetett megbecsülni a várható értékeket). Így biztosítva volt, hogy két karbantartás között csak a tényleges meghibásodások elhárításával kapcsolatos berendezés ellenőrzéseket, cseréket kelljen elvégezni.

5. SYSTEM CONTROL MODUL

Hardware: Honeywell Level 6 16 bites processor – sornyomtató – mágnesszalag egység(2db) – diszk egységek: 80Mb winchester 5db/gép+2X10 MB cserélhető kazetta – 2db 8 inch floppy lemez – vezérlő konzol – 20 db westinghouse felhasználói terminal a repülőtéri lokális hálózaton Operációs rendszer: GCOS 6 MOD 400 –

–

Rendszerparaméterek, o

Rendszerdátum

o

Képernyőterminálok címei

o

Nyomtatók fizikai címei

Felhasználók és jogosultságaik o

Menu id

o

User Id

o

Képernyőformátumokhoz és listákhoz beállítható funkciók és az ezekhez tartozó jogosultságok

LOG tape Az egyes tranzakciók lezárása után a rendszer az egyes táblákban bekövetkezett változások eredményeit (after image) mágnesszalagra rögzítette . Felhasználásával az utolsó mentett állapot visszatöltése után a LOG TAPE –en tárolt adatokból az időközben bevitt tranzakciók visszanyerhetőek voltak anélkül, hogy azokat a tranzakciókat a felhasználók újra bevitték volna. (Journal entry)


oldal 35

A rendszer bevezetéssel járó előnyök:

–

A rendszer bevezetésével a légitársaság adatai egy helyen kerültek tárolásra, melyeket a felhasználók egységesen érhettek el. Az egy helyen tárolt információt az egész rendszer felhasználta, ezzel lehetővé téve a MALÉV különböző területeken dolgozó munkatársak munkájának összehangolását. A felhasználói terminálok a Ferihegyi repülőtéren lokális hálózathoz csatlakoztatva kerültek telepítésre (hangár, labor, hajózószervezet, műszaki ellenőrzés, anyaggazdálkodás, raktárak

–

A rendszer kialakítása során átgondolt folyamatok egységesítésével és automatizálásával áttekinthetőbbé vált az egymáshoz kapcsolódó területek működése

–

A SAGIL rendszerben pontos naprakész információk álltak a felhasználók (dolgozók illetve management) rendelkezésére

–

Az integráltság révén az adatokat csak egyszer kellett rögzíteni a rendszerben, csökkentve ezzel az ismételt adatbevitel igényét, valamint az ezzel járó hibalehetőséget.

–

A rendszerben beépített ellenőrzési funkciók biztosították a hiba lehetőségek kizárását. Az egyes felhasználói terminálok jogosultsága, valamint felhasználói hozzáférések System Control Modulban való meghatározása maximálisan kiszolgálta a repülésbiztonsági követelményeket

–

A terminálok funkcionális kezelése felhasználó barát módon lett kialakítva.

–

Érdekesség: A felhasználok kiképzésével kapcsolatban szokatlan döntést hozott a fejlesztői team. Mivel a programrendszer angol nyelven került kifejlesztésre, felmerült a kérdés, hogy le kellene fordítani magyarra, vagy maradjon az eredeti nyelven. A fordítási próbálkozások nehézégbe ütköztek – az angol terminológiának megfelelő értelmes magyar szót több estben nem sikerült meghatározni. A döntés az angol nyelvű képernyőket hagyta jóvá. A tapasztalat meglepő volt – a felhasználok igen rövid idő alatt megtanulták és elsajátították azokat a terminológiákat, amelyeket használniuk kellett (megjegyezzük, hogy igen kevesen tudtak angolul a szolgálatoknál)


oldal 36

–


oldal 37

OPERATÍV IRÁNYÍTÁSI ÉS HAJÓZÓ RENDSZEREK A MALÉV-NÉL, FLIGHT PLANNING, CREW MANAGEMENT, OPERATIONS CONTROL A hajózó személyzetek tevékenységét szervező és támogató rendszerek teljesen ismeretlenek az utazó közönség számára, de jelentőségük és a repülés biztonságára való kihatásuk óriási. E területen kizárólag jó nevű nagy nemzetközi szállítók szolgáltatásai jöhetnek szóban akik rendszereit országonként felügyelő hatósági szinten kell ellenőrizni és engedélyezni.

FLIGHT PLANNING Az automatizálás igen korai fázisában már 1982-ben megtörtént a SITA Londoni Számítóközpont IBM mainframe osztott/ASP alapon működő Flight Planning Navigációs Útvonaltervező applikációjának sikeresen üzembe helyezése, amely a repülőgépek tervezett és aktuálisan teljesítendő útvonalait kalkulálja, optimalizálja az üzemanyag fogyasztást és teljes körű felkészítést ad a hajózó személyzeteknek a meteorológiai viszonyokról és a várható akadályokról. Ezen alkalmazások lelke az a hatalmas adatbázis, amelyet a szolgáltató állít össze és tart karban a légifolyosókról, repülőterekről, szabályokról stb. Az alkalmazás több olyan modellt futtat, amelyek manuálisan elképzelhetetlenek. Informatika történeti különlegesség, hogy a szolgáltatónál ezt a rendszert olyan kettős végzettségű szakemberek fejleszthetik és üzemeltetik, akiknek egyszerre van felsőfokú informatikai és navigációs szakképzettsége és igazolt gyakorlata. A Flight Planning rendszernek stratégiai szerepe volt a MALÉV hosszú távú járatainak beindításában és a 2 hajtóműves óceánrepülés megalapozásában 1992-től kezdődően. A későbbiekben ezeket a rendszereket kiválóan integrálták a repülőgép fedélzeti komputerekkel és a személyzet mobil eszközeivel.

Berényi Gábor Ágota, a légitársasági és repülőtéri rendszerek nemzetközi informatikai szakértője, a MALÉV, a Budapest Airport és egy kiszolgáló cég informatikai szolgálatainak vezetője, aki a SITÁ-nál is dolgozott, az alábbiakban jellemzi a Flight Planning rendszert:

FLIGHT PLANNING (REPÜLÉSI ÚTVONAL, NAVIGÁCIÓS TERVEZŐ) RENDSZER A repülési tervek elkészítése a navigációs szolgálat feladata volt a MALÉV esetében és az ő feladataikat segítette az a számítógépes szoftver, amit Flight Planning névvel szoktak illetni. Gyakorlatilag két nagy cég ajánlott ilyen szolgáltatást: a SITA vagy a Jeppesen cégek rendszereit használta a legtöbb légitársaság. A MALÉV a SITA Flight Planning rendszerét választotta, vezette be és használta először. A rendszer feladata, hogy minden járatra elkészítse az útvonaltervet. Egy általánosságban a tervezett géptípusra, a statisztikai időjárás adatokat figyelembe vevő terv kellett, hogy készüljön a menetrendi időszakban közlekedő minden járatra (stored flight plan), amely által kiszámított repülési idő adatokat a menetrend tervezésénél is figyelembe kellett venni. Az tárgynapon azonban már a tényleges egyedi repülőgépre, azaz lajstromjelre vonatkozó műszaki adatokat, az aktuális időjárásra vonatkozó meteorológiai előrejelzéseket; valamint a légtér Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 38

használatát szabályozó előírásokat figyelembe véve készítette el a rendszer az útvonaltervet. Ezt még a járat indulása előtt aktualizálnia kellett az utaslétszám és az áru terhelés adataival. Ez az útvonalterv tartalmazta az időjárás adatok mellett a járatok teljesítéséhez szükséges üzemanyag mennyiséget, a kitérő repülőterek adatait és a végrehajtandó repülési feladatot. Információt szolgáltatott a célállomásra vagy az útvonalra kiadott korlátozásokról is. Ezeknek a számításoknak el kellett készülniük addig az időpontig, amikor a személyzet a járatra való felkészülés részeként megkapta az adatokat. Bár a számítógép automatikusan készítette el a szükséges számításokat és a navigációs tiszt ellenőrizte azt, de a végső jóváhagyás a kapitányt illette, aki a járatra való felkészülés során ellenőrizte a rendszer által előállított flight plan-t és ha szükségesnek látta, kérhetett módosításokat. Itt is sokszor felmerült a rendszerek közötti integráció hiánya, hiszen a repülési terv elkészítéséhez szükséges minden aktuális adat rendelkezésre állt, csak éppen különböző számítógépes rendszerekben. Hiszen az utaslétszám adatokat pontosan tartalmazta a DCS rendszer, a várható áruterhelési adatokat a CARGO rendszer; de ezek között a rendszerek között nem volt közvetlen kapcsolat, tehát ismét a „humán interfész” megoldást kellett alkalmazni. A célállomástól függően el lehetett készíteni a visszaútra vonatkozó útvonal tervét is. Új feladatot állított a navigációs szolgálat elé, amikor a MALÉV elindította a hosszú távú járatait New York-ba. Először még Rómán keresztül, azaz római leszállással teljesítették a járatot, később azonban már közvetlen Budapest-New York járatot repültek. Ezeknek a járatoknak a tervezése annyiban különbözött az addigiaktól, hogy az óceán feletti repülésnek a sajátos szabályait is be kellett tartani. Ez azt jelentette, hogy az óceán két partja között minden nap aktuálisan jelöltek ki repülési útvonalakat az időjárás, szélerősség és egyéb paraméterek függvényében mindkét irányban. Ezen túlmenően az így kiadott útvonalak közül csak azokat lehetett használni, amelyek az adott légitársaság besorolásának megfeleltek. Ez azt jelentette, hogy amikor a MALÉV, mint új légitársaság jelent meg ezen az útvonalon; úgy kellett megtervezni az óceán feletti repülés útvonalát, hogy „120 percnél hosszabb távolságra” nem távolodhatott el a kitérő repülőtértől. Ez a „120 perc távolság” azt jelentette, hogy ennyi idő alatt el kellett érnie bármely kitérő repülőteret meghibásodás (pl.:1 hajtómű leállása, vagy a kabinnyomás változása) esetén is. Ez az idő a későbbiekben módosításra került, és 90 percre csökkent, mivel repülő esemény nélkül teljesültek a járatok. Ez a tervezés új volt a MALÉV navigáció számára és eleinte nagy nehézségeket és igen hosszadalmas munkát igényelt egy-egy járatra való felkészülés előtt időben előállítani megfelelő szinten a repülési tervet. Nem kisebb problémát jelentett a visszaútra vonatkozó fligth plan elkészítése és a személyzethez való kijuttatása sem. Mivel az első periódusban nem volt szerződés a célrepülőtéren ilyen szolgáltatásra, így a budapesti navigáció készítette el a visszaútra vonatkozó tervezést és egyéb kommunikációs lehetőség birtokában annak a szállodának a fax készülékére küldtük ki a visszaúti flight plan-t, amit a személyzet használt, hogy a repülőtérre való indulás előtt megkaphassák az adatokat. Hosszú távú repüléseknél nem volt elég csak a célállomásra való megérkezésről információt kapni, hanem fontos volt figyelemmel kísérni, hogy a repülés közben a tervezett és valós adatok eltérnek-e egymástól. Itt két fontos adatot kellett közölni: az üzemanyag mennyiségét és a repülőgép pozícióját az adott pillanatban. Ennek az információnak a bázis repülőtérre való juttatása sem volt egyszerű feladat. Létezett olyan felszereltsége a repülőgépeknek (ACARS rendszer), amely automatikusan generálta ezeket az adatokat a paraméterként beállított időintervallumokban és előre megadott Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 39

címekre automatikusan el is küldte, de a MALÉV által használt repülőgépek nem voltak ilyen berendezéssel felszerelve. Így a személyzet feladata volt (időnként csak lett volna) ezeket az adatokat egy más- verbális - kommunikációs csatornán egy közbülső szervezethez eljuttatni, ahonnan a MALÉV már szabvány üzenetben kapta meg az adatokat. Ez nagyon nehézkes folyamat volt és időnként nem is működött. Ezért nem volt sajnos nagyon használható az a program, amely grafikusan jelenítette meg a repülési útvonalat, az időjárás adatokat; mert ezt aktualizálták volna az u.n. „position report”-ok, és vizuálisan is követni lehetett volna a tervtől való eltérést a feladat végrehajtása során. Nem szorosan ehhez a történethez tartozik, de érdemes megemlíteni, hogy ezeket a szükséges berendezéseket a későbbiekben a légitársaság nem építette be repülőgépekbe, mert nem voltak olyan repülőgép szerelőik, akik ki lettek voltak erre képezve. Így a berendezések addig raktárban voltak, amíg a szükséges képzések meg nem történtek, addigra azonban a berendezéseknek járt le a „szavatossági” ideje. Legjobb tudásom szerint ez a probléma nem oldódott meg az alatt az idő alatt, amíg folytatódtak a hosszú távú repülések A későbbiekben a MALÉV a SITA Flight Planning rendszerét lecserélte a Jeppesen rendszerére.

CREW MANAGEMENT A repülési informatika közismerten legkényesebb területe a hajózó személyzetek szolgálatra való beosztásának automatizálása. A matematikai modellek is bonyolultak, de a legnehezebb a munkaés pihenőidő szabályok algoritmizálása, tehát a gépesíthető környezet megteremtése és ennek elfogadtatása a hajózókkal és érdekképviseleti szerveikkel. A MALÉV ezt a feladatot másodszori nekifutásra teljesítette (=ez nemzetközi összehasonlításban is jó eredmény) és 1992-ben a SITA ASP ernyője alatt üzemeltett SBS Crew Management rendszert bevezette (SITA Londoni Számítóközpont IBM mainframe), először a havi tervezés majd a napi forgalom irányításában is. a Pilóták, légi utaskísérők – és nem utolsósorban szakszervezeteik – példás módon gyorsan és együttműködően adaptálták az új rendszer logikáját és előnyeit. A repülési informatika matematika modell alkalmazásának gyöngyszemei a hajózó személyzetvezénylési rendszerek, amelyek alapvetően 2 algoritmus szerint képesek a beosztás optimalizálására. Ezek végeredménye drasztikusan eltér a manuális gyakorlatban tapasztaltaktól, hiszen az emberi aggyal készített korábbi beosztási munkafolyamat sokkal több korláttal rendelkezett és gyakorlatilag előre kigondolt beosztási kliséken és rutinokon alapult. A rendszer először a szabályoknak megfelelő szolgálati szegmenseket hoz létre ún. pairingeket, amely tulajdonképpen egy vagy több repülési feladatnak és pihenőidőnek (vagy más feladatnak, pl. hajózó települése más állomásra a) az optimálisan teljesíthető kombinációja. Majd ezen alapul a havi „műsor” készítése és a következő fázisban a napi diszpécser vezénylés. A tervek készítésénél 2 modell ismert: az egyik a selective bidding, azaz a rendszer havi terveket készít név nélkül és a hajózók szenioritási lista szerint (tehát először az öregebbek) választanak egy komplett havi programot. A később sorra kerülőknek tehát egyre csökkenő lehetőségei vannak. A másik modell az assigned lines, amelyben a légitársaság (azaz a rendszer) nevesített havi terveket készít, amelyhez azonban bizonyos hajózó kéréseket és szempontokat kisebb mértékben figyelembe tud venni. Rendkívül fontos minden esetben, hogy a hajózó személyzet havi és éves leterheltsége repült órában és a feladat komplexitásában arányos legyen és köztudott, hogy vannak „jó „ és „kevésbé jó” utak. Másrészt a rendszer szigorúan ellenőrzi a hajózó jogosultságát, Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 40

alkalmasságát a feladat teljesítésére és ma már tervezi az oktatásokat, más földi szolgálatokat. A mai rendszereknél a személyzet – bárhol is legyen - web-es felületen képes kommunikálni a rendszerrel.

Berényi Gábor Ágota, a légitársasági és repülőtéri rendszerek nemzetközi informatikai szakértője, a MALÉV, a Budapest Airport és egy kiszolgáló cég informatikai szolgálatainak vezetője, aki a SITÁ-nál is dolgozott, az alábbiakban írja le tapasztalatait a MALÉV-nél:

SZEMÉLYZETVEZÉNYLÉSI RENDSZER - CREW MANAGEMENT A hajózó személyzet és a légiutaskisérők beosztásának elkészítése egy bizonyos méret és bonyolultság felett már automatizálás után kiáltott. A MALÉV az elvégzett piackutatás után az SBS rendszerét választotta. Az adatbázisok felállítása volt az alapfeltétele a rendszer bevezetésének. A menetrend bevitelével kapcsolatban nem volt kérdés, hiszen a járatokhoz kapcsolódó menetrendi adatok minden légitársaság esetében ugyanazok. A MALÉV flotta adatainak a bevitele sem okozott tartalmilag nehézséget. A kivitelezésben az okozta a problémát, vagy időt és fáradtságot, hogy ezeket az adatokat olyan formában kellett bevinni a rendszerbe, mintha lyukkártyán lennének az adatok. A személyzet adatainak megfelelő paraméterezése is megoldható volt a rendszerben. A legproblémásabb feladat a munkajogi szabályok bevitele volt. A munkatörvénykönyve és a kollektív szerződések alapján kellett az adatállományt felépíteni, ami még az SBS cég szakértőinek a segítségével sem volt egyszerű, hiszen számukra néhány teljesítendő feltétel nehezen volt érthető. (mint például a devizában és rubelben kapott napidíjakra vonatkozó megegyezés) Természetesen különböző szabályok vonatkoztak a hajózó személyzetre (cockpit crew) és a légiutaskisérőkre (cabin crew). Ezek a szabályok időről időre változtak a vállalat vezetése és a személyzetek közötti megállapodásoknak megfelelően. Néha nehéz volt paraméterezni bizonyos szabályokat, mert esetleg azok ellentmondtak egymásnak. A tervezés külön készült a cockpit és a cabin crew-ra, hiszen különböző paramétereket kellett figyelembe venni a tervezésnél, és más munkaügyi szabályok vonatkoztak rájuk. A rendszer elsősorban olyan járatsorokat állított össze, amely járatok ugyanazzal a személyzettel végrehajthatóak. Az így összeállított járatokhoz keresett a rendszer olyan személyzetet, amelyek megfelelnek a feltételeknek. Ennek alapján született meg a havi beosztás, amelyet szintén szakszervezeti megegyezés alapján az előző hónap megállapodott napjáig kellett elkészíteni és a személyzetek tudomására kellett hozni. A napi feladatok végrehajtását követő modul 3 évvel később került bevezetésre. 1999-ben a MALÉV a SITA SBS rendszerről átállt a Lufthansa Systems Netline Crew rendszerére, amely gyakorlatilag hasonló elveken alapult, de kliens szerver üzemmódban működött.


oldal 41

LÉGITÁRSASÁGI ÜZEMIRÁNYÍTÁS, OPERATIONS CONTROL, SCHEDULING A légitársasági üzemirányítás Operations Control automatizálása 1987-ben valósult meg, az eredetileg a SAS Scandinavian Airlines által kifejleszett, később a SITA által osztott IBM alapú szolgáltatásként felajánlott OPERA/TOSCA nevű szolgáltatások bevezetésével – ismét, a MALÉV világelsőként jeleskedett. A rendszer a menetrendi és üzemi rányitási folyamatokat automatizálta nemzetközi szabványok szerint. A néhány évvel korábban kialakított Operations Control filozófia és szervezet kedvező bázis ajánlott a rendszer problémamentes bevezetéséhez és üzemeltetéséhez. A későbbiek során a MALÉV az Operations Control területen – 1999-tól kezdődően - a Lufthansa Systems rendszerház szolgáltatásait használta (helyileg is telepített kliens szerver üzemmódban ) – Netline Schedule, Operations és Crew modulokat.

Berényi Gábor Ágota, a légitársasági és repülőtéri rendszerek nemzetközi informatikai szakértője, a MALÉV, a Budapest Airport és egy kiszolgáló cég informatikai szolgálatainak vezetője, aki a SITÁ-nál is dolgozott, az alábbiakban foglalja össze az Operations Control automatizálásának történetét:

LÉGITÁRSASÁGI ÜZEMIRÁNYÍTÁSI (OPERATIONS CONTROL) RENDSZER A Malévnél a napi működés tervezése és az adott napon a végrehajtás ellenőrzése egy nagy kirakós táblán történt. Ezen három nap forgalma volt látható egyszerre, ahol a függőleges tengelyen lajstromjelenként; a vízszintes tengelyen pedig az idő függvényében lehetett látni az egyes repülőgépek által teljesítendő, illetve teljesített járatokat. Az aktuális időt folyamatosan mutatta a tábla, tehát nemcsak hogy vizuálisan követhető volt a napi forgalom alakulása, hanem a változásokból (pl. késések) eredő konfliktushelyzet is látható volt. Ez a lényegében statikus ábrázolás minden nap éjfélkor „aktualizálódott”, ami azt jelentette, hogy az ügyeletes szolgálatban lévő diszpécser a már teljesített járatokat levette a tábláról és egy újabb nap forgalma került fel helyette. Ez a „LEGO játék” lehetővé tette, hogy az operatív irányítási szervezet folyamatában láthassa a légitársaság flottájának várható és már teljesített repülési feladatait. Ennek a feladatnak a megoldására került bevezetésre - sok minden egyéb plusz szolgáltatás mellett az Operation Control rendszer, amely egy lokálisan üzemeltetett SITA által kifejlesztett rendszer volt. Későbbiekben az ugyanezen funkciót ellátó Lufthansa Systems nevű szoftver cég termékére, a Netline rendszerre cserélték az addig használt szoftert. A MALÉV operatív irányítását ellátó szervezet (alakulásakor OIRO – Operatív Irányítási és Rendszerellenőrző osztály; majd később OCC – Operations Control Center) volt ennek a rendszernek a felhasználója, az ő munkaeszközük lett a későbbiekben ez a rendszer, amely a napi munkát és a rövid, valamint a hosszú távú tervezést is segítette.


oldal 42

A rendszer alapvető feladata az volt, hogy az adott menetrendből és a flottában lévő repülőgépek rendelkezésre állásából kiindulva megtervezze, hogy a hét napjain a repülési feladatok hogyan hajthatóak végre és hol merülhetnek fel problémák. Ezen a szinten olyan konfliktus helyzetek adódhattak például, hogy a tervezett géptípusból nem állt rendelkezésre megfelelő számú repülőgép; valamely gép javításával nem készültek el a tervezett időre, stb. Itt még nem „nevesített” a rendszer, tehát nem határozta meg, hogy konkrétan mely repülővel (lajstromjellel) kell teljesíteni az egyes járatokat, csak a szükséges kapacitások rendelkezésre állását vizsgálta. Fontos határnap volt a -3. nap, azaz az adott járat dátuma előtt 3 nappal a rendszer automatikusan meghatározta és hozzárendelte azt a repülőgépet/lajstromjelet, amellyel a járatot teljesíteni kell. Mindkét tervezési időszakban meg kellett határozni, hogy mely algoritmus használatával tervezze meg a forgalmat (készítse el a repülőgépek rotációját) a rendszer. Lehetséges volt a FIFO (First In First Out) illetve a LIFO (Last In First Out) módszert használni, attól függően, hogy melyik segítette jobban az adott időszakban a légitársaság stratégiáját. A FIFO rendszer alkalmazása esetén a legelőszőr megérkezett repülőgépet fogja beosztani a következő járatra; a LIFO használatával pedig a legkésőbben érkezett járat fogja a soron következő feladatot teljesíteni. Ily módon már lajstromjelre bontva készült el a három napos terv, amelynek a teljesítését a tárgynapon szintén a rendszer funkcióit használva lehetett ellenőrizni. Az aktuális napon a feladatok végrehajtása a repülőgépek mozgásának adatait tartalmazó üzenetek (MVT –movement üzenetek) automatikus feldolgozásának felhasználásával volt követhető. Ezek az adatok grafikusan is megjelentek az OCC-ben dolgozó diszpécserek munkaállomásain, ahol a várható konfliktus helyzeteket is előre jelezte a rendszer. (Például, ha egy járat késése esetén a következő járatot már látható volt, hogy nem tudja a repülőgép teljesíteni.) Így időben lehetett intézkedni a probléma megoldásáról. Nagyon lényeges feladat volt minden járatot teljesítő repülőgép folyamatos nyomon követése. Ez azt jelentette, hogy miután a MALÉV járat felszállt a budapesti repülőtérről a rendszer megkapta a Ferihegyen üzemelő FIDS (Flight Information Display System) rendszerből a IATA szabvány szerint automatikusan generált induló MVT üzenetből nem csak azt a tényt, hogy a repülőgép felszállt, hanem a pontos elgurulási időt és a földtől való elemelkedés idejét, valamint a repülőgépen utazók létszámát is. Ugyanezen járatra vonatkozó következő információ egy úgynevezett érkező MVT üzenet volt, amit a célállomás megfelelő rendszere generált és amely tartalmazta a földet érés és az állóhelyre való Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 43

beállás időadatait. Ez az információ fontos volt, hogy a budapesti napi operatív működést figyelemmel kísérő OCC a rendszeren keresztül követni tudja, hogy a tervezetthez képest van-e eltérés a menetrendtől. Ugyanilyen fontos volt a rendszernek megkapni a járatnak a célállomásról való visszaindulására vonatkozó adatait is, amelyet ismét az érintett repülőtérnek kellett elküldenie a budapesti repülőtéren üzemelő Ops Control rendszernek. Többállomásos járat esetén ugyanígy kapta meg a rendszer az adatokat a közbülső állomás(ok)ról is. Ezeknek az információknak a segítségével egyrészt folyamatosan lehetett tudni, hogy a légitársaság flottájához tartozó repülőgépek éppen hol tartózkodnak és milyen repülési feladatot hajtanak végre; másrészt a repülőgépek műszaki adataihoz tartozó le- és felszállásszám, valamint repülési üzemidő adatokat is nyilván lehetett tartani. Ezen a ponton egy örök vita alakult ki a repülőgép személyzete és a kiszolgáló szervezetek között, hiszen a pilótáknak is meg kellett adniuk ugyanezen adatokat a repülőgép fel- és leszállására és a repülési időre vonatkozóan és ez a két adatállomány mutatott eltéréseket időnként. A rendszer lehetőséget adott a menetrend szerkesztési funkciók támogatására is. Az előzetes tervezés során vizsgálta a rendelkezésre álló kapacitások függvényében a tervezett járatok végrehajthatóságát és várható konfliktushelyzet esetén felhívta azokra a figyelmet. Ennek a rendszernek a használata során is elég élesen felmerült a Malévnél egymástól függetlenül működő informatikai rendszerek integrációjának a kérdése. Az Ops Control rendszer esetében a döntések meghozatalához szükséges ismerni a rendelkezésre álló repülőgépek kapacitását, ehhez hasznos lett volna a karbantartást tervező műszaki rendszerrel való kapcsolat, aminek hiányában ilyen típusú adatokat az illetékes területről telefonon lehetett megszerezni. Hasonlóan fontos információ a diszpécser számára a személyzet rendelkezésre állása. Bár a személyzetvezénylési funkciókat szintén egy számítógépes rendszer végezte, de az integráció hiányában szintén csak telefonos kapcsolaton keresztül lehetett tájékozódni az esetleg szükséges tartalék személyzet rendelkezésre állásáról. Ugyanez volt a helyzet az utas- és árú terheléssel kapcsolatos adatokkal is, mivel ezek az adatok nyilván voltak tartva a helyfoglalási (Gabriel reservation) és az árú kezelési (Cargo) rendszerben, de adatkapcsolaton keresztül ezek nem voltak összekötve az Ops Control rendszerrel. A megoldást abban az időben „humán interfésznek” neveztük, ami azt jelentette, hogy a dolgozónak kellett a különböző munkaállomásokon a különböző rendszerekbe való bejelentkezés után összeszedni a döntéséhez szükséges adatokat. Opscontrol - Operations Control -központi koordinációs/ üzemirányítási iroda Scheduling- menetrendtervezés Cargo-légi áruszállítási rendszer Maint,- Maintenance -Műszaki karbantartási, anyaggazdálkodási rendszer FIDS – Flight Information Display System – utastájékoztatási rendszer DCS – Departure Control System –járatindítási rendszer


oldal 44

LÉGI ÁRU FUVAROZÁS AUTOMATIZÁLÁSA MAGYARORSZÁGON Az utas mellett a Cargo automatizálás is megvalósult teljes körűen 1981-ben a SITA osztott Cargo technológiáján alapulva (IBM mainframe), a ebben a MALÉV elsőnek vezette be a világon a szolgáltatást. Áru helyfoglalás, fuvarlevél kibocsátás, tarifálás, különleges áruk kezelése, export, import, raktározás, nemzetközi rendszerekkel való integráció. Ez a cargo domain a későbbiekben egy magyar rendszerház és cargo disztribúciós kultúra megalakulását is eredményezte, akik a cargo vertikum belföldi és külföldi szereplőinek integrálást oldották meg – ma is sikeresen. Csányi István, a MALÉV Operations Control csoportvezetője majd az Árufuvarozási Igazgatóság rendszerfelügyelője, későbbiekben egy önálló és 20 éve sikeres magyar repülési informatikai rendszerház megalapítója és tulajdonosa az alábbiakban foglalja össze a nagy történetet:

AIR CARGO AZAZ LÉGIÁRU-FUVAROZÁS MI AZ A AIR CARGO? A légiáru-fuvarozás történetileg is elsősorban a menetrendszerű utasszállító járatok szabad rakodótér kapacitásának kihasználását jelentette de vannak teherszállító légijáratok, sőt olyan légitársaságok is amelyek csak árufuvarozással foglalkoznak. Kezdetben csak postát, később kereskedelmi árukat is szállítottak a légijáratok. Bár fajlagosan ez a legdrágább, de ugyanakkor a legbiztonságosabb és leggyorsabb fuvarozási mód. Posta- és diplomáciai küldeményeken kívül elsősorban nagy értékű, sérülékeny, romlandó illetve sürgős árukat fuvaroznak air cargo-ként. A légiáru sajátossága (szemben az utasokkal), hogy fuvarozni és mindvégig foglalkozni kell az okmányaival (fuvarlevél, tanúsítványok, vámokmányok), esetleg a „pénzével” (utánvétes küldemények esetén), indulás előtt és érkezés után megfelelő szállást kell biztosítani számára (raktározás), folyamatos kapcsolatot kell tartani a rokonságával (feladó és címzett) és ahova leteszik, ott marad, nem kér segítséget. A cargo terület szinte minden légitársaságnál alulfinanszírozott, a MALÉV-nél gyakran csak mint „fuvar” vagy „bánya” emlegették, pedig közvetlen költségeit messze meghaladó nyereséggel üzemel általában, ám pontos nyereségét lehetetlen objektív eszközökkel meghatározni, hiszen sok költség elem közös az utas fuvarozással.

AZ AIR CARGO-VAL FOGLALKOZÓ SZERVEZETEK ÉS RENDSZEREIK A légiáru-fuvarozásban résztvevő szervezetek sok különböző, bár funkcionalitásukat tekintve számos átfedéssel rendelkező rendszert használnak. Ezeket a rendszereket úgy lehet a közérthetően bemutatni, ha felvázoljuk a résztvevői-kapcsolat rendszert és a folyamatokat.

LÉGITÁRSASÁG – CARGO RESERVATIONS ÉS/VAGY HANDLING RENDSZER, PÉNZÜGYI RENDSZEREK, ULD CONTROL RENDSZER A légitársaság üzemelteti a fuvareszközt, a légi járművet. A poggyász- és postaterhelés után előre láthatón szabadon maradó rakodótér kapacitás mértékéig helyfoglalást készíthetnek a fuvaroztatók. A légitársaság, vagy megbízott ügynöke átveszi és raktározza a Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 45

küldeményeket a járat indulásáig, légi fuvarlevelet (MAWB) állít ki, tarifál és egyéb költségeket számít. Technológia szerint meghatározott idővel a járat indulása előtt összekészíti az adott járatra berakodásra szánt árumennyiséget (pre-manifesztálás), széles törzsű géptípus esetén ULD-t (konténer-paletta) épít. Közvetlenül a járatindulás előtt elkészíti a végleges manifesztet amely a súlypontszámítás egyik alapdokumentuma is egyben. A manifeszt nyomtatott egyik példánya a járaton utazik, elektronikus formája (FFM üzenet) pedig elküldésre kerül minden érintettnek. Érkező járatok esetén, amennyiben saját cargo handlinggel rendelkezik, kirakodja az árut, raktározza, kezeli a rendellenességeket (tracing) és kiértesíti a hatóságokat (vám) és a címzetteket, vagy előzetes keret megállapodás alapján átadja a saját raktárral rendelkező speditőrnek. Amikor a címzett jelentkezik a küldeményért, a vám- és kereskedelmi (bankfelszabadítás) szabályokat betartva, kiadja a küldeményeket a jogos tulajdonosoknak.

SITA CARGO RENDSZER A MALÉV úttörő szerepet vállalt, mivel a kis-közép méretű légitársaságok közül a világon elsőként vezetett be integrált cargo helyfoglalási és árukezelő rendszert 1983-ban. A SITA Cargo Rendszerét választották, amelyet a SITA az „Alitalia Fast IV.” rendszeréből fejlesztett tovább. Ez a SITA londoni adatfeldolgozó központjából IBM mainframe-en host-olt, osztott rendszer volt. A MALÉV partíció a Carmen fantázia nevet kapta. Közel 20 évig használta a MALÉV a Carment (amelyet a SITA folyamatosan fejlesztett, korszerűsített) és a MALÉV mindvégig megőrizte a felhasználói közösségben vezető szerepét. Gyakran volt „reference site” új SITA cargo felhasználók számára és a fejlesztési irányok meghatározásában is kulcsszerepet birtokolt. A SITA Cargo Rendszere akkoriban vitathatatlanul a legkorszerűbb és legszélesebb funkcionalitással bíró rendszer volt – ennek köszönhetően egy évtizeden belül felhasználói száma elérte a 60-at. Később megjelentek a piacon más, hasonló elven működő, hasonlóan átfogó funkcionalitású cargo rendszerek is (mint pl.: a Champ), de felhasználóik száma összesen sem érte el a SITA Cargo Rendszerét. A Carmen-nek volt két alrendszere, amelyekre a MALÉV is előfizetett. Marquis tarifa adatbázis, mely egy Hollandiában működő, ugyancsak mainframe alapú rendszer volt és a IATA cargo tarifákat tárolta. Dangerous Goods Control System a „veszélyes áruk” IATA szabvány ellenőrzését és okmányolását végezte. Voltak egyéb alrendszerei is, mint pl. a Yield Management, amelyeket a MALÉV nem használt. 1992-ig WESTINGHOUSE WI642 „dumB termninál” CRT-k voltak Carmen munkaállomások, amelyek a mainframe-nek megfelelő IBM3270-es emulációval működtek. Bár raktáron voltak a korábban megrendelt sokkal korszerűbb SIGMA 2160 CRT terminálok, de az épület kábelezése és áramellátása alkalmatlan volt ezeknek a korszerűbb eszközöknek az kiszolgálására. A Malév Árufuvarozási Igazgatósága ekkor már több mint egy évtizede abban a barakk épületben működött, amelyet eredetileg 1-2 évre, ideiglenes elhelyezésükre építettek a korszerű cargo bázis felépüléséig – amely a mai napig sem épült fel. 1992 májusában adták át az új irodaépületet, amelyet egy másik, korábban speditőrök által használt barakkból alakítottak ki és ezután lecserélhették a terminálokat is.


oldal 46

PC-S CARGO RENDSZEREK, SZOFTVERFEJLESZTÉSI SIKEREK A PC-k elterjedésével keletkezett igény arra, hogy egy munkaállomás több funkciót is ellásson (pl. Carmen, SITATEX és szövegszerkesztés). A SITA 1993-ban elő is rukkolt a STARS koncepcióval, amely a különböző SITA mainframes rendszerekhez egy PC-ről biztosított hozzáférést, Eicon kártyával, Eicon Aviva szoftverrel. A MALÉV Cargo-ban ekkor már működött PC-s cargo rendszer elérés. A STARS-ra is leszerződött a MALÉV és lassan a „dump terminál”-ok helyét felváltották a PC-k, de még egy évtizeddel később is használtak „dump termninál”-t a MALÉV Cargo-ban. Ugyanakkor a PC-k és a PC-s terminál emulációk elterjedésének következtében a Cargo-ban nyugodtan mondhatjuk, hogy korszakalkotó, igazi informatikai forradalom indult el. A Cargo Rendszerfelügyeleti csoport dolgozói, együttműködve a CCS Hungary Kft.-vel szoftverfejlesztésbe kezdtek és a Carmen-hez kapcsolódó szatellit rendszereket készítettek. Először egy vámbejelentő és kiértesítő PC szoftver készült el a 90-es évek közepén, amely egészen 2005-ig működött. Ez a szoftver akkoriban a világon elsők között, a PC-s terminál emulációt felhasználva, adatokat töltött le és írt be a Carmen rendszerbe, teljesen automatizálva az érkező áruk vám-alapnyilvántartási bejelentését, és a világon elsőként automatizálva az ügyfelek kiértesítését. Ennek köszönhetően a MALÉV saját és a kiszolgált légitársaságok tekintetében az okmányok beérkezését és a Carmen adatrögzítését követően ideális címzett elérhetőség esetén 1 percen belül eljuttatta a küldemény címzettjének az értesítést a küldemény (naponta több száz küldeményről beszélünk, 24 órás üzemben, hiszen akkoriban nem volt még éjszakai korlátozás sem) érkezéséről, részletes adatokkal és az akkor 16 számjegyű vámalapnyilvántartási számmal. Ilyen gyors értesítési rendszer még ma is csak pár repülőtéren valósul meg a világon2003-tól a MALÉV egyetlen versenytársa a BA Rt. Cargo bevezette a CCS Hungary új BACH fantázia nevű cargo rendszerét, amely lényegesen jobban alkalmazkodott a haza sajátosságokhoz és üzleti környezethez, sokkal rugalmasabb volt és nem utolsó sorban nagyságrendekkel olcsóbb mint a MALÉV által használt SITA Cargo rendszer. Pár év alatt nyilvánvalóvá vált, hogy versenyhátrányt jelent a MALÉV-nek a SITA Cargo rendszer használata és hosszas vívódás után 2005 augusztusában a MALÉV is lecserélte cargo rendszerét, a MACH fantázia nevű CCS Hungary termékre.

SZÁMLÁZÁS A számlázás támogatását a SITA Carmen az igen eltérő felhasználói igények egységes kielégítése érdekében egyszerűen oldotta meg egy u.n. CRA (Cargo Revenue Accouinting) queue rendszer bevezetésével. A SITA Carmen időszakban „humán interfész” segítségével történt az adatátvitel a Carmen rendszerből a MALÉV pénzügyi rendszerébe. Amikor egyegy fuvarlevél már befejezte operatív pályafutását a SITA Cargo rendszer nyomtatható formában előkészítette egy-egy fuvarlevél adatait és sorban feltette ú.n. queue-kra, amelyeket a MALÉV Pénzügyi Osztályán lévő Carmen terminállal megnyitottak és az ott lévő fuvarlevél adatsorokat egyenként kinyomtattak (ezzel törlődött is a queue-ról az adott fuvarlevél adata, nem egyszer okozva fejtörést a dolgozóknak).


oldal 47

ÜGYNÖKI ELSZÁMOLÁS A cargo ügynöki elszámolás gyakorlatilag soha nem nem került teljes körűen automatizálásra. Az Alitalia légitársaság szoftver leányvállalata az Alidata készített egy CROMA (Cargo Regional Office Management) ügynöki elszámolásra és CASS interfész fileok előállítására szánt rendszert, amelyet a MALÉV majdnem bevezetett az Alitalia MALÉV résztulajdonlás időszakában, de végül ez nem valósult meg.

INTERLINE ÉS NEMZETKÖZI BEVÉTEL ELSZÁMOLÓ RENDSZER KIVÁLASZTÁS Kezdettől fogva a megoldandó feladatok között szerepelt de sem elegendő idő, sem megfelelő támogatás nem állt a cargo rendelkezésére a probléma megoldásához. Az előkészítő lépés, amikor a Nemzetközi Elszámolási Csoport az Cargo osztályra került szervezetileg és fizikailag is, már 1992 májusában megtörtént. Ezután többször kezdeményezte a Cargo egy megfelelő elszámolási rendszer Beszerzését, de nem történt előre lépés. A 90-es évek közepén már a SZÜV alapú elszámolási rendszer és a folyamatok elavultak (a prorátázást manuálisan végezték a Cargoban, az adatokat ott rögzítették manuálisan az okmányokról és a SZÜV csak a kész adatokat gyűjtötte és listázta, sok szempontból nem a MALÉV igényeinek megfelelően, alig téve a folyamathoz értéket), majd újabb kézi adatfeldolgozás következett. Világos volt, hogy a SZÜV szolgáltatásra alapuló, elavult és feltehetően veszteséget okozóan megbízhatatlan rendszer cseréjékor a rendszertervet sem szabad a meglévő folyamatra alapozni, inkább egy ideális, a ROSS (akkor bevezetés alatt álló főkönyvi) rendszer szempontjából is kifogástalan tervet kell alapul venni. Ez a feladat volumenénél fogva saját fejlesztésben nem megoldható. Három alternatívát állítottak fel (mivel a korábban megvásárolt, de soha be nem vezetett ABC CPATA és az akkoriban megjelent CHAMP az előzetes vizsgálatok alapján alkalmatlan volt). Végül csak 1999. január 1.-ével állt üzembe a RAS-C rendszer.

CARGO HANDLING AGENT – CARGO HANDLING RENDSZER A ramp-handlingtől és az utas-handlingtől jellemzően elkülönült szervezet végzi a cargo handlinget. Budapesten a Légiforgalmi- és Repülőtéri Igazgatóság (L.R.I.) a ’90-es évek közepén hozta létre cargo handling szervezeti egységét, addig csak a MALÉV végzett Ferihegyen (BUD) cargo handlinget. 1996-ban barter megállapodás keretében hálózatépítéssel, PC karbantartással és egy DOS-os raktári nyilvántartó rendszer elkészítésével segítette a CCS Hungary az L.R.I. Cargo indulását, ahol kezdetben manuálisan, papír alapon dolgoztak. Cserébe kaptak egy LRI Cargo-ban lévő helyiséget és 5 telefonvonalat (PBX) a speditőri rendszer dial-up eléréséhez, ami elengedhetetlen volt a CCS szolgáltatás beindításához. A RADIANT RT. alvállalkozójaként tendert nyerve 1997-ban a CCS Hungary átadott egy elnagyolt L.R.I. specifikáció alapján készített Raktárkezelő és Handling rendszert, amelyet 2003-ig használtak. Bár az általuk javasolt modulok közül csak az alapmodult rendelte meg akkor az LRI, és a felhasználóknak biztosított hardver sem felel meg mindenben a kor követelményeinek, az alapvető feladatok ellátását megfelelően támogatja a rendszer. Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 48

Tekintettel az L.R.I. Cargo-val kialakult jó kapcsolatra a rendszert ingyenesen több alkalommal a megváltozott igényekhez igazította a CCS Hungary. A Vámjogszabályok változásával pedig a rendszer alapfelépítését érintő átalakítást is végeztek. Részben a fent említett átalakítások miatt részben a rendelkezésre álló új informatikai eszközök és módszerek nagy számának ösztönzésére 1999-ben tárgyalásokat kezdeményeztek az LRI-vel a rendszer megújítására, a megváltozott körülményekhez és igényekhez alakítására és a korábban nem igényelt modulok elkészítésére. Akkor már új vezetése volt az LRI-nek, akik kevésbé látták át a CCS jelentőségét és az informatikai fejlesztés fontosságát. A tárgyalásokat folytathattak az L.R.I. Cargo új igazgatójával, Juhász János úrral is és végül, nagy nehezen meghívást kapott a CCS is az új cargo rendszer beszerzésére kiírt versenytárgyalásra 2000-ben – ahol végül is a az akkor már kicsit elavultnak számító és egészen más üzemelési környezetre kifejlesztett British Airways rendszer bevezetése mellett döntöttek, de a vezető váltások miatt szerencsére a project elhalt. 2002-ban a CCS Hungary megbízást szerzett a repülőtér tulajdonosától, amely időközben L.R.I.-ből Budapest Airport Zrt.-vé átalakult, egy korszerű, már CCS Hungary szakemberei által specifikált rendszer elkészítésére, amelyet több akkoriban piacvezető rendszer ismerete, hibáink és hiányosságaik tanulmányozása után a CCS el is készített és a rendszer 2003-ban üzembe is állt. A CCS megoldotta az adatmigrációt is így gyakorlatilag az ügyfelek nem érzékeltek fennakadást, a felhasználó zökkenőmentesen átállt az új rendszer használatára, pár hetes párhuzamos üzem után.

HANDLING SZÁMLÁK KÉSZÍTÉSE A MALÉV-hez hasonlóan az L.R.I., később BA Rt., majd a kiszervezett és Celebi multinacionális vállalatnak eladott cargo handling sem oldotta meg a cargo elszámolás és számlázás teljes automatizálását. Jellemzően az aktuálisan használt cargo forgalmi rendszer csak előkészítette a fuvarlevél- és járat adatokat de a számla készítése ezek manuális vagy fél-automatizált adatátvitellel történt a az aktuálisan használt számlázási rendszerbe.

VÁM – VÁMRENDSZER ÉS EGYÉB HATÓSÁGOK RENDSZEREI Az Egyesült Államok Vámhatósága már a ’80-as években elindított egy projectet a vámeljárások számítógépesítésére, ezzel kijelölve az utat a többi állam vámhatóságának. Folyamatosan fejlesztette és terjesztette ki az egyes fuvarozási ágakra az AMS (Automated Manifest System) nevű rendszerét, amely lehetővé tette (sőt 2007-től megkövetelte) egyes légi-fuvarokmányok (MAWB, HAWB, manifeszt) elektronikus benyújtását, méghozzá a légi járat érkezése előtt. Ehhez a MALÉV-nek is csatlakoznia kellett, mivel menetrendszerű járatot üzemeltetett New York-ba, de a SITA megoldása túl költséges volt, ezért a handling agent saját PC-s rendszerén keresztül jelentettünk be. 2004-ben a légitársaságokat egybetömörítő szövetség a IATA (International Air Transport Association) elindította az e-Freight projektet, melynek elsődleges célja a légiárufuvarozásban használt okmányok kiállításának és fuvarozásának megszüntetése és


oldal 49

kiváltása egy egyszerűbb, iparági szinten elfogadott, elektronikus adatcserére épülő, okmánymentes környezet létrehozásával. Ezen projekt, hatással van a teljes árufuvarozási láncra, így létrejött egy "Iparági Aktív Csoport", melynek elsősorban a légitársaságok, a CCS-ek, a legnagyobb légi szállítmányozók, a FIATA és a WCO a tagjai. Együtt a IATA-val, az említett csoport hívatott összefogni az iparág valamennyi szereplőit (légitársaság, szállítmányozó, árukezelést végző szervezetek, hatóságok) és segíteni a projekt előrehaladását. Hazánk hagyományosan a világ élvonalában áll a légiáru-fuvarozási elektronikus adatcsere területén. 1996 óta működik nálunk CCS, azaz árufuvarozási közösségi rendszer, amelynek azóta gyakorlatilag minden, a légiáru-fuvarozásban aktív résztvevő tagja, felhasználója. 1997-ben indult az első elektronikus repülőtéri adatcsere a Vámhatósággal, és az elektronikusan cserélt információk köre azóta folyamatosan bővül. Az elektronikus vám (evám, elektronikus import export vámeljárás) rendszer 2008. évben történő bevezetése a NAV Repülőtéri Főigazgatóság és a légi fuvarozásban közreműködők életében nagy változást hozott, mely rendszer bevezetése jelentősen csökkentette a lég-küldeményekre fordított vámeljárás idejét. A reptéri gazdálkodók teljes mértékben átálltak erre a rendszerre, melynek köszönhetően a repülőtéren közel 100 %-os az elektronikusan beküldött indítványok száma. Ennek sikerét látva és a további egyszerűsítések, a repülőtéri áruforgalom kiszolgáltatásának színvonalasabbá tétele érdekében 2009. év második felében hazánk is csatlakozott az e-Freight projekthez. Fontos volt a nemzetközi gyakorlatban elfogadott és jól működő elektronikusan történő kezelhetőség, annak összes előnyét szem előtt tartva (egyszerűbb árukezelés, költségmegtakarítás, biztonságosabb árufuvarozás, standardizálás és harmonizáció fokozódása, magasabb szintű szolgáltatás nyújtása a megrendelő felé). Természetesen az e-Freight bevezetése nem csupán a légi-szállításban résztvevő felekre nézve jelent előnyt a jelenlegi papír alapú ügyintézéssel szemben, hanem a vámhatóság export-import forgalomban végzett áruellenőrzése területén a gyorsabb és pontosabb információk segítségével hatékonysága jelentősen növelhetővé válik és a mai gazdasági folyamatok egyik legfontosabb elemének, a költséghatékonyság optimalizálását idézi elő. 2012 végére 41 ország 437 repülőterén működik az e-Freight rendszer, mely éles üzemben 2012. november 15-én már hazánkban is elindult. Magyarországon az e-Freight rendszer kiépítését a CCS Hungary Kft. utód cégei, a CCS Hungary Aircargo Kft. és a KVM Technológia Magyarország Kft. végzik, amely gazdasági társaságok a légi árufuvarozásban több szoftvert is kínálnak légitársaságoknak, szállítmányozóknak és kiszolgáló szervezeteknek egyaránt.

POSTA – POSTAELSZÁMOLÁSI RENDSZER A legelső hasznos holt-teher amit kereskedelmi járaton szállítottak, posta volt. Ennek ellenére a postafuvarozást sosem sikerült igazán integrálni sem itthon, sem máshol a cargo folyamatokba, aminek elsődleges oka néhány alapvető eltérés volt a áruküldeményekhez képest. Egyrészt a posta-fuvarokmányoknak (AV7) nem volt sorszáma és „postazsákoknak” sem volt egyedi azonosító száma, a plomba szám ismétlődhetett, így csak az útvonal és a súlyadat egyezése esetén lehetett valószínűsíteni az azonosságot. Másrészt nem kg alapú, Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 50

hanem gramm alapú volt súlyadat, ami a páratartalmi és légnyomásbeli különbségek valamint a mérőeszközök eltérése miatt soha nem egyezett az indító- és célállomáson. 2000-ben MailMan fantázia nevű Postaküldemény nyilvántartó és postaelszámoló rendszert készített egy külső vállalkozás a Cargo szakemberek által elkészített specifikáció alapján, amely közel 10 évig üzemelt. Az Informatikai Igazgatóság döntése alapján azonban nem a működő és bevált rendszert korszerűsítették, hanem 1999-ben mintegy tízszeres költséggel készíttettek egy másik vállalkozással egy új rendszert. A postaelszámolás sajátosságaiból adódóan, feltehetően sok bevételtől esett el a MALÉV ki nem számlázott fuvarokon és a súlyeltérések miatti kártérítések miatt.

SPEDITŐR – SPEDITŐRI RENDSZER A légi áru feladója általában nem közvetlenül lép kapcsolatba a légitársasággal, hanem megbíz egy szállítmányozó vállalatot (más néven speditőrt) amelyik a a szükséges információk és szerződések birtokában ki tudja választani a legoptimálisabb ár-érték arányú fuvarozót és útvonalat elvégzi az okmányolást és számos egyéb feladást megelőző feladatot. Az első légi-speditőri rendszereket a nagy, multinacionális speditőr cégek állították üzembe és az okmányok előállítására, kapcsolódó pénzügyi műveletekre és a világon szétszórt irodáik közötti adatcserére használták. Ezek a rendszerek azonban nem kapcsolódtak a logisztikai lánc többi résztvevőjéhez, így amikor az integrátorok megjelenése arra kényszerítette a légitársaságokat, hogy szorosabb kapcsolatot építsenek ki a speditőrökkel, rendszerkapcsolat helyet kezdetben egy-egy légitársaság rendszerterminálját telepítette a fontosabb speditőrjeihez. Hamarosan kezelhetetlenné vált a helyzet, mert egy nagyobb forgalmú speditőr irodájában egy tucat légitársaság terminálja sorakozott már. Ekkor indult el a rendszerek integrációja és a CCS-ek hódító útja. A ’90-es évek elején a legnagyobb magyar speditőr a MASPED sem rendelkezett légi speditőri rendszerrel, sem számottevő nemzetközi iroda hálózattal, a többiek gyakran még számítógéppel sem, írógéppel dolgoztak. 1993-ban a Cargo számítógépes csapata indította útjára azt a vállalatcsoportot, amely 1996ra elkészült egy integrált és IATA szabvány EDI kommunikáció képes szállítmányozó rendszerrel, amelyet olcsón, havi díjas konstrukcióban használhattak a speditőrök. Mind a mai napig folyamatosan bővül a szoftverkínálat, amely magyar nyelven, de nemzetközi színvonalon áll a magyar szállítmányozók rendelkezésére.

CARGO COMMUNITY SYSTEM (ÁRUFUVAROZÁSI KÖZÖSSÉGI RENDSZER) A CCS egy intézményrendszer, mely a legtöbb esetben nemzeti alapokon szerveződik. A CCS intézményrendszerek olyan semleges és független, de általában a nemzeti légitársaság által támogatott rendszerek, melyek a légiáru-fuvarozási iparág különböző szereplőit képviselik.


oldal 51

Az intézményrendszer elsődleges szerepe, hogy egy olyan, a nemzetközi IATA szabványoknak (UN, IATA, FIATA, WCO/CCC) megfeleltetett, kommunikációs csatornaként működjön, mely az iparág különböző résztvevői által használt kommunikációs szabványok között tolmácsol. Tehát a CCS egy olyan kommunikációs központ, mely a fuvarozásban résztvevő partnerek (Légi szállítmányozók, Légitársaságok, Kiszolgáló ügynökök, Képviseletek, Helyi hatóságok) rendszereit közvetlenül, vagy szabvány üzenetekkel a saját rendszeréhez kapcsolja. A beérkező elektronikus üzeneteket ezt követően automatikusan lefordítja és továbbítja az érintettek felé a rendszereik által „érthető” nyelven. A nemzeti CCS feladata egyben az is, hogy egy kész megoldást nyújtson azon résztvevők számára is, akik nem rendelkeznek saját rendszerrel, mellyel csatlakozhatnának ehhez a kommunikációs csatornához. Mindezzel a nemzeti CCS segítséget nyújt abban, hogy az adott országban megvalósuljon a „pontos” és „bizonylat nélküli” adatforgalom a légiárufuvarozásban, mely a végső cél minden iparág számára. Milyen előnyöket nyújthat egy nemzeti alapokon szerveződött Cargo Community System: Magyarország ezen a területen is a világelsők között szerepelt. 1996-ban, amikor olyan magasan fejlett országokban is csak tervezés- vagy bevezetés alatt állt, nálunk már szinte az egész piacot lefedve működött a CCS. Minden repülőtéri handling agent, a vám, a nemzeti légitársaság, szinte minden speditőr vállalat és a legtöbb ide üzemelő légitársaság aktívan használta az egymás közötti adatcserére. A CCS HUNGARY BT. 1993-ban alakult azzal a céllal, hogy létrehozza Magyarországon a magyarországi Cargo Community System-et azaz CCS-t. A nemzetközi gyakorlat és az iparági követelmények sürgető szavára hozták létre a magyarországi Cargo Community System-et, amely technikai megoldásaival a legmesszebbmenőkig alkalmazkodott a hazai körülményekhez. A magyarországi szállítmányozás szervezettsége és műszaki támogatottsága sajnálatos módon jelentősen lemaradt az európai országok színvonalától. Ez nem csak a szállítmányozó vállalatokat sújtotta, hanem természetesen a fuvaroztatókat is, és végső soron a nemzetgazdaság fejlődését is hátráltatta. Jelentős korlátokat jelentett a magyarországi hírközlés elmaradottsága is, ami e rendszer hatékonyságát is jelentős mértékben rontotta, de a legújabb technikai megoldások (TCPIP, ISDN, ADSL) felcsillantották minden eddigi kommunikációs korlát legyőzésének lehetőségét. A CCS szolgáltatás 1996-ban indult és ma már a légiáru-fuvarozás logisztikájának meghatározó eleme. Funkcionalitása, szolgáltatásai folyamatosan bővültek. kezdetben csak a klasszikus CCS funkciók léteztek: IATA szabvány szerinti kommunikáció a légitársaságokkal és fuvarokmány-készítés. Az idők folyamán először a cserélt üzenetek köre bővült, majd olyan forradalmi fejlesztések is elkészültek, mint pl.: a vonalkódos címkenyomtatás (amely az interneten keresztüli kereskedelem útján eljutott a világ számos országába (Indiától Izraelig, Dél-Amerikától Németországig), komplex szállítmányozói pénzügyi rendszer, majd az elektronikus szállítmánybiztosítás, amely sajnos a partnerek stratégia váltása miatt végül nem került éles üzembe. 1999 december 1.-ig a nemzetközi gyakorlatnak megfelelően az önálló vám alap nyilvántartási bejelentésre kötelezett repülőtéri vállalatoknak kínáltak elektronikus vám-kapcsolat lehetőségét. Szolgáltatásuk nem csak a bejelentő szoftver és a kapcsolat biztosítását foglalta magában, hanem a (SZÜV által készített és karban tartott) vámrendszer hiányosságai miatti napi többszöri személyes kapcsolatfelvételt a Vámhatósággal és hibaelhárítást is. Sajnos az új Hivatalvezetés a CCS HUNGARY-n keresztüli bejelentés lehetőségét megszüntette egy jogszabályi hiányosság Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 52

miatt „vámkapcsolattal csak bejelentésre kötelezettek rendelkezhetnek”, de rövidesen felismerték fontosságát és újraindulhatott és a nemzetközi gyakorlatnak megfelelő, korszerű, EDI alapú rendszerrel, a CCS HUNGARY feladatának megfelelően ezen a területen is integrált szolgáltatást nyújthatott. Akkor már a CCS 14 különböző méretű vállalatnak nyújtunk rendszerfelügyeleti szolgáltatást is és számos cégnél mint solution provider jelent meg. Érdemes megemlíteni, hogy a CCS részt vett már akkoriban is az elméleti munkában: Több, a Közlekedéstudományi Intézet által végzett kutatási programban vett részt, az általuk készített tudományos elemzések megtalálhatóak a KTI WEB lapjain. Rendszeresen meghívott előadóként vettek részt a szakminisztériumok által szervezett EDI Fórum konferenciákon Mind a mai napig több egyetemen oktatják szakembereik a légiközlekedési informatikát és több pályakezdő fiatal mérnöknek nyújtottak érdekes, kihívást jelentő első munkahelyet, biztos állást.

IATA CASS Hasonlóan a BSP-hez, a nemzetközi elszámolást segíteni hivatott rendszer, de míg a BSP az utas fuvarozás, addig a CASS az árufuvarozás rendszere. Magyarországon is megalakította a IATA, de a MALÉV soha nem csatlakozott, közvetlen kapcsolatot tartott a speditőrökkel, a CASS beiktatása csak lassította- és drágította volna az elszámolást közöttük.


oldal 53

MALÉV INFORMATIKAI TÖRTÉNELMI ÁTTEKINTÉSE 1954 – MALÉV megalapítása a Maszovlet jogutódjaként. 1973 – Megalakul a KPM Légiforgalmi és Repülőtéri Igazgatósága, leválik a MALÉV-tól a repülőtéri és irányítási funkció 1975 – MALÉV élére új, szakmai vezetés kinevezése 1976 – A MALÉV Önálló Számítástechnikai osztály megalakítása –informatikai fejlesztés, stratégia kidolgozása, szervezet kialakítása 1980 – Új hangár és műszaki bázis komplexum megépítése 1985 – Ferihegy 2 új terminál megépítése, 2 terminálos üzemmód beindítása Informatikai rendszerek: 1954-1975 –

hang, lyukszalag telex-

1975 –

SITA Gabriel Utas-helyfoglalási rendszer bevezetése (világelsőként)

1978 -

Raycheck bevezetése

1981-

SITA Cargo rendszer bevezetése (világelsőként)

1981-

Rayfids (1. generáció) bevezetése

1982-

SITA Flight Planning bevezetése

1982-83

SAGIL M and E kifejlesztése és bevezetése

1985 –

SDCS és FIDS (2. generációk) bevezetése, 2 terminálos repülőtéri üzem

1990-

IATA Yield Management elindul

1992 -

SITA Crew management bevezetése

1999-

Lufthansa Systems Netline termékcsaládra migráció (ops, crew)

2005 -

magyar termék Cargo bevezetés

2009-

MALÉV utas rendszerek migrációja az AMADEUS Altéa platformra


oldal 54

SITA TÖRTÉNETE A repülés nagy távolságú pontok közötti utas- és áruszállítási feladatokat biztosít. A repülés veszélyes üzem, a repülőterek közötti kommunikációnak aránylag rövid időn belül biztonságosan kell megvalósulnia és igen fontos szerepe volt, van a szabványos eljárások elkészítésének . A légitársaságok felismerték ezen feladatok megoldásának szükségességét és erre létrehoztak egy egyesülést a S.I.T.A. szervezetét . A világháború után ez a terv elsősorban a polgári repülés újraindítását támogatta. A S.I.T.A. szervezetét – Société Internationale Télécommunicátions Aeronautiques – 11 légitársaság alapította meg 1949-ben. (Air France, KLM, Sabena, Swissair, British European Airways,(BEAC), British Overseas Airways Corporation,BOAC), British South American Airways (BSAA), Swedish A.G.Aerotransport, Danish Det Luftfartselskab A/S and Norwegian Det Norske Luftfartselskap. A későbbiekben tagsága több százra növekedett, gyakorlatilag minden légitársaság, repülőtér és repüléshez kötődő szervezet használta a SITA szolgáltatásait. A kooperatív szervezeti felépítés révén a tagok fiktív részvényeket szereztek a rendszerhasználattal arányosan. A S.I.T.A. kommunikációs hálózat óriási fejlődésen ment keresztül az 1950.-es évektől napjainkig, a telegráf, üzenetektől a mai internetes technológiáig. A hálózat már a 70.-es években nem csak a repüléssel kapcsolatos kommunikációt biztosította. Lehetővé vált osztott rendszerek kifejlesztése , mint pl. az USA atlantai központban fejlesztett és üzemben helyezet Gabriel helyfoglalási rendszer, amelyhez már akkor 20 légitársaság csatlakozott, többek között a Malév 1975-ben. A S.I.T.A. hálózat fejlesztésének teljes technikai leírását, mely átfogja az elmúlt 70 évet ebben az ismertetőben a terjedelem végett nem célunk elkészíteni. Az ismertető célja a hálózat kiindulópontjának meghatározása, a fejlesztési generációk bemutatása, az hálózat elvi felépítésének vázlata.

1.1 A SITA kommunikációs hálózat fejlesztésének mérföldkövei 1949 – 1950 – SITA megnyitotta az első telekommunikációs központot Rómában. Az információ átvitel perforált lyukszalagon és nyomtatókon valósult meg. Ez volt az akkori legnagyobb világhálózat 1. számú generációja 1966 – Type B Automated Switching. Az első message switching számítógép Frankfurtban került telepítésre és bevezetésre. Ez a kommunikációs technológia már biztosította a repüléssel, utas Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 55

kezeléssel, földi kiszolgálással és a repülőgép karbantartásával kapcsolatos szabványos üzenetek biztosságos és pontos továbbítását. 1971 – Type A 2nd Gen. network. Lehetővé vált az interaktív adatcsere a terminálok között. SITA letelepített az első szatellit processzort – s ez nagy mértékben biztosította számos új lokáció bekapcsolását. Műholdak kerültek telepítésre 32.00.km magasságban az egyenlítő felett

1981 – X.25.- SNA – 3rd Gen. Network (DTN) Ez egy adatkommunikációs rendszer, az IBM fejlesztette ki. A rendszer biztosította a kommunikációt az u. n. Host számítógép(IBM mainframe) és a perifériális pontok között. Nagy előre lépés volt az u.n. batch(kötegelt)adat továbbítás és az SNA biztosított tranzakció processing eljárás viszonylatában. A DTN- delay and disruption protocol első lépésben kijelöli a címzés szerinti útvonalat és ha a kapcsolódások biztosítottak, az információt a megcímzett desztinációba viszi be.Amennyiben a heterogén hálózaton bármi hiba, áll elő, a kapcsolat megszakad a protocol áttér a „store and forward” technikára, majd folyamatosan próbálkozik, míg az adatokat el nem juttatja a címzett desztinációhoz. 1992 – Frame Relay – 4.th Gen. network.Frame Relay csomagkapcsolt hálózatok egy kommunikációs szabványa, amelyet az ANSI és CCITT közösen dolgozott ki. Gyors adatátvitelt biztosít, a változó hosszúságú adatcsomagok úgynevezett”keretekben”foglalva utaznak. A Frame Relay technológia - jelen estben a SITA központi WAN és a lokális(LAN) hálózatok között biztosít kapcsolatot. Az X.25 szintén egy csomag kapcsolt technológia – mind két technika használatos mai is. 1996 – SITA IP Core – Internet Protocol biztosítja a host (központ)címzését és a routing datagram leírását a forrástól a címzett központig 2002 – Equant IP Global – Az Equant kapcsolatot biztosít a multinacionális vállalatok között, használva a hang és adatkommunikációs technológiát. Equant a HP partnereként fejlesztette ki az IP VPN (Virtual Privat Network) rendszert.

A fentiekben felsorolt mérföldkövek, időintervallumok jól mutatják a gazdasági, repülési folyamatok által kikényszerített óriási fejlődést. Természetesen minden idősávban számos variációt és kapcsolódó kommunikációs lehetőségeket valósítottak meg. Mint előzőekben írtuk a technikai leírások hatalmas területet ölelnek fel, de az interneten ezek a dokumentációk részleteiben megtalálhatóak


oldal 56

A SITA HÁLÓZAT EGYSZERŰSÍTETT ELVI RAJZA (központok városneveivel) HIGH LEVEL CENTER

műhold

CPH Satellit proc.

AMS

LON

BRU

TLV

STO

PMI BER

DUS

NYC

FRA MUC MI VIE

GVA

ROM

PAR ZRH

MAD TUN

MIL

ATH

NCE CAS

BAR

PMI PMI


oldal 57

Az egyszerűsített vázlaton jól láthatóak a hálózat tipikus elemei. A hálózat gerincét a nagy városokban letelepített úgynevezett High Level Center (HLC) központok képezik. Ezek a központok földi kommunikációs kábeleken vannak összekötve. A HLC központokhoz kerültek bekötésre további városok a repterekkel, utas és árukezelési irodákkal. A földi kábelek kiépítése költséges, több estben a kivitelezésük nehézségekben ütköznek. Ezért a SITA bevezette a satellit kommunikációs technológiát. Az adott HLC központokban megkezdte a Satellit processorok telepítését, majd a műholdak pályára állítását. A földi kábeles és a műholdas kommunikációval gyakorlatilag a föld bármely pontja így elérhetővé vált. Érdemes megjegyezni, hogy már a 70-es évek osztott rendszereipl. az atlantai Gabriel utas helyfoglalási rendszer átlagosan 2 másodperces válaszidővel dolgozott. A SITA hálózat adta globális lehetőségek kihasználására applikációs szolgáltatásokat is kifejlesztettek az 1970-es évek végétől kezdve, amelyek egyre nagyobb jelentőséggel bírtak. Először természetesen az utas helyfoglalási rendszereket alakították ki a SITA Atlanta Számítóközpont Unisys mainframe szolgáltatásaira alapítva. A későbbiekben belépett a SITA Európai Központ (először Párizsból majd később, ma is, Londonból üzemeltetve) – ez IBM technológián alapul és a nem utas szolgáltatásokat nyújtotta, cargo, operations területeken. A rendszereket illetően a SITA neutrális, jó minőségű és közepes árfekvésű szolgáltatásokat ajánlott légitársasági ügyfeleinek. A rendszerkultúra meghatározó és igen vonzó eleme a felhasználók intenzív bevonása a fejlesztési igények meghatározásába, amely sok kisebb és induló légitársaságnak nagy segítséget ad a szervezet és munkafolyamatok kialakításához, a nemzetközi közösségbe és üzletbe való beilleszkedéshez. Az SITA utas rendszereknek egy időben akár 100-150 felhasználója is volt, amely magasan meghaladja az utána következő szolgáltatók ügyfélbázisát (jellemzően 10, max. 20). Leghíresebb rendszerek: Gabriel utas helyfoglalás, Cargo, Flight Planning, CUTE repülőtéri platform, Aircom/Satcom digitális föld-levegő kommunikáció, Operations Control stb. A SITA kiemelkedő eredményeket ért el a multihost architektúra kialakításában, amellyel sok ügyfelet tudott egyszerre kiszolgálni úgy, hogy azok élvezték a közös rendszer előnyeit de módjuk volt egyedi beállításokat is alkalmazni és adataik teljesen biztonságban voltak. Az évezred fordulójára a SITA kooperatív jellege megszűnt és a cég tisztán kereskedelmi szolgáltatóvá vált. Egyidejűleg levált tőle a hálózati üzletág Equant néven és 2003-ra a SITA Inc már egyértelműen csak az applikációs rendszerekre koncentrál. A légitársasági ügyfélkor jelentősen kibővül a repülőterekkel és más a cargo résztvevőkkel, sőt az állami szektor számára és a repülés irányítás számára is kifejlesztenek speciális rendszereket. A MALÉV és a magyar polgári repülés számára meghatározó 70-es és 80-as évtizedekben a SITA – a többi repülési informatikai szolgáltatótól eltérően – rendkívül kedvező szolgáltatási struktúrát és feltételeket ajánlott:  haladó színvonalú rendszereket és mértékadó nemzetközi repülési folyamati technológiát  integrált applikációs rendszereket és hálózatokat, gyakran hardware-t, amellyel a világ bármely pontján gyorsan munkaállomásokat lehetett telepíteni és ezáltal lehetővé vált a MALÉV külképviseletek automatizálása (ez a rendszer teljesen elképzelhetetlen volt más polgári iparágak számára kb. 1990-ig)  beruházási igények nélküli szolgáltatás bevezetést, csak a használat után kellett fizetni a forgalom arányában (pl. hány utas, mennyi áru, hány repülési terv lett havonta kezelve)  gyakorlatilag központi hardware telepítése és üzemeltetése nélkül a MALÉV élvezte a világszínvonalú rendszerek szolgáltatásait  a SITA több területen szponzorálta a magyar és a külföldi fejlesztők együttműködését (SAGIL, Cargo)  a MALÉV rendkívül aktív szerepet kapott a SITA Igazgatóságában és szakbizottságaiban és jelentősen befolyásolhatta a nemzetközi szakmai folyamatokat Óbudai Egyetem- NJSZT Informatika Történet – Repülési Informatika Története végleges verzió linkekkel Gonda-Ballai 2013 október 24

oldal 58

SZAKMAI ÉS IDEGEN KIFEJEZÉSEK MAGYARÁZATA KIFEJEZÉS, RÖVIDÍTÉS

DEKÓDOLÁS

ÉRTELMEZÉS

COCOM, COCOM lista

Coordinating Committee for Multilateral Export Controls

A COCOM-lista egy, a keleti blokk országait sújtó, multilaterális kereskedelmi embargó volt. A COCOM-lista egy csúcstechnológiai termékeket tartalmazó feketelista volt.

CRT

cathod ray tube

katódsugárcső, az anyagban a korai munkaállomásokat jelöli

_____________________________________________________________________ Cutover

rendszer éles indítása

_______________________________________________________________________ domain

nagyobb logikai terület

pl. utasforgalom, árufuvarozás, műszaki karbantartás,

_______________________________________________________________________ space control

helyellenőrzés

utas (és áru) eladható kapacitásokat felügyelő szervezet és tevékenység

_______________________________________________________________________ load control

forgalmi iroda

a repülőgépek terhelés- és egyensúlyszámítása, ennek szervezete

________________________________________________________________________ ASP

application service provider csoportos informatikai szolgáltatás

________________________________________________________________________ CUTE

common use terminal equipment

technológia annak biztosítására, hogy a repülőtereken ugyanazon fizikai munkaállomásról váltogatva több különféle légitársasági rendszerhez hozzáférjenek, s így az utaskezelési terület kihasználását javítsák


oldal 59

_________________________________________________________________________ PNL

passenger name list

utaslista, egy járatra foglalt utasok helyfoglalási listája szabvány formátumban

___________________________________________________________________________ LDM, PSM, PTM

szabvány utas üzenetek

állomások és rendszerek között a járatok terheléséről, átszálló és speciális utasokról

____________________________________________________________________________ FIDS

flight information display system járatok érkezése/indulása kijelző

____________________________________________________________________________ AODB

airport operational database

egy repülőtérre üzemelő különböző járatok adatbázisa

_______________________________________________________________________________ flight planning

navigációs útvonaltervezés

_______________________________________________________________________________ crew management

hajózó személyzetek tervezése

______________________________________________________________________________ operations control

légitársasági üzemirányítás

_______________________________________________________________________________ IATA

International Air Transport Association Nemzetközi Repülési Szervezet

a világ légitársaságainak jelentős részét tömörítő egyesület, a folyamatok és kódok szabványosítására

________________________________________________________________________________ S.A.G.I.L

System Aviation Gestionnaire Information

Repülési műszaki üzemeltetési

Logistique

és anyaggazdálkodási rendszer


oldal 60

AJÁNLOTT IRODALOM ÉS HÁTTÉRANYAGOK

Gonda Zsuzsanna: Repülési Informatika könyv megjelent a SZAK Kiadó gondozásában 2005-ben, ISBN 963 9131 81 4 ma is megvásárolható a SZAK Kiadónál www.szak.hu jelen publikációhoz a SZAK Kiadó és a szerző hozzájárultak : http://web.itf.njszt.hu/wp-content/uploads/2013/10/Gonda-Zsuzsanna-Repulesi-Informatika-konyvSZAK-Kiado-2005-NJSZT-publikacio.pdf ______________________________________________________________________

Csányi István : Cargo tanulmány és forrásdokumentum adattár A szerző és cége, az egyetlen magyar légiközlekedési-informatikai rendszerház, a CCS Hungary gondozásában készült több tanulmány és adattár jött létre a magyar légiáru-fuvarozási szakág informatikai történetéről. A tanulmány mögé (az aláhúzott linkekkel elérhető) hatalmas mennyiségű, jelentős részben csak a CCS archívumában fellelhető forrásdokumentum került digitalizálásra és beillesztésre. http://kutatas.aircargo.hu/ Az anyag hasznos forrás lehet tanulmányok és szakdolgozatok készítéséhez. jelen publikációhoz Csányi István, minta szerző és a gyűjtemény gondozója valamint a CCS Hungary hozzájárultak

_________________________________________________________________


oldal 61

A MALÉV ÉS A MAGYAR POLGÁRI REPÜLÉS INFORMATIKAI TÖRTÉNETE A KEZDETEKTŐL NAPJAINKIG

Recommend Documents