\chapter{Anforderungsanalyse}

Die Grundlage der Anforderungsanalyse bestand aus den Benutzeranforderungen, die zusammengefasst in einem Dokument von der GCAA bereitgestellt wurden. Diese Anforderungen wurden schrittweise mit Hilfe von sog. User-Stories in einen Kontext gebracht um dadurch etwaige Uneindeutigkeiten zu beseitigen.\\\\

Für jede Benutzeranforderung wurde mindestens eine Anforderung an das System entwickelt. Dabei wurden entstehende Anforderungsabhängigkeiten durch das Extrahieren einer unabhängigen Anforderung aufgelöst.

Bei der Formulierung der Anforderungen wurde strikt zwischen Anforderung an die Sprache, an das verarbeitende System und an das Benutzer-Interface getrennt. Diese Trennung ermöglichte im weiteren Verlauf die Erarbeitung der Anforderungen an die Komponenten, insbesondere an die Syntax der Konfigurationssprache.

\section{Modellierung der Luftraumbeschränkungen}

Jeder Luftraum besitzt dynamische Beschränkungen auf die Verteilung des Luftverkehrs. Die Beschränkungen dienen maßgeblich zur Gewährleistung der Sicherheit des Luftraums unter Berücksichtigung der geografischen, politischen und technischen Merkmalen der ATS-Routen. Die Dynamik der Regelungen wird durch die Abhängigkeit von Tageszeiten, den Eigenschaften eines Luftfahrzeugs und dessen Flugplan und den vorherrschenden Luftraumbedingungen bestimmt.\\\\

Die Modellierung der Luftraumbeschränkungen soll durch eine Konfigurationssprache realisiert werden. Zur Festlegung der Merkmale für die Konfigurationssprache wurden folgende Aspekte berücksichtigt:

\begin{itemize}

\item Benutzerqualifikation

\item Sicherheitsfaktoren

\item Domänenkontext (Flugplandaten, Flussdichtenregelungen)

\end{itemize}

\subsection{Benutzerqualifikation}

Die Sprache soll eine domänennahe Konfigurationsmöglichkeit bieten, dabei Redundanz und Komplexität in der Syntax vermeiden. Der typische Benutzer der Sprache hat eine Ausbildung im Bereich Flugsicherung und ist technisch versiert.

Anhand dieser Voraussetzungen entstanden Prototypen für die Syntax der Sprache, die vom Entwicklungsteam evaluiert wurden.\\\\

Die Analyse ergab eine deklarative Sprache, die explizite Syntaxelemente aufweist. 

Eine deklarative Sprache beschreibt das formale Modell der Berechnung. Im Gegensatz dazu wird beim imperativen Programmieren der Berechnungsalgorithmus in einzelnen zustandsverändernden Anweisungen verfasst. Zur Vereinfachung kann man sagen, dass der deklarative Ansatz eine zielorientierte Kodierung bedeutet, während beim imperativen Programmieren der Lösungs"-weg, also der Algorithmus kodiert wird. Die zielorientierte Kodierung bedeutet eine Abstraktion vom darunter liegenden Datenmodell und Berechnungsweg, dies ermöglicht den Einsatz der Sprache in dem Domänenumfeld unter Berücksichtigung der Benutzerqualifikationen.\\\\

Als Vorlagen wurden die Logikprogrammiersprache Prolog für die Regeldefinitionen und die Datenbanksprache SQL\footnote{Structured Query Language -- Sprache zur Definition, Manipulation und Abfrage von Daten in relationalen Datenbanken} für die Definition der Regelbedingungen genommen. Gerade SQL eignet sich in Hinsicht der Nähe zur natürlichen Sprache und der expliziten Ausdrücke für diesen Einsatz.

\subsection{Sicherheitsfaktoren}

Die Konfiguration der Abflugplanungskomponente hat Einfluss auf die Verarbeitungsprozesse und ist somit weit möglichst auf Korrektheit zu prüfen. Die Prüfung der Konfiguration soll in der Initialisierungsphase des Systems stattfinden, um die sichere Operation eines Systems zu garantieren, \cite{iec_61508}. Bei statisch typisierten Sprachen werden bereits beim Übersetzen die Datentypen festgelegt und somit überprüfbar gemacht. Dies ermöglicht es, eine große Anzahl an möglichen Fehlern in der Konfiguration zu erkennen, bei denen ungültige Kombinationen von Operation und Datentyp bestehen.\\\\

