Informační systém pro administraci pohybů letadel

Masarykova univerzita Fakulta informatiky

Diplomová práce

Informační systém pro administraci pohybů letadel

Bc. Ota Kadlec

2007

ii Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Brno, 2007 ……………………………………

iii

Shrnutí V úvodu této práce jsem se zaměřil na analýzu komplexního informačního systému (IS) pro letiště střední velikosti a analýzu současné situace na letištích v ČR. Dále stručněji popisuji jednotlivé moduly, které by měl takový systém obsahovat. V další části práce se zaměřuji na implementaci modulu IS letiště pro administraci pohybů letadel a modulu informačních obrazovek (tzv. FIDS). Stejně jako celý systém je i tento modul postaven na jedné z nejmodernějších technologií pro vývoj tzv. enterprise systémů, kterou je Java EE 5. Provozně jednou z nejdůležitějších částí je komunikace se systémy řízení letového provozu a výměna informací mezi IS provozovatele letiště a ŘLP, která je součástí systému. Na závěr uvádím konkrétní využití IS a nasazení na mezinárodním letišti v Karlových Varech, možné rozšíření a výhled do budoucna.

Klíčová slova Letový řád, letiště, pohyb, FIDS, letadlo, Java

iv

Obsah 1. Úvod.............................................................................................................. 6 1.1. 1.2. 1.3. 1.4. 1.5.

2.

Pokračování a návaznost na bakalářskou práci .......................................................... 6 Přechod od PHP k Java EE ........................................................................................ 6 Věci které se do této práce nevešly, nebo nejsou její součástí................................... 6 Použité zkratky a termíny........................................................................................... 6 Přehled kapitol............................................................................................................ 7

Analýza a návrh systému ......................................................................... 9 2.1. Současný stav informačních systémů na letištích ...................................................... 9 2.2. Komplexní informační systém, požadavky................................................................ 9 2.3. Komponenty informační systému ............................................................................ 10 2.3.1. Letové řády a koordinace letů (PLAN) ............................................................ 10 2.3.2. Pohyby, informace o aktuálním provozu (MVTS)........................................... 11 2.3.3. Poskytování služeb, účtování (HANDLING) .................................................. 11 2.3.4. Informace a informační displeje (FIDS) .......................................................... 11 2.3.5. Odbavení (DCS)............................................................................................... 11 2.3.6. Souhrnné statistické informace o provozu (STATS) ....................................... 11 2.4. Jednotlivé etapy vývoje a části implementované v této práci .................................. 12 2.5. Případy užití – use case ............................................................................................ 12 2.5.1. Popisy případu užití.......................................................................................... 13 2.6. Datový model – kostra ............................................................................................. 13 2.6.1. Popis entit......................................................................................................... 14 2.6.2 Vazby ............................................................................................................... 16

3.

Pohyby ..................................................................................................... 19 3.1. Definice pojmu pohyb letadla, jednotlivé druhy...................................................... 19 3.2. Přílet, odlet a místní činnost – stavové diagramy..................................................... 19 3.2.1. Přílet ................................................................................................................. 19 3.2.2. Odlet ................................................................................................................. 20 3.2.3. Místní činnost................................................................................................... 21 3.3. Typy letů a kritéria pro nastavení stavu ................................................................... 22 3.3.1. Jednotlivé typy letů: ......................................................................................... 22 3.3.2. Kritéria pro nastavení stavu.............................................................................. 22 3.4. Informace uložené v pohybech ................................................................................ 23 3.4.1. PAX a kategorie PAX ...................................................................................... 23 3.4.2. Plánovaný, skutečný a slot čas ......................................................................... 24 3.4.3. Historie stavů.................................................................................................... 24 3.5. Zdroje ze kterých se vytvářejí a aktualizují pohyby ................................................ 24 3.5.1. Vytváření pohybů z letového řádu (plánu)....................................................... 24 3.5.2. Manuální vytváření a úprava pohybů............................................................... 25 3.5.3. Automatická úprava pohybů informacemi z ŘLP............................................ 26 3.6. Prohlížení pohybů, hlavní obrazovka pro operátory ................................................ 26 3.7. Párování pohybů....................................................................................................... 27

v

4.

Zprávy posílané od ŘLP a směrem k ŘLP ............................................ 29 4.1. FMTP protokol, komunikace se systémy ŘLP......................................................... 29 4.2. Příchozí a odchozí SFPL .......................................................................................... 29 4.2.1. Elementy příchozí SFPL zprávy ...................................................................... 29 4.2.2. Elementy odchozí SFPL zprávy....................................................................... 30

5.

FIDS – Flight Information Display System............................................ 31 5.1. 5.2. 5.3.

6.

Problém informačních obrazovek, řešení................................................................. 31 Administrační rozhraní pro správu a definici nových obrazovek ............................ 31 Příletové, odletové a informační obrazovky ............................................................ 31

Závěr......................................................................................................... 33 6.1.

Výhled do budoucna................................................................................................. 33

Literatura: ....................................................................................................... 35 Dodatek A ....................................................................................................... 36 Technologie pro vývoj informačního systému ........................................... 36 A.1. A.2.

Enterprise Java Beans 3 (EJB3), Java Persistence API (JPA) ................................. 36 Java Server Pages, Servlets Java Server Faces ........................................................ 37

Dodatek B ....................................................................................................... 39 Testování funkčnosti a výkonu .................................................................... 39 B.1. Testování funkčnosti..................................................................................................... 39 B.2. Testování výkonu ......................................................................................................... 39

Přílohy............................................................................................................. 41

1. Úvod

6

1. Úvod 1.1.

Pokračování a návaznost na bakalářskou práci

Tato práce částečně navazuje na moji bakalářskou práci na téma Informační systém pro letové řády [KAD04]. V této práci jsem se zaměřil na definici hlavních datových struktur, kterými jsou například letiště, typy letadel, konkrétní letadla, subjekty apod. Hlavní částí této práce bylo zpracování letových řádů, jehož částí je modul pro dekódování SCR zpráv, což je požadavek leteckého dopravce na let(y). Dále pak moduly pro koordinaci letů, které byly vytvořeny na základě těchto zpráv a vygenerování odpovědní SCR zprávy, která je zpět odeslána dopravci přes sít SITA. Výstupem jsou jednak letové řády pro veřejnost, které obsahují základní informace o destinaci, datu letu, společnosti a lince a jsou nezbytné pro cestující. Pro pracovníky letištního provozu jsou určeny interní a tajné letové řády, které obsahují navíc provozní informace jako kapacita letadla, typ letu, doba parkování apod. Další podrobnosti jsou ve výše uvedené bakalářské práci. Současná implementace je sice odlišná od verze v bakalářské práci, ale principy zůstaly v podstatě zachovány.

1.2.

Přechod od PHP k Java EE

Hlavní změnou od systému, který byl prezentován ve výše uvedené bakalářské práci je přechod od PHP k platformě Java EE. Důvodů pro přechod k platformě Java EE je celá řada. Jmenovitě například udržovatelnost, rozšiřitelnost, bezpečnost. Dále pak rozhraní pro vzdálenou komunikaci s okolními systémy (např. RMI, CORBA, JMS, JavaOLE-bridge). Základ současného systému tvoří referenční implementace Java EE 5, kterou je aplikační server Java System Application Server 9.0 firmy SUN Microsystems. Dále pak databázové systémy MySQL a PostgreeSQL. Další nespornou výhodou tohoto přechodu je oddělení jednotlivých vrstev implementace. Data jsou uložena v relačním DBS. Veškerá logika aplikace je uložena ve vrstvě tzv. middleware (v našem případě EJB kontejner aplikačního serveru), což nám umožňuje například použití více klientů (tenký – prohlížeč, tlustý – swingová aplikace) bez nutnosti měnit aplikační logiku. V dodatku A této práce popisuji některé technologie, na kterých je tento sytém postaven.

1.3.

Věci, které se do této práce nevešly, nebo nejsou její součástí.

Vzhledem k tomu, že se tato práce týká pouze modulů pro administraci pohybů a FIDS, tak v ní nejsou obsaženy další moduly, které jsou třeba pro chod informačního systému. Jmenovitě například modul pro autentizaci a autorizaci uživatelů, který je nezbytnou součástí každého IS. Tento modul je postaven na technologii JAAS (Java Authentication and Authorization Service). Dále jsou to např. moduly pro „logování“ a ostatní moduly IS (kromě zmíněných FIDS a MVTS), které jsou uvedeny v kapitole 2.

1.4.

Použité zkratky a termíny

Zde uvádím výčet nejdůležitějších zkratek a termínů, které jsou použity v další části a bez kterých se čtenář neobejde.

1. Úvod

7

AD AIS Airline ATC(ŘLP) ATS ADEXP

