diff --git a/sections/einleitung.tex b/sections/einleitung.tex
index 9e96e2f52d624494ef007e2308dbbacaf4207b56..5023f701fbb30604275283786b390c5720d74b59 100644
--- a/sections/einleitung.tex
+++ b/sections/einleitung.tex
@@ -12,18 +12,18 @@ In der Industrie sind bereits verschiedene Testkonzepte bekannt und werden stand
 Obwohl die Forschung im Gebiet der Robotik deutlich zugenommen hat, sind weitere Analysen insbesondere von Testmethodiken dieser speziellen Systeme nötig, um mit dem Fortschritt in der Entwicklung mitzuhalten.
 
 \section{Zielstellung} \label{einleitung:zielstellen}
-Diese Arbeit befasst sich mit dem Systematischen Testen eines in~\Cref{einleitung:motivation} beschriebenen Robotersystems mit Fokus auf das Robot Operating System (ROS).
+Diese Arbeit befasst sich mit dem systematischen Testen eines in~\Cref{einleitung:motivation} beschriebenen Robotersystems mit Fokus auf das Robot Operating System (ROS).
 Zunächst müssen relevante Termini beschrieben werden.
 Folglich wird durch Literaturrecherche Anforderungen an Testmethoden von Robotiksystemen ermittelt und Schwierigkeiten bei der Umsetzung dieser erläutert. 
-Ein zentraler Aspekt dabei ist die korrekte Simulation des Roboters, da diese essentieller Bestandteil des Testumfelds ist. 
+Ein zentraler Aspekt dabei ist die korrekte Simulation des Roboters, da diese essenzieller Bestandteil des Testumfelds ist. 
 Außerdem sollen verschiedene Methoden und Toolchains für das Testen zusammen mit ihren Vor- und Nachteilen vorgestellt werden.
-Weiterhin wird eines dieser Konzept verwendet, indem ein sich in Entwicklung befindendes Projekt des Lehrstuhls getestet wird.
+Weiterhin wird eines dieser Konzepte verwendet, indem ein sich in Entwicklung befindendes Projekt des Lehrstuhls getestet wird.
 Schließlich soll die angewandte Testmethodik im Rahmen der am Anfang ermittelten Kriterien evaluiert werden.
 
 \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 Modell-basierten 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/grundlagen.tex b/sections/grundlagen.tex
index 2c58058abc7cf3291893881b7fb314b65c987455..cb5befd6e13ab87b67e8f3f733dccacd29b7bbe0 100644
--- a/sections/grundlagen.tex
+++ b/sections/grundlagen.tex
@@ -4,36 +4,36 @@ Tests lassen sich in verschiedene Kategorien einordnen.
 Statisches Testen beschreibt das Validieren ohne Ausführung des Systems, wie es beispielsweise bei Code Reviews der Fall ist \cite{Zheng2006}. Kommt es im Gegensatz dazu zu einer Ausführung des Systems, so ist von einem dynamischen Test die Rede. In dieser Arbeit wird hauptsächlich das dynamische Testen betrachtet, da statische Testmethoden bei Robotiksystemen aufgrund ihrer Komplexität nur sehr begrenzt angewendet werden können. Nichtsdestotrotz ist statisches Testen ein wichtiger Bestandteil des Entwicklungsprozesses. 
 Weiterhin wird ein Test, bei dem gezielt die Verarbeitung von Daten innerhalb der getesteten Komponente überprüft wird, \textbf{white~box} Test genannt. Wird im Gegensatz dazu nur das äußere Interface getestet, so spricht man von einem \textbf{black~box} Test \cite{Bihlmaier2014}.
 Sogenannte \textbf{grey~box} Tests verhalten sich wie black box Tests, mit dem Unterschied, dass dem Entwickler die interne Arbeitsweise der Komponente bekannt ist, und diese somit gezielter getestet werden kann \cite{Pueschel2018}. Des Weiteren lassen sich Tests als funktional oder nicht-funktional klassifizieren, nicht-funktionale Tests könnten beispielsweise die Temperatur oder den Stromverbrauch während der Ausführung testen. Selbstverständlich ist auch der Umfang von Tests unterschiedlich und kann von einem Code-Fragment bis zum gesamten System variieren.
-Letztlich ist der Zweck des Testens zu unterscheiden. Beispielsweise überprüfen Fehlertests ob das System korrekt im Fehlerfall reagiert, während Stresstests das Verhalten in Ausnahmesituationen validieren und Crashtests sogar versuchen, das System zum Abstürzen zu bringen. Im sogenannten Test-Driven-Development bildet das Testen das Fundament für die Entwicklung, indem zunächst die Tests geschrieben werden, für welche dann die Komponenten entwickelt werden.
+Letztlich ist der Zweck des Testens zu unterscheiden. Beispielsweise überprüfen Fehlertests, ob das System korrekt im Fehlerfall reagiert, während Stresstests das Verhalten in Ausnahmesituationen validieren und Crashtests sogar versuchen, das System zum Abstürzen zu bringen. Im sogenannten Test-Driven-Development bildet das Testen das Fundament für die Entwicklung, indem zunächst die Tests geschrieben werden, worauf die Entwicklung der Komponenten folgt.
 
 \section{Testanforderungen}\label{grundlagen:testanforderungen}
