1 \chapter{Technologien der Flugsicherung}
2 Die Flugüberwachung bietet eine Reihe von Möglichkeiten den täglichen Flugverkehr zu erfassen, hier sollen die Techniken erläutert werden. Zur erfolgreichen Sicherung des Luftverkehrs ist es notwendig stets ein möglichst genaues Bild über den kontrollierten Luftraum zu erlangen. Die Schaffung eines Abbildes des Luftraums samt der aktuellen Luftfahrzeugpositionen ist die Grundlage der Flugsicherung und bedarf dedizierter Technologie.\\\\
3 Neben der Bodenkontrolle sind auch die Luftfahrzeuge daran interessiert einen Überblick über den nahe liegenden Luftraum zu kriegen um gegebenenfalls Gefahrensituationen vorzubeugen. Der Pilot muss in der Lage sein Entscheidungen zu treffen, welche die Sicherheit seines Luftfahrzeugs gewährleisten.\\\\
4 Traditionelle Flugsicherung bedient sich dem Sprechfunk zur Übermittlung von Anweisungen und Informationsmeldungen. Sowohl die Bodenstationen als auch die Pilot untereinander sind so in der Lage in Kommunikation zu treten und Vereinbarungen zu treffen was den Flugverlauf betrifft.\\\\
5 Mit dem stetigen Wachstum des Flugverkehrs kommt man in naher Zukunft an die Grenzen der möglichen Sprechfunkkapazitäten, die Abhandlung der Flugsicherung wird erschwert und letztendlich mit dieser Technologie nicht mehr durchführbar werden. Die internationalen Institutionen sind nun bestrebt neue Standards der automatisierten Flugraumüberwachung und Sicherung zu verabschieden, die Unternehmen sind entsprechend daran interessiert funktionierende Lösungen zu entwickeln.\\\\
6 Eine Solche Implementierung stellte das \emph{Automatic Dependent Surveillance - Broadcast}, kurz ADS-B, dar. Zur Vervollständigung des Luftbilds wurde das \emph{Traffic Information Service - Broadcast}, kurz TIS-B, entwickelt und soll parallel zu ADS-B betrieben werden. Die Informationen der Broadcasts werden im sog \emph{Cockpit Display of Traffic Information}, kurz CDTI, verwendet. Das CDTI visualisiert die Luftraumbewegungen im Wirkungsradius des Luftfahrzeugs mit relevanten Zusatzinformationen über die Eigenschaften der Luftfahrzeuge.\\\\
7 In den folgenden Abschnitten sollen die Techniken genauer erläutert werden und die Vor- und Nachteile deutlich gemacht werden.
10 Bei dem Primärradar wird ein gerichteter Hochfrequenzimpuls erzeugt, von dem Flugobjekt reflektiert und anhand der Zeitdifferenz vom Sendezeitpunkt und des Wiedereintreffens die Position des Objekts bestimmt. Dieses Verfahren setzt eine starke Sendeleistung voraus um größere Reichweiten zu erreichen, schließlich muss das Signal den doppelten Abstand von Radar zum Luftfahrzeug überbrücken.\\\\
11 Das Primärradar ist neben der Satellitenüberwachung die einzige Möglichkeiten Luftfahrzeuge zu erfassen, die entweder nicht die technischen Hilfsmittel zur aktiven Radarortung besitzen, oder aber deren Sendeequipment beschädigt oder anderweitig gestört ist. Somit bilden Primärradare bis heute ein flächendeckendes Überwachungsfeld in dicht besiedelten Regionen mit hohem Luftverkehrsaufkommen.\\\\
12 Die Nachteile dieser Überwachungsart liegen in dem hohen Energiebedarf solcher Anlagen, deren notwendige Größe um auch entfernte Objekte erfassen zu können und daraus folgenden sehr hohen Betriebs- und Wartungskosten. Durch die beweglichen Teile ist so eine Anlage besonders anfällig für feinkörnige Verschmutzungen, wie z.B. Wüstensand, was den Betrieb in vielen Regionen unwirtschaftlich macht. Große Gebirgsformationen stören den Empfang und schränken die Reichweite einer Radaranlage stark ein, die Überwachung von tief liegenden Flughäfen wird dadurch erschwert.
14 \section{Sekundärradar}
15 Ursprünglich zur Freund/Feindidentifikation für den militärischen Einsatz entwickelt, ist es zum Standard in der zivilen Luftraumüberwachung geworden. Im Gegensatz zum Primärradar wird hier nicht die passive Reflektion des Signals empfangen und interpretiert, sondern ein aktives Antwortsignal vom Flugobjekt ausgesandt.\\\\
16 Dadurch kann die Signalstärke beim Radar verringert werden, die Antwort erfolgt durch einen Impuls auf einer höheren Frequenz, was nochmals eine Energiebedarfsreduktion beim Luftfahrzeug bedeutet, z.B. das Radar sendet mit 1030MHz und das Objekt antwortet mit 1090MHz. Diese Technik bedeutet eine Energieersparnis für die Radaranlage, während der Energiebedarf seitens des Luftfahrzeugs im vertretbaren Bereich liegt.\\\\
17 Der weitere Vorteil liegt darin, dass das Antwortsignal weitere Informationen über Flugobjekt und dessen Zustand enthält, somit erhöht es die Entscheidungsgrundlage für die Regelung des Verkehrs für die Flugsicherung. So beinhaltet das Antwortsignal u.a. Informationen über Rufzeichen, Flugzeugtyp und die Flugvektoren wie Position, Richtung und Geschwindigkeit. Die lokale, GPS-ermittelte Position hat zudem eine höhere Genauigkeit was die Sicherheit und Effektivität der Überwachung steigert.\\\\
18 Das Sekundärradar teilt viele Merkmale und dadurch auch Nachteile des Primärradars. So ist auch hier die Anschaffung und der Betrieb mit hohen Kosten verbunden und die Einsatzmöglichkeit stark von den örtlichen Gegebenheiten abhängig.
20 \section{Automatic Dependent Surveillance}
21 Der Betrieb von Radaranlagen ist mit sehr hohen Kosten und Aufwand verbunden, was den Einsatz in vielen Regionen der Welt schwierig macht. Natürliche Gegebenheiten wie z.B. Wüsten oder größere Gebirge schränken die Effektivität und Einsetzbarkeit gewöhnlicher Radaranlagen ein. Das führt zu einer unausreichenden Luftraumüberwach\-ung wie auf dem afrikanischen Kontinent oder gar zu überwachungsfreien Regionen wie dem Nordatlantik, großer Teile Alaskas oder auch Australiens.\\\\
22 Eine Alternative dazu stellt ADS-A/B/C dar. ADS-A und ADS-C sind dabei für Interrogationsvorgänge, das heißt das Fluggerät antwortet auf eine explizite Anfragen, während ADS-B einen unaufgeforderten Broadcast darstellt. Weiterhin werden wir uns auf ADS-B zur Erläuterung des Verfahrens beschränken.\\\\
23 Voraussetzung für den Betrieb von ADS-B ist ein Transponder, der ADS-B-konforme Signale versenden und empfangen kann. Besitzt ein Luftfahrzeug entsprechende Ausrüstung, so sendet es periodisch ein oder mehrere Signale. Diese Signale kodieren u.a. die Position, die Flugrichtung, Reisegeschwindigkeit und das Rufzeichen des Senders. Zusätzlich können weiter Informationen wie z.B. Statusmeldungen über den Flugbetrieb im Signal enthalten sein.\\\\
24 Der eigentliche Vorteil von ADS-B liegt darin, dass die Broadcasts von allen teilnehmenden Flugobjekten in Reichweite empfangen und dekodiert werden. So erhalten alle Luftfahrzeuge unabhängig von der Bodenunterstützung ein genaues Luftbild rund um den aktuellen Standort.\\\\
25 Das Resultat ist eine erhöhte Sicherheit, die durch die höhere Abtastraten gewährleistet wird. Zudem erhalten die Flugobjekte unabhängig von Bodenstationen oder Radaren ein Fluglagenbild, welches in entsprechenden CDTI dargestellt werden. Natürlich sind auch Bodenstation in der Lage ADS-B-Signale zu empfangen und können diese an zentrale Stellen weiterleiten, aufbereiten und entsprechenden Flugsicherungsinstanzen bereitstellen. Die zentralen Instanzen kombinieren die Eingangsinformationen mehrerer Empfänger und generieren daraus ein vollständiges Luftverkehrsbild vom höchster Genauigkeit.
28 %\includepdf[pages=1]{adsbtisb.pdf}
29 \includegraphics[width=450pt]{adsb.pdf}
30 \caption{ADS-B Funktion: Signale werden zwischen Luftfahrzeugen ausgetauscht, Bodenstation dient als zusätzlicher Empfänger}
34 \section{Multilateration}
35 Multilateration ist ein Verfahren zur Positionsermittlung von einem Punkt basierend auf der Information mehrerer -- mindestens 4 -- Sensoren mit bekannten Standorten. Anhand von Entfernungsmessungen zwischen dem zu bestimmenden Punkt und den geometrisch verteilten Sensoren, ist es möglich die genaue Position des Punktes zu bestimmen. Die größte Genauigkeit erreicht man durch die Messung der Zeitdifferenzen beim Empfang eines Signals, welches von dem Luftfahrzeug als Broadcast ausgesandt und so von allen Sensoren empfangen wird. Die Zeitdifferenzen des Signals können direkt in ein Abstandsmaß umgerechnet werden, so erhält man die Abstände zwischen Sensoren und Luftfahrzeug mit höchster Präzision. ADS-B ist ein geeignetes Signal für diese Zeitmessung.
37 \section{Traffic Information Service - Broadcast}
38 ADS-B bietet eine kostengünstige und effektive Alternative zum traditionellen Radar, jedoch sind bis dato nicht alle Luftfahrzeuge mit ADS-B-fähigen Transpondern ausgestattet. Ohne ADS-B versenden die Luftfahrzeuge keine Broadcasts, die Flugvektoren bleiben anderen Luftfahrzeugen somit unbekannt. Um den ADS-B-fähigen Flugzeugen trotzdem den Flugverkehr lückenlos abzubilden, sollen TIS-B Transponder eingesetzt werden.\\\\
39 Sog. \emph{Tracker} sind zentrale Einheiten, die von mehreren Quellen Radardaten, bzw. ADS-B-Daten beziehen und daraus ein lückenloses Luftbild generieren. Sendet ein Luftfahrzeug keine ADS-B-Signale, so wird es durch örtliche Radaranlagen erfasst und im Tracker verarbeitet. Dieser liefert die Information über die Luftfahrzeuge an entsprechende TIS-B Transceiver Bodenstationen weiter. Die TIS-B Bodenstationen versenden die Informationen über ein \emph{ICAO Extended Squitter Format} und vervollständigen somit das Luftbild der Empfänger. TIS-B-Signale sind kompatibel mit ADS-B-Transpondern, die Informationen sind inhaltlich nahezu gleichwertig zu ADS-B-Signalen.\\\\
40 Die Integration der TIS-B-Funktionalität in einen bestehenden ADS-B Transponder wird in diesem Bericht und den Dokumenten im Anhang detailliert erläutert.
43 %\includepdf[pages=2]{adsbtisb.pdf}
44 \includegraphics[width=450pt]{tisb.pdf}
45 \caption{TIS-B-Funktion: ADS-B-fähige Luftfahrzeuge erhalten Radarinformationen über nicht ADS-B-fähige Luftfahrzeuge durch TIS-B-Bodenstation}
49 \chapter{Quadrant ADS-B Transponder}
50 Der \emph{Quadrant ADS-B Transponder} realisiert den Empfang, Filterung und Aufbereitung von ADS-B-Signalen. Die Signale werden dekodiert, interpretiert und aus den gelieferten Informationen ein ASTERIX-Output generiert. Die Transponder versenden mit Hilfe einer Netzwerkschnittstelle die ASTERIX-Daten an Tracker, wo die Daten zentral aufbereitet werden und zur Genauigkeit und Vollständigkeit des Luftbildes beitragen.\\\\
53 \includegraphics[width=50pt]{images/quadrant.png}
54 \caption{Quadrant ADS-B Sensor: Outdoor-Version mit Standardantenne}
57 Der Transponder ist ein autonomes System mit Fernwartungsmechanismus. Die Netzwerkinteraktion des Systems erlaubt eine vollständige Konfigurierbarkeit, Kontrolle und Steuerung des Transponders per SMTP und einer konsolenbasierten Applikation. Zudem arbeitet das Gerät gemäß Sicherheitsstandards, integriert somit Selbstdiagnosen und Fehlerkorrektur bzw. Systemwiederherstellung.\\\\
58 Der Quadrant Transponder ist durch die robuste Bauweise und geeignete Komponentenwahl in allen klimatischen Gebieten der Erde einsetzbar. Sowohl im großen Gebirge, wie vorzufinden in Peru und den Schweizer Alpen, als auch in trockenen Wüstenregionen wie den Vereinigten Arabischen Emiraten wurde das Gerät erfolgreich getestet und wird teilweise bereits operativ eingesetzt.
60 \section{Sensorhardware}
61 Der Sensor besteht aus einer Antenne samt Verstärker, einem GPS-Empfänger und der integrierten Hardware in einem Metallgehäuse. Als integrierte Lösung werden u.a. einen XILINX-FPGA zur Echtzeitsignalverarbeitung eingesetzt. Der Intel XScale PXA270 Digital Processor ist für die restliche Bearbeitungsprozeduren zuständig, hauptsächlich sind das die Funktionen des Betriebssystems. Mit der Quadrant-Standardantenne wird ein Operationsradius von über 250 nautischen Meilen erreicht bei einer maximalen Leistungsaufnahme von 10W.
64 Als Betriebssystem wird ein \unit{\micro Linux} eingesetzt, die Softwaremodule
65 sind in der Programmiersprache C entwickelt. Das Betriebssystem erlaubt einen hohen Grad an Anpassungsfähigkeit, gleichzeitig bietet es einen stabilen Kernel. Zur Steigerung der Effizienz werden nur die notwendigen Module geladen, dies erlaubt den Einsatz auf Hardware mit begrenzter Rechenkapazität und Speicher.
68 Der Quadrant Sensor empfängt neben Mode-3/A und Mode-C auch Mode-S Formate definiert in ICAO Annex 10 (RTCA DO260, DO260A).\\\\
69 Nach der Interpretation der Downlink-Formate generiert der Sensor Datenpakete im ASTERIX Category 21 Format. Diese werden über eine Ethernet-Schnittstelle an Tracker und andere Surveillance Clients weitergeleitet.
72 Die Antenne ist durch ein Empfangsteil mit dem FPGA verbunden, beim Empfang werden entsprechende FPGA-Register mit den Daten gefüllt.\\\\
73 Der GPS-Empfänger ist über eine R232-Schnittstelle mit dem Sensor verbunden. Dabei geht ein Datenkanal an den PXA270-Prozessor, während ein weiterer den PPS-Impuls für das FPGA bereitstellt.
75 \section{Systemmodule}
76 Neben den Linux-Systemmodulen, stellen eine Reihe von Modulen die Funktionalität des Quadrant bereit. Dabei gibt es bearbeitende Prozesse, die z.B. für das Decodieren, Interpretieren und Encodieren von Nachrichten zuständig sind und Prozesse, die für die Überwachung des Gesamtsystems verantwortlich sind.
78 \subsection{System Controller}
79 Der System Controller ist der Überwachungs- und Regelungsmodul in der
80 Quadrant-Architektur. Nach dem Boot-Vorgang melden sich alle Prozesse, außer
81 dem Hardware Monitor, bei dem System Controller an. Ab diesem Zeitpunkt
82 überwacht dieser die Prozesse mit Hilfe eines Watchdog-Protokolls und greift
83 sobald ein Prozess mehrfach nicht auf den Heartbeat-Request antwortet. In der
84 Regel hat dies einen Neustart des Prozesses zur Folge und soll garantieren,
85 dass das sich System stets in einem korrekten und definierten Zustand befindet.
87 \subsection{DSP Watchdog}
88 Zur Unterstützung des System Controllers, überwacht der DSP Watchdog die
89 Aktivitäten des FPGA. Bei Fehlverhalten kann dieser ebenfalls eingreifen und
90 den FPGA neu initiieren. Der DSP Watchdog wird selbst auch vom System Controller
93 \subsection{Hardware Monitor}
94 Der Hardware Monitor kommuniziert über den i2c-Bus mit der Hardware um
95 Spannungs- und Temperaturinformationen zu gewinnen. Zudem
96 stellt er auch den Synchronisationsstatus des NTP fest. Performance bedingt stellt
97 der Prozess eine Ausnahme dar, denn er wird nicht vom System Controller überwacht.
99 \subsection{SNMP Agent}
100 Der SNMP Agent ist für das Beantworten von SNMP-Get/Set Requests und das
101 Generieren von SNMP-Notifications zuständig. Das System lässt sich über SNMP überwachen,
102 steuern und konfigurieren. Als SNMP-Monitor wird u.a. QCMS eingesetzt.
104 \subsection{Maintenance Application}
105 Die Maintenance Application ist zur Konfiguration und Überwachung des Systems
106 über eine Konsole konzipiert.
108 \subsection{Core Surveillance}
109 Die Core Surveillance ist der informationsverarbeitende Prozess für ADS-B. Die vom
110 FPGA bereitgestellten Nachrichten werden aus einer FIFO gelesen, dekodiert,
111 interpretiert und weiterverarbeitet. Abhängig vom Nachrichtentyp und dessen
112 Inhalt, werden die Nachrichten:
114 \item zum Multilaterationsprozessor weitergeleitet
115 \item zum Kodieren von Asterix CAT21 Nachrichten verwendet
116 \item zur internen/externen Synchronisation genutzt
118 Weiterhin dekodiert der Prozess den Datenstrom des GPS und synchronisiert somit die Systemzeit.
120 \chapter{Quadrant TIS-B Transceiver}
121 Basierend auf der vorhandenen Hardware und Software des Quadrant ADS-B Transponders, sollte ein TIS-B Transceiver entwickelt werden. Aufgaben des TIS-B Transceiver sind die Kommunikation mit dem TIS-B Server abzuwickeln und TIS-B Nachrichten chronologisch korrekt zu versenden. Das TIS-B System soll in den Quadrant ADS-B Transponder integriert werden, sodass dieser nun sowohl als Sende- als auch Empfangseinheit agiert.
123 \section{TIS-B Erweiterung}
124 Um die TIS-B-Funktionalität auf dem Quadrant ADS-B Sensor zu integrieren waren eine Reihe von Anpassungen nötig. Zum Einen wurde die Hardware erweitert um das Senden zu ermöglichen. Die Antenne wurde dazu durch eine bilaterale Sende- und Empfangseinheit ersetzt, die Hardwaresteuerung entsprechend umgesetzt. Zur Integration mussten diverse notwendige Erweiterungen am Treiber und der vorhandenen Software realisiert werden. Als verarbeitende Instanz wurde ein TIS-B Softwaremodul entwickelt und als weiterer Prozess in das System integriert. Die Softwareerweiterung für die TIS-B-Funktionalität war der Schwerpunkt des Praktikums und wird im Detail in Kapitel \ref{chapter:tis-b software} erläutert.
126 \item[Verantwortlicher:] Eugen Sawin (CS/PRO)
127 \item[Meine Aufgaben:]
129 \item Evaluierung und Anpassung der Anforderungen
130 \item Evaluierung und Anpassung der Schnittstellenspezifikation
131 \item Erstellung des Software-Designs
132 \item Implementierung der TIS-B Software
133 \item Integration in den Quadrant ADS-B Sensor
134 \item Erstellung der Systemtestspezifikation
135 \item Testen der Software und des Systems
139 \subsection{Hardwareerweiterung}
140 Der Sensor wurde um eine Sendeeinheit erweitert. Zusätzlich wird ein Dämpfungsglied eingesetzt, der das ausgehende Signal um eine variable Größe dämpft.\\\\
141 Aufgrund von gesetzlichen Sendefrequenzbestimmungen war es nicht möglich die Sendefunktion mit einer aktiven Antenne zu verifizieren, stattdessen wurde der RF-Ausgang des Quadrants mit dessen RF-Eingang kurzgeschlossen, mit dazwischen gesetzten Dämpfern wurde die Signalstärke korrigiert um eine Beschädigung der Hardware zu vermeiden. Im Kapitel \ref{verifikation} wird der Testaufbau detaillierter erläutert.
143 \item[Verantwortlicher:] Stefan Schneider (HUS/ATE)
144 \item[Meine Aufgaben:] Testen und Verifikation der Sendefunktion und Sende"-leistungs"-dämpfung
147 \subsection{FPGA-Anpassung}
148 Am FPGA mussten diverse Modifikationen vorgenommen werden um die erwartete Sendefunktionalität zu unterstützen. Es wurde ein 12 Registerset definiert, indem der TIS-B-Prozess die Sendenachrichten und Konfigurationswerte ablegt. Da
149 das Versenden zeitlich festgelegt auf \unit{10}{\micro s} genau ausgeführt werden muss, wurde die letzte Phase des Scheduling auf demr FPGA realisieren.
151 \item[Verantwortlicher:] Sergii Kibets (HUS/ATE)
152 \item[Meine Aufgaben:]
154 \item Definition des FPGA-Interface für TIS-B
155 \item Festlegung des Scheduling-Verfahrens
156 \item Testen und Verifikation der FPGA-Funktionalität
160 \subsection{Treibererweiterung}
161 Bisher war die Schnittstelle zwischen Software und FPGA auf lesenden Zugriff auf die FIFO beschränkt. Der Treiber wurde um
162 weiter 12 beschreibbare Register erweitert. Weiterhin wurde ein TIS-B Interrupt bereitgestellt, der die Bereitschaft des Registersatzes signalisiert. Der Interrupt musste entsprechend konfiguriert werden.
164 \item[Verantwortlicher:] Eugen Sawin (CS/PRO)
165 \item[Meine Aufgaben:]
167 \item Erweiterung des Registersatzes
168 \item Bereitstellung des TIS-B Interrupts
169 \item Testen und Verifikation der FPGA-Funktion bezüglich des Interrupts: auf
170 Ebenen der Hardware, Treiber und Software
174 \section{ASTERIX Category 21 Version 1.3}
175 Nach Abschluss der TIS-B-Erweiterung wurde die Unterstützung des ASTERIX Category 21 von Version 0.26 auf Version 1.3 hochgestuft. Hierfür waren Änderungen sowohl im Dekodieren der empfangenen ADS-B-Nachrichten notwendig, als auch die Erweiterung der Generierung der ASTERIX-Formate.\\\\
176 Bisher bot Quadrant Unterstützung für die ASTERIX CAT 21 Version 0.23 und 0.26, welche nur im Detail Unterschiede aufweisen. Das Format in der Version 1.3 beinhaltet grundlegende Änderungen gegenüber den vorherigen Versionen. So mussten bereits genutzte Identifikationsfelder anders interpretiert werden, außerdem wurde das Format um einige neue Informationseinheiten erweitert. Eine besondere Schwierigkeit lag in der eingeführten semantischen Abhängigkeiten zwischen einzelnen Informationseinheiten innerhalb eines Signals und auch verteilte in mehreren Downlinks.\\\\
177 Die Änderungen waren mit dem vorhandenen Interpretierungsprozess nicht kompatibel und musst von Grund auf neu strukturiert werden. Das folgende Arbeitspaket bestand aus der Erweiterung des Parsers und der Implementierung der Verbesserungsvorschlag.
179 \item[Verantwortlicher:] Eugen Beck (HUS/ATE)
180 \item[Meine Aufgaben:]
182 \item Umstrukturierung der Dekodierungs- und Interpretationsarchitektur
183 \item Erweiterung der Versionsumschaltung
184 \item Unterstützung bei der Implementierung der Interpretationsfunktionen
188 \section{Synchronisation mit MLAT Central Processor}
189 Um den Quadrant erfolgreich als Multilaterationssensor einsetzen zu können ist es notwendig einen Mechanismus der Zeitsynchronisation zwischen dem Sensor und dem MLAT Central Processor zu liefern. Da das Multilaterationsverfahren auf der Messung von minimalen Zeitunterschieden basiert, ist eine hohe Präzision bei der Synchronisation notwendig.\\\\
190 Die Auflösung der Systemuhr ist für so einen Einsatz unzureichend. Es ist notwendig den FPGA-Schrittgeber für die Synchronisation zu nutzen. Um dies zu ermöglichen, war es notwendig die Verarbeitung der verschiedenen FPGA-Interrupts zu erweitern. Da im Falle der Multilateration auch die genaue Position ein Teil der Berechnung ist, war ein Betrieb ohne GPS-Synchronisation nicht praktikabel. Dieser Zustand ermöglichte die Nutzung des GPS-generierten PPS-Signals: man erzeugt mit jedem eingehenden PPS-Impuls ein UDP-Paket mit der Systemzeit und dem FPGA-Counter und sendet dieses an den Central Processor. Dieser kann mit Hilfe dieser Daten ein Zeitbild mit der Auflösung von einer Nanosekunde erstellen und so alle beteiligten Quadrant Sensoren synchronisieren.
192 \item[Verantwortlicher:] Eugen Sawin (CS/PRO)
193 \item[Meine Aufgaben:]
195 \item Spezifizierung des MLAT-Zeitprotokolls
196 \item Erweiterung der Quadrant-Zeitsynchronisationsprozedur um die Generierung der Zeitpakete
200 \chapter{TIS-B Software}
201 \label{chapter:tis-b software}
202 Als reine ADS-B-Sendeeinheiten hatten bisherige Quadrant Softwareversionen keinerlei Unterstützung für den Empfang, die Verarbeitung und das Versenden von TIS-B Nachrichten. Der Schwerpunkt des Praktikums lag in der Entwicklung der TIS-B Software.\\\\
203 In Zusammenarbeit mit QinetiQ sind bereits Dokumente zu den Systemanforderungen und Schnittstellenspezifikation entstanden. Die erste Aufgabe bestand darin die Anforderungen zu evaluieren, wenn nötig zu präzisieren und zu erweitern.
204 Die nächste Phase bestand aus der Bereitstellung eines Entwurfs für die TIS-B-Softwarekomponente und die Integration in die Quadrant-Architektur. Die Realisierung des Entwurfs war die Abschließende Entwicklungsarbeit. Danach folgte die Verifizierung der Komponenten, insbesondere die Bestätigung der Einhaltung der verschiedenen Zeitbegrenzungen zur Laufzeit unter Last.
206 \section{Anforderungen}
207 Die Anforderungen waren zum Beginn der Tätigkeit bereits vorhanden. Lediglich kleinere Änderungen wurden unter Abstimmung mit den Projektleitern und nach einer gründlichen Evaluation eingearbeitet. Hier sollen die die Anforderungen in zusammengefasster Form beschrieben werden, die ausführlichen und vollständigen Anforderungen sind in der \emph{System Requirements Specification}, zu finden in Anhang A. Im folgenden Abschnitten wird die TIS-B Software kurz mit die Software oder das Modul referenziert.
209 \subsection{Musskriterien}
210 Die folgenden Kriterien haben \emph{höchste Priorität}:
212 \item \textbf{Empfangen von TIS-B Send Requests}\\
213 Das Modul soll durch eine Netzwerkschnittstelle Verbindung mit einem TIS-B Server halten. Die Software soll TIS-B Request-Nachrichten von dem Server empfangen, verifizieren und interpretieren. Das TIS-B Request Datenformat ist im \emph{Interface Design Document} festgehalten. Es gibt zwei Basistypen für die TIS-B Send Requests: \emph{primitive} und \emph{scheduled}. Die Software soll primitive Requests unmittelbar versenden, die anderen zeitgesteuert.\\\\
214 Die maximale Latenz beim Versenden von primitiven Requests beträgt 50ms, die Fluktuation der Latenz darf maximal 10ms betragen.
216 \item \textbf{Senden von TIS-B-Nachrichten}\\
217 Das Modul soll TIS-B-Nachrichten generieren und senden. Die Software soll standardkonforme Nachrichten generieren und diese mit Hilfe der Sendeeinheit als Mode-S Extended Squitter-Signal mit einer Frequenz von 1090MHz senden. Den Standard des Uplinkformats stellt ICAO Annex 10 Volume IV.
219 \item \textbf{Scheduling}\\
220 Das Modul soll TIS-B Send Requests vom Typ \emph{scheduled} auf 10\micro s genau versenden. Die Software soll die erste Phase des Scheduling bereitstellen. Um die notwendige Genauigkeit zu gewährleisten soll die Software das FPGA Scheduling steuern, welches die zweite Phase des Scheduling realisiert.
222 \item \textbf{SNMP}\\
223 Es soll die SNMP-Schnittstelle erweitert werden um eine Kontrolle über die Konfiguration und den Zustand des Moduls zu gewährleisten. Es sollen SNMP-Notifications versendet werden, falls Fehlerkonditionen auftreten wie z.B. das Überlaufen des Netzwerkstacks oder eines der modulinternen Puffer.
225 \item \textbf{Maintenance Application}\\
226 Es soll die Quadrant Maintenance Application erweitert werden zur Kontrolle und Konfiguration des Moduls.
228 \item \textbf{Sendeleistung}\\
229 Das Modul soll die maximale Sendeleistung/Dämpfung konfigurierbar in 12 Schritten machen, bei einer Auflösung von 1dB. Die Sendeleistung wird durch den Inhalt der TIS-B Requests bestimmt.
232 \subsection{Sollkriterien}
233 Folgende Kriterien \emph{sollen} berücksichtigt werden:
235 \item \textbf{Konfigurierbarkeit}\\
236 Das Modul soll mit Hilfe von SNMP und der Maintenance Application vollständig konfigurierbar sein. Weiterhin soll die Überwachung der Leistung und des Zustands ermöglicht werden. Folgende Statistiken sollen u.a. bereitgestellt werden: Nachrichten empfangen, Nachrichten verworfen und Nachrichten versendet. Die Konfiguration soll u.a. folgende Werte steuern: Transmission ein/aus, minimales Transmissionsinterval und die Empfängerschutzverzögerungen.
238 \item \textbf{Effizienz}
239 Das Modul soll keine Prozessorleistung bei Inaktivität beanspruchen. Die Software soll während der Verarbeitung nicht mehr als Durchschnittlich 50\% Prozessorlast in der Sekunde bewirken.
241 \item \textbf{Kontinuierliches Senden}\\
242 Die Software soll ein effektives Versenden von mehreren zeitlich aufeinander folgenden TIS-B Nachrichten unterstützen. Der sog. \emph{Burst Mode} soll in geeigneten Situationen kurzzeitig den Sendeausstoß maximieren.
244 \item \textbf{Nebenläufiger Betrieb zu ADS-B}\\
245 Die Software soll den ADS-B-Betrieb nicht beeinflussen. Ein paralleler Betrieb von ADS-B und TIS-B soll ohne Qualitätsverlust der Dienste möglich sein. Es gelten Richtlinien für die maximale Sendefensterzeit für TIS-B, damit der Empfang von ADS-B-Signalen nicht gestört wird.
247 \item \textbf{Segmentierung}\\
248 Das Modul soll die segmentbasierte Ausrichtung der Sendeeinheit unterstützen. Ein Segment wird im TIS-B Send Request mit der Kombination von Sektor und Sendeleistung kodiert.
251 \subsection{Abgrenzungskriterien}
252 Folgende Funktionalität soll \emph{nicht} realisiert werden:
254 \item \textbf{TIS-B Server}\\
255 Das Modul soll keine TIS-B Server-Funktionalität bereitstellen, d.h. das Modul soll keine TIS-B Send Requests basierend auf ADS-B Daten generieren.
257 \item \textbf{Semantische Datenprüfung}\\
258 Die Software soll keine semantische Datenprüfung der empfangenen TIS-B Send Requests durchführen. Lediglich die Konsistenz des Formats soll mit Hilfe der Header-Metadaten validiert werden.
260 Nach Abschluss der Anforderungsrevision konnte man mit dem Entwurf der Software beginnen.
263 Vor dem Entwurf des Softwaremoduls galt es sich mit der vorhandenen Quadrant Softwarearchitektur auseinander zusetzen. Die Integration sollte möglichst mit wenigen Veränderungen an dem aktuellen Stand der Software erfolgen.\\\\
264 Bei der Erstellung des Software-Designs wurden alle Anforderungen im Detail realisiert. Besonders zu beachten dabei waren die sicherheitskritischen Merkmale, die das Endsystem zu erbringen hatte. Hierzu zählten:
266 \item strikte Timing-Vorgaben (Reaktionszeiten, Dauer von Prozeduren)
267 \item beschränkte Prozessorauslastung (unter 50\%)
268 \item beschränkte Sendeleistungseinstellung (1-12 dbM)
269 \item begrenzte Sendezeitlaufzeit und Sendehäufigkeit
271 Die Software musste demnach in der Lage sein Sendeanfragen zügig zu verarbeiten, effizient zu speichern und zu sortieren und dabei nur wenig Prozessorlast erzeugen. Je nach Typ der Sendeanfrage, war es entscheidend möglichst schnell zu reagieren
272 und den Sendeprozess unmittelbar einzuleiten oder aber das Sendepaket in einer effizienten Datenstruktur zu puffern.\\\\
273 Eine ausführliche Beschreibung des Entwurfs befindet sich in der \emph{Software Design Description}, zu finden in Anhang D.
275 \subsection{TIS-B Server-Kommunikation}
276 Die Kommunikation mit dem TIS-B Server basiert auf UDP\footnote{User Datagram Protocol -- Ein verbindungsloses, nachrichtenbasiertes Standardprotokoll auf der IP-Schicht.}-Schicht.\\\\
277 Der Server versendet sog. \emph{TIS-B Send Requests}, es können mehrere Requests in einer Nachricht enthalten sein. Informationen über den Inhalt bietet ein Header, hier werden in 4 Bytes der Request-Typ und die Gesamtgröße des Pakets kodiert. Ein Request-Format misst 24 Bytes und beinhaltet das TIS-B-Datagramm -- 14 Byte Mode-S Telegram -- und Metainformationen zum gewünschten Sendezeitpunkt, Sendeleistung und Sendesegmentierung.\\\\
278 Mehr Informationen zum TIS-B-Paketformat sind im Anhang C in 2.1 zu finden, eine detaillierte Beschreibung der externen Schnittstelle ist in Anhang D in 2.1.1 enthalten.
280 \subsection{Scheduling}
281 Das TIS-B-Modul unterstützt sowohl zeitgesteuertes als auch unmittelbares Senden von TIS-B-Nachrichten. Die Schwierigkeit liegt darin die verschiedenen Anforderungen an beide Versandarten zu erfüllen. Die beste Möglichkeit beide Nachrichtentypen effizient zu Verarbeiten lag darin dedizierte Datenstrukturen für jeden Typ bereitzustellen.\\\\
282 Die Prozedur beim Erhalt eines sog. primitive TIS-B Send Requests besteht darin diesen nach der Verifikation der Paketintegrität in eine FIFO\footnote{First In First Out -- Datenstruktur}-Datenstruktur abzulegen. Sobald das FPGA ein freies Registerset signalisiert, wird das älteste Request aus dieser Struktur kopiert und versendet. Nach dem erfolgreichen Versenden wird die Nachricht aus der FIFO entfernt. Ein effektiver Entwurf für die FIFO wurde mit Hilfe eines Ringpuffers realisiert.\\\\
283 Zeitgesteuerten TIS-B-Nachrichten hingegen werden zeitlich sortiert in einer doppelt verketteten Liste aufbereitet. Diese Struktur bietet für den Regelfall die höchste Effizienz und erlaubt basierend auf statischer Speicherallokation eine robuste Implementierung in der nächsten Phase.\\\\
284 Der Nachteil des Zweipufferentwurfs liegt in der Verdopplung des benötigen Pufferspeichers, vorausgesetzt man erwartet eine Gleichverteilung zwischen zeitgesteuerten und primitiven TIS-B Send Requests. Da der Einsatz aber keine Langzeitspeicherung vorsieht, können die Puffer klein gehalten werden, was die ungenutzte Speichermenge vernachlässigbar macht.
286 \subsection{Statusnachrichten}
287 Das TIS-B-Modul sendet periodisch \emph{Service Status} und \emph{Service Statistics} Nachrichten im Format nach ASTERIX Category 23. Die Frequenz der Statusnachrichten ist konfigurierbar. Diese Nachrichten bilden eine standardkonforme Kontrolle über die Leistung und die Funktionalität des Moduls nach dem EUROCONTROL Standard Document for Surveillance Data Exchange.
289 \subsection{SNMP Interface}
290 Die Erweiterung der Quadrant MIB\footnote{Management Information Base -- Ein tabellarisches Beschreibungsformat für das SNMP Interface} erlaubt es auf alle Zustände, Statistiken und Konfigurationen mit Hilfe von sog. \emph{SNMP Manager} zuzugreifen. Eine solche Managementplattform bildet auch das Quadrant QCMS, die Einbindung von der TIS-B Kontrolle wurde hier von einem Comsoft-Mitarbeiter bereitgestellt. Eine genaue Aufstellung der MIB-Erweiterung ist im Anhang D in 2.1.1.3 zu finden.
292 \subsection{Maintenance Application}
293 Die Quadrant Maintenance Application bietet vollständige Kontrolle und Konfigurationsmöglichkeiten über alle Quadrant-Module. Diese Anwendung musste erweitert werden, um Zugriff auf die TIS-B-Funktionalität zu bieten. Die Erweiterung beinhaltet u.a. alle durch die SNMP-Schnittstelle bereitgestellten Funktionen. Die vollständige Konfigurationsmöglichkeiten sind im Anhang D in 2.1.1.4 beschrieben.
295 \subsection{Transmission}
296 TIS-B ist ein Uplinkformat nach ICAO Annex 10. Die Software steuert das zeitlich gesteuerte Versenden der TIS-B-Signale.\\\\
297 Die TIS-B Software basiert auf einem Event-basierten Modell. Mögliche Ereignisse sind:
299 \item Empfang von TIS-B Send Requests
301 \item Watchdog-Interrupt
304 Zum Versenden ist die Signalisierung der Bereitschaft des FPGA durch den FPGA-Interrupt relevant. Wird dieses ausgelöst bedeutet dies, dass das FPGA für weiteren Versendeprozeduren bereit ist. Das FPGA löst diesen Interrupt stets aus, sobald das Shadow-Register frei ist, dies ist der Fall sobald eine Nachricht erfolgreich versendet worden ist oder durch ein Timeout verworfen wurde. Im Falle eines Timeouts innerhalb des FPGA wird ein Register-Flag gesetzt, dies ist relevant für die Softwareverarbeitung des Interrupts.\\\\
305 Die Software beschreibt das TIS-B Send Register mit dem Inhalt des TIS-B-Formats und der gewünschten Sendezeit in FPGA-Counts. Die Ausführung des Quadrants stellte einen FPGA mit einem internen 100MHz-Schrittgeber bereit, der Einsatz von FPGA mit höheren Taktraten war für folgende Quadrant-Versionen geplant. Der 100MHz-Counter ermöglicht bereits eine Zeitauflösung im Nanosekundenbereich, was ausreichend für unsere gewünschte Genauigkeit von 10\micro s ist. Zur Ermittlung des Counter-Wertes wird die Software periodisch mit dem FPGA-Counter synchronisiert, dies geschieht durch GPS basierte PPS\footnote{Pulse Per Second -- Ein GPS-Impuls zur Synchronisation der Systemzeit}-Signale. Im Falle eines Ausfalls der GPS-Verbindung, generiert das FPGA sog. \emph{RF-Loop}-Nachrichten, diese gewährleisten u.a. eine fortwährende Synchronisation des Counters mit der Systemzeit.
307 \subsubsection{DSP Interface}
308 Den letzten Schritt der Signalgenerierung übernimmt das FPGA, wobei der Inhalt des Extended Squitter Formats in 1090MHz moduliert werden und per Außen- oder Richtungsantenne ausgestrahlt werden. Vorher wird das Signal durch das Dämpfungsglied gedämpft, die Stärke der Dämpfung ist durch die Software konfigurierbar.\\\\
309 Das FPGA initiiert das Senden sobald die übermittelte Sendezeit mit dem internen Counter-Stand übereinstimmt. Ist die gewünschte Zeit nicht mehr realisierbar -- man beachte weitere Verzögerungszeiten der Sendefunktion -- so wird das Paket verworfen und das Register für weitere Sendungen freigegeben.
311 \subsection{Watchdog}
312 Da das Quadrant System nach den Richtlinien des IEC 61508 für Software nach SIL 2 entwickelt werden muss, gilt es u.a. die Vitalität des Gesamtsystems in allen Fällen zu gewährleisten. Jeder Prozess des Systems muss dafür überwacht werden, im Falle einer Dysfunktion oder Verletzung von Sicherheitsrichtlinien wird der Prozess terminiert und neu initiiert.\\\\
313 Solche Maßnahmen verlangen einen robusten Aufbau der einzelnen Module und nur schwache Kopplungen, im Normalfall datengetrieben, zwischen den Modulen. Die Prüfung der Vitalität basiert auf dem \emph{Watchdog}-Verfahren. Hierbei wird periodisch ein Signal erzeugt und an alle Prozesse propagiert und die Verzögerungszeit des Antwortsignals gemessen.\\\\
314 Weitere Informationen zu dem Quadrant DSP Watchdog sind in Anhang D in 2.1.2.1 zu finden.
316 \subsubsection{DSP Watchdog}
317 Das Signal wird direkt auf dem FPGA erzeugt, was höchste Genauigkeit und Stabilität bietet. Das FPGA generiert hierfür mehrmals in der Sekunden einen Hardware-Interrupt.
319 \subsubsection{System Controller}
320 Den zweite Teil des Watchdog-Protokolls stellt der System Controller bereit. Dieser verwaltet die Anmeldung der Prozesse und registriert die Antwortsignale. Wird ein Zeitlimit bei einer Antwortverzögerung überschritt, so besteht Handlungsbedarf. Der System Controller kann bei wiederholter Verletzung der Reaktivität den Prozess terminieren und neu starten. Dieser Vorgang zeigt eine Fehlfunktion im entsprechenden Modul auf und wird via SNMP-Notification gemeldet.
322 \section{Realisierung}
323 \subsection{Programmiersprache \& Bibliotheken}
324 Das System musste des weiteren im Hinblick auf Robustheit entwickelt werden. Als Programmiersprache wurde ANSI C, mit einigen Einschränkungen, eingesetzt. Entsprechend den Richtlinien der Softwareentwicklung nach dem IEC 61580 Standard (SIL 2) wurde u.a. auf dynamische Speicherallokierung verzichtet.\\\\
325 Bei der Entwicklung des SNMP-Agents kam C++ zum Einsatz. Der SNMP-Agent wird mit Hilfe von \emph{NET-SNMP} entwickelt -- die Bibliothek unterstützt die Erstellung von SNMP-Agenten durch die Bereitstellung der MIB.
327 \subsection{Compiler}
328 Auf den Entwicklungssystem kam \emph{GCC}\footnote{The GNU Compiler Collection -- Ein C/C++ Compiler \& Linker} bei der Übersetzung zum Einsatz. Zur Auslieferung auf dem Zielsystem wurde ein Cross-Compiler eingesetzt, der den C-Code in die entsprechende Architektur überführte.
330 \subsection{CppUnit \& Code Coverage}
331 Zur Erstellung und der Durchführung von Unit-Tests wurde \emph{CppUnit} eingesetzt. Das Framework ermöglicht das Testen von C++-Klassen und C-Modulen. Das Code Coverage dient zur Bestimmung der Testüberdeckung basierend auf den erstellten Unit-Tests. Die resultierenden Statistiken lassen sich mit weiteren Werkzeugen visualisieren und bieten eine wichtige Grundlage zur Beurteilung der Testqualität.
333 \subsection{Entwicklungsumgebung}
334 Als Entwicklungsumgebung wurde Red Hat Enterprise Linux 5.4 eingesetzt. Das Betriebssystem bietet eine Reihe von Werkzeugen, welche die Entwicklung und insbesondere die Interaktion mit dem lokalen Zielgerät und weiteren Testsystemen im Comsoft-Netzwerk unterstützen.
337 Für Programmieraufgaben wurde hauptsächlich die Eclipse IDE eingesetzt. Eclipse ist eine modulares Framework mit großen Erweiterungsmöglichkeiten. Mit dem C++-Plugin wird Eclipse zu einem umfassenden Entwicklungssystem. Eclipse bietet, wie die meisten IDEs, u.a. eine intuitive Bedienung, Syntax Highlighting und Autovervollständigung. Die Integration mit anderen Werkzeugen wie der Versionsverwaltung steigert die Effektivität der Arbeit.
339 \subsubsection{Versionsverwaltung}
340 Bei der Entwicklung von sicherheitskritischen System ist man stets bestrebt sowohl die Produkte als auch den Entwicklungsprozess sicher zu gestalten. Die Konsequenz ist eine konservative Technologiewahl, erprobte und bewährte Systeme und Prozesse werden nur nach gründlicher Prüfung der Alternativen ersetzt. Dies gilt auch für die Versionsverwaltung, so wurde für dieses Projekt CVS\footnote{Concurrent Versions System -- Ein Versionsverwaltungssystem zur Versionierung von Software und aller Änderungen während der Entwicklungsphase} eingesetzt.
342 \section{Verifikation}
344 In der letzten Phase stellt man den Zustand der entwickelten Komponenten fest und stellt diesen den Anforderungen gegenüber. Es werden Testfälle erstellt, die einzelne Positionen der Anforderungen abdecken. Bei der Durchführung der Tests ist eine objektive Sicht notwendig. Die Tests sollen alle Funktionen mindestens einmal verifizieren.\\\\
345 Beim Testen der TIS-B-Funktionalität wurde besonders auf die Einhaltung der vielen Timing-Bestimmungen geachtet. Dafür wurde ein Testprogramm entwickelt, welches parametergetrieben die gewünschten Testszenarien geniert. Die Stresstests dienen außerdem dazu die Software auf ihre Robustheit zu prüfen.
347 \subsection{Unit-Tests}
348 Bei der Verifikation der Unit-Tests wurden die Metriken genutzt um mögliche Gefahrenquellen zu erkennen und nachträglich durch Umformung/Aufspaltung der Funktionalität zu beseitigen. Die Testüberdeckung diente der Entdeckung möglicher Schwachstellen in der Teststellung. Es galt eine Coverage-Rate von mindestens 80\% einzuhalten, größtenteils lagen die einzelnen Komponenten bei einer Überdeckungsquote von 100\%.
350 \subsection{Testskripte}
352 Die Testskripte beschreiben die manuelle Testdurchführung, durchgeführt durch einen Testingenieur. Die Skripte können auch Hilfswerkzeuge einführen und die Testfälle mit deren Hilfe gestalten. Da bei der TIS-B-Komponente keine Benutzerinteraktion besteht, war es möglich die meisten Testfälle mit Hilfe eines dafür entwickelten Testprogramms zu automatisieren. Die Funktion des Testprogramms besteht in der Simulation eines TIS-B Servers. Das Programm generiert basierend auf den übergebenen Parametern eine Sequenz aus TIS-B Send Request-Paketen in einem definierbaren Intervall. Die sog. \emph{Payload} der Pakete konnte dynamisch aus einer vom Tester bereitgestellten Datei übernommen werden, oder statisch generiert werden.
354 \subsection{Testaufbau}
355 Da das TIS-B eine Sendeeinheit darstellt, mussten einige Schwierigkeiten in der Vorbereitung der Tests beseitigt werden. Eine Schwierigkeit bestand darin die tatsächliche Ausgangssignale zu verifizieren. Ein Senden auf der 1090MHz-Frequenz ist auch mit geringer Sendeleistung nicht ohne Genehmigung möglich. Eine Sendegenehmigung ist mit einem Kostenaufwand verbunden und wird nur für Anlagen im operativen Betrieb oder Dauertestbetrieb erwirkt.\\\\
356 Die Lösung dieses Problems bestand darin den Quadrant TIS-B/ADS-B Transceiver sowohl als Sende- als auch Empfangseinheit zu nutzen. Der Aufbau bestand aus einem Quadrant TIS-B Transceiver -- dem Entwicklungsgerät -- und einem Quadrant ADS-B Sensor. Dabei wird das Ausgangssignal des TIS-B Transceiver direkt an den Antenneneingang des Quadrant ADS-B Sensors angeschlossen. Dazwischen werden Dämpfungsglieder angeordnet, da sonst auch bei geringem Ausgangssignal eine Beschädigung der Hardware nicht ausgeschlossen ist, die Testgeräte verfügen über keine Blitzableitung, welche einen Quadrant im operativen Betrieb sonst vor solchen Überspannungen schützen würde.\\\\
357 Das in Abschnitt \ref{testskripte} beschriebe Testprogramm generiert TIS-B Send Requests, die über eine Netzwerkverbindung an den TIS-B Transceiver geleitet werden. Dieser Verarbeitet die Anweisung und sendet die TIS-B Uplink-Daten über den Antennenausgang. Diese Signale landen nun im Quadrant ADS-B Sensor, werden dort zu ASTERIX-Daten aufbereitet und über eine Netzwerkschnittstelle zurück an das Testsystem geleitet. Im Testsystem werden die ASTERIX-Daten mit Hilfe von weiteren Comsoft-Werkzeugen wie dem QCMS zur Visualisierung (Abb. \ref{fig:qcms1}) und dem RAPS-3 zur automatischen Verifizierung verarbeitet (Abb. \ref{fig:raps3}). Dieser Aufbau ermöglichte ein automatisiertes Testen mit manueller Bestätigungsmöglichkeit durch die Visualisierung der Daten.\\\\
359 \centering \includegraphics[width=250pt]{images/qcms1.pdf}
360 \caption{QCMS Display: Zeigt Targets basierend auf ASTERIX-Daten}
363 Nach der initialen Prüfung der TIS-B-Effizienz, konnte der Quadrant ADS-B Sensor aus dem Testaufbau entfernt werden und durch das TIS-B-Testgerät selbst ersetzt werden. Hierzu galt es lediglich den Antennenausgang des Quadrant mit dessen Eingang kurzzuschließen. In diesem zweiten Aufbau konnte das Gerät zudem auf die Stabilität der Nebenläufigkeit von ADS-B und TIS-B geprüft werden, denn auch im operativen Betrieb ist der Betrieb von ADS-B und TIS-B auf einem Sensor vorgesehen.
365 \centering \includegraphics[width=200pt]{images/raps3.png}
366 \caption{RAPS-3: System zum Testen, Verifizieren, Aufnehmen und Abspielen von ASTERIX-Datenströmen}
370 \subsection{Leistungsanalyse}
371 Nach Abschluss der Testdurchläufe wurden die Ergebnisse bewertet. Die TIS-B Software interagiert wie geplant mit dem FPGA und erfüllt alle Anforderungen. Alle zeitkritischen Prozeduren arbeiten effizient, die Bearbeitungszeiten sind innerhalb der geforderten Beschränkungen.\\\\
372 Die Stresstests haben die Robustheit der Software bewiesen. Erst ab 3000 Nachrichten pro Sekunde wird die Grenze des Systems erreicht, dies entspricht der doppelten Belastung als der geforderte Maximalwert von 1500 Nachrichten pro Sekunde. Bei fortwährender Belastung mit dieser Rate gibt es nach einigen Sekunden einen Pufferüberlauf. Wie erwünscht werden in solchen Fällen Nachrichten verworfen, die nicht mehr zeitlich Versenden werden können, auch unter diesen Umständen bleibt das System stabil und die Prozessorlast unter 30\%.