5.3.3 SensorML

From Geostandards

Jump to: navigation, search



Contents

Overview

The Sensor Model Language (SensorML) specification provides a common framework for describing any process and process chain. The focus of SensorML is to define processes and processing components associated with the measurement and post-measurement transformation of observations. Within SensorML, sensors and transducers are all modeled as process that can be connected and participate within a process chain.

The objectives of SensorML are:

  • provide descriptions of sensors and sensor systems for inventory management
  • provide sensor information for observation discovery
  • support the processing and analysis of observations
  • provide an explicit description of the process by which an observation was obtained
  • archive fundamental properties and assumptions regarding sensor systems

Basic Concepts

The basic concept of SensorML is the so called AbstractProcess. From this type all other kinds of processes are derived. The derived process types can be divided into two groups: physical processes (e.g. sensing devices) and non-physical processes (e.g. processing steps that are performed on measured data).

The AbstractProcess contains those properties that are relevant for all derived process types. In detail an AbstractProcess contains

  • name
  • description
  • inputs: for physical sensing devices the inputs are the observed phenomena, for non-physical processes (e.g. processing steps) the inputs are any kind of incoming data
  • outputs: the data that is created by the according process (e.g. measured value or calculation result)
  • parameters
  • metadata

The metadata for a process can be subdivided into five different sub groups:

  • general information: identifiers for the process and a list of according classifiers that facilitate sensor discovery (e.g. sensor type, intended application)
  • constraints: information about security and legal constraints as well as information about the time period for which the process description is valid
  • properties: any kind of characteristics or capabilities of a sensor that may help for discovering it; this includes capabilities like the measurement frequency or accuracy as well as characteristics like the dimensions of a sensor
  • references: information where further documentation about the process can be found and contact data (e.g. of the sensor operator)
  • history: a list of events that describe the history of the sensor; this list may include information like maintenance activities, parameter changes, etc.

Non-physical Processes

Non-physical processes can be understood as mathematical operations. The basic element of a non-physical process is the so called ProcessModel. In addition to the AbstractProcess the ProcessModel contains a method property which describes the mathematical operation of the process.

More complex processes can be described using the ProcessChain type. This type allows the combination of ProcessModels and other ProcessChains in order to describe a sequence of sub processes. In order to achieve this, the ProcessChain includes a list of the ProcessModels and ProcessChains it contains as well as the description how their outputs (sources) and inputs (destinations) are linked.

Physical Processes

Physical processes are processes that are related to space and time. Typical examples for such processes are detectors, actuators, sensor systems or samplers. Unlike non-physical processes physical processes possess means for expressing their temporal and spatial relationships (i.e. the according reference frames and the positions within these reference frames). Furthermore the interfaces of physical processes can be described (hardware as well as software interfaces) based on the OSI Reference Model.

The basic physical process type is the Component. This is the smallest unit which cannot be further sub divided. More complex physical processes can be described using the System type which aggregates individual components as well as other systems. An example for this relationship is a weather station (system) which contains several sensing devices like thermometers, wind speed sensors, etc. (components).

Example

In the following sections an example of a SensorML document will be described. This SensorML document contains metadata about a weather station. This station is modelled as a system whereas the different sensor devices of the weather station are shown as components.

Please note: This example does not contain every possible element that can be provided through SensorML. Instead it shows a basic set of metadata one might use for describing a sensor system.

System

Keywords

The keywords section contains terms that describe the weather station as a whole but also the components it comprises: 

<keywords>
  <KeywordList>
    <keyword>weather station</keyword>
    <keyword>precipitation</keyword>
    <keyword>wind speed</keyword>
    <keyword>temperature</keyword>
  </KeywordList>
</keywords>

Identification

In this example three different identifiers are provided: a unique ID, a long name and a short name of the weather station. 

<identification>
  <IdentifierList>
    <identifier name="uniqueID">
      <Term definition="urn:ogc:def:identifier:OGC:uniqueID">
        <value>urn:ogc:object:feature:Sensor:IFGI:weatherStation123</value>
      </Term>
    </identifier>
    <identifier name="longName">
      <Term definition="urn:ogc:def:identifier:OGC:1.0:longName">
        <value>OSIRIS weather station 123 on top of the IfGI building</value>
      </Term>
    </identifier>
    <identifier name="shortName">
      <Term definition="urn:ogc:def:identifier:OGC:1.0:shortName">
        <value>OSIRIS Weather Station 123</value>
      </Term>
    </identifier>
  </IdentifierList>
</identification>

Classification