Jede Funktionalität eines Systems muss stets überwacht werden. Bei Fehlverhalten soll eine Wiederaufnahme der Funktionalität gewährleistet werden, ohne die Datenintegrität oder andere Prozesse des Systems zu gefährden. 

Zur Sicherung der Daten wird eine strikte Trennung von Daten und informationsverarbeitenden Prozessen durchgeführt. Jeder Transaktion wird geprüft, protokolliert und redundant propagiert. In der Flugsicherung ist die redundante Auslegung von Komponenten Kernbestandteil bei der Sicherung der Verfügbarkeit eines Systems. Die letzte Option bei dem Auflösen eines Systemkonflikts liegt in der Abschaltung und Neuinitialisierung eines Systems, während die redundante Auslegung weiterhin die Funktionalität sicherstellt. 

\subsubsection{Statusmeldungen}

Durch das \emph{Watchdog}-Protokoll ist es möglich die Vitalität einer Komponente zu über\-wachen. In periodischen Abständen wird dabei von einem Überwachungsprozess eine Anfrage an alle Komponenten gestartet, die innerhalb einer bestimmten Zeit beantwortet werden muss. Die Antwort kann detaillierte Informationen über den Status einer Komponente enthalten, oder lediglich deren Aktivität bestätigen. 

Bei Überschreitung des Zeitlimits für die Antwort wird von einer Fehlfunktion der Komponente ausgegangen. Wird das Zeitlimit wiederholt in Folge überschritten, können Prozesse wie z.B. der Neustart der Komponente zur Wiederherstellung der Vitalität in die Wege geleitet werden. Die Wiederaufnahme der Funktionalität soll in jeden Fall möglich sein.

\subsubsection{Redundanz}

Um eine erfolgreiche Migration der Aktivitäten von einem System auf ein Ersatzsystem zu gewährleisten, muss die Komponente dafür konzipiert sein. Die Komponente soll auf flüchtige Datenhaltung verzichten, um den Verlust bei einer Migration in Grenzen zu halten. Es soll auf externe Ressourcen wie z.B. File Handles verzichtet werden, da die Freigabe solcher Ressourcen systemabhängig ist und somit nicht garantiert werden kann.\\\\

Sowohl das Reinitialisieren als auch die Migration eines Prozesses gibt folgende Richtlinien für die Entwicklung der Komponenten vor:

\begin{itemize}

\item Kein flüchtigen Daten

\item Verarbeitungszeiten minimieren

\item Transaktionsmodell zur Persistenzschicht

\item Keine externen Abhängigkeiten zur Laufzeit

\end{itemize}

Die PRISMA-Architektur bietet ein Datenprotokoll zur persistenten Datenhaltung mit der \texttt{DMAP}-Komponente an. \texttt{DMAP} ist eine objektorientierte, verteilte Datenbank basierend auf einer dateibasierten Datenhaltung. Die Kommunikation zwischen den Komponenten und der Datenbank ist auf einer gesicherten UDP-Schicht realisiert. Weiterhin bietet PRISMA eine Klasse zur Realisierung des Watchdog-Protokolls. Somit verlagern sich ein Großteil der Anforderungen auf die bestehende Architektur, was die Entwicklung der Komponenten erleichtert.

\subsection{Flugplandaten}

Um erfolgreich die Sprache in den Kontext Flugsicherung zu integrieren, wurden die Standardflugpläne analysiert und deren Zusammensetzung erfasst. Die einzelnen Merkmale eines Flugplans wurden mit entsprechenden Datentyp in die Syntax der Sprache aufgenommen, \cite{icao_4444}. Die Kodierung der Flugpläne basiert auf dem ASCII\footnote{American Standard Code for Information Interchange -- ein Standard zur Zeichenkodierung für u.a. das lateinische Alphabet und die arabischen Ziffern}-Zeichensatz, in den folgenden Abschnitten soll ein Zeichen bzw. Zeichenketten jeweils auf dem ASCII-Zeichensatz basieren.

