WYBRANE PROBLEMY REALIZACJI STEROWANIA RUCHEM SAMOLOTU KOMUNIKACYJNEGO W TRYBIE UAV DO WIADCZENIA Z PROJEKTU FP6 SOFIA

Transkrypt

1 mgr in. Anna Gaach Instytut Lotnictwa WYBRANE PROBLEMY REALIZACJI STEROWANIA RUCHEM SAMOLOTU KOMUNIKACYJNEGO W TRYBIE UAV DOWIADCZENIA Z PROJEKTU FP6 SOFIA W pracy przedstawiono dowiadczenia i wybrane problemy, jakie napotkano podczas pracy nad projektem FP6 SOFIA (Safe Automatic Flight Back and Landing of Aircraft), majcym na celu opracowanie koncepcji i algorytmów pozwalajcych na automatyczny powrót samolotu na ziemi w przypadku pojawienia si niebezpieczestwa na pokadzie. 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. WSTP W latach Instytut Lotnictwa wraz z szeregiem firm i instytucji z caej Europy wzi udzia w projekcie FP6 SOFIA (Safe Automatic Flight Back and Landing of Aircraft). Projekt mia na celu stworzenie systemu awionicznego majcego zapewni automatyczny powrót samolotu na ziemi w przypadku wrogiego aktu na pokadzie. W artykule przedstawiono dowiadczenia i wybrane problemy, które pojawiy si podczas realizacji tego projektu, w szczególnoci podczas testów stworzonego systemu przeprowadzonych przez Instytut Lotnictwa na samolocie I OPIS PROJEKTU SOFIA Projekt SOFIA [1] mia za zadnie opracowanie koncepcji i technik umoliwiajcych bezpieczny automatyczny powrót na ziemi samolotu w wypadku wystpienia zagroenia bezpieczestwa na pokadzie. Celem projektu byo stworzenie zaawansowanego systemu awionicznego, którego najwaniejszym aspektem byo zaprojektowanie funkcji rekonfiguracji lotu (Flight Reconfiguration Function FRF). Funkcje FRF miay zapewni automatyczne kierowanie samolotem, tak by bezpiecznie doprowadzi go do odpowiedniego lotniska bez udziau zaogi uniemoliwiajc wrogim jednostkom przejcie kontroli nad maszyn. System FRF zapewnia: wyznaczenie najbliszego autoryzowanego lotniska, obliczenie nowego planu lotu, negocjacje planu lotu ze stacj naziemn lotniska, kontrol wszystkich systemów awionicznych zwizanych z lotem i ldowaniem samolotu. Po stworzeniu systemu miaa zosta przeprowadzona walidacja koncepcji i dziaania funkcji FRF przy uyciu platform, na które skaday si symulatory Naziemnej Stacji Kontroli 662 Pomiary Automatyka Robotyka 2/2011

2 Ruchu Lotniczego i symulatory kabinowe oraz przez przeprowadzenie rzeczywistych prób w locie na dwóch samolotach typu General Aviation. 3. ZAOENIA PROJEKTU SOFIA Projekt SOFIA by kontynuacj projektu SAFEE [1], którego celem byo stworzenie systemu wykrywania zagroenia i zarzdzaniem odpowiedzi na niebezpieczestwo, które moe wystpi na pokadzie samolotu (Threat Assessment Management System TARMS). System TARMS po zidentyfikowaniu i potwierdzeniu zagroenia uruchamia system awaryjnego unikania przeszkód (Emergency Avoidance System - EAS), który przejmowa kontrol nad maszyn i generowa manewr majcy zapewni uniknicie kolizji samolotu z ziemi, przeszkodami na ziemi czy obszarami zakazanymi pojmowanymi jako rzeczywiste obiekty i doprowadza maszyn do obszaru oczekiwania (holding pattern HP). t2 HP t0 t2 unikanie przeszkód t1 bezpieczny tunel 4D dla FRFa t2 oczyszczanie przestrzeni powietrznej dla FRF t3 Rys. 1. Schematyczna reprezentacja scenariusza dziaania systemu FRF (wasno konsorcjum SOFIA kontrakt AST5-CT ) Wstpem do projektu SOFIA by moment, w którym system TARMS odbiera informacje o zagroeniu, 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 rozwaane byy 3 rozwizania dziaania 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 samolotem, nowy plan lotu by dostarczony przez jednostk militarn nadzorujc lot samolotu. 2/2011 Pomiary Automatyka Robotyka 663

