SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 137 of 233
8.2.2 Sensor Observation Service
Name Sensor Observation Service
Standard Specifications
OGC 06-009r4 Sensor Observation Service OpenGIS® Implementation Specification
Description The goal of the Sensor Observation Service SOS is to provide access to
observations from sensors and sensor systems in a standard way that is consistent for all sensor systems including remote, in-situ, fixed and mobile
sensors. An SOS organizes collections of related sensor system observations into Observation Offerings. The SOS leverages the Observation and
Measurements OM specification for modelling sensor observations and the TransducerML and SensorML specifications for modelling sensors and
sensor systems. The approach that has been taken in the development of SOS, and the SWE specifications on which it depends, is to carefully model
sensors, sensor systems, and observations in such a way that the model covers all varieties of sensors and supports the requirements of all users of sensor
data. SOS leverages the standard properties of these two data types sensors and observations to provide specialized operation signatures for observation
data. The Sensor Observation Service provides its functionality through the
following interfaces:
ServiceCapabilities : Provides information about both common and
specific capabilities. CoreOperationProfile
: Provides the basic functionality to retrieve observations.
TransactionOperationProfile: Provides functionality to register a
Sensor with the SOS and to insert Observations EnhancedOperationsProfile:
Provides FOI centred operations as well as convenience operations
Interface ServiceCapabilities getCapabilities
Informs the client about both common and specific capabilities of a Service Observation Service instance.
Interface CoreOperationProfile describeSensor
Requests detailed meta-information about a sensor and delivers a document describing the sensor system.
getObservation Retrieves observation data structured according to the Observation and
Measurement specification. Interface TransactionOperationProfile Optional
registerSensor Registers a new sensor system with the SOS as part of the transactional
profile. The response to a registerSensor request contains an AssignedSensorId
which is the identifier assigned by the SOS to designate the new sensor.
insert Observation
Inserts new observations for a sensor system. Interface EnhancedOperationsProfile Optional
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 138 of 233
getObservation ById
optional Returns an observation based on an identifier.
getResult optional
Obtains sensor data in a repetitive fashion from the same set of sensors without having to send and receive requests and responses that largely contain
the same data except for a new timestamp.
getFeature OfInterest
optional Returns detailed information such as location about one or more features.
These features are typically used in the Sensor Observation Service to identify the geographical location where observations are being made.
getFeature OfInterestTime
optional Returns the time periods for which the SOS will return data for a given
advertised feature of interest. Delivers a GML time primitive which lists one or more time periods for which observations from that feature of interest are
available.
describe FeatureType
optional Returns the XML schema for the specified GML feature advertised in
GetCapabilities. This may be used to obtain a description of the type of an observation feature-of-interest.
describe Observation
Typeoptional Returns the XML schema that describes the Observation type that is returned
for a particular phenomenon.
describe ResultModel
optional Returns the schema for the result element that will be returned when the client
asks for the given result model by the given ResultName.
Example usage A sensor data consumer is interested in obtaining sensor observations from one or more sensors. The consumer would perform service discovery using
service capabilities information, usually via a catalogue service, in order to find SOS service instances that can provide the desired sensor observations.
After initial discovery the consumer could directly obtain observations from services or could perform additional discovery at the service level or get
sensor meta-information before obtaining sensor observations. Service-level discovery involves invoking the GetCapabilities operation to return
information about the offerings that are available from each service. Detailed sensor meta-information can be obtained after extracting the sensor system
identifiers out of each observation offering by invoking the DescribeSensor operation.
Comments This service description is abstracted from the OGC 06-009r4 Sensor
Observation Service OpenGIS® Implementation Specification.
Table 8-2 : Description of the Sensor Observation Service 8.2.3
Sensor Planning Service
Name Sensor Planning Service
Standard Specifications
OGC 07-014, OpenGIS® Sensor Planning Service Implementation Specification
Description The Sensor Planning Service SPS provides a standard interface to task any
kind of sensor to retrieve collection assets. It is a service by which a client can determine collection feasibility for a desired set of collection requests for
one or more sensorsplatforms, or a client may submit collection requests
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 139 of 233
directly to these sensorsplatforms. Not only must different kinds of assets with differing capabilities be supported, but so must different kinds of request
processing systems, which may or may not provide access to the different stages of planning, scheduling, tasking, collection, processing, archiving, and
distribution of requests and the resulting observation data and information that is the result of the requests. The SPS is designed to be flexible enough to
handle such a wide variety of configurations. The Sensor Planning Service provides its functionality through the following
interfaces:
ServiceCapabilities : Provides information about both common and
specific capabilities. SensorTasking:
Provides as set of operations to task sensors. Interface ServiceCapabilities
getCapabilities Informs the client about both common and specific capabilities of a Service
Planning Service instance. Interface SensorTasking
describe Tasking
Requests the information needed in order to prepare an assignment request targeted at the assets that are supported by the SPS and selected by the client.
The server will return information about all parameters that have to be set by the client to perform a submit operation.
getFeasibility optional
Provides feedback to a client about the feasibility of a tasking request. Dependent on the asset type covered by the SPS, the SPS server action may
be as simple as checking that the request parameters are valid and are consistent with certain business rules, or it may be a complex operation that
calculates the availability of the asset to perform a specific task at the defined location, time, orientation, calibration etc.
submit Submits the assignment request. Depending on the covered asset, it may
perform a simple modification of the asset or start a complex mission. getStatus
optional Requests information about the current status of the requested task.
update optional
Updates a previously submitted task. cancel
optional Cancels a previously submitted task.
describeResult Access
Retrieves information about how and where data that were produced by the asset can be accessed. The server response may contain links to any kind of
data accessing OGC Web services such as SOS, WMS or WFS.
Example usage Imagine a user who wants to get an overview of the current situation in a specific building. This building is what we call the area of interest AOI. The
first step would be to call up a catalogue to provide descriptions of all sensors that have an area of service AOS which overlaps with the AOI.
However, a catalogue may only contain high-level information about the observable properties, locations and contact information. It might be
necessary to call a Sensor Observation Service to retrieve the SensorML descriptions for the sensors found. In this example, one of the descriptions
provides information about a video camera located inside the building.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 140 of 233
Now the user wants to find out more about the service. Note that a single SPS instance might be a façade covering hundreds of sensors with even more
tasking parameters. The user sends a getCapabilities request to the SPS instance. The response shows that the service supports all SPS operations and
offers only one taskable sensor. Before the user moves forward in tasking the sensor they want to find out whether they can access the sensor data.
Note: The SPS is an interface to task an asset or asset system. It is not an interface to access the observed data produced by it. Observed data can be
made accessible by a number of services. In most cases it might be a Sensor Observation Service, but TML Data Streaming Service, Web Feature Service,
Web Coverage Service, or Web Map Service are other options.
Comments This service description is abstracted from the OpenGIS® Sensor Planning
Service Implementation Specification
Table 8-3: Description of the Sensor Planning Service 8.2.4
Sensor Alert Service
Name Sensor Alert Service
Standard Specifications
OGC 06-028r4, OpenGIS® Sensor Alert Service Implementation Specification
Description The Sensor Alert Service SAS provides the means to register for and
receive sensor alert messages. The service supports both pre-defined and custom alerts and covers the process of alert publication, subscription, and
notification. More specifically, the SAS defines an interface that allows nodes to advertise and publish observational data or alerts and corresponding meta-
information. It allows clients to subscribe for these data
– or any other data that are produced by the SAS based on incoming messages from sensors
– within specific thresholds. Observational data sent from a sensor are referred
to in this specification as sensor data. These sensor data might be a single observation result, a complex observation result or even an alert. The SAS
sends alerts if conditions are matched, supports the integration of new sensors and uses XMPP Extensible Messaging and Presence Protocol to send
messages. The Sensor Alert Service provides its functionality through the following
interfaces:
ServiceCapabilities : Provides information about both common and
specific capabilities. SensorAlert
: interface allowing nodes to advertise and publish observational data or alerts plus corresponding meta-information. It
allows clients to subscribe for data produced by the SAS based on incoming messages from sensors
– within specific thresholds Interface ServiceCapabilities
getCapabilities Informs the client about both common and specific capabilities of a Service
Alert Service instance. Interface SensorAlert
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 141 of 233
getSupported Operations
optional Delivers a document that describes the interface in terms of the operations
that are supported by the service instance. A typical format may be a WSDL document in a W3C Web Service platform environment
1
. advertise
optional Allows producers to advertise the type of information published.
cancel Advertisement
optional Cancels an advertisement.
renewAdvertise ment
optional Renews an advertisement when the advertisement set by the SAS has expired.
subscribe Allows consumers to subscribe to alerts.
cancel Subscription
Cancel a subscription. renew
Subscription Renews a subscription.
describeAlert Delivers a template of the alert message structure.
describeSensor Requests information about a sensor, encoded in SensorML.
Example usage Figure 8-1illustrates a high level view of the SAS and the protocols used at the different steps.
SAS
Client Sensor
last-mile-mode
WNS or other gateway
XMPP
MUC MUC
Advertise: HTTP renew cancel
GetCapabilities: HTTP Subscribe: HTTP
renew cancel
join publish: XMPP alert: XMPP
join: XMPP alert:
various
DescribeAlert: HTTP DescribeSensor: HTTP
Figure 8-1: Overview about the Sensor Alert Service Simonis, 2006
Comments This service description is abstracted from the OpenGIS® Sensor Alert
Service Implementation Specification.
Table 8-4: Description of the Sensor Alert Service
1
In OGC 06-028r4 , the corresponding operation is called “getWSDL”.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 142 of 233
8.2.5 Web Notification Service