Wybrane problemy realizacji sterowania ruchem samolotu komunikacyjnego w trybie UAV - doświadczenia z projektu FP6 SOFIA / PAR 2/2011 / 2011 / Archiwum / Strona główna | PAR Pomiary - Automatyka - Robotyka

mgr inĪ. Anna Gaáach Instytut Lotnictwa

WYBRANE PROBLEMY REALIZACJI STEROWANIA

RUCHEM SAMOLOTU KOMUNIKACYJNEGO W TRYBIE

UAV – DOĝWIADCZENIA Z PROJEKTU FP6 SOFIA

CHOSEN PROBLEMS MET DURING REALIZATION OF THE FLIGHT CONTROL OF GENERAL AVIATION PLANE IN UAV MODE – EXPERIENCES FROM THE FP6 SOFIA PROJECT

The article presents experience and chosen problems met during the work on the FP6 SOFIA (Safe Automatic Flight Back and Landing of Aircraft) project, which purpose was to develop concepts and techniques enabling the safe and automatic return to ground in case of hostile actions.

1. WSTĉP

W latach 2006–2009 Instytut Lotnictwa wraz z szeregiem firm i instytucji z caáej Europy wziąá udziaá w projekcie FP6 SOFIA (Safe Automatic Flight Back and Landing of Aircraft). Projekt miaá na celu stworzenie systemu awionicznego mającego zapewniü automatyczny powrót samolotu na ziemiĊ w przypadku wrogiego aktu na pokáadzie. W artykule przedsta-wiono doĞwiadczenia i wybrane problemy, które pojawiáy siĊ podczas realizacji tego projek-tu, w szczególnoĞci podczas testów stworzonego systemu przeprowadzonych przez Instytut Lotnictwa na samolocie I-23.

2. OPIS PROJEKTU SOFIA

Projekt SOFIA [1] miaá za zadnie opracowanie koncepcji i technik umoĪliwiających pieczny automatyczny powrót na ziemiĊ samolotu w wypadku wystąpienia zagroĪenia bez-pieczeĔstwa na pokáadzie. Celem projektu byáo stworzenie zaawansowanego systemu awio-nicznego, którego najwaĪniejszym aspektem byáo zaprojektowanie funkcji rekonfiguracji lotu (Flight Reconfiguration Function – FRF). Funkcje FRF miaáy zapewniü automatyczne kiero-wanie samolotem, tak by bezpiecznie doprowadziü go do odpowiedniego lotniska bez udziaáu zaáogi uniemoĪliwiając wrogim jednostkom przejĊcie kontroli nad maszyną. System FRF za-pewniaá:

 wyznaczenie najbliĪszego autoryzowanego lotniska,  obliczenie nowego planu lotu,

 negocjacje planu lotu ze stacją naziemną lotniska,

 kontrolĊ wszystkich systemów awionicznych związanych z lotem i lądowaniem samo-lotu.

Po stworzeniu systemu miaáa zostaü przeprowadzona walidacja koncepcji i dziaáania funkcji FRF przy uĪyciu platform, na które skáadaáy siĊ symulatory Naziemnej Stacji Kontroli

Ruchu Lotniczego i symulatory kabinowe oraz przez przeprowadzenie rzeczywistych prób w locie na dwóch samolotach typu General Aviation.

3. ZAàOĩENIA PROJEKTU SOFIA

Projekt SOFIA byá kontynuacją projektu SAFEE [1], którego celem byáo stworzenie systemu wykrywania zagroĪenia i zarządzaniem odpowiedzią na niebezpieczeĔstwo, które moĪe wy-stąpiü na pokáadzie samolotu (Threat Assessment Management System – TARMS). System TARMS po zidentyfikowaniu i potwierdzeniu zagroĪenia uruchamiaá system awaryjnego uni-kania przeszkód (Emergency Avoidance System - EAS), który przejmowaá kontrolĊ nad ma-szyną i generowaá manewr mający zapewniü unikniĊcie kolizji samolotu z ziemią, przeszko-dami na ziemi czy obszarami zakazanymi pojmowanymi jako rzeczywiste obiekty i doprowadzaá maszynĊ do obszaru oczekiwania (holding pattern – HP).

