ATLAS 2000 by rCWMoI

VIEWS: 0 PAGES: 31

									                                 ATLAS 2000

                 INTRODUCTORY

                                            GUIDE

                                        13 February 1997

                                                       Rev B

                                                  Log # ???




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            1
                                           ATLAS 2000
                                     INTRODUCTORY GUIDE

   This Guide has been developed to introduce the reader to concepts and
approaches upon which ATLAS 2000 is to be built.

    ATLAS 2000 is the name given to the newly designed ATLAS language
whose planned publication date is the year 2000. This newly designed language
will be predicated upon the proven test language foundation and experience
gained over the 30 years that ATLAS has been in existence. However ATLAS
2000 will incorporate the capabilities and technical developments in computer
language design, telecommunication and computer sciences to place the proven
ATLAS capabilities and advantages in a designed environment and architecture
which will eliminate or mitigate many of the problems ATLAS users have
contended with in the past. It will introduce a level of flexibility and capability
which had heretofore not been possible.

     Appendix I to this document provides a background and history of ATLAS
for these readers who are interested.

   Additional detail beyond this Introductory Guide in respect to ATLAS 2000
may be obtained from reading the ATLAS 2000 Requirements Document IEEE
SCC20 716 Subcommittee Log #716-067, or the ATLAS 2000 Functional
Specification IEEE ATLAS SCC20 716 Subcommittee Log #716-072-01 or the
ATLAS Architecture Document IEEE ATLAS SCC20 716 subcommittee #716-102.

      The ATLAS language today is criticized for the following:

          a)   The language is considered volatile, changing dramatically with each
          publication of the standard.

           The maintainers of the ATLAS language admit that the language has
          changed dramatically. However these changes reflect the dramatic
          changes in the technology which must be tested and the current structure
          of the ATLAS Standard.

          b)      The language is considered verbose.

           The users and maintainers of ATLAS generally point out that the
          verbosity of the language is due to its high level attributes, meaning it’s
          ability to be read and understood as English statements. It is also due to
          the need for unambiguity wherein a test set up must be subject to
          unequivocal interpretation by both man and machine.

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            2
          c)  The language is considered large and has numbers of key words
          which dwarf other standard languages.

            The large number of key words in the language are driven by the
          technological characteristics of the test community which the language
          supports. The ATLAS language strives to provide to each test community
          the technical terms with which they are familiar and which are common to
          their technology.

          d)      The language size and volatility represent a maintenance burden.

            In order to achieve upwards compatibility between prior and new
          versions of ATLAS the burden of carrying forward all of the prior
          languages elements is required to ensure that test procedures and/or
          programs written using the prior standard will still be executable when
          processed with programs which reflect the new release of the standard. In
          addition there was no viable way to subset the standard for any specific
          application.

          e)   The ATLAS language statements are becoming increasingly complex
          and unreadable.

            The introduction of computer related programming elements into the
          test process inherently introduces the reader to complex and esoteric
          references which go beyond test terminology. In effect the language has
          traded clarity for test processing efficiency.

          f)   The time required to approve and publish changes to the ATLAS
          standard is excessive.

            The consensus process demanded for an international standard is
          inherently long.

It is the intention and challenge of ATLAS 2000 to address the current criticisms
and problems which confront the language. It is felt by the ATLAS 2000
developers that expanded knowledge and experience, as well as technological
improvements can provide the tools necessary to effect a significant
improvement to ATLAS.

ATLAS 2000



This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            3
    Previous publications of ATLAS strived to include within their domain
explicit standard solutions to each and every test problem against which the
language to be brought to bear. The rapid pace of technology and the demand
for technical and cost control has brought the maintainers of ATLAS to the
conclusion that a new and dramatically different approach in respect to the
ATLAS language standard is required to ensure the continued success of the
language.

ATLAS 2000 Language Structure

     The approach being taken by ATLAS 2000 is to provide a broad but basic test
language foundation plus capabilities to apply this foundation to support the
testing needs of any technological specialty. The foundation of ATLAS 2000 is the
Nucleus and Primitives as shown in Figure 1. Upon this foundation one is able
to build models and then Test Application Frameworks that can be used as direct
syntax elements in ATLAS statements. These elements which are built from the
ATLAS 2000 Nucleus and Primitives are reusable components which can be used
to define increasingly complex language elements. This standard language
design approach will give the language consistency and a solid test related basis
but not constrain the users of the language from extending, modeling and
producing new test language elements and structures which are needed for test
within their specialized communities. This structure provides standardization
without burdening ATLAS language users outside a given technological
community or specialty with esoteric technical demands of that specialty within
the standard itself.
These application frameworks would differ from the normative annexes only to
the extent that they would be the responsibility of the developer and would not
be published in the ATLAS 2000 standard or maintained by the IEEE ATLAS
subcommittee. An application framework developed by any user constituency
could be proposed for inclusion into the ATLAS 2000 standard. Upon successful
processing of that proposal and inclusion into the standard that the application
framework then become a normative annex to ATLAS 2000.




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            4
      Figure 1 below illustrates the structure of ATLAS 2000.




                                                          IAL
                                                      MERC
                                                   COM     CAL
                                                       MEDI
                                                                ARY
                                                           MILIT
                                                                            R     Y
                                                                         USE MUNIT
                                                                          COM


                                                            TAF


                                                           IV   ES
                                                       MIT
                                                    PRI

                                                           S
                                                    LEU
                                                 NUC




                                     Figure 1.
            ATLAS 2000 Architecture and Associated Application Domains




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            5
                                          The ATLAS 2000 Nucleus

    The nucleus represents the basis upon which ATLAS 2000 is built. The