-Um festzustellen, welche Methoden und Technologien sich zum Testen von Robotiksystemen eignen, ist es unumgänglich zu wissen, welche Anforderungen an das Testen gestellt werden. Diese lassen sich aus den Anforderungen von Softwaretests allgemein sowie aus den Anforderungen eines Robotik-Systems ableiten.
+Um festzustellen, welche Methoden und Technologien sich zum Testen von Robotiksystemen eignen, ist es unumgänglich zu wissen, welche Anforderungen an das Testen gestellt werden. Diese lassen sich aus den Anforderungen von Softwaretests allgemein sowie aus denen eines Robotiksystems ableiten.
 \subsection{Abdeckung und Vollständigkeit}
-Da der Sinn des Testens auch darin besteht Verlässlichkeit zu garantieren und zu überprüfen, ob sämtliche gestellte Ansprüche erfüllt sind, ist es nötig, dass möglichst viele (im Idealfall alle) Situationen getestet werden, in denen sich das System befinden kann. Ein Robotiksystem ist heutzutage zu umfangreich um alle möglichen Situationen zu testen, das System kann viele Inputs beinhalten und jede Interaktion sowie (kleine) Veränderung in der Umgebung könnte einen weiteren Testfall darstellen. Daher müssen zwangsweise Testfälle selektiert werden \cite{Bihlmaier2014}, woraus folgt, dass die Testmethodik ein Verfahren beinhalten sollte, mit dem festgestellt werden kann, wie gut die Anforderungen an das System mit den genutzten Tests abgedeckt werden. Besonders bei cyber-physischen Systemen ist dieser Punkt eine Herausforderung, da neben den funktionalen Anforderungen auch nicht-funktionale (oder extra-funktionale) wie beispielsweise die Temperatur überprüft werden müssen. Die Umwelt spielt im Bezug auf cyber-physische Systeme aufgrund der starken Kontextabhängigkeit eine wesentliche Rolle. Die Komplexität und Dynamik dieser sorgt dafür, dass die vollständige Darstellung eine besondere Schwierigkeit darstellt \cite{AbbaspourAsadollah2015}. Auch die Interaktion der Umwelt mit dem System ist gerade in der Robotik essenziell und eng mit den beschriebenen Anforderungen verknüpft, sodass auch diese Teil eines Testverfahrens darstellen sollte.
+Da der Sinn des Testens auch darin besteht Verlässlichkeit zu garantieren und zu überprüfen, ob sämtliche gestellte Ansprüche erfüllt sind, ist es nötig, dass möglichst viele (im Idealfall alle) Situationen getestet werden, in denen sich das System befinden kann. Ein Robotiksystem ist heutzutage zu umfangreich um alle möglichen Situationen zu testen, das System kann viele Inputs beinhalten und jede Interaktion sowie (kleine) Veränderung in der Umgebung könnte einen weiteren Testfall darstellen. Daher müssen zwangsweise Testfälle selektiert werden \cite{Bihlmaier2014}, woraus folgt, dass die Testmethodik ein Verfahren beinhalten sollte, mit dem festgestellt werden kann, wie gut die Anforderungen an das System mit den genutzten Tests abgedeckt werden. Besonders bei cyber-physischen Systemen ist dieser Punkt eine Herausforderung, da neben den funktionalen Anforderungen auch nicht-funktionale (oder extra-funktionale) wie beispielsweise die Temperatur überprüft werden müssen. Die Umwelt spielt in Bezug auf cyber-physische Systeme aufgrund der starken Kontextabhängigkeit eine wesentliche Rolle. Die Komplexität und Dynamik dieser sorgt dafür, dass die vollständige Darstellung eine besondere Schwierigkeit darstellt \cite{AbbaspourAsadollah2015}. Auch die Interaktion der Umwelt mit dem System ist gerade in der Robotik essenziell und eng mit den beschriebenen Anforderungen verknüpft, sodass auch diese Teil eines Testverfahrens darstellen sollten.
 \subsection{Reproduzierbarkeit}\label{grundlagen:testanforderungen:reproduzierbarkeit}
 Die Anwendung von sogenannten Regressionstests, also der erneuten (automatisierten) Testdurchführung nach Quellcodeänderungen, ist schon lange eine der weit verbreitetsten Teststrategien der heutigen Industrie um Softwarequalität zu gewährleisten \cite{Onoma1998}. Um derartige Tests zu ermöglichen, muss es möglich sein, die Testfälle zu reproduzieren. Daraus folgt, dass eine genaue und eindeutige Dokumentation ausgeführter beziehungsweise auszuführender Tests erfolgen muss. Aufgrund der Komplexität eines Robotiksystems ist es beinahe unmöglich Testfälle in der echten Welt präzise genug zu wiederholen. Auch Hardware-in-the-loop-Simulationen (siehe \cref{grundlagen:simulationen}) sind kein ideales Umfeld für die Reproduzierbarkeit von Tests, da bereits kleine Veränderungen des Systems oder der Umwelt Auswirkungen auf die Testausführung haben können. Die beste Möglichkeit für Regressionstests bieten aktuell klassische Simulatoren. Aber auch in modernen Simulationen ist die Wiederholbarkeit nicht garantiert, es kann vorkommen, dass das System auf (vermeintlich) exakt gleiche Situationen unterschiedlich reagiert. Einen weit verbreiteten Grund dafür stellen Zufallszahlengeneratoren dar, die in den Roboterkomponenten verwendet werde. Häufig läuft auch die Physik-Engine der Simulation und der Nutzer-Code auf verschiedenen Threads, sodass durch das Scheduling des Betriebssystems Präemptierung auftreten kann, welche die Ausführungsreihenfolge verändert und damit die Reproduzierbarkeit einschränkt \cite{Ferigo2020, Biggs2010}.
