Lade Inhalt...

Aufbau einer plattformunabhängigen hydrologischen Sensor-Web-Anwendung für Smartphones und Tablets

Bachelorarbeit 2012 86 Seiten

Geowissenschaften / Geographie - Kartographie, Geodäsie, Geoinformationswissenschaften

Leseprobe

Inhaltsverzeichnis

1 Einleitung
1.1 Ziele und Methoden
1.2 Aufbau der Arbeit

2 Technologien und Standards im Bereich des Sensor Web
2.1 Open Geospatial Consortium (OGC)
2.2 Sensor Web Enablement (SWE)
2.2.1 Webservices
2.2.2.1 Sensor Observation Service (SOS)
2.2.2.2 Sensor Event Service (SES)
2.2.2.3 Sensor Planning Service (SPS)
2.2.2.4 Web Notification Service (WNS)
2.2.2 Datenformate
2.2.2.1 Observation & Measurement (O&M)
2.2.2.2 Sensor Model Language (SensorML)
2.2.2.3 Water Model Language 2.0 (WaterML 2.0)
2.2.3 Kommunikation von Webservices
2.2.3.1 HTTP GET-Anfrage
2.2.3.2 HTTP POST-Anfrage
2.2.3.3 HTTP Antwort

3 Sensor Web in der Wasserwirtschaft
3.1 Der Wupperverband
3.2 Sensor Web im Wupperverband

4 Plattformen einer mobilen Sensor-Web-Anwendung
4.1 Plattforminteroperabilität
4.2 Web-Plattform
4.3 Grundlagen-Technologien der Web-Plattform
4.3
4.3
4.3.3 JavaScript
4.3
4.4 Software
4.4.1 Mobile Betriebssysteme
4.4.1.1 Apple iOS
4.4.1.2 Google Android
4.4.1.3 RIM Blackberry
4.4.2 Mobile Browser
4.4.2.1 Safari (Apple iPhone)
4.4.2.2 Android Browser
4.4.2.3 Blackberry Browser
4.4.2.4 Zusammenfassung
4.5 Hardware
4.5.1 Smartphones und Tablets
4.5.1.1 Blackberry Bold
4.5.1.2 Samsung Galaxy
4.5.1.3 Apple iPhone 4S
4.5.1.4 Apple iPad
4.5.1.5 Blackberry PlayBook
4.5.2 Web-Server
4.5.3 Pegel

5 Konzeption und Implementierung
5.1 Zieldefinition
5.2 Einstieg
5.3 Anforderungsanalyse
5.3.1 Tabellarisches Anzeigen der Messwerte
5.3.2 Such-Funktion
5.3.3 Diagramm-Generierung
5.3.4 Mitteilung des Sensor-Standortes über eine Kartendarstellung
5.3.5 Anzeige von Metadaten eines Sensors
5.3.6 Umkreissuche
5.4 Systemarchitektur (Web-/Hybrid-/Native-App)
5.5 Systementwurf
5.5.1 Struktur und Aufbau der Anwendung
5.5.2 Layout
5.5.2.1 jQuery Mobil, jQTouch und Co
5.5.2.2 Gestaltung mit jQuery Mobile
5.5.2.3 Layout Vorgabe des Wupperverbands
5.6 Implementierung der Anwendung
5.6.1 Navigation
5.6.2 Umsetzung der Anwendungsfälle
5.6.2.1 Tabellarische Anzeige der Messwerte
5.6.2.2 Such-Funktion
5.6.2.3 Diagramm-Generierung
5.6.3.4 Mitteilung des Sensor-Standorts über eine Kartendarstellung
5.6.3.5 Anzeigen von Metadaten eines Sensors
5.6.3.6 Umkreissuche
5.7 Testbetrieb der Sensor Web-Anwendung

6 Resümee und Ausblick

I. Literaturverzeichnis

II. Abbildungsverzeichnis

III. Listingverzeichnis

IV. Abkürzungsverzeichnis

1 Einleitung

Die Möglichkeit, Messdaten aus der Umwelt zu überwachen, gewinnt in der heutigen Zeit immer mehr an Bedeutung. Sensornetzwerke und immer schneller werdende Daten­verbindungen ermöglichen den Schritt zur Verarbeitung der Daten. Dabei werden die Mess­daten immer schneller Online gestellt und einem immer breiteren Publikum zugänglich ge­macht. Die Aktualisierung der Werte kann von Minuten bis hin zu Stunden dauern, je nach­dem, welches Zeit-Intervall zum erneuten Abruf der Daten ausgewählt ist.

