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
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 58 of 233
mechanisms and protocols of sensor networks. Proprietary mechanisms are part of an Implementation Architecture and are outside the scope of the present document.
Figure 6-1: Functional Domains of the SensorSA
-
Acquisition Domain Services in the acquisition domain deal with access to observations gathered by
sensors. This includes other components in a sensor network e.g. a database or a model that may offer their information in the same way i.e. as observations as
sensors do see the discussion about the Sensor Model in section 5. They explicitly deal with the gathering and management of information coming from the source
system of type “sensor”. The information acquisition process may be organised in a hierarchical fashion by means of intermediate sensor service instances e.g. using data
loggers.
-
Mediation and Processing Domain Services in the mediation and processing domain are not specific to the SensorSA.
They are specified independently of the fact that the information may stem from the source system of type “sensor”. They mediate the access from the application domain
see below to the underlying information sources. They provide generic or thematic processing capabilities such as fusion of information from sensors and other
information sources, management of models or access to model results. In addition, service support for the discovery of sensors, data and services, naming resolution or
service chaining are grouped in the mediation and processing domain.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 59 of 233
-
Application Domain Based on services of the acquisition and processing domain, services in the application
domain support the rendering of information in the form of maps, diagrams and reports such that they may be presented to the user in the user domain.
-
User Domain The functionality of the user domain is to support the interface to the end user.
Functions in this domain are formally outside the scope of the SensorSA. Thus, the SensorSA does not specify dedicated services to support the user interface. However,
when building concrete systems and applications, such functionality is essential. This functionality has to be specified in a dedicated implementation architecture that also
may take proprietary components and products into account.
At the user domain layer, the user usually is provided with a graphical user interface that simplifies the operation of a sensor service application that is run on the application
domain layer. For example, instead of typing commands into a console window or running shell scripts, the user uses forms, control bars, or joysticks to control the application. The
communication taking place between the form and the sensor is opaque to the user. The form- providing application may communicate directly with the sensor or with any of the layers
below. Similarly, every lower layer may communicate directly with the sensor or with any other lower layer. To the user, it appears as a direct communication with the sensor, although
multiple intermediate steps might be involved. The following figure illustrates the various communication paths.
Figure 6-2: Communication paths between the user and the sensor
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 60 of 233
6.3. Models of Interaction
