instrumentation: automatic test equipment; hardware and software: the need for standard languages...

5
LARGE SYSTEMS Instrumentation Automatic test equipment: hardware and software The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic testing With automatic test equipment (ATE) accounting for approximately $0.5 billion a year of industry sales to the U.S. Government, it is not surprising that many com- panies have aimed their efforts at capturing this lucrative market. Basing itself on the early and costly development of ATE systems for the military and NASA, the com- mercial market has benefited immensely, in both avail- ability and sales. And the prospects for the future look even better. Meanwhile, the military ATE market continues to loom large. In 1975, of the total Department of Defense budget of $86 billion, operations and maintenance ac- counted for $26 billion. And of this, $8.4 billion went di- rectly toward logistic support, which includes supply operations and depot maintenance the prime area where ATE can be most effective in saving both time and money. Matching the ATE system to the unit under test (UUT) is a key problem for manufacturers and users. One of the questions now being asked is: Should ATE systems be tailored for special classes of test problems, or should "universal" ATE systems be fitted with special interface hardware for each and every UUT? A related, and equally important, problem is the de- velopment of ATE software. As the significance and cost of software continue to increase, relative to hardware and support, there is increasing interest in standardized languages that can serve vendors and users alike, and can be transported in the same sense that Fortran can now be transported from one ATE system to another. Such standardization remains a goal, but efforts like those di- rected to the Atlas language promise future improve- ments. Software: how much and what kind? By definition, an ATE system is one that runs under programmed instruction. Although the instructions need not be executed by a computer early ATE systems were operated directly from punched paper tape software is an essential component of ATE systems, and one that continues to grow in importance. * The amount of software needed for an ATE system, and the cost of that software, are basically functions of the complexity of the units under test. For a simple pro- duction test, where only one or two types of units are to be checked, the amount of software needed may be small. But when an ATE system is designed to support tests on, say, 500 different types of military circuit boards, the necessary software and adapter hardware may cost as Marce Eleccion Associate Editor much as four times more than the basic ATE system it- self. At present, the general cost breakdown for the ATE user seems to be about 25 percent for the initial purchase, 20 percent for adapter/interface hardware, 30 percent for software, and 25 percent for support. Software costs are easy to underestimate; the process of translating English language statements into program language is only the first step on a long road. After the usual debugging and rewriting, an applications program must be tried out with a unit under test that has actually been tied into the test system via interface devices. Even then, the program is not complete until an independent quality assurance procedure demonstrates that it can locate significant, real faults. Across industry, the most successful ATE pro- grams have been written by engineers who picked up programming skills. It seems to be a widespread axiom among ATE designers that it is a lot easier to teach a* bright test engineer programming than to teach a bright programmer engineering. Broadly speaking, there are three types of software in ATE systems: applications software directs the actual testing of each UUT; operational or system control software drives the ATE computer itself while the tests are being conducted; language processing software converts high-level user-oriented instructions into suit- able codes for detailed operation. There are two main modes of using ATE software. In the interpretive mode, the program is executed and di- rected step by step on the ATE system. In the compiler mode, a complete program is converted, via language processing software, and then run on the ATE system. Use of the interpretive mode is feasible in ATE systems because response from the unit under test is usually slow, compared with general-purpose computer systems. The ATE system spends much of its time waiting for test de- vices to stabilize. And the interpretive mode can allow reduced programming effort and memory use compared with the compiler mode. For instance, so-called run-time variables which depend on current test-system condi- tions can be relatively easily handled, using the inter- pretive mode. The compiled mode allows the ATE pro- grams to be readily linked to existing languages, such as Fortran and Basic, and to existing software routines for driving various peripheral devices. Atlas against the Tower of Babel Over the years, many different automatic testing lan- guages have been developed. For each ATE system, the designers found what they felt was an optimum way to address their problems. The result was a Tower of Babel in which it was not possible to use any ATE language IEEE spectrum JUNE 1976

Upload: marce

Post on 09-Feb-2017

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Instrumentation: Automatic test equipment; hardware and software: The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic

LARGE SYSTEMS

Instrumentation

Automatic test equipment: hardware and software

The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic testing

With automatic test equipment (ATE) accounting for approximately $0.5 billion a year of industry sales to the U.S. Government, it is not surprising that many com-panies have aimed their efforts at capturing this lucrative market. Basing itself on the early and costly development of ATE systems for the military and NASA, the com-mercial market has benefited immensely, in both avail-ability and sales. And the prospects for the future look even better.

