České vysoké učení technické v Praze Fakulta elektrotechnická. Diplomová práce

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Praha 2011

Tomáš Levora

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra měření Obor: Kybernetika a měření Zaměření: Letecké řídící a informační systémy

Vývoj systému pohyblivé mapy a modulu přijímače signálu GPS s rozhraním ARINC 743 Moving Map System Development with a GPS receiver with ARINC 743 Interface

   

Vypracoval: Tomáš Levora Vedoucí práce: Ing. Pavel Pačes, Ph.D. Rok: 2011

Čestné prohlášení autora práce Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací.

V Praze dne . . . . . . . . . . . .

........................... Tomáš Levora

Anotace Cílem této práce, řešené jako část projektu společnosti Honeywell Aerospace, je navrhnout zařízení, jež bude odesílat údaje o své poloze po letadlové sběrnici ARINC 429. Údaje o poloze, včetně časových značek, jsou získávány z průmyslového modulu GPS přijímače a dále slouží jako informace pro laserový gyroskop s rozhraním ARINC 743. Další součástí práce je úprava stávajícího softwarového vybavení – simulátoru grafického displeje, jež spočívá především ve zrychlení překreslování a přidání podpory pro několik programových rozhraní. Zmíněný simulátor je v aplikaci využit pro zobrazení měřených veličin gyroskopu.

Annotation The aim of this diploma work is to design device that transmits it’s position on the ARINC 429 bus. Device was designed as a part of a project in cooperation with Honeywell Aerospace company. Position and timestamps are obtained from the industrial GPS receiver module. Device is primarily used as a data source for an ARINC 743 laser gyroscope. Other part of this work is to modificate an existing software – graphic display simulator. Modifications consist of a frame rate acceleration and adding support for several user and data interfaces. The simulator is used in the application to view gyroscope and GPS measured values.

Poděkování Děkuji panu Ing. Pavlu Pačesovi, Ph.D. za vedení práce a panu Ing. Marku Fojtáchovi za mnoho cenných rad a připomínek.

12

Obsah Úvod

15

1 Úvodní informace 1.1. Družicové systémy určování polohy . . . . . . . . . 1.2. Formáty přenosu navigačních dat . . . . . . . . . . 1.3. Efemeridy a algoritmus výpočtu polohy družice 1.4. Sběrnice ARINC 429 . . . . . . . . . . . . . . . . . . . 1.5. Rozhraní ARINC 743 . . . . . . . . . . . . . . . . . . . 1.6. Alignment in motion . . . . . . . . . . . . . . . . . . . 1.7. Grafická rozhraní . . . . . . . . . . . . . . . . . . . . . . 1.8. Organizované uchovávání dat . . . . . . . . . . . . . 1.9. Dokumentace projektu . . . . . . . . . . . . . . . . . . 1.10. Verzovací systémy . . . . . . . . . . . . . . . . . . . . 2 GNSS senzor pro ARINC 429 2.1. Princip . . . . . . . . . . . . . . 2.2. GNSS přijímač. . . . . . . . . 2.3. Vysílač ARINC 429 . . . . . 2.4. Časování periferií . . . . . . . 2.5. Mikrokontrolér. . . . . . . . . 2.6. Programové vybavení . . . . 2.7. Ověření funkce. . . . . . . . . 2.8. Technické parametry . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 Simulátor displeje 3.1. Popis systému . . . . . . . . . . . . 3.2. Grafické rozhraní . . . . . . . . . . 3.3. Podpora souborového systému. 3.4. Správa paměti . . . . . . . . . . . . 3.5. Ukázkové aplikace . . . . . . . . . 3.6. Posuvná mapa . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

17 17 19 21 23 23 25 25 26 28 29

. . . . . . . .

33 33 33 35 38 38 39 42 45

. . . . . .

47 47 49 52 54 56 57

Závěr

61

Obsah CD

63

Příloha A

65

Příloha B

67

Použitá literatura

71

Seznam rovnic

73

Seznam obrázků

73

Seznam tabulek

73 13

14

Úvod Z praktické stránky je možné práci rozdělit na dvě části, kterými je možné zabývat se samostatně. Cílem první části práce je navrhnout elektronické mikroprocesorové zařízení, které prostřednictvím průmyslového GNSS modulu zajišťuje příjem informací z družic systému určování polohy GPS. Zařízení bude zpracovávat efemeridy a používat je pro určení poloh družic GPS, dále bude přijímat řadu veličin z GPS v souladu se specifikací ARINC 743[1]. Přijaté veličiny zpracuje ve smyslu převodu jednotek a určení jejich validity a následně odešle zakódované ve slova sběnice ARINC 429. Druhá část práce je věnována modifikaci stávajícího simulátoru vestavného zařízení s barevným grafickým displejem. Úprava spočívá ve zvýšení rychlosti překreslování zobrazovací plochy a dále v přidání podpory pro souborový systém uložený v operační paměti a procedur dynamického přidělování operační paměti procesům v rámci simulátoru. Pro přenositelnou část simulátoru je požadováno vytvoření referenční dokumentace. Informace o vlastní poloze a orientaci GNSS senzoru mohou být využity simulátorem vestavného zařízení s grafickým displejem pro zobrazení polohy na posuvné mapě, která se otáčí ve směru pohybu přístroje. Systém může být využit např. pro upozornění pilota proti srážce s terénem nebo jako prostá informace o objektech zájmu v okolí letu.

15

16

1. Úvodní informace 1.1. Družicové systémy určování polohy Družicové, tzv. globální, navigační systémy (zkráceně GNSS – Global Navigation Satellite Systems) nejsou navigačními systémy v pravém slova smyslu. Tyto systémy neposkytují žádná navigační data či služby, jsou určeny pouze pro určování polohy uživatele v blízkosti zemského povrchu. Princip měření této polohy, zpravidla udávané v polárních souřadnicích dvěma úhly a vzdáleností – zeměpisnou délkou, zeměpisnou šířkou a výškou nad referenčním elipsoidem, je dálkoměrný; nepřímo se měří vzdálenost přijímače od jednotlivých družic. Vzdálenost je možné určit ze známé rychlosti šíření elektromagnetického záření a doby přenosu signálu od družice k přijímači. Přenášená informace obsahuje data pro výpočet poloh jednotlivých satelitů. Na základě těchto hodnot máme k dispozici zpravidla přeurčenou soustavu rovnic o čtyřech neznámých – poloha je určena třemi parametry, čtvrtým je určení časového posunu interních hodin od absolutního časového měřítka. Řešením této rovnicové soustavy dostáváme polohu přijímače. Další používanou metodou určení polohy uživatelského přijímače je metoda Dopplerova principu. Tato metoda je založena na vyhodnocování změny nosné frekvence přijímaného signálu ze satelitních vysílačů. Rozdílový kmitočet je dán vztahem (1.1)  fd = fp − fv = fv

c −1 c + vα



 = fv

vα − c + vα

 ,

(1.1)

kde fd je měřený rozdílový kmitočet učený jako rozdíl kmitočtu přijímaného fp a kmitočtu vysílaného fv . Rychlost šíření přijímaného signálu je označena jako c a složka rychlosti pohybu družicového vysílače směrem k přijímači jako vα . Přijímač se nachází v okolí vysílače pod úhlem α ke směru jeho pohybu, pro rychlost v družice potom platí vα = v cos α. Úhel α je možné, při zanedbání rychlosti vα v součtu s rychlostí šíření c signálu, vyjádřit jako 

fd · c α = arccos − fv · v

 .

(1.2)

Opakováním měření ve více okamžicích, případně měřením více vysílačů zároveň, je takto možné získat mnoho parametrů, z nichž a ze známých poloh vysílačů lze 17

Úvodní informace

určit polohu přijímače. Pro každý úhel se může přijímač nacházet na povrchu kužele s vrcholem ve vysílači a vrcholovým úhlem dvojnásobku úhlu α dle (1.2). Mezi známé družicové systémy patří americký GPS (Global Positioning System), ruský GLONASS (Globalnaja Navigacionnaja Sputnikovaja Sistěma) a také se hovoří o vznikajícím evropském systému Galileo. Jednotlivé systémy mají odlišná technická řešení, přijímače tak disponují odlišnými hardwarovými prostředky. Výhodou těchto systémů je potřeba poměrně malého počtu družic, který je dán výškou nad zemským povrchem. Dokonce malý počet družic je schopen svým signálem pokrýt celý zemský povrch, přičemž s rostoucí vzdáleností družic od středu Země roste chyba určení polohy. Ta je dána především neideálním šířením elektromagnetického signálu všemi vrstvami zemské atmosféry (ionosféra). Signál se ve vrstvách láme a prodlužuje tím svoji dráhu. Tuto chybu je částečně možno korigovat parametrizací na základě šíření signálu na více nosných frekvencích, existují však i další zpřesňující postupy. Vedle systémů určených pro korekci průchodu signálu ionosférou je instalována síť podpůrných bodů pro zajištění vyšší přesnosti měření polohy. Tato síť je instalována na zemském povrchu, ale také na geostacionárních družicích. Systémy poskytující korekce ionosférické vrstvy atmosféry Země mívají jak družicové geostacionární (či geosynchronní) stanice, tak i stanice pozemní. Mezi tyto systémy (tzv. SBAS – Satellite Based Augmentation Systems či GBAS – Ground Based Augmentation Systems) řadíme evropský EGNOS, jehož družice jsou spravovány soukromým sektorem, dále americký státní WAAS, japonský MSAS nebo indický systém GAGAN. Pro lokální korekční systémy, v dosahu řádu několika stovek kilometrů, je používáno označení DGPS (Differential GPS). Princip těchto systémů spočívá v jejich umístění v blízkosti přijímačů, jejichž polohu určujeme. Tyto přijímače budou s velkou pravděpodobností přijímat signály stejných družic jako stanice DGPS, budou tedy ovlivněny stejnou chybou v každém časovém okamžiku měření polohy. Se známou polohou referenčních stanic je tak možné korigovat polohu přijímače signálu GPS. Korekce se obyčejně přenáší radiovým signálem některým z používaných protokolů, určených přímo pro šíření těchto korekcí. Případně jsou korekce šířeny 18

Úvodní informace

prostřednictvím GPRS. Formát korekcí je zpravidla RTCM SC-104 (The Radio Technical Commision for Maritime Services Special Committee 104). S těmito „online korekcemi je přesnost určení polohy v řádu centimetrů. Pro přesnější určení polohy jsou korekce dostupné s časovým zpožděním několika hodin až několika desítek hodin, používaný formát korekcí je RINEX. Všechny tyto druhy korekcí bývají zpravidla poskytovány komerčními subjekty za úplatu, cena je určena za časovou jednotku využívání služeb. 1.2. Formáty přenosu navigačních dat V tomto bloku uvedeme použité komunikační protokoly pro přenos informací z GNSS modulu do uživatelské aplikace. Jedná se o protokoly, které byly použity v naší aplikaci pro zpracování dat z GNSS senzoru. Pravděpodobně nejrozšířenějším komunikačním protokolem je NMEA 0183[11], který je implementovaný ve velkém množství komerčních přijímačů. Jedná se o textově orientovaný protokol, je tedy poměrně vhodný pro aplikace přímého zobrazení naměřených parametrů. Mezi často používané informace patrně patří údaje o zeměpisné délce a šířce uživatelského přijímače, výšce nad elipsoidem, informace o aktuálním čase a datu nebo také seznam všech viditelných družic včetně kvality přijímaného signálu a poloh těchto družic. Protokol je primárně určen pro přenos informace ze systému GPS. Každá zpráva protokolu NMEA0183 začíná speciálním zvoleným znakem $ (ASCII kód 36), za ním následuje textový řetězec složený z velkých písmen latinské abecedy, zpravidla se jedná o posloupnost pěti znaků. První dva znaky bývají ve standardních zprávách GP, dále následují znaky reprezentující kód konkrétní zprávy, podle kterého je možné určit strukturu právě přijímané zprávy. Po znakovém kódu zprávy následuje její tělo, tedy množina údajů vzájemně oddělených čárkami. Údaje mohou být číselné či znakové a nesou informaci podle svého pořadí ve zprávě. Mnozí výrobci navíc implementují řadu nestandardních NMEA zpráv, ve kterých nabízejí uživateli další informace, ve standardních zprávách neobsažené. Mezi takové patří např. zpráva $PUBX,03, která naší aplikaci poskytuje informaci o počtu družic používaných pro navigaci, zatímco standardní zprávy obsahují pouze informaci o počtu viditelných družic. Každá zpráva tohoto protokolu je zakončena 19

Úvodní informace

