Image Processing Reference
In-Depth Information
In TinyOS, components which are connected through narrow interfaces defining usage and provi-
sion of its functions, profit from specifying interface contracts []. Contracts expose the component
specification in an executable format and thus allow for automatic checking of correct interface usage.
Contracts can also be used for unit testing of individual software components, e.g., in Avrora. A less
formal, yet similar approach is nCUnit [], a unit testing framework for the nesC language, which
allows for formulating assertions on the test execution.
T-Unit [] is a unit testing framework for TinyOS software, available as a contributed project from
the TinyOS repository. Diferent from traditional unit testing platform, it extends basic functionality
by allowing execution on one or more actual sensor nodes. Tests are controlled from a test host over
theserialinterfaceandcontainallsotwarerequiredtorunthefunctionalityonthetargethardware.
This approach allows for characterization and testing of TinyOS software functionality on and across
nodes, e.g., transmissions. Regression testing on the TinyOS core libraries underlines the significance
of unit testing for validation.
Nguyen et al. [] discuss program representation for TinyOS application in the form of an appli-
cation posting graph (APG). he event-based nature of applications and preemptive scheduling of the
event handlers renders the control flow of an application and thus the APG complex. Nevertheless,
the APG allows for analyzing coverage of tests and facilitates structural testing.
11.3 Sensor Network Testbeds
Sensor network testbeds allow the execution of code on an actual target device, possibly even in a
realistic environmental setting. With respect to other tools such as simulation and emulation this
approach comes closest to reality, i.e., the actual sensor network deployment but also allows to actu-
ally execute the compiled code in its binary form. By doing so a number of effects that are either
hidden away through the simplifying nature of abstractions and models used in simulations or are
not showing to be of significance can be revealed to the developer. Such effects range from the cor-
rectly ordered execution of code to impairments of the wireless channel and the actual availability of
resources and more.
Typical WSN testbeds that are in use today consist of a wired back-channel that allows to repro-
gram and log data from nodes distributed accross a larger space. Testbeds such as MoteLab [] or
TWIST [] are typically set up in office environments and consist of tens to hundreds of nodes wired
either using Ethernet or USB, sometimes a combination of both. In practical operation a software to
be tested would be uploaded to the testbed, programmed onto all the nodes in the testbed and subse-
quently executed. he data logged from all the testbed nodes is made available at a central location for
postexecution analysis. Different testbeds contain a number of different auxiliary features, e.g., user
arbitration, scheduling of execution, instant notification, etc., however they are typically stand-alone
and not integrated with other development tools.
11.3.1 Deployment-Support Network
The DSN [] is a specialized testbed that uses a wireless back-channel and therefore can be quickly
deployed in different locations, e.g., outdoors. Moreover it features a logical and physical separation of
the testbed plane and the devices under test (DUT plane)(see Figure .). With respect to testbeds like
Motelab or TWIST, this separation into individual distributed observers and the nodes to be tested
has the advantage of being able to customize test scenarios and integrate stimuli and asynchronous
testing. Furthermore the decentralized augmentation with other test and measurement equipment is
facilitated.
The DSN testbed is built from BTnodes (DSN nodes) and supports the connection of most pop-
ular Mote architectures using and interface board (e.g., Mica, Tmote Sky, TinyNode, etc.). It is
