Motivating Use cases (Sensor Web and Sensor Networks)

Drivers for the creation of the XG

The creation of this incubator activity and the definition of its two main objectives defined in the XG charter were motivated by several factors:

• The opportunity for several W3C member organisations working on Sensor Ontologies, Semantic Sensor Web and Semantic Sensor Networks applications to merge their research effort in this area,
• The recognition that the legacy mechanisms used to embed domain-specific vocabularies in several Sensor Web Enablement (SWE) standards developed by the Open Geospatial Consortium (SensorML, SWE common) should be replaced by approaches based on the semantic web languages developed by W3C, in particular OWL DL,
• The sentiment that the development of a Semantic Sensor Network ontology and of mechanisms to support semantic annotations could improve interoperability and integration of the services using these standards, as well as facilitate reasoning, classification and other types of assurance and automation not included in the OGC standards.

The work done by the XG on these two objectives is presented in the next sections. During the course of the XG, the group also identified four principal classes of use cases. These uses cases are presented here because they helped to prioritise parts of the ontology for development.

Sensor Web Enablement (SWE) Languages

In SWE, members of the OGC are building a framework of open standards for exploiting Web-connected sensors and sensor systems of all types. This framework is called a Sensor Web, and refers to web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application program interfaces (APIs). SWE is composed of three languages and four service specifications. The languages include the Sensor Model Language ([SENSORML 2007]), Observations and Measurements ([OM 1 2007], [OM 2 2007]), and Transducer Markup Language ([TML 2007]). The services include the Sensor Observation Service ([SOS 2008]), Sensor Planning Service ([SPS 2007])], and Sensor Alert Service ([SAS 2006]).

• Sensor Model Language (SML): 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.

• Observation & Measurements (O&M): Standard models and XML Schema for encoding observations and measurements from a sensor, both archived and real-time.

• Sensor Observation Service (SOS) GetCapabilities: The Sensor Observation Service includes three core operations: GetObservation, DescribeSensor, and GetCapabilities. The GetObservation operation provides an interface to query over observation data and returns an O&M document. The DescribeSensor operation provides an interface to query for the description of a sensor and returns a SensorML document. The GetCapabilities operation provides an interface to query for the description of a Sensor Observation Service. GetCapabilities allows clients to retrieve service metadata about a specific service instance and returns a GetCapabilites response document.

Use case categories for the XG vision

A set of use cases have been identified to motivate the work that has been done by the SSN-XG. They can be roughly classified into four main groups, according to the following two axes:

1) User classification: from users who directly manage sensors and sensor networks; through to users who use and manipulate data (but may not have any direct interest in sensors).

2) Technology: from Semantic Web through Sensor Web to Sensor Network.

The following table and figures provide different viewpoints on this classification, providing names for these four groups of use cases (data discovery, device discovery and selection, provenance and diagnosis, and device operation tasking and programming). The reason to identify several use case categories is that each one requires different levels of detail for the modelling of the sensors, the features they observe, their capabilities, their environment and their conditions of use. These use cases will be described next.

Role of OGC and W3C standards in the use cases

Figure 3.1 suggests a possible distribution of responsibility amongst OGC standards (standards based on XML web services) and W3C Semantic Web standards. It corresponds to that which is is currently feasible when these two platforms are deployed independently. At the bottom level, for sensor and sensor network applications, there are no ubiquituous standards. The backbone of the sensor service infrastructure and the API to sensors can be provided by OGC standards. Semantic Web standards (RDF, OWL, SPARQL) can be leveraged at a later stage of integration when the data is integrated as linked data and in mashups. In this situation, the semantic sensor network ontology is mainly used once the data has been converted into RDF and in the semantic annotations which may help to realise this conversion.

Figure 3.1 - Standards Landscape: Sensor Networks, Sensor Web, Semantic Web

While the work done by the XG can be applied in this configuration, it is not representative of the original vision, nor many current applications, which offer a much wider scope of roles for the ontology and the semantic markup.

Figure 3.2 illustrates how the various configurations are covered by the four categories of uses cases described in this section.

