Monitoring the Environment with Sensor Web Services

Size: px

Start display at page:

Download "Monitoring the Environment with Sensor Web Services"

Claude Wilkerson
6 years ago
Views:

1 EnviroInfo 2009 (Berlin) Environmental Informatics and Industrial Environmental Protection: Concepts, Methods and Tools Monitoring the Environment with Sensor Web Services Simon Jirka 1, Dr. Albert Remke 2 1 Westfälische Wilhelms-Universität Münster, Institut für Geoinformatik Weseler Straße 253, Münster, Germany jirka@uni-muenster.de 2 52 North Initiative for Geospatial Open Source Software GmbH Martin-Luther-King-Weg 24, Münster, Germany remke@52north.org Abstract The human impact on the environment is causing global change, resulting in an increase of natural hazards and depleting natural resources. Real-time information on our man-earth system is essential both in terms of improving our understanding of its condition and dynamics and of enabling more sustainable management of our activities which interact with the environment. Sensor networks are among the most important tools for gathering such (real-time) information. One point focused on by sensor networks is the development of software standards and implementations for web services that facilitate the integration of sensors and sensor data into a wide range of applications. Standardisation of these web services is required because the diversity of sensor concepts and interfaces represents a significant obstacle for the integration of sensor networks into environmental information systems. This paper presents examples how 52 North sensor web services are being used in constructing environmental monitoring systems. 52 North Initiative for Geospatial Open Source Software is an international R&D platform aiming at fostering the innovation process in the field of spatial data infrastructures. Keywords: Sensor Networks, OGC Standards, Sensor Web Enablement, Sensor Observation Service, 52 North 1. Introduction Sensor networks are a valuable tool when it comes to capturing environmental data. Such data can originate from many sources, such as weather station networks or real-time monitoring of aspects such as traffic density, fire detection or flood warning systems. However, the interfaces between sensors and sensor networks are very heterogeneous. In many cases, interfaces vary not only between sensor manufacturers but also between different sensor models from the same manufacturer. This heterogeneity makes the integration of sensors into application systems a very cumbersome and difficult task. One of the main aims of the Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC) is to facilitate this integration. These activities have led to the definition of a suite of standards that define both data models and web service interfaces. As a result, standardised encodings for sensor data and metadata as well as interfaces for accessing sensor data, and for alerting and controlling sensors are now available. This paper introduces one environmental monitoring application which has been built using the SWE framework: a system for monitoring hydrological parameters The introduction to the OGC SWE framework presents the existing specifications and explains how the different SWE components interact. This is followed by a description of the SWE implementations created by 52 North which were used for realising 185

the scenario. A detailed description of the resulting system is given in the next section. The paper concludes with a short summary of the experiences made during the implementation. 2.

2 the scenario. A detailed description of the resulting system is given in the next section. The paper concludes with a short summary of the experiences made during the implementation. 2. Sensor Web Enablement The Sensor Web Enablement (SWE) architecture employed in the solutions presented in this paper was developed by a working group of the Open Geospatial Consortium (OGC). The OGC is an international standards organisation comprising more than 380 members. It aims at developing standards which allow the "geo-enablement" of the internet, leading to the creation of the so called Geospatial Web. In order to achieve this goal, the OGC applies a consensus-based process for defining and agreeing on appropriate standards. These standards address data formats as well as service interfaces. Well-known examples of such standards are the OGC Web Map Service (WMS) and KML (Wilson 2008). In addition, OGC standards are the foundation on which spatial data infrastructure initiatives and developments such as INSPIRE or GEOSS are based. Through its partner network, especially the University of Münster, 52 North is directly involved in the OGC standardisation process. Members of this research group have directly contributed to most of the SWE standards. Furthermore 52 North and the University of Münster are regular participants to OGC testbeds in which new ideas and concepts are practically evaluated. Within the broad range of OGC standards, the SWE framework addresses the integration of sensors and sensor data into the Geospatial Web. The SWE framework is formed by a suite of standards that define data formats for sensor data and metadata as well as interfaces for accessing sensor data, controlling sensors and alerting (Botts et al. 2006). SWE standards can be divided into two groups: the information model which contains data format standards and the service model that deals with standardised web (service) interfaces for providing the necessary functionality. Figure 1 gives an overview of the different standards within the SWE framework. The abbreviations used in this illustration will be explained in the following sections. Figure 1: Overview of the SWE framework 186