nucleus contains the rules for the languages use. The language syntax or the
grammatical rules for the construction of an ATLAS 2000 statement as well as the
ATLAS 2000 semantics are defined within the nucleus. The semantics provide
the connotative meaning of words or groups of words within an ATLAS 2000
statement or set of statements which form a logical group. Thus the semantics
are the link to one of the languages’ most valuable attributes, i.e., providing good
practice and industry accepted meaning to test terminology and usage.

     It should be made clear at this point, that the ATLAS 2000 Syntax and
Semantics are to be predicated on the Syntax and Semantics of the ATLAS which
has preceded ATLAS 2000. The experience, lessons learned and requirements
concerning test will be the solid bedrock upon which ATLAS 2000 will be built.
Initially ATLAS 716 and 626 will be the basis for the ATLAS 2000 Syntax and
Semantics.

     Elements within the nucleus will include rules necessary to define signal
attributes, signal behavior and timing.       The nucleus will also contain
mathematical     elements,     input/output   capabilities   and    information
representation rules as well as control elements for information flow. The
nucleus provides the language data processing elements which will serve to
provide effective access to the computer capabilities provided by automatic and
semi-automatic test systems.

    Among the remaining elements of the nucleus are the rules which will allow
ATLAS 2000 to achieve a level of flexibility and extensibility heretofore not
possible. The nucleus will provide rules for formation of complex testing
relationships predicated upon existing signals, test actions and rules.

    The nucleus rules will also provide language extensibility for converting
simple test models into complex test models building upon the primitives or to
build complex test models using the simple test models and primitives. This
process serves to create application frameworks which define the testing needs
for any given test community or technology, e.g., automotive test or electro-
optical test.

    The nucleus will contain language Reserved Words which will consist of
those elements that enable definition, structuring, and organization within a test
process. This will include things such as BEGIN and END MODULE, BEGIN
and END PROCEDURE, REQUIRE, etc. The nucleus will also contain rules that
link the nucleus, primitives and application frameworks.

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            6
The ATLAS 2000 Primitives

    The ATLAS 2000 primitives are the elements which represent the simplest or
lowest common denominator elements for describing a signal and/or its
characteristics behavior or a test action. The use of the ATLAS 2000 primitives
are defined by the syntax, semantics and rules contained within the nucleus.
Typically a language element in ATLAS 2000 will be a primitive if it cannot be
further decomposed into a combination of lower language elements. However
some primitives will be fundamental test elements for which industry consensus
has been derived and for which standardization is necessary and for which
further decomposition would be contrary to consistent use of ATLAS 2000. The
ATLAS 2000 Primitive Set includes Reserved Words for Nouns, Noun Modifiers,
Signal Verbs, Verb Modifiers, Signal Operators and their function and
definitions. Primitives are technology driven and are based on a class of
functions and signal types. The primitives establish the formal test and signal
definitions based on behaviors. The behaviors, in turn, can be validated to the
National Institute of Standards or other recognized standards organizations.

    The primitives for ATLAS 2000 will be initially predicated upon the
language elements found in 716 and 626 ATLAS.

The ATLAS 2000 Basic Components

    Many syntax elements while decomposable into primitives or simpler test
elements are, from an industry user perspective, the lowest practical
representation of a test element. These syntax elements are basic ATLAS 2000
components. They are used in syntax equation like primitives and can be used to
model more complex test functions.         Basic component models can be
encapsulated into models and then form the basic foundation of a normative
annex. They are capable of being used across a broad scope of test disciplines.


The ATLAS 2000 Normative Annex

     Over time technical disciplines have a tendency to develop their own
terminology, to name or describe signals and/or characteristic performance
attributes pertaining to the technology with which they are involved. The testing
required to support these disciplines, of course, reflects these special terms. It
has been one of the fundamental precepts of ATLAS that the ATLAS language
contain the same terminology which is native to the discipline that is being
tested. This allows ATLAS users the capability of dealing with test statements
which are meaningful and familiar to the practitioners in that technology.

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            7
    An ATLAS 2000 Application Framework is a collection of signals, procedures
and relationships which reflects the names, terms, signals and interactions which
are common to and necessary for support of a specific discipline. When an
Application Framework of this type is published as part of the ATLAS 2000
Standard, it is called a Normative Annex. Currently IEEE Standard 771 Guide to
the Use of the ATLAS Specification contains a number of annexes which could be
considered as potential normative annexes to ATLAS 2000. These include Annex
A, ATLAS in Analog Testing; Annex B, ATLAS in Digital Testing; Annex C,
ATLAS in Air Navigation Testing; Annex D, Timing and Synchronization in
ATLAS; Annex E, ATLAS in Data Bus Testing, etc.

    Each of the annexes noted above contain a variety of names and terms
peculiar to a discipline. Each of these names and terms in turn are comprised of
signals, some of which are quite complex that interact with each other in very
specific ways. For example, within the Air Navigation Annex there are seven
different systems presented and each of these systems has its own set of signal
names and specially named relationships between signals.

    The ATLAS 2000 standard strives to bridge the gap between being as helpful
as possible in providing a standardized test language and not precluding or
excluding technical communication which have unique and specialized needs.
Consequently the normative annexes which shall be included in the ATLAS 2000
standard shall represent only those test disciplines for which there is a
uniformity of view and proven baseline reflecting commonly agreed to best
practices across a technical community. In this way the general risk of placing a
technical community in the position of being non-compliant with the ATLAS
2000 standard is precluded. A community may use a test application framework
which is unique to their requirements and for which there is no consensus as
regards common good practice. Such an application framework would not be
included in the standard as a Normative Annex.

   In summary, an ATLAS 2000 Normative Framework is a Test Application
