No commit message

No commit message

sections/einleitung.tex

@@ -18,7 +18,7 @@ Folglich wird durch Literaturrecherche Anforderungen an Testmethoden von Robotik
 Ein zentraler Aspekt dabei ist die korrekte Simulation des Roboters, da diese essentieller Bestandteil des Testumfelds ist. 
 Außerdem sollen verschiedene Methoden und Toolchains für das Testen zusammen mit ihren Vor- und Nachteilen vorgestellt werden.
 Weiterhin wird eines dieser Konzept verwendet, indem ein sich in Entwicklung befindendes Projekt des Lehrstuhls getestet wird.
-Schließlich soll die angewandte Testmethodik im Rahmen der am Anfang ermittelten Kriterien evaluiert und ein Ausblick auf mögliche Weiterentwicklungen gegeben werden.
+Schließlich soll die angewandte Testmethodik im Rahmen der am Anfang ermittelten Kriterien evaluiert werden.
 
 \section{Gliederung}\label{einleitung:gliederung}
 In diesem Abschnitt wird nach einer Einleitung in das Thema und die gestellten Aufgaben nun der Aufbau dieser Arbeit beschrieben. Sie besteht aus insgesamt 6 Kapiteln. \\
@@ -27,5 +27,4 @@ Folgend ist für jedes aus der Literatur ermittelte Kriterium des Testens von Ro
 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.\\
-\todo{Evaluation}
-\todo{Anhang}
+Das letzte Kapitel beschreibt, wie die im zweiten Kapitel aufgestellten Anforderungen erfüllt wurden und fasst die Erkenntnisse dieser Arbeit zusammen.

sections/evaluation.tex

 \chapter{Evaluation}
