Automated Integration of Geosensors with the Sensor Web to Facilitate Flood Management

Approaches to Managing Disaster - Assessing Hazards, Emergencies and Disaster Impacts demonstrates the array of information that is critical for improving disaster management. The book reflects major management components of the disaster continuum (the nature of risk, hazard, vulnerability, planning, response and adaptation) in the context of threats that derive from both nature and technology. The chapters include a selection of original research reports by an array of international scholars focused either on specific locations or on specific events. The chapters are ordered according to the phases of emergencies and disasters. The text reflects the disciplinary diversity found within disaster management and the challenges presented by the co-mingling of science and social science in their collective efforts to promote improvements in the techniques, approaches, and decision-making by emergency-response practitioners and the public. This text demonstrates the growing complexity of disasters and their management, as well as the tests societies face every day.


Introduction
It is predicted that severe flooding disasters will occur more and more often in the future, due to expanding land use and an increasing number of extreme meteorological events.For monitoring and managing large-scale floods efficiently, up-to-date information is crucial.Geosensors ranging from water gauges and weather stations to stress monitors attached to dams or bridges are used to gather such information.The various kinds of sensors need to be integrated into an interoperable infrastructure so that the measured data can be easily utilized by different disaster relief organizations.The standardized web service framework of the Sensor Web Enablement initiative (section 2.1) can be used as such an infrastructure, since it has shown its suitability in several projects and applications in past years.However, the integration of newly deployed sensors into the Sensor Web has not been straight-forward.That challenge is addressed by this work.A standards-based architecture enabling the on-the-fly integration of environmental sensors into the Sensor Web is presented.This new approach for an on-the-fly integration of geosensors is generic and can be applied to different types of sensors.We demonstrate and evaluate the developed methods by applying them to the real world use case of the German watershed management organization Wupperverband, where the mobile water gauge, G-WaLe, is used as an example for a new geosensor deployed in an ad-hoc manner to densify the measurement network.
The following section 1.1 introduces the topic of flood management and the need for the incorporation of geosensors into a coherent infrastructure to enable interoperable access to up-to-date information.Next, the problem of an interoperability gap between Sensor Web infrastructures and the used geosensors is outlined as the challenge addressed by this work (section 1.2).Section 2 describes the Sensor Web Enablement initiative as well as the mobile water gauge, G-WaLe, that is used to realize the case study in this work.Section 3.2 introduces the Wupperverband, its network of water gauge sensors, and emerging use cases in context of flood management.Next, section 4 presents the standards-based architecture which is applied to realize the case study, as described in section 5.This chapter closes with conclusions and an outlook to future work.

