Kommunikationsgränssnitt mot GP&C transponder

Department of Science and Technology Institutionen för teknik och naturvetenskap

Linköpings Universitet Linköpings Universitet

SE-601 74 Norrköping, Sweden 601 74 Norrköping

Examensarbete

LITH-ITN-EX--03/005--SE

Kommunikationsgränssnitt

mot GP&C transponder

Anders Johansson

LITH-ITN-EX--03/005--SE

Kommunikationsgränssnitt

mot GP&C transponder

Examensarbete utfört i datakommunikation

vid Linköpings Tekniska Högskola, Campus Norrköping

Anders Johansson

Handledare: Pedro Lundquist

Examinator: Kenneth Bjerner

Norrköping den 2003-02-03

Rapporttyp Report category Licentiatavhandling x Examensarbete x C-uppsats D-uppsats Övrig rapport ________________ Språk Language x Svenska/Swedish Engelska/English ________________ Titel

Kommunikationsgränssnitt mot GP&C transponder

Title

Communication interface to a GP&C transponder

Författare / Author

Anders Johansson

Sammanfattning

Examensarbetet som beskrivs i denna rapport handlar om en ny teknik för att förbättra säkerheten för flygplan i luften och i närheten av flygplatser. Denna teknik benämns ADS-B (Automatic Dependent Surveillance Broadcast), och är tänkt att göra det möjligt för piloter att själva få information om trafik i närområdet. Nuvarande system baserar sig i huvudsak på visuella observationer från flygledare i kontrolltorn samt radarspaning omkring flygplatserna. Med det nuvarande systemet kommer det att bli både dyrt och svårt att upprätthålla en acceptabel nivå på flygsäkerheten när trafiken ökar.

Arbetet har bedrivits i AerotechTelubs regi i Linköping samt med hjälp ifrån företaget Sectra Wireless Technologies AB. Huvuddelen av arbetet inriktar sig på implementerandet av C-funktioner för att hantera kommunikationen och sammankopplandet av ett tidigare skapat system, för grafikvisning, med en transponder som hanterar ADS-B (tillverkad av Sectra). Målet med detta var att göra förberedande arbete åt AerotechTelub som de förhoppningsvis kommer att kunna använda i ett eventuellt kommande projekt. Rapporten tar upp några standarder som hör till konceptet GP&C (Global Positioning & Communication), samt beskriver de delar som ligger till grund för programmets funktion.

Examensarbetet har resulterat i ett demonstrationsprogram för att visa hur en lösning av problemet kan se ut. Det har tyvärr inte gått att säkerställa om programmet fungerar till fullo, men genom simuleringar och andra tester har huvuddelen av programmets funktioner gått att verifiera.

Abstract

This thesis describes a new technic to improve the air safety for passing planes in the air and around airports. This technic is abbreviated ADS-B (Automatic Dependent Surveillance Broadcast) and is ment to facilitate for pilots to get information about the traffic situation around them. Today solutions are mostly based on visual observations from control towers and radar to detect planes and vehicles. With the current system it will be both difficult and expensive to maintain flight safety when the amount of traffic increases.

The work has been supervised by AerotechTelub in Linköping but also with the assistance from the company Sectra Wireless Technologies AB. The main part of the work has been implementing C-functions to handle communication and serve as an interface between a previously manufactured graphical program and a hardware transponder, that handles the ADS-B format (manufactured by Sectra). The objective with this interfacing program was to make a preparatory work for AerotechTelub that hopefully will be of use to them in future projects. The thesis discuss some standards that is relevant to the concept of GP&C (Global Positioning & Communication), and describe topics that is the base for the program.

The thesis has resulted in a program for demonstration of how a possible solution can be implemented. It has not been possible to guarantee the functionality of all parts of the program. But with simulations and other tests the majority of the program has been validated.

ISBN

_____________________________________________________ ISRN LITH-ITN-EX--03/005--SE

_________________________________________________________________

Serietitel och serienummer ISSN

Title of series, numbering ___________________________________

Nyckelord / Keyword

STDMA, VDL Mode4, VIP, ADS-B, FIS-B, GNSS, GPS

Datum

Date 2003-02-03

URL för elektronisk version

www.ep.liu.se/exjobb/itn/2003/de/005/

Avdelning, Institution

Division, Department

Institutionen för teknik och naturvetenskap Department of Science and Technology

Sammanfattning

Examensarbetet som beskrivs i denna rapport handlar om en ny teknik för att förbättra säkerheten för flygplan i luften och i närheten av flygplatser. Denna tek-nik benämns ADS-B (Automatic Dependent Surveillance Broadcast), och är tänkt att göra det möjligt för piloter att själva få information om trafik i närområdet. Nuvarande system baserar sig i huvudsak på visuella observationer från flygledare i kontrolltorn samt radarspaning omkring flygplatserna. Med det nuvarande syste-met kommer det att bli både dyrt och svårt att upprätthålla en acceptabel nivå på flygsäkerheten när trafiken ökar.

Arbetet har bedrivits i AerotechTelubs regi i Linköping samt med hjälp ifrån företaget Sectra Wireless Technologies AB. Huvuddelen av arbetet inriktar sig på implementerandet av C-funktioner för att hantera kommunikationen och samman-kopplandet av ett tidigare skapat system, för grafikvisning, med en transponder som hanterar ADS-B (tillverkad av Sectra). Målet med detta var att göra förbere-dande arbete åt AerotechTelub som de förhoppningsvis kommer att kunna använda i ett eventuellt kommande projekt. Rapporten tar upp några standarder som hör till konceptet GP&C (Global Positioning & Communication), samt beskriver de delar som ligger till grund för programmets funktion.

Examensarbetet har resulterat i ett demonstrationsprogram för att visa hur en lösning av problemet kan se ut. Det har tyvärr inte gått att säkerställa om program-met fungerar till fullo, men genom simuleringar och andra tester har huvuddelen av programmets funktioner gått att verifiera.

Abstract

This thesis describes a new technic to improve the air safety for passing planes in the air and around airports. This technic is abbreviated ADS-B (Automatic

Depen-dent Surveillance Broadcast) and is ment to facilitate for pilots to get information

about the traffic situation around them. Today solutions are mostly based on visu-al observations from control towers and radar to detect planes and vehicles. With the current system it will be both difficult and expensive to maintain flight safety when the amount of traffic increases.

The work has been supervised by AerotechTelub in Linköping but also with the assistance from the company Sectra Wireless Technologies AB. The main part of the work has been implementing C-functions to handle communication and ser-ve as an interface between a previously manufactured graphical program and a hardware transponder, that handles the ADS-B format (manufactured by Sectra). The objective with this interfacing program was to make a preparatory work for AerotechTelub that hopefully will be of use to them in future projects. The thesis discuss some standards that is relevant to the concept of GP&C (Global

Positio-ning & Communication), and describe topics that is the base for the program.

The thesis has resulted in a program for demonstration of how a possible solu-tion can be implemented. It has not been possible to guarantee the funcsolu-tionality of all parts of the program. But with simulations and other tests the majority of the program has been validated.

Förkortningar

GP&C Global Positioning & Communication

STDMA Self organising Time Division Multiple Access data link

VDL4 VDL Mode 4

VIP VDL Mode 4 Interface Protocol

VDL Mode4 VHF Datal Link Mode 4

VHF Very High Frequency

GNSS Global Navigation Satellite System

GPS Global Positioning System

GHz GigaHertz

CPR Compact Position Reporting

ANSI American National Standards Insitute

ADS-B Automatic Dependent Surveillance Broadcast

FIS-B Flight Information Service Broadcast

TIS-B Traffic Information Service Broadcast

TCP Trajectory Change Points

PDU Packet Data Unit

ADU Application Data Unit

CRC Cyclic Redundancy Check

HDLC High level Data Link Control

POSIX Portable Standard for UNIX

Figur lista

2.1 Synkroniserade tidsfack . . . 6 2.2 VDL4-paket . . . 7 3.1 Hårdvarans delar . . . 11 4.1 Datalink . . . 17 4.2 Programmets delar . . . 20 4.3 Huvudprogrammet . . . 27 4.4 Mottagning av paket . . . 28

4.5 Avkodning av mottagna paket . . . 29

4.6 Avkodning av ADS_B-data . . . 30

4.7 ”Sortering” av ADS_B-data . . . 31

Innehåll

Sammanfattning i Abstract iii Förkortningar v 1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 1 1.3 Metod . . . 2 1.4 Avgränsningar . . . 2 1.5 Rapportens upplägg . . . 2