- AeroDrome – letiště, odbavovací plocha - Airport Information System - letecká společnost, linka - Air Traffic Control (Řízení Letového Provozu) - Air Traffic System (systém řízení letového provozu) - ATS Data Exchange Presentation (ADEXP). - standardní dokument definovaný společností EUROCONTROL, který definuje formát jakým se předávají zprávy mezi systémy ATC Check-in - odbavení cestujících DCS - Departure Control Systém (odbavovací systém) FIDS - Flight Information Display System - systém sloužící k informování cestujících (např. panely s aktuálními přílety a odlety v odbavovacích a příletových halách letiště) FMTP - Flight Message Transfer Protokol (viz. kap. 4) FPL - Flight Plan (letový plán) FST - Full Stop – plné přistání. Letadlo přistane a zastaví kola. Gate - „brána“, místo kde nastupují cestující do letadla IATA - International Air Transport Association ICAO - International Civil Aviation Organization Imatrikulace - jednoznačný identifikátor letadla. - skládá se z 2-7 alfanumerického registračního kódu příslušného určitému státu a části přidělené registrem tohoto státu („SPZtka“ letadla) LA - Low approach – nízký průlet. Letadlo pouze proletí na letištěm bez dotyku RWY MTOW - Maximum Take-Off Weight (maximální vzletová hmotnost letadla) MVT - Movement – pohyb letadla PAX - passenger - cestující RWY - Runway – vzletová a přistávací dráha SCR - Scheduled Clearance Request (plánovaný požadavek na odbavení) SITA - Societe International de Telecomunications Aeronautiques - síť zprostředkovávající pozemní komunikaci mezi letišti a leteckými společnostmi SSIM - Standard Schedules Information Manual (od IATA) TAG - Touch and Go – letmé přistání. Letadlo se pouze dotkne RWY a zase odletí. Časy: GMT UTC CET

1.5.

- Greenwich Mean Time - Greenwichský čas - Universal Coordinated Time, univerzální čas, který používá většina systému pracujících na letištích a v ATC (stejné jako GMT) - Central European Time – čas ve střední Evropě (ČR)

Přehled kapitol

V první kapitole uvádím zadání práce, stručný úvod do problematiky s popisem termínů a zkratek, používaných v oboru letecké dopravy. Dále popisuji návaznost na svoji bakalářskou prácí a přechod od PHP k Java EE. V další kapitole se podrobněji zaměřuji na analýzu systému letiště a na vazby mezi jednotlivými částmi systému. Uvádím současný stav informačních systémů na letištích v ČR. Dále prezentuji modely z jazyka UML, které popisují případy užití systému a kostru datového modelu.

1. Úvod

8

Třetí kapitola je zaměřena na hlavní část této práce, kterou jsou pohyby letadel. Na úvod popisuji jednotlivé typy pohybů, v jakých stavech se mohou nacházet a vazby mezi těmito stavy znázorňuji stavovým diagramem UML. Následuje popis některých dat, které se v pohybech nalézají. V další části uvádím všechny možnosti jakými lze pohyb vytvořit. Těmi jsou vytvoření pohybu na základě plánu z letového řádu, dále pak ruční přidání pohybu nebo vytvoření (aktualizace) pohybu na základě informací zaslaných z ŘLP prostřednictvím FMTP protokolu. Ve čtvrté kapitole popisuji zprávy odesílané z ŘLP a jejich zpracování. Následně pak odesílaní zprávy na ŘLP a stručněji systém, přes který se komunikuje. Popis FIDS systému je uveden v páté kapitole. Jedná se zejména o informační obrazovky a jejich propojení na pohyby. Dále pak administrační rozhraní pro definici nových obrazovek. V závěrečné kapitole shrnuji výsledky práce a uvádím praktické uplatnění tohoto systému, který je v současné době nasazen na mezinárodním letišti v Karlových Varech. Na závěr uvedu některé další možnosti a výhled do budoucna. Stručný popis některých technologií, které jsem při vývoji použil a postup testování celého IS uvádím v dodatku A a B.

2. Analýza a návrh systému

9

2. Analýza a návrh systému V této části se pokusím definovat požadavky, které jsou kladeny na komplexní informační systém, použitelný pro letiště střední velikosti. Podotýkám, že informace ze kterých jsem čerpal, nejsou mnou nijak vymyšlené, ale vznikly po konzultaci s experty na problematiku letištního provozu, zvláště pak s Ing. Otou Kadlecem, který má více než 17 let praxe s řízením pozemního provozu na letišti na pozici operations manager (vedoucí přepravního provozu). Vzhledem k tomu, že systém je určen především pro letiště střední velikosti, tak informace které zde popisuji se týkají především letišť Brno-Tuřany (LKTB) a Karlovy-Vary (LKKV). U větších letišť typu Praha-Ruzyně tyto problémy samozřejmě nejsou, protože se zde používají velké informační systémy, které jsou mnohonásobně složitější než zde popisovaný systém, stejně tak nároky na takovéto systémy jsou jiné. Jejich cena je však natolik vysoká (řádově desítky miliónů), že si je letiště střední velikosti jako např. Karlovy-Vary nemohou dovolit.

2.1.

Současný stav informačních systémů na letištích

Když jsem poprvé položil dotaz ohledně současného stavu informačních systémů na letištích, dostal jsem velmi jednoduchou odpověď: „Dohromady nefunguje pořádně nic“. V podstatě na žádném z letišť v ČR (vyjma letiště Praha-Ruzyně, které je mimo tuto analýzu) nefungoval komplexní informační systém. Funguje například SITATEX, prostřednictvím kterého se předávají různé provozní zprávy, např. SCR zprávy, což jsou požadavky letecké společnosti na lety (podrobněji v [KAD04]). Jenomže další problémy, jako zpracování těchto zpráv a koordinace letů vzešlých z SCR zprávy, řešeny nejsou. Na některých letištích funguje systém FIDS, ale pouze způsobem, že se ručně zadávají data, která jsou pak zobrazovány na informační panely. Správně by se veškeré informace měly automaticky získávat z pohybů. Handlingový systém, kterým se účtují poskytnuté služby letadlu také nepracuje tak jak by měl. Např. na letišti v Karlových Varech byla před nasazením našeho informačního systému situace následovná. Existoval systém Handling, do kterého bylo třeba ručně zadat všechny údaje o pohybu, dále bylo třeba vybrat jednotlivé služby, které byly letadlu poskytnuty a tyto služby převést do účetního systému Abra Gx, který letiště používá. Tento převod musel být proveden ručně, protože neexistovalo žádné propojení mezi programem Handling a účetním softwarem Abra Gx. Posledním ze systémů, který se používá a který relativně funguje, je odbavovací systém SITA DCS. Tady je problém stejný jako u ostatních systémů, které pracují odděleně. Systém SITA DCS nepřebírá data z pohybů a informace z něj nejsou nijak předávány na FIDS (např. informace cestujícím, že na přepážkách 5,6 začíná odbavení linky OK1234 do Londýna).

2.2.

Komplexní informační systém, požadavky

Od popisu současného stavu přecházíme k tomu, jak by asi měl komplexní informační systém letiště vypadat. Idea takové systému je taková, že žádné informace se nebudou zadávat vícekrát, nebudou duplicitní a pokud možno nebude obsahovat žádné oddělené systémy. V tomto případě myslím odděleným systémem něco, s čímž nejde komunikovat a čemu nelze předávat data automaticky (tzn. musí se zadávat ručně). Jelikož takovýto systém je velmi rozsáhlý, tak se počítá s řadou komponent pracujících na různých počítačích (serverech) v různých sítích a s různými operačními systémy, avšak všechny tyto komponenty spolu musí navzájem komunikovat.


2.3.

10

Komponenty informační systému

Na obrázku 1.1. jsou znázorněny základní komponenty, které by měl informační systém obsahovat. Systém se dá v podstatě rozdělit na 6 hlavních částí, kterými jsou letové řády a koordinace (PLAN), pohyby (MVTS), informace a informační displeje (FIDS), poskytování služeb (HANDLING), odbavení (DCS) a souhrnné statistické informace o provozu (STATS). První částí jsou letové řády a koordinace. Nový letový řád lze vytvořit pouze na základě přijaté SCR zprávy prostřednictvím meziletištní sítě SITA. Na základě informací přijatých touto zprávou, je aktualizován letový řád a koordinátor musí povolit či zamítnout požadavky na požadované lety. Toto je prvotní informace, ze které musí čerpat další moduly. 24 hodin před plánovaným časem letu (tj. časem uvedeným v letovém řádu), začíná uskutečňování daného letového řádu. Tím je pohyb letadla. Pohyb je zdrojem pro ostatní moduly systému včetně FIDS, který z pohybu získá aktuální informace pro cestující (např. linka, destinace, čas apod.). Dále pak modul HANDLING, který přebírá informace o letadle (např. MTOW letadla pro vyúčtování přistávacích poplatků).

Obr. 2.1. Komponenty informačního systému

2.3.1. Letové řády a koordinace letů (PLAN) Letové řády vyjadřují plán nějaké činnosti, tzn. že veškeré informace v nich jsou pouze předběžné. Jsou důležité nejen pro cestující, kteří využívají veřejný letový řád k vyhledání letu do určité destinace (nebo z destinace). Důležité jsou hlavně pro interní pracovníky letiště, např. při rozdělování služeb pracovníků oddělení výpravna či technického


11

