Ortsbasierte Topic-Filterung für die datenzentrierte ... · PDF fileMiddleware ist es, über einen Discovery-Mechanismus passende Publisher und Subscri-ber zu erkennen und ein Abonnement

Hochschule RheinMainFachbereich Design Informatik Medien

Studiengang Informatik

Master-Thesiszur Erlangung des akademischen Grades

Master of Science - M.Sc.

Ortsbasierte Topic-Filterung für die datenzentrierteMiddleware sDDS

vorgelegt von Olga Dedi

am 18. Oktober 2016

Referent: Prof. Dr. Reinhold KrögerKoreferent: Prof. Dr. Martin Gergeleit

II

Erklärung gem. ABPO, Ziff. 6.4.3

Ich versichere, dass ich die Master-Thesis selbstständig verfasst und keine anderen alsdie angegebenen Hilfsmittel benutzt habe.

Ort, Tag. Monat Jahr Vorname Nachname

Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungs-formen dieser Master-Thesis:

Verbreitungsform ja neinEinstellung der Arbeit in dieBibliothek der HochschuleRheinMain

√

Veröffentlichung des Titels derArbeit im Internet

√

Veröffentlichung der Arbeit imInternet

√

Ort, Tag. Monat Jahr Vorname Nachname

III

IV

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen 5

2.1 Lokalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Klassifikation von Lokalisierungsverfahren . . . . . . . . . . . . 5

2.1.2 Global Positioning System . . . . . . . . . . . . . . . . . . . . . 8

2.2 Data Distribution Servic . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Datenzentriertes Publish/Subscribe-Modell . . . . . . . . . . . . 9

2.2.2 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Interaktionsmodell . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Aktueller Stand der Middleware sDDS . . . . . . . . . . . . . . . . . . . 14

2.3.1 Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.3 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.4 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Analyse 19

3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Anwendungsszenarien . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2 Kompatibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.3 Beschränkte Ressourcen . . . . . . . . . . . . . . . . . . . . . . 21

3.1.4 Anforderungsliste . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Repräsentation der Ortsinformationen . . . . . . . . . . . . . . . . . . . 23

3.2.1 Koordinaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1.1 Global Positioning System . . . . . . . . . . . . . . . 24

V

3.2.1.2 Lokales Koordinatensystem . . . . . . . . . . . . . . . 24

3.2.1.3 Designentscheidung . . . . . . . . . . . . . . . . . . . 24

3.2.2 Geometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2.1 Open Geospatial Information Standard . . . . . . . . . 25

3.2.2.2 Eigenes Geometriemodell . . . . . . . . . . . . . . . . 28


3.3 Ortsbasierte Filterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Spezifikation der Filtersyntax . . . . . . . . . . . . . . . . . . . 29

3.3.1.1 OpenGIS - SQL Option . . . . . . . . . . . . . . . . . 29

3.3.1.2 GeoSPARQL . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1.3 CORBA Notification Service - Subscription Filtering . 30


3.3.2 Filterung zur Laufzeit . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.2.1 Empfangsseitige Filterung . . . . . . . . . . . . . . . . 31

3.3.2.2 Senderseitige Filterung . . . . . . . . . . . . . . . . . 32

3.3.2.3 Router-seitige Filterung . . . . . . . . . . . . . . . . . 32

3.3.2.4 Zentrale Filterung . . . . . . . . . . . . . . . . . . . . 36


3.4 Integration in sDDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4.1 Verbreitung der Ortsinformation . . . . . . . . . . . . . . . . . . 37

3.4.1.1 Built-In Topic . . . . . . . . . . . . . . . . . . . . . . 37

3.4.1.2 Topic-unabhängige Verbreitung . . . . . . . . . . . . . 38


3.4.2 Verbinden von Samples mit Ortsinformationen . . . . . . . . . . 38

3.4.2.1 Weiterverarbeitung durch das ContendFilteredTopic . . 39

3.4.2.2 Weiterverarbeitung durch das LocationFilteredTopic . . 39


3.4.3 Umsetzung der Filterung zur Laufzeit . . . . . . . . . . . . . . . 40

3.4.3.1 Aussetzen der Subscription . . . . . . . . . . . . . . . 40

3.4.3.2 Pausieren der Subscription . . . . . . . . . . . . . . . 40


VI

4 Design 43

4.1 Architekturüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Allgemeine sDDS-Erweiterungen . . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Primär- und Sekundärschlüssel . . . . . . . . . . . . . . . . . . . 45

4.2.2 Publikation der Built-In Topics . . . . . . . . . . . . . . . . . . . 45

4.2.3 Discovery Service . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Generische sDDS-Erweiterungen . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1 Ortsinformation und das verwendete Geometriemodell . . . . . . 48

4.3.2 Lokationsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . 50

4.4 Architekturkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.1 LocationBuiltInTopic . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.2 LocationFilteredTopic . . . . . . . . . . . . . . . . . . . . . . . 54

4.4.3 SubscriptionManager . . . . . . . . . . . . . . . . . . . . . . . . 59

4.4.4 ManagementTopic . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.5 Interaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Implementierung 71

5.1 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Allgemeine sDDS-Erweiterungen . . . . . . . . . . . . . . . . . . . . . 72

5.2.1 Primär- und Sekundärschlüssel . . . . . . . . . . . . . . . . . . . 72

5.2.2 Publikation der Built-In Topics . . . . . . . . . . . . . . . . . . . 73

5.2.3 Discovery Service . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Generische sDDS-Erweiterungen: Geometriemodell . . . . . . . . . . . . 74

5.4 Architekturkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.4.1 LocationFilteredTopic . . . . . . . . . . . . . . . . . . . . . . . 76

5.4.2 SubscriptionManager . . . . . . . . . . . . . . . . . . . . 76

5.5 Implementierungsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.5.1 Allgemeine sDDS-Erweiterungen . . . . . . . . . . . . . . . . . 79

5.5.2 Generische sDDS-Erweiterungen . . . . . . . . . . . . . . . . . 80

5.5.3 Architekturkomponenten . . . . . . . . . . . . . . . . . . . . . . 81

5.5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

VII

6 Evaluation 83

6.1 Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.2 Testbett . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.3 Performance-Betrachtung . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.3.1 Analytische Betrachtung der Optimierung . . . . . . . . . . . . . 87

6.3.2 Evaluationsergebnisse . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2.1 Szenario 1 . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3.2.2 Szenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3.2.3 Szenario 3 . . . . . . . . . . . . . . . . . . . . . . . . 94

6.3.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4 Betrachtung qualitativer Kriterien . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 Modularität der Architektur . . . . . . . . . . . . . . . . . . . . 96

6.4.2 Portierung auf andere Plattformen . . . . . . . . . . . . . . . . . 96

6.4.3 Footprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.4.4 Aufwand für Performance-Tests . . . . . . . . . . . . . . . . . . 98

7 Zusammenfassung 101

A Implementierungsaufwand 105

A.1 Allgemeine sDDS-Erweiterungen . . . . . . . . . . . . . . . . . . . . . 105

A.1.1 Primär- und Sekundärschlüssel . . . . . . . . . . . . . . . . . . . 105

A.1.2 Built-In Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.1.3 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.2 Generische sDDS-Erweiterungen . . . . . . . . . . . . . . . . . . . . . . 107

A.2.1 Geometriemodell . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.2.2 Lokationsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . 108

A.3 Architekturkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 109

A.3.1 LocationBuiltInUpdateService . . . . . . . . . . . . . . . . . . . 109

A.3.2 SubscriptionManager . . . . . . . . . . . . . . . . . . . . . . . . 110

A.3.3 ManagementTopic . . . . . . . . . . . . . . . . . . . . . . . . . 111

A.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B Literaturverzeichnis 113

VIII

Abbildungsverzeichnis

2.1 Klassifikation von Messverfahren nach [Ger] . . . . . . . . . . . . . . . 6

2.2 Polarkoordinaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 DDS Überblick des Informationsflusses aus [OMG] . . . . . . . . . . . . 10

2.4 Interaktionsmodell Publisher nach [OMG] . . . . . . . . . . . . . . . . . 13

2.5 Interaktionsmodell Subscriber nach [OMG] . . . . . . . . . . . . . . . . 14

2.6 Klassenmodell des Discovery-Moduls . . . . . . . . . . . . . . . . . . . 16

2.7 Ablauf des Discovery-Mechanismis . . . . . . . . . . . . . . . . . . . . 17

2.8 Klassenmodell der wichtigsten sDDS-Architekturkomponenten . . . . . . 18

3.1 Anwendungsszenario aus dem Smart Home . . . . . . . . . . . . . . . . 20

3.2 Beispiel einen lokalen Koordinatensystems mit Referenzpunkt . . . . . . 25

3.3 OpenGIS-Geometriemodell aus [opeb] . . . . . . . . . . . . . . . . . . . 26

3.4 SDN-Architektur im Überblick aus [Ope13] . . . . . . . . . . . . . . . . 33

3.5 P2P Kommunikation in RPL . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Grobarchitektur der ortsbasierten Topic-Filterung . . . . . . . . . . . . . 44

4.2 Publikationsservice der Built-In Topics . . . . . . . . . . . . . . . . . . . 46

4.3 DiscoveryService-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4 Subscription-Verwaltung durch zugehörige Topics . . . . . . . . . . . . . 48

4.5 Lokales kartesisches Koordinatensystem mit globalem Referenzpunkt . . 49

4.6 Klassenhierarchie des erweiterten OpenGIS-Geometriemodells . . . . . . 50

4.7 Schnittstelle zur Lokalilierung und Tracking von Geräten . . . . . . . . . 51

4.8 Built-In Topic der Lokationsinformationen . . . . . . . . . . . . . . . . . 53

4.9 Empfangen der Lokationsinformation über das Built-In Topic . . . . . . . 53

4.10 Aufbau des LocationFilteredTopic . . . . . . . . . . . . . . . . . . . . . 54

4.11 Zusammen zwischen Topics, DataSink und DataReader . . . . . . . . . . 57

IX

4.12 Zustandsautomat der Filterauswertung . . . . . . . . . . . . . . . . . . . 58

4.13 SubscriptionManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.14 Subscription-Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.15 Grafische Darstellung eines beispielhaften Subscription-Graphs . 62

4.16 ManagementTopic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.17 ManagementTopic Publication-Service . . . . . . . . . . . . . . . . . . . 63

4.18 ManagementTopic Subscription-Service . . . . . . . . . . . . . . . . . . 64

4.19 Anwendungsfall 1 aus Sicht des SubscriptionManagers . . . . . . 65

4.20 Anwendungsfall 1 aus Sicht der Zentralsteuerung . . . . . . . . . . . . . 66

4.21 Anwendungsfall 2 Filterung durch die Zentralsteuerung . . . . . . . . . . 67

4.22 Anwendungsfall 2 aus Sicht des SubscriptionManager . . . . . . . 67

4.23 Anwendungsfall 2 aus Sicht des Staubsaugroboters . . . . . . . . . . . . 68

4.24 Anwendungsfall 4 aus Sicht des Staubsaugroboters . . . . . . . . . . . . 69

5.1 Bitmaske der abgeleiteten geometrischen Objekte . . . . . . . . . . . . . 75

6.1 Grafische Darstellung der Filter aus den drei Szenarien . . . . . . . . . . 84

6.2 Dauer der Ausführung von gettimeofday in 30.000 Iterationen . . . . 90

6.3 Sinnvolle Nutzung der Optimierung durch den SubscriptionManager(Pause 2 Sek) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4 Sinnvolle Nutzung der Optimierung durch den SubscriptionManager(Pause 5 Sek) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.5 Sinnvolle Nutzung der Optimierung durch den SubscriptionManagermit mehreren Subscribern . . . . . . . . . . . . . . . . . . . . . . . . . . 95

X

Tabellenverzeichnis

3.1 OpenGIS Relationsmodell zum Testen räumlicher Relationen zwischengeometrischen Objekten [opeb] . . . . . . . . . . . . . . . . . . . . . . . 27

6.1 Erwartete versendete Nachrichten . . . . . . . . . . . . . . . . . . . . . 89

6.2 Gezählte versendete Nachrichten . . . . . . . . . . . . . . . . . . . . . . 90

6.3 Ausführungszeit der Funktion setFilter in Szenario 1 . . . . . . . . . . . 91

6.4 Ausführungszeit der Funktion evalFilter in Szenario 1 . . . . . . . . . . . 91

6.5 Ausführungszeit bis Subscription-Graph vollständig . . . . . . . . . . . . 92

6.6 Ausführungszeit der Funktion setFilter in Szenario 3 . . . . . . . . . . . 95

6.7 Ausführungszeit der Funktion evalFilter in Szenario 3 . . . . . . . . . . . 96

6.8 Footprint-Betrachtung für die neuen Module . . . . . . . . . . . . . . . . 97

6.9 Footprint-Betrachtung für Rollen . . . . . . . . . . . . . . . . . . . . . . 98

XI

XII

Verzeichnis der Quellcodes

3.1 Geometrieobjekt durch WKT definiert . . . . . . . . . . . . . . . . . . . 294.1 Filtersyntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Filterausdruck Klammerung . . . . . . . . . . . . . . . . . . . . . . . . 565.1 Das Topic Alpha als XML . . . . . . . . . . . . . . . . . . . . . . . . . 725.2 Generierte Datenstruktr des Topics Alpha . . . . . . . . . . . . . . . . . 725.3 Aktivieren des Features Built-In Topics . . . . . . . . . . . . . . . . . . 735.4 Aktivieren des Features Built-In Topics . . . . . . . . . . . . . . . . . . 735.5 XML-Definition eines Vierecks . . . . . . . . . . . . . . . . . . . . . . . 755.6 Ortsfilter für das Topics Alpha . . . . . . . . . . . . . . . . . . . . . . . 765.7 Aufruf des SubscriptionManager-Moduls . . . . . . . . . . . . . . 775.8 Nähere Betrachtung des SubscriptionManager-Moduls am Bei-

spiel der Funktion handleParticipant . . . . . . . . . . . . . . . . 775.9 Nähere Betrachtung der Funktion publishSubscriptionState . . 78

XIII

XIV

Kapitel 1

Einleitung

Durch viele immer kleiner werdende und günstiger erhältliche Hardware wird es mög-lich, immer mehr Alltagsgeräte intelligent zu machen und mit dem Internet zu vernetzen.Etliche dieser Geräte sind mobil und können von Menschen mitgeführt werden, sodass esrelevant wird, die Nutzung und Funktionalität dieser Geräte an ihren aktuellen Standortanzupassen. Die Betrachtung solcher mit dem Internet vernetzter intelligenter Geräte be-zeichnet man als Internet of Things (IoT). IoT hat eine große Überscheidung mit dem Be-reich Smart Home. Dabei handelt es sich um eine Form der Gebäudeautomatisierung, dieinsbesondere darauf abzielt die Wohnqualität zu erhöhen und den Verbrauch zu senken.Dafür werden Teile des Hauses und darin befindliche Geräte untereinander und gegebe-nenfalls mit dem Internet vernetzt. Somit wäre ein Anwendungsfall denkbar, bei welchembeispielsweise eine Fernbedienung immer nur die Lampen ein- und ausschaltet, mit denensie sich im selben Raum befindet.

IoT befasst sich mit vernetzten intelligenten Geräten. Bei der Entwicklung solcher Geräteist es oft wünschenswert, den Fokus auf die Funktionalität zu legen und für die Problem-stellung der Kommunikation eine Middleware als Lösung zu verwenden. Data Distributi-

on Service (DDS) ist ein von der Object Management Group (OMG) herausgegebenerStandard für eine datenzentrierte Publish/Subscribe-Middleware, die eine zuverlässigeund echtzeitfähige Datenübertragung ermöglicht. Dafür werden Daten auf einem Topic

durch Publisher publiziert und können von Subscribern durch das Abonnieren des Topicsempfangen werden. Die Aufgabe der Middleware ist es den Transport richtig zugeordne-ter Daten zu garantieren. Die zwei vollständigsten und verbreitetsten Implementierungendes DDS-Standards stammen von den Firmen RTI und PrismTech. Beide Implementie-rungen skalieren sehr gut für eine große Anzahl von Geräten und eigenen sich durchdiese Eigenschaft zusätzlich für den Einsatz im Bereich Internet of Things, jedoch lassen

1

Kapitel 1. Einleitung

sie sich aufgrund ihrer umfangreichen Funktionalität nicht auf eingebetteten Geräten mitbeschränkten Ressourcen einsetzen. Zur Nutzung einer DDS-Middleware auf resourcen-beschränkten Geräten wurde im Labor für verteilte Systeme der Hochschule RheinMaindie Middleware sensor Data Distribution Service (sDDS) entwickelt, die eine Teilmengedes DDS-Standards implementiert.

Die Master-Thesis ist in das Forschungsprojekt sDDS 4 Smart Home eingebettet, wel-ches in Kooperation mit der Hochschule Darmstadt durchgeführt wird und den Einsatzvon sDDS im Bereich Smart Home evaluieren soll. Ziel der Master-Thesis ist es Subs-cribern zu ermöglichen die Daten eines Topics anhand ihres Entstehungsortes zu filtern(„ortsbasierte Topic-Filterung”). Die Filterung soll zur Laufzeit erfolgen und somit auchden Standortwechsel mobiler Knoten berücksichtigen. Als Teil des Forschungsprojektessoll die Problemstellung der Master-Thesis insbesondere für den Bereich Smart Home

betrachtet werden. Zur Umsetzung einer ortsbasierten Topic-Filterung müssen dabei fol-gende Problemfelder betrachtet werden:

• Für die Umsetzung einer ortsbasierten Topic-Filterung muss ein Konzept zur Defi-nition und Verwendung von Ortsinformationen und zur Formulierung eines ortsba-sierten Filters entwickelt werden.

• Die Master-Thesis soll Möglichkeiten untersuchen, den Datenverkehr durch die Fil-terung zu optimieren.

• Der DDS-Standard spezifiziert eine einheitliche Schnittstelle, wodurch die Imple-mentierungen API-kompatibel zueinander sind. Für die ortsbasierte Topic-Filterungsoll analysiert werden inwiefern eine durch den Standard nicht spezifizierte Funk-tionalität vollständig oder teilweise API-kompatibel umgesetzt werden kann.

• Um auf ressourcenbeschränkter Hardware laufen zu können, wird die Gesamtfunk-tionalität des DDS-Standards in sDDS modularisiert umgesetzt. Dadurch wird esmöglich nur die benötigten Module zu nutzen und so für jedes Gerät eine individu-elle Firmware zu erzeugen. Um die ortsbasierte Topic-Filterung auch auf ressour-cenbeschränkter Hardware nutzen zu können, muss das Konzept der Modularisie-rung in diese Erweiterung einfließen.

• Für die Verwendung ressourcenbeschränkter Hardware ist neben der Modularisie-rung auch ein sparsamer Umgang mit Arbeitsspeicher und Rechenzeit notwendig.Somit muss die Architektur mit Blick auch auf diese Einschränkungen konzipiertund implementiert werden.

2


• sDDS unterstützt bereits eine Reihe verschiedener Plattformen und ermöglicht eineschnelle Portierung. Dafür wird plattformspezifischer Code durch eine Abstrakti-onsschicht gekapselt, wodurch klare Schnittstellen bereitgestellt werden, die einePortierung erleichtern. Die ortsbasierte Topic-Filterung soll genauso einfach por-tiert werden können wie die bisherigen Module.

• Die Architektur und ihre Implementierung sollen nach qualitativen und quantitati-ven Merkmalen evaluiert werden. Dafür sollen Szenarien aus dem Bereich SmartHome betrachtet werden, sodass die Evaluationsergebnisse in das Forschungspro-jekt mit einfließen können.

Im Anschluss folgt das zweite Kapitel mit Grundlageninhalten, um eine Wissensbasisüber benötigte Technologien und Konzepte zu schaffen. Kapitel 3 analysiert die Pro-blemstellung und stellt verschiedene Lösungsansätze vor, die in einem Architekturentwurfmünden. Dieser wird in Kapitel 4 für jede Komponente im Detail erklärt. Es folgt in Kapi-tel 5 eine Beschreibung der Implementierung, welche Besonderheiten und grundlegendeVorgehensweisen vorstellt sowie einen Überblick über den Aufwand gibt. Anschließendwird in Kapitel 6 die sDDS-Erweiterung nach quantitativen und qualitativen Merkmalenevaluiert. Kapitel 7 schließt die Arbeit mit einer Zusammenfassung und einem Ausblickauf die mögliche Weiterentwicklung und den Einsatz der sDDS-Erweiterung ab.

3


4

Kapitel 2

Grundlagen

Das Grundlagenkapitel soll die nötige Wissensbasis schaffen, um die in der Analyse be-trachteten Probleme besser einordnen zu können. Die weiteren Abschnitte befassen sichmit den Themen Lokalisierung, dem Data Distribution Standard-Standard und dem Standder Middleware sDDS.

2.1 Lokalisierung

Dieser Abschnitt befasst sich mit der Lokalisierung, d.h. der Bestimmung und Beschrei-bung des Aufenthaltsortes von Objekten. Die Durchführung geeigneter Lokalisierungs-verfahren ist nicht Teil der Master-Thesis, stattdessen wird eine Schnittstelle, welche dienötigen Daten bereitstellt, vorausgesetzt. Zunächst sollen bekannte Lokalisierungsverfah-ren klassifiziert werden, um einen Überblick zu schaffen und anschließend Global Po-

sitioning System als ein Verfahren näher erläutert werden. Die folgenden Informationenstammen aus [Ger], [CCPL] und [San].

2.1.1 Klassifikation von Lokalisierungsverfahren

Zunächst lassen sich Lokalisierungsverfahren in die Kategorien client- und infrastruktur-basiert aufteilen. Clientbasierte Lokalisierung ermöglicht es einem Objekt, seine eigenePosition zu bestimmen, wohingegen bei der infrastrukturbasierten Lokalisierung die Auf-gabe von der Infrastruktur übernommen wird und durch diese die Positionsinformationbezogen werden kann. Die weitere Unterteilung, wie sie der Abbildung 2.1 entnommenwerden kann, bezieht sich auf das verwendete Mess- und Auswertungsverfahren. Dabei

5

2.1. Lokalisierung Kapitel 2. Grundlagen

unterscheidet man zwischen der Distanzmessung, der Richtungsmessung und der Nach-barbestimmung.

Abbildung 2.1: Klassifikation von Messverfahren nach [Ger]

Die Distanzmessung erlaubt wiederum zwei unterschiedliche Verfahren. Eine Möglich-keit ist es, die Signalstärke zu messen, und dadurch die sogenannte Received Signal

Strength Indication (RSSI) zu bestimmen, welche die gemessene Spannung des emp-fangenen Signals darstellt [San, PAK+05]. Eine wichtige Voraussetzung dafür ist, dasseinige Objekte, die ihre Position kennen (Beacons) bereits existieren. Dabei kann es sichbeispielsweise um stationäre Objekte handeln. Bei der Kommunikation mit den Beaconskann durch den RSSI-Wert eines empfangenen Signals die Entfernung zum Beacon be-stimmt werden. Für die Positionsbestimmung im zweidimensionalen Raum wird die Ent-fernung zu mindestens drei Beacons benötigt. In Wireless-Netzwerken ist die Lokalisie-rung über den RSSI-Wert eine günstige Methode, da keine zusätzliche Hardware nebendem Radio-Transceiver benötigt wird und zudem keine speziellen Nachrichten für die Po-sitionsbestimmung versendet werden müssen. Die Entfernungsmessung über den RSSI-Wert hat jedoch eine Fehlerwahrscheinlichkeit von ±50% [San, SRL02] und ist damitnicht besonders genau. Die hohe Fehlerwahrscheinlichkeit wird durch große Hindernissewie z.B. Vegetation, Wände oder Möbel verursacht, da sie die Ausbreitung des Signalsstören können und dadurch starke Schwankungen in der Signalstärke verursachen. DieserEffekt wird Shadowing bezeichnet. Für sie Distanzbestimmung ist es wichtig das Pfad-verlustmodell sowie den Pfadverlustkoeffizienten des Signals zu kennen, um aus demRSSI-Wert die Distanz berechnen zu können [San].

Eine weitere Möglichkeit der Distanzmessung geschieht über die Signallaufzeit. Zur Be-rechnung dieser werden ebenfalls Beacons mit einer bekannten Position benötigt. Dabei

6

Kapitel 2. Grundlagen 2.1. Lokalisierung

gibt es drei verschiedene Methoden, die Laufzeit eines Signals zu messen. Dies kann mitden Verfahren Time of Arrival (ToA), Time Difference of Arrival (TDoA) oder Timing Ad-

vance (TA) bestimmt werden. Der Vorteil der Distanzbestimmung über die Signallaufzeitist, dass die Messung im Vergleich zur Signalstärke viel weniger fehleranfällig ist. DieGenauigkeit der Messung hängt von der Präzision der verwendeten Zeitbasis ab. Dadurchwird dieses Verfahren im Vergleich zur Messung der Signalstärke aufwändiger und teuer.

Time of ArrivalTime of Arrival definiert den Zeitpunkt, an dem ein Signal eintrifft. Voraussetzungist eine gemeinsame Zeitbasis, die stets synchron gehalten werden muss, sowieKenntnis über den genauen Sendezeitpunkt.

Time Difference of ArrivalTime Difference of Arrival definiert die Differenz der Ankunftszeit zweier empfan-gener Signale. Dafür werden Signale mit unterschiedlichen Ausbreitungsgeschwin-digkeiten verwendet, wie beispeilsweise Licht und Schall. Durch die Annahme,dass das Licht quasi sofort da ist, kann durch die Ausbreitungsgeschwindigkeit desSchalls die Entfernung bestimmt werden.

