1、DESIGN GUIDANCE FORAVIONICS TEST EQUIPMENTPART 1SYSTEM DESCRIPTIONARINC SPECIFICATION 608APUBLISHED: January 15, 1993AN DOCUMENTPrepared byAIRLINES ELECTRONIC ENGINEERING COMMITTEEPublished byAERONAUTICAL RADIO, INC.2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401This document is based on material submitte
2、d by variousparticipants during the drafting process. Neither AEEC nor ARINChas made any determination whether these materials could besubject to claims of patent or other proprietary rights by thirdparties, and no representation or warranty, express or implied, ismade in this regard. Any use of or
3、reliance on this document shallconstitute an acceptance hereof “as is“ and be subject to thisdisclaimer.Copyright 1993 byAERONAUTICAL RADIO, INC.2551 Riva RoadAnnapolis, Maryland 21401-7465 USAARINC SPECIFICATION 608ADESIGN GUIDANCE FOR AVIONICS TEST EQUIPMENTPART 1 - SYSTEM DESCRIPTIONPublished: Ja
4、nuary 15, 1993Prepared by the Airlines Electronic Engineering CommitteeSpecification 608A Adopted by the Airlines Electronic Engineering Committee: November 5, 1992FOREWORDActivities of AERONAUTICAL RADIO, INC. (ARINC)and thePurpose of ARINC Reports and SpecificationsAeronautical Radio, Inc., is a c
5、orporation in which the United States scheduled airlinesare the principal stockholders. Other stockholders include a variety of other air transportcompanies, aircraft manufacturers and foreign flag airlines.Activities of ARINC include the operation of an extensive system of domestic andoverseas aero
6、nautical land radio stations, the fulfillment of systems requirements frequencies tomeet those needs, the coordination incident to standard airborne communications and electronicssystems and the exchange of technical information. ARINC sponsors the Airlines ElectronicEngineering Committee (AEEC), co
7、mposed of airline technical personnel. The AEEC formulatesstandards for electronic equipment and systems for the airlines. The establishment of EquipmentCharacteristics is a principal function of this Committee.It is desirable to reference certain general ARINC Specifications or Reports which areapp
8、licable to more thanone type of equipment. These general Specifications or Reports may beconsidered as supplementary to the Equipment Characteristics in which they are referenced. Theyare intended to set forth the desires of the airlines pertaining to components and general design,construction and i
9、nterchangeability in airline service. The release of a Specification orEquipment Characteristic should not be construed to obligate ARINC or any airline insofar asthe purchase of any components or equipment is concerned.An ARINC Report (Specification or Characteristic) has a twofold purpose, which i
10、s:1) To indicate to the prospective manufacturers or airline electronic equipment theconsidered opinion of the airline technical people coordinated on an industry basisconcerning requisites of new equipment, and2) To channel new equipment designs in a direction which can result in themaximum possibl
11、e standardization of those physical and electrical characteristicswhich influence interchangeability of equipment without seriously hamaperingengineering initiative.iiTABLE OF CONTENTSSPECIFICATION 608AITEM SUBJECT PAGE1.0 INTRODUCTION 11.1 Purpose of This Document 11.2 Advantages 11.3 Objectives 11
12、.4 Goals 11.5 Background 11.6 Relationship to ARINC Specification 608 21.7 Compatibility With Other Systems 21.7.1 ARINC 608A Compatible 21.7.2 ARINC 608A Compliant 21.7.3 SMART Automatic Test Systems 21.7.4 ARINC 608A/SMART Automatic Test Systems 22.0 SYSTEM CONCEPT 32.1 Introduction 32.2 Test Syst
13、em Hardware 32.2.1 Test Control Computer (TCC) 32.2.2 Sources, Sensors and Loads 32.2.3 Switching System Assembly 32.2.4 Test Unit Adapter (TUA) Interface 32.3 Test System Software 32.3.1 Software Functions 32.3.2 Typical System Operation 32.3.2.1 ATLAS Compiler 32.3.2.2 Intermediate Code/Virtual Re
14、source Table File 32.3.2.3 ATLAS Linker 42.3.2.4 Test Unit Adapter (TUA) Wiring Description 42.3.2.5 TUA Processor 42.3.2.6 Resource Description 42.3.2.7 Device Module 42.3.2.8 Configuration Model 42.3.2.9 ATE Modeling Processors 42.3.2.9.1 Resource Description Processor 42.3.2.9.2 Device Model Proc
15、essor 42.3.2.9.3 Configuration Model Processor 42.3.2.10 Resource Allocator 42.3.2.11 Intermediate Code/Real Resource Table File 42.3.2.12 Device Control Task (DCT) 42.3.2.13 ANSI C Compiler/Linker 42.3.2.14 Test Executive 43.0 TEST SYSTEM FUNCTIONS 53.1 Introduction 53.1.1 Desired Functions 53.2 Op
16、erator Interface 53.3 Hardware Interface 53.3.1 Test Control 53.3.2 Test Resources 63.3.3 Switching 63.3.4 UUT Interface 63.4 Automatic Test Control 63.4.1 Options 63.4.1.1 Print All/Fail/No Data 63.4.1.2 Display Data 63.4.1.3 Store All Data 63.4.2 Operator-Initiated Events 63.4.2.1 Run 63.4.2.2 Abo
17、rt 63.4.3 Annunciations 63.4.3.1 Fail 63.4.3.2 Test and Step 73.4.3.3 System Failure 73.4.3.4 Operator Alert 7iiiTABLE OF CONTENTSSPECIFICATION 608AITEM SUBJECT PAGE3.4.4 UUT/ATE Data File 73.4.4.1 UUT Part Number 73.4.4.2 UUT Serial Number 73.4.4.3 Test Document Name 73.4.4.4 Operator Name 73.4.4.5
18、 Test System Serial Number 73.4.4.6 Test Type 73.4.4.7 Reason for Removal 73.4.4.8 Repair Action 73.4.4.9 Date/Time 73.4.4.10 Aircraft Tail Number 73.4.4.11 Vendor Identification 73.5 Manual Test Control 73.5.1 Instrument Control 73.5.2 Manual Control Options 73.5.2.1 Stop on Failure n 83.5.2.2 Sing
19、le Test Step 83.5.2.3 Single Statement Step 83.5.2.4 Test Program Loop start stop n 83.5.2.5 Run Control start, stop 83.5.3 Manual Control Events 83.5.3.1 Stop 83.5.3.2 Pause 83.5.3.3 Continue 83.5.4 Manual Control Annunciations 83.5.4.1 Loop Count 83.5.5 Advanced Troubleshooting Tools 83.5.5.1 On-L
20、ine Troubleshooting Tools 93.5.5.2 Alternate Test Executive 93.6 Test Program Development 93.6.1 Test System Environment Simulation 93.6.2 Test Program Debugging Tools 93.6.2.1 Search 93.6.2.2 Partial Execution 93.6.2.3 Control of Resources and Switching 93.6.2.4 Modification of Source ATLAS Program
21、 94.0 TEST SYSTEM DESIGN GUIDELINES 104.1 Introduction 104.2 Test Control Computer and Operating System 104.2.1 Introduction 104.2.2 General Minimum Capabilities 104.2.2.1 Operating System 104.2.2.1.1 Task Management 104.2.2.1.2 Event Management 104.2.2.1.3 Exception Management 104.2.2.1.4 Shared Me
22、mory 104.2.2.1.5 Binary Semaphores 104.2.2.1.6 Timer Management 104.2.2.1.7 Serial Port Control 104.2.2.1.8 C Compiler Requirements 104.2.3 TCC Functions and Features 114.2.3.1 Peripherals 114.2.3.2 Printer 114.2.3.3 Standard Instrument Control Buses 114.2.3.4 Media for Network Interface 114.2.3.5 M
23、edia for Transporting Software 114.2.3.6 Real Time Clock 114.2.4 Support 114.3 Test System Interfaces 114.3.1 Introduction 114.3.2 Standard Interfaces 124.3.2.1 Standard Interface Characteristics 12ivTABLE OF CONTENTSSPECIFICATION 608AITEM SUBJECT PAGE4.3.2.1.1 TUA Engaging Mechanism 124.3.2.1.2 Fra
24、me and Mounting Plate 134.3.2.1.3 Module Considerations - General 134.3.3 Subset Interfaces 134.3.3.1 Medium Interface 134.3.3.2 Small Interface 134.3.3.3 Small and Medium Interface Characteristics 134.3.3.4 Frame and Mounting Plate, Small 13and/or Medium Interface4.3.4 Module Specifications 134.3.4
25、.1 Signal Module 134.3.4.2 Power Module 144.3.4.3 Coaxial Signal Module 144.3.4.4 Blank Module 144.3.5 Interface Electrical Contacts 144.3.5.1 Signal Contacts 144.3.5.2 Power Contacts 144.3.5.3 Coaxial Contacts 144.3.6 Non-Standard Interfaces 144.4 Switching 144.4.1 Introduction 144.4.2 Switching Me
26、thodology 154.4.3 Common Switching Assembly 154.4.3.1 Type A Switch Characteristics 154.4.3.2 Type B Switch Characteristics 154.4.3.3 Type C Switch Characteristics 154.4.3.4 Type D Switch Characteristics 164.4.3.5 Type E Switch Characteristics 164.4.4 System Architecture 164.4.4.1 Introduction 164.4
27、.4.2 Signal Source Routing 164.4.4.3 Signal Sensor Routing 164.4.4.4 Analog Bus 174.4.4.5 Power Switching 174.4.4.5.1 Configuration One: 7 Amps 174.4.4.5.2 Configuration Two: 15 Amps 174.4.4.6 System Control 184.4.4.7 Self Test 184.5 Digital Test 184.5.1 Discrete Logic Test Interface (DLTI) 184.5.1.
28、1 Architecture 194.5.1.2 Signal Levels 194.5.1.3 Software Control 204.5.2 Dynamic Digital Test Interface (DDTI) 204.5.2.1 Dynamic Digital Data Module (DDDM) 204.5.2.2 Dynamic Digital Clock Module (DDCM) 204.5.2.2.1 Output Clocks 214.5.2.2.2 Input Clocks 214.5.2.2.3 Halt Control Input 214.5.2.2.4 Wai
29、t Control Input 214.5.2.2.5 Wait Acknowledge Control Output 214.5.2.2.6 Trigger Controls 214.5.2.2.7 De-Skew Input 214.5.3 Standard Bus Test Interfaces (SBTI) 214.5.3.1 Hardware 214.5.3.2 Internal Software 214.5.4 Pod Bus Test Interface (PBTI) 224.5.4.1 Parallel Bus Testing 224.5.4.2 Hardware Consid
30、erations 224.5.4.3 Protocol Definition 224.5.4.4 Pod Test Software 224.6 Radio Frequency (RF) Test 224.6.1 RF Switching 22vTABLE OF CONTENTSSPECIFICATION 608AITEM SUBJECT PAGE4.6.2 RF Architecture 234.6.3 RF System Control 234.7 Specialized Testing 234.7.1 Introduction 234.7.2 Switching 234.7.3 Spec
31、ialized Interface 234.7.4 Slot 19 234.7.4.1 Allowable Connectors 234.7.4.2 Preserving TUA Transportability 234.7.4.3 Labeling of the TUA 244.8 Test System Resources 244.8.1 Introduction 244.8.2 Capable Resources 244.8.3 Resource Control 244.8.4 Power Resources 244.8.4.1 General 244.8.4.2 Readback 24
32、4.8.4.3 AC Source 244.8.4.3.1 Frequency 254.8.4.3.2 AC Voltage Range 254.8.4.3.3 AC Current Limit 254.8.4.3.4 Power Interrupts 254.8.4.4 DC Source 254.8.4.4.1 DC Voltage Range 254.8.4.4.2 DC Current Capability 254.8.4.4.3 DC Current Limit 254.8.4.4.4 Ripple 254.8.5 Signal Resources 254.8.5.1 General
33、 254.8.5.2 Source Impedance 254.8.5.3 AC Signal Sources 254.8.5.4 Angular Position Sources 254.8.5.5 Function Generators 254.8.5.6 Fiber Optic Sources 254.8.6 Sensor Resources 264.8.6.1 General 264.8.6.2 Input Impedance 264.8.6.3 Accuracy 264.8.7 Loads 26FIGURES4-1 Interface Schematic 124-2 Standard
34、 Interface - A 124-3 Standard Interface - B 124-4 Example Medium Interface 134-5 Example Small Interface 134-6 Typical Common Switching 154-7 Analog Bus 174-8 Typical Power Switching 174-9 System Schematic 184-10 Self Test Routing 184-11 Typical DLTI Channel 194-12 Strobe Out (Drive) Timing Diagram
35、204-13 Strobe In (Sense) Timing Diagram 204-14 DDDM Schematic 204-15 DDCM Schematic 214-16 Pod Bus Test Set-Up 224-17 RF System Control 234-18 Specialized Switching 23viTABLE OF CONTENTSSPECIFICATION 608AITEM SUBJECT PAGEAPPENDICESA Glossary 27-29B Example Software Architecture 30C Standard Interfac
36、e Modules 31-32D Standard Interface Functional Description 33-49E Receiver Modules (No. 1 thru 21) 50-90F Standard Interface Mechanical Specification 91-121G Dynamic Digital Data Module 122-127H ATE Cabling and Grounding Guidelines 128-135I ARINC 629 Data Bus Testing 136-145J Test Unit Adapter (TUA)
37、 Identification 146-149K User-Defined Module 150-162viiARINC SPECIFICATION 608A - Page 11.0 INTRODUCTION1.1 Purpose of this DocumentThe purpose of this document is to describe a standardavionics test system concept that will reduce the cost of1.2 AdvantagesThis document was written to ensure that th
38、e advantagesof standardized testing can be realized by air transportoperators, airframe manufacturers and avionics suppliers.The advantages of standardized avionics testing will varyfrom user to user. However, three advantages areuniversal to most users. The first advantage is that theARINC 626 ATLA
39、S test programs are expected to betransportable between Automatic Test Equipment (ATE)without costly and time consuming modifications. This isaccomplished by standardizing the test system softwarewhich translates test programs written in the ARINC 626ATLAS language into an intermediate code. The sec
40、ondadvantage is to minimize the need for dedicated avionicstest systems for each vendors avionics. Large inventoriesof specialized test equipment can be reduced, effectivelyreducing capital expenditures. The third advantage is theease of updating test capability when new inventories ofavionic equipm
41、ent arrive with the purchase of a new typeof aircraft. ATLAS test programs and descriptions ofrequired test equipment for new avionics are supplied bythe vendor and are subsequently loaded into the users teststation. After translating the ARINC 626 ATLAS testprogram and adding required test hardware
42、, the users testsystem is ready for use. This capability extends the lifeof the test system.1.3 ObjectivesThe objectives of this approach include but are not limitedto the following:a. The capability to test, troubleshoot, and performend-to-end testing of the Unit Under Test (UUT).b. The use of ARIN
43、C Specification 626, “StandardATLAS for Modular Test“, as the sourcelanguage for test programs. These test programsshould be transportable across all avionics testsystems.c. The concept will prove to be so practical that, inaddition to the airlines, both avionics andairframe manufacturers will use i
44、t in their owntesting operations.d. The ability to support program development,editing and debugging.e. An architecture which can support any type ofavionics testing. Limitations will be imposedonly by individual implementation.f. The capability to generate executable code whenproperly configured.g.
45、 Transportability of Test Unit Adapters (TUAs)between standardized testers.1.4 GoalsGoals of this specification include the following:a. Development and maintenance of standardizedtest systems software on a shared-cost basis.b. Relative freedom of choice in the selection of aTest Control Computer (T
46、CC) and commercialoperating system.c. To provide an environment for ATLAS testprograms to be developed and maintained in themost economical manner.d. Elimination of the differences between avionicequipment manufacturer test specifications andARINC 626 ATLAS test programs.NOTE: ARINC Report 602A, “Te
47、st EquipmentGuidance“, defines test specifications as purerequirements written in the ATLAS language.Test programs are test specifications that havebeen modified to operate on a specific testsystem.e. To gather data for trend and failure analysis.f. To provide as much flexibility as possible in thes
48、election of sources, sensors and loads forinstrumentation.g. To be capable of running the SMARTsoftware.1.5 BackgroundThe digital revolution of the 1970s resulted in thetransition to highly integrated avionics packaged in“ARINC 700-series“ boxes. This application of digitaltechnology enabled high-vo
49、lume automatic testing to beachieved. However, as avionics equipment became morecomplex, it introduced complexity in testing. Althoughautomatic testing significantly reduced the amount ofmanpower needed in the actual testing, it contributed toexcessive front-end development costs. Avionicssuppliers, airframe manufacturers and airlines developeddifferent test systems and by necessity developed uniquetest programs to test avionics equipment. In 1984, theavionics maintenance community concluded that theindustry could realize significant cost savings if there werea standard ap
