18 Co • syntax of tasking parameters
• presence of mandatory parameters • validity of parameter configuration
• asset availability • parameterization update is valid according to current execution state
The result of a feasibility check depends on the current state of the service and associated resources e.g. the asset itself but also operators, support units, radio links, etc.
As an example, imagine a task intended to be performed during a certain interval of time by a specific asset see Figure 7.
Figure 7 — dynamics of a feasibility study result
Client A checks the feasibility of a task to be executed in the time interval t
1
-t
2
1.1. The SPS checks the internal schedule for asset X 1.2 and recognizes that the time frame is
not blocked by any other task. The SPS therefore responds that the task is feasible. Before client A acts again, client B submits a task for asset X with the time interval t
1
-t
2
2.1. Again the SPS checks if the time frame is not already blocked by another task 2.2 and – as this is not the case – adds the task to the schedule of asset X 2.3. The time
interval t
1
-t
2
in the schedule of asset X is now blocked by the task from client B. The SPS has accepted the submission of the task from client B and sends an according response.
Now client A submits its tasking request 3.1. The SPS checks the internal schedule of asset X and recognizes that the time frame t
1
-t
2
is already blocked by another task from client B. It thus rejects the submission.
pyright © 2011 Open Geospatial Consortium
Copyright © 2011 Open Geospatial Consortium 19
6.3.5 Reserving a Task
Clients can reserve tasks. This is useful e.g. if a client needs to task several assets that are useful to him only if tasked in one go via different services. A task can also be
reserved before being submitted. Such a reservation actually represents a task for which all required resources are allocated by the service but which shall not be executed until
the client confirms it.
In other words, the client puts a reserved task on hold. This can be compared to a transaction in which the client first provides all parameterization details and finally
confirms his task. The service shall check the feasibility of the task before it accepts the reservation. When the client confirms the reserved task, it is executed by the service.
The confirmation does not involve an additional feasibility check by the service because a reserved task shall be feasible until it expires. If a service can no longer guarantee the
feasibility of a reserved task for any reason, the reservation shall fail.
The expiration time of a reserved task is defined by the service optionally in agreement with the expiration time the client requested, thus making sure that resources are not
blocked forever. The client can cancel a reservation if the service supports the cancel operation.
A reserved task can be updated if tasking parameters are updatable see clause 6.3.2. Each update is subject to a feasibility check by the service.
6.3.6 State Handling
This section explains in more detail how an SPS handles the states of a tasking request and a task. This is done via two state machine diagrams. A formal documentation of the
diagrams is given in clause 10.
NOTE: One or more of the transitions shown in the following state diagrams are triggered by events and have a specific effect, which is to notify interested clients about the event Notify. A service that
implements publishsubscribe functionality can inform clients about these events.
When a client sends a tasking request to the service, it initiates the behavior shown in Figure 8.
20 Co
Figure 8 — tasking request state machine diagram
The decision if a tasking request is feasible or not is either directly available feasibility determined
, or requires more time feasibility pending. The latter causes the tasking request to transition into the Pending state. If the feasibility of the pending tasking
request cannot be determined before the request expires, then the tasking request automatically transitions from Pending into the Rejected state. Otherwise the tasking
request gets back into the decision cycle: if the tasking request is feasible, then it shall be Accepted
by the service – otherwise it shall be Rejected. A task shall be scheduled by the service if the client reserved or submitted it. The
following state diagram illustrates the state handling for such a task.
pyright © 2011 Open Geospatial Consortium
