A SensorML

A.1 Introduction

SensorML (Sensor Model Language) is part of the the Sensor Web Enablement (SWE) activity of OGC (Open Geospatial Consortium Inc.) which defines interfaces and protocols to access sensors over the Web. Within this activity five foundational components, that have been prototyped and tested, are as follows:

In addition, the following encodings and services are undergoing development as additional components:

Although SensorML serves as a component within the OGC Sensor Web Enablement framework, SensorML does not depend upon the presence of the other SWE components. It can be utilized both as part of, and independent of, the OGC SWE framework.

This annex focuses on SensorML in order to see if it is suited for use within the S-TEN project. This section givesa brief overview of the Sensor Model Language, followed by a detailed description in section A.2, and some conclusions in section A.3.

A.2 Scope

A.2.1 History

In 1998, under the auspices of the international Committee for Earth Observing Satellites (CEOS), Dr. Mike Botts began development of an XML-based Sensor Model Language for describing the geometric, dynamic, and radiometric properties of dynamic remote sensors. Initial development was funded under a NASA AIST Program, and in 2000, SensorML was brought under the oversight of the Open Geospatial Consortium (OGC) where it served as a catalyst for the OGC Sensor Web Enablement (SWE) initiative. The continued development of SensorML has been supported by the Interoperability Program of OGC, as well as the US Environmental Protection Agency (EPA), the US National GeoSpatial-Intelligence Agency (NGA), the US Joint Interoperability Test Command (JITC), the US Defense Information Systems Agency (DISA), SAIC, General Dynamics, and Northrop Grumman. SensorML is in the last formal stages of approval by OGC as an international, open Technical Specification. UAH and others within a wide variety of sensor communities are in the process of building Process Models, Process Chains, documentation, and software in support of SensorML. Much of this will be Open Source, while some will be within Commercial Software. SensorML has been under consideration and testing by a wide range of communities, including those in the science, defense, intelligence, and public sectors.

A.2.2 Purpose and information coverage

SensorML has been designed for the following purposes:

• provide general sensor information in support of data discovery;
• support the processing and analysis of the sensor measurements;
• support the geographical location of the measured data;
• provide performance characteristics (e.g. accuracy, threshold, etc.);
• provide an explicit description of the process by which an observation was obtained (i.e. its provenance);
• provide an executable process chain for deriving;
• applies to in-situ or remote sensors and supports stationary or dynamic sensors, e.g.:
  • stationary, in-situ - chemical "sniffer", thermometer, strain gauge;
  • stationary, remote - stream velocity profiler, tripod-mounted camera, Doppler radar;
  • dynamic, in-situ - aircraft mounted ozone "sniffer", GPS unit, dropsonde;
  • dynamic, remote - satellite radiometer, airborne lidar (laser radar), soldier-mounted video.

Information provided by the Sensor Model Language covers:

• observation characteristics:

  • physical properties measured (e.g. radiometry, temperature, concentration, etc.);
  • quality characteristics (e.g. accuracy, precision);
  • response characteristics (e.g. spectral curve, temporal response, etc.);

• geometry characteristics:

  • size, shape, spatial weight function (e.g. point spread function) of individual samples;
  • geometric and temporal characteristics of sensor and sample collections (e.g. scans or arrays) that are required for metric exploitation;

• description and documentation:

  • overall information about the sensor;
  • history and reference information supporting the SensorML document.

A.2.3 Sensor aggregation concepts

A summary of the key SensorML concepts is as follows:

Detectors are typically simple devices (real or virtual) that take one input signal and generate one or more output signals. These are typically based on simple models that map the input values to output values. The methodology for each of these devices is fairly well defined and can be supported in software using a general model consisting of calibration curves and look-up-tables. In SensorML, these simpler atomic processes are defined as a ProcessModel, that is a detector is a particular type of Process Model.

Sensors typically consist of several such processes that can be linked in series or parallel resulting in a mapping from input to output that is better defined as a process chain. In other words, a sensor may consist several detectors, e.g. a frame camera or a complete airborne scanner is composed of multiple detectors. Other chains can be conceived that take inputs and through a series of individual processes generates new output values. In SensorML, these process chains, including sensors, are modelled as a ProcessChain. A process chain is itself a process, such that it can have inputs, outputs, and parameters, and can itself participate as part of a bigger process chain.