The need for geosensor infrastructures in disaster management
Two days of heavy rain in the mountains of the Erzgebirge in August 2002 caused a dramatic flooding along the German river Elbe.The disaster caused the death of twelve people and a financial damage of over one billion Euros (Elze et al., 2004).This is just one instance for a dramatic flooding disaster in the past years.The Annual Disaster Statistical Review 2007 (Scheuren et al., 2007) states that during the past twenty years seven million people were affected and almost two thousands were killed by flood disasters in Europe.During the last decade, Europe witnessed eight out of twenty of the largest floods ever recorded.Parry et al. (2007) forecast that such kind of flooding disasters will occur more often and more intensely in future.A reason for this is the still expanding land use within critical areas as well as the number of extreme meteorological events which has constantly increased over the past years as a consequence of climate change.
Another region endangered by floods is the drainage area of the river Wupper in the Northwest of Germany.The last floods in this region occurred in August 2007 and caused severe damages (Boch & Schreiber, 2007).Responsible for the watershed management of the Wupper region is the Wupperverband1 organization.In this article, a flooding scenario in the Wupper region is used to illustrate and apply the developed approach (section 5).
To manage disasters such as large-scale floods, but also hurricanes, earthquakes, storms or wild fires, the supply with up-to-date information is crucial to provide decision support for the responsible organisations.In case of floods, information such as water level and precipitation measurements, weather forecasts as well as the state of dams, bridges and other structures along affected watercourses is required.Geosensors and geosensor networks (e.g., networks of stream gauges or weather stations) are valuable means for gathering precise and high resolution data to derive such information.As the National Science and Technology Council Committee on Environment and Natural Resources published in its report on grand challenges for disaster reduction (Subcommittee on Disaster Reduction, 2008), a key to minimize the damage of natural disasters is the provision of sensor data.This data has to be available in near real time, since disasters are time critical situations in which decisions have to be made ad-hoc.Heterogeneous information sources, e.g., different kinds of sensors, have to be integrated on-the-fly into a coherent infrastructure which can be easily utilized by different disaster relief organizations.This infrastructure has to serve as a basis for decision support systems to control and manage emergency situations.It has to enable discovery, browsing, querying and usage of geospatial information as well as processing capabilities.
Today, sensors are becoming smaller, cheaper, more reliable, and more power efficient.Sensors are increasingly used in early warning systems and disaster management (Shepherd & Kumar, 2005).The kinds of sensors utilized in these applications may be stationary or mobile, either on land, water or in the air and could gather data in an in-situ or remote manner.Due to this variety, a coherent infrastructure is necessary to integrate heterogeneous sensors and to enable interoperable access to their functionality.The idea of the Sensor Web describes such an infrastructure for sharing, finding and accessing sensors and their data across different applications (Nittel, 2009).The Sensor Web is to geosensors what the World Wide Web (WWW) is to general information sources -an infrastructure allowing users to easily share their sensor resources.It encapsulates the underlying layers, the network communication details, and heterogeneous sensor hardware, from the applications built on top of it.
The Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC)2 develops standards for Web service interfaces and data encodings which can be used as building blocks for a Sensor Web (section 2.1).SWE incorporates different models for describing sensors and representing sensor observations.Further, it defines Web service interfaces leveraging the models and encodings to allow accessing of sensor data, tasking of sensors and alerting based on gathered sensor observations.The SWE standards serve the functionality to integrate sensors into Spatial Data Infrastructures (SDI).The integration of sensor assets into SDIs makes it possible to couple available sensor data with other spatio-temporal resources (e.g., maps, raster as well as vector data) on the application level which maximizes the information effectiveness for decision support.Due to this integration, Sensor Webs and their comprised geosensors represent a real-time link of Geoinformation Systems (GIS) into the real world.
In recent years, these SWE standards have demonstrated their practicability and suitability in various projects (e.g., (Chung et al., 2009;Jirka et al., 2009;Schimak & Havlik, 2009)) and applications (e.g., (Aasa et al., 2008;Bröring, Jürrens, Jirka & Stasch, 2009;Foerster et al., 2009;Fruijtier et al., 2008)).However, there is still a fundamental challenge currently unresolved, the ability to dynamically integrate sensors in an on-the-fly manner.The integration of sensors into the Sensor Web with a minimum of human intervention is not possible with the given methods and designs.Especially in the above described disaster situations it is required to enable a live deployment of sensor networks and an ad-hoc integration of those sensors into the Sensor Web to allow multiple parties an easy access and usage of the geosensors.Those emergency scenarios require the incorporation of various sensor types.This article addresses the challenge of integrating geosensors on-the-fly towards a true plug & play of sensors with the Sensor Web.

