1 / 31

Service Oriented Sensor Web: NOSA Approach

Service Oriented Sensor Web: NOSA Approach. Gri d Computing and D istributed S ystems (GRIDS) Laboratory Dept. of Computer Science and Software Engineering The University of Melbourne, Australia www.gridbus.org. Rajkumar Buyya and Xingchen Chu. Outline. Introduction Definition, vision..

cutter
Download Presentation

Service Oriented Sensor Web: NOSA Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Service Oriented Sensor Web: NOSA Approach Grid Computing and Distributed Systems (GRIDS) LaboratoryDept. of Computer Science and Software EngineeringThe University of Melbourne, Australiawww.gridbus.org Rajkumar Buyya and Xingchen Chu

  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) • 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?

  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

  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 user’s 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 • 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

  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

More Related