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!
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.
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;
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: