The SenseWeb architecture is shown in the figure below.


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

The SenseWeb architecture consists of multiple sensor gateways that connect sensors deployed by several contributors to the Internet using SenseWeb's open API's. A common gateway, accessible through the DataHub web service interface has been deployed for those sensor owners who do not wish to deploy their own. A specialized gateway to collect data from mobile sensors is shown as well, labelled as the mobile proxy. Another key entity is the coordinator, that consists of two components - SenseDB and Tasking Module. The SenseDB acts as an index of all available sensors 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 tasking module accepts sensing requirements and pulls the appropriate data from sensor gateways. It optimizes communication and processing to take advantage of redundancy in sensing requirements, using data caching and other means. Applications (e.g. SensorMap) that wish to use SenseWeb for their sensing needs submit their requirements to the coordinator or to another class of entities shown as transformers. Transformers perform data processing on the sensor streams fetched through the coordinator. Transformers could carry out domain specific processing that may be shared by multiple applications. For instance, one transformer shown, used by the SensorMap application, helps covert raw sensor data into user friendly visualizations, such as spatio-temporal graphs or map icons.
Note: The architecture described above is under development and differs from the public deployment. The publicly deloyed architecture is discussed in the first part of the tutorial above. The new architecture will become available soon - see the Developer Page for updates and detailed design discussions.

We are building a sensor type ontology to let SenseWeb automatically render sensor data. We plan to adopt some of the Semantic Web techniques such as RDF. A simple starting point is SensorType.xml.

The ontology organizes sensor types into a class hierarchy. In this example, the base class is a generic sensor. Derived from it are QuantitySensor and ImageSensor. Thermometer is a subclass of a QuantitySensor and a VideoCamera is a subclass of an ImageSensor. Aggregation operators are defined on the most abstract types. For example, COUNT applies to type Sensor. That is, we can always count the number of sensors in an area. Numerical operators, such as MIN, MAX, and AVERAGE, apply to QuantitySensors. Thus, when a new sensor, say a pressure sensor, is added as a subclass of QuantitySensor, all the appropriate operators automatically apply and their values are shown in the client UI.

Note that this is just a starting example. Extensions to other sensor types, such as waveforms (e.g. magnetometer), presence (e.g. parking space occupation), and generic XML objects, are under development.