## 3 Survey of Techniques for Updating
### Update Fault Detection and Recovery
#### Aging-Related Mandelbugs  
are a sub-type of _Mandelbugs_, and cause an increasing failure rate or degraded performance. The other approach, identified in [82] and used in [83], is to focus on a _single_ failure, with an easily identified symptom: that of being unable to perform future software updates. The reasoning is that if a software update _can_ be performed, the system is not in need of recovery (from a software update viewpoint), and that if it _cannot_ be performed, then recovery is needed (irrespective of whether the application is currently performing correctly). This does not detect faults that may result in corrupted or missing application data--but this can be done completely orthogonally to the update failure detection, and application correctness checking can run in parallel with the software update failure detection and recovery functionality. Software (or configuration) update faults are considered to be fundamentally different from faults in the original software--even though the symptoms may be the same--under the assumption that the original software has been extensively tested prior to deployment, whereas updates are applied post-deployment and may prove harder to test (or be subject to a less rigorous process). No matter how faults are detected, and how recovery takes place, there needs to be high-reliability recovery software available as an ultimate fallback if permanent network failure (_i.e._, loss of part, or all, of the sensor network) is to be avoided. A number of models have been presented for detection and recovery from _data_ faults in WSNs--for example [84, 85, 86, 87]. In this paper we propose a model for detection and recovery from **execution** faults, designed for use in an autonomous software/configuration update environment: WSN Update Fault Detection and Recovery (WSN-UFDR) shown in Figure 6. This model is based on an analysis of the required functionality. The model includes the usual operating system and applications: this may be in any execution environment (monolithic, modular, script-based, _etc._)--subject to three requirements: there must be a  
Figure 6: A Model for Software Update Fault Detection and Recovery. watchdog timer reserved for use by the UFDR (the update mechanism may chose to delete any such references, using for example null-operations as in [83]), there must be read-only space reserved to hold the _Fallback Update Manager_ which includes the bootloader, and there must be some non-volatile memory reserved (for example in EEPROM). An additional _Update Support Application_ (this may alternatively be an O/S module) is defined, which provides software/configuration update support, and interacts with the _Fallback Update Manager_, an independent software component outside of the operating system. Under non-fault conditions, a beacon originating from one or more management stations in injected into the WSN via one or more gateways, and is propagated by the _Support Application_ to all nodes, using either the O/S supported network stack, or directly using the Wireless Datalink Layer. Via the special communication channel between the fault detection components this resets the watchdog timer. The UFDR builds a model of beacon arrival rates, and if the beacon fails to arrive after a period (based on this model, and user-defined policy parameters) then the watchdog timer is allowed to expire. The behaviour of the _Recovery_ component is then based on the defined recovery policy and the stored fault recovery history--a reboot, a fallback to a previous software version, or ultimately a fallback to the _Fallback Update Manager_ image. If the _Update Support Application_ uses the O/S stack, network-wide recovery may require all nodes to revert to the _Fallback Update Manager_; but if the _Update Support Application_ and the _Fallback Update Manager_ use a compatible Datalink, then network-wide recovery may be able to occur with only some nodes reverting.