provozu apod. Letové řády se týkají hlavně velkých leteckých dopravců, kteří komunikují s letištěm prostřednictvím sítě SITA. Každý letový řád je vytvořen na základě požadavku letecké společnosti, který přijde jako SCR zpráva přes SITA. Jakmile je zpráva (požadavek) zpracována, přechází se na koordinaci letů. V té je potřeba zkontrolovat, zda-li je v danou dobu možné tyto lety akceptovat (např. z kapacitních možností letiště). Pokud je lze akceptovat, tak se odešle potvrzovací zpráva, pokud nelze vyhovět nabídnou se alternativní časy letu a odešle se odpovědní SCR zpráva. Komunikace pomocí SCR zpráv je podrobněji popsána v materiálu společnosti IATA s názvem Standard Schedules Information Manual [IATA03]. 2.3.2. Pohyby, informace o aktuálním provozu (MVTS) Pohyb je uskutečněním letového řádu. Informace o pohybu se získávají z plánu (letového řádu), nebo na základě informací od řízení letového provozu (ŘLP). Tyto informace musí být průběžně aktualizovány. Další možností je zadat informace o pohybu ručně. Tento modul je podrobněji popsán v kapitole 3. 2.3.3. Poskytování služeb, účtování (HANDLING) Ke každému pohybu je třeba evidovat služby, které mu byly poskytnuty. Některé služby je potřeba účtovat automaticky (např. přistávací poplatky) a některé pouze ručně přidávat. Handling musí umožňovat komunikaci s účetním systémem letiště, pro který jsou poskytnuté služby a informace o pohybu hlavními podklady pro následné vyúčtování. 2.3.4. Informace a informační displeje (FIDS) Všechny informace o letových řádech a pohybech je potřeba dále předat cestujícím a ostatním složkám, které je vyžadují. K tomu se používají systémy, které se souhrnně odznačují jako FIDS – Flight Information Display System. Jedná se především o informační obrazovky (LCD či plasma displeje) ve veřejných prostorách, jakými jsou např. odbavovací a příletové haly, tranzitní haly apod. Dále pak různé informační kiosky, zobrazení informací o letových řádech a aktuálních pohybech na Internetu. 2.3.5. Odbavení (DCS) Odbavovací systém (DCS – Departure Control System) je pravděpodobně nejsložitější ze zde popisovaných komponent informačního systému letiště. Jde především o odbavení cestujících, jejich zavazadel a letadel. Zahrnuje výpočet tzv. loadsheetů – což je v podstatě výpočet jak rozložit zavazadla v letadle, dále pak systém posílání zpráv přes SITA (podobně jako u letových řádů). Tato část systému je nejsložitější hlavně z důvodů napojení a spoluprácí s množstvím dalších zařízení jakými jsou váhy a tiskárny zavazadlových přívěsků a palubních vstupenek na odbavovacích přepážkách, další informační displeje (rozšíření FIDS), terminály na GATE. 2.3.6. Souhrnné statistické informace o provozu (STATS) V této komponentě je třeba zpracovat všechny statistické informace, které jsou požadovány jak letištěm, a povinné statistiky požadované společnostmi ACI, EUROSTAT a ICAO.

2.4.

Jednotlivé etapy vývoje a části implementované v této práci

Jak je vidět z popisu komponent, které by měl komplexní informační systém obsahovat, by byl podrobnější popis návrhu a implementace všech těchto komponent nad rámec této diplomové práce. Většinu zde popisovaných komponent jsem navrhnul i


12

implementoval. Jedná se hlavně o základní strukturu systému a komponenty PLAN, MVTS, FIDS a HANDLING. Komponentu STATS implementoval Jiří Kadlec [KADJ07]. Dále využíváme některé komponenty implementované třetími stranami jako například komunikační protokol FMTP pro spojení se systémy ATC. V první etapě vývoje tohoto informačního systému bylo úkolem implementovat základní části systému (datové struktury, administrační nástroje apod.) a moduly PLAN, MVTS a FIDS. Druhá etapa se týkala rozšíření o systém poskytování služeb HANDLING, propojení na účetní systém a implementace speciálního rozhraní využívajícího RMI-IIOP, Java-OLE bridge (ComfyJ) a OLE. V současné době jsou etapy I. a II. nasazeny v provozu. Etapa III. která obsahuje odbavovací systém (DCS) je plánována. V této práci popisuji podrobněji implementaci komponent MVTS a FIDS.

2.5.

Případy užití – use case

Obr. 2.1. Komponenty informačního systému


13

2.5.1. Popisy případu užití Jelikož jsou popisy případu užití příliš dlouhé a zabraly by mnoho prostoru, tak zde pro ilustraci prezentuji pouze jeden. Na následujícím obrázku je vidět jeden z popisů případu užití. Konkrétně se jedná o případ užití „vytvoření pohybů z LR“.

Obr. 2.2. Popis případu užití – vytvoření pohybu z LR

2.6.

Datový model – kostra

Vzhledem k tomu že celý datový model má cca 100 entit, tak uvádím pouze zjednodušený datový model (kostru), která ukazuje nejdůležitější entity a vazby. 29 FIDS_Panel FIDS 34

TypPax SFPLzprava Typ_letu

Nabidka SCRodchozi SCRprichozi 35 0,n

Typ_letadla 1

30

PocetPax

2 10

11

17

19 SFPL Pohyb

SCRprichoziRadek Plan (Letovy rad)

SCRodchoziRadek

0,n

20

Letadlo

(D)

22

32 31

27

SFPLodchoziZprava

24

25

Status

18

0,n

3 0,n

Spolecnost StatusNasledujici 4

21

23

0,n 0,n

Inheritance_1 Subjekt

PohybStatusHistory Osoba Inheritance_2

Letiste

14

Stat 8

5

6 16 Stat_kody

15

Obr. 2.2. Kostra datového modelu


14