3 2.1 The SWE Information Model As explained above, the SWE information model deals with the definition of data and metadata encodings. Specifically, it comprises the following standards: SWE Common (Botts 2007): SWE standards rely on the use of a common basis of data building blocks (e.g. for expressing values or basic data types). These elementary types are provided by SWE Common. Sensor Model Language (SensorML) (Botts 2007): SensorML is a system for encoding sensor metadata. This makes it possible to provide information about sensors, measuring processes or processing steps. This information enables the interpretation of sensor data and the assessment of data quality, and allows decisions to be made about the suitability of a data set for a certain task. Observations & Measurements (O&M) (Cox 2007): Whereas SensorML deals with the encoding of sensor metadata, O&M can be used for encoding the data observed by sensors. Thus, O&M is the data format for exchanging sensor observations. Transducer Markup Language (TML) (Havens 2007): TML combines the encoding of sensor data and metadata. However, it is optimised for supporting the needs of streaming data. 2.2 The SWE Service Model Now that the SWE information model has been introduced, the SWE service model will be explained. Like the information model, the service model also comprises a set of four standards. Sensor Observation Service (SOS) (Na & Priest 2006): The SOS standard defines an interface for accessing the data measured by the sensors. Operations for accessing sensor descriptions or inserting new sensors or sensor data are also available. The sensor data is usually returned using the O&M standard. In most cases, SensorML is used for the sensor metadata. Sensor Alert Service (SAS) (Simonis 2006): Clients using the SAS are able to define the alert conditions to be monitored by a SAS instance. All incoming sensor measurements are then filtered by the SAS and whenever a relevant condition is fulfilled an appropriate alert is transmitted to the subscriber. Sensor Planning Service (SPS) (Simonis 2007): The main function of the SPS is to control the sensors. This may include such tasks as setting the sampling rate for a sensor or defining the areas to be observed by a satellite. The SPS offers a broad range of functions for managing such tasks (e.g. submit new tasks, update tasks, cancel tasks). Web Notification Service (WNS) (Simonis & Echterhoff 2006): The WNS is the final element in the SWE framework. Unlike the other services, the WNS is not directly related to sensors. It is conceived as a help service, which enables asynchronous communication between different SWE components. For example, the SAS can rely on the WNS for transmitting alerts to its subscribers North SWE Implementations The environmental monitoring solution discussed in this paper was built using SWE implementations by 52 North. These implementations are available through a dual license model under the GNU General Public Licence 2 (GPL2) and concurrently under a commercial license. More information and access to the source code can be obtained through the 52 North web site: 52 North Initiative for Geospatial Open Source Software is an international research and development network aiming at fostering innovation through its collaborative software development process. 52 North is an open membership initiative, which is driven by leading research organisations and individuals in the international GIS field. 187

