Image Processing Reference
In-Depth Information
radio and sensor channels. EmCee runs the EmSim core, however, uses real radios instead of modeled
channels. Both EmSim and EmCee use the same EmStar source code and associated configuration
files as a real deployed EmStar system. his aspect alleviates the development and debugging process
of sensor network applications.
EmView is a visualization tool for EmStar systems that uses a UDP protocol to request status
updates from sensor nodes. In order to obtain sensor node or network information, EmView queries
an EmProxy server that runs as part of a simulation or on a real node. EmRun starts, stops, and
manages an EmStar system. EmRun supports process respawn, in-memory logging, fast startup, and
graceful shutdown.
EmStar services comprise link and neighborhood estimation, time synchronization, and rout-
ing. The neighborhood service monitors links and maintains lists of active, reliable nodes. EmStar
applications can use these lists to get informed about topology changes. The LinkStats service pro-
vides applications with more detailed information about link reliability than the Neighborhood
service, however, produces more packet overhead. Multipath-routing algorithms can benefit from
the LinkStats service by weighting their path choices with LinkStats information. he TimeSync ser-
vice is used to convert timestamps between different nodes. Additionally, EmStar supports several
routing protocols, but allows the integration of new routing protocols as well.
12.4.2.2 EmStar IPC mechanism
Communication between EmStar modules is managed by so-called framework for user-space devices
(FUSD)-driven devices, a microkernel extension to Linux. FUSD allows device file callbacks to be
proxied into user space and implemented by user space programs instead of kernel code. Besides
intermodule communication, FUSD allows interaction of EmStar modules and users. FUSD drivers
are implemented in user space, however, can create device files with the same semantics as kernel-
implemented device iles. Applications can use FUSD-driven devices to transport data or expose state.
Several device patterns exist for EmStar systems that are frequently needed in sensor network
applications. Example device patterns comprise a status device pattern exposing the current state
of a module, a packet device pattern providing a queued multiclient packet interface, a command
device pattern that modifies configuration files and triggers actions, and a query device pattern
implementing a transactional RPC mechanism.
12.4.3 SeNeTs—Test and Validation Environment
In SeNeTs, SNAs run distributed on independent hosts such as PCs, PDAs, or evaluation boards
of embedded devices []. The parallel execution decouples applications and simulation environ-
ment. he quasi-parallel and sequential processing of concurrently triggered events in simulations is
disadvantageous compared with real-world programs. SeNeTs prevents this very unpleasant effect.
Without SeNeTs, this effect results in sequenced execution of parallel working SNAs and corrupted
simulation output. To summarize, realistic simulations of sensor networks are complicated.
12.4.3.1 System Architecture
The development and particularly the validation of distributed applications are hard to realize.
Especially systems with additional logging and controlling facilities affect the primary behavior of
applications. Suppose, a logging message is transmitted, then an application message may be trans-
mitted delayed. Exceptionally in wireless applications with limited channel capacity, the increased
communication leads to a modified timing behavior and as a consequence to different results.
The channel capacity is defined as
n
−
,
,since
n
symbolizes the number of nodes. Due to the
degrading channel capacity in large sensor networks, the transport medium acts as a bottleneck [].
