IEC TR 61926-1-1:1999

TECHNICAL IEC
REPORT
TR 61926-1-1
First edition
1999-10
Design automation –
Part 1-1:
Harmonization of ATLAS test languages
Automatisation de la conception –
Partie 1-1:
Harmonisation de langages d'essais ATLAS

Reference number
IEC/TR 61926-1-1:1999(E)
Numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series.
Consolidated publications
Consolidated versions of some IEC publications including amendments are

available. For example, edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the
base publication, the base publication incorporating amendment 1 and the base

publication incorporating amendments 1 and 2.

Validity of this publication
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology.
Information relating to the date of the reconfirmation of the publication is available
in the IEC catalogue.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is to be found at the following IEC sources:
• IEC web site*
• Catalogue of IEC publications
Published yearly with regular updates
(On-line catalogue)*
• IEC Bulletin
Available both at the IEC web site* and as a printed periodical
Terminology, graphical and letter symbols
For general terminology, readers are referred to IEC 60050: International
Electrotechnical Vocabulary (IEV).
For graphical symbols, and letter symbols and signs approved by the IEC for
general use, readers are referred to publications IEC 60027: Letter symbols to be
used in electrical technology, IEC 60417: Graphical symbols for use on equipment.
Index, survey and compilation of the single sheets and IEC 60617: Graphical symbols
for diagrams.
* See web site address on title page.

TECHNICAL IEC
REPORT
TR 61926-1-1
First edition
1999-10
Design automation –
Part 1-1:
Harmonization of ATLAS test languages
Automatisation de la conception –
Partie 1-1:
Harmonisation de langages d'essais ATLAS

 IEC 1999  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission 3, rue de Varembé Geneva, Switzerland
Telefax: +41 22 919 0300 e-mail: inmail@iec.ch IEC web site http://www.iec.ch
Commission Electrotechnique Internationale
PRICE CODE
X
International Electrotechnical Commission
For price, see current catalogue

– 2 – TR 61926-1-1 © IEC:1999(E)

CONTENTS
Page
FOREWORD . 3

OVERVIEW . 4

INTRODUCTION . 13

Clause
1 Scope . 14

2 Reference documents . 14
3 Definitions. 14
4 Symbols and abbreviations. 15
5 Background information and history. 15
6 Relationship between C/ATLAS and ATLAS. 16
7 Current events . 17
8 Implementations of ATLAS and C/ATLAS . 18
9 Harmonization methods. 18
10 Conclusions .22
11 Recommendations . 23
12 Benefits . 23
13 Other languages and/or implementations. 24
Annex A (informative) Comparisons of 416, 716, and 626 definitions – 1984 to 1995. 25
Bibliography . 45

TR 61926-1-1 © IEC:1999(E) – 3 –

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
DESIGN AUTOMATION –
Part 1-1: Harmonization of ATLAS test languages

FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, the IEC publishes International Standards. Their preparation is
entrusted to technical committees; any IEC National Committee interested in the subject dealt with may
participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization
for Standardization (ISO) in accordance with conditions determined by agreement between the two
organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical specifications, technical reports or guides and they are accepted by the National
Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any
divergence between the IEC Standard and the corresponding national or regional standard shall be clearly
indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this technical report may be the subject of
patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
Technical reports do not necessarily have to be reviewed until the data they provide are
considered to be no longer valid or useful by the maintenance team.
IEC 61926-1-1, which is a technical report, has been prepared by IEC technical committee 93:
Design automation.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
93/93/CDV 93/102/RVC
Full information on the voting for the approval of this technical report can be found in the report
on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 3.
This document which is purely informative is not to be regarded as an International Standard.
A bilingual version of the technical report may be issued at a later date.

– 4 – TR 61926-1-1 © IEC:1999(E)

OVERVIEW
A common standard test language has been of interest to the electronics testing community for

many years. Such a common language offers a single communications "medium" for the

description of Unit Under Test (UUT) test requirements to both humans and machines, as well

as the hope for Test Program Set (TPS) cost savings through code re-use and code sharing