\subsubsection{Aerodrome}

Der Flughafen wird in Flugplänen nach \cite{icao_4444} mit vier Buchstaben kodiert. Jedem internationalen Flughafen wird ein dedizierter Kode zugewiesen, der in den Flugplänen als Abflughafen und Zielflughafen zur Identifikation genutzt wird. Abkürzungen, die oft benutzt werden, lauten \emph{ADEP} oder \emph{DEP} für den \emph{Aerodrome of Departure} und \emph{ADES} oder \emph{DEST} für \emph{Aerodrome of Destination}. Zur Berücksichtigung der Flughäfen soll in der Sprache die Feldnamen \emph{ADEP/ADES} für Startflughafen, respektive Zielflughafen, reserviert werden. Zulässige Werte für sind Zeichenketten zusammengesetzt aus vier Buchstaben.

\subsubsection{Runway}

Die Bezeichnungen für die Start- und Ladebahnen -- Englisch \emph{Runway} -- können lokal vergeben werden und sind meist eine Kombination aus mehreren Buchstaben und darauf folgenden Zahlen, z.B. RWY01. Es sind bis zu fünf Zeichen für die Identifikation erlaubt, die Abkürzung \emph{RWY} soll das Feld in der Sprache bezeichnen.

\subsubsection{Aircraft Type}

\emph{ICAO} legt einen vierstelligen Identifikationskode für die Flugzeugtypen fest. Die Kodierung erlaubt sowohl  Buchstaben als auch Zahlen. Beispielkodierungen sind A332 für den \emph{Airbus A330-200} oder B744 für eine \emph{Boeing 747-400}. Gebräuchliche Abkürzung ist \emph{ATYP}. In der Sprache soll das Schlüsselwort \emph{ATYP} für den Flugzeugtyp reserviert sein, zulässige werden sollen alle Zeichenkette der Länge vier darstellen.

\subsubsection{Flight Type}

Der \emph{Flight Type} beschreibt den Einsatztyp des Fluges, sei es ein Passagierflug, Transportflug oder ein militärischer Einsatz. Hierfür wird ein Zeichen zur Identifizierung genutzt. Die Abkürzung hierfür ist \emph{FTYP}. Die Sprache soll als Wertemenge alle Zeichen akzeptieren.

\subsubsection{True Airspeed}

In der Luftfahrt gibt es verschiedene Möglichkeiten die Fluggeschwindigkeit eines Luftfahrzeugs zu ermitteln. Die \emph{True Airspeed} bezeichnet die Geschwindigkeit des Luftfahrzeugs relativ zu den Luftmassen, korrigiert nach den Druck- und Temperaturverhältnissen. Die abkürzende Bezeichnung lautet \emph{TAS}. Die Modellierungssprache soll den Feldnamen \emph{TAS} für diese Flugplaneigenschaft reservieren, eine natürliche Zahl dient als zulässiger Wert, die implizite Einheit ist der Knoten.

\subsection{Flussdichtenregelungen}

\label{analysis:atccl:flow_restrictions}

Eine Äquivalenzklassenanalyse der möglichen Regeln für die Definition von Flussdichten eines Fluginformationsraums ergab eine Anzahl an Regeltypen, die von der Sprache unterstützt werden mussten (siehe Abschnitt \ref{research:gcaa:flow_restrictions}). Zur erfolgreichen Definition jeder möglichen Regeln stellte sich die Boolesche Algebra als ausreichend heraus.\\\\

Die einzelnen Regelterme sind somit entweder Teilmengenrelationen oder Äquivalenz"-relationen, mehrere Regelterme können mit logischen Und- und Oder-Operatoren verknüpft werden. Die Negation dient zum Ausschluss eines Zustands, die Klammersetzung soll die gewünschte Priorität der logischen Auswertung eines Terms vorgeben.

\section{Abflugplanungskomponente}

Die Komponente soll in die PRISMA-Architektur integriert werden, wobei die Komponente als flugplanverarbeitendes Aggregat dem FDPS zugeordnet wird. Die Schnittstelle zum Gesamtsystem wird durch die DMAP gewährleistet, welche die Kommunikationsschicht für ein verteiltes objektorientiertes Datenbanksystem bildet.\\\\