For most sensors of interest to the geospatial community, there is a need to relate the sensor observations to some temporal and spatial domain in order for them to be relevant. In SensorML, a process chain or a collection of process chains that can be related in space and time are modelled as a System. Thus, typically, a System defines a collection of sensors that are related spatially and temporally to one another, as well as related to some geospatial domain.

A.2.4 The SensorML model

A.2.4.1 Model structure

In SensorML, everything is modelled as a Process (abstract base class _Process). The ProcessModel derives all properties from the Process and adds a description of the process methodology through the method property. Thus the ProcessModel:

• defines atomic process modules (detector being one)
• has five sections
  • metadata (primarily for discovery and assistance, and not to be used within process execution)
  • referenceFrame
  • inputs, outputs, parameters (defined using SWE Common data definitions)
  • method

A.2.4.2 Base process model

Process models and process chains in SensorML are intended as serializations of executable components. Process models and chains are expected to be linkable, and these links are expected to be described within a process chain or system.

Abstract Base: _Process

_Process is the base for all processes in SensorML. All processes include inputs, outputs, and parameters.

In addition to inputs, outputs, and parameters, all processes in SensorML can provide several properties that, for the sake of clarity, have been collected within a metadataGroup. These data, while important for resource discovery, for qualification of results, and for assistance to humans, are not considered essential to the execution of the process within a process chain. Thus, all data or information required for actual execution of the process should be included within the inputs, outputs, and parameters properties. It is possible, and encouraged that those parameters desired for resource discovery be linked to or copied within the appropriate metadata section.

In addition to describing purely mathematical processes, SensorML is expected to describe processes that have some relationship to space and time. These might include transducers (detectors and actuators), sensor systems, samplers, and sensor platforms, for example. For much of the processing of sensor data, it is important that temporal and spatial reference frames be described and that the relationships between various reference frames be able to be explicitly defined. Therefore, _Process includes a referenceFrame property that expects a description of any spatial or temporal coordinate reference system that might be used for interrelating internal components within the process, as well as reference frames that might allow this component to be related to other components within a process chain or system. SensorML utilizes the Coordinate Reference System (CRS) models defined for GML. The referenceFrame property is optional and should thus not be included for processes where temporal or spatial state is meaningless.

ProcessModel derives all properties from the abstract base class _Process, and adds a description of the process methodology through the method property. ProcessModel is used to define more or less atomic processes that are expected to be used within more complex process chains. The method property provides the methodology by which one transforms input values to appropriate output values, based on the provided parameter values. The desire is that SensorML instances will define process chains that are self contained and executable without requiring apriori knowledge of complex processes. For this goal to be realized, SensorML-enabled software must understand how to execute the individual process models within a chain and, of course, support the flow of data between these process models according to the link defined within the process instance. A ProcessModel will thus typically use this URI to point to a method defined else where, rather than include the whole definition inline. The software can then decide to download the whole method definition again, or simply rely on the URI to find a local matching implementation.

The following example is for a Davis 7817 Thermometer used in a weather station. The inputs and outputs are simple, real temperature for input and resistance for output. There are two parameters for the ProcessModel: steadyStateResponse and accuracy. Both parameters use a NormalizedCurve temperature to resistance (for the steadyStateResponse) and temperature to absolute accuracy (for the accuracy response). The method for this ProcessModel is a general transducer method that has been defined elsewhere and is referenced here using the xlink:href association.

<ProcessModel xmlns="http://www.opengis.net/sensorML"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns:swe="http://www.opengis.net/swe"
              xmlns:xlink="http://www.w3.org/1999/xlink"
              xsi:schemaLocation="http://www.opengis.net/sensorML../base/sensorML.xsd"
              id="Davis_7817">

