SENSOR WEB SERVICES FOR EARLY FLOOD WARNINGS BASED ON SOIL MOISTURE PROFILES

As result of improved computing and communication capabilities, the use of sensors and sensor networks for environmental monitoring has gained considerable importance in the recent years. For an interoperable integration of sensor data like sensor descriptions, sensor measurements and alarm events, the Open Geospatial Consortium (OGC) started the Sensor Web Enablement (SWE) initiative and proposed several specifications in respect to a geospatial sensor web. First implementations of SWE software frameworks are available. In this paper, we present the results of the recent WEBBOS project. Its objective was to build up a system for early flood warnings by measuring soil moisture profiles. The use of soil moisture profiles is motivated by the fact that traditional approaches like the observation of water gauges are suitable for the prediction of large-river flooding but not for smaller drainage areas. We describe the architecture of our system and how it is built up by using existing software components to a large extent. Our special focus is on the incorporation of 3D soil moisture profiles into the SWE data model, on the integration of the new OGC Sensor Event Service, and on the development of a flexible web client for mapping and other visualization purposes. * Corresponding author.


INTRODUCTION
Recent disastrous floodings have demonstrated the demand for early flood warnings.This need will be enforced by the expected climate change that probably leads to more torrential rain.In general, flood forecasts concentrate on large rivers considering water gauges.However, there exist a large number of smaller drainage areas with a size of 100 to 1000 square kilometers.In such areas, disastrous drainages may happen after heavy rain that cannot reasonably be observed by gauges because the water level changes very fast what prevents warnings to be made in time.
Thus, the creation of early flood warnings for small drainage areas is still an unsolved challenge.One promising approach for solving this problem is the observation of the soil humidity because that measure decides how much of the precipitation will drain off.WEBBOS is a joint project of the Mannheim University of Applied Sciences and the Oldenburg University of Applied Sciences funded by the German Federal Ministry of Education and Research.It has the objective to build a webbased sensor system for early flood warnings by measuring soil moisture profiles.Within this project, special sensors measuring the soil humidity in different depths have been developed and successfully tested.These sensors were integrated into sensor nodes that form local sensor networks.Such a sensor network should be located in an area with a high variety of soil humidity.
Like in other early-warning and disaster management systems, it is important to incorporate the sensor measurements into a geospatial information service that allows managing sensor data.This encloses the visualization of the sensor measurements and the control of the soil humidity sensors as well as the detection and processing of alarm events.Interoperability is an important issue for such systems.Therefore, the Open Geospatial Consortium (OGC) started the Sensor Web Enablement (SWE) initiative some years ago and specified several services and data models in the meantime (Botts et al, 2006).
WEBBOS implemented its information system using those specifications and a popular open-source SWE framework.Many standard requirements can be solved by such an approach without additional efforts.However, often there are important demands that need more sophisticated solutions.Those cases and their solutions for the WEBBOS project will be discussed in this paper.One important aspect is that the use of soil moisture profiles requires temporal 3D measurements and 3D models of soil humidity for each sensor network: Only the relation and difference between the humidity in different depths and their development over the time allow detecting relevant events.The temporal aspect is sufficiently covered by the current SWE specifications.However, these specifications and their implementation are mainly 2D-oriented.
Another important issue for early-warning and disaster management systems is the detection of potentially dangerous situations.This requires the description and detection of spatiotemporal events.For this purpose, the OCG recently proposed the Sensor Event Service (SES) (Echterhoff & Everding, 2008) together with the Event Pattern Markup Language (EML) (Everding & Echterhoff, 2008).Until now, only few applications of the SES exist.Thus, the experience is limited.
Standard visualization tools are often not sufficient for an adequate visualization of sensor data.However, the use of SWE services restricts and formalizes the syntax and semantics of the sensor measurements and of sensor metadata.Therefore, open toolkits are well-suited for developing flexible solutions that can be easily adapted to the requirements of special applications.The WEBBOS project followed this approach by using a JavaScript mapping library.The web client developed by the project allows retrieving sensor data and metadata as well as controlling and evaluating the SES.
The rest of the paper is organized as follows: In the next section we present the overall architecture of our early-warning system.This is followed by the presentation of the data model for the sensors.Section 4 deals with the event service and alert generation.The web client is presented in Section 5.In the sixth section we discuss related work.The paper concludes with a short summary and an outlook to future work.