+Nach der Anwendung von Uppaal mit TRON lässt sich das verwendete Konzept evaluieren. Dafür bilden die in \cref{grundlagen:testanforderungen} spezifizierten Anforderungen die Grundlage.
+
+\section{Anforderungen}
+\subsection{Abdeckung und Vollständigkeit}
+Die Abdeckung der Testmethodik ist unter anderem durch das verwendetet Modell festgelegt. Da dieses relativ abstrakt gehalten wird, muss auch der Adapter zur Abdeckung beitragen. Gazebo ist als Simulation zwar äußerst hilfreich, bietet aber nur begrenzt Möglichkeiten zum Modellieren nicht-funktionaler Eigenschaften, die im Fallbeispiel dieser Arbeit jedoch nicht benötigt wurden. Funktionale Anforderungen sowie Interaktionen und die Umwelt lassen sich jedoch erfassen, sofern entsprechende Modelle für eine Simulation vorliegen.
+\subsection{Reproduzierbarkeit}
+Ein wiederholtes Ausführen der Tests hat im Fallbeispiel funktioniert. Das Modell beschreibt aufgrund seiner Abstraktheit die Testfälle eindeutig, wobei im Adapter darauf geachtet werden muss, dass die Übersetzung ebenso eindeutig stattfindet, damit der Testfall wiederholt werden kann. Damit sind durch Modell und Adapter alle Testfälle dokumentiert.
+Auch hier ist die Simulation und die damit einhergehende korrekte Modellierung als wichtigster Faktor anzusehen. Da wie in jeder Simulation auch Gazebo bei jeder Ausführung minimale Abweichungen aufweist, kann keine absolute Eindeutigkeit gewährleistet werden. Im Fallbeispiel wurde gezeigt, dass selbst kleine Abweichungen größere Veränderungen bewirken können, in diesem Fall ob etwa die Flasche herunterfällt oder nicht. 
+\subsection{Skalierbarkeit}
+Diese Form der Testausführung ist ohne Probleme skalierbar, es kann eine beliebige Anzahl an Tests ausgeführt werden, wobei die Tests jedoch je nach System viel Zeit in Anspruch nehmen können. Dies war im Fallbeispiel primär den Berechnungen von ROS/MoveIt und der Geschwindigkeit der Simulation zuzuschreiben. Diese konnte nur mit einem Tempo von 20 Prozent der Echtzeit ausgeführt werden, da sonst praktisch jede Ausführung fehlschlug, da die Greifoperation des Roboters nicht darauf ausgelegt ist.
+\subsection{Aufwand}
+Wie erwartet ist der Aufwand bei der Implementierung von modell-basiertem Testen eher als hoch anzusehen. Die Entwicklung des formalen Modells erwies sich dabei als relativ einfach, während die Konfiguration des Adapters sowie die Anpassung des Modells an die Topics von ROS deutlich schwieriger war. Dies ist zum einen darauf zurückzuführen, dass Uppaal ursprünglich für die Verifikation von Modellen und nicht zum modell-basierten Testen entwickelt wurde, zum anderen wird Uppaal und TRON nicht mehr aktiv weiterentwickelt und ist relativ alt. Einen weiteren erschwerenden Faktor stellt die schlechte Dokumentation der Tools dar. Weiterhin werden komplexe Berechnungen innerhalb von Uppaal aufgrund der begrenzten Syntax nicht möglich sein, und TRON unterstützt lediglich 32-Bit-Integer-Variablen, was offensichtlich einen Nachteil darstellt und dazu führt das Logik in den Adapter ausgelagert werden muss.
+Außerdem müssen die neben dem System laufenden ROS-Topics analysiert und die gewünschten Informationen innerhalb dieser gefunden werden, um sie im Adapter hinzuzufügen. Daher kann diese Testmethode auch nicht ohne Weiteres auf beispielsweise HIL-Simulationen übertragen werden, wenn Informationen der Umwelt benötigt werden. Positiv anzumerken ist jedoch, dass neu implementierte Änderungen des Systems einfach zu testen sind, wenn dafür gewünschte Informationen bereits durch den Adapter übertragen werden.\\
+Bezüglich der Ausführbarkeit ist festzuhalten, dass eine einfache Automatisierbarkeit gegeben ist. roslaunch-Dateien sowie TRON können einfach aus einem Skript gestartet werden und die Ausführung ohne GUI ist mit Gazebo problemlos umsetzbar. Die Parallelisierbarkeit ist jedoch durch ROS selbst stark eingeschränkt, da es nicht möglich ist mehrere Nodes mit gleichem Namen parallel laufen zu lassen. Dafür wären mehrere Systeme nötig oder es könnte auf virtuellen Maschinen gearbeitet werden. 
+\subsection{Analysierbarkeit}
+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.
+\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. 
+
+\section{Fazit}
+Zusammengefasst lässt sich sagen, dass die in dieser Arbeit verwendete Testmethode erfolgreich zum Finden von unerwünschtem Verhalten und Fehlern verwendet werden kann. Allerdings ist die Implementierung ein aufwändiger Prozess, der sich in einigen Fällen wahrscheinlich nicht lohnt. Bei Systemen, die sich in der Entwicklung befinden oder die aus sonstigen Gründen häufige Änderungen erfahren, kann jedoch ein solcher Testprozess angewandt werden, da bei Vorhandensein des Adapters Änderungen schnell testbar sind, indem das Modell entsprechend verändert wird.\\
+Beschränkende Faktoren für die Testentwicklung von Robotersystemen sind vor allem Simulationen, welche jedoch bereits viele Aspekte des Testens stark verbessern. Daher ist die Forschung auf dem Gebiet der Simulationen äußerst wichtig für die Robotik. Aber auch in der Robotik selbst muss weiterhin Forschung betrieben werden, gerade spezielle Tools zum Testen dieser Systeme für akademische Zwecke (oder open source) sind bisher kaum vorhanden, während für modell-basiertes Testen an sich bereits schon viele Lösungen existieren.\\
+Uppaal selbst ist eine hilfreiche Anwendung und wurde mit TRON um ein sehr sinnvolles Feature erweitert. Allerdings sind die Tools relativ umständlich zu nutzen und es fehlt Unterstützung für heutzutage wichtige Funktionen wie komplexe Variablentypen. Daher wäre eine neue Version des Programms oder eine bessere Alternative ein wichtiger Schritt um modell-basiertes Testen für Robotiksysteme voranzubringen.
\ No newline at end of file

sections/fallbeispiel.tex

 \chapter{Fallbeispiel}
 \section{Integration mit actionlib}\label{actionlib:integration}