-Daher ist es nötig, Testdurchführungen mehrfach vorzunehmen und die Ergebnisse statistisch zu analysieren \cite{Biggs2010}. Trotz potentieller Automatisierbarkeit und Parallelisierbarkeit dieses Prozesses, wie weiter unten diskutiert, ist gegenüber dem Testen reiner Softwaresysteme hier also mit einem Mehraufwand insbesondere auch bezüglich des Debuggens zu rechnen.
+Daher ist es nötig, Testdurchführungen mehrfach vorzunehmen und die Ergebnisse statistisch zu analysieren \cite{Biggs2010}. Trotz potenzieller Automatisierbarkeit und Parallelisierbarkeit dieses Prozesses, wie weiter unten diskutiert, ist gegenüber dem Testen reiner Softwaresysteme hier also mit einem Mehraufwand insbesondere auch bezüglich des Debuggens zu rechnen.
 \subsection{Skalierbarkeit}
-Wie in \cref{grundlagen:testanforderungen:reproduzierbarkeit} beschrieben besitzt das Wiederholen von Testfällen eine hohe Relevanz. Folglich muss die Anzahl an durchzuführenden Tests entsprechend anpassbar sein, um beispielsweise die Häufigkeit oder die Quelle eines potentiellen Fehlers zu ermitteln. Durch moderne Simulationen lässt sich diese Anforderung heutzutage relativ leicht erfüllen, wenn die Testfälle dokumentiert und damit reproduzierbar sind, sodass die Skalierbarkeit als eher untergeordnet anzusehen ist. Wird hingegen Systemhardware verwendet, so kann sich diese aufgrund beschränkter Verfügbarkeit als Flaschenhals herausstellen, was beim Testverfahren beachtet werden sollte \cite{Biggs2010}.
+Wie in \cref{grundlagen:testanforderungen:reproduzierbarkeit} beschrieben besitzt das Wiederholen von Testfällen eine hohe Relevanz. Folglich muss die Anzahl an durchzuführenden Tests entsprechend anpassbar sein, um beispielsweise die Häufigkeit oder Quelle eines potenziellen Fehlers zu ermitteln. Durch moderne Simulationen lässt sich diese Anforderung heutzutage relativ leicht erfüllen, wenn die Testfälle dokumentiert und damit reproduzierbar sind, sodass die Skalierbarkeit als eher untergeordnet anzusehen ist. Wird hingegen Systemhardware verwendet, so kann sich diese aufgrund beschränkter Verfügbarkeit als Flaschenhals herausstellen, was beim Testverfahren beachtet werden sollte \cite{Biggs2010}.
 \subsection{Aufwand}
-Essentiell ist der Aufwand bezüglich Arbeit und Zeit und somit auch Kosten. Dieser lässt sich im Folgenden weiter spezifizieren.
+Essenziell ist der Aufwand bezüglich Arbeit und Zeit und somit auch Kosten. Dieser lässt sich im Folgenden weiter spezifizieren.
 \subsubsection{Entwicklungsaufwand}
 Offensichtlich ist der Arbeits- und Zeitaufwand beim Entwickeln der Tests ein relevanter Faktor. 
