Poster Abstract: OpenCL as Wireless Sensor Network Programming ...

Poster Abstract: OpenCL as Wireless Sensor Network Programming Abstraction Martin Bor, Utz Roedig School of Computing and Communication, Lancaster University, Lancaster, UK {m.bor,u.roedig}@lancaster.ac.uk

Abstract—OpenCL is a programming framework for heterogeneous platforms composed of a multitude of processors such as CPUs, GPUs, and DSPs. The advantage of the framework is that a programmer has a unified view of a program and that it shields the programmer from processor specifics and details of communication primitives. Wireless Sensor Networks (WSNs) comprise of a number of (heterogeneous) sensor nodes forwarding data to a sink node. Application processing is distributed across heterogeneous processors located on sensor nodes and the sink. It is desirable to provide WSN application programmers with a unified programming framework and to shield them from the complexity of distributing code on a multitude of processing platforms. It seems that OpenCL’s goals are a good match for the outlined WSN programming requirements. In this paper we discuss the feasibility of using OpenCL as programming abstraction for processing intensive WSN applications. As example case we discuss structural health monitoring which requires implementation of a data processing chain across multiple heterogeneous processors.

I. I NTRODUCTION Advances in hardware technology have led to dramatic reductions in size, energy consumption and cost of digital circuitry, radio chips and sensors. This development has lead to the design of Wireless Sensor Networks (WSNs), networks of tiny Micro ElectroMechanical Systems (MEMS) equipped with wireless communication and sensors. WSNs are nowadays used for many applications including factory automation, health care and smart cities [1]. Traditionally, wireless sensor nodes are built around a resource-constrained 8 or 16-bit microcontroller, such as the Atmel AVR or the Texas Instruments MSP430. These platforms are able to support processing performance needs of simple WSN applications. Sensor data is collected and then forwarded to a sink node where it is analysed. Recently, more complex applications for WSNs are considered which require more processing capability. Example applications are object recognition via camera sensors, structural health monitoring and monitoring of vital signs of patients. In these situations a complex processing chain is required, executing on sensor nodes and the sink. Thus, WSN platforms are emerging which contain 32-bit microcontrollers (such as ARM Cortex-M, Intel Quark), multicore SOCs (like TI OMAP5, NVIDIA Tegra), and low-power FPGAs and DSPs. In addition, a WSN might support different types of nodes to optimise processing for the outlined application types. Furthermore, over the lifetime of a sensor network some nodes and sometimes the sink are

replaced or upgraded which can result in a change of available processing hardware. Thus, many sensor networks encountered nowadays have a very heterogeneous device population in which each device has its part in a processing chain. A WSN application programmer would require a framework which allows him to construct an application in a unified view. Rather than creating independent code elements (potentially using different languages) for the different processing stages of an application it would be useful to provide one single view. A framework is required which abstracts from implementation specifics of the different processing elements of the system and provides seamless communication among these processing elements. We argue that OpenCL may fit these requirements. However, this would require to use OpenCL in a context where distribution spans across multiple networked nodes. Furthermore, sensor nodes are resource constrained nodes with limited capabilities. For these reasons some extensions and modifications of OpenCL would be desirable. In this paper we discuss the feasibility of using OpenCL as programming abstraction for processing intensive WSN application. II. U SING O PEN CL

FOR

WSN P ROGRAMMING