(just as a single spoken language would benefit mankind in international communications, or a
single computer programming language would allow "anyone" to read/develop/maintain
1)
TM)
computer software code). The Abbreviated Test Language for All Systems (ATLAS) was
developed, and is being maintained, to provide this communications " medium".

This technical report presents the efforts taking place, as well as recommendations/
suggestions to harmonize two differing ATLAS test language specification "dialects", to enable
a common use across two user communities
The evolution of the ATLAS language leading to the interest in harmonization of the two
dominant representations of this language today, i.e. C/ATLAS 716-95 and ATLAS 626-3, took
place in a technological time and context which the reader may find helpful and interesting to
know when considering ATLAS today. The following material provides a brief overview of the
technical history of Automatic Testing, Automatic Test Equipment and the Testing Economics
which existed during the time that ATLAS was evolving. At the conclusion of this background
section, a brief history of ATLAS will be included to complete the technological picture and
provide the reader with a context for assessing the ATLAS issues being faced today.
The need for an automated means to perform testing followed closely on the heels of the
explosive growth in complexity and functionality of the units requiring test. This explosion was
driven by miniaturization. More and more capability could be packaged into a single device in
the same physical envelope using less and less power and operating at faster and faster
speeds.
By the early 1950s, it became clear that a methodology was required which would allow faster
2)
testing. The throughput of units through a manufacturer's factory was being limited by a test
bottleneck. This was due to the large number of tests required for newer units being designed
and built and the limitations of the speeds at which a factory technician could perform these
growing number of tests.
In addition to throughput problems, other testing problems were appearing when testing was
done manually, including the consistency of test. The need to perform the same tests in the
same way every time was too often found to be compromised by the mood, mental state, health
and/or interest of the test technician. Additionally, there were qualitative and economic issues

involved. The quality of work conditions under which a person is expected to quickly and
consistently perform repetitive work with increasing rapidity was coming under question and
scrutiny, as was the cost of the human test technician per unit tested.
________
1)
ATLAS is a trade mark of the Institute of Electrical and Electronics Engineers.
2)
Throughput – the number of units per unit time that can be processed.

TR 61926-1-1 © IEC:1999(E) – 5 –

A final element to this growing problem was the increasing complexity of the tests which
needed to be performed. The tests and testing process reflecting the increasing complexity of
the units to be tested became more difficult to perform and interpret. This further exacerbated

the time and cost issues noted above by imposing a training cost to enable the technician to

perform as required, plus a need for higher skilled technicians who were more costly and more

difficult to find. The problems described in respect to the factory environment were being

repeated in the field repair environment. Many companies in order to reduce time and shipping

costs established field repair and maintenance depots. However, it was not long before these

field depots were confronting very similar problems. These problems were made more difficult

by the fact that the units requiring test and repair covered a broad variety of types and

configurations. This meant that the test technician had less opportunity to become familiar with
the traits and characteristics of a single unit. In addition, the field technician was at a remote
site, not a factory. Therefore, he needed additional support documentation to compensate for
the lack of access to the design engineer available at a factory for advice and guidance. The
field technician had to be supported by a large number of expensive spares so that he could
effect the needed repair. The expense of the repair, time and spares was at the mercy of the
knowledge and diagnostic skill of the repair technician.

– 6 – TR 61926-1-1 © IEC:1999(E)

Suppliers and users of Automatic Test Equipment (ATE)

The users
On the user side there was a clear dichotomy in the use and application of ATE. The NATO

forces were driven by the cold war and the perceived need to extract from technology its

benefits in order to support their defense strategy and posture. Production rates, production

costs, field maintenance and repair of what was arguably the most sophisticated of electronics

were issues that were required to be addressed. Additionally, the ability of NATO to train and

retain qualified field test technicians was under strain as local economies improved and