3 Nastpnie Naziemna Stacja Kontroli Ruchu Lotniczego oczyszczaa przestrze powietrzn z samolotów potencjalnie zagraajcych samolotowi leccemu pod kontrol systemu FRF (t2 na rys. 1). Samoloty byy natychmiast zawracane i kierowane na nowe trajektorie tworzc bezpieczny czterowymiarowy tunel dla samolotu FRF, a do momentu wyldowania samolotu (t3 na rys. 1). Ze wzgldu na to, e Instytut Lotnictwa bra udzia w rozwoju i badaniach pierwszego rozwizania generowania planu lotu bez wymiany danych z innymi jednostkami i bez negocjacji, w dalszej czci artykuu opisywane bdzie jedynie to rozwizanie. 4. ROLA INSTYTUTU LOTNICTWA W PROJEKCIE SOFIA Instytut Lotnictwa w projekcie SOFIA by odpowiedzialny za integracj systemu funkcji rekonfiguracji lotu na samolocie GA, a nastpnie walidacj algorytmów i sprawdzenie poprawnoci dziaania stworzonego oprogramowania w wariancie pierwszym lot bez poczenia ze stacj naziemn, bez negocjacji planu. W praktyce polegao 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 dowiadczenia i wyniki bada miay by wykorzystane do poprawienia systemu i przygotowania go do kolejnych prób w locie na samolocie firmy Diamond (DA-42) (rys. 2). DAI DA-42 Simulator IoA I-23 Aircraft FRF DAI DA-42 Aircraft GAL ATENA Ground Simulations DFS ATC THA/AIRLAB Preliminary Validation (Implementation) Final Validation 4.1. Platforma sprztowa Rys. 2. Plan walidacji systemu FRF (wasno konsorcjum SOFIA kontrakt AST5-CT ) W celu przeprowadzenia testów na I-23, samolot musia zosta poddany modernizacji. W skad nowej sprztowej platformy testowej weszy (rys. 3): komputer FRF/AP - komputer PC/104 (Celeron 650 MHz, 512 RAM, 4 GB ATA/IDE Flash) z dodatkowymi kartami do obsugi szyny CAN i GSM/GPRS, na którym zaimplementowano oprogramowanie FRF wykonane przez partnerów projektów SOFIA oraz autopilota, mechanizmy wykonawcze z linkami sterujcymi lotek, sterów wysokoci i trymerów, 664 Pomiary Automatyka Robotyka 2/2011

