SensorML is an approved Open Geospatial Consortium standard and an XML encoding for describing sensors and measurement processes. SensorML can be used to describe a wide range of sensors, including both dynamic and stationary platforms and both in-situ and remote sensors.
Functions supported include.
Examples of supported sensors are
SensorML provides standard models and an XML encoding for describing any process, including the process of measurement by sensors and instructions for deriving higher-level information from observations. It provides a provider-centric view of information in a sensor web, which is complemented by Observations and Measurements which provides a user-centric view.
Processes described in SensorML are discoverable and executable. All processes define their inputs, outputs, parameters, and method, as well as provide relevant metadata. SensorML models detectors and sensors as processes that convert real phenomena to data.
SensorML doesn't encode measurements taken by sensors; measurements can be represented in Transducer ML, as observations in Observations and Measurements, or in other forms, such as IEEE 1451.
Electronic Specification Sheet -
In its simplest application, SensorML can be used to provide a standard digital means of providing specification sheets for sensor components and systems.
Discovery of sensor, sensor systems, and processes -
SensorML is a means by which sensor systems or processes can make themselves known and discoverable. SensorML provides a rich collection of metadata that can be mined and used for discovery of sensor systems and observation processes. This metadata includes identifiers, classifiers, constraints (time, legal, and security), capabilities, characteristics, contacts, and references, in addition to inputs, outputs, parameters, and system location.
Lineage of Observations -
SensorML can provide a complete and unambiguous description of the lineage of an observation. In other words, it can describe in detail the process by which an observation came to be from acquisition by one or more detectors to processing and perhaps even interpretation by an analyst. Not only can this provide a confidence level with regard to an observation, in most cases, part or all of the process could be repeated, perhaps with some modifications to the process or by simulating the observation with a known signature source.
On-demand processing of Observations -
Process chains for geolocation or higher-level processing of observations can be described in SensorML, discovered and distributed over the web, and executed on-demand without a prior knowledge of the sensor or processor characteristics. This was the original driver for SensorML, as a means of countering the proliferation of disparate, stovepipe systems for processing sensor data within various sensor communities. SensorML also enables the distribution of processing to any point within the sensor chain, from sensor to data center to the individual user's PDA. SensorML enables this processing without the need for sensor-specific software.
Support for tasking, observation, and alert services -
SensorML descriptions of sensor systems or simulations can be mined in support of establishing OGC Sensor Observation Services (SOS), Sensor Planning Services (SPS), and Sensor Alert Services (SAS). SensorML defines and builds on common data definitions that are used throughout the OGC Sensor Web Enablement (SWE) framework.
Plug-N-Play, auto-configuring, and autonomous sensor networks -
SensorML enables the development of plug-n-play sensors, simulations, and processes, which may be seamlessly added to Decision Support systems. The self-describing characteristic of SensorML-enabled sensors and processes also supports the development of auto-configuring sensor networks, as well as the development of autonomous sensor networks in which sensors can publish alerts and tasks to which other sensors can subscribe and react.
Archiving of Sensor Parameters -
Finally, SensorML provides a mechanism for archiving fundamental parameters and assumptions regarding sensors and processes, so that observations from these systems can still be reprocessed and improved long after the origin mission has ended. This is proving to be critical for long-range applications such as global change monitoring and modeling.
Component -
Physical atomic process that transforms information from one form to another. For example, a Detector typically transforms a physical property or phenomenon to a digital number. Example Components include detectors, actuators, and physical filters.
System -
Composite physically based model of a group or array of components, which can include detectors, actuators, or sub-systems. A System relates a Process Chain to the real world and therefore provides additional definitions regarding relative positions of its components and communication interfaces.
Process Model -
Atomic non-physical processing block usually used within a more complex Process Chain. It is associated to a Process Method which defines the process interface as well as how to execute the model. It also precisely defines its own inputs, outputs and parameters.
Process Chain -
Composite non-physical processing block consisting of interconnected sub-processes, which can in turn be Process Models or Process Chains. A process chain also includes possible data sources as well as connections that explicitly link input and output signals of sub-processes together. It also precisely defines its own inputs, outputs and parameters.
Process Method -
Definition of the behavior and interface of a Process Model. It can be stored in a library so that it can be reused by different Process Model instances (by using 'xlink' mechanism). It essentially describes the process interface and algorithm, and can point the user to existing implementations.
Detector -
Atomic component 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. In SensorML a detector is a particular type of Process Model.
Sensor -
Specific type of System representing a complete Sensor. This could be for example a complete airborne scanner which includes several Detectors (one for each band).
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. SensorML design has benefited greatly from the interactions of members of the OGC Sensor Web Enablement Working Group. 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, Northrop Grumman, Oak Ridge National Labs, and NASA.