Intermittent fault

<h2 id="troubleshooting-techniques">Troubleshooting techniques</h2>
<p>Some techniques to resolve intermittent faults are:
</p>
<ul><li>Automatic logging of relevant parameters over a long enough time for the fault to manifest can help; parameter values at the time of the fault may identify the cause so that appropriate remedial action can be taken.</li>
<li>Changing operating circumstances while the fault is present to see if the fault temporarily clears or changes. For example, tapping components, cooling them with freezer spray, heating them. Striking the cabinet may temporarily clear the fault.</li>
<li>a database of similar faults which have been resolved in identical or similar equipment<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a></li>
<li>precautionary changes, without attempting to pinpoint the fault. For example, <a href="/facts/Electrolytic_capacitor/0v22NBVt">electrolytic capacitors</a> subject to high <a href="/facts/Ripple_current/T9mzYBAh">ripple currents</a> can be changed as a routine measure, without bothering to troubleshoot the fault at all. Connectors can be disconnected and reseated. This is sometimes a measure of desperation; things are changed until the fault stops happening, and it is hoped that it is actually resolved rather than dormant.</li>
<li>In electrical systems and cable systems, time domain reflectometry techniques can be used: pulses are sent down electric wiring and the pulses reflected back are examined for anomalies, for example intermittent leakage during the stresses of aircraft operation; this can only be done for one test channel at time and is generally limited to intermittent faults >100milliseconds.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a></li>
<li>In complex, multiple channel systems, where the fault/s might be in an interconnection, the ideal method of finding an intermittent fault is to be able to monitor, detect and isolate all channels or electrical paths continuously and simultaneously. This methodology allows the system under test to benefit from continuous and complete test coverage while any environmental stressing of the system is performed. This type cannot be performed by scanning testing technology but needs to have some form of electronic neural-network which can perform these test without the need for any scanning and/or digital averaging; this testing regime is covered by the DoD's <a href="http://jteg.ncms.org/wp-content/gallery/20151029_IntermittanceTesting/JTEG%20MIL-PRF%20Brief.pdf">MIL-PRF-32516</a> published in March 2015 and it calls for testing technology to operate in the Class 1 category in order to combat intermittent faults effectively.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a></li>
<li>Three main methodologies to mitigate intermittent behavior in integrated circuits are dynamic instruction delaying, core frequency scaling, and thread migration. When the processor incurs more than the expected time to execute a process, time delay and timing violation occur. This fault may be avoided by using techniques such as dynamic instruction delaying. This is a type of algorithm that calculates the scheduling priorities during the execution of the system. The objective is to respond dynamically to the changing conditions and form a self-sustained, optimized configuration. Another approach to mitigating delay is core frequency scaling, which scales down the performance of the CPU to a lower frequency when less is needed and scales it up to a higher frequency when more is needed. Thread migration is another technique used to overcome intermittent failure. A thread is an ordered set of instructions that tells a computer exactly what to do. When a specific thread encounters failures, the content of the thread within the faulty computer core is transferred to another thread within an idle core, where the problem is addressed and solved.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">A discussion of software debugging</a></li>
<li><a href="http://www.repairfaq.org/sam/tshoot.htm#tshint">Sci.electronics.repair FAQ, see section "Troubleshooting of Intermittent Problems"</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Bakhshi, Roozbeh; Kunche, Surya; Pecht, Michael (2014-02-18). "Intermittent Failures in Hardware and Software". Journal of Electronic Packaging. 136 (1): 011014. doi:10.1115/1.4026639. ISSN 1043-7398. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>Qi, H.; Ganesan, S.; Pecht, M. (May 2008). "No-fault-found and Intermittent Failures in Electronic Products". Microelectronics Reliability. 48 (5): 663–674. doi:10.1016/j.microrel.2008.02.003. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>Example of an intermittent TV fault in a database "Highlandelectrix PANASONI.TV". Archived from the original on 2009-04-13. Retrieved 2010-07-19.: "Z3T CHASSIS - NO START UP - INTERMITTENT. D1124 (5.1V) ZENER LEAKY" <a href="https://web.archive.org/web/20090413111211/http://www.highlandelectrix.fsnet.co.uk/tvs/PANASONI.TV.html" target="_blank">https://web.archive.org/web/20090413111211/http://www.highlandelectrix.fsnet.co.uk/tvs/PANASONI.TV.html</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>"Spread Spectrum Time Domain Reflectometry for Locating Intermittent Faults Archived 2010-05-01 at archive.today" Furse, Cynthia; Smith, Paul; IEEE SENSORS JOURNAL, VOL. 5, NO. 6, DECEMBER 2005" <a href="http://livewiretest.com/feasibility-of-spread-spectrum-sensors-for-location-of-arcs-on-live-wires/" target="_blank">http://livewiretest.com/feasibility-of-spread-spectrum-sensors-for-location-of-arcs-on-live-wires/</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>"No Fault Found, Retest OK, Cannot Duplicate or Fault Not Found? - Towards a standardised taxonomy [1]" Samir Khan, Paul Phillips, Chris Hockley, Ian Jennions" <a href="https://dspace.lib.cranfield.ac.uk/bitstream/1826/8091/1/tesconf2012_submission_2-1.pdf" target="_blank">https://dspace.lib.cranfield.ac.uk/bitstream/1826/8091/1/tesconf2012_submission_2-1.pdf</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
<li id="fn:6"><p>Bakhshi, Roozbeh; Kunche, Surya; Pecht, Michael (2014-02-18). "Intermittent Failures in Hardware and Software". Journal of Electronic Packaging. 136 (1): 011014. doi:10.1115/1.4026639. ISSN 1043-7398. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li>
</ol>

Intermittent fault open-in-new

Intermittent fault