1. Service Oriented Sensor Web: NOSA Approach Rajkumar Buyya and Xingchen Chu Grid Computing and Distributed Systems (GRIDS) Laboratory Dept. of Computer Science and Software Engineering The University of Melbourne, Australia www.gridbus.org

2. 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. 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. 4 Vision of Sensor Web

5. 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. 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. 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. 8 How do they work?

9. 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. 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. 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. 12 O&M Data Structure (cont.)

13. 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. 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. 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. 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. 17 NOSA Architecture

18. 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. 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. 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. 21 Design Overview

22. 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. 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. 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. 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. 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. 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. 28 A Setup: Supporting both Real and Simulation Environment

29. 29 Simulation in TOSSIM

30. 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. 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.Service Oriented Sensor Web 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.SensorGrid: Integrating Sensor Networks and Grid Computing http://www.buyya.com