Viewpoint News, December 2009

Test Engineering Proficiency

by James Campbell - jac@viewpointusa.com

Last month’s Challenge of Development Tools dovetails nicely into this month’s Challenge. Test engineers have an ever-growing toolbox to apply to test system development. Half of this month’s theme is becoming and staying proficient with these tools. The other half is the skills to know when to use these tools. Available hardware and software choices play a critical role, and define your toolset, but which one dominates your toolset selection? I have some strong recommendations, read on to see if you agree.<

Are You Prepared?

In my previous articles I have talked at length about how the complexity of the newer products have increased drastically over the past few years. I have also gone on the record with the recommendation that an advanced degree in some form of software/hardware design would serve test engineers well these days. Test engineers arrive in the field from many backgrounds, the successful ones have been taught or have self-developed skills in both software development and hardware integration. The future requires continuous improvement in team skills as well as technical know-how.

I think there are two key areas that are absolutely critical for test engineering. I have thrown in two “bonus” areas, or future looking areas, that we will all have to be up to speed on in the very near future. Additionally, on top of these areas, test engineers need a good understanding of system development life cycle management.

Programming

Learn good programming techniques. There are many software design and algorithm books. For example, search for “data structures and algorithms” at Amazon. A fairly classic book data on the subject is “Data Structures and Algorithms” by Alfred V. Aho, Jeffrey D. Ullman, and John E. Hopcroft. A real classic is Donald Knuth’s three volume series on “The Art of Computer Programming”. These books cover basic data manipulation algorithms and the newer ones discuss methods to manage parallel processing. LabVIEW hides many of these algorithms in high-level constructs and functions (i.e., VIs) but a solid understanding will enhance your programming skills.

Alternatively, take a course or two in basic computer science. The goal is to understand how, when, and why to use the tools, objects, and application frameworks (or patterns). For example, do you understand the benefits and drawbacks of queues and semaphores, parallel threads and events, consumer / producer loops, and so on. These capabilities all reside in LabVIEW, or C#, or VB (some implementations are more difficult than others), but overall application maintainability and robustness rests on good design and tool usage.

Measurement and Control Hardware

Remain contemporary with measurement hardware. Some of this need derives from new features in UUTs that require new measurement capabilities or accuracies. Another part stems from upgrades by the HW vendors.

Regarding new UUT features, for example, more products are introduced each year that communicate to the outside world via RF. I predict that someday you will need to know RF HW and the standard measurement types and communication protocols, or at least how to get such expertise. And, with the increasing need for HW simulators, you will likely become comfortable using cRIO, R-series, and other options as custom controllers.

Regarding HW vendor upgrades, besides the push for better accuracy and throughput, pay attention to the offerings in the newer bus standards, such as USB, PXIe, and Ethernet. Also, watch for new methods for synchronizing measurements, such as IEEE-1588 or PXI backplane trigger and clock-sharing. The latter are important for distributed test and control PCs.

Bonus - Distributing Tasks

Design for distributed tasks. Programming techniques become even more important when using distributed controllers and parallel-processing. Now you have to coordinate multiple processes or processors (or both) and decide how best to split up the tasks. In the test world, I think LabVIEW programmers are farther along this learning curve than those using text-based languages, since LV is a much more natural language for parallel programming.

Bonus - Real-time Operating Systems

Learn to program in real-time operating systems (RTOSs). Code function priorities and minimizing loop jitter may present challenges to those only familiar with Windows applications. Of course, LabVIEW RT offers a recognizable platform for programming in an RTOS. However, beware that LV RT does things a bit differently. For example, traditional IRQ methods don’t work (directly) in LabVIEW or don’t work the same way as traditional RTOS environments, so there are some different techniques that need to be learned by those familiar with QNX, VxWorks, and other historical RTOS environments.

Conclusion

Test engineering proficiency requires lifelong learning. I’ve listed two key areas and a couple of bonus areas in which I think successful test engineers need to be competent going forward.