Copyright © 2011 Open Geospatial Consortium 17
However, clients may require information to be collected until a certain point in time and thus need the feasibility check to be completed some time before. Clients define this
latest time when the response to a getFeasibility request must be available using the lastestResponseTime
property in their request see clause 7.3.1.3. If the service is not able to determine the feasibility of a tasking request until then, both the service and the
client consider the tasking request as not feasible. This decision cannot be changed later on, i.e. any response sent by the service at a later stage is void.
A feasible tasking request means that it is accepted by the service. Depending on the request, the SPS either schedules a new task or provides a positive feasibility response
without doing any further activity internally see clause 6.3.6 for further details on state handling. Tasking in general can involve a sequence of tasking requests to have an asset
gather the desired information.
Example: A client first checks the feasibility of a task via the getFeasibility operation – once a feasible set of tasking parameters has been determined, the task is submitted via the submit operation and is then updated multiple times to
adjust the way the asset is gathering information. This can for example be a switch of the sampling frequency, or orientation of a remote sensor.
Clause 6.2 explained the clientserver interactions for tasking an asset via the SPS in more detail.
6.3.4 Feasibility of a Task
To task a certain asset or system, tasking parameters have to be provided by the client. The definition of these parameters depends on the given asset and the parameterization
abstraction level chosen by the service provider see clause 6.5 for further information. A set of tasking parameters – or better: the set of values for these parameters – constitutes
a tasking request see clause 6.3.3. Before an SPS can accept such a tasking request, it has to check whether that task can be performed or not. This is called a feasibility check.
Feasibility of a task or tasking request shall be checked: • by client request, i.e. if a client needs a pre-check for an intended task.
• if a client wants to reserve a task; a reserved task can be set to operational state by the client at any time until the reservation expires. The service has to ensure the
full feasibility of the task during the reservation time. Under certain conditions, the service cannot maintain the feasibility of a reserved task, e.g. if the asset was
tasked by someone else with higher priority. If the service supports publishsubscribe functionality as described in this specification then it informs
the client that the reserved task has failed.
• when a task is submitted; the task can only be executed if it is feasible. • whenever the client wants to perform an update of a reserved or submitted task.
The feasibility check performed by the service shall proof that the asset is capable of executing the intended task or task update. As such, during a feasibility study a service
can check the items on the following not exhaustive list:
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
