It has been a few months since my last article, "The Next Best Thing to a Crystal Ball for Your Test Strategy," which focused on the role of a modular hardware platform in rapidly changing test requirements, a reality that most test engineers and managers face each year. But as we all know, hardware is only half the battle. Love it or hate it, software is now “the brains” behind a modern automated test system. Without time to press buttons and turn dials, you must automate measurements if you wish to remain competitive.
So, as you pack your bags and head out for summer vacation, spend some time reflecting on your test department’s approach to test software and how it will look in the future. If your OS changed, would your approach still work? If an instrument went end of life, how long would it take to update the code for the new instrument? If your test-software architect left the company, would anyone else know how to modify your software?
This file type includes high resolution graphics and schematics when applicable.
Functioning at a Higher Level
Languages serve a critical role in our lives by enabling us to communicate with one another. Regardless of the format, we are always looking for ways to optimize and improve our communication through language.
For example, chefs and cooks used to shout the command, “add liquid to the hot pan with browned bits and reduce while stirring,” to explain how to make a sauce reduction by harvesting the brown bits of meat on the bottom of the pan. To save time, they adopted the term “deglaze.” In a restaurant, time is of the essence, so when a single word accomplishes the same task as the traditional multiword explanation, chefs and cooks adopt it.
Imagine going to a restaurant and the chef coming to your table and stating, “I apologize for the delay. The language we use in the kitchen is complex; therefore, it takes us 10 times longer than it should to prepare a meal.” Though this situation might seem ridiculous—the restaurant would certainly go out of business—test departments commonly miss deadlines due to software development delays. Instead of delivering a meal late or burned to a customer, test departments are often forced to ship a test-software application that does not meet the internal quality standards of their companies. The restaurant situation results in an unhappy customer or two; a test department faces missed revenue due to a longer time to market or risks product recalls because of low-quality validation. So how do you optimize the communication of your test software to reduce development time? You use abstraction.
If you want to stay competitive in today’s ever-increasing market pressure, you must use an integrated development environment (IDE) that makes it possible to abstract low-level complexity and express commands in a higher-level syntax. If you are struggling to deliver your test applications on time and with the level of quality specified by your company, you are likely using a low-level software approach with 10 times the amount of code than is necessary.
Just as a great line cook understands the term “deglaze” from his chef, a well-architected hierarchy of abstraction in your test application can interpret the function “acquire” and send the series of lower-level commands to the appropriate instruments. By modularizing low-level code into higher-level functions, you also can better isolate semantic errors. Therefore, you save time not only when programming, but also when debugging.
In addition to abstracting low-level syntax, selecting the right application-specific IDE can offer further benefits. For example, test-software applications need a user interface to display relevant data to the operator and provide system control. Also, multicore processors are common in industrial computers, so an IDE should distribute signal-processing and data-manipulation algorithms evenly across all cores to decrease test and measurement times.
Further, an IDE should offer signal-processing and data-manipulation libraries to reduce development time. If your test department is using a general-purpose IDE, then you are spending time on administrative tasks such as parallel programming, file I/O, and signal-processing algorithms rather than focusing on the real task at hand: developing test sequences.
Unifying Disparity
When deciding on a language for communication, most people default to what is easiest for them—their native language. But the real question is: “Who is your audience or the recipient of your communication?”
In today’s globalized world, you are most likely communicating with someone outside your region. If you are from Germany, the chances of you traveling to China and speaking German with a local who understands you are slim to none, so you must adapt.
In a recent article in The Guardian, Alberto Nardelli said the European Union has more than 20 official languages, more than half of EU citizens can hold a conversation in at least one additional language, and 25% of them speak at least two languages. The overlapping foreign language is English. All participants in the conversation still think and process in their native languages, but they use English to communicate with each other.
A test system has a similar setup (Fig. 1). The common spoken language is the IDE programming language, and the instrument driver and API serve as the translation layer to the varying native languages (firmware) of the individual instruments. However, another layer has emerged above the IDE over the past decade—test management software—which helps to facilitate the development, execution, and deployment of test system software (Fig. 2).
Just as an effective application-specific IDE includes prepackaged functionality that helps develop individual test routines, test management software features commercial off-the-shelf functionality for sequencing these test routines, logging test results, building and distributing software installers, developing high-level operator interfaces, and generating reports. It can also integrate routines developed in different IDE languages. Though this might seem trivial at first, it helps many test organizations that have, over the years, juggled different IDE preferences from test-software engineers across the organization. Music enthusiasts experience this pain if they try to play music contained in the various formats they have collected over the past few decades: vinyl, 8-track tapes, cassette tapes, CDs, and now MP3 files.
The Platform for the Future
The future is bright in the field of science and engineering. At National Instruments, we see this regularly through our participation in mentoring and outreach programs. I nostalgically look back at the tools I had as an engineering student. They weren’t stone tablets, but at times they feel that way compared with what technology students have at their disposal today. These tools form the platform for their education and their innovation. But students aren’t the only ones reaping the benefits of these platforms—engineers and scientists gain from them, too.
NI’s test management software, TestStand, is one of these platforms. More than 6000 companies use it worldwide, and 1200 engineers are professionally trained each year on the software. Engineers regularly tell NI about the productivity gains they achieve with TestStand, since it offers the core functionality of test management software out of the box. They can then build on this broad set of tools to meet the challenges of specific applications such as wireless production test and semiconductor characterization and test. Because it’s an open platform, TestStand allows NI engineers and customers alike to plug in functionality for device-under-test manipulation and handling, 802.11 protocol test sequences, system calibration, multisite test, STDF reporting, and much more.
This file type includes high resolution graphics and schematics when applicable.
At the end of the day, nobody wants to receive a letter of resignation from his or her test-software architect. This is a great setback. However, companies can mitigate the risk of test-software development by adopting commercial off-the-shelf software that meets most standard test-software requirements. If you’re already taking this approach, then you can rest easy this summer holiday knowing that whatever the future holds, you’re prepared to handle it swiftly and economically.