Meanwhile, the military ATE market continues to loom large. In 1975, of the total Department of Defense budget of $86 billion, operations and maintenance ac-counted for $26 billion. And of this, $8.4 billion went di-rectly toward logistic support, which includes supply operations and depot maintenance—the prime area where ATE can be most effective in saving both time and money.

Matching the ATE system to the unit under test (UUT) is a key problem for manufacturers and users. One of the questions now being asked is: Should ATE systems be tailored for special classes of test problems, or should "universal" ATE systems be fitted with special interface hardware for each and every UUT?

A related, and equally important, problem is the de-velopment of ATE software. As the significance and cost of software continue to increase, relative to hardware and support, there is increasing interest in standardized languages that can serve vendors and users alike, and can be transported—in the same sense that Fortran can now be transported—from one ATE system to another. Such standardization remains a goal, but efforts like those di-rected to the Atlas language promise future improve-ments.

Software: how much and what kind? By definition, an ATE system is one that runs under

programmed instruction. Although the instructions need not be executed by a computer—early ATE systems were operated directly from punched paper tape—software is an essential component of ATE systems, and one that continues to grow in importance. *

The amount of software needed for an ATE system, and the cost of that software, are basically functions of the complexity of the units under test. For a simple pro-duction test, where only one or two types of units are to be checked, the amount of software needed may be small. But when an ATE system is designed to support tests on, say, 500 different types of military circuit boards, the necessary software and adapter hardware may cost as

Marce Eleccion Associate Editor

much as four times more than the basic ATE system it-self.

At present, the general cost breakdown for the ATE user seems to be about 25 percent for the initial purchase, 20 percent for adapter/interface hardware, 30 percent for software, and 25 percent for support. Software costs are easy to underestimate; the process of translating English language statements into program language is only the first step on a long road. After the usual debugging and rewriting, an applications program must be tried out with a unit under test that has actually been tied into the test system via interface devices. Even then, the program is not complete until an independent quality assurance procedure demonstrates that it can locate significant, real faults. Across industry, the most successful ATE pro-grams have been written by engineers who picked up programming skills. It seems to be a widespread axiom among ATE designers that it is a lot easier to teach a* bright test engineer programming than to teach a bright programmer engineering.

Broadly speaking, there are three types of software in ATE systems: applications software directs the actual testing of each UUT; operational or system control software drives the ATE computer itself while the tests are being conducted; language processing software converts high-level user-oriented instructions into suit-able codes for detailed operation.

There are two main modes of using ATE software. In the interpretive mode, the program is executed and di-rected step by step on the ATE system. In the compiler mode, a complete program is converted, via language processing software, and then run on the ATE system.

Use of the interpretive mode is feasible in ATE systems because response from the unit under test is usually slow, compared with general-purpose computer systems. The ATE system spends much of its time waiting for test de-vices to stabilize. And the interpretive mode can allow reduced programming effort and memory use compared with the compiler mode. For instance, so-called run-time variables—which depend on current test-system condi-tions—can be relatively easily handled, using the inter-pretive mode. The compiled mode allows the ATE pro-grams to be readily linked to existing languages, such as Fortran and Basic, and to existing software routines for driving various peripheral devices.

Atlas against the Tower of Babel Over the years, many different automatic testing lan-

guages have been developed. For each ATE system, the designers found what they felt was an optimum way to address their problems. The result was a Tower of Babel in which it was not possible to use any ATE language

IEEE spectrum JUNE 1976

Page 2: Instrumentation: Automatic test equipment; hardware and software: The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic

across company or organizational lines. Recognizing the need for some sort of standard ATE language, volunteer committees organized mainly through Aeronautical Radio Inc. (ARINC)—an airlines-oriented organiza-tion—developed Atlas (abbreviated test language for avionics systems). Since its inception, just a few years ago, Atlas has found wide acceptance among major airlines, aerospace companies, and instrument manufacturers, as well as in the military. In fact, both the U.S. Navy and the U.S. Air Force have adopted Atlas as their interim stan-

dard for ATE. The U.S. Army, which had been pressing for adoption of an alternative language called Opal, re-cently decided to recognize Atlas as the applied ATE language. The Army continues to recognize Opal as the favored experimental-developmental language, and looks forward to a time—probably within the next couple of years—when the better features of both Opal and Atlas will be merged to form a DOD-standard language.

A recent ARINC survey indicates that 11 percent of Atlas users employ a "standard" version ofthat language;

Spectrum survey of testing needs

Last year, Spectrum conducted a survey of almost 5000 automatic testing system users and developers to deter-mine whether any real progress had been made in ad-vancing the state of the art. The answers to our ques-tions proved revealing but not surprising—the represen-tative ATE user, still overwhelmed with the job of testing complex devices and systems, thought that the micro-processor would be able to solve many of his problems, and hoped for better measurement capability in future systems.

