We are often not aware, how to reduce the PCB bone pile. The answer is : optimizing the test strategy. Having worked within an established company in the world of PCB assembly testing for many years we still come across companies (OEMs) who will tell us, “We don’t need to test, because we demand that the contract manufacturer (CM) only send us 100 percent working boards.” But, demanding and receiving are two different matters. No one can totally accomplish this, and even if they could, what does it actually cost? There’s an old saying in the engineering industry: “If it hasn’t been tested, then it doesn’t work” — rather, you should assume it doesn’t work. Most people however assume the opposite, and that is where the problems start. So the question remains how to optimze your test strategy.
But Testing’s Not My Problem
An OEM might not know or care if its boards are being tested or not, but it should. For example, the CM might only perform a cursory functional test using some type of hot mock-up, which may only power up the board and see if it appears to be working correctly. If the board fails this test, it is cast aside and another is built to replace it until the order is complete. Depending on the CM’s process quality and yield, any number of boards could be hitting the “bone pile,” leaving the OEM with significant extra expense. However, if it costs less to diagnose and fix a board rather than to create an entirely new one, then of course it makes sense to test more vigorously.
The degree and type of testing is important to consider. A simple design like a flashlight can be tested by turning it on and off. To extend this test it could be turned on and off many times to check the integrity of the principal moving component — the switch. This is known as a functional test. Other types of testing include structural testing, which breaks down the test process to check the smallest elements of the design. In a flashlight, this could be the continuity of the conductors to the switch, the switch isolation and closed resistance, the voltage of the batteries, and bulb impedance. This approach to testing gives a much more precise reason for device failure.
The decision to test must be based on hard facts and knowledge of the manufacturing process. Both the OEM and CM must discuss design for test (DFT), fault coverage, diagnostics resolution (test system performance), and other factors before determining the most effective test method. Most good test systems will now provide a fault coverage assessment figure, but how that information is derived should be considered. Independent fault coverage assessment systems are also available that can take inputs from a variety of test systems and aggregate the results. These require a great deal of understanding and maintenance and are generally suited to large organizations with a dedicated DFT staff.
Determining and optimizing the Test Strategy
When defining the optimal test system, be sure to ask the following questions:
Very large boards can eliminate certain types of test options, such as the use of flying probers. Similarly, boards with a large number of test points may require a vacuum or compressed air system to engage the UUT with the test pins. RF boards may require testing within a shielded (Faraday cage) enclosure to protect against electromagnetic influences. High-voltage boards require additional fail-safes and trip switches to guard the user from dangerous power supplies or from the UUT itself. In each of these cases, the fixture supplier is a valuable friend and can offer advice on many aspects of fixture design, or on whether or not it is possible to use a generic, reconfigurable system.
Choosing Test Equipment
The test fixture itself is simply the access mechanism that allows the user to probe specific test points on the UUT with the required fidelity. On its own it is mostly useless so it should be combined with an optimized set of test equipment. Some smaller businesses will try to use the same test equipment that the developer used to debug during design. However, most design tools are not made to withstand the rigors of production testing and do not always support production test software that allows them to be integrated into broader test strategies. Pushing forward with a mismatched test strategy can lead to a confusing and compromising system that may include multiple user interfaces and create a complicated, possibly illogical, test procedure. It might be preferable to decide first on the test executive and then select instruments that can be controlled by it.
The next decision is to determine the diagnostics resolution that the process requires, which affects the types of instruments needed. In the earlier flashlight example, the simple functional test of turning it on and off gives a diagnostics resolution of the entire device. But, by using a digital multimeter (DMM), for instance, the battery voltage, the switch open and close resistance, the bulb’s impedance, and the continuity of the interconnections could all be measured. The diagnostic resolution is then much higher, allowing for repair and rework rather than scrapping the entire product.
For a basic (structural) automated test equipment (ATE) system, such as a manufacturing defects analyzer (MDA), only a few simple measurements are necessary — voltage, frequency, timer, and continuity across a few hundred channels. Adding pattern generation and detection, i.e. digital I/O channels then allows testing to be extended into the functional domain. The further addition of JTAG/boundary scan (IEEE Std. 1149.1) interfaces introduces possibilities for full device-to-device interconnection testing, memory cluster connection tests, logic tests, device programming (flash memory, CPLDs), and more. All of these features can be found in JTAG Technologies’ JT 5705/FXT module, an ultra-compact tester. The JT 5705 can provide almost everything necessary for the required diagnostic resolution. If the application has other requirements, it is easy to select specialized instruments to augment the tester’s capabilities, including oscilloscopes, RF generators, power meters, timer counters, and matrix switchers. Testers that combine functional and structural test aspects are commonly known as “combinational testers.”
FPGA technology also allows flexibility in test systems by allowing reconfigurable instruments to be embedded within the fabric of a device and are typically controlled by PXI or JTAG interfaces. JTAG Technologies’ JT 5705 and JT 5112 MIOS units are reconfigurable tester modules that may be controlled and reprogrammed by JTAG. Test instruments that can be built include serial bus interfaces (SPI, CAN, I2C, Ethernet), DDRx memory interfaces, and others.
Software for Combinational Testers
After selecting the fixture, instruments and power supplies, the next step is to choose a test executive software solution. Some of the more popular software options include National Instruments, Python, Microsoft .NET framework, Marvin’s ATEasy, Keysight VEE, and JTAG Technologies AEX manager.
National Instruments offers a range of options from the ubiquitous LabVIEW to LabWindows/Cvi and TestStand. The LabVIEW graphical programming system was originally designed as a tool for research scientists but now appeals to many non-programmers in the ATE world. LabVIEW/CVi offers a more conventional programmers interface (API) but is not a full implementation of ANSI C. National Instruments software is well-supported by a host of instrument drivers often written by the instrument vendor.
Often known as the engineer’s programming tool, Python is praised for having the simplicity of BASIC with many of the advanced features and flexibilities of C. Another major attraction is that it is open-source and thus essentially free. PyVISA is a Python “wrapper” that offers easy access to shared DLLs built into the Virtual Instrument Software Architecture specification laid down in the 1990s. This allows a high-level control of conventional instruments while JTAG Technologies also provides its own library for boundary-scan activities.
Microsoft’s .NET framework is the company’s latest coding environment and provides language interoperability across several programming languages. Programs written for .NET execute in a software environment known as Common Language Runtime (CLR), a virtual machine that provides security, memory management and exception handling. Languages supported range from C# to VisualBasic.
Specifications and Documentation
Having previously defined a broad test strategy it will be necessary to provide a detailed test specification per UUT. This is especially important in cases where a third party or systems integrator is involved. Glib requests such as “Test as much as you can!” are pretty much meaningless and can provoke much future argument and contractual wrangling. The test specification will also figure in the acceptance specification of the tester along with checks for compliance with electrical safety and EMC measures.
Documentation of the finished system is another important aspect that can extend the useful life of a tester. A great many carefully engineered systems have been abandoned when a lead engineer moves on from an organization without leaving adequate documentation.
Commissioning and Maintenance
The commissioning process for a new test system should be the same whether the equipment was developed in-house or supplied by a third party. In each case, the system must be inspected for compliance to safety specifications before it is even powered up. The UUT program can be subsequently executed with a known good (golden) board to check for false failures. If possible, a board with known failures that are covered by the tester should be run through. Limits checking should be fine-tuned to cover the spread of acceptable results.
Maintenance is perhaps the most neglected part of a test system. In any tester there will be consumable items that will eventually need to be replaced. Test probes, connectors and cables all have a finite lifespan and should be replaced on a schedule rather than later on when an issue arises, which leads to extra time spent tracking down the problem. Similarly, most analog measuring equipment requires periodic calibration or at the very least should be checked against a good traceable instrument. Also, easy access to tester components for replacement and service must be considered at the design stage.
Clearly there is a great deal to consider before embarking on a test system build. Consider what is more important for an application, the required diagnostics resolution or how accurately a given fault can be pinpointed. This determines the types of hardware needed and the software programs to support it. Better resolution requires more instrumentation and also (usually) more test points. However, the latter can be mitigated by the use of JTAG/boundary scan techniques on designs that support this technology.
Since JTAG/boundary scan uses built-in pin access provided by the ICs themselves, hardware overhead can be reduced by removing test points while increasing test coverage and adding useful resources such as in-system programming of CPLDs, flash devices and the embedded memories in microprocessors.