4 52 North s principal partners are the Institute for Geoinformatics at Münster University (Germany), Environmental Systems Research Institute - ESRI Inc. (Redlands, California), con terra GmbH (Münster, Germany) and the International Institute for Geo-Information Science and Earth Observation ITC (Enschede, The Netherlands). The Bundesanstalt für Wasserbau (llmenau, Germany) and the Austrian Research Centers (ARC) are registered as Associated Partner Organisations. 52 North s R&D communities focus primarily on the development of concepts and standards in the field of spatial data infrastructures, in particular Geo Rights Management, Web Processing Services and Sensor Web Enablement (SWE). The 52 North software repositories contain open source implementations of all SWE services in versions which are compliant with their latest specifications. This comprehensive web service framework forms the foundation of the system presented here. In addition, the web-based 52 North Thin SWE client was used for providing web-based access to the SOS and SAS instances deployed. 4. Example of an SWE-Based Environmental Monitoring System In this section, one example of a SWE-based environmental monitoring system is introduced. The system is a solution for monitoring hydrological parameters and was developed in cooperation between the Wupperverband and 52 North (Spies & Heier 2008). The Wupperverband is a public authority responsible for water management in the area of the Wupper River in North Rhine-Westphalia. To facilitate its activities, which range from flood protection to water level management, the Wupperverband defined the following functional requirements: 1. A solution for accessing time series data (i.e. water level measurements or precipitation data) and a client for displaying this data, 2. Notification whenever certain user-defined alert criteria are fulfilled (e.g. when water level exceeds a threshold), 3. A mechanism for controlling pan-tilt-zoom surveillance cameras that observe rain detention basins. An instance of the 52 North SOS was set up to realise the first functional requirement. The SOS makes it possible to access the data measured by water level gauges and weather stations. A link to an existing database was set up at the back end of the SOS instance. This makes it possible to use the existing infrastructure for transferring the data from the sensors to a central server. Using the SOS, the sensor data is available through a standardised interface, in a well-known format. In the next step, this data is visualized. Using the SOS as a standardised data-access interface, the sensor data can be integrated into any SOScompliant application. This could be GIS software, but it can also be the web-based 52 North SOS client that was developed within the context of this project. Figure 2 gives an overview of this client. The main function comprises the visualisation of time series data collected by sensors. Besides supporting such functions as the overlay of diagrams representing time series data from multiple sources, it is also capable of displaying additional metadata about the sensor. A tabular view of measured data and export functionality (e.g. CSV or PDF) is also available. 188

Figure 2: Overview of the monitoring system for hydrological parameters The second aspect, the sending of an alert when certain conditions are satisfied (e.g. a threshold level is exceeded) relies on the same existing sensor infrastructure.

A web-based interface is used for submitting such criteria. This interface gives users options for defining the various alert conditions and for entering the communication endpoints (e.g. SMS or phone numbers) to which the alerts are to be delivered.

5 Figure 2: Overview of the monitoring system for hydrological parameters The second aspect, the sending of an alert when certain conditions are satisfied (e.g. a threshold level is exceeded) relies on the same existing sensor infrastructure. In this case, the sensor data is delivered to a 52 North SAS instance which continuoulsy analyses the incoming data for compliance with user defined criteria. A web-based interface is used for submitting such criteria. This interface gives users options for defining the various alert conditions and for entering the communication endpoints (e.g. SMS or phone numbers) to which the alerts are to be delivered. Typical alert conditions that are supported within the implemented application are: Please send a SMS notification to the phone numer if the water level at the gauge XY rises above 200 cm or falls below 50 cm. Please send an notification to xyz@abc.de if the precipitation within one hour exceeds 50 mm at the weather station XY. Based on these criteria, the SAS is able to detect critical measurements. In this case it relies on the WNS, which is capable of transferring the respective alert messages by way of the user-defined protocol to the registered subscribers. 189

The third and final functional requirement concerns sensor control. Several infrastructure elements operated by the Wupperverband are situated in quite remote locations.

In such cases, surveillance cameras are an important means of performing remote monitoring of critical areas.

52 North SPS instances are used to control the camera. This makes it possible to control cameras with potentially different hardware interfaces, using a single common SWE interface.

6 The third and final functional requirement concerns sensor control. Several infrastructure elements operated by the Wupperverband are situated in quite remote locations. Often, it is not feasible to deploy permanent personnel to continuously monitor the infrastructure. In such cases, surveillance cameras are an important means of performing remote monitoring of critical areas. In order to flexibly set the observed areas, pan-tilt-zoom cameras are deployed, to enable a camera to focus on those features that are of interest. 52 North SPS instances are used to control the camera. This makes it possible to control cameras with potentially different hardware interfaces, using a single common SWE interface. In addition, due to privacy issues, the SPS offers the option to restrict the field of view of the surveillance cameras. Several infrastructure elements that are monitored with surveillance cameras are located near other private or public properties for which it is forbidden to perform video surveillance. Thus, for each camera, specific pan, tilt and zoom parameter ranges can be blocked. The user interface for the surveillance cameras consists of a Java application that interactively allows to set the according camera parameters and shows at the same time the current camera image. Figure 3 shows a summary of the solutions for the use cases described in this section. It shows how the different SWE services: SOS, SAS, SPS and WNS, are orchestrated. Basically, the SWE services form a middleware that works on a layer between the end-user applications and the sensors. Figure 3: Overview of the monitoring system for hydrological parameters 5. Future Work The evaluation of the SWE technology within the described system proved the suitability of the SWE technology for building productive systems. At the same time, further enhancements are planned to be addressed as future work. One topic of special importance is the support of discovery mechanisms for the sensor web. Especially the integration of sensors and SWE services into the OGC Catalogue Service is a necessity to achieve a full integration of the SWE framework into spatial data infrastructures. 190

