Sensor Plug & Play with OGC Standards
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Sensor Plug & Play with OGC Standards

on

  • 1,060 views

 

Statistics

Views

Total Views
1,060
Views on SlideShare
1,058
Embed Views
2

Actions

Likes
1
Downloads
31
Comments
0

2 Embeds 2

http://blog.52north.org 1
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

Sensor Plug & Play with OGC Standards Presentation Transcript

  • 1. 1
  • 2. 2
  • 3. 3
  • 4. Research Institutes:IfGI – Institute for Geoinformatics (part of University of Muenster)ITC - part of University of Twente, NetherlandsAITIndustrial Partners:KistersESRICon terraAgencies:BAW: DLZ-IT 4
  • 5. 5
  • 6. The motivation to develop the Sensor Web idea was that there are sensorseverywhere today.There are weatherstations attached with sensors.Sensors are used to monitor water resourcesThere is the application field of precision agriculture where sensors are used to makeagriculture more efficient.To make fire fighting more secure, we put sensors onto firemen.And of course, we have for example more and more CCTV cameras in our cities.A similar situation applies for the EEA and its associated member state organizations.There, we have environmental data mostly gathered by heterogeneous sensors and isnow offered by a variety of heterogenous data sources. 6
  • 7. 7
  • 8. Our vision is to realize the so-called Sensor Web.But, what is the Sensor Web?Well, we all know the World Wide Web which gives us easy access to informationresources, websites. We can access those resources easily thorough well-definedstandards such HTTP, and on-top of that HTML, ...The Sensor Web on the other hand is not for information resources, but for sensorresources. And also here, the basis for enabling the Sensor Web are standards. 8
  • 9. The SWE standards framework comprises standards of web service interfaces andcommunication 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, thiswebsite is a good starting point. 9
  • 10. This figure shows the functionality of the main SWE services.SOS – Sensor Observation Service ACCESS to sensor dataSAS – Sensor Alert Service / SES – Sensor Event Service EVENTING within Sensor WebWNS – Web Notification Service NOTIFICATION of usersSPS – Sensor Planning Service TASKING of sensors 10
  • 11. Okay, let‘s have a closer look at the Sensor Web component for sensor data (andmetadata) access. 11
  • 12. Basis for a standardized access to sensor data is the observation model defined in theObservations & Measurements standard. Let me briefly describe the main concepts /terms used in this model… 12
  • 13. O&M defines a model describing sensor observations as an act of observing a certainphenomenon (e.g. temperature, or water level). The basic observation modelcontains 5 components as shown in this figure.The observation comprises a link to the procedure (usually a sensor, e.g., a watergauge), which generates the value for the observation,as well as a reference to the observed property (e.g., water level) representing thephenomenon which was observed.The feature Of interest refers to the real world entity (e.g., a river) which was targetof the observation and has to carry the observed property as its feature property.The sampling time attribute indicates the time, when the observation was applied tothe feature of interest.The observation value is contained in the result element. It depicts a symbol for theobserved phenomenon during the sampling time located at a certain feature ofinterest. Thus, the type of the observation result must be consistent with theobserved phenomenon and the observed property has to be a property of the featureof interest. 13
  • 14. 14
  • 15. Sensors and their observations can be registered and stored through the SensorObservation Service (SOS) to make them accessible for clients.The SOS uses the Sensor Model Language (SensorML) specification for the encodingof sensor metadata descriptions.The Observations and Measurements (O&M) specification is utilized by the service toencode the data gathered by sensors.The features of interest which are target of the sensor observations can be e.g.encoded in GML an can be retrieved through the GetFeatureOfInterest operation. 15
  • 16. An example enterprise system within which the German Aerospace Agency (DLR)used 52°North SWE service implementations to provide access to various kinds ofsensors is the tsunami early warning system GITEWS (http://www.gitews.org/ ). 16
  • 17. 17
  • 18. Application scenario: Oil Spill.Aim: Newly deployed sensors have to be made available within the Sensor Web sothat the existing applications can directly utilize the gathered observations.So what’s necessary is some kind of plug&play of sensors, which currently doesn’twork with the SWE framework. 18
  • 19. This is due to the fact that SWE service interfaces (SOS, SPS, SAS… here on the SensorWeb Layer) are intentionally designed from an application-oriented perspective, sothat applications have an interoperable access to the sensor functionality.So far, the connection between sensors and SWE services is not yet sufficientlydescribed.On the sensor layer, there is a huge variety of protocols and the connection of thoseprotocols to SWE services is so far usually established, by manually adapting the SWEservice implementation. 19
  • 20. Currently, the Sensor Web and sensor network layer are integrated by manuallyadapting 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 andsensor type.This approach is cumbersome and leads to extensive adaption efforts to link the twolayers. Since the price of sensor devices is decreasing rapidly, these adaption effortsbecome the key cost factor in large-scale sensor network system. 20
  • 21. Currently, the Sensor Web and sensor network layer are integrated by manuallyadapting 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 andsensor type.This approach is cumbersome and leads to extensive adaption efforts to link the twolayers. Since the price of sensor devices is decreasing rapidly, these adaption effortsbecome the key cost factor in large-scale sensor network system. 21
  • 22. Currently, the Sensor Web and sensor network layer are integrated by manuallyadapting 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 andsensor type.This approach is cumbersome and leads to extensive adaption efforts to link the twolayers. Since the price of sensor devices is decreasing rapidly, these adaption effortsbecome the key cost factor in large-scale sensor network system. 22
  • 23. Currently, the Sensor Web and sensor network layer are integrated by manuallyadapting 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 andsensor type.This approach is cumbersome and leads to extensive adaption efforts to link the twolayers. Since the price of sensor devices is decreasing rapidly, these adaption effortsbecome the key cost factor in large-scale sensor network system. 23
  • 24. Currently, the Sensor Web and sensor network layer are integrated by manuallyadapting 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 andsensor type.This approach is cumbersome and leads to extensive adaption efforts to link the twolayers. Since the price of sensor devices is decreasing rapidly, these adaption effortsbecome the key cost factor in large-scale sensor network system. 24
  • 25. The approach to solve this issue: the concept of Sensor Interface Descriptors, an extension ofOGC SWEs Sensor Model Language, to describe the sensor protocol of a particular sensortype in a declarative way.By means of a generic SID interpreter the native sensor protocol can be translated to SWEprotocols. The SID interpreter is independent of a particular sensor technology, and cancommunicate with any sensor whose protocol can be described by a SID. Hence, a repositoryof SID instances allows users to choose an SID instance which then serves as a “driver” tomake the sensor functionality available for the Sensor Web.Current SWE standards do not deal with actual sensor protocols, and the connectionbetween sensors and SWE services is usually established by manually adapting the internalsof 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 indeveloping large-scale systems.To tackle this issue we have developed a model for Sensor Interface Descriptors (SID) whichenables the declarative description of sensor interfaces, including the definition of thecommunication protocol, sensor commands, processing steps and metadata association. Themodel is designed as a profile and extension of OGC SWEs Sensor Model Language standard.In this model, a SID is defined in XML for each kind of sensor protocol. SID instances forparticular sensor types can be reused in different scenarios and can be shared among usercommunities. A SID interpreter can be built which translates between various sensorprotocols and SWE protocols, hence closing the described interoperability gap. The SIDinterpreter is independent of any particular sensor technology, and can communicate withany sensor whose protocol can be described by a SID. 25
  • 26. This slide shows a typical SWE deployment scenario.A sensor shall be connected to SWE services (at the top). Usually in between there issome kind of Data Acquisition System, or a sensor network sink.A sensor communicates with the data acquisition system in its specific sensorprotocol over a transmission technology such as ISDN or GSM.So, to integrate this sensor with the SWE services, we developed a SensorMLapplication schema/profile, called Sensor Interface Descriptors, which can be used todescribe the sensor protocol in a declarative way.So what we need is an SID instance for the sensor. Then, based on the SID schemaone can build sensor technology independent SID interpreters, which run on the DASand uses the SID to translate the protocol the SWE world.The SID interpreter registers a sensor at a SWE service and uploads sensor data toSOS or SAS (or SES) and is responsible for the opposite communication direction andforwards tasks received by an SPS to a sensor. 26
  • 27. 27
  • 28. 28
  • 29. Example for the Seabird SBE 37 sensor 29
  • 30. 30
  • 31. 31
  • 32. 32
  • 33. 33
  • 34. 34
  • 35. Besides the developed SID schema we also have a first SID Interpreterimplementation.It is based on the OSGI framework and hence consists of several pluggable andloosely coupled Bundle components. 35
  • 36. 36
  • 37. 37
  • 38. We are currently developing a graphical tool which helps you in creating SIDs.A draft of this GUI is shown here… 38
  • 39. 39
  • 40. 40
  • 41. 41
  • 42. 42
  • 43. 43
  • 44. 44