Anhand eines Ereignismodells soll die Komponente auf bestimmte Dateneinträge reagieren, diese bearbeiten und zurück in das System geben. Es gibt zwei mögliche Ereignisse, die eine Bearbeitung initiieren können:

\begin{itemize}

\item Benutzeranfrage vor Startfreigabe

\item Überflüge 

\end{itemize}

Die Kommunikation mit dem Display, welches die Benutzerinteraktion mit der Komponente gewährleistet, ist ebenfalls durch die DMAP-Kommunikationsschicht entkoppelt. Die strikte Trennung der Komponenten erleichtert u.a. die unabhängige Entwicklung der beiden Module und erhält die Modularität der PRISMA-Architektur. PRISMA erlaubt es dadurch ein System je nach Wunsch des Kunden mit beliebigen Komponenten auszustatten. Auch Fremdkomponenten können integriert werden, solange diese die entsprechenden Standards, wie z.B. das Flugplanformat, unterstützen. In diesem Fall wurde das Display für die Abflugplanungskomponente unabhängig entwickelt und ist nicht Bestandteil dieser Arbeit.

Die besonderen Anforderung an die Komponente sind:

\begin{itemize}

\item Robustheit

\item Kurze Bearbeitungszeit

\item Keine Systembeanspruchung bei Inaktivität

\end{itemize}

\section{Musskriterien}

Die folgende Anforderungen sind Kernbestandteil der Komponenten:

\begin{enumerate}

\item \textbf{Dynamische Flugplanfilterung}\\

Die Abflugplanungskomponente soll anhand von Flugplandaten eine Zuordnung zu Flow Points setzen. Die Zuordnung soll anhand der Flugplaneigenschaften und der Tageszeit entschieden werden.

\item \textbf{Berechnung der optimalen Abflugzeit}\\

Die Abflugplanungskomponente soll anhand von Flugplandaten die optimale Abflugzeit, in Abhängigkeit aller Restriktionen der betreffenden Flow Points, berechnen.

\item \textbf{Zuweisung der optimalen Flugfläche}\\

Die Abflugplanungskomponente soll anhand von Flugplandaten die optimale Flugfläche, in Abhängigkeit aller Restriktionen der betreffenden Flow Points, bestimmen. Die Höhen"-staffelung soll die bevorzugte Staffelungsart der Komponente sein.

\item \textbf{Manuelle Übersteuerung}\\

Zu jeder Zeit hat der Bediener der Abflugplanungskomponente Möglichkeiten die automatisch zugewiesenen Werte zu ändern. Manuelle Änderungen sind dauerhaft und keinen weiteren automatischen Überprüfungen ausgesetzt. Manuell angepasste Einträge sollen bei nachfolgenden Berechnungen beachtet werden.

\item \textbf{Konfigurierbarkeit}\\

Die Abflugplanungskomponente soll konfigurierbar sein. Die Konfiguration soll alle mög"-lichen Staffelungskriterien der GCAA-FIR modellieren können. Die Konfiguration soll alle relevanten Flugplandaten berücksichtigen. 

\item \textbf{Transaktionsprotokollierung}\\

Alle Vorgänge der Abflugplanungskomponente sollen in persistenter Form protokolliert werden. Dies umfasst die Benutzereingaben und automatischen Wertsetzungen der Komponente. Die Protokolle sollen vollständig sein, um die Nachvollziehbarkeit aller Aktionen und Entscheidungen zu gewährleisten.

\end{enumerate}

\section{Sollkriterien}

Die folgende Anforderung \emph{sollen} berücksichtigt werden:

\begin{enumerate}

\item \textbf{Statistische Protokollierung}\\

Für jedes von der Abflugplanungskomponente erfasstes Luftfahrzeug soll ein Eintrag in einer persistenten Logdatei erstellt werden. Die Einträge sollen die Anfragezeit, die früheste Abflugzeit, die optimale Abflugzeit, die tatsächliche Abflugzeit neben einer Reihe von Flugplandaten zur eindeutigen Identifizierung des Fluges erfassen. Das Format der Logdatei soll zur statistischen Auswertung geeignet sein, z.B. CSV\footnote{Comma Separated Values -- ein einfaches Dateiformat, bei dem einzelne Dateneinträge mit einem Komma oder einem anderen Trennungszeichen separiert werden}.

