diff --git a/sections/grundlagen.tex b/sections/grundlagen.tex
index 885fe5c9704897199afbc35d52308f8425ca8682..555f97595aba8d211b581e0a9bd252b9da8d874f 100644
--- a/sections/grundlagen.tex
+++ b/sections/grundlagen.tex
@@ -9,7 +9,7 @@ Letztlich ist der Zweck des Testens zu unterscheiden. Beispielsweise überprüfe
 \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.
 \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, 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 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.
 \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.
@@ -24,7 +24,7 @@ Außerdem muss für jeden Testfall beschrieben werden, in welchen Fällen dieser
 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 \cite{Biggs2010}.
+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}.
 \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}.
@@ -36,7 +36,7 @@ Bei Mensch-Roboter-Interaktionen stellen technische Fehler neben schlechten Umwe
 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.
+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.
 \begin{figure}[h]
 	\centering
 	\includegraphics[scale=0.6]{./anforderungen.png}
@@ -46,7 +46,8 @@ Die Anforderungen an die Testmethodiken cyber-physischer und insbesondere Roboti
 
 \section{Simulationen}\label{grundlagen:simulationen}
 Simulationen ermöglichen Entwicklern eine einfachere Umsetzung der in \cref{grundlagen:testanforderungen} gestellten Anforderungen, da das System nicht in seinem Einsatzumfeld getestet werden muss. Neben Kosten und Zeit der Testausführung wird insbesondere bei kollaborativen Robotiksystemen eine größere Sicherheit sowie Reproduzierbarkeit gewährleistet. Allerdings sind als Trade-off bezüglich der Akkuratheit Einbußen anzunehmen \cite{Sarhadi2014}.
-Unterschieden werden im folgenden rein computerbasierte Simulationen und sogenannte Hardware-in-the-Loop-Simulationen, welche die Brücke zwischen Software- und Hardwaretests schlagen.
+Unterschieden werden im folgenden rein computerbasierte Simulationen und sogenannte Hardware-in-the-Loop-Simulationen, welche die Brücke zwischen Software- und Hardwaretests schlagen. 
+Hier lässt sich Anmerken, dass bezüglich der Übertragbarkeit ein großer Teil auf die verwendete Simulation abfällt. Sind für das Verwenden einer Simulation Veränderungen im Quelltext des Systems notwendig, so steigt damit der Aufwand beim Übertragen der Tests auf andere Simulationen (wie z.B. HIL) beziehungsweise auf das Testen ohne Simulation.
 \subsection{Computerbasierte Simulationen}\label{grundlagen:klassifikation:simulationen:computerbasiert}
 Softwareseitige Simulationen sind gerade am Anfang des Entwicklungsprozesses ein äußerst wertvolles Tool zum Validieren des Systems. Auch aufgrund immer besser werdender Hardware können sie zunehmend in Industrie und Forschung verwendet werden \cite{Pepper2007}. 
 Eine Vielzahl an Simulator-Software wurde bereits und wird stetig weiter entwickelt \cite{Staranowicz2011, Harris2011}.
@@ -59,7 +60,7 @@ Viele Sensoren und Aktuatoren sind bereits implementiert, und auch Robotermodell
 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)}
-Zwischen den in \cref{grundlagen:klassifikation: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. 
+Zwischen den in \cref{grundlagen:klassifikation: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:
 \begin{itemize}
 	\item wenn die Kosten eines Fehlers während eines tatsächlichen Einsatzes unakzeptabel hoch sind (z.B. Flugzeug)
@@ -67,10 +68,11 @@ Zur Umsetzung ist also für komplexe Systeme neben dem zu testenden System entsp
 	\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 tatsächlich getestet wird, während die Restlichen Teil der virtuellen Umgebung sind \cite{Hu2006}.
 
 \section{Testprozesse nach ISO 29119}
-Mit ISO 29119 wurde 2013 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:
+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.
+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
@@ -95,11 +97,12 @@ Bibliotheken die ROS nicht benötigen sollen über vorgeschlagene Test-Framework
 für das Testen der Nodes zusätzlich eine Erweiterung namens rostest, welche auf roslaunch (Tool zum Starten von ROS Nodes) aufbaut, zur Verfügung steht. Auch Integrationstests sind mit rostest möglich, da auch mehrere Nodes zusammen gestartet und damit getestet werden können. 
 In der Dokumentation zu ROS~\cite{OSRF2021} werden auch Vorteile und Kosten dieser Testmethodik angeführt, welche im Folgenden zusammengefasst werden.
 \subsubsection{Vorteile}
-Unit-Tests sorgen für ein besseres Codedesign, da der Entwickler gezwungen wird per Unit-Test testbaren Code zu schreiben, was bedeutet die Funktionalitäten des Systems möglichst separat zu halten. Durch Regressionstests kann dem Entstehen von Fehlern sowohl bei Updates als auch bei Refactorings vorgebeugt werden. Auch beispielsweise Änderungen einer externen API können gefunden werden, sollten diese zu Problemen führen.
-Die Tests ermöglichen ebenfalls eine einfachere Zusammenarbeit der Entwickler, da sie die Funktionalität einer Komponente (oder mehrerer) eindeutig beschreiben.
+Unit-Tests sorgen für ein besseres Codedesign im Rahmen der dynamischen Testprozesse, da der Entwickler gezwungen wird per Unit-Test testbaren Code zu schreiben, was bedeutet die Funktionalitäten des Systems möglichst separat zu halten. Das reduziert langfristig neben dem Entwicklungsaufwand des Systems selbst auch den des Testens, wenn etwa Änderungen an den Tests vorgenommen werden sollen. Ebenso sorgen separate Komponenten für eine einfachere Analysierbarkeit der Testergebnisse, da sich ein gefundener Fehler nur in den getesteten Komponenten befinden kann und somit der zu überprüfende Bereich des Quellcodes stark eingeschränkt wird.
+Durch Regressionstests kann dem Entstehen von Fehlern sowohl bei Updates als auch bei Refactorings vorgebeugt werden. Auch beispielsweise Änderungen einer externen API können gefunden werden, sollten diese zu Problemen führen.
+Die Tests ermöglichen ebenfalls eine einfachere Zusammenarbeit der Entwickler, da sie die Funktionalität einer Komponente (oder mehrerer) eindeutig beschreiben. Das Überprüfen von (voneinander unabhängigen) Komponenten lässt sich in vielen Fällen einfach parallelisieren und das automatische Ausführen der Tests ist ebenfalls leicht zu integrieren.
 \subsubsection{Nachteile}
 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}.
-Als weiterer Nachteil kann gesehen werden, dass bei dieser Vorgehensweise nur die Nodes getestet werden und nicht der gesamte Roboter, wie in \cite{Bihlmaier2014} vorgeschlagen.
+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}.
@@ -113,6 +116,6 @@ Da das Modell von Implementierungsdetails unabhängig ist, eignet sich Modell-ba
 \end{enumerate}
 Diese Methode der Testentwicklung ermöglicht erhebliche Einsparungen beim Entwicklungsaufwand, besonders bei Änderungen im Modell können ohne viel Aufwand neue Testfälle generiert werden. Die Anzahl an Testfällen lässt sich einfach anpassen, wodurch mehr Fehler gefunden werden können und eine bessere Abdeckung gegeben ist \cite{Pretschner2005}.
 Als weiterer Vorteil ist bei dieser Methode anzugeben, dass das zu erstellende Modell (neben der Generierung der Testfälle) einen Überblick über die Funktionsweise basierend auf den Anforderungen des Systems gibt, sodass (neue) Entwickler dieses potentiell besser verstehen und daran arbeiten können. Nachteilig lässt sich anmerken, dass sich eine gewisse Redundanz zwischen dem zum Testen genutzten Modell und den Modellen zur Entwicklung nicht vermeiden lässt \cite{Pueschel2018}.