increasing numbers of trained technicians left military service.
Commercially the airlines faced increasingly difficult field test and maintenance problems.
Driven by concerns over safety, a far-flung set of test and maintenance repair depots and a
very difficult avionics requiring test and maintenance, they too began to seek alternative test
maintenance and repair approaches.
Other commercial enterprises, particularly those with broad markets and widespread field
depot operations were close behind the airlines in identifying the need for a new and improved
way to test.
It is safe to say that by the late 1950s all three, i.e., NATO, airlines and large commercial
electronics developers were well on their way to developing test solutions, based upon auto-
matic testing.
The suppliers
The suppliers to the three major using communities of ATE were not the same. The suppliers
of ATE to the NATO communities were commercial suppliers of standard bench-top
instruments configured to be controlled automatically for factory testing, and the suppliers of
weapon systems for support of these systems in the field.
The suppliers of ATE to the commercial airlines in the factories were the same as those for
NATO, and the suppliers of ATE at the factory test depots were the suppliers of the avionics
units used in the aircraft.
The suppliers of ATE to other large commercial suppliers tended to be the suppliers of factory
ATE used by NATO and commercial airlines in the factory, and alternative commercial
suppliers of ATE in depots or occasionally ATE fashioned by themselves.

TR 61926-1-1 © IEC:1999(E) – 7 –

Automatic Test Equipment (ATE)

An ATE system has the general configuration shown in figure 1. This configuration is generally

applicable from the earliest configuration of ATE to current systems.

Test program
(7)
Control
(memory)
(6)
Input Routing Output
(1) (5) (2)
Stimulus (3) Measurement
(4)
UUT
(8)
IEC  1353/99
Figure 1 – General configuration of an ATE system
The eight elements of figure 1 perform as follows in any ATE system.
1 Input – the ATE input subsystem allows the ATE operator both to select the operating mode
under which the system will perform (i.e. print all test results, stop after each test, print only
failures) as well as provide the various media by which the operator can communicate with the
system, i.e. tape, Compact Disk (CD), keyboard, floppy.
2 Output – the output subsystem provides the means by which the ATE system commu-
nicates with the ATE operator. This can include visual indicators (lights), cathode ray tubes,
printers and even voice.
3)
3Stimulus – the stimulus subsystem consists of programmable devices which can provide
either power or signals to a UUT.
4 Measurement – the measurement subsystem consists of programmable devices which can

assess the parametric values of power or signals from a UUT.
5 Routing – the routing subsystem consists of switching devices which by program control
are capable of interconnecting the output stimulus devices or the input of measurement
devices to designated locations on a UUT. The routing subsystem can also route operator
inputs to designated devices and/or output information to designated devices.
________
3)
"Programmable" denotes the ability of having the functional capability of devices controlled by input
signals without human intervention.

– 8 – TR 61926-1-1 © IEC:1999(E)

6 Control – the control subsystem manages the operation of the ATE. It interprets signals

from the input subsystem and controls the system operation in accordance with these inputs.
The control system also interprets the test instructions contained within a test program and

selects the appropriate stimulus device or devices; establishes the routing configuration

required to connect the stimulus as required; sends instructions to the stimulus devices to

output the signal required; instructs the measurement device required to set up to make the

necessary measurement; interconnects the measurement device via the routing subsystem,

analyzing the resulting measurement; and selects the next test to be performed predicated

upon how the measurement result compares to predetermined limits.

7 Test program – the test program is a coded set of instructions which determines the tests

to be performed and the consequence of passing or failing the test.
8 UUT – the UUT or Unit Under Test is the device that is assessed by the ATE in conjunction
with the test program.
Evolution of ATE systems
First generation
The first generation of ATE appeared between 1955 and 1965. They were characterized by
single function stimulus devices adapted to be programmable by the ATE manufacturers.
Control of these systems was accomplished by specially designed digital devices (not general
purpose computers). These devices were typically driven by a perforated tape device.
The test system software consisted of a primitive executive program, normally supported by an
off-line assembler designed to process a very low level test language unique to the test
system.
The component technology used in these systems consisted of discrete components and
vacuum tubes. The input/output devices on these systems consisted of Nixie tubes, other lights
or small printers.
These systems were quite large, used a great deal of power and were typically designed for
test of a single, specific UUT.
Second generation
The second generation of ATE was found between 1962 and 1972. These ATE systems were

