Service Oriented Sensor Web: NOSA Approach
Rajkumar Buyya and Xingchen ChuGrid Computing and Distributed Systems (GRIDS) LaboratoryDept. of Computer Science and Software EngineeringThe University of Melbourne, Australia
www.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
Pollution Detection
Computer Grid
Instrument
Weather Forecast
Tsunami Detection
Researcher
Collaborators
Software, Model, Workflow
Sensor Nets
Historical Data
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) O&M (Observation and Measurement)
Three behavior specification SCS (Sensor Collection Service) SPS (Sensor Planning Service) WNS (Web Notification Service)
8
How do they work?
SPSWNS
Client
Registry
Send Notification
Search Available Services
Request Data Encoded in
SWE Format
User Registration
Data Encoded in O&M or SensorML
Real World Sensor and Sensor Applications
Temperature
SensorMLDescriptionOf Sensors
ImagesPlatform
Sensor
SCS
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
O&M (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
O&M 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
Sensor1 Sensor2 Sensor3 Sensor4 SensorN….
NICTOR Sensor Field
iModel+Encoding:1. SensorML
2. Observation & Measurements
SensorDirectory Services
SensorData Grid Services
SensorGridProcessing Services
Sensor PlanningServices
Sensor Notification
Services
SensorCollection/
ObservationServices
Sensor Coordination
Services
Sensor Programming Framework (APIs, Visual Tools)
Water Information
Network
Barrier Reef Observation
Network
SecureAustralia Network ….
ZigBee/IEEE 802.15.4 protocols
SensorWebSimulation
or Emulation
Safe Transportation
andRoads
Tsunami Detection Network
Actuator1 Actuator2 Actuator3 ActuatorM….
SensorConfiguration
Services
Faulty Sensor Data Correction &
Management Services
Third Party Tools
….
Pollution MonitoringNetwork
Sensor1 Sensor2 Sensor3 Sensor4 SensorN….
NICTOR Sensor Field
iModel+Encoding:1. SensorML
2. Observation & Measurements
SensorDirectory Services
SensorData Grid Services
SensorGridProcessing Services
Sensor PlanningServices
Sensor Notification
Services
SensorCollection/
ObservationServices
Sensor Coordination
Services
Sensor Programming Framework (APIs, Visual Tools)
Water Information
Network
Barrier Reef Observation
Network
SecureAustralia Network ….
ZigBee/IEEE 802.15.4 protocols
SensorWebSimulation
or Emulation
Safe Transportation
andRoads
Tsunami Detection Network
Actuator1 Actuator2 Actuator3 ActuatorM….
SensorConfiguration
Services
Faulty Sensor Data Correction &
Management Services
Third Party Tools
….
Pollution MonitoringNetwork
ApplicationsLayer
ApplicationDevelopmentLayer
ApplicationServicesLayer
Sensor FabricSimulationEnvironment
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
Sensor Layer
Service Layer
Application Layer
Sensor Operating System
Physical Layer
Sensor Application
Sensor Application
Sensor Collection Service
Sensor Planning Service
Sensor Development Tools Third Party Tools
High Level Application
High Level Application
XML Messages
Web Notification Service
Sensor Repository Service
Information Model&Encoding
Sensor
Simulator
Emulator
sensors
Sensor Data & Messages
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
Sensor PlanningService
3 Planning Request
WSDL
Sensor RegistryService
WS
DL
1 Search available service
2 SPS WSDL AddressWeb Notification
Service
WSDL
WS
DL
4 Reg
ister
Use
r
Sensor CollectionService
WSDL
WS
DL
5 Use
r ID
6 Get Observation
8 Return O&M
9 Colle
ctio
n Dat
a Rea
dy
10 Notify User
Sensor RepositoryService
WSDLW
SD
L
7 Sto
re O
&M
24
Sensor Collection Service
Support GetObservation operation to fetch observation from various resources Accept user’s query as input parameter Convert query to a SQL-like executable query language Connect to TinyOS, TinyDB and Observation Database
Sen
sor
Co
nn
ecto
r
Tiny DB
Tiny OS
Sensor Collection Service
3 Query for data4 Observation data
WSDL
Sensor RegistryService
WS
DL
1 Search available service
2 SCS WSDL Address
ProxyProxy
DB Connector
O/R Mapping(JDO)
DatabaseSensor Observation Archives
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
Sensor PlanningService
WSDL
Sensor RegistryService
WS
DL
1 Search available service
2 SPS WSDL Address
3 Make a plan
4 Feasible or not
5 Submit feasible plan
6 Submit Success or fail
Scheduler
Rule Engine
Feasibility check
Schedule request
Sensor Collection
Service
Web Notification
Service
Get Observation
Do Notification
DataCollector
Notify client outcome and
where to collect the data
Store Data
26
Web Notification Service
Support registerUser and doNotification operations Currenty only support email communication Other protocol can be plugged into the existing system easily
Web Notification Service
WSDL
Sensor RegistryService
WS
DL
Search available service
WNS WSDL Address
Register User
AccountManager
User Registration
MySQL DB
Notification
Notify Registered UserSend
Notification
Communication Protocol
Specify protocol
27
A Sample Deployment
Hardware Crossbow’s 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
SCS
SCS
Sensor Registry Service
Base StationNode #1
Node #2
Client
Database
TOSSIM
TinyDB Simulation
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/SensorWebChapter.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