Fault Prediction in Wireless Sensor Networks
Hang Tuan Thien1 and Myungsik Yoo2
1 Department of ICMC, Soongsil University, Seoul, Korea Republic of. (Email: [email protected])
2 School of Electronic Engineering, Soongsil University, Seoul, Korea Republic of. (Email: [email protected])
Abstract
Nowadays, Wireless Sensor Networks are becoming a very popular technology. Several applications have been developed in Wireless Sensor Networks such as Agriculture, Air pollution, Forest Fire, Gas Leakage, etc. However, a lot of issues can affect the reliability of a wireless sensor network. Any error can occur on the way from the source nodes to Sink nodes or cloud managers. Therefore, Wireless Sensor Networks require testing on multiple levels to reduce fault as fast as possible. Many previous studies have been developed to solve these problems. However, they only run the test specification for the first time or after the faults happen. Moreover, several issues can affect the reliability of the wireless sensor networks after deployed such as lack of energy, software malfunction, and the harsh environmental conditions. This article proposes a new prediction testing mechanism for Wireless Sensor Networks application base on the automation testing and machine learning system.
I. Introduction
Presently, Wireless sensor networks have been developed and deployed either on academia or industry. A lot of applications over wireless sensor networks are growing quickly. However, the sensor nodes may fail due to a lack of batteries, nodes hardware or software malfunction, harsh environmental conditions, high network transmission delay, data transmission congestion, etc. Data from sensor nodes can be incorrect that causes the wrong received data at the base station or manager. Moreover, congestion or fault in the Sink can cause the failure of the network. Data can be lost by preventing transmission tasks or retransmitted in the Sink node within the period of fault time. Furthermore, the node is unreachable because of the changing of network topology. Finally, they will lead to permanent faults in the system. Therefore, it is very necessary for testing Wireless Sensor Networks not only before they are deployed but also on the time they are running.
Many studies and researches have been developed for testing Wireless Sensor Networks recently. Different testing purposes have different testing requirements. Most of them designed an architecture for collecting and analyzing the collected data when the fault occurred. They then try to classify the fault or localize the area where fault happened. Many simulations or emulations have been designed to support testing protocols in Wireless Sensor Network. They try one best to model exactly the real environmental characteristics in different cases. Nonetheless, many problems can cause faults in real deployment because of unrealistic assumptions or oversimplified models. To solve such problems, Testbeds try one best to bridge between simulation and real deployment by providing an environment for protocol testing and evaluation that is similar to actual deployment. On the other hand, to reduce both time and cost for the continuous testing process when adding new hardware in Wireless Sensor Networks, the Continuous Integration system is considered to support the current system for automatically deploying and executing new test specifications. Continuous Integration principles help to reduce the workload of the core maintainers. The Continuous Integration process includes source code version control systems and automatic tools that assert the new code’s correctness. Moreover, data prediction will be useful to detect the problems of the wireless sensor networks in the future. Some methods can be used to reduce data transmission, find out abnormal data or avoid accidents. In this paper, we use a machine learning system for fault prediction based on historical data collected. We also propose a process that can detect and classify the faults that occur in both node and path. After classifying the fault, a report is made and sent back to the user. Differently, collected data will be also sent back to the cloud for fault prediction in the future. If the next event is predicted to fail, the automation system will receive a message for running test specifications. In addition, a cache system is deployed inside every node to store test specifications. We will discuss in detail some related work in session 2, and full of the architecture in session 3.
II. RELATED WORK
There are many studies and researches on testing Wireless Sensor Networks. The testing platforms are designed based on the specific testing purpose for completing the expected testing task. In most of these studies, the main objective is to check if the data handled by the wireless sensor network that is computed or transmitted without errors. Very few works concentrate on predicting fault. We will discuss some of these studies below:
TUnit is a unit testing framework designed for Tiny OS and sensor networks [1]. TUnit requires users to define test specifications in the form of OS modules that are programmed onto a node. There are two types of nodes in TUnit. The first one is the driving nodes which are the primary node and runs the test files. They wait for the command to begin testing from the computer. After that, they will run each test case in the test suite. The second is the supporting nodes that are any node except driving nodes. They may be alerted wirelessly by the Driving Node to begin running some function. Because of only providing test input for the driving node, TUnit has some limitations. For example, the specified tests in TUnit execute on a single node, hard to find the cause of failure because the output is true or false values. The paper [2] proposes a new Unit Test for Wireless Sensor Networks which is called MUnit. The test specifications in MUnit are generated at PC on a standard template. Next, they load the test programs to each node on the network and start the test remotely. These nodes then execute the test by giving input to the modules and receive output. The collect results come back to the PC for exporting testing reports.
In [3], they propose the observer component that role as a tester. Observers are controlled by a user or by an automated process. According to the radio area coverage of sensors, they divide the network into several subnetworks to determine the observer’s location on the network. They have a local base station for each subnetwork. It is a special node that provided communication and collected data between regular nodes and the observer. First of all, the observer sends input action messages to the base station. Such messages are transmitted to all nodes. After receiving the message, each node sends a reaction message back to the base station. Finally, the base station transmits it back to the observer. After analyzing the output reactions and checking respectively timed constraints, the verdict is produced by an observer and concluded that the Wireless Sensor Network is at fault or not. Sometimes, the coordination messages can be sent to each other among the observers. There are many limitations that still exist in this study. The main issue is how to determine where the fault happens. It is because data from sensor nodes can be incorrect that causes the wrong received data at the base station. Link errors result in the changing of network topology lead to the loss of unreachable data in each node.
A tool names Sympathy is designed in [4] for detecting and debugging failures in sensor networks. First of all, they design a Sympathy code on nodes to transmit metrics and respond to occasional queries. The Sink collects metrics from other nodes in the system. Then, they analyze these metrics and looked for insufficient data received from any node, including itself. After that, if failure is detected, the root caused failure will run the test as necessary to determine the cause. Finally, all existing failures in the system at that time will be localized in one of the three sources: Failures are localized to the node itself, failures occur due to a failure along the path from the node to the Sink, and failure at the Sink node. All the same, metrics when collecting data from every node are not necessary or redundancy. The other limitation of this paper is testing running after a failure occurred.
Test environments are required to redesign or continuously updates when the system upgraded. The paper [5] proposes a framework that can be using the Continuous Integration Test System for automation tests. On the first step, a new Testbed device registers with the automatic system that it is available for testing. Besides this step, the developer commits the new testing specification to the repository. Then, they are initiating and triggering the automation system. The automatic system pulls the new testing specification from Repository System and executes the deployment scripts specifying to the Testbed devices. Next, the changes from the repository are deployed to the Testbed device. They create the build process on the manager node (infrastructure node). After that, the manager node flashed the built firmware to target nodes and the target nodes execute the test process. All in all, the manager node collects the results from the target node, checks them and sends the results back to the users. Although the test case can be updated after application deployed, test scripts are simple and fault non-classified. After wireless sensor networks application has been deployed for a long time, faults may still happen because of many reasons such as lack of energy, malfunction in software or hardware. Therefore, testing continuously in a period of time after deploying is necessary but they do not mention.
III. PROPOSED FAULT PREDICTION ARCHITECTURE IN TESTING PROCESS
Base on the existing Continuous Integration process in [5], our paper proposes a process depicted in Figure 1. We assume that each node will comprise a cache block to store the test specifications. They received execution messages from the Sink node to run the test script. If the developer updates a new test script, these nodes will also receive a message to upgrade the new version code. We suggest three additional blocks in the Sink node. Firstly, “Collect Data” Block is used to collect data from either other neighbor nodes or itself. Secondly, these data will compute and detect the failure at “Detect Failure” Block. At the end of this process, data will send back to the cloud for prediction purposes. At the same time, the fault data is classified at “Classify Failure” Block. They are then used to make a report for users. Three blocks in Cloud are known as “Test Spec Repository”, “Failure Prediction”, and “Automation System”. The “Test Spec Repository” is where the user stores the specification, configuration files that are needed for the “Automation System” block. They will include a system to control code versions like Git. The “Automation System” Block is very important. It consists of a lot of tools and that support for automation test. Such block will receive a command from “Test Spec Repository” or “Failure Prediction” or from Sink Node to trigger the test. We will discuss in more detail three following steps below:
Fig. 1. The architecture of Fault Prediction in Wireless Sensor Networks Testing Process.
Step 1: Register test:
There are three types of event that activate the automation System:
When a new device (target node) is deployed for the first time, they send a request for testing. The Sink node will check the existing specification script for the new device on “Test Spec Cache” and register with the automatic system that this new device is available for testing.
The developers store and update the new testing specification to the repository. They will initiate and trigger the automation system.
The machine learning system collects the data from every node and recognizes that fault can happen in some places in the future. It then sends the request for testing Wireless Sensor Network.
Step 2 Active test:
After receiving a testing request from Step 1:
If the test scripts from Repository are changed, the automation system pulls the test scripts from the Repository and deploys them to the Sink node. Next, the Sink nodes initiate the build process and update the test script on the cache. Finally, they flash the built firmware to the target node and execute it.
If nothing changes on the Repository, the automation system sends a testing message to the Sink node. Then, they send the execute message to the target node.
Step 3 Run test:
After running the test scripts, the Sink node collects results from every node, including itself. Collected data are computed and detected failure will be classified. At the end of the task, computed data will be sent back to the cloud for predicting and a report will be sent to users.
CONCLUSIONS
In this paper, we have proposed an architecture for the testing process in Wireless Sensor Network. Thanks to the Continuous Integration Testing and Machine Learning system, the architecture not only detects the fault in real-time but also predicts the fault that can happen in the next step base on history data. We also design the cache component inside both the Sink node and the target node to store testing specifications. Besides that, we suggest a sub process in the Sink node to detect and classify the fault. Future work will provide some methods to improve the performance of fault detection and classification.
Acknowledgement
This work was supported by Institute of Information & communications Technology Planning & Evaluation (IITP) grant funded by the Korea government (MSIT) (No. HI19C1032, Implementation of verification platform for ICT based environmental monitoring sensor)
References
TUnit in TinyOs: http://tinyos.stanford.edu/tinyoswiki/index.php/TUnit
Michael Okola, Kamin Whitehouse. “Unit Testing for Wireless Sensor Networks Proceeding SESENA”. Proceedings of the 2010 ICSE Workshop on Software Engineering for Sensor Network Applications Pages 3843.
C ́edric Ramassamy, Hac`ene Fouchal, Philippe Hunel,Nicolas Vidot. “A pragmatic testing approach for Wireless Sensor Networks”. Proceedings of the 6thACM workshop on QoS and security for wirelessand mobile networks, Oct 2010, Turkey.
Nithya Ramanathan, Kevin Chang, Rahul Kapur, LewisGirod, Eddie Kohler, and Deborah Estrin UCLA Center for Embedded Network Sensing. “Sympathy for theSensor Network Debugger”. In ACM SenSys ‘05 SanDiego, CA, 2005.
Matevz Vucnik ; Tomaz Solc ; Urban Gregorc ; AndrejHrovat ; Klemen Bregar ; Miha Smolnikar ; CarolinaFortuna; Mihael Mohorcic. “Continuous Integration in Wireless Technology Development”. In Journals and Magazines IEEE Communications Magazine Volume: 56 Issue: 12.