2 Standarderna VDL4 & ADS-B 5 2.1 VDL4 . . . 5 2.1.1 STDMA . . . 6 2.1.2 Konkurrerande format . . . 7 2.2 ADS-B . . . 8 2.3 FIS-B . . . 8 2.4 GP&C . . . 9 3 Hårdvara 11 3.1 Transponder . . . 11 3.2 GNSS-mottagare . . . 12 3.3 Övriga mätsystem . . . 13 3.4 Presentationssystem . . . 13 3.5 Sammankoppling . . . 14 ix

4 Mjukvara 15

4.1 Bakgrund . . . 15

4.1.1 Statisk minnesstruktur . . . 15

4.1.2 Globala vs. lokala variabler . . . 16

4.1.3 Kompatibilitetsproblem . . . 16 4.2 Programmets byggstenar . . . 16 4.2.1 Datakommunikation . . . 17 4.2.2 Avkodning . . . 18 4.2.3 Avslutning . . . 19 4.3 Programmets uppbyggnad . . . 20 4.4 Datastrukturer . . . 22 4.5 Variabler . . . 22 4.6 Handhavande . . . 24 4.7 Programflöde . . . 25 4.7.1 Huvudprogrammet . . . 25 4.7.2 Mottagning av paket . . . 25

4.7.3 Avkodning av mottagna paket . . . 25

4.7.4 Avkodning av ADS-B-data . . . 25 4.7.5 ”Sortering” av ADS-B-data . . . 26 5 Avslutning 33 5.1 Resultat . . . 33 5.2 Rapporten . . . 34 5.3 Möjliga förbättringar . . . 34

5.4 Källförteckning och länkar . . . 35

A Kravspecifikation 37 B Funktionsbeskrivning 39 B.1 main.c . . . 39 B.2 vip.c . . . 40 B.3 ads_b.c . . . 44 B.4 fis_b.c . . . 46 B.5 config.c . . . 46 B.6 display.c . . . 47 C Kodlistning 49 C.1 main.h . . . 49 C.2 main.c . . . 50 C.3 vip.h . . . 60 C.4 vip.c . . . 64 C.5 ads_b.h . . . 83 C.6 ads_b.c . . . 84

xi C.7 fis_b.h . . . 101 C.8 fis_b.c . . . 102 C.9 display.h . . . 104 C.10 display.c . . . 105 C.11 config.h . . . 110 C.12 config.c . . . 111 C.13 common_def.h . . . 114

KAPITEL 1

Inledning

Denna rapport syftar till att beskriva examensarbetet Kommunikationsgränssnitt

mot GP&C transponder som bedrevs hos AerotechTelub i Linköping under

som-maren 2002. Examensarbetet har ingått som ett moment i 120 poängsutbildningen Data/Elektroteknik (DE) vid Linköpings Tekniska Högskola.

1.1

Bakgrund

I en tid då flygresor blir allt mer vanliga, börjar luftrummens kapacitet nå sina begränsningar. För att öka kapaciteten kommer det att krävas att avstånden mellan flygplanen minskas. Samtidigt spelar säkerheten en större roll i flygtrafiken, och då det inte alltid finns flygledare som kan eller har tid att övervaka allt flyg kommer nya lösningar att krävas.

AerotechTelub är ett företag som mestadels arbetar mot kunder inom det mi-litära området. De har insett att flygsäkerheten inom den civila marknaden är ett minst lika viktigt och lukrativt område. Därför har de funderat på att inom en kort tid börja arbeta på lösningar inom detta område. Eftersom flygbolag världen över förväntas efterfråga produkter inom GP&C (Global Positioning &

Communi-cation), önskar AerotechTelub vara beredd på detta.

1.2

Syfte

Tanken med examensarbetet var att ge AerotechTelub en förberedelse för GP&C i samband med flyg, som de kunde utgå ifrån och eventuellt arbeta vidare på. Främst var denna förberedelsen inriktad på att hämta information ifrån en lämplig transponder för detta område. Eftersom företaget Sectra Wireless Technologies AB

har bidragit med information och kunskap om en egenutvecklade transponder, som använts i detta examensarbetet, har båda parterna föreslagit att den kod som producerats ska kunna utnyttjas av dem båda. En plattformsoberoende kod var därför nödvändig.

1.3

Metod

Arbetet delades in i tre delar. Den första delen bestod i att inhämta relevant infor-mation för att kunna planera upplägget på det program och den rapport som skulle produceras. I den andra delen genomfördes implementationen av programmet, med viss omarbetninig beroende på ändrad kravspecifikation. Och i den tredje delen ve-rifierades resultatet så långt som möjligt med hjälp av avlusningsverktyg inbyggt i utvecklingsplatformen samt med utvecklingsverktyg för den avsedda transpondern. Dock har resultatet inte till fullo kunnat verifierats.

Arbetet har mestadels bedrivits i AerotechTelubs lokaler i Linköping med un-dantag av rapportskrivningen som har genomförts hemifrån då den inte är beroende av utrustning.

1.4

Avgränsningar

Målet med examensarbetet var aldrig att producera en färdig produkt, utan bara att föreslå hur en del av problemet kunde lösas. Till en början var arbetet pla-nerat till 20 poäng (20 veckor), men det blev möjligt att avgränsa det till ett 10 poängs arbete på ett lämpligt sätt. Inriktningen blev att endast implementera ett kommunikationsgränssnitt mot en passande transponder för ADS-B (Automatic

Dependent Surveillance Broadcast) och VDL4 (Very High Frequency Data Link Mode 4). Den resterande delen, att integrera kommunikationsgränssnittet med ett

befintligt program för grafisk presentation av flygplanens position och annan data, ersattes med en förenklad textvisning.

1.5

Rapportens upplägg

Rapporten är indelad i följande delar.

Kapitel 2 beskriver de standarder som ligger till grunden för GP&C samt

även hur alltsammans är tänkt att fungera.

Kapitel 3 beskriver bland annat hur hårdvaran är uppdelad och dess delar. Kapitel 4 beskriver den mjukvara som har producerats samt detaljerade

för-klaring av många av dess delar.

1.5. Rapportens upplägg 3

Bilaga A visar den ursprungliga kravspecifikationen. Vissa ändrade

förutsätt-ningar har medfört förändringar i denna specifikation.

Bilaga B innehåller förklaring till vad varje funktion har för syfte och

funk-tion.

Bilaga C redovisar källkoden på c:a 2800 rader eller 85 kbyte text uppdelat

KAPITEL 2

Standarderna VDL4 & ADS-B

I detta kapitel presenteras de standarder som ingår i konceptet GP&C. Bland des-sa är VDL4 som dikterar hur kommunikationen sköts des-samt ADS-B som beskriver formatet på den informationen som förmedlas genom VDL4. (Andra format

kom-mer sannolikt att läggas till för att lösa andra aspekter inom flygkommunikationen. Den främsta tanken är dock att öka säkerheten inom trafiken.)

2.1

VDL4

Grunden till formatet VDL4 står uppfinnaren Håkan Lans för. Under 1980-talet påbörjade han tillsammans med sina arbetskamrater arbetet med att samman-koppla system för positionsbestämning med kommunikation-, navigering- och över-vakningssystem. Detta arbete resulterade i ett kommunikationsformat som be-nämns STDMA (Self organising Time Division Multiple Access data link), vilket blev patenterat under 1990-talet. Det utgör dessutom grunden för arbetet med en världsstandard inom flyg och sjöfart lett av FN organen ICAO (International Civil

Aviation Organisation) och IMO (International Maritime Organisation). Flygets

och sjöfartens kommunikation har bara formatet STDMA gemensamt. Olika lös-ningar på specifika områden har medfört att de inte är kompatibla med varandra, vilket skulle varit önskvärt. Då till exempel sjöräddningens helikoptrar är beroende av båda systemen.

För flygtrafik används frekvensbandet 118-137 MHz, 25kHz bandbredd per ka-nal samt modulationstypen GFSK (Gaussian Frequency Shift Keying. En typ av modulering speciellt lämpad för digitala signaler). (Sjötrafiken utnyttjar andra

fre-kvensband och annan modulationstyp).

2.1.1 STDMA

