1. Service Oriented Sensor Web Xingchen Chu and Rajkumar Buyya University of Melbourne, Australia Presented by: Gerardo I. Simari CMSC828P – Fall 2006 Professor Nick Roussopoulos Department of Computer Science University of Maryland College Park, USA

2. Introduction Current sensor nodes are more sophisticated in terms of CPU, memory, and wireless transceiver. Sensor networks are long running systems that consist of sensing nodes that work together to collect data (light, temperature, images, etc). Common applications are real-time detection and early warning systems (fires, tsunamis, earthquakes). The challenge: collection and analysis of information from heterogeneous nodes.

3. Why is this a challenge? There is a lack of uniform operations and standard representation for sensor data. There exists no means for resource reallocation and resource sharing. Deployment and usage of resources is usually tightly coupled with the specific location, application, and devices employed. The Service Oriented Architecture (SOA) is an approach to describe, discover, and invoke services from heterogeneous platforms. Here, the term “service” is used both for software and hardware.

4. SOA and Sensors Applying the idea of SOA to sensor networks presents sensors as reusable resources which can be discoverable, accessible, and even controlled through the WWW. It also allows to link distributed resources in order to create a sensor grid, enabling the advantages of a computational grid. The main goal of the Sensor Web (SW) is to offer reliable and accessible services to end users. The following figure illustrates an abstract vision of the SW, a combination of SOA, grid computing, and sensor networks.

5. Vision of the Sensor Web

6. Sensor Web Enablement A set of web-based services may be used to maintain a registry of available sensors. The same web technology standard for describing the sensors’ outputs, platforms, locations, and control parameters should be used all across. This enables the necessary interoperability. The Open Geospatial Consortium (OGC) developed the Sensor Web Enablement (SWE) standard. This standard encompasses specifications for interfaces, protocols, and encodings that enable the use of sensor data and services.

7. Sensor Web Enablement The following are the five specifications for SWE: –Sensor Model Language (SensorML): Information model and XML encodings. –Observation and Measurement (O&M): Information model and XML encodings. –Sensor Collection Service (SCS): Service to fetch observations; also uses SensorML to describe sensor platforms. –Sensor Planning Service (SPS): Helps users build feasible sensor collection plans, and schedule requests for sensor platforms. –Web Notification Service (WNS): Manages client sessions and notifies about outcomes of requests.

8. Sensor Web Enablement

9. SensorML SensorML is an XML encoding scheme that allows clients to remotely use real-time data from web- resident sensors. A standard format for sensor information enables integration, analysis, and creation of data views depending on the user. It also benefits the integration of heterogeneous sensors and platforms, providing an integrated view. It describes the geometric, dynamic, and observational features of sensors. The following figure shows the structure of the Sensor Model Language (SensorML).

10. SensorML

11. Observation and Measurement O&M is another standard information model and XML encoding. It is required for the Sensor Collection Service and related components of the OGC SWE. The aim is towards defining terms used for measurements, and the relationships between them. The following figure shows the basic observation structure.

12. Observation and Measurement

13. SWE Services SWE defines several standard services that can be used to collaborate with sensor networks. As we mentioned before, SWE contains three service specifications: –Sensor Collection Service (SCS) –Sensor Planning Service (SPS) –Web Notification Service (WNS) There are also two new services: Sensor Alarm Service, and TransducerML. The paper only covers the basic three mentioned above.

14. SWE Services (cont.) SCS is used to fetch observations from a sensor or collection of sensors. It plays the role of intermediary agent between a client and an observation repository or near real- time sensor channel. It responds to queries from the client with XML data conformed to the O&M model. SPS provides a standard interface to handle asset management (AM) that manages information sources to meet the client’s goals. It plays a role of coordinator responsible for evaluating the feasibility of the request and submitting the query to the SCS.

15. SWE Services (cont.) The WNS is an asynchronous messaging service. Sending and receiving notifications are the main responsibilities of the WNS, utilizing various communication protocols (HTTP POST, email, SMS, instant message, phone, fax, etc). Operations are defined to conduct both one-way and two-way communication between users and services.

16. Service Oriented Sensor Web Open Source Web Architecture (OSWA) is an SWE compliant infrastructure for providing service oriented access and management of sensors. It’s a platform for integrating sensor networks and distributed computing platforms such as SOA. Among the benefits, the heavy information processing load can be moved to backend distributed systems such as grids. This can save a lot of energy in the sensor networks, and accelerate the processing. Individual sensor networks can be linked together as services.

17. High Level View of OSWA

18. The OSWA Platform Fundamental services are provided by low-level components, whereas high-level components provide tools for creating applications. The OSWA platform provides services such as: –Sensor notification, collection, and observation –Data collection, aggregation, and archive –Sensor coordination and data processing –Faulty sensor data correction and management –Sensor configuration and directory service The OSWA focuses on providing an interactive development environment, a middleware and coordination language for developing sensor apps.

19. A Prototype Instance of OSWA

20. Design and Implementation The primary design and implementation of OSWA focuses on its core services (SCS, WNS, and SPS), The Sensory Repository Service is also key, providing the persistent mechanism for sensor and observation data. In the following figure, we show a typical client collection request, and the invocations between relating services. We will then discuss the design and implementation of each of the core services in turn.

21. Invocation for Sensor Web Client

22. Sensor Collection Service SCS is one of the most important components residing in the service layer. It is the only component that needs to communicate directly with sensor networks. It is responsible for collecting sensing data and translating the raw information into the XML encoding so that other services can use it. The design of SCS provides an interface to both streaming data (built on top of TinyOS) and query based sensor applications (built on top of TinyDB). The following figure illustrates the architecture of the SCS.

23. Sensor Collection Service

24. Sensor Planning Service SPS uses a rule engine which reads a set of rules used to decide the feasibility of the plan made by the user. Rules can be in many different languages. The most important component is the scheduler: –It first composes the collection request and invokes the SCS to get the observation. –Asks the DataCollector to store the observation data for later use by other clients. –Sends notification to the WNS indicating the outcome of the collection request. The following figure illustrates the architecture.

25. Sensor Planning Service

26. Web Notification Service The WNS contains two basic components: AccountManager and Notification. The account manager stores data corresponding to users who have registered with the service. The notification component creates and sends messages, using various protocols, to users who have registered. The following figure shows the WNS architecture.

27. Web Notification Service

28. Experimental Results The authors present a series of preliminary results. Although the services they implement all work properly, the entire OSWA is not fully implemented. Many implementation issues are left as future work, especially regarding the SCS. This central component needs to be reliable, have good performance, and be scalable. The authors conclude that the SCS will greatly affect the performance and reliability of the entire system.