HALT (highly accelerated life testing) is a method to reveal product weaknesses. Design prototypes experience the step-stress application of relevant stresses until failures appear.
The intent is to find design or process related weaknesses early in the design process thus providing time to economically address the issue. Using a build-test-fix approach does improve a product’s robustness and reliability.
Being a useful tool, should you conduct HALT on every project? It seems that revealing weaknesses is certainly useful.
HALT requires the use of prototype units which are expensive, in general. It also takes time and in some circumstances expensive testing equipment to apply the stresses. There also is no guarantee that the exercise will find previously unknown faults.
There is no hard and fast rule to decision point to determine if HALT is worth the effort. The return (discovered weaknesses) has to be worth the effort.
Estimating the value of a specific HALT helps you determine if HALT is the right tool for your specific situation.
When HALT makes sense
The easy answer is when it’s free and the risk of unknown faults is high.
Free? HALT is not a specific or set test using specialized chambers. It is an approach using step-stress with one or more stresses to excite faults for detection. A HALT could occur on the design engineers lab bench using simple tools.
While not totally free as you still require a prototype. If the device is either inexpensive to build or easily repaired, then the overall cost is minimized. Most engineers tend to conduct some form of HALT (they most likely do not call it such) when they first receive a prototype of their design. They apply various stimuli to determine the response and look for anomalous behavior (faults).
Unknown faults imply there is uncertainty about how the device will respond to the stress of use. Another unknown concerns how well the device has been assembled, including the assembly process of supplied parts.
When using new materials, novel solutions, or new assembly methods we have some uncertainty concerning what will fail and how will it fail. Keep in mind that everything will fail, and proving the hypothesis about what will fail first is often left to experimentation or to the customer.
HALT provides a way to avoid the customers from finding the faults first.
Changes in use and environment
Another situation when HALT makes sense is when the customer use and environment changes. For example, if an existing product is to begin sales in a new part of the world or for a new market. In general, we may assume the previous product design focused on the intended geography and expected use stresses.
When the expectations and environment around a product change, the failures that appear also change. HALT provides a way to explore the impact of these new stresses and possibly reveal new product weaknesses.
Low risk of field failure
The fourth situation when HALT makes sense is when the risk of field failure has to be very low. This could be with a new or mature product line, it could be a new invention. It really is a business decision concerning the market acceptance of a product with faults. In some situations, the customers will not tolerate nor expect unexpected failures.
One way to think about product design and failures is the notion of each design and each product has a finite number of faults that will lead to premature failure. The product development process, prototype testing, validation & verification, and similar processes work to identify and resolve as many of the existing and unknown faults as possible.
Benefits of HALT
HALT provides a way to quickly find faults. With enough time, development methods without using the HALT approach will certainly find the faults, it’s just it takes time. HALT finds faults faster, in general, allowing the design team more time to resolve the list of issues. Using multiple stresses with HALT also reveals faults excited by the interaction of stresses which testing with one stress at a time will not reveal. HALT provides a way to reveal difficult to find weaknesses.
With enough time, development methods without using the HALT approach will certainly find the faults, it’s just it takes time. HALT finds faults faster, in general, allowing the design team more time to resolve the list of issues. Using multiple stresses with HALT also reveals faults excited by the interaction of stresses which testing with one stress at a time will not reveal. HALT provides a way to reveal difficult to find weaknesses.
HALT provides a way to reveal difficult to find weaknesses.
When HALT does not make sense
The simple answer is when failures do not matter and the cost of testing is very high.
The best time to determine if HALT is worth doing is after you have completed the process. If you have discovered previously unknown weaknesses and are able to do something about it, then you have learned something useful. The problem with this approach is you have already made the investment in HALT before determining if it is useful.
Does the organization have experience?
If the organization has no experience with HALT, learning about the tool and its potential value is a good enough reason to conduct HALT, whether or not you find something useful. If the team already has experience with HALT, then you should conduct HALT when there is a reasonable chance of finding previously unknown faults.
If the team already has experience with HALT, then you should conduct HALT when there is a reasonable chance of finding previously unknown faults.
Product is similar to previous products
Therefore, if the new product is very similar (‘similar’ is very subjective and based on engineering judgment) to previous products and the team already has a long list of defects that have to be addressed, then conducting HALT may add little value. An extensive Pareto of issues built from field returns, customer complaints, internal testing, and FMEA, leaves little chance of new issues appearing.
Consequence of failures is inconsequential
When the consequence of failures is inconsequential, meaning the customer does not mind if a failure occurs, then finding and fixing issues is of little value.
While this is rare, in my experience, it is possible.
Development process permits no changes
Another situation to avoid conducting HALT is when the development process will not permit any changes. If a fault is found and the team is unable or unwilling to make changes to address the fault, then there is little value in finding additional faults.
Part of the HALT process is fixing issues found.
No information on faults
Also, consider if the HALT process has the ability to yield information on faults. If the testing is set to a fixed routine or a very limited profile or duration, the chances of finding previously unknown weaknesses are diminished.
This may occur when there is a mandate or requirement to HALT every prototype on every project. The constraint on testing resources may preclude sufficient time or test design to excite and discover failure mechanisms.
How to decide when to conduct HALT
There isn’t a formula for this decision. It is a balance between the investment and the potential value.
In general, you should conduct HALT when:
- The design, supply chain or technology are new
- The uncertainty about what will fail is high
- The cost of conducting HALT is low
- The ability to address weaknesses is high
And, in general, you should not conduct HALT when:
- The design, supply chain, and technology are stable
- The existing list of weaknesses is extensive
- The cost of conducting HALT is high
- The ability to address weaknesses is low
When first learning about HALT, just do it. Learn and gain experience with the approach and how the discovery process works. As you and your team gain experience you will be able to judge the potential value from conducting HALT.
As you and your team gain experience you will be able to judge the potential value from conducting HALT.
When the potential value significantly outweighs the cost, do HALT.
4 Steps to Accomplish HALT (article)