Official DERI Presentations

1
(No Transcript)
2
Sensor Data Management Survey Results
3
Presentation Outline

• Motivating Scenario
• Challenge of Sensor Data Management
• Solution
• Next Step

4
Motivating Scenario
Low-level Sensor (S-L)
High-level Sensor (S-H)
H
L
A-H
E-H
A-L
E-L

• How do we determine if A-H A-L? (Same time?
  Same place?)
• How do we determine if E-H E-L? (Same
  entity?)
• How do we determine if E-H or E-L constitutes a
  threat?

5
The Challenge
Collection and analysis of information from
heterogeneous multi-layer sensor nodes
6
Why is this a Challenge?

• There is a lack of uniform operations and
  standard representation for sensor data.
• There exists no means for resource reallocation
  and resource sharing.
• Deployment and usage of resources is usually
  tightly coupled with the specific location,
  application, and devices employed.
• Resulting in a lack of interoperability.

7
Interoperability

• INTEROPERABILITY
• The ability of two or more autonomous,
  heterogeneous, distributed digital entities (e.g.
  systems, applications, procedures, directories,
  inventories or data sets) to communicate and
  cooperate among themselves despite differences in
  language, context, format or content. These
  entities should be able to interact with one
  another in meaningful ways without special effort
  by the user - the data producer or consumer - be
  it human or machine.

8
Interoperability

• X implements service R as a client
• Y implements service R as a server
• X need not have understanding of Y, or vice versa

X
Y
R

• X and Y are able to interact effectively at
  run-time to achieve shared goals

Based upon Semantic Interoperability of
Distributed Geo-Services, Rob Lemmens, PhD
Thesis, Delft University of Technology, Published
by ITC, 2006
9
Survey
Many diverse sensor data management application
frameworks were compared, such as

• GSN
• Global Sensor Network
• Digital Enterprise Research Institute (DERI)
• http//gsn.sourceforge.net/
• Hourglass
• An Infrastructure for Connecting Sensor Networks
  and Applications
• Harvard
• http//www.eecs.harvard.edu/syrah/hourglass/
• IrisNet
• Internet-Scale Resource-Intensive Sensor Network
  Service
• Intel Carnegie Mellon University
• http//www.intel-iris.net/

However, it soon became obvious that these
application frameworks provided only localized
interoperability and that a standards-based
framework was necessary.
10
The Solution
The Open Geospatial Consortium Sensor Web
Enablement Framework
11
What is an Open Standard?

• . . . open standards prevent a single,
  self-interested party from controlling a
  standard, facilitate competition by lowering the
  cost of entry, and stimulate innovation beyond
  the standard by companies that seek to
  differentiate themselves. Customers value the
  interoperability that open standards provide and
  generally benefit from not being locked into a
  particular supplier.

Open Standards, Open Source, and Open Innovation
Harnessing the Benefits of Openness, April 2006.
Committee For Economic Development. www.ced.org
12
Open Geospatial Consortium
OGC Mission To lead in the development,
promotion and harmonization of open spatial
standards

• Consortium of 330 companies, government
  agencies, and academic institutes
• Open Standards development by consensus process
• Interoperability Programs provide end-to-end
  implementation and testing before spec approval
• Standard encodings, e.g.
• GeographyML, SensorML, Observations
  Measurements, TransducerML, etc.
• Standard Web Service interfaces, e.g.
• Web Map Service
• Web Feature Service
• Web Coverage Service
• Catalog Service
• Sensor Web Enablement Services (Sensor
  Observation Service, Sensor Alert Service, Sensor
  Process Service, etc.)

13
What is Sensor Web Enablement?

• The interoperability framework for accessing and
  utilizing sensors and sensor systems in a
  space-time context via Internet and Web protocols
• A set of web-based services may be used to
  maintain a registry of available sensors.
• The same web technology standard for describing
  the sensors outputs, platforms, locations, and
  control parameters should be used all across.
• This enables the necessary interoperability.
• This standard encompasses specifications for
  interfaces, protocols, and encodings that enable
  the use of sensor data and services.

14
Sensor Web Enablement
Vast set of users and applications
Constellations of heterogeneous sensors
Satellite
Airborne
Network Services
Sensor Web Enablement
Weather
Enterprise Services
Surveillance

• Distributed self-describing sensors and related
  services
• Link sensors to network and network-centric
  services
• Common XML encodings, information models, and
  metadata for sensors and observations
• Access observation data for value added
  processing and decision support applications
• Users on exploitation workstations, web browsers,
  and mobile devices

Network Services
Biological Detectors
Chemical Detectors
Sea State
15
Sensor Web Enablement Desires

• Quickly discover sensors (secure or public) that
  can meet my needs location, observables,
  quality, ability to task
• Obtain sensor information in a standard encoding
  that is understandable by me and my software
