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
Co
Figure 9 — task state machine diagram
Based on the user’s intention, the task automatically transitions either into the state Reserved
or InExecution. A Reserved task can be updated by the client but shall not change to state InExecution
unless the client confirms it. If the client does not confirm a Reserved task before it expires, the task automatically transitions into the final state category Expired.
The client can update a task that is InExecution at any time. If such a task produces new data that is made available to the client, the SPS can send a notification. The task itself
remains in its current state InExecution or a substate thereof – or more specifically: it transitions back into its current state.
If the task is completed it transitions into the final state category Completed. This implies that all data gathered for the task has been published.
A client can cancel a scheduled task at any time. The task then transitions into the final state category Cancelled.
If the server fails to complete a scheduled task as planned, then the task transitions into the final state category Failed.
pyright © 2011 Open Geospatial Consortium 21
22 Copyright © 2011 Open Geospatial Consortium
6.4 Status Reporting
Status reports provide information about the status of a task and tasking request but also about the outcome of the cancellationconfirmation of a task. Status reports are contained
in operation responses but are also used to encode event information, which can be published to subscribed clients.
Note: The conceptual model of a status report see clause 7.3.1.5 is therefore quite flexible. Which features of the tasking report are used depends on the specific functionality that was invoked. This is described in
detail in the according clauses.
Whenever an SPS receives a tasking request, it assigns a unique identifier to it and provides this identifier in the status report concerning the status of the request that is
contained in the tasking response. The identifier is created even though the decision on the request may still be pending i.e. the request is not accepted yet. Once the request
gets accepted, in the case of a Submit or Reserve request a task will be scheduled. The identifier remains the same, i.e. the initially created identifier for a request now becomes
an identifier for a task. This allows clients to use the identifier received with the response for subsequent requests to retrieve information about such tasks, e.g. via GetStatus.
Example: the state history of a feasible Submit request and resulting task can thus be the sequence of the states Pending Æ AcceptedInExecution this state can be entered more than once, e.g. when the task was updated or data was
published Æ Completed Example: the state history for a feasible Reserve request can be the sequence of the states
Accepted Reserved the Reserved state can also be entered more than once if the reservation was updated Æ Expired;
another possible sequence is Pending Æ AcceptedReserved Æ InExecution Æ Completed
The SPS reports the current status of a tasking request or task following the state types defined in the state machines see clauses 6.3.6 and chapter 10. A service includes only
final and non-final states. Whenever a task has reached a state, even the same state yet again e.g. after an update the state is still inExecution after being triggered by an event
recognized by this standard see clauses 10.1.3 and 10.2.3 or an extension of this standard, the code for this event see clause 7.3.1.9 shall be added to the report as well.
This helps clients keeping track of the current status of a tasktasking request and the reason why a certain state was re-entered.
By default, an SPS therefore logs the information about the latest state transition that a tasking requesttask made. An SPS can also support provision of the full state history, i.e.
all state transitions. This capability is indicated in the service’s metadata. If this capability is not supported by a service instance then such a service can discard
information about all state transitions of a tasktasking request except for the latest one. In any case, an SPS is only obliged to provide status information for a certain period of
time after a tasking requesttask was finalized. How long exactly this period is depends on the given service instance.
6.5 Levels of Abstraction – SPS Chains
The functionality offered to a client through the SPS by the asset owner can range from full blown, detailed parameterization options to just a small set of very abstract
parameters. Asset owners usually define the tasking parameters of their system according to which functionality they want to make available to their clients. Several abstraction
Co layers can be put in place to make tasking more intuitive for end users – thereby hiding
system complexity – while still allowing experts to take advantage of the full set of parameterization options see following figure.
Figure 10 — tasking on various abstraction levels
The figure above shows an example of an asset management system or a concrete sensor, which has a number of SPS instances assigned to it. The system has a number of
parameters to be set red hexagons. In order to task the system, all parameters have to be defined, which is handled by the first SPS instance SPS 1. The abstraction interface on
top SPS 2 only shows two parameters and a second abstraction interface SPS 3 shows a single parameter only.
As an example for such an SPS chain, imagine a satellite control system. The system itself requires the parameters region of interest, time of interest, minmax of azimuth and
elevation as well as coverage type to be set. The base SPS interface therefore describes seven tasking parameters. At the next abstraction level, the clients can only define region
of interest, time of interest and coverage type. The SPS instance at that level will take care for the missing parameters azimuth and elevation. At the highest abstraction level,
the SPS interface describes only a single parameter: region of interest. Thus, clients cannot define the time of interest or any of the other parameters, but need to accept what
is offered by the service. The different SPS instances simply forward the information provided by a client from the highest level to the asset management system and define the
missing parameters with their own data. Clients are usually not aware of this “request enrichment”; it is opaque to them.
The same chain of SPS instances is conceivable for different types of SPS, like simulation systems, processing systems, fusion systems and real physical assets.
6.6 Asynchronous Communication
The Sensor Planning Service interface often facades complex asset management systems that do not provide an immediate response to operation requests or which need a long
time to gather needed information. The former can be due to the fact that the request has
pyright © 2011 Open Geospatial Consortium 23
