Plattfuÿ lässt grüÿen Automatische Aufzeichnung und Analyse der Qualität von Fahrradwegen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Nachhaltige Kommunikationsnetze
Universität Bremen
Prof. Dr. Anna Förster
Bachelorarbeit
Plattfuÿ lässt grüÿen
Automatische Aufzeichnung und Analyse der
Qualität von Fahrradwegen
von
Dmytro Reznik
Matr.-Nr. 3033882
Bremen, den 28. Februar 2021
Betreut durch:
Prof. Peter Haddawy
Prof. Dr. Anna Förster
Dipl.-Ing. Jens Dede
Ich versichere, daÿ die vorliegende Arbeit bis auf die o zielle Betreuung durch den Lehrstuhl ohne fremde Hilfe von mir durchgeführt wurde. Die verwendete Literatur ist im Literaturverzeichnis vollständig angegeben. Bremen, den 28. Februar 2021 (Dmytro Reznik)
ZUSAMMENFASSUNG Im Rahmen dieser Arbeit wurde ein Projekt mit dem Ziel konzipiert, ein System zur Erfassung von Daten über die Umweltqualität und Radwege zu entwickeln, die in ganz Deutschland für Radfahrer sehr verbreitet sind und deren Hauptverbindung die Radfahrer sein werden sich. Die Idee des Pro jekts ist es, ein spezielles mobiles Gerät zu schaen, das mit einigen Sensoren ausgestattet ist, die ein Radfahrer auf eine Reise mitnehmen und mit seiner Hilfe Daten über die Umgebung sammeln kann. Diese Daten würden unter Verwendung eines speziellen Zwischengeräts in einen zentralen Speicher übertragen, in dem wiederum viele andere Radfahrer oder einfach jeder die Bewertungen verschiedener Pfade zwischen zwei von ihm ausgewählten Punkten sehen könnten. Um die Benutzererfahrung zu verbessern, sollte ein solches System so leicht und automatisiert wie möglich sein. Zwei Personen waren an der Entwicklung des Systems beteiligt, und die Aufgaben des Autors dieses Dokuments waren die Entwicklung einer mobilen Anwendung für das Android-Betriebssystem, die eine Übergangsverbindung zwischen dem Server und dem Mikrocontroller zur Steuerung von Sensoren darstellt und die Formulie- rung und Programmierung einer Formel zur Berechnung der Bewertungen verschie- dener Pfade zwischen zwei Punkten unter Verwendung der in der Serverdatenbank gespeicherten Informationen. Das Endergebnis der Arbeit war neben diesem Dokument und der Arbeit eines Kollegen ein System, das aus drei Teilen bestand. Der erste Teil befasst sich mit der Erfassung von Anfangsdaten über die Umgebung mithilfe verschiedener auf dem Gerät installierter Sensoren. Der zweite überträgt Daten von den Sensoren mithilfe von Mikronetzen über das Internet an den Netzwerkspeicher. Der letztere Teil wird als Aufbewahrungsort für die übertragenen Daten und als Mittel zur Interaktion mit dem Benutzer verwendet, um diese Daten zu verarbeiten und die Bewertungen der verschiedenen Pfade zwischen den beiden Punkten anzuzeigen. Basierend auf den Ergebnissen von Tests dieses Systems können Schlussfolgerungen gezogen werden, dass das System ist stabil genug, um im Feld eingesetzt zu werden, dass beim Vorhandenseins des Zugangs zum Internet, werden Daten schnell genug übertragen und verarbeitet, was ein wichtiges Argument sein kann, um die Öent- lichkeit auf das System aufmerksam zu machen und dass das System so weit wie möglich automatisiert ist. Zusammenfassend lässt sich unter Berücksichtigung der obigen Testergebnisse zu- sammenfassen, dass das Pro jekt ziemlich weit verbreitet werden kann, was wiederum zu einem gröÿeren Interesse der Menschen an Fragen der Ökologie und des Umwelt- schutzes führen und die Lebensbedingungen jedes Einzelnen verbessern kann.
INHALTSVERZEICHNIS
Zusammenfassung 1
1 Einführung 4
2 Anforderungsspezi kationen 7
2.1 Allgemeine Anforderungen zum Projekt . . . . . . . . . . . . . . . . . 7
2.2 Hardware Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Server Hardwareanforderungen . . . . . . . . . . . . . . . . . 8
2.2.2 Kommunikationskanäle von Sensorsteuerung und Sender . . . 9
2.3 System und Software Anforderungen . . . . . . . . . . . . . . . . . . 9
2.3.1 Anforderungen für ein Sender . . . . . . . . . . . . . . . . . . 9
2.3.2 Qualitätsberechnungsalgorithmus . . . . . . . . . . . . . . . . 10
2.4 Vorgehensschema des Projekts . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Versionskontrollsystem: gitlab . . . . . . . . . . . . . . . . . . 11
2.4.3 Git- ow-Work ow . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.4 Kanban-Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.5 Dokumentationsverwaltung . . . . . . . . . . . . . . . . . . . 12
3 Hardware und eingebettete Software 13
3.1 Im Projekt verwendete Sensormodule . . . . . . . . . . . . . . . . . . 13
3.2 Kommunikationskanäle der Sensorsteuermodul und einzelner Sensoren 14
3.2.1 Kommunikation der Sensoren mit Sensorsteuermodul . . . . . 14
3.2.2 Kommunikation den Sensorsteuermodul mit Android Anwen-
dung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Android-Anwendungssoftware (GeliOSMobile) 16
4.1 Vordergrund der Anwendung . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 User Interface (UI) der Hauptanzeige . . . . . . . . . . . . . . 17
4.1.2 Testwerkzeuge der Anwendung . . . . . . . . . . . . . . . . . . 18
4.1.3 Benachrichtigungsleiste . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Hintergrundprozesse des GeliOSMobile Anwendung . . . . . . . . . . 21
4.2.1 Vordergrunddienste . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2 Bluetooth Low Energy (BLE) Verbindung . . . . . . . . . . . 22
4.2.3 Android System Broadcasts . . . . . . . . . . . . . . . . . . . 22
4.2.4 Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.5 Benachrichtigungskanäle . . . . . . . . . . . . . . . . . . . . . 25
4.2.6 Beenden des Dienstes . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Informationsverlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 Kommunikation von Sensorebene mit Android Anwendung . . 26
4.3.2 Kommunikation von Android mit dem Server . . . . . . . . . 27
Inhaltsverzeichnis 3
5 Serversoftware 28
5.1 Benutzer Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Rundungswerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Berechnung der Pfadqualität . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Kommunikationskanäle von GeliOSWeb . . . . . . . . . . . . . . . . . 30
5.4.1 Kommunikationskanäle der Android Anwendung mit dem Server 31
5.4.2 Kommunikation des Servers mit Endbenutzer . . . . . . . . . 32
6 Testergebnisse 33
6.1 Erster Versuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.1 Auswertung der Testergebnisse von dem ersten Versuch und
Verbesserungsmöglichkeiten . . . . . . . . . . . . . . . . . . . 34
6.2 Zweiter Versuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1 Auswertung der Testergebnisse von dem zweiten Versuch . . . 34
6.3 Zusätzliche Tests und Schlussfolgerungen . . . . . . . . . . . . . . . . 35
7 Zusammenfassung und Ausblick 38
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A Quellcode 40
A.1 ratings.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2 ble_device_row.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Abbildungsverzeichnis 44
Tabellenverzeichnis 45
Abkürzungsverzeichnis 47
Literaturverzeichnis 48
KAPITEL 1
Einführung
Das Thema Ökologie und Umweltschutz ist in diesem Stadium der menschlichen
Entwicklung ziemlich akut. Luftverschmutzung, Treibhauseekt, Bodendegradati-
on, Abfallprobleme und Umweltverschmutzung sind nur einige der aktuellen Proble-
me. Wenn man Daten über den Zustand der Umwelt untersucht, kann man vielleicht
eine unangenehme Schlussfolgerung ziehen, dass es im Moment schwierig ist, die ne-
gativen Auswirkungen einer Person auf die umgebende Realität zu übertreiben. Dies
ist auf viele Faktoren zurückzuführen, darunter:
Finanzielle Gründe (hohe Ausrüstungskosten, Unmöglichkeit der Modernisie-
rung), die Schwierigkeiten beim frühzeitigen Übergang zu umweltfreundlicheren
Alternativen beispielsweise in der Energiewirtschaft verursachen.
Inkonsistente Maÿnahmen bei der Umweltüberwachung der zuständigen Behör-
den in verschiedenen Regionen, die zu Kon ikten führen, wenn versucht wird,
Anforderungen und Ansätze zu standardisieren.
Geringes Bewusstsein der Menschen für den tatsächlichen ökologischen Zustand
des Planeten.
Die aktuelle Situation ermutigt internationale Organisationen, weiterhin nach ver-
besserten Wegen zu suchen, um das Ökosystem wiederherzustellen und zu erhal-
ten, die Umweltkontrolle zu verbessern, Produktionsaktivitäten und regulatorische
Rahmenbedingungen zu planen und Möglichkeiten zur Finanzierung neuer grüner
1
Projekte zu nden. Auf der Suche nach solchen neuen Wegen zur Entwicklung
des ökologischen Gleichgewichts arbeiten viele internationale Organisationen unter
der Schirmherrschaft der Vereinten Nationen: United Nations Environment Pro-
2 3
gramme (UNEP) , United Nations Economic Commission for Europe (UNECE) [2],
4
Global Environment Facility (GEF) , die die Entwicklung des internationalen Um-
weltrechts regeln, die Anwendung von Chemikalien, Entwicklung einer Strategie zur
Erhaltung der biologischen Vielfalt und zur nachhaltigen Nutzung natürlicher Res-
sourcen und vieles mehr. Weltweit wurden umfangreiche Arbeiten internationaler
und regionaler Organisationen gestartet, um die Verbreitung von Informationen über
die modernsten umweltfreundlichen technologischen Methoden zu fördern (Global
Nest).
Heute verändert sich die Weltwirtschaft aufgrund der eingeführten Gesetze in Rich-
tung Umweltentwicklung. Es werden viele Anstrengungen unternommen, um um-
weltfreundlichere und menschlichere Produktionsprozesse und deren Produkte zu
schaen: von der Installation spezieller Reinigungs lter für Fabriken bis zur Her-
stellung von Materialien aus recycelten Materialien und der Anwendung spezieller
1
Stand 28.02.2021: https://www.eea.europa.eu/soer/2020/soer-2020-executive-summary-
translations/okruzhaiushchaia-srieda-sostoianiie-i-pierspiektivy-2020[1]
2
Stand 28.02.2021: https://www.unep.org/
3
Stand 28.02.2021: https://unece.org/
4
Stand 28.02.2021: https://www.thegef.org/
5
Recyclingcodes auf verschiedene Materialien, die angeben, wie dieses Material ver-
arbeitet und sortiert werden soll Dadurch werden die negativen Auswirkungen ver-
schiedener Arten von Abfallprodukten der Gesellschaft auf die Umwelt verringert.
Infolgedessen verbessert diese Modi kation die allgemeine Lebensqualität aller Le-
bewesen auf der Erde. In Bezug auf den Menschen zielen solche Maÿnahmen in
erster Linie darauf ab, Morbidität, Stress und die Lebenserwartung eines Menschen
zu verringern.
Es ist interessant festzustellen, dass die Menschen aktiver auf Umweltinitiativen
ihrer Regierungen reagieren und sich direkt an solchen Programmen beteiligen.
Viele in den letzten Jahren durchgeführte Programme waren recht erfolgreich und
haben spürbar positive Ergebnisse gebracht. Ich möchte auf das erfolgreiche Pro jekt
der Sortierung menschlicher Abfälle hinweisen, das mittlerweile für viele Menschen
alltäglich geworden ist. Solche Pro jekte fördern die Selbstorganisation der Bürger,
ermöglichen es, zur gemeinsamen Sache der Verbesserung des Zustands des Planeten
beizutragen und alle für die Umwelt verantwortlich zu machen.
In den letzten zehn Jahren ist die politische Bewertung der Grünen Parteien ge-
stiegen und bietet neben anderen Lösungen Programme an, die verständlich sind
und der Mehrheit der Bürger nahe stehen:
Reduzierung der CO2-Emissionen
Ablehnung fossiler Energiequellen mit dem Übergang zu sauberer Energie
Begrenzung der Entwaldung
Ökologisierung von Städten und Schaung eines besonderen Ökosystems in
ihnen mit zahlreichen Parks, Fuÿgängerzonen und vielem mehr
Neben globalen Parteibewegungen, die die Einstellung zum Lebensstandard radikal
verändern sollen, gibt es auch viele unabhängige Umweltgruppen. In vielen Städten
auf der ganzen Welt versammeln sich Menschen zu Verbänden, Gewerkschaften,
zeigen Beispiele für mutige und kreative Ansätze, testen verschiedene Arten der
Organisation von Leben und Arbeiten und tauschen Ideen aus.[1]
Solche eektiven Bemühungen der Menschen zeigen den Wunsch der Bevölkerung,
wirklich am Prozess der Veränderung der Lebensbedingungen teilzunehmen, die
Absicht, eine harmonischere Welt zu schaen und gleichzeitig die negativen Aus-
wirkungen der Industrialisierung auf die Umwelt zu minimieren. Viele innovative
Entwicklungen als Reaktion auf die sich ändernden Ansichten der Menschen sollen
der Welt ein neues Format umweltfreundlicher Technologien bieten sowie die Suche
nach kreativen Lösungen für die Erfassung von Daten zum Zustand der Umwelt
unter Berücksichtigung die Bereitschaft der Menschen, sich an Forschungsdaten zu
beteiligen, bei denen jeder seinen eigenen realisierbaren Beitrag zum Forschungspro-
jekt leisten kann.
Aber es ist zu verstehen: Je schwieriger die Bedingungen für die Teilnahme an
solchen Projekten sind, desto weniger Menschen sind bereit, an ihnen teilzuneh-
men. Dies bedeutet, dass es notwendig ist, ein System zu schaen, das so wenig
Aufmerksamkeit wie möglich erfordert, um Aufmerksamkeit zu erregen von seinem
Teilnehmer. Ein Beispiel ist eine Box mit Sensoren, die Daten über die Qualität von
beispielsweise Luft in der Umgebung erfassen. Eine solche Box kann auf eine Reise
mitgenommen werden, was für den Endbenutzer fast keinen Aufwand kostet. Es
ist wichtig, dass der Bewegungsprozess statt ndet und dementsprechend an jedem
Ort in der getesteten Region eine umfangreichere Datenerfassung erfolgt, um ein
vollständigeres und detaillierteres Bild der Forschungsergebnisse zu erhalten. Eine6 1. Einführung
solche mobile Ministation zum Sammeln von Informationen kann häu g verwendet
werden, um eine Vielzahl von Indikatoren und vor allem Daten zur Luftqualität zu
sammeln.
Heutzutage kann eine Vielzahl von Studien aufgeführt werden, die darauf abzie-
len, relevante Berichte über den Zustand der Luft zu erhalten, beispielsweise die
durchschnittliche Konzentration von Staub, Kohlendioxid und anderen schädlichen
Substanzen darin. Mittlerweile wird weltweit ein groÿes Netzwerk von Stationen
bereitgestellt, die qualitativ hochwertige Daten zur Umgebung sammeln. Diese Er-
5
gebnisse von jedem dieser Zentren können zum Beispiel hier eingesehen werden. Es
stellt sich jedoch die Frage: Was kann getan werden, um die Indikatoren, die sich
negativ auf Natur und Mensch auswirken, weiter zu reduzieren, oder wie können
die Bedingungen eines bestimmten Menschen im Alltag (auf der Straÿe) verbessert
werden? Wie kann die genauesten Informationen über wirklich günstige Verkehrs-
wege in Bezug auf die Luftreinheit mit einem Mindestgehalt an Kohlendioxid oder
chemischen Elementen erhalten werden, die für die Gesundheit ungünstig sind? Ins-
besondere solche Fragen werden relevant, wenn der Zweck einer solchen Bewegung
die Verbesserung der Gesundheit, die Wiederauüllung von Kraft und Energie ist,
beispielsweise Gehen oder Radfahren, Joggen. Wie oft sehen wir Läufer auf den
Straÿen laufen, die die verschmutzte Luft einatmen, und wie schön wäre es für sie,
die harmlosesten Strecken der Stadt zu kennen und im Voraus den umweltfreund-
lichsten Lauf zu planen?
Wie wird sich die bürgerliche Position einer Person ändern, die aktiv an der ökolo-
gischen Verbesserung ihrer Region teilnimmt und die Ergebnisse ihrer Arbeit zum
Wohle von Familie und Freunden sieht?
5
Stand 28.02.2021: https://aqicn.orgKAPITEL 2
Anforderungsspezi kationen
In diesem Kapitel werden die grundlegenden Anforderungen und Eigenschaften für
die Teile des Systems de niert, die für diese Arbeit entwickelt wurden.
Das GeliOS-Projekt wurde in erster Linie als dynamisches System zur Messung der
Qualität von Radwegen konzipiert, an dem jeder teilnehmen kann. Um die Auf-
merksamkeit der Öentlichkeit auf das Projekt zu lenken, wurde versucht, die Inter-
aktion mit dem System so weit wie möglich zu vereinfachen und den gröÿten Teil der
Routine zu automatisieren, um die Benutzererfahrung zu verbessern, wobei die Ver-
bindung einer mobilen Anwendung am schwierigsten ist das Android-Betriebssystem
mit einem Modul, das Sensoren steuert. Der Autor ist überzeugt, dass es bei ausrei-
chender Popularität und Verbreitung dieses Projekts auf der Grundlage von Daten,
die von Menschen auf der ganzen Welt erhalten wurden, möglich sein wird, eine
umfassendere Analyse der Umweltverschmutzung in verschiedenen Regionen durch-
zuführen.
Neben der Benutzerfreundlichkeit des Systems spielt der Materialpreis eine wichtige
Rolle. Je preiswerter die Ausrüstung ist, desto weniger Geld wird für die Bereitstel-
lung und Wartung des Systems selbst ausgegeben und desto attraktiver wird es für
Endbenutzer. Es war jedoch notwendig, in dieser Angelegenheit ein Gleichgewicht
zwischen Preiswertigkeit, Batterielebensdauer, Qualität der erhaltenen Daten und
Entwicklungszeit zu nden. Infolgedessen erhielt das Pro jekt eine Übergangsverbin-
dung zwischen dem Server, auf den jeder zugreifen konnte, und dem Gerät, auf dem
alle erforderlichen Messungen durchgeführt wurden. Dieser Link ist ein Mobiltelefon
mit einer speziellen Anwendung für die Datenübertragung. Dieser Ansatz ermög-
lichte es, die Kosten des Systems etwas zu senken, da die überwiegende Mehrheit
der Menschen dieses Gerät bei sich hat.
Da die Zielgruppe des Projekts Personen sind, die ein Fahrrad zur Bewegung be-
nutzen, wird davon ausgegangen, dass diese bestimmte Personengruppe mit den
erforderlichen Sensoren zur Messung der Umgebung ausgestattet ist. Dies bedeutet,
dass die Sensoren wie das Steuermodul so klein wie möglich sein sollten, damit sie
auf eine Reise mitgenommen werden können. Darüber hinaus sollte das System nach
dem Anschlieÿen an das Telefon so autonom wie möglich sein, um den Radfahrer
nicht von der Straÿe abzulenken.
2.1 Allgemeine Anforderungen zum Projekt
Die Hauptaufgabe des Pro jekts bestand darin, ein System aufzubauen, das aus:
eine Reihe von Sensoren zum Sammeln von Daten über die Qualitätsmerkmale
der Umgebung,
einen Sender, der Daten über das Internet übertragen kann und eine ausreichen-
de Abdeckung für die kontinuierliche Datenübertragung zum Server aufweist,
einen Server zum Sammeln und Verarbeiten eingehender Daten,8 2. Anforderungsspezi kationen
um letztendlich die Qualität eines oder mehrerer Pfade zwischen zwei bestimmten
Punkten auf der Karte zu bestimmen. Die Sensoren und der Sender sollten so exibel
wie möglich sein und sich im Idealfall problemlos in die Umgebung integrieren lassen.
Es ist beabsichtigt, dass ihre Verwendung auf Radfahrer abzielt, um die Qualität
bestimmter Radwege zu ermitteln. Das heiÿt, die Hauptaufgabe des Projekts besteht
darin, ein Qualitätskontrollsystem für Radwege zu schaen.
Zusätzlich zu den primären wurden auch die sekundären Aufgaben festgelegt, die
vor oder bereits im Entwicklungsprozess ausgedrückt wurden. Unter ihnen waren:
Miniatur des Senders und der Sensoren,
Minimaler Stromverbrauch für maximale Betriebszeit des Geräts,
Verfügbarkeit von Geräten auf dem Markt oder bei der überwiegenden Mehrheit
der Zielgruppe,
Angemessene Kosten für Sensoren und Steuermodule sowie Datenübertragung.
Diese Arbeit wurde zwischen zwei Autoren aufgeteilt und die Aufgaben des Autors
dieses Artikels waren:
1. Erstellung und Programmierung der Übergangsverbindung zwischen Sensor-
steuerung und Server,
2. Bereitstellung des gröÿtmöglichen Abdeckungsbereichs für die Kommunikation
mit dem Server,
3. Hinzufügen von Statistiken für weitere Analysen,
4. Die Möglichkeit, Daten direkt auf dem Übertragungsgerät zu überwachen,
5. Programmieren eines Algorithmus zur Berechnung der Qualität des Radwegs
zwischen zwei Punkten auf der Karte.
Die Arbeit von Ivan Reichert[3] beschäftigt sich hingegen mit:
Die Messeinrichtung auf Basis von einem ESP32-Mikrocontroller ist von Herrn
Ivan Reichert gefertigt
Der Server für die Lagerung und die Auswertung von den gemessenen Daten
ist von Herrn Ivan Reichert aufgesetzt, kon guriert und programmiert. Auÿer-
dem sind von Ihm die Koordinaten-Umrechnungsskripten und das Webinterface
erstellt.
2.2 Hardware Anforderungen
In diesem Unterthema werden die grundlegenden Anforderungen für den Hardware-
teil des Pro jekts in Bezug auf den Sender und den Algorithmus zur Berechnung der
Qualitätsmerkmale des Pfads berücksichtigt. Eine detailliertere Beschreibung der
verwendeten Sensoren, ihres Aufbaus, ihrer Kommunikationsschnittstellen und des
Funktionsprinzips ndet sich in der Arbeit meines Kollegen, der diesen speziellen
Teil des Pro jekts eingehender untersucht und zusammengestellt hat[3].
2.2.1 Server Hardwareanforderungen
Für einen stabilen Betrieb von GeliOSWeb ist es wünschenswert, dass der Server
die folgenden Anforderungen erfüllt:
2 CPU-Kerne
2 GB RAM
3 GB Speicherplatz2.3. System und Software Anforderungen 9
Verbindung mit dem Internet
◦ (optional) Unterbrechungsfreie Stromversorgung (USV)
Auf der o ziellen Website des Django-Projekts gibt es keine Mindestsystemanfor-
derungen, da sie stark von den Entwicklern und ihren Zielen abhängen, wobei die
verschiedenen Bibliotheken, die während des Projekts hinzugefügt wurden und di-
rekt geschriebene Algorithmen berücksichtigt werden müssen. Bei der Erstellung
der Systemanforderungen für diesen Teil des Projekts gingen der Autor des Artikels
und sein Kollege von den Fähigkeiten eines modernen Budget-Computers (Servers)
aus, der in der Lage ist, ohne sichtbare Verzögerungen auf mehrere Dutzende oder
Hunderte von Anfragen gleichzeitig zu reagieren, da das Projekt keine komplexen
Algorithmen für die Benutzerinteraktion und -verarbeitung beinhaltet. Mit der ver-
tikalen Skalierung des Pro jekts ist es natürlich möglich, noch mehr Anfragen in
einem bestimmten Zeitraum zu bearbeiten.
Angesichts des plattformübergreifenden Charakters und der relativ geringen Sy-
stemanforderungen für die Ausführung einer Kopie von GeliOSWeb auf einem Server
besteht theoretisch die Möglichkeit, ein Projekt auf RaspberryPi zu starten. Diese
wurde jedoch nicht getestet und ihre Leistung wurde in der Praxis nicht bestätigt.
2.2.2 Kommunikationskanäle von Sensorsteuerung und Sender
Für die Kommunikation zwischen dem unten beschriebenen Sender und der Sen-
sorsteuerung wird eine Bluetooth-Verbindung verwendet. Dies bedeutet, dass der
Controller Daten über das Bluetooth-Netzwerk übertragen kann. Der Sender selbst
muss wiederum die Möglichkeit zur Kommunikation über Bluetooth bieten, aber
zusätzlich Daten über das Internet übertragen können. Für eine maximale Interne-
tabdeckung muss der Sender auÿerdem in der Lage sein, mobiles Internet (3G, 4G
oder vergleichbar) oder WLAN zu verwenden.
2.3 System und Software Anforderungen
In diesem Abschnitt werden die Softwareanforderungen für die Implementierung des
Projekts berücksichtigt.
2.3.1 Anforderungen für ein Sender
Als Beispiel für ein Gerät, das die in den obigen Abschnitten beschriebenen An-
forderungen vollständig erfüllt, wurde ein Smartphone ausgewählt, das auf dem
Android-Betriebssystem basiert. Die Auswahl wurde auch aus folgenden Gründen
erleichtert:
Eine gewisse Orientierung in der Programmiersprache, die zum Erstellen von
Anwendungen für die Zielplattform verwendet wird.
Orientierung an den Softwarefunktionen der Zielplattform selbst.
Es besteht eine hohe Wahrscheinlichkeit, dass die Zielgruppe (im Rahmen die-
ser Arbeit Radfahrer in Deutschland) das Gerät bereits verwendet. Wenn die
1
Statistik der Anzahl von Smartphone-Nutzer in Deutschland für 2019 mit der
2
Gesamtzahl der im Land lebenden Menschen verglichen wird, kann eine Ver-
1
Stand 28.02.2021: https://www.statista.com/statistics/461801/
number-of-smartphone-users-in-germany/
2
Stand 28.02.2021: https://worldpopulationreview.com/countries/germany-population10 2. Anforderungsspezi kationen
mutung geäuÿert werden, dass die Wahrscheinlichkeit, eine Person mit einem
Smartphone auf der Straÿe zu treen, etwa 69,1% beträgt
Einige zusätzliche Funktionen, die die Benutzererfahrung verbessern (Monitor,
Benachrichtigungssystem, . . . ).
2.3.2 Qualitätsberechnungsalgorithmus
Der Algorithmus zur Berechnung der qualitativen Eigenschaften eines Pfades ist in
der Programmiersprache Python geschrieben und steht in enger Beziehung zu dem
in [3] Arbeit beschriebenen System. Dies impliziert die Notwendigkeit von Lösungen
wie:
Django Framework [4] als Übergangsverbindung zwischen Datenbank und Co-
de,
Google Maps API als Algorithmus zum Au nden der kürzesten Wege zwischen
zwei Punkten,
Python als Interpreter.
Die Arbeit dieses Algorithmus wurde ausgeführt und war ursprünglich für das Linux-
Betriebssystem konzipiert, da es unter Serversystemen sehr beliebt ist. Es gibt
jedoch keinen theoretischen Grund zu der Annahme, dass der Algorithmus unter
dem Betriebssystem der Windows-Familie nicht funktioniert.
2.4 Vorgehensschema des Projekts
Da mehrere Teilnehmer an dem Pro jekt beteiligt sind, besteht eine relativ hohe
Wahrscheinlichkeit für verschiedene Arten von Kon ikten, was dazu führt, dass der
Entwicklungsprozess organisiert werden muss. Vor Beginn der Entwicklung wurden
verschiedene Techniken und Softwareprodukte für die Zusammenarbeit vorgeschla-
gen.
2.4.1 Anforderungen
Verfügbarkeit des Quellcodes für jeden Teilnehmer zu jeder Zeit. Dies bedeutet,
dass es ein System benötigt wird, das sich auf einem Remote-Server be ndet und
auf das jede Seite Zugri haben würde.
Minimierung von Eingrien in die Arbeit jedes Projektteilnehmers, einschlieÿlich:
Ein System, das den Quellcode von Teilen der Anwendung jedes Teilnehmers
gemeinsam nutzt, aber jederzeit auch eine funktionierende Zusammenstellung
der gesamten Anwendung hat. Diese Anforderung ist erforderlich, damit jeder
Teilnehmer seine Arbeitsumgebung unabhängig anpassen kann, ohne die Um-
gebung des Kollegen zu beeinträchtigen. Auÿerdem sollte jederzeit die Mög-
lichkeit bestehen, die Implementierung ihrer eigenen Funktionen unabhängig
zu testen, ohne einen zweiten Teilnehmer einzubeziehen.
Automatisierung des Prozesses zur Lösung von Kon ikten beim Zusammenfüh-
ren von Code oder dessen maximale Vereinfachung. Wenn beispielsweise ein
umfassender Test der Funktionsfähigkeit des Systems durchgeführt wird, sind
die Entwicklungen jedes Projektteilnehmers erforderlich, da die Funktionsfä-
higkeit jedes Elements für sich genommen kein Beweis für die Funktionsweise
des gesamten Systems ist. Darüber hinaus führt die Möglichkeit, Code zu teilen2.4. Vorgehensschema des Projekts 11
und das Zusammenführen zu automatisieren, zu einer Minimierung der Zeit für
das Zusammenführen von Pro jektcode, was ebenfalls ein starkes Argument ist.
Gröÿtmögliche Transparenz des Pro jekts für seine Teilnehmer. Transparenz bedeu-
tet
Automatische Protokollierung von Änderungen für den Quellcode. Es ist wün-
schenswert, das Änderungsprotokoll für jeden Teilnehmer in seiner Arbeitsum-
gebung separat anzeigen zu können.
Möglichkeit, Kommentare und kurze Beschreibungen von Änderungen zu er-
stellen, um besser zu verstehen, was sich geändert hat.
Ein Entwicklungssystem, mit dem eine groÿe Aufgabe in kleinere atomare Teilauf-
gaben unterteilt und nachverfolgt werden kann.
Eine transparente Methode des Entwicklungsmanagements, bei der Prozess, Arbeits-
belastung, Zeitpunkt und Status der Entwicklung jedem Teammitglied klar sind.
Das Pro jekt erfordert die Wartung und Diskussion verschiedener Schnittstellen für
die Kommunikation seiner Teile. Dies bedeutet wiederum, dass ein spezielles Pro-
gramm oder System benötigt wird, in dem ein spezieller Ort zugewiesen wird, an
dem die Projektdokumentation aufbewahrt werden kann.
2.4.2 Versionskontrollsystem: gitlab
3
GitLab wurde aus folgenden Gründen als Versionskontrollsystem verwendet.
Das System ist jederzeit und überall auf der Welt verfügbar, sodass die Teil-
nehmende immer über eine aktuelle Version des Quellcodes verfügen und nicht
von einem bestimmten Ort abhängig sind.
Mit dem System können Beteiligte unabhängige Überprüfungen direkt erstellen,
wodurch sie den Code verschiedener Entwickler trennen können.
Teilweise automatisierte Zusammenführung von Code zu einem Projekt. Wenn
Kon ikte auftreten, können sie im Browserfenster gelöst werden, wodurch sich
der Zeitaufwand für die Codeverwaltung verringert
Das Versionskontrollsystem spart erheblich Zeit, indem es einen Teil der Routine
übernimmt und automatisiert.
2.4.3 Git- ow-Work ow
4
Git- ow-Work ow wurde verwendet, um den Code zu trennen und die Anzahl der
Kon ikte zu reduzieren. Der Upstream-Master hatte Arbeitsversionen des Quell-
codes mit der entsprechenden Version getestet. Im Entwicklungszweig wurde die
Integration und Prüfung des Codes bei Bedarf am Ende jedes Sprints durchgeführt.
Auÿerdem wurde für jeden Teilnehmer ein eigener Zweig erstellt, in dem der Code
eines bestimmten Entwicklers geändert wurde. Da die Trennung klar war, musste
nicht für jedes Ticket eine Filiale erstellt werden.
3
Stand 28.02.2021: gitlab.com
4
Stand 28.02.2021: https://www.atlassian.com/git/tutorials/comparing-workflows/
gitflow-workflow12 2. Anforderungsspezi kationen
2.4.4 Kanban-Board
Japan has made an astonishing change in its auto-production strategy. It has moved
from mass to lean production. This, the authors point out, is a lesson that western
manufacturers and companies can ill-aord to ignore [5]. Die Kanban-Board wurde
verwendet, um den Entwicklungsprozess basierend auf Tickets zu steuern. Ein Ticket
ist eine atomare Aufgabe, die je nach Status der Aufgabe in verschiedene Spalten
der Tabelle verschoben wurde. Die folgenden Zustände wurden verwendet
◦ Open. Ein Analogon zum Rückstand, aus dem Aufgaben für den Sprint über-
nommen werden
◦ To-Do. Die Aufgabe wird vor dem Ende des nächsten Sprints abgeschlossen
◦ Doing. Die Aufgabe wird gerade ausgeführt
◦ Testing. Die Zuordnung ist abgeschlossen, es sind jedoch Tests erforderlich,
um die Qualität und Konformität zu überprüfen
◦ Closed. Ticket abgeschlossen
2.4.5 Dokumentationsverwaltung
5
gitlab-wiki wurde verwendet, um Änderungen und Schnittstellen zwischen verschie-
denen Teilen der Anwendung zu dokumentieren.
5
Stand 28.02.2021: https://docs.gitlab.com/ee/user/project/wiki/KAPITEL 3
Hardware und eingebettete Software
Dieser Abschnitt enthält die Grundkenntnisse und Konzepte des Teils des Projekts,
der für die Erfassung von Umweltdaten und die Übertragung dieser Daten auf ein
Mobiltelefon verantwortlich ist. In diesem Abschnitt werden nicht die Besonderhei-
ten der Arbeit und die technischen Eigenschaften jedes einzelnen Sensors und seiner
Steuerung erläutert. Detaillierte Informationen dazu lassen sich in der verwandten
Arbeit[3] nden.
3.1 Im Projekt verwendete Sensormodule
Sensorname Ziel des Sensors Preis
Lautstärke- Sammelt Daten über die Lärmmenge ab e7,991
sensor (Grove (Lärmbelastung) in der Umgebung
Loudness)[6]
Staubsensor Sammelt Daten über die Menge an Staub- ab e22,302
(SDS011)[7] partikeln mit unterschiedlichen Durch-
messern in der Luft
GPS-Empfänger Sammelt Daten über die Position des Ge- ab e35,783
(EM506)[8] räts zum Zeitpunkt der Messung, um den
Ort der Messung zu bestimmen
Tabelle 3.1: Sensoren zur Erfassung von Umweltdaten
Die Tabelle 3.1 zeigt die Namen und allgemeinen Aufgaben der im Pro jekt ver-
wendeten Sensoren. Während des Projekts wurde auÿerdem vorgeschlagen, anstelle
separater Sensoren wie eines Schall- und eines GPS-Sensors auf dem Mobilgerät des
Benutzers zu verwenden, um die Kosten für das Endgerät zu senken. Später wurde
diese Idee jedoch aus mehreren Gründen abgelehnt, die nachstehend beschrieben
werden.
Verwenden des Mikrofons auf dem Smartphone des Benutzers als Schallsensor
a) Anfänglich bietet der Android Software Development Kit (SDK) keine
Funktionen zum Empfangen sauberer, unverarbeiteter Klangdaten vom
Mikrofon. Dies bedeutet, dass Fremdgeräusche, die das Ziel dieser Art
von Sensoren sind, vor der Messung herausge ltert werden
b) Die Verwendung Android Native Development Kit (NDK) wurde durch
1
Stand 27.02.2021: https://www.conrad.de/de/p/seeed-studio-101020063-arduino-erweiterungs-
platine-passend-fuer-einplatinen-computer-arduino-raspberry-pi-1892436.html
2
Stand 27.02.2021: https://www.amazon.de/-/en/Precision-Quality-Detection-Sensors-Digital/
dp/B07911ZY9W
3
Stand 27.02.2021: http://www.mercateo.com/p/820-1334196/NaviLock_EM_506_60432.
html?ViewName=live&showSimplePage=NO&h_oldQuantity=1&ncID=C1006%3A6200275&14 3. Hardware und eingebettete Software
mangelndes Verständnis des Betriebssystems in einer nativen Umgebung
4
eingeschränkt
Verwenden von GPS auf dem Smartphone eines Benutzers als GPS-Sensor
a) Die Verwendung eines GPS-Sensors zusammen mit einem Bluetooth-Gerät
auf einem Smartphone kann sich äuÿerst negativ auf die Akkulaufzeit des
Geräts auswirken
b) Die Forderung nach einem umfassenderen Ansatz für die Implementierung
der Erfassung von Standortdaten über das GPS-Modul eines Smartphones,
beispielsweise aufgrund der Berücksichtigung des Zustands des Moduls, des
Zugris auf Funktionen usw.
Die Wahl speziell dieser Sensortypen beruhte auf der Strategie zur Berechnung der
Qualität der Umgebung an einem bestimmten Punkt, die im Abschnitt 5.3 aus-
führlicher beschrieben wird, sowie auf mehreren anderen Faktoren wie z.B. relative
Messgenauigkeit und ausreichende Messstabilität.
3.2 Kommunikationskanäle der Sensorsteuermodul und ein-
zelner Sensoren
In diesem Unterthema werden die Technologien und Prinzipien der Kommunikation
allgemein beschrieben, beginnend mit den Sensoren und endend mit der Übertragung
von Daten an den Zielsender (Smartphone des Benutzers).
3.2.1 Kommunikation der Sensoren mit Sensorsteuermodul
Die Daten der Sensoren werden von einem speziellen programmierbaren Modul[9] er-
fasst, das in Ivans[3] Arbeit ausführlicher beschrieben wird. Im Allgemeinen werden
alle Module über Kabel mit dem Steuergerät verbunden und verwenden:
General-purpose input/output (GPIO)-Pins
Rechengeräteknoten, die für die Kommunikation mit anderen digitalen Geräten
ausgelegt sind, nämlich Universal Asynchronous Receiver Transmitter (UART)
einem seriellen synchronen Datenübertragungsstandard Serial Peripheral Inter-
face (SPI)
3.2.2 Kommunikation den Sensorsteuermodul mit Android Anwendung
Die Steuerplatine ist auÿerdem mit einen BLE ausgestattet, mit dessen Hilfe Da-
ten zwischen dem Controller und dem Smartphone zur weiteren Verarbeitung und
Datenübertragung zum Server übertragen werden. Das Format der übertragenen
Daten ist JavaScript Object Notation (JSON)(mehr [10]). Die Gründe für die Wahl
dieses speziellen Datenformats waren seine weit verbreitete Verwendung im Bereich
der Datenübertragung und die einfache Interaktion mit ihm.
Der folgende Text beschreibt die Abfolge der Aktionen des Steuergeräts ohne Be-
rücksichtigung des Starts und des Wartens auf den Start der Sensoren, dh die be-
schriebenen Bedingungen berücksichtigen die volle Bereitschaft der Sensoren.
1. Das Steuermodul liest Daten von jedem Sensor
2. Wenn alle Sensordaten in dieser Iteration erfasst wurden, wird ein neue JSON
String erstellt. Ein Beispiel für einen solchen String ist auf 3.1 zu sehen.
4
Stand 28.02.2021: https://github.com/android/ndk-samples/tree/master/audio-echo3.2. Kommunikationskanäle der Sensorsteuermodul und einzelner Sensoren 15
1 {
2 " pminutes " : " 00 . 0 0 0 0 " ,
3 " pole " : " N " ,
4 " hdegree " : " 0 00 " ,
5 " hminutes " : " 00 . 0 0 0 0 " ,
6 " hemisphere " : " W " ,
7 " mic ": " 7 2 7 " ,
8 " pm 1 0" : " 1 6 2 " ,
9 " pm 2 5" : " 9 4 " ,
10 " bat ": " 0 . 0 0 "
11 }
Listing 3.1: JSON aus Sensorsteuermodul für Smatrphone
3. Ein solcher String wird in einem speziellen Puer gespeichert, aus dem der
später auf eine Anfrage des Empfängers gesendet werden kann.
4. Go To 1.
Der Puer, in dem die Sensordaten für ihre weitere Übertragung gespeichert werden,
hängt nicht von der Ausführung des Hauptprogrammcodes ab, was beispielsweise
bedeutet, dass dieselben Daten zweimal hintereinander angefordert werden könnten
oder die vorherigen Daten tot sind, so dass die Daten irgendwann können ohne
Anfrage aktualisiert werdenKAPITEL 4
Android-Anwendungssoftware (GeliOSMobile)
In diesem Teil der Arbeit werden wir über den Sender zwischen dem Sensorsteuer-
modul und Server sprechen, der Daten speichert, verarbeitet und dem Benutzer das
Endergebnis zeigt. Als solcher Sender wurde ein Smartphone ausgewählt, das auf
dem Android-Betriebssystem basiert. Die Gründe für diese Wahl sowie das Vorhan-
densein dieser Verbindung zum Verbinden von Sensoren und Server wurden in Teil
2.3.1 dieser Arbeit beschrieben.
4.1 Vordergrund der Anwendung
Abbildung 4.1: ModelViewViewModel (MVVM) Patern Struktur.
Dieser Unterabschnitt beschreibt die Teile der Anwendung, die auf die eine oder
andere Weise von Benutzeraktionen abhängen, oder enthält Informationen zum Vor-
gang oder Status der Anwendung.
Das Hauptarchitekturmuster, das zum Erstellen der Benutzerober äche der Anwen-
dung verwendet wurde, war MVVM, das vom Entwicklungsteam des Betriebssy-
stems empfohlen wurde und in den Kreisen der Personen, die ihre Anwendungen
auf dieser Plattform erstellen, weithin bekannt ist. Dies erfordert eine hervorra-
gende Optimierung und Integration bei der Entwicklung eigener Anwendung. Als
einer der Erben des Model-View-Controller (MVC)-Musters kann dieser Ansatz zur
Softwareentwicklung jeden Teil der Anwendung einfacher ersetzen. Abbildung 4.1
gibt einen Überblick darüber, wie die verschiedenen Teile dieses Architekturmusters
1
kommunizieren. Im Allgemeinen haben diese Teile der Anwendung die folgenden
Rollen:
View, das sich im Bild links be ndet, repräsentiert visuelle Elemente, die der
Benutzer sieht und mit denen er interagieren kann. Durch die Verwendung der
Datenbindung kann View die Gra kelementen basierend auf Modelländerun-
gen aktualisieren. Auÿerdem werden verschiedene Ereignisse (ausgelöst durch
Benutzeraktionen) in ViewModel übertragen.
1
Stand 28.02.2021: https://www.raywenderlich.com/636803-mvvm-and-databinding-android-design-pattern4.1. Vordergrund der Anwendung 17
Das ViewModel wiederum manipuliert das Modell und liest die erforderlichen
Daten über den (normalerweise) Rückgabewert einer aufgerufenen Funktion.
Anschlieÿend wird das View über die Datenbindung aktualisiert.
Das Modell rechts enthält Anwendungslogik, Berechnungsfunktionen, Inter-
aktion mit externen Geräten, Zugri auf Systemfunktionen usw.
4.1.1 UI der Hauptanzeige
(a) Navigationsleiste von Ge- (b) Monitor mit der Liste von
liOSMobile, von der aus lässt BLE Geräte, die zu einem be-
sich zu den verschiedenen Bild- stimmten Zeitpunkt des Scan-
schirmen der Anwendung gelan- nens gefunden wurden
gen.
Abbildung 4.2: UI von dem Startbildschirm der Anwendung
Bild 4.2a zeigt eine spezielle Seitenleiste, über die zu jedem Teil der Anwendung
gelungen werden kann, von denen jeder im entsprechenden Abschnitt beschrieben
wird. Auf diese Seitenleiste kann von jedem Teil der Anwendung aus zugegrien
werden, sodass der Benutzer jederzeit die interessante Funktionalität erhält, die die
Anwendung bereitstellen kann.
Aufgrund der Tatsache, dass der Prozess der Datenübertragung mit Telemetrie
gröÿtenteils unabhängig vom Benutzer durchgeführt wird, wurde die Anwendungs-
schnittstelle so weit wie möglich vereinfacht, um Ressourcen für das Projekt zu
sparen. Um die Elemente der Anwendungsschnittstelle zu implementieren, wur-
den Sätze aus den AndroidX- und Android-Bibliotheken verwendet [11]. Das An-
wendungsdesign (Position und Eigenschaften der visuellen Elemente auf dem Bild-18 4. Android-Anwendungssoftware (GeliOSMobile)
schirm) wurde in speziellen Dateien im eXtensible Markup Language (XML)-Format
(mehr z.B. [12]) beschrieben. Ein Beispiel für eine solche Datei lässt sich in Teil A.2
dieses Dokuments nden. Diese Datei beschreibt eine Reihe visueller Elemente und
ihre Position relativ zueinander, um Informationen zu einem gefundenen Bluetooth-
Gerät anzuzeigen. Optisch ist dies in Bild 4.2b zu sehen.
Dieser Ansatz hat gegenüber einer reinen Software-Implementierung mehrere Vor-
teile:
Trennung der Deklaration visueller Elemente von ihrer Funktionalität
aus dem vorhergehenden Absatz folgt die Möglichkeit eines einfacheren Aus-
tauschs oder einer Änderung der visuellen Elemente der Anwendung und ihrer
Eigenschaften
hohe Entwicklungsgeschwindigkeit aufgrund der Kürze des Codes
Auf dem Hauptbildschirm der Anwendung be ndet sich eine Schalt äche zum Ein-
schalten des Bluetooth-Geräts auf dem Smartphone des Benutzers, falls es ausge-
schaltet war, und zum Starten des Scanmodus für Bluetooth-Geräte in der Nähe.
Gefundene Geräte werden während des Scannens auf dem Bildschirm angezeigt, was
in Abbildung 4.2b gezeigt ist. Dieser Vorgang kann nur vom Benutzer unterbrochen
werden, der ein Gerät aus der Liste der gefundenen auswählen oder auf die entspre-
chende Schalt äche klicken muss, um den Scanvorgang zu beenden. Nach Auswahl
eines Geräts wird der Benutzer über die erfolgreiche Verbindung und die Verfügbar-
keit der erforderlichen Merkmale auf dem Gerät informiert. Genauer wird dies in
Teil 4.2.2 dieser Arbeit diskutiert.
4.1.2 Testwerkzeuge der Anwendung
(a) Anzeige der Messwerte in (b) Eine Schalt äche, mit der
der BLE Monitor Ansicht der Erfolg von Datenübertra-
gung zum Server sowie das kor-
rekte Speichern dieser Daten
(auf dem Server) überprüft wer-
den können.
Abbildung 4.3: UI von den Testing Tools Sektion
In Bild 4.2a ist das Vorhandensein zusätzlicher Funktionen in der Anwendung zu
betrachten. Jeder der folgenden Bildschirme wurde gemäÿ den in Teil 4.1.1 beschrie-
benen Prinzipien und Programmiermustern entworfen.4.1. Vordergrund der Anwendung 19
Der BLE Monitor wird verwendet, um Daten zu überwachen, die von Sensoren über
den Bluetooth-Kanal empfangen, bevor sie an den Server gesendet werden. Auf
diesem Bildschirm be ndet sich auch ein Schieberegler zum Ändern der Häu gkeit
von Datenanforderungen. Dieser Bildschirm ist in Abbildung 4.3a dargestellt. Auf
dem Bild lässt sich verschiedene Parameter und den Namen sehen, die zuletzt über
Bluetooth von GeliOSESP32 übertragen wurden. Etwas höher wird auch der Sta-
tus des Bluetooth-Geräts auf dem Mobiltelefon und die MAC-Adresse des Geräts
angezeigt, von dem die Daten derzeit empfangen werden. Zwischen diesen beiden
Konstrukten ist einen Balken zu betrachten, mit dem ist die Anzahl der Anforde-
rungen pro Zeiteinheit zu steuern. So lässt sich experimentieren, wie schnell die
Daten in GeliOSESP32 aktualisiert werden. Ein wichtiger Punkt ist, dass mit ab-
nehmender Verzögerung zwischen BLE-Requests die Anzahl der Anfragen zunimmt
und nicht die Geschwindigkeit der Messungen auf GeliOSESP32.
Der letzte Bildschirm wurde ursprünglich zum Testen der Verbindung der Anwen-
dung zum Server konzipiert, wurde jedoch von der Serverseite durch Weiterleiten der
letzten Anforderung mit Beispieldaten überprüft. Dieser Bildschirm ist in Abbildung
4.3b dargestellt. Wenn auf die Schalt äche geklickt wird, wird eine Standardanfrage
an den Server gesendet, und es lässt sich den Erfolg der Zustellung von Anfrage und
die Richtigkeit der Verarbeitung auf dem Server verfolgen.
4.1.3 Benachrichtigungsleiste
Abbildung 4.4: Benachrichtigungsleiste. Die wird angezeigt, wenn das Gerät vom
Benutzer ausgewählt wurde und nun versucht wird, Daten von diesem Gerät über
die Verfügbarkeit der erforderlichen Dienste darauf zu lesen.
Nachdem der Benutzer ein Gerät für die Verbindung aus der Liste der vorgeschlage-
nen Geräte ausgewählt hat, wird in der Statusleiste eine spezielle Benachrichtigung
angezeigt. Ein Beispiel hierfür ist in Abbildung 4.4 dargestellt. Dieses Bild zeigt die
Mohnadresse des Geräts, mit dem versucht wird, eine Verbindung herzustellen. Die
Tatsache, dass das Gerät noch nicht angeschlossen ist, wird im ersten Teil des Tex-
tes angezeigt. Die Beschriftung ändert sich, wenn die Anwendung die erforderlichen
Dienste auf dem Endgerät ndet. Die Datenübertragung beginnt dann. Um eine
Benachrichtigung zu erstellen, wurde das Builder-Muster von NotificationCompat-
2
Klasse aus der AndroidX-Bibliothek verwendet . Extern sieht die Benachrichtigung
3
einheitlich aus, um die Benutzererfahrung zu verbessern und den Zeitaufwand für
die Entwicklung zu verringern. Die Benachrichtigung hat mehrere Zwecke:
ermöglicht langfristige Operationen im Daemon-Modus. Mehr dazu in Teil 4.2.
2
Stand 28.02.2021: https://refactoring.guru/design-patterns/builder
3
Stand 28.02.2021: https://developer.android.com/guide/topics/ui/noti ers/noti cations20 4. Android-Anwendungssoftware (GeliOSMobile)
bietet dem Benutzer Informationen zum Verbindungsstatus
◦ Device is connecting (Gerät verbindet) + MAC-Adresse des Geräts. Dieser
Status bedeutet, dass das Telefon versucht, eine Verbindung zum Gerät
herzustellen, und prüft, ob die erforderlichen Dienste verfügbar sind. Dieser
Vorgang wird in Teil 4.2.2 näher beschrieben.
◦ Device is connected (Gerät ist verbunden) + MAC-Adresse des Geräts.
Dieser Status zeigt an, dass die Verbindung erfolgreich war und derzeit
Daten zwischen Sensoren, Smartphone und dem Server übertragen werden.
Optional können die Daten auf dem Telefonbildschirm über die in Teil 4.1.2
beschriebene Tab BleMonitor überwacht werden.
um einen speziellen Dienst zu steuern, der im Hintergrund ausgeführt wird. Die
Steuerung beschränkt sich darauf, die Verbindung zwischen dem Smartphone
und den Sensoren zu trennen und den Dienst auszuschalten. Zu diesem Zweck
be ndet sich in der Benachrichtigung eine "Cancel"-Schalt äche, mit der die
Benachrichtigung geschlossen und der entsprechende Dienst deaktiviert wird
4
(genauer gesagt, es wird ein spezielles Konstrukt an alle Teile der Anwendung
gesendet, das im Teil 4.2.3 beschrieben wird).
builder = new NotificationCompat . Builder ( service , service . getString (R .
string . channel_id ))
. setSmallIcon ( android .R. drawable . ic_dialog_info )
. setContentTitle ( service . getString (R . string .
service_notification_bar_title ))
// . setContentText ( text )
. setPriority ( NotificationCompat . PRIORITY_HIGH )
. addAction ( android .R . drawable . btn_default_small ,
mainService . getString (R. string . stb_cancel_btn_text ) ,
quitPendingIntent );
Listing 4.1: Erstellen des Musters für eine Benachrichtigung. In Zukunft wird dieses
Objekt erneut verwendet, um die Systembenachrichtigung zu aktualisieren, die der
Benutzer im Benachrichtigungsfeed des Telefons sieht.
Der Code in Listing 4.1 wird verwendet, um eine solche Benachrichtigung zu skiz-
zieren. Bei der Analyse dieser Skizze geschieht Folgendes:
5
Ein Builder -Klassenobjekt für die Noti cationCompat-Klasse wird erstellt.
Die Argumente für den Konstruktor sind ein Objekt der Context-Klasse oder
ihres Erben und die IDenti er (ID) des Benachrichtigungskanals. Siehe Details
in Teil 4.2.
setSmallIcon Funktion stellt das kleine Symbol für die Benachrichtigungs-
layouts ein. Ein Argument ist eine Ressourcen-ID im Anwendungspaket des
zu verwendenden Drawables. In diesem Fall wurde das Standardsymbol für
Informationsnachrichten verwendet.
setContentTitle Funktion legt den Titel der Benachrichtigung in einer Stan-
dardbenachrichtigung fest. Ein String wird als Argument übergeben. In diesem
Fall wird der Text, der aus der Anwendungsressourcendatei abgerufen wurde,
verwendet, um die Übersetzung der Anwendung in Zukunft zu vereinfachen.
setContentText legt den Text Benachrichtigung in einer Standardbenachrich-
tigung fest. Der Argument ist ein String. In diesem Beispiel wird diese Funktion
aufgrund des Kontexts nicht verwendet. Da sich der Text der Nachricht häu-
g ändern sollte und das Aktualisieren des Textes die Wiederverwendung der
4
Stand 28.02.2021: https://developer.android.com/guide/components/broadcasts
5
Stand 28.02.2021: https://developer.android.com/reference/androidx/core/app/Noti cationCompat.Builder4.2. Hintergrundprozesse des GeliOSMobile Anwendung 21
Builder-Klasse mit dem anschlieÿenden Entfernen der alten Benachrichtigung
bedeutet, ist es zu diesem Zeitpunkt sinnlos, Text hinzuzufügen. Hier wird
das Grundgerüst der Nachricht erstellt, dessen Parameter unverändert bleiben,
und die restlichen Teile, wie z. B. der Benachrichtigungstext, werden später
hinzugefügt, wenn die Benachrichtigung direkt erstellt oder aktualisiert wird.
setPriority legt die relative Priorität für diese Benachrichtigung fest. Die
Priorität der Benachrichtigung gibt an, welche Aufmerksamkeit der Benutzer
dieser Benachrichtigung widmen soll. Bei dieser Anwendung wird die Priorität
so festgelegt, dass die Benachrichtigung beim Schlieÿen des Dienstes selbst nicht
ausgetauscht werden kann (wenn die Benachrichtigung geschlossen wird, löscht
das System nach einer Weile den Dienst, mehr dazu weiter unten).
addAction fügt dieser Benachrichtigung eine Aktion hinzu. Wird in diesem
Zusammenhang verwendet, um Feedback vom Benutzer und dem Prozess hin-
zuzufügen, der Aufgaben im Hintergrund ausführt. Da das Werbesystem keinen
direkten Zugri auf die Ressourcen und Methoden der Anwendung hat, können
Benachrichtigung und Dienst über das integrierte Werbesystem kommunizieren.
Dazu später mehr (4.2.3). In diesem speziellen Fall wurde eine Schalt äche er-
stellt, die den Dienst und die Benachrichtigungen schlieÿt und die Verbindung
zu den Sensoren unterbricht. Die Argumente sind: Ressourcen-ID für das visu-
elle Element (Schalt äche), Schalt ächentext und Intent, das bei Verwendung
der Schalt äche an die Anwendung übergeben wird.
public void onDeviceConnected ( String deviceName ) {
builder . setContentText ( mainService . getString (R . string . stb_connected_text )
+ " : " + deviceName );
notificationManager . notify ( notificationId , builder . build () );
}
Listing 4.2: Erstellen von einer Benachrichtigung. In diesem Fall wurde die
Benachrichtigung bereits mit der Builder-Klasse kon guriert. Es war lediglich
erforderlich, den Text in den erforderlichen zu ändern und die Benachrichtigung
unter Verwendung der speziellen Kennung der alten Benachrichtigung zu
aktualisieren (löschen und neu erstellen).
Verwendet wird das Beispiel aus Listing 4.2, um eine Benachrichtigung anzuzeigen
oder zu aktualisieren. Darin wird der Builder-Klasse der erforderliche Text hinzuge-
fügt und das für die Anzeige erforderliche Objekt erstellt, das dann im Benachrich-
tigungsleiste des Geräts angezeigt wird. Das erste Argument für die Benachrichti-
gungsmethode ist die Benachrichtigungs-ID. Wenn diese ID bereits verwendet wird,
wird die alte Benachrichtigung durch die neue ersetzt. Wenn die ID noch frei ist,
wird eine neue Benachrichtigung erstellt.
4.2 Hintergrundprozesse des GeliOSMobile Anwendung
In diesem Abschnitt werden die verwendeten Softwarebibliotheken und die Funk-
tionen des Systems erläutert, die auÿerhalb der Sichtbarkeitszone des Benutzers
ausgeführt werden und teilweise unabhängig von ihm sind, jedoch auf die eine oder
andere Weise mit dem Erreichen der Haupt- oder Nebenziele dieser Software zu-
sammenhängen. Es ist zu beachten, dass die in diesem Abschnitt beschriebenen
Konstrukte nicht unbedingt in irgendeiner Weise mit dem Benutzer interagieren,
Informationen anzeigen oder auf seine Aktionen reagieren, sondern über spezielle
Vermittler wie Broadcasting (4.2.3).22 4. Android-Anwendungssoftware (GeliOSMobile)
4.2.1 Vordergrunddienste
6
Laut Android-Entwicklerdokumentation sind versteckte Dienste: Foreground ser-
vices perform operations that are noticeable to the user. (Vordergrunddienste führen
Vorgänge aus, die für den Benutzer erkennbar sind.) . Der wichtigste Unterschied
zwischen solchen Diensten und der sichtbaren Anwendung ist der von der Haupt-
anwendung getrennte Lebenszyklus. Dies bedeutet, dass der Dienst auch nach dem
Entfernen der Hauptanwendung aus dem Random Access Memory (RAM) seine Auf-
gaben weiterhin ausführen kann. Diese Eigenschaft spielt eine wichtige Rolle beim
Schreiben zeitaufwändiger Aufgaben und ermöglicht es Ihnen auÿerdem, die Anwen-
dung nach dem Herstellen einer Verbindung zum Sensorsteuergerät zu schlieÿen.
Ab Android Version 8.0 muss beim Starten eine Benachrichtigung im Benachrichti-
gungsleiste erstellt werden, um den Betrieb eines solchen Dienstes zu gewährleisten.
Die Erstellung, der Zweck und die Funktionsweise einer solchen Anzeige sind in Teil
4.1.3 beschrieben.
Im Kontext dieser Anwendung führt der Dienst Aufgaben aus, die autonom und
ohne Benutzereingri ausgeführt werden, nämlich:
Empfangen von Sensordaten über Bluetooth
Hinzufügen von Telemetrie zu Rohdaten
Senden verarbeiteter Daten über das Internet an den Server
4.2.2 BLE Verbindung
Um über ein drahtloses Bluetooth-Netzwerk[13] eine Verbindung zum Endgerät her-
zustellen, sind die folgenden Schritte erforderlich:
1. den Bereich zu scannen um das gewünschte Gerät zu nden.
Es ist nicht erforderlich, einen Dienst für die Suche nach Geräten zu erstellen.
Grundsätzlich übernimmt die Bibliothek die gesamte Routine zum Einrichten
und Kon gurieren der Geräte. Rückrufmethoden werden zur Rückmeldung
verwendet. In dieser Anwendung beträgt die Aktualisierungsdauer des Geräts
ungefähr zwei Sekunden. Bei jeder Aktualisierung der gefundenen BLE-Geräte
wird die Tabelle aktualisiert, mit der das zu verbindende Gerät ausgewählt
werden kann.
2. die Verfügbarkeit der erforderlichen Service- und Kommunikationscharakteri-
stik zu überprüfen.
Eindeutige Kennungen (Universally Unique IDenti er (UUID)s) dienen als Be-
acons, um die Funktionalität (Charakteristiken) von Geräten zu beschreiben,
die Bluetooth als Mittel zum Datenaustausch verwenden. Wenn es versucht
wird, ein Gerät anzuschlieÿen, wird zunächst die Verfügbarkeit der erforderli-
chen Funktionen überprüft, indem die UUID auf dem Gerät gelesen werden.
Die Verbindung ist nicht erfolgreich, wenn keine der erforderlichen Charakteri-
stiken gefunden wurde.
4.2.3 Android System Broadcasts
7
Interne Broadcasts bei Android-System werden verwendet, um mit verschiedenen,
nicht direkt verwandten Teilen der Anwendung zu interagieren oder um auf Syste-
6
Stand 28.02.2021: https://developer.android.com/guide/components/foreground-services
7
Stand 28.02.2021: https://developer.android.com/guide/components/broadcastsSie können auch lesen