Open Computing Language (OpenCL) is a programming framework for writing programs that can be executed on heterogeneous platforms composed of a multitude of processors such as CPUs, GPUs, DSPs and other processors. OpenCL includes a language based on C99 to write kernels (programs running on the devices), and APIs for controlling and managing the devices. OpenCL’s focus is on portability, whereby the programmer does not have have to deal with hardware-specific details. With the increasing heterogeneity of WSNs, we need an abstraction to harness this complexity, and still be able to use its potential to the fullest. Current WSN programming frameworks, such as Contiki and TinyOS, do not provide this level of abstraction. They are more focused in providing the lower level of the stack, at a minimal code size and energy usage. It is up to the programmer to combine the whole stack, from drivers to getting data from a leaf node to the sink. On top of that, the programmer has to write his application for processing the data, taking the whole distributed nature of a WSN into account. We therefore propose to use OpenCL as an abstraction layer for programming the whole network as it is designed for (high-

Sensor Node µC

µC

FPGA

Cluster Head µC

All the communication between host and device (enqueuing kernels, transferring data, events), can be translated to radio messages being send between sink and (leaf) nodes. With this, and the hierarchical memory model and the explicit memory transfers, makes the programmer be aware of the (potentially) costly communication, but hides the complexity of shifting data around.

Sensor Node

Sensor Node

µC

µC

µC

µC

Cluster Head CPU

DSP

DSP

DSP

µC

IV. O PEN I SSUES AND F UTURE D IRECTIONS

OpenCL Devices Sink CPU

GPU

GPU

GPU

GPU

CPU CPU

OpenCL Host

Fig. 1. WSN platform model applied to OpenCL. The sensor nodes and cluster heads are OpenCL devices, with varying processing units. The sink is the OpenCL Host, though its processor can also be part of the devices. node sensor

pre process

feature extraction

node sensor

pre process

feature extraction

cluster head data fusion

post process

sink pattern recognition

decision

Fig. 2. Processing chain for SHM. The dashed clusters indicate which part of the processing chain could be executed on what device.

performance) heterogeneous platforms, with a strong focus on portability. Many of the concepts in OpenCL are a natural fit for WSNs, and provide to the right abstractions. III. E XAMPLE A PPLICATION : S TRUCTURAL H EALTH M ONITORING How OpenCL can be used in WSN programming is best illustrated with an example. Structural Health Monitoring (SHM) is the online monitoring of infrastructure, for example bridges or buildings, to detect damage or imminent failures using a wide array of sensors, i.e. for monitoring vibrations, stress and temperature [2]. The data of the various sensors needs to be pre-processed, fused and analysed, to decide whether a fault is imminent. Real-time operating is crucial. An example of a SHM processing chain is shown in Fig. 2. In a traditional deployment, a programmer would need to write code for the various part of the chain, and for different devices (microcontrollers, FPGAs. DSPs), in different programming languages, and implement mechanics for shifting data around. With an OpenCL-based WSN deployment, we can write the whole processing chain as a part of a single application for the Host. The different parts of the processing chain are coded in separate kernels. The kernels are then compiled and distributed to the appropriate devices. Lower level operation would still be handled by an framework such as Contiki, but development effort can be focused on the processing chain.

In adopting OpenCL for programming WSNs, there are a number of challenges that needs to be addressed. 1) Distributed Environment: OpenCL is designed to run on a single computer, and not in a distributed environment, in this case with low data rate, high latency and possibly lossy communication links. The underlying framework can hide most of these limitations, but some of them will still seep through. In addition, the optimisation metrics would change for WSNs, as communication (data transfers) can be very costly. The programmer therefore needs to be aware of this. In the field of distributed, grid and cloud computing, some work already has been done to cope with this [3]. 2) Resource Constrained Processors: Although future processors used in WSNs will be much more capable, some of them will still be quite resource constrained, compared to the processors often used with OpenCL. The embedded profile in OpenCL [4] helps in making support more manageable, but adaptations may be required. 3) Interacting with underlying framework: Although the OpenCL hides most of the hardware specifics, the kernel still needs to interact with the underlying framework or with other (local) kernels. Mostly to get the data from the sensor, to pass on data, or to change parameters such as sample interval or sensitivity. In the recently ratified OpenCL 2.0 specification, additions such as pipes and nested parallelism, will help, but more are probably required. R EFERENCES [1] J. Beutel, K. Roemer, M. Ringwald, and M. Woehrle, “Deployment techniques for sensor networks,” in Sensor Networks, ser. Signals and Communication Technology, G. Ferrari, Ed., Springer Berlin Heidelberg, 2009, pp. 219–248, ISBN: 978-3-642-01340-9. DOI: 10.1007/ 978-3-642-01341-6 9. [2] N. Xu, S. Rangwala, K. K. Chintalapudi, D. Ganesan, A. Broad, R. Govindan, and D. Estrin, “A wireless sensor network for structural monitoring,” in Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, ser. SenSys ’04, Baltimore, MD, USA: ACM, 2004, pp. 13–24, ISBN: 1-58113-879-2. DOI: 10. 1145/1031495.1031498. [3] R. Aoki, S. Oikawa, T. Nakamura, and S. Miki, “Hybrid OpenCL: enhancing OpenCL for distributed processing,” in ISPA 2011, May 2011, pp. 149–154. DOI: 10.1109/ ISPA.2011.28. [4] K. Pulli, “OpenCL in handheld devices,” 4th annual multicore EXPO, 2009.