Grundidén är att olika transpondrar turas om att sända på samma frekvens. Problem kan dock uppstå om flera transpondrar sänder samtidigt. Det som gör STDMA speciellt är att det har en unik metod att komma runt detta problem. Det går ut på att dela in tiden i ett antal tidsfack under en minut, vars början är synkroniserade från satelliter. Genom att i varje utnyttjat tidsfack skicka med ett nummer på det tidsfack som sändaren tänker utnyttja vid nästa sändning, kan alla andra mottagare räkna ut möjliga tillfällen att sända. Om nya transpondrar vill börja sända, får de först lyssna på all kommunikation för att avgöra vilka tidsfack som är upptagna. Därefter slumpmässigt välja ett ledigt tillfälle som transpondern kan börjar sända på. Om det skulle uppstå en kollision i sändningarna, får de försöka hitta ett annat tidsfack.

0 4499 VDL4-meddelande tidsfack synkroniserad från satelliter 131 3ms VDL4-meddelande

Figur 2.1: Synkroniserade tidsfack

Totalt finns det 75 tidsfack per sekund, där varje varar i 13,33 ms. Detta mot-svarar 4500 tidsfack per minut, vilket täcker en hel period vars början synkronise-rats av satelliter. Ett visst spill blir nödvändigt för att tisdfacken inte skall kunna överlappa varandra vid längre avstånd. Ett tidsfack innehåller 256 bitar vilket motsvarar 19200 bitar per sekund. Den effektiva datamängden som kan överföras är givetvis något mindre eftersom styrdata och in- och utfasningsdata tar upp en hel del. Man bör också komma ihåg att hastigheten 19200 bps delas av alla trans-pondrar som sänder på samma frekvens. Normalt är detta inget problem eftersom det finns 760 frekvensband att utnyttja.

För att ytterligare förbättra hanteringen, finns två lägen på fördelningen av tidsfack. Ett då planen själva kommer överens om vem som skall sända när, men det finns även ett när markstationer hanterar fördelningen av tidsfack. Då detta är det normala vid flygsträckor över land, fungerar detta inte över större hav, där planen själva får sköta hanteringen. Även i områden där markstationerna inte stödjer systemet tvingas planen hantera detta. Men då minskar effektiviteten av systemet avsevärt, eftersom det inte går att garantera att alla omgivande plan är synliga.

2.1. VDL4 7

Ett VDL4-data paket innehåller förutom in- och utfasningsdata följande: - Startflagga 0x7e

- Bitflaggor

- ICAO-adress (sändare) - Typ av meddelande

- Meddelande (t.ex. ADS-B, FIS-B, m.fl.)

- Reservationsdata (för reservation av framtida tidsfack) - Kontrollsumma CRC16

- Stoppflagga 0x7e

Figur 2.2: VDL4-paket

2.1.2 Konkurrerande format

Eftersom det finns en viss prestige i att ta fram sitt eget system, har flera tävlande system vuxit fram. Bland annat har USA två system under utveckling. Delvis är de konstruerade för att passa in till de befintliga systemen i USA, men även för att försöka etablera dem som standard i omvärlden.

UAT (Universal Access Transceiver)

1090 MHz Extended Squitter (utbyggnad av ModeS)

Dessa två system har vissa fördelar jämfört med VDL4 men också några nackde-lar. De har bättre överföringskapaciteten, men använder samtidigt betydligt större bandbredd. Vidare använder de endast en kanal för all kommunikation, vilket för-enklar hårdvarans konstruktion. På grund av att de kräver en högre bandbredd, tvingas de använda väldigt höga frekvensband (GHz). Detta medför de är effekt-krävande samt har sämre känslighet än VDL4. Väldigt stora flygplan har inget problem, men mindre farkoster kan få problem med effektförsörjningen. Det är dock endast VDL4 som har en intelligent hantering av fördelningen av tidsfack. De två andra systemen slumpar ut tillfällen att sända på eller utnyttjar fasta mönster av något slag.

Vilket system som är bäst beror på vilka aspekter som man väger in, men om kostnadsaspekten kombinerad med prestandan får avgöra är VDL4 det alternativ som är att föredra. Oberoende av vilket format som används, har de olika stan-darderna möjlighet att förmedla liknande information inom samma system. För interkontinentala flygningar kan det komma att krävas system som stödjer flera standarder.

2.2

ADS-B

I VDL4, som detta examensarbete är inriktat på, finns det plats för några olika typer av standarder. Några av dessa är inriktade på att förbättra säkerheten inom flygtrafiken, medan andra syftar till att förenkla kommunikationen mellan olika flygplan och markstationer. ADS-B som står för Automatic Dependent Surveillance

Broadcast är grunden inom GP&C, och har till uppgift att förmedla information

om planets position, höjd, hastighet och riktning.

Den data som förmedlas genom ADS-B innehåller bland annat olika typer av bitflaggor, höjd, latitud, longitud och ett fält för tilläggsdata. Positionen som skic-kas är kodad enligt en metod som kallas CPR (Compact Position Reporting) som gör det möjligt att spara lite plats. Detta sker genom att longitud och latitud var för sig omvandlas till en grundposition samt en utökad position. Den utöka-de positionen kan vara 4,6 eller 8 bitar, medan grundpositionen är 12 och 14 för latitud respektive longitud. Med endast grundpositionen kan en relativt god posi-tion utläsas inom ett område på c:a 1100 km. Dock går det inte att avgöra vart på jordklotet detta område finns. Eftersom räckvidden för transpondern inte beräknas vara större än 350 km är positionen ändå användbar.

I fältet för tilläggsdata kan olika typer av data placeras t.ex. förbättrad pre-cision av position och höjd, flygplanens anropsnamn, flygplanets status och typ, planerad flygväg, datum och tid. Vad som skickas är upp till planens transpond-rar att avgöra. Anledningen till att det finns olika typer av tillägsdata är att viss information inte är nödvändigt att uppdatera vid varje sändningstillfälle, t.ex. an-ropsnamn och planerad flygsträcka. Genom att inte behöva uppdatera dessa vid varje tillfälle, kan en hel del utrymme sparas.

2.3

FIS-B

Eftersom detta inte ingick i examensarbetet, men ändå kan betraktas som en intres-sant del i målet att förbättra flygsäkerheten, finns det förberett i den programkod som skapats. Idén med FIS-B (Flight Information Service Broadcast) är att för-medla olika typer av information som kan förenkla flygningen för piloterna. Det kan t.ex. vara väderförhållanden på en flygplats, trafikproblem i samband med oväder m.m. Normalt överförs denna information via radiokommunikation som piloterna själva får hantera. Om detta istället förmedlas som text, kan det bidra till att mins-ka feltolkningar som mins-kan förekomma i samband med bristande språkkunsmins-kaper hos piloterna. Det går också att med större säkerhet garantera att den information som har mottagits är felfri.

2.4. GP&C 9

2.4

GP&C

Tidigare nämnda delar är vad som gör GP&C till ett komplett system för att både öka säkerheten inom flygverksamheten samt att förenkla kommunikationen mellan de olika aktörerna i luften och på marken. Tanken är nämligen att även fordon som finns på marken på en flygplats skall ingå i systemet. Katastrofer i samband med att fordon är i vägen för flygplan som landar eller lyfter är idag ett problem som kontrolleras av markradaranläggningar och observationer ifrån kontrolltorn. I ett komplett utbyggt system ser alla farkoster varandra, och systemet varnar alla inblandade parter om tänkbara kollisionsrisker. Även planeringar av flygstäckor kan hanteras smidigare genom att mötande plan i ett tidigt skede kan korrigera sin planerade flygväg för att undvika kollisioner eller turbulens vid förbiflygningar nära andra flygplan.

KAPITEL 3

Hårdvara

Transpondern som avses i detta examensarbete har utvecklats av Sectra Wireless

Technologies AB. För att förenkla utvecklingsarbetet har ett emuleringsprogram

används istället för den riktiga hårdvaran, dock presenteras arbetet som om en riktig transponder hade använts med erforderliga kringkomponenter.

GNSS-mottagare Dator för VDL Mode 4 VHF-sändare /mottagare Presentations-system Skärm och knappar seriekommunikation

Figur 3.1: Hårdvarans delar

3.1

Transponder

Transpondern består i huvudsak av två delar. En dator som används för att be-handla data men även för att kontrollera och styra hårdvaran, samt en VHF-sändare och mottagare för kommunikationen med transpondrar på andra flygplan

