Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010
•
5 recomendaciones•1,501 vistas
Recomendados
Más contenido relacionado
Destacado
Similar a Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010
Similar a Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010 (20)
Más de Arne Bröring
Más de Arne Bröring (15)
Último
Último (20)
Broering - Bridging Sensor Networks and Sensor Webs @ WOT2010
- 1. Interaction Patterns for Bridging the Gap betweenSensor Networks and the Sensor Web Arne Broering, Theodor Foerster, Simon Jirka Web of Things Workshop, March 29th, 2010
- 2. Motivation Disaster management requires real-time sensor data! On-the-fly integration of (geo)sensors! Arne Broering - broering@52north.org
- 3. SWE - Functionalities 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 Arne Broering - broering@52north.org
- 4. 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 Arne Broering - broering@52north.org
- 5. Problem: Conceptual Gap Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 6. Problem: Conceptual Gap Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 7. Problem: Conceptual Gap Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 8. Problem: Conceptual Gap Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 9. Problem: Conceptual Gap Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 10. Problem: Conceptual Gap Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 11. Close gap: Sensor Network – Sensor Web Ease sensor / service integration Facilitate usage of SWE On-the-fly integration (plug & play) of sensors Objectives Arne Broering - broering@52north.org
- 12. Sensor Bus Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 13. Sensor Bus Application Layer Sensor Web Layer Sensor Network Layer Arne Broering - broering@52north.org
- 14. 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> Arne Broering - broering@52north.org
- 18. Feature
- 19. Property
- 21. ServicesArne Broering - broering@52north.org
- 22. 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 Arne Broering - broering@52north.org
- 23. SAS SIR SOS SWE SWE SWE Service Adapter Service Adapter Service Adapter Sensor Bus - XMPP Chatroom Sensor Adapter Arne Broering - broering@52north.org
- 24. 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) Arne Broering - broering@52north.org
- 25. Questions? Thank you! Arne Broering broering@52north.org Sensor Web community: http://52north.org/swe Sensor Bus project: http://52north.org/sensorBus Sensor Web lab: http://swsl.uni-muenster.de
- 26. SOS
- 27. RESTful SOS Observation retrieval: GET http://sos / offering / sensor / feature / property / begin / end / format Demo link: http://v-swe.uni-muenster.de:8080/52n-OXF-WS/RESTful/sos/
- 28. RESTful SPS Task submission: POST http://ws.spotimage.com/sps/offerings/spot5/tasks Carrying an XML description of task Task status: GET http://ws.spotimage.com/sps/offerings/spot5/tasks/002342/status.xml Task control: PUT http://ws.spotimage.com/sps/offerings/spot5/tasks/002342/command e.g.: <command>cancel</command>
- 30. Sensor Bus - Overview
- 31. Problem: On-the-fly Integration Rieselfelder
- 32. Sensor Interface Description (SID) Sensor Bus Bus Protocol Bus Protocol Bus Protocol Data Acquision PC Data Acquision PC Data Acquision PC SID Interpreter SID Interpreter SID Interpreter SensorML SensorML SensorML USB TCP/IP FTP / JDBC Sensor Network Gateway Sensor Files / DB Sensor Zigbee S1 S3 S2 Sensor S5 S4
- 34. Message Bus Pattern (1) common communication infrastructure (2) shared set of adapter interfaces (3) well-defined message protocol Hohpe & Woolf. Enterprise integration patterns: Designing, building, and deploying messaging solutions. Addison-Wesley Longman Publishing, Boston, MA, USA, 2003.
- 37. Discovery
- 38. Data Publication
- 39. Sensor Tasking
- 40. GetCapabilities SES DescribeSensor GetCurrentMessage (WS-BaseNotification) RegisterPublisher (WS-BrokeredNotification) RegSen Subscribe (WS-BaseNotification) RegServ Service Adapter Publisher endpoint Topic SensorML Filter Subscriber endpoint Sensor Adapter Unsubscribe (WS-BaseNotification) Notify (WS-BaseNotification) Renew (WS-BaseNotification) Producer reference Topic Message PubData Notify (WS-BaseNotification) NotificationConsumer (WS-BaseNotification) Client (e.g. SOS) PauseSubscription (WS-BaseNotification) ResumeSubscription (WS-BaseNotification) RenewRegistration (WS-BrokeredNotification) DestroyRegistration (WS-BrokeredNotification) CreatePullPoint (WS-BaseNotification) GetMessages (WS-BaseNotification) DestroyPullPoint (WS-BaseNotification)
Notas del editor
- The 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
- 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).