Vzdálené ovládání testovací stanice

15. mezinárodní vědecká konference „Měření, diagnostika, spolehlivost palubních soustav letadel“

2015

Vzdálené ovládání testovací stanice Test-Bench Remote Control Bc. Filip Černý UO, FVT, K206, email: [email protected], Resumé: S využitím testovací jednotky TIU (Test Interface Unit), která simuluje data dodávaná z reálných letadlových senzorů, se simuluje jednotka CCD a MKB, čímž se navyšuje testovací schopnost celého systému. Tyto jednotky slouží v reálných letadlech jako hardwarový interface pro manipulaci a zadávání dat do avionických systémů v moderních prostředích „Glass Cockpit“. During the flight pilots need to enter data into the avionics system (FMS, radio channel setting etc.). For those purposes, in modern “Glass Cockpits”, they use the CCD and MKB hardware equipment that form an interface between them and the system. Using the TIU (Test Interface Unit) we can simulate both of these units and ensure the pilot’s inputs to the system during the test procedure. Thanks to this possibility we can increase the testing capability.

1

Úvod Elektronika, jakožto elektrotechnický obor, prodělala a neustále prodělává masivní

rozvoj. Snažíme se o neustálou miniaturizaci součástek, navyšování výkonových stropů, aby se výpočet účinnosti rovnal 1 a mnoho dalšího. S rozvojem elektroniky se začaly vytvářet i specializované podobory, které se soustředí na konkrétní vývojové oblasti. Jedním z nich je i vývoj elektroniky pro aplikace v leteckém průmyslu. Tento obor přejal název z francouzského slova avionique, čili avionika. Vývoj avioniky nastal již v 18. století, kdy bratři Montgolfriové poprvé použili Barometr pro měření nadmořské výšky. Postupně se začaly vyvíjet další a další přístroje, jejichž účelem bylo usnadnit pilotům řízení letadel, ať už se jedná o navigační přístroje (např. umělý horizont, výškoměr, kompas atd.), nebo přístroje určené ke kontrole aktuálního stavu letadla (např. palivoměr, otáčkoměr, průtokoměr atd.). Kokpity se začaly vybavovat řadou analogových prvků a mnohdy bylo potřeba, aby se řízení letu účastnil, kromě kapitána a prvního důstojníka, i palubní inženýr. Avšak s pokročilým vývojem elektroniky (IO, programovatelné obvody) se začaly přístroje digitalizovat, což jednak umožnilo vyšší míru automatizace řídících procesů a také to, že se jednotlivé zobrazovací prvky, resp. informace, které poskytovaly, začaly -1-


2015

shlukovat do rozměrnějších displejů, což je uživatelsky mnohem přívětivější a vede tak mnohonásobně ke zvýšení úrovně ergonomie řízení. Pilotovi „není“ třeba během všech fází letu neustále zobrazovat všechny dostupné informace, ale pouze ty, které jsou k dané fázi či úkonu potřeba. Takto se de facto vyvinul Glass Cockpit, který je typicky představován širokými LCD obrazovkami (Obr. 1). Běžné bývá rozložení na 2 PFD (Primary Flight Display) a 2 MFD (Multi-Function Display), kde PFD bývá rozděleno na ADI (Attitude Directional Indicator) a HSI (Horizontal Situation Indicator) část. MFD zobrazují informace týkající se motorů (dodávané například z FADEC), dále INAV (Interactive Navigation), Charts, Environment a mnoho dalších.

