@@ -10,7 +10,7 @@ Auch hier ist die Simulation und die damit einhergehende korrekte Modellierung a
...
@@ -10,7 +10,7 @@ Auch hier ist die Simulation und die damit einhergehende korrekte Modellierung a
\subsection{Skalierbarkeit}
\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.
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}
\subsection{Aufwand}
Wie erwartet ist ein erhöhter Aufwand bei der initialen Implementierung von modell-basiertem Testen nötig. Obwohl der Code für den Cobot nur etwa 500 Zeilen umfasst, beinhaltet das Modell über 30 Zustände und dementsprechend viele Übergänge. 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, dass Logik in den Adapter ausgelagert werden muss.
Wie erwartet ist ein erhöhter Aufwand bei der initialen Implementierung von modellbasiertem Testen nötig. Obwohl der Code für den Cobot nur etwa 500 Zeilen umfasst, beinhaltet das Modell über 30 Zustände und dementsprechend viele Übergänge. 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, dass 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.\\
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.
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.
In dieser Arbeit wurde eine Testmethode zum systematischen modell-basierten Testen von Robotiksystemen unter ROS vorgestellt. Zur Modellierung wurde Uppaal benutzt, während dessen Erweiterung TRON online-Testing der exemplarisch überprüften Implementierung des Cobots ermöglichte. Am Ende fand eine Bewertung des Konzepts mittels eingangs aus aktueller Literatur ermittelter spezieller Anforderungen für Robotiksysteme statt.
In dieser Arbeit wurde eine Testmethode zum systematischen modellbasierten Testen von Robotiksystemen unter ROS vorgestellt. Zur Modellierung wurde Uppaal benutzt, während dessen Erweiterung TRON online-Testing der exemplarisch überprüften Implementierung des Cobots ermöglichte. Am Ende fand eine Bewertung des Konzepts mittels eingangs aus aktueller Literatur ermittelter spezieller Anforderungen für Robotiksysteme statt.
\\
\\
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.
Zusammengefasst lässt sich sagen, dass die in dieser Arbeit verwendete Testmethode des modellbasierten Testens 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 viele Lösungen existieren.
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 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.
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 modellbasiertes Testen für Robotiksysteme voranzubringen.
@@ -117,14 +117,19 @@ Neben den Testfällen kann potenziell aus den in 1. gegebenen Anforderungen eine
...
@@ -117,14 +117,19 @@ Neben den Testfällen kann potenziell aus den in 1. gegebenen Anforderungen eine
\item Folglich werden die Tests ausgeführt.
\item Folglich werden die Tests ausgeführt.
\item Die Ergebnisse werden analysiert, Fehler gefunden und behoben.
\item Die Ergebnisse werden analysiert, Fehler gefunden und behoben.
\end{enumerate}
\end{enumerate}
Bei Modell-basiertem 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.
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 Modell-basiertes 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}.
In \cite{Utting2011} wird eine weitere Klassifizierung von möglichen Modellen für Modell-basiertes 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}
\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}.
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}.
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}.
Als weiterer Vorteil ist bei dieser Methode anzugeben, dass das zu erstellende Modell (neben der Generierung der Testfälle) einen Überblick über die Funktionsweise basierend auf den Anforderungen des Systems gibt, sodass (neue) Entwickler dieses potenziell besser verstehen und daran arbeiten können.
Als weiterer Vorteil ist bei dieser Methode anzugeben, dass das zu erstellende Modell (neben der Generierung der Testfälle) einen Überblick über die Funktionsweise basierend auf den Anforderungen des Systems gibt, sodass (neue) Entwickler dieses potenziell besser verstehen und daran arbeiten können.
\subsubsection{Nachteile}
\subsubsection{Nachteile}
Nachteilig lässt sich anmerken, dass sich eine gewisse Redundanz zwischen dem zum Testen genutzten Modell und den Modellen zur Entwicklung nicht vermeiden lässt \cite{Pueschel2018}. Einen weiteren Nachteil stellt das Erarbeiten des Modells sowie eines Adapters zur Testausführung dar, da hier der Entwicklungsaufwand initial möglicherweise stark erhöht wird. Außerdem könnte es aufgrund der nötigen Verarbeitungszeit von Signalen zu Schwierigkeiten beim Testen kommen, wenn etwa eine sehr schnelle Kommunikation erforderlich ist.
Nachteilig lässt sich anmerken, dass sich eine gewisse Redundanz zwischen dem zum Testen genutzten Modell und den Modellen zur Entwicklung nicht vermeiden lässt \cite{Pueschel2018}. Einen weiteren Nachteil stellt das Erarbeiten des Modells sowie eines Adapters zur Testausführung dar, da hier der Entwicklungsaufwand initial möglicherweise stark erhöht wird. Weiterhin stellen sowohl das Modell sowie der Adapter zusätzliche potenzielle Fehlerquellen dar.
Außerdem könnte es aufgrund der nötigen Verarbeitungszeit von Signalen zu Schwierigkeiten beim Testen kommen, wenn etwa eine sehr schnelle Kommunikation erforderlich ist.
\subsubsection{Auswahl}
Insgesamt bildet modellbasiertes Testen von Robotiksystemen einen relativ neuen Ansatz und könnte sich als zukunftsweisend herausstellen, sollten sich die Nachteile durch moderne Tools zu großen Teilen vermeiden lassen. Gerade bei komplexen Systemen können Abhängigkeiten zwischen den Eingaben des Systems erfasst und überprüft werden, wodurch sich diese Testmethodik in der Robotik besonders anbietet.
Daher wird im Rest dieser Arbeit modellbasiertes Testen angewandt, wofür im folgenden Kapitel die Auswahl eines geeigneten Tools stattfindet.