Service Oriented Sensor Web: NOSA Approach

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