characterized by the use of general purpose bench top instruments for stimulus and
measurement adapted to be programmable by the instrument manufacturers. These
instruments tended to have all their normal manual controls on their front panels even though
they were automatically controlled.
Control of the second generation of ATE was accomplished by a general purpose computer
having many of the characteristics of today’s desktop computers although much larger and
more limited in performance, speed and memory size.
The system software was more sophisticated than that found in first generation systems. This
sophistication was made possible by the general purpose computer. The software was
supported by an off-line compilation system and utilized some type of higher level (human
readable) language specially designed by the ATE developer and proprietary to his system.

TR 61926-1-1 © IEC:1999(E) – 9 –

The component technology used in second generation systems consisted of discrete
components and some conductor elements. These systems were still quite large but occupied
a much smaller space than equivalent first generation systems. The second generation

systems also utilized less power. For certain field applications they could be readily

transported, when housed in a small van.

The man-machine interface for second generation systems normally was an operator switch

control panel and/or keyboard. Output devices included a printer, Cathode Ray Tube (CRT)

and/or other message displays.

The applicability of second generation systems expanded to include classes or families of UUT

of a given type and parametric range. Examples could include Power Supplies, AM or FM
transceivers or testers of Analog, Digital or Hybrid Printed Circuit boards.
Third generation ATE [6]
Between 1970 and 1980 an ATE class was introduced which relied on the use of more capable
computer systems and sophisticated software to replace many of the stimulus and
measurement building blocks that had characterized second generation ATE.
The third generation ATE had unique attributes: they utilized digital to analog converters to
create signals synthesizing; the signal characteristics were predicated upon the mathematical
definition of that signal. Fundamentally, a signal could be synthesized and shaped to form any
variety of Alternating Current (AC) signals. Conversely any complex signal could be broken
down by a waveform analyzer and its characteristics parameters analyzed.
The advertised benefits of the third generation system were smaller size, since it required less
building blocks, and broad flexibility, since any and all test requirements were relegated to a
software problem.
The third generation system architecture ushered in the use of sophisticated solid state
technology, as well as very sophisticated routing systems for the interconnection of signals.
Fourth generation ATE
The fourth generation of ATE began in the late 1980s and is still seen today. The significant
changes introduced by fourth generation ATE was the increasing sophistication of the
computer systems, the enormous increase in memory availability and the extensive use of
distributed micro-processing, hybrid arrays, and other technological innovations.

Fourth generation systems utilized an array of smart instrumentation. These stimulus
measurement and switching devices took a great deal of the burden away from the central
computer and executive software. They were capable of scale selection, number conversion,
loss analysis and asyn-chronous processing and analysis of test results, resulting in faster and
more accurate testing.
Current ATE [7]
The ATE changes today are being driven by a significant expansion of processing capability and by
recognition of instrument manufacturers that programmable instruments in ATE systems required
their own design attention. The use of instruments on a card unencumbered by the bulk of the
bench top instruments as well as use of the asynchronous processing capabilities of these
instruments on a card is increasingly common. The range, repertoire and capabilities of instruments
on a card are increasingly expanding. Software systems within ATE today are capable of far more
than controlling the test process. They archive data, assess trends, provide sophisticated guidance
and instruction to operators and assist in management and queuing of UUTs.

– 10 – TR 61926-1-1 © IEC:1999(E)

Evolution of ATE software
Executive software
The software which runs and manages an ATE operation is generally called the systems

executive software. The systems executive software controls the manner in which tests are

processed, the selection of tests, the selection of resources to perform the tests, the evaluation

of test results and the disposition of the information obtained from performing a test. These

tasks are introspective to the testing operation itself. In the early days of ATE, the test

executive was only capable of executing a single instruction. Today, this software is capable of

