While graphical programming has already proven its benefits to the VXI world, the automated test industry has been slower to accept it. Perhaps it is the perception that graphical programming does not easily lend itself to automated test executive environments. Nothing could be further from the truth.
To appreciate the contribution of graphical programming, let’s review what it’s done for instrumentation. With the fast, interactive turnaround of a graphical programming environment, test engineers get programs up and running quickly. And instrument drivers and other high-level libraries found in graphical programming eliminate the need to develop large portions of test programs from the ground up.
So how does graphical programming figure into the test-executive environment for automated test applications? This is a particularly important question when you consider the big distinction between test-system development and execution in the automated test environment.
Often, the operator of an automated test program is not knowledgeable about the tools used to develop tests, prompting the need for a separate test-execution environment. This environment, typically called a test executive, is the most distinguishing characteristic of an automated test system.
What Is a Test Executive?
The simplest definition of a test executive is an environment for running a series of programs. Although a test executive may include capabilities for diagnostics, it primarily enforces a strict execution sequence of test programs to determine if a DUT passes some specified criteria. It performs three major tasks:
o Test-flow control.
o Data logging.
o User interfacing.
Test-Flow Control
Perhaps the greatest misconception about using a graphical programming language in the automated test environment is the concern that such a language is not suitable for test sequencing and flow control. A graphical programming language naturally represents parallel operations, while a test executive incorporates an execution scheme that is primarily sequential. Traditional procedural programming languages naturally fit the model of a sequential execution model. Consequently, there is a perception that traditional programming languages are better for developing test executives.
In reality, the execution model of a test executive is not simply sequential. A test executive commonly includes capabilities to alter the execution sequence based on the results of tests in the sequence (Figure 1). Failure of a given test could prompt the system to skip a subsequent test or stop testing altogether. The test executive also may give an operator certain diagnostic features. This capability may give a more knowledgeable operator the ability to run a single test or loop on a test.
The execution capabilities of a test executive are not represented simply by the capabilities of a language, whether it be procedural or parallel data flow. Stated another way, no programming language, graphical or otherwise, is automatically a good test executive.
The heart of a test executive is its flexible execution engine. The development of such an engine requires a programming language. To develop a test-executive engine, the language must provide primarily looping and logical comparisons—basic components of any commercial programming language, including graphical programming products. The selection of a language for developing the engine of a test executive depends on the features of the language rather than on a perceived suitability of the basic execution model of the language.
Data Logging
Logging test results is a major function of a test executive. A key requirement for data logging is the ability to save data in the most appropriate format for the ultimate end use.
A simple ASCII text format can be imported into almost any application, such as a spreadsheet or word processor. In general, the host environment for a test executive must have the data-formatting functionality required to produce the data log in the desired format.
Another key data-logging requirement is the capability to write data over a network and possibly to a data base. To give a test-executive developer the most flexibility in distributing test data, a graphical language must include many input/output options including file, TCP/IP, and dynamic data exchange on Microsoft Windows.
User Interface
The third major requirement for a test executive is a user interface, which limits the operator’s control as defined by the developer. At one extreme, an operator may only select a run button, wait for a set of tests to complete, replace the current DUT with the next device, and start the cycle again. An interface for such a process could be as simple as a single push button on a dialog box.
A more likely scenario is a protected system that presents different levels of control based upon the operator’s password. The operator’s password may present only the run button while a technician’s password might allow selection of individual tests for diagnostic purposes. The developer may even have a special password to allow test-program changes.
Presenting these options in a test executive requires flexible control of the user interface. A graphical user interface (GUI) gives a wide range of options for presenting information to an operator.
Graphical Systems Pass the Test
From the point of functionality, a test executive is not a highly complicated entity. It must provide certain basic capabilities, such as test-flow control, data logging and a user interface (Figure 2).
The fundamental requirement for developing a test executive is a language with basic looping and decision-making capabilities. It also must have the tools for formatting data, creating files, connecting to networks and creating GUIs. Several graphical programming systems for instrumentation meet these requirements.
The ultimate deciding factors, however, are the other capabilities you expect from the development environment. How easy to use and capable is the language for developing test programs? Are there good facilities for debugging programs? Do you need instrument front panels? Are there libraries available, such as instrument drivers or analysis routines, to simplify the job of developing test programs?
Graphical programming languages have proven leverage when it comes to developing actual test programs. Developing a test executive is essentially a one-time operation; developing test programs is an ongoing process. The combination of powerful, easy-to-use test-programming tools and the basic functionality to build a test-executive environment make the graphical programming language a very compelling choice for use in automated test systems.
About the Author
Michael Santori is a Marketing Manager at National Instruments and has been with the company for eight years. He is a graduate of Texas A&M University with a B.S. degree in electrical engineering. National Instruments, 6504 Bridge Point Pkwy., Austin, TX 78730-5039, (512) 794-0100.
Copyright 1995 Nelson Publishing Inc.
June 1995
|
|