SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 53 of 233
service and information viewpoint below. Thus, the sensor model is extended with a network node component e.g. an Internet node as illustrated in Figure 5-5.
The SensorSA defines the resulting sensor network as a collection of sensors and
optional processing nodes, in which information on properties observed by the sensors may be transferred and processed.
Internet nodes might be either connecting a single sensor a or a whole sensor network c to the communication network. Further on, a sensor system might even integrate all
necessary components to act as one single network node, i.e. the sensor system is addressable and accessible within the communication network b.
Figure 5-5: Sensors connected to a Communication Network here: Internet node
Depending on the available addressing options see section 5.2.3, the sensor network appears to users as either a sensor system or a complex form of a sensor. This is the design
decision of the sensor network engineer. Let SN = {S1, S2,…,Sn} be a sensor network with n 0 indicating the number of
sensors in SN. There are the following properties of a sensor network with respect to membership of sensors.
-
The membership of a sensor to a sensor network is time-dependent, i.e., sensors may join and leave sensor networks, or formally: SN1 t1
SN1 t2 ≠ Ø with t1 ≠ t2.
-
Sensor networks may overlap, i.e., a sensor may be member in more than one sensor network at a given time t, or formally: SN1t
SN2t ≠ Ø.
-
Sensors may be moving, i.e. they may change their position. As a consequence of the movement of the sensor it may leave one sensor network SN1 and join another sensor
network SN2, or formally: Si SN1 t1 Si SN2 t2 with t1 ≠ t2. The SensorSA
refers to these sensors as roaming sensors. An example is a sensor node in a wireless sensor network that leaves the reachability zone of a data logger and gets into the
reachability zone of another data logger.
5.5. Service Viewpoint of a Sensor
The service viewpoint is concerned with the functional decomposition of a sensor or a sensor system into a set of services that interact at interfaces. The transfer of this software modelling
perspective into a more functional perspective of the sensor model leads to an even more
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 54 of 233
complex view. There are two perspectives for the service viewpoint: an internal perspective and an external perspective.
The internal perspective ignores the communication part for a moment and has a closer look at the physical device called a sensor by converting the black box sensor into a white box
see Figure 5-6.
Figure 5-6: Service Viewpoint of a Sensor internal perspective
The sensor responds to the physical stimulus “temperature” with the generation of a certain voltage observed in Volts. Afterwards, the voltage gets converted into a digital
representation of degrees Kelvin. The external perspective represents the view of a software developer or a designer that
aims at integrating a sensor into a network of services. From this perspective, a sensor may be seen as a component in a service network with two major logical interfaces:
-
Information: an interface to access the information that represents the properties observed by the sensor see the information viewpoint of a sensor described in section
5.6, and
-
Management: an interface that enables the configuration and monitoring of the internal behaviour of the sensor see the internal perspective as well as the discovery of the
sensor resources that are made accessible through the observation access interface.
Both logical interfaces have been illustrated before in Figure 5-2, Figure 5-3 and Figure 5-4. Technically, the SensorSA maps these logical interfaces upon the interface and service
types of the OGC Sensor Web Enablement initiative. An example of an information access interface is the OGC Sensor Observation Service as described in section 8.2. An example of a
management interface to a sensor is the OGC Sensor Planning Service as described in section 8.2.3.
From the service viewpoint, it often makes sense to consider a simulation model as a sensor, because a model can provide data for times in the past or future analogous to a sensor
device. This view is, for example, found in Botts, 2005 and Cox, 2007. The main reason for this very broad usage of the term “sensor” results from research and standardization
efforts within the domain of service-oriented architectures. As long as sufficient meta- information comes along with the data e.g. how the data were produced, quality etc., it does
not make any difference for the client whether a physical device or a simulation models produced the data. This approach has the advantage that generic sensor applications may be
built that retrieve their data from physical sensors usually past observation results in the
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 55 of 233
same way as from simulation or predictive models i.e. calculated future observation results in the case of predictive models.
Services instances that provide access to sensor data are usually composed in so-called sensor service networks. The Sensor Model defines a service network as a set of service
instances that interact in order to serve the objectives of applications definition derived from RM-OA 2007. Sensor service networks are variants of service networks that are compliant
to the specifications of the SensorSA.
Let SSVN = {SV1, SV2,…,SVm} be a sensor service network with m 0 indicating the number of services in a SSVN. In analogy to the membership of sensors to sensor networks,
there are the following properties of a sensor service network with respect to the membership of service instances.
-
The membership of a service instances to a sensor service network is time-dependent, i.e., service instances may join and leave sensor services networks, or formally:
SSVN1 t1 SSVN1 t2 ≠ Ø with t1 ≠ t2.
-
Sensor service networks may overlap, i.e., a service instance may be member in more than one sensor service network at a given time t, or formally:
SSVN1t SSVN2t ≠ Ø.
-
Sensor service networks may be re-configured, i.e. a service instance SVi may be removed from one sensor service network SSVN1 and assigned to another sensor
service network SSVN2, or formally: SVi SN1 t1 SVi SN2 t2 with t1 ≠ t2.
The physical grouping of sensors into sensor networks and the logical grouping of service instances into sensor service networks is illustrated in Figure 5-7.
Figure 5-7: Sensor Networks and Sensor Service Networks
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
