|
sawine@0
|
1 |
\chapter{Realisierung}
|
|
sawine@0
|
2 |
|
|
sawine@0
|
3 |
\section{Programmiersprache \& Hilfsbibliotheken}
|
|
sawine@0
|
4 |
Alle Module in der PRISMA-Architektur sind in C++ realisiert. Zur nahtlosen Integration in das bestehende System und entsprechend der fachlichen Qualifikation der Entwickler wurden auch die Komponenten dieser Arbeit in C++ entwickelt.
|
|
sawine@0
|
5 |
|
|
sawine@0
|
6 |
C++ eignet sich für systemnahe und objektorientierte Programmierung. Aufgrund einer fehlenden automatischen Speicherverwaltung, auch \emph{Garbage Collection} genannt, sind einige Richtlinien nach \cite{iec_61508} zu befolgen.\\\\
|
|
sawine@0
|
7 |
Zur Entwicklung von robuster Software, wie sie in sicherheitskritischen Systemen verlangt wird, soll u.a. auf dynamische Speicherallokierung verzichtet werden. Wobei der Standard die Laufzeit eines Systems in eine Initialisierungsphase und eine Betriebsphase teilt, in der Initialisierungsphase ist die Allokierung von benötigten Speicher erlaubt, \cite{iec_61508}. Auch \emph{Stack}-basierte Allokationen sind möglich, oft unumgänglich. \cite{iec_61508} beschreibt die Initialisierungsphase als die Zeit unmittelbar nach dem Start eines Systems bis zum Zeitpunkt der Bereitstellung aller Funktionen. Somit ist ein Zeitraum gegeben um auch dynamische Strukturen zu initialisieren, ohne eine Gefährdung der Stabilität eines Systems zu riskieren.
|
|
sawine@0
|
8 |
|
|
sawine@0
|
9 |
\subsection{Compiler}
|
|
sawine@0
|
10 |
Der ATCCL-Parser wurde mit Hilfe von \texttt{flex} und \texttt{bison} entwickelt und ist daher in der Programmiersprache C realisiert. Nach der Evaluation der C++-Varianten beider Werkzeuge hat sich die schwierige Integration der generierten Module bemerkbar gemacht, die aufgrund von Versionsinkompatibilitäten entstanden sein muss. Gleichzeit war der Aufwand solche Konflikte aufzulösen nicht gerechtfertigt, da der Vorteil eines objektorientierten Designs an dieser Stelle vernachlässigbar sind.\\\\
|
|
sawine@0
|
11 |
Die C-Versionen der beiden Werkzeugen sind ausgereift, stabil und bieten eine problemlose Integration. Die Effektivität der Compilerentwicklung wurde durch den Einsatz von \texttt{flex} und \texttt{bison} erheblich gesteigert. Die Entwicklung der Analysephase des Compilers fand in C statt, während die Synthese in C++ realisiert eine C-Schnittstelle bietet um eine erfolgreiches Zusammenspiel zu gewährleisten.
|
|
sawine@0
|
12 |
|
|
sawine@0
|
13 |
\subsection{Comsoft \texttt{stdbase}}
|
|
sawine@0
|
14 |
Die \emph{C++ Standard Library} schließt dynamische Speicherallokierung nicht aus, in den gängigen Implementierungen, so auch in dem \texttt{GCC}, wird davon auch intensiv gebraucht macht. Dieser Zustand macht den Einsatz der Standardbibliothek für die Entwicklung von PRISMA-Modulen nicht möglich.\\\\
|
|
sawine@0
|
15 |
Die \texttt{stdbase}-Bibliothek bietet eine Reihe von Klassen an, die entsprechend der sicherheitstechnischen Richtlinien arbeiten. Diese bieten ein vergleichbares Interface wie die \emph{C++-STL} an, sodass erfahrene C++-Entwickler ohne Einlernungsaufwand dieser bedienen können.
|
|
sawine@0
|
16 |
|
|
sawine@0
|
17 |
Als Beispiel bietet die \texttt{stdbase} eine längenbeschränkte \texttt{String}-Klasse an, die eine \emph{Stack}-basierte Variante der \texttt{std::string} mit fast identischem Interface darstellt.\\\\
|
|
sawine@0
|
18 |
Bisher bot die \texttt{stdbase} keine Variante der \texttt{std::vector} und \texttt{std::map} an. Die Verwendung dieser Klassen würde an vielen Stellen in dem Entwurf Anwendung finden und die Entwicklung effektiver machen. \texttt{StackVector} (Abb. \ref{uml:stack_vector}) wurde für lokale Objektsammlungen mit begrenzter Lebenszeit konzipiert und bei den Auswertungsprozeduren verwendet. Die Klasse bietet ein ähnliches Interface, wie es die \texttt{std::vector}-Klasse bietet, jedoch mit einigen Einschränkungen wie einer maximalen Kapazität. Außerdem ist das Verhalten beim Löschen beschränkt, nur das Löschen des jeweils letzten Elements ist erlaubt.
|
|
sawine@0
|
19 |
\begin{figure}[h]
|
|
sawine@0
|
20 |
\centering \includegraphics[width=200pt]{images/stack_vector_uml.png}
|
|
sawine@0
|
21 |
\caption{\texttt{StackVector}}
|
|
sawine@0
|
22 |
\label{uml:stack_vector}
|
|
sawine@0
|
23 |
\end{figure}
|
|
sawine@0
|
24 |
|
|
sawine@0
|
25 |
\subsection{CppUnit}
|
|
sawine@0
|
26 |
\emph{CppUnit} ist ein C++-Testframework. Mit Hilfe von Präprozessormakros bietet das Framework Möglichkeiten, Klassen nach potentiellen Fehlern, d.h. Abweichungen von deren Spezifikation, zu testen. Die Auswertung der Unit-Tests wird im XML-Format bereitgestellt und kann somit bequem aufbereitet werden.
|
|
sawine@0
|
27 |
|
|
sawine@0
|
28 |
\subsection{Code Coverage}
|
|
sawine@0
|
29 |
\emph{Code Coverage} bezeichnet die verschiedenen Metriken zur Festlegung der Codeabdeckung von Tests. Bei der Integration verschiedener Überdeckungsanalysen ergibt sich eine verlässliche Statistik über die Testqualität. Diese kann dazu genutzt werden, Schwachstellen in der Testerstellung auszumachen und zu beseitigen.
|
|
sawine@0
|
30 |
|
|
sawine@0
|
31 |
\section{Entwicklungsumgebung}
|
|
sawine@0
|
32 |
|
|
sawine@0
|
33 |
\subsection{IDE}
|
|
sawine@0
|
34 |
Der Großteil der Implementierungsarbeit fand unter der \emph{Eclipse IDE} statt. \emph{Eclipse} bietet als Framework ein gelungene Schnittstelle an um die Funktionalität der IDE anzupassen oder zu erweitern. Für die C++-Entwicklung gibt es ein Plugin, das eine vollwertige C++-Entwicklungs"-umgebung bereitstellt. Die Vorteile der Nutzung einer integrierten Entwicklungsumgebung sind:
|
|
sawine@0
|
35 |
\begin{itemize}
|
|
sawine@0
|
36 |
\item Syntaxhervorhebung (\emph{Syntax highlighting})
|
|
sawine@0
|
37 |
\item Autovervollständigung (\emph{Autocomplete})
|
|
sawine@0
|
38 |
\item Integration mit anderen Werkzeugen wie Unit-Tests, Compiler, Versionierungssystem
|
|
sawine@0
|
39 |
\end{itemize}
|
|
sawine@0
|
40 |
Zudem bietet Eclipse genügend Anpassungsmöglichkeit des Editors, um diesen entsprechend den Comsoft-Richtlinien zu konfigurieren.
|
|
sawine@0
|
41 |
|
|
sawine@0
|
42 |
Weiterhin kamen die Texteditoren \emph{Vim}\footnote{Vi Improved -- eine Weiterentwicklung des konsolenbasierten Texteditors vi} und der \emph{GNOME Editor} -- kurz \texttt{gedit} zum Einsatz, u.a. bei der Entwicklung der Python-Skripte.
|
|
sawine@0
|
43 |
|
|
sawine@0
|
44 |
\subsection{Versionsverwaltung}
|
|
sawine@0
|
45 |
Ein Unternehmen für die Entwicklung von sicherheitskritischen Systemen ist stets bestrebt sowohl die Produkte als auch den Entwicklungsprozess sicher zu gestalten. Dies hat mitunter ein konservatives Verhalten bei der Technologiewahl als Konsequenz. Erprobte und bewährte Systeme und Prozesse werden nur nach gründlicher Voruntersuchung der Alternativen ersetzt, so auch im Falle des Versionsverwaltungssystems.
|
|
sawine@0
|
46 |
So wurde für dieses Projekt \emph{CVS}\footnote{Concurrent Versions System -- ein dateibasiertes Versionsverwaltungssystem für Quellcode} für die Versionsverwaltung des Quellcodes eingesetzt.
|
|
sawine@0
|
47 |
|
|
sawine@0
|
48 |
\subsection{Betriebssystem}
|
|
sawine@0
|
49 |
Das eingesetzte Betriebssystem während der Entwicklung war \emph{Red Hat Enterprise Linux 5.2}. Auch die Zielsysteme sind mit einem Red Hat Betriebssystem konfiguriert.
|
|
sawine@0
|
50 |
|
|
sawine@0
|
51 |
\section{Dokumentation \& Entwurf}
|
|
sawine@0
|
52 |
Die Comsoft-Dokumentation wird in \emph{Microsoft Word} erstellt, basierend auf hauseigenen Vorlagen. Für die Ausarbeitung der Bachelorarbeit wurde \LaTeX verwendet.
|
|
sawine@0
|
53 |
|
|
sawine@0
|
54 |
Für die Erstellung von Vektorgrafiken wurde \emph{Inkscape (\texttt{www.inkscape.org})} eingesetzt. Zur Entwicklung des UML-Entwurfs wurden \emph{MagicDraw\texttrademark UML} und der \emph{Umbrello UML Modeller (\texttt{www.uml.sourceforge.net})} verwendet. Die Codedokumentation wird automatisch mit \emph{Doxygen (\texttt{www.stack.nl/$\sim$dimitri/doxygen})} generiert.
|
|
sawine@0
|
55 |
|
|
sawine@0
|
56 |
Für die grafische Auswertung der aufbereiteten Protokolldaten des operativen Betriebs diente das Programm \emph{Gnuplot (\texttt{www.gnuplot.info})}.
|
|
sawine@0
|
57 |
|
|
sawine@0
|
58 |
\section{ATCCL}
|
|
sawine@0
|
59 |
\subsection{\texttt{flex}-Konfiguration}
|
|
sawine@0
|
60 |
\texttt{flex} unterstützt reguläre Ausdrücke zur Bestimmung der Token. Anhand einfacher Regeln und der Verwendung von Metazeichen (Abb. \ref{flex_metazeichen}) kann nach Zeichenkettenmuster gefiltert werden. Dafür entwickelt man Regeln, die auf der linken Seite einen regulären Ausdruck erhalten, während auf der rechten Seite die Aktion festgelegt wird.\\\\
|
|
sawine@0
|
61 |
Die Definition von Zeichenklassen erhöht den Ausdruckswert von komplexeren Regeln und dadurch deren Verständlichkeit. Für ATCCL wurden Zeichenklassen erstellt, die Basistypen der Sprache definieren.\\
|
|
sawine@0
|
62 |
\lstinputlisting[label=flex_config1, caption=ATCCL \texttt{flex}-Konfiguration: Zeichenklassen,language=TeX]{flex_config1.txt}
|
|
sawine@0
|
63 |
\begin{table}[h]
|
|
sawine@0
|
64 |
\begin{center}
|
|
sawine@0
|
65 |
\begin{tabular}{cl}
|
|
sawine@0
|
66 |
\toprule
|
|
sawine@0
|
67 |
\textbf{Metazeichen} & \textbf{Bedeutung} \\
|
|
sawine@0
|
68 |
\midrule
|
|
sawine@0
|
69 |
\texttt{.} & beliebiges zeichen außer Zeilenumbruch \\
|
|
sawine@0
|
70 |
\texttt{\textbackslash n}& Zeilenumbruch \\
|
|
sawine@0
|
71 |
\texttt{\textbackslash t}& Tabulator \\
|
|
sawine@0
|
72 |
\texttt{\textasteriskcentered} & null- oder mehrfache Kopie eines Ausdrucks \\
|
|
sawine@0
|
73 |
\texttt{+} & ein- oder mehrfache Kopie eines Ausdrucks \\
|
|
sawine@0
|
74 |
\texttt{?} & null- oder einfache Kopie eines Ausdrucks \\
|
|
sawine@0
|
75 |
\texttt{\textasciicircum}& Zeilenanfang \\
|
|
sawine@0
|
76 |
\texttt{\$} & Zeilenende \\
|
|
sawine@0
|
77 |
\texttt{a|b} & \texttt{a} oder \texttt{b} \\
|
|
sawine@0
|
78 |
\texttt{(ab)+} & ein- oder mehrfache Kopie von \texttt{ab} \\
|
|
sawine@0
|
79 |
\texttt{'a+b'} & \texttt{'a+b'} Literal \\
|
|
sawine@0
|
80 |
\texttt{[]} & Zeichenklasse \\
|
|
sawine@0
|
81 |
\bottomrule
|
|
sawine@0
|
82 |
\end{tabular}
|
|
sawine@0
|
83 |
\caption{\texttt{flex}-Metazeichen \emph{(Quelle: \cite{lex_paper}, \cite{lex_yacc_guide})}}
|
|
sawine@0
|
84 |
\label{flex_metazeichen}
|
|
sawine@0
|
85 |
\end{center}
|
|
sawine@0
|
86 |
\end{table}
|
|
sawine@0
|
87 |
Nun werden für die Schlüsselwörter der Flugplaneigenschaften entsprechende Token erstellt.\\
|
|
sawine@0
|
88 |
\lstinputlisting[label=flex_config2, caption=ATCCL \texttt{flex}-Konfiguration: Flugplaneigenschaften,language=TeX]{flex_config2.txt}
|
|
sawine@0
|
89 |
Zur Bestimmung der Separationszeiten wird auf eine weitere Flugplaneigenschaft zugegriffen -- die Flugfläche, dies ist nur innerhalb einer Separationsdefinition möglich. \texttt{time\_sep} bezeichnet die Art der Separation, in diesem Fall die Längsstaffelung nach Zeit.\\
|
|
sawine@0
|
90 |
\lstinputlisting[label=flex_config3, caption=ATCCL \texttt{flex}-Konfiguration: Separationstyp und Flugfläche,language=TeX]{flex_config3.txt}
|
|
sawine@0
|
91 |
Die folgenden Regeln gelten der Identifizierung des Regeltyps.\\
|
|
sawine@0
|
92 |
\lstinputlisting[label=flex_config4, caption=ATCCL \texttt{flex}-Konfiguration: Typ der Regeldefinition,language=TeX]{flex_config4.txt}
|
|
sawine@0
|
93 |
Die Operatoren bestehen aus einem oder mehreren Token. Zusammengesetzte Operatoren sind z.B. \texttt{not in}, \texttt{greater than} und \texttt{is not}.\\
|
|
sawine@0
|
94 |
\lstinputlisting[label=flex_config5, caption=ATCCL \texttt{flex}-Konfiguration: Operatoren,language=TeX]{flex_config5.txt}
|
|
sawine@0
|
95 |
Zusätzlich werden eine Reihe von Hilfstoken zur deskriptiven Definition der Separationsregeln erstellt.\\
|
|
sawine@0
|
96 |
\lstinputlisting[label=flex_config6, caption=ATCCL \texttt{flex}-Konfiguration: \texttt{Constraint}-Token,language=TeX]{flex_config6.txt}
|
|
sawine@0
|
97 |
Das yylval wird in der \texttt{bison}-Konfiguration als \texttt{union} von \texttt{integer, double} und \texttt{char*} deklariert. Dadurch wird eine typensichere Wertübertragung von Konstanten in die Syntaxanalyse ermöglicht.\\
|
|
sawine@0
|
98 |
\lstinputlisting[label=flex_config7, caption=ATCCL \texttt{flex}-Konfiguration: Basisdatentypen,language=TeX]{flex_config7.txt}
|
|
sawine@0
|
99 |
Zur zusätzlichen Unterstützung der nachfolgenden Analyse wird eine Regel für die Regeldefinitionsidentifikation gestellt und die Kommentare lokalisiert, zu Bemerken ist Kommentarinhalt wird nicht übergeben, wird demnach ignoriert. Die letzte Regel leitet alle Zeichen weiter, die bisher in keiner Regel aufgefangen wurde, wie z.B. die Klammern.\\
|
|
sawine@0
|
100 |
\lstinputlisting[label=flex_config8, caption=ATCCL \texttt{flex}-Konfiguration: IDs und Kommentare,language=TeX]{flex_config8.txt}
|
|
sawine@0
|
101 |
Eine Besonderheit in der \texttt{flex}-Konfiguration stellt die letzte Zeile dar, die bei Zeilenende den Inhalt der Zeile in einem Puffer zwischenspeichert und einen Zeilenzähler inkrementiert. Diese Regel dient der Fehlerbehandlung. Durch das puffern der Zeilen ist im Fehlerfall eine weitere Analyse möglich, außerdem kann man durch die Zeilenangabe die Lokalität des Fehlers präzisieren.\\
|
|
sawine@0
|
102 |
\lstinputlisting[label=flex_config9, caption=ATCCL \texttt{flex}-Konfiguration: Fehlerbehandlung,language=TeX]{flex_config9.txt}
|
|
sawine@0
|
103 |
\subsection{\texttt{bison}-Konfiguration}
|
|
sawine@0
|
104 |
Die Syntaxanalyse wird mit Hilfe von \texttt{bison} erstellt. Das Werkzeug erlaubt es in EBNF-ähnlicher Notation die Produktionen zu entwickeln und ist mit \texttt{flex} integrierbar.\\\\
|
|
sawine@0
|
105 |
Die Integration mit \texttt{flex} basiert auf der zustandsbehafteten Funktionsrückgabe der Funktion \texttt{yylex} welche die Token zur Weiterverarbeitung an \texttt{bison} liefert. Die vollständige Konfiguration befindet sich in Anhang \ref{bison_config}.
|
|
sawine@0
|
106 |
%\lstinputlisting[label=bison_config1 caption=ATCCL \texttt{bison}-Konfiguration 1,language=TeX]{bison_config1.txt}
|
|
sawine@0
|
107 |
|
|
sawine@0
|
108 |
\subsection{Synthese}
|
|
sawine@0
|
109 |
Der Entwurf sah die Nutzung des Factory Patterns zur generischen Objekterzeugung vor. Die Umsetzung wurde entsprechend durchgeführt. Es wurden zwei Factory-Klassen mit jeweils mehreren überladenen Funktionen erstellt. Anhang \ref{uml:factories} beschreibt die implementierten Klassen.
|
|
sawine@0
|
110 |
|
|
sawine@0
|
111 |
Die Analysephase erfasst die Operator- und Property-Typen und übergibt diese an die Factory-Klasse. Aus den verschiedenen Kombinationen ergeben sich die Term-Instanzen. Das \emph{Adapter Pattern} nach \cite{design_patterns} erlaubt eine generische Lösung für die Klassendefinition der Flugplaneigenschaften (Properties). Die Klassendefinition einer Flugplaneigenschaft wird in den typenabhängigen Rumpf, das \texttt{Property}-Template und eine Adapterklasse verteilt. Der Rumpf erhält den Datentyp der betreffenden Eigenschaft und den Adapter als Template-Parameter. Für jede Flugplaneigenschaft wird ein Adapter definiert, welcher mit Hilfe des FlightPlan-Interface die entsprechenden Dateneinträge in den Cache des Property-Objekts lädt.\\\\
|
|
sawine@0
|
112 |
Muss das ATCCL-Framework zu einem späteren Zeitpunkt um die Unterstützung einer weiterer Flugplaneigenschaft erweitert werden, so ist es notwendig einen Adapter dafür zu definieren und die Factory soweit zu erweitern, dass dieser Typ instanziiert wird. Selbstverständlich muss auch die \texttt{flex}- und \texttt{bison}-Konfiguration die neue Flugplaneigenschaft unterstützen und dieser einen Datentyp zuordnen. Diese Methode erlaubt ein strukturiertes Erweitern der Sprache und reduziert dabei den Implementierungsaufwand durch die Auslagerung aller gemeinsamen Funktionalität.
|
|
sawine@0
|
113 |
|
|
sawine@0
|
114 |
\section{DFLOW}
|
|
sawine@0
|
115 |
Zur Realisierung der DFLOW-Komponente konnte man auf den großen Funktionsumfang von PRISMA zugreifen. So war es nicht notwendig eigene Routinen zur Erstellung der Prognosen über die Überflugzeiten zu entwickeln, diese Funktion wurde bereits von \emph{CalcEstimates} bereitgestellt. FPATH übernimmt als FPDS-Komponente die Aktualisierung solcher Routentabellen samt prognostizierter Zeiten entsprechend dem realen Flugverlauf. Die Ergänzung der Flugroute unmittelbar nach dem Startvorgang wurde mit Hilfe von SID-Lookup-Tabellen realisiert, eine Erklärung zur Bedeutung der SIDs befindet sich in Abschnitt \ref{grundlagen:routensystem}. Die SID-Wegpunkte sind für jede Kombination von Flughafen, Startbahn und Routenverlauf festgelegt und statisch.
|
|
sawine@0
|
116 |
|
|
sawine@0
|
117 |
\subsection{FDPS}
|
|
sawine@0
|
118 |
Die DFLOW-Komponente wurde in den FDPS integriert. Die Komponente ist eine flugplanverarbeitende Instanz und interagiert mit anderen Komponenten des FDPS oder auch den Displays durch das DMAP-Protokoll. Sog. \emph{Notifier}-Klassen implementieren das Observer Pattern für bestimmte Datensätze der DMAP-Datenbank. \emph{Storage}-Klassen bieten eine transparente Zugriffsschicht auf DMAP-Datensätze. Durch die beiden Klassentypen ist es möglich, Event-getrieben und dadurch effektiv auf der DMAP zu arbeiten und gleichzeitig jederzeit volle Zugriffsmöglichkeit mit Hilfe von transparenten Transaktionen auf alle notwendigen Datensätze zu haben.
|
|
sawine@0
|
119 |
|
|
sawine@0
|
120 |
\subsection{Node Manager}
|
|
sawine@0
|
121 |
Der Node Manager ist für die Kontrolle der Vitalität der einzelnen PRISMA-Komponenten zuständig. Basierend auf dem Watchdog-Verfahren werden Prozesse aktiv angesprochen und die Reaktionszeiten zu messen. Ist die Vitalität des Systems durch eine Komponente gefährdet, so kann der Node Manager den Neustart oder die Deaktivierung der identifizierten Komponente mit Fehlfunktion veranlassen. Der Node Manager bietet für dessen Protokoll eine Klasse an, die eine voll automatisierte Lösung des Watchdog-Verfahrens auf Client-Seite darstellt.
|
|
sawine@0
|
122 |
|
|
sawine@0
|
123 |
\subsection{AWP}
|
|
sawine@0
|
124 |
Die AWP bietet eine Reihe von strategischer Displays als integrierte Lösung an. Ein Planer hat u.a. die Aufgaben Flugpläne den Startern zuzuordnen, Prognosen über Verkehrsaufkommen zu analysieren und basierend drauf Entscheidungen zu treffen.
|
|
sawine@0
|
125 |
\begin{figure}[h]
|
|
sawine@0
|
126 |
\centering \includegraphics[width=15.5cm]{images/dflow_displays_grey.png}
|
|
sawine@0
|
127 |
\label{fig:dflow_displays}
|
|
sawine@0
|
128 |
\caption[DFLOW Window \& Flow Aid Window]{Links: das Flow Aid Window zeigt eine graphische Übersicht der Flow Point Slot-Verteilung über Zeit und Flugfläche. Rechts: das DFLOW Window stellt die Interaktion mit der DFLOW-Komponente dar samt Übersicht über die erfasste Flugpläne.}
|
|
sawine@0
|
129 |
\end{figure}\\
|
|
sawine@0
|
130 |
Die DFLOW-Komponente soll mit Hilfe eines in die CWP integrierten Displays zu steuern sein. Die Entwicklung des DFLOW-Displays wurde von einem weiteren Mitarbeiter von Comsoft durchgeführt. Das Display bietet eine Übersicht über alle DFLOW-Dateneinträge, d.h. alle DFLOW-kontrollierten Flüge. Das DFLOW-Display erlaubt es dem Benutzer nach Flugplänen zu suchen und mit der Übergabe der frühesten Abflugzeit die Berechnung des optimalen Abflugslots zu initiieren.
|
|
sawine@0
|
131 |
|
|
sawine@0
|
132 |
\subsection{CWP}
|
|
sawine@0
|
133 |
Das CWP-Display ist das Kernstück des Flugsicherungssystems aus der Sicht des Benutzers. Die Controller erhalten mit diesem Display eine Übersicht über das Luftlagebild, potentielle Gefahrensituationen und erlaubt ein intelligentes Verteilen von Zuständigkeits"-bereichen. Im Gegensatz zur AWP, ist das Display für die unmittelbare Sicherung des Luftraums entwickelt, jedoch soll auch hier bei Bedarf die Information der CWP bereitgestellt werden.\\\\
|
|
sawine@0
|
134 |
Das DFLOW-Window wurde dazu auch in die CWP integriert. Da die Abflugplanung nicht unter die Zuständigkeit der Flutlotsen, die an der CWP aktiv sind, fällt, ist das DFLOW-Display hier als \emph{read-only}-Variante mit Echtzeitverfolgung realisiert.
|