• Readily access sensor observations in a common
  manner, and in a form specific to my needs
• Task sensors, when possible, to meet my specific
  needs
• Subscribe to and receive alerts when a sensor
  measures a particular phenomenon

16
SWE Specifications

• Information Models and Schema
• Sensor Model Language (SensorML) for In-situ and
  Remote Sensors - Core models and schema for
  components, georegistration, response, process
  models
• Transducer Model Language (TML) Core models and
  encoding for supporting real-time streaming
  sensor data and enabling interoperability and
  fusion of dissimilar sensor data.
• Observations and Measurements (OM) Core models
  and schema for observations

17
SWE Specifications

• Web Services
• Sensor Observation Service Access Observations
  for a sensor or sensor constellation, and
  optionally, the associated sensor and platform
  data
• Sensor Alert Service Subscribe to alerts based
  upon sensor observations
• Sensor Planning Service Request collection
  feasibility and task sensor system for desired
  observations
• Web Notification Service Manage message dialogue
  between client and Web service(s) for long
  duration (asynchronous) processes
• Sensor Registries Discover sensors and sensor
  observations

18
Example Observation Model
An Observation is an Event whose result is an
estimate of the value of some Property of the
Feature-of-interest, obtained using a specified
Procedure The Feature-of-interest concept
reconciles remote and in-situ observations
19
Sensor Model Language(SensorML)
20
SensorML Overview

• SensorML is an XML schema for defining the
  geometric, dynamic, and observational
  characteristics of a sensor
• The purpose of the sensor description
• provide general sensor information in support of
  data discovery
• support the processing and analysis of the sensor
  measurements
• support the geolocation of the measured data.
• provide performance characteristics (e.g.
  accuracy, threshold, etc.)
• archive fundamental properties and assumptions
  regarding sensor
• SensorML provides functional model for sensor,
  not detail description of hardware
• SensorML separates the sensor from its associated
  platform(s) and target(s)

21
Scope of SensorML Support

• Designed to support a wide range of sensors
• Including both dynamic and stationary platforms
• Including both in-situ and remote sensors
• Examples
• Stationary, in-situ chemical sniffer,
  thermometer, gravity meter
• Stationary, remote stream velocity profiler,
  atmospheric profiler, Doppler radar
• Dynamic, in-situ aircraft mounted ozone
  sniffer, GPS unit, dropsonde
• Dynamic, remote satellite radiometer, airborne
  camera, soldier-mounted video

22
Information provided by SensorML

• Observation characteristics
• Physical properties measured (e.g. radiometry,
  temperature, concentration, etc.)
• Quality characteristics (e.g. accuracy,
  precision)
• Response characteristics (e.g. spectral curve,
  temporal response, etc.)
• Geometry Characteristics
• Size, shape, spatial weight function (e.g. point
  spread function) of individual samples
• Geometric and temporal characteristics of sample
  collections (e.g. scans or arrays)
• Description and Documentation
• Overall information about the sensor
• History and reference information supporting the
  SensorML document

23
Transducer Model Language(TransducerML)
24
TransducerML Overview

• TML is a language for exchanging streaming
  transducer command status data
• Between a system of transducers and a transducer
  processor/service or client
• Self-describing
• Based on XML (archive or live data)
• The language communicates
• Streaming Transducer data
• Transducer metadata
• Metadata is tightly coupled with data
• Sensor Metadata characterizes the What, When
  and Where of data
• Normalizes data for exchange
• Standardized spatial, temporal, phenomenon value,
  and UOM.
• Data traceable to an enterprise datum's (space,
  time, value) with uncertainties
• Data traceability of processing pedigree and
  source data
• TML is Sensor Agnostic
• Metadata is Common for all Type Sensors
• Enables a Common Sensor Processor
• TML is Application Domain Agnostic
• TML is for Machine-to-Machine data exchange
• Historical, live, and future time precision time
  tagged messages

25
TransducerML Enables

• Common Processing Environment
• Common Sensor Model
• Consistent processing for any sensor
• Sensor Data Fusion
• Correlation
• Registration
• Association of Streaming Multi-Transducer Data
• Common software tools
• Interoperable Data Exchange
• Multi-INT, Multi-Domain
• Scalable
• Simple to Complex
• Accurate
• Precision Geo-Positioning with Error Propagation
• Efficient
• Minimal Overhead
• Live streams and archive files from sensors
• Live sensor control

26
In Conclusion
Data interoperability is necessary in order to
provide complex querying and analysis
capabilities to a sensor data management
framework. The OGC SWE enables such capabilities
by providing standards-based interoperability of
sensor data.
27
The Next Step
Experimentation involving annotation, retrieval
and analysis of real data with SWE
languages. Such experiments could begin with a
simple demo involving off-the-shelf sensors
(i.e., video cameras).
28
Thank You.