Interaction Patterns for Bridging the Gap betweenSensor Networks and the Sensor Web<br />Arne Broering, Theodor Foerster, ...
Motivation<br />Disaster management requires real-time sensor data!<br />On-the-fly integration of (geo)sensors!<br />Arne...
SWE - Functionalities<br />Discovery<br />Sensor Instance Registry<br />Sensor Observable Registry<br />Access<br />Sensor...
Sensor Web Enablement (SWE)<br />http://www.ogcnetwork.net/swe<br />Web Service interfaces  &  data encodings<br />Used to...
Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broe...
Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broe...
Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broe...
Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broe...
Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broe...
Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broe...
Close gap:      Sensor Network –  Sensor Web<br />Ease sensor / service integration<br />Facilitate usage of SWE<br />On-t...
Sensor Bus<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broering@52north....
Sensor Bus<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering  -  broering@52north....
Bus Message Protocol<br />RegServ*<service URL>*<sensor A id><br />RegServ*<service URL>*<sensor B id><br />...<br />Servi...
Sensor Bus - Twitter<br />SPS<br />SOS<br />SWE<br />SWE<br />DB<br />Config<br /><ul><li> Account
 Sensors</li></ul>Config<br /><ul><li> Account
 Sensors</li></ul>Service<br />Adapter<br />Service<br />Adapter<br />1. PubTask<br />2. TaskParam 10 min<br />...<br />x....
 Feature
 Property
 ...</li></ul>Config<br /><ul><li> Account
 Services</li></ul>Arne Broering  -  broering@52north.org<br />
Sensor Bus - Twitter<br />Pros:<br />Managed scalability<br />Managed reliability<br />Managed security<br />Cons:<br />Li...
SAS<br />SIR<br />SOS<br />SWE<br />SWE<br />SWE<br />Service<br />Adapter<br />Service<br />Adapter<br />Service<br />Ada...
Outlook<br />Evaluate different implementations<br />Twitter, XMPP, IRC, JMS, ...<br />Develop mechanisms for sensor plug ...
Questions?<br />Thank you!<br />Arne Broering<br />broering@52north.org<br />Sensor Web community:		http://52north.org/swe...
SOS<br />
RESTful SOS<br />Observation retrieval:<br />GET http://sos / offering / sensor / feature / property / begin / end / forma...
RESTful SPS<br />Task submission:<br />POST http://ws.spotimage.com/sps/offerings/spot5/tasks<br />Carrying an XML descrip...
Sensor Bus overview<br />
Sensor Bus - Overview<br />
Problem: On-the-fly Integration<br />Rieselfelder<br />
Sensor Interface Description (SID)<br />Sensor Bus<br />Bus Protocol<br />Bus Protocol<br />Bus Protocol<br />Data Acquisi...
Sensor Integration Tools<br />
Message Bus Pattern<br />(1) common communication infrastructure<br />(2) shared set of adapter interfaces<br />(3) well-d...
Upcoming SlideShare
Loading in …5
×

Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010

2,414 views

Published on

