License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.



This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.


i. Abstract

The primary focus of the Sensor Model Language (SensorML) is to provide a robust and semantically-tied 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 post-measurement.

The main objective is to enable interoperability, first at the syntactic level and later at the semantic level (by using ontologies and semantic mediation), so that sensors and processes can be better understood by machines, utilized automatically in complex workflows, and easily shared between intelligent sensor web nodes.

This standard is one of several implementation standards produced under OGC’s Sensor Web Enablement (SWE) activity. This standard is a revision of content that was previously integrated in the SensorML version 1.0 standard (OGC 07-000).

ii.          Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, sensor, sensor web

iii.          Preface

This Standard arises from work originally undertaken through the Open Geospatial Consortium’s Sensor Web Enablement (SWE) activity. SWE is concerned with establishing interfaces and encodings that will enable a “Sensor Web” through which applications and services will be able to access sensors of all types, and observations generated by them, over the Web. SWE has defined, prototyped and tested several components needed for a Sensor Web, namely:

  • Sensor Model Language (SensorML)
  • Observations & Measurements (O&M)
  • Sensor Observation Service (SOS)
  • Sensor Planning Service (SPS)
  • SWE Common Data and Services

This Standard specifies models and an XML implementation for the SensorML.

This document deprecates and replaces the first version of OGC® Sensor Model Language (SensorML) Specification version 1.0.0 (OGC 07-000) and the SensorML Corrigendum version 1.0.1 (OGC 07-122r2).

The main changes of SensorML 2.0 from SensorML version 1.0.1 are:

  • The separation of SWE Common Data into a separate specification (OGC 07-094r1);
  • Improved derivation and association of SensorML from GML 3.2 and ISO 19115;
  • More explicit definition of the standard and its requirements;
  • Separation of SensorML into several conformance classes to allow software to support only the part of SensorML that is relevant to the application (e.g., non-physical processes only);
  • Improved support for inheritance, configuration, and modes (e.g., for describing a particular model of a sensor and then an instance of that sensor with particular configuration);
  • Improved explicit support for data streaming (associated with inputs, outputs, and parameters);
  • Addition of Feature of Interest for support of discovery;
  • Addition of extension points for domain or community-specific schema;
  • Improved support for defining position of both static and dynamic components and systems; and
  • Inclusion of DataInterface and DataStream as a possible input, output, or parameter value.

Additionally, much additional and improved functionality of SensorML has been gained through additions and improvements of the SWE Common Data Model specification. Thus, the following additions to SWE Common Data Model are reflected as improvements in SensorML v2.0:

  • A DataChoice component providing support for variable (multiplexed) data types;
  • The DataStream object improving support for real-time data streams;
  • The XMLBlock encoding providing support for simple XML encoded data;
  • Support for definition of NIL values and associated reasons;
  • The CategoryRange class to define ranges of ordered categorical quantities;
  • Extension points for domain or community-specific schema; and
  • Ability to provide security tagging of individual data components through the use of extension points.

Also, some elements of the SWE Common Data Model specification have been removed and replaced by their soft-typed equivalents defined using RelaxNG and/or Schematron. These include:

  • Position, SquareMatrix
  • SimpleDataRecord, ObservableProperty
  • ConditionalData, ConditionalValue
  • Curve, NormalizedCurve

The derivation from GML has also been improved by making all elements substitutable for GML AbstractValue (and thus transitively for GML AbstractObject) and AbstractFeature so that they can be used directly by GML application schemas. The GML encoding rules as defined in ISO 19136 have also been used to generate XML schemas from the UML models with only minor modifications.

This release is not fully backwards compatible with version 1.0.1 even though changes were kept to a minimum.

The main change of SensorML 2.1 from SensorML 2.0 is the addition of setEncodedValues in both the standard and in the XML implementation to provide a method to more concisely encode arrays, as compared to setArrayValues.

As this standard is XML-based, JSON implementations are ruled to be out of scope.  However, Alex Robin has developed a non-normative Best Practice for such implementations: OGC 07-011r2 – JSON Encoding Rules SWE Common / SensorML.