compilation, interpretation and selection of the optimum execution of test program software.
Over time the role of the executive software has grown to keep pace with the power of the
computers which process this software and the capacity of the memory that was available to
store and manipulate data. Today’s executive software is no longer introspective, but rather
encompasses the environment in which the testing takes place, and is capable of multi-
processing, i.e. running tasks simultaneously in foreground and background modes or, for that
matter, under a hierarchy of priorities.
The executive software is also capable of monitoring the health and well-being of the test
system and its resources; dynamically reallocating resources as necessary to perform testing,
when and if a system resource fails; maintaining a diary of test processes and test results
obtained over a unit time; automatically processing test reports; tracking histories of test
results on similar UUTs; tracking spares inventories for repair; and a host of functions
designed to integrate the test process into the total life cycle support process.
Application software
The software containing the instructions for testing a UUT connected to the ATE is denoted
application software. Normally, outside of factory production lines, ATEs in use today will be
required to support many UUTs of similar type and differing configuration or of similar class
and differing type, i.e. analog, digital, video, radio frequency (RF), power supply, etc. For field
ATEs, the variety of types and configurations can be very broad.
It is not unusual for the cost of application software to exceed the cost of the ATE itself.
Evolution of application software
The application software written for early ATE reflected the lack of the systems and controllers
upon which they were run. The test languages used were digital codes, octal codes and a
variety of very specific ordered codes often selected from a code menu.

It is worthwhile to mention one other unique aspect of the ATLAS language. It is a virtual
language. This means that it is divorced from the test system it is to be run on. The rules of
ATLAS require that no reference to the ultimate test system upon which the ATLAS test
language is to be executed be included in the program or procedure itself. Thus, an ATLAS
program may have a statement such as "APPLY, 50VDC, J-1, J-2 $". It will never have a
statement such as "APPLY, BB*55_ _ _$" or "APPLY S*1_ _ _ " referring to a specific resource
of a specific test system. This is not to imply that the test engineer who writes the test program
or procedure is unaware of the target test system. On the contrary, the test methods and test
strategy utilized by the test engineer are guided by the parametric envelope provided by the
test system and the specific accuracy and capabilities of the resource suite. The concept of
using virtual references is predicated upon the hope and expectation that virtual reference as
opposed to explicit resource references will facilitate rehostability of test programs and
procedures across differing test platforms.

TR 61926-1-1 © IEC:1999(E) – 11 –

ATLAS has enjoyed a variety of applications besides its use as a language for test procedures
and test programs. It has been used as a basis for writing test specifications and test
requirements. In addition, ATLAS has been the basis for test-related specifications such as the

IEEE’s "Test Equipment Description Language TEDL" (IEEE Std. 993).

Over time, the sophistication of application software improved with the sophistication of the

processors used. For a time, a variety of general purpose programming languages were used

to design the tests for UUTs. These included FORTRAN, BASIC and C.

The application software used for the ATEs tended each to be unique to the manufacturer of

the ATE. Each manufacturer used a differing form, format and language for their own ATE.

Often differing ATEs built by the same manufacturer used differing languages.
In the 1960s, both the airlines and defense communities who were major users of automatic
test equipment recognized the drawback of diverse languages for each ATE they used. The
language differences made them difficult for the user’s personnel to learn and understand. This
problem was exacerbated when a variety of systems and hence languages were in use. In
addition, when the user of an automatic test system desired to add new UUTs to the systems
work load, the time and cost to write the program was higher because of the burden of the
language. Further, the change of personnel resulting when the designer of a test program
using an esoteric language changed jobs, made it difficult for a new person to pick up and
maintain the test program that had been written.
At another level, both the airlines and defense communities recognized that the development of
a test program for an ATE began with a test procedure by an engineer familiar with the UUT
which was then converted into the language of the ATE. They reasoned that it would be of
great benefit if both test procedures as well as test programs were written in an unambiguous,
human readable form, using explicit testing terminology which only a test engineer could readily
understand. This musing formed the genesis for the development of the ATLAS language
which will be discussed next.
It should be noted that commercial ATE system suppliers, in the factory, rejected the concept
of a common or standardized test language and do so today. The thinking of these vendors
was a combination of belief that their unique and proprietary test languages were superior to
other test languages, and an understanding that a competitive advantage was possible if
customers for their ATE systems could not easily switch to an alternative ATE to support
existing UUTs with their attendant test programs once a significant back log had been built up.
Evolution of ATLAS
The quest for a standard testing language began in the 1960s. Aeronautical Radio Incorporated
(ARINC) started the development of a standard testing language in response to the needs of
commercial airlines. (The language itself was purported to be conceived by Tom Ellison of
United Airlines). The commercial airlines had a need to test and repair similar or identical
avionics systems on their aircraft. They desired a means by which they could exchange test
procedures they had developed in a standardized and unambiguous way, thereby precluding
the need for each airline to redevelop these procedures.
The name of the language developed under the auspices of ARINC was the Abbreviated Test
Language for Avionics Systems or ATLAS. The development of ATLAS was undertaken
through the cooperative and supporting efforts of a large number of commercial companies
interested in avionics test and support. These companies provided skilled engineering
personnel familiar with the maintenance and support of avionics systems who met together and
worked over time to define and develop ATLAS. Over time, the recognition of the need and
benefit of a standardized testing language grew beyond the bounds of the commercial airlines.

