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

SID Creator

by Arne Broering on Apr 21, 2011

412 views

get the according paper here:

More…

get the according paper here:

http://www.springerlink.com/content/r64j30577l956775/

Less

Statistics

Favorites: 0
Downloads: 6
Comments: 0
Embed Views: 0
Views on SlideShare: 412
Total Views: 412

Okay, let’s start by looking at our motivation behind those developments:Assuming, close to the lovely Utrecht, there is some kind of industrial fire (e.g. a waste dump is burning) and this causes a dispersion of pollutants into the air. In this scenario, the disaster management organization has already a Sensor Web, based on OGC’s SWE services, in place. Through this Sensor Web, it can access sensors to get an overview of the situation or to compute dispersion models.However, the density of available wind sensor data is not high enough. So, the disaster management organization decides to deploy new wind sensors in the region in an on-the-fly manner.The newly deployed sensors have to be made available within the SensorWeb so that the existing applications can directly utilize the gathered observations. So what’s necessary is some kind of plug&play of sensors, which currently doesn’t really work with the SWE architecture...
… and this is due to the fact that our SWE service interfaces (e.g. SOS, SPS, SAS… here on the Sensor Web Layer) are intentionally designed from an application-oriented perspective (and not from a sensor perspective), so that applications have an interoperable access to the sensor functionality.So far, the connection between sensors and SWE services is not yet sufficiently described.Actually, we have here (on the sensor layer) a huge variety of protocols and the connection of those protocols to SWE services is so far usually established, by manually adapting the SWE service implementation.
an extension of OGC SWE's Sensor Model Language, to describe the sensor protocol of a particular sensor type in a declarative way. By means of a generic SID interpreter the native sensor protocol can be translated to SWE protocols. The SID interpreter is independent of a particular sensor technology, and can communicate with any sensor whose protocol can be described by a SID. Hence, a repository of SID instances allows users to choose an SID instance which then serves as a “driver” to make the sensor functionality available for the Sensor Web.Current SWE standards do not deal with actual sensor protocols, and the connection between sensors and SWE services is usually established by manually adapting the internals of the SWE service implementation to the specific sensor interface. Such sensor "drivers" have to be built for each kind of sensor interface, which leads to extensive efforts in developing large-scale systems. To tackle this issue we have developed a model for Sensor Interface Descriptors (SID) which enables the declarative description of sensor interfaces, including the definition of the communication protocol, sensor commands, processing steps and metadata association. The model is designed as a profile and extension of OGC SWE's Sensor Model Language standard. In this model, a SID is defined in XML for each kind of sensor protocol. SID instances for particular sensor types can be reused in different scenarios and can be shared among user communities. A SID interpreter can be built which translates between various sensor protocols and SWE protocols, hence closing the described interoperability gap. The SID interpreter is independent of any particular sensor technology, and can communicate with any sensor whose protocol can be described by a SID. The SID interpreter transfers retrieved sensor data to a Sensor Observation Service, and transforms tasks submitted to a Sensor Planning Service to actual sensor commands.
Let me illustrate our approach to solve this issue: the concept of Sensor Interface Descriptors.This slide shows a typical SWE deployment scenario.We have our sensor (here) and our SWE services (at the top, here) *click* and usually in between some kind of Data Acquisition System, or a sensor network sink.A sensor communicates with the data acquisition system in its specific sensor protocol over a transmission technology such as ISDN or GSM*click: SID sichtbar* So, to integrate this sensor with the SWE services, we developed a SensorML application schema/profile, called Sensor Interface Descriptors, which can be used to describe the sensor protocol in a declarative way. So what we need is an SID instance for the sensor… * click: SID interpreter sichtbar* ...Then, based on the SID schema one can build sensor technology independent SID interpreters, which runs on the DAS and uses the SID (so the sensor protocol definition) * click: Pfeilsichtbar* to translate the protocol to the SWE world.It registers a sensor at a SWE service and uploads sensor data to SOS or SAS and is responsible for the opposite communication direction and forwards tasks received by an SPS to a sensor.
This slide gives an overview of the SID model (which is implemented as an XML schema and has been published as such at the OGC in the meantime).It is nicely integrated in SensorML. All the blue classes here are added to the SensorML schema. *click* The SID (now surrounded in red) is strictly encapsulated within the SensorML structure. This way, it can be easily replaced or removed. This characteristic is important to make it possible to reuse the SID in different use cases for sensors with same interfaces. The ability of reusing SIDs also enables sharing SIDs for particular sensor types among user communities.For these reasons, the approach developed here, encapsulates all SID specific information within the sml:interface element of the sml:System.The SID schema extends the OSI layer model and adds certain types to those layers. These types will be explained later on.…
A simple wizardbasedgraphicaluserinterfaceallowingyou to specifybasicsensormetadata and definingtheprotocol of a sensortype.
Weevaluatedthisnewtool in a usecasestudy, where 10 high schoolstudents and 10 universitystudentsweretasked to integrate …
- - After each test, the participant was asked to complete a questionnaire. For example, the participants were asked whether they think they have fully/partly/not understood the principle of the SID concept and whether it can replace manual implementation of adapters between sensor and SOS. The answer to this question should indicate a self-report measure about how sure the participant is of what he/she just did.
-- question whether the SID creator in its current design has enough functionality to support all kinds of sensor types. It is assumed that complex sensor interfaces still require a manual implementation of adapters.

