No commit message

No commit message

sections/einleitung.tex

@@ -26,5 +26,5 @@ Die Grundlagen werden dafür im zweiten Kapitel geschaffen, indem zuerst ein kur
 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 Modell-basierten 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.\\
-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, bevor eine Evaluation der Testmethodik stattfinden kann.\\
-Das letzte Kapitel beschreibt, wie die im zweiten Kapitel aufgestellten Anforderungen erfüllt wurden und fasst die Erkenntnisse dieser Arbeit zusammen.
+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.

sections/fallbeispiel.tex

@@ -56,7 +56,7 @@ Am Anfang wird eine Anzahl an Versuchen festgelegt, die der Roboter beim Aufhebe
 Das aus diesen Angaben erstellte Modell ist in \cref{cobot:formales_modell_bild} dargestellt.\\
 \begin{figure}[h]
 	\centering
-	\includegraphics[scale=.2]{./cobot1_v1.png}
+	\includegraphics[scale=.18]{./cobot1_v1.png}
 	\caption{Formales Modell des Cobots}
 	\label{cobot:formales_modell_bild}
 \end{figure}
@@ -78,7 +78,7 @@ Diese Aspekte schränken zwar das Modell ein und machen eine Auslagerung von Log
 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 jede 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]
 	\centering
-	\includegraphics[scale=.2]{./cobot1_positionen_modell.png}
+	\includegraphics[scale=.22]{./cobot1_positionen_modell.png}
 	\caption{Modell der Positionen vom Glas}
 	\label{cobot:positionen_modell_bild}
 \end{figure}
@@ -102,14 +102,33 @@ Zur Ausführung wurde ein simples Bash-Script geschrieben, welches zuerst einen
 \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.\\
 In 46 der 100 Fälle wurde die Sequenz erfolgreich ausgeführt und die Flasche sowie das Glas waren in der richtigen Position. Dabei wurde eine Toleranz von 5cm verwendet. Nur 3 Fälle führten zum Herunterfahren des Systems, was ebenfalls als erfolgreicher Abschluss gezählt werden kann. Die restlichen 51 Ausführungen führten zu keinem Erfolg und wurden im Folgenden manuell analysiert.\\
-Die größte Fehlerquelle stellte das Neigen der Flasche beim Befüllen des Glases dar. Es kam dabei 42 mal zum Umfallen mindestens eines Objektes. Mithilfe der protokollierten Abstände von Positionen und Orientierungen sowie der Zustände in denen diese auftraten lässt sich grob feststellen, wann ein solches Ereignis auftrat. 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. \\
+Die größte Fehlerquelle stellte das Neigen der Flasche beim Befüllen des Glases dar. Es kam dabei 42 mal zum Umfallen mindestens eines Objektes.
+\cref{fallbeispiel:testergebnisse:log} zeigt das Ende des Logs eines fehlgeschlagenen Tests. Der Channel \textit{place\_success} wurde aktiviert während sich das Modell des Cobots im Zustand \textit{placing\_bottle} befindet, obwohl die Flasche 17cm von seiner Zielposition entfernt war und 90 Grad von der aufrechten Position abwich, sie lag also auf dem Boden.
+Mithilfe der protokollierten Abstände von Positionen und Orientierungen sowie der Zustände in denen diese auftraten lässt sich grob feststellen, wann ein solches Ereignis auftrat. 
+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 ü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.\\
 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. 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.
 
-\begin{table}
+\newpage
+\lstset{
+	escapeinside={*}{*}
+}
+\renewcommand{\lstlistingname}{Log}
+\begin{lstlisting}[tabsize=1, language={}, caption={Letzter Status bei einem fehlgeschlagenen Test}, label=fallbeispiel:testergebnisse:log]
+	( *\textbf{Cobot.placing\_bottle}* press._id9 move._id10 pickup._id11 place._id0 goal_._id7 goalcatcher._id47 positionupdate._id46 positionupdatecatcher._id45 bottle_position.moving glass_position.start_pos testdonecatcher._id44 asapcatcher._id12 )
+	#t>154, #t<=155 retry_count=5 init_retry_count=5 place_glass_retry=0 orient_constraint_set=1 bottle_diff_to_start_pos=17 bottle_diff_to_start_ang=90 *\textbf{bottle\_diff\_to\_target\_pos=17}* *\textbf{bottle\_diff\_to\_target\_ang=90}* glass_diff_to_start_pos=0 glass_diff_to_start_ang=0 glass_diff_to_target_pos=140 glass_diff_to_target_ang=0 bottle_in_start_pos=0 bottle_in_target_pos=0 glass_in_start_pos=1 glass_in_target_pos=0 
+	...
+	Got unacceptable output: *\textbf{place\_success()}*@154032823us at (154;155)
+	TEST FAILED: Observed unacceptable output.
+	Time elapsed: 154 tu = 154.082412s
+	Time    left: 446 tu = 445.917588s
+	Random  seed: 1628691301
+\end{lstlisting}
+
+\begin{table}[h]
 	\caption{Testergebnisse}
 	\label{cobot:testergebnisse:tabelle}
 	{\small

thesis.tex

@@ -21,6 +21,7 @@
 
 \usepackage[hidelinks]{hyperref} % makes all links clickable but hides ugly boxes
 \usepackage[capitalise,nameinlink,noabbrev]{cleveref} % automatically inserts Fig. X in the text with \cref{..}
+\crefname{lstlisting}{Log}{Logs}
 
 \usepackage[colorinlistoftodos,prependcaption,textsize=tiny]{todonotes}