SensorML 2 is well-suited for describing sensor model imaging geometries – the SensorML 2.0 RFC contains examples of a frame camera sensor model based on the Community Standard Model from NGA (NGA.SIG.0002_2.1).  Additional (and more complete) sensor model descriptions are being compiled into a sensor model repository by the OGC Naming Authority, based on work by Gobe Hobona [OGC 18-042r3 (unpublished)].  In addition, work to connect OGC grid coverages to SensorML 2 that began in 2013 is now completed, which involved extending CIS 1.0 [OGC 09-146r2] via the ReferenceableGridCoverage Extension [OGC 16-083r3] to support SensorML 2 descriptions.  Version 2.1 of the GMLJP2 imagery standard [OGC 08-083r8] takes advantage of this coverage extension standard to support embedded and externally located SensorML 2 descriptions, thereby giving GMLJP2 the ability to support “raw” sensor model imagery.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv.          Security Considerations

No security considerations have been made for this standard

v.          Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

  • Botts Innovative Research, Inc.
  • Sensia Software LLC
  • Spot Image, S.A.
  • Seicorp, Inc.
  • US National Geospatial Intelligence Agency (NGA)
  • TASC

vi.          Submitters

All questions regarding this submission should be directed to the editor or the submitters:


Name Affiliation

Michael E. Botts

Botts Innovative Research, Inc.

Alexandre Robin

Sensia Software, LLC

Eric Hirschorn

Eric Hirschorn

1.    Scope

This standard defines models and XML Schema encoding for SensorML. The primary focus of SensorML is to provide a framework for defining processes and processing components associated with the measurement and post-measurement transformation of observations. Thus, SensorML has more of a focus on the process of measurement and observation, rather than on sensor hardware, yet still provides a robust means of defining the physical characteristics and functional capabilities of physical processes such as sensors and actuators.

The aims of SensorML are to:

  • Provide descriptions of sensors and sensor systems for inventory management;
  • Provide sensor and process information in support of asset and observation discovery;
  • Support the processing and analysis of the sensor observations;
  • Support the geolocation of observed values (measured data);
  • Provide performance and quality of measurement characteristics (e.g., accuracy, threshold, etc.);
  • Provide general descriptions of components (e.g., a particular model or type of a sensor) as well as the specific configuration of that component when its deployed;
  • Provide a machine interpretable description of the interfaces and data streams flowing in and out of a component;
  • Provide an explicit description of the process by which an observation was obtained (i.e., its lineage);
  • Provide an executable aggregate process for deriving new data products on demand (i.e., derivable products); and
  •  Archive fundamental properties and assumptions regarding sensor systems and computational processes


SensorML provides a common framework for any process, but is particularly well-suited for the description of sensor and systems and the processes surrounding sensor observations. Within SensorML, sensor and transducer components (detectors, transmitters, actuators, and filters) are all modeled as physical processes that can be connected and participate equally within a process network or system, and which utilize the same model framework as any other process.

Processes are entities that take one or more inputs and through the application of well-defined methods and configurable parameters and produce one or more outputs.  The process model defined in SensorML can be used to describe a wide variety of processes, including not only sensors, but also actuators, spatial transforms, and data processes, to name a few. SensorML also supports explicit linking between processes and thus supports the concept of process chains, networks, or workflows, which are themselves defined as processes using a composite pattern.

SensorML provides a framework within which the geometric, dynamic, and observational characteristics of sensors and sensor systems can be defined. There are a great variety of sensor types, from simple thermometers to complex electron microscopes and earth observing satellites. These can all be supported through the definition of simple and aggregate processes.

The models and schema within the core SensorML specification provide a “skeletal” framework for describing processes, aggregate processes, and sensor systems. Interoperability within and between various sensor communities, is greatly improved through the definition of shared community-specific semantics (within online dictionaries or ontologies) that can be utilized within the framework. In addition, the profiling of small, general-use, atomic processes that can serve as components within aggregate processes and systems is envisioned.

2.    Conformance

2.1    Overview

