implementierung hinzugefügt

lst.tex

@@ -58,4 +58,4 @@
 
 \lstdefinestyle{AST} { language=AST,style=common-style } 
 \lstdefinestyle{JRAG} { language=JRAG,style=common-style }
-\lstdefinestyle{Java} { language=Java,style=common-style }
+\lstdefinestyle{Java} { language=Java,style=common-style }
\ No newline at end of file

sections/appendix.tex

+\chapter{Code der Adapter-Implementierung}
+\lstset{
+	language=C++,
+	breaklines=true,
+	frame=single,
+	basicstyle=\ttfamily,
+	keywordstyle=\color{blue}\ttfamily,
+	stringstyle=\color{red}\ttfamily,
+	commentstyle=\color{gray}\ttfamily,
+	morecomment=[l][\color{magenta}]{\#},
+}
+\lstinputlisting{main.cpp}
\ No newline at end of file

sections/konzept.tex

@@ -29,14 +29,18 @@ Da für die Testgenerierung auch ein Modell für die Inputs des Systems nötig i
 \section{TRON Adapter}
 Channels, welche sowohl im modellierten Input als auch im System vorkommen stellen die Schnittstellen für den Adapter dar. Wird im Inputmodell ein Channel verwendet, so wird dieser sowohl im modellierten als auch im echten (oder simulierten) System über den Adapter ausgelöst. Asynchron dazu gibt das System den Output zurück an den Adapter, welcher dann mit den Gegebenheiten des Modells verglichen wird. Als built-in Adapter sind der sogenannte TraceAdapter, welcher über stdin/stdout kommuniziert, und der SocketAdapter, welcher zur Kommunikation eine TCP/IP-Verbindung aufbaut, verfügbar. Auch eigene Implementationen werden als dynamische C-Bibliothek ermöglicht. Für ROS bietet sich der SocketAdapter an, da die ROS-interne Kommunikation selbst auf TCP aufsetzt und so auch Übertragbarkeit gewährleistet wird. In \cite{Gummel2018} wird eine Erweiterung von TRON namens DTRON verwendet, um TRON für verteilte Systeme zu ermöglichen und mehrere ausgeführte Instanzen zugleich zu überprüfen. Diese Erweiterung ist zum aktuellen Zeitpunkt jedoch nicht verfügbar. Um den Adapter an da ROS-System anzuknüpfen, wird ein ROS-Node geschrieben, welcher die Pakete des Adapters annimmt und intern über die ROS Topics an das System weitergibt. Diese Übersetzung kann potentiell generisch implementiert werden, sodass zukünftig für ROS-Projekte beispielsweise nur eine Konfigurationsdatei erforderlich ist. Um die Umgebung in der Simulation auch für TRON verfügbar zu machen, müssen die dafür vorhandenen Daten folglich auch über ein ROS Topic im System veröffentlicht und dann durch den Adapter weitergereicht werden. Im Leitfaden zu TRON~\cite{TronManual} sind die verwendeten Pakete beschrieben und werden im Folgenden in den Kontext eingeordnet und erläutert wie diese verwendet werden.
 
-\subsection{Adapter-ROS-Node}
+\subsection{Adapter-Phasen}
 \subsubsection{Konfigurierungsphase}
-Zunächst wird der SocketAdapter auf eine eingehende Verbindung warten. Folglich werden Konfigurationsdaten ausgetauscht. Strings werden dabei durch ein Byte mit der Länge des Strings gefolgt von dieser Anzahl an Bytes repräsentiert. Als erstes werden die verschiedenen Channel als Input beziehungsweise Output deklariert. Dazu wird ein Paket mit dem ersten Byte 1 beziehungsweise 2 und dem Namen des jeweiligen Channels im Uppaal Modell versendet. Als Antwort empfängt der Node einen 32-Bit Integer, der die ab diesem Zeitpunkt für diesen Channel genutzte ID widerspiegelt. Ist dieser kleiner oder gleich 0, so trat ein Fehler auf. Die Fehlermeldung kann dann mittels eines Pakets ermittelt werden (erstes Byte 64, dann Fehlercode). Nach erhalten der Channel IDs werden diese genutzt um die Namen der Variablen im Uppaal Modell den Channels zuzuordnen. Als letzter Schritt der Konfigurierungsphase werden mittels der Codes 5 und 6 die Zeiteinheiten sowie der Timeout zum Beenden des Tests gesetzt. \cref{konzept:tron_konfigurierung} skizziert den fehlerfreien Ablauf dieser Phase.  Für Output-Channel müssen die dargestellten Bytecodes 1 und 3 durch 2 und 4 ersetzt werden.
+Zunächst wird der SocketAdapter auf eine eingehende Verbindung warten. Folglich werden Konfigurationsdaten ausgetauscht. Strings sind dabei durch ein Byte mit der Länge des Strings gefolgt von dieser Anzahl an Bytes repräsentiert. Als erstes werden die verschiedenen Channel als Input beziehungsweise Output deklariert. Dazu wird ein Paket mit dem ersten Byte 1 beziehungsweise 2 und dem Namen des jeweiligen Channels im Uppaal Modell versendet. Als Antwort empfängt der Node einen 32-Bit Integer, der die ab diesem Zeitpunkt für diesen Channel genutzte ID widerspiegelt. Ist dieser kleiner oder gleich 0, so trat ein Fehler auf. Die Fehlermeldung kann dann mittels eines Pakets ermittelt werden (erstes Byte 127, dann Fehlercode). Nach erhalten der Channel IDs werden diese genutzt um die Namen der Variablen im Uppaal Modell den Channels zuzuordnen. Als letzter Schritt der Konfigurierungsphase werden mittels der Codes 5 und 6 die Zeiteinheiten sowie der Timeout zum Beenden des Tests gesetzt. \cref{konzept:tron_konfigurierung} skizziert den fehlerfreien Ablauf dieser Phase.  Für Output-Channel müssen die dargestellten Bytecodes 1 und 3 durch 2 und 4 ersetzt werden.
 \begin{figure}[h]
 	\centering
 	\includegraphics[scale=.6]{./tron_konfigurierung.png}
 	\caption{Fehlerfreier Ablauf der Konfigurierung von TRON}
 	\label{konzept:tron_konfigurierung}
 \end{figure}
-\subsubsection{Ausführung}
-Nach erfolgreicher Konfiguration sendet der Node ein Byte mit dem Wert 127 um den Start des Tests anzufragen, als Antwort erhält er ein Byte mit dem Wert 0. Folglich werden Inputs und Outputs ausgetauscht, dabei bestehen die ersten 4 Byte der Nachricht aus den Channel Identifiern, worauf 2 Byte mit der Anzahl an verknüpften Variablen und schließlich die Variablen (je 4 Byte) folgen. Diese müssen dann innerhalb der ROS-Topics verbreitet werden. Als Antwort wird von beiden Seiten eine Bestätigung zurückgesendet, Inputs und Outputs können jedoch asynchron übertragen werden.
+\subsubsection{Ausführungsphase}
+Nach erfolgreicher Konfiguration sendet der Node ein Byte mit dem Wert 64 um den Start des Tests anzufragen, als Antwort erhält er ein Byte mit dem Wert 0. Folglich werden Inputs und Outputs ausgetauscht, dabei bestehen die ersten 4 Byte der Nachricht aus den Channel Identifiern, worauf 2 Byte mit der Anzahl an verknüpften Variablen und schließlich die Variablen (je 4 Byte) folgen. Diese müssen dann innerhalb der ROS-Topics verbreitet werden. Als Antwort wird von beiden Seiten eine Bestätigung zurückgesendet, Inputs und Outputs können jedoch asynchron übertragen werden.
\ No newline at end of file
+
+\subsection{Implementierung}
+Bei der Implementierung des Adapters (siehe Anhang) sind einige Unklarheiten im Handbuch zu TRON (\cite{TronManual}) aufgefallen. So werden die Bytecodes 64 (tatsächlich zum Starten verwendet) und 127 (verwendet zum Anfragen von Fehlermeldungen) vertauscht. Lokale Variablen sowie probabilistische Kanten wie in \cref{konzept:uppaal_tor} werden von TRON nicht unterstützt, im Handbuch allerdings auch nicht erwähnt. Außerdem ist bei der Übertragung der Zeit pro Zeiteinheit die Rede von zwei 32-Bit-Integer-Variablen, während TRON tatsächlich einen 64-Bit-Integer (ohne Vorzeichen) verwendet, um die Mikrosekunden einer Modell-Zeiteinheit festzulegen. Derartige Fehlinformationen sind vermutlich darauf zurückzuführen, dass Uppaal sowie TRON selbst Updates erhielten, ohne dass das Handbuch angepasst wurde.\\
+Der Adapter wurde für eine möglichst generisch gehalten und ist somit für sämtliche Nachrichten die innerhalb von ROS Topics ausgetauscht werden verwendbar. Einem Channel des Modells lassen sich beliebig viele Topics zuweisen und umgekehrt. Templates ermöglichen generische Callbacks für beliebige Klassen von Nachrichten, bei denen vorher definierte Abbildungen benutzt werden, welche neben der Channel-Topic-Abhängigkeit auch Variablen übertragen und wenn nötig, transformieren können. Es sind allerdings sowohl für die Transformation von Variablen als auch für die Callbacks eigene Implementierungen möglich. Eine genauere Anleitung für die Benutzung des Adapters erfolgt zu einem späteren Zeitpunkt.
\ No newline at end of file