The interoperability gap between sensors and the Sensor Web
Dynamically integrating geosensors on the Sensor Web requires advanced concepts.Generally, the SWE standards focus on interacting with the upper application level, since they are designed from an application-oriented perspective.The interaction between the Sensor Web and the underlying sensor layer has not yet been sufficiently addressed.In consequence, a gap of interoperability between these two layers arises.This interoperability gap results from the fact that both layers are designed with different objectives and approaches.The Sensor Web is based on the WWW and its related protocols.Geosensors, on the other hand, communicate based on lower-level protocols.These protocols follow rarely standards for instrument communication, such as IEEE 1451 (Lee, 2000), but instead are usually manufacturer dependent; see for example protocol specifications for typical oceanographic sensors from Sea-Bird-Electronics (2010), WETLabs (2010), or HOBILabs (2008).
From an application perspective, the SWE services encapsulate associated geosensors and hide their lower-level communication protocols.So far, the integration of a geosensor with the Sensor Web involves two major steps: first, driver software needs to be implemented which converts measured data from the native sensor protocol to higher level Sensor Web protocols, and second, the geosensor description has to be manually registered at a Sensor Web service.I.e., proprietary bridges have to be manually built between each pair of SWE service and sensor type (figure 1).This approach is cumbersome and leads to an extensive adaption effort for linking the two layers.Since the price of sensor devices is decreasing rapidly, these adaption efforts become the key cost factor in developing large-scale sensor network systems (Aberer et al., 2006).Besides those infrastructural deficits in the current Fig. 1.The three layers of the geosensor infrastructure stack and the interoperability gap.
Sensor Web design, there is a mismatch between low-level data structures used in sensor protocols and the high-level information models of the Sensor Web.This issue relates to semantic challenges which have to be tackled to enable an automatic integration of sensors as discussed in (Bröring, Janowicz, Stasch & Kuhn, 2009).The main difficulty lies in mapping the relationship between the different Sensor Web concepts used for modeling sensors, observations, and features to the constructs of the lower sensor layer.An example challenge is to guarantee that the output of a geosensor, e.g., a value symbol gathered by an anemometer for the observable wind direction, complies not only syntactically but also semantically with a certain characteristic of a real world entity's representation residing on the Sensor Web level.Currently, these matchings have to be established and maintained manually by an administrator.The Sensor Web is missing mechanisms which ensure a correct semantic matching without user interaction to enable an automatic registration of sensors.
In future, Sensor Webs could be set up for certain geographic regions.SWE services, which build this Sensor Web, are only interested in sensors within that particular region, provide access to their data or enable their tasking.Various sensors of different type could register and upload their observations.Taking into account mobile sensors moving in and out of these regions, the above described problems become even more pressing.Methods enabling an automatic integration of sensors are needed to tackle those kinds of use cases.
Overall, the described obstacles are currently hindering an on-the-fly integration of sensors with minimal human intervention.In case of the Wupperverband's sensor network, serving as an application scenario in this article, these issues lead to a huge effort when integrating new geosensors or adjusting the existing infrastructure to optimize the monitoring of geo phenomena.To enable a timely reaction in disaster situations and to supply decision makers with necessary information, the demand for solutions coping with these problems is immense.
Hence, this work combines results of our previous work to design an architecture that facilitates the connection of the sensor layer and the Sensor Web layer.We apply this architecture here to enable the on-the-fly integration of a mobile water gauge, a sensor system that can be used to support flood management.The architecture incorporates first the Sensor Bus (Bröring, Foerster, Jirka & Priess, 2010), an intermediary layer that introduces a publish/subscribe mechanism between the Sensor Web and underlying geosensor networks.This is required to make services aware of new sensors appearing on the Sensor Web.Second, a driver mechanism for sensors is incorporated in our approach -the Sensor Interface Descriptor (SID) concept (Bröring, Below & Foerster, 2010).The SID model extends OGC's SensorML standard to describe the protocol of a particular sensor type in a declarative way.By means of a generic SID interpreter, the native sensor protocol can be translated to the SWE protocols.

Background
This section provides information on the Sensor Web Enablement initiative and its specifications (section 2.1).Further, the G-WaLe sensor system is described.These football-sized mobile buoys are capable of observing water level and are used in this work to demonstrate the developed architecture for an on-the-fly integration of geosensors (section 2.2).

Sensor Web enablement initiative
The goal of the Sensor Web is to allow Web-based sharing, discovery, exchange and processing of sensor observations, as well as task planning of sensor systems (Nittel et al., 2008).The Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC) defines standards which can be utilized to build such a Sensor Web (Botts et al., 2008).SWE standards make sensors available over the Web through standardized formats and Web service interfaces by hiding the sensor communication details and the heterogeneous sensor protocols from the application layer (Bröring, Echterhoff, Jirka, Simonis, Everding, Stasch, Liang & Lemmens, 2011).
The main Web services of the SWE framework are the Sensor Observation Service (SOS) and the Sensor Planning Service (SPS).The SOS (Bröring, Stasch & Echterhoff, 2010;Na & Priest, 2007) provides interoperable access to sensor data as well as sensor metadata.To control and task sensors, the SPS (Simonis, 2007) can be used.A common application of SPS is to define simple sensor parameters such as the sampling rate but also more complex tasks such as mission planning of satellite systems.Apart from these Web service specifications, SWE incorporates information models for observed sensor data, the Observations & Measurements (O&M) (Cox, 2007) standard, as well as for the description of sensors, the Sensor Model Language (SensorML) (Botts, 2007).
SensorML specifies a model and encoding for sensor related processes such as measuring or post processing procedures.Physical as well as logical sensors are modeled as processes.The functional model of a process can be described in detail, including its identification, classification, inputs, outputs, parameters, and characteristics such as a spatial or temporal description.Processes can be composed by process chains.
O&M defines a model and encoding for observations.An observation has a result (e.g., 3.52 m) which is an estimated value of an observed property (e.g., water level), a particular characteristic of a feature of interest (e.g., the Wupper river at section 42).The result value is generated by a procedure, e.g., a sensor such as a water gauge described in SensorML.These four central components are linked within SWE.