– 12 – TR 61926-1-1 © IEC:1999(E)

The United States Army, Navy, Air Force and NATO services became increasingly active in the

ATLAS language development efforts. Commercial companies working with these agencies as

part of the defense industry also recognized the potential benefit of ATLAS for support of

avionics systems. During this period, participation at ATLAS meetings swelled and became an

increasingly difficult administrative burden for ARINC.

In 1976, administrative control and responsibility for ATLAS was passed from ARINC to the

IEEE. At this time, the name of the language was changed to reflect the broader field of

application. ATLAS became the Abbreviated Test Language for All Systems.

Within the IEEE, control of ATLAS was vested in an ad hoc committee which became Standard

Coordinating Committee 20 (SCC20). However, from its beginnings under ARINC to the current
time the group has been known as the ATLAS committee. This continues despite the fact that
the interests of SCC20 have broadened to include other test-related standards.
The first publication of the ATLAS language standard took place in 1968 and was entitled
ARINC Specification 416-1. Subsequent versions were published by ARINC when sufficient
changes, upgrades, or enhancements had been processed into the language to represent
significant improvement to the previously published version.
By 1976, ARINC Specification 416-13A, which was the fourteenth published version of ATLAS
had been released. In 1976, IEEE Std. 416-1976 was also published. This was the first ATLAS
published under the auspices of the IEEE and represented the ARINC Specification 416-13A
ATLAS in IEEE format. Subsequent publications of 416 ATLAS took place through 1988. These
publications represented the evolution of ATLAS from version 13A to 33.
By the time version 33 of ATLAS was published the language had grown very large. This
growth reflected the sensitivity of the developers to the need for upward compatibility between
versions. However, there was increasing concern and pressure to reduce the maintenance
burden represented by 416 ATLAS.
In May of 1985, the IEEE published IEEE Std. 716-1985 (C/ATLAS) which represented a
common subset of the 416 ATLAS. During the same year ARINC published an ATLAS subset
titled ARINC Specification 626-1985. Unfortunately the 716 standard and the 626 specification
were not compatible nor were they true subsets of 416 ATLAS. The IEEE ceased to publish
416 ATLAS, and formally withdrew it in 1993. IEEE C/ATLAS has been published in an updated
form every three or four years since the initial publication. This is in accordance with IEEE
requirements for a revision/affirmation every five years. ARINC 626 ATLAS has followed a
similar publication schedule.
In 1984 the IEEE also published standard 771. This standard is a guide to the use of the
ATLAS language.
Recently contacts have been made between ARINC, the sponsor and maintainer of ATLAS
Specification 626, and members of a technical team associated with maintenance of C/ATLAS
Std. 716-95, via the IEEE SCC20 and the use of ATLAS within the NATO community. The
purpose of these contacts was to discuss the possibility of coordination and harmonization
between the two communities in a variety of potential areas of automatic testing among these
areas of ATLAS. The following paper will discuss explicit steps to achieve and subsequently
maintain harmonization between these two dialects of ATLAS which represent the largest
utilization of the language.
TR 61926-1-1 © IEC:1999(E) – 13 –

