Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010

Editor's Notes

• #6: The focus of the Sensor Web (-> SWE) design is the interaction with the application level. That is already well-defined.However, the Sensor Web design does not sufficiently describe the interaction between sensors and SWE services, yet.There is a conceptual gap between the 2 layers:Sensor Web is based on the WWW and its related protocols. On the other hand, sensor network technologies are based on lower-level protocols such as ZigBee, Bluetooth, the IEEE 1451 standards family, or often proprietary protocols
• #8: Currently, the Sensor Web and sensor network layer are integrated by manually adapting the internal logic of the services to the specific sensor types. These proprietary bridges have to be manually built for each pair of Web service and sensor type. This approach is cumbersome and leads to extensive adaption efforts to link the two layers. Since the price of sensor devices is decreasing rapidly, these adaption efforts become the key cost factor in large-scale sensor network system.
• #9: Currently, the Sensor Web and sensor network layer are integrated by manually adapting the internal logic of the services to the specific sensor types. These proprietary bridges have to be manually built for each pair of Web service and sensor type. This approach is cumbersome and leads to extensive adaption efforts to link the two layers. Since the price of sensor devices is decreasing rapidly, these adaption efforts become the key cost factor in large-scale sensor network system.
• #10: Currently, the Sensor Web and sensor network layer are integrated by manually adapting the internal logic of the services to the specific sensor types. These proprietary bridges have to be manually built for each pair of Web service and sensor type. This approach is cumbersome and leads to extensive adaption efforts to link the two layers. Since the price of sensor devices is decreasing rapidly, these adaption efforts become the key cost factor in large-scale sensor network system.
• #13:  Mit unserem SensorBus approach müssen nur noch einmal Plugins für jeden Sensor und jeden Service geschrieben werden.
• #14: Dies erleichtert die Integration neuer Sensoren ungemein
• #15: Discovery?
• #16: Service Registration – Twitter- Done by service administrator who just wants to specify the Ids of interesting sensors and everything else is handled.Create Twitter profileCreate and start service adapterAccompany service adapter withconfig file specifying access information to communication infrastructure (here: Twitter account ID)Sensor Ids of interestService adapter registers service profile as follower at the sensor profiles which are associated with the service (it has to search Twitter for the sensor ID and then registers as follower at the sensor profile)This „following“ is necessary so that the service adapter can access potentially private sensor tweetsService adapter inserts sensor information into its DBSensor Registration – Twitter- Done by sensor administrator who does not want to access the servicesCreate Twitter profileCreate and start sensor adapterAccompany withdetailed metadata description (SensorML)Config file specifying access information to communication infrastructure (here: Twitter account ID); in case of other communication infrastructures: e.g. Port, URL, Channel...Sensor adapter registers sensor profile as follower at service profiles from which tasks shall be retrievedData Publication – TwitterService adapter checks regularly the sensor profile for updatesService adapter grabs new data, transforms it to SWE and forwards it to serviceSensor Tasking – TwitterSPS receives task description from client and forwards it to service adapterService adapter transforms task description to bus message sequenceSensor adapter checks regularly the service profile for new tasksSensor adapter retrieves new task, transfroms it to sensor protocol and forwards it
• #26: By taking a use case from disaster management, we outline the challenges and demonstrate how semantically annotated SWE data models and service interfaces support semantic matching.A fast extending blaze at the waste dump of Muenster in Germany causes a dispersion of pollutants into the air. The air pollutants threaten an important European bird reserve, the so called Rieselfelder, and the surrounding settlements. In our scenario, mobile sensors are deployed to monitor air pollutants, wind speed, and wind direction. We assume that a local Sensor Web is already in place and used by a disaster relief organization. The newly deployed sensors have to be made available within the SensorWeb on-the-fly. Applications can directly utilize the gathered observations to get an overview of the situation and for dispersion simulations. Additionally, we assume that the sensors used in this gas plume scenarioare accompanied by a SensorML self-description provided by its vendor or manufacturer.Such a scenario is typical for Sensor Web use cases as it covers two important tasks at the same time - device discovery (e.g., which sensors are necessary to monitor the gas plume) and data discovery (e.g., which data can be used to compute the dispersion of the gas plume).