1 / 7

Experiences with SWE

Experiences with SWE. Presentation to WGISS28 Pretoria, September 2009. Wyn Cudlip BNSC/GeoSeren. wcudlip@geoseren.com. Background. Project underway to develop prototype system for sensor management using Sensor Web Enablement (SWE) Standards from OGC Making use of

fionn
Download Presentation

Experiences with SWE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Experiences with SWE Presentation to WGISS28 Pretoria, September 2009 Wyn Cudlip BNSC/GeoSeren wcudlip@geoseren.com

  2. Background • Project underway to develop prototype system for sensor management using Sensor Web Enablement (SWE) Standards from OGC • Making use of • 52degree North SWE software toolkit • OSCAR SWE software package developed by ComSine (1Spatial) • Monitoring water quality in Dam in the West Country in the UK • In this presentation will concentrate on the issues of: • Definition of a SWE Node • Access control • Accessing sensor information

  3. What is a SWE Node? • A SWE Node is a computing element with an IP address connected to the internet and understands SWE protocols (http) SOS, SAS, SPS, WNS • Could be a desktop PC, Laptop or portable computing device running appropriate software • Internally contains proprietary interface to specific sensor or sensor network • No prescribed method for communicating with sensor. Could use: • RS232; GSM; Radio; Satcom • Therefore, can be varying degrees of complexity within a SWE Node

  4. SWE Node Configurations

  5. Roles & Groups for Access Control Problem: ‘Sensors’ assigned to (multiple) groups • Improved access to the sensor services requires control over user capability • Many users might have read access (SOS) but need to restrict the ability to task a sensor (SPS) • Sensors assigned to different 'Groups' • Users are assigned different Roles for different Groups. E.g 'Viewer' or 'Sensor Controller’ • Attaching a new sensor to a group automatically allows controlled access to that sensor Agency 1 Solution Field Trial Agency 2 User 2 Role User 1 Role Agency 1 Viewer Agency 1 Viewer Agency 2 Controller Field Trial

  6. Observation Identification • Problem: When managing multiple sensing platforms, labelling observations in a meaningful way is difficult. • Usually there is a naming hierarchy: • SWE Node1 (e.g. Tamar Lake Services) (with internet address) • SOS Service1: SAS Service1; SPS Service1 (e.g. Weather information) • Observation Offering1 (e.g. Weather at Dam) • Sensor1 (e.g. Vaisala weather station) • Observable Parameter1 (Feature of interest). (e.g. temperature) • Observable Parameter2 (e.g. Precipitation) • Sensor2 (e.g. YSI Sonde) • Observable Parameter 1 (e.g. Temperature) • ...... • Observation Offering2 (e.g. Camera observation at dam) • ........ • SOS Service2 (e.g. Water Quality) • .... • SWE Node2 (e.g. Tamar River Services) • ........ • SWIMA Solution: Concept of ‘Vstation’ or ‘MySensors’ • Observable parameters (from any SWE Node) identified as a user-defined set. • (see user interface slide for clarification)

  7. Conclusion • 52degree North provide useful toolbox to help SWE implementations • But not yet complete, some bugs and limited documentation • Other implementations becoming available • As access to sensor services becomes easier then more effort with security is required. • Prototyping in real-life situations usually reveal additional issues

More Related