4 panel autopilota 2D z osobnym systemem zasilania, wycznikami bezpieczestwa i bezpiecznikami, szyna CAN czca jednostki obliczeniowe z komputerem FRF/AP, mechanizmami wykonawczymi i panelem sterowania. Rys. 3. Wntrze samolotu I-23 po modernizacji dla systemu FRF Automatyczny lot wzdu trajektorii, za który najczciej odpowiedzialny jest modu FMS w autopilotach samolotów GA, zastpiony zosta przez procedury FRFa i algorytmy autopilota wykonywane na komputerze FRF/AP. Uzyskano w ten sposób to system bardzo elastyczny, umoliwiajcy wprowadzanie ewentualnych zmian i poprawek do systemu co okazao si bardzo znaczce podczas testów systemu Platforma programowa Programow platform testow zosta wybrany przez konsorcjum system Windows XP Professional. Ze wzgldu na brak gwarancji czasu wykonywania operacji (jak to jest w systemach czasu rzeczywistego) nie by to docelowy system operacyjny, ale na etapie testów by wystarczajcy i atwo dostpny dla wszystkich firm biorcych udzia w testach. Przy tworzeniu oprogramowania zdecydowano si na wykorzystanie zintegrowanego rodowisko programistycznego firmy Microsoft Visual Studio 6.0 dla jzyków C++ lub Basic, w zalenoci od preferencji uczestników projektu. rodowisko programistyczne zostao zaproponowane przez firmy odpowiedzialne za tworzenie oprogramowania do systemu FRF ze wzgldu na dowiadczenie w pracy i tworzeniu projektów w tym rodowisku a take jego dostpno. Struktura stworzonego systemu zostaa oparta na architekturze klient-serwer. W systemie aplikacja klienta korzystaa z usug zapewnianych przez funkcje systemu FRF zawarte w moduach programowych (komponentach), za które odpowiedzialne byy poszczególne firmy tworzce oprogramowanie i których kod nie by udostpniany innym uczestnikom projektu ze wzgldu na polityk firmy. Moduy programistyczne zamknite byy w klasach, bibliotekach lub programach i udostpniay jedynie swoj funkcjonalno bez szczegóów dotyczcych implementacji czy rozwiza algorytmicznych. Komunikacja pomidzy poszczególnymi czciami oprogramowania odbywa si poprzez klasy COM/DCOM [2]. 2/2011 Pomiary Automatyka Robotyka 665

5 4.3. Przeprowadzone badania i problemy z nimi zwizane Ze wzgldu na to, e stworzony system mia by wykorzystywany na rzeczywistych samolotach, a podczas tworzenia projektu miay zosta przeprowadzone próby w locie, system FRF, poza okrelon w zaoeniach funkcjonalnoci, musia by bezpieczny i niezawodny. Stworzone w projekcie funkcje rekonfiguracji lotu musiay dziaa bezawaryjnie, algorytmy musia- y by wykonywane w odpowiednich ramach czasowych i uniemoliwia wystpienie stanów nieokrelonych i bdów. System musia dziaa wydajnie i efektywnie wykorzystywa posiadane zasoby. Ze wzgldu na zastosowanie na rónych platformach sprztowych 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, rzeby terenu i danych o samolocie) [3]. Tworzenie systemu tego typu, szczególnie w wypadku, gdy w tworzeniu oprogramowania bierze udzia wiele firm nie majcych dowiadcze we wspópracy ze sob, okazao si procesem skomplikowanym, który potrafi zmienia si dynamicznie wraz z rozwojem projektu, czsto niezalenie od wstpnych ustale zarówno pod wzgldem algorytmów jak rozwiza programistycznych [4]. W przypadku testów przeprowadzanych przez Instytut Lotnictwa pierwsze problemy pojawiy si momencie adaptacji systemu na platformie testowej. Trzeba byo dostosowa wej- cia i wyjcia stworzonego systemu FRF do interfejsów autopilota i zapewni przepyw danych lotu z czujników samolotów do systemu FRF i danych o nowym planie lotu z systemu FRF do systemu sterowania samolotem. Mimo zwartej struktury systemu naleao wprowadzi kilka zmian, np. do poprawnego dziaania autopilota, system FRF musia zmodyfikowa jedno z wyj tak by dostpna bya warto bdu odlegoci od trajektorii ze znakiem. Proces adaptacji okaza si procesem czasochonnym, któremu towarzyszya staa wymiana informacji midzy firmami tworzcymi oprogramowania a firmami testujcymi je na docelowych urzdzeniach. Wymiana informacji oparta bya na kontakcie telefonicznym i mailowym, który nie jest tak efektywny jak kontakt bezporedni i zajmowa duo czasu. W szczególnych przypadkach przy adaptacji systemu niezbdny okaza si przyjazd i pomoc twórców oprogramowania co wizao si z dodatkowymi kosztami. Po zintegrowaniu oprogramowania na samolocie przystpiono do testów. Przed rozpoczciem waciwych bada systemu FRF przygotowana platforma testowa zostaa sprawdzona osobno by uzyska pewno, e ewentualne bdy wynikaj tylko z nieprawidowego dziaania testowanego oprogramowania, a nie s powodowane przez platform. Ze wzgldu na specyfik przeprowadzanych bada i koszt ich wykonywania, dziaanie systemu FRF byo testowane na pocztku na ziemi, podczas symulacji komputerowych. Po przejciu testów wstpnych odbyway si próby w locie. Procedura testów bya powtarzana eliminujc pojawiajce si podczas prób kolejne bdy i niecisoci. Symulacje komputerowe stworzone w celu wstpnego przetestowania oprogramowania FRF na ziemi byy bardzo proste, jednak nawet takie nieskomplikowane dowiadczenia pozwoliy zdoby wiele informacji na temat bdów i braków w oprogramowaniu oraz uzyska wiele wskazówek jak poprawi jego jako i wiarygodno. Podczas symulacji oprogramowanie byo testowane przez wprowadzenie do systemu prostych tras lotu i kontrolowanie czy dane generowanie przez system s prawidowe. W póniejszych fazach testów podawane do sytemu trasy symuloway tras lotu przewidzian na rzeczywiste próby w locie, a w kocowych na wejcie byy podawane rzeczywiste dane z wykonanego wczeniej lotu. W wypadku wystpienia bdu oprogramowanie przekazywane byo do twórców w celu modyfikacji kodu lub dziaania algorytmów. Ze wzgldu na prostot symulatora moliwe byo 666 Pomiary Automatyka Robotyka 2/2011

