Testung eines Nachrichtensystems basierend auf einem Ad-Hoc LoRa Netzwerk

Testung eines Nachrichtensystems basierend auf einem Ad-Hoc LoRa Netzwerk Abschlussarbeit zur Erlangung des akademischen Grades: Bachelor of Science (B.Sc.) an der Hochschule für Technik und Wirtschaft (HTW) Berlin Fachbereich 4: Informatik, Kommunikation und Wirtschaft Studiengang Angewandte Informatik 1. Gutachter: Prof. Dr. Alexander Huhn 2. Gutachter: Prof. Dr.-Ing. Thomas Schwotzer Eingereicht von Raphael Walger [582524] 08.08.2025 Inhaltsverzeichnis 1. Einleitung 1 1.1. Motivation.................................... 1 1.2. Problemstellung und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. AufbauderArbeit ............................... 2 2. Grundlagen 4 2.1. Ad-hoc-Netzwerke ............................... 4 2.2. ASAP....................................... 4 2.3. ASAPEncounter ................................ 5 2.4. ASAPPeer .................................... 5 2.5. ASAPJava .................................... 5 2.6. ASAPHub .................................... 6 2.7. ASAPAndroid.................................. 6 2.8. LoRa ....................................... 6 2.9. LoRaWAN.................................... 6 3. Analyse 8 3.1. StandderForschung.............................. 8 3.2. Vorarbeiten.................................... 8 3.2.1. Erweiterung der Kommunikationsreichweite von ASAPAndroid durchLoRa ............................... 8 3.2.2. Erweiterung der Kommunikationsreichweite vom ASAPHub durch LoRa ................................... 9 3.2.3. Alternative zum ASAPHub mit LoRa . . . . . . . . . . . . . . . . 9 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation 11 4.1. VerwendeteHardware............................. 11 4.1.1. Einplatinencomputer Raspberry Pi Zero 2 WH . . . . . . . . . . 11 4.1.2. LoRa-Funkmodul HIMO-01M . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Festspannungsregler-Modul AMS1117-3.3 . . . . . . . . . . . . . 12 4.2. VerwendeteSoftware.............................. 13 4.3. Weitere benötigte Werkzeuge und Materialien . . . . . . . . . . . . . . . 13 4.4. Gehäuse der Verbindungsstation . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Anleitung zur Einrichtung einer Verbindungsstation . . . . . . . . . . . 14 4.5.1. Erster Schritt: die Software vorbereiten . . . . . . . . . . . . . . . 15 4.5.2. Zweiter Schritt: die Hardware vorbereiten . . . . . . . . . . . . . 16 4.5.3. Dritter Schritt: Ersteinrichtung abschließen . . . . . . . . . . . . . 16 4.6. Test zur Verifizierung einer erfolgreichen Ersteinrichtung . . . . . . . . 17 4.6.1. Verifizierung mit einer weiteren Verbindungsstation . . . . . . . 18 i Inhaltsverzeichnis 4.6.2. Verifizierung mit ASAPService . . . . . . . . . . . . . . . . . . . . 18 5. Testen der Verbindungsstation 20 5.1. Angewandte Testmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Aufbau der Testsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.1. Aufbau der Unterstützungsmethoden . . . . . . . . . . . . . . . . 21 5.2.2. Aufbau der Oberklasse . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Tests zu akzeptierten Grenzwerten . . . . . . . . . . . . . . . . . . . . . . 23 5.3.1. Planung der Grenzwerttests . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2. Dokumentation der Ergebnisse der Grenzwerttests . . . . . . . . 24 5.4. Tests zur maximal versendbaren Nutzlast . . . . . . . . . . . . . . . . . . 24 5.4.1. Planung der Nutzlasttests . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.2. Software für die Nutzlasttests . . . . . . . . . . . . . . . . . . . . 25 5.5. Tests zur maximalen Reichweite . . . . . . . . . . . . . . . . . . . . . . . 26 5.5.1. Planung der Reichweitentests . . . . . . . . . . . . . . . . . . . . . 26 5.5.2. Software für die Reichweitentests . . . . . . . . . . . . . . . . . . 28 5.6. Tests zum maximalen Datendurchsatz . . . . . . . . . . . . . . . . . . . . 29 5.7. Tests zur Dienstverfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.7.1. Planung der Dienstverfügbarkeitstests . . . . . . . . . . . . . . . 30 5.7.2. Software für die Dienstverfügbarkeitstests . . . . . . . . . . . . . 30 5.8. Belastungstests ................................. 30 5.8.1. Planung der Belastungstests . . . . . . . . . . . . . . . . . . . . . 31 5.8.2. Software für die Belastungstests . . . . . . . . . . . . . . . . . . . 31 5.9. Tests zur Leistungsaufnahme . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.9.1. Planung der Leistungsaufnahmetests . . . . . . . . . . . . . . . . 32 5.9.2. Hardware für die Leistungsaufnahmetests . . . . . . . . . . . . . 33 5.9.3. Ergebnisse der Leistungsaufnahmetests . . . . . . . . . . . . . . . 33 6. Auswertung der Testergebnisse 35 6.1. Auswertung der Grenzwerttests . . . . . . . . . . . . . . . . . . . . . . . 35 6.2. Auswertung der Tests zur maximal versendbaren Nutzlast . . . . . . . . 36 6.3. Auswertung der Reichweitentests . . . . . . . . . . . . . . . . . . . . . . 37 6.4. Auswertung der Tests zum maximalen Datendurchsatz . . . . . . . . . . 41 6.5. Auswertung der Tests zur Dienstverfügbarkeit . . . . . . . . . . . . . . . 42 6.6. Auswertung der Belastungstests . . . . . . . . . . . . . . . . . . . . . . . 44 6.7. Auswertung der Tests zur Leistungsaufnahme . . . . . . . . . . . . . . . 45 6.7.1. Auswertung der Tests zur Leistungsaufnahme im Szenarium der keinenNutzung ............................ 45 6.7.2. Auswertung der Tests zur Leistungsaufnahme im Szenarium der gelegentlichen Nutzung . . . . . . . . . . . . . . . . . . . . . . . . 46 6.7.3. Auswertung der Tests zur Leistungsaufnahme im Szenarium der starkenNutzung ............................ 47 6.7.4. Auswertung der Tests zur Leistungsaufnahme aller drei Szenarien 47 7. Zusammenfassung 48 ii Inhaltsverzeichnis 8. Ausblick 50 Quellenverzeichnis v Appendices viii A. Software ix B. Tabellen x C. Dateiinhalte xii iii Danksagung Im nachfolgendem Text möchte ich einigen Personen für ihre Unterstützung, sei es fachlicher, organisatorischer oder anderer Natur, danken. Zu Beginn danke ich meiner Familie, besonders meinen Eltern, für die Ermöglichung meines Studiums, für das Motivieren und dem Korrekturlesen, sowie für ihre Vorschläge und Rat. Bei Marvin Rausch bedanke ich mich für seine Hilfe und Ratschläge während der Ersteinrichtung einer Verbindungsstation und das schnelle Antworten auf meine Fragen. Ich danke Milan Pavlov für seine hilfreichen Vorschläge und die Empfehlung unterstützender Software. Auch Nicole Brehmer, Peter Brack und Udo Martin möchte ich für ihren Rat und das Korrekturlesen danken. Zusammenfassung Innerhalb dieser Bachelorarbeit soll das von Rausch entwickelte Nachrichtensystem, basierend auf einem Ad-Hoc LoRa1 Netzwerk, getestet werden. Diese Arbeit betrachtet insbesondere die Verbindungsstation jenes entwickelten Nachrichtensystems, welche eine Punkt-zu-Punkt-Verbindung zwischen Geräten, die das Routing-Protokoll ASAP2 nutzen, über große Distanzen hinweg ermöglicht. Das Resultat sollen Kenndaten zu Reichweite, Leistung einer Verbindungsstation und Belastbarkeit jenes entwickelten Nachrichtensystems sein. Es sollen die Leistungsaufnahme der Hardware in unterschiedlichen Szenarien dokumentiert und die mögliche Reichweite der Verbindungsstation überprüft werden. Auch soll die Belastbarkeit des Netzwerkes und dessen Robustheit unter Last getestet werden. Die Leistung einer Verbindungsstation hinsichtlich des Datendurchsatzes und die Dienstverfügbarkeit sollen ebenfalls getestet werden. Zuvor soll ein Gehäuse für die Hardware entwickelt werden und die Ersteinrichtung und Konfiguration einer Verbindungsstation vollständig dokumentiert werden, um die Nutzbarkeit und Wiederverwendbarkeit des bereits entwickelten Gesamtsystems zu erhöhen. Abstract This thesis deals with the communication system, which was developed by Rausch and is based on a Ad-Hoc LoRa network, by performing some tests. In particular, this thesis focuses on the connection station of the developed communication system, which makes a point-to-point connection between devices, which use the routing protocol ASAP , possible over big distances. The result should be key data about the range and the performance of a connection station, and about the resilience of the developed system. The power consumption of the hardware should be documented and the potential range of a connection station should be examined. Furthermore, the data throughput and the service availability should be checked. Before that, a case for the hardware should be developed, and the initial setup as well as the configuration of a connection station should be documented in full, in order to increase the useabilty and reuseability of the already developed system. 1Long Range 2Asynchronous Semantic Ad-hoc Protocol 1. Einleitung 1.1. Motivation Einer Gesellschaft, die besonderen Wert auf den Datenschutz und die Datensicherheit legt, ermöglicht das Protokoll ASAP ein dezentrales Kommunikationsnetz aufzubauen. ASAP bieten sowohl Privatpersonen eine alternative Umgebung zum Aufbau eines Kommunikationsnetzwerkes an als auch Sicherheitsund Versorgungskräften. Dies kann besonders dann von Vorteil sein, wenn die zuvor bestehende lokale Kommunikationsstruktur aufgrund einer Umweltkatastrophe, politischen Unruhen oder anderweitigen Ausnahmezuständen beschädigt oder vollständig zerstört wurde. Zwischen Endgeräten, die das Protokoll ASAP implementieren, wird über eine Punktzu-Punkt-Verbindung kommuniziert. Bis vor Kurzem konnte solch eine Verbindung nur auf Basis von Bluetooth oder WIFI1 -Direct innerhalb kurzer Distanzen und einer TCP/IP2 -Verbindung für größere Entfernungen hergestellt werden. Der Nachteil der Nutzung solch einer Verbindung ist das Angewiesensein auf ein bestehendes, funktionierendes, zentrales Kommunikationsnetz. Um auch über große Distanzen hinweg auf ein dezentrales Kommunikationsnetzwerk zurückgreifen zu können, wurde das Protokoll ASAP um den Funkstandard LoRa erweitert. Dies geschah in der Masterarbeit von Rausch mit dem Namen „Entwicklung eines Nachrichtensystems basierend auf einem Ad-Hoc LoRa Netzwerk“, welche am 28.10.2024 abgegeben wurde.[14] Das Ergebnis jener Masterarbeit bildet die Grundlage für diese Arbeit. Sie wird geschrieben, um die von Rausch entwickelte Software für mehr Personen zugänglicher zu gestalten, sodass die entwickelten Komponenten auch unter weniger technikaffinen Individuen zum Einsatz kommen und aktiv genutzt werden kann. Um diese Alternative zu einem zentralen Kommunikationsnetz besser einschätzen und evaluieren zu können, sodass es beispielsweise in Krisengebieten mit einem gestörtem Mobilfunknetz oder Festnetzanschluss eingesetzt werden kann, soll das entwickelte Nachrichtensystem, basierend auf einem Ad-Hoc LoRa Netzwerk, weiter dokumentiert und getestet werden. 1Wireless Fidelity 2Transmission Control Protocol/Internet Protocol 1 1. Einleitung 1.2. Problemstellung und Zielsetzung Um die entwickelten Softwarekomponenten zur Erweiterung von ASAPJava[24] für die jeweilige Situation beurteilen zu können, sollen dessen Verwendung dokumentiert und der Einsatz getestet werden. Das Ziel dieser Arbeit ist die Erstellung eines Überblickes über dessen Eigenschaften. Dazu soll sowohl die Hardware als auch die Software der Verbindungsstationen, welche die Schnittstelle zwischen ASAPJava und dem Funkstandard LoRa darstellen, getestet werden. Im Rahmen der Evaluierung des Netzwerksystems werden folgende Aspekte berücksichtigt: • Protokollierung der größtmöglich versendbaren Nutzlast • Überprüfung der maximalen Reichweite einer Verbindungsstation • Ermittlung des maximalen Datendurchsatzes • Dokumentation des Verhaltens einer Verbindungsstation im Test zur LangzeitDienstverfügbarkeit • Testung der Belastbarkeit und Robustheit des Netzwerkes unter Last • Dokumentation der Leistungsaufnahme der Hardware in unterschiedlichen Szenarien Noch vor dem Testen soll die physische Handhabbarkeit und Robustheit einer Verbindungsstation in das Nachrichtensystem, dass auf einem Ad-Hoc LoRa -Netzwerk basiert, durch eine Flächenminimierung der Hardwarekomponenten und einem zu entwickelnden Gehäuse für jene Komponenten erhöht werden. So soll nicht mehr ein Raspberry Pi der 5. Generation, sondern ein Raspberry Pi Zero WH der 2. Generation zum Einsatz kommen. Das Gehäuse soll zudem von einem handelsüblichen FDM3 3D-Drucker gedruckt werden können. Des Weiteren soll eine Dokumentation hinsichtlich der Ersteinrichtung der Hardware und Software einer Verbindungsstation in solch ein Netzwerk und der Nutzung dieses Netzwerkes erstellt werden. 1.3. Aufbau der Arbeit Beginnend werden in Kapitel zwei einige theoretische Grundlagen, wie das Protokoll ASAP, erläutert. Im dritten Kapitel wird eine Analyse der Grundlage und von vorangegangenen Arbeiten getätigt. Darauffolgend wird in Kapitel vier die Ersteinrichtung einer Verbindungsstation schrittweise dokumentiert. 3Fused Deposition Modeling 2 1. Einleitung Das Kapitel fünf umfasst die Testung der Verbindungstation, beginnend mit Tests zu akzeptierten Einstellungswerten des LoRa -Funkmoduls, Tests zur Ermittlung der größtmöglichen, erfolgreich versendbaren Nutzlast, der Testung der Reichweite innerhalb eines Städteszenarios, gefolgt von Leistungstests und Tests zur Belastbarkeit des dezentralen Kommunikationsnetzes. Die gesammelten Testergebnisse werden im Kapitel sechs analysiert und ausgewertet. Zuletzt folgt die Zusammenfassung dieser Arbeit und ein Ausblick. 3 3. Analyse Funkstandard LoRa an eine weitere Verbindungsstation, die dann aufgrund der MultiHop-Unterstützung von ASAP die Nachricht an den Empfänger weiterleiten kann.[14] Erste Tests haben die Funktionalität des Systems, dass im Hinblick auf Modularität entwickelt wurde, bereits bestätigen können.[14] Diese Arbeit von Rausch ist die Basis für die nachfolgenden Kapitel, innerhalb welcher eine Evaluierung, wie sie im Kapitel 1.2 beschrieben ist, der Verbindungsstation stattfinden soll. 10 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation Innerhalb dieses Kapitels wird die Ersteinrichtung einer Verbindungstation dokumentiert. Die Ersteinrichtung wird in einer aufgegliederten Form niedergeschrieben, sodass dieser schrittweise gefolgt werden kann. 4.1. Verwendete Hardware Die Verbindungstation besteht aus drei Modulen: einem Raspberry Pi Zero 2 WH, dem LoRa -Funkmodul HIMO-01M und einem Spannungsregler-Modul. Zusätzlich wird eine micro SD1 -Karte für den Raspberry Pi, eine zugehörige Antenne für das Funkmodul und einige einadrige Kabel benötigt. 4.1.1. Einplatinencomputer Raspberry Pi Zero 2 WH Der Unterschied im Namen der beiden Einplatinencomputer Raspberry Pi Zero 2 WH und Raspberry Pi Zero 2 W besteht nur im letzten Buchstaben H. Das Hkennzeichnet dasjenige Modul, das mit bereits verlöteten Pin-Reihen verkauft wird. Sofern sich für die Modulvariante ohne dem Hentschieden wird, muss hier zusätzlich Arbeitszeit investiert werden, da bei dieser Variante die Pin-Reihen noch nicht verlötet sind. Der Einplatinencomputer Raspberry Pi Zero W der 2. Generation bietet mit einer 64-bit Arm Cortex-A53 CPU2 und einer Taktfrequenz von einem Gigahertz sowie einem RAM3 mit einer Speicherkapazität von 512 Megabyte[12] ausreichend Rechenkapazität für die Aufgaben einer Verbindungsstation in das Nachrichtensystem, welches auf einem Ad-Hoc LoRa Netzwerk basiert. Es kann sowohl Verbindungen über WLAN4 im Frequenzbereich 2,4 Gigahertz, als auch über Bluetooth aufbauen.[12] Mit einem maximalen Stromverbrauch von 12,5 Watt pro Stunde 5 ist dieser Einplatinencomputer kostengünstiger zu betreiben als ein in der vorangegangenen Arbeit von Rausch im Jahr 2024 verwendetem[14] Raspberry Pi der 5. Generation, dessen maximaler Stromverbrauch mit 25 Watt pro Stunde6beziffert werden kann. 1Secure Digital Memory 2Central Processing Unit 3Random-Access Memory 4Wireless Local Area Network 5 Ergebnis der maximalen Stromaufnahme von 2,5 Ampere bei 5 Volt, Werte können der Quelle [12] entnommen werden 6 Ergebnis der maximalen Stromaufnahme von 5 Ampere bei 5 Volt, Werte können der Quelle [11] entnommen werden 11 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation Eine weitere Stärke des Raspberry Pi Zero 2 W ist die Tatsache, dass die Produktion bis zum Anfang des Jahres 2030[12] geplant ist. Dies ermöglicht voraussichtlich eine Verfügbarkeit für noch mindestens vier weitere Jahre. 4.1.2. LoRa-Funkmodul HIMO-01M Das LoRa -Funkmodul HIMO-01M ist die Schnittstelle zwischen dem Funkstandard LoRa und dem Einplatinencomputer. Zur Kommunikation zwischen den beiden Modulen wird das Protokoll UART7 verwendet. Der Frequenzbereich des Moduls liegt zwischen 410 Megahertz und 470 Megahertz.[8] Die Sendeleistung beträgt 19,26 Dezibel Milliwatt, und die Sensibilität liegt bei -148 Dezibel Milliwatt.[8] Mit der empfohlenen Versorgungsspannung von 3,3 Volt und einer Stromaufnahme von 93 Milliampere bei maximaler Daueremissionsstromstärke ergibt sich eine benötigte Versorgungsleistung von unter 0,31 Watt pro Stunde. Auf der Platine des Funkmoduls ist zwar ein Pin mit USB5V beschriftet, doch die Erfahrungen von Rausch haben gezeigt, dass das Modul nicht über diesen Pin, sondern nur mit 3,3 Volt versorgt werden sollte, da es sonst beschädigt werden kann. Um Schaden am Funkmodul zu vermeiden wird dementsprechend empfohlen, es nicht über den Pin USB5V mit einer Spannung von 5 Volt, sondern über den Pin VIN mit einer Spannung von 3,3 Volt mit Strom zu versorgen. 4.1.3. Festspannungsregler-Modul AMS1117-3.3 Aufgrund der Tatsache, dass die maximale Stromstärke, die durch einen einzelnen GPIO8 Pin des Einplatinencomputers fließen darf, 16 Milliampere beträgt[13], das hier verwendete LoRa -Funkmodul jedoch bis zu 93 Milliampere erfordert, wird ein externes Spannungsregler-Modul benötigt. Um sich von der Limitierung des Spannungsreglers auf dem Einplatinencomputer, das die Spannung von 5 Volt auf 3,3 Volt herunter regelt, zu entfernen, wird das Festspannungsregler-Modul mit der Bezeichnung AMS1117-3.3 verwendet. Mit einer benötigten Eingangsspannung zwischen 4,75 Volt und 10 Volt, einer Ausgangsspannung von 3,3 Volt (mit einer maximalen Abweichung von ± 0,065 Volt) und einer möglichen Ausgangsstromstärke von einem Ampere[5, S. 3], eignet sich dieses 18x9 Millimetergroße Modul für den hier genannten Zweck. Da die 5 Volt-Pins des Raspberry Pi Zero 2 WH ohne weitere elektronischen Komponenten dazwischen mit der Stromversorgung des gesamten Einplatinencomputer verbunden sind, ist nun die Leistung des externen Netzteiles direkt nutzbar, sodass an jenem Pin ein AMS1117-3.3 verbunden werden kann. Das Festspannungsregler-Modul AMS1117-3.3 hat drei Pins mit den Aufschriften VIN (für den positiven Eingang), OUT (für den positiven Ausgang) und GND (für den negativen Einund Ausgang). 7Universal Asynchronous Receiver Transmitter 8General Purpose Input/Output 12 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation 4.2. Verwendete Software Die von Rausch entwickelte Software lora-messenger kann über die Webseite GitLab heruntergeladen werden.[16] Es handelt sich um diejenige Software, die im weiteren Verlauf auf den Einplatinencomputer geladen werden soll. 4.3. Weitere benötigte Werkzeuge und Materialien Je nach gewähltem Raspberry Pi Modell und der Bauweise des LoRa -Funkmoduls HIMO-01M wird zum Anlöten der Pin-Reihen ein Lötkolben, einschließlich etwas Lötzinn, benötigt. Ist ein eigens gedrucktes Gehäuse gewünscht, so ist ein FDM -Drucker samt Druckmaterial ebenfalls von Nöten. Optional kann auch ein Schraubenzieher sowie zwei M3-Schrauben und entsprechende Muttern zur Fixierung und Schließung des Gehäuses erforderlich sein. 4.4. Gehäuse der Verbindungsstation Das Gehäuse der Verbindungsstation besteht aus zwei Teilen und hat eine Gesamtgröße von 8,8 Zentimeter in der Länge, 5,8 Zentimeter in der Breite und 5,2 Zentimeter in der Höhe. Es wurde für handelsübliche FDM -Drucker in einer CAD9 -Software entworfen, sodass je ein Teil des Gehäuses auf einer Druckfläche von 10x10x10 Zentimeter Platz findet. 10 Das Drucken des Gehäuses wurde in einem Zortrax M200 Plus, unter der Verwendung des Materials PLA11 , erfolgreich getestet. Es kann ein Raspberry Pi Zero und ein LoRa -Funkmodul HIMO-01M sowie das zuvor genannte SpannungsreglerModul beherbergen. Abbildung 4.1.: Gehäuseboden (links) und -deckel (rechts) in der CAD-Software 9Computer Aided Design 10die CAD-Dateien können im Ordner cad_files unter der Quelle [28] gefunden werden 11Polyactide 13 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation Die beiden Teile wurden in Hinblick auf die Minimierung von zusätzlichen Materialien gestaltet. Es werden lediglich zwei M3-Schrauben der Länge zwei Zentimeter und zwei zugehörige M3-Muttern benötigt, um den Gehäuseboden (im Bild 4.1 auf der linken Seite, in blau, zu sehen) und den Gehäusedeckel (im Bild 4.1 auf der rechten Seite, in rot, zu sehen) zu verschrauben. Des Weiteren ersetzen die drei Stäbchen, zu sehen im Bild 4.1 auf der rechten Seite, vier Schrauben, die sonst den Raspberry Pi Zero fixieren würden. Auf der rechten Seite des Bildes 4.1 ist eine Riffelung an der Außenseite zu erkennen. Diese wurde gestaltet, um die Grifffestigkeit des Gehäuses zu erhöhen. Abbildung 4.2.: gedrucktes Gehäuse mit eingesetzten Modulen Noch bevor die drei Module in das Gehäuse eingesetzt werden, müssen diese bereits miteinander durch einadrige Kabel verbunden sein. Wie im Bild 4.2 zu sehen, beherbergt der Gehäuseboden den Raspberry Pi Zero. Das LoRa -Funkmodul HIMO-01M wird an der Seite eingeschoben. Das auf dem Bild 4.2 links befindliche Modul, welches vollständig mit rotem Isolierband umwickelt ist, ist das zuvor erwähnte externe Spannungsregler-Modul. Im rechts befindlichen Kabelstrang, der ebenfalls in rotem Isolierband eingewickelt ist, befindet sich eine zusammengewickelte Verbindung von drei einadrigen Kabeln. Da kaum bis kein Spielraum zwischen den einzelnen Teilen gestaltet wurde, kann es sein, dass das gedruckte Resultat modifiziert werden muss. Danach kann der Gehäusedeckel vorsichtig aufgesetzt werden und die Antenne eingeschraubt werden. Zuletzt können die beiden Teile mit zwei M3-Schrauben und M3-Muttern fest zusammengeschraubt werden. 4.5. Anleitung zur Einrichtung einer Verbindungsstation Innerhalb dieses Kapitels wird eine Verbindungsstation schrittweise betriebsbereit eingerichtet. Dies wird im nachfolgendem Text unter dem Betriebssystem Windows 10 getan, sodass für einige hier verwendeten Applikationen wie WinSCP möglicherweise Alternativen genutzt werden müssen, sofern ein anderes Betriebssystem vorliegt. 14 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation 4.5.1. Erster Schritt: die Software vorbereiten Im ersten Schritt soll sowohl das Betriebssystem des Einplatinencomputers als auch die von Rausch entwickelte Software vorbereitet werden. Zur Vorbereitung des Betriebssystems wird die Applikation Raspberry Pi Imager genutzt. Für den Raspberry Pi Zero 2 WH kann das Raspberry Pi Modell RASPBERRY PI ZERO 2 W gewählt werden. Da keine Desktopumgebung benötigt wird, soll als Betriebssystem das Raspberry PI OS LITE (64-BIT), zu finden unter dem Reiter Raspberry Pi OS (other), ausgewählt werden, um die limitierten Ressourcen des Einplatinencomputers nicht für unbenutzte Funktionen wie einer Desktopumgebung zu verschwenden. Ist dies getan, kann nun die micro SD -Karte ausgewählt werden, welche im Nachhinein vollständig mit dem Betriebssystem überschrieben wird. Nach dem Klicken des Weiter-Knopfes können nun die Betriebssystemeinstellungen verändert werden: Unter dem Reiter ALLGEMEIN kann der Hostname, der Benutzername und das Passwort festgelegt werden. Der Benutzername und das Passwort werden für die Anmeldung über das Netzwerkprotokoll SSH12 benötigt. Zusätzlich sollen die WIFI -Einstellungen verändert werden, sodass es möglich ist, über SSH auf den Einplatinencomputer zuzugreifen. Das Wifi-Land muss auf GB eingestellt sein. Unter dem Reiter DIENSTE muss SSH aktiviert werden und die Option, dass sich mit dem Passwort authentifiziert wird, ausgewählt werden. Die von Rausch entwickelte Software lora-messenger kann über die Webseite GitLab heruntergeladen werden. 13 Ist dies getan, so sollen die folgenden drei Vorlage-Dateien in env-Dateien umgewandelt werden: • aloha_protocol_config.env.template • himo01_config.env.template • asap_lora_config.env.template Sie dienen zur Konfiguration der Umgebungsvariablen für die Software lora-messenger. 1cp config_file .env . template conf i g_ fi le . env Listing 4.1: Kopierbefehl unter Linux Im Windows-Explorer kann nun die jeweilige Datei kopiert und umbenannt werden, sodass die Dateiendung .env lautet. Wird bereits auf dem Einplatinencomputer gearbeitet kann alternativ der Bash-Befehl, wie er in der Abbildung 4.1 zu sehen ist, verwendet werden. Der Bash-Befehl muss zuvor an die jeweilige Datei angepasst werden: der erste Dateiname entspricht dem Namen der zu kopierenden Datei und der zweite Dateiname entspricht dem neuen Namen der Kopie. 12Secure Shell 13diese Software ist unter der Quelle [16] zu finden 15 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation 1COM_PORT=/dev/ttyS0 Listing 4.2: Änderung in der Datei himo01_config.env Nachdem die drei Vorlage-Dateien erfolgreich umgewandelt wurden, kann in der Datei himo01_config.env die Umgebungsvariable namens COM_PORT auf den Wert, wie er in der Abbildung 4.2 zu sehen ist, geändert werden. 4.5.2. Zweiter Schritt: die Hardware vorbereiten Im zweiten Schritt soll nun die Hardware vorbereitet werden. Je nach gewähltem Raspberry Pi Modell müssen die Pin-Reihen verlötet werden. Ist dies noch nicht bei dem LoRa -Funkmodul HIMO-01M geschehen, gilt es, auch hier die benötigten PinReihen anzulöten. Nachdem erfolgreich gelötet wurde, müssen nun der Raspberry Pi, Raspberry Pi Zero 2 WH Pin HIMO-01P Pin AMS1117-3.3 Pin 5V VIN VIN OUT GND GND GND RX TX TX RX Tabelle 4.1.: Verbindungen zwischen den drei Modulen das Funkmodul und das Festspannungsregler-Modul mit einigen einadrigen Kabeln, wie in der Tabelle 4.1 dargestellt, verbunden werden. Während des Verbindens soll der Raspberry Pi keine aktive Stromzufuhr besitzen. Nun kann die micro SD -Karte mit dem Betriebssystem in das Raspberry Pi gesteckt und eine adäquate Stromquelle verbunden werden. Das erste Starten des Raspberry Pi kann etwas länger dauern. Es empfiehlt sich, diesen Prozess mit dem Videoausgang des Raspberry Pi zu beobachten und schlussendlich die IP14-Adresse zu notieren. 4.5.3. Dritter Schritt: Ersteinrichtung abschließen Nachdem der Raspberry Pi erfolgreich mit dem voreingestellten WLAN verbunden ist, kann die Ersteinrichtung abgeschlossen werden. Dazu soll die Software lora-messenger auf den Raspberry Pi hochgeladen werden. Um dies zu tun kann die Applikation WinSCP unter der Nutzung des Übertragungsprotokolls SFTP15 und der Port-Nummer 22 genutzt werden. Sobald die Software hochgeladen wurde, kann eine weitere Applikation mit Namen PuTTY eingesetzt werden. Hier kann nun die notierte IP -Adresse, die Port-Nummer 22 und als Verbindungstyp SSH verwendet werden. 14Internet Protocol 15Secure File Transfer Protocol 16 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation 1sudo apt update 2sudo apt i n s t a l l default −jdk 3sudo apt i n s t a l l maven Listing 4.3: Befehle zum Herunterladen von Java und Maven Sobald sich erfolgreich eine Kommandozeile in PuTTY geöffnet hat, können die Befehle aus der Abbildung 4.3 nacheinander eingegeben werden. Sind diese in der gegebene Reihenfolge erfolgreich ausgeführt worden, konnte sowohl Java als auch Maven erfolgreich heruntergeladen werden. 1cd lora −messenger 2mvn validate 3mvn clean verify Listing 4.4: Befehle zur Erstellung einer ausführbaren Applikation Nun kann die Applikation erstellt werden. Insoweit noch nicht geschehen muss in das heruntergeladenen Dateiverzeichnis der Software lora-messenger gewechselt werden (dazu kann der Befehl aus der Abbildung 4.4 aus Zeile 1 verwendet werden, welcher zuvor möglicherweise noch modifiziert werden muss) und die beiden Befehle aus Zeile 2 und 3 (siehe Abbildung 4.4) nacheinander ausgeführt werden. Dieser Vorgang kann einige Minuten in Anspruch nehmen. 1sudo raspi −config Listing 4.5: Befehl zur Änderung der Konfiguration vom Raspberry Pi Ist die Applikation erstellt, kann nun im letzten Schritt die Konfiguration des Raspberry Pi’s geändert werden, sodass eine Kommunikation zwischen dem Funkmodul und dem Raspberry Pi ermöglicht wird. Nach der Eingabe des Befehls aus der Abbildung 4.5 soll nun in den Reiter Interface Options navigiert werden, um die Option Serial Port zu aktivieren. Es ist zu beachten, dass Serial Shell nicht aktiviert werden darf, sondern lediglich Serial Port. Ist dies geschehen, kann der Raspberry Pi neugestartet werden. Möglicherweise ist mehrmaliges Neustarten von Nöten. Nach dem Neustart kann nun zur Verifikation der Funktionstüchtigkeit der Applikation übergegangen werden. 4.6. Test zur Verifizierung einer erfolgreichen Ersteinrichtung Um eine erfolgreiche Ersteinrichtung zu Verifizieren, kann entweder eine weitere, bereits vollständig eingerichtete Verbindungsstation oder die Android-Applikation ASAPService genutzt werden. Aufgrund der Tatsache, dass die Android-Applikation ASAPService zum aktuellem Zeitpunkt des Schreibens dieser Arbeit noch einen Fehler enthält, der dazu führt, dass nach einem erfolgreichen TCP-Encounter die AndroidApplikation abstürzt, kann diese Methode der Verifizierung nur bedingt eine erfolgreiche Ersteinrichtung bestätigen.16 16Für weitere Informationen zu diesem Fehler siehe [17] 17 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation 4.6.1. Verifizierung mit einer weiteren Verbindungsstation Im nachfolgendem Text wird beschrieben, wie eine erfolgreiche Ersteinrichtung einer Verbindungstation (s1) mithilfe einer weiteren, bereits verifizierten Verbindungsstation (s2) überprüft werden kann. Zu Beginn können mithilfe PuTTY zwei Kommandozeilen zu jeweils einer Verbindungstation geöffnet werden. 1java −j ar target/ASAPLoRa. j a r Listing 4.6: Befehl zum Ausführen der Software auf dem Raspberry Pi Ist dies getan, muss nun auf beiden Seiten die Datei ASAPLoRa.jar ausgeführt werden, die sich nach dem erfolgreichen Erstellen der Applikation im Verzeichnis target befinden sollte. Dazu kann der Befehl, wie er in der Abbildung 4.6 zu sehen ist, genutzt werden. Dieser Befehl führt die angegebene Zieldatei aus. Je nachdem innerhalb welches Verzeichnisses jener Befehl ausgeführt wird, muss der dynamische Pfad zur Zieldatei angepasst werden. Nachdem die Applikation auf beiden Verbindungsstationen gestartet ist und eine Punkt-zu-Punkt-Verbindung zwischen ihnen aufgebaut wurde, kann nun der Test zur Verifikation durchgeführt werden. Das Ziel des Testes ist eine erfolgreich gesendete Textnachricht und eine erfolgreich empfangene Nachricht jenes Textes. Um dies zu bewerkstelligen, wird in der Kommandozeile der Verbindungsstation s1 eine Textnachricht, zum Beispiel ’Hello World’, eingegeben und durch das Drücken der Eingabe-Taste auf der Tastatur abgeschickt. Wird in der Kommandozeile der Verbindungsstation s2 die selbe Nachricht erhalten und ausgegeben, so ist der erste Teil des Testes positiv abgeschlossen und es konnte bestätigt werden, dass s1 Daten korrekt versenden kann. Um die Ersteinrichtung vollends zu verifizieren muss nun in die Kommandozeile der Verbindungsstation s2 eine Textnachricht, zum Beispiel ’This is a test.’ eingegeben und versendet werden. Wird in der Kommandozeile der Verbindungsstation s1 die versendete Nachricht erhalten und ausgegeben, so ist der zweite Teil des Testes positiv abgeschlossen und es konnte bestätigt werden, dass s1 Daten korrekt erhalten kann. Konnten beide Teile des Tests positiv abgeschlossen werden, so war die Verifizierung der Ersteinrichtung der Verbindungsstation s1 erfolgreich. 4.6.2. Verifizierung mit ASAPService Steht keine bereits verifizierte Verbindungsstation zur Verfügung, so kann die AndroidApplikation ASAPService theoretisch dazu genutzt werden, um zu überprüfen, ob jene Verbindungsstation im lokalem WLAN -Netzwerk erreichbar ist und Daten aus dem LoRa -Netzwerk Versenden und Empfangen kann, sofern diese entsprechend konfiguriert ist. Um dies zu bewerkstelligen, muss zusätzlich ein Android-Gerät eingerichtet werden, indem auf das mobile Endgerät ASAPService installiert wird. 18 4. Dokumentation zur Ersteinrichtung einer Verbindungsstation Aufgrund eines Fehlers innerhalb jener App17 kommt es jedoch kurz nach einem erfolgreichen TCP-Encounter zu einem Absturz, sodass lediglich die Erreichbarkeit der Verbindungsstation getestet werden kann und nicht dessen Sendund Empfangsfähigkeit. Um dies zu Testen, muss dem Unterkapitel 4.6.1 gefolgt werden. Daher wird im folgendem Text nur mit einer Verbindungsstation und einem Android-Gerät getestet. Nichtsdestotrotz kann mithilfe jener App eine erste Verifikation durchgeführt werden. Um den Test beginnen zu können, muss sich sowohl der Raspberry Pi als auch das Android-Gerät mit der Android-Applikation ASAPService im selben Netzwerk befinden. Ist dies der Fall, so muss nun die Software lora-messenger auf dem Raspberry Pi gestartet werden. Nachdem dies getan ist, kann die Android-Applikation geöffnet werden und folgende Knöpfe in dieser Reihenfolge nacheinander gedrückt werden: STARTWIFI, STARTLORA, TCP ENCOUNTER. Durch das Drücken des in der Reihenfolge letzten Knopfes öffnet sich ein neues Dialogfenster. Hier muss nun im Bereich host die IP - Adresse der Verbindungsstation und im Bereich port die Zahl 6000 eingegeben werden. Nach dem Drücken des Knopfes mit der Aufschrift CONNECT muss der Verbindungsstatus beobachtet werden. Ist der Verbindungsaufbau erfolgreich, so wechselt der Verbindungsstatus von disconnected zu connected, woraufhin die App abstürzt. Wenn es nicht zu solch einer Veränderung der UI18 kommt, so konnte die Erreichbarkeit der Verbindungsstation innerhalb eines WLAN-Netzwerkes nicht verifiziert werden. 17Applikation 18User Interface 19 5. Testen der Verbindungsstation Je Testlauf wird zuerst die zu testende Größe als auch der aktuelle Zeitpunkt dokumentiert. Anschließend wird die Methode _test_one_payload_size() ausgeführt. Dieser Kreislauf wird erst unterbrochen, sobald die zehn Sendeversuche aufgebraucht sind und dementsprechend geschlussfolgert werden kann, das die Maximalgröße von versendbarer Nutzlast erreicht worden ist. Ist dies der Fall, wird auch dieses Ereignis mit einem Zeitstempel dokumentiert. Die Methode _test_one_payload_size() veranlasst eine Verbindungsstation zum Senden einer Testnachricht mit definierter Größe (wobei ein Byte einem versendeten Zeichen entspricht), ließt und verarbeitet die erhaltenen Ausgabedaten von der TUI der Applikation lora-messenger und protokolliert, ob eine Bestätigungsnachricht für jene Testnachricht erhalten wurde. 5.5. Tests zur maximalen Reichweite In diesem Kapitel soll die maximale Reichweite, innerhalb welcher erfolgreich eine Punkzu-Punkt-Verbindung zwischen zwei Verbindungsstationen aufgebaut werden kann, getestet und dokumentiert werden. Dies geschieht teilweise automatisiert, teilweise manuell. Dazu wird eine Unterklasse mit dem Namen RangeTestForTwoStations und eine Android-Applikation mit dem Namen Locator entwickelt. 5.5.1. Planung der Reichweitentests Für diese Tests werden zwei Verbindungsstationen benötigt. Die erste Verbindungsstation, im folgendem Text als mobile Station bezeichnet, wird den Standort für jeden Test wechseln. Die zweite Verbindungsstation, im weiteren Textverlauf als stationäre Station betitelt, wird für die kommenden Tests am selben Standort verbleiben. Innerhalb eines Testdurchlaufes wird die mobile Station zu einem neuen Standort bewegt, die Geodaten (Breitenund Längengrad in Dezimalgrad) dokumentiert und der Test durchgeführt. Währenddessen verweilt die stationäre Station am selben Ort. Um den aktuellen Standort zu dokumentieren, wird die zwecks dessen entwickelte Android-Applikation Locator genutzt, die per Knopfdruck den Startstandort und den aktuellen Standort in eine Datei auf dem Android-Gerät protokolliert. Abbildung 5.4.: Testaufbau des Reichweitentests aus Sicht der mobilen Station Der Aufbau des Reichweitentests sieht wie folgt aus: Die zu testende Applikation 26 5. Testen der Verbindungsstation wird zur selben Zeit manuell auf der stationäre Station gestartet, wie auch teilautomatisch auf der mobilen Station. Während zur stationäre Station lediglich zu Testbeginn eine SSH -Verbindung für das Starten der Java-Applikation benötigt wird, so ist ein komplexerer Aufbau für das Testen mit der mobilen Station erstellt worden. Dieser Aufbau ist im Bild 5.4 zu sehen. Beginnend von links ist ein Android-Gerät zu sehen, dass sowohl die Android-Applikation Locator installiert hat, als auch eine SSH -Verbindung zu einem Raspberry Pi 4B aufbaut und erhält. Auf jenem Raspberry Pi 4B läuft die in der Programmiersprache Python geschriebene Testsoftware, die durch die TUI , die schlussendlich auf dem Android-Gerät angezeigt wird, gesteuert werden kann. Die Testsoftware verbindet sich mit der mobilen Station über das Protokoll SSH , und das LoRa -Funkmodul HIMO-01M ist kabelgebunden und kommuniziert mit dem Raspberry Pi Zero 2 WH über das Protokoll UART . Es wurde sich für den Einbau eines Raspberry Pi 4B in den Testaufbau aufgrund folgender Gründe entschieden: • Die Testsoftware wurde der Effizienz wegen in Python geschrieben und läuft dementsprechend nicht nativ (sowie Java oder Kotlin) auf einem Android-Gerät. • Während erster Testdurchläufe, als noch die Verbindungsstation direkt an der mobilen Stromversorgung angeschlossen war, ist aufgefallen, das diese automatisch in den Ruhezustand wechselte und keine Leistung mehr ausgab, da die mobile Station zu wenig Leistung im Ruhezustand benötigte. Dies wurde gelöst, indem der größere Einplatinencomputer, der mehr Leistung benötigt, zwischen der Stromversorgung und der Verbindungsstation gesteckt wurde, um so eine kontinuierliche Stromversorgung zu ermöglichen. Abbildung 5.5.: Ablauf eines Reichweitentests zwischen zwei Verbindungsstationen 27 5. Testen der Verbindungsstation Im Sequenzdiagramm 5.5 ist ein einzelner Testablauf dargestellt. Der initiale Verbindungsaufbau zwischen den einzelnen Geräten ist nicht in 5.5 dargestellt. Station 1 entspricht der mobilen Station und Station 2 entspricht der stationären Station. Wird ein Testfall von der Testsoftware, die sich auf dem Raspberry Pi 4B befindet, ausgelöst, so wird zu Beginn der Wert eines Zählers und die Anzahl an zu sendenden Bytes dokumentiert. Daraufhin wird der Sendebefehl an die mobile Station gesendet. Während beide Verbindungsstationen miteinander kommunizieren, wird die SendeZeit protokolliert. Nachdem die Testsoftware die erhaltenen Ausgabedaten von der TUI der Applikation lora-messenger verarbeitet hat, wird das Ergebnis (ob die stationäre Station mit einer Bestätigungsnachricht geantwortet hat oder nicht) und erneut der aktuelle Zeitpunkt protokolliert. Die Protokollierung ermöglicht eine Auswertung der Sendedauer und dem Empfangsstatus 5 einer versendeten Testnachricht, sodass in der Auswertung der erreichte Datendurchsatz errechnet werden kann. 5.5.2. Software für die Reichweitentests Für die Tests zur Bestimmung der maximalen Reichweite wurde die Klasse RangeTestForTwoStations geschrieben. Zum Zeitpunkt des Testens kann sie in der Datei mit dem Namen main.py ausgeführt werden, die gegebenenfalls angepasst werden muss, um den jeweiligen Test auszuführen. Wie bereits angedeutet, muss die Applikation lora-messenger auf der stationären Station zur selben Zeit manuell gestartet werden wie auch die Testsoftware selbst. Danach kann der TUI gefolgt und teilautomatisch die Tests durchgeführt werden. Abbildung 5.6.: Klassendiagramm der Klasse RangeTestForTwoStations Wie im Klassendiagramm 5.6 zu sehen, erbt die Klasse RangeTestForTwoStations von der abstrakten Oberklasse ConnectionStationTester und implementiert die Methode _execute_test(). Die Implementierung jener Methode folgt dem allgemeinen Beispiel aus dem Sequenzdiagramm 5.5. 5der Empfangsstatus entspricht 0 (Nachricht nicht erhalten) oder 1 (Nachricht erfolgreich erhalten) 28 5. Testen der Verbindungsstation Die Android-Applikation Locator[27] wurde in der Programmiersprache Java geschrieben. In der Klasse MainActivity werden jeweils drei Objekte der Klasse TextView und der Klasse Button kontrolliert. Der Start-Knopf bereinigt die Dokumentationsdatei, die unter dem Dokumente-Dateiordner des Android-Gerätes gefunden werden kann, und dokumentiert folgende Daten: • den Breitengrad (abgekürzt zu Lat), in Dezimalgrad • den Längengrad (abgekürzt zu Lon), in Dezimalgrad • die Standortgenauigkeit (abgekürzt zu Acc), definiert als „[...] der geschätzte horizontale Genauigkeitsradius in Metern von diesem Standort auf dem 68. Perzentil-Konfidenzniveau“[10] • die Höhe (abgekürzt zu Alt), entsprechend der Höhe über dem WGS84 ReferenzEllipsoiden in Metern[10] • die Unixzeit (abgekürzt zu Tme) Jene Daten werden in der zugehörigen darunterliegenden Instanz einer TextView angezeigt. Der Knopf in der Mitte dient zur Messung der bereits zurückgelegten Entfernung, ausgehend vom Startstandort, welcher zuvor durch das Drücken des Start-Knopfes festgelegt wurde. Darunterliegend wird die berechnete zurückgelegte Distanz in Metern und die Genauigkeit des aktuellen Standortes angezeigt, sodass bei zu schlechter Genauigkeit erneut der Standort abgefragt und die Distanz errechnet werden kann. Um den aktuellen Standort, an dem ein Test für die maximale Entfernung von zwei Verbindungsstationen durchgeführt wurde, zu protokollieren, kann der dritte Knopf genutzt werden. Wie auch beim Start-Knopf werden in der zugehörigen darunterliegenden Instanz einer TextView die Standortdaten angezeigt. Um keinen Standort mit zu niedriger Genauigkeit zu protokollieren, kann der sich in der Mitte befindliche Knopf wiederholt betätigt werden, bis die gewünschte Genauigkeit erzielt wurde, woraufhin nun der dritte Knopf gedrückt werden kann. 5.6. Tests zum maximalen Datendurchsatz Für die Tests zur Klärung des maximal möglichen Datendurchsatzes können die erhobenen Daten aus den Reichweitentests genutzt werden. Aus der dort entstehenden Dokumentationsdatei kann der jeweilige Datendurchsatz in Bezug von Distanz, Zeit und verwendeten Einstellungen des LoRa -Funkmoduls berechnet werden. Dementsprechend wird keine weitere Unterklasse für diesen Testfall entwickelt. 5.7. Tests zur Dienstverfügbarkeit Die Langzeit-Dienstverfügbarkeit einer Verbindungsstation soll durch das ununterbrochene Laufen der Software lora-messenger getestet werden. Eine Verbindungsstation gilt als zuverlässig, wenn die Software lora-messenger nicht abstürzt und erreichbar ist, sodass der angebotene Dienst verfügbar ist. 29 5. Testen der Verbindungsstation 5.7.1. Planung der Dienstverfügbarkeitstests Um die Dienstverfügbarkeit zu Testen werden zwei Verbindungsstationen benötigt, die sich innerhalb eines definierten Zeitraumes wiederholt gegenseitige Nachrichten zusenden. Im Gegensatz zu den im Kapitel 5.5.1 beschriebenen Tests soll die Distanz zwischen den beiden Verbindungsstationen nicht verändert und die Testfälle vollständig automatisch in einem fest definiertem Zeitabstand ausgelöst werden. Innerhalb eines ausgelösten Testfalles versuchen abwechselnd beide Verbindungsstationen sich gegenseitig eine Nachricht zuzusenden. Die Zeitpunkte dieser Ereignisse und der jeweilige Empfangsstatus sollen dokumentiert werden. Die LangzeitDienstverfügbarkeit soll innerhalb eines Zeitraumes von einem Tag stattfinden und der physische Aufbau soll wie der Aufbau aus dem Kapitel 5.3.1 sein. 5.7.2. Software für die Dienstverfügbarkeitstests Um einen Dienstverfügbarkeitstest durchzuführen, wurde die Klasse ServiceAvailabiltyTestForTwoStations implementiert. Abbildung 5.7.: Klassendiagramm der Klasse ServiceAvailabiltyTestForTwoStations Wie im Klassendiagramm 5.7 zu sehen, nimmt der Konstruktor mehrere Parameter zur Zeitverzögerung an. Die Methode _execute_test() nutzt diese und wiederholt den im folgendem Text beschriebenen Vorgang je nach dem Wert des Parameters number_of_ping_series: Beginnend wird der aktuelle Wert des Zählers, der die Anzahl an Ping-Serien symbolisiert, dokumentiert, woraufhin solch eine Ping-Serie ausgeführt wird. Diese besteht aus dem Aufruf der Methode _ping_one_station() 6 für die erste Verbindungsstation, einer Zeitverzögerung, gefolgt von dem Aufruf der selben Methode für die zweite Verbindungsstation. Abschließend folgt erneut eine Zeitverzögerung bis der Zeitpunkt für eine neue Ping-Serie eingetroffen ist. 5.8. Belastungstests Im nachfolgendem Text werden die Tests zur Netzwerkbelastbarkeit und -robustheit unter Last thematisiert. Das Netzwerk ist unter Last, wenn ein hoher Datendurchsatz 6für mehr Informationen zur dieser Methode siehe Kapitel 5.2.2 30 5. Testen der Verbindungsstation im Netzwerk herrscht. 5.8.1. Planung der Belastungstests Es soll ein Stresstest unter der Nutzung der von Rausch definierten Standardeinstellungen 7 des LoRa -Funkmoduls durchgeführt werden. Das Ziel ist eine vollständige Auslastung des Netzwerkes, sodass die Software lora-messenger auf der empfangenden Verbindungsstation abstürzt. Dazu wird eine kontinuierlich fließende Nachrichtenflut simuliert. Der physische Aufbau soll dem beschriebenen Aufbau aus 5.3.1 gleichen. Ausgehend von der ersten Station geht die Nachrichtenflut an Station 2. Station 1 erwartet keine Bestätigungsnachricht, sondern soll kontinuierlich Nachrichten an die zweite Station senden. Abbildung 5.8.: Ablauf eines Belastungstests zwischen zwei Verbindungsstationen Wie im Sequenzdiagramm 5.8 zu sehen, dass jeweils einen Durchlauf des Nachrichtensendens darstellt, soll stets zu Beginn überprüft werden, ob die Software lora-messenger auf der empfangenden Verbindungsstation noch aktiv ist. Ist dem so, soll weiterhin Testnachrichten gesendet werden. Konnte aber erfolgreich die Applikation auf der Station 2 zum Absturz gebracht werden, so wird von der Testsoftware sowohl die aktuelle Zeit als auch der Nachrichtenzähler dokumentiert. 5.8.2. Software für die Belastungstests Zur Testung der Belastbarkeit wurde die Klasse StressTestForTwoStations implementiert. 7diese Einstellungen sind im Anhang in der Abbildung C.1 dokumentiert 31 5. Testen der Verbindungsstation Abbildung 5.9.: Klassendiagramm der Klasse StressTestForTwoStations Auch die Klasse StressTestForTwoStations ist eine Unterklasse von ConnectionStationTester wie im Klassendiagramm 5.9 zu sehen. Wird jene Methode mit Namen _execute_test() aufgerufen, so werden zwei neue Threads gestartet. Der erste Thread führt die Methode _send_ping_to_second_station() aus. Diese Methode enthält eine Schleife, die durch den Wahrheitswert der Variable _stop_flag unterbrochen werden kann. Innerhalb jedes Schleifendurchlaufes wird zuerst überprüft, ob der bisher erreichte Wert des Nachrichtenzählers ein Element der Menge, gebildet aus 10 n , ist. Insofern dies der Fall ist, wird ein Zeitstempel und jener Nachrichtenzählerwert protokolliert. Daraufhin wird eine Testnachricht mit folgendem Inhalt an die zweite Station versendet: ping. Zwischen jedem Schleifendurchlauf wird der Thread für eine Sekunde pausiert. Der zweite Thread führt die Methode _check_if_ping_was_received() aus, die jede 1,4 Sekunden überprüft, ob die zweite Station eine Testnachricht erhalten hat. Konnte nach zehn Versuchen nicht verifiziert werden, dass eine Testnachricht erhalten wurde, so ist der Belastungstest beendet. Dies geschieht durch das Setzen des Wahrheitswertes _stop_flag, sodass der erste Thread dementsprechend über das Testende benachrichtigt wird. 5.9. Tests zur Leistungsaufnahme Im Kapitel 4.1 wurde bereits die theoretische Leistungsaufnahme des Einplatinencomputers und des Funkmoduls errechnet. Nun soll die Leistungsaufnahme der gesamten Verbindungsstation, wie sie in der Praxis benötigt wird, dokumentiert werden. 5.9.1. Planung der Leistungsaufnahmetests Um die Leistungsaufnahme zu testen, wird während der Tests zur Dienstverfügbarkeit sowie während der Belastungstests ein Messgerät zwischen dem Stromnetzteil und der Verbindungsstation zwischengeschaltet. Das Ziel ist die Ermittlung der Leistungsaufnahme (gemessen in Milliamperestunden) in drei Szenarien: keine Nutzung der Verbindungsstation, gelegentliche Nutzung der Verbindungsstation, starke Nutzung der Verbindungsstation: 32 5. Testen der Verbindungsstation • bei dem ersten Szenarium werden keine Tests durchgeführt, die Software loramessenger ist ausgeführt und der Raspberry Pi ist mit keinem WLAN verbunden • das zweite Szenarium tritt während der Tests zur Dienstverfügbarkeit ein, sodass hierzu die Leistungsaufnahme protokolliert wird • der Stresstest bildet das dritte Szenarium ab, demzufolge wird während jener Belastungstests die Leistungsaufnahme dokumentiert 5.9.2. Hardware für die Leistungsaufnahmetests Das Messgerät zur Ermittlung der Leistungsaufnahme ist ein USB8 -Leistungstester mit der Bezeichnung Keweisi KWS-V20. Da es über einen USB -Typ-A-Eingang und einem USB -Typ-A-Ausgang verfügt, kann es zwischen einem mobilen Zusatzakku und der Verbindungsstation gesteckt werden. Der Bildschirm des Messgerätes zeigt vier Datenwerte an: • die aktuell gemessene Spannung in Volt auf zwei Nachkommastellen genau • die aktuell gemessene Stromstärke in Ampere auf zwei Nachkommastellen genau • der bereits vergangenen Zeit des Ladevorgangs in Stunden und Minuten • einen maximal fünfstelligen Wert des Leistungsverbrauches in Milliamperestunden Der Zeitund Leistungsverbrauchswert kann mithilfe des mehrsekündigen Drückens des RESET-Knopfes zurückgesetzt werden. 5.9.3. Ergebnisse der Leistungsaufnahmetests Es wurden drei Datenwerte während der Tests der Leistungsaufnahme protokolliert: Das jeweilige Szenarium, die Dauer des Testes in Stunden, Minuten und Sekunden, und der vom Messgerät gemessene Verbrauch in Milliamperestunden. Szenarium Dauer in Stunden, Minuten und Sekunden gemessener Verbrauch in Milliamperestunden keine Nutzung 02:00:00 0341 gelegentliche Nutzung 24:09:02 4478 starke Nutzung 00:00:34 0002 Tabelle 5.1.: Dokumentation der Ergebnisse der Leistungsaufnahme einer Verbindungsstation in unterschiedlichen Szenarien Wie in der Tabelle 5.1 zu sehen, wurde die Leistungsaufnahme einer Verbindungsstation innerhalb drei unterschiedlicher Szenarien überprüft. Das Szenarium ’keine Nutzung’ entspricht dem Anwendungsfall, innerhalb welcher die Verbindungsstation 8Universal Serial Bus 33 5. Testen der Verbindungsstation zwar Verbindungsanfragen entgegennehmen kann, aber im jeweiligem Zeitraum keine Anfrage dieser Art gestellt wird. 1ps −x Listing 5.3: Befehl zur Anzeige der aktuell laufenden Prozesse Nachdem die zwei Stunden verstrichen waren, wurde das WLAN erneut sichtbar geschaltet, sodass via PuTTY der Befehl, wie er in der Abbildung 5.3 zu sehen ist, ausgeführt werden konnte. Das Ausführen dieses Befehls dient zur Kontrolle, ob die Software lora-messenger zum Testende noch läuft oder zuvor bereits abgestürzt ist. Abbildung 5.10.: Resultat nach dem Ausführen des Befehls aus der Abbildung 5.3 nach dem Testszenarium ’keine Nutzung’ Wie im Bildschirmfoto 5.10 in der fünften Zeile zu sehen, ist die Software loramessenger während der zwei Stunden nicht abgestürzt. Die Zeitdifferenz von drei Minuten zwischen der protokollierten und der im Bild 5.10 zu sehenden Laufzeit entstand durch die Dauer des Verbindungsaufbaus der Verbindungsstation mit dem wieder sichtbar geschaltetem WLAN. Die Spannung schwankte innerhalb des zweistündigen Zeitraumes zwischen 5,07 Volt und 5,13 Volt und die Stromstärke befand sich zwischen 0,17 Ampere und 0,2 Ampere. Im Szenarium ’gelegentliche Nutzung’ wurden jede 15 und 16 Minuten Nachrichten zwischen zwei Verbindungsstationen ausgetauscht. Dabei wurde eine Spannung im Bereich 5,01 Volt und 5,02 Volt dokumentiert sowie Werte der gemessenen Stromstärke von 0,17 Ampere bis 0,23 Ampere. Und innerhalb des Szenariums ’starke Nutzung’ wurden sehr viele Nachrichten in kurzer Zeit zwischen zwei Verbindungstationen ausgetauscht. Der Belastungstest lief 34 Sekunden. Die Spannung variiert zwischen 5,09 Volt und 5,24 Volt. Die Stromstärke befand sich im Bereich von 0,2 bis 0,23 Ampere. 34 6. Auswertung der Testergebnisse Innerhalb dieses Kapitels sollen die Ergebnisse der Tests ausgewertet werden. Die Tests wurden mithilfe der im Zuge dieser Arbeit entwickelten Testsoftware test_lora_messenger 1 durchgeführt. Diese Software wird unter der Apache Lizenz 2.0 bereitgestellt.[28] Die im nachfolgendem Text erwähnten Textdokumentationsdateien befinden sich im Dateiordner mit dem Namen test_results. 6.1. Auswertung der Grenzwerttests Die Tests zu den Einstellungswerten von vier Einstellungen haben die Grundlagen für die nachfolgenden Tests geliefert. Mithilfe der Ergebnisse, die im Anhang dokumentiert sind, konnte der Wertsatz an Einstellungswerten zur Optimierung der Übertragungsgeschwindigkeit gewählt werden. Es ist zu beobachten, dass funktionierende Einstellungswerte zumeist nur einen Versuch benötigten und lediglich in zwei Fällen ein weiterer Versuch nötig war. Zwar konnten jedoch bereits ab einer Bandbreite von 31200 Hertz eine teilweise erfolgreiche Datenübertragung festgestellt werden, jedoch konnte erst ab einer Bandbreite von 62500 Hertz auch das erfolgreiche Empfangen der Bestätigungsnachricht beobachtet werden. Während bei der Nutzung der beiden Bandbreiten 31200 Hertz und 41600 Hertz jeweils eine einmalige und teilweise Nachrichtenübertragung stattfinden konnte, so erlaubte die Nutzung der folgenden vier Einstellungswerte für die Bandbreite eine mehrmalige, vollständige und stabile Nachrichtenübertragung: 62500, 125000, 250000, 500000. Bei den Grenzwerttests zu möglichen Einstellungswerten des Spreizfaktors ist auffallend, dass die Werte, mithilfe von denen eine erfolgreiche Nachrichtenübertragung stattfinden konnte, zwischen unnutzbaren Einstellungswerten sind. So konnte zwar nicht ein Spreizfaktor von 64, jedoch die drei nachfolgenden Werte 128, 256 und 512 genutzt werden. Mithilfe der Spreizfaktoren 1024, 2048 und 4096 konnte wiederum keine Nachrichtenübertragung stattfinden. Alle vier möglichen Werte für die Fehlerkorrekturkodierung erbrachten bereits bei dem ersten Versuch eine funktionierende Datenübertragung. Dementsprechend kann hier je nach den Optimierungszielen der Funkverbindung eine Fehlerkorrekturkodierung frei gewählt werden. Es wurden acht unterschiedliche Längen der Präambel getestet. Während der Nutzung 1diese Software kann unter der Quelle [28] gefunden werden 35 6. Auswertung der Testergebnisse Abbildung 6.6.: Diagramm zur Datenrate in Verbindung mit der Distanz zum Start-Punkt In dem Diagramm 6.6 ist die Datenrate in Relation zur Distanz zum Start-Punkt der 18 Punkte mit erfolgreichem Reichweitentestergebnis zu sehen. Es ist zu erkennen, dass sich der Wert des Datendurchsatzes unabhängig von der Distanz stets über 300 und unter 450 Bytes pro Sekunde befindet. Wie in diesem Diagramm zu sehen, konnte keine lineare Relation zwischen der Datenrate und der Distanz nachgewiesen werden. 6.5. Auswertung der Tests zur Dienstverfügbarkeit Bei dem Test zur Dienstverfügbarkeit wurden 90 Ping-Serien durchgeführt, jeweils in einem Abstand von 900 Sekunden, umgerechnet 15 Minuten. Die Zeitverzögerung innerhalb einer einzelnen Ping-Serie betrug 60 Sekunden. Wird die Verarbeitungsdauer von empfangenen Testnachrichten nicht mit eingerechnet, so ergeben sich die geplanten 86400 Sekunden9, umgerechnet 24 Stunden. Die Dauer der Verarbeitung einer einzelnen Testnachricht setzt sich aus dem Wert der Variable _timeout_sec (dieser entspricht 2,0 Sekunden) und dem Wert der Variable _WAIT_TIME_AFTER_SEND_MSG (dieser entspricht 1,0 Sekunden) zusammen. In der Dokumentationsdatei mit dem Namen service_availabilty_test_results_1752349169.txt kann herausgelesen werden, dass insgesamt 180 Nachrichten versendet wurden, sodass mit eingesetzten Werten eine Gesamtnachrichtenverarbeitungsdauer von 540 Sekunden, umgerechnet 9 Minuten, errechnet werden kann.10 Der Test zur Dienstverfügbarkeit war für 24 Stunden, umgerechnet 86400 Sekunden, angesetzt, lief jedoch neun Minuten und zwei Sekunden länger. Die zusätzlichen neun Minuten können mit der Dauer des Verarbeitens der empfangenen Nachrichten erklärt werden, und die weiteren zwei Sekunden mit der Tatsache, dass der Einplatinencomputer während der Ausführung der Testsoftware weitere Aufgaben, wie das Schreiben in die Dokumentationstextdatei, das Schreiben in die TUI und das Bereitstellen einer SSH-Verbindung, ausgeführt hat. Da die letzte Testnachricht erfolgreich gesendet und versendet wurde, kann ausgesagt 990 ·(60Sekunden +900Sekunden) = 86400Sekunden 10 verwendete Formel: (_timeout_sec +_WAIT_TIME_AFTER_SEND_MSG)·message_counter = total_msg_computing_time 42 6. Auswertung der Testergebnisse werden, dass die Software lora-messenger über 24 Stunden kontinuierlich auf dem in dieser Arbeit gewählten Einplatinencomputer ausgeführt werden kann. Abbildung 6.7.: Analyse der dokumentierten Ergebnisse des Testes zur Dienstverfügbarkeit Das Bild 6.7 enthält die Analyse der Dokumentationsdatei mit dem Namen service_availabilty_test_results_1752349169.txt. Auf der linken Seite, in den ersten beiden Zeilen, sind die bereits angesprochenen Werte der Laufdauer des Testes und die Differenz zwischen der geplanten Testdauer und der tatsächlichen Testdauer zu sehen. Die oben genannten zwei Sekunden wurden vom Wert 1,5344576835632 aufgerundet. In den nachfolgenden fünf Zeilen ist die Anzahl an gesendeten Nachrichten zu lesen, die wie erwartet 180 beträgt, die Anzahl an erfolgreich versendeten Nachrichten, die 137 beträgt, sowie die Anzahl an verlorenen Nachrichten, welche 43 beträgt, und schlussendlich der jeweilige Prozentsatz. Die Ergebnisse des Tests zur Dienstverfügbarkeit deuten auf den Wahrscheinlichkeitswert von über 76% hin, dass eine Nachricht bei dem ersten Versuch erfolgreich übermittelt werden kann und der Sender die Bestätigungsnachricht erhält. Dagegen liegt der Wahrscheinlichkeitswert für verlorene oder verworfene Nachrichten knapp unter 24%. Eine vollständig erfolgreiche Ping-Serie tritt ein, wenn beide Verbindungsstationen für ihre erfolgreich versendeten Nachrichten eine Bestätigungsnachricht im ersten Versuch einer Nachrichtenübermittlung erhalten. Dies geschah 53 mal. Innerhalb 31 Ping-Serien konnte nur eine Verbindungsstation beim ersten Versuch eine Bestätigungsnachricht für ihre gesendete Testnachricht erhalten. Und bei sechs Ping-Serien wurde keine der beiden Testnachrichten im ersten Versuch mit einer darauffolgenden erfolgreich erhaltenen Bestätigungsnachricht versendet. 43 6. Auswertung der Testergebnisse Abbildung 6.8.: Anzahl der erfolgreich versendeten Nachrichten innerhalb der Ping-Serien Das Diagramm 6.8 zeigt die Anzahl (diese kann entweder 0, 1 oder 2 betragen) bei dem ersten Versuch erfolgreich versendeten Testnachrichten bezüglich der jeweiligen Ping-Serie (von der ersten bis zur neunzigsten Serie) an. Da auf dem Diagramm 6.8 kein kontinuierlicher Einbruch der Nachrichtenerfolge und dementsprechend keine eindeutig erkennbare Stelle, an der eine externe Störung das Testsystem stark negativ beeinflusste, erkennbar ist, kann davon ausgegangen werden, dass die Höhe des Wertes von verlorenen oder verworfenen Nachrichten nicht maßgeblich von einer externen Quelle beeinflusst wurde. Und da sich die Werte der erfolgreich versendeten Testnachrichten von sowohl der ersten als auch von der zweiten Verbindungsstation, zu sehen auf der rechten Seite im Bild 6.7, lediglich um drei Nachrichten unterscheiden, kann ebenfalls ausgeschlossen werden, dass eine einzelne Verbindungsstation defekt war und den Wahrscheinlichkeitswert von erfolgreich übermittelten Nachrichten maßgeblich negativ beeinflusste. 6.6. Auswertung der Belastungstests Die Differenz zwischen der Planung und der geschriebenen Software für den Belastungstest kann damit erklärt werden, dass während des Testens der Testsoftware auf das Verhalten der Verbindungsstationen reagiert wurde. Es war geplant, die Software lora-messenger auf der zweiten Verbindungsstation zum Absturz zu bringen, doch während des manuellen Testens der Testsoftware ist aufgefallen, dass nicht der Empfänger, sondern der Sender der limitierende Faktor ist. Denn wird innerhalb kurzer Zeit (hier jeweils eine Sekunde Zeitabstand) versucht, viele Nachrichten zu versenden, kommt es zu einem Fehler in der TUI der Software lora-messenger und keine weiteren Nachrichten können verschickt werden. Um die dokumentierten Ergebnisse und diese Schlussfolgerung zu bestätigen, wurde ein manueller Test durchgeführt und aufgenommen. 11 Dabei konnte festgestellt werden, dass lediglich die erste Testnachricht den Empfänger erfolgreich erreichen konnte. Nach dem Test konnte zwar von der zweiten Verbindungsstation noch Nachrichten 11das Video kann unter der Quelle [26] gefunden werden 44 6. Auswertung der Testergebnisse erfolgreich an die erste Verbindungsstation versendet werden, jedoch konnte die erste Verbindungsstation, die die Nachrichtenflut versucht hat zu versenden, keine neuen Nachrichten mehr an die zweite Verbindungsstation verschicken. In der Textdatei stress_test_results_1751979181.txt, die die Dokumentation des Belastungstestes enthält, ist herauszulesen, dass mindestens die ersten sieben Nachrichten erfolgreich von der ersten Verbindungsstation versendet werden konnten. Ab der zehnten Nachricht wurde der Missstand erkannt, dass keine weiteren Testnachrichten mehr die zweite Verbindungsstation erreichten. In einem Abstand von zwei bis drei Sendeversuchen wurde schlussendlich der Test nach 34 Sekunden beendet, da die zehn Wiederholungsversuche aufgebraucht waren. Mit den hier gesammelten Erkenntnissen kann geschlussfolgert werden, dass ein Zeitabstand von einer Sekunden für des Nachrichtenversenden zu kurz gewählt ist und stattdessen erst eine weitere Nachricht versendet werden darf, nachdem die zuvor gestellte Sendeanfrage vollständig bearbeitet wurde. 6.7. Auswertung der Tests zur Leistungsaufnahme Wie im Kapitel 5.9 beschrieben, konnte die Leistungsaufnahme in den drei Szenarien ’keine Nutzung’, ’gelegentliche Nutzung’ und ’starke Nutzung’ 12 erfolgreich protokolliert werden. Um den Stromverbrauch in Wattstunden zu berechnen kann folgende Formel verwendet werden: P=U·I·t(6.1) Wobei: P: Leistung in Wattstunden U: Spannung in Volt I: Stromstärke in Ampere t: Zeit in Stunden Eine Auswertung eines Szenarios beginnt mit der Umrechnung des Stromverbrauches auf eine Stunde. Anschließend wird dieser Wert mit der niedrigsten und höchsten protokollierten Spannung verrechnet. Um schlussendlich einen arithmetischen Mittelwert aus vier Werten berechnen zu können, wird noch der niedrigste Spannungswert mit dem niedrigsten Wert der gemessenen Stromstärke verrechnet als auch die beiden Höchstwerte der Spannung und der Stromstärke miteinander. 6.7.1. Auswertung der Tests zur Leistungsaufnahme im Szenarium der keinen Nutzung Innerhalb eines zweistündigen Zeitraumes konnten zwei Tatsachen dokumentiert werden: 12zur genauen Definition der Testszenarien siehe Kapitel 5.9 45 6. Auswertung der Testergebnisse • der Wert des MTBF13 der Software lora-messenger beträgt mindestens zwei Stunden • innerhalb zwei Stunden wurde ein Verbrauch von 341 Milliamperestunden gemessen Dementsprechend beträgt der Stromverbrauch pro Stunde 170,5 Milliampere und umgerechnet 0,1705 Amperestunden. Da eine Spannungsschwankung beobachtet wurde, wird mit beiden dokumentierten Spannungswerten gerechnet: 5,07Volt ·0,1705Ampere ·1Stunde =0,864435Wattstunden 5,13Volt ·0,1705Ampere ·1Stunde =0,874665Wattstunden Unter Einbezug der ebenfalls schwankenden Stromstärke ergeben sich die folgenden zwei Berechnungen: 5,07Volt ·0,17Ampere ·1Stunde =0,8619Wattstunden 5,13Volt ·0,20Ampere ·1Stunde =1,026Wattstunden Der arithmetische Mittelwert der errechneten Leistungen beträgt 0,90675 Wattstunden . Aus diesen Ergebnissen kann geschlussfolgert werden, dass die Verbindungsstation im unbenutzten Zustand und bei keiner aktiven WLAN -Verbindung einen Verbrauch von unter 0,91 Wattstunden aufweist. 6.7.2. Auswertung der Tests zur Leistungsaufnahme im Szenarium der gelegentlichen Nutzung Der Test zur Dienstverfügbarkeit lief 86942 Sekunden. Dies entspricht 24 Stunden, 9 Minuten und 2 Sekunden. Wird der dokumentierte Verbrauchswert auf eine einzelne Stunde heruntergerechnet, so ergibt sich der Wert 0,185 Amperestunden. Mit den beiden dokumentierten Spannungswerten 5,01 Volt und 5,02 Volt ergeben sich die folgenden beiden Berechnungen: 5,01Volt ·0,185Ampere ·1Stunde =0,92685Wattstunden 5,02Volt ·0,185Ampere ·1Stunde =0,9287Wattstunden Wie zuvor wird auch der kleinste und der größte Wert der Stromstärke miteinbezogen: 5,01Volt ·0,17Ampere ·1Stunde =0,8517Wattstunden 5,02Volt ·0,23Ampere ·1Stunde =1,1546Wattstunden Der arithmetische Mittelwert der vier hier errechneten Leistungen beträgt somit 0,9654625 Wattstunden . Dementsprechend kann daraus gefolgert werden, dass die Leistungsaufnahme einer einzelnen Verbindungsstation innerhalb dieses Szenarios unter 0,97 Wattstunden beträgt. 13Mean Time Between Failures 46 6. Auswertung der Testergebnisse 6.7.3. Auswertung der Tests zur Leistungsaufnahme im Szenarium der starken Nutzung Wird der gemessene Verbrauch in Milliamperestunden auf eine Stunde hochgerechnet, so ergibt sich eine Leistung von ∼0,21176 Amperestunden. Werden in die Formel die zuvor genannte aufgenommene Leistung und nacheinander die beiden Spannungswerte 5,09 Volt und 5,24 Volt eingesetzt ergeben sich folgende zwei Berechnungen: 5,09Volt ·0,21176Ampere ·1Stunde =1,0778584Wattstunden 5,24Volt ·0,21176Ampere ·1Stunde =1,1096224Wattstunden Unter der Nutzung der kleinsten und der größten Werte der dokumentierten Stromstärke ergeben sich die folgenden Berechnungen: 5,09Volt ·0,20Ampere ·1Stunde =1,018Wattstunden 5,24Volt ·0,23Ampere ·1Stunde =1,2052Wattstunden Da der arithmetische Mittelwert der vier errechneten Leistungen 1,1026702 Wattstunden beträgt, kann geschlussfolgert werden, dass der Stromverbrauch einer sekündlich sendenden Verbindungsstation unter 1,11 Wattstunden liegt. 6.7.4. Auswertung der Tests zur Leistungsaufnahme aller drei Szenarien Innerhalb der drei Testszenarien konnte belegt werden, dass die minimale Leistungsaufnahme bei unter 0,91 Wattstunden und die maximale Leistungsaufnahme bei unter 1,11 Wattstunden liegt. Wie erwartet bildet das erste Szenario den Anwendungsfall mit der niedrigsten Leistungsaufnahme, das dritte Testszenario den Anwendungsfall mit der höchsten Leistungsaufnahme und das zweite Szenario den Anwendungsfall mit einem dazwischen befindlichen Wert der Leistungsaufnahme ab. Da die maximale Leistungsaufnahme mit unter 1,11 Wattstunden sehr niedrig ist, ist eine Verbindungsstation, bestehend aus der hier verwendeten Hardware, dementsprechend kostengünstig zu betreiben. Anhand der hier erarbeiteten Werte kann geschlussfolgert werden, dass ein handelsübliches 5-Watt-Netzteil mit einer Ausgangsspannung von 5 Volt für die Stromversorgung einer Verbindungsstation genügt. Da ein USB -A Ausgang, welcher nach der Spezifikation USB 2.0 konform ist, maximal 0,5 Ampere bei 5 Volt, umgerechnet 2,5 Watt, liefern können muss[1, S. 171] kann auch diese Möglichkeit für die Stromversorgung einer Verbindungsstation genutzt werden. 47 7. Zusammenfassung Innerhalb dieser Arbeit wurde die Verbindungsstation, das von Rausch entwickelte System, dass die Kommunikation über LoRa ermöglicht, erfolgreich dokumentiert und getestet. Zu Beginn wurde der zuvor verwendete Einplatinencomputer Raspberry Pi 5 mit einem Raspberry Pi Zero WH der 2. Generation ausgetauscht, da dieser sowohl kostengünstiger und kleiner ist als auch einen geringeren Stromverbrauch hat. Zusätzlich wurde ein Gehäuse für das LoRa -Funkmodul HIMO-01M, das Festspannungsreglermodul AMS1117-3.3 für die Stromversorgung des Funkmoduls und dem Einplatinencomputer entwickelt und gedruckt. Es existiert nun eine vollständige Dokumentation zur Ersteinrichtung solch einer Verbindungsstation, innerhalb welcher sowohl die Hardware als auch die Software initial und betriebsbereit eingerichtet werden. Diese Ersteinrichtung wurde unter dem Betriebssystem Windows 10 durchgeführt. Diese Arbeit befasste sich ebenfalls mit der Testung der Verbindungsstation. Um dies zu bewerkstelligen, wurde die Testsoftware test_lora_messenger und spezifisch für die Reichweitentests die Android-Applikation Locator entwickelt. Die ersten Tests befassten sich mit den verschiedenen Einstellungswerten des LoRa - Funkmoduls HIMO-01M, um die akzeptierten Einstellungswerte zu ermitteln. Wie im Anhang dokumentiert, konnte festgestellt werden, dass die vier Frequenzen 62500, 125000, 250000 und 500000 Hertz für die Bandbreite verwendet werden können, wenn die anderen Einstellungen den Standardeinstellungen (wie sie im Anhang unter C.1 dokumentiert sind) entsprechen. Für einen nutzbaren Wert eines Spreizfaktors konnten die drei folgenden Werte ermittelt werden: 128, 256 und 512. Mithilfe aller vier möglichen Einstellungswerte zur Fehlerkorrekturkodierung konnte erfolgreich eine Testnachricht verschickt und die Bestätigungsnachricht erhalten werden. Das selbe gilt für die folgenden sechs Einstellungswerte für die Länge der Präambel: 4, 8, 32, 64, 128, 1024. Zwar ist in der Dokumentation des hier verwendeten Funkmoduls eine maximale Länge der Präambel mit 65535 angegeben, jedoch konnte weder für diesen Wert, noch für den darunterliegenden Wert 65534 der Test erfolgreich abgeschlossen werden. Bei dem Test zur Ermittlung der maximalen Größe einer erfolgreich versendbaren Nutzlast konnte sowohl festgestellt werden, dass diese 124 Bytes entspricht, als auch dass die Software lora-messenger die Datenpakete mit einer zu großen Nutzlast nicht automatisch in kleinere versendbare Datenpakete unterteilt. 48 7. Zusammenfassung Die Reichweitentests wurden innerhalb eines Umkreises von unter einem Kilometer um den Campus Wilhelminenhof der Hochschule für Technik und Wirtschaft Berlin durchgeführt. Nach dem Entfernen und dem Anpassen von einigen Testpunkten konnten 27 Punkte ausgewertet werden. Es wurde ermittelt, dass in dem hiesigen urbanem Umfeld eine Verbindungsstation bis zu ungefähr 771 Meter erfolgreich Nachrichten versenden kann, je nach Lage aber auch bereits bei einer Distanz von ungefähr 258 Metern zwischen den Verbindungsstationen innerhalb 40 Sekunden eine Nachricht nicht mehr erfolgreich versendet werden kann. Des Weiteren konnte keine direkte Relation zwischen der Distanz und dem Erfolg eines Sendeversuches bewiesen werden. Schlussendlich wird gefolgert, dass die Reichweite einer Verbindungsstation in einem urbanen Feld unter 800 Meter beträgt, diese Ziffer jedoch je nach Beschaffenheit der Umgebung der Verbindungsstationen auch deutlich geringer sein kann. Mithilfe der protokollierten Daten aus den Reichweitentests konnte eine Auswertung für den Datendurchsatz durchgeführt werden. Diese hat ergeben, dass der Datendurchsatz im Testgebiet zwischen 320 und 424 Bytes pro Sekunde liegt, wobei der errechnete arithmetische Mittelwert unter 390 Bytes pro Sekunde beträgt. Der Test zur Dienstverfügbarkeit lief erfolgreich über 24 Stunden, sodass geschlussfolgert werden kann, dass eine Verbindungsstation mindestens einen Tag lang unter den angegebenen Testbedingungen verwendet werden kann. Zusätzlich wurde ermittelt, dass der erste Sendeversuch von einer Nutzlast mit einer Größe von 4 Bytes mit einer Wahrscheinlichkeit von über 76% erfolgreich sein wird und dementsprechend zu ungefähr 24% der erste Sendeversuch fehl schlägt. Die Auswertung des Ergebnisses des Belastungstests ergab, dass ein Zeitabstand von einer Sekunde zwischen den einzelnen Sendeversuchen von verschiedenen Nachrichten zu gering gewählt ist. Ein Mindestzeitabstand zwischen zwei Sendeversuchen muss so festgelegt werden, dass der erste Sendeversuch vollständig bearbeitet werden konnte, noch bevor der zweite Sendeversuch begonnen wird. Während den Tests zur Leistungsaufnahme einer Verbindungsstation konnten drei Werte ermittelt werden. Wird eine Verbindungsstation nicht benutzt, so beträgt die Leistungsaufnahme unter 0,91 Wattstunden. Unter den Bedingungen des Tests zur Dienstverfügbarkeit, die in die Kategorie der gelegentlichen Nutzung einer Verbindungsstation eingeordnet werden kann, beträgt die Leistungsaufnahme unter 0,97 Wattstunden. In einem Szenarium wie dem Belastungstest steigt die Leistungsaufnahme auf unter 1,11 Wattstunden. Folglich kann als Stromversorgung sowohl ein handelsübliches 5-Watt-Netzteil mit einer Ausgangsspannung von 5 Volt, als auch ein USB -A Ausgang, welcher nach der Spezifikation USB 2.0 konform ist, verwendet werden. 49 8. Ausblick Zu den Ergebnissen dieser Arbeit gehören eine Dokumentation der Ersteinrichtung und eine Menge an Kenndaten einer Verbindungsstation. Auf dieser Basis kann das von Rausch entwickelte System weiterentwickelt werden. Beispielsweise kann innerhalb eines Projektes eine neue UI entwickeln werden, die die TUI von Rausch ablöst und das System leichter verwendbar macht. In diesem Zuge kann der im Kapitel 4.6.2 erwähnte Fehler in der Android-Applikation ASAPService behoben werden. Um die maximale Größe einer versendbaren Nutzlast von 124 Bytes zu erhöhen kann eine Applikation entwickelt werden, die zu große Datenpakete automatisch in versendbare Datenpakete aufteilt oder die Software lora-messenger selbst kann dahingehen erweitert werden. Des Weiteren kann eine Zwischenspeicherung von Sendeversuchen entwickelt werden, sodass der Fehler, der während des Belastungstests entdeckt wurde, nicht mehr auftritt und die Sendeversuche nacheinander abgearbeitet werden. Zusätzlich können die hier durchgeführten Tests weiter vertieft werden. Beispielsweise können mehrdimensionale Tests zu den akzeptierten Grenzwerten durchgeführt werden, indem mehrere Einstellungswerten zur selben Zeit angepasst und überprüft werden. Auch können weitere Reichweitentests in der selben oder unter anderen Umgebungsbedingungen, wie das Senden von Nachrichten in nicht-urbanen Umgebungen, durchgeführt werden. Und es kann ein zeitlich längerer Test zur Dienstverfügbarkeit durchgeführt werden. Ein weiterführendes Projekt ist auch die weitere Verkleinerung einer Verbindungsstation. Möglicherweise kann eine Platine mit lediglich einer CPU , einigen Komponenten für die Stromversorgung und vier Pins für den Anschluss einer externen Stromversorgung und der UART -Schnittstelle entwickelt werden. Zusätzlich kann die Software loramessenger um ein weiteres LoRa -Funkmodul erweitert werden, dass kostengünstiger, kleiner und in größerer Stückzahl bestellbar ist. 50 Abkürzungsverzeichnis App Applikation ASAP Asynchronous Semantic Ad-hoc Protocol BMS Battery Management System CAD Computer Aided Design CPU Central Processing Unit CSS Chirp Spread Spectrum FDM Fused Deposition Modeling GPIO General Purpose Input/Output IP Internet Protocol LED Light Emitting Diode LoRa Long Range MTBF Mean Time Between Failures PLA Polyactide RAM Random-Access Memory SD Secure Digital Memory SFTP Secure File Transfer Protocol SSH Secure Shell TCP/IP Transmission Control Protocol/Internet Protocol TCP Transmission Control Protocol TUI Terminal User Interface UART Universal Asynchronous Receiver Transmitter UI User Interface USB Universal Serial Bus WIFI Wireless Fidelity WLAN Wireless Local Area Network Appendices viii A. Software Testsoftware - test_lora_messenger: [28] Android-Applikation - Locator: [27] ix B. Tabellen Dezimalwert realer Wert in Hertz Erfolgsstatus Versuchsanzahl 0 7800 X 5 1 10400 X 5 2 15600 X 5 3 20800 X 5 4 31200 X 5 5 41600 X 5 6 62500 ✓1 7 125000 ✓1 8 250000 ✓2 9 500000 ✓1 Tabelle B.1.: Dokumentation der Einstellungswerte der Einstellung zur Bandbreite unter der Verwendung der Standardeinstellungen entsprechend dem Dateiinhalt C.1 Dezimalwert realer Wert Erfolgsstatus Versuchsanzahl 6 64 X 5 7 128 ✓1 8 256 ✓1 9 512 ✓1 10 1024 X 5 11 2048 X 5 12 4096 X 5 Tabelle B.2.: Dokumentation der Einstellungswerte der Einstellung zum Spreizfaktor unter der Verwendung der Standardeinstellungen entsprechend dem Dateiinhalt C.1 Dezimalwert realer Wert Erfolgsstatus Versuchsanzahl 1 4/5 ✓1 2 4/6 ✓1 3 4/7 ✓1 4 4/8 ✓1 Tabelle B.3.: Dokumentation der Einstellungswerte der Einstellung zur Fehlerkorrekturkodierung unter der Verwendung der Standardeinstellungen entsprechend dem Dateiinhalt C.1 x B. Tabellen Dezimalwert realer Wert Erfolgsstatus Versuchsanzahl 4 4 ✓1 8 8 ✓1 32 32 ✓1 64 64 ✓2 128 128 ✓1 1024 1024 ✓1 65534 65534 X 5 65535 65535 X 5 Tabelle B.4.: Dokumentation der Einstellungswerte der Einstellung zur Länge der Präambel unter der Verwendung der Standardeinstellungen entsprechend dem Dateiinhalt C.1 xi C. Dateiinhalte 1CARRIER_FREQUENCY=433500000 2TRANSMIT_POWER=20 3MODULATION_BANDWIDTH=8 4SPREADING_FACTOR=7 5ERROR_CODING=2 6CRC=1 7IMPLICIT_HEADER_ON=0 8RX_SINGLE_ON=0 9FREQUENCY_HOP_ON=0 10 HOP_PERIOD=0 11 RX_PACKET_TIMEOUT=3000 12 PAYLOAD_LENGTH=8 13 PREAMBLE_LENGTH=4 14 15 COM_PORT=/dev/ttyS0 16 BAUD_RATE=115200 17 18 PARITY=0 19 FLOW_CONTROL=0 20 STOP_BITS=1 21 DATA_BITS=8 Listing C.1: Standardeinstellungen aus der Datei himo01_config.env xii Eigenständigkeitserklärung Ich erkläre hiermit, dass • Ich die vorliegende wissenschaftliche Arbeit selbständig und ohne unerlaubte Hilfe angefertigt habe, • ich andere als die angegebenen Quellen und Hilfsmittel nicht benutzt habe, • ich die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe, • die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfbehörde vorgelegen hat. Berlin, 08.08.2025 Raphael Walger