-Grob gesagt ist ein Test eine endliche Menge an Input/Output-Paaren. Da Robotersysteme aber häufig theoretisch unendlich lange laufen können, gibt es eine Unendliche Menge an besagten Paaren, sodass sich bei der Entwicklung der Tests auf eine beschränkte Menge an Testfällen festgelegt werden muss. Das unterscheiden von relevanten und nicht-relevanten Fällen (Testauswahlkriterium) kann hier bereits eine Herausforderung darstellen \cite{Pueschel2018}.
+Grob gesagt ist ein Test eine endliche Menge an Input/Output-Paaren. Da Robotersysteme aber häufig theoretisch unendlich lange laufen können, gibt es eine unendliche Menge an besagten Paaren, sodass sich bei der Entwicklung von Tests auf eine beschränkte Menge an Testfällen festgelegt werden muss. Das Unterscheiden von relevanten und nicht-relevanten Fällen (Testauswahlkriterium) kann hier bereits eine Herausforderung darstellen \cite{Pueschel2018}.
 Außerdem muss für jeden Testfall beschrieben werden, in welchen Fällen dieser erfolgreich war oder fehlgeschlagen ist (Testorakel). Dabei muss vom Entwickler auch entschieden werden, welche Präzision vorausgesetzt wird. Diese Entscheidungen sind schwer abhängig vom individuellen Testfall \cite{Bihlmaier2014}.
 Ein weiteres Kriterium stellt insbesondere für cyber-physische Systeme die Übertragbarkeit beziehungsweise Unabhängigkeit der Tests dar. Darunter ist zu verstehen welcher Aufwand nötig ist, um Tests, die in einer Simulation ausgeführt werden können, in einer echten Umgebung (oder einer anderen Simulation wie etwa Hardware-in-the-loop) ausführbar zu machen. Im Idealfall könnten die Tests ohne Änderungen in jedem Umfeld ausgeführt werden.
 \subsubsection{Ausführbarkeit}
-Zur Ausführbarkeit zählt unter anderem die einfache Vor- und Nachbereitung, sowie die Parallelisierbarkeit und Automatisierbarkeit einer Testdurchführung. Bei Simulationen lassen sich diese Anforderungen heutzutage sehr bequem erfüllen, sofern die Tests entsprechend designt wurden. Das bedeutet, dass die Tests in sich geschlossen und unabhängig voneinander ausführbar sein sollten. Durch beispielsweise eine Continuous-Integration-Pipeline kann der Testprozess automatisiert und fließend in den Entwicklungsprozess integriert werden. Mehrere Instanzen einer Simulation auf denen jeweils ein Testfall ausgeführt wird können dabei für die entsprechende Parallelisierbarkeit sorgen. Zeitaufwändiger ist eine sequentielle Ausführung, bei der die Simulation nach jeder Ausführung zurückgesetzt werden muss \cite{Bihlmaier2014}. Von einer automatischen Testausführung kann auch im Rahmen von Regressionstests profitiert werden, während die Parallelausführung der Testfälle je nach Anzahl und Dauer der Tests nicht zwingend nötig ist.
-Sollte Hardware verwendet werden, so ist der Aufwand für die Ausführung erhöht, da die Vorbereitung in der Regel relativ aufwändig ist und die Parallelisierbarkeit und Automatisierbarkeit stark eingeschränkt wird. Weiterhin muss eine Überwachung des Tests stattfinden, damit dieser unter Umständen abgebrochen werden kann, wenn beispielsweise ein Schaden am System droht oder im schlimmsten Fall Menschen in Gefahr sind \cite{Biggs2010}.
+Zur Ausführbarkeit zählt unter anderem die einfache Vor- und Nachbereitung, sowie die Parallelisierbarkeit und Automatisierbarkeit einer Testdurchführung. Bei Simulationen lassen sich diese Anforderungen heutzutage sehr bequem erfüllen, sofern die Tests entsprechend designt wurden. Das bedeutet, dass die Tests in sich geschlossen und unabhängig voneinander ausführbar sein sollten. Durch beispielsweise eine Continuous-Integration-Pipeline kann der Testprozess automatisiert und fließend in den Entwicklungsprozess integriert werden. Mehrere Instanzen einer Simulation, auf denen jeweils ein Testfall ausgeführt wird können dabei für die entsprechende Parallelisierbarkeit sorgen. Zeitaufwändiger ist eine sequentielle Ausführung, bei der die Simulation nach jedem Test zurückgesetzt werden muss \cite{Bihlmaier2014}. Von einer automatischen Testausführung kann auch im Rahmen von Regressionstests profitiert werden, während die Parallelausführung der Testfälle je nach Anzahl und Dauer der Tests nicht zwingend nötig ist.
+Sollte Hardware verwendet werden, so ist der Aufwand für die Ausführung erhöht, da die Vorbereitung in der Regel relativ aufwändig ist und die Parallelisierbarkeit beziehungsweise Automatisierbarkeit stark eingeschränkt wird. Weiterhin muss eine Überwachung des Tests stattfinden, damit dieser unter Umständen abgebrochen werden kann, wenn beispielsweise ein Schaden am System droht oder im schlimmsten Fall Menschen in Gefahr sind \cite{Biggs2010}.
 \subsection{Analysierbarkeit}
