Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

The Sensor Bus – Integrating Geosensors and the Sensor Web

by Dr. Theodor Foerster on Jun 22, 2010

966 views

Held at OS GIS UK, 22 June 2010

More…

Held at OS GIS UK, 22 June 2010

Less

2 Embeds 29

http://swsl.uni-muenster.de	26
http://sensorweb.uni-muenster.de	3

Statistics

Favorites: 0
Downloads: 33
Comments: 1
Embed Views: 29
Views on SlideShare: 937
Total Views: 966

1–1 of 1 previous next

Arne Broering , Research Associate at 52North, IfGI, ITC Please find the according paper here:
http://ifgi.uni-muenster.de/~arneb/comgeo2010.pdf 1 year ago Reply
Are you sure you want to Yes No

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 — 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

The Sensor Bus – Integrating Geosensors and the Sensor Web

by Dr. Theodor Foerster on Jun 22, 2010

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 29

Statistics

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