Published in: Education
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total views
2,414
On SlideShare
0
From Embeds
0
Number of Embeds
461
Actions
Shares
0
Downloads
0
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide
  • The focus of the Sensor Web (-&gt; 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
  • 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.
  • 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.
  • 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.
  •  Mit unserem SensorBus approach müssen nur noch einmal Plugins für jeden Sensor und jeden Service geschrieben werden.
  • Dies erleichtert die Integration neuer Sensoren ungemein
  • Discovery?
  • 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
  • By taking a use case from disaster management, we outline the challenges and demonstrate how semantically annotated SWE data models and service interfaces support semantic matching.A fast extending blaze at the waste dump of Muenster in Germany causes a dispersion of pollutants into the air. The air pollutants threaten an important European bird reserve, the so called Rieselfelder, and the surrounding settlements. In our scenario, mobile sensors are deployed to monitor air pollutants, wind speed, and wind direction. We assume that a local Sensor Web is already in place and used by a disaster relief organization. The newly deployed sensors have to be made available within the SensorWeb on-the-fly. Applications can directly utilize the gathered observations to get an overview of the situation and for dispersion simulations. Additionally, we assume that the sensors used in this gas plume scenarioare accompanied by a SensorML self-description provided by its vendor or manufacturer.Such a scenario is typical for Sensor Web use cases as it covers two important tasks at the same time - device discovery (e.g., which sensors are necessary to monitor the gas plume) and data discovery (e.g., which data can be used to compute the dispersion of the gas plume).
  • Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010

    1. 1. Interaction Patterns for Bridging the Gap betweenSensor Networks and the Sensor Web<br />Arne Broering, Theodor Foerster, Simon Jirka<br />Web of Things Workshop, March 29th, 2010<br />
    2. 2. Motivation<br />Disaster management requires real-time sensor data!<br />On-the-fly integration of (geo)sensors!<br />Arne Broering - broering@52north.org<br />
    3. 3. SWE - Functionalities<br />Discovery<br />Sensor Instance Registry<br />Sensor Observable Registry<br />Access<br />Sensor Observation Service<br />Tasking<br />Sensor Planning Service<br />Eventing / Alerting<br />Sensor Alert Service<br />Sensor Event Service<br />SIR<br />SOR<br />SOS<br />SPS<br />SAS<br />SES<br />Arne Broering - broering@52north.org<br />
    4. 4. Sensor Web Enablement (SWE)<br />http://www.ogcnetwork.net/swe<br />Web Service interfaces & data encodings<br />Used to build a Sensor Web<br />Integration of (geo)sensors on application level<br />Arne Broering - broering@52north.org<br />
    5. 5. Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    6. 6. Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    7. 7. Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    8. 8. Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    9. 9. Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    10. 10. Problem: Conceptual Gap<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    11. 11. Close gap: Sensor Network – Sensor Web<br />Ease sensor / service integration<br />Facilitate usage of SWE<br />On-the-fly integration (plug & play) of sensors<br />Objectives<br />Arne Broering - broering@52north.org<br />
    12. 12. Sensor Bus<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    13. 13. Sensor Bus<br />Application Layer<br />Sensor Web Layer<br />Sensor Network Layer<br />Arne Broering - broering@52north.org<br />
    14. 14. Bus Message Protocol<br />RegServ*<service URL>*<sensor A id><br />RegServ*<service URL>*<sensor B id><br />...<br />Service Registration<br />Sensor Registration<br />Data Publication<br />Sensor Tasking<br />Status Update<br />IntroSen*<sensor id>*<description URL><br />PubData*<sensor id>*<time>*<property>*<data><br />PubTask*<sensor id>*<task id><br />TaskParam*<task id>*<param 1>*<value 1><br />...<br />DoTask*<task id><br />SenStatus*<sensor id>*<property>*<value><br />Arne Broering - broering@52north.org<br />
    15. 15. Sensor Bus - Twitter<br />SPS<br />SOS<br />SWE<br />SWE<br />DB<br />Config<br /><ul><li> Account
    16. 16. Sensors</li></ul>Config<br /><ul><li> Account
    17. 17. Sensors</li></ul>Service<br />Adapter<br />Service<br />Adapter<br />1. PubTask<br />2. TaskParam 10 min<br />...<br />x. DoTask<br />1. IntroSen<br />2. PubData 30°<br />3. PubData 45°<br />...<br />Sensor<br />Adapter<br />SensorML<br /><ul><li> Position
    18. 18. Feature
    19. 19. Property
    20. 20. ...</li></ul>Config<br /><ul><li> Account
    21. 21. Services</li></ul>Arne Broering - broering@52north.org<br />
    22. 22. Sensor Bus - Twitter<br />Pros:<br />Managed scalability<br />Managed reliability<br />Managed security<br />Cons:<br />Limited Tweet length (140 characters) <br />Limited update rate of search index<br />Max 150 requests per hour (20.000 if whitelisted)<br />Max 1.000 Tweets a day<br />Arne Broering - broering@52north.org<br />
    23. 23. SAS<br />SIR<br />SOS<br />SWE<br />SWE<br />SWE<br />Service<br />Adapter<br />Service<br />Adapter<br />Service<br />Adapter<br />Sensor Bus - XMPP<br />Chatroom<br />Sensor<br />Adapter<br />Arne Broering - broering@52north.org<br />
    24. 24. Outlook<br />Evaluate different implementations<br />Twitter, XMPP, IRC, JMS, ...<br />Develop mechanisms for sensor plug & play<br />Apply to real world use cases<br />www.etamax.de<br />www.G-WaLe.de<br />Sensor<br />Adapter<br />Sensor Interface Description<br />(SensorML)<br />Arne Broering - broering@52north.org<br />
    25. 25. Questions?<br />Thank you!<br />Arne Broering<br />broering@52north.org<br />Sensor Web community: http://52north.org/swe<br />Sensor Bus project: http://52north.org/sensorBus<br />Sensor Web lab: http://swsl.uni-muenster.de<br />
    26. 26. SOS<br />
    27. 27. RESTful SOS<br />Observation retrieval:<br />GET http://sos / offering / sensor / feature / property / begin / end / format<br />Demo link:<br />http://v-swe.uni-muenster.de:8080/52n-OXF-WS/RESTful/sos/<br />
    28. 28. RESTful SPS<br />Task submission:<br />POST http://ws.spotimage.com/sps/offerings/spot5/tasks<br />Carrying an XML description of task<br />Task status:<br />GET http://ws.spotimage.com/sps/offerings/spot5/tasks/002342/status.xml<br />Task control:<br />PUT http://ws.spotimage.com/sps/offerings/spot5/tasks/002342/command<br />e.g.: <command>cancel</command><br />
    29. 29. Sensor Bus overview<br />
    30. 30. Sensor Bus - Overview<br />
    31. 31. Problem: On-the-fly Integration<br />Rieselfelder<br />
    32. 32. Sensor Interface Description (SID)<br />Sensor Bus<br />Bus Protocol<br />Bus Protocol<br />Bus Protocol<br />Data Acquision PC<br />Data Acquision PC<br />Data Acquision PC<br />SID Interpreter<br />SID Interpreter<br />SID Interpreter<br />SensorML<br />SensorML<br />SensorML<br />USB<br />TCP/IP<br />FTP / JDBC<br />Sensor Network<br />Gateway<br />Sensor Files / DB<br />Sensor <br />Zigbee<br />S1<br />S3<br />S2<br />Sensor <br />S5<br />S4<br />
    33. 33. Sensor Integration Tools<br />
    34. 34. Message Bus Pattern<br />(1) common communication infrastructure<br />(2) shared set of adapter interfaces<br />(3) well-defined message protocol<br />Hohpe & Woolf. Enterprise integration patterns: Designing, building, and deploying messaging solutions. Addison-Wesley Longman Publishing, Boston, MA, USA, 2003.<br />
    35. 35. Service Registration<br />
    36. 36. Sensor Registration<br />
    37. 37. Discovery<br />
    38. 38. Data Publication<br />
    39. 39. Sensor Tasking<br />
    40. 40. GetCapabilities<br />SES<br />DescribeSensor<br />GetCurrentMessage<br />(WS-BaseNotification)<br />RegisterPublisher<br />(WS-BrokeredNotification)<br />RegSen<br />Subscribe<br />(WS-BaseNotification)<br />RegServ<br />Service<br />Adapter<br />Publisher endpoint<br />Topic<br />SensorML<br />Filter<br />Subscriber endpoint<br />Sensor<br />Adapter<br />Unsubscribe<br />(WS-BaseNotification)<br />Notify<br />(WS-BaseNotification)<br />Renew<br />(WS-BaseNotification)<br />Producer reference<br />Topic<br />Message<br />PubData<br />Notify<br />(WS-BaseNotification)<br />NotificationConsumer<br />(WS-BaseNotification)<br />Client<br />(e.g. SOS)<br />PauseSubscription<br />(WS-BaseNotification)<br />ResumeSubscription<br />(WS-BaseNotification)<br />RenewRegistration<br />(WS-BrokeredNotification)<br />DestroyRegistration<br />(WS-BrokeredNotification)<br />CreatePullPoint<br />(WS-BaseNotification)<br />GetMessages<br />(WS-BaseNotification)<br />DestroyPullPoint<br />(WS-BaseNotification)<br />

    ×