This standard has been written to be compliant with the OGC Specification Model – A Standard for Modular Specification (OGC 08-131r3). Extensions of this standard shall themselves be conformant to the OGC Specification Model.

This Standard defines conceptual models and an XML implementation of these models for describing non-physical and physical processes surrounding the act of measurement and subsequent processing of observations. The conceptual models are described using UML while the implementation is described using the XML Schema language and Schematron. It is envisioned that OWL (Web Ontology Language) and RDF (Resource Description Framework) versions could also be generated from the models if deemed useful and desired.

2.2    Specification identifier

All requirements-classes and conformance-classes described in this document are owned by the specification identified as

2.3    Conformance classes

The conformance rules are based on XML validation using the XML Schema representation of SensorML, together with processing of constraints expressed using Schematron assertions and reports.

Conformance with this specification shall be checked using all the relevant tests specified in Annex A. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in ISO 19105: Geographic information — Conformance and Testing. In order to conform to this OGC™encoding standard, a standardization target shall implement the core conformance class, and choose to implement any one or more of the other conformance classes.

The conformance rules for the XML implementation are based on XML validation using XML Schema representation of SensorML, together with processing constraints expressed using Schematron assertions and reports.


Table : Conformance classes related SensorML instances
Conformance class Description Clause

Core Concepts

Core Concepts


Conceptual Models:

Abstract Process


(Non-Physical) Simple Process


(Non-Physical) Aggregate Process


Physical Component


Physical System


Processes with Advanced Data Types


Configurable Process





XML Schema:

Core Process


(Non-Physical) Simple Process


(Non-Physical) Aggregate Process


Physical Component


Physical System


Configurable Process



Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site[1].

3.    References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

  • OGC 08-131r3 – The Specification Model – A Standard for Modular Specification, 2009
  • OGC 08-094r1 – SWE Common Data Model Encoding Standard, version 2.0, 2011
  • ISO/IEC 11404:2007 – General-Purpose Datatypes, 2007
  • ISO 8601:2004 – Representation of Dates and Times, 2004
  • ISO 19103:2005 – Conceptual Schema Language, 2005
  • ISO 19108:2002 – Temporal Schema, 2002
  • ISO 19111:2007 – Spatial Referencing by Coordinates, 2007
  • ISO 19115:2006 – All Metadata, 2006
  • Unified Code for Units of Measure (UCUM) – Version 2.1, Nov. 2011
  • Unicode Technical Std #18 – Unicode Regular Expressions, Version 19, Oct. 2016
  • The Unicode Standard, Version 10.0, December 2017
  • W3C Extensible Markup Language (XML) – Version 1.0 (4th Edition), 2006
  • W3C XML Schema – Version 1.0 (Second Edition), 2004
  • IEEE 754:2008 – Standard for Binary Floating-Point Arithmetic, 2008
  • IETF RFC 2045 – Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, 1996
  • IETF RFC 5234 – Augmented BNF for Syntax Specifications: ABNF, 2008

4.    Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply.

4.1            Actuator

A type of transducer that converts a signal to some real-world action or phenomenon.

4.2            Aggregate Process

Composite process consisting of interconnected sub-processes, which can in turn be Simple Processes or themselves Aggregate Processes. An aggregate process can include possible data sources. A description of an aggregate process should explicitly define connections that link input and output signals of sub-processes together. Since it is a process itself, an aggregate process also has its own inputs, outputs and parameters.

4.3            Coordinate Reference System (CRS)

A spatial or temporal framework within which a position and/or time can be defined. According to ISO 19111, a coordinate system that is related to the real world by a datum.

4.4            Coordinate System (CS)

According to ISO19111, a set of (mathematical) rules for specifying how coordinates are assigned to points. In this document, a Coordinate System is extended to be defined as a set of axes with which location and orientation can be defined.

4.5            Data Component

Element of sensor data definition corresponding to an atomic or aggregate data type

Note: A data component is a part of the overall dataset definition. The dataset structure can then be seen as a hierarchical tree of data components.

4.6            Datum

