• Save
The Sensor Bus – Integrating Geosensors and the Sensor Web
Upcoming SlideShare
Loading in...5
×
 

The Sensor Bus – Integrating Geosensors and the Sensor Web

on

  • 2,197 views

Held at OS GIS UK, 22 June 2010

Held at OS GIS UK, 22 June 2010

Statistics

Views

Total Views
2,197
Views on SlideShare
2,149
Embed Views
48

Actions

Likes
2
Downloads
51
Comments
1

5 Embeds 48

http://swsl.uni-muenster.de 40
http://sensorweb.uni-muenster.de 3
http://www.linkedin.com 3
https://twitter.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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!
  • 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.
  • 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)
  • 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
  • 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
  • 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.
  • 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
  • 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.
  • 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
  • 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
  • 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.
  • 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

The Sensor Bus – Integrating Geosensors and the Sensor Web The Sensor Bus – Integrating Geosensors and the Sensor Web Presentation Transcript

  • The Sensor Bus – Integrating Geosensors and the Sensor Web
    Arne Broering, Simon Jirka & Dr. Theodor Foerster
    OSGIS, 22 June 2010
  • Motivation
    Sheffield 2007, source: BBC
    Disaster management requires real-time sensor data!
    On-the-fly integration of (geo)sensors!
  • Sensor Web Enablement (SWE)
    http://www.ogcnetwork.net/swe
    Web Service interfaces & data encodings
    Used to build a Sensor Web
    Integration of (geo)sensors on application level
  • SWE - Functionality
    Discovery
    Sensor Instance Registry
    Sensor Observable Registry
    Access
    Sensor Observation Service
    Tasking
    Sensor Planning Service
    Eventing / Alerting
    Sensor Alert Service
    Sensor Event Service
    SIR
    SOR
    SOS
    SPS
    SAS
    SES
  • Problem: Conceptual Gap
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Problem: Conceptual Gap
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Problem: Conceptual Gap
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Problem: Conceptual Gap
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Problem: Conceptual Gap
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Problem: Conceptual Gap
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Close gap: Sensor Network – Sensor Web
    Ease sensor / service integration
    Facilitate usage of SWE
    On-the-fly integration (plug & play) of sensors
    Objectives
  • Sensor Bus
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Sensor Bus
    Application Layer
    Sensor Web Layer
    Sensor Network Layer
  • Bus Message Protocol
    RegServ*<service URL>*<sensor A id>
    RegServ*<service URL>*<sensor B id>
    ...
    Service Registration
    Sensor Registration
    Data Publication
    Sensor Tasking
    Status Update
    IntroSen*<sensor id>*<description URL>
    PubData*<sensor id>*<time>*<property>*<data>
    PubTask*<sensor id>*<task id>
    TaskParam*<task id>*<param 1>*<value 1>
    ...
    DoTask*<task id>
    SenStatus*<sensor id>*<property>*<value>
  • Sensor Bus - Twitter
    SPS
    SOS
    SWE
    SWE
    DB
    Config
    • Account
    • Sensors
    Config
    • Account
    • Sensors
    Service
    Adapter
    Service
    Adapter
    1. PubTask
    2. TaskParam 10 min
    ...
    x. DoTask
    1. IntroSen
    2. PubData 30°
    3. PubData 45°
    ...
    Sensor
    Adapter
    SensorML
    • Position
    • Feature
    • Property
    • ...
    Config
    • Account
    • Services
  • Sensor Bus - Twitter
    Pros:
    Managed scalability
    Managed reliability
    Managed security
    Cons:
    Limited Tweet length (140 characters)
    Limited update rate of search index
    Max 150 requests per hour (20.000 if whitelisted)
    Max 1.000 Tweets a day
  • Outlook
    Evaluate different implementations
    Twitter, XMPP, IRC, JMS, ...
    Develop mechanisms for sensor plug & play
    Apply to real world use cases
    www.etamax.de
    www.G-WaLe.de
    Sensor
    Adapter
    Sensor Interface Description
    (SensorML)
  • Questions?
    Thank you!
    Dr. Theodor Foerster
    theodor.foerster@uni-muenster.de
    Sensor Web community: http://52north.org/SensorWeb
    Sensor Bus project: http://52north.org/sensorBus
    SWSL: http://swsl.uni-muenster.de