Framework published in the ATLAS 2000 standard which reflects consensus
good test practice, terminology and signal relationships across a technical
community.

ATLAS 2000 Structures and New Features

ATLAS 2000 expands upon the capabilities of existing ATLAS and supports the
reuse of developed ATLAS elements at many levels of complexity. The
expansion and flexibility is accomplished through the usage of models to
formally specify and rigorously define more complex syntax elements. Reuse is

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            8
engendered by extending the use of module structures and by designing models
that can make use of previously defined models as constituent components.




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                            9
                                                                                 ATLAS 2000 STRUCTURE
                                                                                       FEATURES
                                                                                        Figure 2



               *           MODULE                                                          Test Program                               Include MODULE ‘RF SET’
                                                                                                                                      Define PROCEDURE
                                                               MODULE                         MODULES
                                                                                                                                      .
                                                                                                                                      .
                            Models                                                                                                    End
                                                                                           PROCEDURES
                                                                                                                                        Apply DC Voltage
                                                               Procedures                   STATEMENTS                                  Measure Voltage, AC Signal
                                                                                                                                        Perform
                                                                                                                                        Apply Q Doppler
                                                                                                                                        Measure Bearings, TACANZ
                                          PROCEDURE
     Define Verb ‘APPLYQ’
      Setup
       .
       .                                          Statements
     End
                                                                             STATEMENT ELEMENTS
    Define Noun “TACANZ’                          Verb                   Noun                Modifier
      .
      .                                                                                                          BEARING
                                             APPLYQ                              TACANZ
      .
    End              *                   MODELS                                    MODELS                                  MODELS

                                                                                                                                                                       interfaces


                                     NORM                Simple Verb              NORM                    Simple signals
                                                          Primitives                                         Complex                                               * New Features
                                                                                                            Composite


                                              *                                          PRIMITIVES

    NORMATIVE MODEL                                                                          NUCLEUS
      COMPONENTS
This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or reproduction without the consent of the IEEE is prohibited.
                                                                                                                                                                                             10
Figure 2 shows that the structure of an ATLAS 2000 test program has not
changed. It can still contain modules, procedures, declarations in a preamble
and its procedural section can contain the executable test statements as APPLY,
MEASURE and PERFORM. While current ATLAS uses the modules to contain
ATLAS or non-ATLAS procedures, ATLAS 2000 extends the use of modules to
also contain models of syntax elements and statement templates as well as
procedures. ATLAS 2000 provides for a standard module information interface
to facilitate the role of the module in the reuse of proven procedures, models and
template statements. ATLAS Procedures remain the same in its use to establish a
sequence of ATLAS test statements to accomplish a test method in a standard
and consistent manner. These familiar structures are shown at the top portion of
Figure 2. Shown along with the familiar module of ATLAS procedures is a
Module containing models of signal functions.

ATLAS 2000 expands the capabilities of current ATLAS at the statement level
and in the use of models to specify current keywords for the various syntax
elements (nouns, verbs, modifiers...). The ATLAS 2000 test statement is viewed
as a specifyable sequence of actions as opposed to a fixed action or proscribed set
of primitive verbs built from primitives. Also a complex noun as TACANZ can
be modeled using a model structure statements with primitives and component
nouns, modifiers and operations. These modeled syntax elements are used in
ATLAS 2000 test statements as keywords are used in current ATLAS statement.

ATLAS 2000 Component Reusability and Extensibility

    One of the benefits of ATLAS 2000 is component reusability. This attribute
allows a language component to have a useful life exceeding the application for
which it was created.




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           11
    Figure 3 illustrates the manner in which ATLAS 2000 is anticipated to evolve
over time.




                         Normative Annexes                                                                   D
                                                                                          A
                                                                   N
                                                                                                         B
                         Primitives
                                                                                          C
                         Nucleus



                                                                             Time




                                                              Figure 3
                                                      ATLAS Evolution Over Time




The far left of Figure 3 represents ATLAS 2000 at any point in time. At this point
a number of Normative Annexes, as discussed previously are included within
the ATLAS Standard. These Application Frameworks may not be directly
useable for a new application, but may establish a base from which more
specialized application elements can be created to fully satify the application
requirement.

    A representative application component based upon one of the Normative
Frameworks is shown as the Box A or D in Figure 3. This component had been
developed in response to a specific testing need using the Normative Annex as a
starting point and utilizing the ATLAS 2000 Nucleus and Primitives. It should
be noted that there is no direct 716 subcommittee control of A or D. It is utilized
and maintained by the group responsible for it’s development, and may be
further evolved as application B or D by a User community.



This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           12
       Some of the ways in which A can be re-used and the language applications
  ability extended is shown in Figure 4.



                                                                      D
             Uncontrolled (by 716) Application
             Frameworks
                                                              A                    B         ATLAS Application Boundary
Layer
             Normative Annex

                                                                      C                      716 Control
               Primitives

                                                                               C
               Nucleus




                                                    Figure 4
                                            Extension of Applications


       Three cases are shown in Figure 4. In the first case Component A becomes
  the basis for a new Component B in the same or different Test Application
  Framework. This case would also include the use of A unchanged in a newly
  developed Application. In the second case A becomes sufficiently popular that it
  is submitted to the 716 subcommittee as a proposed addition to the ATLAS 2000
  Normative Annexes. This approach (C) could potentially result in an addition to
  the ATLAS 2000 Primitives (Primitives are not modified or deleted due to
  upward compatibility issues). Upon acceptance by the 716 subcommittee,
  management of the component takes place as part of the standard.

      In the third case, (D), the component may be used by a technical community
  outside the realm of ATLAS 2000 in an alternative language implementation via
  a test environment such as ABBET. In this case total maintenance and
  implementation responsibility is assumed by the technical community for this
  component.

  The ATLAS 2000 Model

      A fundamental concept of ATLAS 2000 is the model. The ATLAS model is
  the means by which the basic elements of ATLAS found in the nucleus and
  primitives are combined to describe signals and signal relationships of ever
  increasing complexity. The language components presented in the prior
  paragraphs i.e., boxes A through D, are models formed from the ATLAS 2000.

  This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
  reproduction without the consent of the IEEE is prohibited.
                                                                                                                             13
     The modeling capability of ATLAS 2000 is the mechanism which provides
