## 3 New Generation Sensor Web Enablement
### KVP and SOAP Binding Introduced
#### 3.3.3 Tasking of Sensors  
Some sensors or sensor platforms support dynamic configuration at runtime. This can be for example the configuration of the sampling rate or the steering of a movable sensor platform. Tasking of sensors in an interoperable way can be done by using the Sensor Planning Service (SPS). The SPS is a web service interface that allows clients to submit tasks to sensors. The SPS interface aggregates operations covering the complete process of controlling and planning sensor tasks. This contains checking whether a task is feasible for a sensor by using the _GetFeasibility_ operation, the submission of tasks (_Submit_), as well as the status tracking of submitted tasks (_GetStatus_). In order to equip clients with sufficient information to formulate tasking requests, the (self-describing) syntax for describing a task can be requested (_DescribeTasking_). The SPS forwards the submitted tasks to the addressed sensor. However, the subsequently gathered data are not collected by the SPS. Instead, the SPS provides a means for querying where the measured data is accessible (_DescribeResultAccess_). The version 2.0 of the SPS standard brings numerous changes in the request and response models of the client-server communication. We will concentrate on the most prominent advancements from SPS 1.0 [66] to SPS 2.0 [81], as listed in Table 4 and described in the following. Harmonization with SWE Service Model and SWE Common Specification  
SPS 2.0 reuses both the SWE Service Model (Section 3.3.1), as well as the SWE Common (Section 3.2.1) specification. All SPS 2.0 operations derive from the abstract request type defined by SWES which provides well-defined extension points for future SPS profiles, such as the SPS EO Profile (see below). In addition, the SWES operations _DescribeSensor_ and _UpdateSensorDescription_ are implemented in the new SPS specification, the first as a mandatory option and the second as optional. SWE Common data components are now used to describe the tasking parameter syntax and to encode tasking parameters in corresponding requests and supersede the data structures used in version 1.0. Redesign of Task Handling and Status Model  
The SPS 2.0 defines a new task model, which clearly differentiates the subtle differences between all possible states a tasking request or task can hold. It captures all statuses from the request reception until eventual completion or failure of a task. The initial model in version 1.0 enumerated the task statuses _unknown_, _in operation_, _finished_, _not yet started_, _cancelled_, and _delayed_, but provided a rather loose definition only and no state change semantics have been described. This has changed with the \begin{table}
\begin{tabular}{l|c} \hline
**Specification** & **Description of change** \\ \hline \multirow{5}{*}{SPS 2.0} & Harmonization with SWE Service Model and SWE Common specification: \\  & \(\bullet\) Implementation of operations according to SWE Service Model \\  & \(\bullet\) Tasking parameters and tasking parameter descriptions based on SWE Common \\  & Redesign of task handling and status model: \\  & \(\bullet\) Clear definition of state change semantics \\  & \(\bullet\) New operations: _GetTask_, _Confirm_, _Reserve_ \\  & \(\bullet\) Advanced status reporting \\  & New asynchronous communication concept \\  & SOAP binding introduced \\ \hline SPS EO Profile & SPS Earth Observation Profile Update \\ \hline \end{tabular}
\end{table} 
Table 4: Major changes of SPS 2.0.  
new model. State machine diagrams illustrate the new concept and exactly define the status of a task at any time. The new model is closely aligned with the new notification concept, as all task state changes or re-entries in already hold states are reported. In version 1.0, it was necessary to retrieve the current status by issuing _GetStatus_ requests. The new operations to reserve a task (_Reserve_) and to confirm a reserved task (_Confirm_) are reflected by the status concept as well.