Légi irányítás Esettanulmány

1. Légi irányításEsettanulmány Készítette: Szilágyi Jenő E-mail: szjenoko@inf.elte.hu Forrás:

2. Alapprobléma • Az FAA a 90-es években le akarta cserélni a nemzeti légi irányítási rendszert. • Ennek során minden akkori informatikai problémával szembesültek (több millió soros program, elosztva több száz gépen, beágyazva a legmodernebb hardverekbe) • A biztonság nagyon fontos (emberélet) Air Traffic Control

3. Légi irányítás (Air Traffic Control) • Hard real time (valósidejű eredmények) • A biztonság kritikus szempont (emberélet) • Elosztott (sok irányító együttműködése) • A rendszert végül nem vezették be, de implementálták és bebizonyosodott, hogy megfelel a minőségi követelményeknek Air Traffic Control

4. Irányítás • Földi irányítás (ground control): repülőtéren való földi mozgás koordinálása • Tornyok (tower): repülőtér légterében való irányítás, henger alakú térrész • Útközi irányító központok (en route center): az ország légterét 22 területre osztották Air Traffic Control

5. Példa (Key West → Washington DC) • Földi irányítás: Key West ground contorl • Torony: Key West tower • Útközi irányítás: Miami Center, Jacksonville Center, Atlanta Center, Washington Center • Torony: Dulles tower • Földi irányítás: Dulles ground control Air Traffic Control

6. Project • Initial Sector Suite System (ISSS): a 22 útközi irányítóközpontra kiterjedő új hardver- és szoftverrendszer. • Az ISSS megszerezte mindhárom terület (útközi irányítóközpontok, irányítótornyok, földi irányítás) fejlesztésének jogát, így sok komponenst megoszthattak (pl.: rádió rendszer interfésze, repülő adatbázis interfész, …) • Advanced Automation System (AAS): a rendszer újításainak összessége • Végül visszavonták a megbízást, és egy olcsóbb terv vette át a helyét, de tanulságai miatt érdemes elemezni Air Traffic Control

7. Megrendelő FAA Végfelhasználó légiirányítók Követelmények (minőség) Fejlesztők Technikai környezet Ada prg. Nyelv Elosztott programozás Fejlesztői tapasztalatok Hibatűrés Üzenetalapú rendszer Architecture Business Cycle (ABC) Tervezőt befolyásoló tényezők Tervező Architektúra Rendszer ISSS Air Traffic Control

8. Követelmények és minőség • Szinte állandó rendelkezésre állás: egy év alatt a rendszer összesen max. 5 percig lehet elérhetetlen. • Magas teljesítmény: sok repülőgépet kell kezelnie (2440), anélkül, hogy bármelyiket elveszítené. A hálózat kommunikációs csatornáinak gyorsnak és kiszámíthatónak kell lenniük. Air Traffic Control

9. Követelmények és minőség • Nyitottság: képes befogadni a külső szoftverkomponenseket • A részfeladatok különálló kezelhetősége (dekompozíció) • A hardver és szoftver könnyű lecserélhetősége, módosíthatósága • Külső rendszerekhez való kapcsolódás lehetősége Air Traffic Control

10. Követelmények és minőség • Minden szektorból 1-4 irányító központ érhető el • Minden központban legalább két ember van (radar figyelő, adat figyelő) Air Traffic Control

11. Rendszer kapacitásai • 210 konzol / útközi irányító központ • 400-2440 repülőgép párhuzamos kezelése • 16-40 radar kezelése • 1 millió soros Ada kód Air Traffic Control

12. ISSS feladatai • Radar célpont jelentés megszerzése a Host Computer System-től (HCS: a repülési adatok feldolgozásáért felelős) • Szétszórja a jelentéseket a konzolok között és a konzolok kiválasztják, mely jelentést kell megjeleníteniük • Konfliktus helyzetek figyelése • Interfész a Host felé • Adatok folyamatos figyelése (network management) Air Traffic Control

13. ISSS feladatai • Adatok mentésének támogatása (később visszajátszás) • Ablakozó rendszer a konzolon (figyelni az eltakart adatokra) • Csökkentett mód futtatása meghibásodás esetén Air Traffic Control

14. Architektúra

15. Fizikai nézet • Host Computer System (HCS): • Pozíció információk (konzolon jelenik meg) • Repülési adatok (nyomtatószalagra, néhány a konzolra is) • Biztonsági okokból kettő van belőle • Közös konzol: pozíció, kapcsolódó adatok, repülési terv, … • Local Communications Network (LCN): az ISSS elsődleges hálózata (4db bridzsekkel összekötött „token ring”-ből áll) • LCN interface units (LIU-H): a HCS-t és az LCN-t összekötő interfész Air Traffic Control