stability within the Standard while giving potential users the ability to meet the
test requirements of any technology by building upon the lower level testing
building blocks of the language.

    The process of describing the testing needs to support a technology will
consist of a process wherein basic language elements of ATLAS 2000 are
combined to form simple models. These simple models are further combined or
encapsulated to form increasingly complex models of more complicated testing
signals and relationships. Ultimately this process is completed when the entire
technological testing capability for any defined technology is completed as a Test
Application Framework.

    The encapsulated models which are formed can also be decomposed and
recombined with other models to form new and changing test requirements.
Thus elements of an existing test application framework can be used to create
new test application frameworks as needed. Figure 3 implies this relationship
showing differing test application frameworks being formed by utilizing
elements taken from Normative Annexes and/or other test application
frameworks.

ATLAS 2000 and ARINC ATLAS 626

    From the start the ATLAS 2000 design effort recognizes that legitimate
differences in opinion can and do exist between technical communities doing
similar testing. In addition ATLAS 2000 by its design and structure recognizes
that technical communities often prefer to maintain control of their test language
standard rather than depend upon other organizations to do so.

     The relationship between the ATLAS Language Standard utilized by the
commercial airlines ARINC, ATLAS 626 and the ATLAS language standard
utilized by the Defense Community, ATLAS 716 serves as an excellent example
of the manner in which ATLAS 2000 can achieve beneficial convergence and
harmonization between two technical communities while simultaneously not
impinging upon either’s independence and flexibility through design of the
structure of ATLAS 2000.

Baseline ATLAS 626 and ATLAS 716

     As noted previously, ATLAS 626 and 716 will serve as the experience base
for the development of ATLAS 2000. Currently both of these dialects of ATLAS
are very similar. The avionics testing heritage of ATLAS due to the fact that the
ATLAS language was initially produced under the auspices of ARINC for

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           14
avionics test, is clearly reflected by the languages organization, design and
structure.

     The fact that the two ATLAS language dialects are largely identical1 does
nothing to resolve the requirement for upward compatibility between prior
versions of ATLAS predicated upon the differences which exist between the two
languages’. The languages existing structure also does not provide an answer to
the interest in independent control of the language being used.

     The design of the ATLAS 2000 structure elegantly resolves the issues noted
above. The normative annexes within the ATLAS 2000 standard reflect only
those applications for which there was a commonality of view. The ATLAS 2000
nucleus which defines the language and primitives which give it substance,
would contain only lower level language elements and the rules, guidance and
control for creating application frameworks for any using community. Thus the
626 commercial airline community through the facilities of ATLAS 2000 could
produce the Avionic Application Framework Appendices reflecting their special
testing needs and interests. These application frameworks would be maintained
by the 626 community. They would not be part of the ATLAS 2000 standard
unless the 626 community desired to submit them as a proposal. Most
importantly, both communities could save time and money by utilizing ATLAS
2000 which would reflect commonality of application and use within each
standard.

    The converse of this situation would also apply should the 716 community
discover specialized applications to testing reflecting their unique needs. It is
conceivable, for example, that the U.S. Joint Services as well as each of the NATO
users could have special Application Framework Appendices for special testing
needs which they would maintain for the life of the system they were
supporting. This would be very superior to the situation today in which each of
these entities would be faced with supporting the entirety of various dialects of
ATLAS each time they encounter a special testing need for a new system.

ATLAS Application Set

    An ATLAS Application Set is shown in Figure 5. The ATLAS Application