- metadata omitted for brevity =
       <!--~~~~~~~~~~~~~~~~~~~~~~~-->
       <!--Sensor Coordinate Frame-->
       <!--~~~~~~~~~~~~~~~~~~~~~~~-->

 <referenceFrame>
  <gml:EngineeringCRS id="SENSOR_FRAME">
   <gml:srsName>Sensor Frame</gml:srsName>
   <gml:usesCS xlink:href="urn:ogc:def:crs:ogc:1.0:xyzFrame"/>
   <gml:usesDatum>
    <gml:Datum>
     <gml:datumName>Sensor Datum</gml:datumName>
     <gml:anchorPoint>origin is at the tip of the thermometer;
       x and Y are orthogonal to z but undetermined
       z is along the long axis of symmetry of the thermometer
     </gml:anchorPoint>
    </gml:Datum>
   </gml:usesDatum>
  </gml:EngineeringCRS >
 </referenceFrame>

       <!--~~~~~~~~~~~~~-->
       <!--Sensor Inputs-->
       <!--~~~~~~~~~~~~~-->

 <inputs>
  <InputList>
   <input name="temperature">
    <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:temperature"/>
   </input>
  </InputList>
 </inputs>

       <!--~~~~~~~~~~~~~~-->
       <!--Sensor Outputs-->
       <!--~~~~~~~~~~~~~~-->

 <outputs>
  <OutputList>
   <output name="measuredTemperature">
    <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:resistance"/>
   </output>
  </OutputList>
 </outputs>

       <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
       <!--  Temperature Response  -->
       <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

 <parameters>
  <ParameterList>
   <steadyStateResponse>
    <NormalizedCurve fixed="true">
     <function>
      <swe:Curve arraySize="21">
       <swe:definition>
        <swe:Coordinates>
         <swe:axis name="temperature">
          <swe:Quantity id="TEMP1"
           definition="urn:ogc:def:phenomenon:ogc:1.0.3:temperature"
           uom="urn:ogc:unit:celsius"/>
         </swe:axis>
         <swe:axis name="resistance">
          <swe:Quantity id="RES"
           definition="urn:ogc:def:phenomenon:ogc:1.0.3:resistance"
           uom="urn:ogc:unit:ohm" scale="1e3"/>
         </swe:axis>
        </swe:Coordinates>
       </swe:definition>
       <swe:tupleValues>-40,328.4 -35,237.7 -30,173.9 -25,128.5 -20,95.89 -15,72.23
                        -10,54.89 -5,42.07 0,32.51 5,25.31 10,19.86 15,15.69 20,12.49 25,10 30,8.06
                         35,6.536 40,5.331 45,4.373 50,3.606 55,2.989 60,2.49
       </swe:tupleValues>
      </swe:Curve>
     </function>
    </NormalizedCurve>
   </steadyStateResponse>
   <accuracy>
    <NormalizedCurve fixed="true">
     <function>
      <swe:Curve arraySize="6">
       <swe:definition>
        <swe:Coordinates>
         <swe:axis name="temperature">
          <swe:Quantity id="TEMP2"
            definition="urn:ogc:def:phenomenon:ogc:1.0.3:temperature"
            uom="urn:ogc:def:unit:ogc:1.0.3:celsius"/>
         </swe:axis>
         <swe:axis name="absoluteError">
           <swe:Quantity id="ERR"
            definition="urn:ogc:data:quantity:absoluteAccuracy"
            uom="urn:ogc:def:unit:ogc:1.0.3:celsius"/>
         </swe:axis>
        </swe:Coordinates>
       </swe:definition>
       <swe:tupleValues>-40,0.0 -20,0.1 -10,0.2 0,0.3 10,0.4 20,0.5</swe:tupleValues>
      </swe:Curve>
     </function>
    </NormalizedCurve>
   </accuracy>
  </ParameterList>
 </parameters>

 <method xlink:href="urn:ogc:def:process:ogc:1.0.3:transducer"/>

</ProcessModel>

A.2.4.3 Composite Process (ProcessChain)

Whereas ProcessModel defines an atomic process that can be executed using algorithms or code defined by the method property, a ProcessChain defines a process chain where the chain itself defines the execution methodology. ProcessChain consists of a collection of other _Process elements while it is itself derived from _Process. In short, a ProcessChain has all the properties of a _Process, including inputs, outputs, parameters, and metadataGroup, but adds processes, data sources, and connections properties.