G-WaLe -A mobile water gage
The G-WaLe sensor system consists of mobile buoys capable of observing the water level by measuring the position in three-dimensional space via satellite positioning systems.The key parts of the G-WaLe system (Beltrami, 2007) are the sensing devices, so-called floaters.These geosensors can be stationary anchored within a river or can be placed on demand within a flooded area.A floater is equipped with a satellite navigation receiver, a battery, memory, as well as a communication unit.The positioning data received from the satellites is internally stored and regularly transmitted via GSM or radio to a central receiver station (see figure 3).To increase the accuracy of the measurements, local reference stations can be incorporated in the positioning process, so that a positioning accuracy of around 10 cm can be achieved.In Germany, the SAPOS system3 can be utilized for that.The water level is derived from the vertical component of the position measurement.Once the position data is transmitted from the G-WaLe floater to the receiver station, the data are accessible on an FTP server.

Flood management in the Wupper region
In the following, the Wupperverband and its role in flood management is outlined.Subsequently, an overview of the administered drainage area and potential flooding scenarios within that geographic region are outlined.Based on these considerations, the section finalizes with a presentation of different hypothetic applications for an on-the-fly integration of geosensors with regards to flood management.These example use cases serve as basis throughout the further work.

Existing water gage network
The Wupperverband is a statutory corporation whose members are for instance municipalities, water distribution companies, or industrial firms.The main responsibilities of the Wupperverband are the provision of drinking water, the operation of sewage treatment plants, the water level management including the backfilling in case of low waters, as well as the maintenance and ecological development of the river systems.Additionally, an important activity of the Wupperverband is the flood protection as well as the monitoring and warning in case of floodings.To accomplish these functions large amounts of measurement data   (Beltrami, 2007).
have to be gathered, processed, analyzed and maintained.In the hydrology domain, the Wupperverband collects measurement parameters such as the stream flow amount, water level, groundwater level, or the amount of seeping water.Meteorological parameters which are of interest include precipitation data, air temperature, barometric pressure, humidity or wind direction and speed (Sat et al., 2005).
The Wupperverband is responsible for the management of over 3.000 bodies of water with an overall length of about 2.000 kilometers in the catchment area of the Wupper, which has a size of about 815 square kilometers (see Figure 4 4 ).The terrain of the region rises from West to East which results in a heterogeneous precipitation distribution.With maxima of about 1.400 mm per year, the average annual precipitation in the Wupper drainage area can be considered as very high.Another important characteristic of the region is the population density, with 1.169 inhabitants per square kilometer, is around five times higher compared to the rest of Germany.The overall population of the region is 950.000(Wupperverband, 2001).To monitor the parameters of interest within the catchment area of the Wupper, the Fig. 4. The Wupper drainage area Wupperverband operates over 50 weather stations and about 60 water gauge stations.Those water gauges are fixed installations and of various kind (e.g., staff gauges, ultrasonic gauges or radar gauges).At some gauges the water level needs to be looked up manually or a data logger needs to be read out on-site.Others support a remote transmission of the gathered data for example via telephone or GPRS .
Since the region is densely populated, large parts of the watercourses are channeled, the river banks within settlement areas are consolidated and partly outside of settlement areas, too.Thus, infrastructure objects, such as bridges or dams, reduce the discharge capacity considerably in places.The experiences of the disastrous flood at the watercourses of the Erzgebirge mountains in August 2002 have shown that such kinds of bottlenecks are often incapable of coping with the water volume of hundred-year floods (Elze et al., 2004).Thus, these objects are potentially endangered to get damaged which may cause further destructions.
In case of floodings, a potential risk goes out from industry facilities, such as plants or pipelines.Such facilities can particularly be found in the area of the lower Wupper and within the area where the Wupper empties into the Rhine.Other examples of endangered facilities are sewage treatment plants which are only capable of coping with a certain water level.These kinds of facilities demand a specific protection by technical emergency services.Also, gas storage tanks on the property of private households are at risk in flooding situations.These kinds of risks may result in subsequent water pollution, chemical spills, or industrial fires.The map in Figure 5 shows the region around the mouth of the Wupper into the Rhine.The turquoise areas show the floodplains of the river system officially determined by the public authorities.The plains endangered by regularly occurring floodings are drawn in light blue.To achieve an interoperable access to geosensors, e.g., water gauges and weather  (Spies & Heier, 2008).Thus, the gathered hydrology and weather data are provided via Internet in a standardized way.The interoperable interfaces allow applications of the Wupperverband to work with internal as well as externally provided services.Hence, sensor data served by cooperating organizations (e.g., neighboring watershed management organizations) can be included into the decision making process.On the other hand, the information systems of third party organization are also enabled to work with the sensor data offered by the Wupperverband (Bröring & Meyer, 2008).
The central task of the Wupperverband in the context of flood protection is to create precipitation discharge models for the regional watercourse system.Based on those models, statistically possible flood scenarios (e.g., twenty-year or hundred-year floodings) and their consequences are simulated.The results of these simulations are the foundation for catalogs of countermeasures which aim at minimizing the damage in case of floodings.These are usually long-term measures.Real-time reactions on flood situations are currently not the focus of the Wupperverband.In fact, systems for the real-time management of disasters such as floods are still topic of research.An example for such a system has been developed within the SoKNOS project (Stasch et al., 2008).The objective of that project has been the research and development of concepts which effectively support governmental and industrial organizations in the area of public security.A service oriented approach for an emergency management system has been elaborated which helps technical services in handling disaster situations.The requirements for such emergency management systems are exceptional high, especially concerning scalability and reliability in disaster situations.The methods developed within this research support the development of such systems.However, a fully functional system fulfilling those extremely high requirements of emergency management is not the direct outcome.