+Hier wird überprüft, ob der Testadapter bei Systemen, welche auf der actioblib basieren, verwendbar ist.
 Das hier verwendete Szenario entspricht einer etwas erweiterten Version des in \cref{konzept:uppaal_tor} verwendeten Beispiels, einem Garagen-Tor, welches präemptiert werden kann. Der implementierte Action-Server nimmt einen Boolean entgegen, der festlegt, ob das Tor geöffnet oder geschlossen werden soll, und gibt dann zufällig Feedback in Form eines Integers zurück, welcher die aktuelle Position des Tores repräsentiert. Dabei steht der Wert 0 für ein geschlossenes sowie 1000 für ein offenes Tor. Nach Abschluss des aktuellen Vorgangs wird der Status zurück zum Client übertragen. Dieser kann jedoch auch während der Ausführung das Wechseln des Ziels anfragen, woraufhin der Server das alte Ziel verwirft.\\
 Das entsprechend erstellte Uppaal-Modell ist in \cref{integration:uppaal} zu sehen. Auffällig dabei sind Kanten denen die Channel \textit{fertig} und \textit{position} zugewiesen sind. Bei diesen wird vom System die aktuelle Position übermittelt. Dazu wird eine zufällige Zahl zwischen 0 und 1000 ausgewählt und zur Position addiert beziehungsweise subtrahiert. Außerdem wird garantiert, dass die Grenzen des Wertebereiches nicht überschritten werden.
 \begin{figure}[h]

sections/grundlagen.tex

@@ -48,7 +48,7 @@ Die Anforderungen an die Testmethodiken cyber-physischer und insbesondere Roboti
 Simulationen ermöglichen Entwicklern eine einfachere Umsetzung der in \cref{grundlagen:testanforderungen} gestellten Anforderungen, da das System nicht in seinem Einsatzumfeld getestet werden muss. Neben Kosten und Zeit der Testausführung wird insbesondere bei kollaborativen Robotiksystemen eine größere Sicherheit sowie Reproduzierbarkeit gewährleistet. Allerdings sind als Trade-off bezüglich der Akkuratheit Einbußen anzunehmen \cite{Sarhadi2014}.
 Unterschieden werden im folgenden rein computerbasierte Simulationen und sogenannte Hardware-in-the-Loop-Simulationen, welche die Brücke zwischen Software- und Hardwaretests schlagen. 
 Hier lässt sich Anmerken, dass bezüglich der Übertragbarkeit ein großer Teil auf die verwendete Simulation abfällt. Sind für das Verwenden einer Simulation Veränderungen im Quelltext des Systems notwendig, so steigt damit der Aufwand beim Übertragen der Tests auf andere Simulationen (wie z.B. HIL) beziehungsweise auf das Testen ohne Simulation.
-\subsection{Computerbasierte Simulationen}\label{grundlagen:klassifikation:simulationen:computerbasiert}
+\subsection{Computerbasierte Simulationen}\label{grundlagen:simulationen:computerbasiert}
 Softwareseitige Simulationen sind gerade am Anfang des Entwicklungsprozesses ein äußerst wertvolles Tool zum Validieren des Systems. Auch aufgrund immer besser werdender Hardware können sie zunehmend in Industrie und Forschung verwendet werden \cite{Pepper2007}. 
 Eine Vielzahl an Simulator-Software wurde bereits und wird stetig weiter entwickelt \cite{Staranowicz2011, Harris2011}.
 Die Vorteile solcher Software sind vielfältig.
@@ -59,8 +59,8 @@ Moderne Simulationen besitzen bereits einen für viele Anwendungen ausreichenden
 Viele Sensoren und Aktuatoren sind bereits implementiert, und auch Robotermodelle stehen durch die Entwicklung beispielsweise in CAD zur Verfügung. Ist dies nicht der Fall, so ist mit entsprechendem Mehraufwand zu rechnen \cite{Bihlmaier2014}.
 Ist eine komplexe Umgebung zu erwarten, so kann die Konstruktion dieser einen erheblichen Zeitaufwand darstellen, da diese in den allermeisten Fällen manuell durchgeführt werden muss \cite{Afzal2020}.
 Insgesamt ergibt sich also ein hoher Zugewinn an Effizienz und Sicherheit, welcher in einem Gewinn an Kosten und Zeit resultiert, sofern Modelle des Robotersystems (und der Umwelt) bereits gegeben sind und ausreichende Hardware zum Ausführen der Simulationen zur Verfügung steht. Die in \cref{grundlagen:testanforderungen} angeführten Anforderungen lassen sich mit dieser Art von Simulation im Wesentlichen auf eine hohe Abdeckung und einen geringen Entwicklungsaufwand der Tests reduzieren. Dennoch treten Schwierigkeiten beim Nutzen von Simulationen auf, unter anderem wird in \cite{Afzal2020} die fehlende Dokumentation sowie die Stabilität der Software aufgezählt. Auch sind sie aufwändig zu Nutzen, und Features wie das Ausführen ohne GUI ("headless"), was sich auch gerade für CI-Pipelines anbietet, sind teilweise nicht vorhanden oder schwierig umzusetzen.