Beim Wupperverband ist daher die Kenntnis über aktuelle Daten der Pegelstände Grundvoraussetzung für hydrologisches Arbei­ten. Beispielsweise bilden Wasserstände und Durchflüsse von Flüssen und Bächen Grund-lagen für Hochwasserwarn­dienste oder Steuerung von Talsperren zur Trink- und Brauchwas­sernutzung. Langjährige Zeitreihen liefern unter anderem Daten für statische Auswertungen (klimatische Verände­rungen), wasserwirtschaftliche Planungen, wasserrechtliche Entschei­dungen oder Gewäs­serentwicklungskonzepte (Wupperverband, ohne Jahr).

Die Daten zu erfassen und auszuwerten ist dabei die eine Sache, sie zu präsentieren und plattformübergreifend zu visualisieren, die andere. Wie bereits erwähnt, werden die Daten im Laufe der Zeit, einem immer breiterem Publikum zur Verfügung gestellt, sprich der Öf­fentlichkeit. Früher gab es nur einen Weg sich Daten online abzurufen, nämlich von einem Desktop PC. Zur Visualisierung mussten daher nur die verschiedenen Browser beachtet wer­den.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Smartphone-Absatz (Bitkom, 2010)

Doch heute, im Zeitalter der Smartphones und Tablets, muss die Visualisierung auch für den mobilen Sektor bedacht werden. Der Anteil (Verkauf von 11,8 Millionen Exemplaren allein im Jahr 2011) gerade an Smartphones ist hoch und er steigt ständig (Bitkom, 2010). Die Verbrei­tung der Tablets verläuft im privaten Sektor etwas langsamer, doch gewinnt auch dieser. Bereich zunehmend An­teile am Markt. Aus einer Umfrage des Zentrums für europäi­sche Wirtschaftsforschung (ZEW) wird dennoch deutlich, dass ge­rade Unternehmen ihre Mitarbeiter mit Tablets ausstatten (ZEW, 2011). So statten bereits 25% der Unternehmen ihre Mitarbeiter[1] mit Geräten aus. Für das Jahr 2012 soll diese Zahl noch um weitere zwölf Prozentpunkte steigen.

1.1 Ziele und Methoden

Ziel dieser Arbeit ist der Entwurf und die Implementierung einer prototypischen Sensor- Web-Anwendung, welche Anwendern von Smartphones und Tablets den Zugriff auf aktuelle Messstände und Pegeldaten des Wupperverbandes ermöglichen soll. Dabei steht besonders die Plattforminteroperabilität im Vordergrund. Diese ermöglicht es, mit Blick auf die unter­schiedlichsten mobilen Betriebssysteme, eine einheitliche Darstellung zu realisieren. Um dies zu erreichen, wird auf standardisierte Services und Techniken zurückgegriffen. Dabei werden besonders die Standards und Spezifikationen des Open Geospatial Consortiums (OGC), sowie des World Wide Web Consor­tiums (W3C) und der Internationale Organisation für Normung (ISO) eingesetzt.

Der Schwerpunkt dieser Arbeit befasst sich mit der Anforderungsanalyse, sowie den Imple­mentierungsaspekten der Sensor-Web-Anwendung. Dabei sollen die Messdaten vom Sensor Observation Service genutzt werden. Clientseitig werden diese aufbereitet und visualisiert. Zudem soll der Anwender verschiedene Möglichkeiten haben, mit den Informationen um­zugehen.

Als konkreter Anwendungsfall dient die Tätigkeit der Mitarbeiter des Wupperverbandes, die darin besteht, dass sie oft von unterwegs Mess- und Pegeldaten abrufen müssen und denen bislang nur eine tabellarische Übersicht ohne zusätzlichen Funktionen bereitgestellt werden konnte. Die mobile Sensor-Web-Anwendung soll den Mitarbeiter eine optimierte Darstel-lung der Messdaten, sowie zusätzliche Interaktionsmöglichkeiten bieten.

1.2 Aufbau der Arbeit

Diese Bachelor-Arbeit soll zeigen, dass es mit neuesten Technologien und Standardisierun­gen durchaus Möglichkeiten gibt, Sensor-Anwendungen web-basierend bereitzustellen und darüber hinaus mit weiteren Funktionalitäten zu ergänzen.

Zur Umsetzung der oben genannten theoretischen Überlegungen ergeben sich folgende zentrale Fragestellungen der Arbeit:

- Welche Standards liegen im Bereich des Sensor Webs im Wupperverband vor und wie können sie genutzt werden?
- Gibt es Bedingungen, die an die Systemarchitektur gebunden sind?
- Mit welchen Techniken lassen sich die Daten abrufen?
- Wie werden Daten anschließend plattformübergreifend visualisiert?
- Welche Geräte kommen in Frage?
- Welche Funktionalitäten soll die Anwendung zusätzlich haben?

