SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 217 of 233
Once the EO and in-situ data is available from SOS services, a WPS or SPS based data processing e.g. fusion service can be used to implement the processing chain shown above in
Figure 10-29. The processing service will typically use the quality meta-information found in both EO and in-situ SOS services to judiciously combine their observations and produce new
observations with better spatial andor temporal coverage and quality. These new observations can be stored in an SOS could be one of the input SOS services along with uncertainty
information which is essential for decision making.
In the geo-hazard example considered above, inverse distance interpolation spatial fusion limited to a given radius e.g. 30 m can be applied to improve the accuracy of the EO
derived vertical displacement observations at the selected stable reflector points. Statistical information uncertainty related to the interpolated displacements can also be generated and
published along with the updated observations in a Fused SOS server with the same structure as the EO and in-situ SOS servers.
10.10. Integration of Mobile Sensors
Of the sensor network scenarios shown in Table 4-1 in section 4.5, all but one involve mobile sensors:
no. 2. Mobile sensors and fixed or mobile data logger
no. 3. Mobile sensors moving in different service networks
no. 4. Mobile sensor cluster on vehicles e.g. on ships - block data transfer on demand
no. 5. Mobile earth observation sensors satellite, airborne
no. 6. Mobile sensors with their own IP address
For a mobile sensor the location of the sensor is time dependent. In addition, the associated sampled feature and or sampling point of a feature of interest are normally time dependent.
For scenarios 2- 4, observation data is transferred from the sensor to a “data logger”. For
simplicity, it is assumed that each data logger has exactly one associated SOS instance where the observations are published. The protocol between the sensors and data logger is proprietary and
outside the scope of SensorSA. The data logger shall register its SOS instance with a catalogue service. The result of a SOS getCapabilities request to the data logger provides a list of sensors
associated with the data logger and for what sampling or result times observations are available. The catalogue service can subsequently use describeSensor operations to acquire information
about the sensors associated with a data logger. The data logger may have no or only partial knowledge about which sensors are still alive. A catalogue service may compile information as
to the location of sensors in order to support network management.
Scenario 3 differs from scenario 2 in that a sensor may transfer its observation data to several different data loggers, and hence to several SOS instances. If the observations of a given
sensor relate to the same feature of interest, then there are two approaches to dealing with this in applications requiring all data for this feature:
-
A cascading SOS may be employed to merge the observations from the different SOS instances of the data loggers. Thus applications may need to access only the cascading
SOS. This assumes that the cascading SOS has the necessary knowledge of relevant underlying SOS instances.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 218 of 233
-
A catalogue has knowledge about available observations for a feature of interest including references to the pertinent SOS instances. A client application first queries the
catalogue for the SOS instances and subsequently the individual SOS instances with getObservations
. A special case in scenario 3 arises when a sensor transfers the same observation data to
several data loggers – this may be done intentionally for reasons of redundancy and reliability, or
may happen by accident depending on the underlying protocols. A cascading SOS or client application can detect and remove duplicate observations based on the combined reference to the
procedure sensor, feature and sampling time.
Scenario 4 is actually a particular case of scenario 3, whereby the time required to make observations available in an SOS instances can be considerably longer. This has consequences
for applications as they may need to wait for a certain period before data processing is started or can be completed.
In scenarios 4-6 especially, the usage of a SPS is recommended to task the sensor deployment and to obtain information about what observations are feasible and when they will
be available cf. section 8.2.3. In scenario 5, the mobile sensor platform may have its own integrated SOS instances, or it
may communicate with a base station where the SOS instance is located. There is an obvious parallel to scenario 3 in that observations may become available at a later time.
In scenario 6, it is assumed that the sensor has its own SOS instance. Such sensors therefore play a similar role in SensorSA as the data loggers described above.
10.11. Event Handling
