Skip to content
Snippets Groups Projects
Commit f0ec0293 authored by Christoph Schröter's avatar Christoph Schröter
Browse files

No commit message

No commit message
parent d8b31e8f
Branches
No related tags found
No related merge requests found
<mxfile host="app.diagrams.net" modified="2021-06-26T11:58:34.441Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36" etag="Oy6-UVjRcIf5FK2X_SB3" version="14.8.0" type="device"><diagram id="BvBVtmby5S5bfYz1Z3JI" name="Page-1">7VhNc5swEP01PtaDBNhwTJ3U7SFxJk5T+6gBxWhGIEaWA+6vrzDiQwg7boIzk05PYZ+0y+7bfRLOyJ7F+ZyjNLplIaYjaIX5yL4eQQgs25Z/CmRfIg6wSmDDSag2NcCS/MaVp0J3JMRbbaNgjAqS6mDAkgQHQsMQ5yzTtz0zqr81RRtsAMsAURP9RUIRlagHpw3+HZNNVL0ZTPxyJUbVZlXJNkIhy1qQfTOyZ5wxUT7F+QzTgryKl9Lv25HVOjGOE3GOw9PcnwVTtrq/vZuvf0SPi6fn2RcV5QXRnSr48WFxpxIW+4qFbUZiihJpfVUOmAucH80E1PXJwcAsxoLv5Rbl4ClG1EhMlJk1/EJHYVGbW1+BSPV0U0duypYPqvK/YAEaLPxMU4QKv8NEU4MQznZJiIuYQHKSRUTgZYqCYjWTQpBYJGKqls+i7Hh7jvIIXY1Hx+QRuH08Vn6D8zg1eDSIw0l4VchSWgFF2y0JdK5wTsRKPltjmWVprgtTPV/nbWNfGYnMftU21q0Qhd34HazKsUwPh8YZ0BllWQLb8QCfqN1RhxPiG3yqpV5/S1tN6+tZhXFMkSAverp9fVRvuGdEFlJPjO3r0qtnpgpRlqm82odJJ5DT0TCwO7mUPBiBDmNVl/32SfOMSXtYLD9ApacF6QBHZ8UCY9szVQl7VQnHFxOmP4Awa42Np64ms1c0Viu6LWcV46iiBxSmd6YwnX9DmE5HmN1L88LCdIxJuwpRKjB/nzg5E5JelkjTt4YRa/3dUR9hcOz2aHViNn1yqQ8Rd1CdQk2n4EydAk2n8MN0Cj+DTqHrdobG+Zw6nQw4aUC7DlrXw2s3QnMLrFuDd/FJO/dTDf6/EU5OmjSbn6/l9uafAPbNHw==</diagram></mxfile>
\ No newline at end of file
<mxfile host="app.diagrams.net" modified="2021-08-04T15:36:26.018Z" agent="5.0 (X11)" etag="728TOAdahZFifj5337Si" version="14.9.4" type="device"><diagram id="BvBVtmby5S5bfYz1Z3JI" name="Page-1">3Vlbd9o4EP41PMKxfMWPgWTZ9rShLdlu86jYAnTWWK4tAuTXV8IytiRjzLXZ5iFHGllj65uZb2ZExxou1qMUJvPPJERRxzTCdce675im3wfsPxdscoFju7lgluIwF4FSMMFvSAgNIV3iEGXSg5SQiOJEFgYkjlFAJRlMU7KSH5uSSH5rAmdIE0wCGOnSf3FI57m0b3ql/G+EZ/PizcD185UFLB4WJ8nmMCSrish66FjDlBCajxbrIYo4dgUu+b6/9qzuPixFMW2z4fvIHwYe+fHl8+Po+cP8afx9OuwKLa8wWooDP30bP4oPppsChWyFFxGM2Wygv7bQgVKK1hWR+IwRIgtE0w17RKx6AhHhEq6Yrkp8TUfI5lVs+0IIhU1nO83lsdlAnPwIFEwNhX+SBEK+b+vQkQZISpZxiLhOwDBZzTFFkwQGfHXF4oDJ5nQRiWUdskZbtMYRyDjaOo6gFkfTuRKOnoajBhyKwzselmwWRDDLcCBjhdaY/mBjo8e+Mp8+86kY36+rk00xidnXV3fx+XOhkU/KfdtZsXGvM2dkmQao4ai24CKYzpDYiq1Pppv4H1cP4/Xy6+C/n48g7hY2QqHEM7pNK1arM1ohS1EEKX6V2anOkOINXwhmR9u5jOXLPrNzmkJFfnCxq8omiiK7LysCltWzNM/K4dG0bZ1rd/ZW/lYLrqP524c4WVLd6Rj4n+ALy0ySr8EIz2LuiMz6KGUCHnqYcf+dWFjgMOQ6BinK8Bt82erjfpPwE23P6Aw6zv3Ok7TY3SUmsblMBwfpwGuM/a7RswzPk2xQ8NiZPgIseQeZTjN0rv1qj+hfgC/K0Pek0DcOhH5JNF6VaEAj0bTii0YeqBJGE7G8E76wXSXMfftEvrBVRQrxXJkqrBpXcyMG1iDEr2w448Pxkm7pI19g76ms/Rmk4jeSitEDXt++DImYMjUpCq7HKbZmaF7Rdu9CmHB7nFXIpYQyTAi3ot9IB+1rOFMNMMvsibRWreNMVw9x9wLlcD1XHaZl1swkfDiN0Frw86CWqjMW17RVxQcqLGz0nEYerrD+CfWewq2nFYDmMXzeSN/AqCvSjQsVfGqTYJ1Y8JlK5Qhc86YE3tec8tt4ovul2qjWkKdm7b3BqRa5bTvVXYd78dDUK6bJJqNocR6vtYJqv1X24qe5TNsO1bgatemt/taNjCeS4CD7X8DotERRbe0uB6KeY6+aIPaQffsK/9gCvzFBNLHT4TagJm3sD/TflzaAbfSMyp9paVWK7Zd/RSN6bFIBvqfoBb3bXiEU6bG5MWAc0X0kISrLyFYtwgWKy/Pyl/kOi8u6TuwW5CFRR8kkB8njiHvIFuxxzn1BA6P8PqZwgCP72Kk3ipZ6o6gWUddmAvewY/6xLc55yQrsuau8zR2VY8iOc/KdtueodHljD9R/PxnBN/RC3l1i8dTEYtTUpBdKK2xa/kiaQ13+0mw9/AI=</diagram></mxfile>
\ No newline at end of file
File deleted
images/konzept.png

