ATLAS (707/atl001) |
 |
Avionics test language
Abbreviated Test Language for All Systems.
reworking of ATLAS by IEEE (same acronym, new name), formally separated into level compliances, each with own standard. Further standard created by DoD
Huge baroque language with conceptually minimalist specification
Related languages
| ATLAS | => | ATLAS | Evolution of | |
| ATLAS | => | C/ATLAS | Subset |
Samples:
References:
Abbreviated Test Language for Avionics Systems.
This language is still in the process of being defined and refined under the auspices of the ARINC Airline Electronic Engineering Committee. It is the only test language to date approved for use by a group of user organizations. On 1 June 1969, ARINC Specification 416-1 was issued defining ATLAS in substantial detail. Meanwhile, the committee continues to develop and modify ATLAS.
A full description of ATLAS is beyond the scope of this discussion, however, a few key characteristics are listed here for further discussion and evaluation:
The language is abbreviated, using mnemonic contractions of words to express many of its functions rather than spelling out the words. (For example ERRLMT is used for "error limit". )
It is functionally oriented to the test problem and ignores the characteristics of the test system in its statements.
It presumes to be equally applicable to manual test definition and to ATE.
It relies heavily on punctuation symbols to separate elements of each test statement.
It provides for full ATLAS compliance or use of subsets or "adapted" ATLAS.
It attempts to select "a level of encoding which will result in the least expensive compiler while still retaining a readable quality".
Although ATLAS has been heavily debated and defined in substantial detail, there is little evidence that it is being used to any extent by organizations preparing substantial quantities of test programs. Extract: Critique of Existing Languages
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
in ACM Computing Reviews 15(04) April 1974 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 15(04) April 1974 view details
This standard defines ATLAS, a standardized test language for expressing test specifications and test procedures. It is a test-oriented language independent of test equipment, and provides a standard abbreviated English language used in the preparation and documentation of test procedures which can be implemented either manually or with automatic or semi-automatic equipment.
ATLAS was developed originally for avionics applications under the auspices of Aeronautical Radio, Inc (ARINC) and under the direction of the Airlines Electronic Engineering Committee (AEEC), which approved the original version on October 10, 1968.
As the language expanded into non-avionic applications, the original sponsors felt that its jurisdiction should be transferred to an organization regularly engaged in the development of standards by the consensus method and with a broad technical membership active in automatic testing, in test equipment, in computer application, and in software development. Accordingly, on September 1, 1976, the AEEC authorized the transfer of ATLAS to IEEE jurisdiction and management. On September 9, 1976, the IEEE Standai^s Board approved ATLAS as an IEEE standard. On the same date, a joint IEEE/AEEC Ad Hoc ATLAS Subcommittee was authorized, consisting of the former ARINC/ATLAS Subcommittee and a selected IEEE membership. This provided the continuity for the maintenance and future evolution of ATLAS.
The first editions of IEEE Std 416-1976 and IEEE Std 416A-1976, were identical to ARINC Specification 416-13A, Volumes 11 and 1 respectively, representing a complete reformat of the ATLAS Language Specification and creation of a Formal Syntax. ARINC and industry review of the reformat effort was performed by the Ad Hoc Specification Working Group of the ARINC ATLAS Subcommittee and the IEEE Technical Group on Automated Instrumentation.
Following publication of IEEE Std 416-1976, the newly organized IEEE ATLAS Committee continued to expand and improve the language. The Specification and Formal Syntax have been maintained in parallel. Revision 14 was approved by the IEEE Standards Board on September 8, 1977, and was subsequently approved by ANSI. That revision became ANSI/IEEE Std 416-1978 and was approved by the US Department of Defense as the sole approved language for ATE use.
For ANSI/IEEE Std 416-1978, the two previous volumes were included under one cover and identified together as a single standard. Wherever reference is made to 416A this should be taken to refer to the Formal Syntax of the language.
Extract: Purpose
1. Purpose
This language specification defines the Abbreviated Test Language for All Systems (ATLAS). The term "all" was substituted for the original term "avionics" in recognition of the wider application of the language.
ATLAS is a standard abbreviated English language used in the preparation and documentation of test procedures which can be implemented either manually or with automatic or semiautomatic test equipment.
Chapters 1 ? 17 of this standard amplify the formal definition of ATLAS (Chapter 18: ATLAS Formal Definition) by providing functional description and rules applicable to ATLAS constructs over and above the syntactic definition of the language. To provide for a complete, but concise, description of each language construct a reference to the appropriate section (s) of the ATLAS Syntax together with a diagrammatic representation of the language syntax are included, where deemed appropriate, within this document. The diagrammatic representations are referred to as "syntax diagrams" and are intended to provide a guide in constructing valid ATLAS statements. Extract: ATLAS Characteristics
1.1 ATLAS Characteristics
The following are general characteristics of ATLAS.
1.1.1 Unit Under Test Orientation The language is dedicated to defining the test requirements of the Unit Under Test (UUT) with no reference to nor dependence upon the test equipment which may be used. The latter may be automatic, manual or of hybrid design.
1.1.2 Unambiguous Communication The selective use of English language terms which are compatible with the description of test requirements and a'formal structure for their use (as defined in this document) constitute an environment to ensure an unambiguous description of the requirements of a test procedure for the UUT designers, developers, users, and maintenance personnel.
1.1.3 Test Equipment Independence The specification of test requirements in terms of the UUT by ATLAS facilitates the transportability of those test specifications from implementation on one set of test equipment to another, providing that all of the test requirements can be satisfied by the test equipments.
Extract: Levels of ATLAS
1.2 Levels of ATLAS
There are three defined levels of ATLAS; Standard ATLAS, Subset ATLAS, and Adapted ATLAS.
1.2.1 Standard ATLAS
The complete language, including vocabulary, syntax, and rules, as described in this standard, ANSI/IEEE Std 416-1980, ATLAS Test Language, is defined as Standard ATLAS.
1.2.2 Subset ATLAS
A language of which every constituent construct is included within Standard ATLAS (i.e., no extensions) except that, for commercial or technical reasons, it does not include all the vocabulary or statement and syntactic options of Standard ATLAS, is defined as Subset ATLAS. It is anticipated that each Subset ATLAS would be unique, thus no specific forms of Subset ATLAS have been defined.
1.2.3 Adapted ATLAS
As specified in this document, ATLAS is a precise language used to communicate test procedures among various users. It must be
emphasized, however, that each test system user will probably modify the ATLAS procedure for his specific method of implementation. "Adapted ATLAS" is the term used to refer to the ATLAS procedure after it has been modified to suit a local application.
Adapted ATLAS, then, identifies a family of languages which conform closely to ANSI/IEEE Std 416 but which have modified vocabularies and possible syntax distortions. These languages are not intended for use with a Standard ATLAS Compiler.
The different versions of Adapted ATLAS are normally closely associated with the specific hardware employed in various test systems currently in use or being designed.
version). Extract: Chronology of ATLAS
| Chronology of the ATLAS Test Language | ||
| Rev | Date | Remarks |
| — | Oct 1968 | Approved by the Airlines Electronic Engineering Committee |
| — | 4 Feb 1969 | Approved by the Airlines Communications Administrative Council for the Member Airlines |
| 1 | 1 June 1969 | Incorporation of miscellaneous changes |
| 2 | 1 Feb 1971 | Incorporation of miscellaneous changes |
| 5 Oct 1971 | Refinement of analog equipment testing capabilities | |
| 4 | 22 Feb 1972 | Refinement of analog equipment testing capabilities |
| 5 | 22 Feb 1972 | Updated Syntax Diagrams |
| 6 | 31 Oct 1972 | Addition of digital testing capability |
| 7 | 30 Jul 1973 | Incorporation of miscellaneous changes |
| 8 | 30 Jul 1973 | Addition of digital macro capability (DO, DIGITAL) |
| 9 | 30 May 1974 | Incorporation of miscellaneous changes |
| 10 | 15 May 1975 | Addition of Decision Table capability |
| 11 | 25 Jan 1976 | Addition of Structured Programming capability |
| 12 | 23 Apr 1976 | Clarification of complex numbers and miscellaneous changes |
| 13 | 2 Aug 1976 | Addition of BURST and WAVEFORM modifiers and miscellaneous changes |
| 13A | 15 Aug 1976 | Reformat of ARINC Specification 416, including Supplements 1 through 13, to improve the quality and usefulness and to facilitate the management of the ATLAS documentation. (No language changes were intended) |
| IEEE Std 416-1976 | 1 Nov 1976 | Reprint of Revision A by IEEE. No changes within text. |
| IEEE Std 416A-1976 | 20 July 1977 | ATLAS Syntax |
| ANSI/IEEE Std 416-1978 (Rev 14) | 1 Nov 1978 | Addition of REQUIRE and other changes. |
| IEEE Std 416-1981 | July 1981 | |
in ACM Computing Reviews 15(04) April 1974 view details
in SIGPLAN Notices 13(11) Nov 1978 view details
in SIGPLAN Notices 13(11) Nov 1978 view details
in SIGPLAN Notices 13(11) Nov 1978 view details
Resources
- ATLAS logo