5.4.4 Sensor Discovery

From Geostandards

Jump to: navigation, search


Contents

Sensor Discovery

Requirements

For many use cases it is necessary to be able to discover required data sources and sensors. Thus, there is a need for a discovery solution that allows finding sensors as well as the SWE services that encapsulate them.

A sensor discovery solution needs to support the following criteria:

  • spatial criteria: discovery of sensors and sensor data for a certain area (e.g. data that cover the Netherlands)
  • temporal criteria: discovery of sensors and sensor data for a certain time period or point in time (e.g. data that was measured within the last 3 hours)
  • thematic criteria: discovery of sensors and sensor data that concern certain phenomena

Furthermore several sensor specific needs have to be taken into account:

  • search for SWE services based on the functionality they provide (i.e. accessing sensor data, alerting, controlling sensors)
  • providing information about the relationships between sensors and SWE service instances (e.g. for determining which SOS instance offers the data measured by a certain sensor).
  • the identity of sensors has to be considered as users need to be able to search for sensors with a specific id
  • handling the status of sensors/sensor networks for maintenance purposes, e.g.
    • battery state (find all sensors with a battery level lower than 10%)
    • positions of moving sensors

Challenges of Sensor Discovery

Sensor networks possess specific characteristics that distinguish them from conventional geospatial data sources. This leads to a need for specific discovery solutions that go beyond the requirements for cataloguing conventional (more static) geospatial data sets:

  • sensor metadata can be highly dynamic, for example
    • the position of a fast moving sensor changes continuously
    • the state of a sensor (busy, available, active, inactive) can quickly change
  • time dependent data availability (sensors may only be temporarily deployed at a certain location)
    • often continuous deployment of new sensors, removal of sensors, re-configuration of sensors
    • mobile sensors
  • sensor management
    • a higher and more detailed amount of meta information and functionality is needed than for normal discovery use cases
    • knowledge about individual sensors is necessary
  • handling sensor status information
    • relevant to sensor management
    • can be used for improving the quality of sensor discovery (e.g. for taking into account the latest sensor positions)
  • specific metadata formats
    • at least for supporting the SWE framework a sensor discovery solution must be able to handle SensorML documents as metadata input
  • semantics
    • taking into account semantic relationships (e.g. the semantics of the phenomena measured by sensors) the quality of a discovery solution can be improved
    • allows for example to discover sensors that measure similar or equivalent phenomena to a given one

For taking into account these specific requirements an optimized discovery solution is necessary. However such a solution is not available. Some ideas regarding potential approaches for sensor discovery will be discussed below.

Metadata for Sensor Discovery

SensorML is designed for describing the metadata of sensors and sensor systems. A special focus within SensorML was put on the provision of discovery relevant metadata. Thus, SensorML provides a valuable metadata format that can be used for enabling sensor discovery. Consequently a sensor discovery solution should be based on SensorML.

As SensorML is designed to support a very broad and comprehensive range of sensor types, it has a relatively generic character. In order to ensure that the minimum set of metadata necessary for discovery purposes is available within a SensorML document, the definition of an according SensorML profile for discovery is a suitable approach. A first draft of such a profile is described within the OGC OWS-6 Sensor ML Profile for Discovery Engineering Report (OGC 09-033). This profile defines which minimum set of metadata must be provided in which structure. The figure below illustrates the structure of SensorML documents that comply with this profile. An example SensorML document that is based on the discovery profile is introduced in the section about SensorML.

Overview of the contents defined by the SensorML Discovery Profile

Besides describing the metadata within SensorML documents, there is also a need for automatically harvesting the relevant metadata. Especially in large sensor networks that may comprise thousands of sensors the manual insertion of sensor metadata into a sensor registry would be too expensive. The two figures below give an impression of the metadata harvesting workflow that can be applied within the SWE framework.

Harvesting sensor metadata from Sensor Observation Service instances:

Harvesting sensor metadata from Sensor Observation Service instances

Harvesting sensor metadata from Sensor Planning Service instances:

Harvesting sensor metadata from Sensor Planning Service instances


previous 5 Sensor Web Enablement next
Personal tools