Undefined in ISO 19111. Defined here as a means of relating a coordinate system to the real world by specifying the physical location of the coordinate system and the orientation of the axes relative to the physical object. For a geodetic datum, the definition also includes a reference ellipsoid that approximates the physical or gravitational surface of the planetary body.

4.7            Detector

Atomic part of a composite Measurement System defining sampling and response characteristic of a simple detection device. A detector has only one input and one output, both being scalar quantities. More complex Sensors, such as a frame camera, which are composed of multiple detectors, can be described as a detector group or array using a System or Sensor model.

4.8            Determinand

A Parameter or a characteristic of a phenomenon subject to observation. Synonym for observable.[O&M]

4.9            Feature

Abstraction of real-world phenomena [ISO 19101:2002, definition 4.11]

Note:    A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant.

4.10         Location

A point or extent in space relative to a coordinate system. For point-based systems, this is typically expressed as a set of n-dimensional coordinates within the coordinate system. For bodies, this is typically expressed by relating the translation of the origin of an object’s local coordinate system with respect to the origin of an external reference coordinate system.

4.11         Location Model

A model that allows one to locate objects in one local reference frame relative to another reference frame.

4.12         Measurand

Physical parameter or a characteristic of a phenomenon subject to a measurement,whose value is described using a Measure (ISO 19103). Subset of determinand or observable. [O&M]

4.13         Measure (noun)

Value described using a numeric amount with a scale or using a scalar reference system  [ISO/TS 19103]. When used as a noun, measure is a synonym for physical quantity

4.14         Measurement (noun)

An observation whose result is a measure [O&M]

4.15         Measurement (verb)

An instance of a procedure to estimate the value of a natural phenomenon, typically involving an instrument or sensor.  This is implemented as a dynamic feature type, which has a property containing the result of the measurement.  The measurement feature also has a location, time, and reference to the method used to determine the value.  A measurement feature effectively binds a value to a location and to a method or instrument. 

4.16         Muliplexed Data Stream

A data stream that consists of disparate but well-defined data packets within the same stream.

4.17         Observable, Observable Property (noun)

A parameter or a characteristic of a phenomenon subject to observation. Synonym for determinand.[O&M]

A physical property of a phenomenon that can be observed and measured (e.g., temperature, gravitational force, position, chemical concentration, orientation, number-of-individuals, physical switch status, etc.), or a characteristic of one or more feature types, the value for which must be estimated by application of some procedure in an observation. It is thus a physical stimulus that can be sensed by a detector or created by an actuator.

4.18         Observation

Act of observing a property or phenomenon [ISO/DIS 19156, definition 4.10]

Note:     The goal of an observation may be to measure, estimate or otherwise determine the value of a property.


4.19         Observation Procedure

Method, algorithm or instrument, or system of these which may be used in making an observation [ISO/DIS 19156, definition 4.11]

Note: In the context of the sensor web, an observation procedure is often composed of one or more sensors that transform a real world phenomenon into digital information, plus additional processing steps.

4.20         Observed Value

A value describing a natural phenomenon, which may use one of a variety of scales including nominal, ordinal, ratio and interval.  The term is used regardless of whether the value is due to an instrumental observation, a subjective assignment or some other method of estimation or assignment.  [O&M]

4.21         Orientation

The rotational relationship of an object relative to an external coordinate system. Typically expressed by relating the rotation of an object’s local coordinate axes relative to those axes of an external reference coordinate system.

4.22         Phenomenon

A physical state that can be observed and its properties measured.

4.23         Physical System

An aggregate model of a group or array of process components, which can include detectors, actuators, or sub-systems.  A Physical System relates an Aggregate Process to the real world and therefore provides additional definitions regarding relative positions of its components and communication interfaces.

4.24         Position

The location and orientation of an object relative to an external coordinate system. For body-based systems (in lieu of point-based systems) is typically expressed by relating the object’s local coordinate system to an external reference coordinate system. This definition is in contrast to some definitions (e.g., ISO 19107) which equate position to location.

4.25         Process

An operation that takes one or more inputs, and based on a set of parameters, and a methodology generates one or more outputs.

