7.1 Double-anchored Software Architecture
The current software development process inWSNsis characterized by many inefficien-cies. The application-specific nature and the constrained resources push developers into closed and vertically-integrated solutions that impede design and code reuse and hinder faster growth. Developing applications is hard and requires expertise across the technological stack, starting from the hardware platform, communication protocols, sensing stack, up to the application domain.
In this dissertation we have argued about the benefits from introducing a broad domain-specific software architecture for WSNsthat can codify the functional de-composition of the system and lay foundations for a more structured development approach. To this end, we have proposed the Double-Anchored Software Architec-ture (DASA) forWSN, a novel architectural framework that balances between the need for stable abstractions and code reuse and the need to optimize the system to the specific requirements of the target application and hardware.
DASAis based on careful identification of those parts in the software stack where interface fixation can maximize the reuse gains, and on identification of the parts with decisive impact on the fidelity and the efficiency, which should be kept flexible to enable target-specific optimization. Our architectural framework identifies two anchorage zones where rigidity can contribute towards increasing the decoupling and the reuse in theWSNsoftware development process: aportability anchor, that abstracts the local services provided by the underlying hardware; and aninteroperability anchor that abstracts the services in remote contexts and allows more rapid development of distributedWSNapplications.
7.2 Portability Anchor
The lower anchor inDASAaddresses the problem of complexity hiding and porta-bility in the hardware abstraction code. Its interfaces shield the rest of the system from the intricacies of low-level hardware access, enabling easy development of portable service and application code. At the same time, the anchor makes platform-specific optimizations possible when the fidelity and efficiency costs of the portability abstractions become unacceptable.
When we started with our work on the portability anchor, all popularWSN exe-cution environments lacked a clear organization of the hardware abstraction code and exported ad-hoc abstraction interfaces that were strongly biased by the features of particular hardware platforms. Through our experience with porting different hardware platforms on these earlyWSNoperating systems, we realized the bene-fits of separating between the development of complexity hiding abstractions and their equalization across different hardware platforms. This led us to the three-layer hardware abstraction architecture that gives theDASAportability anchor its flexibility.
We applied these insights into the design of TinyOS 2.x, a popular execution environment forWSN, as one of its main design features. Currently, more than ten TinyOS Enhancement Proposal provide detailed specification for service abstractions like timing, communication, sensing, storage, power management, etc., aligned with the decomposition principles of the portability anchor. These specifications are supported by reference implementations that collectively comprise a broad prototype of the proposed anchor architecture. In this work we leveraged the TinyOS 2.x reference implementations to evaluate the proposed portability anchor design. Using a combination of micro-benchmarks and test applications we demonstrated the successful achievement of the design goals and illustrated the flexibility in balancing between the need for reuse and the fidelity costs of the complexity hiding.
The proposed design of the portability anchor has been currently validated only in the specific context of TinyOS. An important direction of future work is to evaluate the possibilities for expanding the architectural principles of the portability anchor acrossmultipleWSNexecution environments. The WASP project [157] follows a similar goal of establishing anOS-independent abstraction interface. Among other things, this would facilitate the development of hardware andOS-independent protocol stacks, direction promoted by the OpenWSN [158] project.
We see several challenges that have to be met. The differences in the code organi-zation model in the different execution environments represent the first roadblock.
DASAassumes a component-based organization, but due to the source-level focus of the specification and the granularity of the design, we believe that the architectural constraints can be easily applied to other domains. More challenging difficulties can arise due to “impedance mismatch” in theAPIdesign philosophies. TheDASA
portability anchor promotes wide and expressive interfaces, supported by extensive compile-time checking which can be hard to reconcile with narrow,POSIX-like de-signs like the one used in MantisOS. Finally, the differences in the synchronicity of
the service invocations would need to be addressed. Unconstrained access to the hardware resources, as promoted by the Hardware Adaptation Layer (HAL) of the
DASAportability anchor typically implies asynchronous access. This can be a problem for thoseWSNexecution environments that only support blocking semantics.
7.3 Interoperability Anchor
The interoperability anchor inDASAaddresses the problem of providing interop-erable access towards the system services both in local and in remote context, as basis for a more rapid development of distributed WSNapplications. The anchor exports a customized Content-Based Publish/Subscribe (CBPS) service that is fully decoupled from the underlying services, including the communication stack. This decomposition strives to provide to the application developer simple and flexible means for adapting the service to the specific needs of the target application.
The design of the interoperability anchor is optimized to the specific needs of resource constrainedWSNplatforms. Consequently, it does not provide rich mecha-nisms for run-time adaptation like introspection and reflection. Most of the config-urability freedom is limited to compile-time. For run-time signaling,DASArelies on explicit exchange ofmetadataamong the components in a local execution context, as well as across differentWSNnodes and contexts.
To evaluate the design of theDASAinteroperability anchor we have developed TinyCOPS, a prototype implementation in the context of the TinyOS execution en-vironment. Using TinyCOPS, we have experimentally demonstrated the flexibility and extensibility of the design and its ability to support different communication protocols and interaction patterns. Our experience with the prototype framework suggests that by careful component decomposition and interface design, it is indeed possible to achieve a good balance between efficient resource usage and reusable software design, which are the core design goals ofDASA.
The presented design of the interoperability anchor inDASAcan be extended in several directions. One area of interest is the better integration of efficient service dis-covery mechanism on top of theCBPSservice [83,183]. Another promising avenue of future work is to explore gateway solutions that will enable transparent bridging be-tween theCBPSservice of theDASAinteroperability anchor and external data-centric frameworks based on publish/subscribe extensions of the Extensible Messaging and Presence Protocol (XMPP) [143], Google’s PubSubHubbub protocol [73] or pop-ular MOM solutions like Advanced Message Queuing Protocol (AMQP) [205] and ZeroMQ [223].
7.4 Distributed Testing Infrastructure
DASApromotes a decoupled software development process in which the principles of
“black-box” reuse can lead to significant reduction in the development overheads. This
compositional freedom, however, has to be supported by stronger integration testing that will validate the semantics of the services and their non-functional properties.
This process requires distributed testing infrastructure that will allow realistic but controlled testing at deployment-scales.
To address these needs, we have designedTWIST, a flexible testing infrastructure forWSNsthat enables efficient testing of functional and non-functional properties of distributedWSNservices.TWISTprovides basic services like node configuration, network-wide programming, out-of-band extraction of debug data and gathering of application data. It also offers powerful topology control and fault injection capabilities that we leveraged in our evaluation of theDASAinteroperability anchor to illustrate the influence of the underlying communication protocols on the semantics of the exported service.
TheTKNinstance ofTWISTis one of the largest publicly availableWSNtestbeds and its services have been successfully used by the members of theWSNresearch community in support of their dissemination activities. Because TWISTrelies on affordable hardware and open-source software, it serves as testbed template that has been replicated by several external groups.
To address the existing roadblocks in performing cross-validation studies on multipleWSNtestbeds, we have also designed aRESTful platform that enables con-venient access to the experimental resources of multiple testbeds, organized in a federation of autonomous entities. With this, we are contributing to the ongoing effort in the community towards federated testbeds solutions, as exemplified by the related activities under theFIRE[56] andGENI[68] initiatives.
Our current work on the testing federation concentrates on refining the platform design and implementing the first prototypes for the core interfaces. As future work we would like to leverage the standardized interfaces of our platform to build template experiments that can serve as a reusable benchmark suite for automatic evaluation ofWSNservices in context of multiple testbeds. Such suite can reduce the barriers for cross-validation studies and can offer a common base for comparing the functional and non-functional properties of competing designs and implementations.
APPENDIX