kontrolním osmibitovým součtem, který je opět v textové podobě připojen na konec zprávy a od jejího těla oddělen znakem hvězdičky (*). Po kontrolním součtu je ještě odeslána posloupnost dvou řídících bytů pro reprezentaci nového řádku. Jedná se o dvojici s kódem v šestnáctkové soustavě 0D, 0A. Druhým použitým protokolem je firemní protokol u-blox[10], ten je oproti předchozímu binární povahy a je tak vhodnější pro další počítačové zpracování. Jako binární protokol je také datově úspornější. Zprávy v protokolu NMEA jsou všechny řazeny na stejnou úroveň, u protokolu u-blox jsou zprávy rozděleny do skupin podle funkce. Jsou zde skupiny funkcí souvisejících s navigací, se surovými naměřenými daty z družic, jako např. efemeridy nebo informace o přijímaných satelitech (družicích). Případně skupina obsahující zprávy konfigurační. Začátky jednotlivých zpráv jsou opět označeny sekvencí bytů, v tomto případě se jedná o dvojici s hexadecimálním kódem B5 a 62. Za touto dvojicí následuje kód skupiny a kód zprávy ve skupině, oba údaje jednobytové. Dalším parametrem je délka datové části zprávy, která následuje. Celá zpráva je opět zakončena kontrolním součtem, tentokrát délky 16 bitů. Těchto zpráv využíváme v naší aplikaci větší množství, byť některé nesou stejnou informaci stejnou jako zprávy protokolu NMEA0183. Název zprávy

Popis obsahu zprávy

NAV-POSLLH

informace o poloze přijímače

NAV-DOP

přesnost, se kterou jsou určeny jednotlivé složky polohy

NAV-VELNED

rychlosti pohybu přijímače v soustavě NED(obr. 1.1)

NAV-TIMEUTC čas UTC, roky, měsíce, dny, hodiny, minuty, sekundy NAV-SBAS

informace o přijímaném systému SBAS

RXM-RAW

údaje o družicích (vzdálenost družic, síla signálu)

RXM-SVSI

podrobnější údaje o viditelných družicích (elevace, azimut)

AID-EPH

efemeridy družic

Tabulka 1.1 - Seznam binárních zpráv použitých v aplikaci. Podstatné jsou pro naši aplikaci zejména funkce navigační a stavové. Konkrétně se jedná o zprávy s kódovými značeními dle tabulky 1.1. Podrobné popisy zpráv jsou součástí specifikace protokolu u-blox[12]. 20

Úvodní informace

Ze zprávy NAV-POSLLH jsou pro vzniknuvší zařízení (ARINC 743 GPS přijímač) podstatné údaje o zeměpisné délce a šířce a výšce nad elipsoidem. Z druhé ze zpráv čerpáme informaci o DOP (Dilution of Precision) a to především vertikální a horizontální složky měřené polohy přijímače. Dále používáme velikosti rychlostí v soustavě NED (North, East, Down), tedy tří složek rychlosti pohybu přijímače. NED je pravotočivá pravoúhlá souřadná soustava se středem v přijímači a orientací osy Down směrem do středu Země, osy North směrem k severu a osy East na východ, graficky je soustava znázorněna na obrázku 1.1. Zpráva NAV-TIMEUTC je podstatná pro určení přesného globálního času. Ze zprávy NAV-SBAS vybíráme pouze informaci o tom, zda používáme SBAS pro zpřesnění určení polohy. Zpráva RXM-RAW nám slouží pro určení vypočtených vzdáleností družic a síly přijímaného signálu. V další zprávě je užita informace o počtu viditelných družic. Poslední zmíněná zpráva (AID-EPH) nese vysílaný efemerid podle specifikace[6].


  

 

 

 

Obrázek 1.1 - Vztah souřadných soustav ECEF a NED. Převzato z[8]. 1.3. Efemeridy a algoritmus výpočtu polohy družice Efemerida (Ephemeris) je soubor parametrů, které popisují dráhu pohybu vesmírného tělesa. Efemeridy (Ephemerides) se používají v astronomii pro popis drah astronomických těles, v mé práci je použito efemerid pro výpočet poloh družic 21

Úvodní informace

GPS. Každá efemerida obsahuje více či méně parametrů – v závislosti na přesnosti a algoritmu určování dráhy. Efemeridy pro popis drah družic GPS jsou popsány v dokumentu[6], ze kterého bylo převzato značení veličin. Mezi přední Keplerovy parametry patří velikost hlavní poloosy A dráhové elipsy, její numerická excentricita e a referenční čas v určitém bodě, ke kterému jsou určeny další parametry. Další tři Keplerovy parametry drah jsou sklon i0 dráhy družice vzhledem k rovníkové rovině v referenčním čase, rychlost změny sklonu IDOT a parametr perigea ω. Na následujících řádkách stručně popíšeme algoritmus, který je použit v zařízení pro výpočet poloh satelitů v souřadném systému ECEF (obrázek 1.1). Jedná se o kartézskou pravotočivou souřadnou soustavu s počátkem ve středu Země, osami x a y ležícími v rovníkové rovině, přičemž osa x směřuje k nultému poledníku, kterým prochází. Osa z prochází severním pólem. Součin gravitační (Newtonovy) konstanty a hmotnosti Země dává určitý parametr (geocentrickou gravitační konstantu), ze kterého je např. možné vynásobením čtvercem vzdálenosti určit gravitační zrychlení v dané vzdálenosti od středu Země. Ze vztahu (1.3), rovnosti gravitační síly a síly dostředivé při rotačním pohybu družice kolem Země, je možné určit rychlost pohybu |FG | = |GD |

⇒

κ·

MZemě · Mdružice Mdružice · v 2 = , r2 r

(1.3)

kde κ je gravitační konstanta, M s příslušnými indexy jsou hmotnosti Země a družice, v je obvodová rychlost družice a r je vzdálenost družice od středu Země (geocentrické dráhy družic). Po úpravě a dosazení vztahu mezi úhlovou a obvodovou rychlostí do rovnice (1.3) obdržíme vztah (1.4) pro úhlovou rychlost pohybu družice  n0 =

κ · MZemě , r3

(1.4)

kde n0 je při vzdálenosti r = A (podle notace[6]) úhlová rychlost družice na své dráze. Korekce rychlosti je zde aplikována jako rozdíl n0 a dalšího parametru efemeridy, korekce úhlové rychlosti Δn. Takto opravená úhlová rychlost je označována jako n a jedná se o úhlovou rychlost, jakou by měla družice pohybující se po kružnici o poloměru hlavní poloosy skutečné eliptické dráhy. Dále je možné určit (1.5) střední anomálii Mk (Mean Anomaly) jako součin úhlové rychlosti n pohybu družice 22

Úvodní informace

a časového intervalu tk , který určíme na základě aktuálního času – počet sekund od začátku týdne (začíná nedělí) korigovaného o čas toe přenášený v efemeridě. Takto spočtený úhel zvětšíme o úhel M0 z pericentru do daného bodu (parametr efemeridy) Mk = M0 + ntk .

(1.5)

Dále je potřeba numericky řešit Keplerovu rovnici (1.6) ve tvaru Mk = Ek − e sin Ek ,

(1.6)

kde Ek je excentrická anomálie (Eccentric Anomaly). Konečně je možné určit (1.7) pravou anomálii (True Anomaly) jako

√ sin Ek 1 − e2 vk = arctan . cos Ek − e

(1.7)

Zeměpisnou šířku Φk , popisující polohu družice je možné určit (1.8) prostým součtem anomálie vk a úhlu perigea ω. Φk = vk + ω.

(1.8)

Další parametr polohy je sklon dráhy ik , který určíme jako součet (1.9) sklonu dráhy i0 v referenčním časovém okamžiku a součinu úhlové rychlosti změny tohoto sklonu IDOT (parametr efemeridy) a času tk ik = i0 + tk · IDOT.

(1.9)

Třetím parametrem popisu polohy družice je vzdálenost rk družice od středu Země, kterou určíme jako rk = A(1 − e cos Ek ).

(1.10)

Podle[6] jsou dále provedeny korekce součtovými koeficienty pro všechny tři souřadnice. Korekční členy jsou přenášeny jako parametry efemeridy. Pro reprezentaci se často, v našem případě také, používá souřadné soustavy ECEF, do které je nezbytné polohu převést. 1.4. Sběrnice ARINC 429 Specifikace letadlové sběrnice ARINC 429 byla prostudována již v rámci mé bakalářské práce[3], ve které je možno nalézt její názorný popis i odkazy na mnohé další zdroje týkající se popisu letadlové sběrnice ARINC 429. 23

Úvodní informace

1.5. Rozhraní ARINC 743 Pod označením ARINC 743 rozumíme rozhraní pro GNSS (Global Navigation Satellite System) senzory[1] používané v leteckých aplikacích. Velká část specifikace se věnuje popisu jednotlivých labelů sběrnice ARINC 429 a způsobu kódování přímo či nepřímo měřených veličin do slov ARINC 429. Specifikace rozhraní ARINC 743 je uzavřená a společnost ARINC ji poskytuje za úplatu. Rozhraní ARINC 743 zpřístupňuje informace získané z GNSS, primárně se předpokládá využití GPS, je ovšem možné zpracovávat i signály GLONASS a také použít zpřesňující údaje z různých SBAS a GBAS. V tomto ohledu specifikace definuje několik módů, ve kterých se GNSS senzor může nacházet v závislosti na počtu zpracovávaných družic a dle těchto stavů přiřazuje jednotlivým odesílaným slovům příslušné kódy SSM datového pole. Zařízení s plnou podporou ARINC 743 by také mělo disponovat příslušnými ARINC 429 vstupy s možností nastavení interních proměnných s některými uloženými veličinami pro odesílání. Specifikace dále omezuje elektrický výkon zařízení a zabývá se použitými aktivními či pasivními anténami. Odesílaná slova jsou podle labelů rozdělena do dvou skupin – Measurement Block a Navigation Block. První ze zmíněných se skládá ze slov určených pro každý satelit, pro který jsou dostupné veškeré údaje. Odesílá se v nich poloha satelitu, informace o čase a údaje o naměřených vzdálenostech satelitů od přijímače. Tento blok se vysílá opakovaně pro každou družici. Druhý blok je tvořen slovy nezávislými na konkrétní družici. Je zde přenášena poloha přijímače, jeho rychlost a čas. Dále také stavové slovo. Jednotlivé odesílané labely jsou uvedeny v příloze, v tabulce 0.1, oba bloky jsou od sebe v tabulce odděleny vodorovnou čarou. Dalším podstatným parametrem je časová značka odesílaná na diferenční sběrnici RS-422. Časové značky slouží zařízení pro časovou synchronizaci s globálním časem UTC (Universal Time Coordinated). Každá časová značka slouží jako přesná informace o nastalé časové události. V našem případě rozumíme časovou událostí změnu celé sekundy v systému UTC. Tyto časové značky nepřenáší údaje o absolutním čase, ty jsou zároveň (v rámci datového bloku) přenášeny po sběrnici ARINC 429. Přenáší se jak datum, tak i čas. Časové značky jsou přenášeny prostřednictvím dvojice vodičů. Přenášený signál je obdélníkový impuls délky 1 ms 24

Úvodní informace

posílaný s periodou jedné sekundy, zarovnaný na čas UTC. Jsou definovány délky obou hran pulsu. Puls je znázorněn na obrázku 1.2, délka pulsu a je rovna 1 ms, náběžná a spádová hrana b je nejvýše 200 ns a perioda pulsu c je 1000 ms.

napětí Vss

0

a

b

čas

c Obrázek 1.2 - Časová značka podle specifikace ARINC 743. Podle[1] 1.6. Alignment in motion Motivací pro návrh zařízení v této diplomové práci je funkce „Alignment in motion. Jedná se o funkci, kterou mohou využít systémy inerciální navigace, v našem případě laserový gyroskop. Motivací pro zrození systému zarovnání inerciální navigace za letu je důvod vzniku možných výpadků napájecího napětí na přívodu do systému inerciální navigace. Tyto výpadky mohou být způsobeny mechanickými vibracemi letadla a mají jen velmi krátké trvání[13]. Po dobu výpadku systém nemůže integrovat zrychlení, ani úhlové rychlosti a připočítávat tak vzdálenost letu. Tímto vzniká chyba určení polohy letadla, kterou je možné v takových okamžicích korigovat např. na základě vhodného systému absolutního určování polohy. Informaci o absolutní poloze je dále možno využít v systému inerciální navigace ke zpřesňování počítané polohy letadla. Tato funkce přímo nesouvisí s diplomovou prací, nicméně zařízení, které bylo v rámci práce navrženo, bude použito pro připojení k systému inerciálních senzorů (laserový gyroskop) a bude sloužit jako GNSS senzor. Výsledek měření polohy a polohových úhlů je přenášen na palubní desku, kde se zobrazuje na palubních zobrazovačích. Problematika zobrazování informací je rozebrána v další kapitole. 1.7. Grafická rozhraní Pro urychlení vykreslování grafických scén na osobních počítačích existuje ně25

Úvodní informace