16. Fizikai nézet • Kiemelt Közvetlen Elérésű Radar Csatorna (Enhanced Direct Access Radar Chanel): ha elvesznek a Host-tól származó adatok, közvetlen nyers adatokat szerez a radartól • Backup Communications Network (BCN): TCP/IP protokollt használó Ethernet hálózat • Monitor & Control konzol: a hálózatokhoz rendelt ellenőrző konzol, mely speciális szoftvereket tartalmaz Air Traffic Control

17. Fizikai nézet • Tesztelő és szimulációs alrendszerek: új hardverek tesztelésére, új szoftverek szimulációjára (betanítás) • Központi processzorok: adatok mentésére és visszajátszására Air Traffic Control

18. Common Consoles Common Consoles Common Consoles ISSS fizikai nézete <<LCN>> Bridge Bridge Bridge Bridge HCS A LIU-H Central Processor <<LCN>> Common Consoles HCS B LIU-H Test and Training Subsystem <<BCN>> <<LCN>> LIU-C EDARC ESI <<BCN>> M&C Consoles M&C Consoles Air Traffic Control

19. Modul dekompozíciós nézet • Computer Software Configuration Items (CSCI): az ISSS szoftver moduljainak összessége • CSCI elemei: • Display Management: konzolokon való megjelenítés • Common System Services (CSS): hasznos közös szolgáltatások az ATC szoftverekben • Mentést, Elemzést, Visszajátszást támogató modul • National Airspace System Modification: a Host-ban helyezkedik el • IBM AIX operációs rendszer Air Traffic Control

20. Modul dekompozíciós nézet Az egyes modulok sugallnak bizonyos optimalizálási taktikákat: • „Szemantikus koherencia” (jól definiált, nem túlterhelt elemek szétosztása a CSCI-nek) • „Absztrakt közös szolgáltatások”: CSS-nél • „Record/Playback”: tesztelhetőséget segíti • „előre látható változások”, „modulok generalizálása”, „interfész stabilitásának fenntartása”: minden CSCI-nél alkalmazandó Air Traffic Control

21. Folyamat nézet • Alkalmazás ~ folyamat • Kommunikáció az alkalmazások között: üzenetküldés • A biztonság érdekében egy alkalmazás több másolatát ún. processor-group-okban többszörösen tároljuk (operational unit = primari address space (PAS) + standby address space (SAS)). • Ezzel nem rendelkező alkalmazások alkotják a funcional group-okat Air Traffic Control

22. Folyamat nézet • Kliens-szerver modell: kliens (kérés) → szerver (válasz) • Operational unit: a PAS-nak értesítenie kell a SAS-okat az állapotváltozásról • Functional group: csak a saját állapotát tartja karban • PAS meghibásodása esetén: • Az egyik SAS előlép PAS-sá • Az új PAS helyreállítja a kapcsolatot a klienssel (rákérdez, történt-e kérés a meghibásodáskor) • A PAS helyére új SAS töltődik • Az új SAS feltöltése friss információkkal Air Traffic Control

23. Folyamat nézet • Új operational unit létrehozása: • Input-források azonosítása • Mely operational unit-ok igényelnek output-ot • Az erőforrás igénylési gráfban való elhelyezés és körmentesség ellenőrzése (dead lock elkerülése) • Üzenetek megtervezése az adatforgalomhoz • Állapot adatok azonosítása (PAS → SAS) • Állapot adatok felosztása → háózatra • Üzenettípus definiálása • Teendők megtervezése hiba esetére • Adatok konzisztenciájának fenntartása • Elemi lépések gyors végrehajtásának biztosítása • Adatmegosztás és –lock-olás megtervezése Air Traffic Control

24. Folyamat nézet • Sugallt optimalizálási taktikák: • „állapot újraszinkronizálás” • „shadowing” • „aktív redundancia” • „removal from service” Air Traffic Control

25. Kliens-szerver nézet • Módosíthatósági taktikák: • „interfész stabilitásának fenntartása” • „component replacement” • „definiált protokollokhoz való ragaszkodás” Air Traffic Control

26. Kód nézet • Programozási nyelv: Ada • Dekompozíció: package, moduláris programozás (több fájlba való csoportosítás) • Konkurencia kezelés: task • Absztrakció, adatelrejtés, újrahasznosítás: package Air Traffic Control

27. Szoftver-réteg nézet 5. Osztott memória • ASS alkalmazás • Címtér modulok • Alkalmazás szubrutinok • Csomagok 4. 3. Osztott memória • CAS AIX Kernel-kiterjesztés • AAS szolgáltatások • Automatic Broadcast Manager • Device Driver-ek • TCP/IP 2. 1. AIX Kernel Air Traffic Control

