Das Backend der Smart Indoor Navigation soll nicht nur die Entitäten und Repositories enthalten, sondern auch die Kommunikation mit den beiden Weboberflächen und den Pies ermöglichen. Außerdem soll innerhalb des Backends die Berechnung des schnellsten Laufwegs erfolgen. Dieser Blogpost behandelt aus diesem Grund die Themenblöcke Kommunikation, wie auch Pfadberechnung.

Kommunikation

Zur Implementierung der REST-Schnittstelle in Java bietet Spring eine Vielzahl von Annotationen. Die klassischen REST-Methoden werden beispielsweise durch @GetMapping, @PostMapping oder @PutMapping abgebildet. Bei Post und Put können Daten als String innerhalb der Pfadvariablen (@PathVariable) oder als komplexere Datenstruktur (JSON) im Request Body (@RequestBody) übergeben werden. Da Spring allerdings nicht mit einem Array von JSONs zurechtkommt, müssen die empfangenen Daten, über ein Zwischenobjekt (Wrapper) entgegengenommen werden. Die Funktionalität dieser Methoden wurde mithilfe der Anwendung „Postman“ getestet, damit die spätere Kommunikation mit den beiden Frontends optimal abläuft:

Das Mapping zwischen JSON Format und Java Objekt wird von Spring übernommen, sofern die Namensgebung identisch ist.

Die Kommunikation in Richtung MQTT Broker wurde über Eclipse Paho realisiert. Damit können Daten wie Strings oder JSON Dateien an die jeweilige Topic des MQTT Broker übermittelt werden. Der MQTT Server konnte erreicht werden und testweise die ersten Nachrichten gepublisht werden. Zur Überprüfung der Funktionalität wurde „MQTT.fx“ verwendet:

Pfadberechnung

Innerhalb dieses Themenblocks ist eine mathematische Herangehensweise an die Problemstellung vorteilhaft. Das Ergebnis der Berechnungen im Backend soll die schnellste Route zu einem oder mehreren Artikeln sein. Um dieses Problem zu lösen, wird ein Netz benötigt, dass alle Netzkanten, Wegpunkte und Artikel enthält. Innerhalb des Verwaltungsfrontends geschieht die Pflege dieser Elemente aber separat voneinander und die Laufwege und Positionen von elektronischen Etiketten sind nicht in einem einzigen Netz vereint. Deshalb muss dies mithilfe eines Algorithmus erfolgen.

Dafür muss für jedes elektronische Etikett ein neuer Wegpunkt im Netz der Laufwege eingefügt werden. Somit muss der kürzeste Weg eines Punktes (ESL) zu der nächsten Kante berechnet werden. Jeder Laufweg kann mit einer Funktion f(x) = m*x + r abgebildet werden. Da der kürzeste Weg von einem Punkt zu einer Geraden immer die Orthogonale ist, kann mithilfe des negativen Kehrwert von m eine neue Funktion aufgestellt werden. Der Schnittpunkt beider Funktionen ist der Punkt, an dem ein neuer Punkt im Netz eingefügt werden muss (nur bei kürzester Länge). Die Abbildung zeigt 3 mögliche Orthogonalen (lila), wobei nur ein neuer Punkt eingefügt wird. Dieses Vorgehen muss für alle elektronischen Etiketten wiederholt werden.

Das neu berechnete Netz wird in der Datenbank durch zwei neue Entitäten abgebildet, damit die Einträge des Marktes nicht überschrieben werden und gegebenenfalls eine Überprüfung der Ergebnisse erfolgen kann. Zur weiteren Berechnung des schnellsten Wegs zu einem bestimmten Artikel war der Algorithmus von Dijkstra anfänglich sehr vielversprechend. Dieser kann allerdings leider nur bei einem einzigen Artikel angewandt werden. Werden mehrere Artikel gesucht, spricht man innerhalb von Operations Resarch vom Traveling Salesman Problem. Dieses Optimierungsproblem ist in der Mathematik lange bekannt und soll nun in Java abgebildet werden. Meist werden hierbei alle möglichen Pfade berechnet und sich schlussendlich dann einfach für den Pfad mit geringstem Kantengwicht entschieden. Dieses Vorgehen ist allerdings sehr ressourcenhungrig. Eine Berechnung mithilfe dieser Algorithmen soll innerhalb der nächsten Wochen erfolgen.

Aktueller Stand Backend 05.06.2019