kolik programových knihoven s volně dostupným zdokumentovaným aplikačním rohraním. Knihovny jsou zpravidla využívané pro tvorbu počítačových her, umožňují vykreslování trojrozměrných geometrických scén, ale mají také rozhraní pro síťovou komunikaci či zvukové vstupy a výstupy. Mám na mysli knihovny OpenGL[20] a DirectX[21]. V širším smyslu existují i jiné knihovny, které jsou ovšem orientované na tvorbu kompletního uživatelského grafického rozhraní a dále se nezabývají nižšími vrstvami. Tyto knihovny zpravidla mohou pracovat nad zmíněnou OpenGL platformou, jedná se např. o knihovny SDL[19], GLut[22] nebo Qt[23] či rozhraní operačních systémů Windows, MFC[18] nebo Win32. Multimediální knihovna DirectX obsahuje, mimo jiné, funkce pro grafický výstup s možností kreslení dvourozměrných geometrických útvarů. Takový modul se jmenuje DirectDraw a v současné době je označen za zastaralý. Jeho náhradou má být množina funkcí skrývající se pod názvem Direct2D, tato část je však podporována až v novějších verzích operačních systémů Windows. Paralelně s tímto modulem se v aplikačním rozhraní DirectX nachází modul Direct3D, jenž obsahuje předpisy funkcí pro práci s trojrozměrnými objekty. Tato část také byla využita v aplikaci simulátoru vestavného zařízení s integrovaným grafickým displejem pro zvýšení vykreslovací frekvence. Přestože není žádný trojrozměrný objekt vykreslován. Pro použití Direct3D je nejprve nezbytné provést inicializaci, ve které se nastaví způsob vykreslování scény, její osvětlení a scéna se vymaže. Ve své aplikaci používáme vlastního bufferu, takže v periodických dávkách jsou volány funkce pro kopírování vlastních bufferů do videopaměti. Pro vykreslování nepoužíváme žádných funkcí pro kreslení geometrických útvarů, vykreslujeme pouze seznam bodů – pixelů. Rozhraní OpenGL nabízí řadu funkcí pro vykreslování jak dvourozměrných, tak i trojrozměrných grafických scén. Opět je zde nezbytná inicializace, ve které se nastaví rozměr plochy a souřadná soustava, do které jsou objekty umisťovány. V periodických dávkách je také kopírován buffer přímo do videopaměti a dále je zajištěno přepínání bufferů přímo ve videopaměti. 1.8. Organizované uchovávání dat Jedním z úkolů této práce je přidání podpory virtuálního paměťového média se 26

Úvodní informace

souborovým systémem. Cílem je přistupovat ke všem souborům stejně jako by byly uloženy ve virtuálním souborovém systému (struktura souborových systémů viditelná operačním systémem). Souborový systém bude v aplikaci použit především pro čtení předem uložených dat (v inicializaci načtených ze skutečného souborového systému). S ohledem na tuto skutečnost není nezbytné provádět implementaci moderního souborového systému s možností žurnálování. Postačuje potom libovolný jednodušší souborový systém. Výhodu by ovšem měla implementace souborového systému pro paměti typu flash (NOR nebo NAND) a to z důvodu možného nasazení na skutečném vestavném zařízení s připojenou SD (Secure Digital) nebo CF (Compact Flash) kartou, případně SSD (Solid State Drive). Flash paměti mají omezený počet přepisů každé paměťové buňky a vhodný souborový systém (JFFS, NILFS a další) se snaží počet zápisů a přepisů rozložit na celé médium rovnoměrně, případně má možnost označit určité oblasti za již nepoužitelné. Nicméně i v praxi (digitální fotoaparáty různých výrobců) se na flash pamětech používá souborového systému FAT (File Allocation Table)[24]. V případě implementace souborového systému pouze do simulátoru vestavného zařízení není příliš podstatné jaký systém zvolíme. S ohledem na příští možnou implementaci ve skutečném vestavném zařízení, jak bylo naznačeno, je však jeho volba důležitá i z jiného pohledu. Jelikož není velké množství existujících souborových systémů podporováno všemi, nebo alespoň velkým množstvím obecných platforem (např. operačních systémů na osobních počítačích), volíme souborový systém takový, který nebude velký problém číst a zapisovat např. na osobním počítači s čtečkou SD karet. V tomto ohledu se jako vhodný opět jeví souborový systém FAT.

Souborový systém FAT pochází z konce sedmdesátých let minulého století, s postupem času byl však dále vyvíjen. Navenek, z pohledu uživatele, došlo k rozšíření možné velikosti ukládaných souborů a také délce názvů souborů a adresářů. Paměťové médium obsahující souborový systém FAT začíná zpravidla několika rezervovanými sektory (na IBM-compatible PC např. boot sektor), následuje tabulka alokací (FAT) a dále je již oblast určená pro soubory, adresáře a kořenový adresář. Každý soubor a adresář je uvozen svojí hlavičkou, jež obsahuje informaci o názvu souboru, právech přístupu, času a době vytvoření, posledního zápisu a přístupu. 27

Úvodní informace

Také obsahuje informaci o délce souboru a jeho umístění ve formě indexu v jednotkách clusterů (viz dále). Všechna data jsou uložena v tzv. clusterech, což jsou datové jednotky o délce zpravidla 512 B, na které je rozděleno celé paměťové médium. Každý cluster je označen příznakem, podle kterého nadřazený systém pozná, zda se jedná o cluster volný nebo třeba vadný. Jelikož nebyl souborový systém implementován, ale byla pouze zvolena již hotová knihovna, která vyžaduje doprogramování pouze nejnižších vrstev, není zde FAT systém rozebrán příliš dopodrobna. 1.9. Dokumentace projektu Dále představíme dokumentační systém, který je použit pro řešení elementární části zadání, dokumentace části již existujícího, prostudovaného, zdrojového kódu. Dále kapitolu doplníme o několik slov k verzovacím systémům, jichž bylo využito ke sdílení změn jednoho z řešených projektů. Jedním z nejznámějších a nejpoužívanějších volně šiřitelných (licence GNU GPL) dokumentačních nástrojů je projekt Doxygen[26]. Projekt slouží pro usnadnění a automatizaci procesu tvorby referenčních příruček k softwarovým produktům. Jedná se o dávkově spouštěný program, který na základě jednoduchých skriptovacích příkazů a tagů umístěných do zdrojového kódu dokumentované aplikace vygeneruje výstupní dokument v některém či několika univerzálních formátech, mezi které patří např. HTML nebo PDF. Dokumentované zdrojové kódy jsou tedy nezbytně rozšířeny o speciálně vymezené komentáře, které obsahují skriptovací příkazy programu Doxygen. Výstupní dokument předně neslouží jako programátorská dokumentace (ta je zapsána v klasických komentářích zdrojového kódu aplikace), nýbrž jen jako reference pro uživatele programového produktu. Výstup je koncipován spíše jako dokumentace rozhraní a nikoliv jako řešení programátorského problému. Dokumentaci je dále možné rozšiřovat o souvislou textovou informaci doplněnou obrázky či jinými informacemi, jako např. matematické rovnice nebo grafy závislostí jednotlivých komponent a modulů. Generovanou referenci v HTML je možné sdílet prostřednictvím webových stránek a poskytnout tak potenciálním či již stávajícím uživatelům rychlý přehled a 28

Úvodní informace

pomoc pro využívání dokumentovaného kódu. Dokumentace ve formátu PDF je koncipována jako souvislý strukturovaný textový dokument doplněný o potřebnou grafiku. Taková dokumentace je vysázena prostřednictvím typografického programového balíku TEX s makrovou nadstavbou LATEX. Tento dokumentační nástroj byl, po konzultaci se zadavatelem projektu, zvolen pro vytvoření dokumentace aplikačního rozhraní grafické knihovny projektu simulátoru displeje. Tato knihovna je a bude v budoucnu využívána studenty předmětu Přístrojové systémy letadel a její zdokumentování má za účel studentům usnadnit její používání a integraci do svých projektů. Kromě zde představeného dokumentačního nástroje Doxygen existuje řada dalších nekomerčních programů, které se používají pro tytéž účely. Mezi ty známější patří např. DocBook[27]. Jedná se také o dokumentační nástroj s mírně odlišným přístupem. Kód vytvářené dokumentace je založen na XML a systém ve svém principu neumožňuje automatické generování dokumentace ze zdrojových kódů, nicméně je stejně jako systém LATEXpro tvorbu dokumentace využíván. Podobně orientovaný systém jako Doxygen je DocBy.TEX[28] a zde je zmíněn jako další možná, ovšem ne tolik rozšířená, varianta dokumentačního systému. Princip je v podstatě stejný, navíc je třeba přidat ke každému zpracovávanému souboru externí soubor s popisy. Výstup je velmi přívětivý, pro generování textového dokumentu je nezbytný systém TEX. Mezi další volně používané nástroje patří např. troff, texinfo, POD či standardní HTML, XML, TEX či LATEX. 1.10. Verzovací systémy Systémů pro správu verzí vytvářených elektronických děl využíváme především jako záložních systémů s možností sdílení vytvářených produktů. Verzovací systém oceníme především při práci na projektu s více přispěvateli nebo v případě potřeby uchovávání starších verzí vytvářených děl. Uživatelé verzovacích systémů mají tedy možnost kdykoliv přejít ke starší datované verzi vznikajícího díla. Některé systémy jsou navíc schopny větvění. Tímto způsobem lze vytvářet více paralelních variant a tím vzniká stromová struktura jednotlivých verzí. Každé úložiště dat verzovacího systému nazýváme repozitářem. Z repozitáře může čerpat data a do repozitáře přispívat obecně více uživatelů. Systémy umožňují 29

Úvodní informace

aktualizaci dokumentů na základě rozpoznaných změn a vhodným způsobem spojovat provedené změny. Z důvodu aplikování diferencí nejsou verzovací systémy příliš vhodné pro binární data, zatímco pro textově orientovaná díla je jejich nasazení velmi vhodné. Používáme jich tedy pro zdrojové kódy programů, binární produkty takto často nesdílíme, přestože je to také možné. V případě sdílení binárních dat, která mohou mezi dvěma sousedními verzemi obsahovat velké změny, může pouze rychleji narůstat velikost repozitáře produktu. Verzovací systémy základně rozdělujeme na systémy centralizované a decentralizované. První uvedená skupina, centralizované systémy, disponuje pouze jediným repozitářem přístupným všem jeho uživatelům. Tito uživatelé si skrze něj vyměňují a sdílí svá data a samozřejmě jejich verze. Tento typ je z dnešního pohledu již zastaralý, přesto na některých místech, často asi z historických důvodů, stále používaný. V případě decentralizovaných systémů má každý uživatel svůj vlastní repozitář umístěný zpravidla na své lokální stanici. S tímto repozitářem obyčejně pracuje a vytváří v něm změny. Zpravidla tak existuje jeden výchozí sdílený repozitář, který si všichni jeho uživatelé celý stahují, případně stahují pouze jeho změny. Přispívající uživatelé také mohou změny ve svém repozitáři připojovat k repozitáři tomuto, veřejnému. Mezi centralizované verzovací systémy patří např. CVS[31], či Subversion[32]. Moderní, distribuované systémy jsou např. Git[29] nebo Mercurial[30]. Název

Adresa

Verzovací systém

Google Code

code.google.com

Mercurial

SourceForge

sourceforge.net

Git

?

SourceForge

sourceforge.net

Mercurial

?

SourceForge

sourceforge.net

Bazaar

?

GitHub

github.com

Git

300

repo.or.cz

repo.or.cz

Git

400

Codeplex

codeplex.com

Mercurial

Tabulka 1.2 - Porovnání verzovacích systémů.

30

Prostor (MB) 2 048

?

Úvodní informace

Poskytovatelů verzovacích systémů existuje celá řada, uveďme zde pouze několik nejvhodnějších. Vhodnost je posuzována z pohledu jejich známosti a viditelnosti na síti internet. Předpokladem je, že viditelnější konzervativní systémy s dlouhou historií mají i jistější a stabilnější budoucnost. V tabulce níže jsou uvedeny některé parametry rozhodující o volbě verzovacího systému. Dále jsou uvedeny pouze verzovací systémy decentralizovaného typu. Pro náš projekt jsme zvolili decentralizovaný verzovací systém Mercurial poskytovaný serverem code.google.com. Z našeho pohledu je velmi vhodný z důvodu velikosti poskytovaného prostoru a pro poskytování decentralizovaného systému. Další výhodou je možnost modifikace webového rozhraní a přidání vlastních webových stránek, jako např. výše zmíněné dokumentace v Doxygenu. Dále je na server možno umístit kompletní distribuci, tedy kompletní verzi bez historie, ke stažení. Tento přístup má výhodu v poskytování hotových produktů uživatelům, kteří neocení kompletní historii produktu, ani nemají v úmyslu produkt modifikovat za účelem sdílení jeho změn. Jedna jediná verze vytvářeného díla má zpravidla zanedbatelnou velikost v porovnání s celou jeho historií.

31

Úvodní informace

32