Timing AdvanceTiming Advance wird häufig in Netzwerken eingesetzt, die eine geslottete Übertra-gung nutzen. Diese Technik wird genutzt, um je nach Entfernung des Empfängersden Sendeburst vorverlegen zu können und somit sicherzustellen, dass die Nach-richten noch innerhalb des dafür vorgesehenen Slots ankommen. Timing Advancesetzt darauf auf, dass die Distanz zwischen Sender und Empfänger bekannt ist, umden Sendezeitpunkt korrekt berechnen zu können.

Neben der Distanzmessung zwischen Sender und Empfänger gibt es auch die Möglichkeitdie Richtung eines Signals zu messen. Dafür wird der Einfallswinkel des empfangenenSignals, Angle of Arrival (AoA), gemessen. Wie bei der Distanzmessung werden auchhier drei bekannte Punkte benötigt. Diese Methode benötigt jedoch zusätzlich Hardware,da der Einfallswinkel nicht über de Radio-Trasceiver gemessen werden kann. Das drittein Abbildung 2.1 dargestellten Messverfahren nutzt die Bestimmung der Nachbarn. Da-für wird ein Bereich in mehrere Zellen unterteilt, die über eine ID eindeutig identifiziertwerden können. Bei dem Verfahren Cell of Origin (CoO) werden die IDs der Nachbar-zellen empfangen. Durch die Identifikation der unmittelbaren Nachbarn, ist es möglichdie eigene Zelle zu bestimmen. Der Vorteil dieser Methode ist, dass keine weitere Hard-ware benötigt wird und die Genauigkeit über die gewählte Zellgröße bestimmt werden

7

2.2. Data Distribution Servic Kapitel 2. Grundlagen

kann. Jedoch gibt es eine natürliche Grenze wie klein eine Zelle gewählt werden kann,sodass beispielsweise niemals die gleiche Genauigkeit wie bei der Signallaufzeit erzieltwerden kann. Weiterhin ist der Bereich, in dem eine Lokalisierung möglich ist, auf diegekennzeichneten Zellen beschränkt.

2.1.2 Global Positioning System

Global Positioning System (GPS) ist ein Lokalisierungsverfahren, das seinen Nutzern er-möglicht die Distanz zwischen dem Nutzer am Boden und im Orbit befindlichen Satel-liten über eine Signallaufzeitmessung (ToA) zu bestimmen und anhand dieser Distanzendie Position zu bestimmen. Das NAVSTAR-GPS hat dafür 24 Satelliten auf insgesamtsechs Orbits [Ger], wobei jeder Satellit einen eigenen Code besitzt. Ein Empfänger kenntdie Codes aller Satelliten und kann bis zu 12 verschiedene Codes gleichzeitig empfangen.Ein Satellit übermittelt den aktuellen Orbit, um seine Position bekannt zu machen, sowieden Sendezeitpunkt zur Berechnung der Signallaufzeit. Es werden mindestens vier Satel-liten benötigt, da hierbei eine Positionsbestimmung im dreidimensionalen Raum erfolgt[Ger].

Die Position eines Objektes wird in Polarkoordinaten angegeben (vgl. Abb. 2.2). Dieseumfassen den gesamten Globus und werden in Grad (°), Bogenminuten (’) und Bogense-kunden (”) angegeben. Der Breitengrad wird auch Latitude genannt und verläuft von 90°bis -90° um den Globus; der Längengrad, auch Longitude genannt, verläuft von 180° bis-180° zwischen den beiden Polen, wobei 0° als Nullmeridian bezeichnet wird. Wie aufAbbildung 2.2 zu sehen ist, wird der Abstand zwischen zwei Längengraden zu den Polenschmaler, wohingegen der Abstand zwischen zwei Breitengraden immer konstant bleibt.Die einzige Ausnahme bildet der Äquator, wo der Abstand zwischen den Längen- undBreitengraden identisch ist.

2.2 Data Distribution Servic

Data Distribution Service (DDS) ist ein durch die Object Management Group (OMG) spe-zifiziert Standard. zur Umsetzung einer datenzentrierten Publish/Subscribe-Middleware,die sich besonders durch ihre zuverlässige und echtzeitfähige Kommunikation auszeich-net [OMG]. Um eine robuste und effiziente Übertragung gewährleisten zu können, wer-den durch den Standard mehrere Quality-of-Service-Merkmale (QoS) definiert, welcheden Grad der benötigten Übertragungsqualität beschreiben und ja nach bedarf aktiviert

8

Kapitel 2. Grundlagen 2.2. Data Distribution Servic

Abbildung 2.2: Polarkoordinaten

werden können. Die folgende Information ist dem DDS-Standard in der vierten Versionentnommen [OMG].

2.2.1 Datenzentriertes Publish/Subscribe-Modell

Das datenzentrierte Publish/Subscribe-Modell basiert auf dem Konzept des globalen Da-

tenraums. Dieser steht allen Anwendungen zur Verfügung und bietet den Anwendungen,welche Informationen bereitstellen wollen, die Möglichkeit diese im globalen Datenraumzu veröffentlichen und somit als Publisher zu agieren. Anwendungen, die Zugriff auf dieDaten wollen, können sich als Subscriber anmelden. Dafür muss ein Abonnement (Sub-scription) zwischen dem Publisher und Subscriber aufgebaut werden. Die Aufgabe derMiddleware ist es, über einen Discovery-Mechanismus passende Publisher und Subscri-ber zu erkennen und ein Abonnement zwischen diesen aufzubauen, damit die von Publis-hern publizierten Daten an alle interessierten Subscriber weitergeleitet werden können.

Einem jeden datenzentrierten Publish/Subscribe-System unterliegt ein Datenmodell, dasden globalen Datenraum definiert und spezifiziert, wie Publisher und Subscriber auf die-sen zugreifen können. Dabei kann das Datenmodell eine Menge voneinander unabhängi-ger Datenstrukturen sein, die jeweils durch ein Topic und einen Typ identifiziert werden.Das Topic verfügt über eine einzigartige Kennung, die Daten-Samples im globalen Daten-raum innerhalb einer Domäne durch einen Primärschlüssel eindeutig identifizieren kann.Der Typ gibt Informationen über die Struktur der Daten.

9


Abbildung 2.3: DDS Überblick des Informationsflusses aus [OMG]

Abbildung 2.3 stellt einen Überblick über den Informationsfluss in DDS dar. Auf derSenderseite befinden sich Publisher und DataWriter, auf der Empfängerseite Subscriberund DataReader. Der Publisher ist für die Verbreitung von Daten verantwortlich und kannDaten-Samples unterschiedlicher Typen publizieren. Ein DataWriter ermöglicht das ty-pisierte Schreiben der Daten und muss von der Anwendung genutzt werden, um Datenan den Publisher zu übertragen. Ein Subscriber ist hingegen dafür verantwortlich, Datenentgegenzunehmen. Um die durch den Subscriber empfangenen Daten zu erhalten, mussdie Anwendung über einen typisierten DataReader darauf zugreifen. Die Typisierung desDataReaders und des DataWriters erfolgt über die Zuordnung eines Topics. TypisierteDaten eines Topics werden hier als Sample bezeichnet.

Neben Topics, die reine Applikationsdaten definieren und diese im globalen Datenraumidentifizieren, gibt es drei weitere Topic-Arten. Dabei handelt es sich um Content-

FilteredTopics, MultiTopics und Built-In Topics.

ContentFilteredTopic

Das ContentFilteredTopic ermöglicht es einem Subscriber ein Topic gefiltert zuabonnieren. Der Subscriber kann einen inhaltlichen Filter angeben, um nur noch relevanteDaten zu erhalten, anstatt alle Daten, die auf dem Topic publiziert werden. Die inhaltlicheEinschränkung wird dabei über einen Filterausdruck spezifiziert. Dieser hat Ähnlichkeitmit dem WHERE-Teil einer SQL-Query.

10


MultiTopic

Das MultiTopic ermöglicht es, Daten von mehreren unterschiedlichen Topics zu kom-binieren, zu filtern, neu anzuordnen und diese Daten als neuen, abgeleiteten Datentypzu abonnieren. Dies kann von der Applikation durch den Subscription-Ausdruck spezi-fiziert werden. Es handelt sich dabei um einen String, der die Auswahl und Neuanord-nung der Daten aus den beteiligten Topics spezifiziert. Der Ausdruck ähnelt einer SQL-Query, wobei der SELECT-Teil die relevanten Felder angibt und der FROM-Teil die To-pics, die nach den Feldern durchsucht werden sollen. Der WHERE-Teil verweist wie beimContentFilteredTopic auf den inhaltlichen Filter. Mehrere Topics werden übereinen NATURAL JOIN kombiniert. Diese Topics können unterschiedliche Datentypenhaben, jedoch müssen die Felder, die für den NATURAL JOIN genutzt werden, vomgleichen Typ sein.

Built-In Topic

Eine Aufgabe der Middleware ist es, neue Teilnehmer im Netzwerk zu erkennen und ihrenStatus zu verfolgen. Diese Information kann jedoch nicht nur für die Middleware sondernauch für die Applikation relevant sein. Um diese Information zugänglich zu machen, wirdeine Menge von Built-In Topics spezifiziert, die von der Middleware und Anwendungengenutzt werden können. Dadurch kann auf diese Information wie auf normale Appli-kationsdaten zugegriffen werden, ohne eine neue Schnittstelle einführen zu müssen. Eswerden durch den Standard folgende Built-In Topics definiert:

DCPSParticipantAuf dem DCPSParticipant Topic wird ein Eintrag publiziert, sobald ein neuer Teil-nehmer das Netzwerk betritt. Der Eintrag enthält einen Primärschlüssel und Infor-mationen zu den QoS-Merkmalen des Domain Participants.

DCPSTopicEin Eintrag wird auf dem DCPSTopic Topic publiziert, sobald ein Topic Objekterzeugt wurde. der Eintrag enthält neben dem Primärschlüssel, den Namen und Typdes Topics, sowie Informationen zu den QoS-Merkmalen.

DCPSPublicationAuf dem DCPSPublication Topic wird ein Eintrag publiziert, wenn ein DataWriterfür einen zugeordneten Publisher erzeugt wird. Der Eintrag beinhaltet den Primär-schlüssel, den Schlüssel des Teilnehmers, dem der DataWriter gehört, Namen undTyp des Topics sowie Informationen über seine QoS-Merkmale.

11


DCPSSubscriptionAuf dem DCPSSubscription Topic wird ein Eintrag publiziert, sobald ein Data-Reader für einen zugeordneten Subscriber erstellt wird. Das Topic hat die gleicheStruktur wie das DCPSPublication Topic.

2.2.2 Quality of Service

Quality of Service beschreibt die Dienstgüte der Kommunikation und setzt sich aus ver-schiedenen QoS-Policies zusammen, die verschiedene QoS-Merkmale zusammenfassen.Ein QoS-Merkmal wird dabei dem DomainParticipant, DataReader, DataWriter, Topic,Publisher, oder Subscriber zugeordnet. Um eine effiziente Kommunikation zu ermögli-chen, müssen die QoS-Policies auf Sende- und Empfangsseite kompatibel sein. Dafürwird angenommen, dass der Subscriber bestimmte QoS-Merkmale fordern kann und derPublisher diese anbietet. Nur wenn die geforderten und angebotenen QoS-Merkmale zu-einander passen, wird eine Subscription von der Middleware zugelassen. Der Standarddefiniert insgesamt 22 QoS-Merkmale, von denen drei genauer betrachtet werden, dieauch in der Middleware sDDS umgesetzt sind. Weitere QoS-Merkmale können im Stan-dard [OMG] im Detail nachgelesen werden.

HistoryDas QoS-Merkmal History bestimmt, wie nicht abgerufene Daten-Samples gespei-chert und nachträglich verändert werden. Dabei lässt sich das Merkmal für Data-Reader und DataWriter unterschiedlich einstellen.

Latency BudgetDas QoS-Merkmal Latency Budget beschreibt die maximale erlaube Verzögerung,die zwischen dem Erzeugen und dem Empfangen eines Daten-Samples vergehendarf. Dabei handelt es sich jedoch nur für eine Richtlinie, die der Middleware dieMöglichkeit einer Optimierung bietet.

ReliabilityDas QoS-Merkmal Reliability legt eine zuverlässige Übertragung fest. Dabei kannzwischen den beiden Varianten Best Effort und Reliable gewählt werden.

2.2.3 Interaktionsmodell

Abbildung 2.4 zeigt das Interaktionsmodell aus Sicht eines Publishers. Der Ablauf zeigt,dass der DomainParticipant auf Anfrage der Applikation einen Publisher erzeugt.

12


Anschließend muss ein Topic erzeugt werden. Die Erzeugung des Topics muss nicht zwin-gend von der Applikation angestoßen werden, sondern kann auch durch andere Teilneh-mer erfolgen. Doch erst wenn das Topic existiert, kann der Publisher den dazugehörigenDataWriter erzeugen. Nach Abschluss der Generierungsphase veröffentlicht die Applika-tion ein neues Sample über den DataWriter, der die Daten dem Publisher zur Verfü-gung stellt, der dann für ihre Verteilung sorgt. Weiterhin ist es möglich, das Publizierenanzuhalten. Die Applikation kann zwar weiterhin neue Einträge schreiben, jedoch werdendie Daten erst dann veröffentlicht, wenn der Publisher wieder aktiviert wird.

Abbildung 2.4: Interaktionsmodell Publisher nach [OMG]

Abbildung 2.5 zeigt das Interaktionsmodell von Subscriber-Seite. Hierfür wird zunächstein Subscriber durch den DomainParticipant erzeugt. Anschließend gibt es zweiMöglichkeiten einen Listener zum Lesen der Daten zu setzen. Die Applikation kanneinen SubscriptionListener erzeugen und diesen am Subscriber registrieren. EinSubscriptionListener wird für alle DataReader eines Subscribers aufgerufensobald ein neues Sample verfügbar ist. Wohingegen ein DataReaderListener nuran einem bestimmten DataReader registriert wird. Sobald ein neues Sample verfügbarist, werden die DataReaderListener nur für die registrierten DataReader aufge-

13

2.3. Aktueller Stand der Middleware sDDS Kapitel 2. Grundlagen

rufen.

Abbildung 2.5: Interaktionsmodell Subscriber nach [OMG]

2.3 Aktueller Stand der Middleware sDDS

Die Middleware sDDS wird im Labor für Verteilte Systeme der Hochschule RheinMainentwickelt und implementiert eine Teilmenge des DDS-Standards. Dabei ist die Imple-mentierung insbesondere für den Einsatz auf ressourcenarmen eingebetteten Systemengedacht [Bec10]. Da sDDS nur eine Teilmenge des Standards implementiert, sind bisherlediglich die Quality of Service Merkmale History, Latency Budget und Reliability umge-setzt. Die weiteren Abschnitte erläutern das verwendete Konzept der Modularisierung, dieUmsetzung allgemeiner Topics und Built-In Topics, den Discovery-Mechanismus sowieeinem Architekturüberblick.

14

Kapitel 2. Grundlagen 2.3. Aktueller Stand der Middleware sDDS

2.3.1 Modularisierung