Set contains the ATLAS 2000 Standard (Nucleus, Primitives, Normative
Annexes), plus the Test Application Frameworks needed by the user.
`


1
 Paper by Arnold Greenspan and Michael Seavey “Comparing and Contrasting ATLAS 716-1995
and ARINC ATLAS 626. To be published in Proceedings of Autotestcon 1996.

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           15
                                                       Normative
                                                       Annexes


                                                      Primitives



                                                       Nucleus




                                                   Test Application
                                                    Frameworks




                                              Figure 5
                                         ATLAS Application Set



    In the discussion previously 626 and 716 users of ATLAS and users within
other communities were postulated as having ATLAS Application Sets that met
their unique testing needs. The special testing requirements which lie outside the
ATLAS 2000 Standard are formed by the creation of one or more Test
Application Frameworks. These frameworks are produced in accordance with
the rules of ATLAS 2000 utilizing the elements found in the nucleus and
primitives and interconnected to the rest of ATLAS 2000 with the rules and
mechanisms of the nucleus.




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           16
    Figure 5 illustrates in more explicit fashion what a hypothetical ATLAS 2000
Application Set might look like. Normative annexes are shown at the top half of
Figure 5 while test application framework types are shown at the bottom half.




                                                       Normative Annexes

                                                                           Timing &
                                                     Digital Normative     Synchronization
                                                           Annex           Normative Annex

                                                                 Primitives
                                                                                     Data Bus
                                           Analog
                                                                                     Testing
                                           Normative
                                                                 Nucleus             Normative
                                           Annex
                                                                                     Annex
                                                             x

                                             Electro-Optical
                                              Test Application
                                                Framework           Air Navigation Test
                                                                    Application
                                                                    Framework
                                                    Special
                                                    Requirements Annexes




                                          FIGURE 6
                       Application Set with Explicit Normative Annexes
                                 and Application Frameworks




    An alternative view of ATLAS 2000 is presented on the following page in
Figure 7.

   What Figure 7 illustrates is the manner in which the elements of ATLAS 2000
combine to form an ATLAS Application Set which utilizes those elements of
ATLAS 2000 that are required to produce the total test requirements of the user.


This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           17
                                                                                   Application Set C       Application Sets may be
Variety of ATLAS Language Application Sets                                                                 tailored for a community
.
Based on ATLAS 2000 and Tailored for the
                                                                               Application Set B
                                                                                                           (medical, military,
                                                                          Application Set A                automotive) or a specific
Users Needs
                                                                                                           application within a
                                                                                                           community, e.g.
                                                                                                           commercial airline
                                                            Test Applications                              (747,777,airbus)
           Bus
                                                            Developed by Users                       Other Specialized User
       AIR-NAV                    User Defined                                                       Defined Application
                                  Application               Using ATLAS 2000                         Frameworks
     Electro                      Frameworks
     Optical                                                                                  Specialized Test Application
                                                                                              Frameworks for RF
     Selected/Designed
     Application
     Frameworks



                                                          Previously Defined Test                  Other Normative Annexes
           Analog                                         Applications Existing as                 as Required
       Digital                  Standard                  Part of the ATLAS Std.                   RF Normative Annex
                                (716)
     Timing                     Application
                                Frameworks
     Normative Annexes
     Applic.Frame.withi
     n ATLAS 2000 Std



                                                       Selected Language
         Modifiers                                     Elements for a Test                           RF Primitives
       Verbs                                           Application Type
     Primitives
                                                       Standard 716                                Basic Primitives (low
                                                       Vocabulary                                  level constructs)
          Primitives



                                                                                         Language Structure for ATLAS
                                                   Standard 716                          2000 (Syntax) Meanings and
         NUCLEUS                                   Syntax, Semantics                     Definitions of Language Elements
                                                   and Rules                             (Semantics)
                                                                                         Structural Relationships Between
                                                                                         Language Elements, Rules for
           ATLAS                                                                         Selection and Development of
           Nucleus                                                                       Application Specific Test
                                                                                         Elements (Models and Test
                                                                                         Application Frameworks)


 ATLAS Test Application
 Set




                                           FIGURE 7
                           Development of ATLAS 2000 Test Application
                                              Sets



This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           18
    Figure 7, at the bottom, illustrates the ATLAS 2000 Nucleus which defines
the formal structure and definition of the languages rules and relationships. The
Nucleus defines, for the user, the ATLAS 2000 capabilities and what may be
accomplished using those capabilities. It also stipulates the processes and
procedures which must be observed in creating the test-related language set
which is desired.

     Immediately above the Nucleus are the Primitives. The ATLAS Primitives
are primarily the simplest forms of the ATLAS 2000 vocabulary which describe
testing signals and characteristic behavior. Specifically, the Primitives are the
vocabulary in its simplest practical form, i.e., Noun, Noun Modifier,
Connections, Verb, Verb Modifier, Test Operators, Test Functions, Qualifying
and Conditioning Keywords, Event Timing and Synchronization Term and
Dimensional Terms.

    Figure 7 illustrates the users ability to select from the entire set of ATLAS
2000 Primitives or those primitive elements related to a test application in which
the user is interested, in this case RF.

     At the next level of the figure, Normative Annex, the figure shows that the
ATLAS 2000 Standard will contain already defined Test Application
Frameworks. These are applications which have been widely accepted by the
test community for a specific test discipline as representing the optimum and
preferred method or approach for testing that type of parameter or type. These
Application Frameworks are called Normative because they are part of the
ATLAS 2000 Standard and thus represents the recommended, standardized i.e.,
Normative approach for testing those signal types.

     The user may, at this point, select the Normative Annexes which meets his
test needs. Alternatively the user may determine that the existing Normative
Annexes within ATLAS 2000 only partially provide what is required or do not at
all provide what is required.

    To the extent that the user finds that the existing ATLAS 2000 Normative
Annexes do not fully and completely meet his requirements (this will often be
the case) he will move to the next higher level of Figure 6.

    At the next level of Figure 7, User Defined Framework, the user will utilize
the facilities of ATLAS 2000 to tailor the language to the specific test needs
required.

    A broad menu of capabilities are available to perform this tailoring; however
the fundamental tool that will normally be used is the model. The ATLAS 2000

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           19
rules concerning models enables the user to select simple primitive vocabulary
elements and join or encapsulate them to make more complex or higher level test
elements. This will allow further joining of the highest level 1 complex test
elements to form functional test units and subsequently new Test Application
Frameworks directly related and congruent to the special test needs that are
required to resolve the users test problem.

    The structure of models can consist of operators, functions and networks
plus associated rules and semantics. It’s components can be primitives, other
pre-defined models and/or elements from these models. Thus, the model rules
also anticipate decomposition and extraction of derivatives from pre-existing
models. When a model is built from another model, the other model inherits the
properties of the model from which it is derived.

    The user will develop those specialized Test Application Frameworks as
necessary to encompass the total test problem which must be faced. In Figure 6
this process is alluded to by a Specialized RF Application Framework derived
from RF Primitives, elements of the RF Normative Annex and the newly created
Test Definitions imposed by the support and test problem. Other user
defined/designed application frameworks are indicated to show that the process
for creation of specialized application frameworks, will continue to cover the
entire test problem.

    At the very top of Figure 7 the representation suggests many different
ATLAS 2000 Application Sets each tailored to specifically meet the test needs of a
particular user or user community. The term Application Set denotes the
combination of the ATLAS 2000 Nucleus, Primitives, Normative Annexes and
user defined Test Application Framework required to fully comply with the
users special test needs.

    It is envisioned that a community such as the commercial airlines which
currently utilizes ARINC ATLAS 626-3 could, in the future, utilize the following
approach to meet their test language needs. Starting with ATLAS 2000 (Nucleus,
Primitives, Normative Annexes) they could create an Application Framework or
set of Frameworks which in effect provide all the basic or general capabilities
currently provided by ARINC ATLAS 626-3. Subsequently, each platform could
further tailor this to a commercial airline Test Application Set to meet the special
needs of any existing or new aircraft addition to the commercial airline
inventory, i.e., 727, 737, 747, 767, 777 and similarly for airbus. The immediate
advantage of this approach is that the language maintenance expense for ATLAS
is greatly reduced to reflect only the platform specific needs imposed by new
aircraft. Upward compatibility is ensured by virtue of the inherent identity of
the base language and the ability to couple or decouple a newly developed Test

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           20
Application Framework as needed. Training is simplified due to the consistency
of the overall language. Risk is reduced because language changes are restricted
to a Test Application Framework and not rippled through the language.
Industry costs are reduced due to each maintenance activity being able to
operate and support only those ATLAS versions, i.e., Application Sets that they
require. Further specialized enhancements are also possible with this approach
through tailoring for specific SMART or other Test Platforms via a Test
Application Framework.

     The same approach can be utilized to define a Department of Defense (DoD)
Test Applications Set. Each service can specialize for their individual needs. Test
Application Sets can be further specialized for a weapon system or by other
criterion. Historically, this has been true for ATLAS applications within the
DoD. The difference now is that the maintenance burden is greatly reduced since
the language is unchanged and only specialized needs are created as models.


ATLAS 2000 External Interfaces

     This Introductory Guide has to this point discussed the internal interfaces of
ATLAS 2000 from Nucleus to Primitive to Annex and between Annexes.
However the design of ATLAS 2000 for the first time will also recognize the
inherent interfaces with which the ATLAS language must work. Figure 8
illustrates the external interfaces which will be considered in the design of
ATLAS 2000.




                                                     ATLAS 2000
                                                                                                        Other
                                                                                                        Interfaces
                PROCESSING                      STANDARDIZATION                      CAD TOOLS
                  TOOLS                              TOOLS

                                                            --ABBET                           - VHDL
         - COMPILERS
                                                                                              - MHDL
         - SYNTAX SEMANTICS
                                                                                              - ATPGs
            EDITORS                                         -AI-ESTATE                        -EDIF
         - STATEMENT
            GENERATORS                                      -TMIMS
         - TRD GENERATORS
         - TPS QUALITY TOOLS




                                               Figure 8
                                      ATLAS 2000 External Interface


This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           21
This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           22
An example of the benefits provided by the design of ATLAS 2000 can be seen in
Figure 8. Figure 8 hypothesizes the use of ATLAS with ABBET, IEEE Std 1226,
the Ada language tools via the facilities of the Interface Definition Language
(IDL). IDL is an output of the Object Management Group (OMG)2. In Figure 9
the essence of the ATLAS 2000 language, its nucleus, is shown as an interface to a
language tool called an ATLAS composition tool. (This tool would be used to
assist parties interested in developing test programs/procedures or Test
Application Sets in accordance with the syntax, semantics and rules of ATLAS
2000.)

                                             ATLAS
                                              2000
                                             Nucleus


                                     ATLAS            ATLAS
                                      2000             2000
                                    Primitives      Normative
                                                    Framework                          Ada Std
                                                                                     (Nucleus for
                                                                                        Ada)


                                                 IDL



                                    ABBET                      ATLAS
                                     TFF                     Composition
                                    ABBET                       Tools
                                     1226


                                                                ATLAS                Ada Source
                                                                Source




                                             Figure 9
                                 ATLAS Interface to other Languages


     To the left, the ATLAS 2000 interface to ABBET is shown. This interface
illustrates the ATLAS 2000 Normative Annexes, and ATLAS Primitives
emplaced in the ABBET Test Foundation Framwork (TFF) via their initial
encoding in IDL (IDL is the standard interface specification selected by ABBET).

2
 The Common Object Request Broker Architecture and Specification (CORBA),
Rev 2.0, Chapter 3, Object Management Group, Inc., July 1995.
This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           23
    Once emplaced into the ABBET TFF, the ATLAS test knowledge, foundation
and experience baseline can be made available to others via the IDL for
generating of test programs or procedure in alternative languages (Ada is
shown). It is recognized that a nucleus for Ada does not exist per se. However
the implication is that the rules, syntax and semantics of Ada (which is not a test
language) can be used with the ATLAS test baseline which would/could make
Ada or any other computer language, also a viable test language alternative.

    Efforts are currently in process to encode the test related elements of ATLAS
716-95 in IDL for emplacement into the ABBET TFF.

Summary and Conclusion

    The process of designing ATLAS 2000 is taking place now under the auspices
of the IEEE within a committee called Standard Coordinating Committee 20
(SCC20). SCC20 meets twice a year. The meetings take place in the U.S. and
Europe. For additional information on the development of ATLAS at SCC20
meetings or to participate in the language development interested parties may
contact the Chairman of SCC20, Mr. Larry Carpenter at ARINC 410-266-2416 or
the Chairman of the ATLAS Subcommittee of SCC20 Mr. Narayanan
Ramachandran at TYX 703-264-1080.


Comments, Suggestions and/or recommendations concerning this document
may be forwarded to A.Greenspan, Arosco Inc., Ph. 410-366-5411, Fax 410-366-
0441, e-mail a.greenspan@ieee.org




This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           24
                                                   APPENDIX I
                                                  ATLAS History


Background

    The need for a standardized language for testing was recognized in the early
1960’s. The problems encountered by the test community at that were
numerous.     They included test related miscommunication between the
responsible agents involved with a units design, production and maintenance,
redundant effort in development of test specifications, test plans and test
procedures and what was perceived to be excessive costs allocated to the test
process.

    The advent of automated systems to perform testing greatly exacerbated the
problems. The demand by the data processors, and later computers used in
these systems imposed an increased demand for precision in the test
instructions. The increasing complexity of the units which were to be tested also
demanded a more consistent and effective language for describing tests. The
growing demand for maintenance and support across a broadening user base for
longer periods of time imposed the need for a common test language reference
which was both technically and administratively viable. These technical
pressures represented a problem that could no longer be ignored and efforts to
pursue the development of a standardized test language were begun in earnest.

    Aeronautical Radio Incorporated (ARINC) started the development of a
standard testing language in response to the demands of the commercial air
lines. 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 which had been 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
maintenance and support of avionics systems. They met together and worked
over time to define and develop ATLAS. Later recognition of the need and
benefit of a standardized testing language grew beyond the bounds of the
commercial airlines. The US Army, Navy, Air Force and NATO services became
increasingly active in the ATLAS language development efforts. Commercial

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           25
companies working with these agencies as part of the defense industry also
recognized the potential benefit of ATLAS for support of avionic defense
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 called
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 titled ARINC 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 416-13A, which was the fourteenth published version of
ATLAS had been released. In 1976 IEEE 416-1976 was also published. This was
the first ATLAS published under the auspices of the IEEE and represented the
ARINC 416-13A ATLAS in IEEE format. Subsequent 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 for the need
for upward compatibility between versions. However, there was increasing
concern and pressure to reduce the maintenance burden represented by ATLAS
416.

    In May of 1988 the IEEE published ATLAS standard 716-1988/9 which
represented a subset of the ATLAS 416. During the same year ARINC published
an ATLAS subset titled ARINC 626-1988/9. Unfortunately standards 716 and
626 were not completely compatible nor were they true subsets of IEEE 416. The
IEEE ceased to publish ATLAS 416 after the release of ATLAS 716, and formally
withdrew ATLAS 416 in 1993. IEEE ATLAS has been published in an updated
form every 3 or 4 years since the initial publication. ARINC 626 has followed a
similar publication schedule.


This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           26
    In 1984 the IEEE also published standard 771. This standard is a guide to the
use of the ATLAS language.

      Table 1 shows the historic development of IEEE ATLAS to the current time.

                          Table 1- The Historic Development of ATLAS

       416 Issue                Month and Year                              Development
                               1965 - 1966                    A study of the need for a standard test
                                                              language was initiated as the airlines
                                                              were considering using automatic test
                                                              equipment for maintenance testing.
                               January 1967                   The first AEEC subcommittee meeting
                                                              was held to formulate a test language.
                               August 1967 -                  Seven preliminary drafts of ATLAS
                               September 1968                 Specification 416 were generated.
ARINC 416-1                    October 1968                   The final draft was approved by
                                                              AEEC for issue as ARINC
                                                              Specification 416-1.
2-5                            1969 - 1972                    Miscellaneous changes and
                                                              refinements were introduced in the
                                                              language which, until this time, only
                                                              covered analog test requirements.
6                              October 1972                   A digital testing capability was
                                                              introduced.
7                              July 1973                      Some minor changes were introduced.
8                              July 1973                      A digital macro construct was
                                                              introduced to augment the handling
                                                              of digital testing.
9                              May 1974                       Miscellaneous refinements were
                                                              incorporated.
10                             May 1975                       The most significant changes were the
                                                              introduction of decision table and
                                                              tasking capabilities. Decision table
                                                              defines and initiates branching a test
                                                              requirement which is dependent upon
                                                              a complex relation between a number
                                                              of variables. Task allows for the use
                                                              of separate test sequences to be
                                                              performed simultaneously.
11                             January 1976                   A structured programming capability
                                                              was introduced which allowed a test

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           27
       416 Issue                 Month and Year                            Development
                                                              requirement to be divided into self-
                                                              contained blocks of test routines
12                             April 1976                     Miscellaneous refinements relating to
                                                              complex numbers and wave form
                                                              handling amongst others were
                                                              incorporated.
13                             August 1976                    Further miscellaneous changes were
                                                              introduced.
13A                            August 1976                    The ARINC Specification 416-13 was
                                                              reformatted with no changes to
                                                              improve the interpretation and the
                                                              management of the document.
IEEE 416-1976                  November 1976                  The reformatted version, ARINC
                                                              Specification 416-13A was adopted by
                                                              the IEEE as their launching version of
                                                              the ATLAS language standard
14                             November 1978                  A capability for the defining of test
                                                              resources as a requirement for testing
                                                              was incorporated.
15                             October 1979                   Miscellaneous refinements were
                                                              introduced.
16                             July 1980                      Further miscellaneous refinements
                                                              were incorporated.
17                             October 1980                   New syntax and semantics were
                                                              introduced to provide for:
                                                              a) definition of signals
                                                              b) inclusion of ATLAS and non-
                                                                 ATLAS program modules
                                                              c) definition of protocol procedures
                                                                 and data exchanges allowing data-
                                                                 bus testing to be handled

                                                              New vocabulary was introduced to
                                                              provide for:
                                                              a) defining electro-magnetic fields
                                                              b) radar signals
                                                              c) ambient-conditions
                                                              d) fluid signals
                                                              e) turbine engine
                                                              f) vibration testing
18                             April 1981                     A number of ATLAS statements were

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           28
       416 Issue                 Month and Year                            Development
                                                              introduced to identify events during
                                                              testing to improve the handling of
                                                              time related testing. Further
                                                              statements were introduced to
                                                              augment to handling of tasking to
                                                              suspend tasks, continue tasks, request
                                                              tasks and release tasks. Vocabulary
                                                              related to input and output devices
                                                              was added.

                                                              A statement was added to separate
                                                              the preamble and procedural sections
                                                              in ATLAS test requirements. New
                                                              constructs for handling inputs and
                                                              outputs of test information were
                                                              introduced.
19                             October 1981                   The if-then-else structure was
                                                              enhanced to include else-if. User
                                                              defined functions were introduced.
                                                              New digital constructs were
                                                              introduced to provide more flexibility
                                                              handling modern digital testing
                                                              techniques. An enable escape
                                                              mechanism was introduced to
                                                              facilitate error handling.
20                             May 1982                       Further miscellaneous refinements
                                                              were incorporated.
21                             November 1982                  Introduction of state diagrams to
                                                              correlate single-action and multi-
                                                              action verbs. Some further
                                                              miscellaneous refinements were
                                                              incorporated.
22                             May 1983                       Vocabulary was introduced for
                                                              Scorsby-like motion; visible light;
                                                              infra-red radiation. Further
                                                              requirements to the bus testing
                                                              constructs and new vocabulary for
                                                              video signal testing were introduced.
23                             November 1983                  Minor miscellaneous refinements
                                                              were incorporated.
24                             May 1984                       Quantities and dimensions
                                                              conforming the International Standard
This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           29
       416 Issue                 Month and Year                             Development
                                                              ISO 10000 Units (SI) were introduced.
                                                              These were for use on non-aerospace
                                                              and non-defense projects although
                                                              they are equally useful in the
                                                              aerospace and defense industries.
                                                              New vocabulary related to target
                                                              signals was introduced.
25                             November 1984                  Some refinements to the old and new
                                                              digital testing constructs were
                                                              incorporated.
IEEE 416-1984                  December 1984                  Published version aligned to
                                                              development revision level 21.
26                             May 1985                       Structured data types were
                                                              introduced to provide more rigorous
                                                              handling of basic data types;
                                                              constants, variables and parameters.
                                                              Refinements to the vocabulary
                                                              relating to waveforms were
                                                              incorporated.
27                             November 1985                  Refinement to sensor type statements
                                                              were incorporated to allow for
                                                              sampled measurements. An extend
                                                              mechanism was introduced to
                                                              facilitate the inclusion of new
                                                              vocabulary into ATLAS test
                                                              requirements. Some non-preferred
                                                              ATLAS statements were deleted.
                                                              Some infrequently used and
                                                              superseded were made non-preferred.
28                             May 1986                       Refinements for bit synchronization
                                                              were added to the new digital testing
                                                              constructs. The first refinements to
                                                              the definitions of the ATLAS
                                                              vocabulary review were incorporated.
31                             November 1987                  Further refinements to the definitions
                                                              of the ATLAS vocabulary resulting
                                                              from the vocabulary review.
31-33                          May 1988 -                     Further refinements to the syntax and
                               November 1988                  semantics of ATLAS arising from the
                                                              creation of the subsets IEEE Std 716-
                                                              1989 and ARINC Specification 626-1.

This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           30
       416 Issue                 Month and Year                            Development
                                                              Further refinements to the definitions
                                                              of the ATLAS vocabulary arising from
                                                              the vocabulary review.
34-36                          May 1989 -                     Various miscellaneous refinements
                               November 1990                  were completed.

                                                              Decision taken to freeze 416 at level 36
                                                              with no further development to take
                                                              place. The level 36 development
                                                              document to be archived for future
                                                              reference.
(36)                           June 1993                      IEEE Std 416-1984 withdrawn.
1982 (level 17)                March 1982                     A common ATLAS subset (C/ATLAS)
                                                              for use in the defense industries was
                                                              created from level 17 of 416 ATLAS.

                                                              Contained ATLAS constructs for
                                                              analog testing and digital testing
                                                              using the old digital constructs.
1985 (level 18)                September 1985                 Refining to the syntax and semantics
                                                              were incorporated.
1989 (level 30)                May 1989                       The subset was revised to include:
                                                              a) SI units
                                                              b) structured data types
                                                              c) identification of events
                                                              d) new digital constructs
                                                              e) data-bus testing constructs
                                                              f) requirement for test resources
                                                              g) extensibility features for semantics
1995                           July 1995                      The standard was revised to include:
                                                              a) escape mechanism
                                                              b) complex signals constructs
                                                              c) dynamic digital constructs
                                                              d) upgraded data-bus testing
                                                              facilities

          The ATLAS test language has proven to be very successful over the years.
          It has precluded or mitigated many of the problems which vexed the test
          community. However, the Standard itself introduced new problems
          which require attention and correction.


This document has been produced on behalf of the Institute of Electrical and Electronics Engineers (IEEE). Its ducplication or
reproduction without the consent of the IEEE is prohibited.
                                                                                                                           31

								
To top