2. GNSS senzor pro ARINC 429 V následujících odstavcích je představena jedna ze dvou hlavních částí diplomové práce. Jedná se o návrh zařízení, jenž v práci označujeme jako GNSS senzor podle specifikace ARINC 743. Cílem je návrh elektronického zařízení založeného na mikroprocesorovém řešení. Návrh spočívá především ve vytvoření programového vybavení zmíněného mikrokontroléru a připojení k potřebným hardwarovým periferiím. 2.1. Princip Navrhované zařízení, GNSS senzor s výstupem na sběrnici ARINC 429, je konstruováno za účelem výzkumu v oblasti systémů určování polohy. Zařízení bude pracovat v aplikaci společně s laserovým gyroskopem, kterému bude prostřednictvím sběrnice ARINC 429 poskytovat naměřené údaje z GNSS přijímače. Dalším výstupem zařízení jsou časové značky na diferenční sběrnici. Zařízení sice není určeno pro provoz v letadle, přesto bude napájeno v souladu s palubními rozvody stejnosměrného napětí, požadavek zadavatele je 28 V. Senzor může být připojen na stejné napětí jako gyroskop. Cílem této práce není navrhnout komplexní GNSS senzor podle specifikace ARINC 743, nýbrž zařízení, které bude vyhovovat minimálním požadavků pro připojení k laserovému gyroskopu. V práci tak není nezbytné řešit vstupy ARINC 429, byť jsou hardwarově připraveny, stejně tak není nezbytné generovat všechny předepsané labely, ale pouze ty, které gyroskop vyžaduje. V tomto ohledu je specifikace rozhraní ARINC 743 chápána pouze jako doporučení a vodítko. Blokové schéma zařízení je uvedeno na obrázku 2.1. 2.2. GNSS přijímač Pro příjem a zpracování GNSS signálů byl zvolen průmyslový komerční modul LEA-6T společnosti u-blox[10]. Tento produkt byl vybrán z důvodu vhodné frekvence poskytování naměřených dat a také pro typ poskytovaných informací. Perioda výstupu měření bývá obyčejně rovna jedné sekundě, pro námi zvolený produkt je nastavitelná už od 200 ms, s tím ovšem souvisí úmerně rostoucí požadavek na výkonovou spotřebu modulu. Podle ARINC 743 je sice nejvyšší dovolené zpoždění právě 33

GNSS senzor pro ARINC 429

200 ms, podle zadání však není nezbytné pro požadovanou přesnost tuto podmínku striktně dodržet, je však žádoucí další přídavná zpoždění minimalizovat. Vnešená zpoždění mohou být způsobena výpočty poloh družic z efemeridů a sestavování všech slov s veličinami. V tomto ohledu musí být zvolen mikrokontrolér s vhodnou instrukční sadou pro prováděné výpočty. Vhodná je podpora výpočtů v pohyblivé řádové čárce s přesností double podle normy IEEE 754 na úrovni instrukční sady. Ocenitelná je také implementace výpočtu goniometrických funkcí vhodných pro výpočty poloh družic z efemeridů.

Obrázek 2.1 - Blokové schéma navrženého zařízení. Gyroskop požaduje, s ohledem na specifikaci ARINC 743, množství měřených veličin. Především jsou to polohy přijímaných satelitů, které jsou spočteny[6] v našem zařízení z poskytnutých efemeridů. Dále jsou to informace o přesnosti měření, informace o aktuálním datu a čase, spočtená poloha jako zeměpisná šířka (latitude) a zeměpisná délka (longitude), rychlost pohybu rozložená do třech směrů, průmět rychlosti na povrch Země, směr (kurz) pohybu a další. Tyto údaje jsou vyslány GNSS senzorem ve zprávách formátu NMEA a UBX uvedených v tabulce 1.1. Po přijetí zmíněných zpráv naším zařízením dochází ke zpracování přijatých zpráv a následnému odeslání obsažených a vypočtených fyzikálních veličin na sběrnici ARINC 429 v příslušných slovech aplikační vrstvy protokolu. 34

GNSS senzor pro ARINC 429

Zvolený GNSS přijímač umožňuje zpracovávat signál z družic systému GPS a je připraven pro příjem signálu Galileo. Pravděpodobně z důvodu technologických rozdílů není podporován existující systém Glonass. Dále přijímač umožňuje zpracovávat signál z SBAS (Satellite Based Augmentation System), konkrétně WAAS, EGNOS, MSAS a GAGAN. Modul přijímače LEA-6T je do aplikace možné připojit prostřednictvím UART kanálu, I2 C nebo USB sběrnice. Dokonce je možné používat i více sběrnic zároveň a ke každé přistupovat nezávisle. To je pro naši aplikaci velmi vhodné, jelikož pro větev zpracovávání dat před odesláním na sběrnici ARINC 429 můžeme pro odesílání využít UART kanálu, zatímco pro paralelní zpracování signálu na osobním počítači bude využito USB rozhraní. Modul také disponuje rozhraním pro aktivní anténu – umožňuje její napájení přes signálový, anténní, vodič. Anténu je tak možné napájet buď z externího zdroje napětí v rozsahu hodnot 3,3 V a 5,5 V, nebo přímo z modulu napájecím napětím. Pro nastavení napájení aktivní antény je nezbytné osadit pouze jediný rezistor. Modul GNSS disponuje hlídacími obvody pro řízení a monitorování stavu antény, detekuje tak na základě proudové spotřeby stav připojení či zkratu (velké spotřeby) antény. Pro implementaci do aplikace je možné zapojit pouze napájení 2,7 V – 3,3 V, anténu a připojit komunikaci. Žádných dalších periferií není třeba. Při napájecím napětí 3 V se spotřeba pohybuje pod 70 mA a je samozřejmě závislá na frekvenci výpočtu a rychlosti odesílání naměřených dat. Zařízení je navrženo pro funkci s pasivní anténou, či anténou aktivní s napájením 3,3 V. 2.3. Vysílač ARINC 429 Pro implementaci fyzické vrstvy jsme použili obvodů fy Holt[16], konkrétně budič sběrnice HI-8585 a pro případ budoucího rozšíření zařízení o příjem na sběrnici ARINC 429 i přijímač HI-8588. Tyto obvody zajišťují fyzickou vrstvu sběrnice ARINC 429 a na svém výstupu v případě budiče a vstupu v případě přijímače mají dva CMOS diferenční signály proti nule přesně tak, jaké jsou na výstupu s rozdílem velikosti amplitudy a délky náběžných a spádových hran. Pro řízení těchto obvodů a vytvoření vyšší vrstvy řízení sběrnice je připojen obvod HI-6010, jenž komunikuje s nadřazeným systémem prostřednictvím paralelní datové osmibitové sběrnice a řady řídicích signálových vodičů. Tento obvod se stará o odesílání a pří35

GNSS senzor pro ARINC 429

jem datových slov na sběrnici ARINC 429, detekuje chyby na sběrnici a dopočítává kontrolní paritní bit odesílaných slov. Řadič sběrnice obsahuje interní 32bitový buffer na odesílaná i přijímaná datová slova, odesílání je možné po uložení slova do bufferu iniciovat jednovodičovým řídícím signálem – triggerem. Obvod HI-6010 disponuje jedním řídícím vodičem pro rozlišení způsobu komunikace. Přivedením tohoto vodiče do jedné logické úrovně způsobí přepnutí stavu do příkazové komunikace, potom jsou přenášená data ukládána do nastavovací části obvodu a případně čtena data ze stavového registru. Pokud je vodič přiveden do druhé logické úrovně, do bufferu obvodu jsou přenášena datová slova sběrnice ARINC 429, případně čtena dříve přijatá slova. Zápis, popř. čtení bytu se provádí pulsem na příslušném vodiči. Pokud dojde k jakékoliv chybě, např. přijetí slova s chybnou paritou nebo přepsání vstupního bufferu novým slovem před vyčtením původního, je nastaven chybový pin, který je nezbytné neustále kontrolovat a na chybu reagovat vyčtením stavového registru. Při odesílání slov není nezbytné počítat paritní bit, ten spočítá obvod sám – toho jsme v aplikaci také využili. Pro příjem slov na sběrnici ARINC 429 může být využito jednovodičové indikace stavu příjetí slova. Obvod dále umožňuje pro příjem filtrovat příchozí slova podle přednastavené databáze a již na hardwarové úrovni neakceptovat nepožadovaná slova. Ohledně seznamu labelů slov, která je nezbytné posílat na sběrnici ARINC 429, je vhodné řídit se specifikací rozhraní ARINC 743. Veškeré potřebné informace jsou v této specifikaci obsaženy. V práci uvádíme pouze krátký seznam zpracovávaných labelů v příloze, v tabulce 0.1. Seznam labelů má sloužit pro představu o rozsahu zpracovávané oblasti a požadavků kladených na rychlost zařízení. V žádném případě neslouží jako opis specifikace, v tomto smyslu byly také vypuštěny ostatní parametry jednotlivých labelů. V práci jsme však čerpali přímo ze specifikace a řídili se jejími doporučeními. Sestavení jednotlivých labelů se řídí specifikací sběrnice ARINC 429. Existuje zde však i několik výjimek, které specifikace nerespektuje. Většina posílaných zpráv je binární povahy s délkou hodnoty slov do 18 bitů. Uložení do přenášeného slova dle specifikace je znázorněno na obrázku 2.2. Každé slovo je zakódováno do binární podoby ve dvojkovém doplňku na délku a rozlišení nejnižšího bitu podle specifikace 36

GNSS senzor pro ARINC 429

ARINC 743. Délka slov je však prakticky vždy o jeden bit delší, protože bit na pozici 29 slouží k určení znaménka přenášeného datového slova. Dále je slovo doplněno bity dle znaménka na délku 18 bitů, ovšem pouze pokud tuto délku již nemá.

8 label

1 9 10 11 SDI (LSB)

data

29 30 31 32 (MSB) SSM P

Obrázek 2.2 - Uložení binární hodnoty do slova. Publikováno v[3]. Nachází se zde však v rozporu se specifikací ARINC 429 i některá slova o délce binární hodnoty 20 bitů. Pro tento případ je postup kódování zcela stejný, hodnota je potom do zprávy uložena i přes pole SDI, které je z tohoto důvodu ze zprávy zcela vypuštěno. Tento způsob kódování je znázorněn na obrázku 2.3, pro srovnání je standardní způsob kódování binárních slov na obrázku 2.2.

8

1 9 label

data

(LSB)

29 30 31 32 (MSB) SSM P

Obrázek 2.3 - Uložení 20bitové hodnoty do slova. V souboru odesílaných labelů se objevují také labely obsahující hodnoty svých veličin kódované v BCD, jedná se o informace o čase a datu. Zde se samostatně kódují všechny cifry zobrazovaného či přenášeného číselného údaje a následně jsou poskládány za sebe ve smyslu názorného obrázku 2.4. Specifikace má opět své výjimky a tak není přesně dodržena délka kódování jednotlivých cifer. Některé jsou kratší z důvodu fyzikálního omezení svého rozsahu, takže např. první cifra hodnoty popisující číslo dne v měsíci může být z pochopitelných důvodů vždy zakódována do dvou bitů.

29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 číslice1 číslice2 číslice3 číslice4 číslice5 Obrázek 2.4 - Uložení BCD hodnoty do slova. Publikováno v[3]. Kromě zmíněných slov jsou podle specifikace ARINC 743 přenášena stavová slova charakteru binárního, nikoliv ve smyslu kódování jedné konkrétní veličiny, nýbrž z pohledu diskrétního kódování stavové informace. V těchto slovech jsou uloženy údaje o použití SBAS a počtu viditelných družic. Stavové slovo každé družice 37

GNSS senzor pro ARINC 429

potom nese informaci o svém identifikačním čísle a např. informaci o tom, zda byl použit pro výpočet polohy družice almanach nebo efemerida. 2.4. Časování periferií Mezi další hardwarové výstupy patří časování hardwarových periferií. V závislosti na požadované přesnosti je použito dvou zdrojů informace o čase. Přesnější, poměrně dobře konfigurovatelný, zdroj hodin je GPS modul se dvěma nezávisle nastavitelnými časovými výstupy s možností konfigurace generování v závislosti na absolutním čase. Generované časové pulsy s nastavitelnou periodou mohou být zarovnány na celé časové jednotky a mohou být odvozeny buď z globálního absolutního času přijímaného z družic nebo lokálního oscilátoru GPS modulu. Zdroj hodin GPS byl použit pro generování referenčního signálu podle obrázku 1.2 nesoucího část informace o absolutní hodnotě času. Téhož pulsu je použito v mikrokontroléru pro detekci vhodného okamžiku pro odeslání naměřených a přepočtených veličin na sběrnici ARINC 429. Před odesláním pulsu do připojeného gyroskopu je upravena jeho napěťová úroveň dle specifikace ARINC 743. Interního oscilátoru mikrokontroléru, jehož frekvence je odvozena od externího krystalu, je využito pro časování sběrnice ARINC 429. Časování sběrnice je řízeno obdélníkovým signálem připojeným jako vstup řadiče sběrnice, obvodu HI-6010. Signál je připojen samostatně pro přijímač a pro vysílač. Jeho frekvence je čtyřnásobná oproti požadované rychlosti sběrnice. Pro 100 kb/s je frekvence 400 kHz. Signál má střídu 50 %. K jeho generování slouží hardwarová periferie mikrokontroléru – modul časovače v konfiguraci PWM s pevnou periodou a střídou. Jeho frekvence je odvozena z časování hlavní sběrnice mikrokontroléru. 2.5. Mikrokontrolér Nejprve byl zvolen mikrokontrolér Freescale MC9S12XE100 z rodiny šestnáctibitových mikroprocesorů HCS12, pro tuto platformu byla v rámci práce navržena a realizována deska tištěných spojů s předpokladem přímého propojení s modulem GPS a obvody pro řízení ARINC 429. Mikroprocesor však výkonostně nevyhověl úpravě požadavků z pohledu rychlosti zpracování. Byl tedy zvolen vhodnější mikrokontrolér a zdrojový kód byl částečně přenesen. 38