Flooding use case
The following hypothetical scenario description is based on the real world flooding of the river Eschbach within the catchment area of the Wupper which happened in August 2007 and caused severe damages in the region (Boch & Schreiber, 2007).
Heavy rainfall is dominating the weather conditions over major parts of western Germany for the past days.This has lead to serious high waters especially along the Lower Rhine and its tributary rivers.During this tense situation, a massive local thunderstorm and heavy rainfalls occur over the greater region of the Wupper drainage area.With over 70 liters per square meter and hour, the measured precipitation amount is at certain weather stations statistically less frequent than every 100 years.Because the soil in the region has already contained much moisture, it is quickly saturated and incapable of absorbing further water.This leads to very high discharge rates along the watercourses of the Wupper region.
Of high importance is that emergency measures are conducted at the right places to assure the protection of critical objects such as dams, bridges or industry facilities.Up-to-date sensor data are the foundation for a sensible decision making.Therefore, the organization for disaster relief cooperates with the Wupperverband and requests water level measurements for all parts of the river basin.These data are necessary to compute the degree of danger of individual river reaches and to create exact situation awareness.
Certain parts of the river courses are not densely enough covered with pre-installed water level gauges.So, the emergency management decides to deploy new mobile geosensors on-the-fly at those reaches of the river.These geosensors increase the temporal and spatial density of precipitation, water level or stream flow measurements.The gathered data serve as input for exact stream flow models in order to compute risk estimations and forecasts.For this scenario, we assume that the Wupperverband is already capable of performing those computations in real-time.
As mentioned above, a local Sensor Web infrastructure is already in place and in productive use for the affected region.It is managed and maintained by the Wupperverband.This infrastructure enables the interoperable access to available water gauges and weather stations and their collected data.The information systems used by the emergency management rely on data provided by this Sensor Web.The newly deployed geosensors have to be made available within this infrastructure in an ad-hoc manner, so that operational applications of the emergency management can directly utilize their collected observations.Immediately after the deployment of the new geosensors in the field, they have to be accessible via the Sensor Web.The existing, persistent water gauges and precipitation sensors of the Wupperverband are partly not equipped with remote data transmission and require a manual readout of the last measured values.Other sensors report their data automatically but with a slow rate.Thunderstorms with heavy rain are short-term events which require a quick reaction time.So, an ad-hoc integration of suitable sensors deployed at endangered locations and transmitting data frequently to a base station can significantly enhance the monitoring and management of the flooding situation.An example for a mobile water gauge sensor, that can be used in the outlined scenario and serves as a test object within this work, is the G-WaLe sensor system as described in section 2.2.
Another example scenario, where an on-the-fly integration of new geosensors facilitates their usage, is construction site monitoring.Constructions built next to or in a water body have to be equipped with multiple kinds of sensors, e.g., to gain information about the quality of the water fed into the river.This use case is not as time critical as disaster management.The construction process is a priori known, at least several weeks before it starts.However, an easy and quick integration of new geosensors into a coherent infrastructure would also facilitate this scenario.

An architecture for the on-the-fly integration of geosensors
In this section, we present an architecture that enables the on-the-fly integration of sensors with the Sensor Web.We apply this architecture to the flood management use case and the G-WaLe sensor system in the following section 5.

