Information Viewpoint of a Sensor

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

5.6. Information Viewpoint of a Sensor

The information viewpoint is concerned with the semantics of information and information processing. Thus, it discusses a sensor in regard to the semantics behind a sensor or a sensor system. The abstraction from the physical device described in the technology viewpoint becomes appropriate. Basically, SANY adopts here the OGC Observations and Measurements model as specified in Cox, 2007 and described in section 7.2. We speak of a sensor as a source that produces a value, within a well-defined value space, of an observed property which may represent a physical, biological or chemical environmental phenomenon. Sensors and sensor systems as well as simulation models fulfil this definition. If the semantics do not differentiate between data produced based on a physical stimulus or any other data, the distinction between model and sensor disappears. The information viewpoint concentrates on the data that are provided in the form of observation results abstracting from the source of the observation data. These observation results have to follow the sensor data information model, i.e. the results have to reflect all aspects of the underlying viewpoints. In addition to the observation results, information about the observation procedure, spatial-temporal context, and organizational characteristics has to be provided. Such information is considered to be meta-information for the purpose of interpretation and further processing of the observation results see section 6.3. In order to identify and describe sensor networks the following information elements may be necessary: - human-readable name and unique identifier of a sensor network - status of the sensor network - observation-related attributes, e.g. observed properties, features of interest - topology of the sensor network e.g. ring, star, bus,... - communication means of the sensor network e.g. Zigbee - administrative attributes of the sensor network e.g. provider, ownership - statement about how the membership of sensors in a sensor network is defined. Membership statements may be formulated explicitly, by defining a list of sensors, or implicitly, by providing a logical expression on attributes. Implicit membership statements may be based upon administrative attributes example: “all sensors operated by the German Mete orological Service”, or based upon spatial-temporal conditions example: “all air monitoring stations in Rome available in January 2009”. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 57 of 233

6. Major Concepts of the Sensor Service Architecture

6.1. Overview

Before starting the detailed specification of the individual viewpoints of the SensorSA, the following major concepts of the SensorSA are described in order to facilitate the understanding of the subsequent specifications: - functional domains of the SensorSA - models of interactions including requestreply and event-based models - resources and their identification - approach for meta-information including handling of data quality - management including resource discovery, sensor planning and sensor and sensor service monitoring - security model with a focus on access control Concrete concepts, e.g. interaction patterns between service instances and policies for service networks, are specified in the Engineering Viewpoint in section 10.

6.2. Functional Domains

Services in the SensorSA are designed to support applications that serve the needs of users. They may call other services if this is required to fulfil the functions offered at their interfaces. In this case, a service may itself be a client to another service. In an extended situation, chains of service operation calls may be defined in order to realise more complex functionality. In a service network every service instance may call operations of any other service. The call of an operation of a service requires that the client know the name and the address of the operation. This knowledge may be acquired from some mediating instance in a discovery phase e.g. a catalogue service, see below, however, it may also be acquired by other means e.g. entered by a human or pre-configured. Although there is no prescribed hierarchy of services, services may be grouped into functional domains for which they are basically designed. The SensorSA distinguishes between the following functional domains as illustrated in Figure 6-1: - Sensor Domain Services in the sensor domain cope with the configuration and management of individual sensors and their organisation into sensor networks. Further examples are services that support the interaction among the sensors themselves, e.g. a take-over service in case of an impending sensor battery failure. Note that services in this domain that will be part of the SensorSA shall be abstractions from the proprietary