1 / 22

OSCAR Sensor Web Enablement Prototype

OSCAR Sensor Web Enablement Prototype. Presentation to WGISS-24 October 2007. Paul Martin ComSine Limited paulm@comsine.co.uk. Introduction. OSCAR – “On-Line Sensor Control & Access Resource”

ratana
Download Presentation

OSCAR Sensor Web Enablement Prototype

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. OSCARSensor Web Enablement Prototype Presentation to WGISS-24October 2007 Paul Martin ComSine Limited paulm@comsine.co.uk

  2. Introduction • OSCAR – “On-Line Sensor Control & Access Resource” • Project under the BNSC Internal Co-operation Program that funds a number of small “Exploitation Projects” • Aimed at allowing UK companies to exploit and contribute to international activities • Completed in October 2007

  3. OSCAR Concept

  4. Project Objectives • Work with real-world user partners to understand their requirements and determine focus of the project • Build a UK software resource that supports the major aspects of the OGC Sensor Web Enablement specifications • Look at the role satellite communications can play in a Sensor Web architecture • Provide a live demonstration of the OSCAR framework

  5. User Partners • Critical Software • Portuguese software development company • Sensor Web interests: Operational services for fire hazards • Hidromod • Portuguese technical consulting company • Sensor Web interests: Monitoring coastal waters • UK Environment Agency • Already operating and extensive network of in-situ sensors • Sensor Web interests: A need to promote high-level access to their sensors • Satamatics • UK Satellite Communications Company • Suppliers of terminal operating under Inmarsat D+ • Sensor Web interests: Oil pipeline monitoring

  6. Partner Requirements Feedback • Each sees a need for deploying sensors in remote areas with limited or no terrestrial communications coverage. • Open standards are an important aspect for their business in both “sharing information and reducing the time-to-market” for their products. • They identified the need to gain high-level access to their sensors as critical. • The ability of remotely monitor and control their sensors would enable their business to run more efficiently • In support of efforts such as GMES (Global Monitoring for Environment and Security), adopting standards to provide alerts on environmental conditions is critical

  7. What We Planned to Build • 2 Sensor Nodes (one in UK, one in Australia) • Each node will host a representative set of weather station sensors • Australia Node will use Satellite Communications over the Inmarsat D+ service • UK Node will be directly connected to the Internet via WAN/LAN • Implement a subset of the O&M and SensorML XML encodings • Describe both sensors and their observations • Implement the major elements of the SOS, SAS and WNS web services • Obtain sensor descriptions and sensor observations • Register to receive alerts for “alarming conditions” from a sensor

  8. OGC SWE Components • Observations & Measurements (O&M) • XML Encoding compliant with OGC Best Practices Document 05-087r4 • Subset of the encoding to handle the following observations: • Temperature, Rainfall, Wind Speed/Direction, Humidity, Air Pressure • Sensor Modelling Language (SensorML) • XML Encoding compliant with OGC Implementation Specification 05-086r2 • Subset of the encoding to describe the following sensor: • Weather Station (TechnoLine WS-2300)

  9. OGC SWE Components • Sensor Observation Service (SOS) • XML Encoding compliant with OGC Implementation Specification 06-009r1 • A web service for describing Sensors and obtaining their Observations

  10. OGC SWE Components • Sensor Alert Service (SAS) • XML Encoding compliant with OGC Discussion Paper 06-028 • A web service that allows a sensor to be monitored for an “alarming condition”, e.g. temperature exceeds a given value • A user may subscribe to receive alerts

  11. OGC SWE Components • Web Notification Service (WNS) • XML Encoding compliant with OGC Best Practices Document 06-095 • Web Service for mediating asynchronously between web services, e.g. Confirmation of a SPS tasking request issuing an alert from an SAS when an “alarming condition” occurs

  12. System Context • Sensor Node • Laptop PC with Weather Station and WebCam sensors attached via RS-232 or USB • A Data Logger will record observations from sensors at a pre-defined interval • Periodically the Sensor Node will send observations via some communications protocol to the OSCAR Server Data Repository • Communications via SATCOM and Internet will be demonstrated

  13. System Context contd • OSCAR Server • The OSCAR Server will periodically scan the Data Repository for new observations • The Data Loader will load new observations into Data Storage • Data Storage will store observations using SWE O&M • Data Storage will also store description of the sensor using SWE SensorML

  14. System Context contd • OSCAR SWE and Client • A set of OGC SWE compliant web services accessible over the internet • Sensor Observation Service - obtain O&M and SensorML • Sensor Alert Service - Monitor sensors for “alarming conditions” • Web Notification Service - alert user of “alarming condition” & mediate with user for planning requests

  15. Satellite Communications • Australian Demo Site • Satamatics SAT-201 terminal via Inmarsat D+ • Sensor Node will load SAT-201 with latest observations • Observations are sent via satellite to the LES • The MHS (gateway) will retrieve messages from the LES • Message Client on the OSCAR Server will use ASPI-XML to look for new observations • New Observations are written to the Data Repository

  16. WAN/LAN Communication • UK Demo Site • Sensor Node connected to the internet via a wired Ethernet connection • New observations will be sent directly over the internet to the Data Repository (e.g. FTP)

  17. Web Services Architecture • O&M and SensorML are stored in a PostGres/PostGIS relational database • Data exposed to upper layers using Java Data Objects (Object Persistence) • Web Service is implemented as Java objects • OGC SWE XML requests and responses are marshalled and un-marshalled into objects using Apache XML Beans (Data Binding) • Client passes XML requests and responses using SOAP over HTTP • Non XML messages handled via Java Servlet, e.g. GetCapabilities

  18. Equipment Setup • Sensor Node (SATCOM) • Weather Station in Torquay, Australia • Observations collected on demand by issuing a Forward Message to the Sensor Node via a SAT-201 terminal over D+ • Observations packaged into OSCAR Data File (ComSine format) to compress data for transmission via a SAT-201 terminal over D+ to the OSCAR Server • Sensor Node (WAN/LAN) • Weather Station in South Warnborough, UK • Observations collected every 10 minute (stored as an OSCAR Data File) • OSCAR Server retrieves observations using an FTP pull

  19. Issues We Experienced • Complete OGC schemas not available at time of development • All schemas were extracted from OGC documentation • There were conflicts in namespaces between the different services • There were conflicts in the use of GML (v3.1 vs 3.2) and other supporting libraries • Sharing of objects between SWE components • In some cases similar object definitions were implemented across server namespaces • E.g. A different FeatureOfInterest object exists for the SOS and the SAS • Standards not yet mature • Each implementation of the standard is at a different stage in the OGC lifecycle • All (except SensorML) are yet to be release as an Implementation Specification at version 1.0

  20. Issues We Experienced • There are some missing links in the process chain • E.g. When you register a new sensor, there is no reference to adding it to an ‘Observation Offering’ via an OGC request • InsertObservation only allows for a single observation to be added per request • This could be a performance bottleneck when a single sensor node wished to communicate several observations • There may be an argument for a batch insert option

  21. On-Line Demonstrator Plans • Weather observations from our UK test site will continue to be uploaded into OSCAR • We plan to modify the Australian test site to the WAN/LAN setup which will also load weather observations into OSCAR • Access to the OSCAR-SWE services will be made available at the following URL • http://81.29.75.200/oscar • Demonstrator will offer access our implementations of the SOS, SAS and WNS services • Very keen to continue work on OSCAR/Sensor Web and would welcome collaboration with others

  22. Who We Are • ComSine is a UK SME with a wholly owned subsidiary in Australia, ComSine Australia PTY Ltd • We specialise software and hardware development in the domains of satellite communications, geographical information, navigation and Earth observation. • Particular expertise in application of OGC standards and development of web services/SOAs • Customers include: ESA, BNSC, the EC, the GSA, Inmarsat, QinetiQ, SEEDA, LogicaCMG, etc.. • Operating from premises in NE Hampshire, UK and Torquay, near Melbourne, Victoria, Australia. • Website - http://www.comsine.co.uk

More Related