Figure 3.2 - Technologies and Use cases

Use case details

Some additional information for each use case is provided below. More information on the XG participants' projects and their relevance for the Incubator activity is available from the XG wiki .

Data Discovery and Linking

Background
We start by providing some background on a potential application where this use case can be better understood. This description is based on an application for flood detection and management in Southern UK that is being built in the context of the SemsorGrid4Env R&D project.

The Channel Coastal Observatory (CCO) is a well-used sensor network data source in the Solent region (in Southern UK). This network consists of a large number of deployed nodes with sensors, which, when associated with an appropriate spatial model, can detect if a flood is ongoing or likely in the near future throughout the Solent region. If this information can be combined with additional data sets pertaining to assets and ecological services, the impact of flood may be minimised by providing additional details during an emergency response and planning mode.

Use case description and actors
In this context, users (environmental managers and emergency response officers) may need to find observations obtained from the CCO network that meet certain criteria, and to link them to external data sources. For example, they may want to find all the observations related to weather conditions and tide information available in a specific bounding box (or in a specific region) and obtained in the last 24 hours, and to link them to the economic assets that could be affected by a potential flood event. These users work under the assumption that although CCO is the primary data source used, there could be other data sources (sensor-based or not) that could dynamically appear in the regions of interest, which they might not control, but which can provide useful information.

Hence, the primary actors in this use case are users with operational functions - such as emergency response, ship management (port operations) or recreational vessel monitoring and management - who will benefit from access to information that is embellished with real-time representation of sea state and height, and who may benefit from integrating this with other existing datasets in order to support multi-criteria decisions and operations. Other additional actors or stakeholders include professional and public users of environmental data who rely on access to existing major public information services, scientists conducting experiments (interested in data that suits their needs), forecast modellers, or citizen scientists.

Ontology usage
Sensor and other data assets are described with respect to the SSN ontology. In this context, special care has been taken to provide information about the related measurements and observations, with less attention paid to the descriptions of the sensor hardware from which these measurements and observations are made (and deployed as part of the Channel Coastal Observatory) since this is out of the scope of this use case.

Geospatial and temporal coverage of the overall sensor network is, however, critical since this must be aligned and linked with the regions identified by the users of the use case, both in the context of their roles and responsibilities and for the data sources they wish to use and link. These specific regions are often bespoke to the user or data source (e.g. the Solent, or coverage of an ecological asset data set) and do not appear in existing ontologies (e.g. Ordnance Survey ones), so must be included and appropriately linked. This also happens with asset descriptions, which are also related to other domain ontologies (e.g., ontologies about weather conditions, tide information, coastal defences and shipping). And finally, spatial and temporal information is also added in order to facilitate the data discovery process.

Device Discovery and Selection

Background
The Device Discovery and Selection use case mirrors the Data discovery use case with more emphasis on the structure and capabilities of the sensor or sensor networks than on how it relates to its environment.

Assessing the fitness of a particular sensor product for a specific task is often difficult. For rainfall gauges, information on how sensors perform in extreme conditions like high intensity rainfall or hail events is not always available. Selecting sensors in the context of international scientific collaborations like Fluxnet is even a bigger challenge, especially when (as for FluxNet) sensor assets are administered by national bodies but with the goal to produce a world-wide carbon-climate field dataset which is globally consistent.

The quality of fact sheets and of other technical documentation provided by sensor manufacturers is highly variable, especially for the description of secondary capabilities like, for example, the performance of rainfall sensors for the measurement of rainfall intensity. The authority for this type of sensor, the World Meteorological Organization, has conducted intercomparison studies ([WMO 2006], [WMO 2009]) to evaluate the performance of 25 models of sensors based on various measuring principles (e.g. tipping bucket, and impact disdrometer). The evaluation covers laboratory and field conditions for both normal and extreme conditions of use. This data would be very useful to users wishing to select the best sensor available for a given mission.