Sensor Bus -A publish/subscribe mechanism for the Sensor Web
An automated on-the-fly integration of sensors and Sensor Web services requires a mechanism that enables a sensor to publish its availability as well as its measured data and enables a service to subscribe for sensors to subsequently receive their data.We realize such a publish / subscribe mechanism here by introducing an intermediary sensor integration layer between the sensor layer and the Sensor Web layer; see figure 6.This intermediary layer is externally designed as a logical bus -the Sensor Bus, as developed by Bröring, Foerster, Jirka & Priess (2010).In this article, we make use of the Sensor Bus and combine it with a generic driver mechanism (section 4.2) to apply it to the flood management use case and the G-WaLe sensor.In the following the concept of the Sensor Bus is outlined.Aligned with the message bus pattern (Hohpe & Woolf, 2003), the Sensor Bus incorporates (1) a common communication infrastructure, (2) a shared set of adapter interfaces, and (3) a well-defined message protocol.The common communication infrastructure is realized upon an underlying messaging technology.The Sensor Bus is independent of the underlying messaging technology which can therefore be exchanged.It can, for example, be realized with instant messaging systems such as XMPP5 or IRC6 , but also using Twitter as shown by Bröring, Foerster, Jirka & Priess (2010).Services as well as sensors can publish messages to the bus and are able to subscribe to the bus for receiving messages in a push-based communication style.The different components (i.e., sensors and Sensor Web services) can subscribe and publish to the Sensor Bus through adapters.Those adapters convert the service or sensor specific communication protocol to the internal bus protocol; see figure 7).A Fig. 7. Components of the Sensor Bus.detailed analysis of interactions between the sensor layer and the Sensor Web layer, which emerge when introducing the Sensor Bus as an intermediary layer, is conducted by Bröring, Foerster & Jirka (2010).Those interactions are realized through particular bus messages.The bus contains two different kinds of channels to exchange such messages (figure 7).First, the management channel is used to register a component at the bus and publish its metadata, i.e. sensor characteristics or service requirements.Second, there are communication channels, where sensors publish their measurements.Each communication is dedicated to a particular observed property (e.g., temperature or water level).The most important bus messages realize the following functionalities: • connecting a sensor and passing a sensor description (encoded in SensorML) • subscribing a service for specific sensors by defining required sensor characteristics • publishing data measured by a sensor • directing sensors / services to bus communication channels A detailed description of the message protocol of the Sensor Bus and a proof-of-concept implementation can be found at Bröring, Foerster, Jirka & Priess (2010).

Sensor interface descriptors -A generic driver mechanism for geosensors
Before a geosensor can be integrated with the Sensor Web, a driver is required which understands the native sensor protocol and offers a well-defined interface that makes the functionality of the sensing device available to the outside.Since there are numerous kinds of environmental sensors with various interfaces available, we propose the usage of a generic driver mechanism for sensors.The Sensor Interface Descriptor (SID) model described in our previous work (Bröring & Below, 2010;Bröring, Below & Foerster, 2010) can be used to provide this functionality.The SID model supports the declarative description of sensor interfaces.It is designed as a profile and extension of OGC's SensorML standard (section 2.1).An instance of the SID model, designed for a particular type of sensor, defines the precise communication protocol, accepted sensor commands, or processing steps for transforming incoming raw sensor data.Based on that information, a so-called SID interpreter is able to establish the connection to the sensor and translates between the sensor protocol and a target protocol.For this work, we have developed a generic SID interpreter which acts as a sensor adapter and converts data received from a sensor in order to transfer it to the Sensor Bus; see figure 8. SID interpreters can be built independently of particular sensor technology since they are based on the generic SID model.Figure 9 depicts an excerpt of this model.The blue colored, SID specific classes extend the beige colored classes defined in SensorML.The SID is strictly encapsulated within the InterfaceDefinition element of a SensorML document.Since the SID is designed for a certain type of sensor and not for a particular sensor instance, this encapsulation makes the interface description independent of the rest of the SensorML document.Consequently, it is easily exchangeable and can also be reused in SensorML documents of other sensors of the same type.
The SID model extends the elements of the Open Systems Interconnection (OSI) reference model (ISO/IEC, 1996) which are already contained in SensorML and associated with the interface definition.The OSI model is the basis for designing network protocols and therefore consists of a number of layers.On the lowest layer, the physical layer, the structure of the raw incoming and outgoing sensor data stream is described.This includes the definition of block identifiers and separator signs within the data stream.Next, encoding and decoding steps can be applied to the raw sensor data.Therefore, according processes can be specified and attached to the data link, network, transport, and session layer.Such processing steps Fig. 8. SID interpreter as a sensor adapter for the Sensor Bus are for example character escaping or checksum validation which are necessary for reliable communication with sensors.Finally, the application layer can be used to define commands accepted by a sensor, including their parameters, pre-and postconditions, as well as response behavior.Those command definitions can for example be used by a Sensor Planning Service (section 2.1) to provide an interoperable interface for tasking.A detailed description of the model can be found at Bröring & Below (2010); Bröring, Below & Foerster (2010).Sensor interfaces and communication protocols are often complex.Consequently, the design and manual creation of SID instances is not straightforward.Hence, a visual SID creator has been developed (Bröring, Bache, Bartoschek & van Elzakker, 2011).This graphical tool (see figure 10) supports users in describing the sensor interface and generate SID instances for their geosensors.The creator can be used by sensor manufacturers to create SIDs for their Approaches to Managing Disaster -Assessing Hazards, Emergencies and Disaster Impacts products and provide them to clients for an easy integration of their geosensors with the Sensor Web.Alternatively, this tool can help owners of sensors to create SIDs if they are not already available from the sensor manufacturer.

