diff --git a/sections/appendix.tex b/sections/appendix.tex
index 59d0d37aa2a506910727e0493ca6f2d10991abfc..42e08a5425b2a4c94dcd65fdd55e4aba41731d8f 100644
--- a/sections/appendix.tex
+++ b/sections/appendix.tex
@@ -1,11 +1,11 @@
-\chapter{Git-Repositorys}
+\chapter{Git-Repositorys}\label{git-repos}
 Das Repository für die actionlib-Integration sowie für das Testen des Cobots sind unter folgenden Links erreichbar:
 \begin{itemize}
 	\item \url{https://git-st.inf.tu-dresden.de/CS/actionlib_tron}
 	\item \url{https://git-st.inf.tu-dresden.de/CS/cobot1_tron_testing}
 \end{itemize}
 Die Adapter-Implementierung und jeweils genutzten Uppaal-Modelle (als XML-Datei) sind in beiden Fällen vorhanden. Beim Cobot sind außerdem die für die Test-Ausführung und -Analyse genutzten Bash-Scripts zu finden.
-\chapter{Header der Adapter-Implementierung}
+\chapter{Header der Adapter-Implementierung}\label{header}
 \lstset{
 	escapeinside={(@*}{*@)}
 }
diff --git a/sections/einleitung.tex b/sections/einleitung.tex
index 389f8ae18b50e47341ecd9c0fb7438da9134565c..2ec79511c963c2c8adcb32547e1af3effc06473c 100644
--- a/sections/einleitung.tex
+++ b/sections/einleitung.tex
@@ -25,6 +25,6 @@ In diesem Abschnitt wird nach einer Einleitung in das Thema und die gestellten A
 Die Grundlagen werden dafür im zweiten Kapitel geschaffen, indem zuerst ein kurzer Überblick über wichtige Begriffe und Klassifikationen im Rahmen der Testentwicklung gegeben wird. 
 Folgend ist für jedes aus der Literatur ermittelte Kriterium des Testens von Robotiksystemen ein Abschnitt vorhanden, welcher dieses näher erläutert und gegebenenfalls in weitere Kriterien unterteilt. Am Ende dieser Auflistung sind die Anforderungen in einer Übersicht dargestellt. Als Nächstes wird erläutert, wie sich Simulationen nutzen lassen, um das Erfüllen einiger der gefundenen Anforderungen zu erleichtern, und die zwei zentralen Arten der Simulation von cyber-physischen Systemen präsentiert. Der nächste Abschnitt beschreibt kurz den heutzutage vorhandenen Standard für Softwaretests, bevor genauer auf Konzepte der Testentwicklung eingegangen wird. Dabei ist zunächst das hierarchische Testmodell zu nennen, da dieses aktuell sehr breit eingesetzt wird und auch in ROS integriert ist. Ein besonderer Fokus liegt auf dem modellbasierten Testen, welches im Rest der Arbeit verwendet wird.\\
 Das dritte Kapitel stellt verschiedene Tools vor, die heutzutage für die ausgewählte Testmethode genutzt werden. Da Uppaal mit seiner Erweiterung TRON als zu evaluierende Toolchain selektiert wurde, ist dieses genauer beschrieben.\\
-Im Konzept ist die Simulationsauswahl und Modellierung dargestellt. Für die Verwendung von TRON wird erläutert, wie das Testen erfolgen kann. Dann ist angegeben wie ein entsprechender Adapter implementiert wurde und genutzt werden kann um Ereignisse innerhalb von ROS verfolgen und so testen zu können, bevor ein kurzer Ausblick auf das nächste Kapitel gegeben wird.\\
+Im Konzept ist die Simulationsauswahl und Modellierung dargestellt. Für die Verwendung von TRON wird erläutert, wie das Testen erfolgen kann. Dann ist angegeben wie ein entsprechender Adapter implementiert wurde und genutzt werden kann um Ereignisse innerhalb von ROS verfolgen und so das System testen zu können, bevor ein kurzer Ausblick auf das nächste Kapitel gegeben wird.\\
 Darin erfolgt erst eine Überprüfung der Integrierbarkeit des entwickelten Adapters in ein actionlib-Projekt. Die actionlib ist ein innerhalb von ROS häufig verwendetes Mittel zur Kommunikation und daher essenziell für ein Testkonzept welches die ROS-internen Nachrichten verfolgt. Da diese Integration erfolgreich ist, wird dann zu einem tatsächlichen Projekt des Lehrstuhls, dem Cobot, übergegangen. Dieser soll zukünftig in der Lage sein, mit einer Flasche, einem Glas und auch Flüssigkeiten sicher umgehen zu können. Zum Testen findet eine formale Analyse des Systems statt, woraufhin ein Modell entwickelt und folglich mitsamt einer Adapter-Konfiguration an die Gegebenheiten von ROS angepasst wird. Dann werden Tests ausgeführt und die Ergebnisse analysiert.\\
 Im folgenden Kapitel wird eine Evaluation der Testmethodik durch die eingangs ermittelten Anforderungen umgesetzt und das letzte Kapitel fasst schließlich die Ergebnisse dieser Arbeit zusammen.
diff --git a/sections/evaluation.tex b/sections/evaluation.tex
index d41d66f5a03ee6fa6a0ddaa087ec330f290cb983..ca49cd43fc03d37795e1a3b0c7f860d42396c250 100644
--- a/sections/evaluation.tex
+++ b/sections/evaluation.tex
@@ -17,6 +17,6 @@ Bezüglich der Ausführbarkeit ist festzuhalten, dass eine einfache Automatisier
 Uppaal und TRON selbst bieten praktisch keine Möglichkeit zur automatisierten Analyse von ausgeführten Testfällen. Dennoch ist eine gute Analysierbarkeit gegeben, wenn alle dafür nötigen Variablen im Uppaal-Modell vorhanden sind. Die von TRON erstellten Log-Dateien können in ihrer Ausführlichkeit angepasst werden und dann durch einfache Batch-Skripts durchsucht und wichtige Informationen zusammengetragen werden. Dies ermöglichte im Fallbeispiel das Finden möglicher Gründe in jedem Fehlerfall, sorgte aber auch für einen relativ hohen Speicherbedarf, da die Log-Datei beinahe jeder Testausführung über 20MB in Anspruch nahm.
 \subsection{Akkuratheit}
 Die Akkuratheit ist wieder zu einem Großteil durch die Simulation bestimmt. Gazebo ist dabei wie in \cref{konzept:simulation} beschrieben, verglichen mit anderen Simulationen, als gut einzustufen. Probleme mit zum Beispiel weichen Materialien oder Flüssigkeiten sind jedoch vorhanden, sodass in diesen Fällen eventuell eine andere Simulation in Betracht gezogen werden sollte.\\
-Das echte Einsatzumfeld des Cobots ist mir nicht bekannt, daher kann ich dazu wenige Aussagen treffen. Offensichtlich ist jedoch, dass die Objekte in der verwendeten Simulation Quader waren, was echte Gläser und Flaschen jedoch selten sind. Neben der Simulation lässt sich also nur erneut darauf hinweisen, dass Modelle möglichst präzise den Gegebenheiten der echten Welt folgen sollten.
+Das echte Einsatzumfeld des Cobots ist mir nicht bekannt, daher lassen sich dazu keine Aussagen treffen. Offensichtlich ist jedoch, dass die Objekte in der verwendeten Simulation Quader waren, was echte Gläser und Flaschen jedoch selten sind. Neben der Simulation lässt sich also nur erneut darauf hinweisen, dass Modelle möglichst präzise den Gegebenheiten der echten Welt folgen sollten.
 \subsection{Sicherheit}
-Die Sicherheit ist durch die Simulation vollkommen gewährleistet. Eine Überwachbarkeit des Testablaufs ist somit nicht nötig und würde lediglich die Automatisierbarkeit der Testausführung einschränken. Wegen der in \cref{grundlagen:simulationen:hil} aufgezählten Gründe sind HIL-Simulationen im Fallbeispiel nicht sinnvoll gewesen und ließe sich mit der vorgestellten Methode wie bereits erwähnt auch nur schwer implementieren. 
\ No newline at end of file
+Die Sicherheit ist durch die Simulation vollkommen gewährleistet. Eine Überwachbarkeit des Testablaufs ist somit nicht nötig und würde lediglich die Automatisierbarkeit der Testausführung einschränken. Wegen der in \cref{grundlagen:simulationen:hil} aufgezählten Gründe sind HIL-Simulationen im Fallbeispiel nicht sinnvoll gewesen und ließen sich mit der vorgestellten Methode wie bereits erwähnt auch nur schwer implementieren. 
\ No newline at end of file
diff --git a/sections/fallbeispiel.tex b/sections/fallbeispiel.tex
index 5f3cd816d0af7f7755fff25df3de04410f047501..fac67f4ba1b385325a1a80777b44a56299520f0f 100644
--- a/sections/fallbeispiel.tex
+++ b/sections/fallbeispiel.tex
@@ -22,6 +22,7 @@ Das entsprechend erstellte Uppaal-Modell ist in \cref{integration:uppaal} zu seh
 	\label{integration:uppaal}
 \end{figure}
 Der Einsatz des Adapters erfolgt unter Verwendung von eigens für die Nachrichtentypen implementierten Callbacks statt der Zuweisung von Bytes. Dadurch können andere Bestandteile des Action-Protokolls wie die Header vernachlässigt werden. Weiterhin ist zu beachten, dass im Adapter die Nachrichten verwendet werden, die \textbf{Action} im Namen tragen (z.B. TriggerActionGoal, nicht TriggerGoal). Diese Nachrichten beinhalten neben den Daten auch Header- und Statusinformationen und müssen verwendet werden, wenn der Adapter selbst weder Client noch Server des Systems ist, sondern ersteren nur emuliert oder die Kommunikation beider Parteien abhört. Eine Implementierung des Adapters, welcher selbst einen Client darstellt, wäre allerdings auch möglich. Die Namen der Topics sind aus dem Namen des Servers (wird bei Konstruktion übergeben) und dem Inhalt der Nachricht zusammengesetzt und können daher ohne Probleme verwendet werden. Die (nicht vollständige) Konfigurationsphase für den Adapter des in \cref{integration:uppaal} gezeigten Modells sieht wie folgt aus:
+\\
 \begin{lstlisting}[tabsize=1]
 	// oeffnen und schliessen stellt jeweils ein Ziel dar
 	Mapping map = adapter.createMapping("/garage_server/goal", "oeffnen", true);
@@ -53,12 +54,12 @@ Die hier verwendeten Callbacks \textit{send\_goal\_open(/close)} rufen die Funkt
 	}
 \end{lstlisting}
 Es lässt sich hinzufügen, dass beim Versenden eines Ziels (oder einer sonstigen Nachricht) vom (hier emulierten) Client keine Felder im Header wie zum Beispiel die Identifikationsnummer dieses Zieles gesetzt werden müssen, da der Server diese beim Empfangen der Nachricht entsprechend ausfüllt, sollten sie leer sein. Die Identifikationsnummer ist für den Client wichtig, um einen bestimmten Auftrag abzubrechen und sollte folglich in diesem Fall von ihm gesetzt werden. Die Funktion \textit{feedback\_callback} gibt lediglich die aktuelle Position an TRON weiter. Da im Uppaal-Modell keine Angaben zur Zeit vorhanden sind, kann die Zeiteinheit in diesem Fall frei gewählt werden. Der Test-Timeout sollte so gewählt sein, dass mehrere Zyklen durchlaufen werden können und ist daher abhängig von der Zeit, die der Server zum Bewältigen der Aufgabe benötigt.
-Die vollständige Implementierung des actionlib-Servers und -Clients sowie des verwendeten TRON-Adapters sind in einem Git-Repository vorhanden (siehe Anhang).
+Die vollständige Implementierung des actionlib-Servers und -Clients sowie des verwendeten TRON-Adapters sind in einem Git-Repository vorhanden (siehe \cref{git-repos}).
 
 \section{Cobot}
 Mit der Möglichkeit zur Verwendung der actionlib kann nun ein tatsächliches Testszenario angegangen werden. Dazu wird zunächst die Aufgabe des Systems überprüft und formale Bedingungen zur Ausführung festgehalten. Dabei wurde der Cobot mehrfach simuliert sowie der Code der Implementierung überflogen, um einen Eindruck vom Systemverhalten zu bekommen.
 \subsection{Formales Modell}\label{cobot:formales_modell}
-Als Erstes lässt sich feststellen, dass der Cobot, nachdem er seine Startposition angenommen hat, wartet bis er ein Signal von einem Drucksensor erhält woraufhin er zu arbeiten beginnt. Nach diesem Signal bewirken weitere Eingaben nichts, wodurch das System als Sequenz modelliert werden kann.
+Als Erstes lässt sich feststellen, dass der Cobot, nachdem er seine Startposition angenommen hat, wartet bis er ein Signal von einem Drucksensor erhält, woraufhin er zu arbeiten beginnt. Nach diesem Signal bewirken weitere Eingaben nichts, wodurch das System als Sequenz modelliert werden kann.
 Am Anfang wird eine Anzahl an Versuchen festgelegt, die der Roboter beim Aufheben und Hinstellen von Objekten durchführt, bevor die Ausführung als fehlgeschlagen gilt und das System herunterfährt. Dann bewegt sich der Roboter zur Flasche (wie das Glas in der Simulation als Block dargestellt) und hebt diese auf. Dabei ist wichtig, dass nach dem Aufnehmen die Flasche in einem aufrechten Zustand gehalten wird, um ein Verschütten der (in Simulation nicht vorhandenen) Flüssigkeit zu verhindern. Dann bewegt der Roboter die Flasche neben das Glas und beginnt sie in Richtung des Glases zu kippen. Dabei wird die Beschränkung der Orientierung temporär aufgehoben, bis das Wiederaufrichten durchgeführt wurde und die Flasche wieder an ihre ursprüngliche Position gebracht werden kann. Nach dem Abstellen der Flasche wird das Glas angehoben. Der Weg zum Glas unterliegt wieder keinerlei Beschränkungen, während bei angehobenem Glas dieses aufrecht gehalten werden muss, bis es auf der anderen Seite abgestellt wurde, woraufhin sich der Roboterarm wieder in seine Startposition begibt. Beim Abstellen ist ein zusätzlicher Fallback integriert, der dafür sorgt, dass beim Fehlschlagen des Platzierens am Ziel das Glas wieder an seine Ursprungsposition gebracht und neu aufgehoben wird. Dies geschieht wie die einzelnen Versuche auch so oft wie am Anfang festgelegt. Dabei wird im Modell keine Aktualisierung der Orientierungsbeschränkung vorgenommen, da diese nach dem Abstellen zwar entfernt, aber durch das sofortige Wiederaufheben unmittelbar wieder hinzugefügt wird.
 Das aus diesen Angaben erstellte Modell ist in \cref{cobot:formales_modell_bild} dargestellt.\\
 \begin{figure}[h]
@@ -80,7 +81,7 @@ Der Uppaal Verifier kann mit der Anfrage \textit{A<> deadlock} (jeder Pfad führ
 
 \subsection{Topics, Adapter und Modellanpassungen}
 Als Nächstes müssen ROS-Topics identifiziert werden, die die benötigten Informationen transportieren. Dazu eignet sich das Tool \textit{rostopic}\footnote{\url{http://wiki.ros.org/rostopic}}, mit welchem sich alle aktiven Topics auflisten und deren Nachrichten abhören lassen.\\
-Für den initialen Impuls des Drucksensors ist bereits ein Topic vorhanden und wird vom Cobot verwendet, kann also auch als Output vom Adapter benutzt werden. Dabei lässt sich direkt die Anzahl an erneuten Versuchen vor einem Abbruch übertragen, da diese in einer Konfigurationsdatei des Systems festgelegt wird und daher in der Konfigurationsphase des Adapters ausgelesen werden kann. In dieser Konfigurationsdatei sind auch die Startposition der Flasche sowie die Start- und Zielposition des Glases hinterlegt, sodass auch diese im Adapter gehalten werden können. Das Speichern sowie Vergleichen der Positionen von Flasche und Glas muss im Adapter erfolgen, da Uppaal TRON keine Gleitkommazahlen beim Testen unterstützt. Gazebo veröffentlicht regelmäßig über \textit{/gazebo/link\_states} und \textit{/gazebo/model\_states} die aktuellen Positionen in der Simulationsmodelle, welche folglich mit den Gewünschten verglichen und die Ergebnisse als Differenz an TRON weitergegeben werden können. Anzumerken ist, dass für jede Differenz ein eigener Channel in Uppaal existiert. Dies ist nötig da eine einzelne Kante, welche alle Werte aktualisiert, dazu führen würde, dass Uppaal alle Kombinationen dieser als mögliche Outputs berechnet, was zu exponentiell erhöhter Rechenzeit führt (\textit{State Explosion}). Die Simulationssoftware beginnt vor dem Initialisieren der Objekte bereits mit dem Veröffentlichen von Nachrichten, sodass vom Adapter mit dem Weitergeben an TRON gewartet wird, bis die Objekte initialisiert wurden. Außerdem wird beim Berechnen der Orientierungsabweichung eine Drehung um die z-Achse (senkrecht zur Szene) ignoriert, da diese für ein Aufrechtstehen nicht relevant ist.
+Für den initialen Impuls des Drucksensors ist bereits ein Topic vorhanden und wird vom Cobot verwendet, kann also auch als Output vom Adapter benutzt werden. Dabei lässt sich direkt die Anzahl an erneuten Versuchen vor einem Abbruch übertragen, da diese in einer Konfigurationsdatei des Systems festgelegt wird und daher in der Konfigurationsphase des Adapters ausgelesen werden kann. In dieser Konfigurationsdatei sind auch die Startposition der Flasche sowie die Start- und Zielposition des Glases hinterlegt, sodass auch diese im Adapter gehalten werden können. Das Speichern sowie Vergleichen der Positionen von Flasche und Glas muss im Adapter erfolgen, da Uppaal TRON keine Gleitkommazahlen beim Testen unterstützt. Gazebo veröffentlicht regelmäßig über \textit{/gazebo/link\_states} und \textit{/gazebo/model\_states} die aktuellen Positionen in der Simulationsmodelle, welche folglich mit den Gewünschten verglichen und die Ergebnisse als Differenz (gerundet) an TRON weitergegeben werden können. Anzumerken ist, dass für jede Differenz ein eigener Channel in Uppaal existiert. Dies ist nötig da eine einzelne Kante, welche alle Werte aktualisiert, dazu führen würde, dass Uppaal alle Kombinationen dieser als mögliche Outputs berechnet, was zu exponentiell erhöhter Rechenzeit führt (\textit{State Explosion}). Die Simulationssoftware beginnt vor dem Initialisieren der Objekte bereits mit dem Veröffentlichen von Nachrichten, sodass vom Adapter mit dem Weitergeben an TRON gewartet wird, bis die Objekte initialisiert wurden. Außerdem wird beim Berechnen der Orientierungsabweichung eine Drehung um die z-Achse (senkrecht zur Szene) ignoriert, da diese für ein Aufrechtstehen nicht relevant ist.
 Diese Aspekte schränken zwar das Modell ein und machen eine Auslagerung von Logik in den Adapter notwendig, sorgen aber gleichzeitig dafür, dass das Modell abstrakt bleibt und nicht zu detailliert wird.
 Um die Positionen der Objekte im Uppaal-System festzuhalten wurde je ein separates Modell, zu sehen in \cref{cobot:positionen_modell_bild} (analog für Flasche) hinzugefügt, welches durch das Topic \textit{/gazebo/link\_states} aktualisiert wird und globale Variablen setzt, die das Modell des Cobots verwendet, um festzustellen, ob sich das Objekt an der richtigen Position befindet. Dabei musste auch darauf geachtet werden, dass fehlgeschlagene Versuche passend dargestellt sind, es existiert also für jeden Zustand eine Kante zu seinem Vorgänger. Zum Startzustand kann allerdings nur zurückgegangen werden, wenn das Objekt nicht gleichzeitig im Endzustand ist, um ein fälschliches Zurückgehen zu verhindern. Es existiert keine Kante direkt vom Start- zum Endzustand, sodass das Objekt mindestens einmal seine Position verlassen muss.\\
 \begin{figure}[h]
@@ -93,9 +94,9 @@ Für das Platzieren und Aufheben von Objekten sowie die Bewegungsplanung wird vo
 Für das Verfolgen von Bewegungen, welche bei der Bewegung zur Flasche, zum Glas und beim Einfüllen relevant sind, wird das Topic \textit{/follow\_joint\_trajectory/result} des \textit{position\_joint\_trajectory\_controller} genutzt. Außerdem ist eine Bewegung nach dem Fehlschlagen des Platzierens vom Glas eingefügt worden, da diese hier hinzugefügt wurde, um Abstand zu gewinnen, bevor ein weiterer Versuch ausgeführt wird.
 Die restlichen Bewegungen (bis auf die zur Startposition des Roboters) sind als Teilvorgänge des Platzierens und Aufhebens anzusehen, da sie an sich keine essenzielle Funktion des Cobots darstellen und sind daher nicht explizit im Modell angegeben.
 Da logischerweise auch das Platzieren und Aufheben von Objekten Bewegungen des Arms beinhaltet, müssen bei entsprechenden Knoten im Modell zusätzliche Kanten eingefügt werden, die zum Knoten selbst zurückführen und dabei eine (nicht-) erfolgreiche Ausführung durch einen Channel abfragen. Dies ist nötig, da TRON sonst einen Fehler aufgrund von nicht erwartetem Output ausgibt. Diese Kanten sorgen dafür, dass die in \cref{cobot:formales_modell} beschriebene Validierung nicht ohne Weiteres so verwendet werden kann, da nun Endlosschleifen möglich sind. Dies könnte beispielsweise durch einen Zähler mit einer (unrealistisch hohen) maximalen Anzahl an Bewegungen und eine Deklarierung von allen Channels als \textit{urgent} realisiert sein, wird jedoch hier nicht vorgenommen, um das Modell übersichtlicher zu halten.\\
-Für die Orientierungsbeschränkung beim Bewegen kommen nur Topics, die ein Ziel festlegen (\textit{/move\_group/goal}, \textit{/pickup/goal}, \textit{/place/goal}) infrage, da nur in diesen Nachrichten eine solche Beschränkung übergeben wird und eine Überprüfung von bereits berechneten Bewegungsbahnen aufwendig wäre. Anzumerken ist hier, dass das Einhalten einer gegebenen Beschränkung genauso wie das Aufheben oder die Bewegungen selbst nicht Teil des Tests darstellen, sondern auf den niedrigeren Testebenen (Unit-Tests oder Integrations-Tests) getestet werden müssen. Daher wird hier nur überprüft, ob eine Orientierungsbeschränkung festgelegt ist. Auch hier wäre ein Abgleich mit einer gewünschten Orientierung innerhalb des Adapters möglich, diese ist jedoch hier nicht zwingend nötig, da eine falsche Orientierung bei einer Simulation extrem auffällig wäre und daher hier ausgeschlossen werden kann. Bei genauerer Analyse des Cobots sind weitere Bewegungsbeschränkungen wie etwa bei der Beschleunigung aufgefallen, diese würden dem gleichen Schema folgen.\\
-Da innerhalb von jedem Modell-Zustand Nachrichten an \textit{goal} gesendet werden, für das Testen allerdings nur eine Änderung bei der Orientierungsbeschränkung relevant ist, wird in das Uppaal-System ein weiteres Modell integriert, welches Outputs an den entsprechenden Channel entgegennimmt, wenn keine Änderung erfolgte. Das gleiche Prinzip wird ebenfalls auf andere Channel angewandt, welche zu jedem Zeitpunkt aktiviert werden können.\\
-Das endgültige Testmodell für den Cobot (ohne die zusätzlich verwendeten Modelle, siehe Anhang) ist in \cref{cobot:modell_bild} abgebildet.
+Für die Orientierungsbeschränkung beim Bewegen kommen nur Topics, die ein Ziel festlegen (\textit{/move\_group/goal}, \textit{/pickup/goal}, \textit{/place/goal}) infrage, da nur in diesen Nachrichten eine solche Beschränkung übergeben wird und eine Überprüfung von bereits berechneten Bewegungsbahnen aufwändig wäre. Anzumerken ist hier, dass das Einhalten einer gegebenen Beschränkung genauso wie das Aufheben oder die Bewegungen selbst nicht Teil des Tests darstellen, sondern auf den niedrigeren Testebenen (Unit-Tests oder Integrations-Tests) getestet werden müssen. Daher wird hier nur überprüft, ob eine Orientierungsbeschränkung festgelegt ist. Auch hier wäre ein Abgleich mit einer gewünschten Orientierung innerhalb des Adapters möglich, diese ist jedoch nicht zwingend nötig, da eine falsche Orientierung bei einer Simulation extrem auffällig wäre und daher hier ausgeschlossen werden kann. Bei genauerer Analyse des Cobots sind weitere Bewegungsbeschränkungen wie etwa bei der Beschleunigung aufgefallen, diese würden dem gleichen Schema folgen.\\
+Da innerhalb von jedem Modell-Zustand Nachrichten an \textit{goal} gesendet werden können, für das Testen allerdings nur eine Änderung bei der Orientierungsbeschränkung relevant ist, wird in das Uppaal-System ein weiteres Modell integriert, welches Outputs an den entsprechenden Channel entgegennimmt, wenn keine Änderung erfolgte. Das gleiche Prinzip wird ebenfalls auf andere Channel angewandt, welche zu jedem Zeitpunkt aktiviert werden können.\\
+Das endgültige Testmodell für den Cobot (ohne die zusätzlich verwendeten Modelle, siehe \cref{git-repos}) ist in \cref{cobot:modell_bild} abgebildet.
 \begin{figure}[h]
 	\centering
 	\includegraphics[scale=.22, angle=90]{./cobot1.png}
@@ -104,7 +105,7 @@ Das endgültige Testmodell für den Cobot (ohne die zusätzlich verwendeten Mode
 \end{figure}
 
 \subsection{Testausführung}\label{cobot:testausfuehrung}
-Zur Ausführung wurde ein simples Bash-Script geschrieben, welches zuerst einen build für das Projekt ausführt und dann eine beliebige Anzahl an Tests startet. Dabei werden die Tests sequentiell ausgeführt, indem zunächst TRON und schließlich eine roslaunch-Datei gestartet wird. In dieser Datei ist das Starten der Simulation und nötigen ros-Nodes, inklusive des Test-Adapters, geregelt. Mittels dem Argument \textit{gui} (und dem Wert \textit{false}) wird Gazebo \textit{headless} gestartet, sodass die Tests problemlos im Hintergrund ablaufen können. TRON ermöglicht das Festhalten der Ergebnisse in Textdateien (siehe \cite{TronManual}). Das Tool eine Testausführung ab, wenn ein Fehler auftritt oder der im Adapter festgelegte Timeout abläuft. Da das System nicht unendlich läuft und ein Erfolg mittels der Zustände \textit{finished\_success} und \textit{shut\_down} kodiert ist, kann ein erfolgreicher Test vor dem Timeout beendet werden. Dazu wurde ein weiterer Channel \textit{test\_done} deklariert, welcher beim Übergang in diese Zustände auslöst und als Input dient, auf welchen der Adapter mit einer von TRON nicht erwarteten Ausgabe reagiert (Channel \textit{intentional\_fail}). Dadurch können bei gleichbleibender Zeit deutlich mehr Tests durchgeführt werden, wenn in Kauf genommen wird, dass nach dem im Modell spezifizierten Verhalten keine weitere Überprüfung stattfindet.
+Zur Ausführung wurde ein simples Bash-Script geschrieben, welches zuerst einen build für das Projekt ausführt und dann eine beliebige Anzahl an Tests startet. Dabei werden die Tests sequentiell ausgeführt, indem zunächst TRON und schließlich eine roslaunch-Datei gestartet wird. In dieser Datei ist das Starten der Simulation und nötigen ros-Nodes, inklusive des Test-Adapters, geregelt. Mittels dem Argument \textit{gui} (und dem Wert \textit{false}) wird Gazebo \textit{headless} gestartet, sodass die Tests problemlos im Hintergrund ablaufen können. TRON ermöglicht das Festhalten der Ergebnisse in Textdateien (siehe \cite{TronManual}). Das Tool bricht eine Testausführung ab, wenn ein Fehler auftritt oder der im Adapter festgelegte Timeout abläuft. Da das System nicht unendlich läuft und ein Erfolg mittels der Zustände \textit{finished\_success} und \textit{shut\_down} kodiert ist, kann ein erfolgreicher Test vor dem Timeout beendet werden. Dazu wurde ein weiterer Channel \textit{test\_done} deklariert, welcher beim Übergang in diese Zustände auslöst und als Input dient, auf welchen der Adapter mit einer von TRON nicht erwarteten Ausgabe reagiert (Channel \textit{intentional\_fail}). Dadurch können bei gleichbleibender Zeit deutlich mehr Tests durchgeführt werden, wenn in Kauf genommen wird, dass nach dem im Modell spezifizierten Verhalten keine weitere Überprüfung stattfindet.
 
 \subsection{Testergebnisse}
 Die in \cref{cobot:testausfuehrung} beschriebene Methode wurde angewandt, um das Modell 100 mal auszuführen und Log-Dateien anzulegen. Folglich konnte erneut ein Bash-Skript genutzt werden, um die Testergebnisse zu analysieren. Da lediglich ein Zustand erreicht werden muss, um den Test erfolgreich abzuschließen, reicht es in diesem Fall nach einem entsprechenden Zustand im Log zu suchen. Wird kein Endzustand erreicht, so kann der Testfall als fehlgeschlagen eingestuft und weiter untersucht werden.\\
@@ -115,7 +116,7 @@ Mithilfe der protokollierten Abstände von Positionen und Orientierungen sowie d
 In 27 Fällen war die Flasche zu mindestens einem Zeitpunkt mehr als 110 Grad geneigt, sodass wahrscheinlich kurz vor oder bei der vollen Neigung der Flasche diese verloren ging. Davon wurde in 3 Fällen auch das Glas umgeworfen. Die restlichen 15 mal fiel die Flasche vermutlich eher, da hier keine 110 Grad bei der Orientierungsdifferenz erreicht wurde. Einmal war die Flasche dabei mehr als 2 Meter von seiner Startposition entfernt, was bei dem Tempo der Bewegungen des Roboters äußerst unwahrscheinlich wirkt und vielleicht durch einen Bug (in der Simulation) verursacht wurde. \\
 Nach dem erfolgreichen Befüllen kam es in zwei Fällen zum Umwerfen des Glases beim Aufheben dieses. Weitere zwei Fälle wurde es kurz angehoben und fiel scheinbar zurück in seine Startposition.\\
 Die übrig gebliebenen Testfälle lassen sich unter anderem auf die Planung von Bewegungen zurückführen. So hielt das System je einmal im Zustand \textit{stepping\_back} und \textit{goto\_last\_state\_before\_shutdown}, welche beide auf das Fehlschlagen vom Platzieren des Glases folgen, um den nächsten Platzierungsversuch von einer (leicht) anderen Position auszuführen. Bei genauerer Inspektion des Codes fiel auf, dass an dieser Stelle ein Fehlschlagen der Bewegungsplanung nicht verarbeitet wird, was die Fehlerquelle darstellen könnte.\\
-Die letzten 3 Testausführungen sind (vermutlich) vom eigentlichen System unabhängig aufgetretene Fehler. Zwei mal wurde im Zustand \textit{in\_start\_pos} ein Update von Positionen der Simulation empfangen, was für TRON zu spät war, da als Nächstes der Übergang zu \textit{finished\_success} aufgrund des urgent Channels \textit{asap} hätte stattfinden sollen. Da an diesem Punkt aber bereits die Ausführung des Systems beendet war und sich sowohl die Flasche als auch das Glas an den richtigen Positionen befanden, sind diese Fälle als erfolgreiche Systemausführung zu werten und es sollte eine Korrektur auf diese fehlerhafte Modellierung folgen. Beispielsweise könnten die Channels, welche Positionsupdates empfangen, ebenfalls als urgent gekennzeichnet werden.\\
+Die letzten 3 Testausführungen sind (vermutlich) vom eigentlichen System unabhängig aufgetretene Fehler. Zwei mal wurde im Zustand \textit{in\_start\_pos} ein Update von Positionen der Simulation empfangen, was für TRON zu spät war, da als Nächstes der Übergang zu \textit{finished\_success} aufgrund des urgent Channels \textit{asap} hätte stattfinden sollen. Da an diesem Punkt aber bereits die Ausführung des Systems beendet war und sich sowohl die Flasche als auch das Glas an den richtigen Positionen befanden, sind diese Fälle als erfolgreiche Systemausführung zu werten und es sollte eine Korrektur auf diese fehlerhafte Modellierung folgen. Beispielsweise könnten die Channel, welche Positionsupdates empfangen, ebenfalls als urgent gekennzeichnet werden.\\
 Der letzte Fehler konnte in der Konfiguration des Adapters identifiziert werden. Im Zustand \textit{move\_to\_glass} wurde eine Nachricht ohne Orientierungsbeschränkung empfangen, was nur auftreten konnte, da für den Channel \textit{goal}, welcher diese Beschränkung übermittelt, mehrere Topics zuständig sind, sodass in der Queue des Subscribers für eines dieser Topics noch eine Nachricht vorhanden war, in der keine Beschränkung besteht, während eine andere mit dieser (von einem anderen Topic)  bereits verarbeitet war. Das Auftreten eines solchen Fehlers ist als sehr selten einzustufen und könnte verhindert werden, indem etwa nur die letzte Nachricht der drei Topics an TRON weitergegeben wird.\\
 Insgesamt ist festzustellen, dass eine Verbesserung des Befüllvorgangs mit Abstand am relevantesten zur Fehlerreduzierung ist. Aufgrund der hohen Anzahl dieser Fehler ist zu vermuten, dass es Probleme bei der Simulation des Festhaltens gibt.
 Außerdem sollte das Fehlschlagen von Planungen der Bewegungen immer beachtet und entsprechend damit umgegangen werden. Schließlich könnte das Aufheben und Platzieren von Objekten zuverlässiger gestaltet werden. Unabhängig vom zu testenden System sind auch Fehler im Modell und Adapter aufgefallen, welche jedoch relativ simpel entfernt werden können. Eine kompakte Auflistung aller Testergebnisse ist in \cref{cobot:testergebnisse:tabelle} zu sehen.
diff --git a/sections/grundlagen.tex b/sections/grundlagen.tex
index dd6820f228dd60bc76bcf31665f7be8f7c22a478..9d110c0d0c49f2b2c5e8271f1fd1839be8ded4a1 100644
--- a/sections/grundlagen.tex
+++ b/sections/grundlagen.tex
@@ -11,7 +11,7 @@ Um festzustellen, welche Methoden und Technologien sich zum Testen von Robotiksy
 \subsection{Abdeckung und Vollständigkeit}
 Da der Sinn des Testens auch darin besteht Verlässlichkeit zu garantieren und zu überprüfen, ob sämtliche gestellte Ansprüche erfüllt sind, ist es nötig, dass möglichst viele (im Idealfall alle) Situationen getestet werden, in denen sich das System befinden kann. Ein Robotiksystem ist heutzutage zu umfangreich um alle möglichen Situationen zu testen, das System kann viele Inputs beinhalten und jede Interaktion sowie (kleine) Veränderung in der Umgebung könnte einen weiteren Testfall darstellen. Daher müssen zwangsweise Testfälle selektiert werden \cite{Bihlmaier2014}, woraus folgt, dass die Testmethodik ein Verfahren beinhalten sollte, mit dem festgestellt werden kann, wie gut die Anforderungen an das System mit den genutzten Tests abgedeckt werden. Besonders bei cyber-physischen Systemen ist dieser Punkt eine Herausforderung, da neben den funktionalen Anforderungen auch nicht-funktionale (oder extra-funktionale) wie beispielsweise die Temperatur überprüft werden müssen. Die Umwelt spielt in Bezug auf cyber-physische Systeme aufgrund der starken Kontextabhängigkeit eine wesentliche Rolle. Die Komplexität und Dynamik dieser sorgt dafür, dass die vollständige Darstellung eine besondere Schwierigkeit darstellt \cite{AbbaspourAsadollah2015}. Auch die Interaktion der Umwelt mit dem System ist gerade in der Robotik essenziell und eng mit den beschriebenen Anforderungen verknüpft, sodass auch diese Teil eines Testverfahrens darstellen sollten.
 \subsection{Reproduzierbarkeit}\label{grundlagen:testanforderungen:reproduzierbarkeit}
-Die Anwendung von sogenannten Regressionstests, also der erneuten (automatisierten) Testdurchführung nach Quellcodeänderungen, ist schon lange eine der weit verbreitetsten Teststrategien der heutigen Industrie um Softwarequalität zu gewährleisten \cite{Onoma1998}. Um derartige Tests zu ermöglichen, muss es möglich sein, die Testfälle zu reproduzieren. Daraus folgt, dass eine genaue und eindeutige Dokumentation ausgeführter beziehungsweise auszuführender Tests erfolgen muss. Aufgrund der Komplexität eines Robotiksystems ist es beinahe unmöglich Testfälle in der echten Welt präzise genug zu wiederholen. Auch Hardware-in-the-loop-Simulationen (siehe \cref{grundlagen:simulationen}) sind kein ideales Umfeld für die Reproduzierbarkeit von Tests, da bereits kleine Veränderungen des Systems oder der Umwelt Auswirkungen auf die Testausführung haben können. Die beste Möglichkeit für Regressionstests bieten aktuell klassische Simulatoren. Aber auch in modernen Simulationen ist die Wiederholbarkeit nicht garantiert, es kann vorkommen, dass das System auf (vermeintlich) exakt gleiche Situationen unterschiedlich reagiert. Einen weit verbreiteten Grund dafür stellen Zufallszahlengeneratoren dar, die in den Roboterkomponenten verwendet werde. Häufig läuft auch die Physik-Engine der Simulation und der Nutzer-Code auf verschiedenen Threads, sodass durch das Scheduling des Betriebssystems Präemptierung auftreten kann, welche die Ausführungsreihenfolge verändert und damit die Reproduzierbarkeit einschränkt \cite{Ferigo2020, Biggs2010}.
+Die Anwendung von sogenannten Regressionstests, also der erneuten (automatisierten) Testdurchführung nach Quellcodeänderungen, ist schon lange eine der weit verbreitetsten Teststrategien der heutigen Industrie um Softwarequalität zu gewährleisten \cite{Onoma1998}. Um derartige Tests zu ermöglichen, muss es möglich sein, die Testfälle zu reproduzieren. Daraus folgt, dass eine genaue und eindeutige Dokumentation ausgeführter beziehungsweise auszuführender Tests erfolgen muss. Aufgrund der Komplexität eines Robotiksystems ist es beinahe unmöglich Testfälle in der echten Welt präzise genug zu wiederholen. Auch Hardware-in-the-loop-Simulationen (siehe \cref{grundlagen:simulationen}) sind kein ideales Umfeld für die Reproduzierbarkeit von Tests, da bereits kleine Veränderungen des Systems oder der Umwelt Auswirkungen auf die Testausführung haben können. Die beste Möglichkeit für Regressionstests bieten aktuell klassische Simulatoren. Aber auch in modernen Simulationen ist die Wiederholbarkeit nicht garantiert, es kann vorkommen, dass das System auf (vermeintlich) exakt gleiche Situationen unterschiedlich reagiert. Einen Grund dafür stellen Zufallszahlengeneratoren dar, die in den Roboterkomponenten verwendet werden. Häufig läuft auch die Physik-Engine der Simulation und der Nutzer-Code auf verschiedenen Threads, sodass durch das Scheduling des Betriebssystems Präemptierung auftreten kann, welche die Ausführungsreihenfolge verändert und damit die Reproduzierbarkeit einschränkt \cite{Ferigo2020, Biggs2010}.
 Daher ist es nötig, Testdurchführungen mehrfach vorzunehmen und die Ergebnisse statistisch zu analysieren \cite{Biggs2010}. Trotz potenzieller Automatisierbarkeit und Parallelisierbarkeit dieses Prozesses, wie weiter unten diskutiert, ist gegenüber dem Testen reiner Softwaresysteme hier also mit einem Mehraufwand insbesondere auch bezüglich des Debuggens zu rechnen.
 \subsection{Skalierbarkeit}
 Wie in \cref{grundlagen:testanforderungen:reproduzierbarkeit} beschrieben besitzt das Wiederholen von Testfällen eine hohe Relevanz. Folglich muss die Anzahl an durchzuführenden Tests entsprechend anpassbar sein, um beispielsweise die Häufigkeit oder Quelle eines potenziellen Fehlers zu ermitteln. Durch moderne Simulationen lässt sich diese Anforderung heutzutage relativ leicht erfüllen, wenn die Testfälle dokumentiert und damit reproduzierbar sind, sodass die Skalierbarkeit als eher untergeordnet anzusehen ist. Wird hingegen Systemhardware verwendet, so kann sich diese aufgrund beschränkter Verfügbarkeit als Flaschenhals herausstellen, was beim Testverfahren beachtet werden sollte \cite{Biggs2010}.
@@ -27,7 +27,7 @@ Zur Ausführbarkeit zählt unter anderem die einfache Vor- und Nachbereitung, so
 Sollte Hardware verwendet werden, so ist der Aufwand für die Ausführung erhöht, da die Vorbereitung in der Regel relativ aufwändig ist und die Parallelisierbarkeit beziehungsweise Automatisierbarkeit stark eingeschränkt wird. Weiterhin muss eine Überwachung des Tests stattfinden, damit dieser unter Umständen abgebrochen werden kann, wenn beispielsweise ein Schaden am System droht oder im schlimmsten Fall Menschen in Gefahr sind \cite{Biggs2010}.
 \subsection{Analysierbarkeit}
 Das Erstellen von automatisierten Methoden zur Testauswertung stellt bei cyber-physischen Systemen eine Herausforderung dar. Die Komplexität eines solchen Systems sorgt für eine schwierige Identifikation der Fehlerquelle \cite{AbbaspourAsadollah2015}. Dennoch können Ergebnisse, gerade wenn eine statistische Analyse nötig ist, zusammengefasst und potenziell auf Ähnlichkeiten in den fehlschlagenden Tests hingewiesen werden.
-Die Analyse der Testergebnisse umfasst auch die der verletzter Systemanforderungen. Daher sollte es möglich sein, nachzuvollziehen, welche Anforderung bei Fehlschlagen welcher Tests verletzt wurden. Um dies zu vereinfachen, können im Rahmen der Testentwicklung die Testfälle den Anforderungen, die sie testen sollen, zugeordnet werden \cite{Pueschel2018}.
+Die Analyse der Testergebnisse umfasst auch die der verletzten Systemanforderungen. Daher sollte es möglich sein, nachzuvollziehen, welche Anforderung bei Fehlschlagen welcher Tests verletzt wurden. Um dies zu vereinfachen, können im Rahmen der Testentwicklung die Testfälle den Anforderungen, die sie testen sollen, zugeordnet werden \cite{Pueschel2018}.
 \subsection{Akkuratheit}
 Das System und seine Umwelt sollten im Testumfeld möglichst genau dem tatsächlichen Einsatz entsprechen, da die Tests sonst kaum Aussagekraft bieten. Selbst kleine Abweichungen von der Realität können bereits Auswirkungen auf die Ergebnisse haben. Daher sollte bei Simulationen auch eine für die jeweils getestete Aufgabe ausreichend korrekte Darstellung physikalischer Zusammenhänge stattfinden und Echtzeitfähigkeit gegeben sein \cite{Bihlmaier2014}. Gerade nicht-funktionale Eigenschaften oder weiche Körper können hier eine Herausforderung darstellen. Auch die Interaktion mit der Umgebung lässt sich schwierig simulieren. Insbesondere Menschen können sich unvorhersehbar verhalten. So stellt beispielsweise das Testen der Nutzerfreundlichkeit eines Systems, welches für alte Menschen oder solche mit Behinderungen entwickelt wird, eine Herausforderung dar \cite{AbbaspourAsadollah2015}.
 Außerdem muss sich das in der Simulation verwendete Modell möglichst genau so verhalten wie der echte Roboter. \cite{Pepper2007} stellt Methoden zur Validierung eines solchen Modells vor.
@@ -78,7 +78,7 @@ Daher wurde 2013 mit ISO 29119 ein neuer internationaler Standard für die Entwi
 	\item Testmanagementprozesse
 	\item Dynamische Testprozesse
 \end{enumerate}
-Die Prozesse interagieren jeweils mit ihrem Vorgänger oder Nachfolger, wobei auch Subprozesse innerhalb der einzelnen Stufen zum Einsatz kommen. In den organisatorischen Prozessen werden beispielsweise Richtlinien, Ziele sowie die Strategie für das Testen festgelegt, welche vom Management umgesetzt werden sollen, welches wiederum Feedback an die Testorganisationsebene gibt, sodass eine kontinuierliche Optimierung stattfindet. Die Testmanagementprozesse stellen eine Konkretisierung der Teststrategie unter Einhaltung der Richtlinien dar. Zunächst wird ein Testplan entwickelt und an die dynamische Testebene weitergereicht. Außerdem wird vom Management die Ausführung dieses Plans bezüglich Fortschritt und Einhaltung der Richtlinien überprüft und gegebenenfalls korrigierend eingegriffen. Als letzter Schritt des Managements ist das Abschließen der Tests angegeben. Dabei wird überprüft, welche Tests ausgeführt wurden und sinnvoll wiederverwendbare Testfälle archiviert. Die Testumgebung in den Ursprungszustand gebracht und relevante Informationen wie Testergebnisse aber auch gewonnene Erkenntnisse ("Lessons Learned") gesammelt.
+Die Prozesse interagieren jeweils mit ihrem Vorgänger oder Nachfolger, wobei auch Subprozesse innerhalb der einzelnen Stufen zum Einsatz kommen. In den organisatorischen Prozessen werden beispielsweise Richtlinien, Ziele sowie die Strategie für das Testen festgelegt, welche vom Management umgesetzt werden sollen, welches wiederum Feedback an die Testorganisationsebene gibt, sodass eine kontinuierliche Optimierung stattfindet. Die Testmanagementprozesse stellen eine Konkretisierung der Teststrategie unter Einhaltung der Richtlinien dar. Zunächst wird ein Testplan entwickelt und an die dynamische Testebene weitergereicht. Außerdem wird vom Management die Ausführung dieses Plans bezüglich Fortschritt und Einhaltung der Richtlinien überprüft und gegebenenfalls korrigierend eingegriffen. Als letzter Schritt des Managements ist das Abschließen der Tests angegeben. Dabei wird überprüft, welche Tests ausgeführt wurden und sinnvoll wiederverwendbare Testfälle archiviert. Die Testumgebung wird in den Ursprungszustand gebracht und relevante Informationen wie Testergebnisse aber auch gewonnene Erkenntnisse ("Lessons Learned") gesammelt.
 Dynamische Testprozesse umfassen die Testimplementierung, das Einrichtungen sowie die Instandhaltung der Testumgebung, die Testausführung und das Berichten von Testvorfällen an das Testmanagement \cite{Alaqail2018}.
 
 \section{Testentwicklung}
@@ -95,7 +95,7 @@ Grundlegend besteht das Modell aus 3 zentralen Bestandteilen:
 		Die gesamte Komponente wird getestet.
 \end{itemize}
 Diese Bestandteile werden auch von den ROS-Entwicklern empfohlen~\cite{OSRF2021} und bieten sich an, da ein (gut designtes) auf ROS basierendes System in sogenannte Nodes aufgeteilt ist, welche die einzelnen Komponenten darstellen. 
-Bibliotheken die ROS nicht benötigen sollen über vorgeschlagene Test-Frameworks (gtest für C++ und unittest für Python) getestet werden während 
+Bibliotheken, die ROS nicht benötigen, sollen über vorgeschlagene Test-Frameworks (gtest für C++ und unittest für Python) getestet werden während 
 für das Testen der Nodes zusätzlich eine Erweiterung namens rostest, welche auf roslaunch (Tool zum Starten von ROS Nodes) aufbaut, zur Verfügung steht. Auch Integrations-Tests sind mit rostest möglich, da auch mehrere Nodes zusammen gestartet und damit getestet werden können. 
 In der Dokumentation zu ROS~\cite{OSRF2021} sind auch Vorteile und Kosten dieser Testmethodik angeführt, welche im Folgenden zusammengefasst werden.
 \subsubsection{Vorteile}
@@ -110,15 +110,15 @@ Folglich ist eine gute Abdeckung der Systemanforderungen schwierig umzusetzen, u
 Das modellbasierte Testen wie in \cite{Pueschel2018} beschreibt einen Ansatz zum automatischen Generieren von Tests, welcher auf allen Ebenen des hierarchischen Testmodells angewandt werden kann. Dabei wird ein abstraktes Modell des Testobjektes erstellt, von dem die Tests abgeleitet werden können. Wichtig hierbei ist, dass das Modell eine gewisse Unabhängigkeit von Modellen besitzt, die zur Entwicklung genutzt wurden, da sich ansonsten Fehler aus dem Entwicklungsmodell in die Testfälle übertragen könnten. Es bietet sich daher an, das Modell direkt aus den Anforderungen des Systems zu entwickeln; das Entwicklungsmodell kann als Basis verwendet werden, oder um das Testmodell zusätzlich zu validieren \cite{Utting2011}.
 Da das Modell von Implementierungsdetails unabhängig ist und sich auf die Ein- und Ausgaben des Systems fokussiert, eignet sich modellbasiertes Testen nicht für white box Tests. Der in \cite{Pueschel2018} dargestellte Testprozess besteht aus 5 Schritten:
 \begin{enumerate}
-\item Zuerst muss das Modell erstellt werden. Dabei müssen die Anforderungen des Systems widergespiegelt sein und das Modell sollte möglichst abstrakt sein. Um später feststellen zu können, welche Anforderungen nicht erfüllt sind, ist es sinnvoll diese beim entsprechenden Teil des Modells anzugeben. Die modellierte Genauigkeit sowie die Teststrategien und -Techniken können in einem Testplan festgelegt werden.
+\item Zuerst muss das Modell erstellt werden. Dabei müssen die Anforderungen des Systems widergespiegelt sein während das Modell möglichst abstrakt gehalten bleibt. Um später feststellen zu können, welche Anforderungen nicht erfüllt sind, ist es sinnvoll diese beim entsprechenden Teil des Modells anzugeben. Die modellierte Genauigkeit sowie die Teststrategien und -Techniken können in einem Testplan festgelegt werden.
 \item Aus dem Modell lassen sich nun (mithilfe von Auswahlkriterien) Testfälle generieren, die sich zunächst auf demselben Abstraktionslevel wie das Modell befinden. Diese können nach der Generierung gespeichert (offline) oder direkt ausgeführt (online) werden, um den Schritt der Zwischenspeicherung zu sparen. Das Speichern der Testfälle sorgt hierbei für eine bessere Reproduzierbarkeit, benötigt aber logischerweise Speicher und ist daher gerade bei Robotiksystemen aufgrund der Menge an möglichen Testfällen eher weniger geeignet. Auch für sehr lange operierende beziehungsweise nicht-deterministische Systeme bietet sich daher online-testen an.
 Neben den Testfällen kann potenziell aus den in 1. gegebenen Anforderungen eine sogenannte Anforderungsrückverfolgungsmatrix (und ein Modellabdeckungsbericht) erstellt werden, mit welcher sich feststellen lässt, welche Anforderungen beim Fehlschlagen von Tests verletzt wurden.
 \item Nun werden die abstrakten Testfälle zu konkreten (ausführbaren) Tests. Realisierbar ist dies beispielsweise durch einen Adapter, der den abstrakten Operationen (während der Laufzeit) Schnittstellen des Systems zuordnet.
 \item Folglich werden die Tests ausgeführt. 
 \item Die Ergebnisse werden analysiert, Fehler gefunden und behoben.
 \end{enumerate}
-Bei modellbasiertem Testen generell kann auch keine automatische Generierung der Testfälle erfolgen. In \cite{Pretschner2005} wurde dabei (mit gleicher Anzahl an Testfällen) kein signifikanter Unterschied in der Summe an erkannten Fehlern festgestellt. Allerdings führte das Erhöhen der Anzahl an Testfällen, welche bei der automatischen Methode deutlich einfacher ist, zu zusätzlichen 11\% an gefundenen Fehlern. \cite{Pretschner2005} weist jedoch darauf hin, dass die festgestellten Ergebnisse nur eine Fallstudie darstellen und daher nicht ohne weiteres zu verallgemeinern sind.
-In \cite{Utting2011} wird eine weitere Klassifizierung von möglichen Modellen für modellbasiertes Testen vorgenommen, unter anderem lassen sich Markov-Ketten, endliche Automaten oder Petri-Netze zur Modellierung nutzen. Da Modelle, deren Umfang sich nur auf Inputs bezieht, kaum funktionales Verhalten verifizieren können sollten für cyber-physische Systeme Input-Output-Modelle verwendet werden. Die Echtzeitanforderungen eines Systems müssen im Modell widergespiegelt werden und spielen folglich auch bei der Testgenerierung und Ausführung eine Rolle \cite[S. 358f]{Broy2005}. Robotiksysteme sollten sich meist deterministisch verhalten, aufgrund des in \cref{grundlagen:simulationen} beschriebenen Nichtdeterminismus der Simulation oder uneindeutiger Inputs kann aber auch ein nichtdeterministisches Modell verwendet werden; sollen auch nichtdeterministische Systemfunktionalitäten überprüft werden, so ist ein deterministisches Modell offensichtlich nicht sinnvoll. Die Dynamik des Modells muss abhängig von den zu testenden Anforderungen sein, meist sind Robotiksystemen als kontinuierlich oder hybrid (Mix aus kontinuierlichen und diskreten Eigenschaften) einzustufen \cite{Utting2011}. Das Paradigma des Modells sowie das Testauswahlkriterium müssen bei der Entwicklung ausgewählt werden, da sie stark von den zu testenden Anforderungen abhängen. Allerdings werden häufig verschiedene dieser Paradigmen verwendet, da sie sich vereinigen lassen. Bezüglich des Testauswahlkriteriums und der Technik zum Generieren der Tests können ebenfalls mehrere verwendet werden \cite{Utting2011}.
+Bei modellbasiertem Testen generell kann auch keine automatische Generierung der Testfälle erfolgen. In \cite{Pretschner2005} wurde dabei (mit gleicher Anzahl an Testfällen) kein signifikanter Unterschied in der Summe an erkannten Fehlern festgestellt. Allerdings führte das Erhöhen der Anzahl an Testfällen, welches bei der automatischen Methode deutlich einfacher ist, zu zusätzlichen 11\% an gefundenen Fehlern. \cite{Pretschner2005} weist jedoch darauf hin, dass die festgestellten Ergebnisse nur eine Fallstudie darstellen und daher nicht ohne weiteres zu verallgemeinern sind.\\
+In \cite{Utting2011} wird eine Klassifizierung von möglichen Modellen für modellbasiertes Testen vorgenommen, unter anderem lassen sich Markov-Ketten, endliche Automaten oder Petri-Netze zur Modellierung nutzen. Da Modelle, deren Umfang sich nur auf Inputs bezieht, kaum funktionales Verhalten verifizieren können sollten für cyber-physische Systeme Input-Output-Modelle verwendet werden. Die Echtzeitanforderungen eines Systems müssen im Modell widergespiegelt werden und spielen folglich auch bei der Testgenerierung und Ausführung eine Rolle \cite[S. 358f]{Broy2005}. Robotiksysteme sollten sich meist deterministisch verhalten, aufgrund des in \cref{grundlagen:simulationen} beschriebenen Nichtdeterminismus der Simulation oder uneindeutiger Inputs kann aber auch ein nichtdeterministisches Modell verwendet werden; sollen auch nichtdeterministische Systemfunktionalitäten überprüft werden, so ist ein deterministisches Modell offensichtlich nicht sinnvoll. Die Dynamik des Modells muss abhängig von den zu testenden Anforderungen sein, meist sind Robotiksystemen als kontinuierlich oder hybrid (Mix aus kontinuierlichen und diskreten Eigenschaften) einzustufen \cite{Utting2011}. Das Paradigma des Modells sowie das Testauswahlkriterium müssen bei der Entwicklung ausgewählt werden, da sie stark von den zu testenden Anforderungen abhängen. Allerdings werden häufig verschiedene dieser Paradigmen verwendet, da sie sich vereinigen lassen. Bezüglich des Testauswahlkriteriums und der Technik zum Generieren der Tests können ebenfalls mehrere verwendet werden \cite{Utting2011}.
 \subsubsection{Vorteile}
 Diese Methode der Testentwicklung ermöglicht erhebliche Einsparungen beim Entwicklungsaufwand bei Änderungen des Systems, da ohne viel Aufwand neue passende Testfälle generiert werden können. Die automatische Generierung eliminiert menschliche Fehler bei der Erstellung von Tests \cite{Gummel2018}.
 Eine gute Skalierbarkeit ist gegeben, da die Anzahl an Testfällen sich einfach anpassen lässt, wodurch mehr Fehler gefunden werden können und eine bessere Abdeckung gegeben ist \cite{Pretschner2005}.
diff --git a/sections/konzept.tex b/sections/konzept.tex
index 9f63a82be19f26eedbfeb76f35707401b8bd7de8..7b29bd0509054a2e241a177ee7a3f3926e7971bf 100644
--- a/sections/konzept.tex
+++ b/sections/konzept.tex
@@ -8,10 +8,10 @@ Auch sind Plug-Ins unterstützt, sodass sich auch nicht nativ implementiere Sach
 Allerdings können komplexe Zusammenhänge, auch abhängig von der gewünschten Akkuratheit, bei einer Implementierung in Form von Plug-Ins den Entwicklungsaufwand stark erhöhen. Problematisch ist bei Gazebo die Performance bei vielen simulierten Robotern oder komplexen Umgebungen, sodass in diesen Fällen potenziell andere Simulatoren verwendet werden sollten \cite{Ivaldi2014}.
 \section{Uppaal-Modellierung}
 Vor dem Erstellen eines Modells müssen zunächst die gewünschten Anforderungen des Systems formal festgehalten werden. Diese formalen Anforderungen sind dann zu quantisieren. Dabei bieten sich besonders für die nicht-funktionalen Eigenschaften Invarianten im Modell an.
-Da für die Testgenerierung auch ein Modell für die Inputs des Systems nötig ist, können die Modelle auch innerhalb von Uppaal verifiziert werden. Ebenso lassen sich formale Eigenschaften mithilfe des integrierten Verifiers überprüfen. Wie in \cref{grundlagen:testentwicklung:modell-basiert} erwähnt können, falls schon eine Implementierung vorhanden ist, auch Modelle die zur Entwicklung verwendet wurden zur Verifizierung beitragen.
+Da für die Testgenerierung auch ein Modell für die Inputs des Systems nötig ist, kann das Modellverhalten auch innerhalb von Uppaal verifiziert werden. Ebenso lassen sich formale Eigenschaften mithilfe des integrierten Verifiers überprüfen. Wie in \cref{grundlagen:testentwicklung:modell-basiert} erwähnt können, falls schon eine Implementierung vorhanden ist, auch Modelle die zur Entwicklung verwendet wurden zur Verifizierung beitragen.
 
 \section{TRON-Adapter}
-Um den Adapter an da ROS-System anzuknüpfen, wurde ein ROS-Node geschrieben, welcher die Pakete des Adapters annimmt und intern über die ROS Topics an das System weitergibt. Diese Übersetzung ist generisch implementiert, sodass zukünftig für ROS-Projekte dieser Adapter bis auf die Konfiguration wiederverwendet werden kann. Um die Umgebung in der Simulation auch für TRON verfügbar zu machen, müssen die dafür vorhandenen Daten über ein ROS Topic im System veröffentlicht und dann durch den Adapter weitergereicht werden. 
+Um den Adapter an da ROS-System anzuknüpfen, wurde eine Adapter-Klasse geschrieben, welche die Pakete des Adapters annimmt und intern über die ROS Topics an das System weitergibt. Diese Übersetzung ist generisch implementiert, sodass zukünftig für ROS-Projekte dieser Adapter bis auf die Konfiguration wiederverwendet werden kann. Um die Umgebung in der Simulation auch für TRON verfügbar zu machen, müssen die dafür vorhandenen Daten über ein ROS Topic im System veröffentlicht und dann durch den Adapter weitergereicht werden. 
 \cref{konzept:bild} zeigt den schematischen Aufbau der Implementierung.
 \begin{figure}[H]
 	\centering
@@ -31,17 +31,17 @@ Zunächst wird der SocketAdapter auf eine eingehende Verbindung warten. Folglich
 	\label{konzept:tron_konfigurierung}
 \end{figure}
 \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.
+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 Nachrichten aus einem Channel-Identifier, 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.
 
 \subsection{Implementierung}
 Der implementierte Adapter verwendet vom Betriebssystem bereitgestellte Sockets für die Kommunikation mit TRON und hält relevante Variablen, in welchen die Abbildungen von Channel auf Topics sowie die zugehörigen Variablen beschrieben werden, innerhalb einer Klasse. Die Verwendung dieser wird im nächsten Abschnitt dargestellt.
-Bei der Implementierung des Adapters (siehe Header-Datei im 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.\\
+Bei der Implementierung des Adapters (siehe \cref{header}) 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 Anzahl an 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 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, mit denen den Uppaal-Variablen Positionen innerhalb der ROS-Nachrichten zugewiesen werden, es sind jedoch auch eigene Implementierungen zum Beispiel für Felder mit variabler Länge möglich, welche in den meisten Fällen zu empfehlen sind.
+Templates ermöglichen generische Callbacks, mit denen den Uppaal-Variablen Byte-Positionen innerhalb der ROS-Nachrichten zugewiesen werden, es sind jedoch auch eigene Implementierungen zum Beispiel für Felder mit variabler Länge möglich, welche in den meisten Fällen zu empfehlen sind.
 \subsubsection{Verwendung}
 Zur Verwendung des Adapters muss eine Instanz der Klasse \textit{TRON\_Adapter} erstellt werden. Ihr wird die Ziel-IP-Adresse sowie der Port übergeben, über den eine bereits laufende TRON Instanz erreichbar ist. Die Struktur \textit{Mapping} beschreibt das Verhältnis von einem Channel zu einem Topic und muss daher für jedes gewünschte Paar mittels der Funktion \textit{createMapping} initialisiert werden. Dabei ist (nach dem Namen des Topics und dem Namen des Channels) anzugeben, ob dieses Mapping als Eingabe oder Ausgabe dient. Soll ein Channel sowohl Eingabe als auch Ausgabe sein, oder sollen mehrere Topics einem Channel zugewiesen werden (oder umgekehrt), so müssen dafür zusätzliche Mappings erstellt werden.
 \\ Nach der Initialisierung lassen sich Variablen hinzufügen. Dazu wird dem Adapter über \textit{add\_var\_to\_mapping} neben dem Mapping selbst der Name der Variablen in Uppaal übergeben. Optionale Parameter wie zum Beispiel der Offset können angegeben werden, wenn die Übersetzung mittels Byte-Positionen innerhalb der ROS-Nachricht stattfinden soll. Der Offset beginnt vom Ende des letzten Feldes, sodass in diesem Fall die Variablen in der richtigen Reihenfolge angegeben werden müssen.
-\\ Für Input-Channel ist zusätzlich ein Callback zu spezifizieren, welcher als Parameter eine Referenz zum entsprechenden Mapping und ein Array von 32-Bit-Integern, den von TRON übergebenen Variablen, bekommt. \textit{mapping\_callback\_to\_topic} kann dafür verwendet werden, und mit den festgelegten Byte-Positionen zu arbeiten. Output-Channel haben keinen separaten Callback, da dieser beim Abonnieren eines Topics durch die ROS API festgelegt wird. Wie bei den Input-Channel ist dafür eine generische Funktion vorhanden, \textit{mappings\_callback\_to\_TRON}, welche bei einfachen Nachrichten verwendet werden kann. Anzumerken ist hierbei, dass diese Methode alle Channel informiert, die als Output mit dem Topic angegeben sind, während bei den Inputs jeweils eine Funktion im Mapping hinterlegt ist.
+\\ Für Input-Channel ist zusätzlich ein Callback zu spezifizieren, welcher als Parameter eine Referenz zum entsprechenden Mapping und ein Array von 32-Bit-Integern, den von TRON übergebenen Variablen, bekommt. \textit{mapping\_callback\_to\_topic} kann dafür verwendet werden, um mit den festgelegten Byte-Positionen zu arbeiten. Output-Channel haben keinen separaten Callback, da dieser beim Abonnieren eines Topics durch die ROS API festgelegt wird. Wie bei den Input-Channel ist dafür eine generische Funktion vorhanden, \textit{mappings\_callback\_to\_TRON}, welche bei einfachen Nachrichten verwendet werden kann. Anzumerken ist hierbei, dass diese Methode alle Channel informiert, die als Output mit dem Topic angegeben sind, während bei den Inputs jeweils eine Funktion im Mapping hinterlegt ist.
 \\ Schließlich muss das Mapping der Liste \textit{mappings} hinzugefügt werden. Zu beachten ist, dass für jedes Topic, welches im Rahmen von Input-Mappings verwendet wird ein entsprechender \textit{ros::Publisher} in der Liste \textit{input\_publishers} vorhanden sein muss. Analog dazu müssen \textit{ros::Subscriber} zu \textit{output\_subscriber} hinzugefügt werden.
 \\ Neben den Mappings muss auch die Zeiteinheit sowie der Zeitraum für den getestet werden soll festgelegt werden, dies geschieht über einen Funktionsaufruf an \textit{set\_time\_unit\_and\_timeout}.
 \\ Für das in \cref{konzept:uppaal_tor} dargestellte Modell könnte die Konfigurierung etwa so aussehen:
@@ -56,7 +56,7 @@ adapter.mappings.push_back(map);
 // Output Channel "position" wird auf Topic "/position" abgebildet
 map = adapter.createMapping("/position", "position", false);
 // es wird eine Variable namens "pos" uebertragen, die sich bei Offset 0 (direkt am Anfang der Nachricht) befindet
-adapter.add_var_to_mapping(map, "akt_position", 0);
+adapter.add_var_to_mapping(map, "pos", 0);
 adapter.mappings.push_back(map);
 adapter.output_subscribers.push_back(
 		nh.subscribe<std_msgs::Int32>("/position", 10, 
@@ -71,6 +71,6 @@ adapter.set_time_unit_and_timeout(1000, 100000);
 Der Channel \textit{position} sowie die Variable \textit{pos} sind in \cref{konzept:uppaal_tor} nicht dargestellt, werden hier aber verwendet, um einen Output-Channel sowie das Übertragen einer Variable zu demonstrieren.
 Ein besonderes Augenmerk liegt auf dem Callback des ros::Subscriber. Dieser benötigt nach dem boost::bind der Adapter-Instanz an die Funktion einen expliziten Cast zu einer boost::function des entsprechenden Typs, da der Compiler diesen nicht zuverlässig selbstständig ableiten kann und dennoch keinen Fehler ausgibt. Dies ist auf der zum Thema passenden Übersichtsseite von ROS\footnote{\url{http://wiki.ros.org/roscpp/Overview/Publishers\%20and\%20Subscribers}} in einer Notiz unter 2.3.3 angemerkt.
 \\
-In den meisten praktischen Fällen ist das verwenden eigens für bestimmte Nachrichten implementierter Callbacks sinnvoller, da ROS-Nachrichten sehr komplex sein können und viele Felder variabler Größe verwendet werden, wofür Konvertierungsfunktionen nötig wären. Außerdem wird dadurch die Lesbarkeit des Codes erhöht und folglich die Wartung erleichtert. Benutzerdefinierte Callbacks können \textit{report\_now} und \textit{publish\_to\_topic} nutzen um Nachrichten zu TRON beziehungsweise zu den Topics zu senden.
+In den meisten praktischen Fällen ist das Verwenden eigens für bestimmte Nachrichten implementierter Callbacks sinnvoller, da ROS-Nachrichten sehr komplex sein können und viele Felder variabler Größe verwendet werden, wofür Konvertierungsfunktionen nötig wären. Außerdem wird dadurch die Lesbarkeit des Codes erhöht und folglich die Wartung erleichtert. Benutzerdefinierte Callbacks können \textit{report\_now} und \textit{publish\_to\_topic} nutzen um Nachrichten zu TRON beziehungsweise zu den Topics zu senden.
 Auch hier ist zu erwähnen, dass die Übersetzung von einem Topic zu mehreren Channels innerhalb lediglich einer Methode stattfinden kann, die dem ROS-Subscriber als Parameter übergeben werden muss.
 Diese Variante wird auch bei einer später im Text folgenden beispielhaften Anwendung des Adapters für die sogenannte \textit{actionlib} sowie im durchgeführten Testbeispiel (siehe \cref{fallbeispiel}) verwendet.
diff --git a/sections/stateoftheart.tex b/sections/stateoftheart.tex
index ff70314231cbd02c37dc97865f51ca30b44b6dc4..52d3afe7c9c5fa986df0d736a852b82713cae559 100644
--- a/sections/stateoftheart.tex
+++ b/sections/stateoftheart.tex
@@ -36,4 +36,4 @@ Das Model-based Adaptivity Test Environment\footnote{\url{http://81.88.24.184/qm
 \end{figure}
 
 \section{Tool-Auswahl}
-Uppaal und TRON werden im weiteren Verlauf dieser Arbeit exemplarisch angewandt. Zum einen kann das Verhalten der Modelle durch die verschiedenen Typen von Knoten und Kanten genau bestimmt werden, zum anderen ist die Verifizierung ein hilfreiches Feature. Außerdem wurde vom Lehrstuhl bereits mit dem Tool, jedoch ohne TRON, gearbeitet. Aus diesen Gründen und da auch am Lehrstuhl bereits mit Uppaal gearbeitet wurde, wird das Tool in dieser Arbeit exemplarisch angewandt. Die Erweiterung von TRON namens DTRON (Distributed TRON) für verteilte Systeme sowie das verwendete Adapter-Template von \cite{Ernits2015, Gummel2018} steht momentan nicht zur Verfügung und kann daher nicht verwendet werden.
\ No newline at end of file
+Uppaal und TRON werden im weiteren Verlauf dieser Arbeit exemplarisch angewandt. Zum einen kann das Verhalten der Modelle durch die verschiedenen Typen von Knoten und Kanten genau bestimmt werden, zum anderen ist die Verifizierung ein hilfreiches Feature. Außerdem wurde vom Lehrstuhl bereits mit dem Tool, jedoch ohne TRON, gearbeitet. Die Erweiterung von TRON namens DTRON (Distributed TRON) für verteilte Systeme sowie das verwendete Adapter-Template von \cite{Ernits2015, Gummel2018} steht momentan nicht zur Verfügung und kann daher nicht verwendet werden.
\ No newline at end of file