Im folgenden Kapitel „Technologien und Standards im Bereich des Sensor Web“ werden die für die Umsetzung der Sensor-Web-Anwendung nötigen Technologien und Standards allge-mein erläu­tert.

Der konkrete Themenbezug zum Wupperverband wird anschließend im Kapitel „Sensor Web in der Wasserwirtschaft“ verdeutlicht. Dabei spielen die wasserwirtschaftlichen Aspekte und die Notwendigkeit der zu erstellenden Anwendung eine Rolle.

Im Kapitel „Plattformen einer mobilen Sensor-Web-Anwendung“ werden Technologien und Standards der Plattform erläutert, um eine Interoperabilität der Anwendung zu gewährleis­ten. Dabei werden sowohl Software, Hardware und aktuelle Internettechniken, die bei der Umsetzung der Anwendung eine Rolle spielen, vorgestellt.

Der Hauptteil der Arbeit handelt von der „Konzeption und Implementierung“. Unter Be­rücksichtigung der bereits erwähnten technologischen Rahmenbedingungen, sowie den ge­wählten Hardware Vorgaben, werden zunächst Anwendungsfälle und Softwarearchitektur erstellt. Diese werden im Folgeprozess realisiert. Das Vorgehen der Implementierung wird dokumentiert. Zum Abschluss des Kapitels wird die prototypische Anwendung in die Test­phase überführt.

Im Abschlusskapitel „Resümee und Ausblick“ werden die erreichten Ergebnisse analysiert und ausgewertet. Darüber hinaus wird ein Ausblick über Technologie und Funktionalität der Zukunft von mobilen Anwendungen gegeben.

2 Technologien und Standards im Bereich des Sensor Web

Um die Interoperabilität der Systeme zu ermöglichen und den Austausch von Daten zu er­leichtern, sind Standardisierungen zwingend erforderlich. Diese Standards werden vom OGC und ISO bereitgestellt und empfohlen. Im folgenden Kapitel werden die für die Wasserwirt­schaft und für die Entwicklung der Sensor-Web-Anwendung nötigen Spezifikationen näher erläutert.

2.1 Open Geospatial Consortium (OGC)

Das Open Geospatial Consortium wurde im Jahr 1994 gegründet und beschäftigt sich mit der Entwicklung von Standards für eine raumbezogene Informationsverbreitung. Ziel dieser ge­meinnützigen Organisation, ist die Erschaffung von Standards zwecks eines interoperablen Austauschs von geografischen Daten. Derzeit hat das OGC 438[2] Mitglieder aus Industrie, Regierungsbehörden und Universitäten, zu denen auch der Wupperverband zählt. Zu den bekanntesten Spezifikationen in der Geoinformationsbranche zählen der WMS, der WFS, der SOS oder die GML. Darüber hinaus gibt es allerdings noch viele weitere Spezifikationen.

Eine Spezifikation schreibt keine konkrete Software-Lösung vor, vielmehr legt sie das Verhal­ten von Schnittstellen eines Dienstes mit dem Verhalten und seinen Eigenschaften fest. So gibt es innerhalb des OGC eine lange Diskussionsphase, bis das Ergebnis letztlich als Spezifi­kation verbschiedet wird. (OGC, 2012)

2.2 Sensor Web Enablement (SWE)

Sensor Web Enablement (SWE) ist eine besondere Initiative des OGC. Ziel dieser Initiative ist es, offene Standards für Sensoren und Sensorsysteme aller Art, wie zum Beispiel für den Hochwasserschutz, Webcams oder satellitengestützten Systemen für das Web zu entwi­ckeln. Für die Nutzung von Echtzeit-Sensordaten gibt es dabei eine Menge an Möglichkeiten zur Einbindung in folgenden Bereichen: Wasserwirtschaft, Umwelt-Monitoring, Industrie-steuerung, Logistik und viele weitere Bereiche (Botts, Percivall, Reed und Davidson, 2007, S. 4).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: OGC Sensor Web Konzept (Heier & Spies, 2009, S. 370): Korrespondenz Wasserwirtschaft Nr.7)

Ähnlich wie bei der Hypertext Markup Language (HTML) und dem Hypertext Transfer Proto­col (HTTP) , dessen Entwicklung Grundlage für die standardisierte Übertragung von Daten im Internet wurde, ist das Ziel des SWE eine Standardisierung der Ermittlung, des Austausches und der Verarbeitung von Beobachtungen eines Sensors. Folgende Funktionalitäten sollen demnach das Sensor Web erfüllen (Botts et al., 2007, S. 5f):