7 Another aspect is the enhancement of alert mechanisms. Especially the definition of complex alert conditions taking into account spatial, temporal and thematic criteria but also allowing the combination of multiple alert criteria is an ongoing work item. Finally, the practical application at the Wupperverband has shown a significant demand for supporting the SWE concepts on mobile devices. Thus, it will be investigated how SWE client applications for devices like mobile phones and PDAs can be designed. 6. Conclusion This article describes how the OGC SWE framework can be applied in the domain of environmental monitoring. It shows how standardised components can be used together with 52 North open source SWE implementations for efficiently building systems that integrate (real-time) sensor data. It is apparent from the implementation and operation of the described systems that the SWE framework has now reached a solid and mature state. It is therefore now possible to enhance currently existing concepts of spatial data infrastructures by employing real-time data sources and thus achieve a more powerful environmental monitoring system, which is capable of handling highly dynamic processes. Since the SWE component interfaces are standardised, it is possible to employ the solutions presented in a broad range of domains. Apart from being used in a hydrological context, the SWE framework has already been employed in such scenarios as forest fire fighting, fire detection in buildings, air pollution monitoring and even in a tsunami early warning system. In summary, the SWE architecture offers a sound framework which allows the easy construction of powerful sensor based environmental monitoring systems. References Botts, M., G. Percivall, C. Reed and J. Davidson (2006). OGC White Paper OGC Sensor Web Enablement: Overview and High Level Architecture, OGC r2, Wayland, MA, USA: OGC. Botts, M. (2007). Sensor Model Language (SensorML) Implementation Specification, Version 1.0, OGC, , Wayland, MA, USA: OGC. Cox, S. (2007a). Observations and Measurements Part 1 Observation schema, Version 1.0, OGC, r1, Wayland, MA, USA: OGC. Cox, S. (2007b). Observations and Measurements Part 2 Sampling Features, Version 1.0, OGC, r3, Wayland, MA, USA: OGC. Havens, S. (2007). OpenGIS Transducer Markup Language (TML) Implementation Specification 1.0.0, Wayland, MA, USA: OGC. Na, A. and M. Priest (2006). Sensor Observation Service 1.0, Wayland, MA, USA: OGC. Simonis, I. (2006). Sensor Alert Service, Version 0.9, OGC, r3, Wayland, MA, USA: OGC. Simonis, I. (2007). Sensor Planning Service Implementation Specification, Version 1.0, OGC, r3, Wayland, MA, USA: OGC. Simonis, I. and J. Echterhoff (2006). Draft OpenGIS Web Notification Service Implementation Specification, Version 0.0.9, OGC, , Wayland, MA, USA: OGC. Spies, K.-H. and C. Heier (2008): OGC Sensor Web in der Praxis - Bereitstellung von Sensordaten in Geodateninfrastrukturen und personalisierter Hochwasserwarndienst, Proceedings 20. AGIT- Symposium Salzburg, July , Salzburg, Austria, pp Heidelberg: Wichmann. Wilson, T. (2008). OGC KML, Version 2.2.0, OGC, r2, Wayland, MA, USA: OGC. 191

Sensor Web Technology for Sharing Hydrological Measurement Data

Sensor Web Technology for Sharing Hydrological Measurement Data IHW-netwerkdag 2017 Simon Jirka (jirka@52north.org) Sharing Hydrological Measurement Data Sensors capture a multitude of in-situ data relevant