-Das Erstellen von automatisierten Methoden zur Testauswertung stellt bei Cyber-Physischen Systemen eine Herausforderung dar. Die Komplexität eines solchen Systems sorgt für eine schwierige Identifikation der Fehlerquelle \cite{AbbaspourAsadollah2015}. Dennoch können Ergebnisse, gerade wenn eine statistische Analyse nötig ist, zusammengefasst und potentiell auf Ähnlichkeiten in den fehlschlagenden Tests hingewiesen werden.
-Die Analyse der Testergebnisse umfasst auch die Analyse verletzter Systemanforderungen. Daher sollte es möglich sein, nachzuvollziehen, welche Anforderung bei Fehlschlagen welcher Tests verletzt wurden. Um dies zu vereinfachen können im Rahmen der Testentwicklung die Testfälle den Anforderungen, die sie testen sollen, zugeordnet werden \cite{Pueschel2018}.
+Das Erstellen von automatisierten Methoden zur Testauswertung stellt bei cyber-physischen Systemen eine Herausforderung dar. Die Komplexität eines solchen Systems sorgt für eine schwierige Identifikation der Fehlerquelle \cite{AbbaspourAsadollah2015}. Dennoch können Ergebnisse, gerade wenn eine statistische Analyse nötig ist, zusammengefasst und potenziell auf Ähnlichkeiten in den fehlschlagenden Tests hingewiesen werden.
+Die Analyse der Testergebnisse umfasst auch die der verletzter Systemanforderungen. Daher sollte es möglich sein, nachzuvollziehen, welche Anforderung bei Fehlschlagen welcher Tests verletzt wurden. Um dies zu vereinfachen, können im Rahmen der Testentwicklung die Testfälle den Anforderungen, die sie testen sollen, zugeordnet werden \cite{Pueschel2018}.
 \subsection{Akkuratheit}
-Das System und seine Umwelt sollten im Testumfeld möglichst genau dem tatsächlichen Einsatz entsprechen, da die Tests sonst kaum Aussagekraft bieten. Selbst kleine Abweichungen von der Realität können bereits Auswirkungen auf die Ergebnisse haben. Daher sollte bei Simulationen auch eine für die jeweilig getestete Aufgabe ausreichend korrekte Darstellung physikalischer Zusammenhänge stattfinden und Echtzeitfähigkeit gegeben sein \cite{Bihlmaier2014}. Gerade nicht-funktionale Eigenschaften oder weiche Körper können hier eine Herausforderung darstellen. Auch die Interaktion mit der Umgebung lässt sich schwierig simulieren. Insbesondere Menschen können sich unvorhersehbar verhalten. So stellt beispielsweise das Testen der Nutzerfreundlichkeit eines Systems, welches für alte Menschen oder Menschen mit Behinderungen entwickelt wird, eine Herausforderung dar \cite{AbbaspourAsadollah2015}.
+Das System und seine Umwelt sollten im Testumfeld möglichst genau dem tatsächlichen Einsatz entsprechen, da die Tests sonst kaum Aussagekraft bieten. Selbst kleine Abweichungen von der Realität können bereits Auswirkungen auf die Ergebnisse haben. Daher sollte bei Simulationen auch eine für die jeweils getestete Aufgabe ausreichend korrekte Darstellung physikalischer Zusammenhänge stattfinden und Echtzeitfähigkeit gegeben sein \cite{Bihlmaier2014}. Gerade nicht-funktionale Eigenschaften oder weiche Körper können hier eine Herausforderung darstellen. Auch die Interaktion mit der Umgebung lässt sich schwierig simulieren. Insbesondere Menschen können sich unvorhersehbar verhalten. So stellt beispielsweise das Testen der Nutzerfreundlichkeit eines Systems, welches für alte Menschen oder solche mit Behinderungen entwickelt wird, eine Herausforderung dar \cite{AbbaspourAsadollah2015}.
 Außerdem muss sich das in der Simulation verwendete Modell möglichst genau so verhalten wie der echte Roboter. \cite{Pepper2007} stellt Methoden zur Validierung eines solchen Modells vor.
 \subsection{Sicherheit}
 Bei Mensch-Roboter-Interaktionen stellen technische Fehler neben schlechten Umweltbedingungen und menschlichem Versagen eine der Hauptkategorien für Unfallursachen dar \cite{Vasic2013}. Fehler innerhalb des Systems können beispielsweise zu unvorhersehbaren schnellen Bewegungen führen, sodass dieses dringlichst getestet werden muss. Aber auch schlechte Umweltbedingungen wie extreme Temperaturen können in Tests einbezogen werden.
