Environmental Stress Testing (EST)

[Ian McIntosh]

Meeting Minutes reference:
http://www.sjtag.org/minutes/minutes080319.html
http://www.sjtag.org/minutes/minutes080407.html

This topic is the startup page for the Environmental Stress Testing discussion forum. It is being set up to be a place holder for further discussions on the subject following the 3/19/2008 meeting where this use case was introduced. EST is sometimes also includes the following subjects:

• Design Verification Testing (Typically done before a product release)
• Hightly Accelerated Lite Test (HALT) (used in design for product ruggedization)
• Highly Accelerated Stress Screening (HASS) (used in production for process monitoring)

What is HALT?:

• HALT is used to find the weak links in the design and fabrication processes of a product during the design phase.
• The stresses are not meant to simulate the field environments at all, but to find the weak links in the design and processes using only a few units. The stresses are stepped up to well beyond the expected field environment until the “fundamental limit of the technology” is reached.

What is HASS?:

• HASS is a screening process that uses accelerated techniques to uncover manufactured product weakness and flaws. The process requires the use of HALT results, and other product specific information to design the initial profile, and then tune it for optimal effectiveness.

A good overview for the reason for performing stress testing may be found at:
http://www.chartchambers.com/pdf/what_is_halt.pdf

What the SJTAG team is to be focusing on is how JTAG is used to perform these types of testing within a system - specifically, how boundary-scan tests are used during the stress process. This includes the use of boundary-scan from remote test systems to the incorporation of integrated test systems within the system under test. Other aspects of JTAG in EST is the testing of board lots and not specifically testing a system as a whole. Thus, a set of boundary-scan tests on a collection of the same type boards udergoing stress might need to be controlled from a single test source concurrently.

[Ian McIntosh]

I would perhaps expand on Brad's heading of "Design Verification": Within the scope of Design Verification (which in my terms is generally focussed on the functional compliance with the Design Requirement) there is also the concept of "Qualification Testing". This covers establishing that the product continues to function over the range of temperature, vibration, shock, humidity, etc., stated in the requirement. Qualification Testing is usually mandated for products supplied for automotive, railway, marine, airborne or military use.

Qualification Testing can be quite a lengthy process, so a typical scenario is that several facilities (and UUTs) may be used in parallel to expedite the testing (e.g. one rig for Vibration Qual., one for Thermal Qual., another for Salt Spray, etc.) . Equipping each facility with a set of functional test equipment is costly and the kit becomes largely redundant on completion of the Qualification activity. While some of the testing is necessarily functional, the ability to conduct the majority at a structural level allows the more expensive functional test assets to be shared amongst the various facilities.

[Ian McIntosh]

Within the scope of EST, I'm also considering scenarii such as Environmental Qualification (design proving), TAF (Test/Analyses/Fix), Reliability Growth, etc., i.e. long-term tests as well as (relatively) short-term thermal and vibration stress screening.

An obvious factor here is that faults have to be reported to the test operator: Where tests are being directed from an external Test Manager, then this is inherent, otherwise there must some form of communication, either via a test bus or a mission interface. It also needs to be noted that these tests are typically supervised by a "watchman" with a remit to monitor several test sites over a shift.

The actual data presented and the timeliness with which it is presented is not necessarily a clear cut matter, and depends on how the tests are managed.

In most cases, it is essential to be able to correlate any failures with the conditions prevailing at the time of failure. Generally, "time tagging" of fail messages will suffice as the environmental stimlus is frequently controlled by a discrete autonomous process, so more sophisticated methods of correlating UUT behaviour with stimulus are rarely viable. This time-tagging may be performed externally (i.e. external to the JTAG Test Manager) if test results are being reported to the monitoring system in "real-time"; otherwise, if the relaying of results is deferred, then the JTAG Test Manager must add the time-tags.

In determining what data is needed timeously by the operator and what can be deferred, it probably best to consider "critical" and "non-critical" failures, the terms being used here in the context of "test impact" rather than "mission impact".

Critical failures are those where continued operation beyond the point of failure may endager the UUT, the test facility or personnel: Such things as overtemperature, gross over-current, etc., where fire or explosion may occur. In such cases it is essential to shut down power to the UUT and stop any stimulus as quickly as pssible. This can be expected to be an automated process so the relayed fault information must contain sufficient information to indicate criticality and trip the "alarm" system of the test facility.
At this point, a diagnostic would be helpful in deciding on the next actions. It would generally be considered inadvisable to switch the UUT on again, so the diagnostic must be derivable from either data on failing vectors/failing nets output at the point of failure or test data held in non-volatile storage that is accessible with UUT power off.

For non-critical failures, such as indication of an open circuit between two devices, then it may be sufficient to indicate to the operator simply the number of failures that have occured during each test cycle (in EST it may be expected that a pre-determind test cycle will be executed repeatedly during stimulation).
Where tests are being run concurrently on several boards within a UUT, this very basic level of reporting may be all that is viable, in terms of utilisation of the reporting bus. For externally managed JTAG tests, a greater level of detail on the failures may be available, but in either case, it will usually be left to the operator (or some overall supervisory process) to determine when or if the test run should be terminated.

For EST, there is probably no great penalty in conducting off-line diagnostics. While real-time diagnostics may be helpful, it is important that these are not provided at the cost of significant extension of test execution time. One of the main benefits of using JTAG within EST is to increase the number of electrical test cycles which can be performed during each stimulus cycle, when compared to functional testing. Typical board level diagnostics techniques will analyse the syndromes from the failing vectors to determine the most probable causes to net or possibly pin level. For a few single faults on unrelated nets, this may not be very time consuming, but if multiple faults manifest then this kind of analysis on a large design may run into minutes.

In the case where embedded JTAG testing is employed during EST and the delivery of detailed test data is deferred, then we can consider that there will likely be periodic opportunities to transfer the test data to the supervisory system or monitoring console. The embedded solution therefore needs to have sufficient results storage to be able to accumulate the essential test data (possibly self-diagnosis results or failing vector/net data in some compressed form, rather than full test result vectors). The storage requirements may not be easy to determine at design time however.