Optimizing Test Engineering Practices for High-Mix Electronics Manufacturing
For PCB and assembly manufacturers, test engineering has become a critical factor in enhancing the profitability of new product introductions (NPIs). Given the trend toward high-mix, low-volume production, the journey from design data to an automated PCB testing program must be quicker and more efficient than ever before.
In this article, we will discuss how to optimize the efficiency of the test engineering process in accordance with these new market realities.
A Brief Introduction to PCB Test Engineering
Test engineering describes the methodology of using design data to define a test strategy that will ensure that a PCB assembly is fully tested and free of defects. The testing infrastructure has gradually expanded from the “bed-of-nails” in-circuit technology (ICT) approach used for PCBs, to flying probe machines, which are better suited for high-mix, low-volume production and prototype runs. While ICTs remain in use and are an efficient means of IC programming, in-line testing, and high-volume testing, the migration to flying probes continues to accelerate due to the cost of ICT fixtures and the reduction in production volumes.
The field of test engineering is further divided into two separate disciplines:
- Process verification: The product is tested to ensure that it was manufactured properly.
- Product verification: The product undergoes functional testing to ensure that it works according to its design specifications. Product verification differs widely from product to product and is heavily customized for each project.
This article focuses on process verification. During process verification, the PCB is tested to ensure that it was built correctly, that the right components were placed in the right places, and that they operate correctly, with no shorts or opens. If the board was designed correctly, and passes process verification, then in theory, it should function as specified.
The Need for Efficient Test Engineering
The electronics manufacturing sector has seen a fundamental shift to higher production mixes, as industries move toward individualization, as well as customization of designs for specific markets. The increase in the number of designs and design variations has pressured test engineering departments to produce reliable, debugged programs in ever-shorter periods of time.
Therefore, the goal for test engineering is to shorten and simplify the path from design data to debugged test programs.
To achieve this, I’ve selected and described in the sections below some key guidelines for economizing and optimizing the process engineering task.
Guideline #1: Maintain a Single Data Source
Commonly, manufacturers use multiple data preparation applications to create operational procedures for the entire line. The applications include SMT process software and testing software, but it is not unusual to see three or four different applications performing these tasks, often resulting in duplicated efforts and inaccuracies.
In addition, each application may rely on different source files, increasing the probability of inconsistent results.
Therefore, it is highly recommended to utilize a single application to create data for all the machines in the line—including testing—thereby creating a digital twin that serves as a “single point of truth” upon which all activities are based.
How to accomplish this?
One of the most crucial requirements in test engineering is the ability to obtain complete layout data which can then be imported into whichever application is being used. Intelligent CAD files, such as ODB++ Design, are highly accurate, and save significant amounts of time when compared to other formats, such as Gerber. If needed, CAM formats such as GenCAD are still preferred over Gerber, but a key objective is to use the same file set for all the machines in the line.
If only Gerber files are available, your test engineering solution must support the import and reverse engineering of Gerber files, including generation of the netlist, which is critical to test engineering analysis.
Gerber import can also be used when CAD files are missing accurate solder mask data. The ability to merge the top and bottom mask Gerber files with CAD-based intelligence yields excellent results, and without the need for reverse engineering.
The physical layout data does not always contain the electrical information needed for test program development, test debug, and repair activities. In this case, it becomes necessary to import the bill of materials (BOM) or import data from a parts library to obtain this information.
While standard machine output files can be created directly from CAD data, it is preferable to work with complete output files that identify all the characteristics of each part on the board, including component types, model names, electrical values, tolerances, and pin mappings.
Accurate package outlines are important for ICT and flying probe analysis. CAD outlines can be used, but they may not be sufficiently accurate. Algorithm-based outlines, together with component dimensions, can be used to create a single closed shape. A comprehensive package library database, such as the Valor Parts Library, can be an excellent source of package outlines for DFT activities.
Guideline #2: Ensure Test Probe Placement Efficiency
When through-hole PCBs were prevalent, bottom-side ICT analysis was automatic, since any pin could be probed, yielding multiple points on a net that could be used. The introduction of surface mount components changed the testing paradigm. Now, test engineers are required to analyze the design, determine how to probe the board, and write scripts to implement the solution. Therefore, the applications simply apply what the test engineer has painstakingly created. As the number of assembly projects grows, this time-consuming approach becomes increasingly unscalable.
Advanced software solutions, such as Valor Process Preparation, can automatically determine probe targets, based on general guidance and constraints from the test engineer. The example below shows blue copper pads with a beige mask pad over them, and a purple drill in the center. If the mask pad is the size of the copper pad or larger, then the exposed area is equal to the size of the copper pad. If the mask pad is smaller than the copper pad, then the exposed area is based on the mask size. Drills may affect the results. While a small drill in via can be ignored, a larger drill should be avoided; therefore, the software needs to consider the annular ring around the drill for probing.
Another issue involves determining how close test probes can be to the board edge. Vacuum fixtures have a gasket around them that must be free of test probes.
ICT fixtures can be expensive, so it is preferred to use one fixture for multiple board variants. Therefore, components should always be considered as being placed, even if they are not.
Different targets can be ignored during analysis, and some types of targets can be prioritized over others. For example, test points are typically preferred over vias.
Package outlines can also be expanded by a specific amount to provide a little more margin around each one if needed.
When preparing for panel testing, it is highly desired to not flatten the board, as debug times will be much longer as a result. The preferred approach is to create a debugged test program first and then panelize the result.
Sometimes, it is necessary to place two probes on a net, for example, for 4-wire measurement. If there is only one accessible point, ICT fixtures can support two channels double wired to the same single test probe.
Finally, probe locking can be useful when planning tests that require special probes that are specified in the CAD system or in a separate file.
Figure 2.2: Precision robotic probes testing a printed circuit board.
Guideline #3: Automate Test Plan Generation
A test plan contains a set of rules that are used to determine the accessibility of locations on the board. It defines the settings or constraints used by the analysis engine to determine which features on each net are accessible to be probed, and which are not. Once these individual features are reviewed across each net, the results can be used to determine if that net can be probed or not.
The results of probe analysis usually indicate that each individual feature is: not accessible, accessible without a test probe, or accessible with a test probe. The constraints of a test plan allow the software to determine which of these three categories each feature falls into.
Figure 3.1: Probe analysis results.
Although a number of these constraints are used by both ICT and flying probe, some are specific to each technology. Probe sizes are specific to ICT and it is important that the different probe sizes of 100 mil, 75 mil and 50 mil are sized correctly and don’t conflict with each other. ICT probes almost always hit the center of the feature, but for flying probe machines, probes can be offset from that location. This is usually what happens when surface mount component pins are probed. The touch point of the flying probe will be offset away from the body of the component and will hit the end of the pad so it will not be deflected by the pin or solder fillet and will not create a false connection through the joint due to probe pressure.
Each unique group of analysis settings can be considered a complete test plan. Many test plans have a group of core routines, such as ICT bottom, ICT both, flying probe top, flying probe both. There may be conservative and aggressive versions of each plan as well. For example, a conservative plan would use 25 mil as a minimum target diameter for ICT and 100-mil and 75-mil probes. An aggressive test plan may use 20-mil targets on the bottom side and introduce a 50-mil probe size.
Pre-conditions can be used to further control how automated algorithms prioritize and then place probes during the test plan stage. There may be cases in which specific components need to be avoided even if they are accessible, or where probes should be placed, even if alternatives exist.
It may also be necessary to power up a board for certain types of testing, therefore, power injection probes need to be assigned to specific nets to achieve this.
There may be more complex scenarios requiring multiple probes, in which some are placed and some are not. Being able to review each point on a net and understand why it was not possible to place a probe on that feature can save a lot of time. Valor Process Preparation, for example, provides a graphical view of the board, highlighting the net. Below the graphical view, accessibility results are presented dynamically, enabling the list to be filtered further down to a single feature if needed.
Figure 3.2: Dynamically reviewing probe results with layout and schematic information.
The goal of any test engineering solution is to place all required probes automatically. However, there are cases following the probe review in which adjustments need to be made. A graphical drag-and-drop function can be used to move a probe from one position to another. The software should be able to constrain the probe to only that area or feature that is valid.
Probes are not the only adjustment that may be necessary. The probe labels may need to be moved away from other probe labels and graphics so that they are clearly readable. This capability can be particularly useful for ICT purposes when a clear probe label map is needed inside the fixture.
Guideline #4: Facilitate Reporting and Data Transfer Reporting
Reports are a crucial aspect of test engineering, in which usable results are delivered in a timely fashion to a variety of users. The output format should be flexible, supporting HTML for readability, CSV files for importation into Excel, as well as formats for data transfer to other systems.
Graphical representations should also be supported. For example, probe placement results should show nets with unplaced probes.
Figure 4.1: Example of an HTML testability report.
Data Export: Ultimately, the data produced by the test engineering solution needs to be passed to the machine software. The final test program will be created from this data. Each test machine has its own specification on how to convey layout, BOM, test attributes, test probes, accessibility, and panel information to the target machine. Some test systems use a single file, some use multiple files.
The more complete the test engineering data, the less work that needs to be done on the target machine. This is why it is important to use these test engineering applications to the fullest as they are the only ones that have the full data set available to them. Be aware that many legacy formats are still in use: Some of them predate surface mount technology and will filter the full data set provided by the test engineering application.
Probe Import: There are multiplexed and non-multiplexed test systems on the market. Multiplexed test systems switch their resources through relays, so it is not possible to switch every net to every resource and therefore, specific channels must be assigned to the board during program creation. Non-multiplexed test systems can switch all resources to any net and therefore can use the initial assignment of test channels as presented.
In the case of multiplexed systems, the programming software should support importation of the final probe channel map after the program has been created in order to ensure that the fixture and debug material align with the program. Files created by the test program generation software tell the test engineering software what the final channel names are, replacing the existing ones.
Learn more about Valor Process Preparation, or try Valor Process Preparation for free with our 30-day free trial.
Mark Laing is a business development manager for Siemens Digital Industries Software.
Additional content from Siemens Digital Industries Software:
