Study Notes

Only available on StudyMode
  • Topic: Interrupt handler, Software testing, Interrupt
  • Pages : 36 (11354 words )
  • Download(s) : 46
  • Published : March 7, 2013
Open Document
Text Preview
Inter-Context Control-Flow and Data-Flow Test Adequacy Criteria for nesC Applications* Zhifeng Lai and S.C. Cheung†
Department of Computer Science and Engineering Hong Kong University of Science and Technology Kowloon, Hong Kong

W.K. Chan
Department of Computer Science City University of Hong Kong Tat Chee Avenue, Hong Kong

{zflai, scc}@cse.ust.hk

wkchan@cs.cityu.edu.hk

ABSTRACT
NesC is a programming language for applications that run on top of networked sensor nodes. Such an application mainly uses an interrupt to trigger a sequence of operations, known as contexts, to perform its actions. However, a high degree of inter-context interleaving in an application can cause it to be error-prone. For instance, a context may mistakenly alter another context’s data kept at a shared variable. Existing concurrency testing techniques target testing programs written in general-purpose programming languages, where a small scale of inter-context interleaving between program executions may make these techniques inapplicable. We observe that nesC blocks new context interleaving when handling interrupts, and this feature significantly restricts the scale of inter-context interleaving that may occur in a nesC application. This paper models how operations on different contexts may interleave as inter-context flow graphs. Based on these graphs, it proposes two test adequacy criteria, one on inter-context data-flows and another on intercontext control-flows. It evaluates the proposal by a real-life open-source nesC application. The empirical results show that the new criteria detect significantly more failures than their conventional counterparts.

1. INTRODUCTION
NesC language [10] is designed for programming wireless sensor network (WSN) applications that are deployed on a collection of small low-powered low-capability devices known as motes. Each mote usually has sensing and wireless communication capabilities. WSN applications are useful for monitoring their physical environments. Most nesC applications running on motes are interrupt-driven, so hardware processors of these motes can sleep and conserve energy when there is no interrupt. In general, event-driven programming is popular for handling interrupts in networked embedded systems running on top of TinyOS [14], TinyGALS [6], or SOS [12]. In the event-driven programming paradigm, developers implement application logic through cooperative event handlers. A high degree of interruptbased concurrency complicates the program design to carry out the desired cooperation [10]. For instance, an abrupt interrupt may occur during the time when an event is being handled. The occurrence of the interrupt may potentially interfere with the event handler through unforeseen dependencies between the event handler and the code that handles the interrupt. Programming nesC applications is an error-prone task: developers of nesC applications need to explicitly handle numerous interrupts in their code. Researchers have reported the problems of data races [10][13], interface-contract violation [4], and memory safety [7] in these applications. Although nesC is designed to ease static analysis, existing static checking [13] and runtime verification [4][7] techniques do not provide a satisfactory solution to these problems. For instance, efficient race detectors [10] may not identify some race conditions (c.f. TinyOS-Help1, a major discussion mailing-list of TinyOS related problems); powerful race detector [13], however, is subject to scalability and precision problems. Even if the errors identified by these techniques have been corrected, the modified nesC applications may still have latent faults. Testing is a major means to assure the quality of software. However, existing testing techniques for sequential programs [9][11][16] address the interactions among interrupts inadequately. In sequential programs, subroutines call one another (termed a calling context). In nesC applications, an...
tracking img