exposing legacy sensors and actuators via TinyOS

A wireless sensor/actuator network (WSAN) consists of cooperating nodes able to sense and affect the surrounding environment. TinyOS is among the most popular operating systems used in WSAN networks. It is available for a number of platforms, most of which are based on a tiny physical node that integrates a microcontroller, some (possibly node-specific) sensors and actuators, as well as a radio module for wireless communication. We refer to such nodes as hardware motes. Examples of hardware mote platforms include MicaZ, TelosB, and IRIS.

Applications developed for TinyOS (and similar operating systems) are most often multi-node (distributed). They run on a number of communicating hardware motes, and, in general, different motes execute different application code. The key resource used by such applications are the sensors and actuators contributed by all participating hardware motes; they are the multi-node application’s means to interact with the environment.

Quite frequently, one would like to reuse an available multi-node, TinyOS application by running it with sensors and actuators not interfaced to TinyOS hardware motes. The challenge is to enable a TinyOS application to access such sensor and actuator resources. To address that, we have developed the proxy mote, a fully functional TinyOS platform for Linux-based PC systems. The main use case for the proxy mote is to expose a non-TinyOS, legacy sensor/actuator device. An application is compiled for the proxy mote in the same way as for hardware motes like MicaZ. TinyOS abstractions for all major hardware mote peripherals (timers, the radio interface, and the serial port) are supported. References to the proxy mote’s sensor/actuator interfaces actually affect the legacy device, accessed remotely in a device-specific way. At runtime, the application, the proxy mote (i.e., the system-level code), and the device driver, linked together, run natively on a PC as an autonomous Linux process.

Support for multi-node, distributed TinyOS applications requires that multiple proxy motes run in parallel and communicate. Accordingly, proxy motes running on a single PC, each accessing its own legacy device, form a proxy network. Networked proxy motes use the familiar Active Message (AM) interface for communication. Message exchange is transparently handled by a dedicated process, named Portplex.

In Fig. 1, a typical TinyOS-based setup is contrasted with one based on ProxyMotes. The same multi-node TinyOS application is run in both cases. Each mote executes its own application code, denoted by App1, App2, and App3, respectively. In Fig. 1a, the application runs on hardware motes and uses mote-integrated sensors and actuators. In Fig. 1b, the application runs on proxy motes and uses a legacy sensor/actuator infrastructure. Each legacy device is represented by a single proxy mote customized by a device-specific driver; jointly, the proxy motes expose the possibly heterogeneous sensor/actuator infrastructure. The entire TinyOS application execution and the inter-mote communication are handled by the hosting PC. Only operations on sensor and actuators are delegated to the legacy infrastructure.

Figure 1. Diagram of (a) a typical TinyOS-based network and (b) a ProxyMotes network.

---

See our paper:

• Paczesny, T.; Tajmajer, T.; Domaszewicz, J.; Pruszkowski, A.
  ProxyMotes: Linux-based TinyOS Platform for Non-TinyOS Sensors and Actuators
  2012 IEEE 10th International Symposium on Parallel and Distributed Processing with Applications (ISPA), pp.255-261, 10-13 July 2012, Leganes, Spain, doi: 10.1109/ISPA.2012.41
  IEEE Xplore