The classification section in the example provides information about the application for which the sensor is inteded for. In this case the intended application is "weather". 

<classification>
  <ClassifierList>
    <classifier name="intendedApplication">
      <Term definition="urn:ogc:def:classifier:OGC:1.0:application">
        <value>weather</value>
      </Term>
    </classifier>
  </ClassifierList>
</classification>

Valid Time

In this example the time sensor description is only valid for a certain time period that is encoded by a gml TimePeriod. 

<validTime>
  <gml:TimePeriod>
    <gml:beginPosition>2009-01-15</gml:beginPosition>
    <gml:endPosition>2009-01-20</gml:endPosition>
  </gml:TimePeriod>
</validTime>

Capabilities

The excerpt of an exemplary capabilities section below contains two main items. First the status of the weather station is described. Here it is "active". After that, a bounding box is provided that comprises the area that is observed by the weather station. For this station (an in-situ sensor) this bounding box includes exactly only one point: the location of the weather station. For other sensor types this bounding box might be bigger (e.g. for remote sensing devices that deliver coverages). 

<capabilities>
  <swe:DataRecord definition="urn:ogc:def:property:capabilities">
    <swe:field name="status">
      <swe:Text definition="urn:ogc:def:property:OGC:1.0:status">
        <gml:description>The operating status of the system.</gml:description>
        <swe:value>active</swe:value>
      </swe:Text>
    </swe:field>
    <swe:field name="observedBBOX">
      <swe:Envelope definition="urn:ogc:def:property:OGC:1.0:observedBBOX">
        <swe:lowerCorner>
          <swe:Vector>
            <swe:coordinate name="easting">
              <swe:Quantity axisID="x">
                <swe:uom code="m"/>
                <swe:value>2592308.332</swe:value>
              </swe:Quantity>
            </swe:coordinate>
            <swe:coordinate name="northing">
              <swe:Quantity axisID="y">
                <swe:uom code="m"/>
                <swe:value>5659592.542</swe:value>
              </swe:Quantity>
            </swe:coordinate>
          </swe:Vector>
        </swe:lowerCorner>
        <swe:upperCorner>
          <swe:Vector>
            <swe:coordinate name="easting">
              <swe:Quantity axisID="x">
                <swe:uom code="m"/>
                <swe:value>2592308.332</swe:value>
              </swe:Quantity>
            </swe:coordinate>
            <swe:coordinate name="northing">
              <swe:Quantity axisID="y">
                <swe:uom code="m"/>
                <swe:value>5659592.542</swe:value>
              </swe:Quantity>
            </swe:coordinate>
          </swe:Vector>
        </swe:upperCorner>
      </swe:Envelope>
    </swe:field>
  </swe:DataRecord>
</capabilities>

Contact

 The contact section in this example points to the operator of the weather station. In this case a research group at the University of Münster. 

<contact>
  <ResponsibleParty gml:id="WWU_IfGI_weather_station_contact">
    <organizationName>Westfälische Wilhelms-Universität Münster - Sensor Web and Simulation Lab</organizationName>
    <contactInfo>
      <address>
        <electronicMailAddress>swsl-ifgi@listserv.uni-muenster.de</electronicMailAddress>
      </address>
    </contactInfo>
  </ResponsibleParty>
</contact>

Position

Here the position of the system is identical to the bounding box that is observed by the sensor. This is a typical characteristic of in-situ sensors. For remote sensing system the sensor position differs from the observed bounding box. 

<position name="systemPosition">
  <swe:Position referenceFrame="urn:ogc:def:crs:EPSG:6.14:31466">
    <swe:location>
      <swe:Vector gml:id="SYSTEM_LOCATION">
        <swe:coordinate name="easting">
          <swe:Quantity axisID="x">
            <swe:uom code="m"/>
            <swe:value>2592308.332</swe:value>
          </swe:Quantity>
        </swe:coordinate>
        <swe:coordinate name="northing">
          <swe:Quantity axisID="y">
            <swe:uom code="m"/>
            <swe:value>5659592.542</swe:value>
          </swe:Quantity>
        </swe:coordinate>
        <swe:coordinate name="altitude">
          <swe:Quantity axisID="z">
            <swe:uom code="m"/>
            <swe:value>297.0</swe:value>
          </swe:Quantity>
        </swe:coordinate>
      </swe:Vector>
    </swe:location>
  </swe:Position>
</position>

Inputs

The inputs for this example weather station are the phenomena it observes. In this case: precipitation, wind and temperature. 

