Playing The Percentages: Reusing Test Station Frameworks

We don’t have to reinvent the wheel every time

When it comes to effective test and measurement, then an agile approach is key. It boils down to the numbers. Let’s say you have a planned throughput of a thousand circuit boards, some may have different processes. The choice is to create a new test station for each PCB product or to build a comprehensive all functions test rig. In this way the test systems can be modified to cater for the specific requirements of each product, yet retain the key functionality that is common.

That means we don’t have to re-invent the wheel every time. This concept of reusability is a key to efficiency, cost reduction, and speed of tests. Ultimately this leads to a positive impact on the bottom line, saving money for the manufacturer during the all important test phase.

The cumulative cost improvements are based on an upfront investment, with diminishing costs as the process handles different products with some specific requirements. This is best visualised through the difference between a car, bus, and tank. Each will have common transport modes, but then different equipment, navigator, and other functionality built in.

Reusability of software and frameworks allows replication

The first station costs more, then iterative repeats of subsequent test stations become less expensive and produce savings. This notion of reusability of software and frameworks (code and hardware) allows replication, albeit with tweaks, with very low costs.

This approach covers a spectrum of test functionality: test platform error handling, logging activities, and report generation through WATS. There is also the hardware abstraction layer to consider, sets of routines in software that provide programs with access to hardware resources through programming interfaces. This allows a programmer to use OS-level operations (e.g. task creation/deletion) in their programs while retaining portability over a variety of different platforms.

Development costs are significantly lower

Reduced down, most components can be re-used with same code and hardware, but with a new product, this approach just needs a tweak, to accommodate for example, other tests steps or functionality.

So, what’s the benefit of doing this?

• Development costs: significantly lower costs for the next test systems
• Quality improved because the code and the hardware were already tested (well documented and tested through WATS)
• You can use the same personnel to maintain all the systems you have (they know the code, it is almost the same code on every system)

The answer is in the numbers, as with many things, if you develop a test system from scratch every time, there’s a hundred percent custom work for each system. Now, since you have this framework, it’s between 5% and about 50% you have to do for each project.

There is always a certain percentage custom but it’s less, and that’s where smart testing makes a big difference.

As a major test house, we just wouldn’t contemplate another way of working!