Since ProcessChain is itself of type _Process, a process chain in SensorML can take other process chains as components in addition to more atomic ProcessModel components.

In ProcessChain, the process chain is defined by first describing all of the processes and dataSources in the chain and then describing the appropriate connections between components. The most basic connection is a Link which merely provides references to the source and destination data components. The source is usually a data component within a data source or within a process OutputList. The destination data component is typically an input or parameter of a process. An additional connection, ArrayLink, allows one to specify source or destination references pointing either to a complete DataArray or to a particular element within a DataArray.

The following example defines a weather station that in this case, measures three phenomenon (temperature, wind speed, and wind direction), outputs the measured values for these phenomenon, as well as a calculated wind chill factor and a maximum temperature alert. The first part of this example defines the metadata (omitted), inputs, outputs, and parameters of the ProcessChain itself.

<ProcessChain xmlns="http://www.opengis.net/sensorML"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns:swe="http://www.opengis.net/swe"
              xmlns:xlink="http://www.w3.org/1999/xlink"
              xsi:schemaLocation="http://www.opengis.net/sensorML../../../base/ProcessChain.xsd"
              id="Weather_Station">

- metadata omitted for brevity

             <!--~~~~~~~~~~~~~-->
             <!--Process Inputs-->
             <!--~~~~~~~~~~~~~-->

 <inputs>
  <InputList>
   <input name="physicalPhenomena">
    <swe:DataGroup>
     <swe:component name="atmosphericTemperature">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:temperature"/>
     </swe:component>
     <swe:component name="wind">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:wind"/>
     </swe:component>
    </swe:DataGroup>
   </input>
  </InputList>
 </inputs>

             <!--~~~~~~~~~~~~~~-->
             <!--Process Outputs-->
             <!--~~~~~~~~~~~~~~-->

 <outputs>
  <OutputList>

             <!--~~~~~~~~~~~~~~~~~~-->
             <!--weather output cluster -->
             <!--~~~~~~~~~~~~~~~~~~-->

   <output name="weatherMeasurements">
    <swe:DataGroup id="outputDataGroup">
     <swe:component name="measuredTemperature">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:temperature"
       uom="urn:ogc:unit:celsius"/>
     </swe:component>
     <swe:component name="measuredWindSpeed">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:windSpeed"
       uom="urn:ogc:unit:metersPerSecond"/>
     </swe:component>
     <swe:component name="measuredWindDirection">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:windDirection"
       uom="urn:ogc:unit:degree"/>
     </swe:component>
     <swe:component name="windChill">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:windChill"
       uom="urn:ogc:unit:celsius"/>
     </swe:component>
    </swe:DataGroup>
   </output>

            <!--~~~~~~~~~~~~~~~~~~~~-->
            <!--temperature alert cluster  -->
            <!--~~~~~~~~~~~~~~~~~~~~-->

   <output name="maximumTemperatureAlert">
    <swe:DataGroup>
     <swe:component name="eventTime">
      <swe:IsoDateTime/>
     </swe:component>
     <swe:component name="measuredValue">
      <swe:Quantity definition="urn:ogc:def:alert:threshold"/>
     </swe:component>
    </swe:DataGroup>
   </output>
  </OutputList>
 </outputs>

             <!--~~~~~~~~~~~~~~-->
             <!--Process Parameters-->
             <!--~~~~~~~~~~~~~~-->

 <parameters>
  <ParameterList>
   <parameter name="maximumTemperatureThreshold">
    <swe:DataGroup>
     <swe:component name="comparisonCriteria">
      <swe:Category definition="urn:ogc:def:data:ogc:1.0.3:relationship"
       fixed="true">greaterThan</swe:Category>
     </swe:component>
     <swe:component name="maxThreshold">
      <swe:Quantity definition="urn:ogc:def:phenomenon:ogc:1.0.3:temperature"/>
     </swe:component>
    </swe:DataGroup>
   </parameter>
  </ParameterList>
 </parameters>

The second part of the example defines the processes that are a part of this process chain. These include three Transducers (thermometer and two components of the anemometer). In the full example, each of these transducer descriptions could include useful metadata, and would also include the response characteristics as part of the parameters, as shown in an earlier example.

