Sensor Registry

Introduction

In order to enable and to facilitate the discovery of sensors and sensor services (SOS, SAS, SPS) it is necessary to provide tools that allow to perform searches based on a variety of parameters and criteria. The SensorRegistry project aims at solving this problem by developing powerful search mechanisms that are not only taking into account the specific needs of highly dynamic sensor data but also the requirements that arise from semantic interoperability problems.

The work of the SensorRegistry project is divided into two main topics:

• Dictionaries for sensors, observables and units
• Registries for sensors and sensor services

The dictionaries which are developed within the first work package will form a foundation that allows to incorporate semantic interoperability into sensor registry services. Thus the intention of the dictionary development is to provide means for referencing terms and concepts that are relevant for formulating search requests.

For the development of the core registry components several sensor specific requirements will be taken into account. Thus the first step will be a comprehensive analysis of the specific needs in conjunction with the capabilities of state-of-the-art catalog and registry mechanisms. During this analysis a special focus will be on the aspect of sensor mobility: Often sensors are mounted on mobile platforms so that they are able to cover bigger areas and to adapt their positions to user needs. This poses the problem that the data generated by on sensor may be available through different services which may change from time to time. Furthermore the availability of data for a certain location can be time depended.

For the solution of the previously described problems it is intended to choose an approach that is as pragmatic as possible. This means that a very strong focus will be put on the analysis of real world scenarios that will serve as a use case for the services to be developed.

Current Work

• 30 April 2007: Currently an analysis of referencing mechanisms and dictionary technologies for definitions is performed

Tasks

• Develop RegistryConcept
• Ontology overview
  • Evaluation of ontologies that are available in the geosensor context
  • Check if there are any existing approaches that can be reused
• Semantic modelling
  • How can semantics be modelled?
  • Which tools are available?
  • Evaluate and test Protégé (http://protege.stanford.edu/)
  • Formats for exchanging and describing ontologies (RDF)
• Analyis of existing dictionary technology?
  • Which operations must be provided by a dictionary?
  • Which technologies are available that can be used?
  • How do existing approaches work?
  • How are ontologies imported/integrated into dictionary services?
  • Example: Ontology Lookup Service (OLS): http://www.ebi.ac.uk/ontology-lookup/
• Lucene
  • http://lucene.apache.org/
  • Tool that provides full text indexing and search mechanisms
  • Analyse the capabilities
  • Perform tests in order to evaluate the potential use for our dictionary and registry implementaions

Scenario

In order to get better insights into the practical requirements regarding registries for sensors and sensor data for a prototypical implementation a scenario concerning a chemical accident is considered. This scenario will be used throughout the development process for a sensor registry. Furthermore it will also provide means for verifying the design and the implementation. We assume as an example that a gas truck has an accident which causes a gas cloud to spread out. For the calculation of the spreading a model for effects with toxic gases that is available through a sensor planning service will be used. For evaluating the potential risk beside the calculation of the spreading even the effect of pollutant for the human organism (toxicity) needs to be considered. The used model represents a model for the estimation of a dangerous situation after an abruptly eruption of toxic substances. Beside kind and amount of the substance and its toxicological parameters in particular meteorological data is used for the calculation of the dispersion. Thus the model calculates the limits of the spreading toxic cloud and assumes within the calculated bounds the same concentration. This conservative approach is necessary because topological conditions are introduced in the model just as planar parameters, singular houses, surrounding property or trees at the accident place which can massive influence the result aren't considered. We assume that our model provides three different segments: irritation by stay in the house or outdoor and smell nuisance (see figure 1).

Figure 1: Output of the model showing the different danger levels

The following meteorological parameters might be necessary for executing the model:

• Precipitation
• Cloudiness
• Wind velocity
• Temperature
• Wind direction
• Fog
• Air pressure

Furthermore following factors need to be considered:

• Kind of escaped substance
• Amount of escaped substance
• Fire
• Land use

Especially for retrieving the necessary meteorological data sensor networks provide a very powerful tool. In order to find the relevant data sources the use of sensor registries is an essential prerequisite. In our scenario it is assumed that a workflow controller component has the task to insert all necessary information into the simulation model. For finding the according data sources (i.e. sensor observation services and sensor alert services) the controller has to rely on the registry that we are planning to develop.