Viewpoint News, September 2009

7 Challenges for Highly Effective Engineers

by James Campbell - jac@viewpointusa.com

What steps do you follow when developing a new test system?

Obviously, much depends on the need for the system: is a brand-new product requiring new measurement and control hardware or is an existing system obsolete and in need of replacement or upgrade.

Either case consists of many decisions beyond the technical choices of which measurement hardware to use. In this article, I highlight seven key challenges that should be considered before embarking on a new test system. I offer some suggestions to handle those challenges. Would you pick the same Seven Challenges? Read along and find out. (Yes, I intentionally chose the article title to mimic the title of Stephen Covey’s popular book. Perhaps I should write my own version for test engineers!)

1 - Product Complexity

Challenge: Products are more complex today than five years ago, certainly than ten years past. It takes more thought to create a test plan for manufacturing or a reliability test for exercising the new product design.

Suggestions: For a design and reliability test, the first question we like to ask the design team is “What do you want to do with the measurement data?” Focus on the output of the test(s) and work backwards to the steps or sequencing and forwards to reporting. Prepare your test code for flexibility, since the design team will usually change their requests after they see the results. For manufacturing test, if your design team hasn’t created a test requirements document, ask them to do so and especially do it in conjunction with test engineering (i.e., you). Sometimes, by sequencing test steps in a particular order, test time can be reduced without loss of testability.

2 - Development Tools

Challenge: Development tools are increasingly difficult to learn as is maintaining skills your skills if you don’t use the tools frequently. As an example, LabVIEW has much more capability then even two versions past, with the ability to target multiple platform types, real-time OS, acquisition devices and their associated quirks, and so on. Or, the VB developers, after making the switch from the now defunct VB6, confronted the .NET development environment and all those new classes, especially as the .NET framework has marched on from version 2.0 to the new soon-to-be-released version 4.0.

Suggestions: Development languages have devoted followers, where you can be very passionate about one and unlikely to switch. The best suggestion I can make is to look at your available pool of resources: who is available and what skills do they possess? People change jobs, move around in the company, or decide to hike the Pacific Crest Trail. If your company has a large source of C# programmers, consider using C#. However, today, most test engineers know LabVIEW, and, increasingly, through the efforts of NI, they are certified. Choosing LabVIEW is a smart choice, but use the right language for the job. Finally, spend at least one week each year keeping abreast of capabilities and possibilities.

3 - Engineering Proficiency

Challenge: Developing a test application seems to require a degree in Computer Engineering these days. Combine that with the complexity of the newer products and required skill levels have increased drastically over the past few years. I have seen the level of competency increase with time for many test engineers, but I’ve also seen others ill-prepared for the challenges of testing complex products under stringent conditions. Training, practice, and teamwork are very important. Are you ready to design a full-fledge test system? Just knowing how to create a “Hello World” application is complicated enough, and certainly not to produce a test system.

Suggestions: Adding to the last challenge, test engineers must go beyond being proficient with the development tools. I can think of three areas, each of which could be another newsletter article.

1. Learn good programming techniques. Take a course or two in basic computer science. Know how and when to use the tools, such as queues and semaphores, parallel threads and events, and so on. Know how and why to use objects and application frameworks (or patterns).
2. Learn to program in real-time operating systems (RTOSs). Code function priorities and maintaining loop timing present challenges to those only familiar with Windows applications.
3. Keep up on the measurement HW. For example, many products communicate to the outside world with RF. Do you know Manchester coding?

4 - Resource Limitations

Challenge: Either the project can’t be completed on time or the required expertise is not available with in-house resources. These two reasons are paramount considerations when out-sourcing. However, accessibility of hardware is often overlooked. Will you have hardware to mock-up or prototype a test station or perhaps a UUT itself to use for testing? Simulation systems provide an avenue to continue parallel development efforts when HW is unavailable, but the real stuff must be present for the final commissioning.

Suggestions: The choices are clear here. For time and personnel limitations, staff with contractors or outsource to integration companies. The latter is usually the best choice when hardware builds are involved. When lacking a UUT, start simulation efforts ASAP, and be prepared for many changes, since this situation usually goes side-by-side with a product that is still in design.

5 - Platform Choices

Challenge: Today, there are so many hardware possibilities and software choices. Even if you choose one vendor to follow the one-stop-shop mentality, the choices can still be huge. Consider National Instruments as an obvious example.

Suggestions: Obviously, the HW and SW need to be sufficient to build the test system under consideration. But, it is equally and maybe more important to consider how long you will be living with these choices.

How long do you expect your UUT and subsequent generations to be sold? How long do you expect the HW to be relevant and functional? Will the vendor still be in business in 10 years? Also, do you want to be on the “bleeding edge” or would you do better with “last year’s” generation of equipment and software, relying on the passing of time to remove those “new introduction” bugs. Of course, this approach leaves hardware that much closer to obsolescence.

6 - Maintenance

Challenge: Relevant to the previous item, you need to consider how long the test system will be in use. I have seen systems that are 25 years old, and the only spare parts now available for these systems are found on eBay. These experiences have demonstrated the importance of choosing robust and widely available components and designing the test system such that its components are easily accessible.

Suggestions: See the suggestions in the prior challenge. Also, for pure maintenance issues, items such as cables, harnessing, plug-in cards versus rack and stack equipment, all need to be easily accessible and swappable in the event of failure or even in the simple case of annual calibration needs.

7 - Measurement Data

Challenge: Test data is quickly approaching or maybe already has arrived in this realm of misty folder structures and network drives where the half-life of remembering file locations is one year or less. Test data management is difficult now and will be critical in the future.

Suggestions: Test engineers need to make their data accessible to others to leverage the usefulness of the knowledge extracted from the data. Plus, all this data needs to be searchable. Search engine (SE) usage is ubiquitous and so ingrained that people depend on them now (think Google or Bing). The same benefits of SEs should apply to test data. Progress is being made in this area already. NI’s DIAdem and our own Aperio products are examples.

Conclusion

This list of 7 challenges is based on Viewpoint’s extensive experience in producing test systems and my observations over the years. Being in the business of producing multiple test systems each and every year enables us to learn best practices and notice trends. These challenges appear frequently. Not every one for every test system, but often enough that we are concerned about them. You should be too.