Test Diagnosis Software Verifies SMPS Design

Referencing the March 2003 issue of Power Electronics Technology, “Ultra-Fast Simulation Expedites Accurate SMPS Design,” we follow with a topic of widespread importance — fault and test diagnosis. Historically in the design phase, there hasn't been a practical way to perform fault and test analysis on analog and mixed-signal designs. Analog test is a difficult procedure, which has discouraged its availability in computer-aided engineering (CAE) tools. The process requires sophisticated test algorithms to detect a myriad of faults injected across a design. Examples include open, short, and stuck-at value. Injecting fault conditions and simulating their effect using a CAE approach is lengthy and produces a battery of simulation runs. Add to this a labor-intensive prioritization of tests to efficiently hunt down design failures — if a corresponding fault is even detectable. Then, test code must be generated for the programming of automated test equipment.

Using fault diagnosis and test sequencing in digital design, faults are readily specified and detected using test vectors within a binary design environment. However, with analog, test signal complexity and fault injection reaches beyond digital's analysis of highs and lows — a challenge that contributes to today's void in analog CAE test tools.

Getting Started with Test Designer

Fortunately, there's now automated test synthesis software for analog and mixed-signal design that circumvents the previous hardship in analog CAE test. Such an application injects faults across the design's components, implements tests based on prescribed signal limits at design nodes, and optimizes test pattern sequencing to detect faults (i.e., failed component in production or field unit). Test Designer, part of Intusoft's ICAP/4 analog and mixed-mode simulation tool suite, enables engineers to enter schematic designs, simulate and debug their operation, verify performance against variations in component tolerance and design temperature, flag component power violations, and fully test the design for potential part failures.

The schematic in Fig. 1 employs ON Semiconductor's 34063A IC in a buck configuration using one of ICAP/4's configurable power supply design templates. It has been simulated and verified using a number of advanced analyses to meet production compliance. The design has been optimized for performance required by today's SMPS, and is ready for full fault injection and test generation to examine acceptable fault coverage.

In setting up a fault injection and testing paradigm, it's reasonable to conclude that boards containing catastrophic component failures should be rejected, but boards containing parametric (i.e., resistor tolerance) failures that don't adversely affect functional performance should be accepted. For example, a 2k pull-up resistor may work as well as a specified 1k resistor. We want to use the out-of-tolerance part because production engineers will desire standard parts based on lowest permissible cost.

Post-design simulation and debug verification analyses are performed to ensure correct operation of a design in the presence of variations found in component tolerance, input voltage, and load resistance. Monte Carlo statistical analysis is a popular way to achieve this goal. It monitors variance at key design nodes for acceptable performance after statistically varying circuit parameters through their tolerance range. Upper and lower test limits at design nodes are then prescribed from the statistical run results, which establishes a “parametric compliant” approach in creating a signal passband. Manually specifying the signal envelope is another method, subject to the designer's discretion, or taking measurements in the lab or field.

The Next Step

We're now ready to continue the testing process. The first step in establishing a protocol is to determine acceptable electrical limits at design nodes. Without fault synthesis, this is a difficult process because the designer is left to guess any circuit node's pass/fail range consequent to a fault, or manually attempt fault injection in a prototype board and see what effect that bears. The latter choice could take days to months for an entire design. However, with Test Designer, an automated fault synthesis program is performed across the design. A test program then automatically flags failed electrical levels at design nodes (outside the signal passband) and associates which faults caused them. The quality of fault coverage is also specified. If the quality is inadequate, then tests at additional design nodes may be required or a tighter pass/fail signal envelope would be ascribed on existing test nodes. Once satisfactory, Test Designer automatically generates pseudo code for production test equipment.

Another test flags component stress (alarm condition) from a safe operating range. When a part fails, it's possible to overstress other parts or cause undesirable — even hazardous — circuit operation. In our SMPS design example, components' stress limits were set to the manufacturer's specification prior to simulation.

Fig. 2 illustrates the measurements established for Fig.1's buck regulator. Key nodes in the design, such as nodes 14 and 12, were prescribed a tight signal passband to monitor faults. For these, a Monte Carlo statistical analysis was run, which prescribed a 3-sigma variation to design tolerances and a corresponding signal envelope at the nodes. Measurement limits can be easily changed if a different level of test stringency is deemed necessary — for instance, expanding a nodal passband arms against variations such as environment or uncalibrated test equipment — all of which can migrate signal levels across test limits. A wider passband produces higher production yield, good when reduced product reliability is acceptable. Conversely, narrower test limits manifest higher product quality as often required by military/aerospace, medical and consumer safety products.

Next, all fault conditions are run across every component in the design, then corresponding pass or fail measurements are monitored at circuit nodes. Fault synthesis is performed automatically. When the fault detection process finds circuit nodes out of signal compliance, corresponding fault condition(s) are recorded. Faults are displayed in numerical and graphical (histogram) format. For example, Fig. 3 shows that node 6 failed out of range in its voltage level, a condition caused by C1 shorted. Any signal failure caused by a fault condition could have been consequent to another fault (failure) in the design. This is typically caused by a component power violation that invokes harm to another circuit portion. However, stress alarms for component power can be easily set up and detected prior to running fault and test sequencing.

Understanding How It Works

Detecting faults is normally an extensive and costly process when using actual test equipment. Test Designer answers this by first automatically building a fault universe, which is a collection of all possible faults in a design. This, in turn, is used to construct a fault tree, a process that prioritizes the outcome of a test as a no-fault condition or a detected fault. When a test passes, successive tests are performed, each possessing a unique set of faults that could cause their test to fail. This subset of faults produced from test to test is called an ambiguity group. Fig. 4 illustrates a test flow example for the design in Fig. 1. The Input Group illustrated shows a list of nine possible faults affecting components X1, C1, D1, L1, and R5. As read, if within 300 µs of simulation the mean value of node V(6) drops to less than 10V, the test fails and one of these faults is a culprit problem. Other tests sequentially isolate an actual fault.

Following each test, the remaining subset of faults for further testing is also called an ambiguity group. For instance, if Tests 1 and 2 fail, the ambiguity group for follow-on tests would be the faults in common within Tests 1 and 2 ( i.e., X1 short between pins 1 and 2, plus pins 3 and 4, and C1 short). The tests' other faults would be irrelevant because they didn't cause both tests to fail. That is, C2 open, for example, could have caused Test 2 to fail, but the fact that it wasn't part of Test 1's fault dictionary, and Test 1 failed, C2 is marked as irrelevant. The ambiguity group out of Test 2 now becomes three faults, down from nine in Test 1.

Since streamlining the fault detection process is an immense task, Test Designer automates this by accounting for the “weight” or effectiveness of each test. This serves to determine which testing order will manifest the fastest fault detection. To better understand this, imagine yourself in a crowded auditorium and you must find a man named Nick, who has blond hair, a red shirt, and who is 5 ft. 10 in. tall. Assume only five people in the crowd are wearing red shirts. You would first quickly scan the right half of the auditorium to search for any man wearing a red shirt. That's your first test, which bears a high weight because it might reduce your search to one half of the auditorium if no red shirts are seen. That test fails, so you jump to the other half of the crowd. There, you spot the five men wearing red shirts. Next, scan half of that section for anyone standing about 5 ft. 10 in. or with blond hair. You find three such persons. That's also a highly weighted fault detection test because you've significantly narrowed the search. Eventually you'll isolate your candidates down to a smaller area based strictly on the name Nick. This final test carries a low weight because of its high degree of specificity.

Test Designer ascribes its search algorithm and optimizes the test order for detecting fault conditions. Here, the goal is to reach a “terminal pass or fail conclusion,” whereby no more tests are available to detect faults. The goal is to perform the fewest number of tests to reach this conclusion. Tests most successful in identifying a fault are ones that possess a high weight. Testing prioritization is based on a process called entropy, which uses a complex algorithm that determines the probability of a test passing or failing. This procedure unfolds throughout the fault tree assembled by Test Designer. The designer can also ascribe changes in the prescribed testing order. Then, a terminal conclusion is reached as a “no fault” condition. If remaining faults exist, they're deemed as undetectable. A more comprehensive set of tests would then be developed, if undetected faults could adversely affect design performance — which means setting up more test points for monitoring signal variance flagged by the faults, and/or tightening existing passband limits. See Fig. 5 for a fault tree infrastructure with corresponding test results. Test Designer can now generate pseudo code as input for automated test equipment.

What has traditionally required an outlay in expertise and expense for testing of analog designs has been circumvented through the use of CAE tools. The result enables increased product reliability and production yield, with less risk incurred from faulty operation.

For more information on this article, CIRCLE 335 on Reader Service Card