\item \textbf{Fehleranalyse der Konfiguration}\\

In der Initialisierungsphase der Abflugplanungskomponente soll eine Analyse der Konfiguration stattfinden. Es sollen alle Fehler in möglichst expliziter Form dargestellt werden.

\item \textbf{Hohe Effizienz}\\

Die Abflugplanungskomponente soll unmittelbar auf Anfragen reagieren, die Kalkulationszeit soll minimal gehalten werden, sodass der Arbeitsablauf der bedienenden Personals nicht gestört wird. Die Effizienz der Komponente soll sowohl im Bearbeitungszeitraum als auch während der Inaktivität hoch sein, die Belastung auf das Gesamtsystem soll minimiert werden.

\item \textbf{Robustheit}\\

Die Abflugplanungskomponente soll sich stets in einem validen Zustand befinden. Die Komponente soll Fehlbedienung, Auftritt von fehlerhaften Daten und Berechnungsfehler korrekt behandeln und eine Fortsetzung der Funktionalität garantieren. Die Komponente soll nach den Richtlinien von IEC 61508 zur Entwicklung von Software nach SIL 2 entwickelt werden, um eine Zertifizierung zu ermöglichen.

\end{enumerate}

\section{Abgrenzungskriterien}

Die folgende Funktionalität soll \emph{nicht} realisiert werden:

\begin{enumerate}

\item \textbf{Kein Abflugmanagement auf Flughafenebene}\\

Die Abflugplanungskomponente soll Position bzw. Gate des Luftfahrzeugs, Rollzeiten oder Startbahnbelegung bei der Bestimmung von Abflugzeiten \emph{nicht} berücksich"-tigen. Die übermittelte früheste Abflugzeit soll bereits diese Details berücksichtigen -- dies ist Aufgabe des Planers.

\item \textbf{Keine globale Optimierung}\\

Die Abflugplanungskomponente soll keine Neuberechnung der Abflugzeiten und Flugflächen aller erfassten Flüge durchführen, sobald Änderungen in dem Berechnungsvektor stattfinden. Solch eine Änderung kann z.B. durch manuelle Über\-steuerung durch das Flugsicherungspersonal oder durch Abweichungen der Flugvektoren eines Verkehrsfahrzeugs entstehen. Tritt eine Abweichung von den vergebenen Slot-Zeiten ein, sodass Potential für eine Optimierung bereits vergebener Slots entsteht, sollen alle vergebenen Slots unverändert bestehen bleiben.

\item \textbf{Keine automatische Slot-Zeitenkorrektur}\\

Bedingung von 2. gilt mit folgender Änderung: durch die eintretende Abweichung von den vergebenen Slot-Zeiten entsteht Potential zur Verletzung einer Luftraumbeschränkung. Die vergebenen Slots sollen unverändert bestehen bleiben -- die Gewähr\-leistung der Einhaltung der Luftraumbeschränkung fällt in die Zuständigkeit der Fluglotsen und Luftfahrzeugführer.

\end{enumerate}

\section{Dokumentation}

Alle ermittelten Anforderungen werden in der sog. System Requirements Specification festgehalten. Das SRS ist die Basis aller folgenden Entwicklungsschritte. Es dient später zur Testfallerzeugung, da hierbei alle Anforderungen mindestens einmal abgedeckt werden müssen.

Das SRS ist das Referenzdokument für die Abnahme vor Ort und dem Kunden und muss deshalb auch vom Kunden abgenommen werden. Jede Änderung im System muss gegen die Anforderungen geprüft werden, gegebenenfalls müssen neue Anforderungen hinzugefügt werden oder alte angepasst, Beides hat zur Folge, dass eine erneute Abnahme vom Kunden fällig wird.\\\\

Im SRS wird für jede Anforderung eine Identifikationsnummer allokiert, diese wird in den weiteren Phasen des Projekts referenziert. Nach \cite{iec_61508} bildet die Dokumentation die Basis der Nachvollziehbarkeit der Entscheidungsfindung und dadurch auch die Grundlage einer erfolgreichen Zertifizierung.