INTRODUCTION
Commercial airline manufacturers and carriers, United States Department of Defense (DoD)

and DoD contractors, United Kingdom Ministry of Defence (MoD) and MoD contractors, as well

as other NATO member countries MoDs and contractors each use implementations of a test

language standard called ATLAS. The ATLAS language standard specification used by the

commercial airlines is maintained and published by ARINC. The Common ATLAS (C/ATLAS)
standard specification used by the defense industries is maintained and published by the IEEE
on behalf of the American National Standards Institute (ANSI).

The ATLAS language specification maintained by ARINC and the C/ATLAS language standard
maintained by the IEEE, initially started from a common base line, which over time, has seen
the two standards diverge (see figure 2) with respect to language syntax and semantics (e.g.
similar to having two dialects of the English language). The International Electrotechnical
Commission (IEC) plans to publish soon the IEEE Std. 716-1995 C/ATLAS as IEC standard
61926 – ATLAS. This technical paper is the response to the IEC request that an effort be
undertaken to determine how the two diverged dialects of the ATLAS definition could best be
brought back into harmonization. This harmonization would allow for a common use of the
ATLAS language across both the commercial airline and defense communities. This technical
report presents the result of the efforts performed by the authors to first compare and contrast
the two ATLAS dialects and second their conclusions and recommendations in respect to
achieving harmonization. It is additionally hoped that the efforts performed can be used to point
the way towards achieving harmonization between ATLAS implementations, or other test
languages and thus facilitate TPS code sharing and TPS code re-use in solving test problems.
Change
proposals
ARINC Specification. 626
(ATLAS)
IEEE Std. 416
Converge
(ATLAS™)
or
- Note -
diverge ?
IEEE Std. 716
(C/ATLAS)
Change
Note : 416 ATLAS™ is
proposals
no longer a maintained
Std.
IEC  1354/99
Figure 2 – ATLAS and C/ATLAS evolution

– 14 – TR 61926-1-1 © IEC:1999(E)

DESIGN AUTOMATION –
Part 1-1: Harmonization of ATLAS test languages

1 Scope
This technical report is applicable to the ATLAS language, the purpose of which is to define a

high order language used for the writing of test programs for UUTs, so that these programs can

operate on various makes and models of ATE / Automatic Test Systems (ATS).
There are at present two published language definitions of the ATLAS language; this technical
report will address the differences between these and provide recommended harmonization
and/or convergence of the two standard definitions.
The basis for this technical report are chapters/clauses 1 through 17 of the published IEEE
Std. 716-1995 (C/ATLAS) and ARINC Specification 626-3 (ATLAS) publications. The IEEE
published IEEE Std. 716-95 in March of 1995, while ARINC published ARINC Specification
626-3 in January of 1995.
2 Reference documents
4)
ARINC Specification 626-3, Standard ATLAS language for Modular Test

ARINC Specification 627, Programmers Guide for SMART Systems using ARINC 626 ATLAS
5)
IEEE Standard 716-1995, Common Abbreviated Test Language for All Systems (C/ATLAS)
6)
IEEE Standard 771-1990, Guide for the use of ATLAS
7)
IEEE Standard 993-1997, Test Equipment Description Language (TEDL)
3 Definitions
For definitions related to the use of C/ATLAS, see IEEE Std. 771; for definitions related to the
use of ATLAS, see ARINC Specification 627.
For the purpose of this technical report, the following definitions apply.

3.1
ATLAS
the Standard ATLAS for Modular Test as defined in ARINC Specification 626-3
3.2
C/ATLAS
the Common Abbreviated Test Language for All Systems as defined in IEEE Std. 716-1995
________
4)
Currently being revised – see current IEEE and ARINC Working Groups for further information.
5)
Copyright IEEE Standards, Piscataway, NJ.
6)
Copyright IEEE Standards, Piscataway, NJ.
7)
Copyright IEEE Standards, Piscataway, NJ.

TR 61926-1-1 © IEC:1999(E) – 15 –