- Finden von Sensorsystemen, Beobachtungen und Beobachtungsprozessen, abge­stimmt auf die Bedürfnisse der Anwendung oder des Anwenders
- Bestimmung der Leistungsfähigkeit eines Sensors und der Zuverlässigkeit seiner Mess­daten
- Zugriff auf Sensorparameter zur automatisierten Verarbeitung und Lokalisierung von Beobachtung
- Bereitstellung von Echtzeit-Beobachtungen oder Zeitintervallen in standardisierter Form
- Möglichkeit eines Sensors, eine explizite Beobachtung anzufordern
- Ereignisreaktion auf ein bestimmtes Event mit anschließender Weiterleitung oder Pub­likation der Warnmeldung.

Die Funktionalität des Sensor Webs und den dazugehörigen Netzwerken wird durch ver­schiedene Kodierung zur Beschreibung und Überwachung von Beobachtungen und standar­disierte Schnittstellen für Web Services geschaffen.

Zu den entwickelten Standards zählen folgende Spezifikationen, die im weiteren Verlauf die­ser Arbeit näher beschrieben werden:

- Observation & Measurement Schema(O&M)
- Sensor Model Language (SensorML)
- Sensor Observation Service (SOS)
- Sensor Planning Service (SPS)
- Sensor Alert Service (SAS)
- Web Notification Service (WNS)

2.2.1 Webservices

Webservices sind bei der Erstellung nicht-proprietärer Anwendungen nötig. Sie kommunizie­ren plattformunabhängig mit Anwendungen oder anderen Services. Jeder Webservice ist über den Uniform Ressource Identifier (URI) eindeutig identifizierbar. Informationen werden über internetbasierte Protokolle XML-basiert übertragen (Melzer, 2010, S. 62f).

Das World Wide Web Consortium (W3C) hat den Begriff Webservice wie folgt definiert:

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-pro­cessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards (W3C, 2004).

Im Bereich des OGC Umfelds weisen die Webservices folgende besondere Eigenschaften auf:

- Die Service-Komponenten sind in mehreren Stufen organisiert
- Die Benutzung von Services ist mit anderen Komponenten verbunden
- Schnittstellen nutzen offene Standards und sind relativ simpel[3]
- Webservices kommunizieren über offene Internetstandards
- Server- und Client-Implementierungen sind nicht eingeschränkt.

2.2.2.1 Sensor Observation Service (SOS)

Der Sensor Observation Service (SOS) ist ein standardisierter Webservice des OGC mit der Aufgabe, Echtzeit- oder Archiv-Daten, aller Arten von Sensoren, sowohl mobile und statio­näre, als auch in-situ[4] und remote[5], zu finden und abzurufen.

Dabei wird zwischen Beobachtungen, den observations, und Beschreibungen, den descripti­ons, unterschieden. Während Beobachtungen als kodierte O&M Observation zurückgegeben werden, werden Beschreibungen, wie etwa Kalibrierungsinformationen oder die Position eines Sensors als SensorML oder TML zurückgegeben (Na & Priest, 2007, S. 8).

So wird die Beobachtung als Event abgebildet, welches ein Ergebnis produziert, dessen Wert eine Schätzung der Eigenschaft der Ziel-Beobachtung oder featureOfInterest[6] ist (Na & Priest, 2007, S. 9).

Um die Möglichkeit einer leeren Rückgabe[7] auf einen GetObservation -Request zu minimie­ren, werden ähnliche Beobachtungen von Sensoren zu sogenannten Observation Offerings zusammengefasst. Diese verhalten sich analog, wie ein Layer in einem Web Map Service (WMS) auf Grund der nicht-überlappenden Gruppe von verwandten Beobachtungen. Jedes Observation Offering ist dabei von folgenden Parametern abhängig (Na & Priest, 2007, S. 9f):

- Sensorsysteme, die Beobachtungen liefern
- Zeitintervalle verfügbarer Daten
- Phänomene, welche gemessen worden sind
- Standort/Verortung des Gebiets mit all seinen Sensoren
- Standortbestimmung des featureOfInterest

Weiter ist darauf zu achten, dass bei Offerings ein räumlicher oder thematischer Zusam­menhang besteht. Beispielsweise wäre es nicht sinnvoll, Sensoren mit unterschiedlichen Zeitintervallen zusammenzuführen, da sonst Ergebnisse ohne Inhalt zurück gesendet werden würden.

Ein Problem für die Interoperabilität des SOS stellen die Vielzahl verschiedener Phänomene und deren Einheiten dar. Die spezifischen Phänomene und Maßeinheiten werden daher de­zentral gespeichert. Ziel soll in Zukunft allerdings sein, einen Mechanismus zu entwickeln, der eine beliebige Anzahl von Definitionen in verschiedenen Anwendungsdomänen behan­deln kann. Dabei muss dieser zum Identifizieren von Phänomenen und Maßeinheiten, äu­ßerst flexibel sein (Na & Priest, 2007, S. 10f).