Application
This section applies the above presented architecture to the use case of a flood in the Wupper region where G-WaLe sensors need to be dynamically deployed to increase the density of the measurement network (section 3.2).A local Sensor Web infrastructure is already in place and built upon the Sensor Bus.New geosensors need to be integrated in an on-the-fly manner.As a proof-of-concept, we demonstrate in the following the integration of the G-WaLe sensor with a Sensor Observation Service.
To connect the G-WaLe sensor to the Sensor Bus we utilize the generic sensor adapter which incorporates an SID interpreter (section 4.2).The SID for the G-WaLe sensor has been designed using the SID creator tool that follows the wizard user interface pattern (Tidwell, 2006).Figure 10 shows the page of the wizard that allows to define how to physically connect to the sensor, e.g., via USB, serial connection, or with an indirect file system connection, as chosen here.The G-WaLe floater devices store measurements in a data file on an FTP folder.These measurement files are read out by the SID interpreter.To enable the SID interpreter to understand the structure of the data file, i.e. the sensor protocol, the page of the SID creator shown in figure 10 further allows to define the structure of the data file.A G-WaLe data file Fig. 10.Sensor protocol defined in SID Creator.contains a timestamp in GPS weeks and milliseconds, the measured elevation in meters, as well as the accuracy of the measurement in meters.Each row of the file represents a data block and ends with the carriage return.The fields of the block are divided by the tab character.An example is shown in listing 1.This structure is defined in the SID creator as shown in figure 10.The signs for block and field separation are specified in ASCII code, i.e., <CR> for a carriage return and <HT> for a tab character.
Listing 1. Example of a G-WaLe data file; each line contains tokens for measured GPS week, GPS milliseconds, elevation (m), and accuracy (m).
1570 547200000 9 3 .8 3 1 0 .0 4 1570 548100000 9 7 .1 6 0 0 .0 4 1570 549000000 9 3 .8 0 4 0 .0 4 1570 549900000 9 1 .5 2 9 0 .0 4 While other sensor protocols contain multiple kinds of data block structures, that can also be defined in the SID creator, the G-WaLe data file uses only one kind of data block structure that contains the four measurement fields.Those fields are named in the SID creator (e.g., the third field is called Elevation), so that they can be referenced during further processing of the data.Listing 2 shows the according SID code generated by the SID creator.
Listing 2. Excerpt of the generated SID file.Once the sensor adapter is started, it sends the message for connecting the sensor to the Sensor Bus and advertises its characteristics.Depending on the phenomenon observed by the sensor, internal management components of the Sensor Bus direct the sensor to the appropriate communication channel.There, the sensor adapter publishes the data measured by the G-WaLe sensor.
Similar to the registration of a sensor, a service adapter subscribes a service, here a Sensor Observation Service (SOS), at the Sensor Bus and defines the sensor characteristics in which the service is interested.For example, a service can declare interest in geosensors which observe the property Elevation.Then, an internal management component of the Sensor Bus points the service to each sensor that matches the requested characteristics and directs the service to the communication channel used by the sensor.Subsequently, the service adapter registers the sensor at the SOS by calling the RegisterSensor operation.
As soon as the sensor adapter publishes measurements in the communication channel, the service adapter inserts that data as observations into the SOS.Therefore, the service adapter transforms the received data to InsertObservation requests and sends it to the SOS.An example of such a request is shown in Listing 3. x l i n k : h r e f =" h t t p :// sweet .j p l .nasa .gov /1.1/ property .owl# E l e v a t i o n "/> < f e a t u r e O f I n t e r e s t > <sa : SamplingPoint gml : id =" p1" > <sa : sampledFeature x l i n k : h r e f =""/ > <sa : p o s i t i o n > <gml : Point > <gml : pos srsName =" urn : ogc : def : c r s : EPSG: 4 3 2 6 " > 5 2 .6 4 7.12 </gml : pos> </gml : Point > </sa : p o s i t i o n > </sa : SamplingPoint > </ f e a t u r e O f I n t e r e s t > < r e s u l t x s i : type ="gml : MeasureType " uom="m" > 9 3 .8 3 1 </ r e s u l t > </Observation > </s o s : InsertObservation > Henceforth, the data is stored by the SOS and available to clients via its standardized interface.It can be accessed and retrieved in a pull-based manner.An example of such a client application which allows accessing and displaying sensor data from an SOS is shown in figure 11 and available as open source at 52 • North7 .
Similarly to registering an SOS, a Sensor Alert Service or Sensor Event Service (section 2.1) can be subscribed at the Sensor Bus to provide data in a push-based manner.Those push-based services receive the incoming data, filter it by certain predefined criteria and forward it to interested clients.
Once available on the Sensor Web, the elevation measurements coming from the G-WaLe sensor can be related to the measurements of water gauges within the same river, and can be used for determination of the moment the wave of the flood passes the mobile water gauge.