22.1 KiB

......@@ -394,7 +394,7 @@
journal = {{IEEE} Transactions on Software Engineering},
title = {On the value of static analysis for fault detection in software},
year = {2006},
month = {apr},
month = apr,
number = {4},
pages = {240--253},
volume = {32},
......@@ -403,4 +403,57 @@
publisher = {Institute of Electrical and Electronics Engineers ({IEEE})},
}
@PhdThesis{Shafique2010,
author = {Shafique, Muhammad},
school = {Carleton university},
title = {Systematic review of state based model based testing tools},
year = {2010},
file = {:shafique-systematicreviewofstatebasedmodelbasedtesting.pdf:PDF},
}
@Article{Silva2008,
author = {Jos{\'{e}} L. Silva and Jos{\'{e}} Creissac Campos and Ana C.R. Paiva},
journal = {Electronic Notes in Theoretical Computer Science},
title = {Model-based User Interface Testing With Spec Explorer and {ConcurTaskTrees}},
year = {2008},
month = apr,
pages = {77--93},
volume = {208},
doi = {10.1016/j.entcs.2008.03.108},
publisher = {Elsevier {BV}},
}
@TechReport{Campbell2005,
author = {Campbell, Colin and Grieskamp, Wolfgang and Nachmanson, Lev and Schulte, Wolfram and Tillmann, Nikolai and Veanes, Margus},
institution = {Technical Report MSR-TR-2005-59, Microsoft Research},
title = {Model-based testing of object-oriented reactive systems with Spec Explorer},
year = {2005},
}
@InCollection{Campbell2005a,
author = {Colin Campbell and Wolfgang Grieskamp and Lev Nachmanson and Wolfram Schulte and Nikolai Tillmann and Margus Veanes},
booktitle = {{FM} 2005: Formal Methods},
publisher = {Springer Berlin Heidelberg},
title = {Testing Concurrent Object-Oriented Systems with Spec Explorer},
year = {2005},
pages = {542--547},
doi = {10.1007/11526841_38},
}
@Article{Naujoks2011,
author = {Naujoks, Manuel and Fuch{\ss}, Thomas},
title = {Spec Explorer},
year = {2011},
}
@InProceedings{Botincan2007,
author = {Matko Botincan and Vedran Novakovic},
booktitle = {2007 9th International Conference on Telecommunications},
title = {Model-based Testing of the Conference Protocol with Spec Explorer},
year = {2007},
month = jun,
publisher = {{IEEE}},
doi = {10.1109/contel.2007.381861},
}
@Comment{jabref-meta: databaseType:bibtex;}
......@@ -81,6 +81,7 @@ Daher wurde 2013 mit ISO 29119 ein neuer internationaler Standard für die Entwi
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 die 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 diese 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.
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}
Die hier vorgestellten Methoden zur Testentwicklung bewegen sich auf dem Niveau der Testorganisation beziehungsweise des Testmanagements. Die Implementierung im Rahmen der dynamischen Testprozesse folgt in einem späteren Kapitel.
\subsection{Hierarchisches Testmodell}
Das hierarchisch aufgebaute Testmodell wie etwa von \cite{Lim2010} demonstriert stellt ein momentan häufig genutztes Modell zum effizienten Testen eines Systems dar.
Grundlegend besteht das Modell aus 3 zentralen Bestandteilen:
......@@ -97,7 +98,7 @@ Bibliotheken die ROS nicht benötigen sollen über vorgeschlagene Test-Framework
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 Integrationstests sind mit rostest möglich, da auch mehrere Nodes zusammen gestartet und damit getestet werden können.
In der Dokumentation zu ROS~\cite{OSRF2021} werden auch Vorteile und Kosten dieser Testmethodik angeführt, welche im Folgenden zusammengefasst werden.
\subsubsection{Vorteile}
Unit-Tests sorgen für ein besseres Codedesign im Rahmen der dynamischen Testprozesse, da der Entwickler gezwungen wird per Unit-Test testbaren Code zu schreiben, was bedeutet die Funktionalitäten des Systems möglichst separat zu halten. Das reduziert langfristig neben dem Entwicklungsaufwand des Systems selbst auch den des Testens, wenn etwa Änderungen an den Tests vorgenommen werden sollen. Ebenso sorgen separate Komponenten für eine einfachere Analysierbarkeit der Testergebnisse, da sich ein gefundener Fehler nur in den getesteten Komponenten befinden kann und somit der zu überprüfende Bereich des Quellcodes stark eingeschränkt wird.
Unit-Tests sorgen für ein besseres Codedesign, da der Entwickler gezwungen wird per Unit-Test testbaren Code zu schreiben, was bedeutet die Funktionalitäten des Systems möglichst separat zu halten. Das reduziert langfristig neben dem Entwicklungsaufwand des Systems selbst auch den des Testens, wenn etwa Änderungen an den Tests vorgenommen werden sollen. Ebenso sorgen separate Komponenten für eine einfachere Analysierbarkeit der Testergebnisse, da sich ein gefundener Fehler nur in den getesteten Komponenten befinden kann und somit der zu überprüfende Bereich des Quellcodes stark eingeschränkt wird.
Durch Regressionstests kann dem Entstehen von Fehlern sowohl bei Updates als auch bei Refactorings vorgebeugt werden. Auch beispielsweise Änderungen einer externen API können gefunden werden, sollten diese zu Problemen führen.
Die Tests ermöglichen ebenfalls eine einfachere Zusammenarbeit der Entwickler, da sie die Funktionalität einer Komponente (oder mehrerer) eindeutig beschreiben. Das Überprüfen von (voneinander unabhängigen) Komponenten lässt sich in vielen Fällen einfach parallelisieren und das automatische Ausführen der Tests ist ebenfalls leicht zu integrieren.
\subsubsection{Nachteile}
......@@ -106,16 +107,24 @@ Folglich ist eine gute Abdeckung der Systemanforderungen schwierig umzusetzen, u
\subsection{Modell-basiertes Testen}\label{grundlagen:testentwicklung:modell-basiert}
Das Modell-basierte 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, eignet sich Modell-basiertes Testen nicht für white box Tests. Der in \cite{Pueschel2018} dargestellte Testprozess besteht aus 5 Schritten:
Da das Modell von Implementierungsdetails unabhängig ist und sich auf die Ein- und Ausgaben des Systems fokussiert, eignet sich Modell-basiertes 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 werden und das Modell sollte möglichst abstrakt sein. Um später feststellen zu können, welche Anforderungen nicht erfüllt sind, ist es sinnvoll anzugeben welche Anforderungen zu welchem Teil des Modells gehören. Die modellierte Genauigkeit sowie die Teststrategien und -techniken können in einem Testplan festgelegt werden.
\item Aus dem Modell können nun Testfälle generiert werden, die sich zunächst auf dem selben Abstraktionslevel wie das Modell befinden. Neben den Testfällen kann aus den in 1. gegebenen Anforderungen eine sogenannte Anforderungsrückverfolgungsmatrix (und ein Modellabdeckungsbericht) erstellt werden, mit welcher bestimmt werden kann, welche Anforderungen beim Fehlschlagen von Tests verletzt wurden.
\item Aus dem Modell können nun (mithilfe von Auswahlkriterien) Testfälle generiert werden, die sich zunächst auf dem selben 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 potentiell aus den in 1. gegebenen Anforderungen eine sogenannte Anforderungsrückverfolgungsmatrix (und ein Modellabdeckungsbericht) erstellt werden, mit welcher bestimmt werden kann, 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}
Diese Methode der Testentwicklung ermöglicht erhebliche Einsparungen beim Entwicklungsaufwand, besonders bei Änderungen im Modell können ohne viel Aufwand neue Testfälle generiert werden. Die Anzahl an Testfällen lässt sich einfach anpassen, 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 potentiell besser verstehen und daran arbeiten können. 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}.
In \cite{Utting2011} wird eine 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 sich verschiedene vereinigen lassen. Bezüglich des Testauswahlkriteriums und der Technik zum Generieren der Tests können ebenfalls mehrere verwendet werden \cite{Utting2011}.
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 daraufhin, 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}.
\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}.
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 potentiell besser verstehen und daran arbeiten können.
\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.
\chapter{Konzept}
Aufgrund der genannten Vorteile von Modell-basiertem Testen wird dieses im folgenden umgesetzt. Zur Modellierung wird Uppaal\footnote{\url{https://uppaal.org/}} genutzt, eine Erweiterung namens TRON\footnote{\url{https://people.cs.aau.dk/~marius/tron/}} (Testing Realtime Systems Online) ermöglicht die Testgenerierung und direkte Ausführung aus dem erstellten Modell, indem ein Adapter erstellt wird. Als Vorbild dienen \cite{Ernits2015, Gummel2018}.
\section{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}.
\cref{konzept:bild} zeigt den schematischen Aufbau der Implementierung.
\section{Uppaal-Modellierung}
Vor dem Erstellen eines Modells müssen zunächst die gewünschten Anforderungen des Systems formal festgehalten werden. Diese formalen Anforderungen müssen dann quantisiert werden. Dazu 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 können formale Eigenschaften mithilfe des integrierten Verifiers überprüft werden. 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.
\begin{figure}[h]
\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.
\cref{konzept:bild} zeigt den schematischen Aufbau der Implementierung.
\begin{figure}[H]
\centering
\includegraphics[scale=.8]{./konzept.pdf}
\includegraphics[scale=.5]{./konzept.png}
\caption{Aufbau der Testmethode}
\label{konzept:bild}
\end{figure}
\section{Modell in Uppaal}
Ein System in Uppaal besteht aus einem oder mehreren Automaten. Sogenannte Channel und global deklarierte Variablen sorgen für eine Synchronisation dieser. Die Automaten selbst sind als erweiterte endliche nicht-deterministische Automaten einzuordnen. Durch Guards kann festgelegt werden, wann eine Kante verfügbar ist. Beim Entlanggehen einer Kante, welches auch durch die erwähnten Channel ausgelöst werden kann, können Variablen (global oder lokal) angepasst werden. Channel bieten sich als Modellierung der ROS Topics an.
Invarianten können global oder nur in bestimmten Zuständen angegeben werden. \cref{konzept:uppaal_tor} zeigt beispielhaft ein modelliertes System eines automatischen Tores mit einem dazugehörigen Schlüssel. Beim probabilistischen Auslösen dieses Schlüssels (mit einer Wahrscheinlichkeit von 1:101) wird das Tor über den Channel \textit{auslösen} informiert, wechselt in den Zustand \textit{öffnend} und setzt die Variable "zeit" auf 0. Nach 10000 vergangenen Zeiteinheiten wechselt das Tor dann in den Zustand \textit{offen}. Das Schließen läuft analog dazu ab.
\begin{figure}[h]
\centering
\includegraphics[scale=.4]{./uppaal_tor.png}
\caption{Beispiel-Modell in Uppaal}
\label{konzept:uppaal_tor}
\end{figure}
Vor dem Erstellen eines Modells müssen zunächst die gewünschten Anforderungen des Systems formal festgehalten werden. Diese formalen Anforderungen müssen dann quantisiert werden. Dazu bieten sich besonders für die nicht-funktionalen Eigenschaften Invarianten an.
Folglich kann das Systemverhalten modelliert werden.
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 können formale Eigenschaften mithilfe des integrierten Verifiers überprüft werden. Wie in \cref{grundlagen:testentwicklung:modell-basiert} erwähnt können, falls schon eine Implementierung vorhanden ist, auch Modelle die zur Entwicklung verwendet werden zur Verifizierung beitragen.
\section{TRON Adapter}
Channels, welche sowohl im modellierten Input als auch im System vorkommen stellen die Schnittstellen für den Adapter dar. Wird im Inputmodell ein Channel verwendet, so wird dieser sowohl im modellierten als auch im echten (oder simulierten) System über den Adapter ausgelöst. Asynchron dazu gibt das System den Output zurück an den Adapter, welcher dann mit den Gegebenheiten des Modells verglichen wird. Als built-in Adapter sind der sogenannte TraceAdapter, welcher über stdin/stdout kommuniziert, und der SocketAdapter, welcher zur Kommunikation eine TCP/IP-Verbindung aufbaut, verfügbar. Auch eigene Implementationen werden als dynamische C-Bibliothek ermöglicht. Für ROS bietet sich der SocketAdapter an, da die ROS-interne Kommunikation selbst auf TCP aufsetzt und so auch Übertragbarkeit gewährleistet wird. In \cite{Gummel2018} wird eine Erweiterung von TRON namens DTRON verwendet, um TRON für verteilte Systeme zu ermöglichen und mehrere ausgeführte Instanzen zugleich zu überprüfen. Diese Erweiterung ist zum aktuellen Zeitpunkt jedoch nicht verfügbar. Um den Adapter an da ROS-System anzuknüpfen, wird ein ROS-Node geschrieben, welcher die Pakete des Adapters annimmt und intern über die ROS Topics an das System weitergibt. Diese Übersetzung kann potentiell generisch implementiert werden, sodass zukünftig für ROS-Projekte beispielsweise nur eine Konfigurationsdatei erforderlich ist. Um die Umgebung in der Simulation auch für TRON verfügbar zu machen, müssen die dafür vorhandenen Daten folglich auch über ein ROS Topic im System veröffentlicht und dann durch den Adapter weitergereicht werden. Im Leitfaden zu TRON~\cite{TronManual} sind die verwendeten Pakete beschrieben und werden im Folgenden in den Kontext eingeordnet und erläutert wie diese verwendet werden.
Im Leitfaden zu TRON~\cite{TronManual} sind die verwendeten Pakete beschrieben und werden im Folgenden in den Kontext eingeordnet und erläutert wie diese verwendet werden.
\subsection{Adapter-Phasen}
\subsubsection{Konfigurierungsphase}
......@@ -42,9 +31,10 @@ Zunächst wird der SocketAdapter auf eine eingehende Verbindung warten. Folglich
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.
\subsection{Implementierung}
Der implementierte Adapter verwendet vom Betriebssystem bereitgestellte Sockets für die Kommunikation mit TRON und hält globale Variablen, in welchen die Abbildungen von Channels auf Topics sowie die zugehörigen Variablen beschrieben werden. Die Verwendung dieser wird im nächsten Abschnitt dargestellt.
Bei der Implementierung des Adapters (siehe 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.\\
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 TRON-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.
Templates ermöglichen generische Callbacks mit denen den TRON-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.
\subsubsection{Verwendung}
Zur Verwendung des Adapters müssen primär Veränderungen in der Funktion \textit{configuration\_phase vorgenommen werden}. Die Struktur \textit{Mapping} beschreibt das Verhältnis von einem Channel zu einem Topic und muss daher für jedes gewünschte Paar 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 können Variablen hinzugefügt werden. Parameter dafür sind in dieser Reihenfolge: der Name in Uppaal, der Offset (in Byte) von der letzten im Mapping vorhandenen Variable und schließlich optional Zeiger zu Konvertierungsfunktionen (von TRON zum Topic und umgekehrt). Letztere lassen sich verwenden, wenn Variablen des Topics nicht in dem von TRON verwendeten 32-Bit-Integer Format vorliegen oder Felder variabler Länge genutzt werden. Anzumerken ist hier, dass durch den Offset der Variable ausgehend von seinem Vorgänger die Variablen in der Reihenfolge angegeben werden müssen, in der sie innerhalb der ROS-Nachricht vorkommen.
......@@ -77,4 +67,4 @@ Diese Variante wird auch bei einer später im Text folgenden beispielhaften Anwe
\section{actionlib}\label{konzept:actionlib}
Die actionlib \cite{Actionlib} baut ein Protokoll auf den Nachrichten von ROS auf und ermöglicht Kommunikation von Nodes für das Ausführen einer bestimmten Aufgabe mithilfe einer Client-Server-Architektur. Diese unterscheidet sich von den \textit{ROS Services}\footnote{\url{http://wiki.ros.org/Services}} insbesondere durch die ermöglichte Asynchronität, welche für konstante Rückmeldung des Servers sowie weitere Anfragen des Clients (wie etwa nach der Präemptierung einer Aktion) genutzt wird.
Dazu wurde die Implementierung eines endlichen Automaten realisiert, was sich neben den verwendeten ROS-Nachrichten für das Testen mittels TRON anbietet. Daher wird im Folgenden die Integration des Testadapters in ein System, welches die actionlib verwendet, beispielhaft vollzogen.
\ No newline at end of file
Dazu wurde die Implementierung eines endlichen Automaten realisiert, was sich neben den verwendeten ROS-Nachrichten für das Testen mittels TRON anbietet. Daher wird im Folgenden die Möglichkeit einer Integration des Testadapters in ein System, welches die actionlib verwendet, beispielhaft überprüft.
\ No newline at end of file
\chapter{State of the Art}
Neben der bereits erwähnten Integration von Unit-Tests in ROS und rostests, welche für Integrations- und System-Tests genutzt werden können existiert eine Reihe von Tools für Model-basiertes Testen wie in \cite{Shafique2010} dargestellt. Im Rahmen dieser Arbeit können jedoch nur nicht-kommerzielle Lösungen genauer untersucht werden. Weiterhin muss das gewählte Tool mit ROS und daher mit C++ kompatibel sein. Die Auswahl eines solchen Tools ist in die Testmanagementprozesse einzuordnen.
\section{Spec Explorer (2010)}
Der Spec Explorer von Microsoft\footnote{\url{https://marketplace.visualstudio.com/items?itemName=SpecExplorerTeam.SpecExplorer2010VisualStudioPowerTool-5089}} ist ein Tool für Modell-basiertes Testen und als kostenlose Erweiterung für Visual Studio vorhanden. Da jedoch eine kostenpflichtige Visual Studio Version notwendig ist, ist dieses Tool als kommerziell einzustufen und kann im Rahmen dieser Arbeit nicht verwendet werden. Es ist jedoch aufgrund seiner Verbreitung hier zu erwähnen und wurde bereits häufig im akademischen Rahmen verwendet \cite{Silva2008, Campbell2005, Campbell2005a, Naujoks2011, Botincan2007}. Ein abstraktes Modell des zu testenden Systems wird dabei in C\# implementiert, es sind jedoch auch andere Sprachen möglich. Das Tool ist umfangreich und bietet sowohl online- als auch offline-Testing an, wobei sich durch Adapter sämtliche Programmiersprachen verwenden lassen. Ebenso wird eine Validierung des Modells selbst unterstützt und es können verschiedene Testauswahlkriterien angewandt werden.
\section{Uppaal TRON}
Uppaal\footnote{\url{https://uppaal.org/}} ist ein für akademische Zwecke frei verfügbares Tool zum Validieren von Modellen und wurde bereits in \cite{Ernits2015, Gummel2018} im Zusammenhang mit ROS verwendet. Dabei wird eine Erweiterung namens TRON\footnote{\url{https://people.cs.aau.dk/~marius/tron/}} (Testing Realtime Systems Online) benutzt, welche das Modell im Rahmen eines online-Tests durchläuft, was sich wie in \cref{grundlagen:testentwicklung:modell-basiert} dargestellt für Robotiksysteme anbietet. 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 zum momentanen Zeitpunkt nicht zur Verfügung und kann daher nicht verwendet werden. Im folgenden wird sowohl das Modell unter Uppaal sowie die Funktionsweise des TRON-Adapters erläutert.
\subsection{Modell in Uppaal}
Ein System in Uppaal besteht aus einem oder mehreren Automaten. Sogenannte Channel und global deklarierte Variablen sorgen für eine Synchronisation dieser. Die Automaten selbst sind als erweiterte endliche nicht-deterministische Automaten einzuordnen, die auch Zeitangaben unterstützen. Durch Guards kann festgelegt werden, wann eine Kante verfügbar ist. Beim Entlanggehen einer Kante, welches auch durch die erwähnten Channel ausgelöst werden kann, können Variablen (global oder lokal) angepasst werden. Channel bieten sich als Modellierung der ROS Topics an.
Invarianten können global oder nur in bestimmten Zuständen angegeben werden. \cref{konzept:uppaal_tor} zeigt beispielhaft ein modelliertes System eines automatischen Tores mit einem dazugehörigen Schlüssel. Beim probabilistischen Auslösen dieses Schlüssels (mit einer Wahrscheinlichkeit von 1:101) wird das Tor über den Channel \textit{auslösen} informiert, wechselt in den Zustand \textit{öffnend} und setzt die Variable "zeit" auf 0. Nach 10000 vergangenen Zeiteinheiten wechselt das Tor dann in den Zustand \textit{offen}. Das Schließen läuft analog dazu ab.
\begin{figure}[h]
\centering
\includegraphics[scale=.4]{./uppaal_tor.png}
\caption{Beispiel-Modell in Uppaal}
\label{konzept:uppaal_tor}
\end{figure}
\subsection{TRON Adapter}
Channels, welche sowohl im modellierten Input als auch im System vorkommen stellen die Schnittstellen für den Adapter dar. Wird im Inputmodell ein Channel verwendet, so wird dieser sowohl im modellierten als auch im echten (oder simulierten) System über den Adapter ausgelöst. Asynchron dazu gibt das System den Output zurück an den Adapter, welcher dann mit den Gegebenheiten des Modells verglichen wird. Als built-in Adapter sind der sogenannte TraceAdapter, welcher über stdin/stdout (Standard-Pipes von Linux) kommuniziert, und der SocketAdapter, welcher zur Kommunikation eine TCP/IP-Verbindung aufbaut, verfügbar. Auch eigene Implementationen werden als dynamische C-Bibliothek ermöglicht. Für ROS bietet sich der SocketAdapter an, da die ROS-interne Kommunikation selbst auf TCP aufsetzt und so auch Übertragbarkeit gewährleistet wird.
\section{GraphWalker?}
\url{http://graphwalker.github.io/}
......@@ -18,9 +18,6 @@
hyperref,
]{biblatex}
\addbibresource{literatur.bib}
\AtEveryBibitem{%
\clearfield{note}%
}
\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{..}
......@@ -125,13 +122,14 @@
\input{sections/einleitung.tex}
\input{sections/grundlagen.tex}
\input{sections/stateoftheart.tex}
\input{sections/konzept.tex}
\input{sections/ausfuehrung.tex}
\printbibliography[heading=bibintoc]\label{sec:bibliography}%
\appendix
\input{sections/appendix.tex}
%\input{sections/appendix.tex}
\confirmation
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment