- hinnerk korrekturen

- grundlagen wieder eien Datei

065_1_bewertung.tex

@@ -8,20 +8,20 @@
 		\subsection{Referenzstation}
 			Die Anforderungen an die Referenzstation wurden nach dem aktuellen Stand erfüllt. Die Einmessung der Antenne konnte wie gefordert im Millimeterbereich ausgeführt werden, siehe hierzu Anhang \ref{cha:auswerungObservation}. Seit dem 7. Juni 2024 bis zum 12. August 2024 lief die Anlage ohne Störungen. Während der Temperaturen über \(30^\circ C\) hat sich der PoE-Splitter ausgeschaltet. Dieser konnte getestet und anschließend wieder eingebaut werden. Zudem ist das Gewinde der Antennenaufnahme abgebrochen. Das Formteil wurde von Mitarbeitern des Hardwarelabors an der FH Dortmund durch eine innen liegende Schraube verstärkt und wieder montiert. Durch diese Instandsetzungen kann die zunächst betriebene Version nicht als wartungsarm bezeichnet werden und erfüllt diese Anforderung somit nicht.
 			\par
-			Die Anforderungen an die Gebäudesicherheit wurden durch Absprache und Begleitung der Installation sichergestellt. Das Kapitel \ref{cha:Hardwareauswahl} Hardwareauswahl hat sich mit den durch die Umwelt und Infrastruktur gegebenen Anforderungen an die Hardware auseinandergesetzt und konnte damit die Energieversorgung leisten sowie die Langlebigkeit der Anlage durch ausreichende Betriebstemperaturbereiche und Regenwasserschutz gewährleisten.
+			Die Anforderungen an die Gebäudesicherheit wurden durch Absprache und Begleitung der Installation sichergestellt. Das Kapitel \ref{cha:Hardwareauswahl} Hardwareauswahl hat sich mit den durch die Umwelt und Infrastruktur gegebenen Anforderungen an die Hardware auseinandergesetzt und konnte damit die Energieversorgung sowie die Langlebigkeit der Anlage durch ausreichende Betriebstemperaturbereiche und Regenwasserschutz gewährleisten.
 			\par
 			Der Installationsort der Antenne unterlag der Bedingung, dass diese eine freie Sicht auf den Himmel innehat. Durch eine Erhöhung der Antenne mit einem C-Profil, um der Abschattung durch den Lüftungskanal zu entgehen, konnte die freie Sicht gewährleistet werden.
 
 			\subsubsection{Server}
-				Der Server musste einige Spezifikationen aufweisen. Der USB-Port zwar zwingend erforderlich für die Verbindung zu dem GNSS-Modul. Als weitere Schnittstelle musste eine RJ-45 für Ethernet vorhanden sein. Diese sollte auch über PoE verfügen, hier musste auf eine Alternative zurückgegriffen werden, da kein angemessenes Gerät gefunden wurde, welches zusätzlich diese Spezifikation erfüllt. Der gewählte Embedded Computer verfügt über die geforderten Schnittstellen und ist aufgrund der handelsüblichen x86 Architektur auch für die RTKLib geeignet. Der Energiebedarf war mit den Spezifikationen schon im SOLL und konnte noch darüber hinaus reduziert werden.
+				Der Server musste einige Spezifikationen aufweisen. Der USB-Port war zwingend erforderlich für die Verbindung zu dem GNSS-Modul. Als weitere Schnittstelle musste eine RJ-45 für Ethernet vorhanden sein. Diese sollte auch über PoE verfügen, hier musste auf eine Alternative zurückgegriffen werden, da kein angemessenes Gerät gefunden wurde, welches zusätzlich diese Spezifikation erfüllt. Der gewählte Embedded Computer verfügt über die geforderten Schnittstellen und ist aufgrund der handelsüblichen x86 Architektur auch für die RTKLib geeignet. Der Energiebedarf war mit den Spezifikationen schon im SOLL und konnte darüber hinaus noch reduziert werden.
 
 		\subsection{Rover}
 			Die Anforderungen an den Rover stammen aus der übergeordneten Forderung. Laut dieser soll der Rover so erweitert werden, dass dieser eine zuvor aufgezeichnete Route eigenständig abfahren kann. Dafür wurden die folgenden Komponenten als Anforderungen definiert:
 
 			\begin{itemize}
-				\item Der Rover muss über einen \textbf{Ntrip-Client} verfügen. Die Implementation wurde in Abschnitt \ref{ssec:ntripclient} beschrieben. Dafür wurde ein Dokument von der RTCM herangezogen, welches Anmerkungen und Hilfestellungen für die erfolgreiche Implementation eines Clients gibt. Durch die Umsetzung als Zustandsautomat kann der aktuelle Zustand des Clients einfach an andere Komponenten weitergegeben werden. Die Anforderungen verloren gegangene Verbindung automatisch wieder aufzubauen wurde für die Verbindung zu dem Caster umgesetzt. Die Umsetzung der W-LAN-Verbindung und deren Funktion zum automatischen Wiederverbinden wurde bereits in der vorhandenen Software des Rovers umgesetzt.
+				\item Der Rover muss über einen \textbf{Ntrip-Client} verfügen. Die Implementation wurde in Abschnitt \ref{ssec:ntripclient} beschrieben. Dafür wurde ein Dokument von der RTCM herangezogen, welches Anmerkungen und Hilfestellungen für die erfolgreiche Implementation eines Clients gibt. Durch die Umsetzung als Zustandsautomat kann der aktuelle Zustand des Clients einfach an andere Komponenten weitergegeben werden. Die Anforderungen, verloren gegangene Verbindung automatisch wieder aufzubauen wurde für die Verbindung zu dem Caster umgesetzt. Die Umsetzung der W-LAN-Verbindung und deren Funktion zum automatischen Wiederverbinden wurde bereits in der vorhandenen Software des Rovers umgesetzt.
 				\item Für die Navigation müssen die Daten für eine \textbf{Route} gespeichert werden. Das Management der Routen wurde den Anforderungen entsprechend vollständig implementiert und wird in Abschnitt \ref{ssec:route_management} beschrieben. Dabei wurde die Speicherung von einzelnen Punkten mit Metadaten, welche durch eine verkette Liste in eine feste Reihenfolge gebracht werden, umgesetzt. Außerdem wurde die Schnittstelle zu einer HTTP-API implementiert, damit die Routen unabhängig von dem ESP32 persistiert werden können. Eine neue Route kann mit dem dafür angelegten Betriebsmodus des Rovers aufgenommen werden.
-				\item Die neue Kernfunktion wurde in zwei Funktionen aufgeteilt, davon ist die erste die \textbf{Navigation}. Mit dieser wird die Route lesend verarbeitet und die Informationen über Distanz und Kurs zum nächsten Punkt werden über einen erstellten Datentypen der nutzenden Komponente zur Verfügung gestellt. Eine nähere Beschreibung der Vorgehensweise ist in Abschnitt \ref{ssec:navigation_implementation} zu finden. Die Eigenständig der Navigation wurde durch die Implementierung als Komponente erreicht.
+				\item Die neue Kernfunktion wurde in zwei Funktionen aufgeteilt, davon ist die erste die \textbf{Navigation}. Mit dieser wird die Route lesend verarbeitet und die Informationen über Distanz und Kurs zum nächsten Punkt werden über einen erstellten Datentypen der nutzenden Komponente zur Verfügung gestellt. Eine nähere Beschreibung der Vorgehensweise ist in Abschnitt \ref{ssec:navigation_implementation} zu finden. Die Eigenständigkeit der Navigation wurde durch die Implementierung als Komponente erreicht.
 				\item Die zweite Funktion zur Realisierung der Kernfunktion ist der \textbf{Autopilot}. Dessen Anforderung werden durch die Implementierungen ab Abschnitt \ref{ssec:route_drive} erfüllt. Dafür wurde der Autopilot und der dazu passende Betriebsmodus entwickelt. Die Kernfunktionen werden zusätzlich mit dem Test in Abschnitt \ref{sec:tests} überprüft.
 			\end{itemize}
 
@@ -79,7 +79,7 @@
 			Zusammen mit der Erfüllung der gestellten Anforderungen an die Referenzstation lässt sich diese als voll funktionsfähig beschreiben. Da der Wartungsaufwand voraussichtlich sehr gering ausfallen wird, reduziert dies die Relevanz der eben genannten Einschränkungen. Einiger dieser Einschränkungen lassen sich mit einem Projekt auf GitHub namens \texttt{RTKBase} \cite[]{rtkbase} beheben und die Referenzstation damit mit Flexibilität ausstatten. Diese mögliche Änderung wird kurz im Abschnitt \ref{sec:ausblick} Ausblick beschrieben.
 
 		\subsection{Ntrip Revision 1}
-			Es wurden die beiden Revision des Ntrip-Protokolls jeweils mit dem Caster \url{rtk2go.com} und \url{sapos-ni-ntrip.de} getestet. Dabei wurde aufgrund der Abwärtskompatibilität erwartet, dass beide Caster die aktuelle Revision von Ntrip akzeptieren. Bei der Erstellung des Mountpoints auf \url{rtk2g0.com} wurde aufgrund der Empfehlungen des Formulars die Revision 1 von Ntrip gewählt. Welche Version von Ntrip der Caster von Sapos nutzt, ist auf der Website nicht ersichtlich. Da jedoch von beiden Castern Anfragen beider Ntrip Revisionen akzeptiert wurden, wird davon ausgegangen, dass auch beide die Revision 1 nutzen.
+			Es wurden die beiden Revision des Ntrip-Protokolls jeweils mit dem Caster \url{rtk2go.com} und \url{sapos-ni-ntrip.de} getestet. Dabei wurde aufgrund der Abwärtskompatibilität erwartet, dass beide Caster die aktuelle Revision von Ntrip akzeptieren. Bei der Erstellung des Mountpoints auf \url{rtk2g0.com} wurde aufgrund der Empfehlungen des Formulars die Revision 1 von Ntrip gewählt. Welche Version von Ntrip der Caster von Sapos nutzt, ist in den Bereitgestellten FAQs \cite[]{saposfaq} nicht ersichtlich. Da jedoch von beiden Castern Anfragen beider Ntrip Revisionen akzeptiert wurden, wird davon ausgegangen, dass auch beide die Revision 1 nutzen.
 			\par
 			Durch die vorhandene und funktionierende Abwärtskompatibilität kann daher problemlos auf die veraltete Revision verzichtet werden. Sollte doch mal ein Caster aus unerwarteten Gründen nur die Revision 1 akzeptieren, kann dies durch den implementierten Client berücksichtigt werden.