och markstationer. Sändaren har en uteffekt på c:a 10 Watt vilket ger en räckvidd på c:a 200 sjömil (370 km). Flera mottagare kan operera samtidigt på olika fre-kvensband för att på så sätt öka det maximala antalet plan inom samma område. Utöver de inbyggda delarna måste andra enheter anslutas för att förse trans-pondern med information om t.ex. position, höjd, hastighet och riktning. Utan dessa saknar transpondern praktisk funktion eftersom den inte vet vart den är och heller inte kan berätta det för sin omgivning. För att sedan förmedla den mottagna informationen till piloterna finns ett presentationssystem anslutet, och det är den-na del som examensarbetet har inriktat sig på. Det är dock tänkbart att ett system kan vara placerad i mindre farkoster som inte har behov av visuell presentation utan endast för att uppmärksamma omgivande flyg på sin existens.

Ett komplement till att varje farkost har en egen transponder, är TIS-B syste-met. I det systemet utnyttjar man att markstationer omvandlar radarinformation till ADS-B data som sedan omgivningen får del av. Det kan tänkas att t.ex. fall-skärmshoppare inte har möjligheten att bära med sig en egen transponder.

3.2

GNSS-mottagare

GNSS står för Global Navigation Satellite System. Denna mottagare är oftast en egen separat enhet som har till uppgift att beräkna sin egen position. En GNSS-mottagare är beroende av att ett antal satelliter som kretsar runt jorden på bestäm-da positioner. Dessa sänder ut tidsinformation som är synkroniserad till varandra. På grund av att radiovågorna från satellit kommer att färdas olika långt fram till mottagaren och därigenom tidsförskjutas olika mycket, kan en relativt exakt position beräknas.

Ett annat namn på samma sak är GPS som står för Global Positioning System. Idag finns det egentligen bara ett system, nämligen det amerikanska NAVSTAR som fram till ett par år sedan endast var till för det amerikanska försvaret. Tidigare lades en onoggrannhet på de signaler som satelliterna skickade ut för att försvåra för andra att använda det. Detta problem kunde man komma runt genom att radi-ofyrar med kända positioner skickade ut korrigeringsdata som mottagarna kunde utnyttja för att räkna fram sin korrekta position. Genom att USA inte ville låta andra länder fritt använda systemet, bidrog de till att konkurrerande system växte fram. Det ryska alternativet GLONASS är tyvärr idag inget alternativ på grund av att de inte har råd att underhålla det. Däremot kan det eventuellt kommande europeiskt systemet GALILEO bli ett lämpligt alternativ till det amerikanska. An-ledningen till att det planeras är främst osäkerheten om det amerikanska systemet ska förbli fritt att utnyttja, men även för att förbättra noggrannheten. Givetvis finns det ett visst prestigetänkande inblandat i beslutet att bygga ett eget system. Eftersom en GNSS enhet inte är ihopbyggd med transpondern, går det utan större problem att byta eller uppgradera till framtida versioner som stödjer andra system eller kombinationer av dem samtidig.

3.3. Övriga mätsystem 13

3.3

Övriga mätsystem

Övrig mätutrustning som behövs för att kunna använda ADS-B till fullo är bland annat hastighetsmätare, höjdmätare och kompass. Med dessa kombinerat med en GNSS-mottagare kan omgivande flyg få reda på både nuvarande position samt i vilken riktning och med vilken hastighet flygplanet är på väg. Detta medför att piloterna kan få information och varningar långt innan eventuell fara skulle kunna uppstå. Det finns också möjligheter att piloterna själva matar in sin planerade färdplan så att omgivande plan mer i detalj får reda på hur planet kommer att fär-das. Detta kallas för TCP (Trajectory Change Points) och innehåller information om position, höjd och ankomsttid. Med jämna mellanrum skickar planets trans-ponder ut denna information som kan bidra till att de olika flygplanens flygvägar inte korsar varandra. Denna information är därför något som piloterna behöver kunna mata in via tangentbord eller liknande.

3.4

Presentationssystem

Eftersom AerotechTelub redan har utvecklat ett presentationssystem för en tidiga-re produkt fanns givetvis ett inttidiga-resse att utnyttja denna del i ett system för GP&C. Detta presentationssystem är baserad på en inbyggd PC-dator med platt skärm. På denna kan en grafisk karta visas, som ändras i takt med att flygplanet förflyt-tar sig, samt symboler för att indikera olika objekt på marken och i luften. Detta för att piloten visuellt ska kunna se hur omgivningen ser ut, även om det t.ex. skulle vara dimmigt med dålig sikt som följd. Mestadels handlar det om att förse piloterna med information om sin omgivning, men det finns även planer om att piloterna skall kunna utnyttja systemet till att kommunicera med andra flygplan, markstationer och flygledare. Detta utan att behöva använda sig av vanlig radio-kommunikation, vilket skulle kunna bidra till att minska de problem som hänger samman med tal. Någon form av knappsats skulle då krävas för piloterna att förse presentationssystemet med indata.

Eftersom detta examensarbetet bedrevs under en begränsad tid (c:a 10 vec-kor), fanns inte möjligheten att bygga in det existerande presentationssystemet från AerotechTelub. För att ändå kunna ta del av all information som hämtas från transpondern, skrevs all flygplansdata ut som text på skärmen. På grund av att utskriften till skärmen skedde via terminalutskrift, d.v.s. ej på fasta skärmkoor-dinater, var utskrivningsrutinen tvungen att hålla reda på vilka plan som fått ny data. Annars skulle texten bara forsa förbi och därigenom vara väldigt svårläst. En alternativ lösning är att rikta om textströmmen till en fil. Att hålla koll på om plan har ny data eller ej är inte nödvändig vid grafisk uppritning, eftersom alla plan ändå ritas om vid varje tillfälle som grafiken behöver uppdateras.

3.5

Sammankoppling

Den datamängd som kan skickas mellan transpondern och presentationssystemet ställer inga stora krav på överföringskapaciteten. Man bör tänka på att begräns-ningen ligger i VDL4 protokollet. Därför användes seriekommunikation (RS-232) med en hastighet av 115,2 kilobit per sekund. Givetvis finns det andra format på seriekommunikation som lämpar sig bättre i en flygplansmiljö, men under utveck-lingsfasen var det smidigare med det som fanns tillgängligt i en vanlig persondator. Tanken med den transponder som Sectra har utvecklat är att olika delar ansluts via olika serieportar. Bland dessa finns anslutningar för presentationssystemet, övervakning och underhåll. Planer finns eventuellt för att ersätta seriekommuni-kationen med t.ex ett ethernet-nätverk för att på så sätt överlåta hanteringen av kommunikationen till lämplig hårdvara.

KAPITEL 4

Mjukvara

I detta kapitel kommer programmets uppbyggnad samt de olika delarnas funktioner redovisas. Vidare även hur de olika delarna hänger ihop och hur de utbyter data mellan varandra. En enklare beskrivning av programflödet finns med tillsammans med hur de olika delarna kan utnyttjas för vidare utveckling av programmet.

4.1

Bakgrund

Till en början var det tänkt att detta arbete skulle inrikta sig på att skapa ett program för att hantera kommunikationen med en transponder för VDL4/ADS-B, och sedan sammanfoga det med ett befintligt program för grafikhantering. Detta ändrades senare till att endast innefatta kommunikationen med transpondern, men med det kravet att det skulle (till så stor del som möjligt) vara plattformsoberoende samt vara skrivet på ett sätt som skulle möjliggöra en framtida certifiering från flygmyndigheter. Med detta i tanke blev valet av programspråk ANSI-C.

4.1.1 Statisk minnesstruktur

Certifiering innebär bland annat att det skall kunna gå att lita på att programmet inte beter sig felaktigt efter en längre tid i drift. T.ex. att variabler hamnar utanför minnesområdet som tilldelats till programmet eller att internminnet tar slut. Detta kan lösas genom att endast använda statiska minnesstrukturer, d.v.s. att variabler inte skapas och tas bort under programmets gång. Detta medför att relativt stora minnesområden tas i anspråk, även om bara en mindre del utnyttjas under normala förhållanden. Det bör dock klargöras att detta program för närvarande utnyttjar relativt lite minne.

4.1.2 Globala vs. lokala variabler

