Double-anchored Software Architecture

the application from the underlying operating system and networking stack in the general-purpose software. To achieve the goals for more structured software de-velopment process we need comparable interfaces in theWSNsoftware architecture that will promote decoupling and reuse, while maintaining the required levels of efficiency. Out of these considerations,DASAdefines two anchors of rigidity in the

WSNsoftware stack (Figure3.3):

Portability anchor that abstracts the local services provided by the underlying hard-ware; and

Interoperability anchor that abstracts the services in remote contexts and allows more rapid development of distributedWSNapplications.

Interoperability Anchor

Portability Anchor

Hardware Platform

hardware/software boundary

Platform-Independent Hardware Interface

Local Services Distributed Applications

Content-based Publish/Subscribe Interface

Double-anchored Software Architecture

Platform-Specific Hardware Interface

Figure 3.3: High-level functional decomposition ofDASA.

In the following we briefly introduce the two anchors and their general features.

The detailed specification of their internal organization and the evaluation of the achievement of our design goals is presented in the two subsequent chapters, Chap-ter4and Chapter5, respectively.

3.3.1 Portability Anchor

Breaking the tight coupling between the software and the underlying hardware through a hardware abstraction is a crucial requirement for amending the ineffi-ciencies of the vertically-integrated development model in WSNs. By hiding the hardware-dependent code from the rest of the system, hardware abstractions play important role in promoting portability and reuse and are thus core element of many execution environments (Section2.3).

According to the definition in [146], a software artifact is portable“...to the degree that the effort required to transport and adapt it to a new environment in the class is less than the effort of redevelopment.”. The aim of the portability anchor inDASAis to improve thesource-level portabilityof theWSNsoftware, by establishing standard hardware-independent interface to the services provided by the underlying hardware platforms.

In this, we are following a similar goal as thePOSIXstandard [96] which“...specifies Application Programming Interfaces (APIs) at the source level, and is about source code portability. Its neither a code implementation nor an operating system, but a stable definition of a programming interface that those systems supporting the specification guarantee to provide to the application programmer”. ThePOSIXapproach of narrow interfaces and monolithic abstractions, however, is not suitable for direct application in theWSN

domain.

As discussed in Section3.1, in theWSNcontext, the cost of abstractions cannot be as easily masked by hardware over-provisioning as in traditional systems. Consequently, mechanisms are needed for avoiding some of the abstraction overhead in cases when the need for performance overshadows the benefits of the complexity hiding. The hardware abstraction inWSNhas to be more modular. It has to accommodate a fluid hardware/software boundary and it has to delineate between the development of complexity hiding abstractions and their equalization across different platforms.

The portability anchor inDASAcodifies these design-constraints that we deem nec-essary for effective organization of software along the hardware/software boundary.

The anchor is structured as a three-level component framework that progressively abstracts the capabilities of the underlying hardware platform. The top-level compo-nents offer publichardware-independent interfacesfor building portable services and applications, and the middle-level components offer publichardware-specific interfaces which provide access to the full capabilities of the underlying hardware.

This organization of the hardware abstraction functionality provides a solid foundation for developing hardware-independent services and applications, allowing significant code reuse across different hardware platforms. At the same time, the design offers mechanisms for flexible control of the performance penalty for this portability. In situations where the performance loss is too high, the developer can skip the portability abstraction and directly tap to the hardware-specific interfaces.

3.3.2 Interoperability Anchor

The lower anchor inDASAdecouples the evolution of the software from the underlying hardware but does not provide sufficient complexity hiding for significant gains in productivity of the development process. To enable more rapid development of distributedWSNapplications, a higher-levelinteroperability spanneris needed that will protect the developer from the complexity of accessing services both in the local and remote execution context.

In manyWSNapplication domains, a classical networkingAPIlike the Berkeley socket does not provide adequate levels of abstraction for substantial productivity gains. Unlike the identity-centric, any-to-any communication patterns, characteristic for the traditional communication networks, the focus in WSNsis on the sensed data and its context, and less on the identity of the node that acquired it. This creates a need for customized communication abstractions that can better support the specific interaction patterns of theWSNapplications. Many of the existingWSN

standardization activities like ZigBee [225], WirelessHART [217], and ISA100 [101], try to address this demand through vertically integrated service architectures that have narrow scope and lack flexibility and extensibility.

The interoperability anchor inDASAoffers a more generic and flexible approach.

It exports a light data-centric abstraction that shields the application from the evo-lution of the underlying service code and provides a sufficient complexity hiding enabling rapid development of distributedWSNapplications. The anchor is organized as component framework with a service interface that follows the Content-Based Publish/Subscribe (CBPS) model, tailored to the specific requirements of theWSN

domain.

The framework fully decouples the implementation of the serviceAPIfrom thehot spotsin the architecture, like the communication and the sensing stacks, that have high impact on the application performance. From one side, this promotes independent evolution of the solutions below the anchor. From the other side, the decoupling enables easy application-specific customization of the service abstraction through the use of different communication substrates and extension components. For example, by choosing between a flooding protocol and a dissemination protocol [130,198], the application developer can select between reliable and unreliable distribution of the subscriptions.

3.3.3 Configurability

Our architectural proposal is tailored to the specific challenges associated with software development for resource constrained WSN platforms. The presented component-based organization and the decoupling constraints are enforced only at the source-level organization and the architecture explicitly allows collapsing of the decoupling barriers and interface optimization during the code compilation process.

In this way, the additional structure in the software stack is maintained only during

the development phases where it generates maximal benefits in terms of reuse and improved productivity.

In contrast to run-time component frameworks like RUNES [156], we believe that for the class of resource constrainedWSNdevices, the memory and the invocation overheads associated with maintaining full run-time component-based organization negate the gains resulting from the increased flexibility. The ability to dynamically exchange components at run-time also has to be weighed against the potential for introducing subtle composability problems which are expensive to detect and fix.

In line with this view, DASA does not provide rich mechanisms for run-time adaptation like introspection and reflection, and lacks dedicated cross-layer data sharing services [115,121]. Instead,DASArelies on explicit exchange of metadata—

comprised of simple attribute/value pairs—as versatile run-time control signaling mechanism both “vertically”, among components in a local execution context, as well as “horizontally”, across differentWSNnodes and contexts (Section5.4.2).