diff --git a/literatur.bib b/literatur.bib index a0ddc5d4d0237b6d0f527ad8a3667e0d3ffc54fc..78021b598ea7b989f210644c794585e8728794cf 100644 --- a/literatur.bib +++ b/literatur.bib @@ -389,4 +389,18 @@ url = {http://wiki.ros.org/actionlib/DetailedDescription}, } +@Article{Zheng2006, + author = {J. Zheng and L. Williams and N. Nagappan and W. Snipes and J.P. Hudepohl and M.A. Vouk}, + journal = {{IEEE} Transactions on Software Engineering}, + title = {On the value of static analysis for fault detection in software}, + year = {2006}, + month = {apr}, + number = {4}, + pages = {240--253}, + volume = {32}, + doi = {10.1109/tse.2006.38}, + file = {:On_the_value_of_static_analysis_for_fault_detection_in_software.pdf:PDF}, + publisher = {Institute of Electrical and Electronics Engineers ({IEEE})}, +} + @Comment{jabref-meta: databaseType:bibtex;} diff --git a/sections/grundlagen.tex b/sections/grundlagen.tex index 9e736f61f05b68aef41f78a7bf652c1a207490f4..885fe5c9704897199afbc35d52308f8425ca8682 100644 --- a/sections/grundlagen.tex +++ b/sections/grundlagen.tex @@ -1,39 +1,39 @@ \chapter{Grundlagen}\label{grundlagen} \section{Klassifikation und Terminologie}\label{grundlagen:klassifikation} 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. 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. +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. \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, 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. +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. \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 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}. \subsection{Aufwand} Essentiell 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} -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} +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}. +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.\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 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}. \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 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}. \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 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}. 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} +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}. \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. @@ -45,22 +45,22 @@ Die Anforderungen an die Testmethodiken cyber-physischer und insbesondere Roboti \end{figure} \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} +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. \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} +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}. 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 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}. 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} +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)} 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: +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 @@ -77,7 +77,7 @@ Mit ISO 29119 wurde 2013 ein neuer internationaler Standard für die Entwicklung \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. -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} +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} \subsection{Hierarchisches Testmodell} Das hierarchisch aufgebaute Testmodell wie etwa von \cite{Lim2010} demonstriert stellt ein momentan häufig genutztes Modell zum effizienten Testen eines Systems dar. @@ -98,11 +98,11 @@ In der Dokumentation zu ROS~\cite{OSRF2021} werden auch Vorteile und Kosten dies 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. \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} +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. \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} +Das Modell-basierte Testen wie in \cite{Pueschel2018} beschreibt einen Ansatz zum automatischen Generieren von Tests, welcher auf allen Ebenen des hierarchischen Testmodells angewandt werden kann. Dabei wird ein abstraktes Modell des Testobjektes erstellt, von dem die Tests abgeleitet werden können. Wichtig hierbei ist, dass das Modell eine gewisse Unabhängigkeit von Modellen besitzt, die zur Entwicklung genutzt wurden, da sich ansonsten Fehler aus dem Entwicklungsmodell in die Testfälle übertragen könnten. Es bietet sich daher an, das Modell direkt aus den Anforderungen des Systems zu entwickeln; das Entwicklungsmodell kann als Basis verwendet werden, oder um das Testmodell zusätzlich zu validieren \cite{Utting2011}. Da das Modell von Implementierungsdetails unabhängig ist, eignet sich Modell-basiertes Testen nicht für white box Tests. Der in \cite{Pueschel2018} dargestellte Testprozess besteht aus 5 Schritten: \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. @@ -111,8 +111,8 @@ Da das Modell von Implementierungsdetails unabhängig ist, eignet sich Modell-ba \item Folglich werden die Tests ausgeführt. \item Die Ergebnisse werden analysiert, Fehler gefunden und behoben. \end{enumerate} -Diese Methode der Testentwicklung ermöglicht erhebliche Einsparungen beim Entwicklungsaufwand, besonders bei Änderungen im Modell können ohne viel Aufwand neue Testfälle generiert werden. Die Anzahl an Testfällen lässt sich einfach anpassen, wodurch mehr Fehler gefunden werden können und eine bessere Abdeckung gegeben ist.\cite{Pretschner2005} -Als weiterer Vorteil ist bei dieser Methode anzugeben, dass das zu erstellende Modell (neben der Generierung der Testfälle) einen Überblick über die Funktionsweise basierend auf den Anforderungen des Systems gibt, sodass (neue) Entwickler dieses potentiell besser verstehen und daran arbeiten können. Nachteilig lässt sich anmerken, dass sich eine gewisse Redundanz zwischen dem zum Testen genutzten Modell und den Modellen zur Entwicklung nicht vermeiden lässt.\cite{Pueschel2018} -In \cite{Utting2011} wird eine Klassifizierung von möglichen Modellen für Modell-basiertes Testen vorgenommen, unter anderem lassen sich Markov-Ketten, endliche Automaten oder Petri-Netze zur Modellierung nutzen. Da Modelle, deren Umfang sich nur auf Inputs bezieht, kaum funktionales Verhalten verifizieren können sollten für cyber-physische Systeme Input-Output-Modelle verwendet werden. Die Echtzeitanforderungen eines Systems müssen im Modell widergespiegelt werden und spielen folglich auch bei der Testgenerierung und Ausführung eine Rolle.\cite[S. 358f]{Broy2005} Robotiksysteme sollten sich meist deterministisch verhalten, aufgrund des in \cref{grundlagen:simulationen} beschriebenen Nichtdeterminismus der Simulation oder uneindeutiger Inputs kann aber auch ein nichtdeterministisches Modell verwendet werden; sollen auch nichtdeterministische Systemfunktionalitäten überprüft werden, so ist ein deterministisches Modell offensichtlich nicht sinnvoll. Die Dynamik des Modells muss abhängig von den zu testenden Anforderungen sein, meist sind Robotiksystemen als kontinuierlich oder hybrid (Mix aus kontinuierlichen und diskreten Eigenschaften) einzustufen. 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} +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}. diff --git a/sections/konzept.tex b/sections/konzept.tex index dd64e3c0d8464de2b7561c18d2d451cd93956477..93a94502daf1bc43744771372c1a754b45ca078b 100644 --- a/sections/konzept.tex +++ b/sections/konzept.tex @@ -1,8 +1,8 @@ \chapter{Konzept} Aufgrund der genannten Vorteile von Modell-basiertem Testen wird dieses im folgenden umgesetzt. Zur Modellierung wird Uppaal\footnote{\url{https://uppaal.org/}} genutzt, eine Erweiterung namens TRON\footnote{\url{https://people.cs.aau.dk/~marius/tron/}} (Testing Realtime Systems Online) ermöglicht die Testgenerierung und direkte Ausführung aus dem erstellten Modell, indem ein Adapter erstellt wird. Als Vorbild dienen \cite{Ernits2015, Gummel2018}. Als Simulator bietet sich Gazebo an, da es sich einfach in ROS integrieren lässt und eine relativ hohe physikalische Korrektheit bietet. Verschiedene Physik-Engines können innerhalb von Gazebo verwendet werden. -Auch werden Plug-Ins unterstützt, sodass sich auch nicht nativ implementiere Sachverhalte wie etwa die Umgebungstemperatur darstellen lassen.\cite{Harris2011} Gazebo ist daher und aufgrund seiner Stabilität in der Robotik und insbesondere in der Forschung die momentan am meisten verwendete Simulationssoftware. -Allerdings können komplexe Zusammenhänge, auch abhängig von der gewünschten Akkuratheit, bei einer Implementierung in Form von Plug-Ins den Entwicklungsaufwand stark erhöhen. Problematisch ist bei Gazebo die Performance bei vielen simulierten Robotern oder komplexen Umgebungen, sodass in diesen Fällen potentiell andere Simulatoren verwendet werden sollten.\cite{Ivaldi2014} +Auch werden Plug-Ins unterstützt, sodass sich auch nicht nativ implementiere Sachverhalte wie etwa die Umgebungstemperatur darstellen lassen \cite{Harris2011}. Gazebo ist daher und aufgrund seiner Stabilität in der Robotik und insbesondere in der Forschung die momentan am meisten verwendete Simulationssoftware. +Allerdings können komplexe Zusammenhänge, auch abhängig von der gewünschten Akkuratheit, bei einer Implementierung in Form von Plug-Ins den Entwicklungsaufwand stark erhöhen. Problematisch ist bei Gazebo die Performance bei vielen simulierten Robotern oder komplexen Umgebungen, sodass in diesen Fällen potentiell andere Simulatoren verwendet werden sollten \cite{Ivaldi2014}. \cref{konzept:bild} zeigt den schematischen Aufbau der Implementierung. \begin{figure}[h]