SENSOR WEBS: A ROADMAP Ingo Simonis Institute for Geoinformatics, University of Muenster Robert-Koch-Str. 26-28, 48149 Münster, Germany,
[email protected]
ABSTRACT Networks of sensors – interacting autonomously within its predefined conditions – are still a far vision of the new efforts called Sensor Web. The heterogeneity of sensor types, data formats, and communication protocols had lead to various distinct systems with very little interoperability in between. New efforts driven by the Spatial Data Infrastructure (SDI) community address those problems and provide interesting solution approaches. The Sensor Web Enablement initiative by the Open Geospatial Consortium aims at standardizing the entire sensor web process of sensor description, sensor discovery, sensor tasking, and access of data observed by sensors. This article will illustrate two important standing legs of current developments towards interoperable sensor webs: First the research questions addressed by research institutes and standardizing consortia, and second by open source software initiatives like 52north that help to bundle developer capacities and therefore accelerate the entire process to set up interoperable sensor webs, which are – despite all efforts – still in its infancy. Keywords: Sensor Web, interoperability, open source, 52north, Sensor Web Enablement.
1 SENSOR WEBS Sensor Webs are integrated systems of real or virtual sensors that are enabled to interact using some kind of communication protocol. Further components are used to process the observed values, archive them or represent them to further components or users. The goal of the Sensor Web Enablement Architectures is the specification of webservice-based interoperability frameworks to integrate geolocatable sensors into Spatial Data Infrastructures (SDI). The architecture will ensure an easy linkage of highly temporal dynamic spatial sensor information with further spatial and spatio-temporal information provided within an SDI. Multi-purpose information encodings represent observational as well as services and observation describing metadata and are based on well defined schemata that will ensure the common understanding across the different services. A distinct identification of roles and functionalities will become necessary to allow a proper definition of the different service interfaces. New communication patterns not used in SDIs so far will represent sensor specific needs much better that the currently used pull based publish-find-bind paradigm. First actions have been already taken by the “Sensor Web Enablement” (SWE) initiative driven by the Open Geospatial Consortium (OGC) (Simonis, Wytzisk et al. 2003). Based on W3C’s webservice standards (XML, SOAP, UDDI) and OGC’s SWE framework, the following key components of sensor webs can be identified: 1.1 Observable Registry To achieve interoperability amongst different types of sensors (and those web-services that encapsulate them), a common understanding of the provided information, i.e. of the measured phenomena (the so called observables) has to be ensured. The Observable Registry Specification will provide an information model and a standardized interface that allows clients to manage and access an observable ontology. 1.2 Sensor Instance Registry The Sensor Instance Registry specification will define standard operations to allow clients to discover and bind sensor instances by means of location, temporal availability, observed phenomena, accuracy, data provision type etc. Sensor discovery will be based on a markup language that describe sensor specifics like SensorML (Botts 2002), a markup language that is designed to primarily describe the sensor system independent of the observations and products derived from these measurements. Different kinds of models allow
detailed and well defined descriptions of sensors and sensor systems. Location models allow the geolocation of observations, a process that could be complex if non in situ but remote sensing is considered. Response models describe the response characteristics of a sensor and process models provide the parameters and actions used in processing raw observation data. Other markup languages like, e.g. TransducerML define a particular format for supporting data clusters streaming from a group of sensor components, and provides a means of relating these clusters to the transducer (sensor, transmitter, etc) that generated them. Those different foci have to be integrated into a common sensor description language. 1.3 Observation & Measurement Observations and measurements have to be encoded to be transported from its source to further processing entities. The Observation and Measurement specification as part of the Geography Markup Language (GML) (Cox, Daisey et al. 2004) provides models and XML encodings for sensor observations and measurements. It mainly focuses on distinct data flows; means that observed sensor data is encoded on request and not provided as a continuous data stream. To represent a broad range of sensors and allow a different kinds of sensor data processing systems to communicate with sensors in an optimal way, continuous data flows have to be integrated. 1.4 Messaging Specification For a fast provision of measurement information, it seems advisable to reassess OGC’s recent webservice architecture as a suitable platform for the Sensor Web. Focusing exclusively on data pulling, the service trading (publish-find-bind) based approach shows significant shortcomings, if an active event dispatch respectively data push is required, which is the case if a measurement value has to be immediately distributed if e.g. it exceeds a predefined threshold. 1.5 Sensor Observation Service The Sensor Observation Service specification provides a web-enabled interface to access observationrespectively measurement-outcomes, which are executed by sensor systems. Sensor Observations Services acts like a wrapper which hides the different communication protocols, data formats and standards of sensor systems behind its standardized interface, which allows clients to collect and access sensor observations and manipulate them in different ways. 1.6 Sensor Planning Service The Sensor Planning Service specification will provide a standardized interface to manage different stages of observation procedures, i.e. planning, scheduling, tasking, collection, archiving and distribution. A Sensor Planning Service encapsulates collection assets respectively their surrounding support systems for management purposes. Therefore, the Sensor Planning Services have to be designed to be flexible enough to handle a wide variety of configurations.
2 PROMISING OPEN SOURCE INITIATIVE: 52NORTH In the past years, the advancements made in geoinformatics are propelled by alterations in user requirements, novel methodological and theoretical approaches in geographic information science as well as the rapid technological progress in general. These advancements share a common trend: proprietary, monolithic and solitary software solutions vanish while open, distributed and interoperable systems come into being, which establish a network of distinct spatial data resources, geoprocessing capabilities and ubiquitous applications. A logical consequence of this paradigm change is the establishment of Spatial Data Infrastructures, a process that gains a respectable momentum worldwide nowadays. Concurrently, research bodies and software industry explore a new business model that proves beneficial for both the software user and the respective provider. Open source software development cannot anymore be exclusively associated with non-commercial, independent developer communities. It also represents an economically viable model for the software industry. These two orthogonal trends establish a tremendous challenge in geoinformatics, which remains not explored at present with regard to its technological and commercial potential. The open source software initiative 52North has been founded by the Institute for Geoinformatics of the University of Münster and con terra GmbH in order to face the aforementioned challenge. It aims at
developing open source software for the acquisition, analysis and visualization of spatial data within open Spatial Data Infrastructures. The widest possible dissemination and popularization of the software in the market for geographic information technologies (public and private users, research and education bodies, developer communities, commercial entities etc.) will be assured by publishing it under the GNU General Public License. In this context, the research and software development activities shall be tailored to come along with technical innovations and market oriented products. Quality management is thereby of paramount importance as it helps to keep track on software usability and continuity. At the same time, the initiative will fuel national and international standardization efforts being relevant for the software in scope. Based on the already existing network of excellence for geographic information technologies, which spans across science and industry, 52North shall empower the development of open source software, its deployment and use. The open source software initiative 52North forms an umbrella around a broad range of software products that follow the principles of the service driven architecture (SOA). Services to form sensor networks will constitute one of three main pillars of the entire project with SDI management services and mobile services being the complementary others. The project serves as a test platform as well as a ready to use repository of stable releases. Following this parallel approach, 52North will be a rich information source to research and development as well as a stable platform that allows building the sensor web from its beginning.
REFERENCES Botts, M. (2002). Sensor Model Language (SensorML) for In-situ and Remote Sensors DIPR Version 0.7, Open GIS Consortium (OGC). Cox, S., P. Daisey, et al. (2004). OpenGIS® Geography Markup Language (GML) Implementation Specification. OGC, Open Geospatial Consortium. Simonis, I., A. Wytzisk, et al. (2003). Interoperability of Simulation and Geoinformation Standards. Spring-SIW, Orlando, Florida.
