Service Oriented Sensor Web: NOSA Approach

1
Service Oriented Sensor Web NOSA Approach

• Rajkumar Buyya and Xingchen Chu

Grid Computing and Distributed Systems (GRIDS)
LaboratoryDept. of Computer Science and Software
EngineeringThe University of Melbourne,
Australiawww.gridbus.org
2
Outline

• Introduction
• Definition, vision..
• Sensor Web Standards
• OGC Sensor Web Enablement
• NOSA A Service-Oriented Senor Web
• Implementation of NOSA Core Services
• Remarks and Future Work

3
What is Sensor Web?

• A paradigm for connecting Physical World with the
  Computer World!
• An emerging trend which makes various types of
  web-resident sensors, instruments, image devices,
  and repositories of sensor data, discoverable,
  accessible, and controllable via World Wide Web.

4
Vision of Sensor Web
5
Why do we need it?

• Traditional Sensor Applications
• Hard to develop and deploy
• Hard to reuse
• No global resource discovery and sharing
  mechanism
• No standard
• SensorWeb overcomes the above limitations and
  aims to
• Enable resource discovery and resource sharing
• Provide reliable and easy-to-use services to
  end-users
• Provide infrastructure and middleware support
• Provide the standard to represent, access and
  control resources

6
Sensor Web Build on Standards

• It is composed of services
• Heavily rely on SOA (Service Oriented
  Architecture)
• It is composed of standards
• Based on SWE (Sensor Web enablement)
• Communication Protocol
• XML and SOAP (Simple Object Access Protocol)

7
Sensor Web Standards

• Without standards
• Interoperability is hard to achieve
• Lack of semantics for sensors (hard to build
  global registry)
• Lack of uniform data representation (Information
  is tightly coupled with specific applications)
• Restrict the ability of mining and analyzing the
  information
• SWE (Sensor Web Enablement) Standards
• Proposed by Open Geospatial Consortium (OGC)
• Five specifications
• Two XML data specification
• SensorML(Sensor Model Language)
• OM (Observation and Measurement)
• Three behavior specification
• SCS (Sensor Collection Service)
• SPS (Sensor Planning Service)
• WNS (Web Notification Service)

8
How do they work?
9
SensorML

• A XML language defined by XML Schema
• Describes sensor and sensor platform
• Provides various data views to both human and
  computers
• Key component for enabling autonomous and
  intelligent sensor webs.
• Enables resource discovery

10
SensorML (cont.)

• Can be used outside SWE framework
• Enable long-term archive of sensor data to be
  reprocessed and refined
• Allow software system to process ,analyze and
  perform a visual fusion of multiple sensors

11
OM (Observation and Measurement)

• Another XML language defined by XML Schema
• Defines applicability of web-based sensors
• Defines terms used for measurements
• Used by Sensor Collection Service and related
  components

12
OM Data Structure (cont.)
13
Sensor Collection Service

• Most important Service
• Fetch observation data from sensors or
  collections of sensors
• Acts as agent between a client and resources
• A resource may be either observation repository
  or real-time sensor channel

14
Sensor Planning Service

• A service to identify, user and manage sensors or
  sensor platforms
• Accept clients collection request as a plan
• Acts as a coordinator to evaluate the feasibility
  of a plan and manage its submission

15
Web Notification Service

• A service providing asynchronous messaging
  mechanism
• Sending and receiving notifications are the major
  responsibility
• Make use of various communication protocol
• HTTP, Email, SMS, Instant Message, Phone Call,
  letter or fax
• User management functionality such as user
  registration

16
NOSA A Service-Oriented Sensor Web

• NOSA (NICTA Open Sensor Web Architecture)
• Complete SWE compliant architecture
• Further extends SWE
• Provides an interactive development environment,
  an open and standard-compliant Sensor Web
  services middleware and a coordination language
  to support development of various sensor
  applications

17
NOSA Architecture
18
Layered Architecture

• Sensor Fabric Layer
• Lowest layer related to either real sensor
  devices or sensor simulator/emulator
• Application Service Layer
• Provides core services to upper layer
• Application Development Layer
• Tools for sensor development and high-level
  services
• Application Layer
• Various Sensor Applications

19
Core Services

• Contains the core services derived from SWE, such
  as SCS, SPS and WNS
• Sensor Directory Service
• provides the capability of storing and searching
  services and resources
• Sensor Coordination Service
• enables the interaction between groups of sensors
  monitoring different kinds of events
• Sensor Data Grid Service
• provides and maintains the replications of large
  amount of sensor data
• SensorGrid Processing Service
• collects the sensor data and processes them
  utilizing grid facilities
• Design issues to consider
• Security, concurrency , transaction,
  maintainability, performance, scalability and
  reusability

20
Core Services Implementation

• Reference implementation of SWE core services
• Support both auto-sending and query mode for
  sensor applications
• Support real time data , simulation and
  repository access
• Support TinyOS and TinyDB

21
Design Overview
22
Background Technologies

• Implement SWE services using Java and Web
  services
• Make use XML binding technology to convert XML
  data and Java Object
• Utilize TinyOS library connecting sensor node and
  simulation environment
• Build repository using JDO (Java Data Object)

23
Services Collaboration

• Client send collection request to SPS
• SPS register user in WNS and check its
  feasibility
• SPS schedule the feasible plan and submit to SCS
• SCS query resources, return observation and WNS
  will notify the client
• Clients can collect result from given source from
  the notification

24
Sensor Collection Service

• Support GetObservation operation to fetch
  observation from various resources
• Accept users query as input parameter
• Convert query to a SQL-like executable query
  language
• Connect to TinyOS, TinyDB and Observation Database

25
Sensor Planning Service

• Support getFeasibility and submitRequest
  operations
• Support scheduling both short term and long term
  plan
• Provide a rule engine to implement application
  specific rules

26
Web Notification Service

• Support registerUser and doNotification
  operations
• Currenty only support email communication
• Other protocol can be plugged into the existing
  system easily

27
A Sample Deployment

• Hardware
• Crossbows MOTE-KIT4XMICA2 Basic Kit
• 1 base-station, 3 mica2 motes, and 1 programming
  board.
• Test for temperature monitoring application auto
  sending application
• Simulation Environment
• TOSSIM come with TinyOS distribution
• Test query based application TinyDB

28
A Setup Supporting both Real and Simulation
Environment
29
Simulation in TOSSIM
30
Remarks and Future Work

• NOSA is a Web Services based and SWE standard
  compliant system
• Provides an highly pluggable system for
  developers to reuse and extend according to
  different requirements
• Future Work
• Support for other sensor operation systems such
  as MANTIS and Contiki need to provide
• Generic Query Engine is required
• Integration of SensorML is desired to provide
  resource discovery
• Integration of SensorWeb Middleware with Grid
  Computing environments

31
Reference

• Xingchen Chu and Rajkumar Buyya, Service Oriented
  Sensor Web, Sensor Network and Configuration
  Fundamentals, Techniques, Platforms, and
  Experiments, N. P. Mahalik (ed), Springer-Verlag,
  Germany, 2006.
• http//www.gridbus.org/raj/papers/SensorWebChapte
  r.pdf
• Chen-Khong Tham and Rajkumar Buyya, SensorGrid
  Integrating Sensor Networks and Grid Computing,
  CSI Communications, pages 24-29, Vol.29, No.1,
  ISSN 0970-647X, Computer Society of India (CSI),
  Mumbai, India, July 2005.
• http//www.buyya.com