Guide for Automated Test Best Practices | Part 1 Test System Design

Part 1 | The Three Most Important Things in Test System Design: Communicate, Communicate, Communicate

Intro 

I don’t think anyone reading this blog will argue that Printed Circuit Boards (PCBs) are increasing in complexity at a rapid pace. Faster clock speeds, more functionality, and massive amounts of firmware are some of the top-line changes, but the list goes on. As test engineers, you know that your automated test systems will grow in complexity… or will they? Test System design is a balance of many parameters–including specifications that MUST be tested, PCB manufacturing throughput, allowed test time, number of testers needed, and the almighty budget that influences all the above. 

In this 3-part blog series, I want to map out some of the steps to achieve faster time to market and just enough test. Many of you may follow similar processes, however, I have found over my many years in this industry, not all these suggested processes are followed consistently. It could be an issue of your product being designed in Texas and manufactured in East Asia where communications channels may be hampered. It could also be just that your engineering departments are siloed. There will be many variations to this strategy. I encourage my readers to pose questions and comments. So, read on fellow Test Types! 

Designing the Perfect Test System 

Let’s say you are new to the Test Engineering team at XYZ Corporation. After several weeks of indoctrination, you are handed your first real assignment to design an automated test system for the corporation’s latest widget. “No problem,” you think. “I’ll get a bunch of instrumentation, design the cabling needed, put it all together, and write a bunch of code… Presto!”  If only it was that easy. 

First, if XYZ is a large company, you are part of a team, or rather, teams.  A test system is built on the inputs of your test engineering team, design engineering, and the manufacturing department. Everyone has a stake. Test engineering needs to know what is being tested and why, design engineering needs to make sure that the test systems look for performance specifications and, in many cases, look for fault conditions. Finally, manufacturing has a production plan for so many widgets per day, per month, and per year (this is known as throughput). Based on these numbers and the estimated test time, the first “balancing act” takes place.  

• How many testers are needed to handle the throughput? 
• Do we have the floor space and operators to thoroughly test all the widgets? 

If the answer is no to the second question, all three teams need to work together to balance the number of testers required versus the thoroughness of the test program and even decide how many widgets will be tested that may fail in the field as the test plan is compromised. 

Once a compromise is decided on, now comes the part you thought would be fun. Purchase the necessary instrumentation, design cabling, integrate and write code. As the test budget is the limiting factor, you have questions to ask; 

• How accurate does your instrumentation need to be? Remember, more accuracy usually implies higher costs. 
  • Form/factor – Are you planning a modular test system, using a form/factor like PXI, LXI Modular or perhaps hybrid PXIe? If so, look closely at all of the pros and cons of each platform to make sure it will your requirements. 
    • So which form/factor should I choose? The choice should be based on availability and the data rates needed for the test. In the case of signal switching, either form/factor is adequate as switching works in milliseconds and microseconds. In the case of complex signal acquisition–I am talking about gigs of data–PXIe is the hands-down winner. And remember, if you select a hybrid PXI chassis, all of the PXI and hybrid PXIe modules will play nicely.
      

Get the Infographic: Pros & Cons of Platform Types for Automated Testing

• Signal Switching – This portion of test system design is usually done at the last minute, but I ask you to think about it. Any measurement channel–that is the connection from the instrument to the Device Under Test (DUT)–is only as accurate as the weakest link.  So, if you buy the best instrument, but purchase inadequate lower-cost switching, you may not meet the measurement specifications required by product engineering. So, it is important to select a good switching vendor to help you select the right switch types for accuracy and repeatability.

Check out our video "How to Design an Automated Test System"

• Cabling – This may sound like the easiest portion of the test system design. After all, it’s just wires and connectors.  What could be so difficult? I won’t go into great detail here, but selecting the right connector based on the number of connect/disconnect cycles can save you maintenance problems in the future. Depending on the voltage, power, and frequency, wire types, insulation, and cable heating issues must be considered. So, unless it is an amazingly simple wiring harness, find a cabling vendor that has the tools and expertise to help you specify the right cable for the job.   

Check out our webinar "How to Design a Custom Cable in Minutes"

All the above tactics require a well-defined Communication Framework (The first “C” word in the title – We will visit other “C” words in later posts) so that issues are defined and resolved quickly. Questions include: 

• Who is the product “Champion”? This would be an employee from any of the teams we have mentioned.  The Product Champion’s role is to work with all of the various teams in order to understand their roles and their part in the manufacturing/test success. If a team is missing its milestones, the product champion works with the team to get them back on track.  
• Who will be the key point person in each group? Is there a plan for regular meetings in the initial stages? Keep in mind the bottom line in this endeavor - faster time to market, minimal faux pas in automated test system design and deployment, and maximum widget throughput. 

Check out Part 2 of this blog series.