Rys. 1. Schematyczna reprezentacja scenariusza dziaáania systemu FRF (wáasnoĞü konsorcjum SOFIA kontrakt AST5-CT-2006-030911)

WstĊpem do projektu SOFIA byá moment, w którym system TARMS odbieraá informacje o zagroĪeniu, potwierdzaá jej wiarygodnoĞü i aktywowaá system EAS (t0 na rys. 1), który prowadziá samolot do zdefiniowanego obszaru oczekiwania (t1 na rys. 1). System FRF byá aktywowany w wybranym momencie lotu w HP. W projekcie SOFIA rozwaĪane byáy 3 rozwiązania dziaáania FRF (t2 na rys. 1):

 nowy plan lotu byá automatycznie generowany przez FRF,

 nowy plan lotu byá generowany przez Stacje Kontroli Lotów i negocjowany z samolo-tem,

 nowy plan lotu byá dostarczony przez jednostkĊ militarną nadzorującą lot samolotu.

unikanie przeszkód HP t2 t2 bezpieczny tunel 4D dla FRFa t2 t0 t1 t3 oczyszczanie przestrzeni powietrznej dla FRF

NastĊpnie Naziemna Stacja Kontroli Ruchu Lotniczego oczyszczaáa przestrzeĔ po-wietrzną z samolotów potencjalnie zagraĪających samolotowi lecącemu pod kontrolą systemu FRF (t2 na rys. 1). Samoloty byáy natychmiast zawracane i kierowane na nowe trajektorie tworząc bezpieczny czterowymiarowy tunel dla samolotu FRF, aĪ do momentu wylądowania samolotu (t3 na rys. 1).

Ze wzglĊdu na to, Īe Instytut Lotnictwa braá udziaá w rozwoju i badaniach pierwszego rozwiązania – generowania planu lotu bez wymiany danych z innymi jednostkami i bez nego-cjacji, w dalszej czĊĞci artykuáu opisywane bĊdzie jedynie to rozwiązanie.

4. ROLA INSTYTUTU LOTNICTWA W PROJEKCIE SOFIA

Instytut Lotnictwa w projekcie SOFIA byá odpowiedzialny za integracjĊ systemu funkcji re-konfiguracji lotu na samolocie GA, a nastĊpnie walidacjĊ algorytmów i sprawdzenie popraw-noĞci dziaáania stworzonego oprogramowania w wariancie pierwszym – lot bez poáączenia ze stacją naziemną, bez negocjacji planu. W praktyce polegaáo to na przygotowaniu komputera, na którym osadzony byá system FRF, zintegrowanie go na samolocie I-23 i przetestowanie stworzonego oprogramowania. Zdobyte w ten sposób doĞwiadczenia i wyniki badaĔ miaáy byü wykorzystane do poprawienia systemu i przygotowania go do kolejnych prób w locie na samolocie firmy Diamond (DA-42) (rys. 2).

Rys. 2. Plan walidacji systemu FRF

(wáasnoĞü konsorcjum SOFIA kontrakt AST5-CT-2006-030911)

4.1. Platforma sprzĊtowa

W celu przeprowadzenia testów na I-23, samolot musiaá zostaü poddany modernizacji. W skáad nowej sprzĊtowej platformy testowej weszáy (rys. 3):

 komputer FRF/AP - komputer PC/104 (Celeron 650 MHz, 512 RAM, 4 GB ATA/IDE Flash) z dodatkowymi kartami do obsáugi szyny CAN i GSM/GPRS, na którym zaimplementowano oprogramowanie FRF wykonane przez partnerów projektów SOFIA oraz autopilota,

 mechanizmy wykonawcze z linkami sterującymi lotek, sterów wysokoĞci i trymerów,