Obr. 1 Glass Cockpit [1] S rozvojem letectví jako takového, ale zaměřme se na civilní sféru, se začaly vyvíjet i organizace, jejichž účelem je vytvářet standardy v oblasti bezpečnosti letu a letecké přepravy jako celku. Globální standardy zastřešuje organizace ICAO (International Civil Aviation Organization), dále se působnost může rozpadat na úrovně nižší, „kontinentální“, kde působí organizace jako FAA (USA), evropská organizace EASA (nástupce JAA), nebo až na úroveň jednotlivých států. Například v České republice působí ÚCL, což je Úřad pro civilní letectví. Členské státy jednotlivých organizací a tím pádem i vývojáři a provozovatelé letecké techniky jsou zavázáni k naplňování jednotlivých standardů, čímž činí leteckou techniku způsobilou k provozu. Společnosti,

jež

se

zabývají

vývojem

letecké

techniky,

v našem

případě

avioniky/software, musí projít komplexním návrhovým a testovacím procesem, který je, -2-


2015

v případě splnění všech požadavků, završen certifikací. Tím je stanoveno, že daný výrobek je způsobilý k zařazení do provozu. Společnost musí takovýto certifikační proces definovat, respektive musí popsat, jakým způsobem hodlá finální certifikace dosáhnout. Jak konkrétně chce testovat jím vytvářené výrobky a zaručit tak požadovaný stupeň bezpečnosti.

1.1.

Popis avionického systému Jak již bylo zmíněno v úvodu, jedno z možných řešení Glass Cockpit je využití 2 PFD

a 2 MFD, plus záložní zobrazovací jednotky. Jednotlivé displeje jsou řízeny grafickými moduly, tzv. AGM (Advanced Graphic Module). Tyto moduly dostávají pokyny, jaké informace a jakým způsobem mají být zobrazeny (například: Left fuel tank = 200 lb, Normal, Valid). To znamená, že se zobrazí hodnota paliva v levé nádrži na hodnotu 200 lb, v zelené barvě a bez dalšího grafického efektu.

PFD

MFD

PFD

MFD Modulární Avionická Jednotka Senzory Obr. 2 Avionický systém

V úvodu dojde k měření hodnoty paliva, pomocí určitého senzoru. Ten na svém výstupu poskytne naměřená data a ta jsou následně přes určitou sběrnici předána do vstupně/výstupní karty, která je schopna tyto data přijímat. Dle dané aplikace závisí, jestli karta již obsahuje procesorový modul, který je schopný data vyhodnotit či ne. V případě, že není, jsou data předána procesorovému modulu, který je takového úkonu schopen. Po dokončení výpočtu jsou -3-


2015

data předána do grafického modulu s instrukcemi, jakým způsobem mají být prezentována. Zmíněné moduly jsou součásti tzv. modulární jednotky, někdy označované jako MAU (Modular Avionics Unit).

1.2

Vývojový proces Za účelem vývoje a testování je nutné mít fyzický hardware, na kterém by obě tyto

činnosti mohly probíhat. V prvotní fázi by však bylo velmi nepraktické, aby vývoj i testování probíhal na skutečném letadle. Z tohoto důvodu byl sestaven tzv. vývojový Bench. Jeho účelem je co nejvěrněji simulovat reálný kokpit letadla. Samozřejmě je sestaven tak, aby bylo možné optimálně provádět všechny výše zmíněné úkony, takže vizuálně jej lze přirovnat k sálovému počítači. Součástí Bench jsou zobrazovací jednotky, modulární jednotky a další periferie. Z praktického hlediska však není možné, aby součástí této simulační jednotky byly i všechny senzory, které se vyskytují na palubě letadla. Tudíž je potřeba vytvořit simulátor, který nahradí data vysílané jednotlivými senzory. Za tímto účelem byl sestaven tzv. TIU server. TIU (Test Interface Unit) je softwarový balík, který lze naistalovat na „běžný“ počítač. Ten musí dále obsahovat vstupně/výstupní karty jež jsou schopné obsluhovat sběrnice, které se fyzicky vyskytují na palubě letadla a jsou připojeny k modulárním jednotkám (např. RS-422, ARINC 429, ASCB atd.). Součástí TIU je pak databáze všech dat, resp. proměnných, které se v systému vyskytují (např.: proměnné určující stav paliva, měření výšky, AOA atd.). Databáze se tvoří tzv. konfiguračními protokoly. Jelikož se TIU chová jako standardní server, je možné se k němu pomocí SW klienta připojit. TIU server reaguje na určité datové pakety, které jsou mu vysílány a na jejich základě provádí určité operace. Kromě zápisu simulačních dat do systému tvoří TIU i kontrolní zpětnou vazbu. Jak je znázorněno na obrázku (Obr. 3), je TIU rovněž připojen i k dalším zařízením a to například přes sběrnici ASCB. Tímto způsobem je možné ověřit, jestli byla do systému zapsána správná data a také výsledky konkrétních úloh. TIU server, resp. jeho výstupy jsou fyzicky napojeny na ITA box, což je inteligentní přepínač. ITA je následně napojen na MAU. Pomocí ITA boxu se volí mezi simulovanými senzory (data z TIU) a senzory reálnými (např.: IRS senzory, GPS přijímači, DME, VOR, aktuátory atd.). V dalších fázích se provádí testy již na reálném letadle. Existují dva základní typy testů, a sice:  Pozemní testování (Ground Tests),  Testování za letu (Flight Tests). -4-