-\subsection{Hardware-in-the-loop (HIL)}
-Zwischen den in \cref{grundlagen:klassifikation:simulationen:computerbasiert} beschriebenen Simulationen und dem Testen im tatsächlichen Einsatzumfeld treten zwangsweise Diskrepanzen auf. Um beim Testen nicht direkt vollständig auf die Vorteile einer Simulation zu verzichten und einen Übergang zu einem "echten" Test zu schaffen, kann die im Kontext von Robotik auch als robot-in-the-loop bezeichnete Art der Simulation verwendet werden \cite{Hu2006}. Sie kann auch verwendet werden, sollte eine konventionelle Simulation nicht oder nur unzureichend möglich sein. Dabei wird die Umwelt simuliert und mit den Schnittstellen des zu testenden Roboters verbunden. Der Roboter erhält so die virtuelle Umgebung als Input und erzeugt entsprechenden Output in Form von beispielsweise Signalen an die Aktuatoren, welche wiederum als Input für die Simulation dienen. 
+\subsection{Hardware-in-the-loop (HIL)}\label{grundlagen:simulationen:hil}
+Zwischen den in \cref{grundlagen:simulationen:computerbasiert} beschriebenen Simulationen und dem Testen im tatsächlichen Einsatzumfeld treten zwangsweise Diskrepanzen auf. Um beim Testen nicht direkt vollständig auf die Vorteile einer Simulation zu verzichten und einen Übergang zu einem "echten" Test zu schaffen, kann die im Kontext von Robotik auch als robot-in-the-loop bezeichnete Art der Simulation verwendet werden \cite{Hu2006}. Sie kann auch verwendet werden, sollte eine konventionelle Simulation nicht oder nur unzureichend möglich sein. Dabei wird die Umwelt simuliert und mit den Schnittstellen des zu testenden Roboters verbunden. Der Roboter erhält so die virtuelle Umgebung als Input und erzeugt entsprechenden Output in Form von beispielsweise Signalen an die Aktuatoren, welche wiederum als Input für die Simulation dienen. 
 Zur Umsetzung ist also für komplexe Systeme neben dem zu testenden System entsprechende IO-Hardware sowie ein Computer mit hohen Datentransferraten und leistungsfähigen Prozessoren, um die Echtzeitfähigkeit zu garantieren, nötig \cite{Ledin1999}. Weiterhin muss spezielle Software gegeben sein, sodass HIL bezüglich der Anschaffungskosten als teuer, gerade im Vergleich zu rein softwaregesteuerten Simulationen (auch Software-in-the-loop genannt), einzustufen ist. Da neben den Kosten auch der Zeitaufwand und die Komplexität nicht unerheblich sind beschreibt \cite{Ledin1999} in welchen Situationen HIL als sinnvoll einzustufen ist:
 \begin{itemize}
 	\item wenn die Kosten eines Fehlers während eines tatsächlichen Einsatzes unakzeptabel hoch sind (z.B. Flugzeug)

sections/konzept.tex

 \chapter{Konzept}
-\section{Simulation}
+\section{Simulation}\label{konzept:simulation}
 Als Simulator bietet sich Gazebo an, da es sich einfach in ROS integrieren lässt und eine relativ hohe physikalische Korrektheit bietet. Verschiedene Physik-Engines können innerhalb von Gazebo verwendet werden.
 Auch werden Plug-Ins unterstützt, sodass sich auch nicht nativ implementiere Sachverhalte wie etwa die Umgebungstemperatur darstellen lassen \cite{Harris2011}. Gazebo ist daher und aufgrund seiner Stabilität in der Robotik und insbesondere in der Forschung die momentan am meisten verwendete Simulationssoftware.
 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 potentiell andere Simulatoren verwendet werden sollten \cite{Ivaldi2014}.