För att öka hastigheten i programmet och minska minnesanvändningen, används vissa globala datastrukturer i programmet. Detta medför att data i en betydande mindre mängd kommer att behöva flyttas mellan olika funktioner. Istället bifogas en pekare eller en referens till datastrukturen. För att detta skall vara möjligt får funktioner inte anropa andra funktioner som utnyttjar samma variabel eller data-struktur. En nackdel med globala variabler är att det blir svårt att överblicka vad som används av de olika funktionerna. Dock bör man känna till att benämningen globala och lokala variabler mest är till för att underlätta hanteringen vid program-mering. Under körning av programmet kan funktioner med brister ändå skriva sön-der andra minnsesområden. Normalt ligger globala delar på ett samlat dataområde medan lokala skapas på programmets stack. (Stack: en typ av minnesområde som

bland annat lagrar parametrar vid anrop och programmets återhoppsadresser.)

4.1.3 Kompatibilitetsproblem

När det gäller den standard som organisationen ANSI har kommit fram till när det gäller programmeringsspråket C, saknas vissa delar. Seriekommunikation är ett exempel på en sådan del som inte finns med i standarden. Normalt används filer för att representera objekt som data kan överföras till och ifrån. När det gäller kommunikationsportar krävs ett antal extra inställningar för att kommunikationen skall kunna fungera korrekt, och dessa finns inte tillgängligt för filobjekt. Trots detta har det ändå vuxit fram en slags standard inom UNIX-systemen. Denna standard bygger på POSIX-standarden och ger programmet möjlighet att ställa in de nödvändiga parametrarna. Dock stödjer inte alla plattformar denna standard, bland annat Windows. För att ändå stödja så många plattformar som möjligt har speciell kod skapats för de delar som hör till seriekommunikationen. I koden går det att konfigurera för vilket system som koden är tänkt att kompileras för.

Dock så har olika UNIX-system frångått en gemensam benämning på de filer som motsvarar de kommunikationsportar som programmet behöver kunna utnytt-ja. Även detta går att ställa i programkoden för de vanligaste UNIX varianterna.

4.2

Programmets byggstenar

Programmet som skapats i detta examensarbete kan i en förenklad form beskrivas som tre olika delar. Dessa delar, som beskrivs var för sig nedan, har till uppgift att hantera kommunikation och avkodning av inkommande data. En speciell del är programmets förmåga att klara av att tillfälligt kunna förlora kontakten med transpondern, och sedan utan problem hantera återskapandet av uppkopplingen

4.2. Programmets byggstenar 17

4.2.1 Datakommunikation

Kommunikationen med transpondern sker via seriekommunikation. För att skapa struktur i kommunikationen är denna indelad i ett antal lager, som vart och ett har olika sätt att hantera all data som skickas. Dessa lager är:

1. Binärt representerade databitar enligt formatet RS-232. 2. Byteformaterad data mellan start- och stoppbit(ar).

3. Datalink paket innehållande data mellan 2 byteflaggor. Datan är kodad

(by-testuffed) för att undvika att den innehåller samma värde som byteflaggorna.

I slutet av datan finns en kontrollsumma inbakad för att kunna bekräfta da-tans integritet. (Denna struktur kallas för HDLC).

4. PDU (Packet Data Unit) innehåller versionsnummer, sessionsnummer, se-kvensnummer, datatyp och bifogad data.

5. ADU (Application Data Unit) kan innehålla 3 olika typer av meddelanden; anrop, svar eller indikering. Anrop innehåller anropsbeteckning (Call ID), parameterlängd och bifogade parametrar. Svar innehåller samma som an-rop, men har också ett returvärde (Return Value) som bland annat berättar om anropet gick bra eller ej. Indikering innehåller liknande som anrop, men har indikeringsbeteckning (Indication ID) istället. Ett indikeringsmeddelan-de kan skickas vid behov av transponindikeringsmeddelan-dern och är ej något som är kopplat till anrop.

6. Parameter data. Kan innehålla data som är specifik till respektive komman-do som kan skickas till transpondern. T.ex. kan dessa parametrar innehålla VDL4 data, som sedan vidare avkodas. (se delen 4.2.2).

Start PDU ADU Data CRC16 Stop

Bytes: 1 3 3-4 0-1024 2 1

Figur 4.1: Datalink

Lagren 1 och 2 hanteras normalt av specialiserad hårdvara inuti datorn. Det tredje lagret hanteras av ett antal funktioner som är placerade i filen vip.c. För att inte programmet ska låsa sig under tiden som ett datapaket strömmar in, finns en variabel som representerar olika faser i mottagandet av ett helt datapaket. Om ingen byte finns från serieporten när mottagningensfunktionen vill läsa, avbryts mottagningen och andra delar av programmet körs istället. När övriga delar i

programmet har gjort sitt, testas serieporten på nytt. (Se figur 4.4 på sidan 28

för visuell beskrivning). Det finns fyra olika faser och beroende på olika händelser

övergår mottagning i en ny fas. 1. Kommunikationsport saknas.

2. Datapaket ej synkroniserat / inget meddelande mottaget. 3. Datapaket håller på att mottagas.

4. Datapaket är färdigmottaget och felfritt.

Under uppstart är mottagningen i fas 1. Om allt går bra övergår mottagningen till fas 2, och väntar på en startflagga. Alla annan data ignoreras. Eftersom denna fas också har hand om att synkronisera mottagningen, testas byten efter startflaggan så att den inte har samma värde. På detta sätt kan början av ett datapaket enkelt upptäckas. När ett nytt datapaket har detekteras, övergått mottagningen till fas 3. All inkommande data lagras fram tills att en stoppflagga mottages, och därefter indikerar funktionen att ett nytt paket finns tillgängligt. Mottagningen övergår därmed till den fjärde fasen, och kommer att förbli där framtill att paketet har tagits om hand. (Se figur 4.5 på sidan 29).

När programmet har uppmärksammats på att det finns ett nytt datapaket, anropas en funktion för att påbörja avkodningen av datan. Först avkodas det tredje lagret genom att plocka bort bytestuffingen och därefter beräkna och jämföra kontrollsumman (CRC16) med den bifogade. Om inget fel har upptäckts, fortsätter funktionen att avkoda lagren 4 och 5 på samma gång. I detta steg flyttas viktig data från datapaketet till en datastruktur som den anropande funktionen bestämmer. De eventuella parametrar som bifogats i paketet finns tillgänglig genom en global pekare. Samtidigt som lagren 4 och 5 avkodas, övergår mottagningsfunktionen till fas 2. Eftersom inga nya paket tas emot fram tills dess att den befintliga datan har tagits om hand, riskerar inget att bli överskrivet. Detta bidrar också till att mindre data behöver flyttas från ett ställe till ett annat.

Om ett fel i paketet upptäckts, kastas det och ett nytt inväntas. Det finns inget sätt att automatiskt begära omsändning från transpondern, vilket kan betraktas som en brist. Normalt kan ett anrop till transpondern göras om på nytt. Om det var information om en farkosts position, återkommer detta normalt vid ett senare tillfälle.

4.2.2 Avkodning

När ett paket innehållande VDL4 data anländer, påbörjas arbeten med att ta hand om alla uppgifter som ADS-B formatet innehåller. Den data som kommer in från transpondern är delvis organiserad enligt en annan ordning än vad VDL4-protokollet anger. Dessutom har transpondern beräknat en komplett positionsangi-velse, under förutsättning att det finns underlag för det. Genom att VDL4 paketet

4.2. Programmets byggstenar 19

innehåller det sändande planets adress kan avkodningsfunktionen kontrollera om planet finns med i en tabell sedan tidigare eller om en ny plats ska reserveras. (Se

figur 4.6 på sidan 30). Det finns också med en parameter (MID ”Message ID”)

som anger vilken typ av data som har bifogats i paketet, t.ex. ADS-B, FIS-B eller något framtida format. Om denna parameter motsvarar värdet för ADS-B, påbör-jas avkodningen. Värdet på parametern anger också vilken tilläggsdata som finns i ADS-B paketet (Se kapitel 2.2). Programmet har sedan bara att extrahera relevant data, omvandla den till en korrekt skala och därefter spara den i den datastruktur som motsvaras av planets adress.

På grund av att olika noggranna angivelser kan skickas med ADS-B forma-tet, hanteras ett tal internt för att representera noggrannheten hos positionen. En ny position med sämre noggrannhet ignoreras samtidigt som noggrannhetstalet minskas. Om en längre tid har gått sedan den senaste uppdateringen, uppdate-ras positionen oberoende noggrannhetstalet. Denna metod bör utvärdeuppdate-ras vidare för att eventuellt justera de inblandade parametrarnas värde och konstatera att uppdateringen fungerar optimalt.

