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

No commit message 

No commit message
parent 2e4b1986
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
sections/appendix.tex
+ 2
− 2
View file @ df2e023d
\chapter{Git-Repositorys} \chapter{Git-Repositorys}\label{git-repos}
Das Repository für die actionlib-Integration sowie für das Testen des Cobots sind unter folgenden Links erreichbar: Das Repository für die actionlib-Integration sowie für das Testen des Cobots sind unter folgenden Links erreichbar:
\begin{itemize} \begin{itemize}
\item \url{https://git-st.inf.tu-dresden.de/CS/actionlib_tron} \item \url{https://git-st.inf.tu-dresden.de/CS/actionlib_tron}
\item \url{https://git-st.inf.tu-dresden.de/CS/cobot1_tron_testing} \item \url{https://git-st.inf.tu-dresden.de/CS/cobot1_tron_testing}
\end{itemize} \end{itemize}
Die Adapter-Implementierung und jeweils genutzten Uppaal-Modelle (als XML-Datei) sind in beiden Fällen vorhanden. Beim Cobot sind außerdem die für die Test-Ausführung und -Analyse genutzten Bash-Scripts zu finden. Die Adapter-Implementierung und jeweils genutzten Uppaal-Modelle (als XML-Datei) sind in beiden Fällen vorhanden. Beim Cobot sind außerdem die für die Test-Ausführung und -Analyse genutzten Bash-Scripts zu finden.
\chapter{Header der Adapter-Implementierung} \chapter{Header der Adapter-Implementierung}\label{header}
\lstset{ \lstset{
escapeinside={(@*}{*@)} escapeinside={(@*}{*@)}
} }
......
sections/einleitung.tex
+ 1
− 1
View file @ df2e023d
...@@ -25,6 +25,6 @@ In diesem Abschnitt wird nach einer Einleitung in das Thema und die gestellten A ...@@ -25,6 +25,6 @@ In diesem Abschnitt wird nach einer Einleitung in das Thema und die gestellten A
Die Grundlagen werden dafür im zweiten Kapitel geschaffen, indem zuerst ein kurzer Überblick über wichtige Begriffe und Klassifikationen im Rahmen der Testentwicklung gegeben wird. Die Grundlagen werden dafür im zweiten Kapitel geschaffen, indem zuerst ein kurzer Überblick über wichtige Begriffe und Klassifikationen im Rahmen der Testentwicklung gegeben wird.
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 modellbasierten Testen, welches im Rest der Arbeit verwendet wird.\\ 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 modellbasierten 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.\\ 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.\\ 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 das System 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.\\ 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. 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/evaluation.tex
+ 2
− 2
View file @ df2e023d
...@@ -17,6 +17,6 @@ Bezüglich der Ausführbarkeit ist festzuhalten, dass eine einfache Automatisier ...@@ -17,6 +17,6 @@ Bezüglich der Ausführbarkeit ist festzuhalten, dass eine einfache Automatisier
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. 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} \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.\\ 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. Das echte Einsatzumfeld des Cobots ist mir nicht bekannt, daher lassen sich dazu keine 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} \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. 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ßen sich mit der vorgestellten Methode wie bereits erwähnt auch nur schwer implementieren.
\ No newline at end of file \ No newline at end of file
sections/fallbeispiel.tex
+ 9
− 8
View file @ df2e023d
This diff is collapsed.
sections/grundlagen.tex
+ 7
− 7
View file @ df2e023d
This diff is collapsed.
sections/konzept.tex
+ 8
− 8
View file @ df2e023d
...@@ -8,10 +8,10 @@ Auch sind Plug-Ins unterstützt, sodass sich auch nicht nativ implementiere Sach ...@@ -8,10 +8,10 @@ Auch sind Plug-Ins unterstützt, sodass sich auch nicht nativ implementiere Sach
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 potenziell andere Simulatoren verwendet werden sollten \cite{Ivaldi2014}. 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 potenziell andere Simulatoren verwendet werden sollten \cite{Ivaldi2014}.
\section{Uppaal-Modellierung} \section{Uppaal-Modellierung}
Vor dem Erstellen eines Modells müssen zunächst die gewünschten Anforderungen des Systems formal festgehalten werden. Diese formalen Anforderungen sind dann zu quantisieren. Dabei bieten sich besonders für die nicht-funktionalen Eigenschaften Invarianten im Modell an. Vor dem Erstellen eines Modells müssen zunächst die gewünschten Anforderungen des Systems formal festgehalten werden. Diese formalen Anforderungen sind dann zu quantisieren. Dabei 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 lassen sich formale Eigenschaften mithilfe des integrierten Verifiers überprüfen. 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. Da für die Testgenerierung auch ein Modell für die Inputs des Systems nötig ist, kann das Modellverhalten auch innerhalb von Uppaal verifiziert werden. Ebenso lassen sich formale Eigenschaften mithilfe des integrierten Verifiers überprüfen. 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.
\section{TRON-Adapter} \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. Um den Adapter an da ROS-System anzuknüpfen, wurde eine Adapter-Klasse geschrieben, welche 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. \cref{konzept:bild} zeigt den schematischen Aufbau der Implementierung.
\begin{figure}[H] \begin{figure}[H]
\centering \centering
...@@ -31,17 +31,17 @@ Zunächst wird der SocketAdapter auf eine eingehende Verbindung warten. Folglich ...@@ -31,17 +31,17 @@ Zunächst wird der SocketAdapter auf eine eingehende Verbindung warten. Folglich
\label{konzept:tron_konfigurierung} \label{konzept:tron_konfigurierung}
\end{figure} \end{figure}
\subsubsection{Ausführungsphase} \subsubsection{Ausführungsphase}
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. 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 Nachrichten aus einem Channel-Identifier, 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} \subsection{Implementierung}
Der implementierte Adapter verwendet vom Betriebssystem bereitgestellte Sockets für die Kommunikation mit TRON und hält relevante Variablen, in welchen die Abbildungen von Channel auf Topics sowie die zugehörigen Variablen beschrieben werden, innerhalb einer Klasse. Die Verwendung dieser wird im nächsten Abschnitt dargestellt. Der implementierte Adapter verwendet vom Betriebssystem bereitgestellte Sockets für die Kommunikation mit TRON und hält relevante Variablen, in welchen die Abbildungen von Channel auf Topics sowie die zugehörigen Variablen beschrieben werden, innerhalb einer Klasse. Die Verwendung dieser wird im nächsten Abschnitt dargestellt.
Bei der Implementierung des Adapters (siehe Header-Datei im 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.\\ Bei der Implementierung des Adapters (siehe \cref{header}) 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 Anzahl an 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. 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 Uppaal-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. Templates ermöglichen generische Callbacks, mit denen den Uppaal-Variablen Byte-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} \subsubsection{Verwendung}
Zur Verwendung des Adapters muss eine Instanz der Klasse \textit{TRON\_Adapter} erstellt werden. Ihr wird die Ziel-IP-Adresse sowie der Port übergeben, über den eine bereits laufende TRON Instanz erreichbar ist. Die Struktur \textit{Mapping} beschreibt das Verhältnis von einem Channel zu einem Topic und muss daher für jedes gewünschte Paar mittels der Funktion \textit{createMapping} 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. Zur Verwendung des Adapters muss eine Instanz der Klasse \textit{TRON\_Adapter} erstellt werden. Ihr wird die Ziel-IP-Adresse sowie der Port übergeben, über den eine bereits laufende TRON Instanz erreichbar ist. Die Struktur \textit{Mapping} beschreibt das Verhältnis von einem Channel zu einem Topic und muss daher für jedes gewünschte Paar mittels der Funktion \textit{createMapping} 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 lassen sich Variablen hinzufügen. Dazu wird dem Adapter über \textit{add\_var\_to\_mapping} neben dem Mapping selbst der Name der Variablen in Uppaal übergeben. Optionale Parameter wie zum Beispiel der Offset können angegeben werden, wenn die Übersetzung mittels Byte-Positionen innerhalb der ROS-Nachricht stattfinden soll. Der Offset beginnt vom Ende des letzten Feldes, sodass in diesem Fall die Variablen in der richtigen Reihenfolge angegeben werden müssen. \\ Nach der Initialisierung lassen sich Variablen hinzufügen. Dazu wird dem Adapter über \textit{add\_var\_to\_mapping} neben dem Mapping selbst der Name der Variablen in Uppaal übergeben. Optionale Parameter wie zum Beispiel der Offset können angegeben werden, wenn die Übersetzung mittels Byte-Positionen innerhalb der ROS-Nachricht stattfinden soll. Der Offset beginnt vom Ende des letzten Feldes, sodass in diesem Fall die Variablen in der richtigen Reihenfolge angegeben werden müssen.
\\ Für Input-Channel ist zusätzlich ein Callback zu spezifizieren, welcher als Parameter eine Referenz zum entsprechenden Mapping und ein Array von 32-Bit-Integern, den von TRON übergebenen Variablen, bekommt. \textit{mapping\_callback\_to\_topic} kann dafür verwendet werden, und mit den festgelegten Byte-Positionen zu arbeiten. Output-Channel haben keinen separaten Callback, da dieser beim Abonnieren eines Topics durch die ROS API festgelegt wird. Wie bei den Input-Channel ist dafür eine generische Funktion vorhanden, \textit{mappings\_callback\_to\_TRON}, welche bei einfachen Nachrichten verwendet werden kann. Anzumerken ist hierbei, dass diese Methode alle Channel informiert, die als Output mit dem Topic angegeben sind, während bei den Inputs jeweils eine Funktion im Mapping hinterlegt ist. \\ Für Input-Channel ist zusätzlich ein Callback zu spezifizieren, welcher als Parameter eine Referenz zum entsprechenden Mapping und ein Array von 32-Bit-Integern, den von TRON übergebenen Variablen, bekommt. \textit{mapping\_callback\_to\_topic} kann dafür verwendet werden, um mit den festgelegten Byte-Positionen zu arbeiten. Output-Channel haben keinen separaten Callback, da dieser beim Abonnieren eines Topics durch die ROS API festgelegt wird. Wie bei den Input-Channel ist dafür eine generische Funktion vorhanden, \textit{mappings\_callback\_to\_TRON}, welche bei einfachen Nachrichten verwendet werden kann. Anzumerken ist hierbei, dass diese Methode alle Channel informiert, die als Output mit dem Topic angegeben sind, während bei den Inputs jeweils eine Funktion im Mapping hinterlegt ist.
\\ Schließlich muss das Mapping der Liste \textit{mappings} hinzugefügt werden. Zu beachten ist, dass für jedes Topic, welches im Rahmen von Input-Mappings verwendet wird ein entsprechender \textit{ros::Publisher} in der Liste \textit{input\_publishers} vorhanden sein muss. Analog dazu müssen \textit{ros::Subscriber} zu \textit{output\_subscriber} hinzugefügt werden. \\ Schließlich muss das Mapping der Liste \textit{mappings} hinzugefügt werden. Zu beachten ist, dass für jedes Topic, welches im Rahmen von Input-Mappings verwendet wird ein entsprechender \textit{ros::Publisher} in der Liste \textit{input\_publishers} vorhanden sein muss. Analog dazu müssen \textit{ros::Subscriber} zu \textit{output\_subscriber} hinzugefügt werden.
\\ Neben den Mappings muss auch die Zeiteinheit sowie der Zeitraum für den getestet werden soll festgelegt werden, dies geschieht über einen Funktionsaufruf an \textit{set\_time\_unit\_and\_timeout}. \\ Neben den Mappings muss auch die Zeiteinheit sowie der Zeitraum für den getestet werden soll festgelegt werden, dies geschieht über einen Funktionsaufruf an \textit{set\_time\_unit\_and\_timeout}.
\\ Für das in \cref{konzept:uppaal_tor} dargestellte Modell könnte die Konfigurierung etwa so aussehen: \\ Für das in \cref{konzept:uppaal_tor} dargestellte Modell könnte die Konfigurierung etwa so aussehen:
...@@ -56,7 +56,7 @@ adapter.mappings.push_back(map); ...@@ -56,7 +56,7 @@ adapter.mappings.push_back(map);
// Output Channel "position" wird auf Topic "/position" abgebildet // Output Channel "position" wird auf Topic "/position" abgebildet
map = adapter.createMapping("/position", "position", false); map = adapter.createMapping("/position", "position", false);
// es wird eine Variable namens "pos" uebertragen, die sich bei Offset 0 (direkt am Anfang der Nachricht) befindet // es wird eine Variable namens "pos" uebertragen, die sich bei Offset 0 (direkt am Anfang der Nachricht) befindet
adapter.add_var_to_mapping(map, "akt_position", 0); adapter.add_var_to_mapping(map, "pos", 0);
adapter.mappings.push_back(map); adapter.mappings.push_back(map);
adapter.output_subscribers.push_back( adapter.output_subscribers.push_back(
nh.subscribe<std_msgs::Int32>("/position", 10, nh.subscribe<std_msgs::Int32>("/position", 10,
...@@ -71,6 +71,6 @@ adapter.set_time_unit_and_timeout(1000, 100000); ...@@ -71,6 +71,6 @@ adapter.set_time_unit_and_timeout(1000, 100000);
Der Channel \textit{position} sowie die Variable \textit{pos} sind in \cref{konzept:uppaal_tor} nicht dargestellt, werden hier aber verwendet, um einen Output-Channel sowie das Übertragen einer Variable zu demonstrieren. Der Channel \textit{position} sowie die Variable \textit{pos} sind in \cref{konzept:uppaal_tor} nicht dargestellt, werden hier aber verwendet, um einen Output-Channel sowie das Übertragen einer Variable zu demonstrieren.
Ein besonderes Augenmerk liegt auf dem Callback des ros::Subscriber. Dieser benötigt nach dem boost::bind der Adapter-Instanz an die Funktion einen expliziten Cast zu einer boost::function des entsprechenden Typs, da der Compiler diesen nicht zuverlässig selbstständig ableiten kann und dennoch keinen Fehler ausgibt. Dies ist auf der zum Thema passenden Übersichtsseite von ROS\footnote{\url{http://wiki.ros.org/roscpp/Overview/Publishers\%20and\%20Subscribers}} in einer Notiz unter 2.3.3 angemerkt. Ein besonderes Augenmerk liegt auf dem Callback des ros::Subscriber. Dieser benötigt nach dem boost::bind der Adapter-Instanz an die Funktion einen expliziten Cast zu einer boost::function des entsprechenden Typs, da der Compiler diesen nicht zuverlässig selbstständig ableiten kann und dennoch keinen Fehler ausgibt. Dies ist auf der zum Thema passenden Übersichtsseite von ROS\footnote{\url{http://wiki.ros.org/roscpp/Overview/Publishers\%20and\%20Subscribers}} in einer Notiz unter 2.3.3 angemerkt.
\\ \\
In den meisten praktischen Fällen ist das verwenden eigens für bestimmte Nachrichten implementierter Callbacks sinnvoller, da ROS-Nachrichten sehr komplex sein können und viele Felder variabler Größe verwendet werden, wofür Konvertierungsfunktionen nötig wären. Außerdem wird dadurch die Lesbarkeit des Codes erhöht und folglich die Wartung erleichtert. Benutzerdefinierte Callbacks können \textit{report\_now} und \textit{publish\_to\_topic} nutzen um Nachrichten zu TRON beziehungsweise zu den Topics zu senden. In den meisten praktischen Fällen ist das Verwenden eigens für bestimmte Nachrichten implementierter Callbacks sinnvoller, da ROS-Nachrichten sehr komplex sein können und viele Felder variabler Größe verwendet werden, wofür Konvertierungsfunktionen nötig wären. Außerdem wird dadurch die Lesbarkeit des Codes erhöht und folglich die Wartung erleichtert. Benutzerdefinierte Callbacks können \textit{report\_now} und \textit{publish\_to\_topic} nutzen um Nachrichten zu TRON beziehungsweise zu den Topics zu senden.
Auch hier ist zu erwähnen, dass die Übersetzung von einem Topic zu mehreren Channels innerhalb lediglich einer Methode stattfinden kann, die dem ROS-Subscriber als Parameter übergeben werden muss. Auch hier ist zu erwähnen, dass die Übersetzung von einem Topic zu mehreren Channels innerhalb lediglich einer Methode stattfinden kann, die dem ROS-Subscriber als Parameter übergeben werden muss.
Diese Variante wird auch bei einer später im Text folgenden beispielhaften Anwendung des Adapters für die sogenannte \textit{actionlib} sowie im durchgeführten Testbeispiel (siehe \cref{fallbeispiel}) verwendet. Diese Variante wird auch bei einer später im Text folgenden beispielhaften Anwendung des Adapters für die sogenannte \textit{actionlib} sowie im durchgeführten Testbeispiel (siehe \cref{fallbeispiel}) verwendet.
sections/stateoftheart.tex
+ 1
− 1
View file @ df2e023d
...@@ -36,4 +36,4 @@ Das Model-based Adaptivity Test Environment\footnote{\url{http://81.88.24.184/qm ...@@ -36,4 +36,4 @@ Das Model-based Adaptivity Test Environment\footnote{\url{http://81.88.24.184/qm
\end{figure} \end{figure}
\section{Tool-Auswahl} \section{Tool-Auswahl}
Uppaal und TRON werden im weiteren Verlauf dieser Arbeit exemplarisch angewandt. Zum einen kann das Verhalten der Modelle durch die verschiedenen Typen von Knoten und Kanten genau bestimmt werden, zum anderen ist die Verifizierung ein hilfreiches Feature. Außerdem wurde vom Lehrstuhl bereits mit dem Tool, jedoch ohne TRON, gearbeitet. 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 momentan nicht zur Verfügung und kann daher nicht verwendet werden. Uppaal und TRON werden im weiteren Verlauf dieser Arbeit exemplarisch angewandt. Zum einen kann das Verhalten der Modelle durch die verschiedenen Typen von Knoten und Kanten genau bestimmt werden, zum anderen ist die Verifizierung ein hilfreiches Feature. Außerdem wurde vom Lehrstuhl bereits mit dem Tool, jedoch ohne TRON, gearbeitet. Die Erweiterung von TRON namens DTRON (Distributed TRON) für verteilte Systeme sowie das verwendete Adapter-Template von \cite{Ernits2015, Gummel2018} steht momentan nicht zur Verfügung und kann daher nicht verwendet werden.
\ No newline at end of file \ No newline at end of file
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment