The sensor Planning Service is one of the web services provided by the Open Geospatial Consortium ( OGC) developed for the realization of sensor Web Enablement.
The OGC Sensor Planning Service was developed to provide a standardized interface for programmable sensors. That might be real sensors, that require a manual trigger such as a sampler or a controllable camera, but also to so-called virtual sensors. Virtual sensors are are mathematical or simulation models, that provide calculated, thus virtual measurements.
If parameters or control variables have to be sent to these sensors, the SPS will be used.
Of course, this service is not limited to sensors. The SPS can be used to controll complete systems via the Internet.

For example, in the project ProOptKa the SPS services were used to parameterize and control the simulation models STORM and STOAT.

The requests to the service are usually based on XML, based on a standardized scheme and are sent by POST-request to the service. However, GET requests are possible for some operations, in which the parameters are transmitted via key-value pair.

For the SPS, there are mandatory and optional operations.

Mandatory operations

  • GetCapabilities - Returns a document with a detailed description of the service and the connected sensors
  • DescribeTasking - With this operation, a client can obtain information about the parameterization of the sensor. This includes information about the permitted value ranges, the unit of measurement these values ​​must be transmitted and whether the setting of a specific value is mandatory or optional.
  • Submit - With this operation the (new) values are transmitted ​​to the SPS
  • DescribeResultAccesss - Here is described where the result of this process can be picked up after processing. This can be a SOS or simply a link to a file.

Optional operations

  • GetFeasibility - This query contains information about whether a sensor is ready for new tasks
  • GetStatus - This query can contain information about how far the execution of a task has progressed
  • Update - If this operation is supported, a new set of values can be sent to a given task
  • Cancel - With this operation, the execution of an operation is aborted

Interaction diagram with a SPS

This diagram shows a typical interaction with a SPS:

[caption id="attachment_325" align="alignleft" width="146"]Interaction diagram with a SPS Interaction diagram with a SPS[/caption]

  1. First, a GetCapabilities request is sent to the service in order to obtain the necessary information
  2. The service delivers its capabilities with a list of the sensors and the adjustable parameters
  3. If one or more parameters for a sensor have to be changed, a DescribeTasking-request with the respective SensorID is sent to the service
  4. The service provides a detailed description of the parameters in a DescribeTaskingRequestResponse
  5. when the sensor returns values ​​after execution of the task, the client needs to know how to get this data. This information can be requested with a DescribeResultAccess-request
  6. The service responds with a DescribeResultAccessRequestresponse with an address where the result of the task will be stored. This might be, for example, the address of an SOS
  7. Is then checked with a GetFeasibility inquiry whether the sensor is ready to get sent the new parameters and execute a task
  8. The service sends the response with a GetFeasibilityRequestResponse
  9. If the sensor is ready and the service gave its OK, the new parameters are transmitted with a Submit request
  10. The service responds with a SubmitRequestResponse whether the submitted values ​​were accepted and assigns this task with a TaskID
  11. If the processing of a task takes longer and the client needs information about the status of the execution, a GetStatus-request can be sent to the service
  12. The service then responds with a GetStatusRequestResponse with information about the status of the execution
  13. If additional or new values ​​are to be sent after processing, it can be done with an Update-request
  14. The service responds with an UpdateRequestResponse wether the new values ​​were accepted
  15. When everything is done, the client sends a Cancel-request to the service and releases it for new tasks

If the service, its sensors and the parameterization are known, for example in a firmly integrated service, the steps 1-6 may be omitted.

Share:

Add comment