PFD

MFD

2015

PFD

MFD

TIU klient

TIU server

ITA

MAU

Control Obr. 3 Simulační systém

1.2.1 Testování Snahou je co nejvíce optimalizovat vývojový a testovací proces, důvodem je samozřejmě zvýšení rychlosti vývoje a snížení nákladů, které jsou s tím spojeny. Jelikož všechny vývojové týmy a odběratelé vyvinutých řešení nejsou zcela centralizovaní, tzn., že se nenachází na jednom konkrétním místě, vytváří se tím překážka ve vývojovém procesu (například: tým aplikačních inženýrů se nachází v Brně, tým produktových inženýrů se nachází v Phoenixu (USA) a koncový odběratel se nachází ve Švýcarsku). Tímto se zavádí hned 2 omezení, a to polohové a časové, z důvodu časového posunu a rozdílné polohy. Například inženýr, který se momentálně nachází ve Spojených státech amerických, není schopen plně manipulovat s Bench, který se nachází v Brně. Je nutné, aby byl v Brně přítomen další inženýr, který bude fyzicky obsluhovat Bench, dle jeho pokynů. Tento problém by mohl být řešen nástrojem pro vzdálené ovládání, avšak ne všechny součásti, které je nutné aktuálně využívat, disponují touto možností. V úvodu bylo zmíněno, že trendem ve vývoji avionických systému je tzv. Glass Cockpit. Což znamená nahrazování velkého počtu zobrazovacích jednotek počtem menším (viz kapitola 1.). Pilot však z důvodů, které jsou spojený s řízením, potřebuje vstupovat do systému a zadávat povely a informace. Tím, že se však zobrazovací části stávají komplexními, je poměrně nepraktické ke každé části obrazovky vytvářet i speciální hardwarový vstup. Takže, aby se mohl pilot na displejích „pohybovat“ a zadávat patřičné údaje (například: ve 2/3 části obrazovky PFD přeladit aktuální rádiový kanál, nastavit tlak na povrchu země, na 1/6 části -5-


2015

MFD nastavit letový plán atd.), potřebuje unifikovaný hardwarový vstup. K tomuto účelu se využívá pohybový joystick (CCD) a multifunkční klávesnici (MKB), viz Obr. 4. Jelikož je nutné v testovacím procesu navozovat různé scénáře, které se během letu odehrávají, a tím odhalit případné chyby v software, vzniká zde potřeba využívat i CCD a MKB panely. Nevýhodou je, že momentálně nejsou zcela použitelné v rámci Remote Control. Existuje sice řešení, avšak to spočívá v hardwarovém vstupu do testovacího systému, což je potencionální nevýhoda při případných změnách a vyvstává zde navíc otázka složitější certifikace.