Um eine derart komplexe Middleware für ressourcenarme Geräte umsetzen zu können,wird die Funktionalität der Middleware modularisiert und damit die Möglichkeit geschaf-fen, für verschiedene Geräte eine individuelle Firmware zu erzeugen, die nur die Moduleverwendet, die von der Rolle des Gerätes benötigt werden [Bec10]. Dies geschieht durchbedingte Kompilierung (über #define und #ifdef) mit deren Hilfe Codesegmenteein- und ausgeschaltet werden können. Als eine weitere Maßnahme verzichtet sDDS aufeine dynamische Speicherverwaltung. Der benötigte Arbeitsspeicher wird statisch allo-kiert und durch die Middleware verwaltet, sodass der benötigte Speicherplatz bereits zurCompile-Zeit berechnet werden kann.

2.3.2 Topics

Als Teil des Datenmodells identifiziert das Topic eine Datenstruktur im globalen Daten-raum und kann diese mit einem Typ verbinden. Dafür wird das Datenmodell des Topicsals XML-Datei definiert und durch Codegenerierung die typisierten Instanzen des Topicsund des DateReaders und DataWriters erzeugt, mit deren Hilfe auf die Daten-struktur zugegriffen werden kann [sdd]. Der DDS-Standard sieht Primärschlüssel vor, umDaten-Samples eindeutig zu identifizieren. Das Konzept der Schlüssel ist in sDDS jedochnicht umgesetzt, sodass es keine Möglichkeit gibt Samples zu überschreiben.

Neben der Möglichkeit Topics mit beliebiger Datenstruktur anzulegen implementiertsDDS auch die vier durch den Standard definierten Built-In Topics: DCPSParticipant,DCPSTopic,DCPSPublication und DCPSSubscription. ContentFiltered-Topics und MiltiTopics werden bisher noch nicht unterstützt.

2.3.3 Discovery

Der Discovery-Mechanismus setzt ein Discovery-Protokoll basierend auf den übertrage-nen Built-In Topics ein; diese werden über Multicast verschickt. Jedoch ist Multicast aktu-ell nur für IPv6 [sdd] implementiert.In seiner aktuellen Implementierung ermöglicht dasDiscovery-Protokoll lediglich, Abonnements zu erstellen, diese aber nicht wieder zu kün-digen. Abbildung 2.6 zeigt den Aufbau des Discovery-Moduls. Derzeit wird auch keineInformation zu den Topics ausgetauscht, sodass das DCPSTopic Topic nicht verwendetwird. Bekannte Teilnehmer werden zur Übersicht in einer Liste gespeichert, wofür esdie Funktion handleParticipant und die Hilfsfunktion addParticipant gibt.

15


Zum Senden und Empfangen der drei verwendeten Built-In Topics werden entsprechendesend- und receive-Funktionen bereitgestellt.

Abbildung 2.6: Klassenmodell des Discovery-Moduls

Abbildung 2.7 zeigt den Ablauf des Discovery-Vorgangs. Dieser gliedert sich in zwei Tei-le, dem zyklischen Verschicken von Samples auf dem Participant Topic und dem Publica-ton Topic sowie dem zyklischen Pollen der Daten. Wird ein Participant Sample empfan-gen, trägt das Discovery-Modul den Teilnehmer, wenn es sich um einen neuen Teilnehmerhandelt, in seine Liste ein. Wenn ein Publication Sample empfangen wird und es sich da-bei um einen Subscriber für das angebotene Topic handelt, sendet das Discovery-Modulein Subscription Sample ab, welches die Adresse, an die Daten für dieses Abonnementgeschickt werden sollen, mitsendet. Wird ein Subscription Sample empfangen und derTeilnehmer ist ein Publisher für dieses Topic, wird die mitgeschickte Adresse in der Listeder Subscriber am Topic registriert.

2.3.4 Architektur

Abbildung 2.8 zeigt die Kernkomponenten der Middleware als Klassenmodell. Die Klas-se Topic steht dabei im Mittelpunkt und ermöglicht den Zugriff auf die Datenstrukturder Samples. Um den typisierten Zugriff auf die Daten zu ermöglichen, wird das Topicvon DataReader und DataWriter referenziert. Die DataSink-Klasse verwaltet al-

16

Kapitel 2. Grundlagen 2.3. Aktueller Stand der Middleware sDDS

Abbildung 2.7: Ablauf des Discovery-Mechanismis

le existierende DataReader und ist die zentrale Stelle, in der alle Samples ankommenund von dort an die jeweiligen DataReader verteilt werden. Die DataSource ver-waltet alle existierenden DataWriter und ist die zentrale Stelle für alle ausgehendenDaten. Dafür ruft sie den für das Topic passenden DataWriter auf, über welchen die Datenpubliziert werden.

17


Abbildung 2.8: Klassenmodell der wichtigsten sDDS-Architekturkomponenten

18

Kapitel 3

Analyse

Das Analysekapitel befasst sich zunächst mit den Anforderungen an die in der Thesis zuentwickelnde sDDS-Erweiterung, die im weiteren Vorgehen in gemeinsame Problemfel-der zusammengefasst werden, und für die in den folgenden Abschnitten mögliche Lösun-gen betrachtet werden.

3.1 Anforderungen

In diesem Abschnitt werden alle Anforderungen an die zu entwickelnde sDDS-Erwei-terung zusammengetragen. Dafür sollen zunächst drei Anwendungsszenarien betrachtetwerden, die es ermöglichen, Anforderungen aus Nutzersicht und aus technischer Sicht zudefinieren.

3.1.1 Anwendungsszenarien

Für den Einsatz einer ortsbasierten Topic-Filterung sind viele Szenarien aus den Be-reichen Internet der Dinge und Industrie 4.0 denkbar. Die hier betrachteten Szenarienlassen sich in den Smart Home Kontext eingliedern. Betrachtet wird zu diesem Zweckdie in Abbildung 3.1 dargestellte Wohnung, die mit vier festen Temperatursensoren undeinem mobilen Staubsaugroboter ausgestattet ist. Jeder Temperatursensor publiziert aufdem Temperatur-Topic seine Werte, wohingegen der Staubsaugroboter auf dem Status-Topic Daten publiziert. Eine Zentralsteuerung ermöglicht es den Bewohnern alle Gerätedes Smart Home zu verwalten und einzustellen. Dafür abonniert die Zentralsteuerung alsSubscriber die Geräte-Topics.

19

3.1. Anforderungen Kapitel 3. Analyse

Abbildung 3.1: Anwendungsszenario aus dem Smart Home

Basierend auf diesen Voraussetzungen sollen nun die folgenden drei Szenarien betrachtetwerden:

Szenario 1

Jeder Temperatursensor publiziere auf demselben Topic. Die Zentralsteuerung abonniertdas Temperatur-Topic mit der Filtervorgabe, dass nur Samples aus dem Badezimmer ge-lesen werden sollen. Weiterhin soll es möglich sein, den Filter zu ändern und das Abon-nement beispielsweise auf ein anderes Zimmer zu beschränken.

Szenario 2

Hier wird das erste Szenario so erweitert, dass die Zentralsteuerung den Filter des Abon-nements auf dem Temperatur-Topic nicht ändern muss, da sie für das Abonnement mehre-re verschiedene Filter festlegt. Insgesamt werden fünf Filter festgelegt, je einer für jedenin Abb. 3.1 dargestellten Raum.

Szenario 3

Dieses Szenario betrachtet die Nutzung eines Staubsaugroboters, der seinen aktuellenStatus auf dem Status-Topic publiziert. Publikationen erfolgen dabei sehr sehr häufig und

20

Kapitel 3. Analyse 3.1. Anforderungen

mit sehr viele Statusinformationen, die hauptsächlich für seine Basisstation relevant sind.Die Zentralsteuerung will nun erkennen, ob der Staubsaugroboter feststeckt, um einenBewohner alarmieren zu können. Erfahrungsgemäß bleibt der Staubsaugroboter an demÜbergang zum Teppichboden im Wohnzimmer hängen, sodass ein Feststecken zwischendem Wohnzimmer und den angrenzenden Zimmern besonders wahrscheinlich ist. Dafürabonniert die Zentralsteuerung das Status-Topic mit dem Filter, dass der Staubsaugroboterzwischen dem Wohnzimmer und dem Flur oder zwischen dem Wohnzimmer und derKüche ist.

3.1.2 Kompatibilität

sDDS ist eine Implementierung des DDS-Standards der OMG. Die ortsbasierte Topic-Filterung ist im Standard nicht vorgesehen und soll somit eine reine sDDS-Erweiterungwerden. Diese Erweiterung soll mit den bestehenden Strukturen der Middleware sDDSsowie mit dem DDS-Standard kompatibel sein. Dazu gehört, dass bestehende Strukturenund Mechanismen genutzt werden und die Benutzung der Erweiterung mit der bisherigenBenutzung von sDDS bzw. DDS kompatibel ist. Sofern Strukturen und Schnittstellen, diebisher noch nicht durch den Standard oder die sDDS-Implementierung umgesetzt sind,benötigt werden, sollen sich diese gut in die bestehenden Paradigmen eingliedern lassen.

3.1.3 Beschränkte Ressourcen

Die hauptsächliche Zielplattform für sDDS stellen Wireless-Sensorknoten dar, welcheüber begrenzte Ressourcen verfügen. So muss bei der Konzeption der Erweiterung Rück-sicht auf einen geringen RAM- und Flashspeicherverbrauch sowie eine geringe Rechen-leistung genommen werden. Die bisher kleinste unterstützte Plattform ist ein ATme-

ga128RFA1 der Firma Atmel. Dabei handelt es sich um einen 8-Bit-Mikrokontroller mit128 KB Flash und 4 KB RAM. Die ortsbasierte Topic-Filterung soll auch von den kleinenPlattformen unterstützt werden.

3.1.4 Anforderungsliste

Aus den soeben betrachteten Bereichen entstehen somit die folgenden Problembereiche,deren Anforderungen in den nachfolgenden Abschnitten des Analysekapitels betrachtet

21

3.1. Anforderungen Kapitel 3. Analyse

und für die mögliche Lösungsansätze diskutiert werden. Die ersten drei Problemberei-che beschreiben dabei funktionale Anforderungen und die weiteren drei Problembereichenicht-funktionale Anforderungen.

Repräsentation der Ortsinformation

Diese Anforderung befasst sich damit, wie Positionen und Orte definiert werden und wiediese Orte in Relation zueinander gestellt werden können.

Verbreitung der Ortsinformation im Netzwerk

Die Ortsinformation der Publisher muss bei den Subscribern bekannt sein, damit diese denortsbezogenen Filter auswerten können. Dafür muss die Ortsinformation der Teilnehmerim Netzwerk verbreitet werden.

Spezifikation und Umsetzung eines ortsbasierten Filters

Damit die Samples eines Topics gefiltert gelesen werden können, muss ein ortsbezogenerFilter definiert und gesetzt werden können. Dafür ist eine Filtersyntax erforderlich, dieangibt, was und wie etwas angegeben werden kann. Anschließend muss der definierteFilter zur Laufzeit ausgewertet werden, um auf dieser Basis eingehende Daten-Sampleszuzustellen oder zu verwerfen. Diese Anforderung bezieht sich dabei auf den Zeitpunkt,an dem die Filterung ansetzt.

Integration in sDDS

Die neue sDDS-Erweiterung muss sich gut in die bestehende Middleware integrieren las-sen und so viele bestehende Komponenten wie möglich wiederverwenden. Unter demAspekt dieser Anforderung müssen folgende Punkte betrachtet werden:

• Verbreitung der Ortsinformation im NetzwerkBei Verbreitung von Ortsinformationen soll bei der Integration nach Möglichkeitauf vorhandene Mittel zugreife.

• Verbinden von Samples mit OrtsinformationenDa Ortsinformationen den Daten-Samples nicht beiliegen, muss die zum Samplezugehörige Ortsinformation gefunden und mit diesem verknüpft werden.

22

Kapitel 3. Analyse 3.2. Repräsentation der Ortsinformationen

• Umsetzung der Filterung zur LaufzeitTechnische Umsetzung der Filterung.

Kompatibilität zum DDS-Standard

Neben einer guten Integration in die Middleware, soll die neue sDDS-Erweiterung auchkompatibel zum DDS-Standard sein. Diese Anforderung muss für alle Problembereicheimmer mit berücksichtigt werden.

Ressourcenbeschränktheit

Die ortsbezogenen Topic-Filterung soll auch auf kleinen eingebetteten Systemen laufen,sodass bei allen Betrachtungen immer darauf geachtet werden muss, dass die sDDS-Erweiterungen auch auf ressourcenarmen Geräten laufen kann.

3.2 Repräsentation der Ortsinformationen

Dieser Abschnitt befasst sich damit, wie Positionen und Orte dargestellt werden könnenund wie die sich daraus ergebende Ortsrepräsentation definiert werden soll.

3.2.1 Koordinaten

Zunächst soll analysiert werden wie die Position einzelner Objekte dargestellt werdenkann. Dafür werden folgende Möglichkeiten betrachtet:

• Global Positioning System als globales Weltkoordinatensystem

• Lokales Koordinatensystem

Die beiden Alternativen werden in den folgenden Unterabschnitten genau gegenüber ge-stellt, sodass auf Grundlage dieser Analyse eine Designentscheidung getroffen werdenkann.

23

3.2. Repräsentation der Ortsinformationen Kapitel 3. Analyse

3.2.1.1 Global Positioning System

Global Positioning System (GPS) ist ein Lokalisierungsverfahren, mit welchem die Po-sition eines Objektes bestimmt und in einem Weltkoordinatensystem angegeben werdenkann (vgl Abschnitt 2.1.2). Auch in Fällen, in denen GPS nicht die geeignete Lokalisie-rungsmethode ist, wird die Position häufig in GPS-Koordinaten angegeben.

Der Vorteil von GPS-Koordinaten ist, dass die Position im Weltkoordinatensystem im-mer eindeutig ist und GPS-Koordinaten eine verbreitete, standardisierte Darstellung bie-ten, die von vielen Lokalisierungsverfahren und Anwendungen bereits unterstützt wird.Um eine hohe Genauigkeit auszudrücken, wie beispielsweise Millimeter oder mindes-tens Zentimeter für den Smart Home Anwendungsfall, müssen die Koordinaten in derDezimalschreibweise mit sieben bzw. sechs Nachkommastellen Genauigkeit angegebenewerden. Dafür muss ein Double als Datentyp verwendet werden, sodass ein einzelnesKoordinatenpaar bereits 16 Byte Speicherplatz belegt und die Arbeit mit Gleitkommazah-len sehr rechenintensiv wird.

3.2.1.2 Lokales Koordinatensystem

Eine Alternative stellt die Nutzung eines lokalen Koordinatensystems dar. Der Vorteilhierbei ist, dass das lokale Koordinatensystem nicht den gesamten Globus umfassen muss.Stattdessen kann es nur die nötige Fläche abdecken und somit die gleiche Präzision erzie-len wie mit GPS-Koordinaten und dabei gleichzeitig die Verwendung eines viel kleinerenDatentyps ermöglichen. Ausgehend von dem in Abschnitt 3.1.1 beschriebenen Smart-Home-Szenarien soll für die weitere Betrachtung eine zentimetergenaue Angabe ange-nommen werden. Bei einer Größe von 2 Byte pro Koordinate könnte somit eine Flächevon 216cm × 216cm = 429.497m2 angegeben werden. Der Nachteil eines lokalen Koor-dinatensystems ist, dass rein auf Basis lokaler Koordinaten eine Positionierung innerhalbeines Weltkoordinatensystems nicht möglich ist. Des Weiteren kann eine Position in lo-kalen Koordinaten, nicht ohne Weiteres durch andere Anwendungen verwendet werden.

3.2.1.3 Designentscheidung

Zwar ist die Nutzung einer standardisierten Koordinatendarstellung, die eine Positionie-rung im Weltkoordinatensystem ermöglicht, praktisch, jedoch ist der Vorteil gegenüberdem sehr großen Speicherverbrauch zu gering, sodass ein lokales Koordinatensystem ver-wendet werden soll. Dieses soll jedoch um einen Referenzpunkt erweitert werden, wel-

24


cher in GPS-Koordinaten angegeben wird, und es somit ermöglicht, lokale Koordinatenbei Bedarf in GPS-Koordinaten umzuwandeln.

Abbildung 3.2: Beispiel einen lokalen Koordinatensystems mit Referenzpunkt

Abb. 3.2 zeigt hierfür ein Beispiel. Der hier angegebene Referenzpunkt positioniert daslokale Koordinatensystem in Wiesbaden, Unter den Eichen 5, sodass abgebildete Objekteim lokalen Koordinatensystem einen Offset zu dem angegebenen Referenzpunkt darstel-len und durch Addieren des Offsets sich die globale Position bestimmen lässt.

3.2.2 Geometrie

Neben der Position von Objekten ist es auch erforderlich, Flächen definieren zu können,die für ein Abonnement relevante Bereiche festlegen. Dafür wird ein Geometriemodell be-nötigt, das verschiedene Flächen beschreibt und Relationen zwischen diesen zu definiert.Hierfür werden als Alternativen das Geometriemodell des Open Geospatial Information

Standards und ein eigenes Geometriemodell betrachtet.

3.2.2.1 Open Geospatial Information Standard

Eine Möglichkeit bietet der Open Geospatial Information Standard - Simple Feature Ac-

cess (OpenGIS) [opeb]. OpenGIS beschreibt eine Architektur, die ein Geometriemodellund eine Schnittstelle definiert, mit der Eigenschaften geometrischer Objekte abgefragtsowie verschiedene Objekte zueinander in Relation gestellt werden können.

Abbildung 3.3 zeigt das OpenGIS-Geometriemodell. Jedem geometrischen Objekt istexakt ein SpatialReferenceSystem zugeordnet, das die Art des Koordinatensys-

25

3.2. Repräsentation der Ortsinformationen Kapitel 3. Analyse

Abbildung 3.3: OpenGIS-Geometriemodell aus [opeb]

tems beschreibt. Weiterhin können mehrere MeasureReferenceSystems zugeord-net sein, die den Maßstab des Objekts definieren. Ein geometrisches Objekt kann dieAusprägung eines Punktes, einer Kurve oder einer Oberfläche haben. Zudem gibt es dasabstrakte GeometryCollection-Objekt, das eine Sammlung von Punkten, Kurvenoder Oberflächen realisiert. Ein Punkt wird als Double-Wert pro Achse angegeben. Zweioder mehr Punkte definieren einen LineString. Abgeleitet davon ist demnach eineLinie ein LineString mit nur zwei Punkten. Da eine Kurve hier nichts anderes ist alseine Approximation durch einen LineString, wird dieser von der Kurve abgeleitet. EinLinearRing wird durch einen geschlossenen LineString gebildet und wird deshalbvon diesem abgeleitet. Einer oder mehrere LinearRings sind Elemente eines Polyg-ons, wobei Polygone wiederum Elemente eines PolyhedralSurface sein können.Polygone und PolyhedralSurfaces werden beide von einem Surface abgeleitet.

Neben dem Geometriemodell beschreibt der erste Teil des Standards auch räumliche Re-lationen zwischen zwei geometrischen Objekten. Eine Auflistung der definierten Relatio-nen ist in Tabelle 3.1 enthalten.

Der Vorteil an OpenGIS ist, dass es sich um einen weitverbreiteten Standard zur Model-lierung von Geoinformationen handelt. Das hier erläuterte Geometriemodell erlaubt dasDefinieren aller vorstellbaren Formen, sowohl im zwei- als auch im dreidimensionalenRaum. Der Nachteil ist jedoch, dass jede Form als Polygon beschrieben werden muss und

26


Funktionsname BeschreibungEquals Die Funktion gibt TRUE zurück, wenn die beiden betrach-

teten geometrischen Objekte räumlich gleich sind.Disjoint Die Funktion gibt TRUE zurück, wenn die beiden betrach-

teten geometrischen Objekte räumlich disjunkt sind.Intersects Die Funktion gibt TRUE zurück, wenn die beiden betrach-

teten geometrischen Objekte sich räumlich schneiden.Touches Die Funktion gibt TRUE zurück, wenn die beiden betrach-

teten geometrischen Objekte sich räumlich berühren.Crosses Die Funktion gibt TRUE zurück, wenn die beiden betrach-

teten geometrischen Objekte sich kreuzen.Within Die Funktion gibt TRUE zurück, wenn das betrachtete geo-

metrischen Objekte sich räumlich innerhalb des übergebe-nen Objektes befindet.

Contains Die Funktion gibt TRUE zurück, wenn das übergebene geo-metrischen Objekte sich räumlich innerhalb des betrachte-ten Objektes befindet.

Overlaps Die Funktion gibt TRUE zurück, wenn das betrachtete geo-metrische Objekt das übergebene Objekt überlappt.

Relate Die Funktion Relate bekommt ein geometrisches Objektund eine intersectionPatternMatrix. Die Matrixbeschreibt, wie sich die innere und äußere Grenze der über-gebenen und des betrachteten Objektes schneiden sollen.Die Funktion gibt TRUE zurück, wenn alle durch die inter-sectionPatternMatrix geforderten Schnitte vorhanden sind.

Tabelle 3.1: OpenGIS Relationsmodell zum Testen räumlicher Relationen zwischen geo-metrischen Objekten [opeb]

dies somit auch für einfache Formen wie Rechtecke und Kreise gilt. Rechtecke müssen alsPolygon mit fünf Punkten angegeben werden. Das ist zwar mehr als bei der Angabe einesUrsprungs und von Länge und Breite, jedoch aus der Sicht des Speicherverbrauchs nochnicht sehr kritisch. Problematischer wird es bei Kreisen, da diese nicht einfach nur durcheinen Ursprungspunkt und einem Radius angegeben werden können, sondern als Poly-gon mit sehr vielen Punkten approximiert werden müssen und dadurch viel Speicherplatzverbrauchen.

27

3.3. Ortsbasierte Filterung Kapitel 3. Analyse

3.2.2.2 Eigenes Geometriemodell

Alternativ dazu besteht die Möglichkeit, auf die Nutzung des Standards zu verzichtenund ein eigenes Geometriemodell zu definieren. Der Vorteil hierbei ist, dass Punkte dasgleiche Koordinatensystem und die gleiche Genauigkeit verwenden können wie die Orts-repräsentation und somit nur so viel Speicherplatz verbraucht wird wie nötig. Weiterhinkann besonders für einfache Formen eine speichereffiziente Darstellung gewählt werden.So ist es beispielsweise ausreichend, für ein Rechteck einen Punkt sowie Länge und Breitezu speichern, und für eine Ellipse den Mittelpunkt sowie die beiden orthogonalen Durch-messer des Einheitskreises. Da diese Grundformen als Approximation für die meistenFälle ausreichen, wäre der Speichergewinn im Gegensatz zur Verwendung von Polygo-nen sehr hoch.


Auch wenn ein eigenes Geometriemodell platzeffizienter wäre, ermöglicht die Verwen-dung eines verbreiteten Standards Kompatibilität zu anderen Anwendungen. Um denSpeicherverbrauch zu reduzieren, soll neben dem Polygon eine weitere Klasse vonSurface abgeleitet werden, die es ermöglicht, einfache Formen wie Rechtecke und El-lipsen effizient zu speichern aber zusätzlich die Möglichkeit bietet, diese in Polygoneumzuwandeln und somit wieder standardkompatibel zu sein. Weiterhin soll statt Double-Werten der gleiche Datentyp wie zur Ortsrepräsentation verwendet werden. Da es das inAbschnitt 3.2.1 definierte Koordinatensystem über den globalen Referenzpunkt ermög-licht, lokale Koordinaten in GPS-Koordinaten umzuwandeln, ist es möglich, das hier an-gepasste Geometriemodell in anderen Anwendungen, die OpenGIS umsetzen, zu verwen-den.

3.3 Ortsbasierte Filterung

Nach der Analyse in Abbschnitt 3.2 über die Definition und Darstellung der Ortsinfor-mation befasst sich dieser Abschnitt mit der ortsbasierten Topic-Filterung. Dafür werdenzunächst mögliche Filtersyntaxen betrachtet, mit deren Hilfe ein solcher Filterausdruckerfasst werden kann. Anschließend werden verschiedene Alternativen betrachtet, an de-nen die Filterauswertung zur Laufzeit angesetzt werden kann.

28

Kapitel 3. Analyse 3.3. Ortsbasierte Filterung

3.3.1 Spezifikation der Filtersyntax

Die Filtersyntax ermöglicht es einer Anwendung, einen Filter dynamisch zu definieren.ContentFilteredTopics und MultiTopics des DDS-Standards nutzen bereitseine zu SQL ähnliche Filtersyntax, die jedoch nicht für eine ortsbasierte Topic-Filterunggeeignet ist. Im weiteren Verlauf werden existierende Filtersyntaxen betrachtet und aufihre Eignung und Kompatibilität zum bestehenden Standard untersucht. Bei den betrach-teten Alternativen handelt es sich um eine SQL-Erweiterung des Open Geospatial Infor-mation Standards, GeoSPARQL und der Filtersyntax der Subscription-Filterung aus demCORBA Notification Service.

3.3.1.1 OpenGIS - SQL Option

OpenGIS Implementation Standard for Geographic information - Simple feature access -

Part 2: SQL option [opea] ist der zweite Teil des in Abschnitt 3.2.2 erläuterten Standardsund definiert, wie die in Teil 1 beschriebene Architektur für eine SQL-Erweiterung um-gesetzt werden kann. Geometrische Objekte können entweder in einem internen Formatgesichert werden oder aks sogenannter Well Known Text (WKT) oder Well Known Binary

(WKB). WKT ist ein String, bei dem die Unterklasse des geometrischen Objektes angege-ben wird und anschließend die Punkte, die das Geometrieobjekt definieren. Dabei werdendie Koordinaten durch Leerzeichen und die Punkte mit einem Komma separiert. Ein Bei-spiel für WKT ist in Quellcode 3.1 zu sehen. Es handelt sich um einen LineString,der aus drei Linien im zweidimensionalen Raum besteht.

1 LINESTRING (30 10, 10 30, 40 40)

Quellcode 3.1: Geometrieobjekt durch WKT definiert

WKB definiert eine Binärrepräsentation. Dabei beschreibt das erst Byte die Endianness,anschließend gibt ein 4-Byte Integer die Unterklasse und Dimension des Koordinatensys-tems an, und schließlich folgen die Koordinaten als Double-Werte.

Das durch die Architektur in Teil 1 [opeb] definierte Relationenmodell wird von der SQL-Erweiterung aus dem zweiten Teil des Standards als SQL-Routinen zur Verfügung gestelltund innerhalb der WHERE-Klausel genutzt werden. Dabei können Objekte aus der Da-tenbank oder Objekte, die als WKT oder WKB innerhalb der Query angegeben werden inRelation zueinander gestellt werden.

29


Der Vorteil einer erweiterten SQL-Syntax ist es, dass die durch den DDS-Standard de-finierte Filtersyntax für ContentFilteredTopics und MultiTopics selbst eineUntermenge von SQL ist. Dadurch würde sich eine räumliche SQL-Erweiterung als Syn-tax gut in den vorhandenen Standard eingliedern.

3.3.1.2 GeoSPARQL

Das Resource Description Framework (RDF) ist eine weitverbreitete Methode zur Mo-dellierung von Daten im Semantic Web. SPARQL ist eine durch das World Wide WebConsortium (W3C) empfohlene Abfragesprache, um Daten im RDF-Format zu durchsu-chen [W3C]. SPARQL weist Ähnlichkeiten mit SQL auf. Der Rückgabewert der Abfragerichtet sich nach der Form der SELECT-Abfrage, und innerhalb der WHERE-Klausel las-sen sich die Werte durch Filterfunktionen weiter einschränken [geo]. Der GeoSPARQL-Standard wurde vom Open Geospatial Consortium herausgegeben und ermöglicht dasDarstellen und Abfragen von räumlichen Daten im Semantic Web, wofür er eine Erwei-terung der Abfragesprache SPARQL definiert. Er ist modular aufgebaut, sodass die Kern-komponente eine allgemeine Klasse für räumliche Objekte definiert. Eine weitere Kom-ponente ist das topologisches Vokabular, das die nötigen RDF-Eigenschaften zum Abfra-gen topologischer Relationen beschreibt. Geometrische Objekte und die dazugehörigenräumlichen Query-Funktionen werden als RDF Schema (RDFS) definiert. GeoSPARQList so konzipiert, dass die OpenGIS-Architektur hierfür verwendet werden kann. Da dieräumliche Information hier als Ontologie vorliegt, ist es möglich, weitere semantische In-formation einzubringen. Zusätzliche Information bedeutet jedoch auch zusätzlichen Spei-cherverbrauch. Ein weiterer Nachteil ist, dass die SPARQL-Syntax aufwendiger als SQList und zudem durch den DDS-Standard nicht unterstützt wird, da der in DDS definierteglobale Datenraum eher einer verteilten Datenbank entspricht als einer Ontologie.

3.3.1.3 CORBA Notification Service - Subscription Filtering

Als letztes Beispiel einer verbreiteten Filtersyntax soll der CORBA Notification Service

betrachtet werden [cora]. Dieser ermöglicht es, eine Benachrichtigung für bestimmte Er-eignisse zu abonnieren. Dabei kann ein Subscription-Filter angegeben werden, der nichtnur nach dem Typ des Ereignisses filtert sondern auch nach inhaltlichen Vorgaben, diedurch den Filter definiert werden können. Als Sprache wird dabei die OMG Trader Cons-

traint Language verwendet [corb, tra]. Sie definiert die üblichen booleschen Vergleichs-operatoren sowie Konnektoren wie AND, OR und NOT. Zusätzlich ist es möglich, die Exis-

30


tenz und Namen von Objekt-Eigenschaften abzufragen sowie mathematische Operationeninnerhalb der Abfrage durchzuführen.

Die Trader Constraint Language könnte damit, so wie sie definiert ist, zur inhaltlichenFilterung der Topics genutzt werden, jedoch nicht ohne Weiteres für einen räumlichenFilter, da keine Definition von räumlichen Objekten und Relationen zwischen diesen vor-handen ist.


Da der DDS-Standard für ContentFilteredTopics und MultiTopics eine Teil-menge von SQL als Filtersyntax definiert, ermöglicht eine SQL-Erweiterung zum Abfra-gen und Prüfen von räumlichen Eigenschaften die größte Kompatibilität. Somit soll derStandard OpenGIS Implementation Standard for Geographic information - Simple feature

access - Part 2: SQL option als Filtersyntax umgesetzt werden.

3.3.2 Filterung zur Laufzeit

Nach Angabe der Filter in einer dafür geeigneten Filtersprache müssen die gefordertenAuflagen für das Abonnement zur Laufzeit durchgesetzt werden. Dafür sollen verschie-dene Zeitpunkte betrachtet werden, an denen man eingreifen kann, um die irrelevantenSamples herauszufiltern.

3.3.2.1 Empfangsseitige Filterung

Der späteste Zeitpunkt, zu dem ein Sample herausgefiltert werden kann, ist auf der Seitedes Empfängers, bevor das Sample in die History des DataReaders eingereiht wird undvon dort aus für die Anwendung zugreifbar ist. Auf diese Weise kann der Publisher un-gefiltert alle Samples publizieren, da der Subscriber sich um die Umsetzung des Filterskümmert.

Der Vorteil einer Filterung auf Empfängerseite ist zum einen die Effizienz in Hinsicht aufdie Anzahl verwalteter, da jeder Subscriber nur seinen eigenen Filter kennen muss undzum anderen lässt sich auf diese Weise garantieren, dass, solange die Filterung korrektumgesetzt ist, auch alle nicht relevanten Samples herausgefiltert wer,den. Der Nachteildieses Ansatzes liegt im höheren Datenverkehr, da auch irrelevante Samples auf Sender-seite publiziert werden und damit weniger effizient in Hinsicht auf die Übertragung. Dies

31


führt weiterhin zu einem höheren Speicher- und Rechenaufwand, da die Filterregeln aufalle eingehenden Samples angewendet werden müssen. Dies kann insbesondere auf res-sourcenarmen Sensorknoten zu Problemen führen.

3.3.2.2 Senderseitige Filterung

Alternativ ist es möglich, die Filterung zum Sendezeitpunkt auf der Seite des Publis-hers anzusetzen. Dadurch kann unnötiger Datentransfer verhindert werden, da irrelevanteSamples bereits durch den Publisher erkannt und gar nicht erst abgesendet werden. Da-für muss ein Publisher allerdings die Filter aller seiner Subscriber kennen, was auf res-sourcenarmen Plattformen zu Problemen führen kann, wenn die Anzahl der Subscribersehr groß wird. Ein Subscriber muss die Filterregeln seiner Subscription an alle Publisherübertragen, wo sie verwaltet und aktualisiert werden. Dies verursacht zusätzlichen Kom-munikationsaufwand und führt zu Latenzen bei der Aktualisierung der Filter. Insgesamtist die senderseitige Implementierung aufwendiger als die Implementierung auf Empfän-gerseite. Zusätzlich muss beachtet werden, dass eine Filterung nur auf Senderseite nichtausschließen kann, dass unerwünschte Samples beim Empfänger ankommen. Dies kannpassieren, wenn ein Publisher beispielsweise die ortsbasierte Filterung nicht unterstütztoder Samples über Multicast an eine Empfängergruppe mit unterschiedlichen Filtern ver-sendet werden.

3.3.2.3 Router-seitige Filterung

Neben der Filterung auf Empfänger- oder Senderseite besteht auch die Möglichkeit,Samples während des Routings herauszufiltern. Dafür sollen zunächst Grundzüge derSoftware Defined Networks Architektur betrachtet und anschließend analysiert werden,wie dieses Konzept in das Routing-Protokoll RPL übertragen werden kann. Der Publisherkann so alle seine Samples abschicken, ohne sich um die Filterauswertung, oder Verwal-tung zu kümmern. Mit einer zentralen Management-Instanz ähnlich dem SDN Controllergäbe es nur noch eine Stelle, an der die Filterregeln verwaltet und geprüft werden müssen.So müsste ein Subscriber zwar seinen Filter noch immer übertragen und würde dadurchzusätzlichen Datentransfer verursachen, jedoch muss er das bei dieser Alternative nur aneinen Teilnehmer schicken.

32


Abbildung 3.4: SDN-Architektur im Überblick aus [Ope13]

Software Defined Networks

Traditionelle Netzwerke bieten keine Möglichkeit für Anwendungen, das Netzwerk zubeeinflussen und anwendungsspezifische Merkmale anzufordern. Dies ist erst durch denEinsatz von Software Defined Networks (SDN) möglich geworden. Abbildung 3.4 zeigtdie verschiedenen Komponenten einer SDN-Architektur und wie diese miteinander in-teragieren. Die Abbildung sowie die nachfolgenden Informationen entstammen [Ope13].Die dargestellte Architektur wird in drei Ebenen unterteilt, die sich Data Plane, Control

Plane und Application Plane nennen. Auf der Data Plane sitzt die SDN Datapath Kompo-nente, die ein logisches Netzwerkgerät darstellt und eine Schnittstelle exportiert, welchedie weiterleitenden und verarbeitenden Mechanismen repräsentiert. Auf der Control Pla-

ne befindet sich der SDN Controller, dieser ist die zentrale Komponente der Architekturund kann die Anforderungen einer Anwendung an den SDN Datapath weitergeben. Dafürkommuniziert der SDN Controller über das SDN Control-Data-Plane-Interface (CDPI),welches der Control Plane ermöglicht, Einfluss auf die darunter liegende Data Plane zunehmen. Weiterhin exportiert der SDN Controller eine abstrakte Sicht auf das Netzwerk,

33


die sich speziell nach den Anforderungen der jeweiligen Anwendung richtet. Als Schnitt-stelle zwischen der Control Plane und der Application Plane dient das SDN Northbound

Interface (NBI), welches der Anwendung diese Netzwerkabstraktionen zur Verfügungstellt. Diese werden von der SDN Application konsumiert, um zu einer Entscheidungsfin-dung zu kommen. Diese Entscheidung kann über das NBI an den SDN Controller über-tragen werden.

Ansatz der Software Defined Networks in RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

In traditionellen Netzwerken verfügen alle Knoten zumindest über einen Teil der Routing-Information und können somit Pakete an die entsprechenden Knoten weiterleiten. Diesgilt jedoch nicht für alle Knoten in einem 6LoWPAN-Netz, da hier das Routing Protocol

for Low-Power and Lossy Networks (RPL) verwendet wird [Win12]. RPL unterscheidetzwischen drei verschiedenen Arten von Knoten, dem DODAG-Root, einem Storing-Nodeund einem Non-Storing-Node. Ein DODAG ist ein Direction Oriented Directed Acyclic

Graph, bei welchen der DODAG-Root den Endknoten für alle Verbindungen im Gra-phen darstellt. Der DODAG wird gebildet durch das Verbreiten des Destination Informa-

tion Objects (DIO), welches die Information eines Knotens an seine Nachbarn versendetund damit von diesen als RPL-Instanz gefunden werden kann. Daher sind RPL-InstanzenKnoten innerhalb des DODAGs. Sie sind in Rängen angeordnet, welche die Entfernungzum DODAG-Root repräsentieren. Eine RPL-Instanz kennt eine Menge von Vätern, diejeweils eine RPL-Instanz mit einem niedrigeren Rang darstellen und somit in RichtungDODAG-Root führen. Aus der Menge der möglichen Väter kann jede RPL-Instanz mit-hilfe der Object Function die am besten geeignete Verbindung heraussuchen. Somit ent-hält der DODAG nur Informationen über Wege in Richtung des DODAG-Roots und jedeRPL-Instanz nur Informationen über Väter.

Der DODAG-Root hat die Möglichkeit, eine Routingtabelle für seinen DODAG aufzu-bauen. Dafür sendet jede RPL-Instanz ein Destination Advertisement Object (DAO) anden DODAG-Root. Non-Storing-Nodes leiten das DAO einfach in Richtung des Rootsweiter, wohingegen Storing-Nodes die DAOs ihres Subgraphen nutzen können, um selbstfür diesen eine Routingtabelle aufzubauen. Bei einer Punk-zu-Punkt (P2P) Kommunika-tion innerhalb des 6LoWPAN-Netzwerks muss ein Paket erst zum nächsten Storing-Nodeoder dem DODAG-Root weitergeleitet werden. Abbildung 3.5 zeigt dies an einem einfa-chen Beispiel. Knoten D möchte eine Nachricht an Knoten F senden. Da jede RPL-Instanznur ihre Väter kennt, wird die Nachricht so lange weitergeleitet, bis sie einen Knoten er-

34


reicht, der die nötige Routinginformation kennt, um die Nachricht korrekt weiterzuleiten.Dafür wird die gesamte Route im Source Header codiert. In diesem Beispiel muss dieNachricht bis zum DODAG-Root weitergeleitet werden, um von dort an F geschickt wer-den zu können.

Abbildung 3.5: P2P Kommunikation in RPL

Ein möglicher Ansatz, das SDN-Konzept in RPL einzubinden, wird von Jacquenet undBoucadair in [JB16] erläutert. Sie schlagen vor, die Architektur eines Knotens in ei-nem 6LoWPAN-Netzwerk aufzuteilen, sodass das eigentliche Gerät nur noch die OSI-Schichten 1,2 und 7 erfüllt und die Schichten 3-6 virtualisiert durch den SDN-Controllerzur Verfügung gestellt werden. Die Applikationsschicht des Geräts kann über eine geeig-nete Schnittstelle mit dem SDN Controller kommunizieren und Einfluss auf die virtuali-sierten Funktionen ausüben.

Dieser Ansatz lässt sich übertragen, um eine Filterung über das Routing durchzusetzen,indem der SDN Controller zusätzlich zu den Routinginformationen auch einen Graphenmit Informationen über den Stand und die Filter der Abonnements hält. Dieser Graph kannausgewertet werden, um festzustellen, ob Samples eines Abonnements gefiltert werdenmüssen oder nicht. Für den Fall, dass gefilterte Samples publiziert werden, kann durch dievirtuallisierte Object Function diese Route vor dem Publisher verborgen werden, indembeispielsweise keine vorhandenen Väter gezeigt werden und das Paket somit nicht anden DODAG-Root gesendet werden kann. Auf dieser Weise können Verbindungen imDODAG für eine RPL-Instance nur dann sichtbar gemacht werden, wenn ein Abonnementzwischen Sender und Empfänger besteht und die Filterregeln erfüllt wurden.

Der Vorteil dieser Vorgehensweise ist, dass die Filterregeln nur noch an einer Stelle ausge-wertet werden müssen, wodurch jedoch das Gerät, das diese Aufgabe übernimmt, dement-sprechend über ausreichend Ressourcen verfügen muss. Der Sender muss sich nicht mit

35


der Auswertung der Filter befassen, sodass der Funktionsumfang geringer gehalten wer-den kann und damit auch auf ressourcenarmen Plattformen implementiert werden kann.Da die Entscheidung jedoch nicht rein über die IP-Adresse der Knoten getroffen werdenkann, müssen die virtualisierten Methoden auch die Möglichkeit bieten, eine TopicID zuübermitteln, wodurch die Definition der DIOs, DAOs und Object Functions strukturell an-gepasst werden müssten. So wäre es möglich, den Datentransfer irrelevanter Samples zureduzieren, jedoch entsteht damit zusätzlicher Datentransfer, da die virtualisierten Funk-tionen auf dem entfernten SDN Controller aufgerufen werden müssen. Zusätzlich kommtdie Schwierigkeit dazu, dass RFC 6550 [Win12], welches RPL definiert, sich mit demAblauf des Protokolls und der übertragenen Daten befasst und kein einheitliches Interfacedefiniert und somit die Implementierungen für verschiedene Systeme sehr unterschiedlichsein können. Dies würde zu einem hohen Implementierungsaufwand für die ortsbasierteTopic-Filterung führen. Ein weiterer negativer Punkt ist die erhöhte Latenz beim Aktuali-sieren der Filter, die dadurch entsteht, dass alle Filter an einem zentralen Ort ausgewertetund aktualisiert werden und somit vom Subscriber erst an den SDN Controller übertragenwerden müssen.

3.3.2.4 Zentrale Filterung

Schließlich soll noch die Möglichkeit einer zentralen Filterung betrachtet werden. Dafürkann ein ausgewählter Knoten als zentrale Instanz agieren, an dem alle Subscriber ihreFilter registrieren. Jeder Publisher publiziert zunächst Daten an diesen Filterknoten, derdie Filter auswertet und die Daten gefiltert an die jeweiligen Subscriber weiterleitet. DerVorteil dieser Vorgehensweise ist, dass die Filterauswertung auf den Filterknoten ausge-lagert werden kann, welcher dafür auf leistungsstarker Hardware umgesetzt werden kann.Die Nachteile sind, dass, wenn die Filterung komplett auf den Filterknoten ausgelagertwird, der Empfänger keine Möglichkeit hat, Samples, die aus einem Fehler heraus zu-gestellt wurden herauszufiltern. Außerdem wird die gesamte Kommunikation auf dieseWeise zentralisiert und bricht damit die dezentrale Struktur von DDS auf. Schließlich ent-steht durch die Übertragung der Filter an den Filterknoten eine Latenz beim Aktualisierender Filter, im Vergleich zu einer direkten Filterung auf Empfängerseite.


Die Filterung seitens des Routings ist zwar möglich, jedoch ist die Umsetzung sehr auf-wendig für den im Vergleich geringen Vorteil. Der hauptsächliche Vorteil liegt darin, dass

36

Kapitel 3. Analyse 3.4. Integration in sDDS

die Filterung ausgelagert und auf leistungsstärkerer Hardware durchgeführt werden kann.Für Publisher und Subscriber bleibt die Filterung außerdem vollständig transparent unddadurch, dass der SDN Controller das gesamte Netz im Überblick behält, ist eine zu-sätzliche Filterung auf Subscriber-Seite nicht nötig. Die Auslagerung und Zentralisierungder Filterung kann auch durch den zentralen Filterknoten erfolgen, jedoch würde diesauch die gesamte Kommunikation zentralisieren, und da der Filterknoten keinen Einflussauf das Netzwerk hat und somit nicht verhindern kann, dass Samples trotzdem aufgrundeines Fehlers verschickt werden, ist es zusätzlich nötig, die Samples auf Empfängersei-te zu filtern. Da keine der vorgestellten Alternativen uneingeschränkt geeignet ist, solleine Kombination aus Router-seitiger Filterung und zentraler Filterung als Ansatz ver-folgt werden. Der SubscriptionManager soll, angelehnt an den SDN Controller,die Kommunikation steuern. Anstatt jedoch Netzwerkinformationen anzupassen, soll derSubscriptionManager das Abonnement eines Publishers, dessen Samples den Fil-terausdruck des Abonnements nicht erfüllen, vorübergehend deaktivieren und somit denDatentransfer reduzieren. Der Subscriber muss trotzdem seine eigenen Filter prüfen, umeine korrekte Filterung zu garantieren. Durch das Deaktivieren gefilterter Subscriptionswird jedoch die Anzahl der zu prüfenden Samples auf der Seite des Subscribers reduziert.

3.4 Integration in sDDS

Dieser Abschnitt befasst sich mit der Integration der in diesem Kapitel diskutierten An-sätze in die Middleware sDDS. Dafür soll untersucht werden, wie Ortsinformationen derKnoten am besten im Netzwerk verbreitet werden können und wie die Filterung am besteninnerhalb der bestehenden Schnittstellen integriert werden kann.

3.4.1 Verbreitung der Ortsinformation

Dieser Abschnitt befasst sich damit, wie die verschiedenen Teilnehmer des Netzwerks ih-re Ortsinformationen untereinander verbreiten und welche Schnittstellen der MiddlewaresDDS sich dazu eignen oder ob eine neue Schnittstelle dafür definiert werden muss.

3.4.1.1 Built-In Topic

Eine Möglichkeit, interne Informationen zwischen den Teilnehmern zu übertragen undauch der Anwendung bereitzustellen, bilden sogenannte Built-In Topics. Von den durch

37

3.4. Integration in sDDS Kapitel 3. Analyse

den Standard definierten Built-In Topics gibt es jedoch kein Topic, das sich dazu eignet,Ortsinformationen zu übertragen [OMG]. Für sDDS besteht die Möglichkeit, ein zusätz-liches LocationBuiltInTopic zu definieren, welches die vorhandene Schnittstelleder Built-In Topics nutzen kann. Die Publikation der Ortsinformation als Sample auf ei-nem Topic hält die Option offen, die Daten in einem ContentFilteredTopic oderMultiTopic (vgl. Abschnitt 2.2.1) zu verarbeiten. Weiterhin ist es offen, ob die Da-ten durch ein Gerät selbstständig publiziert werden oder von einem anderen Knoten, derbeispielsweise die Lokation für andere Knoten übernimmt. Dafür werden Primärschlüs-sel benötigt, um Samples eindeutig identifizieren und somit auch überschreiben zu kön-nen. Diese werden durch die bisherige sDDS-Implementierung noch nicht unterstützt undmüssen für diesen Ansatz implementiert werden.

3.4.1.2 Topic-unabhängige Verbreitung

Alternativ zur Nutzung der Topic-Schnittstelle besteht die Möglichkeit, eine zusätzlicheSchnittstelle zu definieren, über welche Ortsinformationen im Netzwerk verbreitet wer-den sollen. Eine neu definierte Schnittstelle hat den Vorteil, dass sie auf genau diesenAnwendungsfall zugeschnitten werden kann und dadurch die Funktionalität der Schnitt-stelle klarer ersichtlich ist. Der Nachteil dieser Vorgehensweise ist, dass die existierendeSchnittstelle der Topics, die als Kommunikationskanal zum Übertragen beliebiger, zumModellierungszeitpunkt definierter Daten verwendet werden kann, nicht genutzt wird,sondern eine neue Schnittstelle geschaffen werden würde und somit zusätzlicher Codeerzeugt wird, der sich auf die Größe und Wartbarkeit der Anwendung auswirkt.


Die Nutzung der Built-In-Topic-Schnittstelle gliedert sich nicht nur nahtlos in den DDS-Standard ein, sondern auch in die bestehenden Schnittstellen der Middleware sDDS. Eindefiniertes LocationBuiltInTopic kennzeichnet deutlich die Funktion der Datenund kann von Implementierungen, welche die ortsbasierte Topic-Filterung nicht unter-stützen, entweder ignoriert oder als gewöhnliches Topic abonniert werden.

3.4.2 Verbinden von Samples mit Ortsinformationen

Dieser Abschnitt befasst sich damit, wie die Ortsinformation einzelner Geräte mit denSamples eines Topics verbunden werden können, um damit einen Ortsbezug für jedes

38


Daten-Sample herzustellen. Da Ortsinformationen auf einem Topic publiziert werden,können diese durch den JOIN eines DDS MultiTopics mit den Daten anderer Samp-les verbunden werden. Die Funktionalität der DDS MultiTopics ist noch nicht insDDS implementiert, sodass diese Implementierung erst erfolgen muss. Ein JOIN erfolgtdabei durch den Vergleich eines festgelegten Attributs an welchem der JOIN durchge-führt werden soll, und das Zusammenführen der Daten beider Samples.

3.4.2.1 Weiterverarbeitung durch das ContendFilteredTopic

Die durch den JOIN mit Ortsinformationen angereicherten Samples können durch einContentFilteredTopic ausgewertet werden, da die Ortsinformation nach demJOIN als Datum des Samples vorhanden ist. Das ContentFilteredTopic nutzt eineTeilmenge der SQL-Syntax, sodass die OpenGIS SQL-Erweiterung an dieser Stelle direktgenutzt werden kann, um die bestehende Syntax zu erweitern. Die Position würde nachdem JOIN als Ellipse vorliegen, sodass mit der erweiterten Syntax geprüft werden kann,ob die Ellipse innerhalb eines Rechtecks liegt. Der Vorteil liegt darin, dass eine bestehen-de DDS-Schnittstelle zur Definition und Auswertung genutzt werden kann. Als Nachteilsteht dem die semantische Mischung zwei unterschiedlicher Filtervarianten gegenüber.

3.4.2.2 Weiterverarbeitung durch das LocationFilteredTopic

Alternativ zur Verwendung des ContentFilteredTopics besteht die Möglich-keit, einen neuen Topic-Typ einzuführen. Das LocationFilteredTopic kann da-bei vom ContentFilteredTopic abgeleitet werden. Damit würde das Location-FilteredTopic die Filtersyntax des ContentFilteredTopic unterstützen undzusätzlich die OpenGIS SQL-Erweiterung implementieren. Dies hat den Vorteil, dassdurch das neu eingeführte Topic eine klare semantische Trennung möglich ist und dassweitere ortsbasierte Funktionen in Zukunft besser implementiert werden können, ohnedas ContentFilteredTopic weiter ”aufzupumpen”. Der Nachteil liegt in der Ein-führung eines neuen Typs, der nicht durch den Standard vorgesehen ist.


Um eine klarere Trennung zwischen der den bestehenden Filtermechanismen und derortsbasierten Topic-Filterung zu schaffen, sollen die LocationFilteredTopics alsneuer Topic-Typ eingeführt werden.

39


3.4.3 Umsetzung der Filterung zur Laufzeit

Dieser Abschnitt befasst sich mit der Filterung zur Laufzeit und wie diese in dieMiddleware sDDS integriert werden kann. In Abschnitt 3.3.2 wurde bereits die Ideedes SubscriptionManagers als zentrale Managementinstanz zum Auswerten undDurchsetzen der Filter erläutert. Diese Managementinstanz soll einen Subscription-Graphen mit den Status aller Abonnements und der dazugehöriger Filter des Netz-werks verwalten. Die Information über aufgebaute Abonnements kann von dem Sub-

scriptionManager durch das Beobachten des Discovery-Mechanismus gefolgertwerden.

3.4.3.1 Aussetzen der Subscription

Bei Nichterfüllung der Filter soll der SubscriptionManager den Publisher benach-richtigen, das Abonnement für eine bestimmte Zeit auszusetzen. Dafür gibt es die Mög-lichkeit, das Abonnement auf dem normalen Weg zu kündigen. Das Kündigen einesAbonnements wird zwar derzeit nicht durch den Discovery-Mechanismus von sDDS un-terstützt und müsste dafür nachimplementiert werden. Der Vorteil ist aber, dass hier Stan-dardmechanismen verwendet werden können. Jedoch gibt es dadurch keine Möglichkeitzu unterscheiden, ob ein Abonnement erstmalig aufgenommen wird. Dies kann zu einemProblem führen, wenn ein Abonnement erneuert wird, beispielsweise, wenn ein neuerPublisher das Netzwerk betritt und bestehende Subscriber eine Subscription an diesen ab-schicken. In diesem Fall muss für bestehende Publisher dafür gesorgt werden, dass eindurch den SubscriptionManager gekündigtes Abonnement nicht ohne seine Zu-stimmung wieder aufgenommen wird.

3.4.3.2 Pausieren der Subscription

Eine weitere Möglichkeit ist es, einen neuen Zustand des ”pausierten” Abonnements ein-zuführen, um damit die Unterscheidung zwischen einem erstmals aufgebauten Abonne-ment und der Wiederaufnahme eines bestehenden Abonnements treffen zu können. Da-durch wird es einfacher, bei einem Ausfall des SubscriptionManagers ein pausier-tes Abonnement wieder aufzunehmen, da durch den neuen Zustand klar ersichtlich ist,welches Abonnement aufgrund der Filterung pausiert wurde. Der Nachteil liegt in derEinführung eines neuen Zustands, der nicht durch den DDS-Standard definiert ist.

40



Für die Umsetzung der Filterung soll der neue Zustand ”pausiert” eingeführt werden. DerSubscriptionManager prüft für jedes Abonnement den eingetragenen Filter undpausiert das Abonnement, wenn sich derzeit kein Subscriber für die Daten interessiert.Dadurch kann ganz klar der Zustand zwischen einer nicht aufgebauten und einer pausiertSubscription unterschieden werden und somit verhindert werden, dass durch den zyklischausgeführten Discovery-Mechanismus, eine pausierte Subscription wieder aufgenommenwird.

41


42

Kapitel 4

Design

4.1 Architekturüberblick

Aus den Designentscheidungen der in Kapitel 3 erfolgten Analyse kann die in Abb. 4.1dargestellte Architektur abgeleitet werden. Rollen, die eine Anwendungen bei der Kom-munikation annehmen kann, sind hier grau dargestellt. Es handelt sich dabei um die Rol-len des Publishers, des Subscribers und des SubscriptionManagers. Gelb sind die bereitsexistierenden sDDS-Module und blau sind die Module, die für die Erweiterung umgesetztwerden müssen. Im Standardfall nutzen Publisher und Subscriber, die auf einem gemein-samen Topic agieren, den Mechanismus der Subscription Discovery, um ein Abonnementfür dieses Topic aufzubauen. Ein Subscriber kann jedoch zusätzlich zum regulären Abon-nement des Topics auch ein gefiltertes Abbonement über ein LocationFiltered-

Topic aufbauen. Dadurch werden die publizierten Daten gefiltert an die Anwendungweitergereicht. Der Ortsfilter bezieht sich dabei auf den Entstehungsort der Daten undkann über einen entsprechenden Filterausdruck (FilterExpression) definiert wer-den. Zur Laufzeit geschieht die Filterung auf Subscriber-Seite und muss vom Publis-her nicht berücksichtigt werden. Dabei wird zur Auswertung des Filterausdrucks dieOrtsinformation des publizierenden Gerätes benötigt, welche entweder von dem Ge-rät selbstständig auf dem LocationBuiltInTopic oder durch andere Teilnehmerim Netzwerk publiziert wird, wodurch sowohl eine eigenständige als auch eine infra-strukturbasierte Lokalisierung ermöglicht wird. Die zusätzliche Komponente des Subs-

criptionManagers bietet eine Optimierungsmöglichkeit. Dieser erzeugt durch Beobach-ten der Subscription Discovery einen Subscription Graph, der die aufgebauten Abonne-ments abbildet und speichert die verwendeten Filter als Teil des Graphen. Da Filteraus-drücke nicht über die Subscription Discovery verschickt werden, werden diese über das

43

4.1. Architekturüberblick Kapitel 4. Design

ManagementTopic durch den SubscriptionManager von den Subscribern an-gefordert. Alle bekannten Filterausdrücke (FilterExpressions) werden durch denSubscriptionManager evaluiert, sodass Abonnements deren Daten aufgrund derFiltereinstellung keinen Interessenten haben, auf Publisher-Seite pausiert werden können.Dies erfolgt erneut durch eine Anweisung auf dem ManagementTopic.

Abbildung 4.1: Grobarchitektur der ortsbasierten Topic-Filterung

In den weiteren Abschnitte des Design-Kapitels wird die Architektur der ortsbasiertenTopic-Filterung im Detail erklärt. Abschnitt 4.2 beginnt mit der allgemeinen Erweiterungbisheriger sDDS-Module, wobei Topic-Schlüssel sowie der Discovery-Mechanismus da-bei im Näheren besprochen werden. Abschnitt 4.3 erläutert generische sDDS-Erweite-rungen. Dabei werden das Ortsinformations- und Geometriemodell sowie die Lokations-

44

Kapitel 4. Design 4.2. Allgemeine sDDS-Erweiterungen

schnittstelle definiert. Zuletzt werden in Abschnitt 4.4 die in Abb. 4.1 dargestellten Mo-dule zur Umsetzung der ortsbasierten Topic-Filterung besprochen.

4.2 Allgemeine sDDS-Erweiterungen

Die allgemeinen sDDS-Erweiterungen beziehen sich auf vorhandene Module und leisteneinige Vorarbeiten, die zur Umsetzung der ortsbasierten Topic-Filterung benötigt wer-den. Das Topic-Modul muss um die Verwendung von Primär- und Sekundärschlüsselnerweitert werden, da diese (vgl. Abschnitt 3.4.1) derzeit noch nicht unterstützt werden.Weiterhinn muss das Discovery-Modul in zwei Module aufgeteilt werden, um die Publi-kation der benötigten Built-In Topics von der Auswertung der darauf publizierten Datenzu trennen.

4.2.1 Primär- und Sekundärschlüssel

Der DDS-Standard sieht Schlüssel vor, um Samples eines Topics eindeutig identifizierenzu können. Doch das Konzept der Primär und Sekundärschlüssel wird von sDDS nichtunterstützt (vgl. 2.3.2). Dieses Funktionalität wird jedoch benötigt, um Ortsinformatio-nen der einzelnen Geräte identifizieren und überschreiben zu können. Um Komplexität zureduzieren und die Implementierung kleiner und einfacher zu halten, werden zusammen-gesetzte Schlüssel, wie sie im DDS-Standard möglich sind, nicht zugelassen. Es könnenjeoch beliebige Attribute eines Topics zum Modellierungszeitpunkt als Primär- oder Se-kundärschlüssel markiert werden. Bei der Codegenerierug werden dann die notwendigenFunktionen für den Zugriff auf den Schlüssel und den Vergleich zweier Schlüssel gene-riert. Weiterhin muss neben der Codegenerierung auch das History-Modul, welches fürjeden DataReader empfangene Daten-Samples vorhält, so angepasst werden, dass Samp-les anhand des Primärschlüssels identifiziert werden können und bei gleichen Schlüsselnüberschrieben werden.

4.2.2 Publikation der Built-In Topics

Der aktuelle Stand des Discovery-Moduls vereint die Publikation der Built-In Topics so-wie ihre Auswertung und die darauf basierende Discovery. Da die Analyse in Abschnitt3.4.1.3 jedoch ergeben hat, dass die Ortsinformation ebenfalls über ein Built-In Topic

45

4.2. Allgemeine sDDS-Erweiterungen Kapitel 4. Design

verbreitet werden soll, wird es notwendig, die Publikation der Built-In Topics von ih-rer Auswertung zu trennen, sodass ein neues Modul BuiltInTopicPublication-Service implementiert wird. Das Modul ist auf Abb. 4.2 dargestellt, dabei sind in Weißdie durch den DDS-Standard definierten Topics gekennzeichnet, welche für die Discove-ry genutzt werden, und in Blau das neue LocationBuiltInTopic und das ModulBuiltInTopicPublicationService, welches Funktionen zum Publizieren desentsprechenden Built-In Topics enthält. Diese werden entweder durch das Setzen einesIntervalls regelmäßig durch das Modul selbst aufgerufen, oder aber von außen, um einSample außerhalb des definierten Intervalls senden zu können.

Abbildung 4.2: Publikationsservice der Built-In Topics

4.2.3 Discovery Service

Das Modul DiscoveryService stellt die zweite Hälfte des ursprünglichen Discovery-Moduls dar und setzt das Abonnieren der dafür definierten Built-In Topics um, das Aus-werten darauf empfangener Daten und basierend darauf die Umsetzung des Discovery-Protokolls. Das umstrukturierte Modul ist in Abb. 4.3 blau gekennzeichnet. Es soll wäh-rend seiner Initialisierung Callback-Funktionen für die vier abonnierten Built-In Topics

registrieren, die das Discovery-Protokoll umsetzen, wie es bereits in der aktuellen Versi-on implementiert ist. In Weiss ist eine Liste bekannter Teilnehmer dargestellt, die aus deraktuellen Version des Discovery-Moduls übernommen werden soll und dazu genutzt wird,

46

Kapitel 4. Design 4.2. Allgemeine sDDS-Erweiterungen

sich bekannte Teilnehmer zu merken. Zur Verwaltung der Teilnehmerliste wurden auchdie Hilfsfunktionen addParticipant und handleParticipant übernommen.

Abbildung 4.3: DiscoveryService-Modul

Ein Abonnement wird auf Publisher-Seite aufgebaut, indem die Adresse des Subscribersin die Empfängerliste des Topics eingetragen wird. Die aktuelle Version der Middlewarebietet derzeit keine Möglichkeit, ein einmal etabliertes Abonnement zu beenden oder zupausieren. Jedoch ergab die Analyse in Abschnitt 3.4.3.3, dass ein Abonnement zwischenden Status aktiv und pausiert unterscheiden kann, um das Publizieren als Optimierungaussetzen zu können. Abb. 4.4 stellt das neue Design der Subscription-Verwaltung dar.Die einfachen Adresslisten als dsinks bzw. dsources, die zuvor alle Subscriber bzw.Publisher speicherten, werden durch Listen von TopicSubscriptions ersetzt (imBild blau dargestellt). Eine TopicSubscription enthält neben der Adresse auch dieParticipant ID des Teilnehmers und den aktuellen Status des Abonnements.

47

4.3. Generische sDDS-Erweiterungen Kapitel 4. Design

Abbildung 4.4: Subscription-Verwaltung durch zugehörige Topics

4.3 Generische sDDS-Erweiterungen

Als generische Module kommen das in Abschnitt 3.2.2 des Analysekapitels beschriebeneGeometriemodell hinzu, das für die Angabe von Ortsinformationen verwendet wird, so-wie eine Lokationsschnittstelle. Eine Umsetzung der Lokalisierung ist zwar nicht Teil derAnforderung, jedoch soll eine einheitliche Schnittstelle dafür definiert werden, die denZugriff auf Ortsinformationen für die Middleware vereinheitlicht.

4.3.1 Ortsinformation und das verwendete Geometriemodell

Wie in der Analyse in Abschnitt 3.2.1 erläutert, werden Ortsinformationen in einem loka-len, kartesischen Koordinatensystem angegeben. Ea können Orte und auch Positionen alsFlächen in diesem Koordinatensystem angegeben werden, wobei zur Modellierung derFlächen das in Abschnitt 3.2.2 erläuterte Geometriemodell verwendet wird.

Das lokale Koordinatensystem ist ganzzahlig, um das Rechnen mit Gleitkommazahlen zuumgehen und kann aufgrund der eingeschränkten Speicherkapazität nicht den gesamtenGlobus umfassen, sodass damit nur ein Ausschnitt definiert wird, welcher aber über einenReferenzpunkt, der in GPS-Koordinaten angegeben wird, in globale Koordinaten umge-rechnet werden kann (vgl. Abschnitt 3.2.1.3). Dies ist an einem Beispiel in Abb. 4.5 darge-stellt. Das gelb dargestellte lokale Koordinatensystem hat eine absolute GPS-Koordinate

48

Kapitel 4. Design 4.3. Generische sDDS-Erweiterungen

als Referenzpunkt und positioniert alle Objekte innerhalb des Koordinatensystems relativzu diesem Punkt, sodass aus den Koordinaten der dargestellten Fläche oder der Positionund dem Referenzpunkt wieder globale Koordinaten gewonnen werden können.

Abbildung 4.5: Lokales kartesisches Koordinatensystem mit globalem Referenzpunkt

Das Geometriemodell ermöglicht es, Flächen innerhalb des Koordinatensystems zu defi-nieren und Relationen zwischen den Flächen zu überprüfen, wie beispielseise in Abb. 4.5die WITHIN-Relation aussagen kann, dass die rote Position nicht innerhalb der blauenFläche liegt. Das Geometriemodell hält sich an das Geometriemodell des Open Geospati-

al Information Standards [opeb] (vgl. Abschnitt 3.2.2.3). Dieses Geometriemodell wird inAbb 4.6 als Klassenhierarchie dargestellt. Die abstrakte Klasse Geometry stellte dabeidie Basis für alle weiteren geometrischen Formen dar. Sie codiert den Typ des aktuellenObjektes als Bitmaske und bietet acht Relationen zwischen den geometrischen Objekten.Der Standard sieht vor, dass neben Punkten und Linien alle abgeleiteten Geometrien alsPolygonzug notiert werden können. Für einen speichereffizienteren Weg wird das beste-hende Modell um die Klasse der BasicShape erweitert, welche dann die Ausprägungeiner Ellipse oder eines Rechtecks haben kann. Dadurch können einfache Grundformenmit weniger Punkten gespeichert werden. Zusätzlich dazu soll für den dreidimenionalenRaum eine Approximation durch eine Extrusion der Grundfläche möglich sein, wofür dasExtrusion-Interface eingeführt wird, sodass von jeder Fläche auch ein dreidimensionalerKörper erzeugt werden kann.

49

4.3. Generische sDDS-Erweiterungen Kapitel 4. Design

Abbildung 4.6: Klassenhierarchie des erweiterten OpenGIS-Geometriemodells

4.3.2 Lokationsschnittstelle

Für die Selbstlokalisierung wird auf Ebene des System Abstraction Layers eine ein-heitliche Schnittstelle zur Lokalisierung definiert. Die Implementierung der Schnitt-stelle muss anschließend der Middleware für die unterschiedlichen Plattformen be-reitgestellt werden. Dieses Interface ist im oberen Teil der Abb. 4.7 zu sehen und

50

Kapitel 4. Design 4.3. Generische sDDS-Erweiterungen

erwartet eine Initialisierungsfunktion, eine Funktion zum Abrufen der eigenen Posi-tion (getLocation) und eine Funktion zum Abrufen der Position anderer Gerä-te (getDeviceLocation). Letztere ist optional und kehrt nur erfolgreich zurück,wenn das Gerät Fremdlokalisierung auch unterstützt. Weiterhin kann das sDDS-ModulLocationTrackingService bereitgestellt werden, bei dem zu überwachende Ge-räte über ihre Device ID registriert werden können und deren Position regelmäßig durchNutzung des LocationService-Interfaces aktualisiert wird. Die Position eines Gerä-tes wird als Struktur modelliert, die folgende Attribute enthält:

• Die Device ID, um die Postion einem Gerät zuordnen zu können.

• Einen Bereich, der durch eine Ellipse definiert wird.

• Einen Erzeugungszeitpunkt

• Eine Ablaufzeit

• Einen Status, über den angegeben werden kann, dass die Position nicht bestimmtwerden konnte.

Abbildung 4.7: Schnittstelle zur Lokalilierung und Tracking von Geräten

51

4.4. Architekturkomponenten Kapitel 4. Design

4.4 Architekturkomponenten

Der folgende Abschnitt befasst sich mit den einzelnen Komponenten der Architektur underläutert deren statischen Aufbau. Zuerst wird die Komponente LocationBuiltIn-Topic erläutert, da darüber die Ortsinformation der Geräte übermittelt wird. An-schließend folgt die Beschreibung des LocationFilteredTopic über welches derFilterausdruck (FilterExpression) angeben werden kann. Zusammen bilden dieOrtsinformation und der Filterausdruck die Basis für die Filterauswertung zur Lauf-zeit. Nach der Einführung der dafür nötigen Komponenten wird anschließend derSubscriptionManager erläutert. Dabei wird auf den Subscription-Graphen,der die Abonnements und Filter verwaltet, eingegangen, sowie den FilterEvaluator,durch welchen die Filter überprüft werden. Als letztes wird das ManagementTopicerläutert, da dies zur Kommunikation zwischen Publishern und Subscribern und demSubscriptionManager genutzt wird. Nach Betrachtung der einzelnen Komponen-ten für sich soll abschließend die Interaktion zwischen diesen erläutert werden, um nichtnur eine statische Sicht auf die Architektur darzustellen, sondern auch die dynamischeInteraktion und Verzahnung der Komponenten aufzuzeigen.

4.4.1 LocationBuiltInTopic

Für die Verbreitung der Ortsinformation wird das LocationBuiltInTopic einge-führt (vgl. Abschnitt 3.4.1.3). Abb. 4.8 zeigt die Datenstruktur der darauf publizier-ten Samples. Diese entspricht im wesentlichen der DeviceLocation-Struktur, jedochwird statt des Zeitstempels des letzten Updates das Alter des Samples übertragen, dasbeim Subscriber auf den Empfangszeitpunkt aufaddiert wird. Dies ist notwendig, da eskeine Garantie für eine gemeinsame Zeitbasis zwischen den Teilnehmern gibt. Die De-

vice ID ist dabei der Primärschlüsel des Topics, sodass für jedes Gerät nur eine einzigePosition existieren kann. Die Position kann für das eigene Gerät oder aber für andere Ge-räte publiziert werden, wodurch eine infrastrukturbasierte Lokalisierung ermöglicht wird.

Wie auch die anderen Built-In Topics wird das LocationBuiltInTopic über denBuiltInTopicPublicationService publiziert. Für die Auswertung wird esdurch das Modul BuiltInLocationUpdateService abonniert. Abb. 4.9 zeigtden Aufbau des Moduls, welches eine eigene Liste mit Positionsdaten führt. Die-se unterscheidet sich von der Liste des LocationTrackingServices dadurch,dass es sich hier nur um Geräte handelt, deren Position über das Built-In Topic ver-breitet wurde. In der Initialisierungsfunktion wird der updateListener für das

52

Kapitel 4. Design 4.4. Architekturkomponenten

Abbildung 4.8: Built-In Topic der Lokationsinformationen

LocationBuiltInTopic registiert, sodass beim Eintreffen eines neuen Samplesdie Position aktualisiert bzw. neu hinzugefügt wird. Wie bereits der Location-

TrackingService bietet auch der BuiltInLocationUpdateService die Funk-tionen zum Abfragen der Position eines bestimmten Gerätes oder von allen bekannten.Dadurch ist die Schnittstelle beider Dienste gleich und macht diese für andere Anwen-dungsfälle austauschbar.

Abbildung 4.9: Empfangen der Lokationsinformation über das Built-In Topic

53


4.4.2 LocationFilteredTopic

Die Komponente LocationFilteredTopic hat sich in der Analyse in Abschnitt3.4.2.3 als Wahl für den gefilterten Zugriff auf Topics herausgestellt. Der Aufbau desModuls kann anhand von Abb. 4.10 nachvollzogen werden.

Abbildung 4.10: Aufbau des LocationFilteredTopic

Dabei ist zu erkennen, dass das LocationFilteredTopic von dem durch den DDS-Standard definierten ContentFilteredTopic erbt und damit dessen Eigenschaftenübernimmt, wodurch auch die Assoziation des gefilterten Topics mit einem normalen To-pic erfolgt. Der Filterausdruck wird als String angegeben, da dieser so einfacher für Men-schen zu formulieren ist. Er wird jedoch durch die Funktion setFilter in ein Binär-format umgewandelt, da dieses einfacher zu verarbeiten ist und weniger Speicherplatz be-nötigt. Neben dem Setzen und damit notwendigen Umcodieren des Filterausdrucks stelltdas LocationFilteredTopic Funktionen bereit, um den Filterausdruck auszuwer-ten. Dafür gibt es zwei Varianten: evalExpression und evalSample. Die Funktion

54


evalExpression nimmt eine Position entgegben und wertet den Filter in Bezug aufdiese Position aus, wohingegen evalSample ein Daten-Sample entgegennimmt, umdurch einen JOIN der Sekundärschlüssel die Position des Gerätes zu erhalten, welchesdieses Sample abgesendet hat. Anschließend kann der Filter auf diese Position bezogenausgewertet werden. Weiterhin hat jedes LocationFilteredTopic Zugriff auf denGeometryStore. Dieser wird von der Codegenerierung aus den modellierten geome-trischen Objekten statisch erstellt und enthält Verweise auf alle modellierten Objekte,welche dann über eine zum Modellierungszeitpunkt globale, eindeutige ID unterschie-den gehalten werden können. Da der GeometryStore statisch ist, ist es somit nichtmöglich, neue geometrische Objekte zur Laufzeit hinzuzufügen.

Für die Auswertung des Filters enthält jedes LocationFilteredTopic einen Fil-terState zum Speichern des Zwischenergebnisses und der aktuellen Position im Filter.Der FilterState verfügt über eine FilterExpression-Struktur, die durch dasParsen des Filterausdrucks gefüllt wird.

Filtersyntax

Zur ortsbasierten Filterung soll ein Filterausdruck in einer vorgegebenen Syntax textuellangegeben werden können. Bei der Syntax handelt es sich um die SQL-Erweiterung desGeospatial Information Standards OpenGIS [opea], deren Vorzüge bereits in der Analysein Abschnitt 3.3.1 besprochen wurden. Da alle geometrischen Objekte zum Modellie-rungszeitpunkt definiert werden und ihre IDs somit bekannt sind, können sie über diesebzw. ein entsprechendes #define referenziert werden.

1 <EXPR> ::= <FUNC> <GEOMETRY> | NOT <FUNC> <GEOMETRY> | <EXPR> <CONNECTOR> <EXPR>

<CONNECTOR> ::= AND | OR

3 <FUNC> ::= EQUALS | DISJOINT | INTERSECTS | TOUCHES | CROSSES | WITHIN | CONTAINS |

OVERLAPS

5 <GEOMETRY> ::= Point | LineString | LineRing | Line | Ellipse | Square | Polygon |

PolyheadralSurface | EllipseExtrusion | SquareExtrusion | PolygonExtrusion |

PolyhedralSurfaceExtrusion

Quellcode 4.1: Filtersyntax

Quellcode 4.1 zeigt, das der Filterausdruck <EXPR> immer aus einer Funktion <FUNC-TION> und einem geometrischen Objekt <GEOMETRY> besteht. Die Funktion entsprichtdabei der Implementierung einer Relation zwischen der Ortsinformation des Daten-Samples und dem spezifizierten geometrischen Objekt und kann durch das SchlüsselwortNOT negiert werden. Weiterhin können zwei Filterausdrücke mit einem AND oder OR als

55


Konnektoren verbunden werden. Die Filtersyntax lässt keine Klammerung zu, da ansons-ten der Filterausdruck als Baum ausgewertet und die Teilausdrücke und Teilergebnissewährend der Auswertung vorgehalten werden müssten und damit bei langen Ausdrückenviel mehr Speicherplatz verbrauchen würde, als bei einer Syntax ohne Klammern. Durchden Verzicht auf Klammerung wird die Mächtigkeit der Syntax zwar eingeschränkt, je-doch wird ermöglicht, den Ausdruck linear von Links nach Rechts auszuwerten. Dashat den Vorteil, dass immer nur ein Teilausdruck und das vorhergehende Ergebnis ge-speichert werden müssen. Für die durch die Master-Thesis betrachteten Szenarien ist dieeingeschränkte Filtersyntax ausreichend. Ein beispielhafter Ausdruck, der Klammerungbenötigt wird in Quellcode 4.2, Zeile 1 dargestellt.

1 OVERLAPS GEO_LIVINGROOM OR (OVERLAPS GEO_LIVINGROOM AND OVERLAPS GEO_KITCHEN)

3 OVERLAPS GEO_LIVINGROOM OR OVERLAPS GEO_LIVINGROOM) AND OVERLAPS GEO_KITCHEN

