Introduction to the SOS standard

Sensor Observation Servcie (SOS) is an Open Geospatial Consortium (OGC) approved standard (in version 1 and 2) that is part of the Sensor Web Enablement (SWE) initiative.

Sensor Web Enablement

The OGC Sensor Web Enablement (SWE) working group was established to provide a first definition of the system that is able to enable the development of the Sensor Web idea by identifying the technology, the language syntax and the architecture to be used.

In summary, the SWE aim is to define a unique environment where specialists and users can search, access, and process data observed by a multitude of heterogeneous sensor networks. With this propose the SWE working group has defined a series of OpenGIS® standards:

1. SWE Common: XML model for sensors data
2. SensorML (Sensor model Language): XML model for processes and components
3. O&M (Observation and Measurements): XML model for the observation and measurements
4. SOS (Sensor Observation Service): interface for data access and distribution
5. SPS (Sensor Planning Service): interface for the sensor operation activation

And a series of candidate specification or discussion paper like the:

6. SAS (Sensor Alert Service): interface for dispatching alerts using the XMPP (extensible messaging and presence protocol)
7. WNS (Web Notification Service): interface for the notification of information with different protocols

Sensor Observation Service

As part of the SWE, the Sensor Observation Service standard defines the interface to interact with sensor observations: from sensors exploration to measures retrieval and data management throughout transactional operations. It worth noting that this description refers to SOS in version 1; the version 2 of the standard was recently approved at the time of writing and introduces some minor changes.

Like most of the OGC standards, the SOS service is based on the exchange of standard messages (requests and responses) between the service and the consumer by using the HTTP protocol. The requests are sent to the service through an HTTP POST (in this case an XML file formatted according to the specification is submitted) or an HTTP GET method (in this case a KVP, key-value-pairs, is submitted) specifying the request type and the relative permitted parameters. The service responses are always XML file compliant with the specifications. According to the OGC specification a SOS version 1.0 service must implement at minimum the three mandatory requests of the SOS core profile, while other operations of the transactional profile and of the enhanced profile are optional (see next Table-1).

SOS request	Profile	Mandatory	Short description
GetCapabilities	Core	Yes	Allow to describe the service providing information on administrator, offered capabilities, observed property and features, etc..
DescribeSensor	Core	Yes	It provides a potentially detailed description of a given registered component, system or process in SensorML format
GetObservation	Core	Yes	It provides observations based on the setting of filters that includes timing, processes, phenomena, feature of interest, and other parameters in O&M model
RegisterSensor	Transactional	No	It provides capability to automatically register a new sensor to the existing service
InsertObservation	Transactional	No	It provides capability to dynamically insert new observation(s) related to a registered sensor
GetFeatureOfInterest	Enhanced	No	It provides requested feature of interest in GML format
GetResult	Enhanced	No	It provides a light way to request observation without provide full request every time
GetObservationByID	Enhanced	No	It provides a quick access to observation by identification number
GetFeatureOfInterestTime	Enhanced	No	It provides the time interval when a given feature of interest has been observed
DescribeFeatureType	Enhanced	No	It provides the schema used to represent the features of interest
DescribeObservationType	Enhanced	No	It provides the schema used to represent the Observations
DescribeResultModel	Enhanced	No	It provides the schema used to represent the result object within the sml:observation

Table-1: SOS requests for a list of SOS request and relative short description

Two typical SOS UML sequence diagrams respectively from a data consumer and data producer perspective are presented in Figure-1.

Figure-1: Typical SOS UML diagrams for data consumer and producer.

The SOS is based on five key objects as represented in Figure-2 :

1. Observations: they are the center of the standard and represent the values mesured at given time instants (e.g.: value: 0.2, time: 08-11-2012 12:12) and represented according to the O&M standard data model.
2. Procedure: indicates who provide the observations, this is generally the sensor but it may also be a generic process that leads to some observations (e.g.: procedure: TREVANO) and is represented as SensorML standard data model.
3. Observed Properties: they represent the phenomena that are observed (e.g.: phenomenon: air-temperature) and is represented with a URI (uniform resource identifier) composed by colon separated text according to the om:observedProperty of the O&M standard.
4. Feature of interest: it is the fature that relates to the observations, so for an in-place instrument is the sensor location, while for remote device it the target location (e.g.: location: Trevano, coordinates: 718345,99224,389, reference system: CH1903/LV03) represented according to the om:featureOfInterest element of the O&M standard.
5. Offering: it is a collection of sensor used to conveniently group them up (e.g.: offering: weather-sensor-SUPSI) and is represented as sos:ObservationOffering element of the SOS standard.

Figure-1: Key objects of the SOS standard.