Obr. 4 Control Cursor Device [2]

2

Řešení Aktuálním požadavkem je vyvinutí simulačního prostředí pro CCD a MKB, pomocí

kterého bude možné vzdáleně využívat funkčnosti obou reálných prostředků. Součástí mé práce je konktrétně vytvoření virtuálního CCD panelu, jehož použití bude uživatelsky přívětivější, než dosavadní řešení a které navíc bude zapadat do současného testovacího systému.

2.1

Aktuální stav Momentálně již existuje řešení (Obr. 5), které je postavené na hardwarovém zásahu do

simulačního systému. CCD je v běžném stavu (na palubě letadla) napojeno přímo na modulární jednotku. Aby bylo možné použít virtuální CCD, je nutné reálné zařízení odpojit od systému a místo něj připojit hardwarový výstup z PCI karty, která je nainstalovaná na počítači DFTS. Na tomto počítači je možné spustit exe aplikaci, která toto odpojení, resp. přepojení provede. Poté se spustí exe aplikace, která simuluje povely, jež reálně produkuje CCD. Koncová aplikace obsahuje řadu tlačítek, pomocí kterých lze pohybovat kurzorem po jednotlivých obrazovkách. Tzn. nahoru, dolů, vpravo, vlevo. Dále je zde tlačítko určené k nastavení citlivosti posunu kurzoru při jednom kliknutí. Nevýhodou hardwarových řešení je jejich poměrně složitá -6-


2015

aktualizace či razantnější upgrade. Další nevýhoda je, že toto řešení se liší od standardního certifikovaného testovacího systému.

SIM CCD

DFTS CCD

MUX

AGM

PFD, MFD

Obr. 5 Aktuální řešení

2.2

Nový přístup Snahou je tedy vytvořit softwarový simulátor, který bude zapracovaný do aktuálního

způsobu testování a tím všechny testovací procedury sjednotit. K tomuto účelu se využije již zmíněný TIU server. Nejnovější verze TIU obsahují řadu softwarových ovladačů, které „umí“ zacházet s různými vstupně/výstupními kartami. Například zapojení CCD CC-600 vyžaduje použití RS-422 modulu [3]. TIU již obsahuje potřebné ovladače pro jeho použití.

Control

CCD PC mouse & k-board

Client

ITA

AGM

PFD, MFD

TIU Obr. 6 Inovace v systému

Při tomto řešení je nutné provést fyzický wiring, čili přepojit výstup ze CCD na ITA box a zároveň napojit výstup z TIU (konkrétně RS-422 PCI modulu) do ITA. Výstupy z ITA jsou přivedeny na vstup modulární jednotky MAU, v tomto případě její součásti, a sice AGM karty. Pomocí ITA ovladače (nazývaný jako RACAL MUX, na Obr. 6 znázorněný jako Control) bude následně možné volit mezi simulovaným a reálným rozhraním. Následně je nutné vytvořit tzv. IO databázi, která popisuje data, jež jsou standardně produkována na výstupu reálného CCD zařízení.

-7-


2015

Vytvořit konfigurační protokol znamená nadefinovat všechny patřičné proměnné, jejichž hodnoty jsou přes sběrnici RS-422 vysílány do MAU ke zpracování. Reálné CCD CC600 periodicky vysílá zprávy o 36 bytech (informace o vysílači, hodnoty polohy kurzoru, STX a ETX byte atd.) [3]. Při konfigurace je nutné se pohybovat na bitové úrovni a postupovat od konfigurace komunikačních kanálů k datovým blokům, až ke konkrétním hodnotám bitů. Úkolem je vyhradit určité bity určitým proměnným, jejichž hodnotu budeme měnit pomocí softwarového klienta, například: 

DATA, Absolute X, Cursor position, UINT, 32, 5:32, 0, 1.000000, 0.000000, NA, 1