<inputs>
  <InputList>
    <input name="precipitation">
      <swe:ObservableProperty definition="urn:ogc:def:property:OGC:1.0:precipitation"/>
    </input>
    <input name="wind">
      <swe:ObservableProperty definition="urn:ogc:def:property:OGC:1.0:wind"/>
    </input>
    <input name="atmosphericTemperature">
      <swe:ObservableProperty definition="urn:ogc:def:property:OGC:1.0:temperature"/>
    </input>
  </InputList>
</inputs>

Outputs

The inputs of the example weather station lead to four types of outputs that are generated by the sensors of the weather station: precipitation, wind direction, wind speed and temperature. One can see that measuring the input "wind" leads to two different outputs: the direction and the speed of the wind. 

<outputs>
  <OutputList>
    <output name="precipitation">
      <swe:Quantity definition="urn:ogc:def:property:OGC:1.0:precipitation">
        <swe:uom code="mm"/>
      </swe:Quantity>
    </output>
    <output name="windDirection">
      <swe:Quantity definition="urn:ogc:def:property:OGC:1.0:windDirection">
        <swe:uom code="deg"/>
      </swe:Quantity>
    </output>
    <output name="windSpeed">
      <swe:Quantity definition="urn:ogc:def:property:OGC:1.0:windSpeed">
        <swe:uom code="m/s"/>
      </swe:Quantity>
    </output>
    <output name="temperature">
      <swe:Quantity definition="urn:ogc:def:property:OGC:1.0:temperature">
        <swe:uom code="Cel"/>
      </swe:Quantity>
    </output>
  </OutputList>
</outputs>

Components

In this section the three sensor types of the weather station are described more detailled. Whereas the thermometer is described directly within the SensorML document the descriptions of the rain gauge and the anemometer are referenced externally by according URLs.  

<components>
  <ComponentList>
    <component name="rainGauge" xlink:href="http://mySensorMLregistry.com?object=98765"/>
    <component name="anemoneter" xlink:href="http://mySensorMLregistry.com?object=33333"/>
    <component name="thermometer">
      <Component>
        ...
      </Component>
    </component>
  </ComponentList>
</components>

Component

In this section the description of one component of the weather station is shown: the SensorML document describing the thermometer. One can see that the structure of the components resembles strongly the description of the system. However the contacts section and the position section are not repeated again within this document. Instead, this information is inherited from the description of the weather station. 

<Component>
  <keywords>
    <KeywordList>
      <keyword>weather station</keyword>
      <keyword>temperature</keyword>
    </KeywordList>
  </keywords>
  <identification>
    <IdentifierList>
      <identifier name="uniqueID">
        <Term definition="urn:ogc:def:identifier:OGC:uniqueID">
          <value>urn:ogc:object:feature:Sensor:IFGI:thermometer123</value>
        </Term>
      </identifier>
      <identifier name="longName">
        <Term definition="urn:ogc:def:identifier:OGC:1.0:longName">
          <value>OSIRIS Thermometer at weather station 123</value>
        </Term>
      </identifier>
      <identifier name="shortName">
        <Term definition="urn:ogc:def:identifier:OGC:1.0:shortName">
          <value>OSIRIS Thermometer 123</value>
        </Term>
      </identifier>
    </IdentifierList>
  </identification>
  <classification>
    <ClassifierList>
      <classifier name="sensorType">
        <Term definition="urn:ogc:def:classifier:OGC:1.0:sensorType">
          <value>thermometer</value>
        </Term>
      </classifier>
    </ClassifierList>
  </classification>
  <capabilities>
    <swe:DataRecord definition="urn:ogc:def:property:capabilities">
      <swe:field name="status">
        <swe:Text definition="urn:ogc:def:property:OGC:1.0:status">
          <gml:description>The operating status of the system.</gml:description>
          <swe:value>active</swe:value>
        </swe:Text>
      </swe:field>
    </swe:DataRecord> 
  </capabilities>
  <inputs>
    <InputList>
      <input name="atmosphericTemperature">
        <swe:ObservableProperty definition="urn:ogc:def:property:OGC:1.0:temperature"/>
      </input>
    </InputList>
  </inputs>
  <outputs>
    <OutputList>
      <output name="temperature">
        <swe:Quantity definition="urn:ogc:def:property:OGC:1.0:temperature">
          <gml:groupName codeSpace="ObservationOffering"> Weather </gml:groupName>
          <swe:uom code="Cel"/>
        </swe:Quantity>
      </output>
    </OutputList>
  </outputs>
</Component>
← previous 5 Sensor Web Enablement next →
Retrieved from "http://geostandards.geonovum.nl/index.php/5.3.3_SensorML"
Personal tools