Image Processing Reference
In-Depth Information
12.3.9.3 Transducer Markup Language
The transducer markup language (TML) describes protocols to communicate with sensor systems
using a XML model. It supports real-time streaming and command exchange from and to sensor
nodes. Hence, it defines response characteristics of a transducer and methods for transportation
and preparation of sensor data also in spatial and temporal associations. hrough TML definitions,
different phenomena can be correlated to a function to reduce jitter, artifacts, or noise in the data.
12.3.9.4 Sensor Observation Service
The sensor observation service (SOS) defines a standard and consistent interface to access data. The
SOS communicates via a handshake protocol between a client and an observation repository. The
observation repository is a database anywhere in the network to collect measurement data which
canbeaccessedbyanyclients.
Only for soft real-time sensor channels, a direct connection between applications and sensors is
available. To discover sensors, each SOS has an entry in a global service registry anywhere in the
network with characteristic description of the sensor node.
12.3.9.5 Sensor Planning Service
The sensor planning service (SPS) is an interoperable web service interface that allows planning and
execution of data collections from one or more sensors. Standard interfaces are defined to request
information about the capabilities of a SPS. These interfaces consist of request definitions, status
inquiries, updating or canceling of requests, and further OGC Web services that provide access to
more complex processing algorithms.
12.4 Simulation, Emulation, and Test of Large-Scale
Sensor Networks
Applications and protocols for wireless sensor networks require novel programming techniques and
new approaches for validation and test of sensor network software. In practice, sensor nodes have
to operate in an unattended manner. The key factor of this operation is to separate unnecessary
information from important ones as early as possible in order to avoid communication overhead.
In contrast, during implementation and test phases, developers need to obtain as much information
as possible from the network. A test and validation environment for sensor network applications has
to ensure this.
Consider a sensor network with thousands of sensor nodes. Furthermore, consider developing a
data fusion and aggregation algorithm that collects sensor information from nodes and transmits
them to few base stations. During validation and test, developers often have to change application
code, recompile, and upload a new image onto the nodes. hese updates often result in flooding of
the network using the wireless channel. However, this would dissipate a lot of time and energy. But
how could we ensure that every node runs the most recent version of our application?
Pure simulation produces important insights. However, modeling the wireless channel is diffi-
cult. Simulation tools often employ simplified propagation models in order to reduce computational
efforts for large-scale networks. Widely used simulation tools, such as ns- [] use simplified net-
work protocol stacks and do not simulate at a bit level. Furthermore, code used in simulations often
cannot be reused on real sensor node hardware; why should developers implement applications and
protocols twice?
In contrast to simulation, implementation on a target platform is often complicated. he targeted
hardware itself may be still in development stage. Perhaps there are a few prototypes, but developers