In addition to the three transducers, the ProcessList includes two additional processes: one for calculating windchill based on the temperature and wind speed, and one for comparing temperature values against a maximum threshold value.

             <!--~~~~~~~~~~~-->
             <!--processes      -->
             <!--~~~~~~~~~~~-->

 <processes>
  <ProcessList>

             <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
             <!-- Description of Temperature Transducer -->
             <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <process name="thermometer">
    <Transducer id="Davis_7817">

             - details omitted for brevity -..

     <inputs>
      <InputList>
       <input name="temperature">
        <swe:Quantity definition="urn:ogc:phenomenon:temperature"/>
       </input>
      </InputList>
     </inputs>

     <outputs>
      <OutputList>
       <output name="measuredTemperature">
        <swe:Quantity definition="urn:ogc:phenomenon:temperature"/>
       </output>
      </OutputList>
     </outputs>

     <parameters>
      <ParameterList>
       <steadyStateResponse>

             - details omitted for brevity -

       </steadyStateResponse>
      </ParameterList>
     </parameters>

     <method xlink:href="urn:ogc:process:transducer"/>
    </Transducer>
   </process>

             <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
             <!-- Description of Wind Speed Transducer -->
             <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <process name="windSpeedTransducer">
    <Transducer id="windSpd_7911">

             - details omitted for brevity -

     <inputs>
      <InputList>
       <input name="windSpeed">
        <swe:Quantity definition="urn:ogc:phenomenon:speed"/>
       </input>
      </InputList>
     </inputs>

     <outputs>
      <OutputList>
       <output name="measuredWindSpeed">
        <swe:Quantity definition="urn:ogc:phenomenon:speed"/>
       </output>
      </OutputList>
     </outputs>

     <parameters>
      <ParameterList>
       <steadyStateResponse>

             - details omitted for brevity -

       </steadyStateResponse>
      </ParameterList>
     </parameters>

     <method xlink:href="urn:ogc:process:transducer"/>
    </Transducer>
   </process>

             <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
             <!-- Description of Wind Direction Transducer -->
             <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <process name="windDirectionTransducer">
    <Transducer id="windDir_7911">

             - details omitted for brevity -

     <inputs>
      <InputList>
       <input name="windDirection">
        <swe:Quantity definition="urn:ogc:phenomenon:direction"/>
       </input>
      </InputList>
     </inputs>

     <outputs>
      <OutputList>
       <output name="measuredWindDirection">
        <swe:Quantity definition="urn:ogc:phenomenon:direction"/>
       </output>
      </OutputList>
     </outputs>

     <parameters>
      <ParameterList>
       <steadyStateResponse>

              - details omitted for brevity -

       </steadyStateResponse>
      </ParameterList>
     </parameters>

     <method xlink:href="urn:ogc:process:transducer"/>
    </Transducer>
   </process>

              <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
              <!--Threshold Comparison Process  -->
              <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <process name="maxTempCompare">
    <ProcessChain id="ValueCompareProcess">
     <inputs>
      <InputList>
       <input name="value1">
        <swe:Quantity/>
       </input>
       <input name="value2">
        <swe:Quantity/>
       </input>
      </InputList>
     </inputs>

     <outputs>
      <OutputList>
       <output name="criteriaMet">
        <swe:Quantity/>
       </output>
       <output name="criteriaFailed">
        <swe:Quantity/>
       </output>
      </OutputList>
     </outputs>

     <parameters>
      <ParameterList>
       <parameter name="criteria">
        <swe:DataGroup>
         <swe:component name="comparisonCriteria">
          <swe:Category definition="urn:ogc:relationship"
           fixed="true">greaterThan</swe:Category>
         </swe:component>
         <swe:component name="maxThreshold">
          <swe:Quantity/>
         </swe:component>
        </swe:DataGroup>
       </parameter>
      </ParameterList>
     </parameters>

     <method xlink:href="urn:ogc:def:process:ogc:1.0.3:valueComparison"/>
    </ProcessChain>
   </process>

         <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
         <!--Wind Chill Process  -->
         <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <process name="windChill">
    <ProcessChain id="WindChillProcess">
     <inputs>
      <InputList>
       <input name="temperature">
        <swe:Quantity uom="urn:ogc:unit:celsius"/>
       </input>
       <input name="windSpeed">
        <swe:Quantity uom="urn:ogc:unit:metersPerSecond"/>
       </input>
      </InputList>
     </inputs>

     <outputs>
      <OutputList>
       <output name="windChill">
        <swe:Quantity uom="urn:ogc:unit:celsius"/>
       </output>
      </OutputList>
     </outputs>

     <method xlink:href="urn:ogc:process:windChillCalculation"/>
    </ProcessChain>
   </process>
  </ProcessList>
 </processes>