SID Creator — Presentation Transcript

The SID Creator – A Visual Approach for Integrating Sensors with the Sensor Web
Arne Bröring, Felix Bache, Thomas Bartoschek, Corné v. Elzakker
AGILE, 20th April 2011
Motivation: Sensor Plug & Play
Arne Broering - broering@52north.org
Problem: Interoperability Gap
Application Layer
Sensor Web Layer
Sensor Layer
Arne Broering - broering@52north.org
Sensor Interface Descriptors (SID)
Bridging Sensor Protocol <-> SWE Protocol
Model to declaratively describe sensor interface:
Communication protocol
Sensor commands
Processing steps
Metadata association
SID instances: re-usable and exchangeable
Generic SID Interpreter translates:
Sensor protocol   Sensor Web protocol
Arne Broering - broering@52north.org
Sensor Interface Descriptors (SID)
Sensor Web Layer
Sensor Layer
Arne Broering - broering@52north.org
SID Model
Arne Broering - broering@52north.org
How to generate SID instances?
 The SID Creator
Arne Broering - broering@52north.org
UseCase: School Weather Station
10 high schoolstudents
10 universitystudents
Task
Integrateweatherstationwith
a Sensor Observation Service
“Think Aloud” method
Arne Broering - broering@52north.org
UseCase: School Weather Station
Creation of an SID
Sensor Data:
Station|16.09.2010_12:56|10530Q|#
Status|16.09.2010_12:56|72|#
Wind01|16.09.2010_12:56|42.0|23.0|#
:
Block
Field
SID:
Structure Separation:
Block = #
Field = |
Decimal Numbers = .
Data Block 1:
Field 1 = Block_Identifier Value: Wind01
Field 2 = time
Field 3 = wind_speed
Field 4 = wind_direction
:
Association with Observation Metadata
Observed Property := „Wind Speed“
Phenomenon Time
Result
Feature := „High School Havixbeck“
23 m/s 16.9.2010 13:45
Unit of measure
Procedure := „DAVIS_123“
Observation Offering:= Weather
Arne Broering - broering@52north.org
Evaluation of UsabilityStudy
Arne Broering - broering@52north.org
Evaluation of UsabilityStudy
Successfulcreation of SID:
High School students: 2 / 10
University students: 6 / 10
Fully / partly / notunderstood SID?
High School students: 4, 3, 3
University students: 9, 1, 0
SID creationeasierthanadapterimplementation?
5 / 5 students: yes
Arne Broering - broering@52north.org
Conclusions & Outlook
 SID Creator facilitatessensorintegration
SID Creator doesnotyetsupportfull SID model
Not all sensorprotocolscanbedescribed.
Vision:
Sharing of SID instancesamongusercommunities
Creation of SIDsbysensormanufactures
Arne Broering - broering@52north.org
Questions?
Thank you!
Arne Broering
SID project @ 52°North: http://52north.org/sid
Sensor Web lab @ IfGI: http://swsl.uni-muenster.de

SID Creator

by Arne Broering on Apr 21, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

SID Creator — Presentation Transcript