5 OVERLAPS GEO_LIVINGROOM

Quellcode 4.2: Filterausdruck Klammerung

Durch eine Auswertung von links nach rechts entsteht jedoch die in Zeile 2 gezeigte im-plizite Klammerung. Durch vorherige Vereinfachung des Ausdrucks aus Zeile 1 bei derdas Absorptionsgesetzt angewandt wird, lässt sich der Ausdruck wie in Zeile 3 gezeigt,äquivalent vereinfachen. Dies erfordert zusätzlichen analytischen Aufwand bei der Mo-dellierung der Filterregeln, ermöglicht jedoch eine Auswertung mit einem viel geringerenSpeicherverbrauch.

Filterauswertung zur Laufzeit

Die Auswertung des Filters geschieht zur Laufzeit durch den Subscriber auf Empfän-gerseit und den SubscriptionManager, der die Filter auswertet, um eine möglicheOptimierung durchzusetzen (vgl. Abschnitt 3.3.2.5). Auf Empfängerseite löst jedes emp-fangene Daten-Sample die Überprüfung des Filters, aus und nur wenn der Filterausdruckerfüllt ist, wird das Sample an die Anwendung weitergegeben. Dafür muss die aktuelleStruktur des DataSink-Moduls angepasst werden. Diese Anpassung wird durch Abb.4.11 dargestellt, wobei blaue Module neu hinzukommen und weiße Module bereits vor-handen sind.

