Systém monitorování smíšeného provozu malých letadel a bezpilotních prostředků

ˇ Ceské vysoké uˇcení v Praze Fakulta elektrotechnická

Diplomová práce

Systém monitorování smíšeného provozu malých letadel a bezpilotních prostˇredku˚ Valová Iveta

Vedoucí práce: Ing. Pavel Paˇces Studijní program: Elektrotechnika a informatika Obor: Kybernetika a mˇeˇrení leden 2011

Podˇekování Ráda bych touto cestou vyjádˇrila sv˚uj dík Ing. Pavlu Paˇcesovi za jeho cenné pˇripomínky, trpˇelivost a ochotu pˇri vedení mé diplomové práce. Rovnˇež bych chtˇela podˇekovat své rodinˇe a Ing. Marcelu Nejezchlebovi za jejich maximální podporu pˇri psaní. ii

iii

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracovala samostatnˇe a použila jsem pouze podklady uvedené v pˇriloženém seznamu. Nemám závažný d˚uvod proti užití tohoto školního díla ve smyslu §60 Zákona cˇ . 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zmˇenˇe nˇekterých zákon˚u (autorský zákon). V Praze dne 4. ledna 2011

............................................. iv

v

Abstract One of good promise field of aviation trade are unmanned aircraft. In this field there could interact not only aircraft manufacturers, but either various student’s projects. One of these student’s projects is project DaMMaE. This project proposes design small unmanned aircraft. The first part of this diploma thesis covers the project DaMMaE, the second one covers basic bus systems of aircraft, in detail is given account of CAN bus, which was choosen as suitable for use on the small unmanned aircraft. It is followed by problem of transfering data between aircraft and ground stations. In the fourth part there is overview to ADS-B systems. The last part of this diploma thesis is about design of solution for data transfers around aircraft and between aircraft and ground stations.

Abstrakt Jednou ze slibnˇe se rozvíjejících oblastí v leteckém pr˚umyslu jsou bezpilotní prostˇredky. V této oblasti mohou na trhu p˚usobit nejen letecké podniky, ale také r˚uzné studentské projekty. Jedním z nich je projekt DaMMaE, který si klade za cíl navrhnout malý bezpilotní prostˇredek. První kapitola této práce popisuje samotný projekt DaMMaE, v cˇ ásti druhé je popsán základní sbˇernicový systém letadel, detailnˇeji je pak popsána sbˇernice CAN, která byla zvolena jako vhodná pro použití na malém bezpilotním prostˇredku. Následuje nastínˇení problematiky pˇrenosu údaj˚u mezi letadlem a pozemním rˇídícím stanovištˇem. Ve cˇ tvrté kapitole je pˇriblížen systém ADS-B. Poslední cˇ ástí této práce je samotný návrh ˇrešení pˇrenosu údaj˚u na letadle a mezi letadlem a pozemním stanovištˇem.

vi

vii

Obsah 1

Úvod 1.1

2

Popis projektu DaMMaE . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Charakteristika bezpilotního prostˇredku . . . . . . . . . . . . .

1

1.2

Požadavky na realizaci . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.3

Legislativní rámec . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Pˇrenos údaju˚ na letadle

6

2.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.1

Základní dˇelení sbˇernic . . . . . . . . . . . . . . . . . . . . . .

7

2.1.2

Sbˇernice v letectví . . . . . . . . . . . . . . . . . . . . . . . .

8

CAN (Controller Area Network) . . . . . . . . . . . . . . . . . . . . .

8

2.2.1

Základní vlastnosti . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.2

Struktura uzl˚u CAN . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.3

Zprávy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2.4

Informace o smˇerování

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

14

2.2.5

Fyzická vrstva . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.6

Linková vrstva . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2.7

Chyby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.3

Protokoly vyšších vrstev . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4

Protokol CANaerospace . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.4.1

Typ zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.4.2

Formát zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.4.3

Servisní protokol uzl˚u sbˇernice . . . . . . . . . . . . . . . . . .

27

2.4.4

Identifikátory . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.2

3

1

Pˇrenos údaju˚ mezi letadlem a pozemní stanicí

29

3.1

Možnosti komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.1.1

Radiomodemy . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.1.2

GSM spojení . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

viii

OBSAH

3.2

ix 3.1.3

Mobilní vysokorychlostní spojení . . . . . . . . . . . . . . . .

34

3.1.4

Standard 802.11 . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.1.5

VKV spojení . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

Výbˇer druhu komunikace . . . . . . . . . . . . . . . . . . . . . . . . .

36

Odmˇeˇrení vlastností standardu 802.11 . . . . . . . . . . . . . .

36

3.2.1 4

Systém ADS-B

43

4.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.1.1

ADS - C (Automatic Dependent Surveillance - Contract) . . . .

43

4.1.2

ADS - B (Automatic Dependent Surveillance - Broadcast) . . .

43

4.1.3

ADS - R (Automatic Dependent Sureveillance - Rebroadcast) .

47

4.2

Výhody systému ADS-B . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.3

Princip cˇ innosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.4

Datové linky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.4.1

VHF Digital Link Mode . . . . . . . . . . . . . . . . . . . . .

50

4.4.2

Universal Access Transceiver (UAT)

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

51

4.4.3

1090 MHz Mode S Extended Squitter . . . . . . . . . . . . . .

58

Další možnosti systému ADS-B . . . . . . . . . . . . . . . . . . . . .

59

4.5.1

FIS-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.5.2

TIS-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.6

Srovnání ADS-B a SSR . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.7

Souˇcásti systému ADS-B . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.7.1

ADS-B zdroj dat . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.7.2

ADS-B vysílaˇc . . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.7.3

ADS-B pˇrijímaˇc . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.7.4

Zobrazovaˇc ADS-B

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

62

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

73

Integrovaný systém ˇrízení letového provozu . . . . . . . . . . .

73

Souˇcasné využití ADS-B . . . . . . . . . . . . . . . . . . . . . . . . .

74

4.9.1

Situace v Austrálii . . . . . . . . . . . . . . . . . . . . . . . .

75

4.9.2

ADS-B v Evropˇe . . . . . . . . . . . . . . . . . . . . . . . . .

76

4.9.3

ADS-B v USA . . . . . . . . . . . . . . . . . . . . . . . . . .

76

4.10 Využití ADS-B v projektu DaMMaE . . . . . . . . . . . . . . . . . . .

77

Realizace

78

5.1

Identifikace pˇrenášených parametr˚u . . . . . . . . . . . . . . . . . . .

78

5.1.1

První fáze projektu . . . . . . . . . . . . . . . . . . . . . . . .

78

5.1.2

Druhá fáze projektu . . . . . . . . . . . . . . . . . . . . . . . .

79

4.5

4.8

Budoucnost ADS-B 4.8.1

4.9

5

OBSAH

x

5.2

5.3

6

5.1.3

Pˇrenášení parametr˚u pomocí vývojové desky Arduino . . . . .

80

5.1.4

Pˇrenášení parametr˚u po sbˇernici CAN . . . . . . . . . . . . . .

80

5.1.5

Rozšíˇrení projektu . . . . . . . . . . . . . . . . . . . . . . . .

83

Realizace s vývojovou deskou Arduino . . . . . . . . . . . . . . . . . .

84

5.2.1

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

5.2.2

Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

5.2.3

Arduino Duemilanove . . . . . . . . . . . . . . . . . . . . . .

85

5.2.4

Arduino Ethernet Shield . . . . . . . . . . . . . . . . . . . . .

87

5.2.5

Pˇrenos dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

5.2.6

Arduino Mega 2560 . . . . . . . . . . . . . . . . . . . . . . .

89

Realizace pomocí CAN sbˇernice . . . . . . . . . . . . . . . . . . . . .

90

5.3.1

Simulace pomocí Matlabu . . . . . . . . . . . . . . . . . . . .

91

5.3.2

Realizace na desce s procesorem Freescale HC12 . . . . . . . .

97

Závˇer

103

Literatura

105

A Schéma Arduino Duemilanove

110

B Schéma Arudino Ethernet Shield

112

C Schéma vývojové desky

114

D Obsah pˇriloženého CD

116

xi

Seznam obrázku˚ 1.1

Vizualizace bezpilotního prostˇredku projektu DaMMaE, zdroj: [37] . .

2

1.2

P˚udorys bezpilotního prostˇredeku projektu DaMMaE, zdroj: [37] . . . .

2

1.3

Nárys bezpilotního prostˇredeku projektu DaMMaE, zdroj: [37] . . . . .

2

1.4

Bokorys bezpilotního prostˇredeku projektu DaMMaE, zdroj: [37] . . . .

3

2.1

Full-Mesh propojení jednotlivých systém˚u, zdroj: autor . . . . . . . . .

7

2.2

Blokové schéma jednosmˇerné sbˇernice, zdroj: autor dle [27] . . . . . .

7

2.3