Fluxnet is an international network of over 500 sensor towers deployed in 35 countries, with an average of 20 sensors deployed on each tower. The OzFlux sub-network is administered by CSIRO with 14 stations in Australia. These ground stations are designed to provide continuous, long term micro-meteorological measurements of the exchanges of carbon dioxide, water vapor, and energy between the biosphere and atmosphere. The data they provide is used in conjunction with data from satellite-based sensors, to help scientists to validate new scientific theories and models.

Use case description and actors
The central user in this use case wishes to develop a new sensing capability or complete an existing one. This user may also be in charge of the setup of sensor assets and be the custodian of the site-specific data and of the observations produced by the sensors. To be able to pick the right sensor, this user needs to collect information about sensor types, models, and performance in a range of conditions from multiple places:

• Organisations defining sensor categories and standards for their field of application,
• Manufacturers of sensors, and
• Organisations setting up sensor assets.

In this context, search and mashup capabilities are equally important for the user. Ideally, experts for various fields of applications should be tasked to provide the domain-specific extensions to the SSN Ontology allowing sensor manufacturers to describe their products in a more consistent and complete way. Then, manufacturers should provide the data for each model in their catalogues so that it can be mashed up by electronic commerce and comparison web sites designed to let buyers compare and select the sensor which is the best match for their application. Users deploying sensors should then focus on the collection and the dissemination of the deployment-specific data rather than manufacturers' data about categories or models of sensors.

The data provided by manufacturers may also be used directly by end users deploying sensor assets when they merge it with their own data to share with their users. This capability, currently offered via a Service API based on SensorML, could be replaced by mashups, with potentially huge savings for virtual organisations managing many sensor assets like the Fluxnet collaboration.

Note: The latter part of this use case is related to the next use case "Provenance and Diagnosis" which covers the specific needs of users wishing to know more about the context in which data as been produced or to diagnose the causes of errors in the data produced by the sensors. Manufacturers of smart products may also decide to expose this data via a Sensor API so that it is always accessible. This case is discussed in the last use case “Device Operation Tasking and Programming”.

Ontology usage

The ontology should capture information about sensor capabilities, performance, and the conditions in which it can be used. It should include the most common metrological definitions like accuracy, precision, drift, sensitivity, selectivity, measurement range, detection limit, response time, frequency and latency.

One caveat is that to define sensor types, it is necessary to import external definitions. The simplest approach is to define categories of sensors by a reference to the generic quantity it can measure or of the corresponding units of measurement it uses. This works well in some applications (e.g. Pachube) but not in the general case as the need to refine quantity definitions specifically for each domain of application quickly arises. Then, other information such as the type of feature or phenomenon to be observed or the procedure to be followed are also needed (this aspect is discussed in the “Data Discovery” use case).

This dependency on domain-specific definitions like the type of property which is measured or the type of feature which is observed can be served without presuming which external ontologies are selected as the source of definitions for these. However, the quality of these external resources, for example, their ability to cover multiple domains of application with accurate and unambiguous definitions, is a very important consideration.

Provenance and Diagnosis

Background

Organisations deploying sensors need to monitor their assets to detect the possible occurrences of faults and the degradation in the quality of measurement over time (drift), possibly caused by changes in the operating conditions. Provenance data is important for the users of sensor networks wishing to evaluate the fitness of the data for their purpose. Provenance also enables data citations which will be a critical incentive to encourage the sharing of data, especially when it is produced by government or scientific organisations.

There is an urgent need for better management of information about water resources, especially in Australia, as the driest inhabited continent. Information infrastructure that supports real-time or near-real-time situation awareness is required for managing reservoirs and environmental flows, for efficient water trading, for compliance monitoring and irrigation planning, for hydro-electric power generation and for reliable flood warnings. A pilot project to develop real time water information systems (RT-WIS) is being developed in the context of the South Esk river catchment in Tasmania, Australia, by CSIRO and several partners including Tasmanian Department of Primary Industries, Parks, Water and Environment, Hydro Tasmania, Bureau of Meteorology, 52North and the University of Muenster (Germany) and the Rensselaer Polytechnic Institute (USA). The RT-WIS is based on the OGC SWE architecture, and employs real time sensor observations and real-time predictive modelling [Liu et al. 2010].