Sensors and Wireless Sensor Network
The observation of the soil humidity for early flood warnings requires (i) the measurement of soil humidity in different depths and (ii) the observation of the soil humidity in areas with a high variety of soil humidity (Hübner et al. 2010).Moisture sensors are based on the dielectric properties of water.The higher the content of water, the higher is the permittivity (i.e. the electric conductivity).However, there is no unique relation between water content and permittivity.This relation depends on factors like soil density, soil type, grain geometry, temperature and so on.Thus, a material-specific calibration is required.Within the WEBBOS project, two specific sensor types have been developed and evaluated: 1.) a ring sensor like it is depicted on the left side of Figure 1

Web Services and Client
For systems like early-warning systems and disaster management systems, a standardized and interoperable access to the sensor measurements is important (Annoni et al., 2005).As mentioned in the introduction, the geospatial web services introduced by the OGC SWE initiative allows a web-based incorporation of sensor data into specific applications.WEBBOS integrated -like many other geospatial sensor web projects (see Section 6) -the Sensor Observation Service (SOS) (Na & Priest, 2007) for requesting sensor measurements according to the Observations and Measurements (O&M) specification (Cox, 2007) and sensor metadata according to the Sensor Model Language (SensorML) specification (Botts & Robin, 2007).In addition the Sensor Event Service (SES) (Echterhoff & Everding, 2008) was used for detecting events and alert -details are presented in Section 4.
WEBBOS implemented its SWE services by using the popular open-source Sensor Web framework of 52° North (http://52north.org/communities/sensorweb/).This allows a fast development of operating SWE services.In return, sensors and measurements have to observe the given 52°N database schema.The resulting data model is discussed in Section 3.
For visualization and management purposes web-based map clients are a suitable choice.For this purpose, standard visualization tools like WMS clients miss functionality.This had led to the development of special SWE solutions (see also Section 6).For the WEBBOS project we extended the popular open-source JavaScript mapping library "OpenLayers" (http://www.openlayers.org).Beside the visualization of sensors and sensor data, the web client allows also controlling and evaluating the SES.Details are presented in Section 5.

Integration and Evaluation
The overall architecture is illustrated by Figure 3.It shows the data flow from the sensors via SWE services to a web client.Beside laboratory tests, the sensors and the service connection were successfully tested in two field tests in the area of the Sulm River and -beyond the original project objectives -for the a soil moisture monitoring of vineyards.Figure 4 shows the base station and radio module, which is connected with the humidity sensors.The vineyard application is later depicted in Figure 7.

DATA MODEL
The evaluation of soil moisture profiles requires temporal 3D measurements and 3D models of soil humidity for each sensor network: Only the relation and difference between the humidity in different depths and their development over the time allow detecting relevant events.The measurements in Figure 5 illustrate this: After a rainfall only the two sensors near the surface (in red level 1 and in yellow level 2) show a significant growth of soil humidity.After several rainfalls (in the right part of the diagram) also the humidity rises in deeper regions (in cyan level 3 and in green the deepest level 4).The soil is no longer able to absorb water and the danger of floods increases significantly.As mentioned in the introduction, the temporal aspect is sufficiently covered by the current SWE specifications.It is also quite typical to measure different physical phenomena at one 2D-location (e.g., temperature, humidity, air pressure etc.).
In our case, however, the soil humidity is measured by several sensor rings or sensor parts at the same 2D location in different depths.This property demands for a suitable 3D representation.
For using an existing SWE framework, the given database schema implementing the current service specifications should not be modified.As a result, a complete multi-part sensor or a ring sensor with all of its rings is considered as one procedure.
The 3D position of a single ring is described as a feature_of_interest.An observation (i.e., one measurement of one ring at one instant of time) is assigned to exactly one procedure and to one feature_of_interest.
Thus, all required properties can be derived.All sensors of one sensor network are combined by an offering.One -from the point of view of the authors -unnecessary and objectionable restriction is that one observation can only belong to one offering.As consequence, the request other combinations (e.g., all measurements of the sensors of level 4) require more expensive filter definitions.
In addition to soil humidity, temperature and voltage recordings are included into model as phenomena.

EVENT SERVICE
The Sensor Event Service (SES) fits almost perfectly to the needs for an early-warning system, especially the benefits of complex event processing for the evaluation of potentially dangerous situations.The SES does improve the former Sensor Alert Service (SAS) (Simonis 2006) with various enhancements for event processing and communication protocols.The only available reference implementation of the Sensor Event Service has been developed by 52° North (http://52north.org/communities/sensorweb/ses/0.0.1/).Although the framework is in an early development state, it has turned out as usable for event processing within the WEBBOS project.
The first step was to incorporate the SES into the WEBBOS infrastructure.The SES can be easily integrated in the existing Sensor Web infrastructure in addition to a common Sensor Observation Service because of the uniform communication formats used for SWE services.The SES works as a standalone service handling different types of messages like O&M documents with observation data and SensorML documents for sensor registration.It supports three different levels of filter definitions to define an event for subscription.There exist several methods to connect the SES to an existing sensor observation system.One possibility is to customize the sensor software so that the sensor system itself sends its data additionally to the service.Another way to connect the service is to use a gateway service that receives the sensor data and forwards it to all services.With this solution no customization is needed.A third approach is an indirect forwarding to the event service by retrieving new sensor data from the existing observations database.No changes to the existing service architecture are needed for this alternative.Since the data for the SOS is directly transferred into the database of the SWE server, the third solution has been chosen for integrating the event processing service into the WEBBOS system.
For supporting this approach, a solution from 52° North was developed (https://svn.52north.org/cgi-bin/viewvc.cgi/ incubation/SES-SOS-Feeder/?root=sensorweb).This so-called "SES-SOS-Feeder" can be configured to automatically register available sensors from existing observation services.After registration, the feeder starts to query for new sensor observations within a user-defined minimal time interval.The interval will automatically be adjusted within the update cycles according to the availability of new values.
A user can subscribe for an event that he defines in a subscription request.This request can be created and subscribed using the administration client, which is described in the next section.The subscription contains information of the receiver, where the notification will be sent, besides the event specification itself.Within the WEBBOS project, a special SES client has been developed to receive the event notification from the SES.It is used to store events locally on the receiver's computer system.If the event server sends a notification, the SES client informs the user that a new event occurred and caches the message for further analyses and actions.

WEB CLIENT
On the top of the SWE services, a client is required for visualizing and analyzing the results of the measurements as well as for management purposes.This client should be flexibly usable and extensible.Therefore, a system-independent web client was designed and developed.For evaluating and comparing the properties of different solutions, several prototypes were implemented that are based on different software frameworks.First, a client (depicted in Figure 6) was developed using the UMN Map Server (http://mapserver.org) and the "Mapbender" framework for spatial data infrastructures (http://www.mapbender.org).Sensor information was integrated by using WMS and WFS.For the second solution, "Mapbender" was replaced by the JavaScript mapping library "OpenLayers" (http://www.openlayers.org).Also this approach requests the SOS indirectly by using WMS and WFS.Both solutions have shown that a seamless integration of a SOS into existing geospatial web services can be achieved with low efforts.However, because these services do not consider the specific properties of sensor data, both implementations are relatively inflexible and complicate more SWE-related extensions.The measurements are visualized by the JavaScript plotting library "flot" (http://code.google.com/p/flot/)which is based on "jQuery" (http://jquery.com/).Figure 7 gives an impression of the web client depicting SensorML and O&M results received by SOS requests.An event can be subscribed from the SES via a web request that contains its definition.Therefore, an event administration client has been developed.It can connect with an SES for requesting the service capabilities which include registered sensors and available filter functionality for the event definition.The client then extracts the capabilities from the result message returned from the event service (see Figure 8).To define an event, the user creates a filter request within a subscription document.The phenomenon can be chosen from a list of phenomena specific for each registered sensor.The subscription document is visualized as a tree and can directly be created, customized, submitted with the administration client; an example is shown in Figure 9.After a subscription has been submitted successfully, the service starts processing.The final web client allows visualizing the events that have been cached by the SES client (Figure 10).If an event message was received by the SES client, the web client can be used to evaluate in detail the situation that led to the alert.The web client shows a list with an overview of all events that occurred.
A single list item can be expanded to give a detailed description of the event.In addition, the corresponding history of measurements can be visualized using the plotting functionality of the client.
Figure 10.Extended Web client and SES-Client.

RELATED WORK
In the last few years, several projects started that use SOS services for early-warnings systems in respect to flooding.One prominent example is the Tsunami Service Bus of the German Indonesian Tsunami Early Warning System (GITEWS) (Fleischer et al., 2010) which uses SOS, the Sensor Planning Service (SPS), SAS and the Web Notification Service (WNS).
Other projects related to flooding observe water gauges or groundwater levels, e.g., by the Wupperverband SWE project (Spies & Heier, 2008) or within the Dutch spatial data infrastructure (Jellema & Gijsbers, 2008).None of those projects focuses on early flood warnings based on soil moisture profiles.
Like GITEWS, other SWE early-warning systems often use the combination of SOS, SPN, SAS and WNS.A typical example is the European project OSIRIS (OSIRIS Consortium, 2009) that developed an open architecture for smart and interoperable networks in risk management based on in-situ sensors and demonstrated the deficiencies of SAS/WPN.Experiences with the SES are rare; for an overview see (Bröring et al., 2011).
Similarities with WEBBOS in objective and services used has CSIRO's "South Esk Hydrological Sensor Web", which monitors the water cycle in Tasmania and particular forecasts the short-term river flow (Guru et al., 2008).
Since version 2.9, OpenLayers also provides a native SOS support (http://dev.openlayers.org/docs/files/OpenLayers/Protocol/SOS/v1_0_0-js.html).However, its functionality is rather restricted.For example, a request of sensor observations over time periods is not supported.Other SWE client projects can be found at http://52north.org/communities/sensorweb/

CONCLUSIONS
In this paper, we presented the results of the WEBBOS project.The objective of WEBBOS has been to build up a system for early flood warnings by measuring soil moisture profiles.We have shown that current SWE services in combination with existing SWE and mapping libraries allow building up a suitable software framework for a web-based sensor system in this application field.The main contributions are:  the incorporation of soil moisture profiles into the SWE data model,  the integration of the new OGC Sensor Event Service, and  the development of a flexible web client for mapping and visualization of the service results including SWE events.
As next step, it is planned to use the WEBBOS system for other types of environmental monitoring, e.g., in the context of coastal protection.Furthermore, it is intended to integrate data stream management systems (Babcock et al., 2002) with their powerful capabilities for complex event processing (CEP) and processing of very large data streams.
and 2.) a multi-part planar sensor shown on right side of Figure1.Both sensor types measure the permittivity.

Figure 1 .
Figure 1.Two types of humidity sensors.The demand for observing areas requires connecting the humidity sensors via a wireless sensor network.In one observation area about 10 to 20 sensors are placed on a strip of 50 to 100 m length.The sensors are connected to one single base unit that enables external communication.Within the project, different network topologies, sensor boards, sensor node operating systems and protocols have been tested.Areas with a high variety of soil humidity are typically found near

Figure 3 .
Figure 3. Overall architecture and data flow.

Figure 4 .
Figure 4. Base station and a radio module.

Figure 5 .
Figure 5. Exemplary measurements of soil moisture in different depths by one sensor.

Figure 6 .
Figure 6.Web client using "MapBender".The final client is also based on OpenLayers.But in contrast to the previous approaches, the extensibility of the open-source software OpenLayers has been exploited.A direct interface to the SOS service was integrated into OpenLayers by a new class

Figure 8 .
Figure 8. Administration client for event subscription.

Figure 9 .
Figure 9. Example for a subscription document in a tree representation.