-Daher ist bei Cyber-Physischen Systemen Sicherheit als äußerst relevante Anforderung in den Fokus der Industrie gerückt. Besonders kollaborativ arbeitende Systeme müssen diesbezüglich ausreichend getestet werden, um Unfällen vorzubeugen. Bei diesen sollte zunächst in einer Simulation und darauf folgend in einer kontrollierten Umgebung getestet werden, bevor Tests im Einsatzumfeld stattfinden. Die Anzahl an Unfällen im Zusammenhang mit einem System kann als Indikator für die Sicherheit dienen. Ein hauptsächliches Problem hierbei ist herauszufinden, ob die Unfälle durch das System oder durch den Menschen verursacht wurden \cite{Antao2018}.
+Daher ist bei cyber-physischen Systemen Sicherheit als äußerst relevante Anforderung in den Fokus der Industrie gerückt. Besonders kollaborativ arbeitende Systeme müssen diesbezüglich ausreichend getestet werden, um Unfällen vorzubeugen. Bei diesen sollte zunächst in einer Simulation und darauf folgend in einer kontrollierten Umgebung getestet werden, bevor Tests im Einsatzumfeld stattfinden. Die Anzahl an Unfällen im Zusammenhang mit einem System kann als Indikator für die Sicherheit dienen. Ein hauptsächliches Problem hierbei ist herauszufinden, ob die Unfälle durch das System oder durch den Menschen verursacht wurden \cite{Antao2018}.
 
 \subsection{Übersicht}
 Die Anforderungen an die Testmethodiken cyber-physischer und insbesondere Robotik-Systeme stellen für die Forschung momentan eine Herausforderung dar. Simulationen, die in \cref{grundlagen:simulationen} diskutiert werden, können das Erfüllen vieler Anforderungen erleichtern, stellen dabei aber selbst einige Hürden. Die Abdeckung sowie der Aufwand müssen vor allem im Rahmen der Testentwicklung beachtet und umgesetzt werden. \cref{grundlagen:testanforderungen:uebersicht} gibt einen Überblick über die geforderten Eigenschaften. Dabei sind links die in diesem Abschnitt aufgezählten Punkte zu sehen, von welchen aus durch die Pfeile auf relevante Teilaspekte verwiesen wird.
@@ -53,33 +53,34 @@ Softwareseitige Simulationen sind gerade am Anfang des Entwicklungsprozesses ein
 Eine Vielzahl an Simulator-Software wurde bereits und wird stetig weiter entwickelt \cite{Staranowicz2011, Harris2011}.
 Die Vorteile solcher Software sind vielfältig.
 So können ausreichend dokumentierte Testfälle ohne Probleme wiederholt und die Sicherheit vollständig gewährleistet werden. Allerdings sind Simulationen aus den in \cref{grundlagen:testanforderungen:reproduzierbarkeit} genannten Gründen kein Garant für die deterministische Ausführung von Tests und damit die Reproduzierbarkeit, gleichzeitig aber die beste Wahl bezüglich dieser.
-Die Anzahl an parallel durchführbaren Tests ist nicht durch die vorhandene Hardware des zu testenden Systems beschränkt. Die Tests können potentiell automatisch ausgeführt und die Ergebnisse protokolliert werden, wodurch Zeit gewonnen wird. Dafür wird jedoch, je nach Anzahl und Komplexität der auszuführenden Simulationen, gerade im Bezug auf Testautomatisierung möglicherweise teure Hardware (insbesondere GPUs) benötigt. Auch die Simulationssoftware kann teuer sein \cite{Afzal2020}.
-Das für Entwickler als am wichtigsten empfundene Kriterium bei der Auswahl einer entsprechenden Software ist allerdings dass die Simulation möglichst realistisch ist, da sie vor allem eingesetzt wird um Interaktionen des Roboters mit seiner Umwelt zu simulieren \cite{Ivaldi2014}.
+Die Anzahl an parallel durchführbaren Tests ist nicht durch die vorhandene Hardware des zu testenden Systems beschränkt. Die Tests können potenziell automatisch ausgeführt und die Ergebnisse protokolliert werden, wodurch Zeit gewonnen wird. Dafür ist jedoch, je nach Anzahl und Komplexität der auszuführenden Simulationen, gerade in Bezug auf Testautomatisierung möglicherweise teure Hardware (insbesondere GPUs) nötig. Auch die Simulationssoftware kann teuer sein \cite{Afzal2020}.
+Das für Entwickler als am wichtigsten empfundene Kriterium bei der Auswahl einer entsprechenden Software ist allerdings, dass die Simulation möglichst realistisch ist, da sie vor allem eingesetzt wird, um Interaktionen des Roboters mit seiner Umwelt zu simulieren \cite{Ivaldi2014}.
 Moderne Simulationen besitzen bereits einen für viele Anwendungen ausreichenden Realismus, dennoch sind Abweichungen von der Realität zu erwarten. Ob eine Simulation ausreichend präzise ist, muss im Einzelfall durch den Entwickler überprüft werden. 
 Viele Sensoren und Aktuatoren sind bereits implementiert, und auch Robotermodelle stehen durch die Entwicklung beispielsweise in CAD zur Verfügung. Ist dies nicht der Fall, so ist mit entsprechendem Mehraufwand zu rechnen \cite{Bihlmaier2014}.
 Ist eine komplexe Umgebung zu erwarten, so kann die Konstruktion dieser einen erheblichen Zeitaufwand darstellen, da diese in den allermeisten Fällen manuell durchgeführt werden muss \cite{Afzal2020}.
 Insgesamt ergibt sich also ein hoher Zugewinn an Effizienz und Sicherheit, welcher in einem Gewinn an Kosten und Zeit resultiert, sofern Modelle des Robotersystems (und der Umwelt) bereits gegeben sind und ausreichende Hardware zum Ausführen der Simulationen zur Verfügung steht. Die in \cref{grundlagen:testanforderungen} angeführten Anforderungen lassen sich mit dieser Art von Simulation im Wesentlichen auf eine hohe Abdeckung und einen geringen Entwicklungsaufwand der Tests reduzieren. Dennoch treten Schwierigkeiten beim Nutzen von Simulationen auf, unter anderem wird in \cite{Afzal2020} die fehlende Dokumentation sowie die Stabilität der Software aufgezählt. Auch sind sie aufwändig zu Nutzen, und Features wie das Ausführen ohne GUI ("headless"), was sich auch gerade für CI-Pipelines anbietet, sind teilweise nicht vorhanden oder schwierig umzusetzen.
 \subsection{Hardware-in-the-loop (HIL)}\label{grundlagen:simulationen:hil}
