Sensor Web Enablement White Paper

Sensor Web Enablement White Paper

Mike Botts, PhD, University of Alabama in Huntsville

256-961-7760

, http://vast.uah.edu

Dr. Botts is the principal architect of SensorML.

Mark Reichardt, Executive Director, OGC Outreach and Community Adoption Program

Open GIS Consortium (OGC), Inc.

301 840-1361

Jeff Harrison, Executive Director, Program Development

Open GIS Consortium (OGC), Inc.

703 628 8655

Members of the Open GIS Consortium, Inc. (OGC), an international consortium of industry, academic and government organizations (see http://www.opengis.org), are building a unique and revolutionary open platform for exploiting Web-connected sensors. Such sensors and devices include, for example: flood gauges, air pollution monitors, stress gauges on bridges, mobile heart monitors, Webcams, and satellite-borne earth imaging devices. The following are likely to be completed and adopted as OpenGIS® Specifications by OGC in 2003 and 2004:

SensorML – Information model and XML encodings for discovering, querying and controlling Web-resident sensors.
Observations & Measurements – Information model and encodings for observations and measurements.
Sensor Collection Service - Service to fetch observations from a sensor or constellation of sensors. This is the intermediary between a client and an observation repository or near real-time sensor channel.
Sensor Planning Service – Service to assist in "collection feasibility plans" and to process collection requests for a sensor or sensor constellation. This is the intermediary between a client and a sensor collection management environment.
Web Notification Service – Executes and manages message dialogue between a client and Web service(s) for long duration asynchronous processes.

The goal is to make all types of Web-resident sensors, instruments, and imaging devices, and also repositories of sensor data, discoverable, accessible and, where applicable, controllable via the World Wide Web. That is, the goal is to enable the creation of Web-based sensor networks.

With advances in digital technology, it is becoming increasingly practical to fit sensors of virtually any type with wired or wireless connections that enable remote access to the devices' control inputs and data outputs as well as their identification and location information. Through a variety of location technologies such as GPS, Cell-ID, and Cell-ID with triangulation, mobile sensing devices can be made capable of reporting their geographic location along with sensor-collected data.

If the connection can be 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 XML data, enabling automated Web-based discovery of the existence of sensors and evaluation of their characteristics based on their published descriptions. Information provided in the XML schema about a sensor's control interface enables automated communication with the sensor system: 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. This 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.

Sensor Web presents endless opportunities for adding a sensory dimension to the globe-encircling virtual nervous system of the Web. This has extraordinary significance for science, environmental monitoring, transportation management, public safety, security, disaster management, utilities' SCADA operations, industrial controls, facilities management and many other domains of activity. Because OGC is the world's authoritative source for standards related to geoprocessing interoperability, and because OGC has strong international industry and government support in domains that depend on sensors, it is very likely that these specifications will quickly become established in all areas where such a standard can be of use.

Below we describe each of the five basic elements of the Sensor Web. As of this writing (August, 2003), Observations and Measurements has approved as an OpenGIS Recommendation Paper. The remainder of the Sensor Web documents are at various stages in OGC's formal specification development process. Some of the specification documents are available as recommendation papers and discussion papers on OGC's public Web site. Others are available only to members. As soon as the specifications are adopted (approved) by the members, they will be made available to the public at no charge.

1 SensorML

SensorML provides information model and encodings for discovering, querying and controlling Web-resident sensors. That is, SensorML establishes a standard schema for metadata describing sensors, sensor platforms, and sensor tasking interfaces. See the OGC Discussion Paper titled "Sensor Model Language (SensorML) for In-situ and Remote Sensors" (http://www.opengis.org/info/discussion.htm) (OpenGIS Project Document 02-026r4).

SensorML got its start in earlier NASA and CEOS (Committee for Earth Observation Satellites) projects. It was brought into OGC because: the Consortium provides a formal Technical Committee and rapid-prototyping testbed process in which the other elements of Sensor Web could be developed in an open consensus process; because OGC's membership includes many of the agencies, corporations, and universities who might have an interest in shaping and adopting such a standard; because many of the individual participants were experts in certain types of complex sensors (Earth imaging systems); and because OGC has an active and successful Class A liaison with ISO TC/211 (Geographic Information / Geomatics).

SensorML provides a functional model of the sensor system, rather than a detailed description of its hardware. Below we summarize the components of a SensorML document.

Figure 1: Hi-level diagram of SensorML showing several potential “plug-n-play” response models for the measures property.

The root for all SensorML documents is Sensor, or an extension of Sensor such as SensorGroup. The Sensor has a unique id (of type xs:id) as a required attribute. Two optional attributes, documentDate (xs:dateTime) and documentVersion (xs:string), provide the ability to quickly check version information. The sensor description is divided into nine main informational components, (in the central column of boxes, beginning with "identifiedAs"), each of which has sub-parts. (Most of these are optional, so that implementations can be kept as simple as possible.) Several of the components have “plug-n-play” capabilities, such that they can accept models that are appropriate for a given class of sensors. For example, the “measures” component supports one of any number of various sensor response models, as illustrated above.

What does the actual XML code look like? As an example, SensorML for the response property for a YSI Wind Speed Sensor might include:

</minimum>

</maximum>

</dynamicRange>

</threshold>

</maximum>

</survivableRange>

<Quantity observableType=#airTemeratureunitOfMeasure=#celsius>-40

</minimum>

<Quantity observableType=#airTemeratureunitOfMeasure=#celsius>40

</maximum>

</operationalRange>

</GeneralPropertyModel>

</response>

SensorML must be capable of specifying location and orientation of platforms and sensors, either directly within a georeferenced coordinate system or relative to intermediate local coordinate systems. The use of ISO 19111-based schema for specifying coordinate systems and coordinate transforms provides a robust and flexible basis for describing sensor and platform location and orientation. SensorML must also be capable of supporting the georegistration of observations from a wide range of sensors ranging from a simple, static, in-situ sensor to a more complex remote sensing scanner on a dynamic platform.

2 Observations & Measurements

A standard, overarching information model and encodings for observations and measurements are necessary if the Sensor Web is to find universal applicability with Web-based sensor networks.

"Observations and Measurements," an OGC Interoperability Program Report (OpenGIS Project Document OGC 03-022r3), provides a prototype of the general models and XML encodings for sensor observations and measurements. This is required specifically for the Sensor Collection Service and related components of an OGC Sensor Web Enablement capability, The aim is to define a number of terms used for measurements, and the relationships between them. This proposal discusses Observation, Measurement, Value, Observed Value, Coverage, SensorInstance, Observable, Measurand, Phenomenon, and related terms, presented using UML class diagrams and equivalent GML conformant XML serialisations. The scope is restricted to measurements whose results are expressed as quantities, categories, temporal and geometry values, and composites and arrays of these.

"Observations and Measurements" has an accompanying OGC Recommendation Paper titled "Units of Measure Use and Definition" (OpenGIS Project Document OGC 02-007r4). The basic information needed to understand a measured value is the value and the unit of measure. Eight different ways, and various options of these ways, to tie these two pieces of information were identified. The goal is to develop a preferred way to implement this information in XML. In addition, it is noted that a symbol for a unit of measure was not sufficient to identify it. Thus, this recommendation paper also defines a best practice for giving the meaning of a unit of measure."

3 Sensor Collection Service

The Sensor Collection Service (SCS) is a service to fetch observations from a sensor or constellation of sensors. This is the intermediary between a client and an observation repository or near real-time sensor channel. Clients implementing SCS can also obtain information that describes the associated sensors and platforms. OpenGIS Project Document 03-023, a Draft Interoperability Program Report, "Sensor Collection Service Implementation Specification."

Figure 2: Sensor Collection Service Concept

Figure 2 above shows a Sensor Web Enablement (SWE) client making use of the sensor collection service to automatically obtain observations and measurements from a collection of sensors. The Sensor Collection Service 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 3 below 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 live air pollution sensors in Los Angeles. Similarly, automated methods implementing the OpenGIS Sensor Collection Service Specification might be employed in an application that displays a near real-time air pollution map of the city.

Figure 3: Role of registries in the Sensor Web

4 Sensor Planning Service

SPS is being developed to support the information asset manager role. The Sensor Planning Service (SPS) specification will define 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 this specification are information system designers and developers working 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. Such tasks may be susceptible to uncertainties and contingencies. The SPS specification will specify open interfaces for requesting information describing the capabilities of a Sensor Planning Service, 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.

SPS will be a success if:

· Collection management systems only have to interact with one kind of interface

· Collection managers will be able to use any support system that has been "wrapped" with the SPS interface. For example, critical information, such meteorological information, that has not traditionally been considered part of intelligence will be easily integrateable into the collection management process in this way.

· Different types of systems can be used together. One kind of client might be a browser-based Web client, while another kind of client might be a workflow system that manages the CM roles, their interactions, and their products. For any given SPS, these clients will be interchangeable.

Figure 4: Typical in situ Sensor Planning Service

An example of an environmental support system is diagrammed above. This system assists 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.

5 Web Notification Service

The Web Notification Service (WNS) is a service by which a client may conduct asynchronous dialogues (message interchanges) with one or more other services for long duration processes. This service is useful when many collaborating services are required to satisfy a client request, and/or when significant delays are involved is satisfying the request. This service was defined in support of SPS operations.

6 Conclusion

OGC’s Sensor Web Enablement program is building an important framework for discovering and interacting with Web-resident sensors and for assembling and utilizing sensor networks on the Web. While many key interoperability elements have already been codified in specifications, work will continue on these as the specifications are tested and implemented in products. Also, OGC members will continue to address new areas of Sensor Web Enablement in the OGC Interoperability Program’s upcoming Testbeds and Pilot Projects and in the OGC Specification Program’s committees and working groups.

If you are interested in having your organization involved in Sensor Web Enablement, contact Mr. Jeff Harrison, Executive Director, Program Development: , (703) 628 8655.

Sensor Web Enablement White Paper 030512 5 Open GIS Consortium, Inc. 508-655-5858