Preliminary Validation (Implementation) GAL ATENA DFS ATC Ground Simulations Final Validation FRF IoA I-23 Aircraft DAI DA-42 Aircraft THA/AIRLAB DAI DA-42 Simulator

 panel autopilota 2D z osobnym systemem zasilania, wyáącznikami bezpieczeĔstwa i bezpiecznikami,

 szyna CAN áącząca jednostki obliczeniowe z komputerem FRF/AP, mechanizmami wykonawczymi i panelem sterowania.

Rys. 3. WnĊtrze samolotu I-23 po modernizacji dla systemu FRF

Automatyczny lot wzdáuĪ trajektorii, za który najczĊĞciej odpowiedzialny jest moduá FMS w autopilotach samolotów GA, zastąpiony zostaá przez procedury FRFa i algorytmy autopilo-ta wykonywane na komputerze FRF/AP. Uzyskano w ten sposób to system bardzo elastyczny, umoĪliwiający wprowadzanie ewentualnych zmian i poprawek do systemu co okazaáo siĊ bardzo znaczące podczas testów systemu.

4.2. Platforma programowa

Programową platformą testową zostaá wybrany przez konsorcjum system Windows XP Pro-fessional. Ze wzglĊdu na brak gwarancji czasu wykonywania operacji (jak to jest w systemach czasu rzeczywistego) nie byá to docelowy system operacyjny, ale na etapie te-stów byá wystarczający i áatwo dostĊpny dla wszystkich firm biorących udziaá w testach. Przy tworzeniu oprogramowania zdecydowano siĊ na wykorzystanie zintegrowanego Ğrodowisko programistycznego firmy Microsoft – Visual Studio 6.0 dla jĊzyków C++ lub Basic, w zaleĪ-noĞci od preferencji uczestników projektu. ĝrodowisko programistyczne zostaáo zapropono-wane przez firmy odpowiedzialne za tworzenie oprogramowania do systemu FRF ze wzglĊdu na doĞwiadczenie w pracy i tworzeniu projektów w tym Ğrodowisku a takĪe jego dostĊpnoĞü.

Struktura stworzonego systemu zostaáa oparta na architekturze klient-serwer. W systemie aplikacja klienta korzystaáa z usáug zapewnianych przez funkcje systemu FRF zawarte w moduáach programowych (komponentach), za które odpowiedzialne byáy poszczególne firmy tworzące oprogramowanie i których kod nie byá udostĊpniany innym uczestnikom pro-jektu ze wzglĊdu na politykĊ firmy. Moduáy programistyczne zamkniĊte byáy w klasach, bi-bliotekach lub programach i udostĊpniaáy jedynie swoją funkcjonalnoĞü bez szczegóáów doty-czących implementacji czy rozwiązaĔ algorytmicznych. Komunikacja pomiĊdzy poszczegól-nymi czĊĞciami oprogramowania odbywa siĊ poprzez klasy COM/DCOM [2].

4.3. Przeprowadzone badania i problemy z nimi związane

Ze wzglĊdu na to, Īe stworzony system miaá byü wykorzystywany na rzeczywistych samolo-tach, a podczas tworzenia projektu miaáy zostaü przeprowadzone próby w locie, system FRF, poza okreĞloną w zaáoĪeniach funkcjonalnoĞcią, musiaá byü bezpieczny i niezawodny. Stwo-rzone w projekcie funkcje rekonfiguracji lotu musiaáy dziaáaü bezawaryjnie, algorytmy musia-áy byü wykonywane w odpowiednich ramach czasowych i uniemoĪliwiaü wystąpienie stanów nieokreĞlonych i báĊdów. System musiaá dziaáaü wydajnie i efektywnie wykorzystywaü po-siadane zasoby. Ze wzglĊdu na zastosowanie na róĪnych platformach sprzĊtowych system FRF musiaá byü áatwy do adaptacji i integracji. Musiaá mieü równieĪ przygotowane jednolite bazy danych (lotnisk, pasów startowych, obszarów zabronionych i przeszkód, rzeĨby terenu i danych o samolocie) [3].