GNSS senzor pro ARINC 429

Nový mikrokontrolér byl zvolen s ohledem na vhodnou instrukční sadu, vhodný výpočetní výkon a dostupnost. Mikrokontrolér disponuje výpočty v pohyblivé řádové čárce na úrovni instrukcí, v rámci rodiny (STM32) jsou vyráběny mikrokontroléry různých rychlostí, s časováním hlavní sběrnice 24 MHz, 72 MHz a 100 MHz, mikrokontroléry mají různé velikosti obou typů pamětí – programové a operační. Pro odladění základního algoritmu byl použit mikrokontrolér STM32F100RB, ve finální aplikaci bude použit jeho rychlejší derivát v závislosti na požadované rychlosti výpočtů. Aplikace využívá periferie jednoho časovače pro interní a ladicí účely, druhého časovače pro generování hodin sběrnice ARINC 429 a dvou hardwarových UART kanálů – jednoho pro komunikaci s GNSS modulem a jednoho pro případnou komunikaci s nadřazeným systémem, např. osobním počítačem zejména pro účely lazení. Po připojení napájecího napětí zařízení je provedena inicializace integrovaných hardwarových periferií mikrokontroléru, jsou inicializovány připojené obvody Holt jako rozhraní sběrnice ARINC 429 a je nastaven GNSS modul. Toto nastavení spočívá v určení komunikační rychlosti pro používanou sběrnici UART, dále je nastavena periodicita a frekvence odesílání zvolených zpráv z GNSS senzoru a je nakonfigurován časový puls, který senzor generuje. Inicializace trvá zhruba jednu sekundu a to z důvodu čekání na provedení vnitřního spouštěcího programu GNSS senzoru s dostatečnou časovou rezervou. Po inicializaci je spuštěna hlavní programová smyčka, která je prováděna neustále do odpojení napájecího napětí.

2.6. Programové vybavení

Hlavní část programu je koncipována jako nekonečná smyčka. V této smyčce, znázorněné na obrázku 2.5, se neustále zjišťuje, zda byla přijata zpráva z GNSS přijímacího modulu a pokud ano, jsou přijatá data zkontrolována a je provedeno jejich zpracování ve smyslu uložení přijaté informace zkopírováním do určených datových struktur. Informace je reprezentována číselnými údaji jako hodnotami naměřených veličin. Mezi ukládané veličiny patří např. zeměpisná délka a šířka, rychlost pohybu zařízení, její jednotlivé složky, aktuální datum, čas a mnoho dalších. 39

GNSS senzor pro ARINC 429

 





 















 

 

 
 






 # " 


   # 



   



!    

"   

Obrázek 2.5 - Algoritmus hlavní programové smyčky.

Většina zpráv z GNSS senzoru je posílána periodicky každých 200 ms. Toto je nastaveno v bloku inicializace prostřednictvím protokolu UBX a není možné nastavit periodu pro všechny zprávy protokolu, výjimkou z požadovaných zpráv naší aplikace jsou zprávy pro stahování efemeridů ze senzoru, o které je nebytné žádat v každé periodě. Paralelně s procesy příjmu a zpracování zmíněných zpráv přichází ze senzoru periodicky časový impuls. Jeho perioda je 1000 ms, tedy pětkrát vyšší než perioda odesílání automatických zpráv. Po detekci příchodu náběžné hrany impulsu ze senzoru v mikrokontroléru jsou z informací z datových struktur vypočtena slova aplikační vrstvy protokolu sběrnice ARINC 429. Po jejich úspěšném sestavení jsou následně odeslána na sběrnici ARINC 429. Následuje vyslání požadavku na odeslání nových efemeridů ze senzoru. Jedná se o jakousi asynchronní dávku, která je zpracována mezi příjmem pravidelných zpráv. Efemeridy jsou senzorem odeslány 40

GNSS senzor pro ARINC 429

v další periodě. Sestavení odesílaných slov aplikační vrstvy protokolu sběrnice ARINC 429 je z velké části poměrně snadné. Zpravidla se jedná o převod jednotek odesílané fyzikální veličiny následovaný sestavením konkrétních slov. Převod jednotek spočívá ve vynásobení velikosti změřené veličiny konstantou. Od tohoto schématu se poněkud liší pouze výpočet poloh družic z efemeridů. Celý tento postup je popsán v dokumentu[6] specifikace rozhraní GPS a implementovaný algoritmus je matematicky i slovně popsán v úvodní části této práce. Implementace algoritmu výpočtu poloh družic v souřadné soustavě ECEF[7] (Earth-Centered and Earth-Fixed) je snadná, nicméně časová výpočetní náročnost je příliš velká z důvodu výpočtu řady goniometrických funkcí.

Obrázek 2.6 - Příjem zpráv z GPS. Vedlejší task (zde obsluha přerušení) řeší příjem zpráv z GNSS senzoru a je znázorněn na obrázku 2.6. Algoritmus příjmu zpráv je řešen jako stavový automat, 41

GNSS senzor pro ARINC 429

který přímo analyzuje nejnižší vrstvu komunikačního protokolu (NMEA a UBX) a do připravených datových polí ukládá jednotlivé části přijímané zprávy. Procedura příjmu zpráv je volána pro každý přijímaný znak, se kterým dále nakládá podle nastavených pravidel. Po indikaci přijetí znaku do bufferu hardwarové periferie sériového komunikačního kanálu je zjištěno, zda je možné přijatý znak zkopírovat a přepsat tak dříve přijatá data (předchozí zpráva). To je možné pouze tehdy, byla-li již dříve přijatá zpráva zpracována. V opačném případě nastane ztráta celé nově přijímané zprávy. V tomto ohledu musí být zařízení vhodně dimenzované. Jelikož mohou být po sériové sběrnici přenášeny dva typy zpráv (z pohledu použitého protokolu), musí algoritmus příjmu tyto zprávy od sebe vzájemně rozlišit. Jedná se o zprávy protokolu NMEA 0183[11] a ubx[12]. Tyto dva typy zpráv je možné rozlišit již přijetím prvního znaku. Dále jsou načtena zbývající datová pole přijímané zprávy a zároveň je počítán kontrolní součet (ve skutečnosti se nejedná o součet), který je po přijetí celé zprávy porovnán se součtem přeneseným na konci obou typů zpráv. Na základě výsledku porovnání je rozhodnuto, zda bude zpráva označena za přijatou, či zda bude zahozena a programem ignorována. 2.7. Ověření funkce Základní ověření funkce celého zařízení spočívá v kontrole z pohledu vstupu a výstupu. Pro nezbytnou kontrolu sestavení slov sběrnice ARINC 429 je dočasně odpojen senzor GNSS a pro ověření je nahrazen zdrojem referenčních dat se známým předpokládaným výstupem ze systému. Zdroj referenčních vstupních dat je, již dříve pořízený, záznam výstupu z GNSS senzoru. Na výstupu je nejprve pomocí osciloskopu ověřena fyzická vrstva protokolu sběrnice ARINC 429 (viz obrázek 2.7), tedy napěťové úrovně a délky náběžných hran. Dále je ověřena perioda odesílaných datových bloků a zkontrolována její odchylka od mezních hodnot. Následně kontrolujeme obsah jednotlivých slov, tedy správnost pořadí přenášených bitů v labelu a v datových polích. Prostřednictvím profesionálního převodníku pro osobní počítač s USB na sběrnici ARINC 429 je zkontrolován obsah jednotlivých slov a porovnán s referenčním (očekávaným) výstupem. Dále byla ověřena funkce správnosti příjmu dat z GNSS senzoru pomocí zkopírování vnitřních datových struktur (naplněných daty z GNSS senzoru) na komu42

GNSS senzor pro ARINC 429

nikační sběrnici s osobním počítačem. Zde došlo k „ručnímu porovnání informace z GNSS senzoru a zpracované informace z mikrokontroléru. Pro referenční přepočet odeslaných slov sběrnice ARINC 429 byl sestaven jednoduchý program pro osobní počítač. Správnost výpočtu poloh družic byla ověřena na základě referenčních „přesných výpočtů[33], ostatní veličiny byly porovnány s přijatými z GNSS senzoru a pro případ přijaté polohy přijímače byla provedena další kontrola prostřednictvím internetových map[35][36].

Obrázek 2.7 - Slovo sběrnice ARINC 429. Pro paralelní odzkoušení funkce celého zařízení byl použit komerční převodník A429USB[15] fy techSat, jenž nabízí aplikační rozhraní s možností jeho využití ve vlastní softwarové aplikaci pro zpracování přijatých slov včetně časových značek. Na obrázku 2.8 je blokově znázorněno zapojení pro kontrolu funkce zařízení. Program využívající aplikační rozhraní ovladače převodníku byl napsán vedoucím diplomové práce. Program ukládá a převádí přijatá slova do záznamových textových souborů. Program obsahuje chybu ve smyslu chybného zaokrouhlování při dekódování přijatých slov, nicméně v pořádku zaznamenává přijatá slova a časové značky. Je možné znovu ověřit skutečně přijaté datové pakety a porovnat se slovy odeslanými na sériové rozhraní osobního počítače. Další informací jsou časové značky přijímaných slov, tedy informace o čase příchodu slova s rozlišením jedné milisekundy. Pro změření periody odesílání zpráv byl opět sestaven jednoduchý program, který na základě pořízených naměřených dat určí a zobrazí časový interval 43

GNSS senzor pro ARINC 429

mezi dvěma po sobě přijatými slovy. Této funkce bylo využito pro kontrolu přesnosti dodržení periody vysílání. Výsledky jsou přiloženy na doprovodném datovém nosiči. Všechny parametry splnily očekávání, vypočtená slova byla zkontrolována a odpovídala skutečně naměřeným hodnotám z GPS. Schéma použitého měřicího pracoviště je na obrázku 2.8.

Obrázek 2.8 - Měřicí sestava pro ověření funkce. Pro ověření vypočtených poloh družic v souřadné soustavě ECEF bylo využito jejich přesných poloh[33] ve formátu SP3a[34]. Přesné polohy družic jsou distribuovány ve dvou verzích, první přichází s 13hodinovým zpožděním a druhá, přesnější, s několikadenním zpožděním. Tento formát obsahuje polohy všech třiceti dvou družic po celou denní dobu ve čtvrthodinových intervalech, udávaných v čase GPS. Čas je určován jako prostá inkrementace sekund k aktuálnímu času od doby spuštění systému GPS. Od času UTC se dnes (doba publikování diplomové práce) liší o 15 sekund, rozdíl je způsoben počtem přestupných sekund od doby spuštění systému GPS. Polohy spočtené v mikrokontroléru ARM Cortex-M3 se nepatrně lišily (řád centimetrů) od stejného algoritmu spuštěného na 64bitové platformě založené na procesoru 8086. Tato chyba může být způsobená implementací goniometrických funkcí, které jsou na osobním počítači řešeny v rámci instrukční sady a na embedded platformě jsou implementovány softwarově v matematické knihovně jazyka C. Od referenčních hodnot se výsledek algoritmu lišil zpravidla v řádu desítek cen44

GNSS senzor pro ARINC 429

trimetrů, v několika případech až v řádu metrů. Dosažená chyba je zadavatelem akceptovatelná a odpovídá požadavkům. 2.8. Technické parametry Zařízení bylo navrhováno s ohledem na možnost připojení do stejné napájecí větve jako spolupracující gyroskop, bylo tedy počítáno s napájecím napětím v rozsahu nejméně 18 – 28 V. V tomto ohledu byl pro upravení napájecích napětí zvolen spínaný zdroj s rozsahem vstupních napětí pro naši aplikaci 15 – 40 V. Zařízení disponuje vstupním konektorem SMA-R pro připojení pasivní antény nebo antény aktivní určené pro napájecí napětí 3,3 V, výstupní datovou sběrnicí ARINC 429 a dvěma vodiči se signálem pro časové značky. Zařízení bylo navrženo dle požadavků, příslušná elektrická schémata se nacházejí v příloze práce, a stejně jako zdrojový kód navrženého a realizovaného programu, jsou přiloženy na datovém nosiči. Zařízení bylo pro odzkoušení realizováno na nepájivém kontaktním poli společně s vývojovým kitem mikrokontroléru.

