SenseWeb Developer Page

UNDER CONSTRUCTION

This page provides information for people using SenseWeb in their applications and research projects. It also discusses forthcoming features in SenseWeb and discusses their design implications.

Using SenseWeb

To begin using SenseWeb, see the tutorial on the main page.

For general usage questions, requests for features, comments on our forthcoming design, please use the SenseWeb forum.

For specific questions relating to your project (Eg. increasing limit on sensors per account), please email senseweb (at) microsoft (dot) com.

New Architecture, Forthcoming Features

The new architecture is shown in Fig 1 and discussed below (see this paper for more details). The label “WS-API” in the figure denotes web service API’s that will allow developers to use SenseWeb functionality in their projects. The new architecture is currently being implemented and the API documentation will be coming out soon (see this page for updates).

Fig 1. SenseWeb’s open system architecture for flexible sharing.

Coordinator

The Coordinator is the central point of access into the system for all applications and sensor contributors. It consists of two components: SenseDB and Tasking Module. The SenseDB acts as an index of all available sensors, their characteristics, and other system resources. It acts similar to a DNS server on the Internet, converting user friendly sensor descriptions such as location boundaries or sensor types to physical sensor identifiers. The functions of the tasking module are to accept applications’ sensing requirements and attempt to satisfy these from available sensing resources. It also leverages the overlap among multiple application needs, and attempts to minimize the load on the sensors or the respective sensor gateways by combining the requests for common data and also using a cache for recently accessed data. For instance, if data collected in response to an application’s query is cached, other queries in the near future with partially overlapping needs may be served partly from the cache, and the number of sensors accessed may be reduced.

Sensors, Sensor Gateways, Mobile Proxy

The sensing resources form the foundation of the entire system. Sensors could be measuring various physical variables and may be static or mobile, carried by humans, on vehicles, or in robots.

Since sensors may be built using many different platforms widely varying in processing power, energy, and bandwidth capabilities, they may have different interfaces to access them. Low powered wireless sensor nodes may use 15.4 radios to communicate while higher power and higher bandwidth sensors may need Firewire or similar interfaces. They may or may not be connected at all times. To hide much of this complexity, the sensors are connected to a Sensor Gateway that provides a uniform interface to all components above it. The gateway implements sensor specific methods to communicate with the sensor. However, other components of SenseWeb access the gateway to obtain sensor data streams, to submit data collection demands, or access sensor characteristics through a standardized web service API. Each sensor contributor may maintain his or her own gateway. The gateway may also implement sharing policies defined by the contributor. For instance, the gateway may maintain all raw data in its local database, possibly for local applications run by the sensor owner but only make certain non-privacy-sensitive parts of the data or data at lower sampling rates, available to the rest of the SenseWeb.

One shared gateway, named Datahub, has also been implemented, and may be used by sensor contributors who do not wish to maintain their own gateway. DataHub communicates with sensors through a web service API. Tools for common types of sensors including wireless motes and network cameras are provided (see Tutorial).

A special gateway built for mobile sensors is the mobile proxy. (Design details TBA)

Data Transformers

The role of a transformer is to convert data semantics through processing. For example, a transformer may extract the people count from a video stream. Additional examples of data transformers are unit conversion, data fusion, and data visualization services. Moreover, application developers can extend SenseWeb’s processing functionality by writing new transformers on top of Coordinator’s primitive access methods. Domain experts may implement various transformers for different sensor data using suitable domain specific algorithms. Transformers are indexed at the Coordinator and may be discovered and used by applications as needed. They provide an interface similar to that of a Sensor Gateway but serve processed data. One example of a transformer is the Iconizer implemented in our prototype: it converts raw sensor readings into an icon that represents sensor type in its shape and sensor value in its color. Graphical applications may use the output of this transformer instead of raw sensor values.

Applications

Applications are all users of sensor data. These may be interactive applications where human users specify their data needs manually, such as a user queries for average hiker heart rate over the last season on a particular trail, or automated applications in backend enterprise systems that access sensor streams for business processing, such as an inventory management application that access shopper volume from parking counters, customer behaviors from video streams, and correlates them with sales records.

Usage Scenarios for Frequently Asked Features

Several projects have asked for certain functionality not currently supported in the deployed prototype. The following list includes some of the requested features, and explains how SenseWeb provides or will provide the functionality for realizing them.

SenseWeb:

1. Local storage of data (outside SenseWeb): The gateway shown in the architecture can be deployed outside of SenseWeb. A sensor contributor may wish to use their custom gateway instead of the one provided in SenseWeb in certain situations such as when they want to locally store their data (Eg. privacy sensitive data, for which only selective or processed parts may be shared), to support specific types of sensors not supported natively in SenseWeb, or to use custom data management not part of the database used in SenseWeb’s Datahub (Eg. content based image indexing), etc.

2. Support for vector sensors, such as weather stations, with multiple transducers on a single node.

3. New scalar sensors: rainfall, …

4. Security of contributor data: The data stored on the SenseWeb’s default gateway, DataHub, will provide for access control, such that when needed, parts of the data can be shared selectively. The goal is to allow sharing more data and sensors that are not suitable to share publicly.

5. Direct access to data from local source when application (user) accessing sensor is close to source (rather than the data flowing through a central server): An appropriate method will be provided to access data directly from a gateway after the required gateways have been discovered using central indices.

6. Support for mobile sensors: Methods to efficiently index data from mobile sensors where each sample need not be taken at the same location will be added. While some such methods have been prototyped for image data (see publications), generalized methods are under development and may be added to the SenseWeb deployment when ready.

Further, the map based frontend, SensorMap, is also evolving in response to user needs:

1. Icons for new common sensors: weather stations, (request others by emailing the forum)

2. Advanced Visualization, such as generated by other tools: The exact interfaces to integrate visualizations generated by other tools, such as those used in scientific visualization are under development.

3. 3D Virtual Earth view: In addition to the 2D map view, 3D view will be added.

4. Virtual Earth image overlay functionality will be exposed in SensorMap.

5. Time plots of sensor data: In addition to current sensor values, SensorMap will show plots of past sensor values.

Some of these forthcoming features may be seen in demo versions, before their release in the SenseWeb deployment, at presentations made to the scientific community over the next few weeks.