\section{Integration mit actionlib}\label{actionlib:integration}
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.
...
...
@@ -101,18 +101,19 @@ Nach dem erfolgreichen Befüllen kam es in zwei Fällen zum Umwerfen des Glases
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 zu sehen.
\\\\\\
\begin{center}
\begin{tabular}[]{c|c|c}
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.