Blokové schéma obousmˇerné sbˇernice s centrálním ˇrízením, zdroj: autor dle [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4

7

Blokové schéma obousmˇerné sbˇernice s distribuovaným ˇrízením, zdroj: autor dle [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.5

Vztah CAN a modelu ISO/OSI, zdroj: autor dle [48] . . . . . . . . . .

9

2.6

Principiální schéma sítˇe CAN, zdroj: autor dle [3] . . . . . . . . . . . .

11

2.7

Bloky uzlu CAN, zdroj: autor dle [48] . . . . . . . . . . . . . . . . . .

11

2.8

Struktura datové zprávy, zdroj: autor dle [7] . . . . . . . . . . . . . . .

12

2.9

Struktura žádosti o data, zdroj: autor dle [7] . . . . . . . . . . . . . . .

14

2.10 Struktura chybové zprávy, zdroj: autor dle [7] . . . . . . . . . . . . . .

15

2.11 Struktura zprávy o pˇretížení, zdroj: autor dle [7] . . . . . . . . . . . . .

15

2.12 Porovnání metod NRZ, RZ a Manchester kódu, zdroj: autor . . . . . . .

17

2.13 Bit-stuffing, zdroj: autor dle [7] . . . . . . . . . . . . . . . . . . . . . .

17

2.14 Segmenty nutné pro synchronizaci, zdroj: autor dle [48] . . . . . . . . .

18

2.15 Standardní terminátor, zdroj: autor dle [48] . . . . . . . . . . . . . . .

19

2.16 Split terminátor, zdroj: autor dle [48] . . . . . . . . . . . . . . . . . . .

19

2.17 Biased split terminátor, zdroj: autor dle [48] . . . . . . . . . . . . . . .

20

2.18 Princip arbitráže, zdroj: autor dle [7] . . . . . . . . . . . . . . . . . . .

21

2.19 Vztah mezi jednotlivými stavy uzlu, zdroj: autor dle [7] . . . . . . . . .

23

2.20 Obecný formát zprávy, zdroj: autor dle [52] . . . . . . . . . . . . . . .

26

2.21 Formát nouzové zprávy, zdroj: autor dle [52] . . . . . . . . . . . . . . .

26

xii

SEZNAM OBRÁZKU˚

xiii

2.22 Formát zprávy NOD, zdroj: autor dle [52] . . . . . . . . . . . . . . . .

27

3.1

Schéma rádiového modulu HW 86012, zdroj: autor dle [9] . . . . . . .

32

3.2

Demonstrace Fresnelovy zóny, zdroj: autor . . . . . . . . . . . . . . .

33

3.3

Vyzaˇrovací charakteristika antény Cisco ANT-2506, zdroj: autor dle [15]

37

3.4

Umístˇení pˇrístupového bodu a antény, zdroj: autor . . . . . . . . . . . .

38

3.5

Síla signálu s klesající vzdáleností od pˇrístupového bodu, zdroj: autor .

39

3.6

Dosah standardu 802.11b/g pro pˇrenosovou rychlost 5.5 Mbit/s, zdroj: autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

3.7

Síla signálu ve vzdálenosti 430 m po dobu cca 2 minut, zdroj: autor . .

40

3.8

Maximální dosah standardu 802.11b/g, zdroj: autor . . . . . . . . . . .

41

3.9

Osoba mˇeˇrící sílu signálu ve vzdálenosti 750 m, zdroj: autor . . . . . .

41

3.10 Kolísání síly signálu ve vzdálenosti 750 m, zdroj: autor . . . . . . . . .

42

4.1

ADS-B OUT, zdroj: autor . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.2

ADS-B IN, zdroj: autor . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.3

Diagram zobrazovaˇce CDTI, zdroj: autor dle [41] . . . . . . . . . . . .

49

4.4

Princip cˇ innosti systému ADS-B, zdroj: autor . . . . . . . . . . . . . .

49

4.5

VDL Mode 4, zdroj: autor dle [46] . . . . . . . . . . . . . . . . . . . .

50

4.6

Universal Access Transceiver, zdroj: autor dle [46] . . . . . . . . . . .

51

4.7

Formát zprávy UAT ADS-B, zdroj: autor dle [14] . . . . . . . . . . . .

52

4.8

Hlaviˇcka zprávy UAT ADS-B, zdroj: autor dle [14] . . . . . . . . . . .

52

4.9

Formát stavového pole UAT ADS-B zprávy, zdroj: autor dle [14] . . . .

55

4.10 Kvadranty a zemˇepisná délka/šíˇrka, zdroj: autor dle [14] . . . . . . . .

55

4.11 Formát pomocného stavového vektoru, zdroj: autor dle [14] . . . . . . .

56

4.12 Formát zprávy UAT ADS-B pˇrenášené z pozemní stanice, zdroj: autor dle [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.13 1090 MHz Mode S Extended Squitter, zdroj: autor dle [46] . . . . . . .

58

4.14 Kapesní poˇcítaˇc s instalovaným ADS-B, zdroj: [5]

62

. . . . . . . . . . .

4.15 Symbol pro zobrazení okolního provozu, zdroj: autor dle [34]

. . . . .

64

4.16 Displej systému ADS-B v základním režimu, zdroj: autor dle [34] . . .

65

4.17 Vybrání urˇcitého cíle na displeji systému ADS-B, zdroj: autor dle [34] .

65

4.18 Symboly pro zobrazení jiných objekt˚u, zdroj: autor dle [34]

. . . . . .

66

4.19 Zobrazovaˇc CDTI 2000, zdroj: [19] . . . . . . . . . . . . . . . . . . .

66

4.20 Zobrazení okolního provozu CDTI2000, zdroj: [58] . . . . . . . . . . .

68

4.21 Zobrazení okolního terénu CDTI2000, zdroj: [35] . . . . . . . . . . . .

68

4.22 Zobrazení pohybujících se map CDTI2000, zdroj: [58] . . . . . . . . .

68

4.23 Zobrazení digitální komunikace CDTI2000, zdroj: [35] . . . . . . . . .

69

SEZNAM OBRÁZKU˚

xiv

4.24 Význam barev pˇri zobrazení terénu, zdroj: autor dle [34] . . . . . . . .

69

4.25 Zobrazovaˇc Garmin MX20, zdroj: [34] . . . . . . . . . . . . . . . . . .

70

4.26 Grafické a textové zobrazení okolního provozu na zobrazovaˇci MX20, zdroj: [34] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

4.27 Zobrazení okolního terénu na zobrazovaˇci MX20, zdroj: [34] . . . . . .

70

4.28 Grafické a textové zobrazení poˇcasí na zobrazovaˇci MX20, zdroj: [34] .

71

4.29 Zobrazení mapy na zobrazovaˇci MX20, zdroj: [34] . . . . . . . . . . .

71

4.30 Zobrazení letových cest na zobrazovaˇci MX20, zdroj: [34] . . . . . . . 4.31 Letový provoz na obrazovce rˇídícího letového provozu, zdroj: autor dle

71

[44] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

4.32 Pokrytí Austrálie jednotlivými systémy, zdroj: [44] . . . . . . . . . . .

76

4.33 Pokrytí v Evropˇe, zdroj: [18] . . . . . . . . . . . . . . . . . . . . . . .

77

5.1

Schéma pˇripojení blok˚u k vývojové desce Arduino Duemilanove, zdroj: autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

5.2

Propojení jednotlivých blok˚u se sbˇernící CANaerospace, zdroj: autor . .

82

5.3

Schéma simulace teploty, zdroj: autor . . . . . . . . . . . . . . . . . .

88

5.4

Propojení sbˇernice CAN a modulu HW 86012, zdroj: autor . . . . . . .

90

5.5

Propojení sbˇernice CAN a desky Arduino Duemilanove, zdroj: autor . .

91

5.6

Schéma pˇrenosu USB-Matlab-RS 232, zdroj: autor . . . . . . . . . . .

91

5.7

Komunikace pˇres Virtual Null-modem, zdroj: autor . . . . . . . . . . .

93

5.8

Výstup simulace - RS 232 terminál, zdroj: autor . . . . . . . . . . . . .

94

5.9

Schéma propojení CAN sbˇernice a sériového rozhraní RS 232, zdroj: autor 94

5.10 Obecný formát pro binární kódování, zdroj: autor dle [51] . . . . . . . 5.11 Návrh formátu cˇ íslo 185, zdroj: autor . . . . . . . . . . . . . . . . . . .

95 95

xv

Seznam tabulek 1.1

Základní údaje bezpilotního prostˇredku projektu DaMMaE . . . . . . .

2

2.1

Letadla a jejich sbˇernice . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2

Základní elektrické vlastnosti protokolu CAN . . . . . . . . . . . . . .

10

2.3

Význam polí ve zprávˇe . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.4

Závislost doby pˇrechodu signálu a maximální bitové rychlosti pˇri délce vedení 100 m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5

Závislost maximální délky sbˇernice na pˇrenosové rychlosti . . . . . . .

20

2.6

Typy chyb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

2.7

Závislost stavu cˇ ítaˇcu˚ a stavu uzlu . . . . . . . . . . . . . . . . . . . .

23

2.8

Typy zpráv a jejich priority . . . . . . . . . . . . . . . . . . . . . . . .

25

2.9

Servisní zprávy s vysokou prioritou . . . . . . . . . . . . . . . . . . .

28

2.10 Servisní zprávy s nízkou prioritou . . . . . . . . . . . . . . . . . . . .

28

3.1

Bezdrátové technologie IrDa, Bluetooth a ZigBee a jejich dosahy . . . .

30

3.2

Základní parametry technologie DECT . . . . . . . . . . . . . . . . . .

30

3.3

Standardy IEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.4

Základní parametry antény Cisco ANT-2506 . . . . . . . . . . . . . . .

37

4.1

Systém ADS-B a jeho význam . . . . . . . . . . . . . . . . . . . . . .

44

4.2

Vliv kódování dat zprávy ADS-B na pˇrenášená data . . . . . . . . . . .

53

4.3

Význam adresy v hlaviˇcce zprávy UAT ADS-B . . . . . . . . . . . . .

54

4.4

Kódování zemˇepisné šíˇrky a délky . . . . . . . . . . . . . . . . . . . .

54

4.5

Význam bitu Altitude type . . . . . . . . . . . . . . . . . . . . . . . .

55

4.6

Kódování výšky UAT kanálu . . . . . . . . . . . . . . . . . . . . . . .

56

4.7

Kódování pole NIC . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

4.8

Kódování pole A/G State . . . . . . . . . . . . . . . . . . . . . . . . .

57

4.9

Kódování pole UTC . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

4.10 Srovnání pˇrenosu jednotlivých dat SSR a ADS-B . . . . . . . . . . . .

60

xvi

SEZNAM TABULEK

xvii

4.11 Srovnání výhodnosti pˇrenosu parametr˚u pomocí SSR a ADS-B . . . . .

60

4.12 Kódování okolního provozu bez relativního kurzu . . . . . . . . . . . .

64

4.13 Základní technické informace zobrazovaˇce CDTI 2000 . . . . . . . . .

67

4.14 Vybrané technické informace zobrazovaˇce MX20 . . . . . . . . . . . .

72

4.15 Vybrané technické informace zobrazovaˇce GMX 200 . . . . . . . . . .

73

4.16 Symboly pro rozlišení zp˚usob˚u získání informace o poloze . . . . . . .

74

5.1

Senzory analogových veliˇcin . . . . . . . . . . . . . . . . . . . . . . .

80

5.2

Identifikace parametr˚u v protokolu CANaerospace . . . . . . . . . . .

81

5.3

Základní parametry vývojové desky Arduino Duemilanove . . . . . . .

85

5.4

Porovnání pamˇetí mikrokontrolér˚u ATmega168 a ATmega328 . . . . .

85

5.5

Srovnání Arduino Duemilanove a Arduino Mega 2560 . . . . . . . . .

90

5.6

Finanˇcní náklady varianty s radiovým modulem a s Arduinem Duemilanove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91 95

5.8

Byty v obecném formátu binárního kódování . . . . . . . . . . . . . . Popis byt˚u navrhnutého formátu cˇ íslo 185 . . . . . . . . . . . . . . . .

95

5.9

Pamˇeti mikrokontroleru MC9S12XDT256 . . . . . . . . . . . . . . . .

98

5.10 Software pro realizaci . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

5.7

xviii

Kapitola 1

Úvod 1.1

Popis projektu DaMMaE

Projekt DaMMaE se zabývá sestrojením bezpilotního prostˇredku spadajícího do kategorie Very Light UAS (Unmanned Aerial System). Celý projekt byl rozdˇelen na 4 hlavní cˇ ásti: • návrh a konstrukce letadla; • návrh pohonu a zdroj˚u systém˚u; • návrh autopilota; • návrh pˇrenosu a sdílení dat. Tyto oblasti dohromady mají za cíl vytvoˇrit bezpilotní prostˇredek použitelný pro využití volného cˇ asu úˇcastník˚u projektu. Neklade si za cíl konkurovat jiným bezpilotním prostˇredk˚um.

1.1.1

Charakteristika bezpilotního prostˇredku

Návrh konstrukce je ˇrešen v [37]. Koneˇcný návrh je zobrazen na obrázku 1.1. Byla zvolena koncepce tandemového dvouplošníku v kombinaci s tlaˇcnou vrtulí. Základní údaje, vˇcetnˇe vybraných aerodynamických parametr˚u navrhnutého bezpilotního prostˇredku, jsou uvedeny v tabulce 1.1, [37]. Na obrázcích 1.2, 1.3 a 1.4 jsou zobrazeny jednotlivé pohledy na bezpilotní prostˇredek projektu DaMMaE - p˚udorys, nárys a bokorys. Na tˇechto obrázcích jsou okótované nejd˚uležitˇejší rozmˇery. 1

2

KAPITOLA 1. ÚVOD

Obrázek 1.1: Vizualizace bezpilotního prostˇredku projektu DaMMaE, zdroj: [37] Tabulka 1.1: Základní údaje bezpilotního prostˇredku projektu DaMMaE Parametr Hodnota pˇrední kˇrídlo zadní kˇrídlo rozpˇetí 1.18 m 1.5 m stˇrední aerodynamická tˇetiva lSAT 0.1242 m 0.1586 m plocha kˇrídla 0.1457 m2 0.2362 m2 maximální šíˇrka trupu 0.2 m celková délka 0.67 m návrhová rychlost 11.8 m/s (42.5 km/h) maximální úhel nábˇehu α 7-8◦ vzletová hmotnost 2.5 kg

Obrázek 1.2: P˚udorys bezpilotního prostˇredeku projektu DaMMaE, zdroj: [37]

Obrázek 1.3: Nárys bezpilotního prostˇredeku projektu DaMMaE, zdroj: [37]

1.1. POPIS PROJEKTU DAMMAE

3

Obrázek 1.4: Bokorys bezpilotního prostˇredeku projektu DaMMaE, zdroj: [37] Pohon a napájení bezpilotního prostˇredku projektu DaMMaE je ˇrešen v [53]. Z této práce plyne, že pohon bude zajištˇen pomocí tlaˇcné vrtule pohánˇené elektromotorem AXI 2820/10, který je rˇízen regulátorem se vstupem reagujícím na modeláˇrský systém ovládání. Napájení je v této práci ˇrešeno pomocí akumulátor˚u umístˇených v trupu navrhovaného letadla. Jako vhodný druh akumulátor˚u pro napájení systém˚u na letadle byly vybrány lehké Li-Pol akumulátory doplnˇené lineárním regulátorem pro stabilizaci napˇetí. Návrh autopilota pro bezpilotní prostˇredek projektu DaMMaE je podrobnˇe popsán v [36]. Kromˇe popisu autopilota je v této práci rˇešena také problematika nutných jednotek pro bˇeh autopilota - servomotory, zdroj urˇcení polohy, akcelerometry, mikrokontrolery, jednotka zpracování signál˚u a tlakový senzor. 1.1.1.1

Komponenty bezpilotního prostˇredku

Na palubˇe bezpilotního prostˇredku budou neseny tyto komponenty: • pohonná jednotka; • zdroje elektrické energie; • komunikaˇcní zaˇrízení; • jednotka autopilota; • jednotka zpracování signál˚u; • senzory letu; • užiteˇcné zatížení; • návratové zaˇrízení (padák). Úlohou této práce je stanovit vhodné komunikaˇcní zaˇrízení a vhodné médium pro pˇrenos informací mezi jednotlivými zaˇrízeními umístˇenými na bezpilotním prostˇredku.

KAPITOLA 1. ÚVOD

4

1.2

Požadavky na realizaci

Nejd˚uležitˇejším požadavkem na realizaci bezpilotního letounu projektu DaMMaE je cena. Celý projekt je založen na co nejmenších nákladech, jednotlivé komponenty budou hrazeny úˇcastníky. Od toho se odvíjí návrh systému komunikace na palubˇe i mezi letounem a pozemním stanovištˇem, který musí být velmi levný, nebot’ v poˇcátcích provozu letounu se musí poˇcítat s možnými pády a tedy i s možnými destrukcemi systém˚u na letadle. Až po ovˇerˇení spolehlivosti lze pˇristoupit k nákladnˇejším ˇrešením komunikace, protože pravdˇepodobnost zniˇcení komponent˚u není již tak vysoká jako v poˇcátcích. Mezi další základní požadavky lze rˇadit: • spolehlivý pˇrenos údaj˚u; • nízká hmotnost; • malé rozmˇery; • nízká spotˇreba elektrické energie.

1.3

Legislativní rámec

ˇ Provoz bezpilotních prostˇredk˚u není v nynejší dobˇe v legislativˇe Ceské republiky specifikován. Proto se na bezpilotní letadla musí pohlížet jako na pilotovaná letadla. D˚usledkem toho je, že i bezpilotní prostˇredky se musí rˇídit pˇredpisy pro klasická letadla. Vyjímku tvoˇrí ty, jejichž maximální vzletová hmotnost nepˇresahuje 20 kg. Na nˇe se pohlíží jako na modely. Pokud se ale tyto bezpilotní prostˇredky chtˇejí využívat komerˇcnˇe na území ˇ Ceské republiky, musí jejich provozovatelé dostat povolení od Úˇradu pro civilní letectví. Aby se bezpilotní letoun projektu DaMMaE nemusel podˇrizovat pˇredpis˚um pro letadla, byl navrhnut tak, aby jeho maximální vzletová hmotnost byla menší než 20 kilo. Do maximální vzletové hmotnosti se poˇcítá hmotnost letounu vˇcetnˇe vybavení, provozních náplní, paliva a pˇrípadného nákladu [20]. Úˇcel letounu byl stanoven na rekreaˇcní letání úˇcastník˚u projektu. Pod tˇemito podmínkami lze letoun provozovat bez nutnosti schválení Úˇradem pro civilní letectví. Je nutné podotknout, že bˇehem roku 2011 se pˇredpokládá uveˇrejnˇení Doplˇnku X k leteckému pˇredpisu L2 Pravidla létání. Tento Doplˇnek se vztahuje k provozu bezpilotních prostˇredk˚u. Po jeho uveˇrejnˇení se jím bude muset bezpilotní letoun DaMMaE ˇrídit. Dle Dopˇnku X se bezpilotní prostˇredky dˇelí na prostˇredky provozované výhradnˇe v dohledu pilota a na prostˇredky provozované mimo dohled. Projekt DaMMaE poˇcítá se zaˇrazením k prostˇredk˚um provozovaným výhradnˇe v dohledu pilota. Pro ty platí, že vzdálenost mezi pilotem a prostˇredkem nesmí pˇresáhnout 700 m. Na tuto vzdálenost

1.3. LEGISLATIVNÍ RÁMEC

5

musí být ovšem prostˇredek viditelný tak, aby pilot dokázal urˇcit jeho polohu a smˇer letu. Pro menší bezpilostní prostˇredky tak m˚uže být tato vzdálenost ještˇe menší. V pˇrípadˇe, že do letounu nebude zastavˇen autopilot a rˇízení bude pouze manuální, lze letoun provozovat v souladu s plánovaným Doplˇnkem Y. V tomto pˇrípadˇe by se na letoun pohlíželo jako na model letadla. Letoun musí ale být provozován výhradnˇe v dohledu pilota. Vzdálenost mezi pilotem a bezpilotním prostˇredkem (v tomto pˇrípadˇe již vlastnˇe modelem) nesmí opˇet pˇresáhnout 700 m.

Kapitola 2

Pˇrenos údaju˚ na letadle 2.1

Úvod

Pˇrenos údaj˚u na letadle je d˚uležitý hlavnˇe z hlediska pilotáže. S nástupem elektronických systém˚u na místo mechanických se stalo nutností, aby mezi sebou komunikovaly jednotlivé systémy a navzájem spolupracovaly. Staly se hlavním zdrojem informací o pohybu, poloze a dráze letadla, zvláštˇe pˇri snížené viditelnosti. D˚uležitým argumentem elektronického pˇrenosu informací je také samotné rˇízení letadla. S nástupem „fly-by-wire“ již i ovládání kormidel není ˇrešeno pomocí táhel, ale provádí se elektronicky. Nejjednodušším pˇrenosem je samostatné propojení jednotlivých systém˚u. Jenže pˇri velkém množství systém˚u, které se do letadla instalují, roste množství vodiˇcu˚ nutných pro jejich vzájemné propojení a také se zbyteˇcnˇe pˇrenášejí stejná data po nˇekolika vodicˇ ích k r˚uzným systém˚um. Tomuto zapojení se ˇríká Full-Mesh. Poˇcet vodiˇcu˚ roste podle vzorce: n! , 2 kde n je poˇcet propojovaných zaˇrízení. Situace je zobrazena na obrázku 2.1. Z tohoto obrázku je patrné, že již pro 4 zaˇrízení je poˇcet vodiˇcu˚ pˇríliš velký. Roste tedy nejenom celková váha letadla, ale také pravdˇepodobnost závady na nˇekterém z vodiˇcu˚ a konektor˚u. Geometrickou rˇadou nar˚ustá doba nutná pro její odhalení. Dalším problémem je pˇripojení nového systému, který se musí propojit se všemi okolními systémy. Aby se odstranily nevýhody, zaˇcaly se využívat sbˇernice zajišt’ující pˇrenos mezi více zaˇrízeními, které jsou k nim pˇripojené. 6

2.1. ÚVOD

7

Obrázek 2.1: Full-Mesh propojení jednotlivých systém˚u, zdroj: autor

2.1.1

Základní dˇelení sbˇernic

Sbˇernice dˇelíme na: • sbˇernice jednosmˇerné (obr. cˇ . 2.2); • sbˇernice obousmˇerné – s centrálním ˇrízením (obr. cˇ . 2.3); – s distribuovaným ˇrízením (obr. cˇ . 2.4).

Obrázek 2.2: Blokové schéma jednosmˇerné sbˇernice, zdroj: autor dle [27]

Obrázek 2.3: Blokové schéma obousmˇerné sbˇernice s centrálním ˇrízením, zdroj: autor dle [27]

ˇ KAPITOLA 2. PRENOS ÚDAJU˚ NA LETADLE

8

Obrázek 2.4: Blokové schéma obousmˇerné sbˇernice s distribuovaným ˇrízením, zdroj: autor dle [27]

2.1.2

Sbˇernice v letectví

V civilním letectví jsou používány pˇredevším tyto typy sbˇernic: • ARINC 429 - jednosmˇerná; • ARINC 629 - obousmˇerná, distribuovaná; • Commercial Standard Data Bus (CSDB) - jednosmˇerná; • Aviation Standard Communications Bus (ASCB) - obousmˇerná centrální. Ve vojenském sektoru se využívají zejména tyto 2 sbˇernice: • MIL-STD 1553 - obousmˇerná centrální; • MIL-STD 1773 - multiplexní, médium: optické kabely. Pˇrehled nejznámnˇejších letadel a jejich sbˇernic je v tabulce 2.1.

Sbˇernice Arinc 429

Arinc 629

2.2

Tabulka 2.1: Letadla a jejich sbˇernice Letadlo Sbˇernice Letadlo Airbus A320 ASCB Cessna Citation Boeing 747 ATR 72 Bell Helicopter Gulfstream IV MC-11 CSDB DC-8 Airbus A380 Boeing 727 Boeing 777 MIL-STD 1553 L 159 Alca F 16

CAN (Controller Area Network)

CAN je komunikaˇcní vrstva pro sériové sbˇernice. CAN se p˚uvodnˇe využíval pouze v automobilovém pr˚umyslu. Pro své vlastnosti (napˇríklad nízká cena, vysoká spolehlivost

2.2. CAN (CONTROLLER AREA NETWORK)

9

a pˇrenosová rychlost, snadná dostupnost potˇrebných souˇcástek) se zaˇcal šíˇrit i do dalších pr˚umyslových aplikací. CAN a jeho vztah k referenˇcnímu modelu ISO/OSI je znázornˇen na obrázku 2.5, levý sloupec pˇredstavuje ISO/OSI model, v pravém jsou jednotlivé vrstvy CAN.

Obrázek 2.5: Vztah CAN a modelu ISO/OSI, zdroj: autor dle [48] Fyzická vrstva CAN je definována nˇekolika standardy, a je popsána v cˇ ásti 2.2.5. CAN má na úrovni linkové vrstvy referenˇcního modelu ISO/OSI dvˇe specifikace – CAN 2.0A a CAN 2.0B, viz cˇ ást 2.2.6. Aplikaˇcní vrstva je definována nˇekolika standardy, které jsou ovšem vzájemnˇe nekompatibilní. Jejich pˇrehled je uveden v kapitole 2.3. V kapitole 2.4 je podrobnˇeji popsána aplikaˇcní vrstva CANaerospace.

2.2.1

Základní vlastnosti

Základní charakteristika sbˇernice CAN se dá shrnout do následujících bod˚u: • distribuované ˇrízení systém˚u v reálném cˇ ase; • pˇrenosová rychlost až 1Mbit/s; • vysoký stupeˇn zabezpeˇcení pˇrenosu proti chybám; • protokol multimaster;


10

• sbˇernice s náhodným pˇrístupem; • max 30 uzl˚u; • max délka 40 m (pro rychlost 1 Mbit/s). CAN má následující vlastnosti: • priority zpráv; • garantovaná cˇ ekací doba; • multicast pˇríjem s cˇ asovou synchronizací; • detekce chyb a jejich signalizace; • automatické pˇreposlání pˇrerušených dat v okamžiku klidu na sbˇernici; • rozlišení doˇcasných a trvalých chyb uzl˚u s automatickým vypnutím vadných uzl˚u. Základní elektrické vlastnosti protokolu CAN shrnuje tabulka 2.2, [48], pˇriˇcemž úroveˇn dominant pˇredstavuje logickou nulu a úroveˇn recessive logickou jedniˇcku (viz obr. 2.6). Tabulka 2.2: Základní elektrické vlastnosti protokolu CAN Parametr minimální hodnota maximální hodnota Stejnosmˇerné napˇetí (limit pro budiˇc) -3 V +32 V Pˇrechodové napˇetí -150 V +100 V Napˇetí na sbˇernici v bˇežném provozu -2 V +7 V Výstupní napˇetí recessive +2 V +3 V Diferenciální výstupní napˇetí recessive -500 mV +50 mV Diferenciální vnitˇrní odpor 10 kΩ 100 kΩ Odpor pˇri bˇežném provozu 5 kΩ 50 kΩ Diferenciální výstupní napˇetí dominant +1,5 V +3 V Výstupní napˇetí dominant na CAN_H +2,75 V +4,5 V Výstupní napˇetí dominant na CAN_L +0,50 V +2,25 V

2.2.2

Struktura uzlu˚ CAN

Na obrázku 2.6 je principiální schéma sítˇe se sbˇernicí CAN. Jednotlivé uzly se skládají z následujících obvod˚u: • mikroprocesoru; • ˇradiˇce; • budiˇce.


11

Obrázek 2.6: Principiální schéma sítˇe CAN, zdroj: autor dle [3] ˇ c Mikroprocesor obsluhuje události, dává pokyn pro vysílání dat a zpracovává data. Radiˇ CAN (CAN Controller) realizuje spojovou (linkovou) vrstvu sbˇernice CAN. Má na starosti vytváˇrení rámc˚u, arbitráž, filtrování zpráv, chybové zabezpeˇcení atd. Budiˇc CAN (CAN Transceiver) realizuje fyzickou vrstvu - pˇrevádí signál z TTL úrovní. Bloková struktura uzlu CAN je na obrázku 2.7.

Obrázek 2.7: Bloky uzlu CAN, zdroj: autor dle [48]

2.2.3

Zprávy

Zprávy CAN jsou posílány v pevnˇe daném formátu zpráv v r˚uzné, ale limitované délce. Nová zpráva pˇripojené jednotky se posílá, pokud je sbˇernice volná. Zpráva vysílaná na sbˇernici neobsahuje identifikaci cílové jednotky. Je pˇrijímána všemi uzly na sbˇernici. To, zda zpráva bude v zaˇrízení zpracována nebo ne, rozhoduje až aplikaˇcní vrstva CAN protokolu. Typy zpráv: • datová zpráva (Data Frame); • žádost o data (Remote Frame);


12

• chybová zpráva (Error Frame); • zpráva o pˇretížení (Overload Frame). Datová zpráva a žádost o data mají dva formáty: • standardní, definovaný specifikací CAN 2.0A; • rozšíˇrený, definovaný specifikací CAN 2.0B. Základní rozdíl mezi tˇemito formáty je v délce identifikátoru, standardní má 11 bit˚u a rozšíˇrený 29 bit˚u, viz obrázky 2.8 a 2.9. 2.2.3.1

Datová zpráva

Datová zpráva slouží pro odeslání dat vysílací jednotkou. Skládá se ze 7 polí, viz obrázek 2.8, jejichž význam je shrnut v tabulce 2.3.

Obrázek 2.8: Struktura datové zprávy, zdroj: autor dle [7] Pole aribráže se dle obrázku 2.8 skládá z identifikátoru pˇrenášených dat a bitu RTR, který odlišuje žádost o data od datové zprávy. Pole rˇídících informací je pak složeno z rezervovaných bit˚u r1 a r2 a ze 4 bit˚u urˇcujících délku dat (pole DLC, Data Length Code). V rozšíˇreném formátu má bit SRR (Subsitute Remote Request) vždy hodnotu recessive. To zajišt’uje, aby pˇri vzájemné kolizi standardního a rozšíˇreného formátu získal pˇrednost standardní formát. Bit IDE (Identifier Extended) má vždy hodnotu recessive.


Tabulka 2.3: Význam polí ve zprávˇe Pole Význam Zaˇcátek rámce Indikuje zaˇcátek rámce. (Start of Frame - SOF) Pole arbitráže Indikuje prioritu (význam) rámce, rozdílné pro standardní a rozšíˇrený formát. ˇ Rídící informace Indikuje rezervované bity a velikost dat, rozdílné pro standardní a rozšíˇrený formát. Datové pole 0-8 byt˚u dat CRC kód (Cyclic Redundancy Check) Potvrzení (Acknowledge - ACK) Konec rámce (End of Frame - EOF)

Slouží pro detekování chyb. 16. bit má vždy recessive úroveˇn. Slouží po potvrzování správného pˇrijetí rámce. Indikuje konec rámce.

13

Úroveˇn dominant dominant recessive dominant recessive dominant recessive dominant recessive dominant recessive recessive

Potvrzení tvoˇrí 2 bity: • ACK (Acknowledge) - bit potvrzení; • ACD (Acknowledge Delimeter) - oddˇelovaˇc potvrzení - má vždy hodnotu recessive. Mezi jednotlivými zprávami musí být vložena mezera, kterou tvoˇrí 3 bity recessive. 2.2.3.2

Žádost o data

Tímto typem rámce pˇrijímací jednotka vyzývá k poslání dat. Skládá se ze 6 polí. Z obrázku 2.9 je patrné, že formát rámce je shodný s rámcem pro data s výjimkou toho, že neobsahuje datové pole. Význam polí je shodný s datovou zprávou, viz tabulka 2.3. Rozdíl mezi datovou zprávou a žádostí o data • neobsahuje datové pole; • RTR bit v poli arbitráže je na úrovní recessive. Datový rámec bez dat je tedy od žádosti o data odlišen právˇe úrovní bitu RTR. 2.2.3.3

Chybová zpráva

Tento typ rámce slouží pro indikaci chyby, která se m˚uže objevit bˇehem vysílání. Skládá se z pˇríznaku chyby a z chybového oddˇelovaˇce, viz obrázek 2.10.


14

Obrázek 2.9: Struktura žádosti o data, zdroj: autor dle [7] Pˇríznak chyby je dvojího druhu: • aktivní pˇríznak chyby - 6 bit˚u dominant; • pasivní pˇríznak chyby - 6 bit˚u recessive (viz cˇ ást 2.2.7.2). Chybový oddˇelovaˇc tvoˇrí 8 bit˚u recessive. 2.2.3.4

Zpráva o pˇretížení

Zprávu o pˇretížení využívá pˇrijímací jednotka, pokud není pˇripravena pˇrijmout další data. Skládá se z pˇríznaku pˇretížení a z oddˇelovaˇce zprávy o pˇretížení, viz obr. 2.11. Pˇríznak pˇretížení je 6 bit˚u dominant, oddˇelovaˇc tvoˇrí 8 bit˚u recessive.

2.2.4

Informace o smˇerování

Zprávy jednotlivých uzl˚u sbˇernice CAN nenesou žádnou informaci o konfiguraci sítˇe, neexistuje adresování. To pˇrináší nˇekolik d˚usledk˚u: • Flexibilita sítˇe - Jednotlivé uzly sítˇe mohou být pˇripojovány nebo odpojovány dle potˇreby, bez nutnosti zásahu do kteréhokoliv uzlu sítˇe nebo do aplikaˇcní vrstvy. • Smˇerování zpráv - Každá zpráva zaˇcíná identifikátorem zprávy, který nenese informaci o cílovém uzlu (pro koho je zpráva urˇcena), ale popisuje data obsažená dále ve zprávˇe. Každý uzel sítˇe je schopnen rozeznat, zda je zpráva pro nˇej potˇrebná cˇ i nikoliv.


15

Obrázek 2.10: Struktura chybové zprávy, zdroj: autor dle [7]

Obrázek 2.11: Struktura zprávy o pˇretížení, zdroj: autor dle [7] • Multicast - Zprávu na sbˇernici m˚uže souˇcasnˇe pˇrijmout libovolný poˇcet uzl˚u sítˇe. • Konzistence dat - Konzistence dat je dodržena díky principu multicast a také díky kontrole chyb. • Priorita - Identifikátor urˇcuje priority statických zpráv – urˇcuje pˇrístup na sbˇernici, viz odstavec 2.2.6.2. • Multimaster - Pokud je sbˇernice volná, m˚uže jakýkoliv uzel zaˇcít vysílat data – jednotka s vyšší prioritou (a tedy s nižším identifikátorem) pak dostane pˇrístup na sbˇernici. • Arbitráž - Kdykoliv je sbˇernice volná, jakákoliv jednotka m˚uže zaˇcít vysílat. Po-


16

kud zaˇcnou vysílat 2 a více jednotek najednou, konflikt pˇrístupu ke sbˇernici je ˇrešen pomocí bitové arbitráže s pomocí identifikátoru. Princip arbitráže garantuje, že žádná informace nebude ztracena (tomuto typu arbitráže se ˇríká bitwise arbitráž). Více o arbitráži viz odstavec 2.2.6.2. • Bezpeˇcnost - Pro dosažení co nejvyšší bezpeˇcnosti pˇrenosu dat se využívá detekce chyb a jejich signalizace následujícím zp˚usobem: – Monitorování – vysílací jednotka porovnává úroveˇn vyslaného bitu s úrovní bitu, kterou detekuje na sbˇernici; – Cyklický redundantní kód (CRC - Cyclic Redundancy Check ); – Bit-stuffing – slouží nejen k detekci chyb ale také pro cˇ asovou synchronizaci uzl˚u sítˇe; – Kontrola zprávy (Message Frame Check) – zpráva se kontroluje podle formátu dle specifikace; – Potvrzení pˇrijetí zprávy (Acknowledge).

2.2.5

Fyzická vrstva

Základní funkcí fyzické vrstvy je pˇrenos jednotlivých bit˚u od jednoho uzlu sítˇe ke druhému. V rámci jedné CAN sítˇe musí všechny zaˇrízení používat shodné parametry fyzické vrstvy. Pro vzájemnou kompatibilitu vzniklo nˇekolik standard˚u definujících fyzickou vrstvu protokolu CAN: • ISO 11898-2: CAN high speed; • ISO 11898-3: CAN fault-tolerant (low speed); • ISO 11992-1: CAN fault-tolerant for truck/trailer communication; • ISO 11783-2: Agricultural Standard, 250 kbit/s; • SAE J1939-11: stínˇený kroucený dvouvodiˇc (STP Shielded Twisted Pair), 250 kbit/s; • SAE J1939-15: nestínˇený kroucený dvouvodiˇc (UTP Unshielded Twisted Pair) – redukovaná vrstva, 250 kbit/s; • SAE J2411: jednovodiˇcový CAN (SWC Single-wire CAN).

2.2. CAN (CONTROLLER AREA NETWORK) 2.2.5.1

17

Kódování bitu˚

Jednotlivé bity se kódují metodou Non-Return-to-Zero (NRZ). To znamená, že bˇehem celkového cˇ asu pro jeden bit je generována pouze jedná úroveˇn bitu – bud’ recessive nebo dominant. Pro snadnˇejší pˇredstavu je na obrázku 2.12 porovnána metoda NRZ s metodami Return-to-Zero (RZ) a kódem Manchester, pˇri kterých se bˇehem cˇ asu pro jeden bit mˇení hodnota dominant-recessive.

Obrázek 2.12: Porovnání metod NRZ, RZ a Manchester kódu, zdroj: autor Úroveˇn signálu m˚uže z˚ustat delší dobu konstantní, proto je potˇreba zajistit, že není pˇrekroˇcen maximální pˇrípustný interval mezi konci dvou signál˚u. Tato podmínka je d˚uležitá pro správnou synchronizaci uzl˚u. Na takto kódované bity je uplatnˇen bit-stuffing, neboli vkládání bit˚u – po 5 stejných úrovních bit˚u (at’ už dominant nebo recessive) je vložen bit opaˇcný. Po pˇrijetí zprávy je nejdˇríve nutné odstanit všechny vložené bity pro správné dekódování zprávy. Metoda bit-stuffingu je znázornˇena na obrázku 2.13.

Obrázek 2.13: Bit-stuffing, zdroj: autor dle [7]


18 2.2.5.2

Bitové cˇ asování a synchronizace

Protokol CAN využívá synchronní pˇrenos, což pˇrináší nejen zvýšení pˇrenosové kapacity, ale také nutnost implementovat spolehlivou bitovou synchronizaci. Pˇri synchronním pˇrenosu je k dispozici pouze jeden start bit na zaˇcátku rámce. Pro správné cˇ tení zprávy jednotlivými pˇrijímaˇci je nutná pr˚ubˇežná synchronizace. Protože sbˇernice CAN je založena na principu arbitráže (viz 2.2.6.2), je nutné aby každý uzel byl schopen vzorkovat ve stejný okamžik. To je ovšem ovlivnˇeno zpoždˇením šíˇrení signálu mezi jednotlivými uzly. Z tohoto d˚uvodu se používá tzv. phase buffer. Situace je zobrazena na obrázku 2.14.

Obrázek 2.14: Segmenty nutné pro synchronizaci, zdroj: autor dle [48] V tabulce 2.4 je pro názornost uvedena závislost mezi dobou pˇrechodu signálu a pˇríslušné maximální bitové rychlosti [17]. Tabulka 2.4: Závislost doby pˇrechodu signálu a maximální bitové rychlosti pˇri délce vedení 100 m Doba pˇrechodu Maximální bitová signálu [ns/m] rychlost [kbit/s] 5,0 80 5,5 73 6,0 67 6,5 62 7,0 58

2.2.5.3

ISO 11898-2 high speed

Tato norma fyzické vrstvy CAN je nejpoužívanˇejší. Sbˇernice je tvoˇrena: • dvˇema kroucenými stínˇenými vodiˇci nebo • dvˇema kroucenými nestínˇenými vodiˇci.


19

Jednotlivé vodiˇce se oznaˇcují CAN_H a CAN_L a úrovnˇe dominant a recessive jsou reprezentovány rozdílovým napˇetím na tˇechto vodiˇcích. Nominální úrovnˇe v normˇe 11898 jsou definovány takto: • Vdi f f = 0V pro recessive bit; • Vdi f f = 2V pro dominant bit. Na koncích obou vodiˇcu˚ jsou umístˇeny terminátory 120 Ω pro snížení množství odraz˚u na vedení. Z tohoto údaje vyplývá také charakteristická impedance celého vedení 120 Ω. Pro zlepšení elektromagnetické kompatibility lze užít následující možnosti zakoncˇ ení vedení pomocí rezistor˚u: • standardní terminátory (viz obr. cˇ . 2.15); • split terminátory (viz obr. cˇ . 2.16); • biased split terminátory (viz obr. cˇ .2.17).

Obrázek 2.15: Standardní terminátor, zdroj: autor dle [48]

Obrázek 2.16: Split terminátor, zdroj: autor dle [48] Dalším parametrem popisovaným fyzickou vrstvou je pˇrenosová rychlost. Jak již bylo rˇeˇceno v úvodu, nejvyšší rychlost sbˇernice je 1 Mbit/s, nejnižší 10 kbit/s. Na rychlosti pˇrenosu závisí maximální možná délka sbˇernice. Rychlosti 1 Mbit/s odpovídá délka 40 m, pro minimální rychlost 10 kbit/s délka 1 km. Délka je ovšem ovlivnˇena typem použitého vodiˇce a proto m˚uže být proto kratší než uvádí norma. Pˇrehled rychlostí a jim odpovídající maximální délka vedení je uvedena v tabulce 2.5. Tento pˇrehled je ovšem


20

Obrázek 2.17: Biased split terminátor, zdroj: autor dle [48] pouze informativního charakteru. Je založen na zkušenostech, norma tuto tabulku nespecifikuje. Tabulka 2.5: Závislost maximální délky sbˇernice na pˇrenosové rychlosti Pˇrenosová rychlost Maximální délka sbˇernice 1 Mbit/s 40 m 500 kbit/s 112 m 300 kbit/s 200 m 100 kbit/s 640 m 50 kbit/s 1 340 m 20 kbit/s 2 600 m 10 kbit/s 5 200 m

2.2.6 2.2.6.1

Linková vrstva Kódování

Následující cˇ ásti rámce jsou kódovány metodou bit-stuffing: • zaˇcátek rámce; • pole arbitráže; • ˇrídící informace; • CRC kód. To znamená, že kdykoliv se po sobˇe vyskytne 5 stejných bit˚u, je vložen bit opaˇcný. Viz obrázek 2.13. Ostatní cˇ ásti datového rámce, rámce chybové zprávy a zprávy o pˇretížení mají fixní podobu a nejsou kódovány metodou bit-stuffing.

2.2. CAN (CONTROLLER AREA NETWORK) 2.2.6.2

21

ˇ Rízení pˇrístupu k médiu a rˇ ešení kolizí

Uzel m˚uže zaˇcít vysílat v okamžiku, kdy je sbˇernice volná. To znamená, že se na sbˇernici vyskytlo 7 a více bit˚u recessive. V pˇrípadˇe, že uzel zaˇcne vysílat dˇríve než ostatní uzly, má sbˇernici „sám pro sebe“. Ostatní uzly mohou zaˇcít vysílat až v okamžiku, kdy je sbˇernice opˇet volná. Jedinou výjimku tvoˇrí chybová zpráva. Tu m˚uže zaˇcít vysílat libovolný uzel v okamžiku, kdy detekuje chybu v pˇrenášené zprávˇe. V pˇrípadˇe, že na sbˇernici zaˇcne vysílat více uzl˚u najednou, platí princip arbitráže (viz obrázek cˇ . 2.18). To znamená, že pˇrístup na sbˇernici získá ten, který má vyšší prioritu (nižší identifikátor). Každý vysílaˇc porovnává hodnotu, která je na sbˇernici, s hodnotou, kterou vysílá. V pˇrípadˇe, že je na sbˇernici úroveˇn dominant, zatímco uzel vysílá úroveˇn recessive, pˇrestane jednotka vysílat - pˇrenechá tak sbˇernici jednotce s vyšší prioritou. Tento pˇrístup na sbˇernici je nedestruktivní - rámec vysílaný „vítˇeznou“ jednotkou je pˇrenesen bez poškození. Podmínkou ovšem je, aby ke sbˇernici nebyly pˇripojeny dvˇe jednotky, jejichž zprávy mají stejný identifikátor - to musí být zajištˇeno protokolem vyšší vrstvy.

Obrázek 2.18: Princip arbitráže, zdroj: autor dle [7]

2.2.7 2.2.7.1

Chyby Typy chyb

Na CAN sbˇernici se m˚uže vyskytnout 5 typ˚u chyb: • chyba bitu; • chyba kódu CRC; • chyba bit-stuffingu;


22 • chyba formy zprávy; • chyba potvrzení pˇrijetí zprávy.

V tabulce 2.6 jsou pˇrehlednˇe uvedeny jednotlivé chyby, jejich význam, typ zprávy, ve kterém je chyba detekována, a jednotka, která chybu detekovala.

Typ chyby chyba bitu

chyba bit-stuffingu

chyba CRC

chyba formátu zprávy

chyba ACK

2.2.7.2

Tabulka 2.6: Typy chyb Význam chyby Tato chyba je detekována, pokud je úroveˇn právˇe vysílaného bitu a úroveˇn bitu na sbˇernici rozdílná, v dobˇe mimo pole arbitráže. Tato chyba je detekována, pokud je za sebou detekována 6x stejná úroveˇn bitu. Tato chyba je detekována,pokud je CRC spoˇcítané z pˇrijaté zprávy jiné, než CRC ve zprávˇe obsažené. Tato chyba je detekována, pokud je na sbˇernici neplatný formát zprávy.

Tato chyba je detekována, pokud je bit ACK detekován jako recessive.

Typ zprávy datová zpráva žádost o data chybová zpráva zpráva o pˇretížení datová zpráva žádost o data

Jednotka vysílací jednotka pˇrijímací jednotka

datová zpráva žádost o data

pˇrijímací jednotka

datová zpráva žádost o data chybová zpráva zpráva o pˇretížení datová zpráva žádost o data

vysílací jednotka pˇrijímací jednotka

vysílací jednotka pˇrijímací jednotka

vysílací jednotka

Signalizace chyb

Aby nedocházelo vlivem jednotky, která vysílá pˇríliš mnoho chyb, k velmi cˇ astému vysílání pˇríznaku chyby, má každá jednotka zabudovaný interní cˇ ítaˇc chyb. Tyto cˇ ítaˇce jsou dva – jeden udává poˇcet chyb pˇri pˇríjmu, druhý pˇri vysílání. Podle stavu cˇ ítaˇcu˚ se pak jednotka m˚uže nacházet v jednom ze 3 stav˚u: • aktivním (error active); • pasivním (error passive); • odpojeném (bus off ). Pokud je uzel aktivní nebo pasivní, podílí se na komunikaci po sbˇernici. Rozdíl je pouze v pˇríznaku, který jednotka vysílá, detekuje-li chybu na sbˇernici. V aktivním stavu vysílá aktivní pˇríznak chyby (Active Error Flag), který je tvoˇren šesti po sobˇe jdoucími bity dominant. Tím se poškodí pˇrenášená zpráva a dojde k porušení pravidla vkládání bit˚u.


23

V pasivním stavu se pak vysílá pasivní pˇríznak chyby (Passive Error Flag), který je složen ze 6 po sobˇe jdoucími bity recessive, což neporuší pˇrenášenou zprávu. V pˇrípadˇe, že uzel pracuje správnˇe, je stav jeho cˇ ítaˇcu˚ s cˇ asem snižován. Po urˇcité dobˇe se m˚uže z pasivního stavu dostat zpˇet do stavu aktivního. V odpojeném stavu jsou výstupní budiˇce uzl˚u odpojeny, nemají na sbˇernici žádný vliv. Z tohoto stavu se uzel m˚uže dostat pouze v pˇrípadˇe, že se na sbˇernici objeví 128x jedenáct po sobˇe jdoucích recessive bit˚u. V tomto pˇrípadˇe budou oba cˇ ítaˇce nastaveny na nulu. Stav cˇ ítaˇcu˚ pro jednotlivé stavy je uveden v tabulce 2.7. Tabulka 2.7: Závislost stavu cˇ ítaˇcu˚ a stavu uzlu Stav jedlotky cˇ ítaˇc chyb vysílaˇce cˇ ítaˇc chyb pˇrijímaˇce Aktivní 0-127 a 0-127 Pasivní 128-255 nebo 127-255 Vypnuto minimálnˇe 256 Grafické znazornˇení vztahu mezi jednotlivými stavy uzlu je znázornˇen na obrázku 2.19.

TEC = Transmit Error Count = cˇ ítaˇc chyb vysílaˇce REC = Receive Error Count = cˇ ítaˇc chyb pˇrijímaˇce Obrázek 2.19: Vztah mezi jednotlivými stavy uzlu, zdroj: autor dle [7]

2.2.7.3

Zpusob ˚ cˇ ítání chyb

• V pˇrípadˇe, že pˇrijímaˇc detekuje chybu, bude o 1 zvýšen cˇ ítaˇc Receive Error Count. Výjimku tvoˇrí pˇrípady, kdy je detekována chyba bitu (bit-stuffingu) v pr˚ubˇehu vysílání aktivního pˇríznaku chyby nebo pˇríznaku pˇretížení (Active Error Flag nebo Overload Flag).


24

• V pˇrípadˇe, že pˇrijímaˇc detekuje dominant bit jako první bit po vyslání pˇríznaku chyby bude cˇ ítaˇc Receive Error Count inkrementován o 8. • Pokud vysílaˇc vyšle pˇríznak chyby, bude cˇ ítaˇc Transmit Error Count navýšen o 8. • Pokud vysílaˇc detekuje chybu bitu bˇehem vysílání aktivního pˇríznaku chyby nebo pˇríznaku pˇretížení, bude cˇ ítaˇc Receive Error Count navýšen o 8. • Pokud pˇrijímaˇc detekuje chybu bitu bˇehem vysílání aktivního pˇríznaku chyby nebo pˇríznaku pˇretížení, bude cˇ ítaˇc Receive Error Count navýšen o 8. • Po vyslání aktivního pˇríznaku chyby nebo pˇríznaku pˇretížení (6 dominant bit˚u) toleruje každý uzel až 7 po sobˇe jdoucích dominant bit˚u, po cˇ trnáctém se již navyšuje o 8 cˇ ítaˇc Transmit Error Count u pˇrijímaˇcu˚ a cˇ ítaˇc Receive Error Count u vysílaˇcu˚ . Po pasivním pˇríznaku chyby (tedy 6 resessive bit˚u) m˚uže následovat také až 7 dominant bit˚u, po osmém však opˇet každý vysílaˇc a pˇrijímaˇc navyšují pˇríslušné cˇ ítaˇce o 8. • Po úspˇešném pˇrenosu zprávy (pˇrišlo potvrzení ACK a nevyskytla se chyba do odvysílání konce rámce) je cˇ ítaˇc Transmit Error Count zmenšen o 1. • Po úspˇešném pˇrijetí zprávy (pˇrijetí bez chyby do slotu ACK a úspˇešném odvysílání ACK bitu) je Receive Error Count zmenšen o 1, pokud byl ve stavu mezi 1-127. Pokud byl tento stav vˇetší nˇež 127, bude nastaven na hodnotu mezi 119 a 127.

2.3

Protokoly vyšších vrstev

Od uvedení CAN sbˇernice vzniklo nˇekolik protokol˚u vyšších vrstev: • CAL/CANOpen; • CANaerospace; • MilCAN; • DeviceNet; • OSEK; • J1939; • CAN Kingdom; • a další.

2.4. PROTOKOL CANAEROSPACE

25

Použití tˇechto aplikaˇcních vrstev je r˚uzné, pro oblast letectví byl vytvoˇren CANaerospace, který je popsán v následující kapitole.

2.4

Protokol CANaerospace

Tato aplikaˇcní vrstva vznikla pro zabezpeˇcenou komunikaci systém˚u založených na mikropoˇcítaˇcích umístˇených na palubˇe letadla. Úˇcelem CANaerospace je vytvoˇrit normy pro aplikace vyžadující rychlý tok dat a jednoduchou synchronizaci redundantních systém˚u. Zároveˇn však ponechává prostor pro definice, které chce implementovat sám uživatel. CANaerospace využívá protokolu CAN 2.0A a 2.0B, což znamená, že identifikátor má bud’ 11 bit˚u nebo 29 bit˚u, viz 2.2.3. Pro CANaerospace lze využít libovolnou pˇrenosovou rychlost, pˇriˇcemž platí závˇery uˇcinˇené v tabulce 2.5.

2.4.1

Typ zpráv

CANaerospace vymezuje 6 základních typ˚u zpráv, které jsou užívány pro r˚uzné služby sítˇe. Každý typ zprávy má rozsah ID, které identifikují prioritu dané zprávy. Jednotlivé typy zpráv, jejich identifikace a významy jsou uvedeny v tabulce 2.8, [52]. Tabulka 2.8: Typy zpráv a jejich priority Typ zprávy Rozsah ID Význam Nouzové zprávy 0-127 Vysílána asychronnˇe kdykoliv se objeví (EED) ($000-$07F) situace vyžadující okamžité odvysílání Servisní data s 128-199 Vysílána asynchronnˇe nebo cyklicky s vysokou prioritou definovaným vysílacím intervalem (NSH) ($080-$0C7) - operaˇcní pˇríkazy Uživatelská data s 200-299 Zpráva/data a vysílací interval je definován vysokou prioritou uživatelsky (UDH) ($0C8-$12B) Normální operaˇcní 300-1799 Vysílána asynchronnˇe nebo cyklicky s data definovaným vysílacím intervalem (NOD) ($12C-$707) pro operaˇcní a status data Uživatelská data s 1800-1899 Zpráva/data a vysílací interval je definován nízkou prioritou uživatelsky (UDL) ($708-$76B) Servisní ladící data 1900-1999 Vysílána asynchronnˇe nebo cyklicky (DSD) ($76C-$7CF) pro ladˇení komunikace a stahování software Servisní data s nízkou 2000-2031 Vysílána asynchronnˇe nebo cyklicky pro prioritou testování a údržbu (NSL) ($7D0-$7EF)


26

2.4.2

Formát zpráv

Pˇrenášená data jsou ve zprávˇe CANaerospace uloženy metodou Big Endian. Všechny zprávy sbˇernice CANaerospace obsahují hlaviˇcku zprávy, která je složena ze 4 byt˚u, a samotných dat, které mají 1 až 4 byt˚u. 2.4.2.1

Všeobecný formát zpráv

Hlaviˇcka zprávy nese informace o identifikaci uzlu, o typu dat, kódu zprávy a servisním kódu. Servisní kód se využívá pˇri posílání normálních operaˇcních dat, uživatel si jej m˚uže sám definovat. Díky hlaviˇcce zpráv lze identifikovat typ dat bez nutnosti zasílat další identifikátory. Všeobecný formát zpráv je na obrázku 2.20.

Obrázek 2.20: Obecný formát zprávy, zdroj: autor dle [52]

2.4.2.2

Formát nouzových zpráv

Data nouzovách událostí (Emergency Event Data, EED) se vysílájí asynchronnˇe kdykoliv se objeví chyba nebo nastane nouzová situace. Nouzová zpráva obsahuje kromˇe nutné hlaviˇcky také informaci o místˇe chyby, o chybné situaci a nese také kód chyby, která se vyskytla. Formát nouzových zpráv je na obrázku 2.21.

Obrázek 2.21: Formát nouzové zprávy, zdroj: autor dle [52]

2.4. PROTOKOL CANAEROSPACE 2.4.2.3

27

Formát zpráv s normálními operaˇcními daty

Nejˇcastˇeji vysílanými zprávami jsou ty, které se vyskytují bˇehem normálního operaˇcního provozu. Tyto zprávy se oznaˇcují zkratkou NOD (Normal Operation Data). Formát zprávy NOD je na obrázku 2.22.

Obrázek 2.22: Formát zprávy NOD, zdroj: autor dle [52]

2.4.2.4

Formát servisních zpráv jednotlivých uzlu˚ sbˇernice

Formát servisních zpráv jednotlivých uzl˚u sbˇernice (Node Service Data, NSH/NSL) obsahuje data potˇrebná pro kontrolu jednotlivých uzl˚u a rˇídí se servisním protokolem. Formát tˇechto zpáv je podobný zprávám NOD, viz obrázek 2.22. Tyto zprávy jsou vysílány pouze poté, co do požadovaného uzlu pˇrijde specifický požadavek. 2.4.2.5

Formát ladících zpráv

Formát ladících zpráv si plnˇe definuje uživatel. Jedinou podmínkou je použítí správného formátu. Formát musí být volen tak, aby se neshodoval s žádným jiným formátem, který je uveden ve standardu CANaerospace. Tato podmínka je nutná pro zachování maximální flexibility. 2.4.2.6

Uživatelem definovaný datový formát

Pro speciální úˇcely mohou být uživatelem vytvoˇreny formáty datových zpráv, s nízkou (Low Priority-User-Defined Data, UDL) nebo vysokou (High Priority-User-Defined Data, UDH) prioritou. Opˇet je jedinou podmínkou použití správného formátu tak, aby se neshodoval s jiným formátem, který je uveden ve standardu CANaerospace.

2.4.3

Servisní protokol uzlu˚ sbˇernice

Servisní protokol slouží pro komunikaci dvou uzl˚u pro specifické operace, napˇr. pro stahování dat. Typicky se jedná o soubor akcí požadavek-odpovˇed’. Servisní protokol m˚uže mít jak vysokou tak nízkou prioritu. Pˇríklady servisní zprávy s vysokou prioritou jsou uvedeny v tabulce 2.9, s nízkou prioritou v tabulce 2.10, [52]. Pro data s vysokou prioritou je urˇceno 36 kanál˚u, pro nízkou prioritu 16 kanál˚u.


28

Tabulka 2.9: Servisní zprávy s vysokou prioritou Servisní kanál ID požadavku ID odpovˇedi 0 128 ($080) 129 ($081) 1 130 ($082) 131 ($083) 2 132 ($084) 133 ($085) .... .... .... .... .... .... 33 194 ($0C2) 195 ($0C3) 34 196 ($0C4) 197 ($0C5) 35 198 ($0C6) 199 ($0C7) Tabulka 2.10: Servisní zprávy s nízkou prioritou Servisní kanál ID požadavku ID odpovˇedi 100 2000 ($7D0) 2001 ($7D1) 101 2002 ($7D2) 2003 ($7D3) 102 2004 ($7DS4) 2005 ($7D5) .... .... .... .... .... .... 115 2030 ($7EE) 2031 ($7EF) Komunikace probíhá tak, že servisní uzel vyšle požadavek s odpovídajícím ID. Všechny uzly monitorují sbˇernici a kontrolují, zda ID pˇrijaté zprávy obsahuje ID daného uzlu. Pokud ano, daný uzel provede požadavek a vyšle servisnímu uzlu odpovˇed’. Každý uzel sítˇe m˚uže zaˇcít jako servisní uzel. Aby nedošlo ke kolizi, je doporuˇceno, aby každý uzel sbˇernice zaˇcal s vysíláním jako servisní uzel na jemu vyhrazeném kanálu. Standard definuje nˇekolik nejužívanˇejších servisních akcí, které jsou podrobnˇe popsány v [52].

2.4.4

Identifikátory

Standard CANaerospace definuje nˇekteré identifikátory. Ty slouží pro snadné a rychlé pˇripojení nových uzl˚u na sbˇernici. Snadno lze pˇripojit zaˇrízení r˚uzných výrobc˚u. Pokud je dodržován standard, nem˚uže se stát, že jeden výrobce oznaˇcí napˇríklad teplotu výstupních plyn˚u stejnˇe jako jiný výrobce tlak paliva. Normální operaˇcní data mají rozsah 300-1499 a v tomto rozsahu jsou definovaná základní data vyskytující se na letadle. Seznam pevnˇe stanovených identifikátor˚u je uveden v [52], v tabulce 5.2 jsou uvedeny ID parametr˚u potˇrebných na letounu projektu DaMMaE.

Kapitola 3

Pˇrenos údaju˚ mezi letadlem a pozemní stanicí 3.1

Možnosti komunikace

Pro komunikaci s bezpilotním prostˇredkem, který má mít možnost volného pohybu (nebude se zemí „svázán“ ovládacím kabelem), je jedinou možností bezdrátová technologie. Mezi základní bezdrátové technologie se ˇradí: • komunikaˇcní infraˇcervený port IrDa (Infrared Data Association); • standard IEEE 802.15.1 (Bluetooth); • standard IEEE 802.15.4 (ZigBee); • radiomodemy; • GSM/GPRS; • standard IEEE 802.11 (Wi-Fi); • Wi-Max; • a další. První tˇri technologie nemají dostateˇcný dosah a pˇrenosovou rychlost (viz tabulka 3.1) a v této práci jim nebude vˇenována pozornost. 29

ˇ KAPITOLA 3. PRENOS ÚDAJU˚ MEZI LETADLEM A POZEMNÍ STANICÍ

30

Tabulka 3.1: Bezdrátové technologie IrDa, Bluetooth a ZigBee a jejich dosahy Technologie Dosah Pˇrenosová rychlost IrDa až 5 m 115.2 kb/s (verze 1.1 až 4 Mb/s) Bluetooth až 100 m až 2.1 Mb/s ZigBee až 100 m 250 kb/s

3.1.1

Radiomodemy

Na trhu je nepˇreberné množství radiomodem˚u využívajících nejr˚uznˇejší technologie. Popsat tyto technologie je nad rámec této práce, proto se dále zamˇerˇí pouze na technologii DECT, která je autorce dostupná. Bˇežnˇe dostupné radiové modemy jsou pro využití na bezpilotním prostˇredku nevhodné z d˚uvod˚u vˇetších rozmˇer˚u (145x88x46 mm modelu 8612 firmy Höft & Wessel [2] oproti 53x37x3.2 mm radiového modulu model 86012 téže firmy [9]), z tohoto d˚uvodu se tato práce soustˇredí pouze na radiové moduly. 3.1.1.1

Technologie DECT

(Digital Enhanced Cordless Telecommunications, p˚uvodnˇe Digital European Cordless Telecommunications) Základní parametry technologie DECT jsou uvedeny v tabulce 3.2 [47]. Tabulka 3.2: Základní parametry technologie DECT Parametr Hodnota Frekvence 1880 -1900 MHz Pˇrístup MC/TDMA/TDD Rozestup nosných 1728 kHz Doba trvání rámce 10 ms Modulace GFSK s BT=0.5 Pˇrenosová rychlost rámce 1.152 Mbit/s DECT se skládá ze základové a mobilní stanice. Typický dosah je 300 m ve volném prostoru (bˇežnˇe 450 m). Technologie DECT pracuje na principu více nosných s vícenásobným pˇrístupem a cˇ asovým dˇelením – MC/TDMA/TDD (Multi-Carrier/Time Division Multiple Access/Time Division Duplex). Obousmˇerný provoz je zajištˇen cˇ asovým dˇelením kanál˚u. [55] DECT je v Evropˇe alokován ve frekvenˇcním pásmu 1880-1900 MHz. Mimo Evropu se využívá frekvenˇcních pásem 1900-1920, 1910-1930 a 2010-2025 MHz. Nejednotnost tˇechto pásem nezp˚usobuje problémy pˇri pˇrenositelnosti zaˇrízení, protože používané pásmo urˇcuje základová stanice pomocí všesmˇerového vysílání a mobilní stanice se této

3.1. MOŽNOSTI KOMUNIKACE

31

frekvenci pˇrizp˚usobí. DECT využívá modulaci GFSK (Gaussian Frequency Shift Keying, viz [54]). Pro evropské pásmo 1880-1900 MHz je urˇceno 10 nosných s odstupem 1728 kHz (Multi-Carrier). Na každé nosné se vysílá TDMA (Time Division Multiply Access) rámec o délce 10 ms. Skládá se z 24 kanálových slot˚u – 12 pro downlink (tedy od základnové stanice k mobilní) a 12 pro uplink (od mobilní k základové stanici). DECT využívá dynamické pˇridˇelování kanál˚u. Pro každé spojení je vybrán kanál, který je v danou chvíli nejménˇe zarušen. Každých 30 sekund se pˇridˇelené frekvence skenují a získávají se informace o volných a obsazených kanálech. Vzniká tak seznam volných a obsazených kanál˚u – RSSI seznam (Received Signal Strength Indication). Základové stanice systému DECT neustále vysílají informace o identifikaci stanice, o kapacitˇe systému, o svém statusu a informace nutné pro založení vzájemné komunikace. Mobilní jednotka analyzuje toto všesmˇerové vysílání a kontroluje, zda má pˇrístupová práva k založení komunikaˇcní linky. Tyto dva mechanismy zajišt’ují, že se použije nejlepší možné spojení mezi mobilní a základovou stanicí. Zároveˇn to zabraˇnuje interferenci s vysíláním jiné mobilní jednotky. Z uvedeného plyne, že komunikaci zahajuje na základˇe získaných informací mobilní stanice. DECT podporuje handover – to znamená, že v pr˚ubˇehu pˇrenosu dat se m˚uže zmˇenit kanál cˇ i dokonce základová stanice. V pr˚ubˇehu pˇredávání pˇrenosu z jednoho kanálu do druhého je pˇrenos veden paralelnˇe obˇema kanály. Pˇrenos v novém kanálu je analyzován a pokud má odpovídající kvalitu, je pˇrenos v p˚uvodním kanálu ukonˇcen. Autentizace se provádí pˇri každém založení komunikaˇcního kanálu. Základová stanice vygeneruje náhodné cˇ íslo a pošle ho mobilní stanici. Mobilní stanice pomocí definovaného algoritmu vypoˇcítá odpovˇed’ ze svého klíˇce a pˇrijatého náhodného cˇ ísla. Takto vypoˇctenou odpovˇed’ odešle základové stanici. Ta zkontroluje, zda vypoˇctená odpovˇed’ mobilní stanice odpovídá oˇcekávané odpovˇedi. Pro provedení porovnání musí mít k dispozici ve své databázi klíˇc dané mobilní stanice. 3.1.1.2

Modul HW 86012

Radiový modul HW 86012 vyrábí firma Höft & Wessel. Modul využívá díky DECT technologii bezlicenˇcní pásmo 1880-1900 MHz. Protože v tomto pásmu zatím není provozována žádná jiná technologie, není nutné rˇešit problematiku interference s jinými systémy. Základním jádrem tohoto radiového modulu je 16 bitový RISC mikroprocesor a integrované DECT obvody. Architektura radiového modulu HW 86012 (viz obr. 3.1) nabízí celou rˇadu rozhraní pro podporu pˇrenosu dat a hlasu v r˚uzných prostˇredích:


32

• RS 232; • SPI; • I 2C; • μC sbˇernice; • GPIO; • mikrofon/speaker; • PCM. Další pˇredností tohoto radiového modulu je možnost pˇripojit dvˇe antény, což umožˇnuje zlepšit radiový výkon v r˚uzných prostˇredích.

Obrázek 3.1: Schéma rádiového modulu HW 86012, zdroj: autor dle [9]

Dosah

Dosah je v pˇrípadˇe bezdrátového systému závislý na napájení vysílaˇce, citli-

vosti pˇríjímaˇce a zisku antény. Významným faktorem je také tlumení signálu v prostˇredí. Nejmenší je v otevˇreném prostoru. Typický dosah radiového modulu HW 86012 je: • až 60 m uvnitˇr budov; • až 300 m v prostˇredí s pˇrekážkami; • 1000 a více metr˚u v prostˇredí s ideálními podmínkami (pˇrímý dohled, cˇ istá Fresnelova zóna - viz obr. 3.2).


33

Obrázek 3.2: Demonstrace Fresnelovy zóny, zdroj: autor Anténa

Ve standardní konfiguraci je modul HW 86012 vybaven jednou anténou. Pro

dosažení všesmˇerové charakteristiky v horizontální rovinˇe je vhodné tuto anténu umístit do vertikální pozice. V blízkém okolí antény by nemˇely být umístˇeny kovové cˇ ásti, vedení, tištˇené spoje nebo elektrické souˇcástky, které výraznˇe snižují výkon antény. Pokud je požadován maximální výkon a není možné umístit tento modul s anténou do rozumné pozice, je vhodné využít oddˇelenou anténu a pˇripojit ji pomocí koaxiálního kabelu. Použití dvou antén výraznˇe snižuje vliv prostˇredí na vícecestné šíˇrení signálu. Tyto antény by od sebe mˇely být umístˇeny nejménˇe 12 cm daleko. Vˇetšinou mají tyto antény shodnou všesmˇerovou charakteristiku a využívají stejnou polarizaci. V pr˚ubˇehu pˇríjmu signálu z obou antén mˇerˇí modul sílu signálu a poté pro vysílání aktivuje anténu se silnˇejším signálem. Pˇri výbˇeru vhodné antény je potˇreba dbát na to, aby vyzaˇrovaný výkon nepˇrekraˇcoval dané pˇredpisy.

3.1.2

GSM spojení

Mobilní sít’ GSM (Global System for Mobile Communications) se skládá z úˇcastnického zaˇrízení a základové stanice (Base Transceiver Station, BTS). Ty jsou propojeny do subsystém˚u základových stanic (Base Station Subsystem, BSS) a ovládány rˇídící jednotkou (Base Station Controller, BSC). Registraci úˇcastník˚u, spojování hovor˚u a další služby má na starosti sít’ový subsystém (Network Subsystem, NSS), který je nadˇrazený subsystému základových stanic. Mobilní stanice mohou komunikovat se základovou stanici na 3 frekvenˇcních pásmech: • 900 MHz; • 1800 MHz; • 1900 MHz. ˇ V Ceské republice se využívají pásma 900 a 1800 MHz.


34

Frekvenˇcní pásmo 900 MHz je rozdˇeleno takto: • 890.2 až 915 MHz uplink (od mobilní stanice k základové stanici); • 935,2 až 960 MHz downlink (od základové stanice k mobilní stanici). Frekvenˇcní pásmo 1800 MHz je rozdˇeleno takto: • 1710 až 1785 MHz uplink; • 1805 až 1880 MHz downlink. Více o spojení GSM v [40]. Tento zp˚usob komunikace nebude v projektu DaMMaE použit vzhledem k možnosti ztráty signálu v ménˇe pokrytých oblastech a vyšší poˇrizovací cenˇe GSM modul˚u (cca 3000 Kˇc a výše) oproti jiným rˇešením.

3.1.3

Mobilní vysokorychlostní spojení

Mobilní vysokorychlostí spojení (3G sítˇe) je pro využití na bezpilotním prostˇredku neˇ vhodné, nebot’ pokrytí tímto spojením nabízí mobilní operátoˇri v Ceské republice pouze ve vˇetších mˇestech. Provozování letounu by bylo znaˇcnˇe omezeno. O 3G sítích pojednává napˇr. [30].

3.1.4

Standard 802.11

Standard 802.11 je vyvíjen a schvalován institutem IEEE (Institute of Eletrical and Electronics Engineers), oznaˇcení 802 znamená, že jde o sít’ové normy a 11, že jde o normy bezdrátových sítí. Náhradou za termín 802.11 se stalo oznaˇcení Wi-fi. První bezdrátová norma byla oznaˇcena jednoduše IEEE 802.11 a byla pˇrijata v roce 1997, pracovala v pásmu 2.4 GHz s pˇrenosovou rychlostí 2 Mbit/s. Další standardy pak vznikaly zlepšováním vlastností této p˚uvodní normy. Dnes tak existuje nˇekolik variant, nejznámˇejší uvádí tabulka 3.3. [29]

Standard IEEE 802.11a 802.11b 802.11g 802.11n

Tabulka 3.3: Standardy IEE 802.11 Frekvence Max. pˇrenosová Typická pˇrenosová rychlost rychlost 5 GHz 54 Mb/s 23 Mb/s 2.4 GHz 11 Mb/s 4.3 Mb/s 2.4 GHz 54 Mb/s 19 Mb/s 2.4/5 GHz 270 Mb/s 74 Mb/s

Fyzická vrstva OFMD DSSS OFMD MIMO


35

Zabezpeˇcení fyzické vrstvy se provádí pomocí rozprostˇreného spektra, které znaˇcnˇe snižuje možnost rušení nebo odposlechu pˇrenášených dat. Ve standardu 802.11 se dle tabulky 3.3 využívají tyto typy rozprostˇreného spektra: • ortogonální frekvenˇcní multiplex (Orthogonal Frequency Division Multiplexing, OFMD) Data jsou pˇrenášena pˇres více podkanál˚u paralelnˇe (ortogonálnˇe), tedy na r˚uzných frekvencích, není vytvoˇren jeden velký datový kanál, ale nˇekolik. OFDM na každém podkanálu pˇrenáší pouze malý objem informací, nezatížený jinými úlohami. Maximální pˇrenosová rychlost v tomto rozprostˇreném spektru je 54 Mbit/s. • rozprostˇrené spektrum v pˇrímé posloupnosti (Direct Sequence Spread Spectrum, DSSS) DSSS rozprostírá pˇrenosy pˇres nˇekolik kanál˚u v urˇcitém daném frekvenˇcním rozsahu, data však nejsou vysílaná paralelnˇe, ale na každém kanálu redundantnˇe. Díky tomu se zvyšuje pravdˇepodobnost, že data dorazí k pˇrijímaˇci nedotˇcená. Dané kanály jsou vybírány pomocí binárního rˇetˇezce nazývaného kód rozprostˇrení, pˇrijímaˇc musí používat stejný kód rozprostˇrení jako vysílaˇc. DSSS vyžaduje pásmo o šíˇrce 22 MHz. Šíˇrka bezlicenˇcního pásma 2.4 GHz je 83.5 MHz - maximálnˇe tˇri nezávislé DSSS systémy souˇcasnˇe. Více o rozprostˇrených spektrech napˇr. v [39]. Nejnovˇejším standardem je 802.11n, který využívá technologie MIMO (Multipleinput multiple-output). Datový tok se rozdˇelí na více tok˚u a pak se odesílá pˇres dvˇe nebo více antén. Tato technologie je založena na vícecestném šíˇrení toku dat (na odrazech od pˇrekážek), což vede ke zvýšení propustnosti a dosahu a ke snížení poˇctu pˇrenosových bitových chyb. Dosah a pokrytí standardem 802.11 urˇcuje hlavnˇe druh antény. Antény mají tyto základní charakteristiky, které urˇcují jaký dosah a jakou kvalitou signálu anténa má: • šíˇrka frekvenˇcního pásma; • zisk (urˇcuje stupeˇn smˇerovosti); • odstup signálu od šumu (síla radiového signálu vzhledem k šumu); • vyzaˇrovací diagram; • úhel vyzaˇrování; • polarizace (horizontální, vertikální).


36

Další vliv na dosah a pokrytí mají také konektory a kabely, kterými je anténa pˇripojena k pˇrístupovému bodu. Více o výbˇeru antén napˇr. v [29].

3.1.5

VKV spojení

Pˇrenos na velmi krátkýh vlnách (VKV) se realizuje na frekvencích 30 až 300 MHz. Je urˇcen na krátké vzdálenosti a na pˇrímou viditelnost mezi objekty. V tomto pásmu se již objevuje vícecestné šíˇrení signálu, m˚uže tedy vznikat interference mezi odraženým a vyslaným signálem. D˚usledkem je kolísání intenzity signál˚u. Pro odstranˇení tˇechto interferencí se využívají modulace, nejˇcastˇeji úhlové. Z hlediska navrhnutého bezpilotního prostˇredku DaMMaE je využití VKV spojení sice dostaˇcující, ale uživatel musí mít v tomto pásmu licenci. Z tohoto d˚uvodu byl tento zp˚usob spojení mezi letounem a pozemním stanovištˇem zavrhnut.

3.2

Výbˇer druhu komunikace

Pˇri návrhu spojení mezi letadlem a pozemním stanovištˇem je potˇreba pˇrihlížet k tomu, že pˇrenosový systém má mít na palubˇe letounu co nejmenší hmotnost, rozmˇery a také spotˇrebu energie (to platí zejména pro malé bezpilotní letouny). Pˇrenášený signál bývá navíc ovlivˇnován interferencemi z jiných komunikaˇcních zaˇrízení (v dnešní dobˇe lze jen stˇeží nalézt místo, kde se nevyskytuje žádné rušení). Šíˇrka pˇrenášeného pásma je navíc pro praktické použití omezená nejr˚uznˇejšími pˇredpisy a regulacemi. Pozemní vyhodnocovací zaˇrízení musí být snadno pˇrenosné a pˇritom pro bˇežnou praxi také odolné proti vliv˚um prostˇredí. Pro komunikaci mezi bezpilotním prostˇredkem a pozemní stanicí byl zvolen standard 802.11. Vhodnost použití tohoto standardu byla ovˇerˇena mˇeˇrením síly signálu v závislosti na vzdálenosti mezi dvˇema body v reálném prostˇredí. Popis mˇeˇrení a jeho závˇery jsou uvedeny v následující kapitole 3.2.1.

3.2.1

Odmˇerˇ ení vlastností standardu 802.11

Pˇri realizaci tohoto mˇeˇrení byl využit standard 802.11b/g pracující s frekvecí 2400 MHz, nebot’ standard 802.11a pracující na frekvenci 5000 MHz má menší dosah. Standard 802.11n zatím není pˇríliš rozšíˇren a oproti standardu 802.11b/g nepˇrínáší pro dané využití nic navíc, protože vˇetší pˇrenosová rychlost nemá v tuto chvíli opodstatnˇení (v pˇrípadˇe potˇreby lze na tento standard snadno pˇrejít výmˇenou hardware). Cílem tohoto mˇeˇrení bylo ovˇeˇrení reálného dosahu standardu 802.11b/g pˇri použití bˇežného klienta. V tomto pˇrípadˇe byl využit klasický notebook (HP EliteBook 6930p),

ˇ DRUHU KOMUNIKACE 3.2. VÝBER

37

nebot’ na palubˇe bezpilotního prostˇredku bude umístˇena anténa s velmi podobnými parametry. 3.2.1.1

Hardware použitý pˇri mˇerˇ ení

Pˇri mˇeˇrení byl použit pˇrístupový bod (Access Point) Cisco AIR-1200G (specifikace viz [8]) a anténa Cisco ANT-2506. Anténa Cisco ANT-2506 [13, 15] Použitá anténa Cisco ANT-2506 je všesmˇerová anténa s vyzaˇrovací charakteristikou dle obrázku 3.3. Základní parametry této antény jsou uvedeny v tabulce 3.4.

Obrázek 3.3: Vyzaˇrovací charakteristika antény Cisco ANT-2506, zdroj: autor dle [15]

Tabulka 3.4: Základní parametry antény Cisco ANT-2506 Parametr Hodnota Zisk 5.2 dBi Dosah pro pˇrenosovou rychlost 2 Mbit/s 5.31 km Dosah pro pˇrenosovou rychlost 11 Mbit/s 2.66 km Dosah pro pˇrenosovou rychlost 54 Mbit/s 0.34 km Délka kabelu 0.91 m Váha 0.14 kg Pracovní teplota -30◦ až +70◦ C

3.2.1.2

Postup mˇerˇ ení

Mˇeˇrení probíhalo v blízkém prostˇredí Prahy u vesnice Zápy. Toto místo bylo vybráno z d˚uvodu relativnˇe rovného povrchu, který byl potˇreba pro urˇcení reálného dosahu. Vˇetší


38

pˇrekážky by ovlivˇnovaly dosah signálu, který by poté neodpovídal dosahu v prostˇredí mezi bezpilotním prostˇredkem a pozemní stanicí, ve kterém se pˇrekážky nebudou vyskytovat. Pro pˇresné urˇcení vzdáleností se odeˇcítaly souˇradnice pomocí systému GPS. Takto urˇcené souˇradnice byly poté vyneseny do mapy Google Earth a pomocí nástroje Pravítko byla odmˇerˇena vzájemná vzdálenost míst. Napájení pˇrístupového bodu bylo zajištˇeno elektrickou sítí vozidla. Umístˇení pˇrístupového bodu a antény pˇri mˇerˇení je zobrazeno na obrázku 3.4.

Obrázek 3.4: Umístˇení pˇrístupového bodu a antény, zdroj: autor

3.2.1.3

Namˇerˇ ená data

Pr˚ubˇeh síly signálu pˇri klesající vzdálenosti od pˇrístupového bodu je zobrazen na obrázku 3.5. Síla signálu roste takˇrka lineárnˇe s klesající vzdáleností. Pokles kvality signálu viditelný zhruba uprostˇred obrázku 3.5 je zp˚usoben nerovností terénu. Tato nerovnost ovšem nebude mít v aplikaci na letounu žádný vliv, závislost síly signálu na vzdálenosti by byla takˇrka lineární. V levé cˇ ásti obrázku 3.5 je vidˇet seznam SSID (Service Set Identifier) sítí v mˇeˇreném prostˇredí. Je tedy patrné, že mˇeˇrené prostˇredí bylo znaˇcnˇe zarušené a mˇeˇrení nebylo „ideální“. Uvedená skuteˇcnost ovšem odpovídá prostˇredí, ve kterém bude uživatel bˇežnˇe pracovat, mˇerˇení je tedy pˇrínosné. Na obrázku 3.6 je zobrazena vzdálenost 429.64 m, pro kterou byla pˇrenosová rychlost rovna 5.5 Mbit/s. Síla tohoto signálu se po dobu 2 minut mˇenila dle obrázku 3.7, na kterém je vidˇet, že síla signálu kolísala kolem -81 dBm. Maximální dosah pro spolehlivou konektivitu je zobrazen na obrázku 3.8. Pomocí nástroje Pravítko programu Google Earth byla zmˇerˇena tato maximální vzdálenost na 750 m. Ve vˇetší vzdálenosti již zaˇcala vypadávat konektivita. To mohlo být zp˚usobeno


39

Obrázek 3.5: Síla signálu s klesající vzdáleností od pˇrístupového bodu, zdroj: autor nejen vzdáleností, ale také nerovností terénu. Je tˇreba zd˚uraznit, že kružnice o polomˇeru 750 m je pro danou aplikaci více než dostaˇcující, nebot’ provoz bezpilotního prostˇredku není plánován mimo dohled uživatele a jak je patrno z obrázku 3.9, již onˇech 750 m hraniˇcí s dohledností. Pˇrenosová rychlost ve vzdálenosti 750 m byla 1 Mbit/s, tato rychlost je pro pˇrenos základních dat více než dostaˇcující. Na obrázku 3.10 je vidˇet kolísání signálu kolem hodnoty -87 dBm. 3.2.1.4

Shrnutí mˇerˇ ení

Z výše uvedeného lze uˇcinit závˇer, že pro plánované využití bezpilotního prostˇredku DaMMaE je použití standardu 802.11 jako komunikaˇcního kanálu mezi letounem a pozemním stanovištˇem dostaˇcující. Reálný dosah 750 m vyhovuje a lze pˇredpokládat, že v ménˇe zarušeném prostˇredí jej lze ještˇe zvýšit. Dle plánovaného Doplˇnku X k leteckému pˇredpisu L2 však bude maximální povolená vzdálenost mezi uživatelem a prostˇredkem 700 m, viz 1.3. Standard 802.11 je tedy plnˇe vyhovující.

40


Obrázek 3.6: Dosah standardu 802.11b/g pro pˇrenosovou rychlost 5.5 Mbit/s, zdroj: autor

Obrázek 3.7: Síla signálu ve vzdálenosti 430 m po dobu cca 2 minut, zdroj: autor


Obrázek 3.8: Maximální dosah standardu 802.11b/g, zdroj: autor

Obrázek 3.9: Osoba mˇeˇrící sílu signálu ve vzdálenosti 750 m, zdroj: autor

41

42


Obrázek 3.10: Kolísání síly signálu ve vzdálenosti 750 m, zdroj: autor

Kapitola 4

Systém ADS-B 4.1

Úvod

ADS (Automatic Dependent Surveillance) - automatické závislé sledování. ADS je systém umožˇnující pˇrenos dat z paluby letadla ostatním uživatel˚um vzdušného prostoru (dalším letadl˚um, rˇídícím letového provozu) protˇrednictvím datového spoje. Jsou vyvinuty tˇri typy ADS: • ADS - B (Automatic Dependent Surveillance - Broadcast); • ADS - C (Automatic Dependent Surveillance - Contract); • ADS - R (Automatic Dependent Surveillance - Rebroadcast).

4.1.1

ADS - C (Automatic Dependent Surveillance - Contract)

Tento typ se nˇekdy ozvaˇcuje tako jako ADS - A (Automatic Dependent Surveillance Addressed). Jde o komunikaci typu point-to-point, tedy mezi dvˇema uživateli. Pˇrenos probíhá na základˇe pˇredem stanoveného schématu. Tento pˇrenos, neboli kontrakt, m˚uže být zahájen pouze pozemním systémem s výjimkou stavu nouze. Pˇredem pˇripravené schéma stanovuje podmínky, pˇri kterých bude pˇrenos zahájen, obsah pˇrenosu a frekvenci, na které se bude vysílat. Tento systém se v souˇcasnosti již dále nevyvíjí z d˚uvodu neperspektivy.

4.1.2

ADS - B (Automatic Dependent Surveillance - Broadcast)

Federální úˇrad pro letectví (Federal Aviation Authority, FAA) založil v roce 2005 program pro sledování letadel a všesmˇerové vysílání jejich polohy. Díky tomuto programu se dá pˇredpokládat, že se v budoucnu zmˇení pˇrístup k rˇízení letového provozu. Ten je v 43

KAPITOLA 4. SYSTÉM ADS-B

44

dnešní dobˇe zcela závislý na radarové kontrole vzdušného provozu, v budoucnu se bude sledování vzdušného prostoru provádˇet s využitím globálního satelitního systému. Právˇe globální satelitní systém je využíván systémem ADS-B. Název Automatic Dependent Surveillance - Broadcast je do cˇ eštiny pˇrekládán jako Automatické závislé sledování - všesmˇerové vysílání. Informace jsou vysílány automaticky plošnˇe všem uživatel˚um ADS-B v dosahu. Význam jednotlivých cˇ ástí názvu je uveden v tabulce 4.1.

písmeno zkratky A

D

S

B

Tabulka 4.1: Systém ADS-B a jeho význam význam význam pro systém zkratky je vždy zapnut, dochází k automatickému Automatic vysílání a nevyžaduje zásah operátora (ˇridícího letového provozu nebo pilota) funkce závisí na systémech umístˇených na palubˇe letadla Dependent (pohoha m˚uže být získávána napˇr. ze systému GNSS - závisí tedy na pˇresném a silném signálu GNSS) poskytuje služby sledování jako radar Surveillance (urˇcení polohy letadla, vozidla cˇ i jiného prostˇredku, který chceme sledovat) kontinuálnˇe vysílá data o poloze letadla a další data Broadcast k jiným letadl˚um nebo pozemnímu stanovišti vybavenému systémem pˇrijímaˇce ADS-B

Systém ADS-B byl vyvinut, aby pomohl modernizovat ˇrízení letového provozu. V nynˇejší dobˇe je základní technologií pro zlepšení program˚u Next Generation Air Transportation System (NextGen, viz napˇr. [22]) a Single European Sky Air Traffic Management Research Programme (SESAR, viz napˇr. [23]). Oba tyto programy vznikly, aby rˇízení letového provozu bylo schopno odbavit vˇetší množství letadel. Jsou založeny na nahrazení radarových systém˚u systémy satelitními. Dalším popudem k vytvoˇrení takovéto technologie byl rozvoj oblastí, ve kterých nebylo pokrytí konvenˇcním radarem dostupné (Hudsn˚uv záliv, Austrálie). Systém ADS-B je technologie, která poskytuje pilot˚um a ˇrídícím letového provozu schopnost „vidˇet“ letecký provoz s vˇetší pˇresností. Pˇri využití systému ADS-B mohou piloti létat bezpeˇcnˇeji a v menších rozestupech, pˇriˇcemž není potˇreba cˇ asté asistence ˇrídícího letového provozu, protože piloti vidí pˇrehlednˇe veškerý provoz v okolí. Díky ADS-B systému lze zajistit zvýšení bezpeˇcnosti leteckého provozu a také lepší využití letového prostoru. Narozdíl od klasického radaru, pracuje ADS-B také v malých výškách a na zemském povrchu. Toho je s úspˇechem využíváno pro monitorování provozu na pojíždˇecích

4.1. ÚVOD

45

a vzletových a pˇristávacích drahách na letišti. Jeho užití je možné i v oblastech, které nejsou vybaveny radary, nebo kde je použití radar˚u omezené - napˇr. v horách cˇ i v oblastech vzdálených od frekventovaných letadlových cest. Systém ADS-B je schopen zpˇrístupnit pilotovi dále služby pˇredpovˇedi poˇcasí, mapy terénu a letové informaˇcní služby. 4.1.2.1

Základní definice ADS-B

ADS-B je funkce cˇ i schopnost letadla nebo pozemního dopravního prostˇredku vysílat pˇres digitální datový spoj do okolního prostoru sv˚uj stavový vektor a ostatní d˚uležité informace. ADS-B má 3 základní souˇcasti: • GPS (Global Positioning System); • pozemní radiostanice; • ADS-B avionika na palubˇe letadla. ADS-B se v nynˇejší dobˇe dˇelí na dvˇe podˇcásti: • ADS-B OUT - odchozí rozhlasové vysílání automatického závislého pˇrehledu; • ADS-B IN - pˇríchozí rozhlasové vysílání automatického závislého pˇrehledu. Toto dˇelení se zavedlo z d˚uvodu postupné integrace, testování a zavedení systému. 4.1.2.2

ADS-B OUT

Definice Odchozí rozhlasové vysílání automatického závislého pˇrehledu (ADS-B OUT Automatic Dependent surveillance - Broadcast OUT) je funkce letadla cˇ i mobilního prostˇredku, který pravidelnˇe rozhlasovˇe vysílá sv˚uj stavový vektor (polohu a rychlost) a další informace získané z palubních systém˚u ve formátu vhodném pro pˇrijímaˇce ADS-B IN. [24] V nynˇejší dobˇe se nejvíce testuje a zkouší právˇe tato cˇ ást systému. Jedná se o komunikaci systému s pozemním stanovištˇem. Situace je pˇrehlednˇe znázornˇena na obrázku 4.1. Jde vlastnˇe o pˇrenos informací na pozemní stanovištˇe a dále k rˇízení letového provozu. V této cˇ ásti zkoušení nemusí být na palubˇe instalován pˇríjímaˇc systému ADS-B ani žádný displej pro zobrazení informací ze systému ADS-B.


46

Obrázek 4.1: ADS-B OUT, zdroj: autor 4.1.2.3

ADS-B IN

Definice Pˇríchozí rozhlasové vysílání automatického závislého pˇrehledu (ADS-B IN Automatic Dependent Surveillance - Broadcast IN) je funkce, která pˇrijímá pˇrehledová data z ADS-B OUT datových zdroj˚u. [24] ADS-B IN je dalším krokem ke schválení celého systému ADS-B. Jedná se již o implementaci pˇrijímaˇcu˚ systému ADS-B na paluby letadel, zahrnutí displeje pro zobrazení provozu a postupné rozšíˇrování komunikace mezi jednotlivými úˇcastníky leteckého provozu. Situace je zobrazena na obrázku 4.2.

Obrázek 4.2: ADS-B IN, zdroj: autor Schválení ADS-B se pˇredpokládá za mnohonásobnˇe delší dobu z d˚uvodu nutnosti zahrnout do procesu schvalování lidského cˇ initele, který bude mít na palubˇe letadla vždy vˇetší rozhodovací pravomoci než sebedokonalejší systém. Nicménˇe již probíhá testování také této cˇ ásti systému ADS-B a to mimo jiné z d˚uvodu schválení palubního protisráž-

4.2. VÝHODY SYSTÉMU ADS-B

47

kového systému TCAS. Právˇe z poznatk˚u systému TCAS bude vycházet ADS-B IN. Pˇredpokládá se také využití stejného displeje. Narozdíl od systému TCAS se však u systému ADS-B pˇredpokládá daleko vˇetší dosah „vidˇení”, zobrazení vektoru rychlosti, stoupání/klesání cíl˚u a jejich identifikace. Na palubˇe by tak mˇely být zobrazovány stejné informace, které se v dnešní dobˇe zobrazují pouze rˇídícím letového provozu. 4.1.2.4

Rozdˇelení prostoru ADS-B

Systém ADS-B se dle prostoru, ve které se využívá, dˇelí na: • ADS-B RAD - systém ADS-B v oblasti kryté konvenˇcními radary; • ADS-B NRA - systém ADS-B v oblasti nekryté konvenˇcními radary; • ADS-B APP - systém ADS-B na zemi.

4.1.3

ADS - R (Automatic Dependent Sureveillance - Rebroadcast)

Systém ADS-R je založen na tom, že pozemní stanice pˇreposílá informace získané ze systému ADS-B jinému systému ADS-B, který využívá odlišnou datovou linku. Díky ADS-R tak mohou spolupracovat všechny systémy ADS-B v prostoru, ve kterém jsou v provozu r˚uzné datové linky systému ADS-B. O datových linkách viz 4.4.

4.2

Výhody systému ADS-B

Mezi výhody systému ADS-B ˇradíme: • spolehlivá a pˇresná data o leteckém provozu v reálném cˇ ase, jak pilot˚um tak ˇrídícím letového provozu; • menší rozestup kmitoˇctových kanál˚u; • data mají vyšší informaˇcní obsah nˇež data pˇrenášená pomocí radar˚u v módech A/C/S; • lepší schopnost pˇredvídat cˇ as pˇríletu; • služby sledování ve vzdálených nebo nehostinných oblastech, které nejsou pokryty radary (oblasti NRA); • podpora cˇ i náhrada jedné vrstvy radarového krytí v prostorech RAD; • schopnost sledování za letu;


48

• zmenšení rozestup˚u mezi letadly, jak v horizontální, tak ve vertikální rovinˇe pro všechny tˇrídy vzdušného prostoru - nár˚ust kapacity vzdušného provozu a efektivity provozu; • lepší plánování pˇrílet˚u a odlet˚u daleko dopˇredu; • energeticky ménˇe nároˇcné než využití primárních a sekundárních pˇrehledových radar˚u; • možnost velmi levného a rychlého zavedení (využívá již existující digitální technologii); • detekce kolizí a poskytování ˇrešení až do vzdálenosti 100 mílí (160 km); • poskytování informací nejen o poloze letadla, ale také o smˇeru, rychlosti a výšce; • okamžité zobrazení zmˇen v pohybu letadel v okolí; • využití i na pojezdových a vzletových a pˇrístavacích drahách - efektivnˇejší a bezpeˇcnˇejší provoz pˇri souˇcasném pohybu více letadel a ostatních dopravních prostˇredk˚u po drahách za podmínek nižší viditelnosti; • ve vyšších nadmoˇrských výškách jeden z pilíˇru˚ k zavedení a fungování konceptu Free Flight (více o konceptu viz [33, 57]); • úspora paliva díky efektivnˇejšímu provozu. Nejvˇetší výhodou systému ADS-B je poskytování stejných dat v reálném cˇ ase pilot˚um letadel i rˇídícím letového provozu. Hlavním cílem konceptu ADS-B je zkvalitnit, zefektivnit a zabezpeˇcit bezpeˇcný letecký provoz a flexibilní využití vzdušného prostoru a provozních ploch letišt’.

4.3

Princip cˇ innosti

Primárním parametrem vysílaným pomocí systému ADS-B je pˇresná poloha letadla v prostoru. Pro její získání se používájí satelitní metody urˇcování polohy. Systém ADS-B ji konvertuje do digitálního kódu spolu s dalšími parametry urˇcenými k pˇrenosu. Digitální kód je vysílán z letadla na diskrétní frekvenci, která se nazývá datová linka (datalink). Jiná letadla v okruhu až 150 mil (240 km) pˇrijímají vysílání a zobrazují získaná data na obrazovce pro zobrazení leteckého provozu - Cockpit Display of Traffic Information (CDTI), jehož základní princip je na obrázku 4.3. Více o zobrazovaˇcích viz 4.7.4.

4.4. DATOVÉ LINKY

49

Obrázek 4.3: Diagram zobrazovaˇce CDTI, zdroj: autor dle [41] Pokud je dané pozemní stanovištˇe vybaveno pˇrijímaˇcem systému ADS-B, pˇrijímá ˇ data také rˇízení letového provozu (ATC, Air Traffic Control). Rídící letového provozu na své obrazovce vidí nejen cíle urˇcené radarem, ale také cíle systému ADS-B. Situace je zobrazena na obrázku 4.4.

Obrázek 4.4: Princip cˇ innosti systému ADS-B, zdroj: autor

4.4

Datové linky

V souˇcasné dobˇe existují 3 technologie, které jsou schopny poskytovat službu ADS-B: • 1090 MHz Mode S Extended Squitter; • Universal Access Transceiver (UAT); • Very High Frequency Digital Link Mode 4 (VDL Mode 4).


50

4.4.1

VHF Digital Link Mode

Dle [21] je VHF Digital Link Mode definován: VKV cˇ íslicový spoj (VHF digital link) je pohyblivá podsít’ letecké telekomunikaˇcní sítˇe (ATN), pracující ve VKV kmitoˇctovém pásmu, urˇceném pro leteckou pohyblivou službu. VDL m˚uže také zajišt’ovat funkce nesouvisející s ATN, jako napˇr. digitalizaci hlasu. Mód 4 (Mode 4) je potom dle [21] pouze datový spoj VDL používající modulaci s klíˇcováním kmitoˇctovým posuvem a gaussovským fitrováním (GFSK) a samoorganizující vícenásobný pˇrístup s cˇ asovým dˇelením. Tato technologie poskytuje aplikace pro sledování a široké komunikaˇcní služby, vˇcetnˇe módu broadcast, point-to-point komunikace i komunikace zemˇe-vzduch, vzduchvzduch. VDL Mode 4 pracuje na dvou kanálech s rozestupem 25 kHz, kterým se ˇríká Global Signaling Channels, a pˇrípadnˇe na dalších 5 kanálech, které se používají v oblastech s vyšší hustotou provozu. Pˇrístup na tento digitální kanál je ˇrešen metodou cˇ asového multiplexu, STDMA (Self Organizing Time Division Multiple Access). STDMA organizuje pˇrístup k jednotlivým slot˚um tak, že každá stanice je zodpovˇedná za výbˇer a rezervaci cˇ asového slotu, ve kterém chce vysílat. Jednotlivé cˇ asové sloty jsou synchronizovány pomocí cˇ asu získávaného z pˇrijímaˇce GNSS (Global Navigation Satellite System). Díky spoleˇcnému cˇ asu jednotlivých stanic tohoto systému m˚uže probíhat jejich vzájemná komunikace bez nutnosti pˇrítomnosti jakékoliv centrální rˇídící stanice. Pˇrenosová rychlost VDL Mode 4 je 19,2 kb/s. Z d˚uvodu synchronizace se systémem GPS, rozdˇeluje STDMA algoritmus pˇrístup do VKV pásma na 4500 cˇ asových slot˚u za minutu a využívá mobilních terminál˚u. Ty jsou schopny rezervovat daný cˇ asový slot pr˚ubˇežnˇe po každém vysílání a nepotˇrebují systém centrální rezervace. Datový spoj pomocí VDL Mode 4 je zobrazen na obrázku 4.5.

Obrázek 4.5: VDL Mode 4, zdroj: autor dle [46]

4.4. DATOVÉ LINKY

51

Výhodou tohoto datového spoje je pˇrenos krátkých zpráv od velkého množství uživatel˚u. Více o VHF Digital Link Mode viz [4].

4.4.2

Universal Access Transceiver (UAT)

Tato technologie byla speciálnˇe navržena pro podporu systému ADS-B. Pˇrístup na datový spoj je ˇrešen pomocí cˇ asového multiplexu pracujícího s cˇ asovými rámci dlouhými 1 sekundu, rozdˇelených na 2 cˇ ásti: • pˇrenos dat z pozemních stanic na paluby letadel - trvání 188ms, celkem 32 slot˚u; • segment ADS-B, nabízí 3200 možností zahájení zprávy (Message Start Opportunities - MSO). Tomuto ˇrízení pˇrístupu k datovému spoji se ˇríká hybridní. První cˇ ást zprávy je nutno cˇ asovˇe synchronizovat, aby se zamezilo pˇrekrývání vysílání jednotlivých pozemních stanic. Druhá cˇ ást segmentu - ADS-B - má pˇrístup cˇ istˇe náhodný na základˇe jednoho z typu MSO. Datový kanál Universal Access Transceiver je zobrazen na obrázku 4.6.

Obrázek 4.6: Universal Access Transceiver, zdroj: autor dle [46] UAT byl testován na frekvenci 966 MHz s vlnovým rozsahem 3 MHz, pˇrenosová rychlost byla zmˇerˇena na 1 Mb/s. Samotné pˇriˇrazení frekvence UAT ještˇe nebylo standardizováno. Zvažují se 3 alternativy: • 108-118 MHz (VKV pásmo - nyní dost vytíženo, prakticky nevyužitelné); • 690-1215 MHz (L-pásmo); • 5000-5250 MHz (C-pásmo - velký útlum pˇrenosu). 4.4.2.1

Zpráva UAT ADS-B

Zprávy pˇrenášené pomocí UAT se dˇelí na zprávy pˇrenášené na zem a zprávy pˇrenášené z pozemních stanic. [14]


52 4.4.2.2

Formát UAT ADS-B zprávy pˇrenášené na zem

Zpráva se skládá ze tˇrí hlavních polí - synchronizaˇcních puls˚u, dat a parity; viz obr. 4.7. Význam nˇekterých datových blok˚u je uveden dále. Protože popis veškerých polí pˇresahuje rámec této práce jsou vybrána jen nˇekterá, ostatní lze nalézt napˇr. v [14].

Obrázek 4.7: Formát zprávy UAT ADS-B, zdroj: autor dle [14]

Hlaviˇcka

Prvním polem datové cˇ ásti UAT ADS-B zprávy je hlaviˇcka, kterou tvoˇrí 4

byty. Její struktura je zobrazena na obrázku 4.8. První byte identifikuje typ kódu dat (urˇcuje typ a poˇradí pˇrenášených dat, viz tabulka 4.2, [14]) a typ adresy, která následuje v bytech 2 až 4. Jednotlivé typy adres a jejich význam jsou uvedeny v tabulce 4.3, [14].

Obrázek 4.8: Hlaviˇcka zprávy UAT ADS-B, zdroj: autor dle [14] V pˇrípadˇe adresy 000 se zpráva ADS-B vysílá z letadala. Adresa, která následuje, patˇrí vysílajícímu letadlu. Adresa je uložena v pamˇeti vysílacího subsystému. V pˇrípadˇe, že je nulová nebo jedniˇcková, nesmí subsystém zprávu vyslat a musí nahlásit chybu. Stavový vektor

Stavový vektor slouží pro urˇcení pˇresné polohy letadla (pˇrípadnˇe ji-

ného objektu, který tento systém využívá) v protoru. Musí tedy urˇcovat: • zemˇepisnou šíˇrku; • zemˇepisnou délku; • výšku;

4.4. DATOVÉ LINKY

typ kódu 0 1 2 3 4 5 6 7 8 9 10 11-29 30,31

53

Tabulka 4.2: Vliv kódování dat zprávy ADS-B na pˇrenášená data Byte ve zprávˇe 1 - 4 5 - 17 18 - 24 25 - 28 29 30 - 33 34 HDR SV Rezerv. Nepoužito HDR SV MS AUX SV HDR SV Rezerv. AUX SV HDR SV MS TS Rezerv. HDR SV Rezerv. TS Rezerv. HDR SV Rezerv. AUX SV HDR SV Rezerv. TS Rezerv. AUX SV HDR SV Rezerv. HDR SV Rezerv. HDR SV Rezerv. HDR SV Rezerv. HDR Rezerv. HDR Rezerv. pro úˇcely vývoje

HDR...hlaviˇcka, SV...stavový vektor, MS...status módu, TS...cílový stav, AUX SV...pomocný stavový vektor • horizontální rychlost; • vertikální rychlost. Formát stavového pole je zobrazen na obrázku 4.9. Urˇcení polohy

Zemˇepisná šíˇrka a délka jsou vztaženy k modelu zemˇe WGS-84 a

ve zprávˇe UAT jsou kódovány dle tabulky 4.4, [14]. Vzájemný vztah kvadrantu a zemˇepisné šíˇrky a délky je na obrázku 4.10. V pˇrípadˇe, že jsou všechny bity zemˇepisné šíˇrky a délky a pole NIC nulové, znamená to, že je informace o zemˇepisné šíˇrce/délce nedostupná. Pozn.: Protože na Zemi existuje nulová zemˇepisná šíˇrka a délka (pr˚useˇcík poledníku a rovníku), je nedostupnost informací indikována nulovým polem NIC. Urˇcení výšky

Nejprve je nutno urˇcit typ výšky – jestli je urˇcována na základˇe tlaku

nebo jde o výšku nad terénem (urˇcenou napˇr. z radiovýškomˇeru). To je urˇceno polem typ výšky v tabulce 4.9. V tabulce 4.5 ([14]) je ukázáno, jak ovlivˇnuje tento bit pole výška v tabulce 4.9 a pole sekundární výška, které se nachází v pomocném stavovém vektoru (viz tabulka 4.2 a 4.11). Je zˇrejmé, že obˇe výšky nepocházejí ze stejného zdroje. Kódování výšky je uvedeno v tabulce 4.6, [14].


54

bit 6 0 0 0 0 1 1 1 1

Tabulka 4.3: Význam adresy v hlaviˇcce zprávy UAT ADS-B bit 7 bit 8 adresa 0 0 ICAO 24 bitová adresa vysílacího letadla 0 1 Rezervováno pro národní úˇcely 1 0 ICAO 24 bitová adresa letadla vysílána v UAT ADS-B zprávˇe pozemní stanicí (TIS-B) 1 1 24 bitová adresa TIS-B track field vysílaná pozemní stanicí 0 0 24 bitová adresa pˇridˇelená vozidlu oprávnˇenému využívat systém ADS-B 0 1 adresa majáku ADS-B 1 0 Rezervováno 1 1 Rezervováno

Kvadrant

První kvadrant

Tabulka 4.4: Kódování zemˇepisné šíˇrky a délky bity šíˇrky nebo délky Význam 360 MSB LSB LSB= 224 = 21457 × 10−5 ◦ Zemˇepisná šíˇrka Zemˇepisná délka ◦ 0000 0000 0000 0000 0000 0000 0 (rovník) 0◦ (poledník) 0000 0000 0000 0000 0000 0001 LSB stupˇnu˚ LSB stupˇnu˚ severní šíˇrky východní délky .. .. .. . . . 0011 1111 1111 1111 1111 1111

0100 0000 0000 0000 0000 0001

(90-LSB) stupˇnu˚ severní šíˇrky 90 stupˇnu˚ severní šíˇrky (severní pól) -

.. . 0111 1111 1111 1111 1111 1111

-

1000 0000 0000 0000 0000 0000

-

1000 0000 0000 0000 0000 0001

-

.. . 1011 1111 1111 1111 1111 1111

-

0100 0000 0000 0000 0000 0000

Druhý kvadrant

Tˇretí kvadrant

1100 0000 0000 0000 0000 0000 1100 0000 0000 0000 0000 0001 ˇ Ctvrtý kvadrant

.. . 1111 1111 1111 1111 1111 1111

(90-LSB) stupˇnu˚ východní délky 90 stupˇnu˚ východní délky (90+LSB) stupˇnu˚ východní délky .. . (180-LSB) stupˇnu˚ východní délky 180 stupˇnu˚ východní/západní délky (180-LSB) stupˇnu˚ západní délky .. .

90 stupˇnu˚ jižní šíˇrky (jižní pól) (90-LSB) stupˇnu˚ jižní šíˇrky .. .

(90+LSB) stupˇnu˚ západní délky 90 stupˇnu˚ západní délky (90-LSB) stupˇnu˚ západní délky .. .

LSB stupˇnu˚ jižní šíˇrky

LSB stupˇnu˚ západní délky

4.4. DATOVÉ LINKY

Obrázek 4.9: Formát stavového pole UAT ADS-B zprávy, zdroj: autor dle [14]

Obrázek 4.10: Kvadranty a zemˇepisná délka/šíˇrka, zdroj: autor dle [14]

bit 0 1

Tabulka 4.5: Význam bitu Altitude type pole Výška pole Sekundární výška barometrická tlaková výška výška nad terénem výška nad terénem barometrická tlaková výška

55


56

Tabulka 4.6: Kódování výšky UAT kanálu Bit Výška 0000 0000 0000 informace o výšce je nedostupná 0000 0000 0001 -1000 ft 0000 0000 0010 -975 ft ... ... 0000 0010 1000 -25 ft 0000 0010 1001 nulová 0000 0010 1010 25 ft ... ... 1111 1111 1110 101 325 ft 1111 1111 1111 >101 337.5 ft

Pole NIC

Pole NIC (Navigation Integrity Category) udává, jestli má pozice pˇrija-

telnou úroveˇn integrity. Kódování pole NIC je v tabulce 4.7, [14]. V pˇrípadˇe, že systém ADS-B není synchronizován s cˇ asem UTC, musí se v poli NIC vysílat desítková hodnota 8. Znamená to, že se data nedají využít pro pˇresnou navigaci. Pro tu se dají využít data, která mají v poli NIC nastavenu desítkovou hodnotu 9 až 11. A/G State Pole A/G State (air/ground state) reprezentuje stav letadla - zda je na zemi cˇ i ve vzduchu. Kódování je uvedeno v tabulce 4.8, [14]. Toto pole také udává kódování pole horizontální rychlosti. Pole UTC Pole UTC udává, jestli je systém ADS-B synchronizován s cˇ asem UTC, viz tabulka 4.9, [14]. Pomocný stavový vektor Pomocný stavový vektor slouží prozatím pouze pro pˇrenos sekundárnˇe urˇcené výšky. Formát je na obrázku 4.11. Rezervované bity jsou nastaveny na nulu, slouží pro pˇrípadné rozšíˇrení pˇrenášených informací v budoucnu.

Obrázek 4.11: Formát pomocného stavového vektoru, zdroj: autor dle [14]

4.4. DATOVÉ LINKY

57

Tabulka 4.7: Kódování pole NIC Pˇrenášená hodnota Horizonální a vertikální binárnˇe decimálnˇe kontrolní mez 0000 0 Rc ≥ 3704 km (20 NM) ... ... ... 0111 7 Rc < 340.4 m (0.2 NM) 1000 8 Rc < 185.2 m (0.1 NM) 1001 9 Rc < 75 m 1010 10 Rc < 25 m 1011 11 Rc < 7.5 m 1100 Rezervováno 1101 Rezervováno 1110 Rezervováno 1111 Rezervováno Rc ... maximální chyba v urˇcení pozice

Tabulka 4.8: Kódování pole A/G State Bit Stav letadla 00 Let - subsonické podmínky 01 Let - supersonické podmínky 10 Na zemi 11 Rezervováno

Bit 0 1 4.4.2.3

Tabulka 4.9: Kódování pole UTC Význam ADS-B není synchronizován s cˇ asem UTC ADS-B je synchronizován s cˇ asem UTC

Formát zprávy UAT ADS-B pˇrenášené z pozemní stanice

Zpráva pˇrenášená z pozemní stanice má dvˇe cˇ ásti: • hlaviˇcku - prvních 8 byt˚u; • aplikaˇcní data - byte 9 až 432. Struktura aplikaˇcních dat je na obrázku 4.12. Pole, která jsou shodná s poli ve zprávˇe pˇrenášené z letadla na zem, mají stejné kódování. Pole Position Valid je jeden bit, který udává jestli je pozice správná - hodnota 1 prezentuje správnou pozici. Pole Slot ID udává, který z 32 slot˚u byl vybrán. Pole TIS-B


58

Obrázek 4.12: Formát zprávy UAT ADS-B pˇrenášené z pozemní stanice, zdroj: autor dle [14] Site ID pak urˇcuje, jestli jsou ve zprávˇe pˇrenášeny informace TIS-B. Pole aplikaˇcních dat (byte 9 až 432) se skládá z informaˇcních rámc˚u a jejich popis je uveden v [14].

4.4.3

1090 MHz Mode S Extended Squitter

Tento datový spoj využívá také palubní protisrážkový systém TCAS II. Extended Squitter pracuje na frekvenci 1090 MHz, stejnˇe jako odpovˇedi na dotazy sekundárních radar˚u v módu A/C/S, vojenské módy a vysílání palubních protisrážkových systém˚u TCAS. Šíˇrka frekvenˇcního pásma je 3 MHz. Pˇrístup na datový spoj je zcela náhodný, není tedy nutná žádná synchronizace nebo cˇ asový multiplex. Pˇrenosová rychlost je 1 Mb/s. Datový spoj znázorˇnující 1090 MHz Mode S Extended Squitter je na obrázku 4.13.

Obrázek 4.13: 1090 MHz Mode S Extended Squitter, zdroj: autor dle [46] Od p˚uvodního Squitter se liší v poˇctu bit˚u ve zprávˇe - p˚uvodní má 56 bit˚u, rozšíˇrený 112 bit˚u. Více o tomto datovém spoji viz [11].

4.5. DALŠÍ MOŽNOSTI SYSTÉMU ADS-B

4.5

59

Další možnosti systému ADS-B

Mimo základní výhody systému ADS-B uvedené v kapitole 4.2 lze jako výhodu uvádˇet také možnost pˇrenášet data letových informaˇcních služeb (FIS - Flight Information Service) a data služby informací o provozu (TIS - Traffic Information Service).

4.5.1

FIS-B

Letová informaˇcní služba (Flight Information Service - Broadcasting) je služba poskytovaná za úˇcelem podávání rad a informací k bezpeˇcnému a úˇcinnému provádˇení let˚u.

4.5.2

TIS-B

Služba informací o provozu (Traffic Information Service - Broadcasting) se obdobnˇe jako ADS-B dˇelí na 2 podsystémy: • TIS-B OUT - odchozí rozhlasové vysílání služby informací o provozu = pozemní funkce, která pravidelnˇe rozhlasovˇe vysílá pˇrehledové informace získané z pozemních snímaˇcu˚ ve formátu, který je vhodný pro pˇrijímaˇce se schopností TIS-B IN [24]. • TIS-B IN - pˇríchozí rozhlasové vysílání služby informací o provozu = pˇrehledová funkce, která pˇrijímá a zpracovává pˇrehledová data z datových zdroj˚u TIS-B OUT [24].

4.6

Srovnání ADS-B a SSR

Z tabulky 4.10 je patrné, že pˇri užití sekundárního pˇrehledového radaru SSR (Secondary Surveillance Radar) se nˇekterá data dají pˇrenášet jen v urˇcitých módech. Nˇekterá data se nezískavají pˇrímo z paluby letadla, ale jsou získávána z principu radaru. Pˇri využití systému ADS-B jsou veškerá data získávána pouze z palubních systém˚u letadla. To m˚uže mít rˇadu nevýhod, napˇríklad porucha daného zdroje informace. Srovnání vybraných parametr˚u pˇrenášených pomocí sekundárního pˇrehledového radaru SSR a systému ADS-B je v tabulce 4.11. Z tabulky je vidˇet, že systém ADS-B pˇrináší prakticky ve všech tˇechto parametrech srovnatelné nebo lepší výsledky. Jen v pˇrípadˇe nouzové navigace je systém ADS-B horší než sekundární pˇrehledový radar. Je to z toho d˚uvodu, že systém ADS-B spoléhá na parametry získáné ze senzor˚u umístˇených na letadle a v pˇrípadˇe jejich poruchy nemá k dispozici jiný zdroj informací, který by je mohl nahradit. Proto m˚uže být letadlo v pˇrípadˇe urˇcité poruchy „slepé“. Pˇri využití


60

sekundárního pˇrehledového radaru lze získat alespoˇn výšku a azimut letadla a pomocí ˇrídícího letového provozu letadlo bezpeˇcnˇe navigovat na nouzové pˇristání. Tabulka 4.10: Srovnání pˇrenosu jednotlivých dat SSR a ADS-B DATA SSR ADS-B Identifikace pˇreneseno pˇres komunikaˇcní kanál pˇreneseno pˇres komunikaˇcní kanál z letadla z letadla (unikátní 24 bitová adresa + identifikace letu) Pozice radar mˇeˇrí výšku a azimut sám pˇreneseno pˇres komunikaˇcní kanál z letadla Výška pˇreneseno pˇres komunikaˇcní kanál pˇreneseno pˇres komunikaˇcní kanál z letadla z letadla (mód C) Vektor poˇcítán z vývoje výšky a azimutu pˇreneseno pˇres komunikaˇcní kanál rychlosti z letadla Nouzové pˇreneseno pˇres komunikaˇcní kanál pˇreneseno pˇres komunikaˇcní kanál z letadla z letadla zprávy (mód A - speciální kódy)

Tabulka 4.11: Srovnání výhodnosti pˇrenosu parametr˚u pomocí SSR a ADS-B Parametr SSR ADS-B √ Urˇcení pozice x Urˇcení výšky = = √ Identifikace letadla x √ Vektor rychlosti x Identifikace nouze = = √ Interval aktualizace x √ Rozlišení cíl˚u x √ Souˇcasné pokrytí x √ Korekce „šikmé“ vzdálenosti x √ Nouzová navigace x Varování pˇred nízkou výškou = = =...srovnatelné výsledky,

√ ... lepší výsledky, x...horší výsledky

ˇ 4.7. SOUCÁSTI SYSTÉMU ADS-B

4.7

61

Souˇcásti systému ADS-B

Pro plnou operabilitu systému ADS-B je potˇreba, aby bylo letadlo vybaveno tˇemito zarˇízeními: • Zdroj dat (Squitter Data Sources); • ADS-B vysílaˇc; • ADS-B pˇrijímaˇc; • ADS-B zobrazovaˇc. Letadlo zapojené do systému ADS-B musí být schopné vyslat minimálnˇe informace o své pozici, aniž by bylo na tuto pozici dotázáno (napˇr. pomocí TCAS dotazu). V pˇrípadˇe, že se vyžaduje komunikace vzduch-vzduch (mezi letadly navzájem) musí být letadlo vybaveno nezbytnou avionikou, jako je napˇr. pˇrijímaˇc ADS-B signálu. Dalším prvkem pro plné využití možností ADS-B je zobrazovaˇc, který vhodným zp˚usobem pˇredá získané informace posádce letadla.

4.7.1

ADS-B zdroj dat

Jako minimum je potˇreba mít adekvátní zdroj dat o pozici letadla, která budou vysílána. Nejˇcastˇeji se pro tento úˇcel používá stávající navigaˇcní systém. Dále je vhodný systém GNSS cˇ i jiný zdroj navigaˇcních dat s odpovídající integritou nebo samostatá GNSS jednotka balenou s avionikou ADS-B.

4.7.2

ADS-B vysílaˇc

Dalším d˚uležitým prvkem pro možnost úˇcasti na jakékoliv aktivitˇe ADS-B je vysílaˇc zpráv napojený na zdroj informací. Pˇri využití módu S je nejpravdˇepodobnˇejší využití ATC odpovídaˇce, kterým je vybavena vˇetšina letadel. Každý existující odpovídaˇc módu S poskytuje vysílání Short Squitter a modifikace na formát Extended Squitter není nákladná. V pˇrípadˇe, že letadlo není vybaveno klasickým ATC odpovídaˇcem, je možnost alternativního odpovídaˇce v podobˇe zaˇrízení urˇceného pˇrímo pro Extended Squitter. Normy minimální výkonnosti jsou uvedeny v [49].

4.7.3

ADS-B pˇrijímaˇc

Všechna letadla využívající systém ACAS (Airborne Collision Avoidance System)/TCAS (Traffic Alert and Collision Avoidance System) jsou vybavena pˇrijímaˇcem 1090 MHz. Tyto pˇrijímaˇce mohou pˇrijímat i všesmˇerové vysílání Extended Squitter. Letadla bez


62

systému ACAS/TCAS musí být dovybavena pˇrijímaˇcem Extended Squitter. Normy minimální výkonnosti jsou uvedeny v [49]. Seznam pˇrijímaˇcu˚ a vysílaˇcu˚ vyvinutých pro systém ADS-B je uveden v [49].

4.7.4

Zobrazovaˇc ADS-B

Posledním zaˇrízením systému ADS-B je zobrazovaˇc dat. Slouží pro zobrazení ADSB informací získaných z jiných letadel, nejménˇe však informací týkajících se dopravní situace. V souˇcasné dobˇe jsou vyvinuty pouze dva certifikované zobrazovaˇce urˇcené pro systém ADS-B, jeden firmy Garmin, druhý Euro Telematik, viz 4.7.4.3 a 4.7.4.2. V pˇrípadˇe, že se jako pˇrijímaˇc Extended Squitter využívá pˇrijímaˇc systému ACAS, lze ADS-B data zobrazit na pˇrímo na jeho displeji, který však musí být modifikován. Pˇrijímaná data lze také zobrazit na kapesním poˇcítaˇci (PDA - Personal Digital Assistant) vybaveném systémem ADS-B (obr. 4.14). To je velmi výhodné pro malá letadla, do kterých se nemusí instalovat nákladnˇejší Cockpit Display of Traffic Information (CDTI). Kapesní poˇcítaˇc se využívá také pro pozemní testování.

Obrázek 4.14: Kapesní poˇcítaˇc s instalovaným ADS-B, zdroj: [5]

4.7.4.1

Obecný popis zobrazovaˇce ADS-B

Základní funkcí zobrazovaˇce systému ADS-B je informovat pilota o pˇrítomnosti a pˇresné poloze okolního provozu. Na každém displeji musí být zobrazeny tyto informace: • symbolické rozlišení provozu s relativní d˚uležitostí; • kurz; • relativní výška (pouze u letadel hlásících nadmoˇrskou výšku) – nad nebo pod vlastním letadlem (znaménka +/-), numerická hodnota; • svislý trend (pouze u letadel hlásících nadmoˇrskou výšku);


63

• zvolený dosah – volitelný posádkou, pˇri rozsahu 10 námoˇrních mil (NM) musí být okolo vlastního letadla ve vzdálenosti 2 NM zobrazen kroužek. Displej a jeho logika musí být schopné zobrazit nejménˇe 3 letadla a zároveˇn všechna letadla, která jsou v okruhu 5 NM od vlastního letadla. Pokud poˇcet letadel pˇresahuje schopnosti displeje, musí být letadla mazána z displeje v poˇradí: 1. ostatní provoz v nejvˇetší vzdálenosti; 2. nežádaný provoz (TA - Traffic Advisory) s nejvyšším cˇ asem do nejbližšího pˇriblížení a cˇ asu do spoleˇcné nadmoˇrské výšky. V pˇrípadˇe, že je v okolí letadlo, jehož informace by mˇely být zobrazeny, ale je ve vzdáleností vˇetší než je maximální rozsah zobrazení, musí být na okraji displeje v pˇríslušném kurzu zobrazena nejménˇe ¼ symbolu informace o provozu. Datové pole a šipka musí být zobrazeny v bˇežných polohách, jak je popsáno níže. Symbol pro zobrazení okolního provozu je na obrázku 4.15. Tvoˇrí jej velká šipka, v angliˇctinˇe se používá výraz chevron. Smˇer šipky ukazuje ve smˇeru kurzu letu letadla. ˇ Casto bývá doplnˇen úseˇckou znázorˇnující vektor rychlosti. Symbol oznaˇcující okolní provoz nesmí být menší než 0,2 palce, musí být doplnˇen datovým polem a šipkou oznacˇ ující stoupání, respektive klesání letadla. V datovém poli je uvedena identifikace daného letadla a jeho výška. Ta m˚uže být bud’ relativní nebo tlaková. Relativní výška je rozdíl mezi výškou vlastního letadla a letadla, které znázorˇnuje daný symbol. Informace, zda jde o relativní nebo tlakovou výšku, musí být uvedena na displeji. Výška je uvedena pomocí dvojice cˇ ísel, které udávají výšku ve stovkách stop (jiné výšky než výšky u symbol˚u letadel jsou uvedeny ve stopách, ne ve stovkách stop). Pˇred dvojicí cˇ ísel je uvedeno znaménko + nebo -, podle toho zda je letadlo nad nebo pod vlastním letadlem (znaménko + znamená, že je nad vlastním letadlem, znaménko – pod vlastním letadlem). V pˇrípadˇe, že je letadlo ve stejné výšce, je v datovém poli uveden výraz 00, bez znamének. Výška znak˚u v datovém poli nesmí být menší než 0,15 palce. Šipka znázorˇnující klesání/stoupání letadla musí být umístˇena vlevo od symbolu provozu, a to pouze v pˇrípadˇe, že letadlo mˇení svou výšku rychlostí vˇetší než 500 stop za minutu. Smˇer šipky je logický - pokud letadlo klesá, míˇrí šipka dol˚u. Barva písma v datovém poli a barva šipky pro klesání/stoupání musí odpovídat barvˇe chevronu (symbolu) znázorˇnujícího dané letadlo. Pˇrekrývající se symboly by mˇely být zobrazeny i s pˇrekrývajícími se informacemi tak, že symbol provozu s nejvyšší prioritou je nad symboly provozu s nižší prioritou. Nejvyšší prioritu má TA provoz seˇrazený dle cˇ asu do nejbližšího pˇriblížení a cˇ asu do spoleˇcné nadmoˇrské výšky. Ostatní provoz má prioritu ˇrazenou dle vzdálenosti.


64

Obrázek 4.15: Symbol pro zobrazení okolního provozu, zdroj: autor dle [34] Pokud nelze u letadla urˇcit relativní kurz, musí být pod symbolem vlastního letadla zobrazena informace o letovém provozu v tabulkové formˇe. Pˇríklady uvedení takové informace jsou uvedeny v tabulce 4.12. Displej systému ADS-B musí být schopen zobrazit minimálnˇe 2 takovéto typy provozu. Tabulka 4.12: Kódování okolního provozu bez relativního kurzu Kód Význam TA 4 +0,2 provoz TA ve vzdálenosti 4 námoˇrní míle a o 200 stop výše TA 8 -0,8 provoz TA ve vzdálenosti 8 námoˇrních mil a o 800 stop níže TA 5,6 provoz TA bez nadmoˇrské výšky a ve vzdálenosti 5,6 námoˇrních mil Uprostˇred displeje je umístˇeno vlastní letadlo – pomocí symbolu nebo siluety letadla. Zvolený symbol musí být odlišný od symbol˚u znázorˇnujícího okolní provoz, nejˇcastˇeji se používá trojúhleník. Symbol musí být orientován tak, aby byl smˇer letu vždy nahoru (tzv. na 12 hodinách). Pˇri zobrazení kroužku okolo vlastního letadla ve vzdálenosti 2 NM musí mít tento kroužek diskrétní znaˇcky na každé z 12 poloh hodin, takového tvaru a velikosti, aby nezahlcovaly displej. Základní režim displeje je na obrázku 4.16. Displej systému ADS-B m˚uže být vybaven dalšími funkcemi. Jednou z pˇríjemných funkcí je volba rozsahu, pomocí kterého se mˇení pokrytá vzdálenost. Vybraný rozsah musí být na displeji trvale zobrazen. Tato funkce se cˇ asto nazývá ZOOM. Mezi další volitelné funkce patˇrí volba individuálních cíl˚u provozu. Ta se využívá, pokud chce pilot zjistit informace o vybraném letadle, které nejsou uvedeny v datovém poli. Pˇri vybrání urˇcitého letadla se zobrazují tyto informace: • identifikaˇcní cˇ íslo letadla; • typ letadla;


65

Obrázek 4.16: Displej systému ADS-B v základním režimu, zdroj: autor dle [34] • vzdálenost mezi vybraným letadlem a vlastním letadlem; • rychlost; • nadmoˇrská výška; • pozice mezi vybraným letadlem a vlastním letadlem. Pozice mezi vybraným a vlastním letadlem se udává v „hodinách“ jako relativní smˇer letu pro každé letadlo. Napˇríklad oznaˇcení 11/2 znamená, že vybrané letadlo je na 11 hodinách od vlastního letadla a vlastní letadlo je na 2 hodinách od vybraného letadla. Pˇríklad vybrání letadla je na obrázku 4.17.

Obrázek 4.17: Vybrání urˇcitého cíle na displeji systému ADS-B, zdroj: autor dle [34]


66

Další funkcí systému ADS-B je zobrazení TIS-B objekt˚u. To jsou letadla, která nejsou vybavena systémem ADS-B, ale jsou urˇcena pozemními systémy (typicky radarem). Letadla, jejichž pˇresnost v urˇcení polohy není na požadované úrovni, bývají zobrazena pomocí symbolu tvaru „kulky“, viz obr. 4.18. Takto bývají zobrazena letadla typu TIS-B nebo letadla, jejichž pˇresnost polohy ze systému GPS je snížena. Dalším objektem, který lze na displeji ADS-B zobrazit, jsou pozemní cíle vybavené ADS-B, napˇríklad auta na letišti. Zobrazují se pomocí symbolu cˇ tverce žlutohnˇedé až hnˇedé barvy, viz obr. 4.18. Zobrazení letadel s malou pˇresností polohy Zobrazení pozemních cíl˚u Obrázek 4.18: Symboly pro zobrazení jiných objekt˚u, zdroj: autor dle [34]

4.7.4.2

EURO Telematic CDTI2000

Jedním z certifikovaných zobrazovaˇcu˚ systému ADS-B – Cockpit Display of Traffic Information je zobrazovaˇc CDTI2000 firmy Euro Telematik (viz obr. 4.19). Tento zobrazovaˇc je certifikován dle CS-ETSO – C113 (Palubní víceúˇcelové elektronické displeje) a CS-ETSO – C147 (Palubní vybavení systému informací o letovém provozu (TAS)).

Obrázek 4.19: Zobrazovaˇc CDTI 2000, zdroj: [19] Zobrazovaˇc umí zobrazit ADS-B data pˇrijatá pomocí módu S a VDL Mode 4. Podporuje systém Ryan TCAD1 , ale nezahrnuje rozhraní TCAS. Firma Euro Telematik vy1 http://www.avweb.com/news/reviews/182532-1.html


67

vinula také ˇrešení zobrazení inforamcí systému ADS-B pomocí software pro kapesní poˇcítaˇc PDA. Tento software nazvala Flight Companion CDTI. Díky tomuto rˇešení lze ADS-B levnˇe implementovat do malých letadel. Bohužel ještˇe není tento software certifikován pro použití v civilním letectví. Zobrazovaˇc CDTI2000 má implementována rozhraní [35]: • RS 232; • RS 422; • Ethernet; • Arinc 429. Pˇres rozhraní RS 232/422 komunikuje napˇríklad s : • externí GPS; • Satcom; • výškomˇerem; • VDL Mode 4. Pomocí rozhraní Ethernet komunikuje s pˇrijímaˇcem módu S. Sbˇernici ARINC 429 využívá pro získávání informací ze senzor˚u umístˇených na letadle. Základní technické informace jsou uvedeny v tabulce 4.13, [35]. Tabulka 4.13: Základní technické informace zobrazovaˇce CDTI 2000 Parametr Hodnota Rozmˇer 114 x 146.05 x 185 mm Váha 2 kg Pˇríkon 50 W Rozsah operaˇcních teplot -15◦ C až +55◦ C Rozsah skladovacích teplot -25◦ C až +85◦ C Displej CDTI2000 pracuje v tˇechto módech: • zobrazení okolního provozu (Traffic Awareness Display) (viz obr. 4.20); • zobrazení terénu (Terrain Awareness Display) (viz obr. 4.21); • zobrazení pohybujících se map (Moving Map) (viz obr. 4.22); • zobrazení digitální komunikace (Digital Communication) (viz obr. 4.23).

68


Obrázek 4.20: Zobrazení okolního provozu CDTI2000, zdroj: [58]

Obrázek 4.21: Zobrazení okolního terénu CDTI2000, zdroj: [35]

Obrázek 4.22: Zobrazení pohybujících se map CDTI2000, zdroj: [58]


69

Obrázek 4.23: Zobrazení digitální komunikace CDTI2000, zdroj: [35] Význam barev pˇri zobrazení okolního terénu je na obrázku 4.24.

Obrázek 4.24: Význam barev pˇri zobrazení terénu, zdroj: autor dle [34] Tento zobrazovaˇc byl instalován na nˇekterých letadlech tˇechto typ˚u: C172, Piper Archer, Piper Lance, Beech Baron, King Air 100, Dash-7, Lear-35, Citation II, Falcon 20. [58] 4.7.4.3

Garmin MX 20/GMX 200

Dalším typem zobrazovaˇce urˇceného pro systém ADS-B je multifunkˇcní displej MX 20 (viz obr. 4.25) nebo jeho novˇejší verze GMX 200 firmy Garmin, která ovšem ještˇe není certifikovaná. Oba typy zobrazují tyto základní informace: • ADS-B provoz – graficky i textovˇe (viz obr. 4.26); • poˇcasí – graficky i textovˇe (viz obr. 4.28); • varování pˇred blízkostí zemˇe; • zobrazení terénu (viz obr. 4.27);


70 • VFR a IFR mapy (viz obr. 4.29); • letové cesty (viz obr. 4.30 ).

Obrázek 4.25: Zobrazovaˇc Garmin MX20, zdroj: [34]

Obrázek 4.26: Grafické a textové zobrazení okolního provozu na zobrazovaˇci MX20, zdroj: [34]

Obrázek 4.27: Zobrazení okolního terénu na zobrazovaˇci MX20, zdroj: [34]


71

Obrázek 4.28: Grafické a textové zobrazení poˇcasí na zobrazovaˇci MX20, zdroj: [34]

Obrázek 4.29: Zobrazení mapy na zobrazovaˇci MX20, zdroj: [34]

Obrázek 4.30: Zobrazení letových cest na zobrazovaˇci MX20, zdroj: [34] Význam barev pro zobrazení okolního terénu je na obrázku 4.24.


72

Vybrané technické informace zobrazovaˇce MX 20 jsou v tabulce 4.14, [34]. Tabulka 4.14: Vybrané technické informace zobrazovaˇce MX20 Parametr Hodnota Rozmˇery 259 x 127 x 203 mm Váha 2.11 kg Rozmˇer displeje 6” Rozlišení displeje 640 x 480 pixel Rozsah operaˇcních teplot -20◦ C až +55◦ C Vlhkost 95% pˇri teplotˇe +55◦ C Zobrazovaˇc MX 20 byl certifikován podle následujících technických normalizaˇcních pˇríkaz˚u: • TSO-C110a (Palubní systém pro pasivní detekci bouˇrí); • TSO-C113 (Palubní víceúˇcelové elektronické displeje); • TSO-C63c (Pulsní radary pro detekci poˇcasí a mapování povrchu zemˇe); • TSO-C118 (Provozní výstražný protisrážkový systém, TCAS I); • TSO-C147 (Palubní vybavení systému informací o letovém provozu (TAS)); • JTSO-C110a (Palubní systém pro pasivní detekci bouˇrí); • JTSO-C113 (Palubní víceúˇcelové elektronické displeje). Pozn.: Specifikace TSO je americký ekvivalent evropských specifikací ETSO. ETSO vychází z TSO, ale upravuje je pro použití v evropských podmínkách. Ne vždy kladou specifikace TSO a ETSO stejného cˇ ísla rovnocenné podmínky. Vybrané technické informace zobrazovaˇce GMX 200 jsou uvedeny v tabulce 4.15, výrobce plánuje certifikaci dle: • TSO-C110a (Palubní systém pro pasivní detekci bouˇrí); • TSO-C113 (Palubní víceúˇcelové elektronické displeje); • TSO-C63c (Pulsní radary pro detekci poˇcasí a mapování povrchu zemˇe); • TSO-C118 (Provozní výstražný protisrážkový systém, TCAS I); • TSO-C147 (Palubní vybavení systému informací o letovém provozu (TAS)).

4.8. BUDOUCNOST ADS-B

73

Tabulka 4.15: Vybrané technické informace zobrazovaˇce GMX 200 Parametr Hodnota Rozmˇery 159 x 127 x 203 mm Váha 2.1 kg Rozmˇer displeje 6.5” Rozlišení displeje 640 x 480 pixel Rozsah operaˇcních teplot -20◦ C až +55◦ C Rozsah skladovacích teplot -55◦ C až +85◦ C Vlhkost 95% pˇri teplotˇe +50◦ C Maximální výška 35 000 feet

4.8

Budoucnost ADS-B

Dne 28. cˇ ervna 2002 rozhodna organizace FAA (Federal Aviation Authority) o zavedení architektury ADS-B ve svém vzdušném prostoru (USA). Toto rozhodnutí bylo d˚uležité z hlediska výrobc˚u a provozovatel˚u letadlové techniky, jakým smˇerem dále vyvíjet potˇrebné systémy. Na základˇe mnoha letových test˚u, simulací, analýz a dalších studií tak FAA rozhodla, že ADS-B je vhodný pro využití v leteckém odvˇetví. Nemalá spolupráce musela probˇehnout i s ostatními mezinárodními organizacemi, napˇr. s evropskou spoleˇcností EUROCONTROL. Po mnoha jednáních bylo nakonec rozhodnuto, že ADS-B bude využívat datový spoj 1090 MHz Mode S Extended Squitter pro letadla létající ve vyšších nadmoˇrských výškách, a levnˇejší UAT s frekvencí 978 MHz pro všeobecné letectví. Aby se zajistila kompatibilita v obou tˇechto cˇ ástech, musí být zajištˇena pozemní infrastruktura ADS-B zvládající oba tyto datové spoje. Navíc budou data na palubu jednotlivých letadel vysílána pomocí zpráv TIS-B.

4.8.1

Integrovaný systém rˇ ízení letového provozu

Integrovaný systém ˇrízení letového provozu je založen na sledování vzdušného prostoru pomocí: • radar˚u; • ADS-C; • ADS-B; • hlášení pilot˚u o poloze a dopoˇcítávaní aktuální polohy z letového plánu.


74

Zp˚usob získávání informace o poloze pomocí hlášení pilot˚u a dopoˇcítávání polohy z podaného letového plánu se využívá v oblastech, která nejsou pokryta žádným z výše uvedených zp˚usob˚u získávání informace o poloze. Pro ˇrídícího letového provozu je d˚uležité, aby vˇedˇel, který ze zp˚usobu sledování vzdušného prostoru byl použit. Z tohoto d˚uvodu se pro zobrazení letadla na obrazovce letového prostoru využívají r˚uzné symboly pro odlišný zp˚usob získání informací z letadla, viz tabulka 4.16. Tabulka 4.16: Symboly pro rozlišení zp˚usob˚u získání informace o poloze Symbol P˚uvod informace o poloze radar ADS-B ADS-C hlášení pilot˚u, poloha z letového plánu ˇ Rídící letového provozu na své obrazovce okamžitˇe pozná o jaký typ informace se jedná a m˚uže podle toho rˇídit daný prostor. Každý se zp˚usob˚u má jinou pˇresnost urˇcení polohy. Záleží na mnoha faktorech, je však patrné, že urˇcení podle letového plánu je nejvíce klamné a rˇídící musí k takovému letadlu pˇristupovat jinak než k letadlu se systémem ADS-B cˇ i letadlu, jehož poloha je urˇcena pomocí pˇrehledového radaru. Pˇríklad pˇrehledu letového provozu na obrazovce rˇídícího letového provozu je na obr. 4.31.

4.9

Souˇcasné využití ADS-B

První oblastí, ve které již funguje ADS-B, je Aljaška, kde byl spuštˇen bˇežný provoz ADS-B jako schválený zdroj pˇrehledových dat pro ATC bez radarového krytí. Projekt spuštˇení ADS-B na Aljašce je pod záštitou FAA nazýván Capstone. Datový spoj byl realizován pomocí UAT technologie. Ke spuštˇení došlo 1. 1. 2001. V souˇcasnosti je v provozu 20 stanic, které poskytují služby pˇribližnˇe 200 letad˚um vybavených potˇrebnou avionikou. Zkušební provoz zaˇcal probíhat také v okolí mˇest Memphis, Atlantic City, Washington D.C. a nad Mexickým zálivem. Dalším státem využívajícím ADS-B se stala Kanada. Jako datový spoj byl zvolen také UAT. Ve vnitrozemí Austrálie je v souˇcasné dobˇe instalováno pro zkušební provoz 28 pozemních stanic. Používají pouze datový spoj 1090 MHz Extended Squitter. V Evropˇe byl také vybrán tento druh datového spoje. Švédský úˇrad pro civilní letectví umístil na území Švédska také nˇekolik stanic podporujících datový spoj VDL Mode 4 pro odzkoušení této alternativy. VDL Mode 4 se zkouší také v oblasti Stˇredozemí.

ˇ 4.9. SOUCASNÉ VYUŽITÍ ADS-B

75

Obrázek 4.31: Letový provoz na obrazovce ˇrídícího letového provozu, zdroj: autor dle [44] Pro celosvˇetovou interpretaci ADS-B se jednotlivé organizace dohodly na využívání datového spoje 1090 MHz Extended Squitter. Pokud se do budoucna toto rozhodnutí neprokáže jako optimální, jsou jednotlivé organizace naklonˇeny k diskuzím o jiném vhodnˇejším datovém spoji. Toto rozhodnutí podpoˇrilo jak FAA a EUROCONTROL, tak také ICAO a IATA. Na základˇe tohoto rozhodnutí již nˇekteˇrí výrobci letadel na pˇrání svých zákazník˚u vybavují svá letadla potˇrebnou technologií 1090 MHz Extended Squitter. Vzhledem k již fungujícím pozemním stanicím v jednotlivých cˇ ástech svˇeta, které využívají r˚uzné datové linky, se zaˇcal vyvíjet také systém ADS-R, pˇres který spolu mohou komunikovat pˇrístroje využívající odlišnou datovou linku.

4.9.1

Situace v Austrálii

Nejdále se zkušebním provozem systému ADS-B je Austrálie. D˚uvod je pˇri pohledu na mapu Austrálie jasný – je potˇreba rˇídit provoz také ve vnitrozemí, kde je jen poušt’ a instalace klasických radar˚u by byla pˇríliš drahá. Na základˇe výborných výsledk˚u tˇechto test˚u, schválil CASA (Civil Aviation Safety Authority – australský ekvivalent úˇradu pro civilní letectví) odstup letadel na 5 námoˇrních mílí, což je ekvivalentní požadovanému rozestupu pˇri použití radar˚u. Pokrytí Austrálie jednotlivými systémy je na obr. 4.32.


76

Obrázek 4.32: Pokrytí Austrálie jednotlivými systémy, zdroj: [44]

4.9.2

ADS-B v Evropˇe

Pro zavedení systému ADS-B do evropského vzdušného prostoru byl vytvoˇren program CASCADE, jehož cílem je uvedení do provozu a zajištˇení harmonizace [12]. Program CASCADE pˇredpokládá pouze využití datového spoje 1090 MHz Extended Squitter. V souˇcasné dobˇe jsou v Evropˇe vydána certifikaˇcní kritéria pro využití ADS-B v neradarových oblastech – ADS-B-NRA (viz kapitola 4.1.2.4). Tato certifikaˇcní kritéria jsou uvedena v [12]. Pokrytí systémem ADS-B v Evropˇe je na obrázku 4.33. Zelenˇe jsou zobrazeny vysílaˇce v plném provozu, cˇ ervenˇe jsou zobrazeny plánované vysílaˇce. Modˇre jsou vyznacˇ eny státy, které na programu CASCADE v souˇcasné dobˇe spolupracují.

4.9.3

ADS-B v USA

Federální úˇrad pro letectví ve Spojených státech amerických (FAA) vydal rozhodnutí, že od roku 2020 musí všechna letadla využívající rˇízený vzdušný prostor USA vysílat svou polohu pomocí systému ADS-B. To znamená, že tato letadla musejí být vybavena minimálnˇe podˇcástí ADS-B OUT. Pˇríslušné právní pˇredpisy budou k dispozici bˇehem

4.10. VYUŽITÍ ADS-B V PROJEKTU DAMMAE

77

Obrázek 4.33: Pokrytí v Evropˇe, zdroj: [18] roku 2013. [38] Primárnˇe je plánovan datový spoj 1090 MHz Mode S Extended Squitter, pro všeobecné letectví UAT.

4.10

Využití ADS-B v projektu DaMMaE

ˇ Se systémem ADS-B se v první fázi projektu DaMMaE nepoˇcítá, nebot’ v Ceské republice není zatím dostupné pokrytí. Navíc je tento systém pro plánované použití (hobby úˇcastník˚u projektu) zbyteˇcný, nebot’ nebude provozován v provozu a v rˇízeném prostoru. Pˇri komerˇcním využití by však bylo vhodné tento systém do letounu implementovat, protože není vybaven žádným jiným systémem pro komunikaci s rˇízením letového provozu (Mod S, TCAS, ...). Dokud nebude místo provozování pokryto systémem ADSB, lze pomocí zaˇrízení na palubˇe komunikovat s rˇízením letového provozu. Po instalaci pozemních stanic se budou moci služby systému plnˇe využít.

Kapitola 5

Realizace 5.1

Identifikace pˇrenášených parametru˚

Na malých letadlech a na bezpilotních prostˇredcích je nutné pˇrenášet obrovské množství informací. Z tohoto d˚uvodu se tato práce bude soustˇredit na parametry nutné pro rˇízení malého bezpilotního prostˇredku, který je nastínˇen v kapitole 1.1.

5.1.1

První fáze projektu

V první fázi projektu se poˇcítá s pouhým testováním letových vlastností letounu. K ˇrízení letounu bude použita klasická modeláˇrská souprava. Komunikace mezi bezpilotním prostˇredkem a stanovištˇem nebude v této fázi realizována. Sbˇer informací bude probíhat pouze lokálnˇe na palubˇe letounu a po absolvování letu budou tato data stažena do poˇcítaˇce, kde budou vyhodnocena. Bˇehem této fáze projektu se budou monitorovat tyto parametry: • polohy ˇrídících ploch: – poloha výškovky; – poloha kˇridélek (levého a pravého); • stav baterie: – 30% nabití; – kritická úroveˇn; • poloha v prostoru ze systému GPS;

78

ˇ 5.1. IDENTIFIKACE PRENÁŠENÝCH PARAMETRU˚

79

• motorové údaje: – teplota motoru; – otáˇcky vrtule. V této fázi projektu se poˇcítá s co nejmenšími finanˇcními náklady a co nejuniverzálnˇejším rˇešením kv˚uli pˇrípadným nutným zmˇenám v konfiguraci, které jistˇe budou zapotˇrebí po vyhodnocení letových vlastností letounu. Z tohoto d˚uvodu je velmi vhodným ˇrešením pˇrímé spojení vývojové desky Arduino Duemilanove s jednotlivými monitorovanými bloky, které je popsáno v kapitole 5.1.3

5.1.2

Druhá fáze projektu

V druhé fázi projektu se budou na bezpilotním prostˇredku pˇrenášet tyto parametry: • údaje aerometrického systému: – skuteˇcná vzdušná rychlost; – kalibrovaná vzdušná rychlost; – vertikální rychlost; – barometrická výška; – teplota okolního prostˇredí; • údaje autopilota: – pˇríkazy k jednotlivým akˇcním prvk˚um (motor, ˇrídící plochy); • stav baterie; • poloha v prostoru; • motorové údaje: – teplota motoru; – otáˇcky vrtule; – pˇríkazy pro nastavení práce motoru; • polohy ˇrídících ploch: – polohu výškovky; – polohu kˇridélek (levého a pravého); – pˇríkazy pro nastavení jednotlivých ploch.

KAPITOLA 5. REALIZACE

80

5.1.3

Pˇrenášení parametru˚ pomocí vývojové desky Arduino

V první fázi projektu bude použita vývojová deska Arduino Duemilanove, jejíž popis je uveden v kapitole 5.2. Pˇri testování se budou data uvedená v kapitole 5.1.1 ukládat na mikroSD kartu, která je umístˇená na Ethernet Shieldu. Po absolvování letu se data jednoduše stáhnou do osobního poˇcítaˇce, kde se vyhodnotí. Zapojení bude realizováno dle obrázku 5.1, použité porty pro senzory jsou uvedeny v tabulce 5.1.

Obrázek 5.1: Schéma pˇripojení blok˚u k vývojové desce Arduino Duemilanove, zdroj: autor

Tabulka 5.1: Senzory analogových veliˇcin Senzor Parametr 1 Teplota motoru 2 Otáˇcky vrtule 3 Poloha výškového kormidla 4 Poloha levého kˇridélka 5 Poloha pravého kˇridélka 6 Nepoužito

5.1.4

Pˇrenášení parametru˚ po sbˇernici CAN

Realizace se sbˇernicí je v první fázi projektu zbyteˇcná, protože levnˇejší a plnˇe dostaˇcující rˇešení je pomocí samostatné vývojové desky Arduino Duemilanove. Využití sbˇernice je tedy vhodnˇejší až v druhé fázi. V pˇrípadˇe využití sbˇernice CAN s aplikaˇcní vrstvou CANaerospace jsou identifikace základních parametr˚u v protokolu CANaerospace uve-


81

deny v tabulce 5.2. Schéma propojení snímaˇcu˚ parametr˚u se sbˇernicí CANaerospace je na obrázku 5.2. Tabulka 5.2: Identifikace parametr˚u v protokolu CANaerospace Parametr Jednotka CAN ID decimálnˇe hexadecimálnˇe skuteˇcná rychlost letu ms−1 316 13C −1 kalibrovaná rychlost letu ms 317 13D vertikální rychlost ms−1 314 12A teplota okolního vzduchu K 335 14F barometrická výška m 322 142 teplota motoru K 512 200 otáˇcky vrtule m−1 700 2BC poloha výškovky stupnˇe 308 134 poloha levého kˇridélka stupnˇe 309 135 poloha pravého kˇridélka stupnˇe 310 136 GPS zemˇepisná šíˇrka stupnˇe 1036 40C GPS zemˇepisná délka stupnˇe 1037 40D GPS výška nad elipsoidem m 1038 40E GPS ground speed ms−1 1039 40F napˇetí baterie V 920 398 Na základˇe tˇechto parametr˚u lze již daný bezpilotní prostˇredek provozovat, nebot’ jej lze rˇídit za letu bez nutnosti využití modeláˇrské soupravy. Nejd˚uležitˇejší parametry, které se budou po sbˇernici pˇrenášet, jsou polohy jednotlivých rˇídících ploch a pokyny pro jejich nastavení. Díky tˇemto signál˚um se ovládá smˇer a výška letu letadla. Tyto ˇrídící plochy bude ovládat autopilot, v pˇrípadˇe jeho výpadku pˇrejde letoun do manuálního rˇízení pomocí obsluhy na pozemním stanovišti. Letoun je vybaven pouze dvˇema ˇrídícími plochami, výškovkou umístˇenou na pˇredním kˇrídle (letoun je typu kachna) a kˇridélky na zadním kˇrídle. Ovládání letounu pomocí rˇídících ploch je detailnˇe popsáno napˇr. v [28, 45]. Další d˚uležitý parametr je poloha v prostoru. Ta se pomˇernˇe pˇresnˇe urˇcí pomocí GPS. Po sbˇernici se tak bude pˇrenášet GPS zemˇepisná šíˇrka a GPS zemˇepisná délka. Pomocí GPS lze zjišt’ovat také výšku letounu, jako záloha m˚uže sloužit barometrická výška vypoˇctená v aerometrickém systému na základˇe mˇerˇení statického a dynamického tlaku. Dalším parametrem, který lze na základˇe tˇechto tlak˚u pˇrenášet, je rychlost. Také tento údaj je zpracováván v aerometrickém systému letounu. Rychlost není pro plánované využití letounu (koníˇcek zúˇcastnˇených v létání s modely) tak d˚uležitá, jelikož je ale na letounu plánované snímání obou tlak˚u, lze tento parametr sledovat také. Více o aerometrickém systému napˇr. v [27, 28, 57].


82

Obrázek 5.2: Propojení jednotlivých blok˚u se sbˇernící CANaerospace, zdroj: autor

D˚uležité je také sledování stavu baterie. Tato baterie napájí motor, po vybití baterie by došlo ke ztrátˇe ovládání letounu. Nejd˚uležitˇejším parametrem je v tomto pˇrípadˇe vˇcasné varování kritické úrovenˇe nabití baterie, která záleží na konkrétním výbˇeru napájecí baterie. Dalším užiteˇcným parametrem je signalizování 30% úrovnˇe nabití baterie. Pˇri této signalizaci je nutné, aby se letoun zaˇcal navádˇet na místo, kde lze bezpeˇcnˇe pˇristát. Motorové parametry navrhnutého bezpilotního prostˇredku jsou oproti komerˇcním letadl˚um znaˇcnˇe omezené. Pro daný úˇcel bohatˇe staˇcí pˇrenášet teplotu motoru, aby nedošlo k jeho zniˇcení a následnému pádu letounu. D˚uležitým parametrem jsou také otáˇcky vrtule, pomocí které lze urˇcit, zda motor na vrtuli v˚ubec pˇrenáší nˇejaký výkon. Posledním signálem, který se musí pomocí sbˇernice pˇrenášet, jsou pokyny pro regulátor motoru, který ovládá výkon motoru pro pˇrechod do jednotlivých fází letu. Na sbˇernici bude také pˇripojena jednotka ˇrídící pˇríjem a vysílání dat z/na pozemní stanovištˇe. Tato jednotka bude pˇrijímat data po sbˇernici a rˇídit jejich vysílání na pozemní stanovištˇe. Dále bude pˇrijímat data z pozemního stanovištˇe, která bude vysílat na sbˇernici, aby byla pˇredána jednotce, které jsou data urˇcena.


83

Z pozemního stanovištˇe se budou vysílat tato data: • nastavení poloh ˇrídích ploch; • nastavení motoru. V pˇrípadˇe dalšího rozvíjení projektu DaMMaE na komerˇcní využití lze soubor tˇechto dat kdykoliv rozšíˇrit pomocí dodateˇcného pˇripojení potˇrebné jednotky na sbˇernici a pˇridˇelení ID potˇrebnému parametru. Díky této možnosti je zvolený systém velmi flexibilní a poˇcáteˇcní investice nejsou tak vysoké jako v pˇrípadˇe, že by byl požadavek pˇrenášet veškerá možná data hned na zaˇcátku projektu.

5.1.5

Rozšíˇrení projektu

Rozšíˇrení projektu po splnˇení druhé fáze je možné na oblast komerˇcního využití. Podmínek pro komerˇcní využití projektu DaMMaE je nˇekolik. 5.1.5.1

Legislativní podmínky

Pro možné komerˇcní využití projektu DaMMaE by bylo potˇreba do projektu zahrnout ˇ nutné komunikaˇcní vybavení pro spojení s Rízením letového provozu, které je nutné pro vstup letounu do ˇrízeného vzdušného prostoru. V souˇcasné dobˇe je letoun navrhnut pro provoz v neˇrízeném vzdušném prostoru (rozdˇelení vzdušného prostoru viz [6, 1]). Další nutnou podmínkou pro vstup do rˇízeného vzdušného prostoru je zahrnutí vybavení pro bezpeˇcnost a pˇrehled – systémy pracující s módem S, TCAS nebo ADS-B. 5.1.5.2

Podmínky pro vybavení letounu

Aby byl v komerˇcní sféˇre v˚ubec zájem o tento projekt, je d˚uležité mít zájemc˚um co nabídnout. Prvním a na první pohled nejd˚uležitˇejším parametrem je samozˇrejmˇe cena. Pˇri odhlédnutí od požadavku co nejnižší ceny, musí letoun „nˇeco umˇet“. Proto by projekt mohl být, dle cílové skupiny, vybaven prostˇredky pro sbˇer informací, napˇr.: • optickými prostˇredky – kamerou, fotoaparátem; • prostˇredky pro infraˇcervené spektrum; • senzory radiace a r˚uzných chemických látek; • radiolokaˇcními prostˇredky; • prostˇredky pro radiový pr˚uzkum; • a dalšími, pro r˚uzné cílové skupiny atraktivními prostˇredky.


84

Samozˇrejmˇe všechny tyto prostˇredky jsou relativnˇe drahé, nˇekteré více, jiné ménˇe, a proto nejsou zahrnuty v základním projektu. V pˇrípadˇe podnikatelských zájm˚u nˇekterého z úˇcastník˚u projektu není neˇrešitelný problém tyto prostˇredky do letounu zastavˇet. Další možnosti se mohou objevit pˇri pˇrípadném konkrétním zadání ze strany zájemce o letoun.

5.2

Realizace s vývojovou deskou Arduino

Vývojové desky Arduino vytvoˇrila firma Smart Project v roce 2005. Velkou výhodou vývojových desek Arduino je, že mají otevˇrenou architekturu, tzv. „open-source“. To znamená, že jsou k dispocizi podrobná schémata jejich zapojení a další dokumentace a výrobce dal výslovné svolení s tím, že je možné vývojovou desku libovolnˇe upravovat. Toto svolení pro Arduino zajišt’uje licence Creative Commons Attribution Share-Alike 2.5. Upravovaná zaˇrízení se ovšem nesmˇejí jmenovat Arduino, ale v jejich názvu se vždy objevuje výraz „duino“, napˇr. FreeDuino, Seeduino a podobnˇe. Pomocí pˇrídavných periferií, tvz. štít˚u (shields), lze k tˇemto deskám pˇripojit témˇerˇ cokoliv, vˇcetnˇe snímaˇcu˚ , relé, pamˇet’ových karet, ethernetového rozhraní. Právˇe ethernetové rozhraní bude využito pˇri realizaci pˇrenosu dat mezi pozemním stanovištˇem a letounem.

5.2.1

Hardware

Základem vývojové desky Arduino je mikrokontrolér ATmega s architekturou AVR. AVR jsou osmibitové procesory typu RISC s hardvardskou architekturou, což znamená, že mají oddˇelený pamˇet’ový prostor pro program a pro data. Na mikrokontroléru jsou umístˇené i nˇekteré periferie, cˇ asovaˇce, sériové a paralelní porty, A/D pˇrevodníky a další. Na desce Arduino je dále umístˇeno nˇekolik obvod˚u, pˇredevším stabilizátory napájecího napˇetí a obvody, které zajišt’ují komunikaci s PC, na typu Duemilanove je umístˇen USB port.

5.2.2

Software

Programy pro vývojové desky Arduino lze psát v programech urˇcených pro architekturu AVR. Další možností je využití software, který pro tuto desku vyvinuli její autoˇri. Programovací jazyk se jmenuje Arduino Programmable Language a je založen na jazyce Wiring. Je to jazyk vzniklý z jazyka C, ale odráží specifické požadavky na vývoj software pro jednoˇcipová zaˇrízení. Nespornou výhodou software pro vývojové desky Arduino je, že je vytvoˇrena verze nejen pro Windows, ale také pro varianty Linux. V prostˇredí Debian lze software velmi

5.2. REALIZACE S VÝVOJOVOU DESKOU ARDUINO

85

jednoduše nainstalovat pomocí pˇríkazu: sudo apt-get install arduino

5.2.3

Arduino Duemilanove

Arduino Duemilanove je vývojová deska s mikrokontrolérem ATmega168 [32] nebo ATmega328 [31]. Schéma této vývojové desky je v pˇríloze A, zdroj: [25]. Na vývojové desce je umístˇeno 14 digitálních vstupnˇe-výstupních pin˚u, 6 analogových výstup˚u, konektor USB, napájecí konektor, ICSP header a resetovací tlaˇcítko. Díky rozhraní USB lze snadno pˇripojit desku k poˇcítaˇci, desku lze pˇres USB také napájet. Další možností napájení je pomocí adaptéru nebo baterie, které lze pˇripojit na napájecí konektor. 5.2.3.1

Specifikace

Základní parametry vývojové desky Arduino Duemilanove jsou uvedeny v tabulce 5.3. V tabulce 5.4 jsou uvedeny hodnoty pamˇetí pro jednotlivé mikrokontrolery. [25] Tabulka 5.3: Základní parametry vývojové desky Arduino Duemilanove Parametr Hodnota Mikrokontroler ATmega168/ATmega328 Operaˇcní napˇetí 5V Vstupní napˇetí (doporuˇcené) 7-12 V Vstupní napˇetí (limitní) 6-20 V Digitální vstupnˇe-výstupní piny 14 Analogové vstupní piny 6 Stejnosmˇerný proud na vstupnˇe-výstupní pin 40 mA Stejnosmˇerný proud na 3.3 V pin 50 mA Takt 16MHz

Tabulka 5.4: Porovnání pamˇetí mikrokontrolér˚u ATmega168 a ATmega328 Parametr ATmega168 ATmega328 Flash pamˇet’ 16 kB 32 kB SRAM 1 kB 2 kB EEPROM 512 B 1 kB Vývojová deska je vybavena USB pro pˇripojení k PC, další možností pˇripojení je sériový port RS 232 za pˇredpokladu použití pˇrevodníku úrovní.


86

Ze 14 digitálních vstupnˇe-výstupních pin˚u je 6 s podporou pulsnˇe šíˇrkové modulace (Pulse Width Modulation, PWM). 5.2.3.2

Napájení

Vývojová deska Arduino Duemilanove m˚uže být napájena pˇres USB konektor nebo pomocí externího zdroje, pˇripojeného k napájecímu konektoru. Volba mezi tˇemito dvˇemi možnostmi je provádˇena automaticky. Deska m˚uže pracovat v rozsahu napˇetí od 6 až do 20 V, ale pokud je napájena ménˇe než 7 V (v pˇrípadˇe napájení pˇres USB ménˇe než 5 V) není zaruˇcena správná funkce desky; a pˇri použití více než 12 V se m˚uže pˇrehˇrívat regulátor napˇetí a deska se m˚uže zniˇcit. Proto je doporuˇcený rozsah napˇetí od 7 do 12 V. Napájecí piny jsou: • VIN – slouží pro pˇripojení externího zdroje napˇetí. • 5V – regulovaný zdroj napˇetí používaný k napájení mikrokontroléru nebo jiných souˇcástí na desce. Napˇetí 5 V m˚uže být získáno skrz pin VIN a regulátor umístˇený na desce nebo díky pˇripojenému USB nebo jiným regulovaným 5 V zdrojem napˇetí. • 3V3 – Napˇetí 3,3 V generované na cˇ ipu FTDI na desce. Maximální proud je 50mA. • GND – uzemnˇení. 5.2.3.3

Vstupnˇe-výstupní piny

Každý ze 14 digitálních pin˚u m˚uže být použit jako vstup i jako výstup. Piny jsou napájeny 5 V, maximální proud je 40 mA a vnitˇrní odpor je 20 − 50 kΩ. Následující piny mají urˇcenou funkci: • Pin 0 (RX) a 1 (TX) - slouží pro pˇríjímání (RX) a odesílání (TX) sériových dat (TTL úrovnˇe). Tyto piny jsou pˇripojeny ke korespondujícím pin˚um na cˇ ipu pro komunikaci po USB. • Pin 2 a 3 - slouží pro obsluhu vnˇejšího pˇrerušení. • Piny 3, 5, 6, 9, 10 a 11 - piny poskytující na výstupu pulsnˇe šíˇrkovou modulaci. • Piny 10, 11, 12 a 13 - piny podporující SPI komunikaci. • Pin 13 - na pin 13 je pˇripojena LED dioda.

5.2. REALIZACE S VÝVOJOVOU DESKOU ARDUINO 5.2.3.4

87

Analogové piny

Arduino Duemilanove má 6 vstupních analogových vstup˚u, každý s rozlišením 10 bit˚u. Standardnˇe mˇerˇí v rozsahu 0-5 V, ale tento rozsah lze zmˇenit pomocí pinu AREF - tento pin je zdrojem referenˇcního napˇetí. Piny 4 a 5 slouží pro komunikaci na I 2C.

5.2.4

Arduino Ethernet Shield

Arduino Ethernet Shield slouží, jak už název napovídá, k pˇripojení na internet. Jako Ethernet rˇadiˇc je použit cˇ ip WIZnet W5100 [59], který integruje IP stack pro UDP i pro TCP. Tento shield je plnˇe kompatibilní s vývojovou deskou Arduino Duemilanove a komunikuje s ní pomocí SPI sbˇernice na pinech 11, 12 a 13. Na desce je umístˇen standardní konektor pro Ethernet - RJ45. Na aktuální verzi Arduino Ethernet Sheild je umístˇen také slot na mikroSD kartu, na kterou lze ukládat data. Pˇri komunikaci s Ethernet Shieldem a deskou Duemilanove lze pomocí pin˚u 10 a 4 rozhodnout, zda se budou data ukládat na mikroSD kartu (pin 4) nebo se pošlou na Ethernet (pin 10). Protože jak Ethernet tak mikroSD karta používají stejné piny pro komunikaci na SPI sbˇernici, m˚uže být v jednu chvíli aktivní pouze jeden z nich. Schéma Arduino Ethernet Shield je uvedeno v pˇríloze B, zdroj: [26].

5.2.5 5.2.5.1

Pˇrenos dat Analogové vstupy

Analogové vstupy jsou na letounu uvedeny v tabulce 5.1. Teplota motoru se mˇeˇrí pomocí termistoru, který musí být vhodnˇe zvolen tak, aby odpovídal pracovním teplotám zvoleného motoru. Mˇerˇení teploty pomocí termistoru je založeno na zmˇenˇe odporu termistoru pˇri zmˇenˇe teploty. Proto lze snímaˇc teploty snadno simulovat pomocí potenciometru. Ten byl pˇripojen na analogový vstup A0 a zmˇena jeho odporu byla vysílána pomocí Ethernetu do osobního poˇcítaˇce, kde byla zobrazena. Schéma simulace je uvedeno na obrázku 5.3. Algoritmus odeslání analogového vstupu na Ethernet: #include <Ethernet.h> byte mac[] = {0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA};

//definice MAC adresy

byte ip[] = {192, 168, 0, 2};

//definice IP adresy

float senzor; Server server = Server(23);

//definice TCP portu


88

void setup() { Ethernet.begin(mac, ip);

//inicializace TCP/IP stacku

server.begin();

//inicializace Telnet serveru

} void loop() { Client client = server.available(); if (client) { server.print("SENZOR1: "); senzor = analogRead(0);

//cteni analogoveho vstupu

server.print(senzor * 100);

//matematicka uprava hodnoty //a jeji vypis

server.println(" Ohm"); delay(2500);

//interval provadeni vypisu

}}

K dispozici jsou také výstupy z PWM, pomocí kterých lze ovládat „analogové velicˇ iny“, napˇr. nastavení úhlu klapek.

Obrázek 5.3: Schéma simulace teploty, zdroj: autor 5.2.5.2

Digitální vstupy

ˇ Ctení digitálních vstup˚u probíhá stejným zp˚usobem jako cˇ tení analogových vstup˚u. V algoritmu se musí navíc pouze definovat pin, ze kterého se má cˇ íst jako vstupní (zde pin 5): pinMode(5, INPUT);

a pro cˇ tení digitalního vstupu se použije pˇríkaz: senzor = digitalRead(0);

Na letounu se digitální vstup bude používat pro signalizaci 30% a kritického napˇetí baterie.

5.2. REALIZACE S VÝVOJOVOU DESKOU ARDUINO 5.2.5.3

89

Digitální výstupy

Jako digitální výstup byla použita LED dioda, která se ovládala z osobního poˇcítaˇce pˇres Ethernet. Ethernet Shield má v sobˇe již implementovánu LED diodu, byla ovšem použita externí LED dioda, aby se prokázalo možnost ovládání externích periférií pˇripojených k vývojové desce Arduino. Algoritmus ovládání digitálních výstup˚u:

#include <Ethernet.h> #define LED 5 byte mac[] = {0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA}; byte ip[] = {192, 168, 0, 2}; Server server = Server(23); void setup() { pinMode(LED, OUTPUT); Ethernet.begin(mac, ip); server.begin(); } void loop() { Client client = server.available(); if (client) { if (client.read()==’1’) { digitalWrite(LED, HIGH); return; } if (client.read()==’0’) { digitalWrite(LED, LOW); return; }}}

5.2.6

Arduino Mega 2560

V pˇrípadˇe nedostateˇcného množství analogových a digitálních vstup˚u/výstup˚u lze místo vývojové desky Arduino Duemilanove použít desku Arduino Mega 2560, která je plnˇe kompatibilní s Arduino Ethernet Shieldem a jejíž algoritmy pro zpracování dat jsou shodné s algoritmy Arduina Duemilanove. Hlavní rozdíl spoˇcívá v poˇctu analogových a digitálních vstup˚u a výstup˚u. Srovnání tˇechto dvou vývojových desek uvádí tabulka 5.5.


90

Tabulka 5.5: Srovnání Arduino Duemilanove a Arduino Mega 2560 Parametr Duemilanove Mega 2560 [poˇcet pin˚u] [poˇcet pin˚u] Analogové vstupy 6 16 Digitální vstupy/výstupy 14 54 Výstupy s PWM 6 14 Sériová komunikace 1 4

Tato vývojová deska nebyla poˇrízena z d˚uvod˚u vyšší ceny (1230 Kˇc oproti 570 Kˇc pro Arduino Duemilanove 1 ). Další informace o této desce viz [16].

5.3

Realizace pomocí CAN sbˇernice

Další možností realizace je umístit na palubu letounu CAN sbˇernici popsanou v kapitole 2.2 a s aplikaˇcní vrstvou CANaerospace, která je pospána v kapitole 2.4. Návrh sbˇernice pro druhou fázi projektu je zobrazen v kapitole 5.1.4 na obrázku 5.2. Z obrázku je patrné, že je nutné na sbˇernici pˇripojit jednotku, která bude data vysílat a pˇrijímat ze zemˇe. Jedním ze zp˚usob˚u, jak na sbˇernici takovou jednotku pˇripojit, je pˇrevodník mezi CAN a RS 232, nebot’ po RS 232 již komunikuje celá rˇada zaˇrízení, která jsou schopna komunikovat s pozemní jednotkou, napˇr. radiový modul HW86012 (viz 3.1.1.2). Návrh sbˇernice s radiovým modulem je na obrázku 5.4, návrh s Arduinem na obrázku 5.5.

Obrázek 5.4: Propojení sbˇernice CAN a modulu HW 86012, zdroj: autor

Na obrázcích je vidˇet, že pˇri realizaci s vývojovou deskou Arduino Duemilanove je nutné implementovat více blok˚u. Ovšem koneˇcná cena realizace s Arduinem je ve srovnání s realizací s radiovým modulem HW 86012 daleko menší, viz tabulka 5.6. 1 http://www.czechduino.cz/?arduino,23

ˇ 5.3. REALIZACE POMOCÍ CAN SBERNICE

91

Obrázek 5.5: Propojení sbˇernice CAN a desky Arduino Duemilanove, zdroj: autor

Tabulka 5.6: Finanˇcní náklady varianty s radiovým modulem a s Arduinem Duemilanove Rádiový modul HW86012 Arduino Duemilanove Arduino Duemilanove 570 Kˇc modul na letadle 5 000 Kˇc Arduino Ethernet Shield 930 Kˇc modul na zemi 5 000 Kˇc MAX232 100 Kˇc Access Point 500-1 000 Kˇc Celkem 10 000 Kˇc 2 100-2 600 Kˇc

5.3.1

Simulace pomocí Matlabu

Z obrázk˚u 5.4 a 5.5 je patrné, že je nutné mít k dispozici pˇrevodník z RS 232 na CAN. V následujících odstavcích je popsán popis simulací, které nakonec vyústily v návrh pˇrevodníku z RS 232 na CAN na mikroprocesoru Freescale HC12. 5.3.1.1

USB2CAN pˇrevodník

Byl odzkoušen pˇrenos mezi dvˇemi sériovými zaˇrízeními. Prvním sériovým zaˇrízením byl modul GPS Navilock NL-202. V poˇcítaˇci byly vytvoˇreny dva virtuální sériové vzájemnˇe propojené porty (Null-modem). Celý pˇrenos byl proveden pomocí programu Matlab. Schéma situace je zobrazeno na obrázku 5.6.

Obrázek 5.6: Schéma pˇrenosu USB-Matlab-RS 232, zdroj: autor Na obrázku 5.6 je vidˇet, že modul GPS byl pˇripojen na portu COM5. Vytvoˇrené virtuální porty byly operaˇcním systémem identifikovány jako COM20 a COM21. V pro-


92

stˇredí Matlab byl pro odeslání dat z modulu GPS na „vzdálený terminál“ vytvoˇren následující algoritmus:

// inicializace GPS gps = serial(’COM5’); set(gps, ’BaudRate’, 4800); set(gps, ’DataBits’, 8); set(gps, ’Parity’, ’none’); set(gps, ’StopBits’, 1); set(gps, ’FlowControl’, ’none’);

//nastaveni parametru seriove komunikace

set(gps, ’InputBufferSize’, 390); set(gps, ’OutputBufferSize’, 512);

//nastaveni input/output bufferu

fopen(gps) // inicializace RS 232 com = serial(’COM20’); set(com, ’BaudRate’, 4800); set(com, ’DataBits’, 8); set(com, ’Parity’, ’none’); set(com, ’StopBits’, 1); set(com, ’FlowControl’, ’none’); set(gps, ’Timeout’, .1); set(gps, ’InputBufferSize’, 512); set(gps, ’OutputBufferSize’, 390); fopen(com) // GPS --> COM20 while 1 fwrite(com, fread(gps));

//kopirovani jednoho rozhrani na druhe

end //ukonceni programu a uvolneni prostredku fclose(com); fclose(gps);

//uzavreni seriovych spojeni

fdelete(com); fdelete(gps);

//smazani odpovidajicich objektu

Pro pˇrenos CAN protokolu by došlo k modifikaci vstupnˇe/výstupních buffer˚u tak, aby nedocházelo k zahazování zpráv a pˇritom nevznikala zbyteˇcná prodleva (maximální velikosti CAN zprávy).


93

Virtuální porty byly vytvoˇreny pomocí programu Advanced Virtual COM Port2 , na obrázku 5.7 je zobrazeno prostˇredí programu. Na obrázku je taky vidˇet, že data pˇrijatá na port COM 20 byla odeslána na port COM21 a naopak.

Obrázek 5.7: Komunikace pˇres Virtual Null-modem, zdroj: autor Na obrázku 5.8 je zobrazen terminál, na který se data z modulu GPS pˇres 2 sériová rozhraní posílala. Jde o surová data, která modul GPS posílá (zprávy NMEA protokolu), nebot’ zpracování dat ze systému GPS není náplní této práce. Pˇri použití USB2CAN pˇrevodníku místo modulu GPS lze použít Matlab-To-Can Toolbox, který umožˇnuje komunikaci sbˇernice CAN z prostˇredí Matlabu. V tomto pˇrípadˇe by došlo k modifikaci výše zmínˇeného algoritmu a k použití funkcí: • CAN_Open; • CAN_Send; • CAN_Receive; • CAN_Close. Popis Toolboxu, jednotlivých funkcí a jejich syntaxe je uvedena v [43]. 2 http://www.AdvancedVirtualComPort.com/index.html


94

Obrázek 5.8: Výstup simulace - RS 232 terminál, zdroj: autor 5.3.1.2

Komunikaˇcní protokol CAN - RS 232

Pro realizaci s použitím sbˇernice CAN je potˇreba pˇrevést CAN zprávu na sériovou linku RS 232. Protože standard RS 232 je pouze fyzická vrstva v modelu ISO/OSI, je nutné definovat komunikaˇcní protokol, viz obrázek 5.9.

Obrázek 5.9: Schéma propojení CAN sbˇernice a sériového rozhraní RS 232, zdroj: autor Návrh vychází z komunikaˇcního protokolu SPINEL od firmy Papouch. Jeho detailní specifikaci lze nalézt v [51].

Obecný popis Protokol SPINEL lze rozšiˇrovat a modifikovat. Modifikované protokoly jsou oznaˇcovány jako formáty. Každý formát je oznaˇcen cˇ íslem, pro ASCII kódování cˇ íslem mezi 0 až 96, pro binární kódování 97 až 255. Zaˇrízení mohou podporovat nˇekolik formát˚u protokolu. Data jsou pˇrenášena v rámcích (paketech) s definovaným zaˇcátkem.


95

Obecný formát pro binární kódování Obecný formát je na obrázku 5.10. Popis jednotlivých byt˚u je uveden v tabulce 5.7, [51].

Obrázek 5.10: Obecný formát pro binární kódování, zdroj: autor dle [51]

Tabulka 5.7: Byty v obecném formátu binárního kódování Byte Popis PRE Prefix (0x2A) ˇ Císlo formátu FRM NUM Poˇcet byt˚u dat SDATA Data CR Zakonˇcovací znak (0x0D) Navržený formát komunikaˇcního protokolu CAN - RS 232 vychází ze SPINEL binárního formátu 97. Byl upraven tak, aby obsahoval pouze informace potˇrebné pro pˇrenos CAN zpráv. Pro návrh modifikovaného formátu bylo vybráno cˇ íslo 185. Návrh formátu cˇ íslo 185

Návrh formátu pro pˇrenos zpráv CAN - RS 232 je na ob-

rázku 5.11. Byty oznaˇcené stejnˇe jako byty v obecném formátu mají stejný význam. ˇ Císlo formátu je 185, tedy B9 hexadecimálnˇe. Popis ostatních byt˚u je uveden v tabulce 5.8.

Obrázek 5.11: Návrh formátu cˇ íslo 185, zdroj: autor

Tabulka 5.8: Popis byt˚u navrhnutého formátu cˇ íslo 185 Byte Popis cnLENGHT Urˇcuje poˇcet byt˚u v CAN zprávˇe cnID ID CAN zprávy cnDATA Data CAN zprávy Byte cnLenght obsahuje pole DLC v CAN zprávˇe (4 bity, viz 2.2.3.1), které je doplnˇené na byte. První pole NUM bude v tomto pˇrípadˇe vždy nulové. Byty cnID1 a cnID2 pˇrenášejí identifikátor CAN zprávy. Identifikátor ve standardním formátu tvoˇrí 11 bit˚u, proto je nutné jej pˇrenášet ve dvou bytech. Byty cnDATA1 až cnDATA8 odpovídají datovému poli v CAN zprávˇe.


96

Nejprve je nutné jednotlivá pole v CAN zprávˇe rozdˇelit na pˇríslušné byty. Byl navržen tento algoritmus: // Vyhledani zacatku zpravy: // konec zpravy (End of Frame) - 1111111 // mezera mezi zpravami - 111 // zacatek zpravy (Start of Frame) - 0 // k = index, urcuje, kde zacina zprava k = strfind(rawData, ’11111111110’); k = k + 11; while k > 0 rawData = sscanf(rawData, ’%*1c %s’, 1); k = k - 1; end

// cnID = ID CAN zpravy, 11 bitu cnId = sscanf(rawData, ’%11c’, 1); cnId = bin2dec(cnId); k = 13; while k > 0 rawData = sscanf(rawData, ’%*1c %s’, 1); k = k - 1; end

// cnLength = delka CAN zpravy = pocet nasledujicich bitu (1-8) cnLength = sscanf(rawData, ’%4c’, 1); cnLength = bin2dec(cnLength); // rawData nyni zacinaji byty cnData rawData = sscanf(rawData, ’%*4c %s’, 1); k = cnLength; i = 1;

// cteni datovych bytu do cnData while k > 0 data = sscanf(rawData, ’%8c’, 1); data = bin2dec(data); rawData = sscanf(rawData, ’%*8c %s’, 1); cnData(i) = data; i = i + 1; k = k - 1; end


97

Simulace Pro otestování navrženého formátu byl v programu Matlab vytvoˇren algoritmus, který pˇrevádí CAN zprávy na zprávy urˇcené pro pˇrenos pomocí RS 232. Vstup a výstup pˇrevodníku simulují hexadecimální hodnoty uložené v souborech input.txt a output.txt. Po rozdˇelení CAN zprávy na byty dle pˇredchozího algoritmu se pošlou data na sériovou linku RS 232 dle algoritmu: PRE = ’2A’; FRM = ’B9’; CR = ’0D’; NULL = ’00’; NUM = strcat(’0’, dec2hex(3 + cnLength));

// 2x cnID + SUM

// prevedeni cnID na hexadecimalni retezec protokolu SPINEL HEXcnId = dec2hex(cnId); // vsechny prenasene CAN ID maji 3 HEX znaky - doplneni na 4 HEXcnId = strcat(’0’, HEXcnId);

// prevedeni cnData na hexadecimalni retezec protokolu SPINEL k = 1; HEXcnData = zeros(0); while k < cnLength + 1 data = dec2hex(cnData(k)); k = k + 1; HEXcnData = strcat(HEXcnData, data); end

outSpinelPacket = strcat(PRE, FRM, NULL, NUM, HEXcnId, HEXcnData, CR);

// zapsani zpravy CAN ve formatu 185 do vystupu file2 = fopen(’output.txt’, ’w’); fwrite(file2, outSpinelPacket);

// vycisteni programu fclose(file); fclose(file2);

5.3.2

Realizace na desce s procesorem Freescale HC12

Pro fyzickou realizaci pˇrenosu CAN zprávy na sériovou linku RS 232 byla využita deska Freescale HC12 demo board. Její schéma je uvedeno v pˇríloze C, zdroj: [42]. Deska je osazena mikrokontrolerem MC9S12XDT256MAA. Popis oznaˇcení mikrokontroleru:


98 • MC - oznaˇcení výrobce (Motorola); • 9 - typ použité pamˇeti (Flash); • S12 - oznaˇcení jádra procesoru; • XDT - oznaˇcení ˇrady; • 256 - velikost pamˇeti Flash; • M - rozsah pracovních teplot; • AA - oznaˇcení pouzdra.

Mikrokontroler je vybaven 16 bitovým jádrem s maximální taktovací frekvencí 80 MHz. Nabízí napˇr.: • rozhraní SCI (Serial Communications Interface); • rozhraní SPI (Serial Peripheral Interfaces); • rozhraní CAN sbˇernice; • rozhraní I 2C (Inter IC bus); • 10 bitový A/D pˇrevodník; • 59 vstupnˇe-výstupních pin˚u. Velikost pamˇetí mikrokontroleru uvádí tabulka 5.9 [10]. Tabulka 5.9: Pamˇeti mikrokontroleru MC9S12XDT256 Typ pamˇeti Velikost Flash EEPROM 256 kB EEPROM 4 kB RAM 16 kB Kompletní popis mikrokontroleru lze nalézt napˇr. v [10]. CodeWarrior K programování mikroprocesoru Freescale slouží vývojové prostˇredí CodeWarrior. V CodeWarrior lze programovat v jazyce symbolických adres (asembler) nebo v jazyce C/C++. Toto vývojové prostˇredí umožˇnuje vytvoˇrenou aplikaci spustit nejen v modulu, ale také pomocí simulace.

ˇ 5.3. REALIZACE POMOCÍ CAN SBERNICE Processor Expert

99

Pro nastavení mikrokontroléru, jeho registr˚u a periferií lze použít

v prostˇredí CodeWarrior utilitu Processor Expert. Nastavení se provádí pomocí volby vlastností z GUI nabídek v utilitˇe. Processor Expert vygeneruje odpovídající kód v jazyce C. Generuje také konkrétní funkce. Jejich voláním lze nastavit nebo pˇreˇcíst hodnoty vstupu/výstupu, zahájit pˇrevod A/D pˇrevodníku, spustit cˇ asování, vyslat nebo pˇrijmout byte ze sériového rozhraní. [56] Programátor USB BDM Multilink

Programátor poskytuje pˇrístup do BDM mikro-

kontroler˚u. BDM (Background Debug Mode) je sériové rozhraní, které umožˇnuje provozovat mikrokontroler v monitorovacím módu. Ten slouží pro testování a vývoj systému pˇrímo v aplikaci [50]. Pomocí USB a poˇcítaˇce lze ˇrídit cˇ tení/zápis do registr˚u, hodnoty pamˇetí, programovat zaˇrízení a další funkce. 5.3.2.1

Algoritmus realizace

Pomocí procesoru Freescale HC12 byl realizován pˇrevodník mezi CAN sbˇernicí a sériovou linkou RS 232. Zatím je podporován pouze standardní formát CAN zprávy (viz 2.2.3). Na sériovou linku jsou data posílány dle SPINEL formátu cˇ íslo 185 navrženého v 5.3.1.2. V rámci první fáze realizace bude mít navržený formát vždy pevnˇe danou délku - 15 byt˚u. Pokud bude tˇreba pˇrenášet kratší CAN zprávu, dojde k doplnˇení nul. V pˇrípadˇe dalšího využití pˇrevodníku je vhodné implementovat napˇr. mechanismy ošetˇrení chybových stav˚u, podporu zasílání žádosti o data nebo podporu pro rozšíˇrený formát CAN zpráv. Software

Verze použitých program˚u jsou shrnuty v tabulce 5.10. Tabulka 5.10: Software pro realizaci Software Verze Poznámka CodeWarrior 5.1 30 denní trial verze Processor Expert 3.02 Souˇcást CodeWarrior 5.1 PP2CAN3 2.540 Serial Port Terminal4 5.5 15 denní trial verze

Nastavení parametru˚ periferií Sériový port byl nastaven na rychlost 38 400 baud˚u, 8 datových bit˚u, bez parity, 1 stop bit a bez flow control. Rychlost CAN sbˇernice byla nastavena na 20 kbit/s.


100 Struktura projektu

Kromˇe zdrojových soubor˚u generovaných Processor Expertem

se projekt skládá z: • xdt.c - hlavní smyˇcka programu; • variables.c, variables.h - definice globálních promˇenných; • Events.c - obsluha pˇrerušení. Zdrojové kódy celého projektu jsou uloženy na pˇriloženém CD. Hlavní smyˇcka programu Hlavní program obsahuje pouze inicializaci periferií (funkce PE_low_level_init) a smyˇcku blikání zelené LED diody v intervalu jedné sekundy. void main(void) { // Processor Expert internal initialization. DON’T REMOVE THIS CODE!!! PE_low_level_init(); // End of Processor Expert internal initialization. for(;;) { // blikani zelene LED CPU_Delay100US(5000); Bit1_NegVal(); }

Pˇrerušení CAN_OnFullRxBuffer Tato pˇrerušovací rutina je volána v pˇrípadˇe zaplnˇení Input Bufferu CAN sbˇernice. Obsahuje naˇctení CAN zprávy, vygenerování zprávy ve SPINEL formátu 185 a její odeslání na RS 232. Odeslání sériové zprávy indikuje bliknutí cˇ ervené LED diody. void CAN_OnFullRxBuffer(void) { // lokalni promenne int k = 0; word sent = 0; // definice struktury navrzeneho SPINEL formatu struct SPI { byte PRE; byte FRM; byte NULA; byte LENGTH; byte ID1; byte ID2; byte DATA[9]; } spinel_msg;


101

// precteni CAN zpravy can_msg_read = CAN_ReadFrame(ptr_cnId, ptr_cnFrameType, ptr_cnFrameFormat, ptr_cnLength, cnData); // jen pro debug - odeslani prijmute CAN zpravy zpet // can_msg_send = CAN_SendFrameExt(cnId, cnFrameType, cnLength, ptr_cnData); // vytvoreni SPINEL zpravy pro RS232 dle navrzeneho formatu spinel_msg.PRE = 0x2A; // zacatek ramce PRE spinel_msg.FRM = 0xB9; // cislo spinel protokolu FRM spinel_msg.NULA = 0x00; // prvni byte NUM = vzdy "nula" spinel_msg.LENGTH = cnLength; // delka CAN zpravy if (cnId < 255) { spinel_msg.ID1 = 0x00; spinel_msg.ID2 = (byte) cnId; // pokud cnID zabira pouze 1 byte } else { spinel_msg.ID1 = (byte) (cnId / 256); // prvni byte cnID spinel_msg.ID2 = cnId % 256; // druhy byte cnID } // skutecna data for (k = 0; k < cnLength; k++) spinel_msg.DATA[k] = cnData[k]; // doplneni nulami, pokud je potreba for (k; k < 8; k++) spinel_msg.DATA[k] = 0x00; // konec ramce spinel_msg.DATA[k] = 0x0D;

// odeslani prijate CAN zpravy na RS232 i = AS1_SendBlock((byte*)&spinel_msg, sizeof(spinel_msg), &sent); // bliknuti cervenou LED Bit3_ClrVal(); CPU_Delay100US(500); Bit3_SetVal(); }

Pˇrerušení AS1_OnFullRxBuf

Tato pˇrerušovací rutina je volána v pˇrípadˇe zaplnˇení

Input Bufferu sériové linky RS 232. Obsahuje naˇctení zprávy ve SPINEL formátu 185 pevné délky 15 byt˚u, vygenerování odpovídající CAN zprávy a její odeslání na CAN sbˇernici. Odeslání CAN zprávy indikuje bliknutí žluté LED diody. void AS1_OnFullRxBuf(void) { // lokalni promenne int k; byte err; word received = 0;

102

KAPITOLA 5. REALIZACE // definice struktury navrzeneho SPINEL formatu struct SPI_READ { byte PRE; byte FRM; byte NULA; byte LENGTH; byte ID1; byte ID2; byte DATA[9]; } spinel_read_msg;

// nacteni SPINEL zpravy z RS232 err = AS1_RecvBlock((byte*)&spinel_read_msg, sizeof(spinel_read_msg), &received); // vytvoreni odpovidajici CAN zpravy cnId = (spinel_read_msg.ID1 * 256) + spinel_read_msg.ID2; cnLength = spinel_read_msg.LENGTH; for (k = 0; k < cnLength; k++) cnData[k] = spinel_read_msg.DATA[k]; // odeslani CAN zpravy na sbernici can_msg_send = CAN_SendFrameExt(cnId, cnFrameType, cnLength, ptr_cnData); // bliknuti zlutou LED Bit2_ClrVal(); CPU_Delay100US(500); Bit2_SetVal(); }

Kapitola 6

Závˇer Návrh bezpilotního prostˇredku je cˇ asovˇe velmi nároˇcná práce. V bˇežné praxi se na vývoji podílí velké množství lidí. Projektu DaMMaE se úˇcastnili pouze 4 lidé v rámci svých diplomových prací. Pˇresto se podaˇrilo návrh pro zamýšlený úˇcel dokonˇcit. Tato práce mˇela za úkol stanovit vhodné médium pro pˇrenos informací na letadle a mezi letadlem a pozemním rˇídícím stanovištˇem. Pro první fázi projektu byla zvolena realizace pomocí vývojové desky Arduino Duemilanove, které je pro sbˇer informací bˇehem letu vyhovující. Pro komunikaci mezi letounem a pozemním stanovištˇem byl zvolen standard 802.11. Pomocí mˇerˇení v reálném terénu bylo prokázano, že jeho dosah je dostateˇcný. Pro pˇrípadné rozšíˇrení a pokraˇcování projektu bylo navrhnuto robustnˇejší ˇrešení pomocí sbˇernice CAN. Pro komunikaci mezi letadlem a pozemním stanovištˇem s použitím sbˇernice CAN byl navrhnut pˇrevodník CAN - RS 232. S pomocí pˇrevodníku lze sbˇernici CAN pˇripojit k zaˇrízení pro zasílání dat na pozemní stanovištˇe. Toto zaˇrízení m˚uže být libovolné, kromˇe standardu 802.11 lze použít napˇríklad radiový modul DECT. Samotný pˇrevodník byl navržen a realizován na vývojové desce s procesorem Freescale HC12. Poslední cˇ ástí této práce bylo zvážení možnosti využití systému ADS-B. Systém je velmi zajímavý a sotisfikovaný. Pro využití na tak malém bezpilotním prostˇredku s daným využitím je ale zbyteˇcný.

103

104

ˇ KAPITOLA 6. ZÁVER

Literatura [1] Tˇrídy vzdušného prostoru. URL

vfrspacecz.gif> [2] User manual, Cordless Twin Port, HW8612 DECT, HW 8612/US FHSS. Höft and Wessel, 2001. [3] Controller Area Network (CAN). 2004. URL

files/cs/vyuka/predmety/x38psy/CANPopis.pdf> [4] Manual on VHF Digital Link (VDL) Mode 4. Internationl Civil Aviation Organization, 2004. [5] ADS-B Solutions. Euro Telematik AG, 2005. [6] AIP ENR 1.4 Klasifikace vzdušného prostoru ATS. 2006. URL [7] Application Note: Introduction to CAN. Renesas, 2006. [8] Datasheet Cisco Aironet 1200 Series Access Points. Cisco Systems, Inc., 2006. [9] Integration Manual, HW 86012 DECT Embedded Radio Module. Höft and Wessel, 2007. [10] MC9S12XDP512 Data Sheet. Freescale Semiconductor, 2007. [11] Technical Provisions for Mode S Services and Extended Squitter. Internationl Civil Aviation Organization, 2008. [12] Všeobecné pˇrijatelné zp˚usoby pr˚ukazu pro letovou zp˚usobilost výrobk˚u, letadlových cˇ ástí a zaˇrízení AMC 20. 2008. 105

LITERATURA

106

[13] Datasheet Cisco Aironet 2.4 GHz and 5 GHz Antennas and Accessories - Complete the Wireless Solution. Cisco Systems, Inc., 2009. [14] Manual on the Universal Access Receiver (UAT). Internationl Civil Aviation Organization, 2009. [15] Reference Guide Cisco Aironet Antennas and Accessories. Cisco Systems, Inc., 2009. [16] Arduino Board Mega 2560. 2010. URL [17] The CAN physical layer. 2010. URL [18] The CASCADE Programme. 2010. URL [19] CDTI-2000 The Multi-Function Display and Traffic Information System. Euro Telematik, 2010. ˇ [20] Letecký pˇredpis L 2, Pravidla létání. Ministerstvo dopravy Ceské republiky, zpracovatel Úˇrad pro civilní letectví, 2010. [21] Letecký pˇredpis o civilní letecké telekomunikaˇcní službˇe, Svazek III - komunikaˇcní ˇ systémy. Ministerstvo dopravy Ceské republiky, zpracovatel Úˇrad pro civilní letectví, 2010. [22] Next Generation Air Transportation System (NextGen). 2010. URL [23] Transport: What is the SESAR project? - European commision. 2010. URL [24] L 10/IV Pˇredpis o civilní letecké telekomunikaˇcní službˇe, Svazek IV. - Pˇrehledový ˇ radar a protisrážkový systém. Ministerstvo dopravy Ceské republiky, zpracovatel Úˇrad pro civilní letectví, 22. 11. 2007. [25] Arduino: Arduino Board Duemilanove. 2010. URL

ArduinoBoardDuemilanove>

LITERATURA

107

[26] Arduino: Arduino Board Duemilanove. 2010. URL

ArduinoEthernetShield> [27] kolektiv autor˚u: Studijní modul 5, Digitální technologie/elektronické pˇrístrojové systémy. Akademiké nakladatelství CERM, s.r.o., 2003. [28] kolektiv autor˚u: Studijní modul 13, Aerodynamika, konstrukce a systémy letadel. Akademiké nakladatelství CERM, s.r.o., 2005. [29] Brisbin, S.: Wi-fi ... postavte si svou vlastní wi-fi sít’. Neocortex, 2003. [30] Chavis, J. C.: What is a 3G Network? 2010. URL [31] Corporation, A.: 8-bit AVR Microcontroller with 4/8/16/32K Bytes In-System Programmable Flash. 2009. URL

documents/doc8161.pdf> [32] Corporation, A.: 8-bit AVR Microcontroller with 4/8/16K Bytes In-System Programmable Flash. 2009. URL

documents/doc2545.pdf> [33] Endsley, M. R.: Situation Awareness, Automation and Free Flight. Massachusetts Institute of Tehnology, 2005. [34] Fanshier, B.: MX20 color Multi-Function Display pilot’s guide. Garmin Ltd., 2006. [35] Heinz, K.: Flight companion CDTI. Euro Telematik, 2006. ˇ [36] Hovorka, P.: Návrh autopilota. Diplomová práce, CVUT Fakulta dopravní, 2010. [37] Kárász, P.: Návrh a konstrukce draku bezpilotního prostˇredku DaMMaE. Diploˇ mová práce, CVUT Fakulta dopravní, 2010. [38] McHale, J.: ADS-B In brings air traffic control elements to the cockpit. 2010. URL

sessionID=5E703D1FBED634C1164482C87&cid=1325507&eid= 14957&pg=16&mode=2> [39] Meel, J.: Spread Spectrum - An introduction. DE NAYER Instituut, 1999.

LITERATURA

108

[40] Mlejnek, J.: Realizace online systému sledování letadel v pr˚ubˇehu plachtaˇrských ˇ závod˚u. Diplomová práce, CVUT, 2009. [41] Owusu, K.: Development of Cockpit Display of Traffic Information (CDTI). ICAO, 2005. [42] Paˇces, P.: Freescale HC12 demo board - schéma zapojení. 2009. URL

<www.pacespavel.net/Download/index.php?soubor=

Paces_schUniversalModule> [43] Paˇces, P.: Matlab-To-Can Toolbox. 2010. URL

soubor=PacesCanTbx> [44] Peake, B.: The Australian ADS-B Program. 2007. ˇ [45] Pech, Z.: Systémy rˇízení letu. CVUT, 2006. ˇ [46] Pleninger, S.: Systémy CNS. Fakulta dopravní, CVUT, 2009. [47] Poole, I.: DECT Specification Summary. URL

dect/dect_specification_summary.php> [48] Richards, P.: A CAN Physical Layer Discussion. Microchip Technology Inc., 2002. [49] Rose, A.: 1090 MHz ADS-B Avionics and Avionics Manufactures’ plans. 2005. [50] Sklenáˇr, M.: Návrh desky s mikrokontrolérem HC12. Fakulta elektrotechnická, Západoˇceská univerzita v Plzni, 2002. [51] s.r.o., P.: SPINEL, Komunikaˇcní protokol, Obecný popis. 2010. URL

spinel/spinel_obecne.pdf/_downloadFile.php> [52] Stock, M.: CANaerospace. Stock Flight Systems, 2006. ˇ [53] Svoboda, D.: Projekt DAMAE - pohon a napájení. Diplomová práce, CVUT Fakulta dopravní, 2010. ˇ [54] Sýkora, J.: Teorie digitální komunikace. CVUT, 2001. [55] Urbanec, V.: Semestrální práce DECT. 2007.

LITERATURA

109

[56] Vojáˇcek, A.: Processor Expert - snadné nastavení MCU a periferií jen klikáním myší. 2008. URL ˇ [57] Vˇek, V.; Celerinová, J.: Letadlové systémy. CVUT, 2002. [58] Wittig, T.: Der Transponder der Zukunft - ADS-B NOW. Euro Telematik, 2006. [59] WIZnet: W5100 Datasheet. 2010. URL

ReferenceFiles/W5100_Datasheet_v1.2.2.pdf>

110

111

Pˇríloha A

Schéma Arduino Duemilanove

112

/(

*

)

*

/

*

*

*

/ / 0 + 0

+

(. (/(/ (. . /(/ .

*

*

0

+ 0

0

0

1 1 + /

(.1 (.1

. .

*

*

*

*

0

+/

&' %&'

+ * *

+ *0

0

*

0

/( 0 0 . . 0 (.1 (.1 0

13(

*

1 1 4 + / (/( (/(

(/( (/( 0 0 0

. .

(.1

(.1

* * ** * * * * *

* * *

*

*

1

1/ 1 /

)./

(

0,

+/

//(52

5 1 +

0 .( .( 0 (./ ./ 1/ )./ / +/ 11/

11/ 11/

4//( 4 42 4( 4 0 0 0

0 0 0 0 0* 0 0

0 0

2

$+ *

(

% 0

%

0

!!"#+ *

*

0(

60( 1 + *0( 0(

6

*

/(/( 15(/ 2(/51(

/

//( (

)

*

.

">$7?9<&@;A& &0$ 7" !:8& $&<9&$:<7=&"BB"8&0<<$7C <7"9:$&0!7%&&7;8 9<<D66;$:<7=;"BB"8"$?6!7;886C>8:66

+

!!"#+

)3

!!"#+

+ 0

.

(.

1

-

//(52

12/ //(

$+

1

+

/ 1

:;<7=&!"#

0$ 7"&/( //(&&897!&

*

*

% %

% %

% %

*

+ + *

((

+ 0

//(

/(/( 2

0/)

!!"#

0

1 + //(

5

2

* +

13(

2

+

* +

+

*

,

,

,

*

1

113

Pˇríloha B

Schéma Arudino Ethernet Shield

114

A

B

C

D

100n

C22 100n

R35

10u

C36

27p

6MHz

GND

CS VCC SK NC DI ORG DO GND

U7

31

2

1

32

4

28

+

10u

1 3 4 5 2 6

13 8 11 10

XTIN

RSTOUT#

8 7 6 5

GND

VCC GND

R1OUT R2OUT T1OUT T2OUT

5

RS232_TXD

RS232_RXD

GND

U10 ICL232CBE SOJ.050/16/W B.400/L.400

C+ C1C2+ C2V+ V-

R1IN R2IN T1IN T2IN

R53

R52

GND

VCC_5V

5 9 4 8 3 7 2 6 1

16 15

12 9 14 7

P1

25

RXD_TTL

VCC_5V

RS232_TXD

RS232_RXD

GND

MOTO_TXD

R47 0R

GND

VCC_5V

SM/R_1206 R33 FTDI_PW REN# 0R

SM/R_1206 R24 0R FTDI_CTS#

SM/R_1206 R21 0R FTDI_RTS#

SM/R_1206 R20 0R

SM/R_1206 R19 0R MOTO_RXD

GND Decoupling CAPs FT232

+

FTDI_SLEEP# SM/R_1206

SM/C_0805

XTAL

VCC_5V_A

VCC_5V_A

GND_A

GND_A

REF

REF

FB

J14

1

1 2

5

6

7

J18 1 TP TestPoint

OUT-

V-

DIS

8

SM/R_1206 R55 15R

ADA4941-1

OUT+

V+

REF

J17 TestPoint TP

4

3

2

1k

R50

DIO2

DIO1

DIO0

1

FB

GND_A

J16 TestPoint TP

IN

SM/R_1206 R56 15R

3 2 1

3

uC RESET

VCC_5V

GND

1

VCC_5V

GND

XFC

SS1 SCK1 MOSI1 MISO1 PT0/IOC0 PT1/IOC1 PT2/IOC2 PT3/IOC3 VDD1 VSS1 PT4/IOC4 PT5/IOC5 PT6/IOC6 PT7/IOC7 BKGD/MODC PB0 PB1 PB2 PB3 PB4

GND

VRH VDDA ANO7/ETRIG0 ANO6 ANO5 ANO4 ANO3 ANO2 ANO1 ANO0 VSS2 VDD2 PA7 PA6 PA5 PA4 PA3 PA2 PA1 PA0

15R

15R

GND_A

GND_A

SM/R_1206

R63

GND_A

SM/R_1206

R59

GND

GND GND SM/C_0805

3

VCC_5V_A

+

BKG_DBG

REF VDD IN+ INGND

U12

GND

GND_A

GND

L4 FERITE_BEAD SM/L_0805 GND

10 9 8 7 6

GND DIN SCLK SYNC

GND

TxD Rs GND CANH Vdd CANL RxD Vref

U13

2

AD_SCLK AD_DOUT SM/R_1206

AD_RDY#

AD_DIN

Optional Resistors 0R - SDI connected to +5V - SDI connected to MOSI

R60 47k

8 7 6 5

OR

VCC_5V

15R

CAN_L

CAN_H

GND

GND

SM/R_1206

R45

GND

GND_PW R

3 2 1

0R

1 2 J10

+

4

Date:

Size A3

Title

0R SM/R_1206

R51

GND

U9

VIN

LD1086DT50

3

Universal Module - PACES Pavel

Sunday, May 17, 2009

Document Number UM MAIN BOARD

6

100n

1k GND

SM/C_0805

GND

VCC U5 C19

WP

SCL

SM/R_1206

R34

8

1k

GND

2 1 J7

J6

VCC_5V_PW R_SRC VCC_5V_SRC VCC_5V_USB_FTDI

TERM_SIP_PITCH.200/2

SM/R_1206

R38

2 1

4

IICGND

IICGND DIP.100/8/W .300/L.450 1 A0 SDA 5 2 A1 3 A2


1 2 3

IIC_VCC_5V

IICGND

TEMP_ALERT

+

3

4

1

Sheet 1

1

SM/_SMB J15

of

1

TERM_SIP_PITCH.200/2 Rev v1.3

TERM.BLOCK 2

1 2

GND_PW R

1

2

VCC_5V_SRC

D6 MBRA130LT3 2

NML0505S

+VOUT +VIN DC/DC -VIN -VOUT

U8

HEADER 3 SIP/TM/L.300/3 HEADER - Powering option Device powered from USB or Self powered device

J13

PW M_IN

PWM IN

PW M_OUT

PWM OUT

VCC_5V

VOUT

0R

0R IIC_SCL2

0R

MCP9803-M/MSG U2

IICGND 7

IIC_VCC_5V

IIC_SCL2

IICGND

IIC_VCC_5V

IIC_SDA2

SELF_PWR

HEADER 3 SIP/TM/L.300/3

J19

IIC_VCC_5V

0R IIC_SDA2

0R

MSOP.025/8/W G.125/L.250 IIC_SDA2 1 SDA Vdd 8 IIC_SCL2 2 SCLK A0 7 TEMP_ALERT 3 Alert A1 6 4 GND A2 5

C_POL_5MM_CPCYL/D.200/LS.100/.031 C_POL_5MM_CPCYL/D.200/LS.100/.031

SM/R_1206

R57

J11

TERM.BLOCK 2

1 2 3


VCC_5V_PW R_SRC

AD_CNV

GND

U6 VDD 1 NC 2 NC 3 VOUT 4 AD5310

15R

SM/R_1206

R49

SM/R_1206 R46 1k

1

R4 SM/R_1206 R6 SM/R_1206 IIC_SCL R8 SM/R_1206 TEMP_ALERT2 R9 SM/R_1206 R11 GND SM/R_1206 IIC_SDA

VCC_5V

IIC PullUps in MC9S12 PIM Outpt Module

IIC

TERM.BLOCK 3

SM/R_1206 W ALCON.100/VH/TM2OES/W .325/10

10bit A/D IN

GND

SM/R_1206 N2510-6002RB NCAP_OE# R23 0R 1 2 NCAP_DATA_OUT 3 NCAP_CLK 4 NCAP_TRIGGER# 5 J4 NCAP_DATA_IN 6 STIM_INT# STIM_ACK# 7 8 R25 0R STIM_DET# 9 10

VCC_5V

MCP2551-I/SN SOG.050/8/W G.244/L.175 SM/C_0805/MODIF SM/R_0805/MODIF

1 2 3 4

SM/R_1206 VCC_5V R18 470R

LED3MM_CYL/D.150/LS.100/.031

LED3mmYellow 1 D3 2

CAN driver

8 7 6 5

SM/R_1206 VCC_5V R15 470R

LED3MM_CYL/D.150/LS.100/.031

LED3mmGreen 1 D2 2

GND

SM/R_1206 VCC_5V R12 470R

LED3MM_CYL/D.150/LS.100/.031

LED3mmRed 1 D1 2

D/A Output

0R 0R 0R

R66 0R

GND

VCC_5V

C46 100n

CAN_RX

CAN_TX

VCC_5V

DA_IN DA_SYNC#

DA_CLK R40 DA_IN R43 DA_SYNC# R44

VIO SDI SCK SDO CNV

CONNECTOR_BDM 2 RESET_MOTO# J1 4 6

NCAP CONNECTOR

LED3

LED2

LED1

DBG LEDs

GND SM/C_0805 LED1 C20 LED2 220n LED3 FTDI_RTS# FTDI_CTS# FTDI_PW REN# FTDI_SLEEP# AD_TRIGGER DA_CLK AD_IN

VCC_5V

AD_TRIGGER AD_IN

VCC_5V

60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41

R16 0R SM/R_1206

AD7691 C_POL_5MM_CPCYL/D.200/LS.100/.031

1 2 3 4 5

L3 FERITE_BEAD SM/L_0805

1 3 5

BDM

CON6A VCC_5V Used values are for bus freq. 25 Mhz with 16 MHz oscilator

Phase loop filter - if not used (XFC tied to VDD_PLL) Rplce C(XFC/VDD_PLL) by R0Ohm

U4 MC9S12DT256MFU QUAD.65M/80/W G18.15

GND

2

VCC_5V SM/R_1206 3k3 R1

Resetuje Procesor!!!!!!!

18bit A/D input

VCC_5V

GND

SM/C_0805

VDD_PLL

uControler

VCC_5V

SM/C_0805 C10 100n RESET_MOTO# C100n (RESET/GND) is optional

TestPoint TP

J2

AD_CNV

GND

SM/C_0805 C27 100n

J12 SM/R_1206 GND TERM_SIP_PITCH.200/2

1 2

1k

R48

1 J9 2 SM/R_1206 GND TERM_SIP_PITCH.200/2

GND_A TERM_SIP_PITCH.200/2 U11 1 FB IN

VCC_5V_A

4

IN

GND

R39 1k 1 J8 2 SM/R_1206 GND TERM_SIP_PITCH.200/2

1 2 3 4 5 6 7 8 9 10

SM/C_0805

GND

MC34064

GND VCC RESET

U1

R28 0R 1 R22 0R 2 R31 3 0R 0R 4 R30 0R 5 R26 6 0R 0R 7 R27 8 0R 9 C17 220n 10 PW M_IN 11 GND DIO0 12 DIO1 13 DIO2 14 BKG_DBG 15 GATEB0 16 VCC_5V GATEB1 17 GATEB0 GATEB2 18 GATEB1 GATEB3 19 GATEB2 GATEB4 20 GATEB3 GATEB4 GATEB5 GATEB6 GATEB7

NCAP_OE# NCAP_CLK NCAP_DATA_OUT NCAP_DATA_IN R29 NCAP_TRIGGER# STIM_ACK# STIM_INT# R32 STIM_DET#

MC9S12 supposed as SPI MASTER

C12

22p

SM/C_0805

XTAL R1M is necessary

Analog grounding

LED3MM_CYL/D.150/LS.100/.031 LED3MM_CYL/D.150/LS.100/.031

10

11

12

14

15

16

18

19

20

21

22

23

24

TXD_TTL

USB

FT232BM

SLEEP#

RXLED#

TXLED#

PWRCTL

PWREN#

TXDEN

RI#

DCD#

DSR#

DTR#

CTS#

RTS#

RXD

TXD

GND_PW R

U3

L2 FERITE_BEAD SM/L_0805

FERITE_BEAD SM/L_0805

0R SM/R_1206 0R SM/R_1206

VCC_5V

TEST

EEDATA

EESK

EECS

RESET#

XTOUT

RS232

CAT93C56VI SOG.050/8/W G.244/L.175

1 2 3 4

27

5

USBDP

USBDM

3V3OUT

L1

QRAD/.450X.200/LS.200/.031

Q2

SM/R_1206 10k SM/C_0805

SM/C_0805 C21 27p

C18

RSTOUT# SM/C_0805

7

USBDP

6

470R

100n

SM/C_0805

C14

R14

8

VCC_5V

GND

GND

VCC_5V

GND_USB

SM/C_0805

SM/R_1206

1 4

6

CON1

USB_SOCKET_B USB_SOCK_B

VCC_5V GND C_POL_5MM_CPCYL/D.200/LS.100/.031 C_POL_5MM_CPCYL/D.200/LS.100/.031 C_POL_5MM_CPCYL/D.200/LS.100/.031 C_POL_5MM_CPCYL/D.200/LS.100/.031 C_POL_5MM_CPCYL/D.200/LS.100/.031

C35

+

4

1

USBDM

SM/R_1206

VCC_5V

GND

VCC_5V

GND

GND

3

2

SHLDA SHLDB D- Vcc D+ Gnd

SM/R_1206 R17 1k5

15R

SM/R_1206

USBDP R10

5 2 3

Q1

C3

SM/C_0805

16MHz

QRAD/.450X.200/LS.200/.031 EXTAL C4 22p 4k7 R5

SM/C_0805

3 26 13

SM/R_1206 USBDM R3 15R

SM/C_0805 33n C16

SM/R_1206 R41 10k

C28

10u

R42 2k2

100n C29 SM/C_0805 Decoupling CAPs RS232

C7

10n

30

C5

10u

R36

AVCC

AGND

29

1 D5

2 LED3mmGreen

VCC VCC VCC-IO

QUAD.80M/32/WG9.00

GND GND

SM/C_0805 100n C8

1 D4

2 LED3mmYellow

8k45 R58 11k8 R54 SM/R_1206 SM/R_1206

9 17

C_POL_5MM_CPCYL/D.200/LS.100/.031

R37

470R SM/R_1206 470R SM/R_1206

J5

HEADER 10

PWM_OUT

SM/R_1206 R2 1M

SIP/TM/L1.000/10

SM/R_1206

C37 10n SM/C_0805

4

TERM.BLOCK 2

C23 220n

VCC_5V

C44 100n SM/C_0805

TERM.BLOCK 2 TERM.BLOCK 2 TERM.BLOCK 2

TXD_TTL RXD_TTL MOTO_TXD MOTO_RXD

VCC_5V_USB_FTDI

C39 100n SM/C_0805

AD_RDY#

SM/R_1206 SM/R_1206 SM/R_1206

SM/R_1206 SM/R_1206 SM/R_1206 SM/R_1206 SM/R_1206 SM/R_1206 SM/R_1206 SM/R_1206

SM/C_0805 C2 22n SM/R_1206 R7 4k7

80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 PP4/PWM4 PP5/PWM5 PP7/PWM7 VDDX VSSX PM0/RXB PM1/TXB MISO0 SS0 MOSI0 SCK0 SDA SCL VREGEN TXD1 RXD1 TXD0 RXD0 VSSA VRL

10n C15 SM/C_0805

CAN_RX CAN_TX AD_DOUT TEMP_ALERT2 MC9S12 SPI master AD_DIN AD_SCLK SS# pin not used IIC_SDA IIC_SCL SM/R_1206 R13 3k3

2n2 C6 SM/C_0805 100n C38

5

SM/R_1206

C25 100n SM/C_0805

C24 100n SM/C_0805

100n

GND

10u C40

SM/R_1206

C26 100n SM/C_0805 R69 120R


AT24C64-2.7

SM/C_0805 100n C9

10k5 R65 9k76 R64 SM/R_1206 SM/R_1206

C32 10u

PB5 PB6 PB7 PE7 PE6/MODB PE5/MODA PE4/ECLK VSSR VDDR RESET VDDPLL XFC VSSPLL EXTAL XTAL TEST PE3 PE2 PE1/IRQ PE0/XIRQ C42 10n SM/C_0805

C34 100n SM/C_0805

C45 100n SM/C_0805

+

10u C41

+

+

RS232_FEMALE_DB9 DSUB/RS.318/TM/9

C30 100n SM/C_0805 10u C31

100n C13 SM/C_0805

100n

C33 100n SM/C_0805

GATEB5 21 GATEB6 22 GATEB7 23 XCLK_SEL# 24 25 26 27 28 29 RESET_MOTO# 30 VDD_PLL 31 XFC 32 33 EXTAL 34 XTAL 35 36 37 38 39 40 10u C43

SM/R_1206 0R R61

0R R62

GND 1

C11 SM/C_0805 TERM.BLOCK 2 TERM.BLOCK 2

C1

A

B

C

D

115

Pˇríloha C

Schéma vývojové desky

Pˇríloha D

Obsah pˇriloženého CD Dokumenty/ (zdrojové soubory s textem práce) |-- DP_Iveta_Valova.lyx |-- DP_Iveta_Valova.pdf |-- literatura.bib Obrazky/ (použité obrázky v r˚ uzných formátech, dle kapitol) |-- 1_DaMMaE |-- 2_Sbernice |-- 3_Komunikace |-- 4_ADS-B |-- 5_Realizace Realizace/ |-- HC12_demo_board (projekt pˇ revodníku RS 232 - CAN) Software/ (software použitý pˇ ri realizaci pˇ revodníku) |-- CodeWarrior_v5.1 (vývojové prostˇ redí Freescale) |-- PE_USB_BDM_Multilink (ovladaˇ ce programátoru pro WinXP) |-- RS232 (analyzátor a terminál sériové linky) |-- USB2CAN (ovladaˇ ce a obslužný software pro USB2CAN pˇ revodník)

116

Systém monitorování smíšeného provozu malých letadel a bezpilotních prostředků

Recommend Documents