diff --git a/sections/einleitung.tex b/sections/einleitung.tex
index 5023f701fbb30604275283786b390c5720d74b59..bbb4f58f3046afcc3d5606635cc0fac275d941a1 100644
--- a/sections/einleitung.tex
+++ b/sections/einleitung.tex
@@ -23,7 +23,7 @@ Schließlich soll die angewandte Testmethodik im Rahmen der am Anfang ermittelte
 \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. \\
 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 Modell-basierten 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.\\
 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.\\
diff --git a/sections/evaluation.tex b/sections/evaluation.tex
index 881fc90ad6082a8577a97debc492a460284dd518..d41d66f5a03ee6fa6a0ddaa087ec330f290cb983 100644
--- a/sections/evaluation.tex
+++ b/sections/evaluation.tex
@@ -10,7 +10,7 @@ Auch hier ist die Simulation und die damit einhergehende korrekte Modellierung a
 \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 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.
+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 modellbasierten 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.\\
 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}
diff --git a/sections/fazit.tex b/sections/fazit.tex
index 17a4804d2f79018e91f51222f24ad7f9db39d09d..597cb130baa561a7ab78ca8d760d20f00f373b6c 100644
--- a/sections/fazit.tex
+++ b/sections/fazit.tex
@@ -3,6 +3,6 @@ In dieser Arbeit wurde eine Testmethode zum systematischen modellbasierten Teste
 \\
 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 modellbasiertes 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 modellbasiertes Testen für Robotiksysteme voranzubringen.
\ No newline at end of file
diff --git a/sections/grundlagen.tex b/sections/grundlagen.tex
index d71f931cd32c1568ae502fd68c22fa4503f0d5a5..dd6820f228dd60bc76bcf31665f7be8f7c22a478 100644
--- a/sections/grundlagen.tex
+++ b/sections/grundlagen.tex
@@ -106,9 +106,9 @@ Die Tests ermöglichen ebenfalls eine einfachere Zusammenarbeit der Entwickler,
 Die Dokumentation zu ROS erwähnt als Nachteile die Entwicklungs- und Instandhaltungskosten der Teststruktur. Außerdem kann bei Robotersystemen nur eine sehr beschränkte Teilmenge aller Input-Output-Paare getestet werden und der Entwickler muss für jeden Test Kriterien angeben, um festzulegen, wann ein Test als erfolgreich oder fehlgeschlagen gilt. Die Komplexität sorgt auch dafür, dass Abhängigkeiten verschiedener Inputs voneinander nur schwer überprüft werden können \cite{Pueschel2018}.
 Folglich ist eine gute Abdeckung der Systemanforderungen schwierig umzusetzen, und um diese zu erreichen ein hoher Zeit- und Entwicklungsaufwand nötig.
 
-\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 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:
+\subsection{Modellbasiertes Testen}\label{grundlagen:testentwicklung:modell-basiert}
+Das modellbasierte 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 und sich auf die Ein- und Ausgaben des Systems fokussiert, eignet sich modellbasiertes 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 sein und das Modell sollte möglichst abstrakt sein. Um später feststellen zu können, welche Anforderungen nicht erfüllt sind, ist es sinnvoll diese beim entsprechenden Teil des Modells anzugeben. Die modellierte Genauigkeit sowie die Teststrategien und -Techniken können in einem Testplan festgelegt werden.
 \item Aus dem Modell lassen sich nun (mithilfe von Auswahlkriterien) Testfälle generieren, die sich zunächst auf demselben 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.
@@ -118,7 +118,7 @@ Neben den Testfällen kann potenziell aus den in 1. gegebenen Anforderungen eine
 \item Die Ergebnisse werden analysiert, Fehler gefunden und behoben.
 \end{enumerate}
 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 modellbasiertes 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}.