45

GNSS senzor pro ARINC 429

46

3. Simulátor displeje V této části práce je představen systém – simulátor vestavného zařízení s barevným grafickým displejem (v práci také označován jako simulátor displeje) – jehož modifikace byla součástí zadání diplomové práce. V následujícím odstavci se nacházejí obecné informace o systému, dále jsou v krátkosti uvedeny provedené úpravy a naznačen jejich význam pro stávající systém simulátoru displeje. 3.1. Popis systému V magisterské etapě studia na Českém vysokém učení technickém v Praze, fakultě elektrotechnické je pro předmět Palubní informační a řídicí systémy vyvíjena platforma pro zobrazování číslicových palubních přístrojů malých letadel. Jedná se o soustavu aplikací tvořenou letovým simulátorem Flight Gear [4] produkujícím údaje o prováděném letu; tyto informace jsou sbírány softwarovým převodníkem a dále ve formátu aplikační vrstvy protokolu CANAerospace[5] odesílány v datagramech UDP do jedné či více koncových aplikací. Tento systém je blokově vyobrazen na obrázku 3.2. V obrázku se navíc nachází pohyblivý letadlový simulátor, který je využíván v jiném projektu, zde je pouze pro ilustraci a naznačen jako variantní použití. Koncová aplikace je software určený pro osobní počítač s operačním systémem Microsoft Windows. Tato aplikace navenek vypadá jako grafický displej; jedná se tedy o zobrazovací plochu rozměru reálného displeje, na kterou je vykreslován letadlový palubní přístroj. Jádrem aplikace je přenositelný kód implementující samotný letadlový přístroj. Mezi přístrojem a displejem je, stejně jako mezi přístrojem a komunikační sběrnicí, jednotné rozhraní (HAL – hardware abstract layer). V rámci zmíněného vyučovaného předmětu byla studenty vytvořena celá řada palubních přístrojů, od klasických elementárních ručičkových indikátorů až po větší integrované číslicové přístroje, jako např. umělý horizont kombinovaný s výškoměrem, variometrem, ukazatelem magnetického kurzu a dalších veličin. Jeho podoba je na obrázku 3.4. Samotný simulátor grafického displeje je tvořen několika logickými programovými celky. Základem aplikace je hlavní programové okno, blok VirtualLCD. Po spuštění tento blok inicializuje veškeré své součásti, nastaví všechny moduly a spustí časovače pro pravidelné překreslování obrazovky displeje. Displej je implementován 47

Simulátor displeje

jako grafický komponent VirtualScr, vkládaný do hlavního okna. Tento modul obsahuje ve svém jádře implementaci několika grafických rozhraní, z nichž je pouze jediné součástí přeloženého programu – o které z nich se jedná volíme konstantou při překladu. Uživatelsky programovatelnou součástí je modul aplikace Gauge, tento modul obsahuje logiku vlastního přístroje. Přijímá informace z letového simulátoru a tvoří grafický design vykreslovaného přístroje. Na displej aplikace Gauge vykresluje, a s modulem VirtualScr komunikuje, prostřednictvím grafické knihovny GrLib. Jedná se o soubor funkcí napomáhajících vykreslování geometrických útvarů, mezi které patří např. kružnice, kruhy, jejich výseče či úsečky nebo textové informace v několika fontech. Spojení všech bloků systému je znázorněno na obrázku 3.1.

Obrázek 3.1 - Blokové schéma simulátoru displeje. Podle materiálů k předmětu Přístrojové systémy letadel. Simulátor displeje není využíván pouze v rámci předmětu Přístrojové systémy letadel. Aktuálně je zvažována možnost nasazení displeje na systém simulátoru letadla s pohyblivou základnou. Jedná se o právě řešený projekt Českého vysokého učení technického v Praze, fakulty elektrotechnické ve spolupráci s průmyslem. Ve vztahu ke zmíněnému simulátoru displeje je v projektu řešen nový přístroj pro zvýšení bezpečnosti posádky letadla. Simulátor displeje by mohl být v celém systému použit pro zobrazování letadlových přístrojů a případně i pro zmíněný, v rámci projektu vznikající, přístroj. 48

Simulátor displeje

     



   


 

   




Obrázek 3.2 - Zařízení fy Pragolet a simulátor displeje. Na základě materiálů k předmětu Přístrojové systémy letadel. Tomáš Levora, Martin Šipoš. 3.2. Grafické rozhraní Hlavním úkolem práce na tomto systému byla úprava jeho zobrazovací části. Simulátor byl naprogramován pro běh na operačním systému s knihovnou MFC[18]. Pro vykreslování plochy displeje bylo použito přímo rozhraní operačního systému – plátno (canvas), pomocí něhož aplikace prováděla vykreslování přímo na device context[2]. Tento přístup ke grafickému rozhraní se zdál být příliš pomalý, proto vznikl požadavek implementovat rychlejší rozhraní. Základem vykreslovací části simulátoru je grafická knihovna, jež implementuje vykreslování jednoduchých geometrických útvarů a několika fontů. Důvod použití knihovny je jednotnost výstupů nezávislá na použité platformě. Vstupem grafické knihovny jsou parametry geometrických útvarů a výstupem grafické knihovny je množina elementárních pixelů. Vhodnější grafická rozhraní jsou ta, která přistupují přímo do videopaměti grafické karty. Mezi tato rozhraní patří známé OpenGL[20] a Direct3D[21], obě je možné implementovat do stávající aplikace. Obě rozhraní nabízí mnohem větší možnosti, než které potřebujeme využít; výhoda těchto rozhraní je především v hardwarovém výpočtu (parametrizaci, vyhlazování, . . .) a to zejména pro prostorové (trojrozměrné) scény. Aplikace je nyní koncipována tak, aby si mohl uživatel snadno zvolit, s jakým grafickým rozhraním program přeloží. Rozhraní OpenGL poskytuje svému uživateli velké množství funkcí, především 49

Simulátor displeje

pro vykreslování trojrozměrných objektů. Výhoda použití pro naši aplikaci spočívá v hardwarové podpoře OpenGL enginu a hlavně v přímém přístupu do videopaměti. Vykreslování prostorových těles, jejich stínování nebo vyhlazování vykreslované scény je pro naši aplikaci docela nepodstatné. Dokonce nevyužijeme ani funkcí pro vykreslování dvourozměrných geometrických útvarů. Důvodem je použití vlastní grafické knihovny, která zajišťuje stejný vzhled vykreslovaných scén na všech platformách. Možností vykreslování grafické informace na displej za užití OpenGL je několik. První nápad je jednorázovým voláním vykreslit požadovaný pixel do videopaměti. Vzhledem k faktu, že při každém překreslování scény není potřeba vykreslovat celou zobrazovanou plochu, ale pouze malou část displeje (záleží na programátorovi přístroje), se tento přístup jeví jako poměrně vhodný. Při použití dvou přepínaných bufferů (viz dále) je však již nepoužitelný. Vykreslením bufferu na obrazovku je v tomto případě všechna informace ztracena a při dalším překreslení by se totéž opakovalo s daty o vzorek staršími. Jako vhodné řešení problému se potom zdá být použití vlastního bufferu, který je v periodických úlohách celý zkopírován do videopaměti. Kopírování probíhá za pomoci funkce grafického enginu OpenGL, je tedy možné jeho optimalizace na hardware. Tento přístup byl použit i v naší aplikaci simulátoru vestavného zařízení s grafickým displejem. Pro buffer je nezbytné rezervovat paměťové místo velikosti s vykreslované plochy pro každou barevnou složku, tedy s = k · x · y,

(3.1)

kde x je velikost horizontální strany displeje v pixelech, y je velikost vertikální strany displeje, též v pixelech a k je počet barevných složek. V našem případě je k = 3 pro červenou, zelenou a modrou barevnou složku. Zarovnání položek bufferu na 32bitová slova není použito. Zarovnání by se mohlo projevit vyšší rychlostí přístupu do paměti, potřebné množství paměti by však vzrostlo o jednu třetinu. Dva buffery (double-buffering) se v grafických aplikacích používají pro eliminaci „blikání obrazovky během překreslování. Jeden buffer je vždy zobrazován na plochu obrazovky, zatímco druhý je „skryt a slouží pro zapisování. Po provedení úprav jsou buffery přepnuty (swap). Zobrazované údaje jsou potom plynulé a nejsou 50

Simulátor displeje

rušeny překreslováním konečnou rychlostí. Direct2D jsme v aplikaci neimplementovali z důvodu jeho podpory až ve vyšších verzích operačního systému Windows, pro který je simulátor vestavného zařízení určen. Implementovali jsme však rozhraní Direct3D, též z balíku DirectX. Pro případ implementace Direct3D byl zvolen stejný pohled jako pro případ OpenGL. Byl tedy vytvořen buffer, který je periodicky zkopírován do videopaměti a tím zobrazen na displeji. Aby bylo možné provést srovnání nejenom implementovaných změn, ale také srovnání s jinými platformami, byly naprogramovány i další aplikace, všechny založené na grafické knihovně. Programy byly vytvořeny na základě volně dostupných knihoven, především multiplatformních. Mezi použité knihovny patří SDL[19], GLut[22] a Qt[23]. Pokud se jedná o multiplatformní knihovnu, bylo provedeno měření na dvou různých platformách, zastoupených vždy jedním operačním systémem. Platforma

Operační systém

FPS (Hz)

Canvas Win32

Windows XP 32bit

1

OpenGL

Windows XP 32bit

21

Direct3D SDL

Windows XP 32bit Linux 2.6 64bit

14 43

SDL GLut

Windows XP 32bit Linux 2.6 64bit

8 46

GLut Qt

Windows XP 32bit Linux 2.6 64bit

39 28

Qt

Windows XP 32bit

16

Tabulka 3.1 - Porovnání rychlosti překreslování. V tabulce 3.1 jsou porovnány jednotlivé zobrazovací platformy a jejich rychlost za stejných podmínek. Všechny položky jsem implementoval v rámci diplomové práce pro srovnání jejich rychlostí s naším simulátorem. Měření rychlosti překreslování bylo provedeno jako měření počtu překreslení grafické scény v době třiceti sekund. Objektově orientované platformy (Qt a naše platforma na prvních třech řádcích tabulky 3.1) měly nastavený časovač s 10milisekundovou periodou a v přerušení bylo voláno vykreslování. Procedurální aplikace (SDL a GLut) v nekonečné 51

Simulátor displeje

smyčce vykreslovaly scénu s naprogramovaným horním omezením rychlosti překreslování na 50 Hz. Scéna měla rozměr 640 × 480 pixelů, překreslena byla postupně po jednotlivých pixelech. Námi změřená frekvence překreslování je potom vždy maximálně dosažitelná v aplikaci displeje. Velké množství přístrojů využívá pro zobrazení překreslování celé obrazovky. Kromě vykreslení samotného je v displeji prováděn výpočet zobrazované scény. Pouze v případě ručičkových přístrojů je možné dosáhnout rychlejšího vykreslování. Z tabulky jsou zřejmé relativně podstatné rozdíly v rychlostech překreslování. Rozdíly vychází především z faktu, že zmíněné programy můžeme zařadit vždy do dvou kategorií z několika pohledů. Zcela zásadní vliv na dobu vykreslování má struktura kódu, jsou zde totiž jak objektové, tak procedurální programy. U programů procedurálních je rychlost vykreslování vyšší a je dána tím, že si frekvenci překreslování řídíme sami přímo v kódu tím, že se na určitou dobu vzdáme procesoru ve prospěch jiného procesu. Program potom stále aktivně čeká na daný okamžik dalšího překreslení scény. U objektově orientovaných kódů je vykreslování řízeno pomocí časovače, jenž využívá fronty zpráv operačního systému. Ve frontě zpráv se vyskytují nejen informace o uplynutí stanovené doby, ale také velké množství jiných zpráv. To způsobuje další případné zpoždění doručení požadované zprávy, v případě velkého množství zpráv ve frontě není vůbec zaručeno jejich doručení. Dále je možno vidět závislost rychlosti na použitém operačním systému. 3.3. Podpora souborového systému Některé aplikace běžící na našem systému pracují s poměrně krátkou periodou a s relativně velkým množstvím datových informací uložených v souborovém systému na pevném disku. Častý přístup k tomuto pomalému paměťovému médiu má za následek velké zpoždění celého výpočetního cyklu programu, tento fakt je nezbytné respektovat při tvorbě aplikačního rozhraní a vhodně optimalizovat. Dále je možné celý proces urychlit zkopírováním dat z pomalého paměťového média do rychlejšího úložiště, jakým je např. paměť RAM. To je důvod pro provedení implementace rozhraní k souborovému systému a v simulátoru zvolit úložiště v operační paměti. Aby byl přístup k souborům stále univerzální, byl do simulátoru implementován virtuální souborový systém s aplikačním rozhraním velmi podobným rozhraní 52

Simulátor displeje