Des Weiteren bietet der SOS auch Möglichkeiten der Filterung an. Dabei können Beobach­tungen nach Zeit, Raum, Sensoren und Phänomenen gefiltert werden. Dies bietet sich dann an, wenn explizite Werte gefordert werden und die Last der Datenübertragung verringert werden soll/kann (Na & Priest, 2007, S. 19).

Im Wesentlichen werden beim Sensor Observation Service (SOS) vier Profile unterschieden. Das Core Profil, welches immer implementiert wird und die minimal Operationen GetCapabilities, DescribeSensor und GetObservation beinhaltet. Das Transactional Profil, welches zwei optio­nale Operationen enthält, nämlich RegisterSensor, um Sensoren im SOS zu registrieren und InsertObservation, bei dem Beobachtungen dem SOS hinzugefügt werden können. Beim dritten Profil, dem Enhanced Profil, wird der SOS um verschiedene optionale Operationen ergänzt, wie zum Beispiel GetResult oder GetFeatureOfInterest. Von einem vierten Profil, dem Entire Profil spricht man, wenn alle vorherigen Profile implementiert sind (Na & Priest, 2007, S. 20).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: SOS-Unterschiede (nach Na & Priest, 2007, S.15, geändert)

Da besonders das Core-Profil für die Umsetzung der Anwendung eine große Rolle spielt, werden im Anschluss die drei dazugehörigen Operationen explizit erläutert.

Der GetCapabilities-Aufruf gibt eine standardisierte XML-Datei mit beschreibenden Metada­ten über den SOS zurück. Dabei ist diese, wie ein Baum-Verzeichnis strukturiert. Der Haupt­knoten beinhaltet die SOS Version und die dazugehörige Schema-Datei. Es folgen weitere Unterknoten. Im Knoten sind unter anderem Ti­tel, eine kurze Beschreibung und Keywords[8] zu finden. Der Knoten gibt den Herausgeber des SOS bekannt mit Merkmalen, wie Name, Anschrift und Telefon­nummer. Unter werden Bedingungen genannt, die nötig sind, um eine erfolgreiche Abfrage an den Service zu senden. So werden dem Anwender die zur Verfügung stehenden Values[9], die akzeptierten Formate oder die möglichen Request-Metho­den mitgeteilt. Um sich jedoch nicht alle vorhandenen Werte anzeigen zulassen, was den Server mit Sicherheit an seine Grenzen bringen würde, gibt es zusätzlich den Knoten , der Möglichkeiten zur Filterung der Beobachtungen bereitstellt. Im Knoten werden schließlich die einzelnen Observation Offerings gelistet mit Werten, wie räumlichen Begrenzungen, maximalen Zeitintervallen, Ausgabeformaten und dem featureOfInterest.

Durch diese Informationen hat der Anwender alle nötigen Parameter und Metadaten, die zum Arbeiten mit dem SOS nötig sind.

Der DescribeSensor-Aufruf gibt detaillierte Metadaten über den Sensor im SensorML-For­mat oder im TML-Format aus. In dem Ergebnis der Anfrage sind in der Regel die ID des Sen­sors, dessen Position, sowie das beobachtete Phänomene enthalten. Darüber hinaus können weitere spezifische Daten des Sensors, wie zum Beispiel Kalibrierungsdaten oder Informatio­nen zum Eigentümer enthalten sein (Na & Priest, 2007, S. 25).

Der GetObservation-Aufruf wurde entwickelt, um den SOS nach Beobachtungen abzufragen und das Ergebnis strukturiert durch die Observation & Measurement Spezification auszuge­ben. Eine GetObservation-Anfrage beinhaltet mehrere Parameter, davon sind einige ver­pflichtend und andere optional. Es folgt eine tabellarische Übersicht der notwendigen Para­meter (Na & Priest, 2007, S. 29).

Abbildung in dieser Leseprobe nicht enthalten

Die Antwort auf eine GetObservation -Anfrage ist entweder eine Observation substitution group oder eine ObservationCollecation. Die SOS-Schnittstelle ist optimiert für den Zugriff auf Beobachtungen und den damit verbundenen Informationen. Im Fall einer fehlerhaften Anfrage, wird eine Exception in Form eines XML-Dokuments zurückgegeben.

Außer den notwendigen Operationen aus dem Core Profil gibt es noch folgende weitere op­tionale Operationen die zur Verfügung stehen (Na & Priest, 2007, S. 33f):

