REDFLAG: A REal-time, Distributed, Flexible, Lightweight, and Generous Fault Detection Service

Author: Iñigo Urteaga

REDFLAG is a distributed fault detection and diagnostic service for sensor applications. It provides two subservices: the Sensor Reading Validity subservice (SRV) and the Network Status Report subservice (NSR). The former applies signal processing and rule-based techniques to validate sensor readings, so that abnormal readings are recognized. The latter collaboratively monitors WSN nodes and link connectivity to abate data loss. Subservices provide clean interfaces for both service configuration and report notification purposes.

Sensor Reading Validity (SRV) subservice

WSN applications are designed to monitor all kinds of phenomena using diverse sensor types. Sensors translate a physical magnitude of interest into human or machine readable signals. However, the translation process is subject to many non-ideal factors: sensitivity variations, scale and offset dynamic errors, calibration drifts, hysteresis, noise, non-linearity effects, etc. Systematic errors (influenced by offset, scale ranges, sensitivity variations, non-linearity, etc.) may be handled by calibration; whereas, random errors (primarily noise) may be compensated for with signal processing techniques.

The SRV subservice uses a clearly defined interface to interact with the application. First, a configuration command is provided so that the application can determine and adjust the service parameters anytime, since they are sensor specific and are influenced by the deployment and application requirements. Second, the SRV subservice provides a read command which is a call to get a new sensor reading. The application receives back both the final reading and a validity field. The validity field indicates whether the reading is valid (i.e., if it passes the considered rules), or, if it is invalid, which type of failure(s) was detected.

Network Status Report (NSR) subservice

Typical WSN deployments are subject to unforgiving environments where node and link failures are likely to happen. Nodes may appear unresponsive if they run out of battery, are broken, or if connectivity with their neighbors is lost. Missing data from unresponsive nodes is a serious problem. Moreover, specific applications may require ancillary information such as notification of temporary link failures. Hence, the primary goal of the NSR subservice is to detect unresponsive nodes and diagnose their root causes.

The NSR subservice provides a clean interface to interact with the application. On the one hand, configuration commands are defined in order to determine and adjust all the relevant service parameters anytime. On the other, the NSR subservice provides an event based reporting interface, where detailed information regarding the status of the network is conveyed.

Implementation details and configuration

The code provided here is written in nesC for the TinyOS operating system ( It has been developed for version 2 of TinyOS, tested and correctly executed with TinyOS v2.1 and CVS modifications up to 2009/07/15. Therefore, the dependencies and requisites to meet for this code to be compiled and run are directly mandated by TinyOS itself. Even if REDFLAG’s code has been tested using TOSSIM, porting it to real TinyOS running motes should not be traumatic.

REDFLAG_code.tar.gz contains the following 4 directories:

  • src: This directory contains three directories where the actual REDFLAG code and two accesory components are implemented:
    • “./src/EnergyEstimation” -> energy consumption estimating component, which computes energy depletion based on radio transmission, reception and idling periods. -“./src/SimulatedSensor” -> simulated sensor to be used when running REDFLAG within TOSSIM. Sensor readings are provided externally via python Radio or Serial messages at run-time. -“./src/REDFLAG” -> Source for the REDFLAG fault detection service for WSN. It contains the definition of the provided interfaces and both the NSR and SRV subservices. The user of this code should only need to interact with components
    • “./src/REDFLAG/SRVSubservice/SRVSubserviceC” and “./src/REDFLAG/NSRSubservice/NSRSubserviceC” plus their corresponding interfaces.
  • DemoApp: Example application of how to run REDFLAG within TOSSIM. “./DemoApp/” illustrates how to wire the corresponding components and interfaces to have a working application, while “./DemoApp/” is a good example of how to configure REDFLAG’s NSR and SRV subservices and how to process its notifications and events.
    • In order to execute REDFLAG within TOSSIM, first install TinyOS and TOSSIM in your system, then compile DemoApp within its directory by running “make micaz sim” and, finally, run the simulation executing “python”. Besides some output shown in the terminal, several debug channels (where important information regarding REDFLAG’s execution is saved) are redirected to files within directory “./DemoApp/Debug”.
  • Files: Auxiliary directory containing important input files for the DemoApp to be run in TOSSIM: topology and concentration information, noise-traces, etc.
  • Scripts: Auxiliary python scripts to be used within TOSSIM.