6 przekazywanie jego kodu partnerom w celu lepszego unaocznienia spostrzee co do dziaania systemu. Podczas przeprowadzonych bada wykryto cz bdów, do których naleay m.in.: problem stabilnoci oprogramowania w pocztkowych fazach testów aplikacja potrafia przesta dziaa w niespodziewanym momencie podczas lotu wzdu zadanej trajektorii, zatrzymanie dziaania 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 dostpem do niektórych zmiennych systemu wymaganych przez autopilota, wahania kroku czasowego dziaania aplikacji. Naley nadmieni, e w celu przeprowadzenia prób na samolocie Instytut musia uzyska pozwolenie na testy w locie samolotem z eksperymentalnym oprogramowaniem od EASA. Okazao si to procesem bardzo czasochonnym, gdy ze wzgldu na gruntown przebudow ukady sterowania, samolot musia przej ponown certyfikacj. Po odbyciu ponad 20 testów naziemnych i technicznych, wykonanych w obecnoci obserwatora Urzdu Lotnictwa Cywilnego 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 moe by wykorzystywana w atwy, otwarty sposób, by wspomóc zaog samolotu w sytuacjach niebezpiecznych. System zosta przebadany a wyniki testów zachcaj do dalszej pracy i rozwoju projektu. Praca przy projekcie SOFIA pozwolia Instytutowi Lotnictwa zdoby wiele dowiadcze dotyczcych zarówno metodyki tworzenia duych projektów lotniczych, jak i wspópracy z firmami z innych krajów i instytucji. Wiele informacji, poczwszy od sposobów definicji wstpnych zaoe projektu, tak aby wszyscy uczestnicy byli zadowolenie z podziau pracy i wyboru rozwiza programistycznych i lotniczych, poprzez prowadzenie dokumentacji w czasie trwania caego projektu a do rozpowszechniania osigni wspópracy innym firmom i instytucjom z Europy, pozwoli w przyszoci na znaczne usprawnienie dziaa w podobnych przedsiwziciach. Udzia w SOFII unaoczni liczb i typy problemów jakie mog powsta w czasie trwania takiego projektu, od maych, takich jak róne rozumienie tych samych poj przez róne firmy, po due, takie jak uzyskiwanie certyfikatów lotu dla samolotu z nowym, eksperymentalnym systemem pokadowym. W wyniku udziau w projekcie powstaa 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, DCOM Technical Overview. MSDN, Microsoft Corporation Cykl tworzenia oprogramowania na przykadzie projektu SOFIA., Prace Instytutu Lotnictwa 2010 (oddana do wydawnictwa). 4. Software engineering. The eighth edition, Ian Sommerville. 2/2011 Pomiary Automatyka Robotyka 667