Development of an early warning information infrastructure using spatial web services technology

Abstract

Current high-performance monitoring and early warning systems are comparatively expensive and inflexible. The project described here aims for a systematic development of a prototypical alarm and early warning system for landslides utilising low-cost ad hoc wireless sensor networks and flexible spatial web service technology. Using web-based services as tools to exchange environmental data is an important step towards addressing today's larger scale environmental problems. The project's information system functions for notification, data access and analysis are implemented utilising Open Geospatial Consortium web service specifications. Approaches to implementing the orchestration of operation workflows and production of near real-time information products are illustrated.

Keywords:

• early warning
• wireless sensor network
• Sensor Web Enablement
• digital earth
• OGC
• SLEWS

Introduction

Current mass-market ready monitoring and early warning infrastructures are highly specialised systems with expensive hardware and software components built for high performance. Using monolithic, technology-centred information structures built on top of these systems are therefore necessary in order to implement effective workflows and warning chains. In contrast, building monitoring and early warning infrastructures on top of web service-based technologies is still at the prototype stage. However, the ongoing fusion of local and remote computing (see Maue and Kiehle 2009, Kouyoumjian 2010) is leading to a paradigm change in how applications can be designed. The combination of either new or existing specialised systems with web service functionality promises the development of flexible and less expensive applications that are highly scalable and easy to use. Spending additional effort on offering gathered information as a syntactically and semantically interoperable service resource adds extra value to the work which is already being performed. Using web-based services as tools for interdisciplinary data exchange, as well as for the extensive usage of heterogeneous data resources, is an important step towards addressing today's larger scale environmental problems (Bacharach 2008). The integration of environmental sensor networks into a service-based spatial infrastructure (sensor web) is recognised as being a fundamental requirement to enable this (Delin 2002, Liang et al. 2005). The Open Geospatial Consortium (OGC) addresses the requirement of making sensor information exchangeable by developing service interfaces, protocols and data types in the Sensor Web Enablement (SWE) specification series (Botts 2007). By making measurements and results from different fields discoverable and accessible over the internet, data producers can reduce data redundancy and existing data sets can be used to their full capacity without semantic and syntactic limitations.

The joint project ‘A Sensor-based Landslide Early Warning System (SLEWS)’ described here uses existing commercial sensor products together with a proof-of-concept web service layer using SWE technologies to provide access to data for internal processing, as well as for external users in an open and interoperable manner (Fernandez-Steeger et al. 2009).

Project outline

The danger from landslide hazards to people and infrastructures is still rising worldwide. Due to the progressive development of urban areas and infrastructure, more and more people settle in environments that are or become endangered by mass movements. Early warning and alarm systems are an efficient tool to monitor landslide hazards and reduce the risks from landslides, especially where no other mitigation strategies are suitable (Fernandez-Steeger et al. 2008). However, the available technologies are comparatively expensive and not very flexible.

SLEWS aim is the systematic development of a prototypical alarm and early warning system for different types of landslides utilising low-priced ad hoc wireless sensor networks (WSN) and flexible spatial web services technology (Bill et al. 2008). Project partners are the Department of Engineering Hydrogeology at RWTH Aachen, the Federal Institute for Geosciences and Natural Resources at Hannover, the Chair of Geodesy and Geoinformatics at Rostock University and ScatterWeb GmbH at Berlin. In the following sections, the process of transforming sensor-specific raw data into user-friendly early warning and monitoring information products which are obtainable via standardised interfaces and generic software is outlined.

Wireless sensor network (WSN)

The application of WSN provides an inexpensive and easy to implement monitoring system for landslide events. The system used for deploying sensor units is constructed by the project partner ScatterWeb GmbH. As a modern and autonomous ad hoc WSN (Figure 1), it is characterised by self-organisation and self-healing capacities (Arnhardt et al. 2008). Data packages from each node are sent via radio waves (868 MHz frequency) directly or via other nodes (multi-hop) to a collection point (gateway). Energy efficiency is achieved by reducing transmission power to only communicate with adjacent nodes. The bi-directional structure of the system enables data transfer from each node via the gateway interfaces to the gateway server (desktop, notebook or server unit), but also allows the transmission of commands such as data requests, as well as software updates to individual nodes or to a group of nodes.