Tworzenie systemu tego typu, szczególnie w wypadku, gdy w tworzeniu oprogramowania bierze udziaá wiele firm nie mających doĞwiadczeĔ we wspóápracy ze sobą, okazaáo siĊ pro-cesem skomplikowanym, który potrafiá zmieniaü siĊ dynamicznie wraz z rozwojem projektu, czĊsto niezaleĪnie od wstĊpnych ustaleĔ zarówno pod wzglĊdem algorytmów jak rozwiązaĔ programistycznych [4].

W przypadku testów przeprowadzanych przez Instytut Lotnictwa pierwsze problemy po-jawiáy siĊ momencie adaptacji systemu na platformie testowej. Trzeba byáo dostosowaü wej-Ğcia i wyjwej-Ğcia stworzonego systemu FRF do interfejsów autopilota i zapewniü przepáyw da-nych lotu z czujników samolotów do systemu FRF i dada-nych o nowym planie lotu z systemu FRF do systemu sterowania samolotem. Mimo zwartej struktury systemu naleĪaáo wprowa-dziü kilka zmian, np. do poprawnego dziaáania autopilota, system FRF musiaá zmodyfikowaü jedno z wyjĞü tak by dostĊpna byáa wartoĞü báĊdu odlegáoĞci od trajektorii ze znakiem.

Proces adaptacji okazaá siĊ procesem czasocháonnym, któremu towarzyszyáa staáa wymia-na informacji miĊdzy firmami tworzącymi oprogramowania a firmami testującymi je wymia-na doce-lowych urządzeniach. Wymiana informacji oparta byáa na kontakcie telefonicznym i mailowym, który nie jest tak efektywny jak kontakt bezpoĞredni i zajmowaá duĪo czasu. W szczególnych przypadkach przy adaptacji systemu niezbĊdny okazaá siĊ przyjazd i pomoc twórców oprogramowania co wiązaáo siĊ z dodatkowymi kosztami. Po zintegrowaniu opro-gramowania na samolocie przystąpiono do testów.

Przed rozpoczĊciem wáaĞciwych badaĔ systemu FRF przygotowana platforma testowa zo-staáa sprawdzona osobno by uzyskaü pewnoĞü, Īe ewentualne báĊdy wynikają tylko z nieprawidáowego dziaáania testowanego oprogramowania, a nie są powodowane przez plat-formĊ. Ze wzglĊdu na specyfikĊ przeprowadzanych badaĔ i koszt ich wykonywania, dziaáanie systemu FRF byáo testowane na początku „na ziemi”, podczas symulacji komputerowych. Po przejĞciu testów wstĊpnych odbywaáy siĊ próby w locie. Procedura testów byáa powtarzana eliminując pojawiające siĊ podczas prób kolejne báĊdy i nieĞcisáoĞci.

Symulacje komputerowe stworzone w celu wstĊpnego przetestowania oprogramowania FRF na ziemi byáy bardzo proste, jednak nawet takie nieskomplikowane doĞwiadczenia po-zwoliáy zdobyü wiele informacji na temat báĊdów i braków w oprogramowaniu oraz uzyskaü wiele wskazówek jak poprawiü jego jakoĞü i wiarygodnoĞü. Podczas symulacji oprogramo-wanie byáo testowane przez wprowadzenie do systemu prostych tras lotu i kontrolooprogramo-wanie czy dane generowanie przez system są prawidáowe. W póĨniejszych fazach testów podawane do sytemu trasy symulowaáy trasĊ lotu przewidzianą na rzeczywiste próby w locie, a w koĔcowych na wejĞcie byáy podawane rzeczywiste dane z wykonanego wczeĞniej lotu. W wypadku wystąpienia báĊdu oprogramowanie przekazywane byáo do twórców w celu mo-dyfikacji kodu lub dziaáania algorytmów. Ze wzglĊdu na prostotĊ symulatora moĪliwe byáo

