Sensornetze in der MDI Michael Bauer Workshop 13.10.2011 Hamburg Herzlich Willkommen zurück aus der Pause. Zum Start des Nachmittags will ich etwas über Sensornetzwerke erzählen und wie diese in der MDI eingesetzt werden können. Da wir uns hier ja die ganze Zeit über Dateninfrastrukturen unterhalten, meine ich wenn ich Sensornetzwerke sage natürlich in erster Line das Sensor Web Enablement des OGC. [Klick]

Sensor Web Enablement (SWE) Observations & Measurements (O&M) Standard zur Kodierung von Beobachtungen und Messungen Sensor Observations Service (SOS) Webservice zur Abfrage von Sensordaten und Datenzeitreihen Sensor Model Language (SensorML) Beschreibungssprache für Sensoren, Sensordaten und Messverfahren Transducer Model Language (TML) Sensor Planning Service (SPS) Sensor Alert Service (SAS) Web Notification Services (WNS) Sensor Web Enablement oder auch kurz SWE ist eine Gruppe von Standards des OGC. Für uns in erster Linie interessant sind Observations & Measurements (O&M), der Sensor Observations Service (SOS) sowie SensorML. Darüber hinaus gibt es noch einige weitere Standards in dieser Gruppe … Etwas auf die Standards eingehen. Vor allem auf die ersten beiden will ich jetzt gern noch etwas genauer eingehen.

Observations & Measurements Observations & Measurements (O&M) Standard zur Kodierung von Beobachtungen und Messungen ISO 19156 “An Observation is an action whose result is an estimate of the value of some property of the feature-of-interest, at a specific point in time, obtained using a specified procedure.” (Cox 2008) „Der Standard „Observations and Measurements“ (O&M) stellt ein Modell sowie Daten-format zur Kodierung und Beschreibung von Beobachtungen und Messungen bereit.“ (GDI-DE Architekturkonzept 2.0) Observations & Measurements (O&M) ist ein Standard zur Kodierung von Beobachtungen und Messungen. Auch vom ISO übernommen unter unter Nr. 19156 zu finden. O&M wurde als Anwendungsschema von GML entwickelt und fügt sich somit nahtlos in die OGC Standardkette ein. Hier zwei Definitionen – einmal eine wissenschaftliche und dann eine ganz angewandte und naheliegende, die aus dem GDI Architekturdokument entnommen ist. Grundlegendes Konzept von O&M ist die Beobachtung bzw. Messung, durch welche ein Phänomen mit einem Wert verknüpft wird. Wobei Observation hierbei für die Messung steht und Phänomen für den gemessenen Parameter.

Hier ein Beispiel für eine Datenmodellierung nach O&M Hier ein Beispiel für eine Datenmodellierung nach O&M. Diejenigen unter Ihnen, die sich mit sowas auskennen, werden mir beipflichten, dass dies kein sonderlich komplexes Schema ist. Ich beschreibe zuersteinmal die Beobachtung, also um welches objekt es sich handelt und dann den Wert des Parameters. Dies bedeutet, dass ich einem Sensor auch mehrere Parameter und gemessene Werte zuweisen kann. Darüber hinaus gibt es auch plugins und tools um aus Datenbankschemata gängiger Datenbanken so etwas zu generieren, um tiefe Eingriffe in gewachsene Datenstrukturen zu vermeiden.

O&M und INSPIRE O&M relevant für verschieden INSPIRE Themen Verwendung in: D2.9 Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE Annex II and III data specification development O&M wurde übrigens auch von der INSPIRE Community als relevant erkannt und wird für verschiedene Themen in Annex II und III angewendet werden. Die Diskussionen im Detail sind da noch am Laufen, aber unter anderem werden entsprechende FeatureTypes dafür hinzukommen.

Sensor Observation Service OGC Service, vergleichbar mit Web Map Service (WMS) und Web Feature Service (WFS) Operationen optimiert für Messdaten Nicht nur für Sensordaten Operationen: getCapabilities getObservation describeSensor getFeatureOfInterest getObservation: Stellt Messdaten bereit Die Ergebnisse lassen sich filtern nach: Sensoren Time Parametern Ort Etc.

Sensor Observation Service Time Layer Sensors Sensor in Time Timeseries In einem visuellen Beispiel bedeutet dies: Zeichnung erklären – 3 dimensionale Speicherung (2d Raum + Zeit) Layer herausziehen Zeitserien Durchstich „3D Bounding Box“ – Audehnung + Zeitraum

Architektur Was bedeutet das für die Architektur? Nun, bislang haben wir vor allem einfach und starre Architekturen – im simpelsten Fall so etwas hier. Natürlich sieht keiner unserer Knoten derart aus, aber für die Datenbereitstellung ist dies der Basisfall. Wenn wir nun SOS hinzunehmen, eröffnen sich uns neue Möglichkeiten. Wir können natürlich nach wie vor unsere Daten per WMS und WFS bereitstellen, indem wir, wie gezeigt, ein Layer zu einem Zeitpunkt herausziehen. Wir können auch verschiedene SOS so fusionieren, z.B. berechnete Daten und Live-Sensordaten. Wir können die Daten auch durch einen Processing Service analysieren lassen. Oder direkt aus dem SOS eine Zeitreihe abfragen. Das Zusammenspiel unserer Dienste wird damit also deutlich flexibler.

Angewandte Beispiele Pegel Online Aber jetzt hab ich sie genug gelangweilt mit der Theorie – was können wir denn damit genau anfangen: Das hier wohl bekannteste Beispiel ist Pegel Online. Hier mit der Zeitreihenvisialisierung für den Pegel St. Pauli. Aber man muss ja nicht zwangläufig die Zeitreihen ansehen. Durch die Bereitstellung von Pegelonline in Form eines SOS, kann ich die Daten auch in andere Anwendungen einbinden.

Angewandte Beispiele Heidelberg 3D Hier ein Beispiel von Heidelberg 3D, wo ebenfalls die Sensordaten aus PegelOnline verwendet wurden um die entsprechenden Pegel im 3D Modell einzublenden und bei Klick ein Label mit den entsprechenden Daten anzuzeigen. In diesem Fall werden der Wert, also der Wasserstand, die ID des Sensors und die Zeit angegeben.

Beispiel – BAW Vision Ich hab dieses Beispiel mal BAW –Vision genannt, da dies zeigt wie wir uns den Einsatz von SWE in BAW zukünftig vorstellen. Also was haben wir vor und wieso nehmen wir dazu einen SOS? Zeichnung erklären.

Pro & Contra Pro Contra Flexible Architektur Arbeitsaufwand Nahtlose Integration in OGC Infrastrukturen Komplexere Architektur Standardisierte Datenstruktur Evtl. unnötiger Overhead Vereinfachte Datenharmonisierung Mehrdimensionaler Datenzugriff Layer Zeitreihen „Bounding Cube“ Was also spricht für und was gegen den Einsatz von SWE in der MDI bzw. für die einzelnen Aufgaben der MDI? Was muss ich bedenken? Arbeitsaufwand – neue Technologien einzuführen bedeutet immer einen gewissen Arbeitsaufwand. Ich denke eine der Aufgaben innerhalb des Forschungsprojekts MDI muss sein, hier einfache Lösungen zu finden.

Fragen? Vielen Dank! Michael Bauer Bundesanstalt für Wasserbau michael.bauer@baw.de +49 40 81908 447 Ich sehe, ich bin sehr früh fertig, aber ich bin mir sicher einer meiner Nachfolger wird die zusätzliche Zeit zu schätzen wissen. Danke sehr.