Xingchen Chu and Rajkumar Buyya

1
Service Oriented Sensor Web

• Xingchen Chu and Rajkumar Buyya
• University of Melbourne, Australia
• Presented by Gerardo I. Simari
• CMSC828P Fall 2006
• Professor Nick Roussopoulos
• Department of Computer Science
• University of Maryland College Park, USA

2
Introduction

• Current sensor nodes are more sophisticated in
  terms of CPU, memory, and wireless transceiver.
• Sensor networks are long running systems that
  consist of sensing nodes that work together to
  collect data (light, temperature, images, etc).
• Common applications are real-time detection and
  early warning systems (fires, tsunamis,
  earthquakes).
• The challenge collection and analysis of
  information from heterogeneous nodes.

3
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.
• The Service Oriented Architecture (SOA) is an
  approach to describe, discover, and invoke
  services from heterogeneous platforms.
• Here, the term service is used both for
  software and hardware.

4
SOA and Sensors

• Applying the idea of SOA to sensor networks
  presents sensors as reusable resources which can
  be discoverable, accessible, and even controlled
  through the WWW.
• It also allows to link distributed resources in
  order to create a sensor grid, enabling the
  advantages of a computational grid.
• The main goal of the Sensor Web (SW) is to offer
  reliable and accessible services to end users.
• The following figure illustrates an abstract
  vision of the SW, a combination of SOA, grid
  computing, and sensor networks.

5
Vision of the Sensor Web
6
Sensor Web Enablement

• 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.
• The Open Geospatial Consortium (OGC) developed
  the Sensor Web Enablement (SWE) standard.
• This standard encompasses specifications for
  interfaces, protocols, and encodings that enable
  the use of sensor data and services.

7
Sensor Web Enablement

• The following are the five specifications for
  SWE
• Sensor Model Language (SensorML) Information
  model and XML encodings.
• Observation and Measurement (OM) Information
  model and XML encodings.
• Sensor Collection Service (SCS) Service to fetch
  observations also uses SensorML to describe
  sensor platforms.
• Sensor Planning Service (SPS) Helps users build
  feasible sensor collection plans, and schedule
  requests for sensor platforms.
• Web Notification Service (WNS) Manages client
  sessions and notifies about outcomes of requests.

8
Sensor Web Enablement
9
SensorML

• SensorML is an XML encoding scheme that allows
  clients to remotely use real-time data from
  web-resident sensors.
• A standard format for sensor information enables
  integration, analysis, and creation of data views
  depending on the user.
• It also benefits the integration of heterogeneous
  sensors and platforms, providing an integrated
  view.
• It describes the geometric, dynamic, and
  observational features of sensors.
• The following figure shows the structure of the
  Sensor Model Language (SensorML).

10
SensorML
11
Observation and Measurement

• OM is another standard information model and XML
  encoding.
• It is required for the Sensor Collection Service
  and related components of the OGC SWE.
• The aim is towards defining terms used for
  measurements, and the relationships between them.
• The following figure shows the basic observation
  structure.

12
Observation and Measurement
13
SWE Services

• SWE defines several standard services that can be
  used to collaborate with sensor networks.
• As we mentioned before, SWE contains three
  service specifications
• Sensor Collection Service (SCS)
• Sensor Planning Service (SPS)
• Web Notification Service (WNS)
• There are also two new services Sensor Alarm
  Service, and TransducerML.
• The paper only covers the basic three mentioned
  above.

14
SWE Services (cont.)

• SCS is used to fetch observations from a sensor
  or collection of sensors.
• It plays the role of intermediary agent between a
  client and an observation repository or near
  real-time sensor channel.
• It responds to queries from the client with XML
  data conformed to the OM model.
• SPS provides a standard interface to handle asset
  management (AM) that manages information sources
  to meet the clients goals.
• It plays a role of coordinator responsible for
  evaluating the feasibility of the request and
  submitting the query to the SCS.

15
SWE Services (cont.)

• The WNS is an asynchronous messaging service.
• Sending and receiving notifications are the main
  responsibilities of the WNS, utilizing various
  communication protocols (HTTP POST, email, SMS,
  instant message, phone, fax, etc).
• Operations are defined to conduct both one-way
  and two-way communication between users and
  services.

16
Service Oriented Sensor Web

• Open Source Web Architecture (OSWA) is an SWE
  compliant infrastructure for providing service
  oriented access and management of sensors.
• Its a platform for integrating sensor networks
  and distributed computing platforms such as SOA.
• Among the benefits, the heavy information
  processing load can be moved to backend
  distributed systems such as grids.
• This can save a lot of energy in the sensor
  networks, and accelerate the processing.
• Individual sensor networks can be linked together
  as services.

17
High Level View of OSWA
18
The OSWA Platform

• Fundamental services are provided by low-level
  components, whereas high-level components provide
  tools for creating applications.
• The OSWA platform provides services such as
• Sensor notification, collection, and observation
• Data collection, aggregation, and archive
• Sensor coordination and data processing
• Faulty sensor data correction and management
• Sensor configuration and directory service
• The OSWA focuses on providing an interactive
  development environment, a middleware and
  coordination language for developing sensor apps.

19
A Prototype Instance of OSWA
20
Design and Implementation

• The primary design and implementation of OSWA
  focuses on its core services (SCS, WNS, and SPS),
  
• The Sensory Repository Service is also key,
  providing the persistent mechanism for sensor and
  observation data.
• In the following figure, we show a typical client
  collection request, and the invocations between
  relating services.
• We will then discuss the design and
  implementation of each of the core services in
  turn.

21
Invocation for Sensor Web Client
22
Sensor Collection Service

• SCS is one of the most important components
  residing in the service layer.
• It is the only component that needs to
  communicate directly with sensor networks.
• It is responsible for collecting sensing data and
  translating the raw information into the XML
  encoding so that other services can use it.
• The design of SCS provides an interface to both
  streaming data (built on top of TinyOS) and query
  based sensor applications (built on top of
  TinyDB).
• The following figure illustrates the architecture
  of the SCS.

23
Sensor Collection Service
24
Sensor Planning Service

• SPS uses a rule engine which reads a set of rules
  used to decide the feasibility of the plan made
  by the user.
• Rules can be in many different languages.
• The most important component is the scheduler
• It first composes the collection request and
  invokes the SCS to get the observation.
• Asks the DataCollector to store the observation
  data for later use by other clients.
• Sends notification to the WNS indicating the
  outcome of the collection request.
• The following figure illustrates the architecture.

25
Sensor Planning Service
26
Web Notification Service

• The WNS contains two basic components
  AccountManager and Notification.
• The account manager stores data corresponding to
  users who have registered with the service.
• The notification component creates and sends
  messages, using various protocols, to users who
  have registered.
• The following figure shows the WNS architecture.

27
Web Notification Service
28
Experimental Results

• The authors present a series of preliminary
  results.
• Although the services they implement all work
  properly, the entire OSWA is not fully
  implemented.
• Many implementation issues are left as future
  work, especially regarding the SCS.
• This central component needs to be reliable, have
  good performance, and be scalable.
• The authors conclude that the SCS will greatly
  affect the performance and reliability of the
  entire system.