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

2. CEOS WGISS 28 Meeting, Pretoria, September 2009 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. CEOS WGISS 28 Meeting, Pretoria, September 2009 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. CEOS WGISS 28 Meeting, Pretoria, September 2009 SWE Node Configurations

5. CEOS WGISS 28 Meeting, Pretoria, September 2009 Roles & Groups for Access Control 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 Solution Problem: Field Trial User 1 Role Agency 1Viewer Controller User 2 Role Agency 1 Viewer Agency 2 ‘Sensors’ assigned to (multiple) groups Agency 1 Agency 2 Field Trial

6. CEOS WGISS 28 Meeting, Pretoria, September 2009 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. CEOS WGISS 28 Meeting, Pretoria, September 2009 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