28. Szoftver-réteg nézet • Az alsó rétegek (2.): • Kis méretű (biztonsági szempontok miatt), • C-ben íródott szoftverek (a Kernel-lel való kompatibilitás miatt). • A Kernel címterében futnak, • az esetleges hibákat a Kernel-en belül kell kezelni. Air Traffic Control

29. Szoftver-réteg nézet • Felsőbb rétegek (3.): • Az operációs rendszer kiterjesztései. • Ada-ban íródott, • nagyobb méretű programok. • A hibákat a Kernel-en kívül kell lekezelni. Air Traffic Control

30. Szoftver-réteg nézet • Legfelső réteg (4.): • Applikációs szint: itt helyezkednek el az alkalmazások • Local Availability Manager: irányítja az alkalmazások inicializációját, leállítását, rendelkezésre állását. Kapcsolattartás más processzorok menedzsereivel, valamint a globális menedzserrel. • Internal Time Syncronisation: az ISSS processzorainak óráit szinkronizálja Air Traffic Control

31. Hibakezelés nézet • Ez a nézet azt mutatja, hogy a hibák hogyan detektálhatók, izolálhatók, és a rendszer miként állítható helyre. • A detektálás és helyreállítás fokozatai a hibakezlési hierarchiában: • Hiba detektálása a keletkezés helyén, vagy alsóbb szinten • Alsóbb szinten keletkezett kivétel kezelése • Diagnózis, helyreállítás, jelentés, vagy kivétel dobás Air Traffic Control

32. Hibakezelés nézet • A hiba kezelésének szintjei: • Fizikai (hálózat, processzor, I/O) • Operációs rendszer • Valósidejű környezet • Alkalmazások • Local Availability Management szintje • Group Availability Management szintje • Global Availability Management szintje • System monitor and control Air Traffic Control

33. Hibakezelés nézet • Hibadetektálás: a hierarchia minden szintjén • Helyreállítás: a szoftverhierarchia minden szintjén. • Availability Manager-ek: táblázat alapján • PAS: működési státusz alapján 4 helyreállítási típus • A helyreállításban segítséget nyújt a redundancia: • Hálózati hardver szinten (LCN, BCN, bridge) • Processzor hardver szinten (processor group) • Szoftver szinten (operational unit többszörös tárolása) Air Traffic Control

34. A nézetek egymáshoz való viszonya • A különböző nézetekben megjelennek más nézetek elemei. Ezek teremtenek összefüggést közöttük. Feltérképezve a kapcsolatokat, lesz teljes rálátásunk az architektúrára. • Példák összefonódásokra: • Modul dekompozíciós nézet elemei: CSCI • A CSCI alkalmazásokból épül fel • Az alkalmazások elemei a folyamat és a kliens-szerver nézetnek • Az alkalmazásokat Ada-ban implementálták (programok, package-k), ami a kód nézetben jelenik meg Air Traffic Control

35. Adaptációs adatok • Konfigurációs fájl • Ezen keresztül paraméterezhető a program • Helyi sajátosságok, változások gyors, egyszerű kezelésére • Generikus programozás (paraméterezhetőség, template) • Hátrányok: • Új parancs felvétele → interpreter • Inkonzisztencia kezelése nem automatizálható • Állapottér növekedése → nehezebb tesztelhetőség Air Traffic Control

36. Absztrakt közös szolgáltatások • Template-ek alkalmazása (Ada) • Példa (PAS, SAS): • Ugyanazzal a template task-kal megvalósítva, ami egy végtelen ciklust tartalmaz, melyben a lehetséges eseményeket kezeli le a lehetséges állapotok függvényében • A korábban leírt funkciókat látja el • A programozónak nem kell tudnia: • az üzenetkezelésről • hogy az alkalmazás hibatűrő-e Ezek felsőbb tervezési szinteken kerülnek elő • Támogatja a módosíthatóságot • „megelőzni az előre látható változásokat” taktika Air Traffic Control

37. Absztrakt közös szolgáltatások • „szemantikus koherencia”: absztrakt szinten mindegyik alkalmazás ugyanazt csinálja • „modulok generalizálása” • Ha az interfészeket és protokollokat a template részévé tesszük akkor megvalósulnak a következő taktikák is: • „interfész stabilitás” • „ragaszkodjunk a definiált protokollokhoz” Air Traffic Control

38. Hogyan feleljünk meg az ATC rendszer minőségi követelményeinek? Air Traffic Control

39. Itt a vége, fuss el véle!