In order to support the interpretation of information produced through the RT-WIS, it is proposed to develop a comprehensive provenance information management service. This service will take advantage of the developing W3C work on Provenance [Provenance XG 2010] and is using the SSN ontology to describe the origins of the sensed data, arising from stream gauges and weather stations managed by separate organisations in the region.

Description The ontology needs to provide information about the sensor that is used to derive measurement data. Firstly, it needs to describe the physical property being observed, and properties of the sensor's measuring capability such as frequency, accuracy, measurement range, and precision. This can be used to check whether the sensor has been properly used to derive some subsequent conclusion, and could also be used to derive error bounds on derived results such as forecasts.

Further, the ontology should describe the physical structure on which the sensor is deployed and its location (in our case we may want to include the altitude or depth below a normative stream height), the custodian responsible for the sensor, the maintenance schedule for the device (e.g. how often is the sensor checked and freed of weeds) and the environmental conditions under which the sensor is expected to operate according to specification. The custodian information and maintenance information can be used to determine trust in the data. The environmental conditions might be used to diagnose the reasons for an apparent data failure.

Actors In many cases the information may be used for direct human interpretation, like a printed data sheet. However, software agents may also use the information to make inferences about the reasons for unexpected or anomalous results.

Device Operation Tasking and Programming

Background

The device operation tasking and programming use case is presented in the context of the Phenonet sensor network for agricultural microclimate monitoring. This sensor network and its modelling with the SSN ontology is described further here: Agriculture Meteorology Sensor Network. As this is a highly experimental network, with the aim of collecting information about different aspects of different experimental field crops at different stages in their growth cycles, it is implemented with a heterogeneous range of sensors deployed in a mix of heterogeneous networks over a common spatial region. It is required to offer agricultural scientists, as end users, the ability to change the data collection method (systems, devices, and sensors employed, frequency of measurement, location of measurement if mobile, local aggregation and memory management) taking into account the capability of the sensor network. Some sensing devices are subsystems of Mote-like network nodes which can be programmed in the NesC or SNlog programming languages. Others are passive data loggers, and others still are programmable directly through a proprietary command-line based language.

Description

The words tasking and programming are used interchangeably here to refer to the assembly and transmission of instructions intended to control the behaviour of the sensing device. Tasking is normally used in the OGC SWE context, referring perhaps to the tasking of assets used for surveillance, but programming would be a more natural term for Mote-like devices and the sensor network developer community. Although sensing devices are sometimes also actuation devices, in this context we confine our attention to the control of sensing behaviour and actuation that is necessary to obtain the desired sensing data (for example, changing the angle of tilt of a camera).

The ontology should capture sufficient information about the capability of sensor devices and about the current state of the devices to support a palette of options for selection by the user. For example, a user should be able to define the desired observation frequency expressed in terms of the possible frequencies identified for the sensing device. It should be possible to extend the ontology to capture command language templates sufficient for device drivers to translate a completed template to an executable device-specific program. See How to represent a process implemented by a sensor for one way to model this and [Taylor and Penkala 2009] for another.

The user should be able to understand the network resource cost of proposed instructions (for example, power required per measurement, current battery life, latency before instruction can be executed). These qualities could be interpreted by the scientist user directly, or by an automated agent aiming to optimise network efficiency through resource scheduling and optimisation algorithms. The scientist or agent user should also be able to use information on sensor operating conditions to determine whether a sensor can be used as required, possibly by tasking another sensor to determine whether those conditions are met. For example, see Operating Range to see how to represent that a sensor can only operate under given environmental and battery power conditions.

The ontology should also be able to provide capability documentation and a vocabulary of instructions for the Sensor Planning Service ([SPS 2007]).

Actors

The intended primary actor would be an engineer or scientist issuing commands to the sensor network, supported by software that uses the ontology as the primary description of the network. In other cases it might be a software developer incorporating the sensor network into a larger observation or information system, requiring information on the control mechanisms available.