Sensors can be used to measure e.g. a room's light intensity, motion inside of it or its temperature. Thus a room's state described by these parameters and others may be used to derive further information concerning its current situation or the ongoing cooperative process inside that room (e.g. a current meeting).
This project aimed to extend the SensBase architecture to a Service Oriented Architecture (SOA) by using the Broker pattern. It focused on replication of sensor’s data and distribution issues of sensors. This project extended the SensBase architecture (cf. Figure 1) with a broker, service providers, service consumers. A broke is a centralised unit, which holds all information about registered sensors and their locations. Furthermore, it enables standardised communication within among distributed SensBase infrastructures. The broker allows better decoupling of the sensor and the consumer of the sensor services. Each SensBase infrastructure can act as a Web service provider and allow encapsulating and hiding of all specific hardware implementation details of their attached sensors. Furthermore, they provide a simple common interface for other application to obtain real-time sensor data, or persistently stored past sensor data. A service consumer can discover available sensors and their contact information via the broker and can then directly request required sensor data from that service. the service consumer communicate the service according to a well-defined interface, described in the Web Service Description Language (WSDL) that includes function names, required parameters, and results.

Figure 1. Extension of the SensBase architecture with a broker.

We developed in this project XML-schemas for describing sensors and their locations as well as their events (cf. Figure 2).

1 <?xml version="1.0" encoding="UTF-8"?>
2 <Event xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="115">
3 <Mandatory>
4 <SensorID>Temp_Sensor_04</SensorID>
5 <SensorType>Temperature sensor</SensorType>
6 <SensorValue>24,4</SensorValue>
7 <OccurrenceTimeStamp>
8 <OccurrenceDate>2005-08-13</OccurrenceDate>
9 <OccurrenceTime>18:20:59</OccurrenceTime>
10 </OccurrenceTimeStamp>
11 <Location>B11</Location>
12 </Mandatory>
13 <Optional>
14 <RelativeTimestamp>Late</RelativeTimestamp>
15 <Urgency>
16 <UrgencyType>Infomation</UrgencyType>
17 <UrgencyValue>Test</UrgencyValue>
18 </Urgency>
19 <Granularity>Fine</Granularity>
20 <Ingredients>
21 <EventID>String</EventID>
22 </Ingredients>
23 <Relationship>
24 </Relationship>
25 </Optional>
26 <Custom>
27 <Pair>
28 <Key>Custom key</Key>
29 <Value>Custom value</Value>
30 </Pair>
31 </Custom>
32 </Event>

Figure 2. Example of formatted sensor event.

Furthermore, we examined some security and privacy concept (e.g. role-based access control , security policies ) enforce access control upon sensors and users for ensuring that a user has the permissions required to access specific sensor's data. In the next term (2005/2006) we will focus on developing of security and privacy aspects for Sens-ation II.

Current Status

Finished.

Past Events

July 15-17, 2005 CML Open House 2005 at CML-B11.
July 14, 2005 15:30 - Final presentation.
May 26, 2005 11:00 - Midterm presentation.
April 14-15, 2005 - Workshop Cooperative Programming in Java

Resources

	Internal Resources (Restricted Access)
	Sensation2 Video, Length: 7:40 min. Format MPEG 4. Size: 82 MB
	Internal CML-BSCW workspace for this project
	This project's internal Tikiwiki

People

Stefanie Heinz
Daniel Moreno Linares

Tom Gross (Supervisor)
Tareg Egla (Supervisor)

Created by: oemig last modification: Monday 28 of August, 2006 [17:04:46 UTC] by mirko.fetter