The last part of the ProcessChain example defines the connections between inputs, outputs, and parameters. The connection property uses a Link object to reference the source and destination of a connector.

To reference a particular data component inside of a ProcessChain, SensorML defines a syntax using property qnames as path components starting with at the base of the ProcessChain instance. Thus all path references will begin with either inputs, outputs, parameters, or processes, indicating those properties of the ProcessChain. A path only uses property names (lowerCamelCase elements) and not Object names. If the property has a value assigned to the name attribute, then that will be used in place of the element name.

For example, a reference to the first input component of the ProcessChain would be "inputs/physicalPhenomenon/temperature" while the reference to the input of the thermometer would be "processes/thermometer/inputs/temperature".

 <connections>
  <ConnectionList>

           <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
           <!-- process inputs to transducer inputs -->
           <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <connection name="inputToThermometer">
    <Link>
     <source ref="inputs/physicalPhenomena/temperature"/>
     <destination ref="processes/thermometer/inputs/temperature"/>
    </Link>
   </connection>
   <connection name="inputToWindSpeed">
    <Link>
     <source ref="inputs/physicalPhenomena/wind"/>
     <destination ref="processes/windSpeedTransducer/inputs/windSpeed"/>
    </Link>
   </connection>
   <connection name="inputToWindDirection">
    <Link>
     <source ref="inputs/physicalPhenomena/wind"/>
     <destination ref="processes/windDirectionTransducer/inputs/windDirection"/>
    </Link>
   </connection>

           <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
           <!-- transducer outputs to process outputs -->
           <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <connection name="outputToTemperature">
    <Link>
     <source ref="processes/thermometer/outputs/measuredTemperature"/>
     <destination ref="outputs/weatherMeasurement/measuredTemperature"/>
    </Link>
   </connection>
   <connection name="outputToWindSpeed">
    <Link>
     <source ref="processes/windSpeedTransducer/outputs/measuredWindSpeed"/>
     <destination ref="outputs/measuredWindSpeed"/>
    </Link>
   </connection>
   <connection name="outputToWindDirection">
    <Link>
     <source ref="processes/windDirectionTransducer/outputs/measuredWindDirection"/>
     <destination ref="outputs/measuredWindDirection"/>
    </Link>
   </connection>

          <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
          <!-- wind chill inputs and outputs -->
          <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <connection name="temperatureToWindChill">
    <Link>
     <source ref="processes/thermometer/outputs/measuredTemperature"/>
     <destination ref="processes/windChill/inputs/temperature"/>
    </Link>
   </connection>
   <connection name="windSpeedToWindChill">
    <Link>
     <source ref="processes/windSpeedTransducer/outputs/measuredWindSpeed"/>
     <destination ref="processes/windChill/inputs/windSpeed"/>
    </Link>
   </connection>
   <connection name="windChillToOutput">
    <Link>
     <source ref="processes/windChill/outputs/windChill"/>
     <destination ref="outputs/windChill"/>
    </Link>
   </connection>

         <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
         <!-- maxTemp threshold inputs, outputs, and parameters -->
         <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

   <connection name="temperatureToMax">
    <Link>
     <source ref="processes/thermometer/outputs/measuredTemperature"/>
     <destination ref="processes/maxTempCompare/inputs/value1"/>
    </Link>
   </connection>
   <connection name="maxTempToAlert">
    <Link>
     <source ref="processes/maxTempCompare/outputs/criteriaMet"/>
     <destination ref="outputs/maximumTemperatureAlert/measuredValue"/>
    </Link>
   </connection>
   <connection name="maxTempThreshold">
    <Link>
     <source ref="parameters/maximumTemperatureThreshold"/>
     <destination ref="processes/maxTempCompare/parameters/criteria"/>
    </Link>
   </connection>
  </ConnectionList>
 </connections>