DATA, Absolute X, Cursor position, UINT, 40, 5:32, 0, 1.000000, 0.000000, NA, 2 Tímto TIU serveru říkám, vytvoř proměnnou Absolute X, typu UINT, počítej od 32.

bitu, vyhraď prostor 5 bitů z 32 pro horní byte polohy, počátečního hodnota je nula, rozlišení je 1, offset je nulový, nepřiřazuj jednotku. Takto vytvořený konfigurační soubor je poté nahrán do TIU serveru. TIU při spuštění na základě této konfigurace alokuje potřebnou paměť v paměti počítače (RAM - RWM). Každému alokovanému místu přiřadí jeho jedinečnou jmennou adresu, které obsahuje názvy stromové struktury, jež je definovaná v konfiguračním souboru: 

Serial Comm\Channel 1\Device-1\Position\Absolute X,



Serial Comm\Channel 1\Device-1\Position\Absolute Y. V konfiguračním protokolu je rovněž definováno s jakou periodou (jedná-li se o

periodickou strukturu) mají být data vysílána, na kterém konkrétním portu výstupní karty a jaké data mají být při inicializaci vyslána, plus další aspekty konfigurace. V dalším kroku je potřeba vytvořit softwarového klienta, který bude komunikovat s TIU a de facto přepisovat hodnoty proměnných v paměti. Aby byl systém co nejvíce uživatelsky přívětivý, přistoupilo se k vyžití počítačové myši, jakožto náhrada reálného CCD panelu (rovněž je plánováno využít počítačovou klávesnici jako simulátor MKB). Příslušný klientský software vyhodnocuje relativní polohu myši a počítá přírůstky změny polohy, přírůstky jsou následně ukládány do softwarových čítačů, jejichž hodnota je odesílána po LAN síti do příslušného TIU serveru. Je rovněž žádoucí využít i jednotlivá tlačítka: 

Levé tlačítko supluje funkci Enter reálného CCD,



Pravé tlačítko supluje funkci Push Button Menu,



Tlačítku Scroll bude ponechána stejná funkce. -8-


3

2015

Závěr Účelem této práce je pochopení avionického systému jako celku, lepší porozumění

datovým strukturám a toku dat, který v reálném letadle probíhá, efektivně navýšit testovací schopnosti reálného testovacího systému, snížit nároky kladené na pracovníky a rovněž potenciálně snížit vývojové náklady. Toto řešení by, kromě možnosti vzdáleného ovládání, rovněž mohlo přinést i možnost automatizace různých dějových scénářů, které se během testování provádí. To znamená, že by se například zadávání dat do FMS mohlo odehrávat automaticky s využitím simulovaného CCD a MKB, bez nutnosti zásahu testovacího inženýra. V nejbližších dnech by již mělo dojít k uvolnění první verze softwaru, která umožňuje vzdálené ovládání CCD.

Literatura [1]

AIRSOC. Falcon

2000LX [online].

2013

[cit.

2015-10-17].

Dostupné

z:

http://airsoc.com/articles/view/id/53bc38e9313944442c8b4568/falcon-2000lx-serialnumber-147-n786ad [2]

DASSAULT

FALCON. EASy

Flight

Deck [online].

[cit.

2015-10-17].

Dostupné

z:

http://www.dassaultfalcon.com/en/technology/pilotbenefit/pages/flight-deck.aspx

[3]

Honeywell International Inc. 2003. HARDWARE REQUIREMENTS DOCUMENT (HRD) FOR THE CC-600, CURSOR CONTROL DEVICE, HONEYWELL PART NUMBER 7028640-VAR: Engineering Specification. AES- BELL RD.

Dedikace Článek byl vypracován v rámci projektu rozvoje organizace UO - K206 s názvem „Komplexní elektronický systém pro UAS“.

-9-

Vzdálené ovládání testovací stanice

Recommend Documents