Sammankopplat med avkodningsfunktionen finns en funktion som körs under ledig tid, d.v.s. då ingen data tas emot. (Se figur 4.7 på sidan 31). Denna funk-tion kontrollerar listan med alla upptäckta plan och rensar bort de plan som inte blivit uppdaterade på en längre tid. Detta händer endast då plan hamnat utanför mottagningsområdet för transpondern och inte längre bidrar med ny information. Totalt finns det plats för 4500 plan, men utan upprensning skulle denna lista snabbt bli fylld.

I programmets nuvarande utförande ignoreras vissa typer av tilläggsdata som tas emot. Bland annat är det TCP data (Trajectory Change Points) och tidsinfor-mation som ej tas om hand. TCP data är något som lämpligen bör tas om hand, för att på så sätt kunna förutse de omgivande planens framtida positioner.

4.2.3 Avslutning

En extra finess som programmet erbjuder är omstart. Om transpondern får behov att startas om, reagerar programmet på detta och kör initialiseringsfunktionerna på nytt. Det kan tänkas att flera system i framtiden är anslutna till transpondern och att ett av dessa kommenderar transpondern att starta om. Resultatet blir en snabbare omstart än om de olika systemen manuellt startas på nytt. Programmet reagerar också om uppkopplingen med transpondern avslutas, varvid den försöker återansluta.

Eftersom programmet i nuvarande utförande inte bryr sig om knapptryckningar eller liknande, går det bara att avsluta programmet genom att låta transpondern skicka nån form av avslutningskommando. För att demonstrera möjligheten till omstart, startas programmet om varefter det omedelbart avslutas på ett korrekt sätt.

4.3

Programmets uppbyggnad

För att förenkla utvecklingsarbetet har delar som uppenbart hör samman samlats ihop till egna filer. Under arbetets gång byggdes de olika delarna upp successivt under tiden som nya idéer tog form. Detta har medfört att t.ex. filen main.c har delar i sig som egentligen borde varit placerad i filen vip.c. Då detta upptäckts efter avslutat arbete, har det inte justerats, men bör så göras för att få ut optimal funktion av programmet. De delar som programmet är uppbyggt av presenteras nedan. display.c config.c main.c ads_b.c fis_b.c vip.c Bildskärm Serieport Figur 4.2: Programmets delar

main.c

Kärnan i programmet som styr de övriga delarna. Vid start kontrolleras kommando-promten och de växlar som angivs utförs. Funktioner i config.c samt vip.c an-vänds för att justera inställningar i transpondern. Funktioner i filen vip.c anropas för att sända och ta emot meddelanden från transpondern. Under uppstartnings-fasen anropas initialiseringsfunktioner i filerna display.c, ads_b.c och fis_b.c. När ett meddelande tagits emot vidarebefordras det till den del som har hand om att avkoda den mottagna datan. Om inget meddelande har tagits emot anropas i tur och ordning funktioner i filerna display.c, ads_b.c och fis_b.c för att kontrollera och uppdatera intern data vid behov. T.ex. kan transpondern tagit emot data från ett nytt flygplan som behövs ritas ut på skärmen.

4.3. Programmets uppbyggnad 21

vip.c

Hanterar kommunikationen med transpondern. Denna del erbjuder funktioner för att sända/ta emot meddelanden till/från transpondern. Internt hanterar den mo-menten som finns i samband med att data strömmar in från serieport tills data finns tillgänglig för den behövande funktionen och vice versa. Under denna pro-cess packas styrdata, kommandon, sekvensnummer och annan data ihop till ett paket. Därefter beräknas CRC16-kontrollsumma för paketet så att fel enklare kan upptäckas. Till slut kodas paketet så att den data som skickas via serieporten inte innehåller några styrdata som VIP-protokollet använder (denna fas kallas för byte

stuffing). Motsvarande, fast i omvänd ordning, utförs när ett meddelande tas emot

från serieporten.

ads_b.c

Sköter avkodningen av ADS-B data samt håller koll på alla inrapporterade farkoster. Under initialiseringsfasen anropar den en funktion i main.c för att prenumerera på speciella meddelanden. Dessa meddelanden kommer transpondern skicka så fort den fått in dem.

När ett nytt flygplan kommer inom mottagningsområdet för transpondern, kommer denna avkodningsfunktion upptäcka att det är ett nytt flygplan och pla-cera planets information i en stor lista tillsammans med de redan upptäckta planen. När ny data skrivs i i listan, lagras den aktuella tiden tillsammans med platets öv-riga data. Under tiden som inga meddelanden tas emot kommer en funktion köras för att kontrollera de registrerade planen. Om deras data är för gammal, plockas planet bort i från listan.

fis_b.c

Är tänkt att hantera FIS-B data på motsvarande sätt som ads_b.c. Information som kan skickas är bl.a. textinformation om t.ex. väder och olika förhållanden på flygplatser. Kan tänkas att detta kan ersätta mycket av vanlig radiokommunikation.

FIS-B är ej implementerad i detta examensarbete.

display.c

Visar all data om näraliggande farkoster. Hämtar data ifrån en lista i filen ads_b.c som innehåller alla upptäckta plan. Eftersom detta program bara är en demon-stration skrivs informationen från listan ut till skärmen i form av text och siffror, men bara den information som har blivit uppdaterad.

config.c

Konfigurerar transpondern. Aktiveras via kommandopromten med växeln -config. På grund av att detta program endast är en demonstration, har inställningarna byggts in i koden. Lämpligt vore att inställningar läses från en vanlig textfil, så det blir enkelt att konfigurera transpondern på egen hand.

4.4

Datastrukturer

För att samla ihop de variabler som indirekt är sammankopplade till varandra, infördes två speciella datastrukturer. Den ena (vip_data) är specifikt anpassat till VIP-protokollet som Sectra har tagit fram till sin transponder. Den andra

(adsb_data) är anpassad för att hantera ADS-B data.

adsb_data

Innehåller flygplanets identitet, position, höjd, hastighet, riktning samt variabler för att hantera mindre noggranna positionsrapporter. I programmet finns det en datastruktur för varje farkost som transpondern har mottagit data ifrån. Denna datastruktur lämpar sig att bygga ut för att lagra annan information om respektive flygplan. T.ex. finns möjlighet att få reda på vilken flygväg planen har planerat. Genom att ta hänsyn till denna information kan man minska risken att flyga i vägen för varandra.

vip_data

Används vid sändning och mottagning av meddelanden. Innehåller typ av medde-lande, sekvensnummer, kommando och antal byte data som meddelandet innehål-ler. Genom att jämföra datastrukturen av ett mottaget meddelande med det som tidigare sänts, kan man enkelt avgöra om ett svar har kommit på den motsvarande förfrågan.

4.5

Variabler

I filerna ads_b.c och vip.c finns några variabler som är speciellt värda att näm-nas. Dessa har betydelse för flertalet funktioner i nästan alla de filer som ingår i programmet.

ads_b.c

adsb_data own_location har till uppgift att lagra planets egen position medan adsb_data plane_list[maximum_planes] innehåller information om omgivande

4.5. Variabler 23

flygplan, markstationer och andra farkoster som sänder ADS-B information. Ef-tersom nya plan kommer och går, måste listan vara organiserad på ett sätt som gör det enkelt att addera nya plan och ta bort de plan som blivit inaktuella. Detta ordnas genom att nya plan adderas sist till listan, medan det sista planet i listan flyttas till det den position som motsvarar det plan som blivit inaktuellt. Därefter rensas den sista positionen på sitt innehåll för att det inte skall behandlas ännu en gång. Av den anledningen kan inte ett plan kopplas till en viss position i listan, utan ICAO-adressen måste utnyttjas för att hitta ett specifikt plan.

vip.c

Den del av programmet som sköter kommunikationen med transpondern har ett antal fält (arrays). Dessa har till uppgift att mellanlagra den data som strömmar in från serieporten fram tills dess att all data har extraherats.

byte serial_in_buffert[def_serial_buffert_size] byte serial_out_buffert[def_serial_buffert_size] word serial_in_buffert_size

word serial_out_buffert_size

Ovan angivna fält och variabler har till uppgift att hantera in- och utmatningen av data till och från serieporten. Storleken på fälten är anpassade till hur mycket data som VIP-protokollet kan hantera per paket. serial_in_buffert_size och serial_out_buffert_size håller reda på hur mycket data som respektive fält in-nehåller. När ett komplett datapaket har tagits emot packas paketet upp till ett annat fält. Därefter nollställs detta fält och ny data kan tas emot. Vid data som strömmar ut till serieporten är hanteringen lite enklare. De rutiner som finns in-byggda i operativsystemet tar hand om den utgående datan direkt. Detta gör att innehållet i detta fält skickas iväg på en gång. När ny data sedan ska skickas skrivs fältet över på nytt samtidigt som den nya storleken anges.

