Introduction Task – Concept and Handling

16 Copyright © 2011 Open Geospatial Consortium

6.3.2 Tasking Parameters

In order to parameterize an asset management system, clients need to provide tasking parameters that influence the parameterization of the asset. Tasking parameters need to: • describe full syntax as well as semantic of the parameter • be extensible with metadata • support optional parameters • support choices between parameterization options • support default values • support provision of value constraints • indicate whether the parameter can be used in a task update The data types defined in SWE Common Data Model [OGC 08-094] satisfy these requirements and thus are used by SPS for defining tasking parameters and for encoding their values.

6.3.3 Tasking requests

To parameterize an asset, a client first has to initialize a set of tasking parameters, which constitute the task that the client is interested in getting executed by the SPS. The definition of the tasking parameters for a given asset can be retrieved via the SPS describeTasking operation. Then, the client has required all information to formulate and send a tasking request to the SPS. Four types of tasking request are differentiated. • getFeasibility – to determine whether the task remember, a tasking request contains tasking parameters can be executed by the service or not, depending upon its current state see clause 6.3.4. This operation can also be used to check if an update of an existing task is feasible. • reserve – to block all resources required to execute the task if it is feasible for a certain amount of time; this is useful to ensure that assets from different services can be tasked together see clause 6.3.5. The reserved task either expires or gets confirmed to be executed by the client. • submit – to instruct the service to execute the task if it is feasible. • update – to update if feasible the tasking parameters for a task that is already reserved or in execution. Determining if a tasking request is feasible can take a long time, depending on the procedures executed by the service to evaluate the feasibility. In simple cases a trivial syntax check of the tasking parameters might be sufficent, while in other cases the service might have to wait for human approval. 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: