License Agreement
Permission is hereby granted by the Open Geospatial Consortium, Inc. ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
i. SWE Architecture White Paper and OGC contact points
Any questions regarding this document should be directed to the editor or any the following contributors:
|
CONTACT |
COMPANY |
E-Mail ADDRESS |
|
Carl Reed (Editor) |
OGC |
|
|
Mike Botts |
Botts Innovative Research |
mike.botts<at>botts-inc.net |
|
George Percivall |
OGC |
|
|
John Davidson |
Image Matters, LLC |
Please note that there are many other OGC members contributing to the Sensor Web Enablement standards work.
ii. Forward
This white paper provides a high-level overview of and architecture for the Open Geospatial Consortium (OGC) standards activities that focus on sensors, sensor networks, and a concept called the “Sensor Web”. This OGC focus area is known as Sensor Web Enablement (SWE). For readers interested in greater technical and architecture details, please download and read the OGC Best Practice titled “The OGC Sensor Web Enablement Architecture” (OGC document 06-021r4).
Further Reading
Sensor Web Enablement Architecture, OGC 06-021r4, 2008. http://portal.opengeospatial.org/files/?artifact_id=29405
OWS-6 Secure Sensor Web Engineering Report, OGC 08-176r1, 2009. http://portal.opengeospatial.org/files/?artifact_id=34273
SANY Fusion and Modeling Architecture. OGC 10-001, 2010 http://portal.opengeospatial.org/files/?artifact_id=37139
OGC® Sensor Planning Service Interface Standard 2.0 Earth Observation Satellite Tasking ExtensionOGC® Sensor Planning Service (2.0), 2011. http://portal.opengeospatial.org/files/?artifact_id=40185
Earth Observation Metadata profile of Observations & Measurements (1.0), 2011. https://portal.opengeospatial.org/files/?artifact_id=47040
ABSTRACT
This OGC White Paper provides a high-level overview of and architecture for the Open Geospatial Consortium (OGC) standards activities that focus on sensors, sensor networks, and a concept called the “Sensor Web”. This OGC focus area is known as Sensor Web Enablement (SWE).
Keywords
sensor, OGC, “Sensor Web Enablement”, “sensor web”, transducer, geospatial, “web service”, SOA, “service oriented architecture”, imaging, sos, sps, o&m, puck, sensorml.
Introduction
A sensor network is a computer accessible network of many, spatially distributed devices using sensors to monitor conditions at different locations, such as temperature, sound, vibration, pressure, motion or pollutants[1]. A Sensor Web refers to web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application program interfaces (APIs).
In an Open Geospatial Consortium (OGC)[2] initiative called Sensor Web Enablement (SWE), members of the OGC have defined and documented a unique and revolutionary framework of open standards for exploiting Web-connected sensors and sensor systems of all types: flood gauges, air pollution monitors, stress gauges on bridges, mobile heart monitors, Webcams, airborne and satellite-borne earth imaging devices and countless other sensors and sensor systems.
SWE presents many opportunities for adding a real-time sensor dimension to the Internet and the Web. This has a high level of significance for disaster management, environmental monitoring, transportation management, public safety, facility security, utilities’ Supervisory Control And Data Acquisition (SCADA) operations, industrial controls, science, facilities management and many other domains of activity.
The sections below describe the high level SWE architecture, SWE standards, harmonization with other standards such as IEEE 1451, and several use cases.
.
High Level Architecture
The models, encodings, and services of the SWE architecture enable implementation of interoperable and scalable service-oriented networks of heterogeneous sensor systems and client applications. In much the same way that Hyper Text Markup Language (HTML) and Hypertext Transfer Protocol (HTTP) standards enabled the exchange of any type of information on the Web, the OGC’s SWE initiative is focused on developing standards to enable the discovery, exchange, and processing of sensor observations, as well as the tasking of sensor systems. The functionality that OCG has targeted within a sensor web includes:
- Discovery of sensor systems, observations, and observation processes that meet an application’s or user’s immediate needs;
- Determination of a sensor’s capabilities and quality of measurements;
- Access to sensor parameters that automatically allow software to process and geo-locate observations;
- Retrieval of real-time or time-series observations and coverages in standard encodings
- Tasking of sensors to acquire observations of interest;
- Subscription to and publishing of alerts to be issued by sensors or sensor services based upon certain criteria.
Within the SWE initiative, the enablement of such sensor webs and networks is being pursued through the establishment of several encodings for describing sensors and sensor observations, and through several standard interface definitions for web services. Sensor Web Enablement standards that have been built and prototyped by members of the OGC include the following OGC standards:
1. Observations & Measurements Schema (O&M) – An OGC adopted standard that defines conceptual models for encoding observations and measurements from a sensor, both archived and real-time.
2. Observations and Measurements XML (OMXML) – XML encoding of the O&M conceptual model.
3. Sensor Model Language (SensorML) – An OGC adopted standard that defines standard models and XML Schema for describing sensors systems and processes; provides information needed for discovery of sensors, location of sensor observations, processing of low-level sensor observations, and listing of taskable properties.
4. Sensor Observations Service (SOS)- An OGC adopted standard that specifies a standard web service interface for requesting, filtering, and retrieving observations and sensor system information. This is the intermediary between a client and an observation repository or near real-time sensor channel.
5. Sensor Planning Service (SPS) – An OGC adopted standard that specifies standard web service interface for requesting user-driven acquisitions and observations. This is the intermediary between a client and a sensor collection management environment.
6. SWE Common Data Model -The Sensor Web Enablement (SWE) Common Data Model Encoding Standard defines low level data models for exchanging sensor related data between nodes of the OGC® Sensor Web Enablement (SWE) framework. These models allow applications and/or servers to structure, encode and transmit sensor datasets in a self-describing and semantically enabled way.
7. SWE Services Common – This standard currently defines eight packages with data types for common use across OGC Sensor Web Enablement (SWE) services. Five of these packages define operation request and response types. These packages use data types specified in other standards.
8. PUCK Protocol Standard- This standard defines a protocol for RS232 and Ethernet connected instruments. PUCK addresses installation and configuration challenges for sensors by defining a standard instrument protocol to store and automatically retrieve metadata and other information from the instrument device itself. PUCK is the newest addition to the SWE standards suite.
9. Sensor Alert Service (SAS) – An OGC Discussion paper describing a web service interface for publishing and subscribing to alerts from sensors. This is not an OGC standard.
10. Web Notification Services (WNS) – Standard web service interface for asynchronous delivery of messages or alerts from SAS and SPS web services and other elements of service workflows. This is not an OGC standard.
The goal of SWE is to enable all types of Web and/or Internet-accessible sensors, instruments, and imaging devices to be accessible and, where applicable, controllable via the Web. The vision is to provide a standards foundation for “plug-and-play” Web-based sensor networks. Sensor location is usually a critical parameter for sensors on the Web, and OGC is the world’s leading geospatial industry standards organization. Therefore, SWE standards have been harmonized with other OGC standards for geospatial processing. The SWE standards foundation also references other relevant sensor and alerting standards such as the IEEE 1451 “smart transducer” family of standards (see page 8) and the OASIS Common Alerting Protocol (CAP), Web Services Notification (WS-N) and Asynchronous Service Access Protocol (ASAP) specifications. OGC works with the groups responsible for these standards to harmonize them with the SWE specifications.
Advances in digital technology are making it practical to enable virtually any type of sensor or locally networked sensor system with wired or wireless connections. Such connections support remote access to the devices’ control inputs and data outputs as well as their identification and location information. For both fixed and mobile sensors, sensor location is often a vital sensor parameter. A variety of location technologies such as GPS and Cell-ID with triangulation make mobile sensing devices capable of reporting their geographic location along with their sensor-collected data.
When the network connection is layered with Internet and Web protocols, eXtensible Markup Language (XML) schemas can be used to publish formal descriptions of the sensor’s capabilities, location, and interfaces. Then Web brokers, clients and servers can parse and interpret the XML data, enabling automated Web-based discovery of the existence of sensors and evaluation of their characteristics based on their published descriptions. The information provided also enables applications to geolocate and process sensor data without requiring a priori knowledge of the sensor system.
Information in the XML schema about a sensor’s control interface enables automated communication with the sensor system for various purposes: to determine, for example, its state and location; to issue commands to the sensor or its platform; and, to access its stored or real-time data. A Web-based application might communicate with the sensor system through a proprietary or custom interface or through an interface that implements the IEEE 1451 standard. An object-oriented approach to sensor and data description also provides a very efficient way to generate comprehensive standard-schema metadata for data produced by sensors, facilitating the discovery and interpretation of data in distributed archives.
The SWE Standards Framework
Below we describe each of the seven SWE standards. All of these documents have been approved as official OGC standards using the OGC’s formal standards adoption process. These standards are all available free of charge.
In this paper we also describe other standards that are important in Sensor Webs.
Starting with the OGC Web Service Testbed Initiative 3.0, Sensor Web Enablement has been and continues to be a main topic in OGC Web Services Interoperability Initiatives Based on interoperability experiments performed in the testbeds, number of SWE oriented OGC Engineering Reports have been written and are available on the OGC public web site.
Professional videos developed by WNET, the OGC, and OGC members demonstrates the OGC member work on interoperability and sensors accomplished during OWS-3 and OWS-4 (http://video.google.com/videoplay?docid=-7153530463394016693&q=OGC&pl=true ).
Observations and Measurements OGC Abstract Specification Topic 20 (2010)
The OGC Observations and Measurements (O&M) standard [OGC 10-004r3] provides a standard conceptual model for representing and exchanging observation results. O&M provides standard constructs for accessing and exchanging observations, alleviating the need to support a wide range of sensor-specific and community-specific data formats. O&M 2.0 was approved by the OGC Members as a standard in late 2010. In early 2010, the document was also approved by the ISO TC211 Members as an ISO Standard.
O&M establishes a high-level framework for representing observations, measurements, procedures and metadata of sensor systems and is required by the Sensor Observation Service Implementation Standard, for implementation of SWE-enabled architectures, and for general support for OGC standards compliant systems dealing in technical measurements in science and engineering.
As defined within the O&M standard, an Observation is an event with a result that has a value describing some phenomenon. The observation is modeled as a Feature within the context of the ISO/OGC General Feature Model. An observation feature binds the result to the feature of interest, upon which it was made. An observation uses a procedure to determine the value, which may involve a sensor or observer, analytical procedure, simulation or other numerical processes.
Observations and Measurements XML (OMXML) 2.0 (2011)
This standard specifies an XML implementation for the OGC and ISO Observations and Measurements (O&M) conceptual model (OGC Observations and Measurements v2.0also published as ISO/DIS 19156), including a schema for Sampling Features. OMXML is document OGC 10-025r1.
More specifically, this standard defines XML schemas for observations, and for features involved in sampling when making observations. These provide document models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities.
OMXML is referenced by other OGC standards. For example, this encoding is an essential dependency for the OGC Sensor Observation Service (SOS) Interface Standard.
SWE Common Data Model Encoding Standard 2.0 (2011)
The primary focus of the SWE Common Data Model is to define and package sensor related data in a self-describing and semantically enabled way. The main objective is to achieve interoperability, first at the syntactic level, and later at the semantic level (by using ontologies and probably semantic mediation) so that sensor data can be better understood by machines, processed automatically in complex workflows and easily shared between intelligent sensor web nodes.
This standard is a revision of content that was previously integrated to the SensorML standard (OGC 07-000). These common data models are now defined in a separate document that is referenced by other OGC® SWE encoding and service standards.
More precisely, the SWE Common Data Model is used to define the representation, nature, structure and encoding of sensor related data.
The SWE Common Data Model is intended to be used for describing static data (files) as well as dynamically generated datasets (on the fly processing), data subsets, process and web service inputs and outputs and real time streaming data. All categories of sensor observations are in scope ranging from simple in-situ temperature data to satellite imagery and full motion video streamed out of an aircraft.
The SWE Common language is an XML implementation of this model and is used by other existing OGC® Sensor Web Enablement standards such as Sensor Model Language (SensorML), Sensor Observation Service (SOS), Sensor Alert Service (SAS) and Sensor Planning Service (SPS). The Observations and Measurements Standard (O&M) also references the SWE Common data model, although the observation model defined in the O&M specification is decoupled from this standard. One goal of the SWE Common Data Model is thus to maintain the functionality required by all these related standards.
SWE Service Model 2.0 (2011)
This SWE Service Model standard [OGC 09-001] currently defines eight packages with data types for common use across OGC Sensor Web Enablement (SWE) services. Five of these packages define operation request and response types. The packages are: 1.) Contents – Defines data types that can be used in specific services that provide (access to) sensors; 2.) Notification – Defines the data types that support provision of metadata about the notification capabilities of a service as well as the definition and encoding of SWES events; 3.) Common - Defines data types common to other packages; 4.) Common Codes –Defines commonly used lists of codes with special semantics; 5.) DescribeSensor – Defines the request and response types of an operation used to retrieve metadata about a given sensor; 6.) UpdateSensorDescription –Defines the request and response types of an operation used to modify the description of a given sensor; 7.) InsertSensor – Defines the request and response types of an operation used to insert a new sensor instance at a service; 8.) DeleteSensor – Defines the request and response types of an operation used to remove a sensor from a service. These packages use data types specified in other standards. Those data types are normatively referenced herein, instead of being repeated in this standard.
Sensor Model Language (SensorML) Encoding Standard 1.0 (2007)
SensorML (see OGC’s Sensor Model Language (SensorML) Implementation Standard, OGC Document07-000) provides an information model and encodings that enable discovery and tasking of Web-resident sensors, and exploitation of sensor observations.[3]
The measurement of phenomena that results in an observation consists of a series of processes (also called procedures), beginning with the processes of sampling and detecting and followed perhaps by processes of data manipulation. The division between measurement and “post-processing” has become blurred with the introduction of more complex and intelligent sensors, as well as the application of more on-board processing of observations. The typical Global Positioning System (GPS) sensor is a prime example of a device that consists of basic detectors complemented by a series of complex processes that result in the observations of position, heading, and velocity.
SensorML defines models and XML Schema for describing any process, including measurement by a sensor system, as well as post-measurement processing.
Within SensorML, everything including detectors, actuators, filters, and operators are defined as process models. A Process Model defines the inputs, outputs, parameters, and method for that process, as well as a collection of metadata useful for discovery and human assistance. The inputs, outputs, and parameters are all defined using SWE Common data types. Process metadata includes identifiers, classifiers, constraints (time, legal, and security), capabilities, characteristics, contacts, and references, in addition to inputs, outputs, parameters, and system location.
SensorML provides a functional model of the sensor system, rather than a detailed description of its hardware. SensorML treats sensor systems and a system’s components (e.g. sensors, actuators, platforms, etc.) as processes. Thus, each component can be included as part of one or more process chains that can either describe the lineage of the observations or provide a process for geolocating and processing the observations to higher level information. In SensorML, all processes, including sensors and sensor systems, have input, output, parameters, and methods that can be utilized by applications for exploiting observations from any sensor system. In addition, SensorML provides additional metadata that are useful for enabling discovery, for identifying system constraints (e.g. security or legal use constraints), for providing contacts and references, and for describing taskable properties, interfaces, and physical properties.
SensorML 2.0 is currently being developed and is expected to be approved in late 2012.
Sensor Observation Service (SOS) Interface Standard 1.0 (2007)
The OGC Sensor Observation Service Interface Standard, OGC Document 06-009r6, defines an API for managing deployed sensors and retrieving sensor data and specifically “observation” data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today. Therefore, the SOS Implementation Standard is a critical element of the SWE architecture, defining the network-centric data representations and operations for accessing and integrating observation data from sensor systems.
The SOS is the intermediary between a client and an observation repository or near real-time sensor channel. Clients can also access SOS to obtain metadata information that describes the associated sensors, platforms, procedures and other metadata associated with observations.
Figure 3 above shows a SWE client making use of the SOS to automatically obtain observations and measurements from a collection of sensors. The SOS might also control the sensors for the client. The client depends on registries that provide metadata for the different types of sensors and the kinds of data that they are capable of providing.
Figure 4 above shows the role that registries (also called catalogs) play in a fully operational Web Services based Sensor Web. The schema for each sensor platform type is available in a registry, and sensors of that type are also in registries, with all their particular information. The schema for each observable type is available in a registry, and stored collections (data sets) of such observables and live data streams of that type are also in registries. Searches on the registries might reveal, for example, all the active air pollution sensors in Los Angeles. Similarly, automated methods implementing the SOS specification might be employed in an application that displays a near real-time air pollution map of the city.
SOS 2.0 is being developed and is expected to be approved in mid 2012.
Sensor Planning Service (SPS) Interface Standard 2.0 (2011)
The OGC**® Sensor Planning Service Interface Standard (SPS) defines interfaces for queries that provide information about the capabilities of a sensor and how to task the sensor. The standard is designed to support queries that have the following purposes: to determine the feasibility of a sensor planning request; to submit and reserve/commit such a request; to inquire about the status of such a request; to update or cancel such a request; and to request information about other OGC Web services that provide access to the data collected by the requested task..
The OGC**® Sensor Planning Service (SPS) Implementation Standard,OGC Document 09-000, defines interfaces for a service to assist in collection feasibility plans and to process collection requests for a sensor or sensor constellation.
The developers and likely users of the SPS standard will be enterprises that need to automate complex information flows in large enterprises that depend on live and stored data from sensors and imaging devices. In such environments, specific information requirements give rise to frequent and varied collection requests. Quickly getting an observation from a sensor at the right time and place may be critical, and getting data that was collected at a specific place at a specific time in the past may be critical. The SPS standard specifies open interfaces for requesting information describing the capabilities of a SPS, for determining the feasibility of an intended sensor planning request, for submitting such a request, for inquiring about the status of such a request, and for updating or canceling such a request.
An example of an environmental support system is diagrammed above in Figure 5. This system uses SPS to assist scientists and regulators in formulating collection requests targeted at water quality monitoring devices and data archives. Among other things, it allows an investigator to delineate geographic regions and time frames, and to choose quality parameters to be excluded or included.
There is an Earth Observation Satellite Tasking Extension to SPS 2.0. These extensions are dedicated to providing an interoperable access to the tasking capabilities of various types of earth observation systems. The resulting extended web service interface can be used for determining the feasibility of an intended sensor planning request, for submitting such a request, for inquiring about the status of such a request, for updating or cancelling such a request, and for requesting information on means of obtaining the data collected by the requested task.
PUCK Protocol Standard 1.0 (2011)
Standards such as OGC SWE and IEEE 1451 strive to integrate diverse instruments into networks with minimal human effort and high reliability. Nevertheless use of these standards may require several software components to be manually installed on the instrument network, including instrument “drivers”, web servers, and metadata documents that describe instruments in a standard way.
The PUCK protocol standard [OGC 10-127r1] addresses these installation and configuration challenges by defining a standard instrument protocol to store and automatically retrieve metadata and other information from the instrument’s “PUCK memory”. This information can include descriptive documents such as OGC SWE SensorML or IEEE 1451 TEDS as well as actual instrument “driver” code. A host computer that understands PUCK can automatically retrieve and utilize this information from the instrument itself when the device is installed. For example, a SensorML document and instrument driver code can be physically stored in the instrument’s PUCK memory before deployment; the information can later be automatically retrieved and utilized by a host on the sensor network when the instrument is plugged in, thus minimizing manual installation steps. We refer to this automated process as “plug and work”. PUCK protocol is currently defined for devices with an EIA232 (aka “RS232”) or Ethernet physical/electrical interface.
Sensor Alert Service (SAS)
The OGC**® Sensor Alert Service Discussion Paper, OGC Document 06-028 specifies interfaces for requesting information describing the capabilities of a Sensor Alert Service, for determining the nature of offered alerts, the protocols used, and the options to subscribe to specific alert types. The document defines an alert as a special kind of notification indicating that an event has occurred at an object of interest, which results in a condition of heightened watchfulness or preparation for action. Alerts messages always contain a time and location value.
The draft SAS standard describes an interface that allows nodes to advertise and publish observational data or its describing metadata respectively. It is important to emphasize that the SAS itself acts like a registry rather than an event notification system! Sensors or other data producers do advertise their offers to a messaging server. The messaging server itself forwards this advertisement to the SAS. If a consumer wants to subscribe to an alert, it sends a subscription-request to the SAS. We want to point out that this operation is rather a lookup than a real subscription. This is based on the fact that the SAS will not send any alerts. All actual messaging is performed by a messaging server. The response sent by the SAS will contain the communication endpoint. It is up to the consumer to open a connection to this communication endpoint. The SAS response contains all information necessary to set up a subscription.
Therefore, a SAS implementation relies on other alerting protocols and standards. For instance, users could register with a SAS enabled alert registry to receive OASIS Common Alert Protocol (CAP) alerts for specific types of observations, such as weather events or earthquakes[4].
Web Notification Service (WNS)
The OGC**® Web Notification Service (WNS) Best Practices Paper, OGC Document 06-095 specifies an open interface for a service by which a client may conduct asynchronous dialogues (message interchanges) with one or more other services. [OGC Document 05-114] As services become more complex, basic request-response mechanisms need to contend with delays/failures. For example, mid-term or long-term (trans-) actions demand functions to support asynchronous communications between a user and the corresponding service, or between two services, respectively. A WNS is required to fulfill these needs within the SWE framework.
The WNS includes two different kinds of notifications. First, the “one-way-communication” provides the user with information without expecting a response. Second, the “two-way-communication” provides the user with information and expects some kind of asynchronous response. This differentiation implies the differences between simple and sophisticated WNS. A simple WNS provides the capability to notify a user and/or service that a specific event occurred. In addition, the latter is able to receive a response from the user.
Other Areas of Sensor Web Standards Harmonization
The OGC has an active coordination program with many other standards groups and has been active in the Sensor Standards Harmonization WG (SSHWG) led by the National Institute of Standards and Technology (NIST). The broad challenge of SSHWG is to “integrate sensor and non-sensor data in a decision support network.”
IEEE 1451 Transducer interfaces
Developing an open standards framework for interoperable sensor networks requires finding a universal way of connecting two basic interface types – transducer interfaces and application interfaces. Specifications for transducer interfaces typically mirror hardware specifications, while specifications for service interfaces mirror application requirements. The sensor interfaces and application services may need to interoperate and may need to be bridged at any of many locations in the deployment hierarchy.
At the transducer interface level, a “smart” transducer includes enough descriptive information so that control software can automatically determine the transducer’s operating parameters, decode the (electronic) data sheet, and issue commands to read or actuate the transducer.
To avoid the requirement to make unique smart transducers for each network on the market, transducer manufacturers have supported the development of a universally accepted transducer interface standard, the IEEE 1451 standard.
The object-based scheme used in 1451.1 makes sensors accessible to clients over a network through a Network Capable Application Processor (NCAP), and this is the point of interface to services defined in the OGC Sensor Web Enablement specifications. In Figure 6, SWE services such as SOS act as clients (consumers) of IEEE-1451 NCAP services and TEDS documents, thereby enabling interactions with heterogeneous sensor systems via scalable networks of applications and services.
Imaging Sensors
The SWE sensor model described by SensorML and TML specifications is sophisticated enough to support encoding of all the parameters necessary for characterizing complex imaging devices such as those on orbiting earth imaging platforms. ISO and OGC have cooperated to develop two ISO standards that are relevant to the SWE effort: ISO 19101-2Geographic Information – Reference Model – Imagery (OGC Abstract Specification, Topic 7).Other related work for support of imaging sensors within the SWE context include: OGC**® Geography Markup Language (GML) Encoding Specification (OGC Document 03-105r1), GML Application Schema for EO Products (OGC Document 06-080r1), OGC**® GML in JPEG 2000 for Geographic Imagery Encoding Specification (OGC Document 05-047r3) and Draft GML Application: Encoding of Discrete Coverages (OGC Document 06-188).
Examples and Implementations
SWE Implementations and Demonstrations
The OGC’s fourth OGC Web Services testbed activity, OWS-4, culminated in a December, 2006 demonstration based on a hypothetical scenario in which a bomb containing highly toxic radioactive material was discovered as a container was being unloaded from a ship at a wharf near New York City. Before the bomb could be disarmed, it exploded, injuring people and releasing a wind-borne plume of radioactivity. Disaster managers from state, federal and local agencies attending the demonstration saw live Web-based information systems being used to find, access and integrate diverse geospatial resources, many of which were live sensors, just as these managers’ systems might be used in a real disaster. The information flowed from many different data sources through Web services. Most of the software involved was commercially available off-the-shelf software implementing OGC standards.
In the demonstration, a radiation sensor whose Web interface conformed to SWE standards triggered an alert that automatically set several processes in motion. Other sensors in the vicinity were polled. A server managed by the Emergency Operations Center (EOC) alerts the EOC operator and automatically prepared a report, including a map display of sensors reporting high radioactivity. This automated process involved “service chaining” of multiple online services that publish or process sensor locations and other geospatial data. An EOC manager notified local fire and police departments immediately, as well as the appropriate state and federal agencies.
Online catalogs conforming to the OGC**® Catalog Services Standard provided the means for the EOC operator to determine the location and other features of a wide variety of online sensors. The sensor data and metadata were immediately displayed on a map. Video cameras near the explosion were immediately accessible, and the operator could control those that provided remote control, because the SensorML standard addresses sensor control parameters.
Anticipating the need for real-time weather information, the operator accessed NASA’s Earth Observation-1 (EO-1) satellite ground system, instructing the satellite through an open interface to provided images of the New York/New Jersey area over the next several days. The acquisition request was accepted by the EO-1 planning systems and the image was acquired on December 8th during the OWS-4 demonstration. NASA satellites are in fact being fitted with implementations of SWE standards to make such use possible.
The fundamental concept of Geospatial Decision Support (GeoDSS) is that a decision maker at a single workstation should be able to identify geospatial resources anywhere, access the resources, bring them into an operational context, and integrate them with other resources to support the decision process. The EOC operator’s operational context is different from the first responder’s operational context. Data displayed in police and firefighters’ handheld devices and on-board computers needs to be rendered using cartographic styles these first responders are familiar with, styles that may be different in different jurisdictions. OGC standards such as the OGC** Styled Layer Descriptor Encoding Standard enable software and services running on different devices to tailor data “portrayal” for the user of the device.
Active 2008 OGC Interoperability Initiatives that involve SWE standards include: Empire Challenge Pilot (EC Pilot), Federated Earth Observation Pilot (FedEO), GALEON IE (Geo-interface for Atmosphere, Land, Earth, and Ocean netCDF IE), GEOSS (Global Earth Observation System of Systems) Architecture Implementation Pilot, Ocean Science Interoperability Experiment (OceansIE) and OGC Web Services, Phase 5 (OWS-5).
Some current SWE implementation efforts:
- Oak Ridge National Laboratory’s (ORNL) SensorNet program at Fort Bragg, North Carolina, developing a collection of systems for the detection, identification and assessment of chemical, biological, radiological and nuclear threats
- SensorWeb, being developed by SAIC for the Defense Intelligence Agency (DIA)
- The Heterogeneous Mission Accessibility (HMA) project of the European Space Agency and various partner organizations in Europe
- Persistent Universal Layered Sensor Exploitation Network (PULSENet), a Northrop Grumman Corporation internal research and development project
- SANY (Sensors Anywhere), co-funded by the Information Society and Media Directorate General of the European Commission, contributing to the Global Monitoring for Environment and Security (GMES) program
- The German organization 52North provides a complete set of SWE services under GPL license. One project using 52North’s software is the German Indonesian Tsunami Early Warning System (GITEWS), a 35-million euro project of the German aerospace agency, DLR, and the GeoForschungsZentrum Potsdam (GFZ), Germany’s National Research Centre for Geosciences.
- The Consortium of Universities for the Advancement of Hydrologic Science Inc. (CUAHSI) representing more than 100 U.S. universities, uses SWE standards in its Hydrologic Information System (HIS).
Conclusion
OGC’s SWE standards provide an integrated framework for discovering and interacting with Web-accessible sensors and for assembling and utilizing sensor networks on the Web. Many key interoperability elements have already been codified in specifications, and work will continue on these as the specifications are tested and implemented in products. OGC members will continue to address new areas of Sensor Web Enablement in the OGC Standards Program committees and working groups and the OGC Interoperability Program’s testbeds and pilot projects.
OGC invites additional participation in the consensus process and also invites technical queries related to new implementations of the emerging standards.
Your Participation
Membership in OGC offers many benefits to both your organization and the larger geospatial community. We invite you to learn more. Contact:
Carl Reed, PhD
Executive Director, Stamdards Program
Open Geospatial Consortium
creed<at>opengeospatial.org
Copyright © 2012, Open Geospatial Consortium, OGC**® and OGC® are trademarks or registered trademarks of the Open Geospatial Consortium, Inc. in the United States and in other countries. All other products mentioned are registered trademarks or trademarks of their respective companies. Please send comments or report problems to: Webmaster@opengeospatial.org.
[1] Wikipedia
[2] The OGC is an international consortium of industry, academic and government organizations who collaboratively develop open standards for geospatial and location services. (See http://www.opengeospatial.org.)
[3] SensorML got its start in earlier NASA and CEOS (Committee for Earth Observation Satellites) projects. It was brought into OGC because OGC provides a process in which this and other elements of Sensor Web Enablement could be developed in an open consensus process.
[4] "OASIS Advances Common Alerting Protocol and Emergency Data Exchange Language." http://xml.coverpages.org/ni2005-05-19-a.html