byte pdu_buffert[def_pdu_packet_buffert_size] byte *const pdu_parameter_buffert

byte *const adu_call_buffert byte *const adu_reply_buffert byte *const adu_indication_buffert byte *const adu_call_parameter_buffert byte *const adu_reply_parameter_buffert byte *const adu_indication_parameter_buffert

För att förenkla hanteringen av de olika lager som VIP-protokollet är uppdelat i, används endast ett fält. Samtidigt finns det ett antal olika pekare som används för

att peka ut de olika lagren i fältet pdu_buffert. Detta fält fungerar både för mot-tagning och sändning av meddelanden. Anledningen till att endast ett fält används är för att spara minne, eftersom det inte är nödvändigt att sända och ta emot data precis samtidigt. De olika pekarna används på olika ställen i programmet, beroende på vilken typ av meddelande det är. De tre sistnämnda pekarna används för att skriva och läsa den data som hör ihop med meddelandet, medan övriga används internt i filen vip.c.

För mer detaljerad information om VIP-protokollet, se dokumentet “SkyNet“ från Sectra Wireless AB.

4.6

Handhavande

Syftet med examensarbetet var att skapa ett program för att arbeta vidare på, eller åtminstone ett antal funktioner som kan utnyttjas vid tillverkning av ett nytt program. För att kunna utnyttja programmet så som det för närvarande ser ut, behöver vissa delar omarbetas.

Stommen i programmet är baserad på att förmedla meddelanden till de oli-ka funktionerna som är specialiserade för att ta hand om dessa. För närvarande är denna del placerad i filen main.c, men bör flyttas till filen vip.c. Detta för att kunna sammankoppla mottagningsdelen och meddelandefördelningen. Ifall ett meddelande kommer in under tiden som en anropande funktion väntar på ett spe-cifikt meddelande, kan det snabbt tas om hand och därefter återgå till att vänta som tidigare.

Även den del som har hand om prenumerationer på meddelanden bör flyttas in i filen vip.c. Detta för att meddelandefördelningen skall fungera tillfredsställande. För att kunna ta emot meddelanden anropas funktionen check_message() kontinuerligt för att läsa ifrån serieporten och ta emot inkommande data. Funk-tionen returnerar omedelbart med ett värden för att indikera om det finns ett nytt paket eller inte. Om det inkommit ett helt paket kan funktionen get_message() användas för att extrahera information och innehåll i det. Det finns också funk-tioner för att sköta detta automatiskt, och återvända med ett nytt paket eller efter maximalt 2 sekunder utan paket. Detta kan användas under uppstart för att skicka konfigureringskommandon till transpondern och enkelt få tillbaka svaret på om kommandot lyckades. För närvarande är några av dessa kommandon mindre bra konstruerade, eftersom de slänger alla andra meddelanden än det önskade sva-ret. Om ovan nämnda omskrivningar genomförs, kan dessa kommandon användas under drift också.

Ett antal funktioner för att skicka konfigureringskommandon samt funktioner för att hämta data från transpondern finns färdigskrivna. Dessa är baserade på

4.7. Programflöde 25

de funktioner som slänger mindre önskade meddelande. Om de endast används under uppstart fungerar de även under nuvarande former, men givetvis även efter eventuell omstrukturering. Dessa funktioner bidrar till att förenkla hanteringen av vissa av transponderns alla funktioner. Fler liknade är givetvis att föredra.

4.7

Programflöde

För att till viss del lättare se hur en program är uppbyggt och fungerar, används ibland flödelsediagram. I detta examensarbete har detta inte används på grund av att det skulle bli alltför oöverskådligt. Dock kommer några delar av programmet ändå visualiseras genom flödelsediagram.

4.7.1 Huvudprogrammet

Figur 4.3 (sidan 27) beskriver den kod som finns i filen main.c. Den är till stor del uppdelad i två delar, en för hantering av mottagna paket med tillhörande förmedling och en för att uppdatera mottagen data samt underhålla listor och variabler.

4.7.2 Mottagning av paket

Figur 4.4 (sidan 28) visar hur mottagningen av data sker i stora drag. Främst vilken princip som används för att hantera de problem som hör samman med mottagning av data utan att samtidigt låsa programmet i övrigt.

4.7.3 Avkodning av mottagna paket

Figur 4.5 (sidan 29) illustrerar i en förenklad form de steg som behövs för att avkoda de paket som tas emot. Detaljer som hör samman med de olika lagren i avkodningen, förutom datalinklagret, sammanfattas med att dess parametrar sparas i en bifogad datastruktur. Mer detaljer rörande mottagningen finns i filen

vip.c.

4.7.4 Avkodning av ADS-B-data

Figur 4.6 (sidan 30) visar till största del hur nya plan adderas till en gemensam lista. Därefter pekas det plan (befintligt som nytt) ut för att mottaga ny eller uppdaterad data. Denna kod har placerats i filen ads_b.c som i sig utgör en slags programmodul. Detta för att enkelt kunna göra liknande moduler för att hantera andra slags format.

4.7.5 ”Sortering” av ADS-B-data

Figur 4.7 (sidan 31) beskriver den procedur som finns för att underhålla den lista som hela tiden växer för varje nyupptäckt plan. Sorteringsrutinen är enkel men ändå väldigt effektiv, eftersom det inte finns något krav på ording i listan. Det enda som den gör är att se till att listan inte innehålla några luckor. Vid uppdatering av grafiken på skärmen, utnyttjas nummer på varje registrerat plan.

4.7. Programflöde 27 main() initialisera variabler m.m. nytt meddelande ? uppdatera: skärmen uppdatera: ADS-B variabler uppdatera: FIS-B variabler fördela alla meddelanden till rätt rutiner anropa: ADS-B rutin anropa: FIS-B rutin rutiner för övriga meddelanden okända meddelanden omstarts-meddelanden avsluts-meddelanden exit() ja nej Figur 4.3: Huvudprogrammet

check_message() fas=1 ? returnera: fel fas=4 ? returnera: paket väntar läs en byte från serieporten ny byte mottagen ? returnera: inget fel testa fas startbyte ? spara byte i listan fas=3 spara byte i listan stoppbyte ? fas=4 returnera: nytt paket open_comport() öppna serieport ok ? returnera: fel fas=2 returnera: ok ja nej ja nej nej ja nej ja nej ja fas2 fas3 nej ja

4.7. Programflöde 29 get_message() fas=4 ? returnera: ej fel avkoda datalinklagret återställ mot-tagningsbuffert sätt fas=2 CRC16 korrekt ? returnera: fel spara parametrar i bifogad datastruktur testa returvärde returnera: fel returnera: nytt paket nej ja nej ja fel ok

avkodningsrutin extrahera ICAO-adress adress lika med adress i lista ? addera nytt plan

sist till listan

extrahera och anpassa all data

i meddelandet skall datan uppdateras ? uppdatera rätt datastruktur med avkodad data

spara och justera noggrannheten i datastrukturen returnera: ok slut på listan nej ja ja nej

4.7. Programflöde 31 sorteringsrutin testa senaste uppdatering för aktuellt plan för gammal ?

kopiera data från sista position i listan till aktuell position

rensa sista positionen i listan, uppdatera listans längd returnera: ok slut på listan nej ja

KAPITEL 5

Avslutning

I denna del presenteras resultatet av examensarbetet. Förslag på förbättringar av programmet finns också beskrivna. Alla förkortningar som använts i rapporten samt källförteckning presenteras i slutet av detta kapitel tillsammans med den ursprungliga kravspecifikationen.

5.1

Resultat

Programmet som skapats har visat sig fungera till stor del. Vissa delar har ej kun-nat testas på grund av att programmet som emulerat transpondern inte har varit fullt funktionellt. Emulatorn behövde nämligen en riktig GNSS-mottagare för att kunna fungera korrekt. Det är ändå osäkert om detta hade bidragit till att av-göra om programmet fungerat tillfredsställande. De mest grundläggande delarna som t.ex. det protokoll som används för att kontrollera och överföra data mellan transpondern och presentationssystemet har dock konstaterats fungera väl. Andra delar har testats genom avlusningsprogram (debugger) och på så sätt undersökts någorlunda väl. Detta är dock ingen garanti för att programmet fungerar samman-taget i verkliga miljöer.

