Short description of the SensorML standard

The OGC Sensor Modeling Language (SensorML) provides means of defining processes and processing components associated with the measurement and post-measurement transformation of observations. This includes sensors and actuators as well as computational processes applied pre- and postmeasurement. The main objective is to enable interoperability so that sensors and processes can be better understood by machines, utilized automatically in complex workflows, and easily shared between intelligent sensor web nodes. Information about sensors which are queried from a Sensor Observation Service (SOS) are typically encoded using the SensorML data model and format.

The Role of SensorML in SDDI

Currently, the Sensor Observation Service is in use in the SSD district London QEOP. The SOS facades has been set up for the following two sensors:

  • Weather stations - The weather stations are set up and operated by Intel UK and measure in total 15 properties in the park including temperature, humidity, wind speed etc. The observations are recorded every minute.
  • Smart Meters - The "fake" smart meters for 3 buildings have been set up by TUM, which measure electricity and gas consumption for the buildings every 30 minutes.

Information about all the registered sensors can be queried using a Sensor Observation Service (SOS) with the help of the DescribeSensor operation. The response of this operation is encoded in the SensorML instance document.

More details about the implementations can be found here.

SensorML components

To be useful, a sensor description should at a minimum tell "what it measures" and "where it is". Since a sensor in SensorML is simply a physical process that outputs a measurement, then "what it measures" is provided in the sml:outputs element. "Where it is" is provided by the sml:position element. SensorML uses the OGC SWE Common Data specification for describing data within inputs, outputs, parameters, capabilities, and characteristics. The swe:Quantity element requires that one reference an online resolvable definition of the Quantity in order to be very specific about what is being measured and to provide some chance for interoperability between various sensor communities.

The different components of a SensorML document have been described as follows:

Header

The header information defines the schema and namespaces for the response of DescribeSensor operation.

Header 
<swes:DescribeSensorResponse xmlns:swes="http://www.opengis.net/swes/2.0" 
                             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                             xmlns:gml="http://www.opengis.net/gml/3.2" 
                             xmlns:xlink="http://www.w3.org/1999/xlink" 
                             xsi:schemaLocation="http://www.opengis.net/gml 
                                                 http://schemas.opengis.net/gml/3.1.1/base/gml.xsd 
                                                 http://www.opengis.net/swe/1.0.1 
                                                 http://schemas.opengis.net/sweCommon/1.0.1/swe.xsd 
                                                 http://www.opengis.net/swes/2.0 
                                                 http://schemas.opengis.net/swes/2.0/swesDescribeSensor.xsd 
                                                 http://www.opengis.net/gml/3.2 
                                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd 
                                                 ttp://www.opengis.net/sensorML/1.0.1 
                                                 http://schemas.opengis.net/sensorML/1.0.1/sensorML.xsd">
    <swes:procedureDescriptionFormat>http://www.opengis.net/sensorML/1.0.1</swes:procedureDescriptionFormat>
    ....
    ....
</swes:DescribeSensorResponse>


Description

swe:description encodes all the relevant information and metadata about sensors.

SensorDescription 
<swes:description>
    <swes:SensorDescription>
        <swes:validTime>...</swes:validTime>
        <swes:data>
            <sml:SensorML xmlns:sml="http://www.opengis.net/sensorML/1.0.1" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:gml="http://www.opengis.net/gml" version="1.0.1">
                <sml:member>
                    <sml:System>
                        <!-- optional; generated if not present -->
                        <sml:keywords>...</sml:keywords>
                        <sml:identification>...</sml:identification>
                        <sml:validTime>...</sml:validTime>
                        <sml:capabilities name="featuresOfInterest">...</sml:capabilities>
                        <sml:capabilities name="offerings">...</sml:capabilities>
                        <sml:contact>...</sml:contact>
                        <sml:position name="sensorPosition">...</sml:position>
                        <sml:inputs>...</sml:inputs>
                        <sml:outputs>...</sml:outputs>
                    </sml:System>
                </sml:member>
            </sml:SensorML>
        </swes:data>
    </swes:SensorDescription>
</swes:description>


Keywords

sml:keywords property provides for a list of keywords that might assist one in discovering this particular object (process, sensor, etc.). The sml:KeywordList element has an optional codespace attribute which can be used to reference, through a resolvable URL, a specific online dictionary or collection of terms from which these keywords can be selected.

Keywords 
<sml:keywords>
    <sml:KeywordList>
        <sml:keyword>DHT22_Sensor</sml:keyword>
        <sml:keyword>
            DHT22 Sensor attached to an ESP201 (ESP8266 based microcontroller)
        </sml:keyword>
        <sml:keyword>DHT22_Sensor_Munich</sml:keyword>
        <sml:keyword>Humidity_DHT22</sml:keyword>
        <sml:keyword>Offering_DHT22</sml:keyword>
        <sml:keyword>Temperature_DHT22</sml:keyword>
    </sml:KeywordList>
</sml:keywords>


Identifiers

Identifiers in SensorML are primarily used for search and discovery. Identifiers are names and numbers that taken together might uniquely identify the object. These might include, for example, a long and short name, the manufacturer's name, the model number, serial number, or other various IDs (tail ID, tag number, license number, etc.).

Sensor Identifiers 
<sml:identification>
    <sml:IdentifierList>
        <sml:identifier name="uniqueID">
            <sml:Term definition="urn:ogc:def:identifier:OGC:1.0:uniqueID">
                <sml:value>DHT22_Sensor</sml:value>
            </sml:Term>
        </sml:identifier>
        <sml:identifier name="longName">
            <sml:Term definition="urn:ogc:def:identifier:OGC:1.0:longName">
                <sml:value>
                    DHT22 Sensor attached to an ESP201 (ESP8266 based microcontroller)
                </sml:value>
            </sml:Term>
        </sml:identifier>
        <sml:identifier name="shortName">
            <sml:Term definition="urn:ogc:def:identifier:OGC:1.0:shortName">
                <sml:value>DHT22_Sensor</sml:value>
            </sml:Term>
        </sml:identifier>
    </sml:IdentifierList>