Das Modul DataSink verwaltet alle existierenden DataReader, die es zu allenbekannten Topcs gibt. Neue Samples landen in der DataSink und werden an die

56


Abbildung 4.11: Zusammen zwischen Topics, DataSink und DataReader

DataReader verteilt, wo sie in der History abgelegt und von der Anwendung entnom-men werden können. Für ein gefiltertes Topic dürfen nur Samples weitergegeben werden,die den Filter erfüllen. Dafür wird ein FilteredDataReader-Modul hinzukommen,das von dem normalen DataReader erbt. Um die Vererbung zu ermöglichen, soll dasEinsortieren des Samples in die History nun von den DataReadern durchgeführt wer-den anstatt von der DataSink. Dies wird durch die Funktion pushData erfolgen, so dassein FilteredDataReader die Funktion überschreiben kann, um vorher eine Prüfungdes Filters durchzusetzen. Damit muss die DataSink zu den Normalen DataReadernauch die gefilterten DataReader verwalten. Weiterhin ist es in der aktuellen Imple-mentierung bisher nur vorgesehen, dass nur ein einziger DataReader zu einem Topicexistiert und durch die DataSink zugreifbar ist. Dies wird geändert, indem ein Iteratorimplementiert wird, der durch alle vorhandenen DataReader zu einem angegebenen Topicläuft.

Zum Auswerten des Filterausdrucks wird seitens des SubscriptionManagers die

57


Funktion evalExpression des LocationFilteredTopics für jedes Eintref-fen eines LocationBuiltInTopic-Samples aufgerufen. Der Subscriber ruft dage-gen evalSample für jedes eingehende Daten-Sample auf. Die eigentliche Auswertungverläuft in beiden Fällen gleich.

Das Auswerten des Filterausdrucks erfolgt durch den in Abb. 4.12 dargestellten Zustands-automaten. Da der Ausdruck linear von links nach rechts ausgewertet werden kann, ist esausreichend, dass ein LocationFilteredTopicmit einer einzigen FilterState-Struktur auskommt, wie sie in Abb. 4.10 dargestellt ist.

Abbildung 4.12: Zustandsautomat der Filterauswertung

58


FilterState hält Informationen über die aktuelle Position im Filterausdruck, das vor-angegangene Ergebnis, einen eventuell eingelesenen Konnektor und den aktuellen Teil-ausdruck. Dafür wird der Filterausdruck sequentiell ausgewertet. Zunächst wird ein Teil-ausdruck, der aus einer Funktion, einem geometrischen Objekt und optional einer Negati-on besteht, gesucht und die FilterExpression-Struktur gefüllt. Konnte ein gültigerTeilausdruck gelesen werden, wird dieser evaluiert und falls zuvor ein Konnektor einge-lesen wurde, mit dem bisherigen Ergebnis und- bzw. oder-Verknüpft. Anschließend wirdder Filterausdruck weiter geparst. Wenn kein Konnektor nach einem Ausgewerteten Teil-ausdruck gelesen werden konnte, endet der Automat im Endzustand, und das Endergebniskann in der Struktur FilterState abgelesen werden; ansonsten wird nach dem Einle-sen eines Konnektors der nächste Teilausdruck gesucht.

4.4.3 SubscriptionManager

Der SubscriptionManager ist, wie in Abschnitt 3.3.2.5 des Analysekapitels heraus-gearbeitet, eine zentrale Management-Instanz, die an das Konzept des SDN Controllers

angelehnt ist, um den Datenverkehr zu beeinflussen. Dabei geschieht dies nicht durchRouting, sondern durch Einflussnahme auf die Abonnements zwischen Publishern undSubscribern. Der SubscriptionManager kann durch selbstständiges Auswerten derortsbezogenen Filter feststellen, wann ein Publisher Daten publiziert, für die es keineAbnehmer gibt und das Abonnement für diesen Zeitraum pausieren. Dafür verfügt derSubscriptionManager über einen SubscriptionGraphen, welcher Informati-on über aktuelle Subscriptions im Netzwerk hält und einen FilterEvaluator, deralle Filter aller Abonnements eines Subscribers prüfen kann.

Diese drei Module können anhand vob Abb. 4.13 nachvollzogen werden. Der Graph wirdaufgebaut, indem der SubscriptionManager den Discovery Service beobachtet unddadurch ohne weiteres Eingreifen in Erfahrung bringen kann, welcher Teilnehmer aufwelchem Topic publiziert oder dieses abonnieren möchte. Dafür werden die FunktionenhandleParticipant, handlePublication und handleSubscription fürjedes Eintreffen der jeweiligen Samples ausgeführt. Der Filterausdruck ist nicht Teil derDiscovery und muss über das in Abschnitt 3.4.3.3 herausgearbeitete ManagementTopic,das konzeptionell an das Northbound Interface der SDN-Architektur angelehnt ist, bezo-gen werden, sodass das ManagementTopic-Sample dann über registerFilterausgewertet werden kann, um den Filter zu setzen. Durch evalFilteredSubscrip-tions werden mit Hilfe des FilterEvaluators alle Filterausdrücke aller Abonne-ments für eine vorgegebene Position überprüft.

59


Abbildung 4.13: SubscriptionManager

Beim SubscriptionGraph, zu sehen in Abb. 4.14, handelt sich hierbei um einen ge-richteten Graphen, bei dem eine Kante ein Abonnement zwischen einem Publisher undeinem Subscriber darstellt. Für jeden ParticipantNode kann über eine Bitmaske dieRolle des Publishers bzw. des Subscribers angegeben werden. Weiterhin wird die Adresseund die Ortsinformation des Knotens in der ParticipantNode-Struktur geführt, so-wie eine Liste aller Kanten, an denen dieser beteiligt ist, um einen leichteren Zugriff dar-auf zu haben. Wenn das Abonnement über ein LocationFilteredTopic entstand,wird das entsprechende Flag an der Kante gesetzt und das LocationFilteredTopicreferenziert. Weiterhin enthält eine Kante auch die Information darüber, welchen Sta-tus das Abonnement aktuell hat und ob die Daten über Unicast oder Multicast versen-det werden. Der SubscriptionGraph bietet die Möglichkeit mit den FunktionencreateParticipantNode, establischSubscription sowie establish-

FilteredSubscription neue Knoten und Kanten zu erzeugen, sowie mit den Funk-tionen cancleSubscription, pauseSubscription und resumeSubscrip-

tion ein Abonnement zu beenden, zu pausieren oder zu reaktivieren. Die Anweisung,ein Abonnement zu pausieren oder zu reaktivieren, wird über das ManagementTopicversendet. Diese Anweisung muss durch den SubscriptionManager zyklisch erneu-ert werden, da das pausierte Abonnement ansonsten nach einer festgelegten Zeit wiederdurch den Publisher reaktiviert wird, um bei einem Ausfall des SubscriptionMana-gers den Normalzustand wieder herstellen zu können.

60


Abbildung 4.14: Subscription-Graph

