1、PROGRAMMERS GUIDE FORSMART SYSTEMS USINGARINC 626 ATLASARINC REPORT 627-2PUBLISHED: June 30, 2002AN DOCUMENTPrepared byAIRLINES ELECTRONIC ENGINEERING COMMITTEEPublished byAERONAUTICAL RADIO, INC.This document is based on material submitted by variousparticipants during the drafting process. Neither
2、 AEEC norARINC has made any determination whether these materials couldbe subject to valid claims of patent, copyright or other proprietaryrights by third parties, and no representation or warranty, expressor implied, is made in this regard. Any use of or reliance on thisdocument shall constitute an
3、 acceptance thereof “as is” and besubject to this disclaimer.Copyright 2002 byAERONAUTICAL RADIO, INC.2551 Riva RoadAnnapolis, Maryland 21401ARINC REPORT 627-2PROGRAMMERS GUIDE FOR SMART SYSTEMSUSING ARINC 626 ATLASPublished: June 30, 2002Prepared by the Airlines Electronic Engineering CommitteeRepo
4、rt 627 Adopted by the Airlines Electronic Engineering Committee: January 2, 1990Report 627 Adopted by the Industry: February 23, 1990Summary of Document SupplementsSupplement Adoption Date PublishedReport 627-1 July 24, 1992 August 18, 1992Report 627-2 April 15, 1996 June 30, 2002FOREWORDActivities
5、of AERONAUTICAL RADIO, INC. (ARINC)and thePurpose of ARINC Reports and SpecificationsAeronautical Radio, Inc., is a corporation in which the United States scheduled airlines are theprincipal stockholders. Other stockholders include a variety of other air transport companies, aircraftmanufacturers an
6、d non-U.S. airlines.Activities of ARINC include the operation of an extensive system of domestic and overseasaeronautical land radio stations, the fulfillment of systems requirements to accomplish ground and airbornecompatibility, the allocation and assignment of frequencies to meet those needs, the
7、 coordination incident tostandard airborne communications and electronics systems and the exchange of technical information.ARINC sponsors the Flight Simulator Engineering and Maintenance Conference (FSEMC), composed ofairline technical personnel. The FSEMC formulates Flight Training Device (FTD) st
8、andards for electronicequipment and systems for the airlines. The establishment of Equipment Characteristics is a principalfunction of this Committee.It is desirable to reference certain general ARINC Specifications or Report which are applicable tomore than one type of equipment. These general Spec
9、ifications and Reports may be considered assupplementary to the Equipment Characteristics in which they are referenced. They are intended to setforth the desires of the airlines pertaining to components and general design, construction and test criteria,in order to insure satisfactory operation and
10、the necessary interchangeability in airline service. The releaseof a Specification or Equipment Characteristics should not be construed to obligate ARINC or any airlineinsofar as the purchase of any components or equipment is concerned.An ARINC Report ( Specification or Characteristic) has a twofold
11、 purpose, which is:(1) To indicate to the prospective manufacturers of airline electronic equipment the consideredopinion of the airline technical people, coordinated on an industry basis, concerningrequisites of new equipment, and(2) To channel new equipment designs in a direction which can result
12、in the maximum possiblestandardization of those physical and electrical characteristics which influenceinterchangeability of equipment without seriously hampering engineering initiative.iiARINC REPORT 627TABLE OF CONTENTSITEM SUBJECT PAGEiii1.0 INTRODUCTION 11.1 Purpose of this Document 11.2 Backgro
13、und 11.3 Goals of ARINC 626 ATLAS 21.4 ARINC Report 627 Overview 21.4.1 Introduction - Section 1 31.4.2 ATLAS Test Program Structure - Section 2 31.4.3 Good Programming Practices - Section 3 31.4.4 Operator Interface - Section 4 31.4.5 Guidance for Using Selected ARINC 626 ATLAS Constructs - Section
14、 5 31.4.6 Documentation - Section 6 31.4.7 Test Unit Adapters (TUA) and TUA Directive Files - Section 7 31.4.8 ATLAS Main Program Template (MAIN) 41.4.9 Additional ATLAS Libraries 41.4.10 Software Development Tools 41.4.11 Program Examples 41.4.12 Standardized Non-ATLAS Module Procedure Calls 41.4.1
15、3 Graphical Functions 41.4.14 Glossary 41.5 Relationship Between ATLAS Test Specification and ATLAS Test Program 51.6 Related Documents 52.0 ATLAS TEST PROGRAM STRUCTURE 62.1 Introduction 62.2 The Benefits of a Standard Test Program Structure2.2.1 Design and Development Phase 62.2.2 Test and Repair
16、Phase 62.2.3 Program Maintenance Phase 62.3 The TPS Template 62.3.1 Description of the TPS Template 72.3.2 Guidance in Using the TPS Template 72.3.3 The Standard, User, and UUT Libraries 92.3.4 Test Executive Built-In Procedures 132.3.5 Procedures Accessible to the TPS Programmer 132.3.6 Library and
17、 Test Executive Global Stores 132.3.7 Signal Modules 183.0 GOOD PROGRAMMING PRACTICES 193.1 Introduction 193.2 Test Objectives 193.3 Preparation for ATLAS Test Program Development 203.4 Use of Virtual Resources 203.5 Proper Test Sequence 213.6 Test Program Maintainability 223.6.1 Configuration Contr
18、ol 223.6.2 Use of Commentary 223.6.3 Meaningful Labels 223.6.4 Test Organization 223.6.5 Conversion of Digital Words 233.7 Complete and Partial Testing 233.7.1 Selective Testing Using Entry Points 233.7.2 Selective Testing Using BLOCK Structures 243.7.3 Use of Entry Points 243.8 Diagnostics 243.9 Pr
19、ogramming Methodology 243.9.1 Test Program Development 253.9.2 Overview of Technical Activities 264.0 OPERATOR INTERFACE 344.1 Introduction 344.2 Operator Skill Level 344.3 Operator Directive Messages 344.4 PASS/FAIL Messages 354.5 Use of INPUT/OUTPUT Statements 354.5.1 Output Messages 364.6 Long Te
20、st Execution Time 364.7 Consistency 37ARINC REPORT 627TABLE OF CONTENTSITEM SUBJECT PAGEiv4.8 Standardized Test Reports 374.9 Use of Graphics Within SMART 375.0 GUIDANCE FOR USING SELECTED ARINC 626 CONSTRUCTS 395.1 Use of EXTEND ATLAS Noun 395.1.1 Management of the EXTEND ATLAS Facility 395.1.2 Res
21、ponsibility for the Management of Extensibility 405.2 Manometrics and Fluid Signals 415.3 Digital Testing 415.4 Bus Testing 415.4.1 Protocol Establishment 415.4.2 Exchange Data 425.4.3 DO EXCHANGE Statement 435.5 Use of NON-ATLAS Modules in Digital Testing 435.5.1 General 435.5.2 Portability 445.6 T
22、he DEFINE DRAWING Statement 445.6.1 Completeness of the Drawing Information 455.6.2 Use of the DEFINE DRAWING Statement 455.6.3 Use of the APPLY DRAWING Statement 455.6.4 Use of the REMOVE DRAWING Statement 465.6.5 Use of the MONITOR Statement 465.6.6 Notes and Examples 465.6.7 Signal Conditioners 4
23、65.7 Implementation of Decimal and Integer 465.8 Implementation Differences Between ARINC 626 and SMART 476.0 DOCUMENTATION 536.1 Introduction 536.2 CMM Documentation 536.3 ATE Documentation 536.4 TPS Documentation 536.4.1 The ATLAS Test Program 546.4.2 Supplementary Documentation 546.4.2.1 Addition
24、al TPS Information 546.4.2.1.1 DEFINE DRAWING 556.4.2.1.2 Extended ATLAS Vocabulary 556.4.2.1.3 NON-ATLAS Modules 556.4.2.1.4 Data Bus 556.4.2.2 Operator Actions 556.4.2.3 TUA Directive Files 566.4.2.4 External Data Files 567.0 TUA AND TUA DIRECTIVE FILES 577.1 Relationship Between ATLAS And Test Un
25、it Adapter 577.2 Relationship Between ATLAS And TUA Directive File 577.3 Directive File 577.4 Relationship Between TUA Directive File and Other SMART System Models 577.4.1 Other SMART System Models 577.4.1.1 Configuration Models 577.4.1.2 Device Models 587.4.1.3 Resource Descriptions 587.4.2 Relatio
26、nships Between TUA Directive File And Other SMART System Models 587.4.3 Access to SMART System Model Documentation 587.5 SMART TUA Directive File Limitations 587.6 TUA Directive File Description 587.7 Test Unit Adapter Development 59ARINC REPORT 627TABLE OF CONTENTSITEM SUBJECT PAGEvFIGURES3-1 Conve
27、rsion of Digital Words 313-2 Selective Testing Using Entry Points 323-3 Selective Testing Using BLOCK Structures 333-4 Use of Entry Points 335-1 Reserved for Future Use 485-2 Example of Define Drawing 495-3 Example of Define Drawing 505-4 Example of Define Drawing 515-5 Example of Define Drawing 52A
28、PPENDICESA ATLAS Main Program Template (MAIN) A-1 thru A-41B SMART 627 Standard Procedures Library (STD) B-1 thru B-45C Example 627 User Library 1 (USR1) C-1 thru C-102D Example 627 User Library 2 (USR2) D-1 thru D-35E Example 627 Unit Under Test Library (UUST) E-1 thru E-40F Example SMART Resource
29、Allocation Directives F-1 thru F-2G Example SMART Linker Directives G-1 thru G-2H Example SMART Non-ATLAS Interface Definition File H-1I Example SMART TUA Source I-1 thru I-4J Software Development Tools J-1 thru J-2K Program Examples K-1 thru K-7L Standardized Non-ATLAS Module Procedure Calls L-1 th
30、ru L-5M Graphical Functions M-1 thru M-86N Glossary/Acronyms N-1 thru N-7ARINC REPORT 627 - Page 11.0 INTRODUCTION1.1 Purpose of this DocumentThe purpose of this document is to provide guidance to ATLAS test programmers fordeveloping, writing and documenting test programs for SMART systems conformin
31、g toARINC Specification 608A, “Design Guidance for Avionics Test Equipment.“ It also providesguidance to managers and system integrators for standardizing test programs and theirdocumentation.It is expected that the test programmer will become familiar with the text and examplescontained herein and,
32、 where possible, adhere to the style used in this guide. An ATLAS TestProgram template is provided in the Appendices to this report to assist in writing wellstructured and consistent ATLAS Test Programs. Test programmers are encouraged to takeadvantage of this structure.1.2 BackgroundSince the 1960s
33、, the airline community has been working toward standardization of testprocedure languages. The purposes of such standardization are to increase the technicalunderstanding of test procedures provided from different sources (e.g., avionics vendors, testequipment vendors and other airlines), define mo
34、re complete test procedures, and tofacilitate transportation of test procedures from one set of test equipment to another. As aresult, the ATLAS (Abbreviated Test Language for Avionic Systems) language specificationwas developed. It began as ARINC Specification 416, dedicated to avionics. It then ev
35、olvedto accommodate the testing of systems other than avionics. Due to its popularity in industriesother than air transport, control of the specification was transferred to the Institute of Electricaland Electronics Engineers (IEEE) and renamed IEEE Std 416-1978 (Abbreviated TestLanguage for All Sys
36、tems).The emergence of first generation digital transports such as the B-767 and the A310 createda need for a new avionics subset of ATLAS - ARINC Specification 616. Although ARINC 616provided a standardized language for test requirements information, it was not universallyaccepted by avionics manuf
37、acturers for in-house testing of their products. One reason for thiswas the lack of software and compilers in the 1980s to support test program development inATLAS. Additionally, lack of electronic designer and programmer experience with ATLASinhibited its use. Furthermore, an ATLAS program which wa
38、s produced either as a testspecification or a test program needed tailoring to move it onto a specific set of ATE. Thisproblem was further complicated by differences in test philosophies, ATE designs, andATLAS compilers.To address these shortcomings and work towards the goal of transportability of t
39、est programsthe industry developed a standard approach to ATE. ARINC Specification 608A defines astandardized ATE architecture covering both hardware and software portions of the system. Inconjunction with this ARINC Specification 626, “Standard ATLAS for Modular Test“ wasprepared. ARINC also embark
40、ed on the development of a standard and comprehensivesoftware package based on the requirements of ARINC Specification 608A and ARINCSpecification 626. This software package is known as SMART. In an effort to standardizethe way in which test programmers develop and write their programs, ARINC Report
41、 627 wasARINC REPORT 627 - Page 21.0 INTRODUCTIONcreated. These elements taken as a whole, provide the best opportunity to date to achieveairline goals of a standard test language, as well as transportable test programs.1.3 Goals of ARINC 626 ATLASThe ATLAS test language has evolved considerably sin
42、ce the definition of ARINC 616ATLAS. New constructs have evolved to handle testing of the latest technology components.Capabilities have been added to make ATLAS more appropriate as a programminglanguage rather than a procedural or specification language. Some older constructs havebeen deleted. In v
43、iew of this and the air transport industry program to create a standard ATEconcept, the joint TG-103/AEEC Test Equipment Guidance (TEG) Subcommittee developedARINC 626 ATLAS.One characteristic of the ATLAS language is that in many cases, a particular test sequencecan be written in different ways usi
44、ng one of several different constructs. Carrying redundantcapability in the specification increases complexity and cost of ATLAS translators/compilers.Therefore, where possible, all redundancies in ARINC 626 have been eliminated.The goals of ARINC 626 ATLAS as noted above essentially preclude backwa
45、rd compatibilitywith ARINC 616 ATLAS. This decision was made by the TEG Subcommittee afterconsiderable discussion.1.4 ARINC Report 627 OverviewThis document is organized in seven major sections plus appendices. The body includes:- Introduction- Objectives of Standard Testing- Good Programming Practi
46、ces- Operator Interface- Guidance for Using Selected ATLAS 626 Constructs- Documentation- Test Unit Adapters and TUA Directive FilesThe appendices include:- ATLAS Main Program Template- ATLAS Libraries- Software Development Tools- Program Examples- Standardized Non-ATLAS Module Procedure Calls- Glos
47、saryThe user of this guide is encouraged to read Sections 1 through 6 in their entirety. The usershould then refer to Section 7 and the appendices as necessary for particular testingproblems. Appendix A should be used as the framework for writing the ATLAS test program.ARINC REPORT 627 - Page 31.0 I
48、NTRODUCTION1.4.1 Introduction - Section 1The introduction provides general information on ARINC Report 627, its purpose, its role inthe airline modular test philosophy of today, and its relationship to other documents.1.4.2 ATLAS Test Program Structure - Section 2This section provides guidance on th
49、e standardization of test programs. The ProgramTemplate is introduced here, as well as the Standard, User and UUT Libraries. The existenceof SMART Test Executive built-in procedures and global stores is also presented in thissection. Lastly, the preferred method of handling ATLAS Extensions is provided.1.4.3 Good Programming Practices - Section 3This section provides guidelines for designing and writing quality ATLAS test programs. Itprovides guidance on test objectives, test program preparation, test sequencing, testprogram maintainability, complete and partial testing, and diagnostics.
