The Sensor Bus – Integrating Geosensors and the Sensor Web

Editor's Notes

• #3: Let’s start with looking at the motivation of our work and the surrounding project.Well, to manage disasters such as large-scale floods (like the one in Dresden 2002, or in Italy 2001), the supply with up-to-date information is crucial for decision support.clickThis necessary information can be derived from real-time sensor data.In case of floods, those geosensors are for example:Water-level sensorsWeather stations and attached precipitation and wind sensorsor Web cameras and stress monitors attached to bridges or dams to get insight about their status clickTo make those sensors usable and accessible for different disaster management organisations using different systems and applications, an (on-the-fly) integration of the geosensors into a coherent infrastructure is required!
• #4: This necessary integration of geosensors on the application level can be realized by using the specification framework defined within the Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (abbreviated: OGC).The SWE standards framework comprises standards of web service interfaces and communication protocols which can be used to build a so-called Sensor Web.If you are interested in detailed information about the standards of the OGC, this website is a good starting point.
• #5: The SWE framework defines standards for the following core functionalities of a Sensor Web:sensor instance discovery (Catalogue / Registry)sensor data access (SOS)sensor tasking (SPS)alerting & notification mechanisms in cases of specified events (SAS / WNS)
• #6: This slide shows the role of the Sensor Web in relation to the Application Level and the Sensor Network Level.Sensors and Sensor Networks are deployed in the real world.The SWE or Sensor Web services encapsulate the sensors and hide their heterogeneous protocols.The services offered interoperable interfaces to the applications which can make use of the sensor functionality then.clickThe 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
• #7: There is a 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 CAN-Bus, the IEEE 1451 standards family, or even proprietary protocols Impedance mismatch between the low-level data structures (signals) and the higher-level information models of the Sensor Web world
• #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.
• #12: So, the objectives of this work are to:Develop methods to bridge the gap between …Thereby, the integration of new sensors and new services into the Sensor Web shall be facilitatedConsequently, the usage (and especially the administration and deployment) of SWE services shall be facilitatedThe mid-term aim of our project is to enable an on-the-fly integration of sensors with a minimum of human intervention – so a true plug&play of sensors into the Sensor Web shall be achieved
• #13: The basis of our approach for achieving these aims is shown on this slide.We introduce an additional, intermediary layer which stands between Sensor Network layer and Sensor Web layer.We align this intermediary layer with the Message Bus pattern from “Enterprise Application Integration” and we call this intermediary layer “Sensor Bus”.For sensors and services, pluggable adapters are developed which can be attached to the Sensor Bus and establish the connection between bus and sensors and services.Thereby, the Sensor Bus realizes publish subscribe mechanism. Services can subscribe for sensors in which they are interested.
• #14: The concept facilitates the integration of new sensors:…example: fancy ultra sonic anemometerIn future: plugin repository for sensorsAlso, the deployment of new services in the Sensor Web is facilitated:…example: discovery services
• #16: Different communication infrastructures are possible.Twitter is one of them: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
• #17: Building the Sensor Bus on Twitter enables reusing functionality such as scalability and reliability management.Also, security mechanisms can be incorporated, since authentication functionality is provided by Twitter.However, there are some disadvantages in using Twitter as the communication infrastructure:Pull-based design of Twitter does not allow a true push-based Sensor Bus. Instead, the message retrieval has to be realized by regularly submitted API queries.Another disadvantage is the limited update rate of Twitter's search index which means that for example a data publication message posted by a sensor adapter is not instantly accessible by a service adapter.The length of a 'tweet' is restricted to 140 characters.Twitter account cannot submit more than 150 requests per hour A service adapter can maximally query 150 times an hour the recently posted tweets of all sensors it is followingTo solve this issue Twitter offers the possibility for applying to “whitelist” certain accounts or IP addresses. A whitelisted entity can submit 20.000 requests per hour.Twitter account cannot send more than 1.000 tweets a day. In the current design of the Sensor Bus implementation, a sensor posts one data value per tweet. So, this results in a maximum sampling rate of around 40 measurements per hour. In many sensor network applications, this would be unacceptable.
• #18: Our future steps are:We want to evaluate different implementations of the Sensor Bus using different base technologies. Besides Twitter and XMPP, we are looking at IRC, JMS and Pub Sub Hubbub.We want to work on our mid-term aim, of achieving sensor plug & play.Therefore, we are currently developing a specific profile for OGC’s Sensor Model Language specification – the Sensor Interface Descriptor LanguageThis flexible XML dialect allows to describe arbitrary sensor interfaces in a declarative mannerWe are also creating specific GUIs and tools which support sensor administrators to configure an SID for their particular sensorsLast but not least, we will apply the develop approach to real world use casesAs I mentioned in the beginning, our project focuses on flood monitoringIn this context we are cooperating with a company called etamaxThey are developing these neat mobile water level sensors – football-sized buoys which can be thrown into rivers if there is demand for sensor network densification.We will use this system as a showcase for our methods