Abb. 4.15 zeigt beispielhaft, wie so ein Graph aussehen könnte. Das Beispiel besteht ausdrei Teilnehmern. P publiziert auf Topic 1, PS abboniert Topic 1 und publiziert auf Topic2 und S abonniert Topic 2. Der SubscriptionManager füllt die auf der Abbildungdargestellten Listen der Knoten und Kante,n indem er den Discovery Service auswertetund erhält so den abgebildeten Graphen (rechts auf Abb. 4.15.

4.4.4 ManagementTopic

Das ManagementTopic erbt von einem normalen Topic und bringt eigene ab-geleitete DataReader und DataWriter mit. Die Vererbungshierarchie kann inAbb. 4.16 nachvollzogen werden. Das ManagementTopic wird verwendet, um Key-Value-Paare gezielt an einen bestimmten Teilnehmer zu übertragen. Dafür bietet derManagementDataWriter die Funktion writeToParticipant, dem im Ge-gensatz zum normalen DataWriter zusätzlich gezielt eine Empfängeradresse über-geben werden kann. Die Samples des ManagementTopics enthalten neben demKey-Value-Paar, einen Primärschlüssel sowie eine Participant ID, um die Nachrichtfür den Fall einer Multicast-Übertragung einem bestimmten Teilnehmer zuordnen zu kön-nen.

61


Abbildung 4.15: Grafische Darstellung eines beispielhaften Subscription-Graphs

Über den ManagementTopicPublicationService (siehe Abb. 4.17) könnenmithilfe der Funktion publishManagementDirective beliebige Key-Value-Paare an einen angegebenen Empfänger publiziert werden. Der ManagementTopic-SubscriptionService (siehe Abb. 4.18) registriert den Listener executeMana-gementDirective, der eine dem Key entsprechende Anweisung ausführt.

Zur Umsetzung des SubscriptioManagers, müssen folgende Anweisungen imple-mentiert werden:

Key: SET_SUBSCRIPTION_STATE

Value: <topicID><participantID><state>

Aktion: Statusänderung einer Subscription zwischen den Status ACTIVE und PAUSED.

Key: REQUEST_FILTER_EXPRESSION

Value: <topicID>

Aktion: Erzeugt für jeden vorhandenen Filter für die gefragte Topic ID ein Management-Topic-Sample mit dem Key SEND_FILTER_EXPRESSION und dem Filter alsValue.

Key: SEND_FILTER_EXPRESSION

Value: <topicID><participantID><expr length><expr>

Aktion: Registriert den empfangenen Filter für alle Subscriptions des Subscribers aufdiesem Topic.

62

Kapitel 4. Design 4.5. Interaktionen

Abbildung 4.16: ManagementTopic

Abbildung 4.17: ManagementTopic Publication-Service

Key: DELETE_FILTER_EXPRESSION

Value: <topicID><participantID>

Aktion: Löscht den Filter für alle Subscriptions des Subscribers auf diesem Topic.

4.5 Interaktionen

Dieser Abschnitt befasst sich mit der Interaktion der Module untereinander und betrachtetsomit den dynamischen Aspekt des Architekturdesigns. Dafür soll das in der Analyse inAbschnitt 3.1.1 beschreibene Szenario 3 betrachtet werden, indem der Staubsaugroboter

63

4.5. Interaktionen Kapitel 4. Design

Abbildung 4.18: ManagementTopic Subscription-Service

an seiner Basisstation im Flur startet, dort saugt und danach ins Wohnzimmer fährt, woer im Teppichboden stecken bleibt. Anschließend wird er wieder befreit und fährt weiterins Wohnzimmer. Daraus ergeben sich folgende Abläufe, die für die Interaktionen imeinzelnen betrachtet werden sollen:

Anwendungsfall 1 Der Staubsaugroboter wird aktiviert und nimmt am Discovery teil.Er publiziert auf dem Topic Status, das von der Zentralsteuerung gefiltert abonniertwerden soll. Dies soll durch den SubscriptionManger registriert werden, umden SubscriptionGraphen zu aktualisieren.

Anwendungsfall 2 Der Staubsauger publiziert eigenständig seine Position. Während ersich im Flur aufhält, stellt der SubscriptionManager fest, dass der registrierteFilterausdruck nicht erfüllt wird und pausiert das Abonnement.

Anwendungsfall 3 Der Staubsaugroboter fährt ins Wohnzimmer und bleibt im Teppichhängen. Er befindet sich zwischen Wohnzimmer und Flur, wodurch der Filteraus-druck erfüllt wird und der SubscriptionManager das Abonnement reaktiviert.

Anwendungsfall 4 Der Staubsaugroboter wird von einem der Bewohner befreit und fährtweiter ins Wohnzimmer, wo sein Abonnement wieder pausiert wird. Dafür fällt dieZentralsteuerung aus, sodass der Staubsaugroboter das Abonnement wieder reakti-viert.

Anwendungsfall 1

Da der einfache Discovery-Mechanismus unverändert bleibt, wird für den Anwendungs-fall nur die Seite des SubscriptionManagers und der Zentralsteuerung betrachtet.

Abbildung 4.19 zeigt die Sicht des SubscriptionManagers. Dieser empfängt einParticipant-Sample, welches zu dem neuen Teilnehmer Staubsaugroboter gehört. Wie

64


Abbildung 4.19: Anwendungsfall 1 aus Sicht des SubscriptionManagers

jedes Sample landet es in der DataSink wo nach der Zuordnung zum entsprechen-den DataReader der participantListener des Moduls DiscoveryService auf-gerufen wird und von dort an den SubscriptionManger weitergereicht wird. Dader SubscriptionManager den Teilnehmer noch nicht kennt, wird dieser als neu-er Knoten im SubscriptionGraph durch createParticipantNode erzeugt.Anschließend wird ein Publication-Sample des Staubsaugroboters empfangen und er-neut bis zum SubscriptionManager durchgereicht, wo dieser Knoten als Publis-her markiert wird. Auf das Publication-Sample reagiert die Zentralsteuerung mit einemSubscription-Sample, für welches der SubscriptionManager eine Kante für dasAbonnement im SubscriptionGraph anlegt. Da es sich hierbei um ein gefilter-tes Abonnement handeln könnte, fordert der SubscritionManager den Subscriberüber ein Management-Sample auf, einen Filter zu senden. Wird kein Filter gesendet,bleibt das Abonnement ungefiltert. In diesem Fall reagiert die Zentralsteuerung mit ei-nem Management-Sample, das den Filterausdruck enthält. Das Sample wird über denListener an das Modul MangementTopicSubscriptionService weitergereicht,

65


wo durch Analyse der Key-Attributes festgestellt wird, dass es sich um einen Filteraus-druck handelt. Dieser wird an den SubscriptionManager weitergegeben und imSubscriptionGraphen registriert.

Abbildung 4.20: Anwendungsfall 1 aus Sicht der Zentralsteuerung

Abbildung 4.20 zeigt den Vorgang aus Sicht der Zentralsteuerung. Diese nimmt an demganz normalen Discovery teil und abonniert den Status des Staubsaugroboters. Anschlie-ßend kommt ein ManagementTopic-Sample an, das an den Listener des Moduls Mana-gementPublicationService weitergereicht wird. Das Key-Attribut des Samples wird aus-gewertet und als Filteranfrage erkannt. Darauf wird der Filter für das angegebene Topicüber das Modul ManagementPublicationService an die Absendeadresse zurckgeschickt.

Anwendungsfall 2

Anwendungsfall 2 wird aus Sicht des SubscriptionManagers, der Zentralsteuerungund des Staubsaugroboters betrachtet. Die Publikation des LocationBuiltInTopic-Samples wird nicht beachtet, da diese wie die Publikation anderer Built-In Topics erfolgt.

Abbildung 4.21 zeigt das empfängerseitige Herausfiltern der Samples in der Zeit, in derdie Optimierung noch nicht erfolgt ist. Bevor ein Filterausdruck überprüft werden kannmuss jedoch eine Position für das Gerät vorhanden sein, da die Auswertung ansonstenstandardmäßig TRUE ergibt. Diese wird über ein LocationBuiltInTopic-Sampleübermittelt und durch das Modul BuiltInLocationUpdateSerice aktuallisiert.Wenn ein Status-Sample des Staubsaugroboters eintritt, nachdem seine Position bekanntist, wird nach dem Aufruf der Funktion pushData des FilteredDataReader dasSample an das LocationBuiltInTopic zur Überprüfung gegeben. Da der Filter-ausdruck auf Überlappung der Position der beiden Räume Wohnzimmer und Flur filtert,wird die Funktion overlaps des Geometry-Moduls aufgerufen. Der Filter ist für dieses

66


Abbildung 4.21: Anwendungsfall 2 Filterung durch die Zentralsteuerung

Sample nicht erfüllt und das Sample wird verworfen.

Abbildung 4.22: Anwendungsfall 2 aus Sicht des SubscriptionManager

Abbildung 4.22 zeigt das Überprüfen des Filterausdrucks aus Sicht des Subscription-Managers. Dies wird ausgelöst, wenn ein LocationBuiltInTopic-Sample emp-fangen wird. Über den Listener wird es an das Modul LocationBuiltInTopicweitergereicht, wo die Position des Gerätes aktualisiert wird. Anschließend wird dasSample an den SubscriptionManager gegeben, der eine Überprüfung über dasModul FilterEvaluator startet. Dabei werden alle Abonnements, die dieser Sub-

67


scriber auf diesem Topic hat, untersucht und die vorhandenen Filterausdrücke ge-prüft. Da alle registrierten Filterausdrücke in diesem Fall FALSE ergeben, wird die-ses Ergebnis dem SubscriptionManager mitgeteilt, der darauf erst den Status desSubscriptionGraphen ändert und anschließend ein Management-Sample mit derAnweisung das Abonnement zu pausieren an den Staubsaugroboter sendet.

Abbildung 4.23: Anwendungsfall 2 aus Sicht des Staubsaugroboters

Der Staubsaugroboter publiziert nach einem aufgebauten Abonnement erstmal auf demStatus-Topic Samples, bis eine Anweisung des SubscriptionManager zum pausie-ren erhält. Abbildung 4.23 zeigt die Sicht des Staubsaugroboters, der ein Management-Sample empfängt, das durch das ManagementTopicSubscriptionService-Modul ausgewertet wird und worauf das Abonnement auf PAUSED gesetzt wird. Da dasPausieren aktiv wiederholt gesendet wird, wird bei einem bereits pausierten Abonnementder Status erneuert.

Anwendungsfall 3

Dieser Anwendungsfall soll anhand bereits vorhandenen Abbildungen betrachtet werden,da er sich nur in der Auswertung des Filterausdrucks unterscheidet. In Abb. 4.22 aus An-wendungsfall 2 ergibt die Filterauswertung TRUE, und es wird das Management-Samplemit der Anweisung resume gesendet. Dieses wird durch den Staubsaugroboter empfan-gen und ausgewertet (vgl. Anwendungsfall 2) und der neue Status für das Abonnementgesetzt. Die Zentralsteuerung empfängt wieder Status-Samples, sodass die Filterauswer-tung aus Abb. 4.21 des zweiten Anwendungsfalls für das neue Sample TRUE ergibt unddas Sample in die History geschrieben wird.

68


Anwendungsfall 4

Dieser Anwendungsfall soll aus Sicht der Staubsaugroboters betrachtet werden. DerPausiert-Status des Abonnements wird durch den SubscriptionManager auf-rechterhalten, weil das Modul ManagementTopicSubscriptionService eineÜberprüfung der Aktualität durchführt und bei langer Inaktivität das Abonnement wie-der reaktiviert.

Abbildung 4.24: Anwendungsfall 4 aus Sicht des Staubsaugroboters

Dafür wird wie in Abb. 4.24 dargestellt zyklisch die Funktion reactivateSub-

scription aufgerufen, die für alle Subscriptions prüft, ob das Abonnement pausiertist und das letzte Update die vorgegebene Deadline überschritten hat. Wenn dies der Fallist, wird das Abonnement wieder reaktiviert.

69


70

Kapitel 5

Implementierung

Dieses Kapitel befasst sich mit der Implementierung der in Kapitel 4 beschriebenen Er-weiterung und geht dabei zuerst auf die Entwicklungsumgebung ein, greift interessanteImplementierungsdetails heraus und gibt abschließend eine Aufstellung über den Imple-mentierungsaufwand.

5.1 Entwicklungsumgebung

Die Entwicklung erfolgte in der Programmiersprache C unter Linux und wurde zunächstfür Linux auf einem Desktop-PC umgesetzt und getestet und später für Linux auf demRaspberry Pi getestet. Die Entwicklung für RIOT wurde ebenfalls unter Linux betriebenund für einen Atmel ATSAMR21-XPRO cross-kompiliert und auf diesem getestet.

Ein großer Teil des Codes wird generiert. Dafür werden Einstellungen in XML-Dateienangegeben und durch GSL-Skripte ausgewertet. GSL ist ein Open Source Tool, das diegleichnamige Skriptsprache interpretiert, um damit XML-Dateien auszuwerten. Somitwurden die bestehenden GSL-Skripte erweitert, um den Quellcode für die Primär- undSekundärschlüssel, die Geometrieobjekte, den GeometryStore und die Location-FilteredTopics zu generieren.

71

5.2. Allgemeine sDDS-Erweiterungen Kapitel 5. Implementierung

5.2 Allgemeine sDDS-Erweiterungen

5.2.1 Primär- und Sekundärschlüssel

Das Datenmodell der Topics wurde, wie im Design in Abschnitt 4.2.1 beschrieben, umPrimär- und Sekundärschlüssel erweitert. Topics, beziehungsweise die dazugehörigen Da-tenmodelle, werden im XML-Format modelliert und anschließend durch die Codegene-rierung als C-Datenstruktur mit den dazugehörigen Funktionen erzeugt. Jedes definier-te Attribut der Datenstruktur soll als Primär- oder Sekundärschlüssel verwendet werdenkönnen. Ein Beispiel hierzu findet sich im Quellcode 5.1, wo ein beispielhaftes Topicmit dem Namen alpha und drei Attributen angelegt wird. Das Attribut value ist vomTyp DDS_char und wird als Primärschlüssel markiert. Das Attribut device ist vomTyp DDS_short und soll der Sekundärschlüssel werden. Schließlich wird noch str

definiert, ein zehn Zeichen langer String, der keine Schlüsselfunktion übernimmt.

1 <topic name = "alpha" domain = "1" id = "A">

Alpha testing topic.

3 <attribute name = "value" type = "DDS_char" key = "primary">

Any char value

5 </attribute>

<attribute name = "device" type = "DDS_short" key = "secondary">

7 Device ID

</attribute>

9 <attribute name = "str" type = "DDS_string" size= "10" >

Any string value

11 </attribute>

</topic>

Quellcode 5.1: Das Topic Alpha als XML

Von der Codegenerierung wird aus dem XML-Dokument die in Quellcode 5.2 gezeigteDatenstruktur erzeugt. Die Implementierung erfolgte mit Hilfe von Unions, sodass aufdie als Schlüssel definierten Attribute immer zusätzlich mit dem Namen pKey für Pri-märschlüssel oder sKey für Sekundärschlüssel zugegriffen werden kann.

struct Alpha

2 {

/* Any char value */

4 union {

DDS_char pkey;

6 DDS_char value;

};

8 /* Device ID */

union {

72

Kapitel 5. Implementierung 5.2. Allgemeine sDDS-Erweiterungen

10 DDS_short skey;

DDS_short device;

12 };

/* Any string value */

14 DDS_char value2[11];

};

16 typedef struct Alpha Alpha;

Quellcode 5.2: Generierte Datenstruktr des Topics Alpha

Da jedes Attribut prinzipiell als Schlüssel gewählt werden kann, muss das Topic entspre-chende Funktionen bereitstellen, um die Schlüssel miteinander vergleichen zu können,beziehungsweise einen Zeiger auf das jeweilige Attribut zurückgeben zu können.

5.2.2 Publikation der Built-In Topics

Das ursprüngliche Discovery-Modul wurde im neuen Design (vgl. Abschnitt 4.2.2) inzwei Module unterteilt, die nun separat genutzt werden können. Zum Publizieren derBuilt-In Topics muss das Feature über die Einstellungen aktiviert werden. Dies geschiehtwie in Quellcode 5.3 gezeigt.

<define name = "FEATURE_SDDS_BUILTIN_TOPICS_ENABLED" />

Quellcode 5.3: Aktivieren des Features Built-In Topics

Damit wird das #define FEATURE_SDDS_BUILTIN_TOPICS_ENABLED gesetztund die Module BuiltinTopic und BuiltInTopicPublicationService kom-piliert.

5.2.3 Discovery Service

Den zweiten Teil des ursprünglichen Discovery-Moduls stellt das neue Modul Dis-coveryService dar (vgl. Abschnitt 4.2.3). Die Funktionalität wurde aus dem ur-sprünglichen Modul übernommen, jedoch wurde das Pollen der DataReader durch dieRegistrierung von entsprechenden Listenern ersetzt. Quellcode 5.4 zeigt dies am Beispieldes participantListener.

1 // define participant listener

struct DDS_DataReaderListener participantListStruct = {

3 .on_data_available =

73

5.3. Generische sDDS-Erweiterungen: Geometriemodell Kapitel 5. Implementierung

&s_DiscoveryService_participantListener

5 };

// set listener

7 dds_ret = DDS_DataReader_set_listener(g_DCPSParticipant_reader, &participantListStruct,

NULL);

if(dds_ret == DDS_RETCODE_ERROR){

9 Log_error("Unable to set participantListener.\n");

return SDDS_RT_FAIL;

11 }

Quellcode 5.4: Aktivieren des Features Built-In Topics

Dafür wird zunächst in den Zeilen 1 bis 5 ein DDS_DataReaderListener ange-legt und die Callback-Funktion, die aufgerufen wird sobald Samples vefügbar sind,in Zeile 3 zugewiesen. Anschließend wird in Zeile 7 der Listener an dem entspre-chenden DataReader-Objekt registriert. Zum Aktivieren des Discovery Service müs-sen die beiden Einstellungen FEATURE_SDDS_BUILTIN_TOPICS_ENABLED undFEATURE_SDDS_DISCOVERY_ENABLED gesetzt werden.

5.3 Generische sDDS-Erweiterungen: Geometriemodell

Das Geometriemodell, wie es im Designkapitel in Abschnitt 4.3.1 definiert wurde, wur-de auf Grund des hohen Aufwands nur soweit umgesetzt, dass die im Analysekapitelin Abbschnitt 3.1.1 beschriebenen Szenarien umgesetzt werden konnten. Bei der Imple-mentierung musste auf die generische Verwendbarkeit der geometrischen Objekte sowieauf den eingeschränkten Speicherplatz geachtet werden. Die generische Verwendbarkeitwurde dadurch erzielt, dass das Geometry-Objekt über eine Bitmaske, wie sie in Abb.5.1 zu sehen ist, angibt um welches der abgeleiteten Objekte es sich handelt. Somit istes möglich, die Objektrelationen als Interface für das generische Geometry-Objekt zudefinieren und erst als Teil der Implementierung auf das tatsächlich abgeleitete Objekteinzugehen.

Da nicht jedes der abgeleiteten Objekte in jeder Instanz verwendet wird, kann die Firm-waregröße reduziert werden, indem nur die benötigten Objekttypen aktiviert werden.Dies geschieht ebenfalls durch entsprechende #defines. Dafür muss das allgemeineGeometry-Modul durch die Angabe FEATURE_SDDS_GEOMETRY_ENABLED aktiviertwerden und beispielsweise der Objekttyp Ellipse durch FEATURE_SDDS_GEOMETRY_-ELLIPSE_ENABLED. Die Implementierung der Relationen einzelner geometrischer Ob-jekte kann ebenfalls durch #defines gezielt aktiviert werden. Dies ist möglich, da al-le Geometrietypen bereits für jede sDDS-Instanz zum Modellierungszeitpunkt bekannt

74

Kapitel 5. Implementierung 5.3. Generische sDDS-Erweiterungen: Geometriemodell

Abbildung 5.1: Bitmaske der abgeleiteten geometrischen Objekte

sind und nicht zur Laufzeit erzeugt werden können. Geometrische Objekte werden eben-falls als XML-Struktur definiert und von der Codegenerierung als entsprechende C-Strukturen erzeugt. Daraus wird anschließend der statische GeometryStore erzeugt,über welchen alle geometrischen Objekte zugreifbar sind. Quellcode 5.5 zeigt die De-finition eines Vierecks. Dabei ist zu sehen, dass die XML-Struktur die C-Struktur ex-akt abbildet und zusätzlich einen Variablennamen als Attribut des class-Elementesangibt, hier s_geo_bedroom. Weiterhin wird eine ID angegeben, unter welcher dasObjekt im GeometryStore zu finden ist, sowie der Namen des #defines, hierGEO_BEDROOM, der als Synonym für die ID verwendet werden kann. Der GPS-Referenzpunkt für das lokale Koordinatensystem wird ebenfalls über XML konfiguriert,bezieht sich jedoch auf die gesamte Anwendung und muss nicht separat für jedes einzelneObjekt angeben werden. Eine beispielhafte Angabe ist ab Zeile 11 zu sehen.

1 <geometryEntry name="GEO_BEDROOM" id="3" >

<class type="Square" name="s_geo_bedroom">

3 <attribute name="basicShape.vertex.x" value="0"/>

<attribute name="basicShape.vertex.y" value="400"/>

5 <attribute name="basicShape.vertex.z" value="0"/>

<attribute name="basicShape.width" value="400"/>

7 <attribute name="basicShape.length" value="500"/>

</class>

9 </geometryEntry>

11 <define name = "GEO_REFERENZ_X" value="50.08"/>

<define name = "GEO_REFERENZ_Y" value=" 8.33" />

Quellcode 5.5: XML-Definition eines Vierecks

75

5.4. Architekturkomponenten Kapitel 5. Implementierung

5.4 Architekturkomponenten

5.4.1 LocationFilteredTopic

Das LocationFilteredTopic umfasst die Filtersyntax und die Auswertung der Fil-ter zur Laufzeit (beschrieben in Abbschnitt 4.4.2 und 4.4.2 des Designkapitels). Somitteilte sich auch die Implementierung in zwei Teile. Das LocationFilteredTopicwird wie auch das normale Topic in XML modelliert und durch die Codegenerierung er-zeugt. Quellcode 5.6 zeigt, wie ein Filter für das Alpha-Topic in XML modelliert wird.Hierfür muss das Topic, welches gefiltert werden soll, eingebunden werden sowie allegeometrischen Objekte, die in dem Filter oder in möglichen Änderungen des Filters ver-wendet werden sollen. Anschließend kann das LocationFilteredTopic definiertwerden, das als Attribute den Namen der Variable, das referenzierte Topic und den Filter-ausdruck bekommt.

<include filename = "../topics/alpha.xml" />

2 <include filename = "../geometries/bedroom.xml" />

<topicFilter name="filteredAlpha" topic="Alpha" expression=""WITHIN

"GEO_BEDROOM"/>

Quellcode 5.6: Ortsfilter für das Topics Alpha

Die Auswertung des Filters erfolgt durch Implementierung der in Abschnitt 4.4.2 be-schriebenen Zustandsmaschine.

5.4.2 SubscriptionManager

Der SubscriptionManger und der dazugehörige SubscriptionGrpah wurdenohne Rücksicht auf geringen Speicherverbrauch implementiert, da diese Rolle durch leis-tungsstarke Geräte mit ausreichend Speicherplatz eingenommen werden soll. Somit wares möglich, eine dynamische Speicherverwaltung zu nutzen, da der Gesamtverbrauch desRAM-Speichers nicht bereits zum Kompilierzeitpunkt bekannt sein muss. Dafür wurdefür das generische Listen-Interface das Hilfsmodul DynamicLinkedList implemen-tiert, das es im Gegensatz zu den anderen verfügbaren Listenarten erlaubt, verkettete Lis-ten zu erstellen, deren Listenelemente dynamisch erstellt und gelöscht werden können.

Das Modul SubscriptionManager implementiert die im Design in Abschnitt 4.4.3beschriebene Klasse. Die Ausführung der hier definierten Schnittstellen geschieht je-doch nicht durch einen separaten Service, sondern ist im DiscoveryService und

76

Kapitel 5. Implementierung 5.4. Architekturkomponenten

ManagementTopic eingebettet und übe #defines gesteuert. Beispielhaft wird diesin Quellcode 5.7 gezeigt, wo in Zeile 4 das durch den Discovery Service empfangeneParticipant Sample an den SubscriptionManager weitergegeben wird.

1 // subscription manager

# ifdef FEATURE_SDDS_SUBSCRIPTION_MANAGER_ENABLED

3 rc_t retSM;

retSM = SubscriptionManagementService_handleParticipant(&p_data_used);

5 if (retSM != SDDS_RT_OK) {

Log_error("SubscriptionManagementService_handleParticipant failed.\n");

7 }

# endif

Quellcode 5.7: Aufruf des SubscriptionManager-Moduls

Quellcode 5.8 zeigt beispielhaft, wie das Participant Sample durch den Subscription-Manager verarbeitet wird. Die Zeilen 4 bis 16 zeigen dabei die Zeitmessung für denPerformance-Test, sodass die eigentliche Verarbeitung ab Zeile 18 geschieht. Hier wirdder SubscriptonGraph nach dem Teilnehmer durchsucht. Handelt es sich um einenbekannten Teilnehmer, gescieht nichts, ansonsten wird in Zeile 23 ein neuer Knoten er-zeugt und mit den richtigen Werten belegt (Zeilen 24 bis 26) und als Knoten eingetragen.

rc_t

2 SubscriptionManager_handleParticipant(SubscriptionManager_t* self,

SDDS_DCPSParticipant* sample) {

// Performance test RIOT

4 #ifdef SDDS_EVAL_SUBSCRIPTION_GRAPH_RIOT

List_t* n = self->subscriptionGraph.nodes;

6 if (n->size_fn(n) == 0) {

xtimer_now_timex(&start);

8 }

#endif

10 // Performace test Linux

#ifdef SDDS_EVAL_SUBSCRIPTION_GRAPH_LINUX

12 List_t* n = self->subscriptionGraph.nodes;

if (n->size_fn(n) == 0) {

14 gettimeofday(&start, NULL);

}

16 #endif

18 // search participant

ParticipantNode_t* node =

SubscriptionGraph_containsParticipantNode(&self->subscriptionGraph,

sample->data.key);

20 // if new participant

if (node == NULL) {

22 // create

ParticipantNode_t* node =

SubscriptionGraph_createParticipantNode(&self->subscriptionGraph);

77

5.4. Architekturkomponenten Kapitel 5. Implementierung

24 Locator_upRef(sample->srcAddr);

node->addr = sample->srcAddr;

26 node->id = sample->data.key;

28 // add

List_t* nodes = self->subscriptionGraph.nodes;

30 rc_t ret = nodes->add_fn(nodes, node);

if (ret != SDDS_RT_OK) {

32 Locator_downRef(sample->srcAddr);

Log_error("Unable to add new participant node.\n");

34 SubscriptionGraph_freeParticipantNode(&self->subscriptionGraph, node);

return SDDS_RT_FAIL;

36 }

Log_info("Create node %x\n", node->id);

38 }

else {

40 Log_debug("node %x exists\n", sample->data.key);

}

42return SDDS_RT_OK;

Quellcode 5.8: Nähere Betrachtung des SubscriptionManager-Moduls am Beispielder Funktion handleParticipant

Als weiteres Beispiel zeigt Quellcode 5.9 die Funktion publishSubscription-

State, die der SubscriptionManager bereitstellt um ein Abonnement zu pausierenoder zu aktivieren. Da das ManagementTopic ein generisches Interface zum verschi-cken beliebiger Key-Value-Paare bietet, muss der Aufrufer sich um die Kodierung derDaten kümmern. Dafür wird zunächst in Zeile 8 die ID des Empfägers eingetragen, um beieiner Multicast-Übertragung den Empfänger zu kennzeichnen. Anschließend muss in Zei-le 10 der Key geschriebene werden, um die entsprechende Aktion auf Empfängerseite aus-zulösen, und ab Zeile 12 der Value der Nachricht codiert, wofür die Encode-Funktionendes Marshalling-Moduls verwendet werden. Die fertig kodierte Nachricht wird dannin Zeile 22 an den Publisher des Abonnements verschickt.

1 rc_t

SubscriptionManager_publishSubscriptionState(DirectedEdge_t* edge) {

3 assert(edge);

rc_t ret;

5 // Management Sample

SDDS_DCPSManagement data;

7 // set dest id

data.participant = edge->publisher->id;

9 // set key

strcpy(data.mKey, SDDS_MANAGEMENT_TOPIC_KEY_SET_SUBSCRIPTION_STATE);

11 // encode value

int size = 0;

13 // topic ID

78

Kapitel 5. Implementierung 5.5. Implementierungsaufwand

ret = Marshalling_enc_uint8((byte_t*) data.mValue + size, &edge->topic->id);

15 size += sizeof(edge->topic->id);

// subscriber ID

17 ret = Marshalling_enc_uint16((byte_t*) data.mValue + size, &edge->subscriber->id);

size += sizeof(edge->publisher->id);

19 // state

ret = Marshalling_enc_uint8((byte_t*) data.mValue + size, (uint8_t*)&edge->state);

21 // send sample to publisher

return ManagementTopicPublicationService_publishManagementDirective(&data,

edge->publisher->addr);

23 }

Quellcode 5.9: Nähere Betrachtung der Funktion publishSubscriptionState

5.5 Implementierungsaufwand

Der folgende Abschnitt beschreibt den Implementierungsaufwand in Form von Lines of

Code (LoC). Dabei werden alle neuen Module separat betrachtet und die angepasstenModule anteilig hinsichtlich der veränderten bzw. hinzugekommen LoCs. Die Metric LoCbetrachtet Code- und Kommentarzeilen separat. Zur Auswertung wurde die Anwendungcloc unter Linux verwendet. Die exakten Werte nach Dateien aufgeschlüsselt können imAnhang A nachgelesen werden.

5.5.1 Allgemeine sDDS-Erweiterungen

Primär- und Sekundärschlüssel

----------------------------------------------------------------

File blank comment code

----------------------------------------------------------------

SUM:

same 0 116 360

modified 0 2 30

added 0 2 6

removed 32 1 154

----------------------------------------------------------------

Built-In Topics

----------------------------------------------------------------

79

5.5. Implementierungsaufwand Kapitel 5. Implementierung


----------------------------------------------------------------

SUM:

same 0 56 927

modified 0 0 14

added 0 1 2

removed 103 9 467

----------------------------------------------------------------

Discovery

----------------------------------------------------------------


----------------------------------------------------------------

SUM:

same 0 0 0

modified 0 0 0

BuiltInTopicPublicationService{*h, *c}, DiscoveryService.{*h, *c}

added 68 94 411

Discovery.h, Discovery.c

removed 51 10 288

-----------------------------------------------------------------

5.5.2 Generische sDDS-Erweiterungen

Geometriemodell

----------------------------------------------------------------

Language files blank comment code

----------------------------------------------------------------

C 13 2803 150 10334

C/C++ Header 13 185 81 373

----------------------------------------------------------------

SUM: 26 2988 231 10707

----------------------------------------------------------------

Lokationsschnittstelle

----------------------------------------------------------------

80

Kapitel 5. Implementierung 5.5. Implementierungsaufwand


----------------------------------------------------------------

C 2 41 12 158

C/C++ Header 2 15 12 35

----------------------------------------------------------------

SUM: 4 56 24 193

----------------------------------------------------------------

5.5.3 Architekturkomponenten

LocationBuiltInUpdateService

----------------------------------------------------------------


----------------------------------------------------------------

C 1 16 40 95

C/C++ Header 1 6 23 11

----------------------------------------------------------------

SUM: 2 22 63 106

----------------------------------------------------------------

LocationFilteredTopic

----------------------------------------------------------------


----------------------------------------------------------------

C 3 116 19 591

C/C++ Header 4 35 24 88

----------------------------------------------------------------

SUM: 7 151 43 679

----------------------------------------------------------------

SubscriptionManager

----------------------------------------------------------------


----------------------------------------------------------------

C 5 148 34 708

C/C++ Header 5 148 34 708

81

5.5. Implementierungsaufwand Kapitel 5. Implementierung

----------------------------------------------------------------

SUM: 9 196 58 825

----------------------------------------------------------------

ManagementTopic

----------------------------------------------------------------


----------------------------------------------------------------

C 4 146 38 588

C/C++ Header 4 29 24 78

----------------------------------------------------------------

SUM: 8 175 62 666

----------------------------------------------------------------

5.5.4 Evaluation

----------------------------------------------------------------


----------------------------------------------------------------

C 30 309 13 1317

XML 34 229 158 980

Bourne Shell 14 107 2 411

Python 1 16 14 46

----------------------------------------------------------------

SUM: 79 661 187 2754

----------------------------------------------------------------

82

Kapitel 6

Evaluation

Dieses Kapitel befasst sich mit der Evaluation der Erweiterung zur ortsbasierten Topic-Filterung für die Middleware sDDS. Dafür wird die Erweiterung sowohl nach Perfor-mance, als auch nach qualitativen Kriterien bewertet. Somit folgt zuerst eine Erläuterungder für die Evaluation nachgestellten Szenarien. Diese wurden auf den Plattformen Li-nux auf einem Raspberry Pi und RIOT auf einem ARM Cortex-M3, sodass das Testbettbeider Plattformen im darauffolgenden Abschnitt erläutert wird. Anschließend folgt diePerformance-Betrachtung und schließlich ein Abschnitt, der die Erweiterung nach quali-tativen Kriterien bewertet.

6.1 Szenarien

Für die Evaluation wurden die im Analysekapitel in Abschnitt 3.1.1 beschriebenen Sze-narien genauer definiert und für die Tests nachgestellt. Hierfür wird der in Abb. 3.1 vor-gestellte Grundriss verwendet. Abbildung 6.1 stellt die Filter dabei grafisch dar.

Szenario 1

Szenario 1 zeigt die einfachste Form der Filterung. In einem Smart Home seien Tem-peratursensoren fest verbaut. Die zentrale Heizungssteuerung abonniert die Tempera-tur aus dem Badezimmer über ein LocationFilteredTopic mit Hilfe des Filters”WITHIN GEO_BATHROOM”. Abbildug 6.1 stellt den gefilterten Bereich gelb dar unddie Position als roten Punkt. Die Heizungssteuerung kann auf diese Weise über den ge-filterten DataReader explizit nur Temperatur-Samples aus dem Badezimmer erhalten

83

6.1. Szenarien Kapitel 6. Evaluation

Abbildung 6.1: Grafische Darstellung der Filter aus den drei Szenarien

und die Verarbeitung somit auf diese beschränken. Das Szenario soll mit einem Subscri-ber, dem SubscriptionManager und bis zu n Publishern durchgeführt und evaluiertwerden.

Szenario 2

Szenario 2 vervollständigt den im ersten Szenario betrachteten Ansatz. Neben der ausdem Badezimmer abonnierten Temperatur soll auch die Temperatur aus dem Wohnzim-mer, dem Schlafzimmer und der Küche über ein separates LocationFilteredTopicabonniert und somit je nach Raum eine kontextabhängige Verarbeitung ermöglicht wer-den. Es werden somit vier separate LocationFilteredTopics mit den Filtern”WITHIN GEO_BATHROOM”, ”WITHIN GEO_BEDROOM”. ”WITHIN GEO_LIV-

INGROOM” und ”WITHIN GEO_KITCHEN” angelegt. Diese werden in Abb. 6.1 alsblaue Flächen markiert und Position der Sensore wieder mit einem roten Punkt. Das Sze-nario soll mit dem SubscriptionManager, vier bis n Publishern, einem Subscriber,der alle vier gefilterten Topics abonniert, zwei Subscribern, die jeweils zwei gefilterteTopics abonnieren und vier Subscribern, von denen jeder jeweils ein gefiltertes Topicabonniert, durchgeführt und evaluiert werden.

Szenario 3

Szenario 3 konzentriert sich auf die Auswertung eines etwas komplexeren Filteraus-drucks. Der Filter soll Daten aus den Bereichen zwischen Wohnzimmer und Kücheoder Wohnzimmer und Flur empfangen. In Abb. 6.1 werden diese Bereiche grün dar-

84

Kapitel 6. Evaluation 6.2. Testbett

gestellt und die Positionen, die den Filter erfüllen als rote Punkte. Der gestrichel-te Pfad entspricht dem Pfad auf dem sich der Staubsaugroboter bewegt. Diese Be-reiche sollen kritische Stellen darstellen, an denen der Roboter öfters hängen bleibt,sodass die Smart-Home-Steuerung das Status-Topic des Staubsaugroboters über einLocationFilteredTopic abonnieren kann, um ein Feststecken zu erkennen unddie Bewohner des Smart Home alarmieren zu können. Der Filterausdruck sähe dafür fol-gendermaßen aus ”(WITHIN GEO_LIVINGROOM AND WITHIN GEO_KITCHEN)

OR (WHITHIN GEO_LIVINGROOM AND WITHIN GEO_HALLWAY)”. Da die Fil-tersyntax jedoch keine Klammerung vorsieht, muss der Ausdruck wie folgt umgestelltwerden: ”WITHIN GEO_KITCHEN OR WHITHIN GEO_HALLWAY AND WITHIN

GEO_LIVINGROOM”. Da die Auswertung sequentiell von links nach rechts stattfindetund dadurch eine impliziete Klammerung stattfindet, muss darauf geachtet werden, dassder Teilausdruck ”WITHIN GEO_KITCHEN OR WHITHIN GEO_HALLWAY” zuerstausgewertet wird, da dieser nach Anwendung des Distributivgesetzes geklammert seinmüsste.

6.2 Testbett

Für die Performance-Betrachtung werden die erläuterten Szenarien auf den PlattformemLinux und RIOT OS umgesetzt. RIOT OS ist ein Betriebssystem, das insbesondere aufden Einsatz im Bereich Internet der Dinge ausgelegt ist. Es basiert auf einer Mikrokernar-chitektur, ist echtzeitfähig und zeichnet sich besonders durch einen geringen Footprint undhohe Energieeffizienz aus [?]. Es handelt sich dabei um ein open source Betriessystem,das durch die Freie Universität Berlin, das französischen Forschungsinstitut Inria und dieHochschule für angewandte Wissenschaften Hamburg entwickelt wird. Die Lokalisierungwird für alle Knoten als infrastrukturbasierte Lokalisierung simuliert. Dafür gibt es einenausgewählten sDDS-Knoten, der eine Position über den Built-In-Topic-Mechanismus pu-bliziert. Für die Simulation stationärer Knoten wird die Position einmal bestimmt undanschließend in dem festgelegten Intervall publiziert. Für die Simulation eines mobilenKnotens muss eine Route als Koordinatenabfolge definiert werden. Die Koordinaten die-ser Route werden von der Simulation nacheinander dem mobilen Knoten als Positionzugewiesen. Die Position wird jedoch nicht mit jeder Änderung, sondern wie auch beistationären Knoten in einem vorgegebenen Intervall publiziert.

85

6.2. Testbett Kapitel 6. Evaluation

Linux-Testbett

Unter Linux wurde die Evaluation auf einem Raspberry Pi Cluster durchgeführt, welches20 Raspberry Pis Modell 1B+ über ein Gigabit-Switch von HP zusammenschließt. JederPublisher und Subscriber, der SuscriptionManager sowie die Lokationssimulationwerden auf einem separaten Gerät ausgeführt.

RIOT-Testbett

Die RIOT-Version der Tests lief auf dem Testbett ”Iot-Lab” des FIT Konsortiums, wel-ches ein Zusammenschluss von fünf großen, französischen Einrichtungen für Lehre undForschung ist. Dabei handelt es sich um Université Pierre et Marie Curie (UPMC), Inria,Université de Strasbourg, Institut Mines Télécom und CNRS [con]. Als Hardware wurdefür die Tests der STM32F1, ein ARM Cortex-M3 Mikrocontroller mit 72 Mhz Taktungund 64 kB RAM verwendet.Die Kommunikation erfolgte über 6LoWPAN. Das Testbettbesteht aus mehreren Standorten, die alle mitainender verbunden sind. Für die Evaluationwurde der Standort Grenoble verwendet, wo 382 M3-Knoten zur Verfügung stehen. DieVerfügbarkeit der Knoten kann über das Webinterface eingesehen werden. Freie Knotenkönnen für einen bestimmten Zeitpunkt gebucht werden. Dafür wird ein Experiment ge-bucht, über welches jedem Knoten eine Firmware zugewiesen werden kann, die zu demdefinierten Zeitpunkt auf die Knoten aufgespielt und gestartet wird. Dies kann über dasWebinterface erfolgen, oder über Kommandozeilenanwendungen, die über einen entfern-ten Zugriff auf Linux-Rechnern der IoT-Labs ausgeführt werden. Für diese Evaluationwurden die Kommandozeilenanwendungen verwendet, da die Test dadurch über Skriptegesteuert werden konnten.

Weiterhin ist ein Routing von Multicastadressen in RIOT nur für Link-lokale-Adressenimplementiert, sodass der SubscriptionManager, der dafür entworfen ist, auf einemleistungsstarken Rechner mit ausreichend Speicherplatz zu laufen, ebenfalls auf einemder STM2F1 laufen musste und aus Speicherplatzgründen nur ein Graph mit maximalacht Subscriptions aufgebaut werden konnte. Um die Ergebnisse vergleichbar zu halten,wurden die Szenarien auf den Raspberry Pis ebenfalls auf acht Subscriptions beschränkt,auch wenn der Speicherplatz hier mehr zugelassen hätte.

86

Kapitel 6. Evaluation 6.3. Performance-Betrachtung

6.3 Performance-Betrachtung

Für die Performance-Betrachtung werden die drei erläuterten Szenarien auf den Plattfor-men Linux und RIOT durchgeführt und Messungen für die folgenden Kriterien durchge-führt:

Dauer, einen Filter zu setzenHierfür soll die Ausführungszeit der Funktion ”LocationFilteredTopic_

setFilter” vermessen werden, bei der die Stringrepräsentation eines Filteraus-drucks binär kodiert und einer LocationFilteredTopic-Instanz zugewiesenwird.

Dauer der FilterauswertungHierbei wird die Ausführungszeit der Funktion ”LocationFilteredTopic_evalExpression” gemessen, die einen binär kodierten Filterausdruck auswer-tet und die geforderten geometrischen Berechnungen durchführt.

Dauer zum vollständigen Aufbau des Subscription-GraphenHierfür wird die Ausführungszeit gemessen, die der SubscriptionManagerbenötigt, um alle Teilnehmer, Subscriptions und die zugehörigen Filter zu erfassenund damit einen vollständigen Graphen aufzubauen. Der Startzeitpunkt der Mes-sung ist das Registrieren des ersten Teilnehmers. Der Endzeitpunkt ist erreicht,wenn die definierte Anzahl an Kanten und Filtern erreicht wurde. Diese ist für dasjeweilige Szenario bekannt und wird zum Modellierungszeitpunkt als Konstantefestgelegt.

Vorteil durch die OptimierungWeiterhin soll untersucht werden, mit welchen Kriterien und Teilnehmerzahlen dieOptimierung durch den SubscriptionManager einen Nutzen bringt und wannder Overhead durch die zusätzlichen Management-Nachrichten den Nutzen über-wiegt.

6.3.1 Analytische Betrachtung der Optimierung

Die Optimierung durch den SubscriptionManagers lohnt sich, wenn die Gesamt-zahl der verschickten Nachrichten zusammen mit den durch den SubscriptionManagerhinzukommenden Management-Samples kleiner ist als die Anzahl der Nachrichten, die

87

6.3. Performance-Betrachtung Kapitel 6. Evaluation

ohne Optimierung verschickt werden. Um die erwartete Anzahl der verschickten Nach-richten zu berechnen, lässt sich folgende Formel verwenden:

N = Participant Samples+ Publication Samples

+ Subscription Samples+Data Samples+Management Samples

Die Gesamtzahl N aller Nachrichten ergibt sich also aus der Gesamtzal der Participant,Publication, Subscription, Data und Management Samples.

Participant Samples = participants× 60sparticipantT imerSec

participants = subs+ pubs+ 1

Die Gesamtzahl der Participant Samples ergibt sich aus der Anzahl der Teilnehmer malder Anzahl pro Minute versendeter Participant Samples. Die Teilnehmer umfassen allePublisher und Subscriber im Netzwerk sowie den SubscriptionManager, da sichdieser ebenfalls am Discovery beteiligt.

Publication Samples = pubs× 60spublicationT imerSec

Die Gesamtzahl der Publication Samples ergibt sich aus der Anzahl der Publisher mal derAnzahl pro Monite verschickter Publication Samples.

Subscription Samples = Publication Samples× subs

Bei der Anzahl der Subscription Samples handelt es sich um die obere Schranke. Hierfürwird die Anzahl der Publication Samples mit der Anzahl der Subscriber multipliziert.Da ein Subscription Sample jedoch nur versendet wird, wenn sich der Subscriber für dasTopic interessiert, kann die Gesamtzahl der Subscription Samples auch geringer sein. Fürdie hier betrachteten Szenarien entspricht jedoch die maximale Anzahl der Samples auchder tatsächlichen Anzahl, da sich jeder Subscriber für jede Publikation interessiert.

Data Samples = 60sdataT imerSec

× (pubs− pausedPubs)

Die Gesamtzahl der Daten Samples ergibt sich aus der Anzahl pro Minute versende-ter Daten Samples mal der Anzahl der Publisher, wobei hier im optimierten Fall, wennpausedPubs > 0, nur die aktiven Publisher betrachtet werden.

Management Sample = (SubscriptionSamples× 2) + ( 60spauseT imerSec

∗ pausedPubs)

Die maximale Amtzahl der Management Samples ergibt sich aus der doppelten Anzahlder Subscription Samples, weil für jede Subscription der Filter durch den Subscrip-tionManager angefordert wird und vom Subscriber zugeschickt wird, und der Anzahlpro Minute verschickter Pauseanweisungen für jeden pausierten Publisher. Da die Szena-rien nur gefilterte Subscriptions betrachten entspricht die maximale Anzahl der Samplesauch der tatsächlichen Anzahl.

88


Die Formel wurde durch Messungen überprüft; dabei wurden ein Subscriber und vier Pu-blisher verwendet, von denen drei pausiert wurden. Das Management-Sample zum Pau-sieren wurde dabei jede Sekunde, also 60 mal pro Minute verschickt. Tabelle 6.2 zeigtdie erwarteten Nachrichten und Tabelle 6.1 die tatsächlich gezählte Nachrichten, die nurgeringfügig von der Annahme abweichen. Dies liegt hauptsächlich daran, dass bei derzyklischen Publikationen, die exakt auf die sechzigste Sekunde fällt, diese Nachrichtenmitgemessen wurden und sie bei der genauen analytischen Betrachtung nicht mehr indem betrachteten Intervall liegen. Das fällt besonders beim Vergleich der Participant undPublication Nachrichten auf, die jede fünf Sekunden publiziert wurden. Die Messung undauch analytische Betrachtung wurden für folgende Einstellungen durchgeführt:

• 1 SubscriptionManager

• 1 Subscriber

• 4 Publisher, davon 3 pausiert

• 6 Data Samples pro Minute

• 12 Participant Samples pro Minute

• 12 Publication Samples pro Minute

• 60 Management (Pause) Samples pro Minute

Node Par Pub Sub Data Mngmt GesamtSubscriptionManager 12 0 0 0 228 240Subscriber 12 0 48 0 48 108Publisher (1) 12 12 0 6 0 30Publisher (2) 12 12 0 1 0 24Publisher (3) 12 12 0 0 0 24Publisher (4) 12 12 0 0 0 24Gesamt 72 48 48 6 276 450

Tabelle 6.1: Erwartete versendete Nachrichten

6.3.2 Evaluationsergebnisse

Für die Messungen wurde unter Linux gettimeofday und unter RIOT xtimer-

_now_timex verwendet. Die Verwendung der genannten Systemfunktionen zum Mes-sen der Zeit verursachten einen Messfehler unter Linux im Mittel von 1,032 µs bei einer

89


Standardabweichung von 9,351 µs und unter RIOT exakt 4 µs bei einer Standardabwei-chung von 0 µs. Abbildung 6.2 trägt die Messpunkte von gettimeofday in einemVerlauf auf. Dieser zeigt jedoch, dass die Ausreißer keinem Schema folgen, sondern eherzufällig wirken.

Abbildung 6.2: Dauer der Ausführung von gettimeofday in 30.000 Iterationen

6.3.2.1 Szenario 1

Filter setzen

Das Umwandeln der Stringrepräsentation des Filters in eine binäre Darstellung dauert imMittel auf beiden Plattformen etwas gleich lange. Für das erste Szenario wurde ein ein-zelner Filterausdruck kodiert, wofür mit Hilfe der Funktion strcmp die Art der Relationuntersucht wurde und anschließend die ID des Geometry-Objektes in einen Integer um-gewandelt wurde. Es fällt auf, wie man den Ergebnissen aus der Tabelle 6.3 entnehmen

Node Par Pub Sub Data Mngmt GesamtSubscriptionManager 13 0 0 0 220 233Subscriber 13 0 42 0 39 94Publisher (1) 13 13 0 7 0 33Publisher (2) 13 13 0 1 0 27Publisher (3) 13 13 0 0 0 26Publisher (4) 13 13 0 0 0 26Gesamt 78 52 42 8 259 439

Tabelle 6.2: Gezählte versendete Nachrichten

90


kann, dass das Maximum und die Standardabweichung unter Linx auf dem Raspberry Piweit über dem Durchschnitt liegt, wohingegen diese Werte unter RIOT auf dem Cortex-M3 kaum abweichen. Dies könnte mit dem Scheduling unter Linux zusammenhängen,oder mit eingehenden Interrupts, beispielsweise durch den Netzwerkcontroller.

Linux RIOTavg 36,26 us 38 usmin 32 us 37 usmax 211 us 38 usstdabw. 10,34 us 0,07 us

Tabelle 6.3: Ausführungszeit der Funktion setFilter in Szenario 1

Filter auswerten

Tabelle 6.4 zeigt die Messergebnisse der Filterauswertung. Dafür wird die Binärform desFilters verarbeitet. Die Position wird der Funktion bereits übergeben, dann wird die ent-sprechende Relation aufgerufen und die Berechnung durchgeführt. Die Ausführungszeitist unter Linux auf dem Raspberry Pi im Mittel etwas mehr als doppelt so schnell, jedochliegt auch hier das Maximum sehr weit über dem Mittelwert und ist vermutlich ebenfallsdem Schedulingverhalten geschuldet.


Tabelle 6.4: Ausführungszeit der Funktion evalFilter in Szenario 1

Subscription-Graph aufbauen

Die Messung der Dauer bis zum Aufbau eines vollständigen Subscription-Graphen wurdemit einem Subscriber und bis zu 8 Publishern durchgeführt. Die Publication der Partici-pantID und des Publication-Topics wurden für das Discovery auf 5 Sekunden eingestellt.Das Subscription-Topic wird als direkte Reaktion auf das Publication-Topic versandt undnimmt somit ebenfalls einen 5 Sekunden-Zyklus ein. Da der SubscriptionManager

91


den Graphen durch das Beobachten des Discovery-Mechanismusses aufbaut, ist die Maxi-male Geschwindigkeit an den Zyklus der Discovery-Built-In-Topics gebunden. Die mitt-lere Dauer liegt unter Linux bei einem bis vier Publishern bei etwas mehr als 10 Sekunden,was zwei Discovery-Zyklen entspricht und steigt bei acht Publishern auf etwas mehr alsdrei Zyklen an. Das hohe Maximum und die hohe Standardabweichung zeigen, dass dieZeiten hier sehr stark schwanken und vermutlich von der sonstigen Auslastung des Pisabhängen. Auf dem Cortex-M3 hingegen ist bei bis zu zwei Publishern im Mittel nur einDiscovery-Zyklus nötig, um den Graphen aufzubauen. Bei vier Publishern sind es bereitszwei Zyklen und bei acht Publishern sogar acht Zyklen. Der SubscriptionManagerist jedoch nicht dafür ausgelegt auf einem leistungsschwachen Mikrocontroller wie demCortex-M3 zu laufen.

Solange der Subscrption-Graph nicht vollständig aufgebaut ist, kann der Subscrip-tionManager Fehlentscheidungen treffen. Insbesondere wenn ein Subscriber meh-rere Filter für das gleiche Topic hat und noch nicht alle Filter an den Subscrip-

tionManager propagiert wurden, kann die Subscription fälschlicherweise pausiertwerden. Dies tritt jedoch nur in der Anfangsphase auf und ist vergleichbar mit demZustand anderer DDS-Implementierungen, in deen ContentFilter zwar von derAnwendung bereits gesetzt, aber von der Middleware noch nicht durchgesetzt wur-den. Eine mögliche Gegenmaßnahme, um zumindest den Verlust von Datensamplesdurch fehlerhafte Optimierung zu vermeiden, wäre eine vorgeschrieben Dauer, die derSubscriptionManager abwarten muss, bis ein Pausieren als ”sicher” angesehenwerden kann.

LinuxPub 1 2 4 8avg 10,09 s 10,49 s 10,65 s 17,49 smin 7,42 s 9,97 s 9,89 s 9,97 smax 14,97 s 15 s 16,84 s 64,97 sstdabw. 900,95 ms 1,5 s 1,68 s 13,25 s

RIOTavg 5,01 s 4,63 s 10,22 s 45,08 smin 5,02 s 15,01 s 35,05 s 320 smax 5,02 s 15,01 s 35,05 s 320 sstdabw. 1,88 ms 2,41 s 6,6 s 46,6 s

Tabelle 6.5: Ausführungszeit bis Subscription-Graph vollständig

92


Nutzen der Optimierung durch den SubscriptionManager

Für das erste Szenario ergibt sich somit, dass der Pause-Status maximal alle 2 Sekundenpropagiert werden darf und 7 von 8 Publishern pausiert sein müssen, damit die Optimie-rung einen Zweck hat (siehe Abb. 6.3). Ein besseres Ergebnis erziehlt man mit einemPropagieren des Pause-Status alle 5 Sekunden (siehe Abb. 6.4), wo sich die Optimierungdann bereits ab fünf pausierten Publishern lohnt.

Abbildung 6.3: Sinnvolle Nutzung der Optimierung durch denSubscriptionManager (Pause 2 Sek)

6.3.2.2 Szenario 2

Das Setzen und Auswerten des Filterausdrucks wurde für das zweite Szenario nicht se-parat gemessen, da dieser Vorgang dem ersten Szenario entspricht. Stattdessen wurde dieGrenze, ab welcher eine Optimierung sinnvoll ist, betrachtet. Insbesondere wenn es vierseparate Subscriber gibt, kann eine Optimierung erst in Betracht gezogen werden, wennder Pause-Status nur einmal alle 60 Sekunden propagiert wird und mindesten sieben vonacht Publishern pausiert sind (siehe Abb. 6.5). Allgemein lässt sich sagen, dass, je höher

93


Abbildung 6.4: Sinnvolle Nutzung der Optimierung durch denSubscriptionManager (Pause 5 Sek)

das Verhältnis von Publishern zu Subscribern ist, sich desto eher eine Optimierung durchden SubscriptionManager lohnt. Neben der Anzahl der Nachrichten ist ein weite-rer wichtiger Punkt die Ausführungszeit, um den Filterausdruck zu evaluieren. Da jedeseingehende Daten-Sample überprüft wird, kann dies einen Subscriber bei vielen Datensehr stark auslasten. Sind unter diesen Daten viele irrelevante Samples, kann dies durchdas Pausieren der Subscription reduziert werden. Somit muss bei der Entscheidung eineOptimierung durch den SubscriptionManager zu verwenden, nicht nur die allg-meine Last des Netzwerks berücksichtigt werden, sondern auch die Leistungsfähigkeitder Subscriber und unnötige Auswertung der Ortsfilter.

6.3.2.3 Szenario 3

Filter setzen

Der Filterausdruck des dritten Szenarios besteht aus insgesamt drei Teilausdrücken. Aufdem Raspberry Pi dauert das Kodieren und Setzen des Ausdrucks nur minimal länger alsim ersten Szenario. Auf dem Cortex-M3 hingegen dauert es etwa drei mal so lange wieim ersten Szenario. Dies lässt darauf schließen, dass das eigentliche Kodieren und setzen

94


Abbildung 6.5: Sinnvolle Nutzung der Optimierung durch denSubscriptionManager mit mehreren Subscribern

des Filters auf dem Pi nur einen Bruchteil der Zeit ausmachen kann und die gemesseneZeitspanne durch andere bisher unbekannte Seiteneffekte entsteht.


Tabelle 6.6: Ausführungszeit der Funktion setFilter in Szenario 3

Filter auswerten

Das Auswerten des komplexeren Filters dauert wie erwartet auf beiden Plattformen län-ger als der weniger komplexe Ausdruck, und ebenfalls wie erwartet ist der Cortex-M3langsamer in der Ausführung. Wie bereits bei den anderen Ergebnissen ist der maximaleMesswert auf dem Raspberry Pi sehr weit entfernt von dem Mittelwert, woraus zu vermu-ten ist, dass die Ausführungszeit stark von den weiteren Aktivitäten abhängt.

95

6.4. Betrachtung qualitativer Kriterien Kapitel 6. Evaluation

6.3.3 Zusammenfassung

Sowohl das Setzen als auch das Auswerten des Ortsfilters läuft wie erwartet auf demRaspberry Pi wesentlich schneller als auf dem M3, wodurch sich die Designentscheidungbestätigt, den SubscriptionManager für den Einsatz auf leistungsfähigen Gerätenzu konzipieren, da dieser in größeren Netzwerken sehr viele Filter verwalten und auswer-ten muss. Die Optimierung durch den SubscriptionManager lohnt sich, wenn derFokus daruaf liegt, den Datenverkehr zu reduzieren, wenn es viele Publisher und wenigSubscriber für ein Topic gibt und zudem viele der publizierten Samples herausgefiltertwerden. Die Auswertungszeit des Filters auf den M3-Knoten zeigt jedoch, dass sich eineOptimierung auch lohnen kann, um den Rechenaufwand der Subscriber zu reduzieren.

6.4 Betrachtung qualitativer Kriterien

Dieser Abschnitt stellte eine qualitative Betrachtung der Modularität der Architektur an.Weiterhin wird der Aufwand bewertet die Erweiterung auf andere Plattformen zu portie-ren, die Größe des Footprints sowie der Aufwand, die Performance-Tests durchzuführen.

6.4.1 Modularität der Architektur

Die Modularität der Architektur erwies sich gut angesetzt. Die Funktionalität konnte gutgekapselt und jedes Modul unabhängig implementiert werden. Dies war jedoch erst mög-lich, nachdem fehlende Funktionalität implementiert wurde und die vorhandene Imple-mentierung sauberer modularisiert wurde.

6.4.2 Portierung auf andere Plattformen

Das Portieren der Erweiterung zur ortsbasierten Topic-Filterung auf andere Plattformenist sehr einfach, da der gesamte Erweiterungscode plattformunabhängig ist und ledig-

Linux RIOTavg 36,62 us 81,57 usmin 35 us 66 usmax 3323 us 107 usstdabw. 104,3 us 14,78 us

Tabelle 6.7: Ausführungszeit der Funktion evalFilter in Szenario 3

96

Kapitel 6. Evaluation 6.4. Betrachtung qualitativer Kriterien

lich die Schnittstelle für die Lokalisisierung mit den Funktionen getLocation undgetDeviceLocation umgesetzt werden muss.

6.4.3 Footprint

Tabelle 6.8 zeigt den Footprint der für die Erweiterung neu entstandenen Module.Da die Implementierung des LocationBuiltInTopics im bereits existierendenBuiltinTopic-Modul verankert ist, wird hier für dieses Modul nur der durch dieLocationBuiltInTopics zusätzlich entstandene Umfang aufgeführt.

Modul text (B) data (B) bss (B) gesamt (B)BuiltInLocationUpdateService 1369 0 352 1721+BuiltinTopic +1192 0 0 +904BuiltInTopicPublicationService 1402 0 8 1410DiscoveryService 2008 240 0 2248DynamicLinkedList 1097 0 0 1097FilteredDataReader 443 0 0 443FilterEvaluator 258 0 0 258Geometry 1476 0 0 1476Geometry_Ellipse 895 0 0 895Geometry_Point 208 0 0 208Geometry_Square 235 0 0 235GeometryStore 84 0 0 84LocationService 97 0 0 97LocationTrackingService 1090 0 432 1522LocationFilteredTopic 2660 0 0 2660ManagementTopic 0 0 0 0ManagementTopicDataWriter 928 0 0 928ManagementTopicPublicationService 407 0 0 407ManagementTopicSubscriptionService 1726 0 0 1726SubscriptionGraph 2372 0 0 2372SubscriptionManagementService 601 0 32 633SubscriptionManager 3236 0 0 3236

Tabelle 6.8: Footprint-Betrachtung für die neuen Module

Publisher mit infrastrukturbasierter LokalisierungFür die Rolle eines Publishers, der die Lokalisierung und Verbreitung der Ortsinfor-mation der Infrastruktur überlässt, werden nur die vier Module des Management-Topics benötigt.

97


Publisher mit SelbstlokalisierungFührt der Publisher seine Lokalisierung selbt durch, werden zusätzlich auch die Mo-dule LocationTrackingService, LocationService, Geometry_-

Ellipse, Geometry_Point, Geometry, BuiltInTopicPublica-

tionService und BuiltinTopic benötigt.

SubscriberFür die Rolle des Subscribers werden die Module DynamicLinkedList, Fil-terEvaluator, LocationService, LocationTrackingService, Sub-scriptionGraph, SubscriptionManagementService und Subscrip-tionManager nicht benötigt.

SubscriptionManager

Für die Rolle des SubscriptionManagers werden alle Module bis aufLocationService und LocationTrackingService benötigt.

Rolle text (B) data (B) bss (B) gesamt (B)Publisher (infra. Lok.) 3061 0 0 3061Publisher (selbstlok.) 10790 0 792 11294Subscriber 15033 240 360 15345SubscriptionManager 22597 240 392 22941

Tabelle 6.9: Footprint-Betrachtung für Rollen

Für die Rolle des SubscriptionManagers wird der meiste Speicherplatz benötigt,jedoch ist es immer noch klein genug, um auch auf eingebetteten Geräten wie demSTM32F1 laufen zu können. Geräte, die als Publisher agieren kommen mit dem ge-ringsten Speicherplatz aus, insbesondere, wenn die Lokalisierung nicht durch das Gerätselbst übernommen wird. Alle hier betrachteten Werte beziehen sich nur auf die sDDS-Erweiterung. Für die tatsächliche Firmwaregröße muss auch der restliche Middleware-Code sowie die gewählten Topics betrachtet werden.

6.4.4 Aufwand für Performance-Tests

Die Szenarien waren durch die Simulation der Lokalisierung einfach umzusetzen. Esmussten dafür nur Anwendungen für die drei Rollen: SubscriptionManager, Sub-scriber und Publisher angelegt werden sowie die Simulation der Lokalisierung. Für die

98

Kapitel 6. Evaluation 6.4. Betrachtung qualitativer Kriterien

Szenarien musste anschließend nur noch die XML-Konfiguration angepasst werden undeinige Ausgaben der Main-Loop, um die Logs eindeutiger zu machen. Insbesondere dieRolle des Publishers konnte unverändert für mehrere Publisher verwendet werden, da ei-ne infrastrukturbasierte Lokalisierung simuliert wurde und die Position somit unabhängigvon der Anwendung der Publisher für die Szenarien geändert werden konnte.

99


100

Kapitel 7

Zusammenfassung

Im Rahmen der Master-Thesis sollte eine ortsbasierte Topic-Filterung für die datenzen-trierte Middleware sDDS konzipiert, implementiert und evaluiert werden. Ziel der Erwei-terung ist es, Subscribern zu ermöglichen, Daten-Samples anhand ihres Entstehungsortesfiltern zu können und die Filterung dabei auch auf Daten mobiler Knoten anwenden zukönnen. Die Aufgabenstellung wurde vollständig umgesetzt und damit folgende Ziele er-füllt:

• Die ortsbasierte Topic-Filterung wurde zum DDS-Standard vollständig API-kom-patibel umgesetzt.

• Das Design kapselt Teilfunktionalitäten so, dass die Architektur sehr stark modula-risiert werden kann und somit eine individuelle Firmware mit genau den Funktionenerzeugt werden kann, die von der Rolle des Gerätes benötigt werden.

• Das Design geht auf die speziellen Bedürfnisse ressourcenbeschränkter Hardwareein und sparsam mit diesen um.

• Die ortsbasierte Topic-Filterung kapselt plattformspezifischen Code durch saubergetrennte Interfaces wodurch die Portierung dieser erleichtert wird.

• Die sDDS-Erweiterung bietet eine Filtersyntax zum Formulieren eines ortsbasiertenFilters. Dafür wurde ein Modell entwickelt, das es ermöglicht Ortsinformationen zudefinieren und miteinander in Relation zu setzen.

• Neben dem einfachen gefilterten Zugriff auf die Daten bietet die sDDS-Erweiterungauch eine Möglichkeit, den Datenverkehr zu optimieren indem die Übertragunggefilterter Daten verhindert wird.

101

Kapitel 7. Zusammenfassung

• In einer Evaluation wurde das Design und die Implementierung untersucht undBetrachtungen zu qualitativen und quantitativen Merkmalen aufgestellt. Diese Be-trachtungen erfolgten für drei Szenarien aus dem Bereich Smart Home, sodass diedabei entstandene Ergebnisse in das Forschungsprojekt, in welchem die Master-Thesis eingebettet ist, einfließen können.

Das Design und die dadurch bestimmte Modularisierung erwiesen sich als sinnvoll, dadiese problemlos umgesetzt werden konnten. Bei der Performance-Messung traten je-doch einige Probleme auf, welche erste Versionen der Messungen unbrauchbar gemachthatten, sodass die gesamten Messreihen mehrfach wiederholt werden mussten. Das ers-te Problem bestand darin, dass bei der Systemabstraktion von Timern in RIOT ein Fehlervorlag, der die Umrechnung von Mikrosekunden in Millisekunden betraf war und dadurchalle Zeitmessungen verfälschte. Nach Beseitigung dieses Problems konnte die korrekteZeit gemessen werden, wobei diese erneute Messung vorgab, dass der ARM Cortex-M3einen Filter fast doppelt so schnell auswerten kann wie ein Raspberry Pi. Dieses auf-fällige, abwegige Ergebnis kam dadurch zustande, dass Anwendungen für RIOT nichtüber das sDDS-eigene Makefile kompiliert wurden, sondern über das RIOT-Makefile,wodurch die RIOT-Anwendungen mit Optimierung kompiliert wurden, wohingegen dieLinux-Anwendungen explizit ohne Optimierung kompiliert wurden, sodass die Messwer-te nicht miteinander vergleichbar waren. Die Linux-Anwendungen wurden aus diesemGrund mit den selben Optimierungen kompiliert und das Problem dadurch schließlichgelöst.

Durch die Master-Thesis entstand ein Konzept zur ortsbasierten Topic-Filterung, das mitFokus auf die Funktionalität umgesetzt wurde. Als nächsten Schritt ist es notwendig, dasGeometriemodell vollständig auszuimplementieren, da die aktuelle Implementierung nurObjekte und Relationen abdeckt, die nötig sind, um die betrachteten Szenarien umzuset-zen. Anschließend können Optimierungen vorgenommen werden. Zum einen kann Klam-merung in der Filtersyntax als optionale Erweiterung umgesetzt werden, um bei Bedarfeine mächtigere Grammatik zu bieten, und zum anderen kann für den SubscriptionMana-ger eine separate Implementierung der Filterauswertung umgesetzt werden, die auf Per-formanz und nicht auf Speicherverbrauch optimiert ist. Weiterhin kann der Subscription-Graph durch Hash Tables optimiert werden, um den Zugriff auf Knoten und Kanten zubeschleunigen. Neben der Optimierung können auch zusätzliche Test durchgeführt wer-den. Die durchgeführten Performance-Tests betrachten derzeit nur Messungen auf einemeinzelnen Knoten, sodass im nächsten Schritt der Gesamtablauf betrachtet werden sollte.

102


Die sDDS-Erweiterung zur ortsbasierten Topic-Filterung entstand im Rahmen des For-schungsprojektes sDDS4SmartHome, das als Kooperation zwischen dem Labor für Ver-teilte Systeme der Hochschule RheinMain und der Hochschule Darmstadt durchgeführtwird, und das die Nutzung von sDDS im Smart Home evaluiert. Im Rahmen des For-schungsprojektes wird die Middleware für dieses Einsatzgebiet erweitert und ein Smart-Home-Szenario umgesetzt, für das auch die ortsbasierte Topic-Filterung eingesetzt wer-den kann. Neben dem Gebiet Smart Home ist ein Einsatz der sDDS-Erweiterung überalldort möglich, wo die Verarbeitung der Daten von ihrem Standort abhängt. Im Bereich In-dustrie 4.0 kann somit das Smart-Home-Szenario einfach auf eine Fabrik oder Lagerhalleübertragen werden. Weiterhin wäre es möglich, die ortsbasierte Topic-Filterung beispiels-weise auch beim Transport, oder als Form der Diebstahlsicherung einzusetzen.

103


104

Anhang A

Implementierungsaufwand

A.1 Allgemeine sDDS-Erweiterungen

A.1.1 Primär- und Sekundärschlüssel

----------------------------------------------------------------


----------------------------------------------------------------

History.c

same 0 47 274

modified 0 2 16

added 0 1 6

removed 4 1 25

----------------------------------------------------------------

Topic.c

same 0 17 41

modified 0 0 7

added 0 0 0

removed 21 0 102

----------------------------------------------------------------

Topic.h

same 0 52 45

modifie 0 0 7

added 0 1 0

removed 7 0 27

----------------------------------------------------------------

105

A.1. Allgemeine sDDS-Erweiterungen Anhang A. Implementierungsaufwand

SUM:

same 0 116 360

modified 0 2 30

added 0 2 6

removed 32 1 154

----------------------------------------------------------------

A.1.2 Built-In Topics

----------------------------------------------------------------


----------------------------------------------------------------

BuiltinTopic.c

same 0 22 755

modified 0 0 9

added 0 1 2

removed 97 9 406

----------------------------------------------------------------

BuiltinTopic.h

same 0 34 172

modified 0 0 5

added 0 0 0

removed 6 0 61

----------------------------------------------------------------

SUM:

same 0 56 927

modified 0 0 14

added 0 1 2

removed 103 9 467

----------------------------------------------------------------

A.1.3 Discovery

----------------------------------------------------------------


----------------------------------------------------------------

SUM:

same 0 0 0

106

Anhang A. Implementierungsaufwand A.2. Generische sDDS-Erweiterungen

modified 0 0 0

BuiltInTopicPublicationService{*h, *c}, DiscoveryService.{*h, *c}

added 68 94 411

Discovery.h, Discovery.c

removed 51 10 288

-----------------------------------------------------------------

A.2 Generische sDDS-Erweiterungen

A.2.1 Geometriemodell

----------------------------------------------------------------


----------------------------------------------------------------

Geometry_Ellipse.c 241 12 989

Geometry_Square.c 228 12 832

Geometry_LineString.c 227 12 828

Geometry_LineRing.c 227 12 828

Geometry_PolyhedralSurface.c 228 12 828

Geometry_EllipseExtrusion.c 230 12 828

Geometry_SquareExtrusion.c 228 12 828

Geometry_Polygon.c 227 12 828

Geometry_Line.c 227 12 828

Geometry_PolyhedralSurfaceExtrusion.c

229 12 828

Geometry_PolygonExtrusion.c 229 12 828

Geometry_Point.c 228 12 826

Geometry.c 54 6 235

Geometry.h 34 9 129

Geometry_Square.h 13 6 22

Geometry_Ellipse.h 13 6 22

Geometry_Polygon.h 13 6 20

Geometry_Line.h 12 6 20

Geometry_SquareExtrusion.h 13 6 20

Geometry_PolyhedralSurface.h 13 6 20

Geometry_LineString.h 12 6 20

Geometry_EllipseExtrusion.h 12 6 20

Geometry_PolygonExtrusion.h 13 6 20

107

A.2. Generische sDDS-Erweiterungen Anhang A. Implementierungsaufwand

Geometry_LineRing.h 12 6 20

Geometry_PolyhedralSurfaceExtrusion.h

13 6 20

Geometry_Point.h 12 6 20

----------------------------------------------------------------

SUM: 2988 231 10707

----------------------------------------------------------------


----------------------------------------------------------------

C 13 2803 150 10334

C/C++ Header 13 185 81 373

----------------------------------------------------------------

SUM: 26 2988 231 10707

----------------------------------------------------------------

A.2.2 Lokationsschnittstelle

----------------------------------------------------------------


----------------------------------------------------------------

LocationTrackingService.c 27 6 114

LocationService.c 14 6 44

LocationService.h 7 6 20

LocationTrackingService.h 8 6 15

----------------------------------------------------------------

SUM: 56 24 193

----------------------------------------------------------------


----------------------------------------------------------------

C 2 41 12 158

C/C++ Header 2 15 12 35

----------------------------------------------------------------

SUM: 4 56 24 193

----------------------------------------------------------------

108

Anhang A. Implementierungsaufwand A.3. Architekturkomponenten

A.3 Architekturkomponenten

A.3.1 LocationBuiltInUpdateService

----------------------------------------------------------------


----------------------------------------------------------------

BuiltInLocationUpdateService.c 16 40 95

BuiltInLocationUpdateService.h 6 23 11

----------------------------------------------------------------

SUM: 22 63 106

----------------------------------------------------------------


----------------------------------------------------------------

C 1 16 40 95

C/C++ Header 1 6 23 11

----------------------------------------------------------------

SUM: 2 22 63 106

----------------------------------------------------------------

LocationFilteredTopic

----------------------------------------------------------------


----------------------------------------------------------------

LocationFilteredTopic.c 75 6 410

FilteredDataReader.c 37 7 168

LocationFilteredTopic.h 15 6 48

GeometryStore.h 9 6 19

GeometryStore.c 4 6 13

FilteredDataReader.h 5 6 12

ContentFilteredTopic.h 6 6 9

----------------------------------------------------------------

SUM: 51 43 679

----------------------------------------------------------------


----------------------------------------------------------------

C 3 116 19 591

C/C++ Header 4 35 24 88

109

A.3. Architekturkomponenten Anhang A. Implementierungsaufwand

----------------------------------------------------------------

SUM: 7 151 43 679

----------------------------------------------------------------

A.3.2 SubscriptionManager

----------------------------------------------------------------


----------------------------------------------------------------

SubscriptionManager.c 52 7 267

SubscriptionGraph.c 43 7 223

DynamicLinkedList.c 27 7 134

SubscriptionGraph.h 22 6 66

SubscriptionManagementService.c

19 7 62

SubscriptionManager.h 11 6 25

FilterEvaluator.c 7 6 22

SubscriptionManagementService.h

10 6 19

FilterEvaluator.h 5 6 7

----------------------------------------------------------------

SUM: 196 58 825

----------------------------------------------------------------


----------------------------------------------------------------

C 5 148 34 708

C/C++ Header 5 148 34 708

----------------------------------------------------------------

SUM: 9 196 58 825

----------------------------------------------------------------

110

Anhang A. Implementierungsaufwand A.4. Evaluation

A.3.3 ManagementTopic

----------------------------------------------------------------


----------------------------------------------------------------

ManagementTopicSubscriptionService.c

43 12 207

ManagementTopic.c 54 6 182

ManagementTopicDataWriter.c 1 13 179

ManagementTopic.h 13 6 51

ManagementTopicPublicationService.c

8 7 20

ManagementTopicDataWriter.h 5 6 12

ManagementTopicPublicationService.h

5 6 9

ManagementTopicSubscriptionService.h

6 6 6

----------------------------------------------------------------

SUM: 175 62 666

----------------------------------------------------------------


----------------------------------------------------------------

C 4 146 38 588

C/C++ Header 4 29 24 78

----------------------------------------------------------------

SUM: 8 175 62 666

----------------------------------------------------------------

A.4 Evaluation

----------------------------------------------------------------


----------------------------------------------------------------

C 30 309 13 1317

XML 34 229 158 980

Bourne Shell 14 107 2 411

Python 1 16 14 46

----------------------------------------------------------------

111

A.4. Evaluation Anhang A. Implementierungsaufwand

SUM: 79 661 187 2754

----------------------------------------------------------------

112

Anhang B

Literaturverzeichnis

[Bec10] BECKMANN, Kai: Konzeption einer leichtgewichtigen, datenzentrierten

Middleware für Sensornetze und eine prototypische Realisierung für ZigBee,Hochschule RheinMain, Diplomarbeit, 2010

[CCPL] CHUAN-CHIN PU, Chuan-Hsian P. ; LEE, Hoon-Jae: Indoor Location

Tracking using Received Signal Strength Indicator

[con] https://www.iot-lab.info/about-us/

[cora] CORBA Notification Service API Reference. –http://docs.oracle.com/cd/E13203_01/tuxedo/tux100/notify/evnt_api.html

[corb] ; OMG (Veranst.): CORBA Notification Service Specification

[geo] ; Open Geospatial Consortium (Veranst.): OGC GeoSPARQL - A Geographic

Query Language for RDF Data

[Ger] GERGELEIT, M.: Vorlesungsunterlagen, Internet der Dinge, Kapitel 9

[JB16] JACQUENET, Christian ; BOUCADAIR, Mohamed: A Software-Defined Ap-proach to IoT Networking. In: ZTE COMMUNICATIONS (2016)

[OMG] OMG: Data Distribution Service (DDS) v.1.4

[opea] ; Open Geospatial Consortium Inc. (Veranst.): OpenGIS ® Implementation

Standard for Geographic information - Simple feature access - Part 2: SQL

option

113

Anhang B. Literaturverzeichnis

[opeb] ; Open Geospatial Consortium Inc. (Veranst.): OpenGIS ®Implementation

Standard for Geographic information - Simple feature access - Part 1: Com-

mon architecture

[Ope13] Open Networking Foundation: SDN Architecture Overview. Dezember 2013

[PAK+05] PATWARI, Neal ; ASH, Joshua N. ; KYPEROUNTAS, Spyros ; HERO, AlfredO. ; MOSES, Randolph L. ; CORREAL, Neiyer S.: Locating the nodes: Co-operative localization in wireless sensor networks. In: IEEE Signal Proces-

sing Magazine 22 (2005), 7, Nr. 4, S. 54–69. http://dx.doi.org/10.1109/MSP.2005.1458287. – DOI 10.1109/MSP.2005.1458287. – ISSN1053–5888

[San] SANTOS, Francisco: Localization in Wireless Sensor Networks

[sdd] sDDS Quellcode. – https://zenon.cs.hs-rm.de/sdds/sdds

[SRL02] SAVARESE, Chris ; RABAEY, Jan M. ; LANGENDOEN, Koen: Robust Positio-ning Algorithms for Distributed Ad-Hoc Wireless Sensor Networks. In: Pro-

ceedings of the General Track of the Annual Conference on USENIX Annual

Technical Conference. USENIX Association (ATEC ’02). – ISBN 1–880446–00–6, 317–327

[tra] ; OMG (Veranst.): Trading Object Service Specification

[W3C] W3C: SPARQL Query Language for RDF. – https://www.w3.org/TR/rdf-sparql-query/

[Win12] WINTER, et a.: RPL: IPv6 Routing Protocol for Low-Power and Lossy

Networks. Internet Engineering Task Force (IETF), März 2012. – htt-ps://tools.ietf.org/html/rfc6550

114

Documents

Ortsbasierte Topic-Filterung für die datenzentrierte ... · PDF fileMiddleware ist es, über einen Discovery-Mechanismus passende Publisher und Subscri-ber zu erkennen und ein Abonnement