2.6.1. Popis entit FIDS Objektem typu (#FIDS) je každá dodatečná informace o pohybu, která má být zobrazena na informačních panelech pro cestující. FIDS_panel Objektem typu (#FIDS_panel) je každá konfigurace konkrétního informačního displeje. Letadlo Objektem typu (#Letadlo) je každý jednoznačně určený létající objekt, který má přidělenou imatrikulační značku. Letiste Objektem typu (#Letiste) je každá společností ICAO oficiálně stanovená plocha, určená ke startu a přistání letadla. Nabidka Objektem typu (#Nabidka) je každá množina alternativních časů pro letový řád, určená koordinátorem letů. Osoba Objektem typu (#Osoba) je každá fyzická osoba, která prostřednictvím daného letadla provádí na letišti nějaký pohyb. Plan (Letovy rad) Objektem typu (#Plan) je každý předem naplánovaný let letadla. V tomto případě se objektem typu plan myslí jeden plánovaný let (přílet, odlet). Seznam takovýchto letů tvoří letový řád. Pohyb Objektem typu (#Pohyb) je každý konkrétní let letadla či výcvik. SFPL Objektem typu (#SFPL) je každá hlavička SFPL zprávy, která byla přijata ze systému řízení letového provozu (ŘLP). SFPLzprava Objektem typu (#SFPLzprava) je každý obsah SFPL zprávy, která byla přijata ze systému řízení letového provozu (ŘLP). SFPLodchoziZprava Objektem typu (#SFPLodchoziZprava) je každý obsah SFPL zprávy, která je byla odeslána systému řízení letového provozu (ŘLP). SCRprichozi Objektem typu (#SCRprichozi) je každá hlavička příchozí SCR zprávy rozdělená na jednotlivé pole dle specifikace IATA SCR.


15

SCRprichoziRadek Objektem typu (#SCRprichoziRadek) je každá položka(požadavek) příchozí SCR zprávy, rozdělená na jednotlivé pole dle specifikace IATA SCR. SCRodchozi Objektem typu (#SCRodchozi) je každá hlavička odpovědní SCR zprávy, rozdělená na jednotlivé pole dle specifikace IATA SCR. SCRodchoziRadek Objektem typu (#SCRodchoziRadek) je každá položka odpovědní SCR zprávy ,rozdělená na jednotlivé pole dle specifikace IATA SCR. Položka odpovědní SCR zprávy znamená: odpověď na položku příchozí SCR zprávy. Spolecnost Objektem typu (#Spolecnost) je každá právnická osoba, která má přidělený IČO popř. DIČ. Stat Objektem typu (#Stat) je každá země světa, která má přidělený kód v souladu s celním zákonem ČR. Stat_kody Objektem typu (#Stat_kody) je každý registrační kód letadel přidělený určitému státu. Status Objektem typu (#Status) je každý možný stav v jakém se letadlo může nacházet. Subjekt Objektem typu (#Subjekt) je každá osoba nebo společnost, jíž má smysl evidovat pro potřeby letiště. Typ_letadla Objektem typu (#Typ_letadla) je každý létající objekt definovaný organizacemi IATA a ICAO. Typ_letu Objektem typu (#Typ_letu) je každý druh letu specifikovaný organizací IATA v dokumentu SSIM. TypPax Objektem typy (TypPax) je každý typ cestujících, který má smysl evidovat (muži, ženy, děti, kojenci) PocetPax (Asociativní) Objektem typu (#PocetPax) je každá reprezentace vazby mezi TypPax a Pohybem ve smyslu: (#Pohyb), ve kterém je dané (množství) cestujících daného (#TypPax)./0,1:0,M


16

PohybStatusHistory (Asociativní) Objektem typu (#PohybStatusHistory) je každá reprezentace vazby mezi Statusem a Pohybem ve smyslu: Stavy (#Status), ve kterých se nalézaly dané (#Pohyby)./0,M:0,M StatusNasledujici (Asociativní) Objektem typu (#StatusNasledujici) je každá reprezentace vazby mezi Statusem a Statusem ve smyslu: (#Status) pohybu, který se může pro daný (Typ pohybu) změnit pouze na dané stavy (#Status)./0,1:0,M

2.6.2 Vazby Ref: 1 Konkrétní letadla (#Letadlo) určená daným typem letadla (#Typ_letadla). /0,N:1,1 Ref: 2 Plánovaný typ letadla (#Typ_letadla), kterým se uskuteční daný let (#Plan). /1,1:0,N Ref: 3 Subjekt (#Subjekt), který je provozovatelem daného letadla (#Letadlo). /1,1:0,N Ref: 4 Letecká společnost (#Spolecnost), která si objednala daný let (#Plan). /1,1:0,N Ref: 5 Subjekty (#Subjekt) patřící do daného státu (#Stat). /0,N:1,1 Ref: 6 Kódy (#Stat_kody) registrací přidělené danému státu (#Stat). /0,N:1,1 Ref: 8 Letiště (#Letiste) nacházející se na území daného státu (#Stat). /0,N:1,1 Ref: 10 Nabídky (#Nabidka) alternativních časů pro daný let (#Plan). /0,N:1,1 Ref: 11 Naplánovaný typ letu (#Typ_letu) pro uskutečnění daného letu (#Plan). /1,1:0,N Ref: 14 (#Pohyb) uskutečněný z/na dané (#Letiště). /0,N:1,1 Dle IATA letiště orig/dest (výchozí u příletu / cílové u odletu) - nepovinné. Ref: 15 (#Subjekt), který provádí daný (#Pohyb)/ 1,1:0,N


17

Ref: 16 (#Pohyb) uskutečněný z/na dané (#Letiště). /0,N:1,1 Dle IATA letiště prev/next (předchozí u příletu / další u odletu). Ref: 17 Příchozí SCR zpráva (#SCRprichozi), která obsahuje dané položky (#SCRprichoziRadek): 1,1:0,N Ref: 18 (#Status) v jakém se nachází dané pohyby (#Pohyb) / 1,1:0,N Ref: 19 Odchozí SCR zpráva (#SCRodchozi), která obsahuje dané položky (#SCRodchoziRadek): 1,1:0,N Ref: 20 Odpovědi (#SCRresponse) na daný požadavek (#SCRrequest)/ 0,N:1,1 Ref: 21 Let (#Plan) naplánovaný na dané (#Letiště). /0,N:1,1 Dle IATA letiště prev/next (předchozí u příletu / další u odletu). Ref: 22 (#SCRprichozi), ze které byly vygenerovány(aktualizovány) dané lety v (#Letovy_rad) /1,1:0,N Ref: 23 Let (#Plan) naplánovaný na dané (#Letiště). /0,N:0,1 Dle IATA letiště orig/dest (výchozí u příletu / cílové u odletu) - nepovinné. Ref: 24 Let z (#Plan), který doplňuje dvojici k danému letovému řádu (odlet k příletu, přílet k odletu)/ 0,1:0,1 Ref: 25 Historický let (#Plan) k danému letu (#Plan) z letového řádu/0,1:1,1 Ref: 27 (#Pobyb), který je realizací daného letu (#Plan)/0,1:0,1 Ref: 29 (#Letadlo), kterým se uskutečňují dané (#Pohyb)/0,1:0,N Ref: 30 Příchozí SFPL zpráva (#SFPL), která obsahuje dané položky (#SFPLzprava): 1,1:1,N Ref: 31 Odchozí SFPL zpráva (#SFPLodchozi), která obsahuje dané položky (#SFPLodchoziZprava): 1,1:1,N

2. Analýza a návrh systému Ref: 32 (#Pohyb), ke kterému přišla daná SFPL / 1,1:0,1 Ref: 33 (#Pohyb), ke kterému byla odeslána daná odchozí SFPL (SFPLodchozi) / 1,1:0,1 Ref: 34 Typ letu (#Typ_letu) jakým se uskutečňuje daný (#Pohyb). /1,1:0,N Ref: 35 (#Pohyb) pro který byly zadány doplňující informace pro FIDS (#FIDS)/1,1:0,N

18

3. Pohyby

19

3. Pohyby 3.1.

Definice pojmu pohyb letadla, jednotlivé druhy

Pohybem letadla se rozumí každá činnost letadla na letišti. Dělí se na základní 3 druhy, kterými jsou přílet, odlet a místní činnost (většinou výcvik). Místní činnost je speciální druh pohybu, který může obsahovat několik příletů i odletů, které se označují jako FULL STOP (letadlo přistane a zase odletí). Dále obsahuje tzv. letmé přistání – TOUCH AND GO a průlety LOW APPROACH. Každý pohyb začíná plánem, tzn. že je buď pohyb vytvořen na základě informací z letového řádu (tzv. dlouhodobí plán) nebo je pohyb vytvořen ručně na základě požadavku subjektu. Další možností vytvoření pohybu je informace o letu z řízení letového provozu. Pokud tato informace přijde a čas odletu (z ADEP letiště) v ní obsažený je starší než aktuální čas, tak se pohyb vytvoří ve stavu letí. V opačném případě, kdy odlet ještě nenastal, se pohyb vytvoří ve stavu plán. Další informace o stavech pohybu jsou popsány v následujících odstavcích.

3.2.

Přílet, odlet a místní činnost – stavové diagramy

Že se každý pohyb či letadlo, které jej provádí, musí nalézat v určitém stavu je zřejmé. Je potřeba nejen tyto stavy nalézt a definovat, ale určit i vazby mezi nimi. Vazbou mezi stavy je myšleno do jakých stavů se lze z aktuálního stavu dostat. Stavy, ve kterých se mohou pohyby nalézat: Nástup – nástup cestujících do letadla Odbavení – odbavení cestujících, nákladu a letadla Divertoval – letadlo odletělo na jiné letiště než bylo plánováno Letí – letadlo je ve vzduchu letí směrem k nám(přílet) či od nás (odlet) Přisál – letadlo přistálo Plán – pohyb je ve fázi plánu (letadlo ještě nezačalo uskutečňovat pohyb) Připraven ke startu – letadlo je odbaveno a splnilo všechny podmínky pro připuštění ke startu Poslední výzva – poslední výzva pro cestující aby si nastoupili do letadla Uzavřený – pohyb byl ukončen a vyúčtovány všechny služby. Tento stav je koncový. Nakládání – naložení nákladu popř. pošty nebo zavazadel do letadla Vykládka – výstup cestujících a vykládka nákladu

3.2.1. Přílet Následující stavový diagram popisuje vztahy mezi jednotlivými stavy na příletu, podmínky přechodu a akce, které se s přechodem vykonávají. Jako všechny ostatní UML diagramy byl tento diagram vytvořen pomocí nástroje Visual Paradigm for UML. Situace u příletů je poměrně jednoduchá. Každý přílet začíná buďto plánem nebo informací z ATC, že letadlo již letí. Následně letadlo přistane na našem letišti nebo kvůli jiným okolnostem (např. počasí apod.) přistane jinde (divertuje). Po přistání následuje vykládka letadla nebo je pohyb rovnou ukončen a vyúčtován.

3. Pohyby

20

nově naplánovaný let / vytvorPohyb

Plán

SFPL zpráva od ŘLP, ruční zadání / vytvorPohyb

Letí

přišlo info o letu / nastavit skutečný čas Divertoval info o přistání jinde

info o přistání jinde info o pokračování v letu po diverzi

všechny pož. data zadána / uzavreny = 1

přišel ATA čas, nebo info o přistání / casSkut = ATA

všechny pož. služby a data zadány / vyuctuj, uzavřeny = 1 všechny pož. data zadána / vyuctuj, uzavreny = 1 Vykládání

požadavek na další služby / pridejSluzbu

Přistál



Obr. 3.1. Stavový diagram - přílet 3.2.2. Odlet Další stavový diagram popisuje vztahy mezi jednotlivými stavy na odletu, podmínky přechodu a akce, které se s přechodem vykonávají. Plán informace o plánu na odlet / vytvorPohyb začátek poskytování služeb / informuj cestující Nástup

Odbavení (Služby) nástup cestujících / informuj cestující požadavek naložení nákladu

x min do odletu / informuj cestující

odbavení ukončeno / vyúčtuj

Poslední výzva Nakládání

nástup ukončen / vyúčtuj

nakládka ukončena / vyúčtuj

Připraven ke startu

ATD čas z ŘPL že odletělo / nastav skutCas = ATD

Letí

info o přistání jinde

všechny pož. data zadána / uzavreny = 1 Divertoval všechny pož. data zadána / uzavreny = 1

Obr. 3.2. Stavový diagram - odlet

3. Pohyby

21

3.2.3. Místní činnost Místní činnost je speciálním případem pohybu, ve které je v podstatě spojen přílet i odlet a může se opakovat. Jedná se zpravidla o výcvik, technické testy nebo vyhlídkové lety. Na rozdíl od příletu a odletu nemá plánovaný a skutečný čas, ale má čas začátku a konce. Mezi těmito časy je možné provádět činnost v okruhu letiště. Každá místní činnost začíná buďto plánem nebo informací z ATC o začátku místní činnosti (zpráva, že letadlo již letí na naše letiště a bude tu provádět místní činnost). Může začít jak příletem, tak i odletem, stejně tak je možné jakkoliv činnost ukončit. Letadlo může ukončit činnost přistáním u nás, což je nejběžnější způsob, nebo odletět na cizí letiště, což je bráno jako diverze. Po této diverzi (odletu na jiné letiště) se může letadlo vrátit a pokračovat v místní činnosti. Celkově je místní činnost dost nesystematická, protože vzniká např. problém jak účtovat a zdali připustit letadlo ke startu či ne. U odletu je tato situace jednoduchá. Pokud je letadlo odbaveno a majitel/provozovatel nezaplatí, tak není povolen start (stav připraven ke startu) tzn. že na systémy ATC se nepošle zpráva, že je letadlo připraveno ke startu a tím pádem nebude umožněn letadlu odlet. Nebo se pošle zpráva, že letadlo nemá zaplaceno (konkrétně bude tento systém realizován na základě domluvy provozovatele letiště a řízení letového provozu). Kapitola handling a účtování je však nad rámec této práce, tak se tímto problémem dále zabývat nebudeme. info o naplánování místní činosti

info o prováděné místní činosti

pokračování v letu po diverzi

aktualizace pohybu

Plán

místí činost zahájena / nastavitZacatek

Letí

start povolen

info o přistání jinde

Divertoval

ukončení části místní činosti

info o další činosti

info o návratu po diverzi

Přistál

přistání bez info o letu poskytnutí služeb info o další činosti

požadavek na služby

Vykládání končí / vyúčtování, uzavreny = 1

Odbavení

Nástup odb ukonč. / informuj cestující

končí / vyúčtování, uzavreny = 1

x min do odletu / informuj cestující Poslední výzva

všechny pož. data zadána / vyuctuj, uzavreny = 1

pokračuje v místní činosti / doúčtováni

odbavení ukončeno / vyuctuj nástup ukončen / vyúčtuj Připraven ke startu služby neposkytovány / začni místníi činost

pokračuje v místní činosti / doúčtování

končí / vyúčtování, uzavreny = 1

Obr. 3.3. Stavový diagram – místní činnost K těmto základním stavům existují ještě další doplňkové stavy, kterými jsou dle plánu, zpožděný a zrušený. Tyto doplňkové stavy mohou být u kteréhokoliv základního stavu. Např. letadlo může být zpožděné ve stavu letí, i při odbavení, nakládání apod. Stejně tak může být let např. zrušen. Ke každému stavu jsou definovány kritéria(podmínky), za jakých je možné do tohoto stavu přejít. Např. pokud chceme nastavit stav letí, tzn. že konkrétní letadlo je již ve vzduchu, musíme mít v pohybu nastavenou imatrikulaci tohoto letadla apod. Tyto kritéria se také vážou na typy letů, které jsou definované dle IATA. Např. pokud je typ letu Cargo/Mail, tak musíme mít v pohybu zadáno množství přepraveného nákladu/pošty.

3. Pohyby

3.3.

22

Typy letů a kritéria pro nastavení stavu

Každý pohyb, který reprezentuje konkrétní let musí být určitého typu, podle toho za jakým účelem je prováděn. Například přeprava cestujících, nákladu, pošty, nebo pouze prázdné přelety či jiné speciální lety. 3.3.1. Jednotlivé typy letů: Additional Flights (doplňkové lety) Cargo/mail - doplňkové lety přepravující náklad nebo poštu Passenger (Shuttle) - doplňkové lety přepravující cestující v tzv. Shuttle režimu Passenger (Normal) - doplňkové lety přepravující cestující v normálním režimu Passenger/Cargo - doplňkové lety přepravující cestující a/nebo náklad Charter (charterové) Passenger only – standardní charterové lety s cestujícími Cargo and/or Mail – charterové lety přepravující náklad a/nebo poštu Passenger and Cargo and/or Mail – charterové lety přepravující cestující, náklad a/nebo poštu Charter requiring special handling – charterové lety požadující speciální handling – tzn. určité speciální služby nebo přepravuje speciální náklad Scheduled (plánované) Cargo/mail - plánované lety přepravující náklad a/nebo poštu Passenger - (Normal) - plánované lety přepravující cestující v normálním režimu Cargo/mail (only mail) - plánované lety přepravující pouze poštu Passenger/Cargo in cabin PAX cum freighter - plánované lety přepravující náklad v kabině Passenger - (Shuttle) - plánované lety přepravující cestující v tzv. Shuttle režimu Others (ostatní) Special – ostatní lety přepravující nějaké výjimečné osoby vyžadují zvláštní pozornost (např. FAA, vládní lety apod.) Training - výcvikové a vyhlídkové lety Non-revenue – neziskové lety (např. Positioning, kdy se letadlo pouze přesouvá bez cestujících a nákladu), technické testy apod. Military – vojenské lety Technical Stop

Další podrobnosti ke specifikaci typů letů je možné najít v dodatku C dokumentu SSIM [IATA03]. 3.3.2. Kritéria pro nastavení stavu Následující tabulka znázorňuje jaké informace o pohybu musí být zadány, aby mohl být nastaven daný status. Pro názornost uvádím pouze tabulku pro odlet. Další tabulky pro přílet a místní činnost jsou nahrány na přiloženém CD. Dále lze tabulku rozšířit o kritéria pro zadávání typů letu. Například, když je zadán typ letu jako Cargo, tak musí být zadáno množství nákladu, nebo pro lety s pasažéry musí být zadán počet PAX.

3. Pohyby

23

Odlet Pole letiště prev/next letiště orig/dest subjekt letadlo typ letu sfpl typ pohybu RW Y pravidla linka plánovaný čas skutečný čas čas zdroj PAX celkem PAX tranz PAX transf PAX neplatici Mezinarodni Vyučtovany Bag Mail Cargo Skupina Info Auto_Zmena Pozn

Plán + + + + + + K + + + + -

Letí + + + + + + + + S + + + + -

Divertoval Přistál + + + + + + + + S + + + + -

Vykládání Odbavení + + + + + + + + K/S S/S/S/+ + + + -

Nakládání + + + + + + + + + S/S/S/+ + + -

Nástup + + + + + + + + S S/S/S/+ S/S/S/+ + + -

Posl.výzva + + + + + + + + S S/S/S/+ S/S/S/+ + + -

Připr.ke startu Ukončený + + + + + + + + + + + + + + + + + + S S S/S/S/S/S/S/+ + + S/S/S/S/S/S/+ + + + + + -

+ musí být vždy vyplněn - nemusí být vyplněn +/P může být převzat z plánu K - dle kapacity letadla K/S - kapacita nebo skutečnost, je li známa S - skutečnost

Tab. 3.1. Kritéria pro nastavení stavů

3.4.

Informace uložené v pohybech

Při definici, jaká data budou obsahovat pohyby jsem se musel zaměřit nejen na aktuální situaci a na data, které budou využívat komponenty současného systému, ale i na data pro budoucí použití jako například podrobné rozdělení PAX na kategorie. Každý přílet i odlet obsahuje informace o letištích, ze kterých (na které) se odlétá, aktuálním a plánovaném čase, lince apod. Dále obsahuje data, která jsou důležitá např. pro vytváření statistik jako použitou RWY při pohybu, podle jakých pravidel se letělo (IFR – podle přístrojů, VFR – podle „očí“). 3.4.1. PAX a kategorie PAX Při vytváření či úpravě pohybů lze zadávat počet pasažérů (PAX) dvěma způsoby. Prvotní nepříliš přesnou informaci získáváme z letového řádu a tou je celkový počet PAX. Tím je v případě plánu kapacita letadla, takže tento údaj není příliš přesný. Tento údaj lze v pohybech samozřejmě změnit a upřesnit, kolik cestujících z celkového počtu je neplatících, kolik jich je tranzitních a kolik transferových. Toto je základní zadání, které lze zadat přímo v úpravě pohybu a pro uzavření pohybu je nutné. V současné době je tento způsob dostačující, ale v případě rozšíření systému například o DCS je potřeba rozdělit PAX na jednotlivé kategorie. Těmi jsou muži, ženy, děti a kojenci. Každá tato kategorie se dále dělí na celkové, celkové neplatící, tranzit, tranzit neplatící, transfer a transfer neplatící. Například subsystém Loadsheet, podle kterého se počítá vyvážení letadla a rozmístění zavazadel, počítá s různými hmotnostmi pro různé kategorii cestujících. Pokud jsou počty cestujících zadány pomocí druhého způsobu, je možnost zadání pomocí prvního způsobu zablokována. Může se zdát, že možnost dvou typů zadávání cestujících může vytvářet duplicitní data. Je to sice pravda, ale na druhou stranu je v současné době (až na účtování letištních tax)

3. Pohyby

24

dělení PAX na kategorie zbytečné a pouze by obsluhu zdržovalo. Následující obrázek zobrazuje zadávání PAX pro jednotlivé kategorie.

Obr. 3.4. Zadávání PAX rozdělených na jednotlivé kategorie 3.4.2. Plánovaný, skutečný a slot čas Veškeré časy v systému jsou uloženy v UTC a to z důvodu, že všechny systémy jako IATA SCR či systémy ATC pracují v UTC a všechny časy posílají taktéž v UTC. Stejně tak veškeré výpočty v systému se provádí v UTC. Samozřejmostí je, že pro uživatele se tyto časy zobrazují v CET. U každého pohybu, který je vytvořen z letového řádu se automaticky přebírá plánovaný čas. Z něj vychází čas skutečný, který může být a většinou i je v průběhu letu upřesňován např. informacemi z ŘLP nebo ručním zadáním (méně časté). K tomuto času je evidován i zdroj, ze kterého čas přišel. Zdrojem času může být plán (S), ruční zadání (H), ŘLP (A) a nebo ŘLP SLOT (T). Zdroj je důležité evidovat z důvodu priority času. Pokud je např. odeslán z ŘLP slotový čas, tak tento čas nesmí nikdo kromě ŘLP změnit. Pokud ŘLP pošle zprávu, která obsahuje SLC (slot clear – zrušení stotu), je priorita pro slotový čas zrušena. V případě místní činnosti mají tyto časy poněkud jiný význam. Místní činnost se neplánuje, ale začíná určitým časem a určitým časem končí, takže význam časů je začátek a konec místní činnosti. 3.4.3. Historie stavů Každý pohyb se nalézá v určitém stavu (jak je popsáno v 3.2.) a pro každý stav jsou nastavena určitá kritéria (viz 3.3.2.), která musí být splněna, aby mohl být daný status nastaven. Tato kritéria je však potřeba rozšířit (upřesnit), podle toho jaký stav(y) stavu následujícímu předcházel(y). Například pokud chci uzavřít pohyb, tak musím zadat použitou RWY. Musím se však podívat, jaký byl předcházející stav. Pokud byl přistál, tak použitou RWY zadat musím, ale pokud byl stav divertoval (odletěl jinam), tzn. že na našem letišti nepřistál a tudíž nepoužil žádnou RWY, tak není nutné zadávat RWY. Další možností využití historických stavů je pro statistiky apod.

3.5.

Zdroje ze kterých se vytvářejí a aktualizují pohyby

3.5.1. Vytváření pohybů z letového řádu (plánu) Většina „velkých letů“ (lety přepravující velkém množství cestujících či nákladu) je v letovém řádu. Na základě těchto letových řádů jsou vytvářeny pohyby, což se zpravidla děje 24h před plánovaným uskutečněním pohybu. K tomuto slouží tzv. EJB timer service, která

3. Pohyby

25

periodicky po určitém časovém intervalu prohledává letové řády (LR) a pokud v nich najde lety, které mají být uskutečněny v průběhu 24h, tak z nich vytvoří pohyby. Každému takovémuto pohybu je nastaven status na plán a jsou převzaty základní informace z LR, které jsou použity jako plánované a zpravidla se v průběhu uskutečňování pohybu mění. Příkladem může být plánovaný čas, typ letadla či počet cestujících v letadle. Počet cestujících, který je uváděn v LR slouží jako přibližná informace pro koordinaci, kdy je potřeba znát přibližný čas na odbavení letadla. Na následujícím obrázku je pomocí UML Activity diagramu znázorněno generování pohybu z letového řádu.

Cas (EJB Timer)

prejdi na dalsi let

Vyhledej vsechny lety v LR v nasl 24h

lety nalezeny

existuje nepridany let

Podle letu z LR vygeneruj pohyb

Nenalezeny žádné lety

vsechny lety jiz pridany do pohybu

Obr. 3.5. UML Activity diagram – vytvoření pohybu z letového řádu 3.5.2. Manuální vytváření a úprava pohybů Jak již bylo zmíněno většinu informací o letu máme z letového řádu nebo ze systému ATC. Ruční vytváření pohybů není sice příliš časté, avšak je nezbytné. Např. v situacích kdy je na odbavovací ploše letadlo, se kterým někdo přistál a informaci kdy odlétá ještě nemáme. Tento subjekt se po nějaké době „objeví“ a nahlásí na pracoviště odbavení kdy chce odletět. Tuto informaci by systém samozřejmě získal při odletu letadla informací ze systému ATC, ale v tomto případě je potřeba informace o pohybu mít dříve. Např. musíme vyúčtovat služby, které byly letadlu provádějícímu odlet naúčtovány. Pomocí ruční úpravy pohybů lze také nastavit místo stání pro letadlo či určit vjezd pro letadlo a tím informovat ŘLP, kam navádět letadlo. Toto se provádí odesláním SFPL zprávy od provozovatele směrem k ŘLP. Dále viz kapitola 4.2. Na následujícím obrázku je znázorněna obrazovka pro ruční přidávání pohybů.

3. Pohyby

26

Obr. 3.6. Nový pohyb 3.5.3. Automatická úprava pohybů informacemi z ŘLP Informace o novém pohybu či upřesnění přichází nejčastěji ze systému řízení letového provozu (ŘLP). Tato komunikace probíhá zasíláním SFPL zpráv prostřednictvím FMTP protokolu. Bližší informace v kapitole 4.1. Obsahem těchto zpráv jsou například letiště, ze kterých se přilétá či na které se odlétá, plánované a skutečné časy, sloty, nebo u místní činnosti počet provedených touch and go, full stop a low approach. Na základě těchto dat jsou automaticky aktualizovány pohyby, příletové a odletové obrazovky (FIDS).

3.6.

Prohlížení pohybů, hlavní obrazovka pro operátory

Existují dvě základní obrazovky pro získávaní informací z pohybů. Těmi jsou prohlížení pohybů a aktuální pohyby. Prohlížení pohybů slouží pro všechny provozní složky letiště, ale pouze pro získání základních informací o pohybech. Naproti tomu obrazovka aktuálních pohybů obsahuje veškeré dostupné informace o pohybu, včetně možnosti rychlých změn základních údajů (např. nastavení stavu pohybu, nastavení odbavovacích přepážek a gate pro FIDS apod.). Tato obrazovka je určena zvláště pro pracoviště výpravna, kde běží stále a po určitém čase se aktualizuje. Díky tomu jsou operátorům vždy k dispozici aktuální informace s minimálním zpožděním. Na následujícím obrázku je vidět okno pro prohlížení aktuálních pohybů. U jednoho letu jsou zobrazeny podrobnosti.

3. Pohyby

27

Obr. 3.7. Aktuální pohyby

3.7.

Párování pohybů

Vzhledem k tomu, že může nastat případ kdy nelze informaci z ŘLP vyhodnotit přesně, může dojít k vytvoření nového pohybu místo úpravy již existujícího pohybu. Takováto situace může nastat, když je pohyb vytvořen na základě plánu (čili z letového řádu). V takovém případě pohyb obsahuje pouze informaci o lince a ne o konkrétním letadle (imatrikulace). V poli ARCID (aircraft ID), které je odesíláno prostřednictvím SFPL zprávy je uvedena buď imatrikulace letadla nebo linka, pod kterou letadlo letí. Podle tohoto pole systém určuje k jakému pohybu tuto informaci přiřadit. Pokud nenajde hodnotu pole ARCID v linkách již plánovaných pohybů, zkusí pohyb najít podle imatrikulace. Nenajde-li jej, vytvoří se nový pohyb letadla s danou imatrikulací. Jako subjekt, který provádí daný let je implicitně uveden provozovatel letadla. Problém tedy nastává, když máme např. plánovaný let s linkou OK123, ze kterého je vytvořen pohyb. Později nám přijde z ŘLP zpráva o příletu letadla s imatrikulací OK2451. Tím pádem se vytvoří nový let letadla s imatrikulací OK2451. Dále musí obsluha vyhodnotit, že se jedná o identické lety a musí je spojit. K tomu slouží aplikace párování pohybů, ve které se na jedné straně vybere některý z plánovaných pohybů a na straně druhé pohyb vytvořený ze SFPL zprávy. Po výběru letů a potvrzení se plánovaný let se aktualizuje informacemi z letu od ŘLP, které mají vyšší prioritu. Následně je let vytvořený ze SFPL zprávy zrušen. Na následujícím obrázku je screenshot aplikace párování pohybů.

3. Pohyby

28

Obr. 3.8. Párování pohybů

4. Zprávy posílané od ŘLP a směrem k ŘLP

29

4. Zprávy posílané od ŘLP a směrem k ŘLP V předcházejících kapitolách bylo napsáno, že informace o aktuálních pohybech přichází jako SFPL zpráva odeslaná ze systému řízení letového provozu. V následujících odstavcích stručně popíšu způsob posílání zpráv a některá důležitá data obsažená v této zprávě.

4.1.

FMTP protokol, komunikace se systémy ŘLP

Komunikace probíhá tak, že ALS systém umístěný na ŘLP odesílá formalizovanou SFPL zprávu k provozovateli letiště. K přenosu těchto zpráv je určen speciální FMTP protokol, definovaný společností EUROCONTROL [EGIS05]. Tento protokol je postaven nad TCP/IP, takže není zapotřebí žádný speciální HW (síťové karty, switche apod.) jako u předchozí specifikace FDE. V sítí je umístěn stroj, na kterém běží FMTP server, který tyto zprávy přijímá (Pozn.: implementace FMTP protokolu byla zadána dodavatelské firmě, proto není součástí této práce a dále se jí zabývat nebudeme). Zde se tyto zprávy nezpracovávají, ale odesílají se prostřednictvím JMS do fronty zpráv, která je umístěna na aplikačním serveru na kterém běží celý informační systém letiště. Na tuto frontu je napojen EJB Message Driven Bean, který funguje jako posluchač nad danou frontou a když přijde nová zpráva, tak ji zpracuje, provede potřebné změny v pohybech a následně vygeneruje potvrzovací LAM zprávu. Tato LAM zpráva je odeslána do další JMS fronty, na kterou je napojen posluchač běžící na FMTP serveru, který tuto potvrzovací zprávu odešle systému ŘLP.

4.2.

Příchozí a odchozí SFPL

Každá příchozí SFPL zpráva obsahuje hlavičku ve které je definován jedinečný identifikátor zprávy (SFPLID) a identifikátor letadla/linky ARCID. Vzhledem k tomu, že identifikátor ARCID může být buď imatrikulace letadla nebo linka pod kterou letadlo letí, tak vzniká problém nejednoznačného zařazení letu ze SFPL zprávy (viz odst. 3.5). Dále zpráva obsahuje jednotlivé informace o lety vždy ve dvojici klíč-hodnota. Klíč určuje o jakou informaci jde a hodnota je daná informace. Např. dvojice „–ATA 1150“ říká, že aktuální čas příletu (ATA – actual time of arrival) je v 11.50 UTC. Odchozí SFPL zpráva, kterou odesílá provozovatel směrem k ŘLP, může být odeslána pouze na základě příjmu příchozí SFPL zprávy, ze které získá SFPLID. V odchozí zprávě informuje letiště ŘLP např. o připravenosti letadla k odletu či o umístění letadla na příletu. 4.2.1. Elementy příchozí SFPL zprávy Příchozí SFPL zpráva obsahuje standardní pole (klíče) definované společností EUROCONTROL či speciální pole definované na základě domluvy provozovatelů letišť a řízení letového provozu. V následující tabulce uvedu pouze některá důležitá pole definovaná společností EUROCONTROL. Pole ARCID

ADEP ADES ETA ETD

Formát 2-7 alfanumerických znaků 4 znaky 4 znaky hhmm (čas) hhmm (čas)

Význam Identifikace letadla (imatrikulace) nebo linka pod kterou letí (kód dopravce + číslo letu) ICAO kód letiště, ze kterého se odlétá (departure) ICAO kód letiště, na které se přistává (destination) Předpokládaný čas příletu (estimated time of arrival) Předpokládaný čas odletu (estimated time of departure)

4. Zprávy posílané od ŘLP a směrem k ŘLP ATA ATD FLIGHTRULE ARCTYP

hhmm (čas) hhmm (čas) ‘I’ nebo ‘V’ 4 znaky

30

Aktuální čas příletu (actual time of arrival) Aktuální čas odletu (actual time of departure) Pravidla letu IFR nebo VFR ICAO kód typu letadla

Zpráva může obsahovat další pole informující např. o vzletové a přistávací dráze, o přiděleném slotu či počtu provedených FST, TAG a LA. Bližší informace jsou k nalezení v příloze A3 v dokumentu [ADEXP01]. 4.2.2. Elementy odchozí SFPL zprávy Odchozí zprávou lze informovat ŘLP o stavu připravenosti letadla k odletu nebo o čase, kdy letadlo může odletět (tzn. dveře jsou zavřené a čeká se na pokyn řídícího). Tímto lze například vyřešit problém typu, že provozovatel letadla nezaplatil určité služby. V tom případě se nepovolí nastavení stavu na připraven ke startu a tato zpráva se nepošle řídícímu, který odlet letadla nepovolí. U příletu se odesílají informace o příjezdu letadla a odbavovací ploše na kterou má být postaveno. Tyto zprávy jsou odesílány automaticky podle informací zadávaných do pohybů.

5. FIDS – Flight Information Display System

31

5. FIDS – Flight Information Display System Všechny informace obsažené v pohybech a letových řádech je potřeba dále předat provozním složkám a veřejnosti (cestujícím, cestovním kancelářím apod.). K tomu slouží systém informačních displejů FIDS, který obsahuje i informace dostupné prostřednictvím webových stránek letiště. V první etapě vývoje informačního systému FIDS obsahuje displeje pro zobrazení aktuální příletů a odletů a obrazovky pro zobrazení zprávy pro cestující.

5.1.

Problém informačních obrazovek, řešení

Jako řešení informačních displejů slouží širokoúhlé velkoplošné LCD panely s vysokým rozlišením (HDTV), dovolujícím zobrazit i loga společností a všechny potřebné informace. Každý tento LCD panel je připojen na PC přes VGA či DVI. K jednomu PC lze připojit až 4 panely popř. klasické CRT (ty už se dnes nepoužívají). K zobrazení informací se používá klasický webový prohlížeč spuštěný v tzv. „kiosk“ režimu, který dovoluje zobrazení informací v celo-obrazovkovém režimu bez zobrazení menu, dalších panelů prohlížeče apod. Ačkoli se může zdát, že je toto řešení velmi primitivní, je velmi efektivní a snadno rozšířitelné. Pro všechny obrazovky jsou vytvořeny dvě jazykové mutace (čeština, angličtina), které se po určitém intervalu mění. Stejně tak se po určitém intervalu obnoví celá obrazovka, aby byly zobrazené informace aktuální. V budoucnu se uvažuje o využití technologie AJAX pro získávání aktuálních dat po panely.

5.2.

Administrační rozhraní pro správu a definici nových obrazovek

V IS je vytvořeno rozhraní pro správu FIDS obrazovek, které umožňuje přidávat jednotlivé displeje a určit jaké informace na nich mají být zobrazovány. Zároveň umožňuje obsluze zadávání informačních zpráv na danou obrazovku a to jak v češtině tak i v angličtině. Vzhledem k tomu, že k jednomu PC je možné mít připojeno víc obrazovek a tudíž všechny obrazovky jsou ze systému přístupné jako jedna plocha, tak součástí každé definice obrazovky jsou i x-ové a y-ové souřadnice obrazovky. Poslední ale neméně důležitou informací je zobrazení stavu displeje (zdali běží či ne).

Obr. 5.1. Administrační obrazovka pro FIDS

5.3.

Příletové, odletové a informační obrazovky

Příletové obrazovky obsahují aktuální informace o příletech včetně místa, ze kterého (na které) se odlétá, času (plánovaného i skutečného), linky a loga letecké společnosti. Dále jsou k dispozici informace zdali je let zpožděný nebo zrušený. Navíc lze ke každému letu doplnit informaci či sdělení pro cestující.

5. FIDS – Flight Information Display System

32

Odletové obrazovky obsahují stejné informace jako příletové, ale ještě jsou rozšířeny o další informace týkající se pouze odletu. Jsou to například čísla odbavovacích přepážek a čísla „gate“ pro nástup cestujících. Stejně tak jsou rozšířeny stavy o odlet a nástup. Na následujícím obrázku je vidět odletová obrazovka:

Obr. 5.2. Odletová obrazovka

6. Závěr

33

6. Závěr V této práci jsem se pokusil shrnout požadavky na informační systém letiště střední velikosti v ČR. Dále pak o návrh a implementaci některých z komponent informačního systému letiště. Tento IS včetně zde prezentovaných komponent je v současné době v provozu na mezinárodním letišti v Karlových Varech. V současné době je testována i druhá etapa systému, která obsahuje modul HANDLING. V nejbližší době se předpokládá přechod i druhé etapy do ostrého provozu. Dále předpokládáme rozšíření tohoto informačního systému i na druhé největší letiště v ČR Brno-Tuřany. Myslím si, že tento systém plní svoji roli celkem obstojně a to i vzhledem k tomu, že žádný podobný IS v ČR není, takže při vývoji nebylo možné se např. inspirovat jiným systémem. Tento informační systém také podstatně ulehčuje práci provozních složek letiště např. při koordinaci letů správě pohybů, informování cestujících apod. Na následujícím obrázku je UML diagram nasazení informačního systému na letišti v Karlových Varech. FMTP server (Windows) ATC Systems FMTP

<> FMTP comm

prime - main server (SuSE linux) ABRA comm system (Windows)

AppServer glassfish

Local JVM <> RMI server

<> JMS queue (IN/OUT)

JMS

Remote <> Java-OLE Bridge

<> EJB Module RMI-IIOP

Local Remote

OLE

<> ABRA

<> Web Application

HTTP

<> Web Services N/A

ABRA AppServer WS (SOAP, WSDL...) JDBC N/A

ABRA DB (FIrebird)

FIDS server

Airport Web Server

DB server

Obr. 6.1. Diagram nasazení IS - LKKV

6.1.

Výhled do budoucna

V současné době je etapa I. (PLAN, MVTS a FIDS) plně v provozu a etapa II. (HANDLING, STATS) těsně před ostrým spuštěním. Do budoucna se plánuje etapa III., která obsahuje vytvoření odbavovacího systému. Současný systém a všechny jeho komponenty jsou

6. Závěr

34

připraveny spolupracovat s odbavovacím systémem. Ze všech komponent, zde popisovaných, je však odbavovací systém nejsložitější, jelikož obsahuje velké množství rozhraní a ovladačů pro speciální zařízení jako terminály na gate, tiskárny na check-in, váhy zavazedel apod. Stejně tak rychlost odezvy systému je zde velmi kritická, protože z každé vteřiny ztracené na odbavování cestujícího se při velkém počtu stávají minuty. Proto uživatelské rozhraní III. etapy již není plánováno jako webové, ale jako klasická swingová aplikace. Dále bude potřeba rozšířit vývojový tým, takže možností do budoucna je jistě dost, i když dost náročných.

Literatura

35

Literatura: [ADEXP01] EUROCONTROL: STANDARD DOCUMENT for ATS Data Exchange Presentation, EUROCONTROL 2001 [APACHE07] Apache Software Foundation, Apache MyFaces Tomahawk, document dostupný na URL: http://myfaces.apache.org/tomahawk/index.html [EGIS05] EUROCONTROL: GUIDELINES FOR IMPLEMENTATION SUPPORT (EGIS), Part 5 COMMUNICATION & NAVIGATION SPECIFICATIONS, CHAPTER 13 FLIGHT MESSAGE TRANSFER PROTOCOL (FMTP), EUROCONTROL 2005 [HAINES06] Steven Haines: Pro Java EE 5 Performance Management and Optimization, Apress 2006 [IATA03] International Air Transport Association: Standard Schedules Information Manual, 2003 [KAD04] Ota Kadlec: Informační systém pro letové řády, Fakulta informatiky, Masarykova univerzita, 2004 [KADJ07] Jiří Kadlec: Modul pro zpracování statistik na letišti, Fakulta informatiky, Masarykova univerzita, 2007 [KEITH06] Mike Keith, Merrick Schinariol: Pro EJB 3 Java Persistence API, Apress 2006

Dodatek A

36

Dodatek A Technologie pro vývoj informačního systému A.1. Enterprise Java Beans 3 (EJB3), Java Persistence API (JPA) IS je postaven na aplikačním serveru, který zprostředkovává spojení s ostatními systémy, databázové spojení a spravuje transakce. Aplikační (business) logika IS běží nad tímto aplikačním serverem (v EJB kontejneru). To nám umožňuje oddělení prezentační vrstvy (GUI, web apod.) od logiky. Technologie Java EE 5 je určena zejména pro velké informační systémy, které zpravidla neběží na jednom PC, ale jsou distribuovány mezi různé servery či systémy běžící na různých platformách, využívají různé klienty apod. Schéma vícevrstvé architektury (multitier architecture) je znázorněno na obr. A.1.

Obr. A.1. Schéma vícevrstvé architektury systému podle Java EE 5 Technologie EJB je jedním ze základních stavebních kamenů celé Java EE 5. Vychází z Java RMI (Remote Method Invocation), která umožňuje vzdálené volání procedur (např. v jiné VM). Avšak RMI poskytuje pouze základní funkčnost jakou je lookup do tzv. RMI registry, volání operací a předávání parametrů apod. Neumožňuje např. správu transakcí, přístup k datům apod. K tomu jsou určeny právě EJBs. Ty se dělí na dva základní druhy (3 ve specifikaci 2.1.). Těmi jsou Session Bean – bezstavové a stavové (Stateless, Stateful), MessageDriven Beans. Ve specifikaci 2.1. byly ještě Entity Bean, které sloužily pro persistenci. Ty jsou v EJB3 nahrazeny tzv. POJO objekty (obyčejné java beans s příslušnými anotacemi), kterým se říká Entities. EJB3 samozřejmě Entity Beans podporuje, ale hlavně z důvodu zpětné kompatibility. Session beans většinou poskytují určené služby klientským aplikacím. Jejich „životnost“ závisí na době spojení klienta se session beanem. Stavové SBs mohou navíc během spojení uchovávat stav. Entity beans a entities reprezentují nějaké objekty zájmu jako např. Letadlo, Letiště apod. a jsou ukládány do DB. Třetí kategorií jsou tzv. Message driven beans, které „poslouchají“ (čekají na zprávu) nad určitou frontou (JMS message queue). Na základě příjmu zprávy provádí nějakou akci. V našem IS je to např. příjem zprávy z FMTP serveru, který zprávu přijal od ŘLP a dále ji posílá do dané message

Dodatek A

37

queue. To je výhodné, protože systém nemusí znát, kde se nachází FMTP server, protože všechny data přebírá z dané fronty. Stejně tak když IS odesílá zprávu směrem k ŘLP, tak nemusí znát polohu FMTP serveru, ale zprávu uloží do druhé fronty (výstupní). FMTP server získá odkaz na danou frontu přes JNDI. Velkou výhodou je také otevřenost celé této technologie a to nejenom možnost provozu systému na různých platformách, ale taky spolupráce s jinými systémy, jazyky apod. Modul FMTP serveru, který pro nás implementovala dodavatelská firma je vytvořen v prostředí Microsoft Visual Studio v programovacím jazyce Visual C++. Tím pádem běží na OS Windows. S IS bez problémů komunikuje přes JMS a to díky JMS C-API. Data IS jsou uložena v relační databázi, ke které se přistupuje pomocí rozhraní JDBC. To nám však umožňuje pouze klasický přístup do DB s použitím SQL. Existuje však možnost tyto data namapovat na objekty pomocí tzv. ORM (Object-Relational Mapping). V Java EE 5 k tomu složí standard JPA, který je součástí specifikace EJB3 a jehož referenční implementací je Oracle TopLink. Díky tomu lze s daty pracovat objektově i nad relační databází. JPA dále obsahuje speciální dotazovací jazyk nad, který se označuje jako JPA QL. Tento jazyk vychází z předchůdce EJB QL, ale oproti němu je výrazně rozšířen (např. ve specifikaci EJB2.0 nepodporoval QL ani klauzuli ORDER BY). Pro další informace ohledně JPA doporučuji publikaci Pro EJB 3: Java Persistence API [KEITH06].

A.2. Java Server Pages, Servlets Java Server Faces Java Server Pages a Servlety jsou dvě základní možnosti jak v Javě generovat dynamický obsah na webu. JSPs jsou v textové dokumenty obsahují značky (taky) podobně jako HTML dokumenty. Po nasazení aplikace (deploy) se tyto JSPs stránky překládají do servletů. Když přijde http požadavek na danou jsp stránku (servlet), tak se z něj vytvoří html dokument, který je vrácen uživateli. Poměrně často se říká, že uživatelský komfort je lepší u aplikací s tlustým klientem (např. Swingová aplikace) než u aplikací webových. Je to zapříčiněno hlavně delší dobou odezvy u http požadavků, ale i samotným uživatelským rozhraním. JSF je komponentové API, které umožňuje jednoduše vytvářet uživatelská rozhraní (UI). Komponentou u JSF se myslí konkrétní značka (tag), pomocí kterého lze vytvořit danou část UI (ne však prezentační část). Samotné JSF komponenty žádné GUI nevytvářejí. K tomu slouží tzv. renderers. Takže můžeme mít napsané UI v JSF které chceme zobrazit ve webovém prohlížeči na PC, tak použijeme standardní HTML renderer, ale pokud chceme použít jiné zařízení, u kterého chceme mít jiné zobrazení je potřeba použít tzv. custom renderer. JSF komponenty jsou většinou spojeny se servlety či JSPs. Zde je jejich použití nejčastější. Vývojáři JSP stránek ulehčí spoustu práce s psaním HTML kódu, který se dokáže z dané komponenty vygenerovat. JSF dále usnadňuje navigaci, propojení na java beans, ukládání stavu apod. V této práci jsou použity jak standardní komponenty dodávané s aplikačním serverem SUN, ale i další JSF komponenty z Tomahawk od Apache či ze SUN blueprints. Pro názornost uvádím příklad použití komponent Calendar z Apache Tomahawk. Na prvním obrázku je zápis ve zdrojovém kódu v JSP stránce včetně lokalizačních řetězců pro dny, týdny apod.

Obr. A.2. Použití JSF komponenty Calendar

Dodatek A

38

Na dalším obrázku je zobrazen výsledek v HTML.

Obr. A.3. Použití JSF komponenty Calendar – výstup v HTML Další užitečnou JSF komponentou je tzv. autocompetition (automatické doplňování textu). Např. při vytváření pohybu se vybírá letiště a imatrikulace letadla. V databázi je víc než 10000 letišť, takže výpis celého seznamu by byl dost neefektivní, z toho důvodu je pro výběr letiště a letadla podle imatrikulace použitá autocompetition komponenta. Na následujícím obrázku je zobrazena autocompetition komponenta (včetně zápisu ve zdrojovém kódu) pro výběr letiště podle ICAO.

Obr. A.4. Autocompetition pro letiště

Dodatek B

39

Dodatek B Testování funkčnosti a výkonu B.1. Testování funkčnosti Testování výsledného IS bylo rozdělené na dvě části. První byly automatické testy pomocí JUnit přes vzdálené rozhraní (remote interface) a tou druhou uživatelské testy a validace, jestli program splňuje požadavky letišť. Druhý typ testů prováděl převážně Ing. Ota Kadlec, proto se zaměřím pouze na automatické testy, které jsem z části prováděl osobně a z části je prováděl i Jiří Kadlec. Kostru pro testování metod jsem vytvořil za pomocí vývojového prostředí Netbeans, ve kterém je celý IS vytvořen. Vzhledem k tomu, že testovací moduly neběží ve stejné VM jako EAR modul, tak bylo zapotřebí použít JNDI lookup na remote rozhraní oproti DI (dependency injection), která je použitá ve webové aplikaci, která součástí EAR archivu .

B.2. Testování výkonu Pro otestování výkonu aplikace jsem použil nástroj AppPerfect LoadTester, který umožňuje simulovat zátěž určitého počtu uživatelů. Tento program obsahuje velice užitečnou utilitu pro testování výkonu webových aplikací, kterou je URL recording. Pomocí ní se dá jednoduše („klikáním na odkazy“) nasimulovat práce uživatele se systémem. Takto jsem vytvořil testovací projekt, který jsem pak spustil pro 10 současně pracujících uživatelů. Toto číslo se mi zdálo jako dostatečné vzhledem k počtu lidí, kteří tento systému budou používat. Celkový počet uživatelů je samozřejmě vyšší, ale k vyššímu počtu současně pracujících uživatelů pravděpodobně docházet nebude. Na následujícím screenshotu je výsledek daného testu.

Obr. B.1. Výsledky load testu v programu AppPerfect

Dodatek B

40

Výsledný test ukazuje hned několik parametrů jako například minimální, maximální a průměrnou dobu odpovědi, která byla v případě tohoto testu 789ms, nebo počet přenesených bytů, počet virtuálních uživatelů apod. Dále lze podrobně pro každou úlohu či určitého uživatele zjistit jednotlivé doby odpovědi. Pomocí těchto čísel se dá například najít „slabé“ místo v systému a popř. udělat úpravy pro urychlení dané části.

Přílohy

41

Přílohy K této práci je přiložené CD, které obsahuje část zdrojových kódů informačního systému, některé UML diagramy a datový model systému. Dále obsahuje text práce v souboru pdf a MS Word. Vzhledem k tomu, že systém obsahuje velké množství dalších modulů, z nichž některé jsou komerční, nelze na CD nahrát plnou spustitelnou verzi, nehledě na to, že samotné nastavení a nakonfigurování systému by mohlo být téma samostatné diplomové práce. IS je dostupný na webu http://is.ok-air.eu, na kterém mohu předvést funkčnost.

Informační systém pro administraci pohybů letadel

Recommend Documents