- Transaction Profil
- RegisterSensor
Erlaubt dem Anwender den SOS, um weitere Sensorsysteme zu ergänzen
- InsertObservation
Erlaubt dem Anwender das Hinzufügen von Beobachtungen zu einem Sensor­system
- Enhanced Profil
- GetObservationId
Rückgabe einer Beobachtung anhand der ID
- GetResult
Zur automatischen Aktualisierung der Daten, ohne ständig Anfragen senden zu müssen
- GetFeatureOfInterest
Gibt ein featureOfInterest zurück, welches in einem ObservationOffering im Capabilities-Dokument enthalten ist
- GetFeatureOfInterestTime
Gibt ein Zeitintervall zurück, für das ein featureOfInterest zur Verfügung steht
- DescribeFeatureType
Rückgabe eines XML-Schemas für ein GML-Objekt, um eine Beschreibung des Types der Beobachtung zu erhalten
- DescribeObservationType
Rückgabe eines XML-Schemas, das den Typ der Beobachtung für ein bestimm­tes Phänomen beschreibt
- DescribeResultModel
Rückgabe eines Schemas für das Ergebnis.

Doppelt unterstrichende Operationen stehen ab SOS 2.0 nicht mehr zur Verfügung

(Bröring et al., 2011, S. 18).

Sensor Observation Service 2.0

Ein erfreulicher Punkt ist auch die Weiterentwicklung einzelner Services. So befindet sich der SOS 2.0 zurzeit in der Genehmigungsphase zur Verabschiedung der Spezifikation. In Hinblick auf die Entwicklung der Sensor Web-Anwendung sind Änderungen, wie das Senden von HTTP GET-Anfragen an den GetObservation -Operator oder die zwingende Eingrenzung räumlicher und zeitlicher Phänomene, sehr nützlich.

Die wesentlichen Änderungen im Überblick (Bröring et al., 2011, S. 18):

- Umstrukturierung der Spezifikation in core und extensions
- KVP[10] und SOAP[11] werden verbindlich eingeführt
- Erhöhte Interoperabilität
- Bindende Operatoren für räumliche und zeitliche Filter
- Filter-Profile definieren interoperablen Zugriff auf Beobachtungen
- O&M als verpflichtendes Rückgabeformat
- Neuordnung der Capabilities
- Nur ein Sensor pro ObservationOffering
- Statt alle featuresOfInterests werden verwandte features in den Capabilities gelistet
- Umstrukturierung des Ergebnis-Handlings
- Neue Operation zur Ergebnis-Einbindung (InsertResult und InsertResultTemplate)
- Neue Operation zum Ergebnis-Abruf (GetResult und GetResultTemplate)
- Erweiterte Abrufmöglichkeiten von Features durch übergreifende GetFeatureOfInterest -Operation
- Entfernung von Operation zum Abruf von Typen (DescribeObservationType, DescribeResultModel und DescribeFeatureType)
- SOS 2.0 - Get Data Availability Extension
Erweiterung für den Abruf von verfügbaren Metadaten (GetDataAvailability)

2.2.2.2 Sensor Event Service (SES)

Ziel des Sensor Event Services ist es, beim Eintreffen bestimmter Ereignisse, wie zum Beispiel das Erreichen eines definierten Pegelstands, Benachrichtigungen auszugeben (Echterhoff & Everding, 2008, S. 9).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Event notification system overview (aus Echterhoff & Everding, 2008, S.9)

Der SES befindet sich zurzeit noch in der Diskussionsphase, soll aber den Sensor Alert Service (SAS) als Nachfolger in Zukunft ablösen. Dabei unterscheiden sich die beiden Services in mehreren Punkten. Hauptunterschied soll der Blick auf die Interoperabilität sein, dass die Nutzung von vorhandenen Normen und Spezifikationen gestärkt werden und nicht wie bis­lang Lösungen proprietär realisiert werden. Um dies zu ermöglichen, ist die Einführung des OASIS WS-Notification Standards nötig, der die Services definiert, die gebraucht werden, um die Anfrage/Ausgabe-Kommunikation zu ermöglichen. Weiter wurde die SAS-spezifische Kodierung durch den O&M Standard ersetzt, der es nun ermöglicht, zusätzliche Metadaten bereitzustellen und somit die Interoperabilität der Dienste untereinander steigert. Zudem wurde auch die Filter-Definition aktualisiert. Nutzte der SAS noch eine spezielle, eigene Fil­ter-Sprache, die nur wenig Funktionalität bot, wurde beim SES eine Basis-Filter-Sprache ein­geführt, welche die Unterstützung von XPath[12] benötigt, um Filter auf Basis von XML-Mus­tern umzusetzen. Darüber hinaus werden noch zwei weitere optionale Filter-Sprachen un­terstützt: FES und EML (Bröring et al., 2011, S. 25).

2.2.2.3 Sensor Planning Service (SPS)

