Projektarbeit
Internet of Things: Antenne
eingereicht von: Sebastian Marquart - 747551
Martin Meixner - 747552
Michael Schillinger - 747555
betreut durch Prof. Dr.-Ing. Zacher
Darmstadt, den 15. September 2017
Inhaltsverzeichnis
1 Einleitung ....................................................................................................................... 3
1.1 Aufgabenstellung .................................................................................................... 3
1.2 Beschreibung des Ist-Standes ................................................................................. 3
1.3 Vorgehensweise zur Realisierung ........................................................................... 4
2 Projektmanagement ....................................................................................................... 5
2.1 Detaillierung Projektauftrag: .................................................................................... 5
2.2 Machbarkeitsanalyse ............................................................................................... 6
2.3 Projektplanung ........................................................................................................ 7
2.3.1 Projektstrukturplan ........................................................................................... 7
2.3.2 Ablauf- und Terminplanung .............................................................................. 8
2.3.3 Ressourcen- & Kapazitätsplanung ................................................................... 0
2.3.4 Kosten- und Budgetplanung ............................................................................. 1
2.4 Identifikation und Analyse Stakeholder .................................................................... 2
2.5 Risikoanalyse .......................................................................................................... 4
3 Systembeschreibung ...................................................................................................... 6
3.1 Antennenmodul ....................................................................................................... 6
3.2 Antriebsregelung ..................................................................................................... 7
3.3 Gateway .................................................................................................................. 8
3.4 Bedienerschnittstelle ............................................................................................... 8
4 Wiederinbetriebnahme der Antenne ............................................................................... 9
4.1 Anschluss / Verkabelung der Antenne ..................................................................... 9
4.2 Verbindung des Raspberry Pi mit WLAN-Netz .......................................................10
4.3 Node-RED – Erklärung, Start und Konfiguration .....................................................12
4.3.1 Was ist Node-RED? ........................................................................................12
4.3.2 Verfügbarkeit von Node-RED auf dem Raspberry Pi .......................................13
4.3.3 Start von Node-RED auf dem Raspberry Pi und Konfiguration über einen PC 13
4.3.4 Oberfläche und Bedienung von Node-RED .....................................................15
4.4 Kommunikation über MQTT ...................................................................................18
4.4.1 Was ist MQTT? ...............................................................................................18
4.4.2 Schwierigkeiten bei der Inbetriebnahme des Vorgängersystems .....................19
4.4.3 Auswahl und Konfiguration eines MQTT-Brokers ............................................20
4.5 Test der Antennenansteuerung ..............................................................................22
5 Neuentwicklung .............................................................................................................24
5.1 Grundbeschreibung der Software-Architektur .........................................................24
5.2 Serverseitig verwendete Technologien ...................................................................25
5.3 REST-Service ........................................................................................................26
5.3.1 Start eines neuen Experiments .......................................................................26
5.3.2 Status eines Experimentes abfragen ...............................................................28
5.3.3 CSV-Datei eines abgeschlossenen Experimentes downloaden .......................30
5.4 HTML-Client ...........................................................................................................31
5.4.1 Aktions-Auswahl ..............................................................................................31
5.4.2 Neues Experiment starten ...............................................................................33
5.4.3 JSONP ............................................................................................................36
5.5 ASP.NET Hosting ...................................................................................................39
5.5.1 1&1 Hosting Paket „Unlimited Windows“ .........................................................39
5.5.2 Anwendungsverzeichnis ..................................................................................41
5.5.3 Hosting ............................................................................................................42
6 Abschlussbetrachtung und Lessons Learned ................................................................46
Anhang .................................................................................................................................47
Literaturverzeichnis ..............................................................................................................48
Abkürzungsverzeichnis .........................................................................................................48
Abbildungsverzeichnis ..........................................................................................................49
Tabellenverzeichnis ..............................................................................................................50
1 Einleitung
Die vorliegende Projektarbeit „Internet of Things: Antenne“ ist eine Weiterentwicklung der Pro-
jektarbeit „Modellbasierte Softwareentwicklung mit Raspberry Pi“, welche im Wintersemester
2016/17 von Frau Dubinski und den Herren Doubleur und Kortenjann durchgeführt wurde.
Sie ist Bestandteil des Moduls C22 ”Projektmanagement“, welches im Sommersemester 2017
von Dozentin Dipl.-Wirtschaftsing. Tanja Wälzholz betreut wird. Folgende Ziele sollen bei der
Durchführung dieser Projektarbeit erreicht werden:
- Einarbeitung in die Projektarbeit „Modellbasierte Softwareentwicklung mit Raspberry
Pi“ und darauf aufbauend die Inbetriebnahme der Antenne.
- Realisierung eines Client-Server-Systems zur Antennenansteuerung via Internet
- Anwendung und Vertiefung von Projektplanungs- und Managementtechniken und
Werkzeugen im praktischen Umfeld. Die Methoden und Werkzeuge wurden im Modul
”Projektmanagement“ teils theoretisch, teils an Beispielen behandelt und sollen nun
zur Unterstützung bei der Erfüllung des Projektziels herangezogen werden.
1.1 Aufgabenstellung
Die von Herrn Zacher ausgegebene Projektarbeit „Internet of Things: Antenne“ soll mit Metho-
den des Projektmanagements bearbeitet werden.
Zu Beginn des Projekts soll eine Einarbeitung in die vorangegangene Projektarbeit erfolgen.
Darauf aufbauend ist die Antenne in Betrieb zu nehmen. Nach erfolgreicher Inbetriebnahme
der Antenne soll ein Client-Server-System für den Fernmaster-Studiengang „Elektrotechnik“
entwickelt werden, welches den bereits bestehenden Zustand der Antenne insofern erweitern
soll, dass eine Ansteuerung der Antenne über einen Webservice und somit über eine vorge-
gebene Internetadresse möglich ist. Das folgende Kapitel beschreibt den Ist-Stand der An-
tenne nach der Übergabe zu Beginn der Projektarbeit.
1.2 Beschreibung des Ist-Standes
Die Antenne lässt sich vor Beginn dieser Projektarbeit bereits via Internet steuern. Dazu wurde
vom vorherigen Projektteam eine Visualisierungsoberfläche in JAVA geschrieben, welche auf
einem beliebigen PC, Laptop oder einem anderen Raspberry Pi ausgeführt werden kann. Wie
in der unteren Abbildung zu sehen ist, erfolgt die Datenübertragung von der Visualisierungs-
oberfläche zur Antenne über einen MQTT-Broker (Erklärung von MQTT erfolgt in einem spä-
teren Kapitel). Um die Kommunikation der Antenne (inklusive Arduino und Raspberry Pi) mit
der Visualisierungsoberfläche über einen MQTT-Broker zu realisieren, wurde mittels der Soft-
ware ”Node-Red“ auf dem Raspberry Pi ebenfalls eine definierte Schnittstelle geschaffen, wel-
che die Umsetzung der seriellen Verbindung vom Arduino in das MQTT-Protokoll übernimmt.
Abbildung 1: Stand nach Übernahme der Antenne zu Beginn der Projektarbeit
1.3 Vorgehensweise zur Realisierung
Die Realisierung dieser Projektarbeit erfolgte in folgenden Schritten, welche sich auch als ein-
zelne Kapitel wiederfinden:
- Kapitel 2 behandelt den Bereich des Projektmanagements (=> Projektdefinition & Pro-
jektplanung), welches zur Bearbeitung dieser Projektarbeit notwendig war.
- Das vorhandene System, auf dessen Basis unsere Entwicklung aufsetzte, wird in Ka-
pitel 3 beschrieben, wobei eine Kurzbeschreibung des Systems bereits in Kapitel 1.2
aufgenommen wurde, um den Einstieg zu erleichtern.
- Kapitel 4 beschäftigt sich mit der Wiederinbetriebnahme des Systems in neuer Umge-
bung und verifiziert somit das Ergebnis des Vorgängerprojekts.
- Die eigentliche Umsetzung des Client-Server-Systems mit zugehörigem Test ist in Ka-
pitel 5 zu finden.
- Letztendlich wird in Kapitel 6 ein Fazit gezogen und schlägt eventuelle Verbesserungs-
möglichkeiten vor, welche nicht als Teil dieser Projektarbeit definiert waren.
3 Systembeschreibung
Das Antennensystem lässt sich in vier miteinander verbundene Komponenten aufgliedern
(siehe Abbildung 1Fehler! Verweisquelle konnte nicht gefunden werden. in Kapitel 1.2).
Die einzelnen Systemkomponenten werden im Folgenden weiter ausgeführt.
3.1 Antennenmodul
Das Antennenmodul besteht aus der Antenne selbst, dem Antennenmast und einem Unterbau
(Abbildung 8). Der Unterbau ist ein geschlossenes System und enthält den Antriebsmotor so-
wie ein Potentiometer zur Erfassung der aktuellen Winkelposition.
Die elektrische Kontaktierung von Motor und Potentiometer erfolgt über Bananenbuchsen.
Abbildung 8 Aufbau Antriebseinheit
Anschluss Potentiometer Anschluss Motor
Antennenmast
Antenne
Unterbau
3.2 Antriebsregelung
Die Antriebsregelung ist ein Multi-Board-System bestehend aus einem Arduino Due Mikrocon-
troller-Board inkl. selbst entwickelten Motor Shield und einem Raspberry Pi 3, Model B. Die
Systemkomponente stellt die Schnittstelle zwischen Sensor (Winkel-Position) und Aktor (Mo-
tor) dar und dient zur Ausrichtung der Antenne auf einstellbare Soll-Winkel. Die verwendeten
Reglerparameter sind dynamisch einstellbar.
Zur Erfassung des Ist-Winkels wird das Potentiometer im Antennenunterbau über einen Ana-
logeingang des Mikrocontrollers ausgewertet.
Die Verarbeitung von Ist- und Soll-Winkel und die Berechnung der Stellgröße für die Motoran-
steuerung erfolgt über einen PID-Regler auf dem Arduino-Mikrocontroller. Der Regelalgorith-
mus wurde mit Methoden der modellbasierten Softwareentwicklung unter Verwendung von
Matlab entworfen und generiert.
Die Ansteuerung des Motors erfolgt über einen Toshiba TB6612FNG Motortreiber auf dem
Motor Shield (Abbildung 9, [3]).
Abbildung 9 Arduino Due mit Motor Shield
Die Verbindung zwischen Arduino und Raspberry PI erfolgt über eine serielle Schnittstelle
Auf dem Raspberry läuft die Software IBM Node-RED. Diese stellt die Verbindung zur Außen-
welt dar. Für eine Beschreibung der Software siehe Kapitel 4.3 Node-RED – Erklärung, Start
und Konfiguration S.12ff.
3.3 Gateway
Die Kommunikation zwischen der Antriebsregelung und der Bedienerschnittstelle erfolgt über
einen MQTT Broker. Dieser fungiert als Server und verteilt empfangene Nachrichten weiter.
Bei der Wiederinbetriebnahme wird in Kapitel 4.4 Kommunikation über MQTT S.18ff näher auf
das Thema MQTT eingegangen.
3.4 Bedienerschnittstelle
Die vierte Komponente stellt die Bedienerschnittstelle dar. Folgende Funktionen sind vorgese-
hen:
- Vorgabe anzuwendende Regler-Parameter
- Einstellung Soll-Position (Winkel)
- Start bzw. Stopp des Positioniervorgangs
- Visualisierung der erfolgten Positionsänderung
Die dazu im Vorgängerprojekt entwickelte Java-Applikation ist in Kapitel 4.5 Test der Anten-
nenansteuerung S.22ff detaillierter beschrieben.
4 Wiederinbetriebnahme der Antenne
Aufbauend auf der Einarbeitung in die Projektarbeit „Modellbasierte Softwareentwicklung mit
Raspberry Pi“ und nach Verstehen des Systems (siehe Kapitel 3) konnte die Antenne schließ-
lich in Betrieb genommen werden. Die Inbetriebnahme wird in den folgenden Unterkapiteln in
realisierter Reihenfolge beschrieben:
- Anschluss / Verkabelung der Antenne
- Verbindung des Raspberry Pi mit einem vorhandenen WLAN-Netz
- Start und Konfiguration von Node-RED
- Anlegen eines Zugangs zu einem MQTT-Broker
- Test der Antennenansteuerung über den angelegten MQTT-Broker mit Hilfe der Visu-
alisierungssoftware der vorherigen Projektarbeit
Da einige Schritte nicht selbsterklärend waren und so manche Schwierigkeiten bereiteten, wird
in dieser Ausarbeitung Wert auf eine präzise Erklärung gelegt, um einer Weiterentwicklung
des Systems durch andere Projektgruppen entgegen zu kommen, auch wenn es sich stellen-
weise um triviale Schritte handelt.
4.1 Anschluss / Verkabelung der Antenne
Die Verkabelung und der Anschluss der Antenne ans Stromnetz sind in folgender Abbildung
zu erkennen.
Abbildung 10 Anschluss / Verkabelung der Antenne
4.2 Verbindung des Raspberry Pi mit WLAN-Netz
Im Raspberry Pi 3, Model B, welcher für die Antennenansteuerung verwendet wird, ist ein
WLAN-Modul integriert. Bei der Erstinbetriebnahme der Antenne in einem neuen WLAN-Netz
muss das WLAN-Modul konfiguriert werden. Dies erfolgt durch folgende Schritte:
- Auf das Menü-Symbol (Himbeere) klicken.
- Dann weitere Auswahl von „Einstellungen“ „Raspberry-Pi-Konfiguration“.
Abbildung 11 Raspberry-Pi-Konfiguration öffnen
- Es erscheint daraufhin folgendes Fenster, in welchem „Lokalisierung“ „WiFi-Land
festlegen…“ zu wählen ist. Als Länderkürzel das entsprechende Land auswählen, in
welchem man sich befindet.
Abbildung 12 WiFi-Land festlegen
- Anschießend muss das verfügbare WLAN-Netz ausgewählt werden, über welches die
Antenne an das Internet angebunden werden soll. Dazu auf das entsprechende Sym-
bol in der Menüleiste klicken (siehe unter kleinem schwarzen Pfeil!). Es öffnet sich
schließlich eine Liste mit allen verfügbaren WLAN-Netzen in Reichweite. Das pas-
sende WLAN-Netz auswählen.
Abbildung 13 WLAN-Netz wählen
- Abschließend muss das Passwort des WLAN-Netzes eingegeben und mit „OK“ bestä-
tigt werden, um die Verbindung aufbauen zu können. Wie die dazu erforderliche Tas-
tatur (vorausgesetzt es ist keine externe Tastatur angeschlossen!) angezeigt werden
kann, ist ebenfalls in einer Abbildung aufgezeigt (Himbeersymbol „Barrierefreiheit“
„Florance Virual Keyboard“).
Abbildung 14 WLAN-Schlüssel eingeben
Abbildung 15 Tastatur auf dem Raspberry Pi öffnen
Das WLAN-Symbol sollte jetzt so aussehen wie in Abbildung 10 zu sehen (Links neben dem
Lautsprecher in der Hauptmenüleiste. Klickt man auf dieses Symbol, so befindet sich ein grü-
ner Haken vor dem ausgewählten WLAN-Netz. Darüber kann die Verbindung bei Bedarf auch
wieder getrennt werden.
4.3 Node-RED – Erklärung, Start und Konfiguration
Die folgenden Abschnitte „Was ist Node-RED?“ und „Verfügbarkeit von Node-RED auf dem
Raspberry Pi“ sind der Projektarbeit „Modellbasierte Softwareentwicklung mit Raspberry Pi“
entnommen. Für eine allgemeine Beschreibung soll die Welt nicht zweimal erfunden werden.
4.3.1 Was ist Node-RED?
Die Software Node-RED ist ein von der Firma IBM entwickeltes Programm zur grafischen Pro-
grammierung von Abläufen für ”Internet-of-Things“-Anwendungen. ”Internet-of-Things“ oder
kurz ”IoT“ bezeichnet dabei die zunehmende Tendenz, das einfache Geräte, so genannte
Dinge, ohne Zutun eines menschlichen Teilnehmers miteinander und mit internetbasierten
Diensten Daten auszutauschen und zu kommunizieren. Aktuelle Version von Node-RED ist
0.16.2. Zielsetzung ist dabei, eine Informationslücke zu schließen, welche dadurch entsteht,
dass bestimmte Zustände eines Geräts dem Gegenüber nicht bekannt sind. Diese Zustände,
z.B. Umgebungstemperatur oder Tonerstand eines Druckers, sollen dabei so automatisch wie
möglich zu dem Gegenüber übertragen werden. Dies kann beispielsweise über RFID Iden-
tifikatoren geschehen oder über Sensoren und Aktoren, die Zustände melden oder ändern.
Das ”IoT“ bezeichnet dabei nun die Verknüpfung von eindeutig identifizierbaren Gegenständen
miteinander über internetähnliche Strukturen. Anstelle des klassischen HTTP-Protokoll kommt
aus Gründen der besseren Anwendbarkeit ein Protokoll namens MQTT zum Einsatz, welches
besser auf die Anwendung mit kommunizierenden Kleinstgeräten zugeschnitten ist, wie weiter
unten gezeigt wird. MQTT steht dabei für ”Message Queue Telemetry Transport“, bezeichnet
also die Übertragung von Telemetrie-Daten mittels einer Warteschlange. Node-RED erleich-
tert die Programmierung von Kommunikationsabläufen über einen eigenen grafischen Editor,
mit dem über parametrierbare Funktionsblöcke und deren Verbindung untereinander so ge-
nannte ”Flows“ erstellt werden. Diese ”Flows“ wandeln nun die Nachrichten der ”Internet-of-
Things“ wunschgemäß und leiten sie in die gewünschten Nachrichtenkanäle. Dabei kann der
Nutzer aus unterschiedlichen Standardblöcken wählen, beispielsweise Eingangsblöcken, Ver-
arbeitungsblöcken und Ausgangsblöcken. Diese Funktionsblöcke sind entweder parametrier-
bar oder eigene Blöcke können mittels Javascript vollständig selbst programmiert werden. Der
gesamte Code wird letztendlich vollständig in Javascript abgebildet, welcher beispielsweise
beim Exportieren von Flows sichtbar wird. Ist ein Flow erstellt, kann dieser leicht über den
sogenannten Deploy-Knopf aktiv gesetzt werden und beginnt seine Arbeit. Node-RED ist dabei
auf vielen Plattformen verfügbar wie z.B. auch auf dem Raspberry Pi.
4.3.2 Verfügbarkeit von Node-RED auf dem Raspberry Pi
Seit November 2015 ist Node-RED und die dafür notwendige Plattform Node.js Bestandteil
des Betriebssystems des Raspberry Pi, genannt Raspbian Jessie. Nach Download und Instal-
lation auf der SD-Karte kann dann sofort nach dem Start des Raspberry PI über das Haupt-
menü Node-RED gestartet werden. Node-RED ist dann im Netzwerk über http://IP-Ad-
resse_des_Raspberry_PI:1880 erreichbar. Diese kann man an jedem Rechner des Netzwerks
über den Webbrowser eingeben und befindet sich dann im Editor des Node-RED.
4.3.3 Start von Node-RED auf dem Raspberry Pi und Konfiguration über einen PC
Wie soeben beschrieben, wird Node-RED über das Hauptmenü gestartet (Menü Entwick-
lung Node-RED). Es öffnet sich daraufhin auf dem Bildschirm die Node-RED Konsole.
Abbildung 16 Start von Node-RED auf dem Raspberry Pi
Abbildung 17 Node-RED console
Im Konsolenfenster ist unter anderem die Information „Once Node-RED has started, point a
browser at http://192.168.2.108:1880...“ zu sehen. Dies ist gleichbedeutend mit obiger Be-
schreibung „http://IP-Adresse_des_Raspberry_PI:1880“, wobei die IP-Adresse des Raspberry
Pi demzufolge 192.168.2.108 ist. Über diese Adresse kann also der Zugriff auf Node-RED mit
einem im gleichen Netzwerk befindlichen PC oder Laptop erfolgen. Es wird empfohlen, mit
dem Firefox-Browser zu arbeiten, weshalb dies im Folgenden geschehen soll. Nach Eingabe
der genannten Adresse öffnet sich Node-RED im Browser.
Abbildung 18 Node-RED Entwicklungsumgebung
4.3.4 Oberfläche und Bedienung von Node-RED
Für genauere Informationen zur Oberfläche und Bedienung von Node-RED, vor allem aber
auch zur Erstellung von Flows, soll auf die Projektarbeit „Modellbasierte Softwareentwicklung
mit Raspberry Pi“ verwiesen werden. Da wir im Rahmen unserer Projektarbeit auf den beste-
henden Flows aufgesetzt haben, waren die Berührungspunkte mit Node-RED beschränkt auf
den Start der programmierten Flows über den Deploy-Knopf und die Konfiguration eines
MQTT-Brokers anhand passender Zugangsdaten, weshalb lediglich diese Schritte in diesem
Kapitel beschrieben werden.
Der Deploy-Knopf ist in vorheriger Abbildung rechts oben mit „Deploy“ beschriftet und ist ak-
tuell ausgegraut. Die bestehenden Flows können also noch nicht gestartet werden. Um den
Start zu ermöglichen, muss über das Symbol mit den drei horizontal übereinander angeordne-
ten Strichen (rechts oben) ein Menü geöffnet werden, in welchem dann „Configuration nodes“
auszuwählen ist. Es öffnet sich daraufhin ein „config“-Fenster, in welchem die entsprechenden
Nodes konfiguriert werden können. Die Nodes, welche in der vorliegenden Projektarbeit zur
Anwendung kommen, sind zum einen der „mqtt-broker“, über den Daten von der Antenne an
den zu entwickelnden Web-Service (und umgekehrt) übertragen werden sollen, und zum an-
deren der „serial-port“, über welchen die mqtt-Daten übersetzt und passend zum Arduino über-
tragen werden (und auch hier ebenfalls in die andere Richtung), welcher die Regelung der
Antennenansteuerung letztendlich vollzieht.
Abbildung 19 "config"-Registerkarte nach Menüauswahl in Node-RED
Ein Doppelklick auf den angelegten mqtt-broker öffnet das Fenster „Edit mqtt-broker node“.
Hier müssen die folgenden Daten des MQTT-Brokers eingetragen werden, was auch die zwei
nachstehenden Abbildungen zeigen. Wie man an die Daten des MQTT-Brokers kommt, wird
im nächsten Kapitel aufgezeigt.
In der Registerkarte „Connection“:
- Server-Adresse
- Port
In der Registerkarte „Security“:
- Username
- Password
Nach Eingabe der Daten werden diese über den Button „Update“ aktualisiert. Jetzt können die
bestehenden Flows über den Deploy-Knopf gestartet werden und die Verbindung zum MQTT-
Broker wird hergestellt, was auch vom Raspberry Pi in der „Node-RED console“ angezeigt wird
(siehe Abbildung unten).
Abbildung 20 "Edit mqtt-broker node" - "Connection" in Node-RED
Abbildung 21 "Edit mqtt-broker node" - "Security" in Node-RED
Abbildung 22 Ansicht des Node-RED Konsole auf dem Raspberry Pi nach Start der Flows über Node-RED
4.4 Kommunikation über MQTT
Bevor wir uns in diesem Kapitel mit dem Anlegen eines Zugangs zu einem MQTT-Broker be-
schäftigen, soll eine kurze Einführung zum Thema MQTT gegeben werden. Auch diese Be-
schreibung findet man ausführlich in der vorangegangenen Projektarbeit beschrieben. Trotz-
dem soll ein kurzer Überblick zu MQTT erfolgen, um bei einer Weiterentwicklung der Anten-
nenansteuerung via Internet die Einarbeitungszeit auf ein Minimum zu beschränken.
4.4.1 Was ist MQTT?
Das MQTT-Protokoll ist ein seit 2014 standardisiertes, offenes Nachrichtenprotokoll für Ma-
schine-zu-Maschine Kommunikation und eignet sich dank seines minimalen Protokoll-Over-
heads auch für verzögerte oder bandbreitenbegrenzte Übertragung in Netzwerken.
Für das Protokoll ist es unerheblich, ob es sich bei den übertragenen Daten um Text oder
binär-kodierte Inhalte handelt. Zudem ist bei der Kommunikation zwischen Geräten über
MQTT kein Polling notwendig. Das bedeutet, dass die einzelnen Teilnehmer, welche über ei-
nen zentralen Verteiler ( MQTT-Broker) miteinander verknüpft sind, nicht zyklisch nach
eventuell empfangenen Nachrichten fragen müssen. Eine Nachricht kann von jedem Teilneh-
mer zum MQTT-Broker gesendet werden. Dieser verteilt die Nachrichten automatisch an alle
anderen Teilnehmer. Man spricht davon, dass die Nachrichten gepusht werden, also direkt
weiterverteilt. Dieses Prinzip nennt man „Publish/Subscribe“.
Abbildung 23 Das "Publish/Subscribe"-Prinzip bei Datenkommunikation über MQTT
In obiger Abbildung sind beispielsweise drei über einen MQTT-Broker verkoppelten Geräte zu
sehen, ein Temperaturfühler, ein Laptop und ein mobiles Endgerät. Diese Teilnehmer nennt
man Clients. Jede Nachricht eines Clients enthält dabei ein so genanntes Topic und die tat-
sächlichen Daten. Das Topic kann von jedem Client, der einen Nutzen davon hat, abonniert
werden. Ergibt sich nun eine neue Nachricht eben jenes Topics, informiert der MQTT-Broker
jeden eingetragenen Client darüber. Somit ist eine Abfrage der Clients nach neuen Nachrich-
ten zum Server nicht notwendig. Dies ermöglicht eine sehr effiziente Kommunikation. Kein
Teilnehmer weiß dabei von einem anderen, nur der Message Broker ist Ansprechpartner. Wei-
terhin besitzt MQTT eine Reihe weiterer Features, auf die hier nicht weiter eingegangen wer-
den soll.
4.4.2 Schwierigkeiten bei der Inbetriebnahme des Vorgängersystems
Eine große Schwierigkeit bei der Einarbeitung und nachfolgend der Inbetriebnahme der An-
tenne bestand darin, dass nicht geklärt wurde, auf welcher Seite der MQTT-Broker läuft. Nach
etlichen Fehlversuchen, die Flows des Node-RED (siehe Kapitel 4.3) zu starten und demzu-
folge eine Verbindung zum MQTT-Broker herzustellen, war klar, dass eine tiefere Beschäfti-
gung mit dieser Thematik notwendig sein würde.
Bis zu diesem Zeitpunkt gingen wir davon aus, dass der MQTT-Broker Bestandteil der vorhe-
rigen Projektarbeit war. Doch wieso konnte keine Verbindung mehr zu ihm aufgenommen wer-
den? Also wurde recherchiert, wo der MQTT-Broker denn eigentlich implementiert war. Ergeb-
nis der Recherche war letztendlich, dass ein Anbieter über das Internet ausgewählt wurde,
welcher den MQTT-Broker zur Verfügung stellte. Um welchen es sich handelte und wie damit
umzugehen war, zeigt der nächste Abschnitt.
4.4.3 Auswahl und Konfiguration eines MQTT-Brokers
Die Nachverfolgung des verwendeten MQTT-Brokers führte zum Anbieter „CloudMQTT“
(https://www.cloudmqtt.com).
Abbildung 24 Startseite "www.cloudmqtt.com"
Dort ist es unter dem Reiter „Plans“ möglich, eine MQTT-Broker-Instanz einzurichten. Die kos-
tenlose Variante nennt sich dabei „Cute Cat“ und beinhaltet laut Angabe zehn Verbindungen
bei einer Geschwindigkeit von zehn kbit/s. Benötigt man eine höhere Performance, ist es not-
wendig zu einer kostenpflichtigen Version zu wechseln.
Leider wird keine Angabe gemacht, wie lange die angelegte MQTT-Broker-Instanz bei der
kostenlosen Version aktiv bleibt. Dass die Verbindung mit den Zugangsdaten der vorherigen
Projektarbeit nicht funktionierte, lag wohl an einer bestimmten Zeit von Inaktivität. Es war daher
nötig, einen eigenen Account anzulegen, da wir auf den entsprechenden Account der Vor-
gruppe keinen Zugang hatten. Es soll hierbei jedoch kurz erwähnt werden, dass auch die erste
von uns angelegte Instanz nach einiger Zeit Inaktivität nicht mehr funktionierte. Wir legten da-
her eine Neue über „+ Create“ an. Im Folgenden ist der angelegte Account zu sehen.
Abbildung 25 CloudMQTT Instanzen
Mittlerweile ist jedoch klar, dass auch die erste Instanz wieder aktiv gesetzt werden kann. Dazu
mit „Details“ die dafür notwendige Registerkarte öffnen (siehe folgende Abbildung). Dort sind
die benötigten Zugangsdaten zum Aufbau der Verbindung mit dem MQTT-Broker abrufbar. Mit
dem Button „Restart“ ist es möglich, diese Instanz neu zu starten. Vermutlich ist dies nach
einer bestimmten Zeit Inaktivität notwendig.
Diese Zugangsdaten können jetzt also in der Software Node-RED zur Konfiguration des
MQTT-Broker-Knotens verwendet werden. Auf eine weitere Behandlung des MQTT-Brokers
soll hier verzichtet werden, da dieser Teil wie bereits erwähnt nicht Bestandteil dieser Projek-
tarbeit war.
Abbildung 26 Informationen zu einer angelegten MQTT-Broker Instanz
4.5 Test der Antennenansteuerung
Um die Antennenansteuerung letztendlich zu testen, wurde die Visualisierungssoftware der
Vorgruppe verwendet. Diese wird mit einem Doppelklick auf „ProjektarbeitGUI.jar“ gestartet.
Nachstehende Abbildung zeigt die Oberfläche dieser Software.
Abbildung 27 Visualisierungsoberfläche "Antennenregelung"
Vor dem Start muss die Software über die Registerkarte „Einstellungen“ mit dem MQTT-Broker
verbunden werden. Standardmäßig sind hier die veralteten Daten eingetragen. Über den But-
ton „connect“ wird versucht, die Verbindung aufzubauen.
Abbildung 28 Registerkarte „Einstellungen“ der Software "Antennenregelung"
Die Registerkarte „Konsole“ gibt Informationen darüber, ob dies erfolgreich war. Wie hier in
den oberen Zeilen zu sehen ist, konnte die Verbindung nicht hergestellt werden, da diese In-
stanz entweder inaktiv ist oder sogar gelöscht wurde. Das gleiche Spiel wurde schließlich mit
unseren eigenen Zugangsdaten durchgeführt. Auch dies ist in der Konsole zu sehen und zeigt
die erfolgreiche Kommunikation mit dem MQTT-Broker. Die Status der Parametrierung des
Reglers (Regelparameter) werden also gleich mit dem Start der Verbindung übermittelt
Abbildung 29 Registerkarte „Konsole“ der Software "Antennenregelung"
Da die Antenne ebenfalls mit dem MQTT-Broker verbunden ist, werden diese Daten an sie
weitergeleitet, worauf sie mit einer entsprechenden Bewegung reagiert. Die Reglerparameter
und die Sollposition der Antenne als Winkel können geändert werden und mit dem Button
„übernehmen“ vorbereitet werden. Mit Klick auf „Start“ werden diese neuen Werte schließlich
ebenfalls zum MQTT-Broker übermittelt. Wurde die Kommunikation mit dem MQTT-Broker
einmal gestartet (Button „Start“ ist ausgegraut, also aktiv), so können die Reglerparameter und
die neue Soll-Position der Antenne über den Button „übernehmen“ direkt zur Antenne übertra-
gen werden.
5 Neuentwicklung
5.1 Grundbeschreibung der Software-Architektur
Um später eine (in Grenzen) beliebige Zahl von Anwendern parallel den koordinierten Zugriff
auf die Antenne zu ermöglichen, sollte zwischen Anwender und Antenne eine Zwischenschicht
implementiert werden. Diese Zwischenschicht wurde als Webservice ausgeführt. Dieser kom-
muniziert einerseits mit allen Anwendern (=Clients) über das HTTP-Protokoll – hier können
Experimente gestartet und Informationen bezüglich denselben abgefragt werden.
Der Webservice übernimmt hierbei die Koordination und Priorisierung aller Clients – es erhält
zu einem Zeitpunkt immer nur 1 Anwender Zugriff auf die Antenne. Dahinter wird eine Warte-
schlange für weitere Experiment-Anfragen geführt, welche nach dem First-In-First-Out Prinzip
(FIFO-Prinzip) einer Queue umgesetzt wurde. Weiterhin kommuniziert der Webservice als ein-
ziger Teilnehmer direkt mit der Antenne über den MQTT Broker CloudMQTT. Gemäß dem
aktuell auszuführenden Experiment wird die Antenne vom Webservice angesteuert und die
über MQTT zurückgelieferten Daten zu Ist- und Soll-Position aufgezeichnet.
Abbildung 30 Softwarearchitektur
Im Folgenden werden die Details bzgl. der Softwarearchitektur und der Implementierung vor-
gestellt.
MQTT Bro-
ker Antenne Webservice
Client 1 Client 2 Client …
5.2 Serverseitig verwendete Technologien
Der Server wurde vollständig in C# unter Anwendung des Microsoft ASP.NET Web API Frame-
work implementiert. Dieses Framework erlaubt die einfache Entwicklung von auf dem HTTP-
Protokoll basierenden Servern – insbesondere von solchen, welche dem REST-Architektur-
prinzip folgen.
REST (kurz für „Representational State Transfer“) ist ein maßgeblich vom US-amerikanischen
Informatiker Roy Fielding, einem der Hauptautoren der HTTP-Spezifikation, seit dem Jahr
2000 geprägter Begriff [4]. REST bezeichnet dabei allerdings den Architekturstil selbst – un-
abhängig von konkreten Protokollen. Dennoch verwende REST-Services (Services, welche
gemäß REST-Architekturstil implementiert wurden) heute meist das HTTP-Protokoll.
Kern des REST-Architekturstils ist die Betrachtung von Datenpaketen als Ressource. Hierbei
ist von anwendungsorientierten Datenpaketen der OSI-Schichten 6, 7 und 8 die Rede – Da-
tenpakete (wie bspw. TCP-Packets) der darunterliegenden OSI-Schichten zählen nicht zu die-
ser Betrachtung. Ressourcen könnten damit ein Bild oder ein zusammengehöriger Datensatz
(bspw. Informationen zu einer Person aus einem Adressbuch) sein.
Weiterhin erfordert die Umsetzung des REST-Architekturstils eine Client-Server-Struktur. Alle
vom Server bereitgestellten Ressourcen müssen eindeutig adressierbar und über eben diese
Adressen von der Client-Anwendung aus erreichbar sein.
Der Server in dieser Arbeit sollte jedoch nicht nur bereits existierende Ressourcen (bspw. Er-
gebnissen vergangener Regler-Experimente) an den aufrufenden Client zurückliefern. Es
musste auch die Möglichkeit bestehen, neue Ressourcen zu erzeugen und damit auch server-
seitige Aktionen auszulösen (bspw. neues Experiment starten).
Zur Übertragung von Parametern bei Auslösung eines neuen Experimentes besteht in Kombi-
nation mit dem HTTP-Protokoll prinzipiell die Möglichkeit, diese per PUT oder POST zu über-
tragen. In dieser Arbeit wurden alle Parameter per PUT übertragen – hierfür werden die an
den Server zu übertragenden Parameter als sogenannter Query-String an die REST-Adresse
angehängt. Auf Grund dieser Entscheidung konnte ein normaler Web-Browser (Google
Chrome, Mozilla Firefox, …) als vollwertiger Client verwendet werden. Dies erleichterte insbe-
sondere die Testphase des Servers, als noch keine Client-Applikation implementiert worden
war.
Im Folgenden werden die Details bezüglich der Server-Implementierung vorgestellt.
5.3 REST-Service
Der Server verfügt über mehrere Ressourcen, welche vom Client über konkrete Adressen ab-
gefragt bzw. manipuliert werden können. Zudem kann über eine spezielle Adresse ein neues
Experiment gestartet werden.
5.3.1 Start eines neuen Experiments
Zum Starten eines neuen Experiments ist die Adresse http://{SERVER}:4567/order/new auf-
zurufen. {SERVER} stellt in diesem Fall einen Platzhalter für die tatsächliche Server-Adresse
dar, welche davon abhängt, wo die Server-Anwendung gehostet wird (bspw. „localhost“ für
lokale Tests). 4567 bezeichnet die Nummer des TCP-Ports, über welchen mit dem Server
kommuniziert werden kann. An die Adresse müssen nun alle Parameter des Experiments in
Form eines Query-Strings angehängt werden. Folgende Tabelle 6 verschafft einen Überblick
über alle verfügbaren Parameter.
Tabelle 6 Beschreibung Übergabeparameter Start Experiment
Parametername Kurzbeschreibung
startPos Gewünschte Startposition der Antenne, welche vor Aufzeichnung des
Trace angefahren werden soll. Angabe in 0,1°-Schritten (z.B. 25° =
250). Muss um Bereich 20° - 340° liegen.
targetPos Gewünschte Zielposition der Antenne. Angabe in 0,1°-Schritten (z.B.
310° = 3100). Muss im Bereich 20° - 340° liegen.
traceTimeSec Aufzeichnungsdauer in Sekunden für das Experiment. Das Experi-
ment beginnt an der parametrierten Startposition. Für die angegebene
Anzahl von Sekunden werden Sollwert und Istwert für spätere Analy-
sen aufgezeichnet. Muss im Bereich 5 Sek. – 30 Sek. liegen.
ctrlP Gewünschter Regler-Parameter P.
ctrlI Gewünschter Regler-Parameter I.
ctrlD Gewünschter Regler-Parameter D (wird im Moment hardwareseitig ig-
noriert).
Alle aufgeführten Parameter müssen im Query-String client-seitig spezifiziert werden. Dieser
lautet formal
startPos={startPosValue}&targetPos={targetPosVa-
lue}&traceTimeSec={traceTimeSecValue}&ctrlP={ctrlPValue}&ctrlI={ctrlIVa-
lue}&ctrlD={ctrlDValue}
wobei die in geschweiften Klammern angegebenen Platzhalter durch die gewünschten Para-
meterwerte substituiert werden müssen. Der Query-String muss anschließend der Ressour-
cen-Adresse angehängt werden. Als Beispiel diene folgendes fiktive Experiment:
Es soll eine 20-sekündige Aufzeichnung der Soll- und Ist-Positionen einer Antennenbewegung
von 60° nach 190° stattfinden. Als Regler für die Positionsregelung soll hier ein reiner P-Regler
mit einem Verstärkungsfaktor von 10 verwendet werden. Folgende Adresse inklusive Query-
String muss hierfür verwendet werden:
http://{SERVER}:4567/order/new?startPos=600&target-
Pos=1900&traceTimeSec=20&ctrlP=10&ctrlI=0&ctrlD=0
Als Rückmeldung auf eine client-seitigen Anforderung „Start eines neuen Experiments“ sendet
der REST-Service eine menschenlesbare Antwort im Format JavaScript Object Notation (kurz
JSON) mit Padding (kurz JSONP) zurück. Die in dieser JSON-Nachricht enthaltenen Parame-
ter werden in der nachfolgenden Tabelle 7 aufgelistet:
Tabelle 7 Beschreibung Rückgabeparameter Start Experiment
Parametername Kurzbeschreibung
OrderId Eindeutige ID-Nummer für den server-seitig erzeugten Auftrag. Eine
gültige ID-Nummer ist immer eine natürliche Zahl. Wird eine 0 (Null)
zurückgegeben, so konnte für das gewünschte Experiment server-sei-
tig kein Auftrag erzeugt werden.
State Ergebniscode der server-seitigen Auftragsverarbeitung.
1 = Auftrag erfolgreich angelegt
2 = Fehler beim Versuch, den Auftrag anzulegen (siehe DiagnosticDe-
tails für weiterführende Informationen).
DiagnosticDetails Enthält optional eine textuelle Zusatzinformation. Diese wird nur be-
füllt, falls das Experiment nicht erfolgreich angelegt werden konnte
(bspw. auf Grund von fehlerhaften Parametern). Der Aufrufer erhält
somit Hilfe-Informationen für den Fall, dass die Schnittstelle nicht kor-
rekt verwendet wird.
Folgend eine exemplarische JSONP-Antwort des Servers, aus welcher der Client herauslesen
kann, dass das angeforderte Experiment mit den vorgegebenen Parameterwerten server-sei-
tig akzeptiert wurde. Über die OrderID 45 kann die Client-Anwendung alle weiteren Informati-
onen bezüglich dem angelegten Auftrag / Experiment vom Server abfragen.
callback_neworder({
"OrderId": 45,
"State": 1,
"DiagnosticDetails": ""
})
Die Kapselung der reinen JSON-Antwort mit „callback_neworder()“ rührt von der Verwendung
des erweiterten Formats JSONP. Hintergrundinformationen und Erläuterungen hierzu finden
sich im späteren Kapitel „Cross-Origin Resource Sharing und JSONP“.
5.3.2 Status eines Experimentes abfragen
Zur Abfrage des aktuellen Status eines Experimentes inklusive der aufgezeichneten Soll- und
Ist-Positionen ist die Adresse http://{SERVER}:4567/order/getstate/{orderID} aufzurufen. {or-
derID} stellt dabei einen Platzhalter dar und ist durch die ID-Nummer des interessierenden
Experimentes zu ersetzen. Folgender JSONP-Ausschnitt zeigt eine exemplarische Antwort auf
die Status-Abfrage eines bereits abgeschlossenen Experimentes:
callback_getstate({
"OrderRequest": {
"StartPosition": 250,
"TargetPosition": 2500,
"TraceTimeSec": 25,
"P": 5.0,
"I": 5.0,
"D": 5.0
},
"OrderId": 21,
"PrecedingClientsCount": 0,
"EstimatedSecondsLeft": 0,
"State": 3,
"Data": [
{
"TargetValue": 2500,
"ActualValue": 263,
"TimestampMS": 0
},
{
"TargetValue": 2500,
"ActualValue": 254,
"TimestampMS": 10
},
{
"TargetValue": 2500,
"ActualValue": 246,
"TimestampMS": 20
},
…
]
})
In nachfolgender Tabelle 8 werden die relevanten Einträge dieser JSONP-Nachricht aufgelis-
tet und im Detail erläutert.
Tabelle 8 Beschreibung Rückgabeparameter Status Experiment
Parametername Kurzbeschreibung
OrderRequest JSON-Objekt, welches die Experiment-Konfiguration darstellt. Hierin
enthalten sind die Randbedingungen des Experimentes, wie bspw.
Start- und Zielposition, Experiment-Dauer und Reglerparameter.
OrderId Eindeutige ID-Nummer des Experimentes.
PrecedingClient-
sCount
Anzahl der Experimente anderer Clients, die noch vor diesem Experi-
ment vom Server ausgeführt werden.
EstimatedSe-
condsLeft
Geschätzte / grob kalkulierte Zeitdauer bis zum Start dieses Experi-
ments (basierend auf der Anzahl und der konfigurierten Experiment-
dauer der noch vorab auszuführenden Experimente).
State Aktueller Status-Code:
1 = Experiment in Warteschleife – andere Experimente werden zuvor
ausgeführt
2 = Experiment wird aktuell ausgeführt
3 = Experiment abgeschlossen
4 = Zur vom Client angefragten OrderId wurde kein Experiment ge-
funden
5 = Unbekannter Fehler, welcher zum Abbruch des Experimentes
führte
Data Aufzeichnungswerte der Soll- und Ist-Positionen der Antenne in Zeit-
abständen von 10 Millisekunden. Data ist als Array von JSON-Objek-
ten ausgeführt.
TargetValue Zielposition in 0,1°-Schritten zum angegebenen Zeitpunkt Ti-
mestampMS.
ActualValue Ist-Position in 0,1°-Schritten zum angegebenen Zeitpunkt Ti-
mestampMS.
TimestampMS Zeitstempel in Millisekunden, die seit Beginn des Experimentes ver-
gangen sind.
5.3.3 CSV-Datei eines abgeschlossenen Experimentes downloaden
Nach Abschluss eines Experimentes kann über Aufruf der Adresse http://{SERVER}:4567/or-
der/gettrace/{orderID} die Aufzeichnung von Zeitstempeln mit zugehörigen Soll- und Ist-Posi-
tionen im CSV abgefragt werden. Diese Daten lassen sich im Anschluss einfach für weitere
Analysen (bspw. mit MATLAB) verwenden.
5.4 HTML-Client
Um die Server-Funktionalitäten komfortabel nutzen zu können, wurde eine Client-Anwendung
entwickelt. Diese Client-Anwendung besteht aus HTML-Seiten mit eingebetteten JavaScript-
Funktionalitäten, welche in gängigen Webbrowsern durch Aufruf spezieller Adressen des
REST-Services angezeigt werden können. Die Kommunikation mit dem Server wurde mit Hilfe
der JavaScript Bibliothek jQuery umgesetzt.
5.4.1 Aktions-Auswahl
Durch Aufruf der Adresse http://{SERVER}:4567/ui/selection liefert der Server eine Webseite
zurück, welche den Nutzer zur Auswahl einer Aktion auffordert. Es besteht prinzipiell die Wahl
zwischen
- Anzeige der Ergebnisse eines Experimentes anhand einer bekannten OrderId
- Start eines neuen Experimentes
Als OrderId sind nur positive Ganzzahle zugelassen. Wird diese Forderung bei der Eingabe
seitens des Anwenders verletzt, wird eine entsprechende Meldung an diesen ausgegeben
(Abbildung 31). Ebenso erhält der Anwender eine Meldung, wenn eine syntaktisch gültige je-
doch unbekannte OrderId angegeben wird (Abbildung 32).
Abbildung 31 Aktions-Auswahl: Ungültige OrderID
Abbildung 32 Aktions-Auswahl: Unbekannte OrderID
Wird eine korrekte und bekannte OrderId angegeben, liefert der Server die entsprechenden
Daten an den Client zurück. Dieser visualisiert die aufgezeichneten Soll- und Ist-Positionen
über den Zeitverlauf des Experimentes. Zusätzlich wird dem Anwender eine Schaltfläche an-
geboten, über welche die CSV-Datei mit den Aufzeichnungen des Experimentes herunterge-
laden werden kann (Abbildung 33).
Abbildung 33 Visualisierung Resultat Experiment
5.4.2 Neues Experiment starten
Über Aufruf der Adresse http://{SERVER}:4567/ui/newexperiment liefert der Server eine Web-
seite zur Konfiguration eines neuen Experimentes an den Client. Durch Klick auf die Schaltflä-
che „Neues Experiment“ der oben angesprochenen Seite zur Aktions-Auswahl wird der An-
wender ebenso auf diese Adresse umgeleitet (Abbildung 34). Die vom Server ausgelieferte
Webseite bietet Eingabemöglichkeiten für alle Experiment-Parameter, sowie JavaScript Funk-
tionalitäten zur Validierung der Benutzer-Eingaben sowie zur Kommunikation mit dem Server.
Abbildung 34 Konfiguration Experiment in Web-Oberfläche
Nach Betätigen der Schaltfläche „Experiment starten“ werden ungültige Nutzereingaben er-
kannt, markiert und mit einem entsprechenden Hinweis für den Anwender versehen (Abbil-
dung 35).
Abbildung 35 Konfiguration Experiment - ungültige Eingabe
Sind alle Nutzereingaben in Ordnung, wird die Experiment-Konfiguration an den Server über-
tragen. Sofern bereits andere Experimente in der server-seitigen Warteschlagen verwaltet
werden, erhält der Anwender eine sich stetig aktualisierende Information über die Anzahl der
noch vor dem eigenen Experiment durchzuführenden Experimente, sowie der geschätzten
Wartezeit bis zum Start des eigenen Experimentes (Abbildung 36).
Abbildung 36 Wartebildschirm in Web-Oberfläche
Sobald das eigene Experiment ausgeführt wird, werden die aufgezeichneten Daten im
Webbrowser des Anwenders live visualisiert und aktualisiert. Nach Abschluss des Experimen-
tes kann über Betätigen der Schaltfläche „CSV herunterladen“ die komplette Aufzeichnung der
Experiment-Daten im CSV-Format heruntergeladen werden (Abbildung 37, Abbildung 38).
Abbildung 37 Anzeige laufendes Experiment in Web-Oberfläche
Abbildung 38 Anzeige abgeschlossenes Experiment in Web-Oberfläche
Die Visualisierung der Experiment-Daten im Browser wurde mit Hilfe der JavaScript Bibliothek
plot.ly umgesetzt. Dank dieser ist der gezeigte Chart interaktiv: so können bspw. einzelne Da-
tenlinien im Chart ein- und ausgeblendet sowie in verschiedenen Dimensionen gezoomt wer-
den.
5.4.3 JSONP
An dieser Stelle sei ein kurzer Einschub zum Thema JSON mit Padding (kurz JSONP) gestat-
tet. Gängige Webbrowser erfüllen in der Regel die Vorgaben der Same-Origin Policy (kurz
SOP). Gemäß diesem Sicherheitskonzept verhindert ein Webbrowser den Zugriff aus HTML-
Seiten (und damit speziell darin enthaltener Skripte) auf Inhalte, welche aus einer anderen
Quelle stammen [5]. „Same Origin“ bedeutet zu Deutsch etwa „selber Ursprung“ bzw. „selbe
Quelle“. Der Webbrowser prüft dabei konkret auf die Übereinstimmung folgender 3 Punkte:
- Verwendetes Protokoll
- Domäne
- Port
Sobald ein Unterschied in mindestens einem der drei aufgeführten Punkte zwischen anfor-
derndem Client und angesprochenem Service festgestellt wird, verweigert ein der SOP folgen-
der Webbrowser der Client-Anwendung den Zugriff auf die erhaltenen Daten.
Solange die HTML-Webseiten von Quelle („Origin“) bereitgestellt werden, zu welcher auch alle
weiteren Kommunikationsverbindungen aus der HTML-Seite und darin enthaltener Skripte auf-
gebaut werden, gibt es keine Probleme. Insbesondere aber in frühen Testphasen kam es hier
durchaus zum Problem einer Verletzung der SOP:
Dabei wurden zu Testzwecken zunächst statische HTML-Seiten erstellt und direkt vom Datei-
system im Webbrowser geöffnet. Wurde nun mittels Skript versucht, eine HTTP-Kommunika-
tionsverbindung mittels JavaScript zum Server aufzubauen, wurde dies vom Webbrowser ge-
blockt. Dies lag darin begründet, dass die „Origin“ der vom Dateisystem geladenen HTML-
Seite und des unter localhost gehosteten Servers nicht übereinstimmten.
Es bestehen jedoch mehrere Möglichkeiten, Daten aus beliebigen Quellen abzurufen, welche
nicht der SOP unterliegen und somit nicht vom Webbrowser geblockt werden. Eine Möglichkeit
besteht in der Einbindung von Skripter per „script“-Tag in eine HTML-Seite. Im Web-Umfeld ist
es gang und gäbe JavaScript-Bibliotheken von fremden Servern in eine Webseite einzubinden.
JSONP nutzt eben diese Möglichkeit aus, indem die zu übertragenden JSON-Daten in einen
Funktionsaufruf verpackt werden. Betrachte man beispielsweise folgendes JSON-Objekt:
{
"OrderId": 45,
"State": 1,
"DiagnosticDetails": ""
}
Dieses wird vom Server im Funktionsaufruf callback_neworder() „verpackt“:
callback_neworder({
"OrderId": 45,
"State": 1,
"DiagnosticDetails": ""
})
Der Client erhält diese JSONP-Nachricht zurück und interpretiert sie als reines JavaScript. Das
bedeutet, im Client muss eine JavaScript Funktion callback_neworder(data) definiert sein, wel-
che nach Erhalt der JSONP-Nachricht aufgerufen wird – das ursprüngliche JSON-Objekt wird
dieser Funktion als Parameter „data“ übergeben. [6]
Die verwendete JavaScript Bibliothek jQuery erlaubt bei HTTP-GET-Requests das einfache
„Umschalten“ auf JSONP, indem an den Query-String der Parameter „callback=?“ angehängt
wird. Folgender exemplarischer Code-Ausschnitt verdeutlicht die Anwendung von JSONP in
JavaScript unter Nutzung der Bibliothek jQuery.
/// callback function
function callback_neworder(data) {
/// handle JSON object received via parameter “data”
...
}
/// send new request
function StartNewRequest(startPosDeg, targetPosDeg, simTimeSec, ctrlP,
ctrlI, ctrlD){
$.getJSON( "http://localhost:4567/order/new?startPos=" +
(startPosDeg * 10) + "&targetPos=" + (targetPosDeg * 10) +
"&traceTimeSec=" + simTimeSec + "&ctrlP=" + ctrlP + "&ctrlI=" +
ctrlI + "&ctrlD=" + ctrlD + "&callback=?" );
...
}
Natürlich hätte auch alles mit normalen JSON-Datenpaketen realisiert werden können. Hierzu
hätten lediglich alle HTML-Seiten bereits in den frühen Testphasen über den Server bereitge-
stellt werden müssen. Die Verwendung von JSONP wurde jedoch bewusst bevorzugt, da somit
für eventuell noch folgende Projekte mehr Freiheiten bestehen – bspw. in der Entwicklung
anderer oder erweiterter Client-Anwendungen.
5.5 ASP.NET Hosting
Nach Abschluss aller lokal durchgeführten Tests der Server- und Clientsoftware bestand der
nächste Schritt im Hosting der Server-Anwendung auf einem über das Internet zugänglichen
Server, sodass dieser später auch von überall angesprochen werden konnte. Da serverseitig
mit der Microsoft-Technologie ASP.NET gearbeitet wurde, war zwingend ein Webserver-Be-
treiber mit Windows Hosting Angeboten auszuwählen. Über die Hochschule Darmstadt wurde
uns dafür ein Zugang für ein 1&1 Webhosting Paket „Unlimited Windows“ bereitgestellt. Im
Folgenden wurde der prinzipielle Ablauf des Hostings der entwickelten ASP.NET-Anwendung
dokumentiert – diese soll als Leitfaden für den/die späteren Betreiber der Anwendung dienen.
5.5.1 1&1 Hosting Paket „Unlimited Windows“
Um die Anwendung das erste Mal auf dem 1&1 Server hosten zu können, mussten einige
grundlegende Einstellungen im 1&1 Control Center des von der Hochschule bereitgestellten
Zugangs vorgenommen werden.
Im ersten Schritt wurde über den 1&1 Webfiles Manager ein entsprechendes Verzeichnis mit
dem Namen „AntenneC22“ direkt im Webspace Root-Verzeichnis angelegt. Dem Standardbe-
nutzer (unter welchem später auch die Server-Anwendung ausgeführt wird) wurden für dieses
Verzeichnis vollständige Lese- und Schreibrechte zugeteilt (Abbildung 39).
Abbildung 39 Verzeichnis anlegen und Zugriffsrechte konfigurieren
Anschließend wurde das soeben erstelle Verzeichnis über die Anwendungseinstellungen (Da-
tei => Anwendungseinstellungen) als Anwendungsverzeichnis festgelegt (Verzeichnis anwäh-
len und Schaltfläche „Hinzufügen“ betätigen). Die erfolgreiche Festlegung als Anwendungs-
verzeichnis lässt sich am geänderten Icon vor dem Verzeichnisnamen im Fenster „Anwen-
dungseinstellungen“ erkennen. Diese Festlegung ist nötig, um ASP.NET Anwendungen in ei-
nem konkreten Verzeichnis hosten zu können (Abbildung 40).
Abbildung 40 AntenneC22 als Anwendungsverzeichnis deklarieren
Im nächsten Schritt wurde ein FTP-Zugang im 1&1 Control Center angelegt, welcher direkt mit
dem eben erzeugten Verzeichnis verknüpft wurde (projektspezifischer FTP-Zugang). Über die-
sen FTP Zugang konnte später komfortabel die ASP.NET Serveranwendung gehostet werden
(Abbildung 41).
Abbildung 41 Projektspezifischen FTP Zugang einrichten (Benutzernamen und Verzeichnisdetails unkenntlich ge-macht)
5.5.2 Anwendungsverzeichnis
Bei der Entwicklung von ASP.NET Anwendungen gilt es zu berücksichtigen, dass die Anwen-
dung in der Regel mit Hilfe der Microsoft Diensteplattform Internet Information Services (IIS)
bereitgestellt wird. Sollen in der Anwendung verwendete Daten dynamisch bleiben und in sta-
tischen Dateien ausgelagert werden (bspw. im konkreten Fall dieser Projektarbeit Archiv-Da-
teien für jedes ausgeführte Experiment mitsamt einem Trace der Soll- und Ist-Positionen der
Antenne), muss aus der Anwendung heraus auf diese Dateien zugegriffen werden.
Bei einem Administrator-Zugang zum IIS stellt dies kein Problem dar, da für beliebige Ver-
zeichnisse beliebige Zugriffsrechte verteilt werden können. Beim verfügbaren 1&1 Paket Unli-
mited Windows hingegen steht kein solcher Administrator-Zugang bereit. Daten können nur
im zugeordneten Webspace abgelegt werden – hier sind jedoch weder der relative Pfad zum
IIS noch der absolute Pfad in Bezug auf die Windows-Maschine im Hintergrund erkennbar.
Um dennoch im Quellcode Zugriffe auf Dateien und Verzeichnisse im Webspace zu ermögli-
chen, stellt die ASP.NET Serverumgebung den Befehl
System.Web.Hosting.HostingEnvironment.MapPath(string path)
bereit.
In der Variable „path“ können nun Pfadangaben relativ zum Root-Verzeichnis des Webspace
erfolgen – die Routine MapPath ermittelt im Hintergrund die entsprechenden Konfigurationen
und liefert die absolute Adresse der angeforderten Ressource auf der Windows-Maschine zu-
rück.
5.5.3 Hosting
Die ASP.NET Serveranwendung wurde mit der Entwicklungsumgebung Microsoft Visual Stu-
dio Professional 2013 erstellt. Diese kann jedoch durchaus auch mit aktuelleren Versionen
bearbeitet werden – es genügen hierfür auch die kostenlosen Community-Versionen. Der Vor-
teil in der Verwendung von Visual Studio liegt in der integrierten Hosting-Funktionalität – die
Anwendung kann direkt aus der Entwicklungsumgebung auf den Server übertragen werden.
Zunächst muss hierfür die Publish-Funktion (Rechtsklick auf das Projekt im Solution Explorer
=> Publish) aufgerufen werden (Abbildung 42).
Abbildung 42 Publish-Funktionalität im Kontext-Menü
Daraufhin öffnet sich das Fenster „Publish Web“. Als „Publish Target“ muss „Custom“ gewählt
und im sich nun öffnenden Fenster ein Profilname (hier: AntenneC22) angegeben werden.
Dieses Profil kann für zukünftige Publish-Vorgänge aus Visual Studio heraus verwendet wer-
den. Änderungen an einem einmal angelegten Publish-Profil sind möglich (Abbildung 43).
Abbildung 43 Publish-Profil anlegen
Das Hosting-Profil kann nun um die FTP-Einstellungen erweitert werden – hier kann der zuvor
angelegte projektspezifische FTP-Zugang verwendet werden (Abbildung 44). Die Einstellun-
gen beinhalten
- Server: FTP-Pfad – kann aus 1&1 Control Center ausgelesen werden
- Site path: relativer Pfad zum Root-Pfad des verwendeten FTP-Zugangs (in unserem
Fall wurde der projektspezifische FTP Zugang verwendet, dessen Root-Pfad mit dem
Anwendungspfad übereinstimmen soll)
- User name & Password: FTP-Zugangsdaten
- Destination URL: URL, unter welcher nach erfolgreichem Hosting die Anwendung
aufgerufen werden soll (Angabe ist optional)
Abbildung 44 Konfiguration des FTP-Zugangs in Visual Studio
Ein abschließender Klick auf die Schaltfläche „Publish“ veröffentlicht die ASP.NET Anwendung
über den konfigurierten FTP Zugang. Der Fortschritt sowie der erfolgreiche Abschluss können
über die Visual Studio Konsole verfolgt werden (Abbildung 45).
Abbildung 45 Konsolenausgabe bei erfolgreichem Publish-Vorgang
Zum Abschluss des Hosting-Vorgangs müssen nur noch (einmalig) alle statischen Daten
(HTML-Templates, Konfigurationsskripte, etc.) über einen einfachen FTP-Client in das Anwen-
dungsverzeichnis übertragen werden. Damit wird der Hosting-Vorgang abgeschlossen und die
Server-Anwendung kann gestartet werden (Startadresse im Projekt: http://s689497654.on-
line.de/AntenneC22/ui/selection).
6 Abschlussbetrachtung und Lessons Learned
Zum Abschluss dieser Projektarbeit bleibt in erster Linie festzuhalten, dass die präsentierte
Software-Lösung, bestehend aus ASP.NET-Serveranwendung und CSS/HTML Client mitsamt
JavaScript-Unterstützung, vollumfänglich die gestellten Anforderungen erfüllt. Durch die ge-
wählte Software-Architektur kann eine „beliebig große“ Anzahl (= nur durch die Speicherkapa-
zität des Hosting-Pakets begrenzt) von Studenten den Dienst nutzen. Jeder Anwender kann
somit nur mit einem Webbrowser „bewaffnet“ einen PID-Regler konfigurieren und über eine
Internetverbindung diesen direkt an der bereitgestellten Antennen-Hardware testen.
Größere Schwierigkeiten bei der Umsetzung dieser Projektarbeit bestanden einerseits im Lö-
sen der Probleme in Bezug auf Cross Domain Requests während der Testphase, sowie beim
Hosting des ASP.NET Servers auf dem 1&1 Webserver. Bis dato verfügte kein Projektmitar-
beiter über Expertise in diesen Themenbereichen – so musste sich das gesamte Projektteam
zunächst intensiv mit diesen Themen beschäftigen und die zahlreichen Stolpersteine und Hür-
den während der Umsetzung meistern.
Die Softwarearchitektur der Server-Anwendung wurde so entworfen und umgesetzt, dass spä-
teren Weiterentwicklungen durch zukünftige Studentengruppen nichts im Wege steht. Eine
weitere Nutzungs-Idee, die uns bereits während der Testphase der Projektarbeit kam und wel-
che wir auch zu Testzwecken „quick & dirty“ umgesetzt hatten, besteht in einer Simulations-
Engine. Über eine Simulations-Engine könnten serverseitig diverse Regelstrecken simuliert
werden, für welche jeder Anwender über einen Webbrowser einen Regler konfigurieren und
testen könnte. Diese Engine könnte man um zusätzliche Funktionen erweitern – bspw. das
Aufzeichnen von Sprungantworten. Eine solche Anwendung könnte für zahlreiche studenti-
sche Übungsaufgaben im Bereich der Regelungstechnik eingesetzt werden – bspw. zur Iden-
tifikation unbekannter Regelstrecken.
Im Rahmen der Projektplanung wurden die Arbeitspakete und Aufwände an die einzelnen
Teammitglieder verteilt. Ziel war die Nutzung der jeweiligen Qualifikationen und eine gleich-
mäßige Auslastung aller Teammitglieder unter Berücksichtigung von anderweitigen privaten
und beruflichen Verpflichtungen.
Als Projektmanagement-Methoden kamen unter anderem die Stakeholder-Analyse und die
Risiko-Analyse zum Einsatz. Gegen Projektende wurde festgestellt, dass das Netzteil des
Raspberry PI unterdimensioniert war. Da das Risiko Hardwareausfall im Vorfeld betrachtet
wurde, konnte kurzfristig eine Powerbank eingesetzt werden. Eine dauerhafte Lösung des
Problems wurde durch Einsatz eines ausreichend dimensionierten Ersatznetzteils erreicht.
Die im Projektzeitplan vorgesehene Steuerungsreserve wurde genutzt, um eine negative Aus-
wirkung des Hardware-Problems auf das Projektergebnis zu verhindern.