Figure 1.  Structure of the SLEWS project's ad hoc wireless sensor network (WSN).

Nodes are fitted with a range of sensors such as tiltmetres, pressure, acceleration and displacement detectors, specifically chosen to monitor engineering-geological parameters of landslide events. Due to improved manufacturing processes and progress in the area of microsensor systems, small but precise low-cost sensors can be integrated in such systems. Testbed WSNs are being operated by the project partner RWTH Aachen under laboratory, as well as various field conditions.

Sensor Web Enablement (SWE)

The models, encodings and services of the SWE architecture enable implementation of interoperable and scalable service-oriented networks of heterogeneous sensor systems and client applications. In much the same way that Hyper Text Markup Language (HTML) and Hypertext Transfer Protocol (HTTP) standards enabled the exchange of any type of information on the Web, the OGC's SWE initiative is focused on developing standards to enable the discovery, exchange and processing of sensor observations, as well as the tasking of sensor systems (Figure 2, Botts 2007).

Figure 2.  Vision of the OGC Sensor Web Enablement initiative (by Botts 2007( http://portal.opengeospatial.org/files/?artifact_id=25562. Copyright©2007 Open Geospatial Consortium, Inc. All rights reserved)).

SLEWS proposes that all system functions for warning notification, data access and analysis may be implemented utilising SWE specifications (Figure 3). This additionally allows information resources to be offered to external research projects and also to seamlessly access resources which may be made available by third parties. In the following sections, the SWE services and specifications used are described more closely (see Figure 3).

Figure 3.  Current SLEWS project's information infrastructure.

Sensor Observation Service (SOS)

A Sensor Observation Service (SOS) offers a web-based interface to retrieve measurement data and sensor information via HTTP-based spatial and temporal queries (OGC 2008). Response formats of the SOS are the XML-based data encoding schemas SensorML and Observation & Measurement (O&M).

SensorML

It is used to describe and formalise the parameters of a sensor or data producer. The way sensors are described in SensorML is strictly process-based and can be used to capture sensor metadata, operation sequences, as well as software patterns of data-related operations. Every procedure a SOS offers data from has to be described by a particular SensorML document. SensorML is thus used to enable interoperability of sensors by allowing a client to discover relevant new sensors and to prepare for the interpretation of measurements in a hardware-independent manner.

Observation & Measurement (O&M)

It is used for the exchange of actual measurements and observations. O&M output documents can be requested with options to filter all available observations by time, location, observed phenomenon or sensor. O&M may be compared with the well-established OGC format for general geospatial vector data, Geography Markup Language (GML).

Sensor Planning Service (SPS)

Bi-directional communication with the WSN to remotely control functions such as energy management or measurement cycle rate is possible by sending instructions via the gateway node. The process of communicating these instructions to the WSN can be encapsulated using a Sensor Planning Service (SPS). A SPS offers the execution of a set of instructions via a standardised web-based interface. Users can thus remotely adapt the process of data gathering without knowing details of the WSN's operations. By wrapping controls in a standardised interface these functions may be integrated into generic client applications and straightforwardly operated by users.

Sensor Alert Service (SAS)

Another aspect of bi-directional communication with the WSN is the need for event-based notification to users without having to continuously ‘poll’ the SOS for new information. A Sensor Alert Service (SAS) allows the subscription to messages coming from a sensor system matching certain criteria (Simonis 2007). Both sides join a Multi-user Chat (MUC) through which messages are passed using Extensible Messaging and Presence Protocol (XMPP)-based protocols such as Jabber or GoogleTalk. Subscribed users can receive these messages depending on subscription parameters using desktop or web-based XMPP/Jabber client software. In order to extend the range of possible communication channels a Web Notification Services (WNS) server can be used as a protocol converter bridging the so-called last mile by notifying users by e-mail or SMS.

Methods

In order to make sensor data accessible via a web service layer as the basis for different kinds of information products, two general procedures have to be distinguished. The first procedure involves the process of importing native sensor data into the SWE service layer. Data providers are often confronted with the problem of how to apply SWE standards, especially for existing observation and data producing systems which have not previously been operating in an explicitly spatial context. Despite SWE's focus on plug and play capability within the service layer, connecting sensor systems as data providers remains a difficult task requiring detailed knowledge of both the sensor network's native format and of the SWE standards (Walter and Nash 2009).

The second procedure covers the actual implementation of information products being produced using a combination of OGC web services. In doing so, the full utilisation of the high flexibility of web services is a very important aspect. The main benefits of this flexibility are possible combinations of arbitrary numbers of distributed data sources and usage of extensive processing resources available through Web Processing Services (WPS; which may serve as a gateway to GRID-based processing systems, Foster et al. 2001). As a main goal, web-based client applications should include only a minimum amount of business logic and be as open and lightweight as possible in order to support a wide range of different platforms. Such thin clients may then run on a wide range of devices from smartphones and PDAs to notebook or desktop computer units, whilst requiring nothing more than a web browser to be installed.

In the following sections, the implementation of both these procedures within the SLEWS project is outlined.

Providing access to wireless sensor networks (WSN) data

In the SLEWS project's system architecture, basic measurement data can be accessed and interfaced at the WSN gateway via the gateway server connected to it. Communication between gateway and gateway server can be established using a physical or a wireless data connection (e.g. UMTS). A listener application running on the gateway server (Figure 4) is used to access the data stream arriving at the gateway, consisting of WSN-specific text output representing data packages received from sensor nodes.

Figure 4.  Interface application between sensor and service layer.

To be available for generic SWE-enabled applications, measurement data have to be converted into an appropriate data schema. To understand this schema, it is helpful to outline the SWE spatial view on the sensor/measurement concept (OGC 2008). Consistent to well-established OGC models, a sensor, as one of many possible data producers called procedure (defining sensor node/detector properties), is well-defined by a location called feature of interest. At a location an observation is recorded which represents a certain measured phenomenon at a certain time.

A parser application reformats the measurement strings using look-up tables to determine suitable parameters based on previous knowledge and uses these to supplement the data in order to meet the requirements of the SWE observation data model. In a next step, observation data are repeatedly transferred by a feeder application to a spatial database either using the native database interface (via SQL request) or the transactional service interface of the SOS (via HTTP request). The database serves as the central data management and is the source for the SOS.

Additionally, current data sets and other respective WSN system messages are concurrently parsed and published via XMPP protocol to the SAS where they may be selected based on defined filter rules in order to be relayed to the user.

Orchestrating information products

Highly scalable information products ranging from detailed expert-driven text or numeric output to very clearly represented map visualisations can be created using a different combination of service resources. As an example for a typical information workflow the following early warning situation is depicted.

A group of outdoor sensor nodes monitoring the movement of a rock pillar adjacent to an area frequently used by tourists show a change of readings exceeding a certain threshold. Measurements are instantly submitted via UMTS connection to the remote service layer where they are published to the SOS and SAS. Depending on the severity of the threshold exceedance, a predefined SAS filtering profile reacts to the recent observation and publishes a notification message to the referenced user subscription. A notification arriving at the user's workstation/phone via an instant messaging protocol or e-mail/SMS contains a brief text about the corresponding sensor node, phenomenon and timestamp/value pair. Despite the briefness of this notification, it contains enough spatial and temporal parameters to formulate a well-defined query against the SOS requesting the most recent time series data regarding the relevant phenomenon. Although this can directly be done using a standard web browser, the direct query results in a XML-based O&M document. While this basic information product may already be comprehensible to expert users, it is not necessarily suitable for general users.

To support a much more intuitive usage of SOS data, a web browser-based client using the OpenLayers framework is currently under development to quickly and comprehensibly visualise the development of landslide-related parameters at respective sensor nodes over time (Figure 5). It allows for users with different knowledge levels to evaluate the given situation and to decide on further steps to be taken.

Figure 5.  Visualising SOS data using a web browser-based client.

To put recent sensor readings into perspective, additional information may be required. Supplemental phenomena which are interdependent with landslide parameters can be consulted to verify current measurements. External OGC-conformant data sources offered, e.g. by national administrative authorities or research projects can be integrated easily by the client to offer live information support and to depict the surrounding situation more closely (Figure 6). Such information resources can be, e.g. rainfall events offered as raster data via Web Coverage Service (WCS), ground acceleration caused by earthquakes as vector data via Web Feature Service (WFS) or soil classification offered as map product via Web Map Service (WMS).

Figure 6.  SLEWS project's operation workflow orchestrating information products using different OGC web services.

Another important aspect for users to evaluate the given situation correctly lays in the capability to run more advanced analysis methods on the sensor data. Analysis operations such as time series and interpolation methods are crucial to provide decision support in more complex situations. Current applications for this are, however, mostly included in sophisticated (and expensive) software packages which would, as fully integrated solutions on the client side, contradict the project's efforts to create very lightweight user applications. As a solution, the usage of external processing resources offered via WPS promises to be a feasible approach. WPS offers specialised functions and algorithms in the form of encapsulated self-describing web services accessible via the internet. Given the availability of a suitable WPS, users can utilise arbitrary amounts of processing power offered by remote dedicated (GRID) server units running complex data operations and retrieve results to their own devices. In addition, the WPS interface allows the service to access input data directly from other web services, creating a dynamic service chain and thus avoiding unnecessary traffic between the end-user client and the WPS.

As a use case, the SLEWS project is working on a WPS wrapping functions of the well-known mathematical computing software MATLAB to create different kinds of time series analysis charts. Via a web-based WPS interface, which can easily be integrated into the client application mentioned previously, the user can trigger internal MATLAB functions to query the project's SOS for data. Data sets are retrieved and analysed and the results visualised using MATLAB's plotting capabilities. The charts created can be returned in a wide range of digital image formats directly or relayed through a WMS to the client application.

Discussion

The studies in the SLEWS project show a clear trend towards the possibility to utilise extensive information resources using nothing more than off-the-shelf tools which are already available on most existing computers and smartphones. Using the self-describing interfaces and standardised services of the OGC's SWE initiative, users can access measurement data of complex and specialised sensor systems with little previous knowledge and using just a web browser. As a proof of concept, the project successfully orchestrated an information workflow using a combination of OGC services offering near real-time information products for a monitoring and early warning scenario.

Although the fundamental requirements in order for local systems with highly customised business logic to be substituted with lightweight web service-based applications exist, there still are open issues which have to be addressed. In the use case described above, the process of ‘clicking together’ (orchestrating) an information product still demands a high amount of potentially error-prone user interaction. However, time-critical scenarios require highly automated workflows.

As a possible solution, client applications could maintain the status of an information product that has been orchestrated once by polling new data from the service layer on a regular basis. However, this process could result in a lack of efficiency and flexibility. A more feasible approach would be for the client application to keep the role of being triggered only when certain events occur, but to react directly to the asynchronously delivered notifications of the SAS. In order to keep a client application as modular as possible without having to constantly listen for notifications coming from the SAS, the solution being presented here suggests the use of an ‘Alert Map Context’ (AMC).

Following the concept of the Web Map Context (OGC 2005), a companion specification of the WMS interface, an AMC file would be used to pass a set of instructions on how to orchestrate an adequate information product using distributed information resources and services. The use of AMC would allow for users to use any OGC service compatible client software to utilise the information of an AMC without customisation being necessary. After being published as a file or file reference to the user via e-mail/SMS, etc. a client application using this specification would be able to create the given information product and user interface on the fly by querying the chained services or offering the possibility to interact with them. The process of creating an AMC could be automated by converting the information of a SAS notification similar to the function of a WNS server, using services and resources implied by described phenomena, events, etc. The responsibility to create AMC blueprints, as well as maintaining up-to-date service and information references falls to the operators of the relevant information systems.

Outlook

Future work will focus on establishing more complex early warning cycles by adopting the described system to the requirements of different landslide scenarios concurrently tested within the project. Particularly, data resulting from combined spatial and geological analysis operations will have to be very clearly presented to meet user requirements and to offer better decision support. The AMC concept therefore must be evaluated further to determine if it is sufficient to supply ad hoc users with adequate information. Furthermore, the overall system performance must in general be carefully analysed to determine if an entirely web service-based information infrastructure, which may be error-prone due to online availability, compares favourably to its specialised monolithic counterparts.

Notes on contributor

Kai Walter is a research associate with the Chair of Geodesy and Geoinformatics, Faculty of Agricultural and Environmental Sciences at Rostock University, Germany. His research interests include information infrastructures, spatial web services and sensor webs.

Acknowledgements

This work was funded by the German Federal Ministry for Research and Education under Grant Number FKZ: 03G0662A. The author would also like to thank colleagues from within the SLEWS project who have assisted with aspects of this work.