Concealing the Complexity of Node Programming in Wireless Sensor Networks Sebastian Bader, Bengt Oelmann Department of Information Technology and Media, Mid Sweden University Holmgatan 10, 85170 Sundsvall, Sweden
[email protected]
Abstract—There is a significant potential for Wireless sensor networks to be used as a general distributed measurement and monitoring system. The integration of computation, communication and sensing enables smart sensors to be built that can be adapted to a plethora of application requirements and allow for automated data collection throughout the network. However, the potential end users of this systems are domain experts, who usually do not possess the technical expertise to program, and thus operate, wireless sensor nodes, which prohibits the technology from becoming off-the-shelf equipment. In this paper, we present a method which enables the complexity of programming sensor nodes to be concealed in order to allow domain experts to use wireless sensor networks in basic applications without the requirement of technical assistance. We propose to use a computer-based specification entry, which generates a configuration parameter set to adjust the sensor node’s application behavior. The method has been implemented in a proof-of-concept system and evaluated with test subjects who possess limited programming skills. The results show that users without any prior programming knowledge, or experience with embedded systems, are capable of configuring a sensor node according to a given application scenario within minutes.
I. I NTRODUCTION Typically composed of several small-sized, low-power embedded sensor devices, wireless sensor networks (WSN) are a suitable technology for the setup of distributed measurement systems. This has led to the employment of WSNs in a large set of different application domains, ranging from large-scale environmental monitoring [1], [2] to industrial control systems [3]. In order to adjust the underlying sensor network platform to the requirements of the application at hand, the most common case is the development of an application software for the individual sensor nodes within the network. At present, this is usually performed using an embedded system compatible programming language, such as C, C++ or some sort of dialect. While these programming languages provide the user with a highly efficient interface to the sensor node’s resources, they demand a deep technical understanding of the systems and the languages in use. Although there has been a great deal of work in the field of programming abstraction and application development for this type of systems, the majority of the solutions are targeted for technically experienced developers. Implementations such
978-1-4673-5501-8/13/$31.00 © 2013 IEEE
as TinyOS [4], [5] or Contiki [6], [7], which have become de-facto standards for operating systems for wireless sensor nodes, have created a software platform that makes the sharing of code between research and development groups somewhat simpler. However, development still occurs on a low level, which requires knowledge of the underlying hardware platform. Languages with higher abstraction level, typically referred to as macroprogramming languages [8], simplify the description of complex tasks such as inter-node collaboration, but can still be considered to be technical programming languages, which demands a programmer’s way of thinking in order to describe and solve a specific application task. Many of the end users benefiting from a distributed measurement system (e.g., environmental scientists, meteorologists or building administrators) possess skills related to the application domain rather than technical skills related to the measurement instrument to be used. In current research projects and application proof-of-concept studies, application experts work hand in hand with system specialists. While this is a feasible option within research or large development projects, the necessity of system-level experts will prohibit the employment of wireless sensor networks as an off-the-shelf technology for measurement tasks. In this paper we present a method to enable domain experts without technical expertise to adjust wireless sensor nodes to their specific application requirements. Maintaining the traditional process chain from application specification to node implementation, the translation between these parameters is performed by a computer-aided interface rather than a system specialist. The generated node parameters are then inserted into a configurable node firmware, defining the node’s application behavior. While this approach limits the flexibility of node configuration to a pre-defined set of configuration possibilities, we believe that, particularly for smaller measurement tasks, in which technical consultation is economically infeasible, basic monitoring configurations are sufficient. In the remainder of this paper we present the design and evaluation of the proposed method. While Section II contains a review of related literature in programming abstraction and simplification, in Sections III and IV we introduce the underlying idea and implementation of the system. Section V
177
IEEE ISSNIP 2013
describes how the method has been tested and evaluated, and summarizes the results. Finally, we conclude the work and provide an outlook for further extension in Section VI.
Specification
II. R ELATED W ORK
Domain Expert
The majority of sensor node platforms in use are based on low-power microcontrollers, such as the MSP430 or the ATmega families. Due to the restricted resources these processors possess, they are typically programmed with rather lowlevel programming languages, such as Assembler or C. With the steady improvements in their energy efficiency, recently, more complex programming languages, such as C++ and Java [9], [10], have become more common. Whereas the lowlevel languages allow for a high degree of control and highly predictable system behavior, the more advanced programming languages include support functionality that can speed up the development time. As sensor nodes are typically part of a network, the source code running on these devices not only includes platformspecific code, but also requires functionality regarding network access and management, as well as certain services, in addition to the application code. In order to integrate these different software components, special operating systems have gained popularity within the community. The most commonly used instances of these operating systems are TinyOS [4] and ContikiOS [6]. Although these solutions make the development of complex applications easier for experienced developers, they still require the user to use low-level programming languages. Specific application-level programming languages for wireless sensor networks, such as Abstract Regions, Logical Neighborhoods or TinyDB [11], [12], [13], enable the user to program the complete network rather than individual nodes. Although this enables the simplification of the description of distributed tasks, the presented solutions are still programming languages that must be learned by the user. Several solutions for graphical programming of sensor nodes have been presented, both in academia [14] and in industry [15]. While these solutions make programming more intuitive, the development of a comprehensive library demands a significant amount of time. Furthermore, a basic understanding of programming principles remains expected of the user. A highly popular system for users with limited programming skills is the Arduino system, utilizing the processing [16] and wiring [17] languages – which are developed particularly for non-technical users – in order to simplify the programming task. Similar approaches can be found in sensor network related literature. In [18], for example, an archetype-based design method is presented, which targets domain experts as the developer group. However, while these mechanisms reduce the barrier into programming sensor nodes/networks, they do not remove the requirement to learn a programming language and the related programming principles. In this work, we present a method to configure a sensor node based on principles already known to the domain expert. Thus, the user is not required to learn programming languages,
Implementation
System Expert
Sensor System
Fig. 1. The typical design process of an application-specific measurement system. Specifications are translated into an implementation by a system expert.
Specification
Domain Expert
Configuration
User Interface
Configurable Sensor System
Fig. 2. The proposed design method for standard measurement and monitoring applications. The system specialist is replaced by a computeraided system interface.
which would prohibit sensor networks from becoming off-theshelf monitoring systems for small measurement projects. III. M ETHODOLOGY The design process of an application-specific sensor system typically involves domain experts, as well as system experts, such as is depicted in Figure 1. In this case the domain expert – who is the end user of the final measurement system – provides the specifications for the intended application. The system expert converts these specifications into requirements on the targeted sensor system, resulting in a system implementation. In measurement systems based on wireless sensor networks the underlying hardware platform for sensor nodes typically remains similar. Often controlled by a low-power microcontroller connected to a short-range wireless communication interface, the integrated sensors become the most applicationdependent hardware module in the system. In order to allow for the design of a general-purpose measurement system, sensors can easily be connected externally to a sensor node, making the system flexible for sensor requirement variations. This leaves the embedded software as the only adaptation required for different utilizations of the measurement system. In order to avoid the necessity of a system expert and, thus, to enable domain experts to use wireless sensor networks as an off-the-shelf distributed measurement instrument, an automated method for the translation of an application specification to a system implementation is proposed. While, in principle, the design process has maintained its previous format, two major changes have been introduced, which are shown in Figure 2. The two adaptations, which will be described in more detail in the following, are
178
1) A computer-aided specification entry 2) A configurable sensor node firmware
A. Application-Specific Parameters
C. Node Configuration
While wireless sensor networks can be used for many different applications within various application domains, one major utilization is the usage of the technology as a measurement/monitoring system. In these scenarios, the network typically acts in a many-to-one fashion [8], which means that many distributed nodes transfer their data to a central location in the network. In order to adapt sensor nodes for different monitoring purposes, adjustments to a set of application parameters can be performed. These parameters are related to the typical tasks of a wireless sensor node, namely sensing, communication, processing and storage. The greatest variation is typically expected in sensing, as different application scenarios require the monitoring of different physical values at various time intervals. The communication behavior of the nodes within these systems can typically be distinguished between being timedriven or event-driven [8]. While sensor sampling is usually performed periodically, a time-driven system also transfers the sampled data, or an extracted subset/result, in a timely manner. As opposed to that, in an event-driven system, the node only communicates if the sensor data indicates an event (e.g., a threshold crossing). Finally, processing and storage are not required in all application scenarios, but might be desirable for reducing data traffic and increasing reliability, respectively. Typical examples of simple pre-processing steps in measurement systems are min/max detection and sample averaging. Furthermore, sensor samples might be stored in a non-volatile memory to provide a backup to lossy communication links.
In order to allow the node to be adjusted to different application requirements, the firmware running on the device is parametrized. Functions, which are not required in a given application scenario, can be disabled and application parameters, such as the sampling rate, altered. The parameter set, required to define the node’s behavior, is automatically created from the specification entry tool that has been described in the previous section. The same tool is used to transfer the configuration parameters to the sensor node.
B. Computer-Aided Specification In a typical wireless sensor network system, the adjustments to the previously described parameters are made directly in the sensor nodes’ source code. This, however, requires the programmer of the node firmware to have knowledge of the application scenario, which is not the case if the system expert is no longer part of the application development. In this case, the end user should be able to make the required adjustments without the necessity of learning a technical programming language. Instead, the translation from application-level parameters to technical parameters should be concealed from the user, so as to simplify the application development. In order to fulfill this requirement, the method in this work uses a computer-aided tool for specification entry. As opposed to programming the sensor node directly, the user enters the node’s intended behavior on a higher abstraction level. The specification entry is performed by answering questions related to the intended application (e.g., how often a device should measure a certain value), thus, maintaining a similar approach to that which would be carried out by a system specialist in order to learn about the application requirements. The answers and selections made by the user are then translated into nodespecific configuration parameters in order to alter the node’s behavior to match the specifications.
IV. I MPLEMENTATION A proof-of-concept version of the presented method has been implemented. It includes a graphical user interface to collect specifications from the user, and which then translates the specifications to a configuration parameter set, and controls a configurable node firmware with the created parameter set. A key consideration for the implementation was to make it as simple as possible for an end-user to configure a sensor node to specific application requirements, while avoiding high performance degradation during node operations. A. User Interface As the user interface is the direct connection between the end-user and the technology to be setup, it is of utmost importance that the interface provides an adequate requirement level in relation to the targeted user group. In this implementation we target domain experts, which prohibits the use of conventional sensor node configuration interfaces, such as programming languages, because the domain experts typically do not possess the required skills. Instead, we have selected a wizard-like specification tool, which will be familiar to the majority of computer users from the installation of software. The wizard based tool provides two main advantages. Firstly, it provides a familiar graphical interface – and the related means of navigation – to the end user, and secondly, it allows the complex task of specification entry to be split into smaller steps thus avoiding the risk of overwhelming the user. The implementation was carried out using the crossplatform application framework QT [19]. This allowed us to rely on a large developer community, which provides many frequently used software components, as well as an easily portable application code. Figure 3 depicts a high-level overview of the implemented specification process, wherein the specification entry is divided into smaller configuration steps following the task classification presented in Section III-A. Furthermore, Table I provides a listing of the specifications to be made in each of the process steps. In order to make the specification process self-explanatory and intuitive, simplicity is the major design concern for the graphical user interface. Thus, specification entry is performed by answering short questions, which would be the natural interface of a system specialist in order to obtain the information necessary to implement the system.
179
Node and Network Parameters
Fig. 3.
Sensor Selection and Configuration
Communication Method (Time vs. Event)
Processing and Storage Options
Configuration Listing
Lifetime Estimation
Save Configuration and Configure Node
High-level overview of the specification process. The process is divided into separate steps to reduce confusion of the end user.
After the specifications have been entered, the user interface provides an overview of the resulting sensor node behavior. This overview is presented in clear text (i.e., not only single parameters) and allows the user to verify that the specifications provided will result in the intended sensor node behavior. After this verification process, the end user is presented with a lifetime estimation of the node running the specified configuration. This provides the user with the possibility to adjust specifications made with respect to the desired system lifetime. Finally, the user can upload the configuration parameters – which are automatically generated from the specification – to the sensor node. In this implementation, upload is carried out via USB, but can easily be adapted to be wireless, as only a set of parameters, as opposed to a complete application code, must be transmitted. The parameter set in the proof-ofconcept implementation contains 17 bytes, but will vary with the number of sensors available to the system. B. Node Firmware In order to be able to adjust the behavior of the sensor node, a configurable node firmware has been developed. The firmware receives and stores the configuration parameter set, generated by the specification software, and adjusts its application behavior accordingly. As the configuration parameters are stored in a non-volatile memory, the previous operation mode can be restored after a reset condition or a power failure. Furthermore, as opposed to a re-programming of the node application, the transmission of a small configuration parameter set is less prone to errors that would require technical assistance for the end user. The firmware has been implemented on SENTIO-em, a mote-type sensor node platform developed at Mid Sweden University. SENTIO-em uses an ARM Cortex-M3 controller running at 32 MHz, and allows to be equipped with different hardware modules so as to be versatile to sensing, communication and power requirements. Table II shows the hardware configuration of the modules used in the prototype implementation. For the communication, a WSN-typical IEEE 802.15.4 transceiver has been chosen. A SHT15 temperature and humidity sensor was implemented as an example sensor. Furthermore, the node is powered by battery or USB connection. A relay-based circuitry allows for the automatic selection of the power source, depending on its availability. In addition, the USB connection is used for the transmission of configuration parameters generated on a host computer. The configuration parameters, and optionally measurement data, are stored on a microSD card, which allows for a size and
cost efficient storage medium. The entirely integrated node is shown in Figure 4. For the firmware implementation, a finite state machine (FSM) framework has been utilized. In this framework, a separate definition of states and transitions is made to form the FSM. Transitions can occur directly at the completion of a previous state, but are most often triggered by an external event (e.g., a timer interrupt). Furthermore, the framework supports the use of hierarchical state machines, which allows for a simplified implementation of complex state trees. In this scenario, for example, the usage of a hierarchical state machine would be recommendable in the case involving the support of many different sensor types. The major advantage of utilizing a state machine programming model for the configurable firmware is its runtime efficiency. In a typical implementation of the configurable code, the final application can easily become inefficient, because of the execution of several ifelse or switch blocks. The more configuration options that are included, the more overhead is added to the final application code. As opposed to this, a FSM implementation can avoid most of this overhead by implementing selections in form of states. In the case of a reconfiguration of the application code, only the state transition tree has to be changed, which results in
180
TABLE I D IVISION OF SPECIFICATION STEPS Wizard Page
Specification Parameters
Node/Network Sensing
Node name and network affiliation Sensor selection and sample rate Time- or event-driven communication Sensor threshold (only event-driven) Processing type and sample set Storage option (all or transmitted samples) Clear text node behavior listing Lifetime estimate and adjustment options Configuration save and upload option
Communication Processing/Storage Verification Lifetime Configuration
TABLE II H ARDWARE C ONFIGURATION Module
Implementation
Computation
Energy Micro EFM32 (ARM Cortex M3), 32 MHz, 128 kB Flash, 16 kB RAM microSD card Digi International XBee 802.15.4, 2.4 GHz Sensirion SHT15 (temperature and humidity) USB or Battery, automatically selected
Storage Communication Sensing Power
Power Supply Selection and USB Interface
Temperature and Humidity Sensor
the last task of a period has been completed, the node enters into a power conserving sleep mode until the next task period begins. In order to be able to update the configuration, the node can enter a special configuration update state, which can be triggered from any place in the FSM by an external event. In the proof-of-concept implementation, the event leading to the configuration update event was chosen to be the plugging of the USB cable to the host computer. At this time, the normal operation of the node ceases and it waits for the reception of a new configuration parameter set, which is then stored and used to update the transition tree. Once, the configuration is updated, the application continues its operation, using the newly configured application code.
SENTIO-em Node Platform
V. E VALUATION Fig. 4. Integrated prototype of the configurable sensor node based on the SENTIO-em platform. A detection circuit allows to automatically select the power supply, as well as to enter the configuration state when the device is connected to the host computer.
Initialization
Load Existing Configuration
Configuration Update
Periodic Sleep
Sensor Sampling
Communication
Processing
Storage
Fig. 5. High-level overview of the configurable node firmware. Different modules are implemented in form of individual states of a finite state machine.
a single-time overhead. After the reconfiguration, no overhead is added to the application at runtime. As it is assumed that the operation time is much longer than the reconfiguration time, the overhead added is minimal. Figure 5 shows an overview of the FSM implemented for the configurable firmware on the prototype. The figure shows the implementation on a high abstraction level, which means that the blocks, shown in the graph, can be split into several FSM states or even individual state machines in the implementation. The application code consists of a setup and a periodic part. In the setup, the hardware is initialized and the previous configuration (if it exists) is loaded. Afterwards, the node enters the periodic part of the application, wherein it performs its tasks according to the configured state transition tree. After
In order to evaluate the presented method, the implemented prototype system was given to a group of test users. The group consisted of ten users, of which half had prior knowledge of programming principles while the other half did not. While the users without programming experience have been chosen due to their similarity to the targeted end user group, the users with prior programming knowledge have been added to gain more feedback on the system’s design and usability. As most of the test users did not have the domain knowledge that provides the measurement system constraints, the users had to place themselves in the role of a domain expert. In order to allow the test user to take the required role, several application scenario descriptions have been composed. These scenarios describe the desired sensing task (i.e., the final goal of using the measurement system), reasons why the user wants to use the sensor network technology, as well as a set of application requirements (e.g., min. measurement rate, lifetime requirements, or maximum notification latency). The scenarios covered basic monitoring applications for wireless sensor networks, ranging from the periodic monitoring of environmental parameters to event detection (e.g., for fire detection). Allocation of the application scenarios to the test users occurred randomly. The users were then provided with the configurable sensor node, which for them was merely a black box, that they could attach to a computer via a USB cable. No further interaction with the sensor node hardware was required. Furthermore, the specification tool was used to configure the sensor node according to the application requirements received in the scenario description. During this period, no support was provided for the test user, which meant that the system had to be self explanatory. The intention of this method was to determine whether the user was able to make the specifications desired without technical assistance, which would be the case if the system is used as an off-the-shelf measurement equipment. The evaluation of success took place based on two factors. First, the configuration on the sensor node was read out, in order to determine the successful configuration of the device. Furthermore, the specifications that have been entered in the graphical entry tool have been controlled to verify the correct implementation. In addition to the pure determination of
181
success, the users filled out an evaluation form and participated in a short interview. In this phase, the user provided an estimation of his own prior knowledge related to computer usage, embedded systems and programming, as well as a feedback regarding the configuration system. All ten users have managed to configure the provided sensor node in a time period of about 10 to 15 minutes. No prior preparation for the task was required, with the exception of reading the scenario description. Of the ten users only one was considered to have failed in relation to the application implementation. The analysis of this case showed that the user was able to configure the node, but had difficulties understanding the application scenario, leading to a confusion of parameters. Furthermore, we were able to extract a set of improvements for the user interface from the comments provided in both, the evaluation form and the user interviews. The majority of these improvements relate to verbal formulations. VI. C ONCLUSION While the technology of wireless sensor networks shows continuous improvements, existing systems cannot be easily used by end users with limited technical expertise. These, however, form the majority of the targeted end user groups. In particular, if wireless sensor networks should be able to be used as an off-the-shelf measurement instrument, an improvement of the end user interface is required. In this paper we have presented a method for concealing the complexity of programming sensor nodes in a wireless sensor network. We have circumvented the requirement for a systems expert by providing a computer-based specification tool to the end user, which enables the generation of sensor node configurations for basic measurement and monitoring tasks. While it is unlikely that the method will scale well to complex applications, it is particularly the basic applications that make technical assistance economically infeasible. The generated parameter set is loaded to a configurable node firmware, which avoids any change with regards to the embedded software running on the sensor node. A finite state machine based programming model was utilized to avoid runtime overhead, while making the node flexible to application configurations. A preliminary evaluation of the presented method has been conducted with a group of test users. The users were asked to implement a node functionality based on a provided application scenario description. While all the test users were able to configure the provided sensor node, in one case, the result was judged unsuccessful, as parameters have been confused. As this was interpreted as a problem with the clarity of the scenario description rather than the user interface, we do not expect this to occur when providing the system to domain specialists. While the preliminary evaluation demonstrated the usability of the proposed method, there are a couple of topics that must be addressed in further investigations. Primarily, to obtain a more representative evaluation, we hope to provide the system to domain specialists for its usage in a real application scenario. This will, in particular, provide feedback on the
implemented configuration options (e.g., which parameters a domain specialist needs to adjust). Also we plan to address the question of implementing additional sensors to the platform. At the current state, the firmware has to be prepared for each sensor that might be connected to the node. In cases involving new sensor integration, a method that avoids an firmware update is desirable. R EFERENCES [1] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J. Anderson, “Wireless sensor networks for habitat monitoring,” in Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications - WSNA ’02, 2002. [2] G. Barrenetxea, F. Ingelrest, G. Schaefer, M. Vetterli, O. Couach, and M. Parlange, “SensorScope: Out-of-the-Box Environmental Monitoring,” in 2008 International Conference on Information Processing in Sensor Networks (IPSN 2008), Apr. 2008, pp. 332–343. [3] V. C. Gungor and G. P. Hancke, “Industrial Wireless Sensor Networks: Challenges, Design Principles, and Technical Approaches,” IEEE Transactions on Industrial Electronics, vol. 56, no. 10, pp. 4258 –4265, oct. 2009. [4] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, “System Architecture Directions for Networked Sensors,” ACM SIGARCH Computer Architecture News, vol. 28, no. 5, pp. 93–104, Dec. 2000. [5] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, “The nesC language: A Holistic Approach to Networked Embedded Systems,” in Proceedings of the ACM SIGPLAN 2003 conference on Programming language design and implementation - PLDI ’03, 2003. [6] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors,” in 29th Annual IEEE International Conference on Local Computer Networks, 2004, pp. 455–462. [7] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali, “Protothreads - Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems,” in Proceedings of the 4th International Conference on Embedded Networked Sensor Systems - SenSys ’06, 2006. [8] L. Mottola and G. P. Picco, “Programming Wireless Sensor Networks,” ACM Computing Surveys, vol. 43, no. 3, pp. 1–51, Apr. 2011. [9] F. Aiello, G. Fortino, R. Gravina, and A. Guerrieri, “A Java-Based Agent Platform for Programming Wireless Sensor Networks,” The Computer Journal, vol. 54, no. 3, pp. 439–454, Feb. 2010. [10] N. Brouwers, K. Langendoen, and P. Corke, “Darjeeling, A Feature-Rich VM for the Resource Poor,” in Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems - SenSys ’09, 2009. [11] M. Welsh and G. Mainland, “Programming Sensor Networks Using Abstract Regions,” in Proceedings of the 1st conference on Symposium on Networked Systems Design and Implementation - Volume 1, 2004. [12] L. Mottola and G. P. Picco, “Logical Neighborhoods : A Programming Abstraction for Wireless Sensor Networks,” Distributed Computing in Sensor Systems, vol. 4026, pp. 150–168, 2006. [13] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “TinyDB: An Acquisitional Query Processing System for Sensor Networks,” ACM Transactions on Database Systems, vol. 30, no. 1, pp. 122–173, Mar. 2005. [14] E. Cheong, E. A. Lee, and Y. Zhao, “Viptos: A Graphical Development and Simulation Environment for TinyOS-based Wireless Sensor Networks,” in Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems - SenSys ’05, 2005. [15] “National Instruments Wireless Sensor Networks - Website,” http://www. ni.com/wsn/, (accessed November 2012). [16] “Processing Language – Website,” http://www.processing.org/, (accessed November 2012). [17] “Wiring Language - Website,” http://wiring.org.co/, (accessed November 2012). [18] L. S. Bai, R. P. Dick, and P. A. Dinda, “Archetype-based design: Sensor network programming for application experts, not just programming experts,” in Proceedings of the 2009 International Conference on Information Processing in Sensor Networks, 2009, pp. 85–96. [19] “QT Programming Framework - Website,” http://qt.digia.com/, (accessed November 2012).
182