diff --git a/sections/stateoftheart.tex b/sections/stateoftheart.tex
index 47ec9d40ef287ef0ad86e1ea1089e45de95605d4..ff70314231cbd02c37dc97865f51ca30b44b6dc4 100644
--- a/sections/stateoftheart.tex
+++ b/sections/stateoftheart.tex
@@ -1,7 +1,7 @@
 \chapter{Tools für MBT}
 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.
+Der Spec Explorer von Microsoft\footnote{\url{https://marketplace.visualstudio.com/items?itemName=SpecExplorerTeam.SpecExplorer2010VisualStudioPowerTool-5089}} ist ein Tool für modellbasiertes 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. Außerdem kann Uppaal ein erstelltes Modell mithilfe von formalen Anfragen einer eigenen Syntax validieren, was gerade in den Anfangsphasen eines Projektes hilfreich sein kann. Im Folgenden wird sowohl das Modell unter Uppaal sowie die Funktionsweise des TRON-Adapters erläutert.
 \subsection{Modell in Uppaal}
@@ -27,7 +27,7 @@ GraphWalker \footnote{\url{http://graphwalker.github.io/}} ist ein neueres Tool,
 \end{figure}
 
 \section{MATE}
-Das Model-based Adaptivity Test Environment\footnote{\url{http://81.88.24.184/qmate/}} (MATE) wurde unter anderem in \cite{Pueschel2018} vorgestellt und unterstützt verschiedene Arten von Modellen, sodass sich Systeme möglichst optimal darstellen lassen. Abhängig vom genutzten Modell sind Editoren vorhanden, die das Erstellen vereinfachen, wie in \cref{konzept:mate:bild} zu sehen. Auch hier kann vor dem Testen eine Verifizierung der erarbeiteten Darstellung stattfinden. Es wird online und offline-Testing ermöglicht, statistische Analysen der Testergebnisse werden automatisch (bei offline-Tests) durchgeführt. Zur Ausführung der Tests lassen sich benutzerdefinierte Adapter einrichten, sodass MATE unabhängig von der vom System verwendeten Technologie angewandt werden kann. Außerdem ist das Tool auf Erweiterbarkeit ausgelegt, das heißt es existiert beispielsweise ein Framework, mit welchem eigene Modelltypen implementiert werden können (solange diese einem Metamodell-Interface folgen). Insgesamt ist MATE ein mächtiges und breit einsetzbares Tool für Modell-basiertes Testen, es ist jedoch momentan nicht verfügbar und kann daher im Rahmen dieser Arbeit nicht verwendet werden.
+Das Model-based Adaptivity Test Environment\footnote{\url{http://81.88.24.184/qmate/}} (MATE) wurde unter anderem in \cite{Pueschel2018} vorgestellt und unterstützt verschiedene Arten von Modellen, sodass sich Systeme möglichst optimal darstellen lassen. Abhängig vom genutzten Modell sind Editoren vorhanden, die das Erstellen vereinfachen, wie in \cref{konzept:mate:bild} zu sehen. Auch hier kann vor dem Testen eine Verifizierung der erarbeiteten Darstellung stattfinden. Es wird online und offline-Testing ermöglicht, statistische Analysen der Testergebnisse werden automatisch (bei offline-Tests) durchgeführt. Zur Ausführung der Tests lassen sich benutzerdefinierte Adapter einrichten, sodass MATE unabhängig von der vom System verwendeten Technologie angewandt werden kann. Außerdem ist das Tool auf Erweiterbarkeit ausgelegt, das heißt es existiert beispielsweise ein Framework, mit welchem eigene Modelltypen implementiert werden können (solange diese einem Metamodell-Interface folgen). Insgesamt ist MATE ein mächtiges und breit einsetzbares Tool für modellbasiertes Testen, es ist jedoch momentan nicht verfügbar und kann daher im Rahmen dieser Arbeit nicht verwendet werden.
 \begin{figure}[h]
 	\centering
 	\includegraphics[scale=.6]{./MATE.png}