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.