The present situation is a familiar one—our average ATE user, confronted with overwhelmingly complicated test procedures in every field from communications to avionics, is beginning to insist on devices and systems that easily interface with each other, the real world being measured or controlled, and himself. And he wants it done quickly, accurately, and—above all— cheaply. Although he has specific problem areas (RF, microwave, and nonelectronic systems in particular), he relishes the universal tester—one that interfaces with everything, generates test programs and fault diagnosis automatically, accepts a high-level standardized test language, and churns out easily understood data and in-structions.

In many ways, the problem of universal testing has been approached by the application of costly software, a solution that has introduced many problems of its own. For this reason, such LSI circuitry as the microproces-sor and semiconductor memories have been sought by ATE users and developers alike as the most likely can-didates to impact the next generation of ATE. With the dedicated microprocessor, a modular approach to uni-versal testing may be achieved inexpensively; this trend toward modular system building is not only popular with ATE users, but seems to be prevalent throughout the electronics industry for applications ranging from instru-mentation to home entertainment.

In the first question to the Spectrum survey, ATE users and developers (actually, the distribution was about even) were asked If they felt that ATE develop-ment was keeping up with the progress being made by the overall Instrumentation field. To this, approximately 30 percent answered "yes," 28 percent "no," 5 per-cent said that the ATE field progressed even faster, and 37 percent were noncommittal or didn't know. The last statistic Is probably attributable to the fact that many readers did not differentiate between the two fields.

Question 2 asked the reader which technologies he anticipated would have the greatest Impact on future-generation ATE. The answers (see Fig. 1) gave an over-whelming edge to the microprocessor, with high-density memories and LSI technology capturing second place. Some answers could not be listed In our statistics be-cause of their sparseness; among these were disk and plated-wlre memories, management systems, supercon-ductive devices, fast-Fourier analysis for analog testing, test-dedicated consoles, Intercomparison algorithms, cybernetics, and contactless testing. In answer to a question as to how they projected the widespread use of the new technology, most respondents agreed that the technologies listed would take up to five years, with ex-

o I

20 I

40 t

60 I

80 I

100 I

Ίmicroprocessor, techr^ogy;

Highfdensity bulk merwiias <■•"■v:M

Automatic test generation arid fault diagnosis':·: V: ·; y

Digital data-processing; techniques.' : / ;

"High'ievdl standardized, test languages.;

BüjU-in-self testing ·'

Minicomputer control

Better displays

Efectrooptics

Intelligent control ·.; ^ ■:-:r'A terminals.;; ■·. Λ ; \ ■ .'■. " · : . · ' * - . '·..*'■··'. '.'>:£? v-.'.".Vi

Computer-aided ' .· ■" :. -'^y ■ \*-U""_- ' . ' " ; ■ / \ / ' design . . : · " ' . - ;Λ· "·;·'- ';"/-/, '■ '';. '·.· ';'... ·;·'.'-;· >'.';: Programmable "smart" ? ' instruments ; : V «· -;\\ *> · · ; - " . " ' , - ' .·.' \ ··'.'·" ' j

[1] "What new or emerging technologies do you anticipate will have the greatest Impact on the next generation of ATE?"

[2] "Identify those features of the new and emerging technologies that best lend themselves to future standardization."

Maintenance and repair. *;

otic technologies like holography and contactless test-ing taking from 10 to 20 years to become fully Imple-mented.

The two leading answers to question 3 (Fig. 2), which asked respondents to Identify those features of emerg-ing technologies that best lend themselves to standard-

Elsccion—Automatic teat equipment: hardware and software 61

Page 3: Instrumentation: Automatic test equipment; hardware and software: The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic

38 percent use a subset of the language; 36 percent use an expanded or modified version of Atlas. Despite its growing use, proponents of Atlas point out that both the purpose and the details of Atlas are often misunderstood.

In the first place, Atlas is a procedure-oriented lan-guage. The first portion of an Atlas program—called the preamble—defines the testing functions involved. This portion lays out the ground rules. The preamble is fol-lowed by a program body that describes the actual test procedures to be used. For example, consider the Atlas

statement: MEASURE, (FREQ ERLMT + -0.002 MHZ), AC

SIGNAL, FREQ RANGE 4 MHZ TO 6 MHZ, VOLTAGE RANGE 1 V TO 1.5 V, CNX HI Jl-1 LO Jl-2 $ This statement defines the test function as: measure the frequency, with required measurement accuracy of ±0.002 MHz, of an ac signal having expected amplitude and frequency characteristics of 1 to 1.5 volts ac at 4 to