</ProcessChain>

While connection references inside of a ProcessChain description may be challenging for humans to follow, they are simple for XML-aware software to parse. This syntax should also be easily implemented in future application software that will allow creation of SensorML instances using graphical interfaces.

A.2.4.4 System

A System is a process chain that includes positional information (spatial and temporal), allowing one to relate a process and its components to the real world. It thus inherits all the properties of the ProcessChain (as illustrated above). System also provides relative positions of its components as well as connectivity of the internal process chain to the real-world by including interface information.

The position property takes either a _PositionData object that explicitly defines a position, or a ProcessChain from which a position can be derived. A _PositionData object defines the position (location and orientation) of a local frame (identified by the localFrame attribute) relative to an external reference frame (defined by the referenceFrame attribute). The example below provides a location of a weather station to a longitude, latitude, and altitude based on a WGS84 Datum. The example then provides the location of the anemometer's referenceFrame relative to the weather station referenceFrame.

The localFrame and referenceFrame attributes both use a URI to reference the appropriate referenceFrame definitions. In the example, the station and anemometer reference frames would have both been defined within the appropriate process description, and would have been assigned id attribute values of "STATION_FRAME" and "ANEMOMETER_FRAME", respectively.

<SensorML xmlns="http://www.opengis.net/sensorML"
             xmlns:swe="http://www.opengis.net/swe"
             xmlns:gml="http://www.opengis.net/gml"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <System id="DAVIS_SIMPLE_STATION">
  <positions>
   <PositionList>

          <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
          <!-- Position of Station in Lat, Lon, Alt -->
          <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

    <position>
     <swe:Position localFrame="#STATION_FRAME"
      referenceFrame="urn:ogc:def:crs:EPSG:1.0:4329">
      <swe:location>
       <swe:Location definition="urn:ogc:phenomenon:location">
        <swe:coordinate name="x">
         <swe:Quantity uom="urn:ogc:unit:degree">34.72450</swe:Quantity>
        </swe:coordinate>
        <swe:coordinate name="y">
         <swe:Quantity uom="urn:ogc:unit:degree">-86.94533</swe:Quantity>
        </swe:coordinate>
        <swe:coordinate name="z">
         <swe:Quantity uom="urn:ogc:unit:meter">20.1169</swe:Quantity>
        </swe:coordinate>
       </swe:Location>
      </swe:location>
     </swe:Position>
    </position>

         <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
         <!-- Position of Anemometer relative to Station -->
         <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->

    <position>
     <swe:Position localFrame="#ANEMOMETER_FRAME"
      referenceFrame="#STATION_FRAME">
      <swe:location>
       <swe:Location definition="urn:ogc:phenomenon:location">
        <swe:coordinate name="x">
         <swe:Quantity uom="urn:ogc:unit:degree">0</swe:Quantity>
        </swe:coordinate>
        <swe:coordinate name="y">
         <swe:Quantity uom="urn:ogc:unit:degree">0</swe:Quantity>
        </swe:coordinate>
        <swe:coordinate name="z">
         <swe:Quantity uom="urn:ogc:unit:meter">3.0</swe:Quantity>
        </swe:coordinate>
       </swe:Location>
      </swe:location>
     </swe:Position>
    </position>
   </PositionList>
  </positions>
 </System>
</SensorML>

A.3 Conclusions for S-TEN

A.3.1 SensorML scope

SensorML is not concerned with actual measurements, but with describing a device which makes a measurement. S-TEN is concerned with both the devices and the measurements that they make.

A.3.2 SensorML principal objects

In the SensorML Conceptual Models, the 'top' object is _Process. ProcessChain inherits from _Process and System inherits from ProcessChain.

The term "process" usually implies an activity, and is mostly used in this sense in SensorML. But at times there seems to be a merging of an activity and a device which carries it out.

Within the process industry it is usual to distinguish between:

A.4 Reference