Der Sensor Planning Service definiert Schnittstellen für Abfragen, die Informationen über Fähigkeiten von Sensoren, und wie man diese nutzt, liefert. Dieser Standard wurde für fol­gende Zwecke entwickelt (Simonis & Echterhoff, 2011, S. 11):

- Bestimmung der Durchführbarkeit einer Sensor Planning Anfrage
- Senden und Empfangen von Anfragen
- Erkundigung über den Status einer Anfrage
- Aktualisierung und Abbrechen einer Anfrage
- Anfordern von Informationen über andere OGC Services, die den Zugriff auf die Da­ten von der ersuchten Anfrage sammeln.

Die SPS Operationen können in zwei wesentliche Teile gegliedert werden, den Informations- und Funktions-Operationen. Die Informations-Operationen bestehen aus GetCapabilities, DescribeTasking, DescribeResultAccess, GetTask und GetStatus Operationen. Zu den Funkti­ons-Operationen gehören die GetFeasibility, Reserve, Confirm, Submit, Update und Cancel Operationen (Simonis & Echterhoff, 2011, S. 12f).

Sensor Planning Service 2.0

Seit März 2011 steht nun auch die SPS Spezifikation in der Version 2.0 zur Verfügung. Der neue Standard bringt besonders im Anfrage-/Antwort-Modell der Client-/Server Kommuni­kation einige Änderungen mit sich. Die größten Änderungen sind im folgenden dargestellt (Bröring et al., 2011, S. 22):

- Harmonisierung mit den Spezifikationen SWE Service Model und SWE Common
- Implementierung der Operationen nach dem SWE Service Model
- Nutzen von Parameter und Parameterbeschreibungen mittels SWE Common
- Neugestaltung der Bedienbarkeit und dem Status-Modell
- Klare Definitionen der Semantik von Zustandswechseln
- Neue Operationen: GetTask, Confirm, Reserve
- Erweitertes Status-Reporting
- Neues asynchrones Kommunikations-Konzept
- SOAP-Bindung eingeführt

2.2.2.4 Web Notification Service (WNS)

Der Web Notification Service ist als eine Art Nachrichten-Transport-Dienst zu sehen, der über asynchronen Datenfluss dem Anwender beim Eintreten bestimmter Ereignisse eine Mitteilung zukommen lässt. Er wird insgesamt von zwei Services in Anspruch genommen. Zum einen vom SPS, der den WNS verwendet, um das Ergebnis der ursprünglichen Abfrage an den Client weiterzuleiten und zum anderen vom SAS/SES, der Benachrichtigungen übli­cherweise mit dem XMPP-Protokoll versendet. Ist eine Benachrichtigung gewünscht, ohne dass ein Endgerät eine Internetverbindung herstellen kann, so wird die Nachricht ohne zu wissen, mit welchem Protokoll sie später übertragen wird, an den WNS geschickt. Dieser wählt dann eine passende Sendeoption aus und verschickt die Nachricht. Zurzeit stehen fol­gende Benachrichtigungsmöglichkeiten zur Verfügung: E-Mail, HTTP-Anruf, SMS, XMPP, Handy-Anruf und Fax (Simonis & Echterhoff, 2006, S. 5f).

2.2.2 Datenformate

2.2.2.1 Observation & Measurement (O&M)

Der Standard Observation & Measurement (O&M) definiert ein Domain-unabhängiges, kon­zeptionelles Modell zur Darstellung von räumlichen und zeitlichen Messdaten. Die Imple­mentierung dieses Modells beinhaltet ein auf dem GML-Applikations-Schema basierendes XML (Bröring et al., 2011, S. 11).

Observation ist die Beobachtung einer Eigenschaft oder eines Phänomens mit dem Ziel, die­sen einen Wert zuzuweisen. Measurement ist eine Beobachtung, dessen Ergebnis ein Wert ist (Cox, 2007, S. 6).

Darüber hinaus teilt sich O&M in zwei wesentliche Komponente, dem Observation Schema und den Spezifikationen der Sampling Features. Die wichtigsten Bestandteile[13] einer Observation sind, das featureOfInterest, die observedProperty, die procedure und das result. Ergänzend zu den Objekten sind auch die zusätzlichen Parameter samplingTime, resultTime, resultQuality, parameter und metadata zu nennen (Cox, 2007, S. 12f). Bei den SamplingFea­tures handelt es sich um ein generisch, abstraktes Modell, um beobachtete Objekte abzubil­den. Dabei sind diese während einer Beobachtung eher als featureOfInterest zu verstehen, da sie Teile von Eigenschaften der features enthalten oder nur Teile alter features sind (Cox 2007, S. 1).

