1.1 Binary file book/out/buchblock.pdf has changed
2.1 --- a/book/src/conclusion.tex Sat Mar 26 01:46:39 2011 +0100
2.2 +++ b/book/src/conclusion.tex Mon Mar 28 19:25:26 2011 +0200
2.3 @@ -2,10 +2,9 @@
2.4 \section{Fazit}
2.5 Am Ende dieser Arbeit kann festgestellt werden, dass die Zielsetzung vollständig erreicht wurde. Der Projektverlauf war wie geplant, alle Phasen wurden erfolgreich abgeschlossen. Die Verifizierung ergab ein positives Bild über die Funktionalität der entwickelten Abflugplanungskomponente und des \emph{ATCCL-Frameworks}.
2.6
2.7 -Die Wahl eine domänenspezifische Sprache für die Modellierung der Luftraumbeschränkungen zu entwickeln, hat sich als ein großer Vorteil herausgestellt. Die Sprache gewährleistet große Freiheiten bei der Konfiguration der Abflugplanungskomponente, gleichzeitig bietet sie eine hervorragende Kontrolle über die Validität der Konfiguration. Bereits während der Bearbeitungszeit der Bachelorarbeit wurde \emph{ATCCL} in einem weiteren Projekt erfolgreich eingesetzt, was die Entwicklungszeit verkürzte und die Dynamik des Projekts erheblich steigerte.\\\\
2.8 +Die Wahl eine domänenspezifische Sprache für die Modellierung der Luftraumbeschränkungen zu entwickeln, hat sich als ein großer Vorteil herausgestellt. Die Sprache gewährleistet große Freiheiten bei der Konfiguration der Abflugplanungskomponente, gleichzeitig bietet sie eine hervorragende Kontrolle über die Validität der Konfiguration. Bereits während der Bearbeitungszeit der Arbeit wurde \emph{ATCCL} in einem weiteren Projekt erfolgreich eingesetzt, was die Entwicklungszeit verkürzte und die Dynamik des Projekts erheblich steigerte.\\\\
2.9 Seit dem 27. Januar 2010 wird \emph{DFLOW} erfolgreich im operativen Betrieb für die Bestimmung der Abflugzeiten von der \emph{GCAA} eingesetzt. Der störungsfreie Betrieb und ein zufriedener Kunde ist ein weiterer Beweis für die Qualität der realisierten Komponenten.
2.10
2.11 \section{Ausblick}
2.12 -Ein weiterer Ausbau des \emph{ATCCL-Frameworks} kann das Anwendungsgebiet der Sprache erweitern. Alle flugplanverarbeitenden Systeme können tendenziell vom Einsatz der Sprache profitieren. Durch das generische Konzept des Frameworks ist eine Erweiterung der Syntax und Semantik mit wenig Aufwand möglich, was eine schnelle Integration in zukünftige Projekte ermöglichen soll.
2.13 -
2.14 +Ein weiterer Ausbau des \emph{ATCCL-Frameworks} kann das Anwendungsgebiet der Sprache erweitern. Alle flugplanverarbeitenden Systeme können tendenziell vom Einsatz der Sprache profitieren. Durch das generische Konzept des Frameworks ist eine Erweiterung der Syntax und Semantik mit wenig Aufwand möglich, was eine schnelle Integration in zukünftige Projekte ermöglichen soll.\\\\
2.15 Die systematische Konfigurierbarkeit der \emph{DFLOW-Komponente} macht eine Erweiterung der Verarbeitungslogik möglich. Als Vervollständigung des Automatisierungskonzepts der Abflugregelung, ist eine Integration mit einem Departure Manager, zur Abhandlung des Mikromanagements auf Flughafenebene, geeignet.
3.1 --- a/book/src/design.tex Sat Mar 26 01:46:39 2011 +0100
3.2 +++ b/book/src/design.tex Mon Mar 28 19:25:26 2011 +0200
3.3 @@ -381,16 +381,16 @@
3.4 Das DFLOW braucht zur Realisierung der Logik Zugriff auf folgende DMAP-Datensätze:
3.5 \begin{itemize}
3.6 \item \textbf{DFLOW}\\
3.7 -Dieser Datensatz beinhaltet die DFLOW-spezifischen Einträge. Dazu gehört der sog. \emph{Slot State} -- der aktuelle Verarbeitungszustand des Eintrags. Weiterhin hält der Eintrag Daten über die Startbahn und die geltenden Flow Points. Als Zeiten sind der Zeitpunkt der Anfrage und die früheste und zugewiesene Abflugzeit Bestandteil eines Eintrags. Die DFLOW-Erweiterung der DMAP-Datensätze wird zum Zeitpunkt der Entwicklung bereitgestellt.
3.8 +Dieser Datensatz beinhaltet die DFLOW-spezifischen Einträge. Dazu gehört der sog. \emph{Slot State} -- der aktuelle Verarbeitungszustand des Eintrags. Weiterhin hält der Eintrag Daten über die Startbahn und die geltenden Flow Points. Als Zeiten sind der Zeitpunkt der Anfrage und die früheste und zugewiesene Abflugzeit Bestandteil eines Eintrags. Die DFLOW-Erweiterung der DMAP-Datensätze wurden zum Zeitpunkt der Entwicklung bereitgestellt.
3.9 \item \textbf{FPATH}\\
3.10 -Die \emph{Flight Path}-Datensätze halten Informationen über die Wegpunkte und deren veranschlagte Überflugzeiten. Diese Datensätze werden stets vom FDPS korrigiert um möglichst verlässliche Prognosen über den Flugverlauf der Luftfahrzeuge zu erlauben.
3.11 +Die \emph{Flight Path}-Datensätze halten Informationen über die Wegpunkte und deren veranschlagte Überflugzeiten. Diese Datensätze werden stets vom FDPS korrigiert, um möglichst verlässliche Prognosen über den Flugverlauf der Luftfahrzeuge zu erlauben.
3.12 \item \textbf{SFPL}\\
3.13 Alle Datensätze halten für jeden Eintrag eine Referenznummer -- die SFPI -- zum dazugehörigen \emph{System Flight Plan} -- oder auch SFPL. Dadurch wird die Verbindung zwischen weiterführenden Informationen zum Flugplan gemacht. Der SFPL beinhaltet alle Details eines regulären Flugplans mit einigen systemspezifischen Zusatzinformationen.
3.14 \end{itemize}
3.15 Die oben genannten Datensätze bieten alle Informationen, die eine DFLOW-Verarbeitung eines Flugplans benötigt. Die Idee ist es möglichst effiziente Entscheidungen anhand von abgefangen Transaktionen der DMAP zu treffen, um dabei die Zugriffe auf die Datensätze zu reduzieren.
3.16
3.17 \subsection{Verarbeitungslogik}
3.18 -Die Aufgabe des DFLOW ist es, optimale Abflugzeiten in Abhängigkeit der betroffenen Flow Points und dem, dafür zugewiesenen, Flugverkehr zu bestimmen. Zur Bedienung der Komponente wird ein DFLOW-Display entwickelt, das nicht Bestandteil dieser Arbeit sein soll.
3.19 +Die Aufgabe des DFLOW ist es, optimale Abflugzeiten in Abhängigkeit der betroffenen Flow Points und dem, dafür zugewiesenen, Flugverkehr zu bestimmen. Zur Bedienung der Komponente wird ein DFLOW-Display entwickelt, das nicht Bestandteil dieser Arbeit war.
3.20
3.21 Das Display bietet dem Benutzer Möglichkeiten, Flugpläne zu selektieren, sie mit Zusatzinformationen wie der Startbahn und der frühesten Abflugzeit zu vervollständigen, und die Bestimmung der optimalen Abflugzeit anzufordern. Die Anfrage der optimalen Abflugzeit initiiert die Verarbeitungslogik, hierfür wird dem erzeugten DFLOW-Eintrag ein \texttt{REQUEST}-Flag gesetzt.
3.22
3.23 @@ -398,7 +398,7 @@
3.24 \item \textbf{Ergänzung: SID-Wegpunkte}\\
3.25 Bevor die eigentliche Berechnung beginnen kann, müssen alle notwendigen Informationen bereitgestellt werden. Der erste Schritt ist die Ergänzung der Route um die SID-Wegpunkte, siehe \ref{grundlagen:routensystem}. Für alle internationalen Flughäfen gibt es fest definierte Routen, die in Abhängigkeit der Startbahn eine Verbindung zwischen den Startvektor und der Reiseroute herstellt.
3.26
3.27 -Im Falle DFLOW ist die vollständige Route essentiell für die Genauigkeit der Zeitenprognosen und somit ausschlaggebend für die Qualität der Optimierung.
3.28 +Im Fall DFLOW ist die vollständige Route essentiell für die Genauigkeit der Zeitenprognosen und somit ausschlaggebend für die Qualität der Optimierung.
3.29
3.30 \item \textbf{Bestimmung: Flow Points}\\
3.31 Sobald die Vervollständigung der Route abgeschlossen ist, findet die erste Interaktion mit der virtuellen Maschine des ATCCL-Frameworks statt. Die virtuelle Maschine wird mit der Ermittlung aller Flow Points beauftragt, die für den betreffenden Flugplan gelten. Dazu gilt es, den Flugplan durch die Flugplanmuster der Flow Points zu evaluieren. Details dazu sind in Abschnitt \ref{design:pattern_evaluation} zu finden.
3.32 @@ -407,10 +407,10 @@
3.33 Sobald alle Flow Points bekannt sind, werden alle Einträge im DFLOW-Datensatz geladen, die den gleichen Flow Points zugewiesen sind. Bei Flow Point-Überschneidungen kann es zu Kollisionen in der Zeit-Slot-Vergabe führen, somit müssen alle betroffenen Flugpläne bei der Vergabe der Abflugzeit berücksichtigt werden.
3.34
3.35 \item \textbf{Berechnung: Wegpunktzeiten}\\
3.36 -Mit Hilfe der PRISMA-Klasse \texttt{CalcEstimates} lassen sich die Wegpunktzeiten der Route bestimmen. Ausgangspunkt der Rechnung ist die \emph{Estimated Entry Time} -- oder ETN -- die wir mit der frühesten Abflugzeit belegen. Die Berechnung der Zeiten ist notwendig für die Konfliktauflösung der Flow Point Slot-Zeiten.
3.37 +Mit Hilfe der PRISMA-Klasse \texttt{CalcEstimates} lassen sich die Wegpunktzeiten der Route bestimmen. Ausgangspunkt der Rechnung ist die \emph{Estimated Entry Time} -- oder ETN -- die wir mit der frühesten Abflugzeit belegen. Die Berechnung der Zeiten ist für die Konfliktauflösung der Flow Point Slot-Zeiten notwendig.
3.38
3.39 \item \textbf{Berechnung: optimale Abflugzeit}\\
3.40 -Die Vorbereitungszeit ist abgeschlossen und die Berechnung der optimalen Abflugzeit wird eingeleitet. Die Kalkulation wird von der virtuellen Maschine geleistet. Die Eingabeparameter bestehen aus dem Flugplan, der zur Bearbeitung steht und den Flugplänen mit den gleichen zugewiesenen Flow Points. Der Optimierungsalgorithmus ist in \ref{design:atot_calculation} beschrieben. In diesem Schritt wird ebenfalls die Höhenstaffelung realisiert werden.
3.41 +Die Vorbereitungsphase ist abgeschlossen und die Berechnung der optimalen Abflugzeit wird eingeleitet. Die Kalkulation wird von der virtuellen Maschine geleistet. Die Eingabeparameter bestehen aus dem Flugplan, der zur Bearbeitung steht und den Flugplänen mit den gleichen zugewiesenen Flow Points. Der Optimierungsalgorithmus ist in \ref{design:atot_calculation} beschrieben. In diesem Schritt ist ebenfalls die Höhenstaffelung realisiert.
3.42 \end{enumerate}
3.43 Nach Abfolge der Verarbeitungsschritte sind die Flow Points und Flugflächen zugewiesen, die optimale Abflugzeit bestimmt und die resultierende Flow Point-Überflugzeit ermittelt. Die gewonnen Informationen werden durch eine Transaktion an den DMAP-Datensatz übermittelt. Mit der Über"-mittlung beendet die Verarbeitung des DFLOW, für die Visualisierung der DFLOW-spezifischen Daten ist das DFLOW-Display zuständig. Zur Verifizierung der Verarbeitungsterminierung wird dem Eintrag das \texttt{PROPOSAL}-Flag gesetzt.\\\\
3.44 Eine automatisierte Vergabe von Abflugzeiten ist stets nur ein Vorschlag, welcher vom Benutzer überstimmt werden kann. Dies stellt eine wichtige Anforderungen an das System dar. Eine voll automatisierte Verarbeitung bietet nicht die Flexibilität, die in einem Umfeld wie der Flugsicherung zu einem reibungsfreien und effektiven Betrieb notwendig ist. Treten Ausnahmesituationen ein, oder wird die Qualität der Automatisierung durch andere Faktoren gestört, so muss es möglich sein, den Flugverkehr ordnungsgemäß in manueller Steuerung abzuhalten. Ist die manuelle Steuerung unmöglich, so kann das zu einer Beeinträchtigung der Flugsicherung und damit der Sicherheit oder Effektivität führen, was letztendlich mit der Abschaltung des Systems enden kann, \cite{flugleiter_dman}.
3.45 @@ -421,7 +421,7 @@
3.46 %\end{figure}
3.47
3.48 \subsection{Protokollierung}
3.49 -DFLOW bedient sich der DMAP, welche alle Transaktionen protokolliert. Diese Zustand erleichtert die Nachvollziehbarkeit der Entscheidungen, die von der DFLOW-Komponente automatisch oder manuell gemacht werden. Zur Ergänzung der statistischen Auswertemöglichkeiten des FDPS, sollen zusätzlich DFLOW-spezifische persistente Logdateien erzeugt werden. Ein Logeintrag soll einen Starter mit relevanten Zusatzinformationen wie dessen Rufzeichen, zugewiesener Flow Point und den Zeiten protokollieren.\\\\
3.50 +DFLOW bedient sich der DMAP, welche alle Transaktionen protokolliert. Diese Zustand erleichtert die Nachvollziehbarkeit der Entscheidungen, die von der DFLOW-Komponente automatisch oder manuell gemacht werden. Zur Ergänzung der statistischen Auswertemöglichkeiten des FDPS, sollen zusätzlich DFLOW-spezifische persistente Logdateien erzeugt werden. Ein Logeintrag soll einen Starter mit relevanten Zusatzinformationen wie dessen Rufzeichen, zugewiesene Flow Points und den Zeiten protokollieren.\\\\
3.51 Um eine automatisierte Auswertung solcher Protokolle zu erleichtern, wird für die DFLOW-Protokolle ein CSV-Datenformat verwendet. Ein Protokolleintrag hat folgende Datenfelder:
3.52 \begin{itemize}
3.53 \item \emph{Call Sign:} das Rufzeichen des Luftfahrzeugs
4.1 --- a/book/src/document.log Sat Mar 26 01:46:39 2011 +0100
4.2 +++ b/book/src/document.log Mon Mar 28 19:25:26 2011 +0200
4.3 @@ -1,4 +1,4 @@
4.4 -This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.1.10) 26 MAR 2011 01:46
4.5 +This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.1.10) 28 MAR 2011 19:14
4.6 entering extended mode
4.7 restricted \write18 enabled.
4.8 %&-line parsing enabled.
4.9 @@ -1927,10 +1927,10 @@
4.10 []
4.11
4.12
4.13 -Overfull \hbox (13.88303pt too wide) in paragraph at lines 104--107
4.14 -\OT1/lmr/m/n/12 Funk-ti-on \OT1/lmtt/m/n/12 yylex \OT1/lmr/m/n/12 wel-che die T
4.15 -o-ken zur Wei-ter-ver-ar-bei-tung an \OT1/lmtt/m/n/12 bison \OT1/lmr/m/n/12 lie
4.16 --fert. Die vollst[]andige
4.17 +Overfull \hbox (17.14833pt too wide) in paragraph at lines 104--107
4.18 +\OT1/lmr/m/n/12 Funk-ti-on \OT1/lmtt/m/n/12 yylex\OT1/lmr/m/n/12 , wel-che die
4.19 +To-ken zur Wei-ter-ver-ar-bei-tung an \OT1/lmtt/m/n/12 bison \OT1/lmr/m/n/12 li
4.20 +e-fert. Die vollst[]andige
4.21 []
4.22
4.23
4.24 @@ -1945,7 +1945,7 @@
4.25 []
4.26
4.27
4.28 -Underfull \vbox (badness 4441) has occurred while \output is active []
4.29 +Underfull \vbox (badness 10000) has occurred while \output is active []
4.30
4.31 [73]
4.32 <images/dflow_displays_grey.png, id=1754, 1272.755pt x 574.145pt>
4.33 @@ -2032,7 +2032,12 @@
4.34
4.35 []
4.36
4.37 -) [85] [86] (./document.lof)
4.38 +)
4.39 +Underfull \hbox (badness 10000) in paragraph at lines 9--82
4.40 +
4.41 + []
4.42 +
4.43 +[85] [86] (./document.lof)
4.44 \tf@lof=\write6
4.45 \openout6 = `document.lof'.
4.46
4.47 @@ -2145,7 +2150,7 @@
4.48 Here is how much of TeX's memory you used:
4.49 13172 strings out of 495021
4.50 186649 string characters out of 1181035
4.51 - 329858 words of memory out of 3000000
4.52 + 329867 words of memory out of 3000000
4.53 15157 multiletter control sequences out of 15000+50000
4.54 67653 words of font info for 68 fonts, out of 3000000 for 9000
4.55 28 hyphenation exceptions out of 8191
4.56 @@ -2166,7 +2171,7 @@
4.57 usr/share/texmf/fonts/type1/public/lm/lmtk10.pfb></usr/share/texmf/fonts/type1/
4.58 public/lm/lmtt12.pfb></usr/share/texmf/fonts/type1/public/lm/lmtti10.pfb></usr/
4.59 share/texmf/fonts/type1/public/lm/lmtto10.pfb>
4.60 -Output written on document.pdf (107 pages, 1865716 bytes).
4.61 +Output written on document.pdf (107 pages, 1865638 bytes).
4.62 PDF statistics:
4.63 2505 PDF objects out of 2984 (max. 8388607)
4.64 811 named destinations out of 1000 (max. 500000)
5.1 Binary file book/src/document.pdf has changed
6.1 --- a/book/src/impl.tex Sat Mar 26 01:46:39 2011 +0100
6.2 +++ b/book/src/impl.tex Mon Mar 28 19:25:26 2011 +0200
6.3 @@ -4,15 +4,15 @@
6.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.
6.5
6.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.\\\\
6.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.
6.8 +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.
6.9
6.10 \subsection{Compiler}
6.11 -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.\\\\
6.12 -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.
6.13 +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 ist.\\\\
6.14 +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.
6.15
6.16 \subsection{Comsoft \texttt{stdbase}}
6.17 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.\\\\
6.18 -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.
6.19 +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 diese bedienen können.
6.20
6.21 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.\\\\
6.22 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.
6.23 @@ -31,7 +31,7 @@
6.24 \section{Entwicklungsumgebung}
6.25
6.26 \subsection{IDE}
6.27 -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:
6.28 +Der Großteil der Implementierungsarbeit fand in 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 Entwicklungs"-umgebung bereitstellt. Die Vorteile der Nutzung einer integrierten Entwicklungsumgebung sind:
6.29 \begin{itemize}
6.30 \item Syntaxhervorhebung (\emph{Syntax highlighting})
6.31 \item Autovervollständigung (\emph{Autocomplete})
6.32 @@ -39,17 +39,17 @@
6.33 \end{itemize}
6.34 Zudem bietet Eclipse genügend Anpassungsmöglichkeit des Editors, um diesen entsprechend den Comsoft-Richtlinien zu konfigurieren.
6.35
6.36 -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.
6.37 +Weiterhin kamen die Texteditoren \emph{Vim}\footnote{Vi Improved -- eine Weiterentwicklung des konsolenbasierten Texteditors vi} und \emph{Emacs} und zum Einsatz, u.a. bei der Entwicklung der Python-Skripte.
6.38
6.39 \subsection{Versionsverwaltung}
6.40 -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.
6.41 -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.
6.42 +Ein Unternehmen für die Entwicklung sicherheitskritischer Systeme 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.
6.43 +So wurde für dieses Projekt \emph{CVS}\footnote{Concurrent Versions System -- ein dateibasiertes Versionsverwaltungssystem für Quellcode} für die Versionsverwaltung des Quellcodes und der Systemkonfigurationen eingesetzt.
6.44
6.45 \subsection{Betriebssystem}
6.46 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.
6.47
6.48 \section{Dokumentation \& Entwurf}
6.49 -Die Comsoft-Dokumentation wird in \emph{Microsoft Word} erstellt, basierend auf hauseigenen Vorlagen. Für die Ausarbeitung der Bachelorarbeit wurde \LaTeX verwendet.
6.50 +Die Comsoft-Dokumentation wird in \emph{Microsoft Word} erstellt, basierend auf hauseigenen Vorlagen. Für die Ausarbeitung dieses Buches wurde \LaTeX verwendet.
6.51
6.52 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.
6.53
6.54 @@ -96,13 +96,13 @@
6.55 \lstinputlisting[label=flex_config6, caption=ATCCL \texttt{flex}-Konfiguration: \texttt{Constraint}-Token,language=TeX]{flex_config6.txt}
6.56 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.\\
6.57 \lstinputlisting[label=flex_config7, caption=ATCCL \texttt{flex}-Konfiguration: Basisdatentypen,language=TeX]{flex_config7.txt}
6.58 -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.\\
6.59 +Zur zusätzlichen Unterstützung der nachfolgenden Analyse wird eine Regel für die Regeldefinitionsidentifikation gestellt und die Kommentare lokalisiert. Der Kommentarinhalt wird nicht übergeben sondern ignoriert. Die letzte Regel leitet alle Zeichen weiter, die bisher in keiner Regel aufgefangen wurde, wie z.B. die Klammern.\\
6.60 \lstinputlisting[label=flex_config8, caption=ATCCL \texttt{flex}-Konfiguration: IDs und Kommentare,language=TeX]{flex_config8.txt}
6.61 -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.\\
6.62 +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 den Fehler lokalisieren.\\
6.63 \lstinputlisting[label=flex_config9, caption=ATCCL \texttt{flex}-Konfiguration: Fehlerbehandlung,language=TeX]{flex_config9.txt}
6.64 \subsection{\texttt{bison}-Konfiguration}
6.65 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.\\\\
6.66 -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}.
6.67 +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}.
6.68 %\lstinputlisting[label=bison_config1 caption=ATCCL \texttt{bison}-Konfiguration 1,language=TeX]{bison_config1.txt}
6.69
6.70 \subsection{Synthese}
6.71 @@ -118,17 +118,17 @@
6.72 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.
6.73
6.74 \subsection{Node Manager}
6.75 -Der Node Manager ist für die Kontrolle der Vitalität der einzelnen PRISMA-Komponen\-ten 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.
6.76 +Der Node Manager ist für die Kontrolle der Vitalität der einzelnen PRISMA-Komponen\-ten zuständig. Basierend auf dem Watchdog-Verfahren werden Prozesse aktiv angesprochen um 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.
6.77
6.78 \subsection{AWP}
6.79 -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.
6.80 +Die AWP bietet eine Reihe 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 darauf Entscheidungen zu treffen.
6.81 \begin{figure}[h]
6.82 \centering \includegraphics[width=15.5cm]{images/dflow_displays_grey.png}
6.83 \label{fig:dflow_displays}
6.84 \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.}
6.85 \end{figure}\\
6.86 -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.
6.87 +Die DFLOW-Komponente soll mit Hilfe eines in die CWP integrierten Displays zu steuern sein. Die Entwicklung des DFLOW-Displays war ein Teil des Projekts, die Dokumentation dessen ist aber nicht Teil dieser Arbeit. 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.
6.88
6.89 \subsection{CWP}
6.90 -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.\\\\
6.91 +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.\\\\
6.92 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.
7.1 --- a/book/src/verification.tex Sat Mar 26 01:46:39 2011 +0100
7.2 +++ b/book/src/verification.tex Mon Mar 28 19:25:26 2011 +0200
7.3 @@ -1,6 +1,6 @@
7.4 \chapter{Verifikation}
7.5 \section{Werkzeugeinsatz}
7.6 -Nach Beendigung der Entwicklungsphase, war man in der Lage ein Fazit über die Qualität der eingesetzten Werkzeuge zu stellen. Deren Einsatz wurde hinsichtlich der Effektivitätssteigerung bewertet. Tabelle \ref{auto_gen_loc} bietet eine quantitative Übersicht über die Komplexität der entwickelten Komponenten.\\
7.7 +Nach Beendigung der Entwicklungsphase war man in der Lage ein Fazit über die Qualität der eingesetzten Werkzeuge zu stellen. Deren Einsatz wurde hinsichtlich der Effektivitätssteigerung bewertet. Tabelle \ref{auto_gen_loc} bietet eine quantitative Übersicht über die Komplexität der entwickelten Komponenten.\\
7.8 \begin{table}[h]
7.9 \begin{center}
7.10 \begin{tabular}{cll}
7.11 @@ -20,13 +20,13 @@
7.12 \end{center}
7.13 \end{table}\\
7.14 Das ATCCL-Framework ist in Codezeilen bemessen der Schwerpunkt der Entwicklung gewesen. Mit einem Konfigurationsaufwand von 432 Zeilen Code, wurde mit Hilfe von \texttt{flex} und \texttt{bison} rund 30\% des ATCCL-Frameworks generiert. Die quantitative Auswertung beinhaltet nicht die hohe Komplexität einer Parsergenerierung und der notwendigen Testprozeduren, um die Fehlerfreiheit des Parsers zu gewährleisten. Zusammenfassend kann man behaupten, mit dem Einsatz der Parsergeneratoren eine enorme Steigerung der Produktivität erzielt zu haben.\\\\
7.15 -Nach \cite{code_gen} bietet der Einsatz von Codegeneratoren auch beim Zertifizierungsprozess einen Vorteil gegenüber manuell entwickeltem Code. Bei dem ATCCL-Framework wird die Zertifizierung der Parsergeneratoren nicht notwendig sein, da der automatisch generierter Code ausschließlich im Compiler-Front-End zum Einsatz kommt. Das Front-End ist für die Syntax- und Semantikanalyse zuständig, welche nur bei der Initialisierung durchgeführt werden. Fehlverhalten in der Initialisierungsphase bedeutet keine Gefährdung der Sicherheit, solange diese erfolgreich erkannt werden und somit die operative Phase verhindert wird. Die Synthese erfolgt durch manuell entwickeltem Code, die generierten Objekte daraus werden auch zur Laufzeit aktiv.
7.16 +Nach \cite{code_gen} bietet der Einsatz von Codegeneratoren auch beim Zertifizierungsprozess einen Vorteil gegenüber manuell entwickeltem Code. Bei dem ATCCL-Framework wird die Zertifizierung der Parsergeneratoren nicht notwendig sein, da der automatisch generierter Code ausschließlich im Compiler-Front-End zum Einsatz kommt. Das Front-End ist für die Syntax- und Semantikanalyse zuständig, welche nur bei der Initialisierung durchgeführt werden. Fehlverhalten in der Initialisierungsphase bedeutet keine Gefährdung der Sicherheit, solange diese erfolgreich erkannt werden und somit die operative Phase verhindert wird. Die Synthese erfolgt durch manuell entwickelten Code, die generierten Objekte daraus werden auch zur Laufzeit aktiv.
7.17
7.18 \section{Unit-Tests}
7.19 Während der Implementierungsphase wurden für die C++-Klassen Unit-Tests erstellt, die das Verhalten der Einheiten gegen die Anforderungen prüfen. Mit Hilfe von Über"-deckungs"-diagnosen werden nicht ausreichend getestete Module lokalisiert und die ungeprüften Bereiche mit weiteren Tests belegt.
7.20
7.21 Zu den kritischen Modulen gehören u.a. \texttt{VirtualMachine}, \texttt{StackVector} und \newline \texttt{TermFactory}.
7.22 -Die \texttt{Virtual"-Machine} beherbergt die zeit-bestimmenden Algorithmen und muss deshalb besonders intensiv getestet werden. Hier ist nicht nur die Korrektheit der Ergebnisse relevant, sondern auch die Laufzeiten der Berechnungen, mehr dazu in Abschnitt \ref{verification:efficiency}. Die StackVector-Klasse dient als Standardklasse für eine Reihe von Situationen, Fehler in dieser Klasse würden Konsequenzen für eine Reihe von Modulen haben. Die TermFactory ist als objekterzeugende Einheit wegen der dynamischen Speicherallokierung kritisch. Gleichzeitig bieten die Tests dieser Klasse eine unmittelbare Prüfung für neu integrierte Property-Klassen.
7.23 +Die \texttt{Virtual"-Machine} beherbergt die zeitbestimmenden Algorithmen und muss deshalb besonders intensiv getestet werden. Hier ist nicht nur die Korrektheit der Ergebnisse relevant, sondern auch die Laufzeiten der Berechnungen, mehr dazu in Abschnitt \ref{verification:efficiency}. Die StackVector-Klasse dient als Standardklasse für eine Reihe von Situationen, Fehler in dieser Klasse würden Konsequenzen für eine Reihe von Modulen haben. Die TermFactory ist als objekterzeugende Einheit wegen der dynamischen Speicherallokierung kritisch. Gleichzeitig bieten die Tests dieser Klasse eine unmittelbare Prüfung für neu integrierte Property-Klassen.
7.24
7.25 \section{Testspezifikation}
7.26 Die Testspezifikation -- auch System Test Description -- wird analog zu dem SRS\footnote{System Requirements Specification -- Dokument zur Spezifikation der Systemanforderungen} entwickelt. Jeder Test hat mindestens eine Anforderung abzudecken, alle Anforderungen müssen mindestens in einem Test verifiziert werden.
7.27 @@ -58,7 +58,7 @@
7.28 \subsection{Analysewerkzeuge}
7.29 Die Bewertung basiert auf den von DFLOW erstellten Logdaten und den DMAP-Transaktions"-protokollen. Die DFLOW-Logs enthalten einen Eintrag für jeden erfassten Starter, während die \emph{Daily Movement Logs} -- kurz DML -- alle Flüge innerhalb des kontrollierten Gebiets protokollieren.
7.30
7.31 -Durch die detaillierte Protokollführung, entstehen große Datenmengen. Die tägliche Datenmenge misst im Durchschnitt ca. 350 kB für die DFLOW-Logs, 6 MB für die DMLs und 60 MB für die DMAP-Transaktionen. Um eine Analyse dieser Daten zu ermöglichen, wurden \emph{Python}\footnote{Eine dynamische, höhere Programmiersprache, der gute Lesbarkeit attestiert wird -- wird durch die hohe Abstraktion und weite Verbreitung oft als Skriptsprache eingesetzt}-Skripte entwickelt. Die Skripte dienen der Vorverarbeitung der Datensätze, im Detail:
7.32 +Durch die detaillierte Protokollführung entstehen große Datenmengen. Die tägliche Datenmenge misst im Durchschnitt ca. 350 kB für die DFLOW-Logs, 6 MB für die DMLs und 60 MB für die DMAP-Transaktionen. Um eine Analyse dieser Daten zu ermöglichen, wurden \emph{Python}\footnote{Eine dynamische, höhere Programmiersprache, der gute Lesbarkeit attestiert wird -- wird durch die hohe Abstraktion und weite Verbreitung oft als Skriptsprache eingesetzt}-Skripte entwickelt. Die Skripte dienen der Vorverarbeitung der Datensätze, im Detail:
7.33 \begin{itemize}
7.34 \item \texttt{dflowlog.py} ist das Basismodul zur Interaktion mit DFLOW-Logs
7.35 \item \texttt{filter.py} dient zum Entfernen nicht relevanter Datensätze
7.36 @@ -66,7 +66,7 @@
7.37 \item \texttt{pushback.py} versetzt Spalteneinträge nach hinten, erleichtert den Einsatz von cutbase.py
7.38 \item \texttt{cutbase.py} entfernt nicht relevante Spalten, als Vorbereitung zur Weiterverarbeitung mit \texttt{gnuplot}
7.39 \end{itemize}
7.40 -Zusätzlich wurde nach dem Prinzip des \emph{Data-Warehouse} eine \emph{MySQL}\footnote{Ein Open-Source-Datenbankmanagementsystem}-Datenbank angelegt. In die Datenbank wurden Daten, in aufbereiteter und auf den aussagekräftigen Informationsteil reduziert, aus den verschiedenen Protokollquellen importiert. Die Datenbank bietet eine Möglichkeit mit SQL-Abfragen dynamische Auswertungen und Zusammenhänge zwischen verschiedenen Datensätzen zu bilden. Die Extraktion, Transformation und das Laden in die Datenbank wurde mit einem weiteren Python-Skript realisiert:
7.41 +Zusätzlich wurde nach dem Prinzip des \emph{Data-Warehouse} eine \emph{MySQL}\footnote{Ein Open-Source-Datenbankmanagementsystem}-Datenbank angelegt. In die Datenbank wurden Daten in aufbereiteter, auf den aussagekräftigen Informationsteil reduzierten Form aus den verschiedenen Protokollquellen importiert. Die Datenbank bietet eine Möglichkeit mit SQL-Abfragen dynamische Auswertungen und Zusammenhänge zwischen verschiedenen Datensätzen zu bilden. Die Extraktion, Transformation und das Laden in die Datenbank wurde mit einem weiteren Python-Skripten realisiert:
7.42 \begin{itemize}
7.43 \item \texttt{dml.py} ist das Basismodul zur Interaktion mit DML-Dateien
7.44 \item \texttt{dml2db.py} dient zur Extraktion relevanter DML-Einträge und dem Laden der Daten in die Datenbank
7.45 @@ -85,7 +85,7 @@
7.46 \end{figure}\\
7.47 Die Analyse der rund 1800 Flüge ergab, dass die vergebenen Zeiten zum größten Teil sehr strikt eingehalten werden. Man sieht eine starke Konzentration um den Nullpunkt auf der X-Achse. Die Streuung beschränkt sich, bis auf wenige Ausnahmen, auf eine Abweichung von $\pm$3 Minuten.
7.48
7.49 -Interessant ist eine kleine Gruppe von abweichenden Zeiten im Bereich (-20, 25). Die Flüge in diesem Bereich wurden zur Einhaltung der Separationsregeln um rund 25 Minuten zeitlich versetzt. Die tatsächliche Abflugzeit liegt jedoch 20 Minuten vor der vergebenen Zeit, also unmittelbar nach der frühesten Abflugzeit. Die Entscheidung der Planer die vergebene Zeit nicht zu übersteuern und trotzdem den frühzeitigen Abflug zu gestatten, mag in der Funktion von DFLOW liegen, solche Verletzungen der Abflugslots visuell zu signalisieren. Sowohl der Planer an der AWP als auch der Fluglotse an der CWP werden durch eine definierte Zeichenkette über die Abweichung informiert und diesen Flügen besondere Aufmerksamkeit bei der Eingliederung in den Luftverkehr widmen.
7.50 +Interessant ist eine kleine Gruppe von abweichenden Zeiten im Bereich (26, -20). Die Flüge in diesem Bereich wurden zur Einhaltung der Separationsregeln um rund 25 Minuten zeitlich versetzt. Die tatsächliche Abflugzeit liegt jedoch 20 Minuten vor der vergebenen Zeit, also unmittelbar nach der frühesten Abflugzeit. Die Entscheidung der Planer die vergebene Zeit nicht zu übersteuern und trotzdem den frühzeitigen Abflug zu gestatten, mag an der Funktion von DFLOW liegen, solche Verletzungen der Abflugslots visuell zu signalisieren. Sowohl der Planer an der AWP als auch der Fluglotse an der CWP werden durch eine definierte Zeichenkette über die Abweichung informiert und diesen Flügen besondere Aufmerksamkeit bei der Eingliederung in den Luftverkehr widmen.
7.51 \begin{figure}[h]%
7.52 %\centering
7.53 \parbox{6.5cm}{\input{laldo_hist}}%