220 likes | 424 Views
Open Geospatial Consortium (OGC) Sensor Web Enablement Rocket City Geospatial Conference Huntsville, AL October 24, 2007. Dr. Mike Botts mike.botts@uah.edu Principal Research Scientist University of Alabama in Huntsville. OpenGeospatial Consortium (OGC). Open Geospatial Consortium.
E N D
Open Geospatial Consortium (OGC)Sensor Web Enablement Rocket City Geospatial ConferenceHuntsville, ALOctober 24, 2007 Dr. Mike Botts mike.botts@uah.edu Principal Research Scientist University of Alabama in Huntsville
Open Geospatial Consortium • The Open Geospatial Consortium, Inc (OGC) is an international industry consortium of 334+ companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications and encodings. • Open Standards development by consensus process • Interoperability Programs provide end-to-end implementation and testing before spec approval • Standard encodings (e.g. GML, SensorML, O&M, etc.) • Geography Markup Language (GML) – Version 3.2 • Style Layer Description language (SLD) • SensorML • Observations and Measurement (O&M) • Standard Web Service interfaces; e.g.: • Web Map Service (WMS) • Web Feature Service (WFS) • Web Coverage Service (WCS) • Catalog Service • Open Location Services – used by communications and navigation industry • Sensor Web Enablement Services (SOS, SAS, SPS)
Basic Desires • Quicklydiscover sensors and sensor data (secure or public) that can meet my needs – location, observables, quality, ability to task • Obtain sensor information in a standard encoding that is understandable by me and my software • Readily access sensor observations in a common manner, and in a form specific to my needs • Task sensors, when possible, to meet my specific needs • Subscribe to and receive alerts when a sensor measures a particular phenomenon
Sensor Web Vision -1- • Sensors will be web accessible • Sensors and sensor data will be discoverable • Sensors will be self-describing to humans and software (using a standard encoding) • Most sensor observations will be easily accessible in real time over the web
Sensor Web Vision -2- • Standardized web services will exist for accessing sensor information and sensor observations • Sensor systems will be capable of real-time mining of observations to find phenomena of immediate interest • Sensor systems will be capable of issuing alerts based on observations, as well as be able to respond to alerts issued by other sensors
Sensor Web Vision -3- • Software will be capable of on-demand geolocation and processing of observations from a newly-discovered sensor without a priori knowledge of that sensor system • Sensors, simulations, and models will be capable of being configured and tasked through standard, common web interfaces • Sensors and sensor nets will be able to act on their own (i.e. be autonomous)
Heterogeneous sensor network Airborne Satellite Decision Support Tools In-Situ monitors Bio/Chem/Rad Detectors Surveillance • sparse • disparate • mobile/in-situ • extensible Sensor Web Enablement • discovery • access • tasking • alert notification web services and encodings based on Open Standards (OGC, ISO, OASIS, IEEE) Models and Simulations • nested • national, regional, urban • adaptable • data assimilation • vendor neutral • extensive - flexible • adaptable Sensor Web Enablement Framework M. Botts -2004
Integration Of ObservationsFrom A Variety Of Sensors We desire the ability to discover and integrate observations from any sensor that meets our needs
Background -1- OGC Web Services Testbed 1.2: • Sponsors: EPA, General Dynamics, NASA, NIMA • Specs: SOS, O&M, SensorML, SPS, WNS • Demo: Terrorist, Hazardous Spill and Tornado • Sensors: weather stations, wind profiler, video, UAV, stream gauges • Specs advanced through independent R&D efforts in Germany, Australia, Canada and US • Sensor Web Work Group established • Specs: SOS, O&M, SensorML, SPS, WNS, SAS • Sensors: wide variety OGC Web Services Testbed 1.1: • Sponsors: EPA, NASA, NIMA • Specs: SOS, O&M, SensorML • Demo: NYC Terrorist • Sensors: weather stations, water quality SensorML initiated at University of Alabama in Huntsville: NASA AIST funding 1999 - 2000 2001 2002 2003-2004
Background -2- OGC Web Services Testbed 3.0: • Sponsors: NGA, ORNL, LMCO, BAE • Specs: SOS, O&M, SensorML, SPS, TransducerML • Demo: Forest Fire in Western US • Sensors: weather stations, wind profiler, video, UAV, satellite SAS Interoperabilty Experiment OGC Web Services Testbed 4.0: • Sponsors: NGA, NASA, ORNL, LMCO • Specs: SOS, O&M, SensorML, SPS, TransducerML, SAS • Demo: Emergency Hospital • Sensors: weather stations, wind profiler, video, UAV, satellite SWE Specifications toward approval: SensorML – V0.0 TransducerML – V0.0 SOS – V0.0 SPS – V0.0 O&M – Best Practices SAS – Best Practices 2005 2006
SWE Specifications • Information Models and Schema • Sensor Model Language (SensorML) for In-situ and Remote Sensors - Core models and schema for observation processes: support for sensor components, georegistration, response models, post measurement processing • Observations and Measurements (O&M) – Core models and schema for observations • TransducerML – adds system integration and multiplex streaming clusters of observations • Web Services • Sensor Observation Service - Access Observations for a sensor or sensor constellation, and optionally, the associated sensor and platform data • Sensor Alert Service – Subscribe to alerts based upon sensor observations • Sensor Planning Service – Request collection feasibility and task sensor system for desired observations • Web Notification Service –Manage message dialogue between client and Web service(s) for long duration (asynchronous) processes • Sensor Registries – Discover sensors and sensor observations
OGC Sensor Web Enablement -4- • Sensor Web Enablement – Potential Harmonizations • OASIS Common Alert Protocol (CAP) – being considered as standard encoding of sensor alerts in SAS • OASIS EDXL – XML “envelope” for alerts • IEEE P1451 – provides “plug-n-play” capabilities for sensors; looking at complimentary interaction between 1451, SensorML, and the SWE Framework
Status • Current specs are in various stages • SensorML – Version 1.0 • TransducerML – Version 1.0 • Observations & Measurement – In 60 day final vote • WNS – Request for Comments • SOS – Version 1.0 • SPS – Version 1.0 • SAS – Request for Comments • OGC Web Services (OWS) include thread for Sensor Web Enablement • 5.0 phase I and II: July 2007 to January 2007
Known Open Source Software • 52 North • SWE Common parser/writer • Full suite of SWE services (SOS, SPS, SAS) • University of Alabama in Huntsville • SWE Common parser/writer • SensorML parser • process chain executor and process model library • editors for SensorML/O&M instances and profiles – in progress • Space Time Toolkit SWE client • SOS/WCS services • Texas A&M / Marine Metadata Initiative • Non ebRIM registry based on ontology • light weight clients • Several services • MapServer / GDAL • SWE services incorporated into MapServer • GeoBlinky • Several components used with the EO1 SAT activities • Northrop Grumman • Several components used within the PulseNet activity There is an initiative to begin to look at joint development and management of Open Source SWE software
A Few Example Activities using SWE • Community Sensor Models (NGA) – SensorML encoding of the CSM; CSM likely to be the ISO19130 standard for sensor models • Multi-INT Metadata Standards (DIA) – Committed to SensorML and SWE as future direction • OGC OWS5.1Georeferenceable Imagery (NGA/NASA) – will be demonstrating use of SensorML within JPEG2000 and JPIP for support of geolocation of streaming imagery • Oak Ridge National Labs SensorNet – funded project will be adding SensorML and SWE support in SensorNet nodes for threat monitoring • Northrop Grumman IRAD (PulseNet) – demonstrated end-to-end application of SensorML/SWE for legacy surveillance and MASINT sensors in field • Empire Challenge (NGA) – planning to utilize SensorML and SWE for sensor observation processing and integration in 2008 testbed • European Space Agency – developing SensorML profiles for supporting sensor discovery and processing within the European satellite community; implementing SWE services • Canadian GeoConnections Projects – used SensorML and SWE in water monitoring network • Hurricane Missions (NASA MSFC) – using SensorML for geolocation and processing of satellite and airborne sensors; implementing SWE services for satellite, airborne, and ground-based sensors • Sensors Anywhere (SAny) – intending to use SensorML/SWE within large European sensor project • NASA ESTO – funded 30 3-year projects on Sensor Webs; 5 SBIR topics with SensorML and Sensor Web called out
SensorML Geolocation examples AMSR-E SSM/I TMI & MODIS footprints MAS TMI Geolocation of satellite and airborne sensors using SensorML Cloudsat LIS
Previous OGC OWS Testbeds: SensorML-Enabled Discovery and Georeferencing Weather LaPlata Tornado UAV for Fire Detection Radiation plumesand weather
PulseNet: SensorML/SWE-Enabled Discovery, Data Access, and Tasking Credit: Northrop Grumman PulseNet Project
Relevant Links Open Geospatial Consortium http://www.opengeospatial.org Sensor Web Enablement Working Group http://www.opengeospatial.org/projects/groups/sensorweb SensorML information http://vast.uah.edu/SensorML SensorML Public Forum http://mail.opengeospatial.org/mailman/listinfo/sensorml