4.26         Process Method

Definition of the algorithm, behaviour, and interface of a Process.

4.27         Property

Facet or attribute of an object referenced by a name

[ISO/DIS 19143:2010]

Example          : Abby’s car has the color red, where “color” is a property of the car instance, and “red” is the value of that property.

4.28         Reference Frame

A coordinate system by which the position (location and orientation) of an object can be referenced.

4.29         Result

An estimate of the value of some property generated by a known procedure [O&M]

4.30         Sample

A representative subset of the physical entity on which an observation is made.

4.31         Sensor

An entity capable of observing a phenomenon and returning an observed value. Type of observation procedure that provides the estimated value of an observed property at its output.

Note: A sensor uses a combination of physical, chemical or biological means in order to estimate the underlying observed property. At the end of the measuring chain electronic devices often produce signals to be processed.

4.32         Sensor Model

In line with traditional definitions of the remote sensing community, a sensor model is a type of Location Model that allows one to georegister or co-register observations from a sensor (particularly remote sensors).

4.33         Sensor Data

List of digital values produced by a sensor that represents estimated values of one or more observed properties of one or more features.

Note: Sensor data is usually available in the form of data streams or computer files.

4.34         Sensor-Related Data

List of digital values produced by a sensor that contains ancillary information that is not directly related to the value of observed properties

Example: sensor status, quality of measure, quality of service, battery life, etc. Such data can be sent in the same data stream with measured values and when measured is sometimes indistinguishable from sensor data.

4.35         (Sensor) Platform

An entity to which can be attached sensors or other platforms. A platform has an associated local coordinate reference frame that can be referenced relative to an external coordinate reference frame and to which the reference frames of attached sensors and platforms can be referenced.

4.36         Transducer

An entity that receives a signal as input and generates a modified signal as output. Includes detectors, actuators, and filters.

4.37         Value

A member of the value-space of a datatype. A value may use one of a variety of scales including nominal, ordinal, ratio and interval, spatial and temporal. Primitive datatypes may be combined to form aggregate datatypes with aggregate values, including vectors, tensors and images [ISO11404].

5.    Conventions

5.1    Abbreviated terms

In this document the following abbreviations and acronyms are used or introduced: 

CRS              Coordinate Reference System
DN Digital Number
ECEF            Earth-Centered Earth-Fixed
ECI Earth Centered Inertial
GPS               Global Positioning System
ISO International Organization for Standardization
MISB            Motion Imagery Standards Board
OGC              Open Geospatial Consortium
SAS               Sensor Alert Service
SensorML     Sensor Model Language
SI   Système International (International System of Units)
SOS               Sensor Observation Service
SPS               Sensor Planning Service
SWE              Sensor Web Enablement
TAI               Temps Atomique International (International Atomic Time)
uom               Unit(s) of measure
UCUM          Unified Code for Units of Measure
UML             Unified Modeling Language
UTC              Coordinated Universal Time
XML             eXtended Markup Language
1D  One Dimensional
2D  Two Dimensional
3D  Three Dimensional

5.2    UML notation

The diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram.  The UML notations used in this standard are described in the diagram below.

UML Notation
Figure : UML Notation

5.3    Table notation used to express requirements

For clarity, each normative statement in this standard is in one and only one place and is set in a bold font within the tabular format shown below. If the statement of the requirement is repeated for clarification, the “bold font” home of the statement is considered the official statement of the normative requirement. Individual requirements are clearly highlighted and identified throughout the document by using tables and URL identifiers of the following format:


Req N. Textual description of requirement.

In this standard, all requirements are associated to tests in the abstract test suite in Annex A. The reference to the requirement in the test case is done by its URL.

Requirements classes are separated into their own clauses and named and specified according to inheritance (direct dependencies). The Conformance test classes in the test suite are similarly named to establish an explicit and mnemonic link between requirements classes and conformance test classes. There are formally identified by URL and described within a tabular format as shown below:

Requirements Class{req-class-name}

Target Type

Description of standardization target type


Examples will be indicated using a grey text box and are considered to be informative rather than normative:


