SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 223 of 233
1. The “sensor triggered plug-and-measure” pattern implies that the station computer
passively listens for new sensors and is notified when a new sensor is connected. To illustrate this consider the case of a USB sensor connecting to the USB subsystem of the
station. Upon connection the USB subsystem fires an interrupt that is propagated through various software layers, eventually translated into a notification and caught by the station
computer sub-process handling new sensors.
2. The “station triggered plug-and-measure” pattern implies that the station actively polls
for new attached devices. This can easily be imagined for the case of simple bus technologies like CAN-BUS.
10.12.2 Sensor recognition and connection establishment
To enable the station to communicate with the sensor, the sensor must be able to provide type information. We make no assumptions here about how this is realised or about the format of the
sensor type information. For example, USB devices are providing complex meta-information describing the device e.g. device identifier, manufacturer name, interfaces etc.. The station
needs knowledge about the sensor type in order to be able to load and use the appropriate software component that enables application layer level communication byte stream between
the station and sensor. As soon as application layer level communication is possible further sensor information can be retrieved by an appropriate software component.
The sensor description can be stored on the sensor much like the IEEE1451 TEDS or on a local or remote sensor description repository. The sensor description shall be encoded as a
SensorML Botts, 2005 document and contain the information necessary to enable the station computer to configure the sensor, initiate measurement tasks and retrieve observation data. The
information encompassed in a sensor description is dependent on the use-case and the specific station computer and sensor implementation. Such information might include a description of the
software protocol by which the sensor and the station communicate. The protocol description can be interpreted by a so called generic de-serializer component running on the station computer
and enabling packet based communication with the sensor over the existing byte stream. Moreover, parts of the SensorML description are process descriptions. An example of a process
is the conversion from raw observation values into engineering units, taking into account sensor calibration and decoration of observation data with units of measurement or annotation.
10.12.3 Sensor Adapters
Simple sensors with analogue inputs and outputs usually do not fulfil the abovementioned requirements on interface, processing and storage. This kind of sensor requires a “Smart Sensor
Adapter” device that enables the plug and measure functionality. An example of such a device is shown in Figure 10-38. It interfaces a simple sensor with analogue IO right side with the
station computer left side. It enables plug and measure capability by providing a digital interface with the station computer e.g. USB and providing, on demand, a SensorML
description of the sensor. A composite of a simple sensor and a plug-and-measure adapter is treated as an entity when described in SensorML. The SensorML description is initially
transferred to the adapter and deployed together with the sensor.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 224 of 233
Figure 10-38: Smart Sensor Adapter 10.12.4 Sensor Access through Service Interfaces
The SensorSA recommends to expose a new sensor through sensor planning SPS, sensor observation SOS and sensor alert service SAS interfaces as defined in the OGC Sensor Web
Enablement see section 8.2. Every measurement starts by submitting a task via the SPS interface. In order to be able to task a measurement the sensor must be registered with an SPS
instance. This means on one hand that the sensor must be assigned a unique ID within the scope of the station. On the other hand two documents have to be provided and mapped to the sensor
ID: the sensor tasking description an XML document returned upon invocation of SPS DescribeTasking
operation describing the parameters needed to task a specific sensor and a SensorML description of the sensor. Further, if the station exposes observation data through an
SOS interface the sensor description shall be also registered with the SOS instance.
10.12.5 Publish plug-and-measure related information
