Download - CEOS WGISS 28 Meeting, Pretoria, September 2009 Wyn Cudlip BNSC/GeoSeren Presentation to WGISS28 Pretoria, September 2009 Experiences with SWE [email protected].

CEOS WGISS 28 Meeting, Pretoria, September 2009

Wyn Cudlip BNSC/GeoSeren

Presentation toWGISS28

Pretoria, September 2009

Experiences with SWE

[email protected]


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


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


SWE Node Configurations


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 1Viewer

Agency 2

‘Sensors’ assigned to (multiple) groups

Agency 1

Agency 2

Field Trial


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)


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