Levels of Abstraction – SPS Chains

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 24 Copyright © 2011 Open Geospatial Consortium to be analyzed first, which might be a time consuming task. The latter can be due to the fact that the asset – for example a reconnaissance drone or satellite – is not located above the area of interest and therefore has to be moved there, first. Another example is to have the service itself inform the client about a situation of interest. In either case, this shows that the SPS needs to have functionality to support an asynchronous interaction pattern.

6.7 Information Access

The service functionality of SPS does not encompass operations for direct access to the information gathered or produced by an asset. Data retrieval services like SOS Sensor Observation Service, WMS Web Map Service, or WCS Web Coverage Service, or even FTP or REST-based services are much more suited to perform this functionality. The SPS interface provides references to the information gathered by an asset. The reference data contains enough information to retrieve the complete set of data output by an asset for a certain task.