programovacího jazyka C. Jak již bylo uvedeno výše, výhodou tohoto řešení je zkrácení přístupové doby k uloženým souborům. Další výhoda spočívá v univerzálnosti řešení a možnosti implementace i na různé embedded platformy. Tato výhoda vychází z přenositelnosti kódu. Pro uchovávání dat v souborovém systému byla zvolena volně šiřitelná knihovna FatFS[25], která implementuje množinu souborových systémů FAT[24]. Tato knihovna obsahuje implementaci samotného souborového systému a na uživateli zanechává programování nejnižší (fyzické) vrstvy. V našem případě je fyzickou vrstvou přístup do operační paměti, na jiném systému může zajišťovat např. přístup k SD nebo CF kartě. Tato knihovna byla zvolena na základě doporučení vedoucího práce, pro použití v simulátoru displeje je její použití velmi vhodné. Pro nasazení ve flash paměti však existují vhodnější souborové systémy s rovnoměrným rozložením počtu zápisů v celém paměťovém rozsahu, v praxi se nicméně z důvodu kompatibility s používanými operačními systémy pro osobní počítače používá též souborového systému FAT. 192.168.1.1 <SendPort>10999 11000 104857600 <ParentPath>Z:\SRTM 53

Simulátor displeje

<MemorySize>104857600 Ukázka 3.2 - Ukázka nastavení aplikace. Upraveno podle materiálů k předmětu Přístrojové systémy letadel. Do simulátoru je knihovna zakomponována v části inicializace a ukončení. Po startu programu dojde k načtení souborů a adresářů definovaných v konfiguračním souboru z reálného souborového systému do nově vytvořeného virtuálního souborového systému. V tomto ohledu byl rozšířen konfigurační XML soubor (ukázka a popis níže) simulátoru o několik vlastností. Jednou je velikost vytvářeného souborového systému a druhým parametrem je cesta k existujícímu adresáři ve VFS (Virtual File System) operačního systému, která je určena ke zkopírování do vytvořeného souborového systému. Nově přidané parametry musí být umístěny na konci konfiguračního souboru, příklad je uveden v ukázce 3.2. Konfigurační soubor sestává z několika nastavitelných položek. Nastavení aplikace je umístěno v hlavním tagu VirtualLCD. První položka IP obsahuje IP adresu, pomocí které se připojuje k Flight Gear Connectoru (program poskytující simulační data) a komunikuje na UDP portech SendPort a RecvPort. Další položky byly v rámci práce přidány spolu s nově implementovanými moduly. Jedná se o položky FileSystem a DynamicMemory. První z nich, FileSystem, má první celočíselnou vlastnost DiskSize nesoucí informaci o počtu bytů, které budou alokovány pro virtuální souborový systém v operační paměti. Položka ParentPath obsahuje cestu k adresáři v adresářové struktuře operačního systému. Tento adresář je celý po spuštění simulátoru zkopírován do paměti. Položka MemorySize má stejný význam jako DiskSize, zde se však jedná o velikost statického bloku pro dynamické přidělování paměti. 3.4. Správa paměti Veškerou, skutečně instalovanou, paměť systému označujeme pamětí fyzickou. 54

Simulátor displeje

Takovou paměť adresujeme lineárně a její počet buněk odpovídá skutečnému, hardwarovému, počtu. Virtuální paměť je abstrakce vytvořená operačním systémem; její velikost je zpravidla několikanásobně větší než je tomu u skutečné, fyzické, paměti. Spojitý blok virtuální paměti nemusí být nezbytně spojitě umístěn i v paměti fyzické. Virtuální paměť zjednodušuje správu paměti na systémech s více procesy. Na platformách bez operačních systémů nebývá implementace virtuální paměti k dispozici. Způsoby přidělování (alokace) paměti procesu operačním systémem dělíme na dva typy, na statickou a dynamickou alokaci paměti. Statická alokace paměti probíhá při zavádění procesu, zatímco dynamická alokace kdykoliv za jeho běhu. Použitím dynamické alokace paměti můžeme zvýšit efektivitu využívání paměti v čase, nemusíme potom vždy alokovat limitní množství pro daný algoritmus, ale alokujeme přesné množsví až v okamžiku potřeby.

Obrázek 3.3 - Dynamická alokace paměti. Princip vlastního algoritmu alokace paměťového bloku, jenž jsme implementovali, je znázorněn na obrázku 3.3. Dynamické přidělování paměti probíhá nad staticky alokovaným blokem. Tento blok obsahuje jednoduchou hlavičku s informací o své délce a příznakem, zda je obsazený či nikoliv. Požadavek na přidělení 55

Simulátor displeje

volné paměti projde všechny bloky (na počátku je blok jediný) a nalezne první dostatečně velký volný blok, z něhož část obsadí a ukazatel na jeho začátek předá žadateli. Z druhé části vytvoří další volný paměťový blok. Při uvolňování dynamicky alokované paměti dochází ke spojování všech sousedních volných bloků. Jedná se o vlastní variaci algoritmu pro dynamickou alokaci. 3.5. Ukázkové aplikace Tento odstavec vznikl, abychom demonstrovali funkčnost simulátoru a informovali o jeho možnostech. Aplikace zde popsané vznikly v rámci předmětu Přístrojové systémy letadel a byly vytvořeny studenty jako semestrální úkoly. Pravděpodobně nejvíce komplexním přístrojem je integrovaný systém pro zobrazování množství leteckých veličin postavený na umělém horizontu. Displej je vidět na obrázku 3.4.

Obrázek 3.4 - Přístroj s umělým horizontem. Studenti předmětu Přístrojové systémy letadel. Na pozadí je zobrazen standardní číslicový umělý horizont, v horní části displeje je zobrazen kurz letu z magnetického kompasu, podél levé strany displeje je vykreslen bargraf s barevným znázorněním několika pásem a zobrazovačem číselné hodnoty pravé vzdušné rychlosti v knotech. Podobný bargraf se nachází i na pravé straně a zobrazuje aktuální barometrickou výšku letu ve stopách. Napravo od tohoto bargrafu je zobrazen úzký růžový proužek, v saturaci doplněný o šipku, zobrazující hodnotu vertikální rychlosti ve stovkách stop za minutu. Pro lepší čitelnost polo56

Simulátor displeje

hových úhlů (podélný sklon a příčný náklon) je displej doplněn o stupnici. Celé zobrazení bylo vytvořeno na základě přístrojů fy Dynon Avionics[17]. Dalším z řady přístrojů je zobrazovač výškové pohyblivé mapy. Přístroj zobrazuje terén v blízkém okolí letadla, terén je rozdělen na několik výškových pásem vzhledem k výšce letu, jednotlivá pásma jsou znázorněna různými barvami – pro nižší výšky je terén zobrazen stupni zelené barvy, příliš nízký terén je černý a vyšší terén než výška letu je zobrazen stupni červené barvy. Ukázka přeletu v okolí nejvyššího vrcholu České republiky je na obrázku 3.5. 3.6. Posuvná mapa Po startu aplikace provede program inicializaci a vykreslí uvítací obrazovku. Další překreslování je voláno periodicky spouštěnou procedurou z hlavního modulu aplikace simulátoru. V každé periodě je nejprve zjištěno, zda došlo k přijetí simulačních dat a zda se přijatá data liší od dat předchozích. V takovém případě dojde k překreslení mapové scény. Hlavní informací vykreslenou na displeji je relativní výšková mapa, tedy barevné zobrazení jednotlivých výškových hladin vzhledem k aktuální výšce letadla. Druhým zdrojem informace je grafické zobrazení kurzu letu v přední části displeje. Poloha letadla v mapě je vyobrazena piktogramem letadla, která je také středem kružnice vykresleného kurzu. Kromě těchto informací jsou na displej vypsány údaje o absolutní poloze letadla z GPS, nadmořská výška a vykreslena ovládací tlačítka pro přizpůsobení zobrazení. Pro práci bylo využito volně dostupných dat z SRTM (Shuttle Radar Topography Mission[9]), na internetu je možné nalézt velké množství informací, pro vytvoření představy zde však přesto uvedeme alespoň několik základních údajů. Shuttle Radar Topography Mission byla jedenáctidenní mise raketoplánu Endeavour též známá pod označením STS-99. Mise byla podniknuta v průběhu měsíce února roku 2000 pod záštitou společností NGA a NASA. Úkolem této mise bylo změřit výšku terénu nad rotačním elipsoidem (WGS-84) na větší části obydleného zemského povrchu. Zpracovaná data provedených měření jsou k dispozici od konce roku 2009 na webových stránkách dds.cr.usgs.gov/srtm. Naměřená data jsou poskytována v několika variantách v závislosti na fázi jejich zpracování. Základní verzí 57

Simulátor displeje

jsou surová naměřená data, ta jsou k dispozici pod označením verze 1. Ve druhé fázi zpracování jsou mapy filtrované na výškové nespojitosti malých rozměrů způsobené chybně naměřenými vzorky. Dalším produktem jsou informace o poloze vodních hladin, které nejsou zakomponovány přímo ve výškových mapách, ale jsou uloženy samostatně ve zvláštních datových souborech.

Obrázek 3.5 - Přístroj posuvné mapy. Petr Gazdík, Tomáš Levora. Výšková naměřená data jsou ukládána do čtverců o velikosti strany jednoho úhlového stupně, který odpovídá zeměpisné délce a šířce. Distribuovaná data jsou ještě dělena v závislosti na velikosti jednotlivých vzorků, existují soubory s rozlišením jedné a tří úhlových sekund (zhruba 90 a 30 metrů), kolekce dat se označují jako SRTM s postfixem odpovídajícím rozlišení. Z uvedeného vyplývá rozměr čtverce 1201 nebo 3601 vzorků, které jsou uloženy sekvenčně po řádkách. Vždy krajní řádek a sloupec dat je duplicitní se sousedními čtverci. Data s jemnějším rozlišením jsou v současné době dostupná pouze pro oblast Severní Ameriky. Každý vzorek je 16bitový s rozlišením jednoho metru, vyjadřuje výšku nad rotačním elipsoidem WGS-84. Jedná se o celá čísla v rozsahu od -32768 do 32767 uložená v big endian, kódovaná ve dvojkovém doplňku. Pro ukládání informace o výškové mapě světa je nezbytné zvolit kompromis 58

Simulátor displeje

mezi výpočetní náročností, množstvím přístupů k hardware a velikostí použité paměti. Poznamenejme, že do paměti neukládáme načítanou výškovou mapu, nýbrž jen informaci o zobrazené barvě. Velikost mapy v paměti přesahuje velikost mapy zobrazené, uložená data jsou ve čtverci, jehož strana je rovna průměru kružnice opsané zobrazované části mapy. Přístup k hardwaru je časově poměrně náročný a jeho četnost byla omezena na otevření každého souboru pouze jednou a čtení informací postupně tak, jak je uložena v médiu (v souboru, nebereme v potaz fragmentaci dat). Data jsou čtena selektivně pomocí skoků. S ohledem na měřítko zobrazované mapy může být počet zároveň načítaných mapových podkladů nejvýše čtyři (případ výskytu letadla v okolí rohu čtverce). Pro aplikaci na osobním počítači byl vliv doby přístupu k médiu eliminován vytvořeným virtuálním souborovým systémem v operační paměti. Aby bylo zřejmé, jaké mapové podklady je potřebné načíst, musí být známa poloha letadla v rámci displeje, velikost displeje a měřítko mapy. Z relativní polohy letadla na displeji je určena zeměpisná poloha středu displeje. Podle této polohy, aktuálního kurzu letu, rozměrů displeje a měřítka vypočteme krajní místa, která budou na displej vykreslena. Na základě těchto informací načteme potřebné mapové podklady a uložíme je do paměti. Při ukládání mapy do bufferu je dále zohledněno měřítko zobrazení. Implementace neumožňuje zvětšovat měřítko, tedy oddalovat (zoom out) mapu. Maximální vzdálenost zobrazená na mapě je pro výšku displeje 640 pixelů zhruba 60 km. Nejmenší vzdálenost je omezená pouze rozlišením naměřených mapových podkladů (SRTM). Měřítko je možné měnit plynule nastavením proměnné v programu. Pro změnu měřítka jsme považovali naměřené vzorky za čtvercové, položili jsme tedy jeden úhlový stupeň zeměpisné délky roven jednomu úhlovému stupni zeměpisné šířky, vzniklá chyba je v daném měřítku nepatrná. Při zpracovávání mapových podkladů jsme se již nezabývali jejich filtrováním (odstraňováním chybějících míst, kterých je především v oblasti vysokých hor mnoho). Každý naměřený vzorek je na displeji reprezentován čtvercem, data nejsou z důvodu rychlosti vyhlazována. Pro čtvercové vzorky (elementy) větší jednoho pixelu je potřeba zpřesnit polohu letadla tak, aby byla vykreslena správně i v rámci elementárních vzorků. 59

Simulátor displeje

