sawine@1: \chapter{Grundlagen}
sawine@1: \section{Flugsicherung}
sawine@1: Die Hauptaufgabe der Flugsicherung ist die Vermeidung von Kollisionen zwischen den Luftfahrzeugen. Dazu wird zwischen den Flugobjekten eine räumliche Trennung erwirkt. Im Sichtflugbetrieb stellt diese Aufgabe nur in Ausnahmesituationen ein Problem dar und kann auf die Piloten übertragen werden. Im Instrumentenflugbetrieb jedoch ist der Pilot auf die Anweisungen der Fluglotsen und seine Navigationsinstrumente angewiesen.\\\\
sawine@1: Um die Sicherheit der Flugzeuge zu gewährleisten gibt es eine Reihe von Verfahren zur Staffelung des Flugverkehrs.
sawine@1: 
sawine@1: \subsection{Luftraumorganisation}
sawine@1: Die Strukturierung des Luftraums bildet die Grundlage, auf der Flugsicherungsmechanismen arbeiten. Die Struktur soll die Koordination von Flugbewegungen ermöglichen und die Häufigkeit von Eingriffen in den Flugverlauf reduzieren. Außerdem ist die Auflösung und somit die Genauigkeit von Überwachungseinrichtungen wie der Primär- und Sekundärradare beschränkt, dies soll durch intelligente Organisation des Flugverkehrs kompensiert werden.\\\\
sawine@1: In den folgenden Abschnitten wird die Basis der Luftraumorganisation erläutert, \cite{moderne_flugsicherung}.
sawine@1: 
sawine@1: \subsubsection{Fluginformationsgebiet}
sawine@1: Der internationale Luftraum ist in Fluginformationsgebiete unterteilt. Es sind geographische Sektoren, die einen Zuständigkeitsbereich zur Regelung des Flugverkehrs definieren. Die Fluginformationsgebiete selbst können in mehreren Kontrollbezirken organisiert sein. Diese Gebietshierarchie ermöglicht eine effektive Vergabe von Zuständigkeiten an unabhängige, jedoch vernetzte Organe, die den Flugverkehr innerhalb ihrer Bereiche sichern.
sawine@1: 
sawine@1: Gerade bei internationalen Gebietsgrenzen spielen sog. \emph{Coordination Exit/Entry Points} eine wichtige Rolle, diese markieren Wegpunkte für die Übergabe des Flugverkehrs von einem FIR\footnote{Flight Information Region -- das Fluginformationsgebiet ist ein Luftraumsektor, in dem Fluginformations- und Alarmdienste angeboten werden} in den angrenzenden Kontrollsektor.
sawine@1: 
sawine@1: \subsubsection{Routensystem}
sawine@1: \label{grundlagen:routensystem}
sawine@1: Ähnlich dem Straßenverkehrsnetz, hat auch der Luftraum fest definierte Flugrouten -- die sog. \emph{Air Traffic Service Routes} -- kurz ATS-Routes. Der Flugverkehr hat diesen Routen mit einer bestimmten Genauigkeit zu folgen.\\\\
sawine@1: Die ATS-Routen ermöglichen erst eine Sicherung des Flugraums mit hohen Verkehrsdichten. Eine ergänzende Routenführung findet im Nahbereich von Flughäfen statt, hier existieren zusätzlich die \emph{Standard Arrival Routes} und die \emph{Standard Instrument Departure Routes}. Die \emph{Standard Arrival Routes} -- kurz STAR -- führen die Luftfahrzeug von den ATS-Routen zum Flugplatz, während die \emph{Standard Instrument Departure Routes} -- kurz SID -- die Wegpunkte von Flugplatz zu den ATS-Routen setzten.
sawine@1: 
sawine@1: \subsubsection{Flugflächensystem}
sawine@1: Zur Vermeidung von Kollisionen auf dem Routennetz und zur Ausnutzung der technischen Möglichkeiten eines Luftfahrzeugs -- der Navigation auf verschiedenen Höhen -- wird eine Höhen"-separation durchgeführt.
sawine@1: 
sawine@1: Für jeden Routenabschnitt werden hierfür mehrere Flughöhen festgesetzt, auf denen die Luftfahrzeuge navigieren können. Die Angabe der Flughöhe wird in Flight Levels -- kurz FL -- angegeben, wobei ein FL 100 ft barometrischer Höhe entspricht, umgerechnet ca. 30,48 Meter.
sawine@1: 
sawine@1: \subsection{Staffelungsverfahren}
sawine@1: Die Staffelung bildet eine Reihe von Verfahren, die zur Separation von Luftfahrzeugen verwendet werden, \cite{moderne_flugsicherung}. Es gibt besondere Staffelungsverfahren für Landeanflüge und Startvorgänge, da diese Arbeit jedoch nur die Separation im Streckenflug -- also nach Abschluss von Start- und Landemanövern -- gewährleisten soll, werden diese nicht weiter erläutert.
sawine@1: 
sawine@1: \subsubsection{Längsstaffelung}
sawine@1: \label{research:time_separation}
sawine@1: Im folgenden wird lediglich die Längsstaffelung nach Zeit beschrieben, da nur diese Form der Längsstaffelung für das Projekt relevant war.\\\\
sawine@1: Bei der Längsstaffelung nach Zeit werden Mindestabstände zwischen Luftfahrzeugen erwirkt, indem man minimale Zeitabstände zwischen zwei aufeinander folgenden Flügen an bestimmten Wegpunkten durchsetzt. Dabei wird bei der Festlegung der minimalen Zeitabstände eine Klassifizierung nach Verkehrsrichtung etabliert:
sawine@1: \begin{itemize}
sawine@1: \item Verkehr in gleicher Richtung
sawine@1: \item Kreuzender Verkehr
sawine@1: \item Gegenverkehr
sawine@1: \end{itemize}
sawine@1: Bei Verkehr in gleicher Richtung gilt ein Mindestzeitabstand von 10 Minuten, 5 Minuten bei großem Geschwindigkeitsvorteil des voraus fliegenden Luftfahrzeugs. Wechselt ein Luftfahrzeug die Flugfläche und kreuzt dabei die Flugbahn eines anderen Flugobjekts, spricht man von kreuzendem Verkehr. Hier gilt ein Mindestabstand von 5 Minuten zum Zeitpunkt des Kreuzen. Bei Gegenverkehr gilt es spätestens 10 Minuten vor dem Zusammentreffen die Durchführung einer Höhenstaffelung einzuleiten. Nach dem Überflug kann die Höhenstaffelung ab 5 Flugminuten Abstand aufgehoben werden.
sawine@1: 
sawine@1: \subsubsection{Höhenstaffelung}
sawine@1: \label{research:flight_level_separation}
sawine@1: Für die vertikale Separation wird der Luftraum in zwei Bereiche geteilt, wobei jeweils verschiedene Separationsregeln gelten. Für den Luftraum unter Flugfläche 290 gilt ein Mindestvertikalabstand von 1000 ft.\\\\
sawine@1: Da die Genauigkeit der Barometertechnik zur Bestimmung der Flughöhe durch den Luftdruck in größeren Höhen abnimmt, lag die historische minimale Vertikalseparation für Flüge oberhalb der Flugfläche 290 bis Flugfläche 410 bei 2000 ft. Mit dem Fortschritt der Technik wurden die Geräte präziser und auch in großen Höhen verlässlicher. Seit 2005 gilt deshalb in den meisten Lufträumen der westlichen Hemisphäre auch in den Höhen oberhalb der Flugfläche 290 ein vertikaler Mindestabstand zwischen zwei Flugobjekten von 1000 ft. Die Voraussetzung hierfür ist eine technische Ausrüstung, die festgelegte Kriterien der Genauigkeit und Robustheit durch Redundanz erfüllt. Die Regelung nennt sich \emph{Reduced Vertical Separation Minima} -- kurz RVSM -- oder ins Deutsche übersetzt \emph{reduzierte Vertikalstaffelung}.
sawine@1: 
sawine@1: \subsubsection{Slot}
sawine@1: Für die sichere Durchführung der Flugsicherung ist es notwendig, die vergebenen Zeiten möglichst genau einzuhalten. Die Dynamik des Luftverkehrs verhindert jedoch zumeist eine sekundengenaue Präzision, durch die Addition minimaler Abweichungen entsteht Potential für Gefahrensituationen. Um diesem Potential entgegenzuwirken, werden in der Flugsicherung stets Zeitfenster vergeben. Die Zeitfenster -- auch \emph{Slots} genannt -- bieten minimalen Spielraum für die Piloten und Fluglotsen. Werden die vergebenen Zeiten nicht eingehalten, so gilt es lediglich im Rahmen eines Zeitfensters zu bleiben, um die Sicherheit des Flugverkehrs nicht zu beeinträchtigen.\\\\
sawine@1: Solche Slots werden für die Start- und Landemanöver vom Flughafen vergeben und für die Überflüge über den gesetzten Wegpunkten von den Lotsen. Werden Slot-Zeiten verletzt so muss dieser Zustand in die Aufmerksamkeit des zuständigen Lotsen gebracht werden, es besteht möglicherweise Handlungsbedarf um die Sicherheit zu erhalten.
sawine@1: 
sawine@1: \subsection{GCAA}
sawine@1: Die \emph{General Civil Aviation Authority} (GCAA) ist die Flugsicherungsbehörde der \emph{Vereinigten Arabischen Emirate}. In Zusammenarbeit mit den lokalen Autoritäten hat die GCAA die Sicherung des Flugraums über Abu Dhabi, Dubai, Sharjah, Ajman, Umm al-Quwain, Ras al-Khhaimah und Fujairah als Aufgabe. Auch die regelkonforme Weiterleitung des Flugverkehrs in angrenzende Kontrollgebiete gehört zu den Zuständigkeiten der Behörde. 
sawine@1: 
sawine@1: Die GCAA ist der Kunde, in dessen Auftrag die Abflugplanungskomponente entwickelt wurde. Zur Abflugregulierung müssen die zuständigen Fluglotsen der Flughäfen im GCAA-kontrollieren Gebiet jeden Starter registrieren. Beim Anmelden eines Starters hat die GCAA die Möglichkeit, Einfluss auf die Startzeit des Luftfahrzeugs zu nehmen. Die Bewilligung einer Startzeit soll im Sinne der Sicherheit, somit also der Einhaltung der Staffelungsrichtlinien und eventuellen Flussdichtenbeschränkungen, stattfinden.\\\\
sawine@1: In Zusammenarbeit mit einem Berater der Behörde und einigen GCAA-Fluglotsen wurde die Sachlage der Flussdichtenbeschränkungen analysiert. 
sawine@1: 
sawine@1: \subsubsection{Beschränkungen auf Verkehrsflussdichten}
sawine@1: \label{research:gcaa:flow_restrictions}
sawine@1: Der Flugverkehr kann an geeigneten Wegpunkten reguliert werden. Das Setzen von maximalen Flussdichten bedeutet eine Begrenzung der Anzahl an Überflügen innerhalb einer Zeitspanne. Aus der Flussdichtenbeschränkung kann eine Durchflussfrequenz abgeleitet werden. 
sawine@1: 
sawine@1: Das Ziel der Beschränkungen ist die Sicherung des Flugverkehrs über Gebieten, die aufgrund ihrer geographischen Eigenschaften nicht durch Radar überwacht werden. Im Falle des GCAA-FIR sind besonders die nordwestlichen und östlichen Routen von solchen Beschränkungen betroffen. In nordwestlicher Richtung liegen ausgedehnte Wüstengebiete, die kaum Radarüberdeckung aufweisen, da der Betrieb von Radaranlagen dort sehr kostspielig und wartungsintensiv ist. In östlicher Richtung führen die Flugrouten über den Indischen Ozean, auch hier ist zum heutigen Stand der Technik keine flächendeckende Radarüberwachung möglich. Dass Abb. \ref{fig:near_east} veranschaulicht die Gefahrenzonen im Umfeld von den GCAA-kontrollierten Gebiet.\\\\
sawine@1: \begin{figure}[h]
sawine@1: \centering \includegraphics[width=300pt]{images/near_east_problem.pdf}
sawine@1: \caption[GCAA Luftraumbeschränkungen]{GCAA FIR und umliegende Gebiete. Die gestreiften Gebiete sind größtenteils nicht von Radar überwacht. \emph{Quelle (Weltkarte): Wikipedia}}
sawine@1: \label{fig:near_east}
sawine@1: \end{figure}
sawine@1: Die Analyse der verschiedenen Flussdichtenregelungen der GCAA hat ergeben, dass man neben den regulären Beschränkungen auf einem Wegpunkt auch drei Sonderfälle betrachten muss:
sawine@1: \begin{itemize}
sawine@1: \item \textbf{Kombinierte Wegpunkte}\\
sawine@1: Aufgrund eines Zusammenführens mehrerer Flugrouten im späteren Flugverlauf, gilt es bereits im kontrollierten Gebiet mehrere Wegpunkte einem abstrakten Durchflusswegpunkt -- \emph{Flow Point} genannt -- zuzuordnen. Ein Flow Point wird bei der Zuordnung der Zeiten als ein logischer Wegpunkt betrachtet, auch wenn die explizite Überflugzeiten dem entsprechenden Wegpunkt zugeordnet werden.
sawine@1: \item \textbf{Routenverlauf}\\
sawine@1: Nicht alle Routen von einem Wegpunkt müssen über das restriktive Gebiet führen. Manche Flugrouten bieten Abzweigungen außerhalb des FIR an, die in andere Gebiete ohne Restriktionen führen. Hier gilt es den den nachfolgenden Routenverlauf zu betrachten um eine positive Zuweisung zu einem Flow Point zu leisten. 
sawine@1: \item \textbf{Wegpunkten außerhalb des kontrollierten Gebiets}\\
sawine@1: Eine besondere Regelung der GCAA fordert eine Separation auf einem Wegpunkt, der außerhalb des kontrollierten FIR liegt. Hier gilt es durch die Prognose der Überflugzeit an dem besagten Wegpunkt eine Separation an den kontrollierten Exit Points zu leisten.
sawine@1: \end{itemize}
sawine@1: Die Besonderheiten der Flow Point-Zuweisung erhöht die Komplexität der Komponenten, die eine Automatisierung der Zuordnung und Startzeitvergabe realisieren sollen. Die Einteilung der Regelungen in Äquivalenzklassen ermöglicht eine genauere Analyse der Anforderung an ein System. Sind alle Klassen identifiziert, muss die Unterstützung für alle Regelungen nicht explizit in die Anforderungen aufgenommen werden und später verifiziert werden. Die Recherche der Luftraumbeschränkungen ist die Basis der Analyse im Abschnitt \ref{analysis:atccl:flow_restrictions}. 
sawine@1: 
sawine@1: \subsubsection{Manuelle Abflugplanung}
sawine@1: Vor der Einführung der DFLOW-Komponente, wurde der Abflugzeitpunkt manuell durch das Personal der GCAA bestimmt. Die Vorgabe für die Planer bestand darin, eine maximale Frequenz an Startern pro Flugroute nicht zu überschreiten. Hierbei war eine Berücksichtigung der Eigenschaften des Luftfahrzeugs, wie z.B. dessen Ausrüstung, Reisegeschwindigkeit und Flughöhe, nicht möglich. Die Berechnungsvektoren für eine Optimierung sind für einen Menschen zu umfangreich, die Berücksichtigung aller Eigenschaften -- dazu zählt auch die aktuelle Slot-Belegung an den jeweiligen Wegpunkten einer Route -- ist bei manueller Bearbeitung nicht in einer praktikablen Zeit möglich.\\\\
sawine@1: Die höchste Priorität bei der Vergabe von Startzeiten gilt der Wahrung der Sicherheit. Durch die manuelle Vergabe der Abflugzeiten entsteht eine ineffektive Nutzung der Luftraumkapazitäten. Dies hat negative Folgen für die Wirtschaftlichkeit der Flugsicherung, insbesondere im Fall der GCAA und des enormen Wachstums des Luftverkehrs in deren kontrollierten Region.
sawine@1: 
sawine@1: \section{PRISMA-Architektur}
sawine@1: PRISMA von der Comsoft GmbH ist eine modulare Lösung zur integrierten Flugsicherungsautomation. Ein PRISMA-System ist eine kundenspezifische Kombination und Konfiguration von Komponenten. Alle PRISMA-Komponenten sind außerdem als eigenständige Module erhältlich und somit in andere Umgebungen integrierbar.\\\\
sawine@1: Die Hauptkomponenten von PRISMA sind:
sawine@1: \begin{itemize}
sawine@1: \item \textbf{CWP -- \emph{Controller Working Position}}\\
sawine@1: Die CWP ist das Display für die Lotsen und die Lotsenaufsicht. Es bildet das Kernstück des PRISMA-Frontends und bietet ein interaktives Luftlagebild über den kontrollierten Sektor. Alle Komponenten des PRISMA werden in diesem Display integriert, so liefert das SDPS die Tracks\footnote{Der Flugverlauf eines Luftfahrzeugs basierend auf der Integration verschiedener Überwachungsdaten}, das FDPS die Flugpläne während die Konfliktwarnungen des Safety Net im Display visualisiert und mit einem Audiosignal versehen werden.
sawine@1: \item \textbf{AWP -- \emph{Assistent Working Position}}\\
sawine@1: Die AWP ist das Display für die Assistent Controller -- auch Planer genannt. Das Display bietet eine strategische Ansicht, geeignet zur Vorverarbeitung der Flugplandaten, Zuweisung von Flugplänen zu Luftfahrzeugen und Vergabe von Abflugslots. Zusätzlich stellt es Werkzeuge bereit zur Bildung und Darstellung von Prognosen über das Verkehrsaufkommen. 
sawine@1: \item \textbf{FDPS -- \emph{Flight Plan Data Processing System}}\\
sawine@1: Das FDPS ist der Bearbeitung von Flugplandaten dediziert. Es werden u.a. dynamische Flugplanprofile erstellt, Überflugzeiten prognostiziert und Vorhersagen über das Verkehrsaufkommen entwickelt.
sawine@1: \item \textbf{SDPS -- \emph{Surveillance Data Processing System}}\\
sawine@1: Das SDPS bietet die Integration von mehreren heterogenen Datenquellen der Luft"-raum"-überwachung an. Das System unterstützt Primär- und Sekundärradare, Mode-S, ADS-B/C und Multilateration als Datenquellen.
sawine@1: \item \textbf{Safety Net}\\
sawine@1: Zur Unterstützung der Fluglotsen validieren die sog. Safety Nets die Flugsicherheit. Die Prozesse suchen den Flugraum nach möglichen Gefahrenquellen ab und melden potentielle Verstöße gegen die Regelungen der Flugsicherung.
sawine@1: \item \textbf{Daten-, Audio- und Displayaufzeichnung}\\
sawine@1: Eine sorgfältige Protokollierung der Datenströme ist die Grundlage der Nachvollziehbarkeit von Fehlerereignissen und der Nachvollziehbarkeit von Benutzerentscheidungen. PRISMA bietet hierfür eine Reihe von Werkzeugen an, von der automatisierten Aufzeichnung aller Datenbanktransaktionen bis zur synchronisierten Funkverkehr- und Displayaufzeichnungen.
sawine@1: \end{itemize}
sawine@1: 
sawine@1: \subsection{DMAP}
sawine@1: Eine Besonderheit in der PRISMA-Architektur stellt das Modell der Datenkommunikation dar. PRISMA besitzt eine verteilte Datenbank, die im höchsten Maße die Robustheit der beteiligten Systeme und die Sicherheit der Daten garantiert. 
sawine@1: 
sawine@1: Die DMAP ist eine sichere Kommunikationsschicht auf der UDP\footnote{User Datagram Protocol -- ein verbindungsloses, nachrichtenbasiertes Internetprotokoll der Transportschicht}/IP-Schicht zur Realisierung von Transaktionen auf den persistenten Datensätzen. Die Datensätze sind in semantische Gruppen organisiert, wie z.B. die \texttt{SFPL} als Datensatztyp für sie \emph{System Flight Plans} oder \texttt{FPATH} für die Routenzusatzinformationen.\\\\
sawine@1: Jede Komponente von PRISMA, die mit der DMAP interagiert, hält stets lokale Kopien der relevanten Datensätze, Änderungen werden durch das DMAP-Protokoll zur \emph{primären Datenbank} und von dort zu allen verteilten Abonnenten propagiert.
sawine@1: Jegliche Interaktion zwischen PRISMA-Komponenten wird durch diese Schicht realisiert, der datengetriebene Ansatz ermöglicht eine hohe Dynamik in der Entwicklung und Integration neuer Komponenten und minimiert die Notwendigkeit feste Schnittstellen zu pflegen.
sawine@1: 
sawine@1: Dieses Modell bietet zudem einen hohen Grad an Redundanz der Daten. Die lokalen Kopien der Komponenten befähigen diese auch bei Abbruch der Verbindung zu dem Server weiterhin operativ zu bleiben, Benutzereingaben zu verarbeiten und bei Wiederaufnahme der Verbindung die Transaktionen fortzusetzen.
sawine@1: 
sawine@1: \section{Compilerbau}
sawine@1: Zur effektiven Modellierung der Luftraumbeschränkungen soll eine domänennahe Konfigurationssprache entwickelt werden. Für diesen Zweck galt es einen Compiler zu entwickeln, der die Sprache akzeptiert und das Modell der Luftraumbeschränkungen in ein geeignetes Format zur dynamischen Weiterverarbeitung überführt. Dieser Abschnitt ist die Zusammenfassung der Recherche von Techniken der Compilerentwicklung und der vorhandenen Technologien.\\\\
sawine@1: Die Übersetzung eines Programms von einer Sprache in eine andere Sprache wird von einem Compiler durchgeführt.
sawine@1: Es gibt verschiedene Gründe für die Notwendigkeit einer Übersetzung, die Gemeinsamkeit liegt in der Zugänglichkeit und
sawine@1: erhöhten Effizienz, die dadurch für die Entwicklung erreicht wird.\\\\
sawine@1: Eine Programmiersprache soll die Kommunikation zwischen Mensch und Computer erleichtern. Die Sprache ist an die
sawine@1: menschlichen Bedürfnisse angepasst und erlaubt im besten Fall eine Abstraktion über das darunter liegende System.
sawine@1: Das Übersetzen des Programms in ein Programm in Maschinensprache ermöglicht letztendlich das Ausführen des Programms auf einem Computer.\\\\
sawine@1: In manchen Situationen bietet es sich an eine weitere plattformunabhängige Schicht dazwischen zu setzen, die sog. Virtuelle Maschine. Diese Schicht bedient sich der Schnittstellen des Systems und bietet dafür eine abstrahierte Laufzeitumgebung an. Eine Virtuelle Maschine kann somit plattformunabhängigen Bytecode auf verschiedenen System ausführen.\\\\
sawine@1: Eine wichtige Rolle eines Compilers ist es, Fehler im Programmcode zu berichten, die während der Übersetzung
sawine@1: entdeckt wurden. Zur effektiven Auflösung von auftretenden Fehlern gilt es eine möglichst genaue Beschreibung und Lokalität des Fehlers zu liefern. Zur Reduzierung von wiederholten Übersetzungsvorgängen ist es hilfreich möglichst viele Fehler in einem Durchlauf zu erkennen. Hierfür ist es notwendig Richtlinien zu setzen, die eine Fortsetzung des Übersetzungsvorgangs ermöglichen und das Entstehen von Seiteneffekten durch vorhergegangene Fehler vermeiden.
sawine@1: 
sawine@1: \subsection{Compilerarchitekturen}
sawine@1: Nach \cite{compilers} fordern verschiedene Anwendungsgebiete bestimmte Eigenschaften von einem Übersetzer.
sawine@1: Der traditionelle Compiler übersetzt Quellcode von einer Programmiersprache in ein lauffähiges Programm. Das Resultat ist eine ausführbare Datei, welches bestimmte Eingaben erwartet, auf denen es die programmierten Funktionen ausführt. So ein Programm ist systemabhängig (Abb. \ref{fig:compiler}).
sawine@1: \begin{figure}[h]
sawine@1: %\begin{picture}(100, 100)
sawine@1: \centering \includegraphics[width=200pt]{images/compiler.pdf}
sawine@1: %\end{picture}
sawine@1: \caption{Ein Compiler. \emph{Quelle: \cite{compilers}}}
sawine@1: \label{fig:compiler}
sawine@1: \end{figure}\\\\
sawine@1: Einen anderen Ansatz bietet der Interpreter (Abb. \ref{fig:interpreter}), welcher sowohl den Quellcode als auch die Eingabeparameter erhält und daraus direkt die Ausgabe produziert. Der Übersetzungs"-prozess passiert iterativ für jeden Befehl, was Optimierungsmaßnahmen schwierig macht. Ein Interpreter wird eingesetzt, wenn ein interaktives Werkzeug gebraucht wird und die Berechnung der Ausgabe nicht zeitkritisch ist.
sawine@1: \begin{figure}[h]
sawine@1: \centering \includegraphics[width=200pt]{images/interpreter.pdf}
sawine@1: \caption{Ein Interpreter. \emph{Quelle: \cite{compilers}}}
sawine@1: \label{fig:interpreter}
sawine@1: \end{figure}\\\\
sawine@1: Will man jedoch ein systemunabhängiges Programm erstellen, welches eventuell sogar auf das jeweilige Zielsystem optimiert werden soll, lässt sich ein sog. hybrider Compiler samt virtueller Maschine einsetzten (Abb. \ref{fig:hybrid_compiler}).
sawine@1: 
sawine@1: In diesem Fall übersetzt der Compiler den Quellcode in ein sog. \emph{Intermediate Program}. Das Resultat ist ein systemunabhängiger Bytecode, welcher als Eingabeprogramm für die virtuelle Maschine genutzt wird. Die virtuelle Maschine ist nun in der Lage, systemabhängige Optimierungen am Programm durchzuführen. Zusammen mit den Eingabeparameter, führt die virtuelle Maschine die Berechnungen durch und erzeugt somit die Ausgabe. 
sawine@1: \begin{figure}[h]
sawine@1: \centering \includegraphics[width=200pt]{images/hybrid_compiler.pdf}
sawine@1: \caption{Ein hybrider Compiler. \emph{Quelle: \cite{compilers}}}
sawine@1: \label{fig:hybrid_compiler}
sawine@1: \end{figure}
sawine@1: 
sawine@1: \subsection{Werkzeugunterstützung}
sawine@1: In der Analysephase eines Übersetzers wird der Eingabecode analysiert und auf Fehler über"-prüft um aus dem validen Code die Überführung in das Back-End zu gewährleisten.
sawine@1: Das Front-End eines Compilers wird auch Parser genannt. Die Geschichte der Compiler-Entwick"-lung hat seit dem ersten Compiler im Jahre 1952, welches von Grace Hopper entwickelt wurde, die später auch an der Entwicklung von \emph{COBOL} beteiligt war, enorme Fortschritte gemacht. Mittlerweile stehen für die Entwicklung eines Übersetzers eine Vielzahl an Werkzeugen zur Verfügung, die jede Phase des Compilers abdecken.\\\\
sawine@1: Für die Entwicklung des Compilers für die Konfigurationssprache wurden verschiedene Technologien evaluiert:
sawine@1: \begin{itemize}
sawine@1: \item LLVM\footnote{Low Level Virtual Machine -- eine modulare Compilerarchitektur mit optimiertem Übersetzungskonzept}
sawine@1: \item \texttt{lex}
sawine@1: \item \texttt{yacc}
sawine@1: \item \texttt{flex}/\texttt{flex++}
sawine@1: \item \texttt{bison}/\texttt{bison++}
sawine@1: \end{itemize}
sawine@1: 
sawine@1: \subsubsection{LLVM}
sawine@1: \emph{LLVM} ist eine Compiler-Infrastruktur zur Optimierung von Programmen, die in beliebigen Sprachen erstellt werden können. In einigen Anwendungsgebieten -- wie z.B. in der Entwicklung von Objective-C-Programmen -- soll es den \texttt{GCC}\footnote{GNU Compiler Collection -- eine Compilersammlung für u.a. C, C++ und Java unter GPL-Lizenz} ersetzen. Der Vorteil von \emph{LLVM} liegt in der modernen Architektur des Frameworks und den fortgeschrittenen Optimierungsmechanismen. Auch die Integration mit anderen Werkzeugen, wie z.B. einer IDE\footnote{Integrated Development Environment -- eine integrierte Entwicklungsumgebung}, sollen mit \emph{LLVM} erleichtert werden.
sawine@1: 
sawine@1: \subsubsection{\texttt{lex} und \texttt{flex}}
sawine@1: Die Erstellung der lexikalischen Analyse ist der erste Schritt in einer Parser-Entwicklung. \texttt{lex} bietet eine Möglichkeit die Analyse mit Hilfe einer Konfiguration zu automatisieren. Das Resultat ist ein Scanner in der Programmiersprache C.
sawine@1: 
sawine@1: \texttt{flex} ist eine unter \emph{GNU Public License} entwickeltes Kommandozeilen-Tool, welches die Funktionen des \texttt{lex} implementiert und darüber hinaus Erweiterungen bietet. \texttt{flex++} bietet eine Reihe von C++-Klassen an, die eine Integration in einen C++-Parser erleichtern sollen. Auch der generierte Code ist dann in C++ verfasst.
sawine@1: 
sawine@1: \subsubsection{\texttt{yacc} und \texttt{bison}}
sawine@1: Dieses Kommandozeilenwerkzeug soll die Parser-Generierung automatisieren. Der Name steht für \emph{Yet Another Compiler-Compiler}, was jedoch irreführend sein kann, denn es handelt sich definitiv nicht um einen Compiler-Generator. Mit einer Konfigurationsnotation wird die Syntax einer Sprache definiert, \texttt{yacc} generiert daraus C-Code, der die Syntaxanalyse realisiert.
sawine@1: \texttt{bison} ist ein Werkzeug, welches die Funktionalität des \texttt{yacc} kopiert, jedoch unter der \emph{GNU Public License} erhältlich ist. \texttt{bison++} bildet das C++-Pendant und bietet eine Integration mit \texttt{flex++} an.
sawine@1: 
sawine@1: \section{Sicherheitsfaktoren}
sawine@1: Systeme im Einsatz zur Flugsicherung müssen bestimmte Richtlinien der Sicherheit erfüllen. U.a. werden diese Richtlinien durch den \emph{IEC 61508 Standard} festgelegt, der die \emph{Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar elektronischer Systeme} definiert.\\\\
sawine@1: Als Planungskomponente erfüllt das DFLOW-System zwar keine unmittelbaren sicherheitsbezogenen Aufgaben, jedoch sollen die Richtlinien die Grundlage bilden für eine reibungslose Integration in das sicherheitskritische PRISMA-System.
sawine@1: 
sawine@1: \section{Produktvergleich}
sawine@1: Auf dem Markt befinden sich eine Reihe von Systemen, die das Abflugmanagement und Funktionen des \emph{Air Traffic Flow Managements} automatisieren. Die Systeme bieten eine große Vielfalt an Ansätzen zur Bewältigung der Aufgaben an, exemplarisch werden drei Systeme kurz erläutert.
sawine@1: 
sawine@1: \subsection{CFMU}
sawine@1: Das \emph{Central Flow Management Unit} -- oder auch CFMU -- ist ein koordiniertes, zentrales System zur Regelung des Luftverkehrsflusses im europäischen Raum. Das System wird von EUROCONTROL\footnote{Die europäische Organisation für Flugsicherung} betrieben, ausführliche Dokumentation ist online unter\\ \texttt{www.cfmu.eurocontrol.int} erhältlich.
sawine@1: 
sawine@1: CFMU bietet eine Architektur basierend auf Web Services. Es werden eine Reihe von Diensten zur Vorbereitung und Übermittlung von Flugplänen, zur Visualisierung von Routen und Flugräumen und zur Erstellung von statistischen Reports angeboten. Es gibt eine große Bandbreite an Werkzeugen zur Interaktion mit diesen Diensten.\\\\
sawine@1: CFMU ist ein für den europäischen Flugraum konzipiertes System, die Funktionen realisieren somit nur die europäischen Regelungen. Es gibt keine Möglichkeit die Dienste für einen anderen Flugraum zu konfigurieren und die Systeme auf einem abgeschlossenen System, unabhängig von dem Internet, zu betreiben. 
sawine@1: 
sawine@1: \subsection{PATS Departure Manager}
sawine@1: Ein weiteres von EUROCONTROL in Auftrag gegebenes System ist der \emph{PATS Departure Manager}. Im Rahmen eines \emph{PHARE}\footnote{Programme for Harmonised Air Traffic Management Research in EUROCONTROL}-Projekts wurde ein Abflugmanager entwickelt, der europäischen Standards entspricht. Die Gewichtung der Aufgaben des \emph{PATS Departure Manager} liegt
sawine@1: bei der Sicherung des Abflugverkehrs unter Betrachtung der Trajektorie der Luftfahrzeuge während der Startmanöver \cite{eurocontrol_dman}. Mit Hilfe der \emph{PATS Conflict Probe} wird eine optimale und konfliktfreie Auflösung des startenden Flugverkehrs realisiert, während der \emph{PATS Trajectory Predictor} die Trajektorieberechnungen aller Alternativen durchführt. Hierbei bilden die SIDs-Wegpunkte die Route zur Integration der Starter in die Reiseverkehrsrouten. 
sawine@1: 
sawine@1: Neben einer Integration mit einem Arrival Manager zur Regelung von sog. Mixed Mode Airways\footnote{Startbahnen, die sowohl für Start- als auch Landeverkehr freigegeben sind} realisiert ein Display die Interaktion mit den Komponenten.\\\\
sawine@1: Der \emph{PATS Departure Manager} realisiert laut \cite{eurocontrol_dman} 2.3.3 keine Optimierung des Flugverlaufs hinsichtlich der weiterführenden Route und deren Verkehrsflussdichten. Auch die Separation nach Flugfläche ist nicht Bestandteil der Funktionalität.
sawine@1: 
sawine@1: \subsection{Departure Manager Frankfurt}
sawine@1: Eine weitere Entwicklung im Bereich Abflugmanager stellt der \emph{darts4D DMAN} von der Firma \emph{Delair} dar. Das System soll verbindliche Aussagen über die Startzeit, bzw. die sog. \emph{Off-Block Time}, unter Berücksichtigung aller Prozesse und Richtlinien des Flughafens machen. Der Departure Manager wurde im April 2007 in Frankfurt in Betrieb genommen und aufgrund von Beeinträchtigung des Abflugmanagements wenige Monate später wieder aus dem System genommen \cite{flugleiter_dman}.\\\\
sawine@1: Interessant hierbei sind die genannten Gründe für den Fehlschlag: eine unausreichende Einbindung der Endanwender und Domänenexperten in den Entwicklungsprozess sollen laut \cite{flugleiter_dman} die Hauptgründe für die fehlerhafte Konzeption gewesen sein. Ein weiterer Grund werden die komplexen Abhängigkeiten der vielen Parameter sein, die zum erfolgreichen Mikromanagement eines Abflugs in die Berechnung aufgenommen werden. Die Eingangsparameter sind zudem durch äußere und menschliche Einflüsse höchst dynamisch, was die Zuverlässigkeit der Prognosen reduziert.