ί„5;·ϋ.5ίΗΧΐ£"73.·ΪΣΑ'ί3;

20 I

40 I

60 30 I

100 I

Testing of complex devices and systems

RF and microwave testing

Mechanical /electromechanical/ nonelectronic system testing

Electroopticat device and systems testing

Automatic program generation and fault diagnosis

Cost-effective software development

Displays and the man-machine interface

Low-cost ATE systems

Remote (on-line) or on-site diagnostic systems

Built-in-self-testing

[3] "What areas of application do you feel the present ATE technology does not successfully satisfy?"

[4] "What new features would you like to see Implemented In future-gen-eration ATE?'*'

20 I

40 I

60 I

80 I

100 I

j Better measurement capability and performance

Standardized software/test languages

ϊ · - ' · · . " ■ - · ; " . · . " '·.:· "·."'■ '■■ ■"· v . " " ·..· ' - · ' - " ;> · .. ··

1

1 V V v V : : ; ■■■'■[

1 .·

"Be pe

Com signs

St; ha

Sta

More use of

|Au jge Autc and

[Built-in self-test and [self-calibration

True hardware/software modularity

Stan( inter

terdized face V ;'..'.. ?'

:\-··':-. ;.

tomatic test-program neration v : , · * >matic fault̂ diagnosis fault isolation

sophisticated , v ··; v

computers j '."/.■·.';·"· "/.':··" '·':''· : ndardized /'-:··:· ;' : ; · . Μ » » Λ « * £ £ « ♦ · . £ » V." .

Smaller, more portable, more inexpensive ATE systems

aridardized · *>'rC rdware .·>'··

suter-aided 1 analysis .

Reliability \ ; '■'■■; ; and durability ~ ■·'■-"-.

ripherals '■·■''··;.;■;*· ·'■" ''".'·■".··'■" ·· '"'.^V/^A:.

ization, reflected the two areas receiving the most at-tention in standardization today—digital bus interfaces and test languages. The concern with interfacing, of course, brings us back to today's dilemma of communi-cating effectively between many instruments, control stations, and a central computer bank. Primary concern among the answers was for such present systems as Hewlett-Packard's and the International Electrotechnical Commission's (IEEE Std 488), the ASCII standard, and CAMAC.

In terms of standardized languages, Atlas seemed to receive the most attention among respondents requiring a procedural-type language, although languages sought after ranged from basic-English languages to design lan-guages to problem-oriented languages to "high-level" languages, an indication of the multifaceted communi-cations problem confronting the user who wants to speak to his machine.

Other responses to question 3 included everything from logic levels, cycle time, and word lengths to pack-aging, module functions, and removable media such as floppy disks

Of all the responses to the questions in our survey, none led by so great a margin as the most popular reply to question 4. In naming the areas of application not fully satisfied by today's ATE technology (Fig. 3), re-spondents showed their complete frustration with at-tempting to test modern complex systems. In reality, the first three leading answers to this question could have been lumped together, for they are part of the overall problem. On the one hand, the user cries helplessly for designers to make systems more testable (to the point where he sighs in relief at modular subsystem concepts, built-in test equipment, or even accessible test points); on the other hand, he welcomes any aid in solving nitty-gritty details such as those encountered with testing small communication systems, home entertainment de-vices, pulse-type and phase-sensitive equipment, tele-phone equipment, networks, medical instrumentation, low-signal applications, and—above all—RF and micro-wave switching problems.

Question 5 (Fig. 4), which allowed the respondent to bare his chest by asking him to list those features he would like implemented in future ATE, again reflected the major concern of automatic testing—better mea-surement performance. Included in this category are re-quests for higher-frequency capability, parallel stimulus and measurement, sampled measurement, arbitrary function generation, automatic computer selection of stimuli, UUT simulation, faster pulse generator rise and fall times, more accurate low-impedance switching, self-determination of analog test limits, reference stan-dards and switching capability to handle "bad" mea-surements, and on . . . and on . . .

In short, today's ATE user feels himself in a quandary, hamstrung by his inability to easily test complex sys-tems, but still secure in his belief that things will get bet-ter through a generous application of better, standard-ized measuring and control techniques, and a renais-sance in instrument and system design.

62 IEEE spectrum JUNE 1976

Page 4: Instrumentation: Automatic test equipment; hardware and software: The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic

System test cells

TV monitor of system test

H26O0 computerized module test Goerz 551-3

test table Fecker 267 0000 test table

Fecker 267 0100 test table

Accelerometer test stand

Typical CRT monitor and control

Typical MAG tape data recorder

IIA test table (not visible)

Data link to H6080 and H-716 computers

A fish-eye view of Honeywell's inertial test facility portrays the complexity of high-level automatic testing.

6 MHz, present at UUT output pins Jl-1 and Jl-2. Atlas allows all those concerned with a given ATE

procedure to understand exactly what is involved. It can be used to define manual as well as automatic test, it provides a basis for transporting programs from one ATE system to another, and it allows both program use and changes to be standardized. These are valuable assets for the military and for those organizations that need such standardization. For those involved in in-house testing jobs, where no such standardization is required, Atlas may seem ponderous and overly expensive.

At Hewlett-Packard, it is felt that although Atlas is self-documenting and easy to modify and transport, it is not an easy language to learn. They feel, however, that Atlas allows ease of failure analysis, which is enhanced with product systems that can be broken down into subsystems.

William F. Boggs, systems marketing manager for E-H Research Laboratories, has told Spectrum: "While I think that something that might work would be a series of standard commands, I don't feel that the way a soft-ware system operates can ever be standardized."

Atlas proponents feel that it is an important lan-guage—not because it is so beautiful—but because it has been proven and is widely used. Although Atlas does not solve all ATE problems, it offers considerable flexibility. Thus, it can be used both in the interpretive and compiled modes. In fact, at RCA Atlas programs are compiled into an intermediate code, which is then executed interpre-tively. And at Hewlett-Packard, Atlas is compiled into an intermediate language called ATS Basic. Thus, an Atlas statement that calls for a measurement of frequency may compile into ten ATS Basic statements that set up an input attenuator to a counter, close a switch, set the equipment in the frequency mode, take a reading, etc.

Many conversions and calculations can be done directly in the Atlas language, and it allows for subroutines (in-cluding Fortran) for detailed operation. Recently branching and IF-THEN-ELSE instructions (useful for structured programming) were added. Atlas is a living language, constantly being updated and enlarged.

Universal vs. dedicated systems Turning from software to the problem of interfaces

between systems on the units under test (UUTs), we find that general-purpose or "universal" ATE systems

sometimes require interface units many times more complex than the device or system they are designed to test. The Navy's VAST on-board aircraft carrier avionics test system is an example. One way to reduce UUT in-terface complexity dramatically is to use the peripheral interface unit concept as approached by RCA in their EQUATE system and by General Dynamics' SCATE system. The concept involves a set of interface hardware that can be used for many different UUTs, adapting to the special requirements of each, by means of individu-alized software. Although expensive (the cost of switching is increased dramatically), the technique is ideal for medium- to large-size ATE systems required to test a variety of different devices.

Some observers now see the balance shifting between universal and special-purpose ATE systems. For example, Robert Sigsby, publicity coordinator for Teradyne, ob-serves that, until recently, the needs of the semiconductor manufacturer have been met most satisfactorily by somewhat general-purpose testers; that is, test systems that can handle a wide range of devices. However, as de-vices become more complex and more difficult and time-consuming to test, it is becoming more cost-effective to turn to more optimized, or dedicated, test systems. For example, there are now testers designed strictly for cal-culator chips, for time-keeping circuits, and for memories.

Linear devices are also demanding more dedicated testing and, although the volume produced is often suf-ficient to cover the cost of individual testers for each type of linear device, the flow of devices to be tested may be unregulated. According to Sigsby, the result is that a large batch of voltage regulators may be produced one day, and a batch of op amps the next day, meaning that several dedicated testers might sit idle for much of the time.

Experts like Robert Rassa from Westinghouse feel that one large ATE system for all test systems does not appear to be the most cost-effective deployment. Smaller ATE systems, designed to handle functional families of test units, are seen as far more adaptable and practical. Ex-amples of functional families include radio frequency (RF), low frequency, digital, electromechanical, and so on. Rassa declares: "If the UUT was not designed with ATE in mind, attempts at using ATE are met with little or no success. The most successful ATE projects are those involving the design of prime equipment UUTs as an integrated factor." +

Eleccion—Automatic test equipment: hardware and software 63

Page 5: Instrumentation: Automatic test equipment; hardware and software: The need for standard languages and sophisticated interfaces is paced by the expanding applications for automatic

·:,:',·£%ν·&&335 ^ f c^^^ÖaSüS^SSä &fg&S&^J..:". ,.·■ . :

Duplicated equipment

I [1] In the D-10 system, ehown here In block diagram form, a Equipment in partial stored-program computer contrcia the switching circuits, while standby service Input-output equipment provides maintenance and operating

personnel access to the system.

64 Shiromizu—Electronic telephone twitching in Japan