</sml:identification>


Capabilities

capabilities describe many of the properties that we might wish to know about a sensor, actuator, or process. These properties can be used for discovery but are often more important for understanding the nature of the object and for qualifying the output. In this example, featureOfInterest and Offerings have been defined for discovering the sensor.

featureOfInterest 
<sml:capabilities name="featuresOfInterest">
    <swe:SimpleDataRecord>
        <swe:field name="featureOfInterestID">
            <swe:Text definition="http://www.opengis.net/def/featureOfInterest/identifier">
                <swe:value>DHT22_Sensor_Munich</swe:value>
            </swe:Text>
        </swe:field>
    </swe:SimpleDataRecord>
</sml:capabilities>
Offerings 
<swe:SimpleDataRecord>
    <swe:field name="Offering_DHT22">
        <swe:Text definition="http://www.opengis.net/def/offering/identifier">
            <gml:name codeSpace="eng">Offering_DHT22</gml:name>
            <swe:value>Offering_DHT22</swe:value>
        </swe:Text>
    </swe:field>
</swe:SimpleDataRecord>


Contact Information

sml:contact allows providing the contact details of the owner/responsible person of sensors.

Contact Information 
<sml:contact>
    <sml:ContactList>
        <sml:member>
            <sml:ResponsibleParty>
                <sml:individualName>Bruno Willenborg</sml:individualName>
                <sml:organizationName>TUM - GI III - SOS</sml:organizationName>
                <sml:positionName>Research associate</sml:positionName>
                <sml:contactInfo>
                    <sml:phone>
                        <sml:voice>+49 89 298-22973</sml:voice>
                    </sml:phone>
                    <sml:address>
                        <sml:deliveryPoint>Arcisstr. 21</sml:deliveryPoint>
                        <sml:city>Munich</sml:city>
                        <sml:postalCode>80333</sml:postalCode>
                        <sml:country>Germany</sml:country>
                        <sml:electronicMailAddress>b.willenborg@tum.de</sml:electronicMailAddress>
                    </sml:address>
                    <sml:onlineResource xlink:href="https://wiki.tum.de/x/_47DAQ"/>
                </sml:contactInfo>
            </sml:ResponsibleParty>
        </sml:member>
    </sml:ContactList>
</sml:contact>


Sensor Position

In order to support a wide variety of needs for providing location, orientation, and dynamic state of a physical component or system, there are several means for specifying "where". These include byDescription, byPoint, byLocation, byState, byTrajectory, and byProcess. For a static location (as shown in this example) where orientation is irrelevant, we may use a swe:Vector to provide a 2D or 3D location. The swe:Vector element allows one to specify the location relative to a geospatial reference frame (e.g. SRS 4326) or relative to the spatial reference frame of another physical component (e.g. the platform). 

Sensor position 
<sml:position name="sensorPosition">
    <swe:Position referenceFrame="urn:ogc:def:crs:EPSG::4326">
        <swe:location>
            <swe:Vector gml:id="STATION_LOCATION">
                <swe:coordinate name="easting">
                    <swe:Quantity axisID="x">
                        <swe:uom code="degree"/>
                        <swe:value>11.5736231</swe:value>
                    </swe:Quantity>
                </swe:coordinate>
                <swe:coordinate name="northing">
                    <swe:Quantity axisID="y">
                        <swe:uom code="degree"/>
                        <swe:value>48.1499762</swe:value>
                    </swe:Quantity>
                </swe:coordinate>
                <swe:coordinate name="altitude">
                    <swe:Quantity axisID="z">
                        <swe:uom code="m"/>
                        <swe:value>52.0</swe:value>
                    </swe:Quantity>
                </swe:coordinate>
            </swe:Vector>
        </swe:location>
    </swe:Position>
</sml:position>


Input and Output

sml:input and sml:output elements define the properties which are measured by processes.

Inputs 
<sml:inputs>
    <sml:InputList>
        <sml:input name="observable_property_DHT22">
            <swe:ObservableProperty definition="observable_property_DHT22"/>
        </sml:input>
    </sml:InputList>
</sml:inputs>
Outputs 
<sml:outputs>
    <sml:OutputList>
        <sml:output name="Temperature_DHT22">
            <swe:Quantity definition="Temperature_DHT22">
                <swe:uom code="Celsius"/>
            </swe:Quantity>
        </sml:output>
        <sml:output name="Humidity_DHT22">
            <swe:Quantity definition="Humidity_DHT22">
                <swe:uom code="Percent"/>
            </swe:Quantity>
        </sml:output>
    </sml:OutputList>
</sml:outputs>

Standard Specification

Specification documents: http://www.opengeospatial.org/standards/sensorml

Implementations / Products

The following selection of products was made by the SDDI team and includes those implementations which are (or likely will be) used in the SSD project and from which we know that they are compatible with the requirements of the Smart Sustainable Data Infrastructure. Please note that the list is not a complete list of available or suitable SensorML implementations. The Open Geospatial Consortium provides a catalog of implementations of their standards which can be found at http://www.opengeospatial.org/resource. Note that also the OGC list is not complete and not necessarily completely up-to-date.

  • Name, Type (commercial, Open Source), Link, Short Description, used in which districts?

Additional Information

to be provided

  • Keine Stichwörter