2.2.2.2 Sensor Model Language (SensorML)

Zur Beschreibung von Sensor Metadaten wurde vom SWE die Sensor Model Language (SensorML) ent­wickelt. SensorML definiert ein Modell über Beschreibungen aller Arten von Sensoren und den damit verbundenen Prozessen. Ein Prozess ist in diesem Zusammenhang zum Beispiel ein Messvorgang eines Sensors oder die Nachbearbeitung der zuvor gesammelten Daten. In der SensorML ist es ein Sensor, der ein Phänomen beobachtet und ein Ergebnis liefern kann. Es ermöglicht eine detaillierte Beschreibung eines Prozesses einschließlich einer Liste der input, outputs, parameters und process methods (Bröring et al, 2011, S. 12).

Zudem wurde die SensorML für folgende weitere Zwecke definiert (Botts & Robin, 2007, S. 15):

- Zur Beschreibung der Sensoren und Sensorsysteme für die Bestandsverwaltung
- Bereitstellen von Sensor- und Prozessinformationen zur Unterstützung der Messungen von Ressourcen und Beobachtungen
- Unterstützung der Verarbeitung und Analyse von Sensormessdaten
- Unterstützung zur Verortung der Messwerte
- Bestimmen von Leistungsmerkmalen (z.B. Genauigkeit, Schwelle, etc.)
- Bestimmung einer genauen Beschreibung des Prozesses, durch den eine Beobach­tung gemacht wurde
- Auf Anfrage, Bestimmung einer ausführbaren Prozesskette für die Ableitung neuer Da­tenprodukte
- Archivierung von grundlegenden Eigenschaften und Annahme in Bezug auf Sensorsys­teme

Es gibt mindestens drei grundlegende Ansätze zur Umsetzung und Nutzung eines SensorML-Instanz-Dokumentes. Beim ersten Ansatz erfolgt eine Definierung der Sensorsystembe­schreibung, die über einen längeren Zeitraum Gültigkeit besitzt. Alle zeitlich variierenden Parameter oder andere Daten würden hierbei als Input der Prozesskette verstanden werden. Diese Methode unterstützt Echtzeit- und archivierte Beobachtungen und bietet ein hohes Maß an Flexibilität für den Abruf von erkannten und verarbeiteten Beobachtungen.

Beim zweiten Ansatz wird die Sensorbeschreibung nur für einen definierten Zeitraum bereitgestellt.

Im dritten Ansatz wird das SensorML-Dokument als Beschreibung genutzt, welches beschreibt, wie mit den Daten des Sensors im weiteren Verlauf des Prozesses umgegangen wird (Botts & Robin, 2007, S. 32f).

Auch bei der SensorML befindet sich bereits die Version 2.0 in der Diskussionsphase. Dabei geht es um folgende wesentliche Veränderungen (Bröring et al., 2011, S. 10):

- Möglichkeiten zur Vererbung von Eigenschaften
- Sensor-Schnittstellen-Beschreibung
- Anlegen von Profilen

[...]


[1] Aus Gründen der Übersichtlichkeit wurde in dieser Bachelorarbeit auf eine geschlechtsspezifische Schreibweise verzichtet. Die Verwendung einer männlichen Form impliziert die gleichberechtigte Ansprache des weiblichen Geschlechts.

[2] Stand:21.03.2012, http://www.opengeospatial.org/ogc

[3] nur wenige Operationen

[4] vor Ort

[5] aus der Ferne

[6] Interesse an einem Merkmal

[7] leeres XML-Dokument als Antwort (response) an den Client

[8] Schlüsselwörter

[9] Werte

[10] key-value-pair: Definiert einen Schlüssel-Wert-Paar, das festlegt oder abgerufen werden kann

[11] Simple Object Accsess Protocol: Netzwerkprotokoll zum Datenaustausch

[12] XML Path Language (XPath): Abfragesprache um Teile eines XML-Dokuments zu Adressieren

[13] ausführliche Information: OGC-Dokument: 07-022r-1 - O&M - Part 1 - Observation Schema

Details

Seiten
86
Jahr
2012
ISBN (eBook)
9783656333876
ISBN (Buch)
9783656334477
Dateigröße
1.8 MB
Sprache
Deutsch
Katalognummer
v205852
Institution / Hochschule
Hochschule Bochum
Note
1,0
Schlagworte
Geoinformatik Sensoren Sensor Observation Service OGC W3C Wasserwirtschaft Hydrologie Responsive Design JQuery JQueryMobile Openlayers Smartphones Tablets Handy plattformunabhängik interoperabel

Autor

Teilen

Zurück

Titel: Aufbau einer plattformunabhängigen hydrologischen  Sensor-Web-Anwendung für Smartphones und Tablets