-In \cite{Utting2011} wird eine Klassifizierung von möglichen Modellen für Modell-basiertes Testen vorgenommen, unter anderem lassen sich Markov-Ketten, endliche Automaten oder Petri-Netze zur Modellierung nutzen. Da Modelle, deren Umfang sich nur auf Inputs bezieht, kaum funktionales Verhalten verifizieren können sollten für cyber-physische Systeme Input-Output-Modelle verwendet werden. Die Echtzeitanforderungen eines Systems müssen im Modell widergespiegelt werden und spielen folglich auch bei der Testgenerierung und Ausführung eine Rolle \cite[S. 358f]{Broy2005}. Robotiksysteme sollten sich meist deterministisch verhalten, aufgrund des in \cref{grundlagen:simulationen} beschriebenen Nichtdeterminismus der Simulation oder uneindeutiger Inputs kann aber auch ein nichtdeterministisches Modell verwendet werden; sollen auch nichtdeterministische Systemfunktionalitäten überprüft werden, so ist ein deterministisches Modell offensichtlich nicht sinnvoll. Die Dynamik des Modells muss abhängig von den zu testenden Anforderungen sein, meist sind Robotiksystemen als kontinuierlich oder hybrid (Mix aus kontinuierlichen und diskreten Eigenschaften) einzustufen. Das Paradigma des Modells sowie das Testauswahlkriterium müssen bei der Entwicklung ausgewählt werden, da sie stark von den zu testenden Anforderungen abhängen. Allerdings werden häufig verschiedene dieser Paradigmen verwendet, da sich verschiedene vereinigen lassen. Bezüglich des Testauswahlkriteriums und der Technik zum Generieren der Tests können ebenfalls mehrere verwendet werden \cite{Utting2011}.
+In \cite{Utting2011} wird eine Klassifizierung von möglichen Modellen für Modell-basiertes Testen vorgenommen, unter anderem lassen sich Markov-Ketten, endliche Automaten oder Petri-Netze zur Modellierung nutzen. Da Modelle, deren Umfang sich nur auf Inputs bezieht, kaum funktionales Verhalten verifizieren können sollten für cyber-physische Systeme Input-Output-Modelle verwendet werden. Die Echtzeitanforderungen eines Systems müssen im Modell widergespiegelt werden und spielen folglich auch bei der Testgenerierung und Ausführung eine Rolle \cite[S. 358f]{Broy2005}. Robotiksysteme sollten sich meist deterministisch verhalten, aufgrund des in \cref{grundlagen:simulationen} beschriebenen Nichtdeterminismus der Simulation oder uneindeutiger Inputs kann aber auch ein nichtdeterministisches Modell verwendet werden; sollen auch nichtdeterministische Systemfunktionalitäten überprüft werden, so ist ein deterministisches Modell offensichtlich nicht sinnvoll. Die Dynamik des Modells muss abhängig von den zu testenden Anforderungen sein, meist sind Robotiksystemen als kontinuierlich oder hybrid (Mix aus kontinuierlichen und diskreten Eigenschaften) einzustufen \cite{Utting2011}. Das Paradigma des Modells sowie das Testauswahlkriterium müssen bei der Entwicklung ausgewählt werden, da sie stark von den zu testenden Anforderungen abhängen. Allerdings werden häufig verschiedene dieser Paradigmen verwendet, da sich verschiedene vereinigen lassen. Bezüglich des Testauswahlkriteriums und der Technik zum Generieren der Tests können ebenfalls mehrere verwendet werden \cite{Utting2011}.