Sensor Planning Information Service Planning Functions

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 86 of 233

6.6.4.2 Sensor Planning Information

The communication between a Sensor Planning Service and a client consists of the following information items: - Meta-information about the service The service shall be self-describing section 7.7.2. - Meta-information about tasked sensors The service shall provide all information about the sensors that will be tasked by the service e.g. type of sensor, location, accuracy etc. - Tasking parameters The service shall describe the kinds of parameters required to submit a tasking request. Those parameters might be in direct relation to the sensor, e.g. the looking angle in degrees for a frame camera, or they are more abstract parameters, e.g. the different modes “normal”, “severe”, or “fatal” for an observation campaign. The tasking parameter has to be semantically defined, though the executed actions might be transparent to the user of the service. The client provides values of the required parameters in order to start the tasking or check the feasibility of a potential tasking request. - Status information of tasking requests The service shall describe if a tasking request is still in queue, currently executed, idle etc. - Status information of feasibility requests Analogous to the status information of tasking requests, the service shall be able to report the status of a feasibility check.

6.6.4.3 Service Planning Functions

In the following the major functional requirements of a service that realises sensor planning are listed from an abstract point of view. - Sensor Description The service shall be able to describe the sensor itself. The sensor and the tasking parameters are different aspects. Therefore, the sensor description shall focus on the sensor itself rather than on the description of the tasking parameters of the sensor. The sensor description primarily serves the purpose of identifying the service instance as an instance that provides access to a specific sensor with its features. This information can be stored in registries or catalogues to foster discovery. - Description of tasking parameters SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 87 of 233 The service shall be able to describe the tasking parameters of the sensor. The description shall follow design and encoding rules in order to allow usage of previously unknown sensors. The level of detail of those rules defines the level of interoperability, as only very strict rules allow tasking of new sensors fully automatically, i.e. without human intervention. - Feasibility Analysis The service shall be able to test a tasking request for feasibility. This allows the user to determine if and under what conditions a tasking would be feasible before submitting a potentially expensive tasking request. The service itself shall provide detailed responses, indicating the feasibility itself as well as potential alternatives. - Submission of tasking requests The service shall be able to accept tasking commands. The tasking instructions shall follow the definitions provided by the service in its asset tasking description. - Update of submitted requests The service shall allow the user to update any submitted request, either feasibility test or concrete tasking command. Additionally, the service itself shall be able to request update information from the client. This situation occurs when the tasking had been stopped and additional information becomes necessary in order to proceed with the tasking. - Cancellation of submitted requests The service shall allow the cancellation of previously submitted feasibility test requests or tasking requests. It is the responsibility of the service to bring the tasked asset back into a safe position. This should be transparent to the user. - Status description The service shall provide information about the current status of a submitted feasibility test or tasking request. The response sent by the service shall contain all available information about the current status of a request. As this information depends to a large extent on the concrete application, the service shall be able to describe the parameters of the status report in its self-description or as part of other request responses. - Description of Result Access Mechanisms The service shall be able to provide information about how to access potential data that are produced in response to a tasking instruction. In the SensorSA, Sensor Planning activities are based on the Sensor Planning Service SPS as specified by the Open Geospatial Consortium OGC 07-014r3 and described in section 8.2.3. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 88 of 233

6.7. Meta-information Approach

6.7.1 Introduction

The approach to describing meta-information within the SANY Architecture is based on the ORCHESTRA meta-information approach, as described in Annex A3 of RM-OA, 2007. According to this approach a conceptual meta-information model, which is a human understandable representation of the meta-information needed, has to be developed for a given purpose. Based on the user requirements see section 4.6, the following purposes for meta-information have been identified: - Data and Service Integration - Interpretation - Discovery - Monitoring - Authentication and authorisation - User profiling - Quality control management

6.7.2 Data and Service Integration

For the purpose of service integration a service has to provide meta-information that describes the service. This meta-information comprises the structure of the implemented interfaces, the descriptions of the operations that can be performed including the descriptions of the parameter and return types, the location of a service instance e.g. its URL or additional characteristics of the service e.g. costs that enable service selection. For the purpose of data integration a service has to expose meta-information regarding the data it provides describing the structure, the location where can it be accessed, geo- spatial information, quality and precision information, measurement unit, measured phenomenon, and the measurement and processing e.g. filtering procedure, among other information.

6.7.3 Interpretation

Meta-information is needed for the explanation and understanding of resources data and services. Resource descriptions shall contain explicit semantic descriptions or pointers to vocabularies dictionaries in order to ensure the self-description of services and data and their semantically correct integration.