Example This is an example text box that will include informative notes and examples.

6.    Requirements Class: Core Concepts (normative core)

Requirements Class

Target Type

Derived Model, Encoding, and Software Implementation

6.1    Introduction

In SensorML, all components are modeled as processes. This includes components normally viewed as hardware, such as detectors, actuators, and physical processors (which are viewed as physical components) and sensors and platforms (which are viewed as physical systems). All components are modeled as processes that receive input and through the application of an algorithm defined by a method and set parameter values, generate output. All such components can therefore participate in process networks (or aggregate processes). Aggregate processes are themselves processes with their own inputs, outputs, and parameters.

Hence, SensorML can be viewed as a specialized process description language with an emphasis on application to sensor data. Process descriptions in SensorML are agnostic of the environment in which they might be executed, or the protocol by which data is exchanged between process execution modules.

In order to support the use of SensorML within specialized applications (e.g., processing centers or image processing software), the SensorML models and encodings have been divided into several conformance classes. Thus, if one wishes to use SensorML for computation processes only, the software only needs to conform to the requirements for non-physical processes. Similarly, by only adhering to the Simple Process conformance class, a piece of software can describe internal processes using SensorML while supporting chaining of these processes in a proprietary way.

However, all derived model and encodings based on SensorML must implement the core concepts of SensorML, regardless of whether they deal strictly with non-physical computational processes or sensor systems.

Requirement 1

Req 1.    Any derived model or encoding shall correctly implement the modeling concepts defined in the core of this specification.

6.2    Process Definitions

In SensorML, all relevant components are modeled as processes, including both computation and physical processes (e.g., detectors, actuators, and sensor systems). Processes in SensorML are conceptually divided into two types: (1) those that are physical processes, such as detectors, actuators, and sensor systems, where information regarding their positions may be relevant, and (2) non-physical or “pure” processes which can be treated as merely mathematical operations or functions.

Example For a process representing the standard linear equation, x would be the input, m and b the parameters, y the output, and the equation y = mx + b would define the methodology. For a detector, the input would typically be a physical stimulus (or observable property), the parameters might include a calibration curve and other factors that affect the measurement, and the output would be a digital number representing some quantity representation of that observed property.

Fundamentally, a process is a physical or computational operation that may receive input and based on configurable parameters and a methodology, generate output.


Inputs and outputs may be digital numbers or physical stimuli (i.e., observable properties of the environment). Parameters can be variable or constant, but they don’t typically vary at the same frequency as the input values. In essence, however, parameters can be viewed as just another input into the process that is either fixed or changes less frequently than inputs

A process can consist of a single atomic operation, or an explicitly defined network of operations (e.g., an aggregate process or system). 

Any process must have a definable method of operation. In the case of an aggregate process or physical system, the explicit description of the process components and the flow of data between them will itself serve as the process methodology.

Requirement 2

Req 2.    The core model for a process shall define inputs, outputs, parameters, and methodology of that process.


Any process description must provide a unique ID that can be used for discovery of that process and for retrieving the definition of that process.

Requirement 3

Req 3.    The core model for a process shall include a unique ID for distinguishing that process from all others.


To be useful, the core process model shall include metadata about the process that aid in identification, discovery, and qualification of the process but do not themselves affect the execution of the process.

Requirement 4

Req 4.    The core model for a process shall include metadata that support identification, discovery, and qualification of the process.


Requirement 5

Req 5.    The metadata descriptions for a process shall not be required for successful execution of that process. All information required for execution of a simple process shall be contained within the inputs, outputs, parameters, and methodology descriptions of the process.

Process definitions can support general representations of a process or a specific instance of a process.

Example A general process for the linear equation would define the allowable inputs, outputs, and parameters. A specific instance of the process might define constant values for the parameters. An example of a general physical process would be the manufacturer’s description of the characteristics and configurable options for a particular model of a sensor (i.e., one that describes the common characteristics of all instances of that model of sensor). The description of a specific instance of that model of sensor would include information that is relevant to that particular instance of the sensor (e.g., serial number, owner’s name, location, etc.).