Genom att bristerna i emulatorn upptäcktes i slutet av arbetet, har mycket möda gått åt att spåra problem i koden som sedan visats sig bero på andra faktorer. Den slutsats som man kan dra av detta är att datablad och instruktioner kan tolkas på olika sätt. Även de standarder som organisationer sammanställer kan implementeras på olika sätt beroende på oklarheter i beskrivningarna.

Ett av de större problemet har varit att få tag i information om hur serie-kommunikation används på en betydande lägre nivå jämfört med vanliga program. Den informationsdatabas från Microsoft, som användes i samband med utveck-lingsplattformen Visual C, har visat sig vara väldigt svåranvändbar. Klart är att

ANSI-C inte är något som betraktas som relevant för dem, och därigenom inte värt att stödja till fullo. Efter att ha undersökt C-funktioner i Visual C som Microsoft själva skrivit, hittades de eftertraktade funktionerna för att hantera seriekommuni-kationen på den lägsta nivån. Normalt antas att endast text skickas via serieporten eller att programmet vill vänta på att all data anlänt innan den kan köra vidare. Så var inte fallet i detta program, som utnyttjar binär data samt förlitar sig på att alla delar endast tar en betydligt liten del av tiden i anspråk och framförallt inte väntar på något.

5.2

Rapporten

En betydligt längre tid än planerat har lagts på rapportskrivandet. Detta skulle kunna undvikits genom att fördela denna del under hela examensarbetet. På grund av att inriktningen ändrades efter halva tiden, användes denna kvarvarande tid uteslutande till programmering. När det sedan var dags att påbörja rapporten, infann sig en viss skrivkramp. Detta löstes som synes ändå.

För att undvika problem med layouten har rapporten skrivits i ett slags

pro-grammeringsspråk kallat LA_{TEX. Detta fungerar genom att infoga styrkommandon}

i en vanlig text och sedan kompilera detta. Fördelen jämfört med t.ex. MS-Word är att det mesta går att göra och att råmaterialet till dokumentet är sparat i vanligt textformat. Nackdelen är att resultatet inte syns direkt och att en viss tid äts upp av upprepande kompileringar, för att se om ändringarna blev bra.

5.3

Möjliga förbättringar

Denna del kan göras väldigt lång. Därför presenteras endast de viktigaste föränd-ringarna. Vissa delar är kanske inte relevanta för detta examensarbetet, utan en mer generell tanke på förbättringar.

• Skriva om koden så att funktionerna i filen main.c som hör till initialiseringen

och prenumerationen av olika VDL4-meddelanden, istället placeras i filen vip.c.

• Den del i filen main.c som testar mottagna meddelanden och anropar andra

funktioner för att avkoda dem bör placeras i filen vip.c. På så sätt samlas alla snarlika funktioner under samma tak.

• De funktionerna i filen vip.c som väntar på specifika meddelanden och

släng-er andra meddelanden undsläng-er tiden bör skrivas om. Istället bör meddelanden avkodas under tiden som programmet väntar på andra, och när det önska-de medönska-delanönska-det anlänönska-der, returneras kontrollen åter till huvudprogrammet. Dessa funktioner används normalt under uppstart.

5.4. Källförteckning och länkar 35

• Lägga till hantering av TCP och onoggrannhet i datastrukturen adsb_data

för att kunna avgöra vart planen har planerat att åka, samt för att kunna bestämma ett område som ett planet kan befinna sig inom. På så sätt kan det teoretiskt minsta avståndet till omgivande plan förtydligas.

• Anpassning till AerotechTelubs befintliga rutiner för grafikritning har ej

ta-gits i beaktning vid programmets planering. Detta beroende på att koden inte varit tillgänglig av olika skäl. Risken är att denna del inte har sam-ma grundtanke om att inte låsa eller skapa för stora tidsfördröjningar som programmet i examensarbetet har.

• Mycket av databeräkningarna kan med stor fördel placeras i transponderns

program. Bland annat de delar som håller koll på alla omgivande farkosters data. Detta eftersom transpondern sedan tidigare håller koll på de tidsluc-kor som reserverats av omgivande farkoster samt beräknar den förbättrade positionen ur de mottagna dataströmmarna för de olika flygplanen. De delar som istället bör prioriteras är grafiken och interaktionen till piloterna, samt andra delar som inte direkt hör till ökad flygsäkerhet.

5.4

Källförteckning och länkar

AerotechTelub (division Sensorsystem) www.aerotechtelub.se

VDL4 Interface Protocol Skynet (00.24-5.01.doc) Sectra Wireless Technologies AB

www.sectra.se/wireless/

Diverse relevanta dokument blinder.lfv.se/ans/card/document.htm

Manual on Detailed Technical Specifications for the

VDL Mode 4 Digital Link (Appedix B, Revision to AMCP/7-WP/81) blinder.lfv.se/ans/card/docs/pdf/tm_amcp_rev2%20chv51.pdf

GP&C Systems International AB www.gpc.se

Serial Programming Guide for POSIX Operating Systems www.easysw.com/˜mike/serial/

Information om LA_TEX

BILAGA A

Kravspecifikation

Följande sida visar den ursprungliga kravspecifikationen så som arbetet var utfor-mat till en början. Förändringar som gjordes direkt var längden på examensarbe-tet, från 20 till 10 poäng. Detta medförde att det skulle bli vissa svårigheter att hinna med sammanfogningen mellan kommunikationsgränssittet och en befintlig programvarumodul för grafikhantering. Istället ersattes denna del med en enkel textutskrift till skärm.

Ytterligare förändringar ägde rum strax innan halva tiden, då programme-ringsspråket byttes från C++ till ANSI-C. Detta visade sig inte medföra så stora problem eftersom mycket av koden enkelt kunde omvandlas till ANSI-C. Andra delar som t.ex. klasser omvandlades till enklare datastrukturer.

Exjobb på division Sensorsystem

Titel: Programvaruutveckling för ADS-B, 20p (ref.nr. 8006) Beskrivning av examensarbetet/uppsatsen:

Bakgrund

Automatic Dependant Surveillence Broadcast (ADS-B) är en ny teknik som används för att utbyta information mellan flygplan och/eller trafik-ledningssystem. AerotechTelub utvecklar bland annat presentationssystem (dator+display) för placering i flygplan och vill komplettera befintlig programvara med programvarumoduler för ADS-B.

Uppgift

Definiera, utveckla och dokumentera programvarumodul för kommunika-tion med ADS-B transponder.

Utvecklingsmiljö: PC, Microsoft Visual C++

Programspråk: C++ med MFC

Ort för examensarbete/uppsats: Linköping

Examensarbetes/uppsatsens längd: 20 veckor

Önskat antal studenter: 1 person

Börja tidigast: 2002-05-01

Börja senast: 2002-08-01

Kontaktperson: Pedro Lundquist

Avdelning: Division Sensorsystem

Telefon: 013-23 15 95

E-post: pedro.lundquist@aerotechtelub.se

Adress: Ingen gatu/box uppgift

BILAGA B

Funktionsbeskrivning

De funktioner som programmet är uppdelat i kommer att beskrivas i denna del. Många av dem har namn som gör dem ganska självförklarande medan andra kräver en mer ingående förklaring av vad de gör. I vissa fall är också deras in och utdata av speciellt intresse. Funktionerna är grupperade till de filer som de härstammar ifrån.

B.1

main.c

int main(int argc, char *argv[])

Programmets huvudfunktion som tar kommandoraden som inparameter. Komman-doraden blir uppdelad i ord som separeras med mellanslag. char *argv[] inne-håller pekare till de textsträngar som skrevs på kommandoraden, medan int argc anger hur många strängar det finns. I denna funktion sker sammankopplingen av programmets olika delar. Det testas om det kommit något meddelande, och om så är fallet anropas den del som kan ta hand om det. Under tiden som det inte kommer in några meddelanden anropas de olika delarna ifall de har någon data som behöver uppdateras. Detta görs sedan hela tiden fram till ett meddelande om avslut kommer från transpondern.

byte subscribe_on_message(byte id_number,byte plugin_number)

Denna funktion har hand om att begära prenumeration på en specifik typ av med-delande från transpondern samt att lagra vilken insticksmodul som begärde detta. För närvarande använder bara filen ads_b.c denna funktion, men tänkbart är att filen fis_b.c och framtida insticksmoduler också kan utnyttja detta.