przekazywanie jego kodu partnerom w celu lepszego unaocznienia spostrzeĪeĔ co do dziaáa-nia systemu.

Podczas przeprowadzonych badaĔ wykryto czĊĞü báĊdów, do których naleĪaáy m.in.:  problem stabilnoĞci oprogramowania – w początkowych fazach testów aplikacja

po-trafiáa przestaü dziaáaü w niespodziewanym momencie podczas lotu wzdáuĪ zadanej trajektorii,

 zatrzymanie dziaáania aplikacji, gdy samolot znalazá siĊ zbyt daleko od wyznaczonej trajektorii lotu,

 problemy z czyszczeniem rejestru komputera,

 problem z wizualizacją niektórych parametrów na interfejsie graficznym systemu,  problem z dostĊpem do niektórych zmiennych systemu wymaganych przez autopilota,  wahania kroku czasowego dziaáania aplikacji.

NaleĪy nadmieniü, Īe w celu przeprowadzenia prób na samolocie Instytut musiaá uzyskaü pozwolenie na testy w locie samolotem z eksperymentalnym oprogramowaniem od EASA. Okazaáo siĊ to procesem bardzo czasocháonnym, gdyĪ ze wzglĊdu na gruntowną przebudową ukáady sterowania, samolot musiaá przejĞü ponowną certyfikacjĊ. Po odbyciu ponad 20 testów naziemnych i technicznych, wykonanych w obecnoĞci obserwatora UrzĊdu Lotnictwa Cywil-nego Instytut Lotnictwa uzyskaá zgodĊ na wykonanie prób w locie.

5. WNIOSKI

W wyniku pracy nad projektem SOFIA powstaá system awioniczny, áatwy do integracji na róĪnych jednostkach, gdzie automatyzacja wprowadzona przez funkcje FRF moĪe byü wyko-rzystywana w áatwy, otwarty sposób, by wspomóc zaáogĊ samolotu w sytuacjach niebez-piecznych. System zostaá przebadany a wyniki testów zachĊcają do dalszej pracy i rozwoju projektu.

Praca przy projekcie SOFIA pozwoliáa Instytutowi Lotnictwa zdobyü wiele doĞwiadczeĔ dotyczących zarówno metodyki tworzenia duĪych projektów lotniczych, jak i wspóápracy z firmami z innych krajów i instytucji. Wiele informacji, począwszy od sposobów definicji wstĊpnych zaáoĪeĔ projektu, tak aby wszyscy uczestnicy byli zadowolenie z podziaáu pracy i wyboru rozwiązaĔ programistycznych i lotniczych, poprzez prowadzenie dokumentacji w czasie trwania caáego projektu aĪ do rozpowszechniania osiągniĊü wspóápracy innym fir-mom i instytucjom z Europy, pozwoli w przyszáoĞci na znaczne usprawnienie dziaáaĔ w podobnych przedsiĊwziĊciach. Udziaá w SOFII unaoczniá liczbĊ i typy problemów jakie mogą powstaü w czasie trwania takiego projektu, od maáych, takich jak róĪne rozumienie tych samych pojĊü przez róĪne firmy, po duĪe, takie jak uzyskiwanie certyfikatów lotu dla samolo-tu z nowym, eksperymentalnym systemem pokáadowym.

W wyniku udziaáu w projekcie powstaáa równieĪ tania, szybka i áatwa do modyfikacji platforma testowa do prowadzenia badaĔ nad systemami sterowanie, awionicznymi i programistycznymi jedynie poprzez zmianĊ oprogramowania komputera AP/FRF.

BIBLIOGRAFIA

1. SOFIA reports, 2005-2008.

2. DCOM Technical Overview. MSDN, Microsoft Corporation 1996.

3. Cykl tworzenia oprogramowania na przykáadzie projektu SOFIA., Prace Instytutu Lotnic-twa 2010 (oddana do wydawnicLotnic-twa).