Po aplikování změny měřítka se zabýváme rotací mapového podkladu na základě aktuálního kurzu letadla. Pro rotaci mapy je nejprve nezbytné určit její střed, tedy průnik jejích diagonál. Jedná se o bod, podle kterého dojde k orotování zobrazovaných dat. Tento střed určíme na základě znalosti aktuální polohy piktogramu letadla na displeji



xs ys



    x sin ϕ = −d· , y cos ϕ

(3.2)

kde xs a ys jsou souřadnice středu mapy a x a y jsou souřadnice polohy piktogramu letadla v mapě. Úhel ϕ je úhel od severu ve směru hodinových ručiček a d je vzdálenost polohy piktogramu letadla od středu mapy. Následně provedeme rotaci pomocí goniometrických funkcí a jednotlivé pixely umístíme na své pozice 

xdisp ydisp



 =

cos θ sin θ

− sin θ cos θ

   x · , y

(3.3)

kde xdisp a ydisp jsou souřadnice bodu na displeji, x a y jsou souřadnice bodu v neorotovaném bufferu a θ je aktuální kurs letadla, tedy úhel ve směru hodinových ručiček, o který provádíme rotaci (také ve směru hodinových ručiček). Zobrazená mapa na displeji je doplněna o ovládací prvky a zobrazení varování EGPWS. Kromě mapy je volitelně zobrazen kurz letadla a údaje o jeho poloze. Ovládací prvky zajišťují přepínání mezi dvěma přednastavenými měřítky mapy a dvěma polohami letadla v rámci displeje. V případě, že se před letadlem vyskytuje terén s větší nadmořskou výškou než je výška letu, dojde k zobrazení varovné hlášky EGPWS ve spodní části displeje. Přístroj výškové mapy byl zpracován v rámci předmětu Přístrojové systémy letadel studenty Petrem Gazdíkem a Tomášem Levorou (autor této diplomové práce), použitý text byl součástí závěrečné zprávy, pro účel diplomové práce byl upraven. Dále vzniklo velké množství rozličných, zdánlivě jednodušších, přístrojů, jako např. ručičkové teploměry, tlakoměry, kombinované přístroje zobrazující stavové informace nebo třeba letové údaje jako variometr nebo kompas.

60

Závěr Diplomová práce je rozdělena do tří základních kapitol. V úvodní kapitole seznamuje autor čtenáře se základními pojmy a principy, které jsou využity v dalších kapitolách této práce a čtenáři umožňují získat přehled o řešené problematice. Je zde vysvětlena problematika použitého zpracování signálů z družicových systémů určování polohy, jsou představeny použité komunikační protokoly a nachází se zde obecné informace o grafických platformách. Dále je zde věnováno několik slov verzovacím systémům, ze kterých byl zvolen a otestován systém pro budoucí šíření softwarové aplikace a její dokumentace. Část kapitoly je věnována programátorským dokumentačním systémům. Další dvě kapitoly se zabývají popisem praktické části diplomové práce, a to postupně návrhem elektronického zařízení pro měření polohových údajů s výstupem v souladu se specifikací ARINC 743 a úpravou stávajícího softwarového simulátoru vestavných zařízení s grafickým displejem. V rámci této diplomové práce byl navržen přijímač signálu GNSS s požadovaným výstupem podle specifikace ARINC 743, jehož funkce byla ověřena jednak porovnáním vypočtených poloh družic se světovou referencí a pro případ přímého výstupu byl pro ověření použit profesionální převodník ARINC 429 – USB. S použitím moderního mikrokontroléru ARM, rodiny Cortex-M3, bylo dosaženo doby výpočtu polohy jedné družice v rozsahu 6,5 ms až 7,2 ms. Další přidaná zpoždění souvisí s přenosem dat z GNSS do mikrokontroléru (230 ms) a se sestavením slov ARINC 429 včetně doby jejich odeslání (53 ms). Uvedené časy souvisí s počtem přijímaných družic a odpovídají počtu devíti satelitů se všemi informaci (celkem 15 viditelných). Celkové zpoždění tedy dosahovalo zhruba 350 ms. Dále byla upravena aplikace simulátoru vestavného zařízení. Aplikace byla doplněna požadovanou dokumentací, virtuálním souborovým systémem a dynamickou alokací paměti. Implementované moduly byly ověřeny v aplikaci posuvné mapy a umělého horizontu, rychlost vykreslování byla pro maximální zatížení oproti dřívějšímu řešení zvýšena šestnáctkrát. Grafický displej s aplikací umělého horizontu byl dále testován v součinnosti s připojeným laserovým gyroskopem Honeywell LaseRef V a MEMS IMU jednotkou iNemo[14] fy ST Microelectronics.

61

62

Obsah CD Adresář se simulátorem vestavného zařízení s displejem – simulator Display Upravovaný simulátor, popis v materiálech předmětu PRS grLib/doxy/doc.pdf Dokumentace ke grafické knihovně simulátoru fastlcd Pokusný základ grafické aplikace v SDL glulcd Pokusný základ grafické aplikace v GLut lcd Pokusný základ grafické aplikace v Qt Adresář se zdrojovými kódy gnss sensoru – gnss sensor Program pro zobrazení přijatých slov ARINC arinc check Elektrické schéma zařízení device schema Návrh DPS pro MCU Freescale HCS12 freescale pcb gps pcb Návrh DPS pro GPS modul Program pro zobrazení period zpráv ARINC interval check Programové vybavení MCU mcu program

63

64

Příloha A Název labelu Measurement Status Pseudo Range Pseudo Range Fine Range Rate SV Position X SV Position X Fine SV Position Y SV Position Y Fine SV Position Z SV Position Z Fine UTC Measurement Time Altitude HDOP VDOP True Track Angle Position Latitude Position Longitude Ground Speed Position Latitude Fine Position Longitude Fine Horizontal Integrity Limit Vertical Integrity Limit Vertical FOM UTC Fine UTC Vertical Velocity North/South Velocity East/West Velocity Horizontal FOM Date GPS Sensor Status

Label 060 061 062 063 065 066 070 071 072 073 074 076 101 102 103 110 111 112 120 121 130 133 136 140 150 165 166 174 247 260 273

Jednotka – m m m/s m m m m m m s ft – – ◦ ◦ ◦

kt ◦ ◦

nm ft ft s – ft/min kt kt nm – –

Tabulka 0.1 - Veličiny podle ARINC 743. Podle[1]

65

Perioda (ms) 990–1010 990–1010 990–1010 990–1010 990–1010 990–1010 990–1010 990–1010 990–1010 990–1010 990–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010 90–1010

66

Příloha B

Elektrické schéma GNSS senzoru podle ARINC 743 – mikrokontrolér

67

Elektrické schéma GNSS senzoru podle ARINC 743 – rozhraní ARINC 429

68

Elektrické schéma GNSS senzoru podle ARINC 743 – GPS přijímač

69

Elektrické schéma GNSS senzoru podle ARINC 743 – napájecí zdroje

70

Použitá literatura [1] ARINC Characteristic 743A GNSS Sensor., Specifikace ARINC 743, k zakoupení na http://www.arinc.com [2] MSDN., Microsoft Development Network http://msdn.microsoft.com [3] Levora, Tomas. Převodník Ethernet – ARINC 429. Praha, 2009. Bakalářská práce. ČVUT. volně dostupná verze na http://measure.feld.cvut.cz/zaverecne prace [4] Flight Gear. Oficiální webová prezentace projektu Flight Gear, http://www.flightgear.org [5] CAN Aerospace. Informace o protokolu CAN Aerospace, http://www.canaerospace.net [6] Interface Specification GPS 200D. www.gps.gov/technical/icwg/IS-GPS-200D.pdf [7] Souřadná soustava ECEF. http://en.wikipedia.org/wiki/ECEF [8] Soustavy NED, ECEF . Grafické znázornění závislosti http://en.wikipedia.org/wiki/North East Down [9] Shuttle Radar Topography Mission. Oficiální informace o misi SRTM, http://www2.jpl.nasa.gov/srtm [10] u-blox AG. Oficiální webová prezentace společnosti u-blox AG, http://www.ublox.com [11] Protokol NMEA 0183. http://www.nmea.org [12] Protokol UBX. http://www.u-blox.com [13] GPS Align in Motion of Civilian Strapdown INS . Honeywell Aerospace, http://www51.honeywell.com/aero/common/documents/ White Paper Align in Motion.pdf [14] ST iNemo. Inerciální jednotka iNemo, http://www.st.com/internet/evalboard/product/250367.jsp [15] techSAT ARINC429USB. Převodník ARINC 429 – USB, http://www.techsat.com/products/databus-products/arinc-429/ a429-usb.html [16] Holt. Oficiální webová prezentace společnosti Holt, http://www.holtic.com [17] Dynon Avionics. Oficiální webová prezentace společnosti Dynon Avionics, http://www.dynonavionics.com [18] Microsoft Foundation Class Library. Aplikační rozhraní operačních systémů Windows, http://msdn.microsoft.com/en-us/library/d06h2x6e.aspx [19] Simple DirectMedia Layer. Multiplatformní multimediální knihovna, http://www.libsdl.org [20] OpenGL. Grafické multiplatformní rozhraní, 71

http://www.opengl.org [21] DirectX. Multimediální rozhraní pro operační systémy Windows, http://www.microsoft.com [22] GLut. Grafické uživatelské rozhraní pro OpenGL, http://www.opengl.org/resources/libraries/glut [23] Qt. Multiplatformní aplikační rozhraní, http://qt.nokia.com [24] FAT. Dokumentace souborového systému FAT, http://msdn.microsoft.com/cs-cz/windows/hardware/gg463084 [25] FatFs. Volně šiřitelná knihovna implementující FAT, http://elm-chan.org/fsw/ff/00index e.html [26] Doxygen. Dokumentační systém pro C++, C, Java, Python, Fortran, VHDL, PHP, C#, . . ., http://www.stack.nl/∼dimitri/doxygen [27] DocBook. Dokumentační systém DocBook, http://www.docbook.org [28] DocBy.TEX Dokumentační systém DocBy.TEX, http://www.olsak.net/docbytex.html [29] Git. Verzovací systém Git, http://git-scm.com [30] Mercurial. Verzovací systém Mercurial, http://mercurial.selenic.com [31] CVS. Verzovací systém CVS, http://www.cvshome.org [32] Apache Subversion. Verzovací systém Subversion, http://subversion.apache.org [33] National Geodetic Survey. Referenční polohy družic GPS, http://www.ngs.noaa.gov/orbits [34] Popis formátu SP3a. http://www.ngs.noaa.gov/orbits/sp3 docu.txt [35] Google Maps. Mapové podklady Google, http://maps.google.com [36] Seznam mapy. Mapové podklady seznam.cz, http://www.mapy.cz

72

Seznam rovnic Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice Rovnice

1.1: Rozdílový – dopplerovský – kmitočet . . . . . 1.2: Úhlová odchylka polohy přijímače GNSS . . . 1.3: Rovnost gravitační a dostředivé síly družice . . 1.4: Úhlová rychlost pohybu družice po kruhové dráze 1.5: Střední anomálie družice . . . . . . . . . . . 1.6: Keplerova rovnice . . . . . . . . . . . . . . 1.7: Pravá anomálie . . . . . . . . . . . . . . . 1.8: Zeměpisná šířka družice . . . . . . . . . . . 1.9: Inklinace družice . . . . . . . . . . . . . . 1.10: Vzdálenost družice od středu Země . . . . . 3.1: Potřebná velikost bufferu . . . . . . . . . . 3.2: Střed zobrazené části mapy . . . . . . . . . 3.3: Rotace zobrazované mapy . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

17 17 22 22 23 23 23 23 23 23 50 60 60

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

21 25 34 37 37 37 39 41 43 44 48 48 55 56 58

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

20 30 51 54 65

Seznam obrázků Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek

1.1: 1.2: 2.1: 2.2: 2.3: 2.4: 2.5: 2.6: 2.7: 2.8: 3.1: 3.2: 3.3: 3.4: 3.5:

Vztah souřadných soustav ECEF a NED . Časová značka podle specifikace ARINC 743 Blokové schéma navrženého zařízení . . . Uložení binární hodnoty do slova . . . . . Uložení 20bitové hodnoty do slova . . . . Uložení BCD hodnoty do slova . . . . . . Algoritmus hlavní programové smyčky . . Příjem zpráv z GPS . . . . . . . . . . . Slovo sběrnice ARINC 429 . . . . . . . . Měřicí sestava pro ověření funkce . . . . . Blokové schéma simulátoru displeje . . . . Zařízení fy Pragolet a simulátor displeje . Dynamická alokace paměti . . . . . . . . Přístroj s umělým horizontem . . . . . . Přístroj posuvné mapy . . . . . . . . .

Seznam tabulek Tabulka Tabulka Tabulka Tabulka Tabulka

1.1: 1.2: 3.1: 3.2: 0.1:

Seznam binárních zpráv použitých Porovnání verzovacích systémů . Porovnání rychlosti překreslování Ukázka nastavení aplikace . . . Veličiny podle ARINC 743 . . . 73

v . . . .

aplikaci . . . . . . . . . . . . . . . .

. . . .

74