-Zwischen den in \cref{grundlagen:simulationen:computerbasiert} beschriebenen Simulationen und dem Testen im tatsächlichen Einsatzumfeld treten zwangsweise Diskrepanzen auf. Um beim Testen nicht direkt vollständig auf die Vorteile einer Simulation zu verzichten und einen Übergang zu einem "echten" Test zu schaffen, kann die im Kontext von Robotik auch als robot-in-the-loop bezeichnete Art der Simulation verwendet werden \cite{Hu2006}. Sie kann auch verwendet werden, sollte eine konventionelle Simulation nicht oder nur unzureichend möglich sein. Dabei wird die Umwelt simuliert und mit den Schnittstellen des zu testenden Roboters verbunden. Der Roboter erhält so die virtuelle Umgebung als Input und erzeugt entsprechenden Output in Form von beispielsweise Signalen an die Aktuatoren, welche wiederum als Input für die Simulation dienen. 
-Zur Umsetzung ist also für komplexe Systeme neben dem zu testenden System entsprechende IO-Hardware sowie ein Computer mit hohen Datentransferraten und leistungsfähigen Prozessoren, um die Echtzeitfähigkeit zu garantieren, nötig \cite{Ledin1999}. Weiterhin muss spezielle Software gegeben sein, sodass HIL bezüglich der Anschaffungskosten als teuer, gerade im Vergleich zu rein softwaregesteuerten Simulationen (auch Software-in-the-loop genannt), einzustufen ist. Da neben den Kosten auch der Zeitaufwand und die Komplexität nicht unerheblich sind beschreibt \cite{Ledin1999} in welchen Situationen HIL als sinnvoll einzustufen ist:
+Zwischen den in \cref{grundlagen:simulationen:computerbasiert} beschriebenen Simulationen und dem Testen im tatsächlichen Einsatzumfeld treten zwangsweise Diskrepanzen auf. Um also nicht direkt vollständig auf die Vorteile einer Simulation zu verzichten und einen Übergang zu einem \glqq echten\grqq~Test zu schaffen, kann die im Kontext von Robotik auch als robot-in-the-loop bezeichnete Art der Simulation verwendet werden \cite{Hu2006}. Sie lässt sich auch anwenden, sollte eine konventionelle Simulation nicht oder nur unzureichend möglich sein. Dabei wird die Umwelt simuliert und mit den Schnittstellen des zu testenden Roboters verbunden. Der Roboter erhält so die virtuelle Umgebung als Input und erzeugt entsprechenden Output in Form von beispielsweise Signalen an die Aktuatoren, welche wiederum als Input für die Simulation dienen. 
+Zur Umsetzung ist also für komplexe Systeme neben dem zu testenden System entsprechende IO-Hardware sowie ein Computer mit hohen Datentransferraten und leistungsfähigen Prozessoren, um die Echtzeitfähigkeit zu garantieren, nötig \cite{Ledin1999}. Weiterhin muss spezielle Software gegeben sein, sodass HIL bezüglich der Anschaffungskosten als teuer, gerade im Vergleich zu rein softwaregesteuerten Simulationen (auch Software-in-the-loop genannt), einzustufen ist. Da neben den Kosten auch der Zeitaufwand und die Komplexität nicht unerheblich sind beschreibt \cite{Ledin1999}, in welchen Situationen HIL als sinnvoll einzustufen ist:
 \begin{itemize}
 	\item wenn die Kosten eines Fehlers während eines tatsächlichen Einsatzes unakzeptabel hoch sind (z.B. Flugzeug)
 	\item wenn der Einsatz von HIL keinen Mehraufwand verursacht, da etwa Praxistests ersetzt werden können
 	\item wenn Regressionstests sehr präzise sein müssen
 	\item wenn Prototypen von Komponenten während der Entwicklung getestet werden müssen
 \end{itemize}