7.    UML Conceptual Models (normative)

This standard defines normative UML models with which derived encoding models as well as all future separate extensions should be compliant. The standardization target type for the UML requirements classes defined in this clause is thus a software implementation or an encoding model that directly implements the conceptual models defined in this standard.

7.1    Package Dependencies

The packages defined by the SensorML Model and their dependencies are shown in figure below:

Internal Package Dependencies
Figure : Internal Package Dependencies

SensorML also has dependencies on several external packages defined within other standards, namely GML 3.2, ISO 19103, ISO 19108, ISO 19111, and ISO 19115, as described below.

7.1.1    Dependency on GML Feature Model and ISO TC 211 Models

A process represents a feature type as defined by the ISO General Feature Model and is thus modeled as an instance of the <<metaclass>> GF_FeatureType (ISO 19109:2006). These models are further refined within the GML 3.2 standard (ISO 19136) which will provide the basis for XML encodings in the following section 8 of this specification document. This association of SensorML process with GML primarily brings recognition of SensorML processes as features and provides important identity properties.

External Package Dependencies – GML
Figure : External Package Dependencies – GML

The base feature classes in GML from which all processes in SensorML derive include AbstractGML and AbstractFeature, as shown in the figure below:

Models for dependent GML Feature classes
Figure : Models for dependent GML Feature classes

SensorML is dependent on ISO 19108:206 for Temporal Schema. In particular, the temporal elements, TM_Instant and TM_Period are used within the core SensorML model for Abstract Process. Additionally, SensorML depends on ISO 19115 for general metadata elements.

External Package Dependencies – ISO TC 211
Figure : External Package Dependencies – ISO TC 211

The SensorML standard utilizes the ISO 19115 models for common metadata properties such as citations, online resources, responsible party, and constraints. While Version 1.0 of SensorML defined encoding based on the ISO 19115 models, this version utilizes these models directly.

ISO 19115 Models for dependent classes.
Figure : ISO 19115 Models for dependent classes.


7.1.2    Dependency on SWE Common Data Models

In particular, SensorML is heavily dependent on the SWE Common Data Model standard for defining inputs, outputs, and parameters, as well as for specifying characteristics, capabilities, interfaces, and event properties. The SWE Common Data Models, which were originally defined within the version 1.0 SensorML specification, are in version 2.1 defined as a separate specification and are utilized throughout the SWE family of encoding and web service specifications.

External Package Dependencies – SWE Common Data
Figure : External Package Dependencies – SWE Common Data

The SWE Common specification provides a flexible yet robust means of defining data types and data values, including support for simple data types such as Quantity, Boolean, Category, Count, Text, and Time, as well as aggregate data such as DataRecord, DataArray, Vector, and Matrix. Additionally, SWE Common supports the concept of DataChoice, which will be utilized by SensorML for providing multiplexed messages in data streams and configurable options for processes and physical systems.

The data models in SWE Common provide additional properties than are provided by basic data types, including for example, units of measure (uom), quality indications, allowable constraints, significant digit counts, and in particular, the meaning and semantics of a data component. Both simple and aggregate data components in SWE Common allow for unambiguous definition of that data component through a resolvable link to an online dictionary or ontology. The definition of the SWE Common Data Models can be found in OGC 08-094r1.

The main objective of SWE Common Data Models is to achieve interoperability, first at the syntactic level, and later at the semantic level (by using ontologies and semantic mediation) so that sensor data can be better understood by machines, processed automatically in complex workflows, and easily shared between intelligent sensor web nodes.

SensorML depends heavily on the AbstractDataComponent element defined in SWE Common. This element serves as the base component from which all relevant data types in SWE Common are derived, including Quantity, Count, Category, Boolean, Text, DataRecord, DataArray, Vector, Matrix, and DataChoice. AbstractDataComponent thus serves as a substitution group that any of these data types can satisfy. AbstractSWEIdentifiable will serve as the basis for the ObservableProperty element defined in this specification (Section 7.2.1).

The model for the SWE Common AbstractDataComponent is given in the figure below: