diff options
Diffstat (limited to 'docs/formal/main.tex')
| -rw-r--r-- | docs/formal/main.tex | 250 |
1 files changed, 187 insertions, 63 deletions
diff --git a/docs/formal/main.tex b/docs/formal/main.tex index 8831883..9ca9036 100644 --- a/docs/formal/main.tex +++ b/docs/formal/main.tex @@ -42,7 +42,7 @@ \newglossaryentry{kicad} { name=KiCad, - description={Open-Source-Software-Suite für elektronische Schaltungen und zum Platinendesign \href{https://www.kicad.org/}{Webseite}} + description={Open-Source-Software-Suite für elektronische Schaltungen und zum Platinendesign \url{https://www.kicad.org/}} } \newglossaryentry{esp} @@ -72,6 +72,24 @@ } } +\newglossaryentry{mongoose} +{ + name=Mongoose, + description={ + Mongoose ist eine Plattformübergreifende Webserver Bibliothek die sich Speziell für Mikrocntroller spezialisiert ist.\\ + \url{https://mongoose.ws/} + } +} + +\newglossaryentry{ams1117} +{ + name=AMS1117, + description={ + Ein Familie von Abwärtswandlern die ein Strom Signal in ein schwächeres Strom umwandeln. \\ + \href{http://www.advanced-monolithic.com/pdf/ds1117.pdf}{Datenblatt} + } +} + \begin{document} \begin{titlepage} \begin{center} @@ -118,9 +136,6 @@ Für die Entwicklung der Firmware wird der Sublime Text Editor benutzt. Der Schaltplan und das Platinen design werden in \gls{kicad} angefertigt. -\subsubsection{Betrieb} -Die DataTrustee GmbH - \subsection{Anforderungen} Wir haben die Anforderung, eine digitale Anbindung an unsere bestehenden Produkte zu entwickeln, um die Steuerung zu erleichtern und die Bedürfnisse unserer Kunden zu erfüllen. @@ -141,7 +156,7 @@ Die Shelly IoT API Kompatibilität benötigt: \begin{itemize} \item WiFi Access-Point zur erstmaligen Konfiguration mit den folgenden Einstellungen: \begin{itemize} - \item SSID mit Gerät Typ und MCA Adresse + \item SSID mit Gerät Typ und MAC Adresse \item Kein Passwort \item Statische IP Addresse 192.168.33.1 für das Gerät \item DHCP Server für zusätzliche teilnehmer @@ -169,68 +184,68 @@ Für das Projekt gibt es die folgende Zeitplanung \begin{tabular}{ | l | r | } \hline - Planung& 10 \\ - Analyse& 10 \\ + Analyse& 3 \\ Konzept& 10 \\ - Realiserung& 10 \\ - Dokumentation& 10 \\ - Fazi& 10 \\ - Puffer& 10 \\ + Realiserung& 34 \\ + Tests& 8 \\ + Dokumentation& 13 \\ + Fazit& 7 \\ + Puffer& 5 \\ \hline \hline - \textbf{Gesamt}& 15 Stunden \\ + \textbf{Gesamt}& 80 Stunden \\ \hline \end{tabular} \pagebreak -\section{Analyze} \subsection{Ist Analyze} -Derzeit müssen unsere Messprodukte manuell betätigt werden. -Unsere Messgeräte bestehen aus fertig produzierte Geräte die wir Elektronisch mit einander Verbinden +Derzeit verkaufen wir Messgeräte die intern vor-konfektionierte Elektronik besitzen und von uns nur Elektronisch verkabelt werden damit die Nutzung für den End-Nutzer vereinfacht wird. -\subsection{Wirtschaftlichkeit} -Für die Wirtschaftlichkeitsrechnung werden die folgenden Beispiel Werte benutzt die der Realität ähnel: -\begin{itemize} - \item Anfahrt von Bochum nach Münster und zurück (~160km) - \item Benzinverbrauch je 100 Meter (7 liter) -\end{itemize} +\subsection{Kosten-Nutzen Analyse} +Mit der Kosten-Nutzen Analyse ermitteln wir die Wirtschaftlichkeit des Projektes für die Firma. +Das Projekt kommt aus Nachfragen von Kunden, ist aber kein direktes Kunden Projekt. -Projektdurchführung \\ \begin{tabular}{ | l | r | } \hline - - Stundenlohn& 35,00 € \\ Projektstunden& 80\\ + Auszubildener Stundenlohn& 35,00 €\\ + \hline + \hline + Arbeitslohn& 2.800,00 €\\ \hline - Arbeitslohn& 2800,00 € \\ - Entwicklungsumgebung& 100,00 € \\ - Computer& 300,00 € \\ +\end{tabular} + +Der berechnete Arbeitslohn bezieht sich auf Durchschnittliche Werte und ist nicht unbedingt Personen bezogen. +\begin{tabular}{ | l | r | } \hline + Lohn& 2.800,00 €\\ + Hardware Pauschale& 100,00 €\\ + Ressourcen-Pauschale& 100,00 €\\ \hline - - \textbf{Projektkosten}& 3200,00 € \\ \hline -\end{tabular} -\\ \\ -Ohne Projekt \\ -\begin{tabular}{ | l | r | } + Projektkosten& 3.000,00 €\\ \hline +\end{tabular} + +Mit dem Projekt würde sich ein möglicher Kunde die mehrfache Anfahrt zu einem Ort sparen in dem des Gerät Ferngesteuert werden kann. - Entfernung& 160 km \\ - Sprit/Liter& 1,90 € \\ - Verbrauch/100km& 7 l\\ +Da wir nicht genau wissen können wie der Kunden anfährt vermuten wir die Nutzung eines PKWs mit durchschnittlichen Verbrauch sowie durchschnittliche Spritkosten und eine Entfernung die der Realität entspricht. + +\begin{tabular}{ | l | r | } \hline + Entfernung& 160 km\\ + Spritkosten pro Liter& 1,90 €\\ + Verbrauch / 100km& 7 l\\ \hline - - \textbf{Spritkosten/Anfahrt}& 21,28 € \\ \hline -\end{tabular} \\ -\\ + Anfahrkosten& 21.28 €\\ + \hline +\end{tabular} \begin{tikzpicture} \begin{axis}[ @@ -251,32 +266,101 @@ Ohne Projekt \\ samples=100, color=blue, ] - {3200}; -\addlegendentry{Mit Projekt} + {x * 21.28}; +\addlegendentry{Anfahrkosten} \addplot [ domain=0:200, samples=12, color=red, ] - {x * 21.28}; -\addlegendentry{Ohne Projekt} + {3000}; +\addlegendentry{Projektkosten} \end{axis} \end{tikzpicture} +Das Projekt würde nach \textit{141} Anfahrten billiger sein als die Anfahrkosten. +Bei Kunden die eine Großzahl an Geräten verwenden würde sich das Projekt schnell lohnen. + \subsection{Nicht Monitäre Vorteile} -Das Gerät spart Zeir für die Anfahrt und Aufsicht die anders verwendet werden kann. +Eine Digital Anbindung würde Automatisierung Möglichkeiten erzeugen wo ein Messsensor zu bestimmten Bedingungen eingeschaltet werden kann. + \pagebreak \section{Konzept} +\subsection{Soll-Konzept} +Für ein Soll-Konzept müssen verschiedene Eigenschaften des Projektes entschieden werden. + +Einige Elemente wurden schon im Projektantrag entscheiden, wie zum Beispiel die Auswahl von C++ für die Programmiersprache und den \gls{esp} für den Mikrocntroller. +Diese Entscheidungen werden trotzdem noch einmal übergangen um herauszufinden ob es nicht bessere Alternativen gäbe. + +\subsubsection{Programmiersprache} + +Für Embedded Software Projekte eignen sich meist Kompilierte Sprachen da diese Quellcode in effizienten Maschinen Code konvertieren und damit Speicherbedarf und Rechnenleistung gespart werden können. +Die Sprachen die zur Wahl stehen sind: +\begin{itemize} + \item C + \item C++ + \item Rust + \item Zig +\end{itemize} + +\paragraph{C} +C biete sich am besten an da es Offiziell vom Hersteller Unterstützt wird + +\paragraph{C++} +Wie C werden Offizielle Compiler angeboten dazu bietet C++ eine umfangreiche Standardbibliothek sowie Kompatibilität mit C-Bibliotheken, wodurch das Projekt leicht erweitert und angepasst werden kann. + +\paragraph{Rust} +Rust ist eine LLVM basierte Programmiersprache und LLVM hat derzeit keine Unterstützung für die Xtensa Architektur des ESP32. +Die Community arbeitet daran Rust für diese Architektur bereitzustellen, jedoch gibt es noch viel was erarbeitet werden muss. + +\paragraph{Zig} +Zig ist eine relative neue Programmier Sprache mit noch keinen Stabilen Versionen. +Sie ist zwar nicht an LLVM gebunden, hat derzeit aber noch keine unterstützung für die ESP32 Architektur \\ + +Erstaunlicher weiße gibt es auch eine beliebte interpretierte Programmiersprache für den ESP32: \textbf{Micropython} + +Micropython hat jedoch den Nachteil dass das Programm während der Laufzeit interpretiert werden muss und somit viel langsamer ist als Kompilierte alternative. +Dazu bring die Standardbibliothek nicht viele Funktionalitäten die man vom Hersteller kriegen würden. + +Sommit fällt die entscheidung weiterhin auf \textbf{C++}. + +\subsection{Mikrocntroller} + +In der Mikrocontroller Industrie gibt es viele zur Auswahl, am Ende sind die folgenden Chips in die Engere Auswahl gekommen: + +\begin{itemize} + \item ESP32 + \item ESP8266 + \item RP2040 +\end{itemize} + +Bei der Auswahl war es wichtig einen Mikrocontroller zu verwenden die in einem praktisch Modul Formfaktor vorhanden sind. +Die eigentlichen Integrierten Chips brauchen meist sehr genaue Anforderungen an passiven Komponenten. + +\paragraph{ESP32} +Die ESP32 Familie von Mikrocontrollern ist weit beliebt durch ihre Performanz sowie ihr Kleiner Form Faktor und Netzwerk Fähigkeiten, sei es WiFi, Bluetooth oder sogar Zigbee. +Der Mikrocontroller selbst ist meist als sogenannter System on a Chip, Modul und als Entwicklung Einheit vorhanden. + +\paragraph{ESP8266} +Älterer Chipsatz welcher auch Netzwerk fähig ist, wurde jedoch Funktional von der ESP32 Familie ersetzt. + +\paragraph{RP2040} +Der RP2040 ist ein neuer AMD basierter Mikrocontroller von der Raspberry Pi Foundation. +Sehr beliebt in Hobby Projekten und sehr Kosten Günstig, je 1€ pro Chip, ist jedoch nur als Entwickler Platine und als System on a Chip verfügbar. +Wifi und Bluetooth müssten extern bei der Platinen Entwicklung angebunden werden. + +Am Ende hat sich der \textbf{EP32} war der ESP32 die beste Entscheidung da die Chip Familie gut und weiterhin vom Entwickler sowie von der Community unterstützt wird und durch den Modul Formfaktor bei der Platinen Entwicklung weniger Hindernisse aufbringen wird. + \subsection{Schaltplan} Der \gls{esp}, braucht eine Aktivspannung on 3.3V und geht von Nominalen 500mA Strom für die Verwendung von WiFi und Bluetooth aus. Um die Stromversorgung zu vereinfachen wird ein einfacher USB Port verwendet. Da der USB Standard 5V vorsieht brauchen wir einen Abwärtswandler. -Wir haben uns dabei für den \href{http://www.advanced-monolithic.com/pdf/ds1117.pdf}{AMS1117-3.3} (U5) entschieden welcher eine Spannung von mindestenz 4.7V zu 3.3V umwandelt. +Wir haben uns dabei für den \gls{ams1117} (U5) entschieden welcher eine Spannung von mindestenz 4.7V zu 3.3V umwandelt. Die Verwendung eines Spannungsteiler ist hier leider nicht möglich, da der USB2.0 Nominal einen Strom von 500mA vorsieht, genug um den Mikrocontroller zu betreiben. Um zu verhindern, dass die Spannung durch momentare Stromlast gesenkt wird, wird mit 2 Kondesatoren mit jeweils 10uF (C2) und 0.1uF (C1) die Stromversorgungsschiene entkoppelt. @@ -292,16 +376,16 @@ Die Anbindung der Pins folgt UART, dabei wird der DTR und RTS pin zum einschalte \includegraphics[scale=0.75]{schematic.png} \\ -\subsection{Architektur} -Die Firmware wurde vollständig in prozeduralem C++ verfasst. C++ bietet eine umfangreiche Standardbibliothek sowie Kompatibilität mit C-Bibliotheken, wodurch das Projekt leicht erweitert und angepasst werden kann. +\subsection{Software} +Die Entwicklung für den \gls{esp} wurde mit der Offiziellen \href{https://docs.espressif.com/projects/esp-idf/en/stable/esp32/index.html}{ESP-IDF} Toolchain durchgeführt. +Diese Unterstützt alle Hardware Komponente direkt und kommt mit vielen nützlichen Bibliotheken inkludiert welche in diesem Projekt verwendet werden, zum Beispiel ein \href{https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_http_server.html?highlight=http}{HTTP Server}. -Der Code ist in Dateien organisiert, die entsprechend ihrer Funktion benannt sind, z. B. \textit{net.cpp} für alle Netzwerk-relevanten Logiken. Die Methoden zur Verarbeitung von HTTP-Anfragen sind nach ihren Pfaden sortiert. +Ehemalig war mDNS Unterstützung teil der Entwicklungsumgebung, wurde aber später von Espressif als eigene Komponente abgetrennt. +Da die Inklusion dieser Komponente sehr einfach ist werden wir diese für das Projekt benutzen. \pagebreak \section{Realisierung} -\subsection{Übersicht} - \subsection{Hardware} Der Prototyp wurde auf einem Breadboard aufgebaut, wobei vorgefertigte Breakout-Boards genutzt wurden, um Kosten bei der Entwicklung einzusparen. Ein wesentlicher Unterschied zwischen dem Schaltplan und dem Platinen-Design besteht darin, dass im Breadboard-Design ein \gls{llc} zur Unterstützung der seriellen Verbindung mit anderen Chips verwendet wurde. Da der \gls{cp2102} Chip mit Spannungen von 3,3 und 5V arbeiten kann, wurde dies nicht weiter benötigt. Für den \gls{esp} wurde aufgrund des Mangels an einem vorgefertigten Breakout-Board ein eigenes Board entworfen und produziert. @@ -325,8 +409,38 @@ Für den Prototypen gibt es ein vollständiges Platinen design mit jeweils den g %\pagebreak %\includegraphics[scale=0.25]{pcb_3d_perspective.jpg} - \subsection{Software} +Die Software wurde vollständig in prozeduralem C++ verfasst, da die ESP-IDF Komponenten sich mehr für prozeduralem Strukturen eignen. + +Für die Implementierung wurde die Logik in die folgende Komponente unterteilt: +\begin{itemize} + \item HTTP Server und Routen + \item Netzwerk Logik + \item Relay Logik + \item Einstellungen +\end{itemize} +Somit wird sichergestellt das Änderungen an einzelnen Komponenten keinen Indirekten Einfluss auf andere haben kann. + +\subsubsection{HTTP Server und Routen} +Als HTTP Server benutzen wir die inkludierte Komponente der ESP-IDF Toolchain. +Diese erlaubt uns beliebig viele Routen zu registrieren die wir dann verarbeiten können. + +Routen wurden in einen Unterordner ausgelagert wo die Methoden eines Hauptpfad in eine Datei implementiert werden. + +So werden z.B. \textit{/settings} und \textit{/settings/sta} von \textit{settings.cpp} implementiert. + +\subsubsection{Netzwerk} +Für die WiFi Nutzung wird die die \href{https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_netif.html}{ESP-NETIF} Komponente Verwendet. +Diese erlaubt uns verfügbare Netzwerk Hardware anzusteuern und über Generische Methoden anfragen zu versenden. + +Für \gls{mdns} wird die die \href{https://components.espressif.com/components/espressif/mdns}{mdns Komponente} von Espressif verwendet welche sich direkt mit netif integriert. + +\subsubsection{Relais} +Die Relay Komponente beinhaltet Methoden womit externe Komponente den Status des Relais abfragen und ändern können. + +\subsubsection{Einstellungen} +Die Einstellung beinhaltet Methoden zum einstellen und abfragen von Konfigurationen wie zum Beispiel die WiFi Konfiguration. + \pagebreak \section{Testphase} @@ -336,40 +450,50 @@ Für den Prototypen gibt es ein vollständiges Platinen design mit jeweils den g Mit Blackbox Tests Prüfen wie die Funktionalität des Web Servers sowie der jeweiligen Routen und deren Verhalten. Im gegensatz zu einem Whitebox tests sind Implementierungs Details irrelevant solange das Geräte richtig auf Anfragen reagiert. +Um dies zu Testen haben wir 2 Programme laufen lassen: + +\begin{itemize} + \item Ein Programm das dauerhaft das Relay ausschalten wollte, und überprüft hat ob die Antwort den Status als Aus zurück gegeben hat + \item Ein Programm das dauerhaft das Relay einschalten wollte, und überprüft hat ob die Antwort den Status als Ein zurück gegeben hat +\end{itemize} + +Über 8 Stunden gab es dabei keine Probleme. + \subsection{Stress Test} -Bei Stress tests wurde das Gerät dauerhaften mit Anfragen unterdrückt um sicher zu stellen das es auch unter großen Anzahlen von Anfragen weiterhin problemlos läuft. +Mit Stress Test wird die Belastbarkeit und Leistung des Web Servers überprüft. +Dies ist besonders über längere Zeiträume wichtig um potenzielle Probleme frühzeitig zu ermitteln. + +Um das Gerät gründlich zu strapazieren haben wir einen Test aufgebaut wobei das Gerät von 3 Endgeräten über 24 Stunden dauerhaft angefragt wurde und Relais umgeschalten. -Mit Stresss Test wird die Belastbarkeit und Leistung des Web Servers überprüft. -Dies ist besonders über längere Zeiträume wichtig um potenzielle Probleme frühzeitig zu ermitteln.1 +Bei den Test ist es zu keinen Ausfällen gekommen, jedoch hat sich gezeigt das der HTTP Server inkludiert in ESP-IDF sich nicht sehr gut belasten lässt. \pagebreak \section{Dokumentation} \subsection{Erstellung} -Die Firmware wurde nach dem Prinzip der Selbst-Dokumentierung Entwickelt, so ist der Nutzen jeder Funktion direkt erkennbar oder, wenn dieser zu ungenau ist in der Beschreibung der Funktion. +Die Software wurde nach dem Prinzip der Selbst-Dokumentierung Entwickelt, so ist der Nutzen jeder Funktion direkt erkennbar oder, wenn dieser zu ungenau ist in der Beschreibung der Funktion. -Um eine Übericht über die Firmware zu gewärleisten wird Doxygen benutzt um ein HTML Dokument zu erstellen mit dem man die selbst-dokumentierten Informationen einsehen kann +Um eine Übersicht über die Firmware zu gewährleisten wird Doxygen benutzt um ein HTML und PDF Dokument zu erstellen mit dem man die selbst-dokumentierten Informationen einsehen und direkt mit dem Quellcode vergleichen kann. \subsection{Kundendokumentation} Die Kundendokumentation besteht aus einer kleinen Einleitung zur Konfiguration und Bedienung des Gerätes mit Bildern der App zu Hilfestellung. \\ Der Elektronische Einbau ist in der Kundendokumentation nicht beschrieben, da dies von uns in Geräte vorgefertig wird. -\\ +\\ \\ \hyperref[sec:kd]{8.2 Kundendokumentation} \pagebreak \section{Fazit} -\subsection{Soll/Ist Vergleich} \subsection{Erkenntnisse} Wärend der Testphase wurden einige Erkenntnisse gesammelt wie das Projekt in der Zukunft verbessert werden könnte: \begin{itemize} - \item Die ESP-IDF HTTP Server Komponente ist nicht für hohe Verfügbarkeit optimiert, so kann es dazu kommen das Anfragen verzögert verarbeitet werden. Ein alternative HTTP Server der sich besser hierfür eignet wäre \href{https://github.com/cesanta/mongoose}{Mongoose} + \item Die ESP-IDF HTTP Server Komponente ist nicht für hohe Verfügbarkeit optimiert, so kann es dazu kommen das Anfragen verzögert verarbeitet werden. Ein alternative HTTP Server der sich besser hierfür eignet wäre \gls{mongoose} \end{itemize} \subsection{Ausblick} -Das Projekt wurde erfolgreich umgesetzt und erfüllt die erforderten Anforderungen. \\ -Trotzdem gibt es weiterhin verbesserungen die man in einem folge Projekt analysieren sollte +Das Projekt wurde vollständig umgesetzt und erfüllt die erforderten Anforderungen. +Bei der Entwicklung sind Erkenntnisse aufgekommen die die Belastbarkeit verbessern würde, was man mit der Simplen jedoch Effizienten Struktur der Software leicht umsetzen kann. \pagebreak \section{Anhang} @@ -380,8 +504,8 @@ Trotzdem gibt es weiterhin verbesserungen die man in einem folge Projekt analysi \setcounter{subsection}{1} \subsection{Kundendokumentation} -\input{Kundendokumentation} \label{sec:kd} +\input{Kundendokumentation} \pagebreak \setcounter{subsection}{2} |