-Insbesondere wenn ein System in einer schwer zu erreichenden oder gefährlichen Umgebung arbeiten soll bietet sich HIL an. Ebenso können Systeme, die aus vielen kooperativen Robotern bestehen, getestet werden, wobei einer dieser Roboter tatsächlich getestet wird, während die Restlichen Teil der virtuellen Umgebung sind \cite{Hu2006}.
+Insbesondere, wenn ein System in einer schwer zu erreichenden oder gefährlichen Umgebung arbeiten soll bietet sich HIL an. Ebenso können Systeme, die aus vielen kooperativen Robotern bestehen, getestet werden, wobei einer dieser Roboter physisch und die anderen virtuell am Test teilnehmen \cite{Hu2006}.
 
 \section{Testprozesse nach ISO 29119}
-In der Industrie sind Standards wichtig für ein organisiertes Zusammenarbeiten. Auch für das Testen von Software, insbesondere der von Robotiksystemen, ist eine strukturiertes Vorgehen innerhalb eines Unternehmens von zentraler Bedeutung.
+In der Industrie sind Standards wichtig für ein organisiertes Zusammenarbeiten. Auch für das Testen von Software, insbesondere der von Robotiksystemen, ist ein strukturiertes Vorgehen innerhalb eines Unternehmens von zentraler Bedeutung.
 Daher wurde 2013 mit ISO 29119 ein neuer internationaler Standard für die Entwicklung Softwaretests geschaffen. Im zweiten Teil werden die für das Testen nötigen Prozesse in 3 Stufen aufgeteilt:
 \begin{enumerate}
 	\item Organisatorische Prozesse
 	\item Testmanagementprozesse
 	\item Dynamische Testprozesse
 \end{enumerate}
-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.
+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 eine 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 dieses 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}
@@ -89,17 +90,17 @@ Grundlegend besteht das Modell aus 3 zentralen Bestandteilen:
 	\item Unit-Tests:\break
 		Einzelne Einheiten (wie etwa Klassen) werden getestet.
 	\item Integrations-Tests:\break
-		Das Zusammenspiel der (vorher einzeln getesten) Einheiten wird getestet.
+		Das Zusammenspiel der (vorher einzeln getesteten) Einheiten wird getestet.
 	\item System-Tests:\break
 		Die gesamte Komponente wird getestet.
 \end{itemize}
 Diese Bestandteile werden auch von den ROS-Entwicklern empfohlen~\cite{OSRF2021} und bieten sich an, da ein (gut designtes) auf ROS basierendes System in sogenannte Nodes aufgeteilt ist, welche die einzelnen Komponenten darstellen. 
 Bibliotheken die ROS nicht benötigen sollen über vorgeschlagene Test-Frameworks (gtest für C++ und unittest für Python) getestet werden während 
-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.
+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 Integrations-Tests sind mit rostest möglich, da auch mehrere Nodes zusammen gestartet und damit getestet werden können. 
+In der Dokumentation zu ROS~\cite{OSRF2021} sind auch Vorteile und Kosten dieser Testmethodik angeführt, welche im Folgenden zusammengefasst werden.
 \subsubsection{Vorteile}
 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.
+Durch Regressionstests kann dem Entstehen von Fehlern sowohl bei Updates als auch bei Refactorings vorgebeugt werden. Auch beispielsweise Änderungen einer externen API lassen sich finden, 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}
 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}.
@@ -109,19 +110,19 @@ Folglich ist eine gute Abdeckung der Systemanforderungen schwierig umzusetzen, u
 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:
 \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 (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 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.
+Neben den Testfällen kann potenziell aus den in 1. gegebenen Anforderungen eine sogenannte Anforderungsrückverfolgungsmatrix (und ein Modellabdeckungsbericht) erstellt werden, mit welcher sich feststellen lässt, 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}
-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.
+Bei Modell-basiertem Testen generell kann auch keine automatische Generierung der Testfälle erfolgen. In \cite{Pretschner2005} wurde dabei (mit gleicher Anzahl an Testfällen) kein signifikanter Unterschied in der Summe an erkannten Fehlern festgestellt. Allerdings führte das Erhöhen der Anzahl an Testfällen, welche bei der automatischen Methode deutlich einfacher ist, zu zusätzlichen 11\% an gefundenen Fehlern. \cite{Pretschner2005} weist jedoch darauf hin, dass die festgestellten Ergebnisse nur eine Fallstudie darstellen und daher nicht ohne weiteres zu verallgemeinern sind.
 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.
+Als weiterer Vorteil ist bei dieser Methode anzugeben, dass das zu erstellende Modell (neben der Generierung der Testfälle) einen Überblick über die Funktionsweise basierend auf den Anforderungen des Systems gibt, sodass (neue) Entwickler dieses potenziell besser verstehen und daran arbeiten können.
 \subsubsection{Nachteile}
 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.