4 Symbols and abbreviations
ABBET A Broad Based Environment for Test

AMC Airlines Maintenance Conference

ANSI American National Standards Institute

ARINC Aeronautical Radio Incorporated

ATE Automatic Test Equipment
ATLAS Abbreviated Test Language for All Systems

ATLAS-2000 Abbreviated Test Language for All Systems in the year 2000

ATS Automatic Test System (i.e. ATE and TPS)
C/ATLAS Common Abbreviated Test Language for All Systems
CD Compact Disk
CRT Cathode Ray Tube
DoD Department of Defense
GPS Global Positioning System
IEEE Institute of Electrical and Electronics Engineers
IEC International Electrotechnical Commission
MoD Ministry of Defence
NATO North Atlantic Treaty Organization
RF Radio Frequency
Standards Coordinating Committee 20
SCC20
TPS Test Program Set
TEDL Test Equipment Description Language
UUT Unit Under Test
5 Background information and history
The comparisons between C/ATLAS (revisions published in 1985, 1989, and 1995) and ATLAS
originated at the request of the US DoD and NATO, where there were questions about
migrating ATE programs from utilizing/implementing one version of C/ATLAS to a later version.
This original comparison is contained in annex B.
The basis of the comparison was to evaluate the specification chapter by chapter (for the purpose of
this technical report, chapters and clauses are interchangeable terms). The chapters that were

compared were 1 through 17. (Formal Syntax – chapter 18 – was not included in the comparisons,
but was compared to "validate" the chapter comparisons) Each chapter was "evaluated", to
determine the impact of writing a test procedure or program to one or the other of the two
specification versions."
Preliminary results and recommendations of the comparison and contrasting of C/ATLAS and
ATLAS have previously been published and presented at AUTOTESTCON ‘96[1], published in ®
8)
PLANE TALK [2], and presented to IEC TC 93 WG 7[3].
The results of the comparison between IEEE Std. 716-1995 (C/ATLAS) and ARINC
Specification 626-3 (ATLAS) are contained in clauses 6 through 9.
________
8)
PLANE TALK is a registered trademark of Aeronautical Radio Incorporated.

– 16 – TR 61926-1-1 © IEC:1999(E)

6 Relationship between C/ATLAS and ATLAS

The following relationship exists between C/ATLAS and ATLAS (see figure 3).

a) Size – C/ATLAS is larger than ATLAS, due primarily to the fact that defense industry

applications cover a broader scope of test requirements than those that are required to

support commercial airlines.
There are 609 language elements in C/ATLAS and 507 language elements in ATLAS. Thus,

C/ATLAS is approximately 20 % larger than ATLAS.

b) Language element differences – There are 141 language elements in C/ATLAS that are

not included in ATLAS. There are 39 language elements in ATLAS that are not included in
C/ATLAS.
The reasons are explained as follows:
– first, initially C/ATLAS and ATLAS developed incompatible subsets of the IEEE Std. 416

ATLAS syntax, and these differences have been carried forward;
– second, each has incorporated change proposals to each respective standard. Because
these have not necessarily been incorporated the same way (or at all) in the other,
further differences have occurred.
What this means is that 77 % of the 609 language elements in C/ATLAS are identical to
those in ATLAS while 92 % of the total language elements in ATLAS are identical to
those in C/ATLAS. Both language dialects together are 86 % identical with respect to
language element differences.
c) Incompatibilities – Beyond the language element differences noted in item b) above, there
are 13 incompatibilities between C/ATLAS and ATLAS.
For the purpose of this technical report, an incompatibility is defined as a rule, operation or
application of a programming/testing function, implemented or interpreted differently between
the two language dialects.
Of the 13 incompatibilities identified, only four will present problems in regard to achieving
compatibility between the two dialects. (A problem in this case represents a cost or additional
technical effort in achieving compatibility / harmonization between a test program written in one
dialect, being used on an ATE designed around the other dialect.)
The requirements for correction of the four problem incompatibilities, as well as the nine
simpler incompatibilities, and the language differences are presented
...