Conclusions & outlook
In this chapter, we stress the need for methods that enable an easy and flexible integration of geosensors with the Sensor Web, as a coherent information infrastructure.Thereby, an on-the-fly integration needs to be automated to minimize administration and configuration efforts.Such a facilitated integration of geosensors can support various use cases, in particular disaster management.Here, a flood management use case in the region of the German river Wupper is described, where heavy rain events have caused a local flood.Additional water gauges are needed to increase the measurement density and improve flood management.We demonstrate how the G-WaLe sensor, a mobile water gauge, can be used and dynamically integrated with the Sensor Web by means of the developed architecture.
The architecture consists of (1) the Sensor Bus, a message bus that realizes a publish / subscribe mechanism between sensors and web services and (2) the Sensor Interface Descriptor (SID) concept, a generic driver mechanism for geosensors.Both components are available as open source software at 52 • North8 .The presented approach is generic and in related articles we have shown that it can also facilitate the integration of radiation sensors (Bröring, Below & Foerster, 2010), a basis for managing nuclear disasters, or the integration of oceanographic sensors to fight oil spills or harmful algae plumes (Bröring, Maué, Janowicz, Nüst & Malewski, 2011).
The SID concept enables the operation of geosensors without the necessity of manually implementing a driver for the instrument.Instead, an SID file is created which describes the structure of the sensor's protocol.This SID creation is supported by the SID creator tool.Any SID interpreter implementation that follows the SID specification (Bröring & Below, 2010) can execute the SID file and can communicate with the geosensor.Of course, the current design of the SID model does not accommodate every possible sensor protocol, but a broad variety of manufacturer specific protocols is already covered.Possible extensions of the SID specifications will broaden the range of supported protocols.
For the future, we are particularly interested in applying the developed approach in countries, such as Pakistan where floods have caused enormous damage in the recent past.In under-developed regions, where no static water gauge network is maintained by the state, a system that enables the on demand deployment and on-the-fly integration of water gauge sensors would significantly support flood management.

Fig. 2 .
Fig. 2. Deployment of a G-WaLe floater in a river.

Fig. 5 .
Fig. 5. Potential flooding zones of the lower Wupper station, the Wupperverband has built up a local Sensor Web.The services of the SWE initiative have been used to encapsulate those sensor systems for seamlessly integrating them into the existing Spatial Data Infrastructure of the Wupperverband(Spies & Heier, 2008).Thus, the gathered hydrology and weather data are provided via Internet in a standardized way.The interoperable interfaces allow applications of the Wupperverband to work with internal as well as externally provided services.Hence, sensor data served by cooperating organizations (e.g., neighboring watershed management organizations) can be included into the decision making process.On the other hand, the information systems of third party organization are

Listing 3 .
Example of a simplified SOS InsertObservation request.<sos : InsertObservation s e r v i c e = 'SOS ' v e r s i o n = ' 1 .0 : t i m e P o s i t i o n > </samplingTime> <procedure x l i n k : h r e f =" h t t p :// myserver .org/ sensor/G−WaLe−1"/> <observedProperty