DIMATE(ID:252/dim001)for Depot Installed Maintenance Automatic Test Equipment. Benson H. Scheff, RCA, for automatic equipment tests, on RCA 301. Derivative of an earlier RCA development for their MTE (Multipurpose Test Equipment). Samples: References: in Southeastern Regional Meeting of ACM, June 9, 1965 view details Concluding Remarks The compiler which uses the source language described in this paper has been operational since June, 1965. Because the source language has been used by both engineers and technicians, a preliminary evaluation of the ease of using the language can be made. Virtually no previous indoctrination in either the DIMATE system or the compiler language is required to enable a test engineer to interpret an existing test program. Furthermore, our experience has shown that the rules for writing the language can be mastered simply by having an engineer (or technician) who is moderately familiar with the DIMATE system write a test program. Some engineers have been able to write programs correctly after spending less than an hour of self-instruction. This language has proven to be of value not only during program coding but also during program debugging. In addition, the user- oriented source language has permitted engineers who did not participate in writing the test program to be of assist- ance during the program debugging phases. Extract: Introduction Introduction An Automatic Test Equipment (ATE) system consists of a configuration of programmable devices which apply stimuli and obtain measurements from electronic units. The testing processing is designed to determine the operational condition of the unit being tested. Programming an ATE system consists of translating the procedures for testing a unit-under-test (UUT) into a test program which automatically or semiautomatically conducts the equipment test. The test engineer programs his test by writing instructions to: (1) address the required stimulus generators and set them to the proper scale, (2) provide the commands which connect the stimulus generators and the measuring devices to the UUT, (3) specify the numerical limits for comparison with the test results, and (4) generate the commands which start the test. A compiler can be used to convert the engineer's specification of the test procedures to the ATE digital code. However, because a test engineer is not generally trained as a digital computer programmer, the compiler's source language must allow the engineer to state his test in a simple language not artificial to him and not requiring programming-oriented conventions. A major drawback to applying syntax-directed compilers is the user's difficulty in relating the compiler input language to his background. The compilers generally suggested for ATE systems use source languages which depend heavily on programming notation (some of which has been adopted from existing programming-oriented languages). The nonprogramming-oriented engineer has trouble adjusting to notation and conventions which either have no direct meaning or conflict with existing meanings in his application area. Having a nonengineering-oriented digital-computer programmer translate the test engineer's test specifications to the language used by the programming system is no panacea. The practical difficulties with this process have been amply recorded [1], [2]. In many such ATE systems the engineer prepares a flowchart from which the digital computer programmer codes the test. In some cases the digital-computer programmer, after discussing the test sequence with the engineer, codes some general types of statements leaving details to be filled in by the test engineer. However, wherever the engineer did not prepare the test instruction in the final form for the computer input, the comnmnication loop between engineer and programmer became a continual process. The programmer because of his lack of engineering orientation repeatedly had to question the test engineers and blunder into asking the "right questions." A compiler which uses engineering expressions arranged in a tubular format has been developed for a particular ATE system, DIMATE (Depot Installed Maintenance Automatic Test Equipment). Because the tabular structure provides a framework into which test parameters can be inserted, test procedures can be stated in a source The DIMATE system consists of a general purpose digital computer controlling a complex of programmable stimulus and measuring devices for testing electronic communication assemblies. language having a simple syntactical structure. Consequently the engineer can program his test requirements in a format which appears natural for him using only common engineering vocabulary terms. The programming conventions are built into the structure of the table. As a result the engineer programs his test specification directly. Such an input source language (1) minimizes engineering training time, (2) decreases the engineering skill level required to write test programs, (3) removes computer programmers from the programming loop, (4) facilitates engineer-to-engineer communications, and (5) permits test program to be used for test design documentation. As a secondary benefit a tabular language minimizes the anmunt of syntactical analysis processing to be performed by the compiler. As a direct result the compiler program translating this tabular source language has a simpler design and is cheaper to implement than a standard statement language compiler. Extract: Language Description Language Description The compiler language consists of 24 functions shown in Table I. Associated with these function words is information which further defines the function such as units of magnitude, statements to be printed and connection point identification. From an application standpoint, the functions can be subdivided into three major groups: 1. Basic test processes: (a) Connecting and disconnecting stimulus and measuring devices. (b) Establishing proper time delays. (c) Generating stimulus signals and performing the measurements. (d) Evaluating measured values against specified limits. (e) Branching based upon results of a measurement comparison. (f) Printing measurement results. 2. Internal test program control and arithmetic computations: (a) Conditional jumps based upon state of internal program indicators. (b) Computational subroutines. 3. Compiler processing: (a) Starting and stopping compilation. (b) Comments. The functions in the first group form the primary language used to specify DIMATE test operations. The language is comprehensive and permits all output stimulus signals and input measurements to be selected. Each statement contains sufficient detail to define the selected stimulus to be applied to the UUT or the selected measurement to be performed, the DIMATE interconnectors which are required and points of applications. The test sequence may branch according to the results of a comparison between a measurement value and stated limits. in [ACM] CACM 9(04) April 1966 view details A truly effective computer-directed data processing system is one that can be programmed rapidly and efficiently by the intended user. However, most data processing systems, and the languages developed for use with them, implicitly require that the user be trained as a computer programmer. Contrary to the system programmers' general conception, the user may not readily adopt programmers' conventions for his task. A problem-oriented data processing system is not automatically a user-oriented system, and may present a severe obstacle to the non-programming-oriented user. In the case of automatic test equipment, the user is a test engineer who thoroughly understands testing techniques and the functional operation of his equipment. To prepare programs which direct the operation of his tests on the automatic test equipment, the test engineer needs a programming system which he can understand and use easily. Extract: Summary The DIMATE programming system is a user-oriented system because it: 1. Reduces the time and cost of test programming 2. Minimizes the specialized training needed to prepare test programs 3. Improves overall information flow 4. Eliminates retraining required by the user for new ATE systems These goals were accomplished by: 1. Decreasing the engineering skill level required to write test programs 2. Removing computer programmers from the UUT programming loop 3. Reducing engineering training time 4. Decreasing the time required to prepare and checkout UUT programs 5. Facilitating emendations to existing UUT test programs 6. Permitting engineer-to-engineer communication on the engineering level 7; Using the UUT test program coding input a. as the test program specification b. as final test design documentation Extract: Benefits benefits The intrinsic value of a programming system is realized when it is designed to fulfill the needs of the user. The ever-increasing application of computer-directed systems, both in defense and industry, where the user is not trained as a skilled programmer emphasizes the value of programming aids. The field of automatic test equipment is only one example. Programming aids which are based on techniques and vocabulary which the user can relate to his background mark a significant step toward practical user-oriented programming systems. A simple processing system which is specifically tailored to a user's background can be more effective than a very elegant and powerful processing system. In the case of DIMATE, the compiler with its user-oriented source language and tabular format has made it possible for non-programming-oriented test engineers to write their test programs without undergoing an intensive education process. The long range benefits become apparent when one considers for a moment the normal turnover of personnel during a five-year period. Without these aids, the task of teaching programmers the intricacies of testing a wide variety of equipment on a complex test system would be large. With the aids and minimal indoctrination, an electronic test engineer can almost immediately write test programs. Assuming proper training an engineer can write a UUT program in compiler language in about 40% of the time in which a computer programmer (and engineer) would require using only assembly language. Assembly language permitted a reduction in UUT coding time of 90% when compared with direct machine language coding. For the DIMATE I system, each UUT required on the average 650 tests. However, the number of tests could vary from 1000 tests needed to comprehensively self-check a complex unit, to 65 tests needed for a simple device. Junior electronics personnel with a high school background were, after a few days indoctrination and training, able to code approximately 20 tests an hour in compiler language. Significantly, longer training would have been required to enable them to reach the corresponding figures of 12 tests an hour using only assembly language or 1.2 tests an hour using only machine language. The compiler language provides indirect benefits which are most helpful in the test program debugging process. (1) The user-oriented source language permits engineers who did not participate in writing the test program to be of immediate assistance during program checkout. (2) The tabular format for the source language simplifies the compiler design; consequently, little time is needed to analyze the compiler's processing when compiler errors are suspected. For complex equipment systems where available time is premium and a large number of programs must be prepared and updated on a continuing basis, the simulator becomes an integral part of a user-oriented programming system. The advantages to be derived in time savings and risk of damage more than offset the cost of developing a comprehensive simulation program. Extract: DIMATE Compiler Functions DIMATE Compiler Functions Group Function Meaning 1 CONNECT Applies stimulus to UUT DISCONNECT Disconnects a stimulus from UUT MEASURE Measures a response from UUT *MEASURE Sets up to measure a response from UUT MONITOR Continuously measures a response from UUT WAIT Specifies a time interrupt period DELAY Causes a delay prior to measuring TRIGGER Starts external time delay period and a measure PRINT Prints a message MESSAGE Defines a message PAUSE Stops for manual intervention GO TO Conditionally or unconditionally changes the program sequence HALT System reset 2 SET Sets a program indicator RESET Resets a program indicator CHECK Checks a program indicator CALISUB Calls a predefined subroutine SAVEMV Saves the last measured value NAME Creates a named location ENTER Enters a subroutine LEAVE Leaves a subroutine 3 ASSEMBLE Permits DIMATE instructions to be used directly COMPILE Permits use of compiler functions END Terminates the compilation very elegant and powerful processing system. In the case of DIMATE, the compiler with its user-oriented source language and tabular format has made it possible for non-programming-oriented test engineers to write their test programs without undergoing an intensive education process. The long range benefits become apparent when one considers for a moment the normal turnover of personnel during a five-year period. Without these aids, the task of teaching programmers the intricacies of testing a wide variety of equipment on a complex test system would be large. With the aids and minimal indoctrination, an electronic test engineer can almost immediately write test programs. Assuming proper training an engineer can write a UUT program in compiler language in about 40% of the time in which a computer programmer (and engineer) would require using only assembly language. Assembly language permitted a reduction in UUT coding time of 90% when compared with direct machine language coding. For the DIMATE I system, each UUT required on the average 650 tests. However, the number of tests could vary from 1000 tests needed to comprehensively self-check a complex unit, to 65 tests needed for a simple device. Junior electronics personnel with a high school background were, after a few days indoctrination and training, able to code approximately 20 tests an hour in compiler language. Significantly, longer training would have been required to enable them to reach the corresponding figures of 12 tests an hour using only assembly language or 1.2 tests an hour using only machine language. The compiler language provides indirect benefits which are most helpful in the test program debugging process. (1) The user-oriented source language permits engineers who did not participate in writing the test program to be of immediate assistance during program checkout. (2) The tabular format for the source language simplifies the compiler design; consequently, little time is needed to analyze the compiler's processing when compiler errors are suspected. For complex equipment systems where available time is premium and a large number of programs must be prepared and updated on a continuing basis, the simulator becomes an integral part of a user-oriented programming system. The advantages to be derived in time savings and risk of damage more than offset the cost of developing a comprehensive simulation program. Extract: compiler source language and format compiler source language and format These goals were achieved for DIMATE by developing a compiler input language consisting of engineering expressions arranged in a tabular format. Because the tabular structure provides a framework into which test parameters can be inserted, procedures are stated simply. Programming conventions are implicit in the structure of the table and the test engineer programs his requirements in a format and vocabulary which appears natural to him. The compiler vocabulary and format provide a basic language structure oriented towards the user's background and his associated task requirements without forcing him to rely upon unfamiliar terms. By not requiring specialized programming notation, engineer-to-engineer communication is facilitated and the test program in compiler source language becomes final user documentation. The compiler language functions can be considered to be divided into three groups: a basic group of test functions for the relatively untrained user and two groups of functions which require, respectively, greater programming skill or engineering knowledge to use properly. These latter groups of compiler functions act as an "overlay" and are not required to perform the basic equipment tests. The relatively unskilled user is expected to use only the basic test processes to write his test program. He needs to: 1. connect and disconnect stimulus and measuring devices 2. establish proper time delays 3. generate stimulus signals and perform measurements 4. evaluate measured values against specified limits 5. branch based upon the results of a measured comparison 5. print the measurement results. The compiler statements for these functions form the primary language used to specify DIMATE test operations. This primary language is comprehensive and permits all output stimulus signals and input measurements to be selected. Each statement defines the selected stimulus to be applied to the UUT, the selected measurement to be performed, and the DIMATE connection points. The more skilled user who is interested in programming; his test more efficiently can use internal program branching and subroutine linkages. Internal test program control is achieved by the programmer through conditional jumps based upon the state of internal program indicators. The compiler language permits both open and closed subroutines. Any section of the program can be defined by the programmer as an open subroutine while predefined computational subroutines allow arithmetic functions of either a single measurement or several measurements to be evaluated. The highly skilled user can intentionally violate the DIMATE system rules by making direct reference to each of the stimulus and measurement subsystems. This feature is considered beyond the capability of the normal user, because coding in machine language of the DIMATE computer requires skill in applying both engineering and programming techniques. The complete compiler language consists of 24 function words. Associated with these function words is information which further defines the function such as units of magnitude, statements to be printed, and connection point identification. The function words and their meanings are listed in Table I. The test specifications are keypunched on cards to form the compiler's source deck. For operational convenience, each function is completely described on one 80-column card. The standard tabular form for the card is exhibited in Fig. 2. The test number field permits the test designer to identify the compiler statement by a test number reference or a symbolic tag while the function field contains the compiler function. The remaining fields contain modifiers, arguments, or DIMATE connection point numbers3 according to the requirements of each individual function. Modifiers are the units of measurement of magnitude which further define the task of a particular function while the arguments are the values which are used Extract: The ATE system The ATE system An automatic test equipment (ATE) system consists of a configuration of programmable devices which apply stimuli to, and obtain measurements from, electronic units under test (UUT's). The testing; process is designed to determine the operational condition of the UUT. The programming task consists of translating the procedures for testing a UUT into a program which conducts the equipment test. The ideal test equipment programmer should be capable of understanding complex logical sequences of both hardware and programming processes. He should be able not only to devise the test specifications and assist in the debugging of the unit being tested, but, because the testing procedures are controlled by the test program, also must be capable of writing and checking out the computer program. In practice, few people have the necessary combination of programming and engineering training and experience. In many applications, the broad differences in technologies between test engineering and computer programming make it more efficient to train test engineers in the rudiments of programming techniques than to teach programmers the intricacies of equipment checkout. The problem, then, is one of developing a programming system which can be readily used by a non-programming-oriented test engineer to prepare and check out his test program. Such a programming system not only expedites the process of obtaining operational test programs, but reduces the overall cost of test programming. A user-oriented programming system consisting of a compiler and simulator was developed for the Depot-Installed Maintenance Automatic Test Equipment (DIMATE) system. (The compiler and simulator programs have been in operation since mid '65.) DIMATE, a computer-controlled test system, was designed and built for the U. S. Army Electronics Command, Fort Monmouth, New Jersey, to test and check out a wide variety of electronic and electrical communications equipment in real-time. The DIMATE System consists of a complex of stimuli and measuring devices. Adapter cables connect the test points on the UUT to connector panels on DIMATE. Stimuli are routed to these connector panels and the responses of the UUT presented at these connector panels are measured. The DIMATE System consists of the following six subsystems: 1. Computer/Controller Subsystem The computer/controller subsystem contains a general-purpose digital computer and a system controller. The digital computer makes logical decisions and performs computations. The controller controls the operation of the switching subsystem and the input and output devices. 2. Stimulus Subsystem The stimulus subsystem generates the basic voltage levels, sine-waves, and pulses for use in stimulating a UUT. The basic stimuli can be mixed to generate complex waveforms. 3. Measurement Subsystem The measurement subsystem measures the response from the UUT, compares the response against programmed limits and converts the measurement to digital data. The basic parameters that may be measured are voltage, frequency, time interval, power, resistance, and impedance. 4. Switching Subsystem The switching subsystem selects and routes stimuli, responses and measurements, to the programmed assemblies within the stimulus and measurement subsystems. The switching functions include: (1) Stimuli selection. (2) Routing the selected stimuli to synthesize complex stimuli. (3) Routing the synthesized stimuli to the UUT. (4) Selecting measurement functions and ranges. (5) Selecting UUT responses. (6) Routing measurement data. 5. Control and Display Subsystem The control and display subsystem provides the primary interface between the operator and the remainder of the system. This subsystem permits the operator to exercise overall control. The control and display subsystem also displays test results and measurement data to the operator. 6. Power Supply Subsystem The power supply subsystem distributes primary power and converts primary power to the required dc voltage levels for the operating assemblies. The DIMATE programming system permits engineering users with various technical skill levels to generate accurate test programs and debug them quickly. The compiler allows the test engineer to write the program directly in a language that he understands, automatically converting his specification to the operational system's digital code. The simulator permits the engineer to verify (i.e., debug) his test program prior to validation (operational checkout) on the test system with a UUT. The first DIMATE system is in operation at Tobyhanna Army Depot, Tobyhanna, Pa. in Datamation 12(10) Oct 1966 view details Equipment Check-out: DIMATE Another language to assist in check-out is incorporated as part of DIMATE (Depot Installed Maintenance Automatic Test Equipment) to assist in conducting equipment tests. The complete language can be divided into three major categories: Basic test processes (e.g., establishing proper time delays and evaluating measured values against specified limits), internal test program control and arithmetic computation (e.g., conditional jumps), and compiler processing. For example, the artificial language statement CONNECT 100 VDC J80-19 J80-20 would be written to mean connect a 100-volt DC stimulus source to test points J80-19 and J80-12. Similarly, the sentence measure 30.3 ohms with a tolerance of 12 percent between joints J1-20 and PI-20 would be written as MEASURE 30.3 OHMS +/- 12% J1-20 P1-20 Stimuli available include voltage (both AC and DC), sine waves (both AM and FM), and pulse train, Measurement capabilities include voltage, resistance, frequency, and pulse width. Stimulus statements include relay supply, signal ground, and chassis ground. Measurement statements include AC and DC voltage, frequency, and time. in Datamation 12(10) Oct 1966 view details Critique of Existing Languages Because so much of the language selection process is based on the peculiar needs of a given application, it is difficult to make general recommendations. Also criticism of existing languages become rather subjective, depending on the evaluators experience. Nevertheless, for those who have little experience and weak biases, an evaluation of the languages mentioned earlier should be helpful. The author favors free-flowing statements with a minimum of punctuations, special symbols, and mnemonics. While such features tend to make the conversion software more expensive, they reduce test programming errors and attendant costs. Since software tool design is a non-recurring cost as contrasted to the recurring costs of UUT programming, the allowable investment in software design is a function of the test programming volume. Of the languages shown in the illustrations, basic PLACE is least natural and DIMATE most readable It also requires substantially less writing to program the equivalent function in DIMATE language. The use of fields or columns to separate words in a statement rather than commas and parenthesis tends to reduce errors and simplifies spot checking of statements for completeness. Universality of a language is extremely important both from its design and application. A universal design allows the language to be applied to many ATE systems so that as one is replaced or a new one added, the test designers do not need to learn a new language. One simply extends the existing vocabulary to handle any new features of a given system. Application universality refers to how used a language is. The more organizations that use a language on more test problems, the better refined it becomes. The problems with the language tend to be worked out and it becomes a more practical language. That, after all, is what any language is for - to be used. That more than any other is the reason some languages become accepted, because they are used by many people. Because ELATE and DIMATE were not designed to be universal, they have limited applications and tend to be used less. ATLAS is being designed to be universal, but so far has not been applied to any extent. As it is used, many of its shortcomings will be uncovered and may result in its demise. In the opinion of the author, it attempts to be too universal by trying to meet the needs of all test equipment rather than only ATE. There are many characteristics of ATE that differ from conventional testing which cannot be taken advantage of if the procedure must apply equally to manual testing. Furthermore, the extensive use of mnemonics and need for punctuation symbols make it far from natural to anyone except the accomplished programmer. In attempting to develop the language so that it is easy to compile, too many of the computers needs have been favored to the neglect of the test designer. PLACE has the advantage of being both universal in design and having had substantial use. It has been used for ATE systems of different manufacturers and has been implemented on several general purpose computers, including the IBM 7090, CDC 6400, and IBM 360 series. It is believed that more test programs have been produced using PLACE than any other language. The complex input structure and awkward vocabulary can be overcome by adapting PLACE to a users vocabulary using MACRO phrase definitions. The results of one successful adaptation of PLACE using the technique is shown in the examples of SPM adapted PIACE in Figure 3. With a more elaborate MACRO phrase library, the source language could be made substantially more free-flowing and natural. Because of its universal design, adaptability to many ATE's and its proven usage, PLACE is probably the most practical ATE language available. Industry would do well to modernize PLACE or at least pursue its universal design objective rather than continue to proliferate ATE languages. in [ACM] Proceedings of the 1971 ACM Annual Conference view details in ACM Computing Reviews 13(04) April 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in ACM Computing Reviews 13(04) April 1972 view details |