In the common vision of pervasive computing, technology is integrated into our environment and able to adapt to environmental changes and user demands. Interest in wireless sensor networks (WSNs) as pervasive technologies has escalated over the past 10 years, generating a plethora of sensor hardware as well as research into protocols, algorithms, and applications. Yet, not only is there relatively little diversity in terms of robust sensor nodes to support this research, but more important, software engineering support and practice have lagged behind.
The Tesseræ Autonomic Architecture links tiny Beastie computers and their associated sensors, using the Autonomic Network Services (ANS) protocol for self-management.
Pervasive computing requires that computer systems quietly adjust themselves to the user and the changing environment. For this to happen, program code must be able to change on demand in a clean and speedy manner. Developers of high-end pervasive computing systems take for granted the luxury of having languages and tools to support component-based system development, as well as abstractions that provide dynamic code reconfiguration to facilitate runtime adaptation and self-management. However, due to the tight resource constraints of sensor nodes, WSN systems are typically composed of simple assembler or C programs. This means that when updates are needed, whole programs must be replaced. Also, the code encompasses all possible processing paths, making it complex, unwieldy, and prone to error. Inadequate software development tools for WSN have led to poor software practices whereby these highly resource-limited devices are actually underused, due to the difficulty of programming them effectively.
To this end, we have developed the Tesseræ Autonomic Architecture, illustrated in Figure 1. At the hardware end, we use sensor nodes called Beasties. These tiny computers have 8MHz processors, a small amount of memory, and wireless networking capabilities, and can be plugged into a number of sensors that measure, e.g., temperature or humidity. Tesseræ is the language that allows programmers to build components, fundamental building blocks from which they can compose services such as a location identifier.1 Self-management is the process by which the system monitors itself and adapts to improve its performance or degrade gracefully. This is implemented using the Autonomic Network Services (ANS) protocol, which is driven by the application directly.2
The software engineering component model is particularly useful for abstracting sensors and their controls, making system development more tractable. A component is a self-contained block of executable code that can communicate with other components only via interfaces, or lists of possible messages. Tesseræ is an architectural description language built to allow the development of high-level abstract component designs. It uniquely features runtime reconfigurable binding between components, generic parameterised components, multiple inheritance, and a fully componentised operating system.
Implementations of components are separate from how they are connected together, and behaviour is defined through the use of the interfaces. The executable code that defines the actual behaviour of components is not written in Tesseræ. Rather, the Tesseræ compiler farms out compilation of the component's source code to separate ‘plug-in’ compilers. This allows the implementations of components to be written in multiple languages and targeted at multiple hardware architectures. Interface descriptions support multiple inheritance to allow the easy addition of components to upgrade the system live, while also mapping a single piece of code over multiple problems.
Components bind together to provide services to the application that uses the WSN. Figure 2 shows an example of dynamic Tesseræ code self-optimising using dynamic rebinding of components. This listing defines a dynamic buffer that gathers data when the WSN node battery level is ‘LOW’ or ‘MEDIUM’. When the battery is fully charged, this buffer is bypassed. In other words, when the system has lots of power it can deliver data using a high-speed, high-power network after each measurement. But if battery power is more limited, sensor measurements are buffered and fed out more slowly.
This example of dynamic Tesseræ buffer code is used only when the WSN node battery level is relatively low, and is bypassed otherwise.
Introducing self-management to sensor networking is crucial to achieving the vision of pervasive computing. To this end, we have developed ANS,2 a decentralised, lightweight, scalable yet powerful protocol that executes on each of the sensor nodes. We assume a degree of redundancy whereby a given node can have many functions. For example, a video sensor might be relaying patient location as its primary function, but may also be capable of analysing the gait of the patient, if necessary, as a secondary function. The ANS protocol is run over the basic network layer and provides a service-based infrastructure that allows devices to provide information and facilities (services) to other devices on the network. When an ANS device requires a service, it broadcasts a request on the network naming the service and supplying parameters specifying how it would like the service provided (for example, how precise a sensor it requires). Devices that support the requested service employ a utility function to determine how close they are to the parameters requested and reply with a single integer. The requesting device then uses this to select the best service provider. Regular retendering for services allows the system to adapt to new devices entering the network and others leaving as they fail. The ANS service structure maps well to component-based design, as individual services can be encapsulated inside components. Thus, application designers need only include components for the services that they wish to use and never need to control the raw networking layer directly.
The Tesseræ architecture has so far been used outside of the laboratory to run various sensors as part of smart office and home installations. The architecture is currently being enhanced to implement large-scale water-cycle infrastructure monitoring, an ideal test for the Beastie hardware that will also examine the software's ability to adapt to a complex changing environment.