Automatic Test System

Automatic Test SystemCritical Interfaces Report

Release 19/30/96

�Table of Contents� TOC \o "1-6" �1. Executive Summary� GOTOBUTTON _Toc368629762 � PAGEREF _Toc368629762 �1-1��1.1 Statement of the Problem� GOTOBUTTON _Toc368629763 � PAGEREF _Toc368629763 �1-1��1.2 The Critical Interfaces Project� GOTOBUTTON _Toc368629764 � PAGEREF _Toc368629764 �1-1��1.3 The Critical Interfaces� GOTOBUTTON _Toc368629765 � PAGEREF _Toc368629765 �1-2��1.3.1 Hardware� GOTOBUTTON _Toc368629766 � PAGEREF _Toc368629766 �1-2��1.3.2 Software� GOTOBUTTON _Toc368629767 � PAGEREF _Toc368629767 �1-3��1.4 Selected Critical Interface Candidates� GOTOBUTTON _Toc368629768 � PAGEREF _Toc368629768 �1-5��1.4.1 Hardware� GOTOBUTTON _Toc368629769 � PAGEREF _Toc368629769 �1-6��1.4.2 Software� GOTOBUTTON _Toc368629770 � PAGEREF _Toc368629770 �1-6��1.5 Recommendations for Further Research� GOTOBUTTON _Toc368629771 � PAGEREF _Toc368629771 �1-7��1.5.1 Hardware� GOTOBUTTON _Toc368629772 � PAGEREF _Toc368629772 �1-7��1.5.2 Software� GOTOBUTTON _Toc368629773 � PAGEREF _Toc368629773 �1-7��2. Introduction� GOTOBUTTON _Toc368629774 � PAGEREF _Toc368629774 �2-1��2.1 Purpose� GOTOBUTTON _Toc368629775 � PAGEREF _Toc368629775 �2-1��2.2 Background� GOTOBUTTON _Toc368629776 � PAGEREF _Toc368629776 �2-1��3. Programmatics� GOTOBUTTON _Toc368629777 � PAGEREF _Toc368629777 �3-1��3.1 Organization� GOTOBUTTON _Toc368629786 � PAGEREF _Toc368629786 �3-1��3.2 Objectives� GOTOBUTTON _Toc368629787 � PAGEREF _Toc368629787 �3-1��3.3 Process� GOTOBUTTON _Toc368629788 � PAGEREF _Toc368629788 �3-2��3.4 Scope� GOTOBUTTON _Toc368629789 � PAGEREF _Toc368629789 �3-3��3.5 Technical Approach� GOTOBUTTON _Toc368629790 � PAGEREF _Toc368629790 �3-3��4. Hardware� GOTOBUTTON _Toc368629791 � PAGEREF _Toc368629791 �4-1��4.1 Hardware Interfaces� GOTOBUTTON _Toc368629792 � PAGEREF _Toc368629792 �4-1��4.2 Hardware Decomposition� GOTOBUTTON _Toc368629793 � PAGEREF _Toc368629793 �4-1��4.3 Definitions of Potentially Critical Hardware Interfaces� GOTOBUTTON _Toc368629794 � PAGEREF _Toc368629794 �4-3��4.3.1 Computer Asset Controller Interface� GOTOBUTTON _Toc368629795 � PAGEREF _Toc368629795 �4-3��4.3.2 Computer to External Environments Interface� GOTOBUTTON _Toc368629796 � PAGEREF _Toc368629796 �4-3��4.3.3 Host Computer Interface� GOTOBUTTON _Toc368629797 � PAGEREF _Toc368629797 �4-3��4.3.4 Instrument Control Bus Interface� GOTOBUTTON _Toc368629798 � PAGEREF _Toc368629798 �4-3��4.3.5 Receiver/Fixture Interface� GOTOBUTTON _Toc368629799 � PAGEREF _Toc368629799 �4-3��4.3.6 Switching Matrix Interface� GOTOBUTTON _Toc368629800 � PAGEREF _Toc368629800 �4-3��4.3.7 Hardware Interface Criticality Evaluation� GOTOBUTTON _Toc368629801 � PAGEREF _Toc368629801 �4-3��4.4 Recommended Hardware Critical Interfaces� GOTOBUTTON _Toc368629802 � PAGEREF _Toc368629802 �4-5��4.4.1 Computer to External Environments Interface� GOTOBUTTON _Toc368629803 � PAGEREF _Toc368629803 �4-5��4.4.1.1 Computer to External Environments Candidates� GOTOBUTTON _Toc368629804 � PAGEREF _Toc368629804 �4-5��4.4.1.2 Computer to External Environments Recommendations and Rationale� GOTOBUTTON _Toc368629805 � PAGEREF _Toc368629805 �4-5��4.4.2 Switching Matrix Interface� GOTOBUTTON _Toc368629806 � PAGEREF _Toc368629806 �4-5��4.4.2.1 Decomposition� GOTOBUTTON _Toc368629807 � PAGEREF _Toc368629807 �4-5��4.4.2.2 Requirements and Issues Considered� GOTOBUTTON _Toc368629808 � PAGEREF _Toc368629808 �4-6��4.4.2.3 General Requirements� GOTOBUTTON _Toc368629809 � PAGEREF _Toc368629809 �4-7��4.4.2.4 Current Government ATE Requirements� GOTOBUTTON _Toc368629810 � PAGEREF _Toc368629810 �4-8��4.4.2.4.1 Programmable DC Power Supplies� GOTOBUTTON _Toc368629811 � PAGEREF _Toc368629811 �4-8��4.4.2.4.2 Programmable DC Loads� GOTOBUTTON _Toc368629812 � PAGEREF _Toc368629812 �4-10��4.4.2.4.3 AC Power Supply Requirements� GOTOBUTTON _Toc368629813 � PAGEREF _Toc368629813 �4-10��4.4.2.4.4 Summary Power Supply Requirements� GOTOBUTTON _Toc368629814 � PAGEREF _Toc368629814 �4-11��4.4.2.4.5 Digital I/O Capabilities� GOTOBUTTON _Toc368629815 � PAGEREF _Toc368629815 �4-12��4.4.2.4.6 Analog Instrumentation Requirements� GOTOBUTTON _Toc368629816 � PAGEREF _Toc368629816 �4-12��4.4.2.4.7 Analog Instrumentation Requirements Summary� GOTOBUTTON _Toc368629817 � PAGEREF _Toc368629817 �4-15��4.4.2.4.8 Power Switch Matrix Requirements� GOTOBUTTON _Toc368629818 � PAGEREF _Toc368629818 �4-16��4.4.2.4.9 Low Frequency Switch Matrix Requirements� GOTOBUTTON _Toc368629819 � PAGEREF _Toc368629819 �4-16��4.4.2.4.10 Performance Switch Matrix Requirements� GOTOBUTTON _Toc368629820 � PAGEREF _Toc368629820 �4-17��4.4.2.4.11 ATS Summary Core Capability� GOTOBUTTON _Toc368629821 � PAGEREF _Toc368629821 �4-18��4.4.2.4.12 Connector Module Requirements Summary� GOTOBUTTON _Toc368629822 � PAGEREF _Toc368629822 �4-18��4.4.2.5 Switching Matrix Recommendations and Rationale� GOTOBUTTON _Toc368629823 � PAGEREF _Toc368629823 �4-19��4.4.2.5.1 General� GOTOBUTTON _Toc368629824 � PAGEREF _Toc368629824 �4-19��4.4.2.5.2 Switching Matrix Building Block Configuration� GOTOBUTTON _Toc368629825 � PAGEREF _Toc368629825 �4-21��4.4.3 Receiver/Fixture Interface� GOTOBUTTON _Toc368629826 � PAGEREF _Toc368629826 �4-21��4.4.3.1 Decomposition� GOTOBUTTON _Toc368629827 � PAGEREF _Toc368629827 �4-21��4.4.3.2 Subelement Review� GOTOBUTTON _Toc368629828 � PAGEREF _Toc368629828 �4-23��4.4.3.3 Requirements and Alternatives Considered� GOTOBUTTON _Toc368629829 � PAGEREF _Toc368629829 �4-24��4.4.3.3.1 Receiver Trade-Offs� GOTOBUTTON _Toc368629830 � PAGEREF _Toc368629830 �4-24��4.4.3.3.2 Receiver - Resource Interface Alternatives� GOTOBUTTON _Toc368629831 � PAGEREF _Toc368629831 �4-25��4.4.3.3.2.1 Receiver Mechanisms� GOTOBUTTON _Toc368629832 � PAGEREF _Toc368629832 �4-27��4.4.3.3.2.2 Receiver Framework Design� GOTOBUTTON _Toc368629833 � PAGEREF _Toc368629833 �4-28��4.4.3.3.2.3 Receiver Mechanical Advantage� GOTOBUTTON _Toc368629834 � PAGEREF _Toc368629834 �4-28��4.4.3.3.3 Fixture Product Design Alternatives� GOTOBUTTON _Toc368629835 � PAGEREF _Toc368629835 �4-29��4.4.3.3.4 General Requirements� GOTOBUTTON _Toc368629836 � PAGEREF _Toc368629836 �4-30��4.4.3.3.4.1 Design General Objectives� GOTOBUTTON _Toc368629837 � PAGEREF _Toc368629837 �4-30��4.4.3.3.4.2 Design Performance Objectives� GOTOBUTTON _Toc368629838 � PAGEREF _Toc368629838 �4-31��4.4.3.3.4.3 Receiver/Fixture Building Block I/O Requirements� GOTOBUTTON _Toc368629839 � PAGEREF _Toc368629839 �4-31��4.4.3.3.4.4 Receiver/Fixture Connector Requirements� GOTOBUTTON _Toc368629840 � PAGEREF _Toc368629840 �4-32��4.4.3.4 Receiver/Fixture Recommendations and Rationale� GOTOBUTTON _Toc368629841 � PAGEREF _Toc368629841 �4-35��4.4.3.4.1 Subelement Review� GOTOBUTTON _Toc368629842 � PAGEREF _Toc368629842 �4-35��4.4.3.4.2 Connector Review and Weighting Process� GOTOBUTTON _Toc368629843 � PAGEREF _Toc368629843 �4-37��4.4.3.4.2.1 Connector/Module Review Candidates� GOTOBUTTON _Toc368629844 � PAGEREF _Toc368629844 �4-37��4.4.3.4.2.2 Connector and Contacts� GOTOBUTTON _Toc368629845 � PAGEREF _Toc368629845 �4-39��4.4.3.4.2.3 Eurocard DIN Standard� GOTOBUTTON _Toc368629846 � PAGEREF _Toc368629846 �4-40��4.4.3.4.2.4 Mixed Low/High Power Contacts and Connector Module� GOTOBUTTON _Toc368629847 � PAGEREF _Toc368629847 �4-45��4.4.3.4.2.5 Low RF Coax Commercial Contacts and Connector Module� GOTOBUTTON _Toc368629848 � PAGEREF _Toc368629848 �4-45��4.4.3.4.2.6 High Performance RF Coax Contacts and Connector Module� GOTOBUTTON _Toc368629849 � PAGEREF _Toc368629849 �4-46��4.4.3.5 Receiver/Fixture Mechanism Review and Weighting Process� GOTOBUTTON _Toc368629850 � PAGEREF _Toc368629850 �4-47��4.4.3.5.1 Introduction� GOTOBUTTON _Toc368629851 � PAGEREF _Toc368629851 �4-47��4.4.3.5.2 Receiver/Fixture Mechanism Candidates� GOTOBUTTON _Toc368629852 � PAGEREF _Toc368629852 �4-47��4.4.3.5.2.1 Critical Issues of the Selection Process� GOTOBUTTON _Toc368629853 � PAGEREF _Toc368629853 �4-47��4.4.3.5.2.2 Level of Applicability� GOTOBUTTON _Toc368629854 � PAGEREF _Toc368629854 �4-48��4.4.3.5.2.3 Open System Architecture� GOTOBUTTON _Toc368629855 � PAGEREF _Toc368629855 �4-48��4.4.3.5.2.4 Scaleability� GOTOBUTTON _Toc368629856 � PAGEREF _Toc368629856 �4-48��4.4.3.5.3 Receiver/Fixture Mechanism Results� GOTOBUTTON _Toc368629857 � PAGEREF _Toc368629857 �4-48��4.4.3.5.4 Receiver/Fixture Mechanisms Long Term Solution� GOTOBUTTON _Toc368629858 � PAGEREF _Toc368629858 �4-50��4.4.3.5.5 Receiver/Fixture Mechanisms Short Term Solution� GOTOBUTTON _Toc368629859 � PAGEREF _Toc368629859 �4-50��4.4.3.6 Fixture Enclosures Review and Weighting Process� GOTOBUTTON _Toc368629860 � PAGEREF _Toc368629860 �4-51��4.4.3.6.1 Fixture Enclosure and Internal Packaging Structure Review Candidates� GOTOBUTTON _Toc368629861 � PAGEREF _Toc368629861 �4-52��4.4.3.6.2 Fixture Enclosures� GOTOBUTTON _Toc368629862 � PAGEREF _Toc368629862 �4-53��4.4.3.6.3 Internal Packaging Review and Weighting Process.� GOTOBUTTON _Toc368629863 � PAGEREF _Toc368629863 �4-53��4.4.3.7 Receiver/Fixture Pin Map Evaluation� GOTOBUTTON _Toc368629864 � PAGEREF _Toc368629864 �4-53��5. Software� GOTOBUTTON _Toc368629865 � PAGEREF _Toc368629865 �5-1��5.1 Software Decomposition� GOTOBUTTON _Toc368629866 � PAGEREF _Toc368629866 �5-1��5.2 Run Time Interfaces� GOTOBUTTON _Toc368629867 � PAGEREF _Toc368629867 �5-3��5.2.1 Data Networking� GOTOBUTTON _Toc368629868 � PAGEREF _Toc368629868 �5-3��5.2.1.1 Data Networking Candidates� GOTOBUTTON _Toc368629869 � PAGEREF _Toc368629869 �5-4��5.2.1.2 Data Networking Recommendations and Rationale� GOTOBUTTON _Toc368629870 � PAGEREF _Toc368629870 �5-4��5.2.2 Instrument Communication� GOTOBUTTON _Toc368629871 � PAGEREF _Toc368629871 �5-4��5.2.2.1 Generic Instrument Classes� GOTOBUTTON _Toc368629872 � PAGEREF _Toc368629872 �5-4��5.2.2.1.1 Generic Instrument Classes Candidates� GOTOBUTTON _Toc368629873 � PAGEREF _Toc368629873 �5-4��5.2.2.1.2 Generic Instrument Classes Recommendations and Rationale� GOTOBUTTON _Toc368629874 � PAGEREF _Toc368629874 �5-5��5.2.2.2 Instrument Command Language� GOTOBUTTON _Toc368629875 � PAGEREF _Toc368629875 �5-5��5.2.2.2.1 Instrument Command Language Candidates� GOTOBUTTON _Toc368629876 � PAGEREF _Toc368629876 �5-5��5.2.2.2.1.1 Control Interface Intermediate Language� GOTOBUTTON _Toc368629877 � PAGEREF _Toc368629877 �5-5��5.2.2.2.1.2 Standard Commands for Programmable Instruments� GOTOBUTTON _Toc368629878 � PAGEREF _Toc368629878 �5-5��5.2.2.2.2 Instrument Command Language Recommendations and Rationale� GOTOBUTTON _Toc368629879 � PAGEREF _Toc368629879 �5-5��5.2.2.3 Instrument Communication Manager� GOTOBUTTON _Toc368629880 � PAGEREF _Toc368629880 �5-6��5.2.2.3.1 Instrument Communication Manager Candidates� GOTOBUTTON _Toc368629881 � PAGEREF _Toc368629881 �5-6��5.2.2.3.1.1 Virtual Instrument Software Architecture� GOTOBUTTON _Toc368629882 � PAGEREF _Toc368629882 �5-7��5.2.2.3.1.2 IEEE P1226.5� GOTOBUTTON _Toc368629883 � PAGEREF _Toc368629883 �5-7��5.2.2.3.2 Instrument Communication Manager Recommendations and Rationale� GOTOBUTTON _Toc368629884 � PAGEREF _Toc368629884 �5-7��5.2.2.4 Instrument Driver API� GOTOBUTTON _Toc368629885 � PAGEREF _Toc368629885 �5-7��5.2.2.4.1 Instrument Driver API Candidates� GOTOBUTTON _Toc368629886 � PAGEREF _Toc368629886 �5-7��5.2.2.4.1.1 VPP-3� GOTOBUTTON _Toc368629887 � PAGEREF _Toc368629887 �5-8��5.2.2.4.1.2 IEEE P1226.4� GOTOBUTTON _Toc368629888 � PAGEREF _Toc368629888 �5-9��5.2.2.4.1.3 ATLAS Intermediate Language� GOTOBUTTON _Toc368629889 � PAGEREF _Toc368629889 �5-9��5.2.2.4.1.4 Test Resource Information Model� GOTOBUTTON _Toc368629890 � PAGEREF _Toc368629890 �5-10��5.2.2.4.1.5 Instrument Command Languages� GOTOBUTTON _Toc368629891 � PAGEREF _Toc368629891 �5-10��5.2.2.4.1.6 Driver API plus Instrument Command Languages Hybrids� GOTOBUTTON _Toc368629892 � PAGEREF _Toc368629892 �5-10��5.2.2.4.2 Instrument Driver API Recommendations and Rationale� GOTOBUTTON _Toc368629893 � PAGEREF _Toc368629893 �5-10��5.2.3 Software and Software Coordination Interfaces� GOTOBUTTON _Toc368629894 � PAGEREF _Toc368629894 �5-11��5.2.3.1 Diagnostic Processing� GOTOBUTTON _Toc368629895 � PAGEREF _Toc368629895 �5-11��5.2.3.1.1 Diagnostic Processing Candidates� GOTOBUTTON _Toc368629896 � PAGEREF _Toc368629896 �5-11��5.2.3.1.2 Diagnostic Processing Recommendations and Rationale� GOTOBUTTON _Toc368629897 � PAGEREF _Toc368629897 �5-11��5.2.3.2 Framework� GOTOBUTTON _Toc368629898 � PAGEREF _Toc368629898 �5-11��5.2.3.2.1 Framework Candidates� GOTOBUTTON _Toc368629899 � PAGEREF _Toc368629899 �5-13��5.2.3.2.2 Framework Recommendations and Rationale� GOTOBUTTON _Toc368629900 � PAGEREF _Toc368629900 �5-14��5.2.3.3 Multimedia Formats� GOTOBUTTON _Toc368629901 � PAGEREF _Toc368629901 �5-15��5.2.3.3.1 Multimedia Formats Candidates� GOTOBUTTON _Toc368629902 � PAGEREF _Toc368629902 �5-16��5.2.3.3.1.1 Commercial and Proprietary Formats� GOTOBUTTON _Toc368629903 � PAGEREF _Toc368629903 �5-16��5.2.3.3.1.2 World Wide Web Formats� GOTOBUTTON _Toc368629904 � PAGEREF _Toc368629904 �5-16��5.2.3.3.1.3 Standards Based Formats� GOTOBUTTON _Toc368629905 � PAGEREF _Toc368629905 �5-17��5.2.3.3.2 Multimedia Formats Recommendations and Rationale� GOTOBUTTON _Toc368629906 � PAGEREF _Toc368629906 �5-17��5.2.3.4 Run Time Services� GOTOBUTTON _Toc368629907 � PAGEREF _Toc368629907 �5-17��5.2.3.4.1 Run Time Services Candidates� GOTOBUTTON _Toc368629908 � PAGEREF _Toc368629908 �5-18��5.2.3.4.1.1 ATLAS Intermediate Language� GOTOBUTTON _Toc368629909 � PAGEREF _Toc368629909 �5-18��5.2.3.4.1.2 ABBET Standards Related to Run Time Services� GOTOBUTTON _Toc368629910 � PAGEREF _Toc368629910 �5-18��5.2.3.4.2 Run Time Services Recommendations and Rationale� GOTOBUTTON _Toc368629911 � PAGEREF _Toc368629911 �5-18��5.2.3.5 Test Program to Operating System� GOTOBUTTON _Toc368629912 � PAGEREF _Toc368629912 �5-18��5.2.3.5.1 Test Program to Operating System Candidates� GOTOBUTTON _Toc368629913 � PAGEREF _Toc368629913 �5-18��5.2.3.5.2 Test Program to Operating System Recommendations and Rationale� GOTOBUTTON _Toc368629914 � PAGEREF _Toc368629914 �5-19��5.3 Development Interfaces� GOTOBUTTON _Toc368629915 � PAGEREF _Toc368629915 �5-19��5.3.1 Application Development Environments� GOTOBUTTON _Toc368629916 � PAGEREF _Toc368629916 �5-19��5.3.1.1 Text-based Application Development Environments� GOTOBUTTON _Toc368629917 � PAGEREF _Toc368629917 �5-19��5.3.1.2 Graphical Application Development Environments� GOTOBUTTON _Toc368629918 � PAGEREF _Toc368629918 �5-19��5.3.1.3 Hybrid Application Development Environments� GOTOBUTTON _Toc368629919 � PAGEREF _Toc368629919 �5-20��5.3.1.4 Desirable Characteristics in an Application Development Environments� GOTOBUTTON _Toc368629920 � PAGEREF _Toc368629920 �5-20��5.3.1.5 Application Development Environments Candidates� GOTOBUTTON _Toc368629921 � PAGEREF _Toc368629921 �5-21��5.3.1.6 Application Development Environments Recommendations and Rationale� GOTOBUTTON _Toc368629922 � PAGEREF _Toc368629922 �5-21��5.3.2 Digital Test Data Formats� GOTOBUTTON _Toc368629923 � PAGEREF _Toc368629923 �5-21��5.3.2.1 Logic Values� GOTOBUTTON _Toc368629924 � PAGEREF _Toc368629924 �5-22��5.3.2.2 Patterns� GOTOBUTTON _Toc368629925 � PAGEREF _Toc368629925 �5-22��5.3.2.3 Relevancy� GOTOBUTTON _Toc368629926 � PAGEREF _Toc368629926 �5-22��5.3.2.4 Timing� GOTOBUTTON _Toc368629927 � PAGEREF _Toc368629927 �5-22��5.3.2.5 Levels� GOTOBUTTON _Toc368629928 � PAGEREF _Toc368629928 �5-23��5.3.2.6 Compression� GOTOBUTTON _Toc368629929 � PAGEREF _Toc368629929 �5-23��5.3.2.7 Diagnostics� GOTOBUTTON _Toc368629930 � PAGEREF _Toc368629930 �5-23��5.3.2.8 Models� GOTOBUTTON _Toc368629931 � PAGEREF _Toc368629931 �5-24��5.3.2.9 Digital Test Data Format Candidates� GOTOBUTTON _Toc368629932 � PAGEREF _Toc368629932 �5-24��5.3.2.9.1 Commercial Formats� GOTOBUTTON _Toc368629933 � PAGEREF _Toc368629933 �5-24��5.3.2.9.1.1 Standard Event Format� GOTOBUTTON _Toc368629934 � PAGEREF _Toc368629934 �5-24��5.3.2.9.1.2 Waveform Generation Language� GOTOBUTTON _Toc368629935 � PAGEREF _Toc368629935 �5-25��5.3.2.9.1.3 LSRTAP (SDF)� GOTOBUTTON _Toc368629936 � PAGEREF _Toc368629936 �5-25��5.3.2.9.2 Standards-based Formats� GOTOBUTTON _Toc368629937 � PAGEREF _Toc368629937 �5-25��5.3.2.9.2.1 IEEE Std 1029.1-1989� GOTOBUTTON _Toc368629938 � PAGEREF _Toc368629938 �5-25��5.3.2.9.2.2 IEEE P1445 Digital Test Interchange Format� GOTOBUTTON _Toc368629939 � PAGEREF _Toc368629939 �5-25��5.3.2.9.2.3 IEEE P1450 Standard Test Interchange Language� GOTOBUTTON _Toc368629940 � PAGEREF _Toc368629940 �5-25��5.3.2.10 Digital Test Data Format Recommendations and Rationale� GOTOBUTTON _Toc368629941 � PAGEREF _Toc368629941 �5-25��5.3.3 ATE and UUT Information Interfaces� GOTOBUTTON _Toc368629942 � PAGEREF _Toc368629942 �5-26��5.3.3.1 Adapter Function and Parametric Data� GOTOBUTTON _Toc368629943 � PAGEREF _Toc368629943 �5-26��5.3.3.2 ATE Instrument Function and Parametric Data� GOTOBUTTON _Toc368629944 � PAGEREF _Toc368629944 �5-27��5.3.3.3 ATE Switching Function and Parametric Data� GOTOBUTTON _Toc368629945 � PAGEREF _Toc368629945 �5-27��5.3.3.4 UUT Test Requirements� GOTOBUTTON _Toc368629946 � PAGEREF _Toc368629946 �5-27��5.3.3.5 Information Interface Candidates� GOTOBUTTON _Toc368629947 � PAGEREF _Toc368629947 �5-28��5.3.3.5.1 Documentation� GOTOBUTTON _Toc368629948 � PAGEREF _Toc368629948 �5-28��5.3.3.5.2 ATLAS Compiler (e.g., TYX, ARINC SMART) Databases� GOTOBUTTON _Toc368629949 � PAGEREF _Toc368629949 �5-28��5.3.3.5.3 ATLAS Language� GOTOBUTTON _Toc368629950 � PAGEREF _Toc368629950 �5-29��5.3.3.5.4 CAD/CAM Formats� GOTOBUTTON _Toc368629951 � PAGEREF _Toc368629951 �5-29��5.3.3.5.5 Test Resource Information Model� GOTOBUTTON _Toc368629952 � PAGEREF _Toc368629952 �5-29��5.3.3.5.6 VPP-5 Expanded to Include Parametric Data� GOTOBUTTON _Toc368629953 � PAGEREF _Toc368629953 �5-30��5.3.3.6 Information Interface Recommendations and Rationale� GOTOBUTTON _Toc368629954 � PAGEREF _Toc368629954 �5-30��5.3.4 TPS Documentation� GOTOBUTTON _Toc368629955 � PAGEREF _Toc368629955 �5-30��5.3.4.1 TPS Documentation Candidates� GOTOBUTTON _Toc368629956 � PAGEREF _Toc368629956 �5-30��5.3.4.2 TPS Documentation Recommendations and Rationale� GOTOBUTTON _Toc368629957 � PAGEREF _Toc368629957 �5-31��6. Recommendations for Further Research� GOTOBUTTON _Toc368629958 � PAGEREF _Toc368629958 �6-1��6.1 Hardware Issues� GOTOBUTTON _Toc368629959 � PAGEREF _Toc368629959 �6-1��6.2 Software Issues� GOTOBUTTON _Toc368629960 � PAGEREF _Toc368629960 �6-1��6.2.1 AFP, IFP, and SFP Interfaces� GOTOBUTTON _Toc368629961 � PAGEREF _Toc368629961 �6-1��6.2.2 Diagnostic Processing� GOTOBUTTON _Toc368629962 � PAGEREF _Toc368629962 �6-2��6.2.3 Generic Instrument Classes� GOTOBUTTON _Toc368629963 � PAGEREF _Toc368629963 �6-2��6.2.4 Run Time Services� GOTOBUTTON _Toc368629964 � PAGEREF _Toc368629964 �6-2��6.2.5 Test Program Documentation� GOTOBUTTON _Toc368629965 � PAGEREF _Toc368629965 �6-2��6.2.6 UUT Test Requirements� GOTOBUTTON _Toc368629966 � PAGEREF _Toc368629966 �6-2��6.2.7 Convergence of Information Interfaces� GOTOBUTTON _Toc368629967 � PAGEREF _Toc368629967 �6-2��7. Summary� GOTOBUTTON _Toc368629968 � PAGEREF _Toc368629968 �7-1��7.1 Conclusions Dealing with Hardware Interfaces� GOTOBUTTON _Toc368629969 � PAGEREF _Toc368629969 �7-1��7.2 Conclusions Dealing with Software Interfaces� GOTOBUTTON _Toc368629970 � PAGEREF _Toc368629970 �7-2��8. Perry Memorandum� GOTOBUTTON _Toc368629971 � PAGEREF _Toc368629971 �8-1��9. Glossary� GOTOBUTTON _Toc368629972 � PAGEREF _Toc368629972 �9-1��10. Acronyms and Abbreviations� GOTOBUTTON _Toc368629973 � PAGEREF _Toc368629973 �10-1��11. Critical Interfaces Working Group Members� GOTOBUTTON _Toc368629974 � PAGEREF _Toc368629974 �11-1����List of Tables� TOC \c "Table" �Table 1 Hardware Critical Interfaces� GOTOBUTTON _Toc368629975 � PAGEREF _Toc368629975 �1-3��Table 2 Software Critical Interfaces� GOTOBUTTON _Toc368629976 � PAGEREF _Toc368629976 �1-4��Table 3 Hardware Critical Interface Candidates� GOTOBUTTON _Toc368629977 � PAGEREF _Toc368629977 �1-6��Table 4 Software Critical Interface Candidates� GOTOBUTTON _Toc368629978 � PAGEREF _Toc368629978 �1-6��Table 5 Critical Interfaces Standardization Guidelines� GOTOBUTTON _Toc368629979 � PAGEREF _Toc368629979 �1-8��Table 6 Hardware Interfaces Summary Matrix� GOTOBUTTON _Toc368629980 � PAGEREF _Toc368629980 �4-2��Table 7 DoD ATS Programmable DC Power Supply Configurations� GOTOBUTTON _Toc368629981 � PAGEREF _Toc368629981 �4-9��Table 8 DoD ATS Programmable DC Load Configurations� GOTOBUTTON _Toc368629982 � PAGEREF _Toc368629982 �4-10��Table 9 DoD ATS AC Power Supply Configurations� GOTOBUTTON _Toc368629983 � PAGEREF _Toc368629983 �4-11��Table 10 DoD ATS Digital I/O Capabilities� GOTOBUTTON _Toc368629984 � PAGEREF _Toc368629984 �4-12��Table 11 DoD ATS Analog Instrumentation Descriptions� GOTOBUTTON _Toc368629985 � PAGEREF _Toc368629985 �4-13��Table 12 DoD ATS Analog Instrumentation Requirements� GOTOBUTTON _Toc368629986 � PAGEREF _Toc368629986 �4-15��Table 13 DoD ATS Power Switch Matrix Requirements� GOTOBUTTON _Toc368629987 � PAGEREF _Toc368629987 �4-16��Table 14 DoD ATS Low Frequency Switch Matrix Requirements� GOTOBUTTON _Toc368629988 � PAGEREF _Toc368629988 �4-16��Table 15 Performance Switch Matrix Requirements� GOTOBUTTON _Toc368629989 � PAGEREF _Toc368629989 �4-17��Table 16 DoD ATS Connector Module Requirements� GOTOBUTTON _Toc368629990 � PAGEREF _Toc368629990 �4-18��Table 17 Worst Case - High End Requirements� GOTOBUTTON _Toc368629991 � PAGEREF _Toc368629991 �4-32��Table 18 Typical - Mid Range Requirements� GOTOBUTTON _Toc368629992 � PAGEREF _Toc368629992 �4-32��Table 19 Basic - Low End Requirements� GOTOBUTTON _Toc368629993 � PAGEREF _Toc368629993 �4-32��Table 20 Signal Contact Requirement� GOTOBUTTON _Toc368629994 � PAGEREF _Toc368629994 �4-33��Table 21 High Power Contact Requirement� GOTOBUTTON _Toc368629995 � PAGEREF _Toc368629995 �4-33��Table 22 Low Power Contact Requirement� GOTOBUTTON _Toc368629996 � PAGEREF _Toc368629996 �4-34��Table 23 Low RF Coax Contact Requirement� GOTOBUTTON _Toc368629997 � PAGEREF _Toc368629997 �4-34��Table 24 High RF Coax Contact Requirement� GOTOBUTTON _Toc368629998 � PAGEREF _Toc368629998 �4-35��Table 25 Receiver/Fixture Connector Product Design Comparison� GOTOBUTTON _Toc368629999 � PAGEREF _Toc368629999 �4-38��Table 26 Eurocard DIN Comparison - Part 1� GOTOBUTTON _Toc368630000 � PAGEREF _Toc368630000 �4-42��Table 27 Eurocard DIN Comparison - Part 2� GOTOBUTTON _Toc368630001 � PAGEREF _Toc368630001 �4-43��Table 28 Receiver/Fixture Mechanism Product Design Review� GOTOBUTTON _Toc368630002 � PAGEREF _Toc368630002 �4-49��Table 29 Fixture Internal Packaging Product Review Comparison Chart� GOTOBUTTON _Toc368630003 � PAGEREF _Toc368630003 �4-52��Table 30 Possible Pin Map Configuration and Related Test Requirements for DoD ATS� GOTOBUTTON _Toc368630004 � PAGEREF _Toc368630004 �4-55��Table 31 Critical Interfaces Standardization Guidelines� GOTOBUTTON _Toc368630005 � PAGEREF _Toc368630005 �6-1��Table 32 Hardware Critical Interfaces (Summary)� GOTOBUTTON _Toc368630006 � PAGEREF _Toc368630006 �7-1��Table 33 Software Critical Interfaces (Summary)� GOTOBUTTON _Toc368630007 � PAGEREF _Toc368630007 �7-2����List of Figures� TOC \c "Figure" �Figure 1 ATS Hardware Interfaces� GOTOBUTTON _Toc368630008 � PAGEREF _Toc368630008 �1-2��Figure 2 TPS Development Interfaces� GOTOBUTTON _Toc368630009 � PAGEREF _Toc368630009 �1-3��Figure 3 TPS Run Time Interfaces� GOTOBUTTON _Toc368630010 � PAGEREF _Toc368630010 �1-4��Figure 4 Example ATS Interfaces� GOTOBUTTON _Toc368630011 � PAGEREF _Toc368630011 �2-2��Figure 5 CIWG Organization� GOTOBUTTON _Toc368630012 � PAGEREF _Toc368630012 �3-1��Figure 6 CIWG Process� GOTOBUTTON _Toc368630013 � PAGEREF _Toc368630013 �3-2��Figure 7 Generic ATS Architecture� GOTOBUTTON _Toc368630014 � PAGEREF _Toc368630014 �3-4��Figure 8 CASS Hardware Architecture� GOTOBUTTON _Toc368630015 � PAGEREF _Toc368630015 �3-5��Figure 9 CASS Software Architecture� GOTOBUTTON _Toc368630016 � PAGEREF _Toc368630016 �3-6��Figure 10 IFTE Hardware Interfaces� GOTOBUTTON _Toc368630017 � PAGEREF _Toc368630017 �3-7��Figure 11 IFTE Software Interfaces� GOTOBUTTON _Toc368630018 � PAGEREF _Toc368630018 �3-8��Figure 12 ATS Generic Hardware Interfaces� GOTOBUTTON _Toc368630019 � PAGEREF _Toc368630019 �4-2��Figure 13 Test Program Isolation From Host Computer� GOTOBUTTON _Toc368630020 � PAGEREF _Toc368630020 �4-4��Figure 14 Re-host of a TPS� GOTOBUTTON _Toc368630021 � PAGEREF _Toc368630021 �4-4��Figure 15 Switching Matrix Product Designs� GOTOBUTTON _Toc368630022 � PAGEREF _Toc368630022 �4-6��Figure 16 Sample Switch Matrix Configuration #1� GOTOBUTTON _Toc368630023 � PAGEREF _Toc368630023 �4-19��Figure 17 Sample Switch Matrix Configuration #2� GOTOBUTTON _Toc368630024 � PAGEREF _Toc368630024 �4-20��Figure 18 Example Receiver/Fixture ATS Interfaces� GOTOBUTTON _Toc368630025 � PAGEREF _Toc368630025 �4-22��Figure 19 Receiver/Fixture Basic Elements� GOTOBUTTON _Toc368630026 � PAGEREF _Toc368630026 �4-23��Figure 20 Receiver/Fixture Subcomponents� GOTOBUTTON _Toc368630027 � PAGEREF _Toc368630027 �4-24��Figure 21 Receiver Interfacing Approaches� GOTOBUTTON _Toc368630028 � PAGEREF _Toc368630028 �4-25��Figure 22 Receiver Subelements� GOTOBUTTON _Toc368630029 � PAGEREF _Toc368630029 �4-26��Figure 23 Example Mechanical Interface Receivers� GOTOBUTTON _Toc368630030 � PAGEREF _Toc368630030 �4-27��Figure 24 Fixture Basic Design� GOTOBUTTON _Toc368630031 � PAGEREF _Toc368630031 �4-30��Figure 25 Connector/Module Configurations� GOTOBUTTON _Toc368630032 � PAGEREF _Toc368630032 �4-39��Figure 26 Signal Connector/Module Detail� GOTOBUTTON _Toc368630033 � PAGEREF _Toc368630033 �4-40��Figure 27 Eurocard DIN Receiver Connector/Module Design Specification� GOTOBUTTON _Toc368630034 � PAGEREF _Toc368630034 �4-41��Figure 28 Eurocard DIN Fixture Connector/Module Design Specification� GOTOBUTTON _Toc368630035 � PAGEREF _Toc368630035 �4-41��Figure 29 Mixed Low/High Power Contacts and Connector Module Design� GOTOBUTTON _Toc368630036 � PAGEREF _Toc368630036 �4-45��Figure 30 Low Performance RF Coax Commercial Connector Module and Contacts� GOTOBUTTON _Toc368630037 � PAGEREF _Toc368630037 �4-46��Figure 31 High RF Coax Contacts and Connector Module� GOTOBUTTON _Toc368630038 � PAGEREF _Toc368630038 �4-46��Figure 32 Receiver/Fixture Mechanism Design Specification Configuration� GOTOBUTTON _Toc368630039 � PAGEREF _Toc368630039 �4-51��Figure 33 Possible Receiver/Fixture Pin Map Configuration� GOTOBUTTON _Toc368630040 � PAGEREF _Toc368630040 �4-54��Figure 34 TPS Run Time View of Potential Critical Interfaces� GOTOBUTTON _Toc368630041 � PAGEREF _Toc368630041 �5-1��Figure 35 TPS Development Potential Critical Interfaces� GOTOBUTTON _Toc368630042 � PAGEREF _Toc368630042 �5-3��Figure 36 VXIplug&play Instrument Driver Diagram� GOTOBUTTON _Toc368630043 � PAGEREF _Toc368630043 �5-9��Figure 37 System Communication Interfaces� GOTOBUTTON _Toc368630044 � PAGEREF _Toc368630044 �5-12��Figure 38 Product Test Information Flow� GOTOBUTTON _Toc368630045 � PAGEREF _Toc368630045 �6-3����Executive SummaryStatement of the ProblemFrom 1980 to 1992, the U.S. Department of Defense (DoD) investment in depot and factory Automatic Test Systems (ATS) exceeded $35 billion with an additional $15 billion for associated support. Most of this test capability was acquired as part of individual weapon system procurements. This led to a proliferation of different custom equipment types with unique interfaces and made the DoD appear to be a variety of separate customers.Recent policy decisions have changed the direction of the DoD on the purchase of test equipment.DoD ATS Policy, USD (A&T) - 15 March 1996, and DoD Regulation 5000.2-R� bring a cost effective approach to the acquisition of Automatic Test Equipment (ATE). This policy requires hardware and software needs for depot and intermediate-level applications to be met using DoD designated families and commercial equipment with defined interfaces and requires the management of ATS as a separate commodity through a DoD Executive Agent Office (EAO)Secretary of Defense Memorandum on Specifications and Standards - 29 June 1994, directs that DoD procurements will be made first by performance definition, second by commercial standards, and finally (and only with waiver) by military standardsThe DoD Regulation 5000.2-R ATS Policy states: “ATS capabilities shall be defined through critical hardware and software elements.” The policy does not currently define these critical elements. The Critical Interfaces Project was created to define critical ATS elements.The Critical Interfaces ProjectThe Factory-to-Field Integration of Defense Test Systems Project (commonly referred to as the Critical Interfaces Project) was started in the latter part of 1995. The Critical Interfaces Working Group (CIWG) within the Joint-Service ATS Research and Development Integrated Product Team (ARI) was established to perform the project. The ATS EAO has provided project management and coordination among the Air Force, Army, Marine Corps, and Navy participants. In addition, many industry representatives have participated.The objective of the Critical Interfaces Project is to demonstrate the feasibility of reducing the cost to re-host Test Program Sets (TPSs) and increase the interoperability of TPS software among the military services by using standardized interfaces. Interfaces that offer the potential to achieve this objective are deemed critical. Potential savings will be quantified through demonstration.The CIWG developed a list of Critical Interfaces (CIs) and will demonstrate the use of these defined CIs on common testers. The three testers selected for demonstration purposes are the defense-designated tester families, the Consolidated Automated Support System (CASS) and the Integrated Family of Test Equipment (IFTE), and a commercial tester, the L300-Series from Teradyne. The interfaces considered are based upon open commercial standards, defacto standards, and DoD tester architectures including the CASS, IFTE, and the Marine Corps Automatic Test Equipment System (MCATES).A primary deliverable product from the CI project is this document setting forth the CI definitions. This document is intended to be used by DoD acquisition programs and maintained by the ATS EAO. This document will aid in satisfying the requirements of DoD Regulation 5000.2-R and assist convergence in migration plans for the DoD designated tester families.The Critical InterfacesHardware� REF _Ref359678726 \* MERGEFORMAT �Figure 1� shows a graphical portrait of the hardware CIs.

�Figure � SEQ Figure \* ARABIC �1� ATS Hardware Interfaces� REF _Ref363453648 \* MERGEFORMAT �Table 1� provides a detailed description of the hardware CIs portrayed in � REF _Ref359678726 \* MERGEFORMAT �Figure 1�.Table � SEQ Table \* ARABIC �1� Hardware Critical InterfacesName�Mnemonic�Description��Computer to External Environments�CXE�Communication path between the computer and external environments such as local area and wide area networks��Receiver/Fixture�RFX�Mechanical and signal interface between the ATE receiver and the fixture ��Switching Matrix�SWM�Switching matrix architecture including signal paths to and from the instruments and receiver/fixture��SoftwareSoftware CIs are outlined in � REF _Ref359678999 \* MERGEFORMAT �Figure 2� and � REF _Ref359565440 \* MERGEFORMAT �Figure 3�. The former displays CIs encountered during TPS development and the latter reflects the run time interfaces active during the execution of the TPS.�Figure � SEQ Figure \* ARABIC �2� TPS Development Interfaces�Figure � SEQ Figure \* ARABIC �3� TPS Run Time InterfacesA description of the software CIs as shown in � REF _Ref359678999 \* MERGEFORMAT �Figure 2� and � REF _Ref359565440 \* MERGEFORMAT �Figure 3� are presented in � REF _Ref359565425 \* MERGEFORMAT �Table 2�.Table � SEQ Table \* ARABIC �2� Software Critical InterfacesName�Mnemonic�Description��Adapter Function and Parametric Data�AFP�The information and formats used to define to the Application Development Environments the capabilities of the test fixture, how the capabilities are accessed, and the associated performance parameters��Diagnostic Processing�DIA�The interface protocol linking execution of a test with software diagnostic processes that analyze the significance of test results and suggest conclusions or additional actions that are required��Instrument Driver API�DRV�The Applications Programming Interface (API) through which instrument drivers accepts commands from and return results to Generic Instrument Classes (GIC).��Digital Test Format�DTF�The data formats used to convey the information used in conjunction with digital tests (e.g., vectors, fault dictionaries) from Digital Test Development Tools to the Application Development Environments.��Framework�FRM�A collection of system requirements, software protocols, and business rules (e.g., software installation) affecting the operation of test software with the underlying Host Computer and Host Operating System.��Generic Instrument Classes�GIC�The Applications Programming Interface (API) through which instrument drivers accept commands from and return results to the test procedure or run time services serving the Test Program.��Instrument Communication Manager�ICM�The interface between the instrument drivers and the Communication Manager that supports communication with instruments independent of the bus or other protocol used (e.g., VXI, IEEE-488.2, RS-232).��Instrument Function and Parametric Data�IFP�The information and formats used to define to the Application Development Environments the load, sense, and drive capabilities of the Instruments, how these capabilities are accessed, and the associated performance parameters.��Multimedia Formats�MMF�The formats used to convey hyperlinked text, audio, video and three-dimensional physical model information from Multimedia Authoring Tools to the Application Development Environments, Application Execution Environment, and Host Framework.��Network Protocols�NET�The protocol used to communicate with external environments over a local area or wide area network. ��Run Time Services�RTS�The run time services needed by Test Programs not handled by the services supplied by the DRV, FRM, GIC and NET interfaces (e.g., error reporting, data logging).��Switch Function and Parametric Data�SFP�The information and formats used to define to the Application Development Environments the interconnect capabilities of the Switch Matrix, how these capabilities are accessed, and the associated performance parameters.��Test Program to Operating System�TOS�Calls to the Host Operating System made directly from the Test Program.��Test ProgramDocumentation�TPD�Human-understandable representations of information about the TPS for use by the TPS maintainer.��UUT Test Requirements�UTR�The information and formats used to define to the Application Development Environments the load, sense, and drive capabilities that must be applied to the UUT to test it, including the minimum performance required for a successful test.��Selected Critical Interface CandidatesPriority was given to formal or defacto commercial standards in selecting candidates for CIs. The effectiveness of these candidates will be evaluated during the demonstration phase. If the demonstration concludes that these candidates are effective at reducing the cost of a TPS re-host and increasing the interoperability of TPSs among the military services, they will be recommended by the ARI to the ATS EAO for inclusion into DoD acquisition guidelines.HardwareThe hardware CIs and the selected candidates are presented in � REF _Ref364085678 \* MERGEFORMAT �Table 3�.Table � SEQ Table \* ARABIC �3� Hardware Critical Interface CandidatesCritical Interface�Mnemonic�Candidate��Computer to External Environments�CXE�Any hardware capable of supporting TCP/IP��Receiver/Fixture�RFX���Fixture Frame Mechanisms��None��Receiver Mechanisms��None��Contacts and Connector Module����Signal��200 position Eurocard DIN standard��Low power��None��High power��None��Low RF��None��High RF��None��Pin Map and connector/slot definition��None��Switching Matrix�SWM���Switch Module��None��SoftwareThe software CIs for which available candidates were selected are presented in Table 4.Table � SEQ Table \* ARABIC �4� Software Critical Interface CandidatesCritical Interface�Mnemonic�Candidate��Adapter Function and Parametric Data�AFP�None��Diagnostic Processing�DIA�None��Instrument Driver ADE�DRV�VPP-32The ADE shall communicate with instruments through VPP-3 instrument drivers��Digital Test Format�DTF�LSRTAP (SDF)��Framework ADE�FRM�VPP-22The ADE shall be compatible with at least one framework in VPP-2. Cross platform compatibility is preferred.��Generic Instrument Classes�GIC�None��Instrument Communication Manager�ICM�VPP-4���Instrument Function and Parametric Data�IFP�None��Multimedia Formats�MMF�None��Network Protocols�NET�TCP/IP (IAB STD 1)��Run Time Services�RTS�None��Switch Function and Parametric Data�SFP�None��Test Program to Operating System�TOS�Calls to the Host Operating System prohibited��Test Program Documentation�TPD�DI-ATTS-80284A and DI-ATTS-80285A (and DI-ATTS-80285 if need for CFAT exists) in HTML 3.0 format��UUT Test Requirements�UTR�None��Recommendations for Further ResearchSatisfactory standards are not available for several of the CIs. These CIs are described in the following sections. The CIWG recommends these be given high priority for future ARI efforts.HardwareThe discussions and analysis of the hardware interfaces identified two areas needing additional research: portions of the RFX and portions of the SWM architecture. The CIWG developed partial specifications for both of these areas. These specifications should be refined by the ARI in concert with industry alliances.SoftwareThe CIWG recommends that the ARI pursue standardization efforts for the CIs shown in � REF _Ref359679420 \* MERGEFORMAT �Table 5�. Standards in these areas are important because they offer the potential to increase the effectiveness of these CIs and reduce the cost of re-hosting TPSs.�Table � SEQ Table \* ARABIC �5� Critical Interfaces Standardization GuidelinesName�Mnemonic�Related Standards Activities��Adapter Function and Parametric Data�AFP�IEEE P1226.11 ABBET TRIM��Diagnostic Processing�DIA�IEEE P1232.x AI-ESTATE��Digital Test Format�DTF�IEEE P1445 DTIF��Generic Instrument Classes�GIC�IEEE P1226.9��Instrument Function and Parametric Data�IFP�IEEE P1226.11 ABBET TRIM��Run Time Services�RTS�IEEE P1226.10��Switch Function and Parametric Data�SFP�IEEE P1226.11 ABBET TRIM��Test Program Documentation�TPD�TPS Standardization IPT��UUT Test Requirements�UTR�IEEE P1029.3 TRSL, EIA EDIF/Test���IntroductionPurposeRecent DoD policy changes require that “Automatic Test System capabilities be defined through critical hardware and software elements”. The purpose of this document is to define these critical hardware and software elements through Critical Interfaces (CIs). This document will aid in satisfying the requirements of DoD Regulation 5000.2-R and assist convergence in migration plans for the DoD designated tester families. Within the Joint-Service ATS Research and Development Integrated Product Team (ARI), the Critical Interfaces Working Group (CIWG) was established. The CIWG identified interfaces as critical if they offered the potential to lower the cost to re-host Test Program Sets (TPSs) and increase the interoperability among DoD test equipment. Interfaces with significant impact on Automatic Test Equipment (ATE) interoperability and TPS re-hostability, but without the ability to be implemented in the short term due to lack of commercial standards or products that support them, are recommended for further study.This document provides the requirements for each interface recommended for control along with the rationale utilized in determining its criticality. In general, criticality for each interface is based upon its ability to reduce the cost of transporting TPSs among ATE horizontally and vertically within DoD maintenance organizations and to reduce the cost of re-hosting TPSs to DoD testers and commercial testers that contain the controlled interfaces. � REF _Ref359143293 \* MERGEFORMAT �Figure 4� illustrates some interfaces in a typical tester architecture.BackgroundFrom 1980 to 1992, the U.S. Department of Defense (DoD) investment in depot and factory Automatic Test Systems (ATSs) exceeded $35 billion with an additional $15 billion for associated support. Often, application specific test capability was procured by weapon system acquisition offices with little coordination between DoD offices. This resulted in a proliferation of different custom equipment types with unique interfaces that made the DoD appear to be a variety of separate customers. The policy changes listed below require DoD offices to take a unified corporate approach to purchases of ATE.DoD ATS Policy, USD (A&T) - 15 March 1996, and DoD Regulation 5000.2-R� bring a cost effective approach to the acquisition of ATE. This policy requires hardware and software needs for depot and intermediate-level applications to be met using DoD designated families and commercial equipment with defined interfaces and requires the management of Automatic Test Systems (ATS) as a separate commodity through a DoD EAOSecretary of Defense Memorandum on Specifications and Standards - 29 June 1994, directs that DoD procurements will be made first by performance definition, second by commercial standards, and finally (and only with waiver) by military standardsThe use of open standards in ATE has been projected to provide the following five benefits.�Improve the test acquisition process by creating an ATS framework that can meet functional and technological needs, promote automation in software development, re-hostability and portability of TPSsDecrease the use of custom hardware from approximately 70% today to 30% by the year 2000Reduce TPS engineering costs 70% by the year 2000Reduce TPS integration time and cost 50-75% by the year 2000Provide an iterative improvement in the quality of test by the reuse and refinement of libraries�Figure � SEQ Figure \* ARABIC �4� Example ATS Interfaces�ProgrammaticsOrganizationThe CIs were developed within a joint Government/Industry working group to aid in promoting commercial compatibility and vendor acceptance. The CIWG consists of representatives from the Air Force, Army, Navy, Marine Corps, engineering support contractors, vendors, and consultants with expertise in ATS. Overall guidance for CIWG activities was provided by representatives of the DoD EAO.The CIWG, funded under the title Factory-to-Field Integration of Defense Test Systems, was chartered as a working group under the ARI. Prior to the inception of the CIWG, the Air Force initiated an activity known as the Open Architectures Integrated Product Team (OA-IPT) that had similar goals to the CIWG. Given the similarity in goals and the fact that the OA-IPT had collected data needed by the CIWG, the two teams merged. � REF _Ref359143615 \* MERGEFORMAT �Figure 5� shows the organization of the CIWG.�Figure � SEQ Figure \* ARABIC �5� CIWG OrganizationObjectivesThe CIWG was chartered to define interfaces which could be validated through demonstration and used today. In addition, the CIWG was chartered to identify interfaces worthy of further research for the long term.The primary objectives of the Critical Interfaces Project are summarized below.To develop critical test interface definitions from among selected and existing CIs in conjunction with commercial and defense test industries. CIs are either hardware or software, or a combination of hardware and software, which promote TPS reuse and interoperability among testers that contain those interfaces.To demonstrate critical test interfaces on Consolidated Automated Support System (CASS) and Integrated Family of Test Equipment (IFTE) at a minimum, and on a commercial tester if cost and schedule can be met. The purpose of the demonstration is to evaluate the benefits of the CIs.To contribute to test system migration plans to evolve current DoD tester families to common test interfaces and open test environments through Preplanned Product Improvement (P3I) programs where feasible and cost effectiveTo develop investment and benefit parameters needed for implementation assessmentsProcessThe CIWG is utilizing a spiral process for defining and recommending CIs. � REF _Ref368103932 \* MERGEFORMAT �Figure 6� shows the process flow and feedback loops for iteratively defining the CIs and migrating to an open systems architecture. The Open Systems Joint Task Force (OSJTF) is providing Office of the Secretary of Defense (OSD) and the EAO with the policies and procedures that are necessary to adequately define an open systems architecture. These policies and procedures are then made available to the CIWG through the ARI for further definition and refinement of the CIs. Recommendations from the OSJTF and the CIWG provide the EAO and (OSD) with data necessary for making acquisition policy and guidance decisions.This report represents the initial recommendations of the CIWG to the EAO. The interfaces recommended for Release 1 have been reviewed by industry via an Industry Review Board (IRB) process. The initial recommendations will be further refined via demonstrations, producing a Release 2 report. The report recommendations will continue to be revised as commercial and defacto standards are developed to satisfy CIs that currently have no viable candidate.�Figure � SEQ Figure \* ARABIC �6� CIWG ProcessScopeThe following factors guided the CIWG in defining CIs.Criticality - Only those interfaces that offered a potential to reduce TPS re-host costs and increase transportability among DoD and commercial testers were considered.Hardware and Software - Hardware and software associated with the supported test domains and software interfaces required to build ATSs were considered. The definition of software interfaces includes the test information and electronic information exchange of all types (e.g., digital vectors, test strategy reports, netlists).Open Architectures IPT - The responses to the OA-IPT Request For Information as well as interfaces identified in the responses were considered.Preference - Both commercial and DoD specific interfaces were considered. Preference was given to interfaces used in commercial test systems over those employed in DoD test systems.Signals and Testing Levels - The scope was limited to digital, analog, Radio Frequency (RF), and microwave electrical signals and to factory, depot, and intermediate (I-level) test environments.The following factors guided the CIWG in selecting candidates for each CI.Availability - Preference was given to candidates that are currently available or expected to be available for the demonstration.Commercial Acceptance - Preference was given to candidates that are available from multiple sources and are widely accepted.Efficacy - Preference was given to those candidates that are perceived to be more effective in reducing TPS re-host costs and promoting TPS/ATE interoperability.Openness - Preference was given to candidates for which there are open, commercial standards and specifications.Technical ApproachThe CIWG utilized a systems engineering approach to identify and characterize ATS hardware and software interfaces. First the CIWG developed requirements and formulated the overall approach. Then, the CIWG divided into subgroups, as shown in � REF _Ref359143615 \* MERGEFORMAT �Figure 5�, to address specific issues. The results are documented in this report.Each subgroup used the following process to identify and characterize interfaces and candidates.Develop a reference architecture diagram to allow identification and description of interfacesIdentify interfacesDevelop criteria for evaluating the criticality of identified interfacesApply criteria to interfaces and identify the CIsSelect candidates for the CIsProvide the results for review by the full CIWGPeriodic meetings assured coordination and provided mutual review of interim results. Electronic mail was used extensively between meetings. A World Wide Web (WWW) page made working material available to CIWG members.� REF _Ref362771992 \* MERGEFORMAT �Figure 7� presents a high-level overview of a typical ATS structure. The ATS structure shown portrays the major ATS system segments that play roles in the transportability and re-hostability of TPSs across ATE. The UUT is isolated in the box on the right. The TPS includes the fixture and the test program software. The ATE is comprised of the host computer, system software, instruments, switching, receiver and supporting communication buses. This ATS architecture is further subdivided in the generic hardware and software diagrams discussed in Sections � REF _Ref363360569 \n �4� and � REF _Ref363360605 \n �5�.�Figure � SEQ Figure \* ARABIC �7� Generic ATS ArchitectureA variety of diagrams in the hardware and software sections of the report relate to the architecture shown in � REF _Ref362771992 \* MERGEFORMAT �Figure 7�. The critical hardware and software interfaces are analyzed by expanding the boxes shown.The group reviewed architectural diagrams of the current DoD designated families of testers. � REF _Ref359092944 \* MERGEFORMAT �Figure 8� shows the CASS hardware architecture while � REF _Ref363444714 \* MERGEFORMAT �Figure 9� shows the CASS software architecture. � REF _Ref363444730 \* MERGEFORMAT �Figure 10� shows the IFTE hardware architecture while � REF _Ref363444741 \* MERGEFORMAT �Figure 11� outlines the IFTE software architecture. These architectural diagrams were used as a baseline to develop a generic view of hardware and software elements that are common to most tester architectures.��Figure � SEQ Figure \* ARABIC �8� CASS Hardware Architecture�Figure � SEQ Figure \* ARABIC �9� CASS Software Architecture

�Figure � SEQ Figure \* ARABIC �10� IFTE Hardware Interfaces

�Figure � SEQ Figure \* ARABIC �11� IFTE Software Interfaces�HardwareHardware InterfacesIn this section the generic ATS architecture is decomposed into hardware elements and the interconnects between them. Each interface is evaluated against its ability to reduce the cost of transporting and re-hosting a TPS to determine its relative criticality.Hardware Decomposition� REF _Ref363364621 \* MERGEFORMAT �Figure 12� provides a view of the top-level hardware elements and interconnects in a generic ATS architecture. This diagram was developed for the purpose of representing all generic hardware interface categories which might be considered CIs. The diagram is meant as a starting point for discussions on particular interfaces and their pertinence to TPS transportability and re-hostability. The diagram is not a representation of a test system architecture, but does have resemblance of such since there is a close relationship. The following is a discussion of the diagram and some of the implications and outcomes concerning the diagram which have resulted from the CIWG hardware group.The diagram is composed of hardware elements and the interconnects existing between them. A named data flow arrow connecting two elements represents an interconnect. The elements represent general ATS system hardware components. Elements and interconnects were considered as interface candidates during the hardware group deliberations.The hardware subgroup used the � REF _Ref364086621 \* MERGEFORMAT �ATS Generic Hardware Interfaces� to visualize each interface category and how information might flow between elements. This is important since there are many test architectures and the diagram must incorporate the important interfaces for transportability and re-hostability for all of them. For instance, a test system may incorporate a distributed computing architecture like that found in the CASS. Although the diagram does not explicitly exhibit a distributed computing architecture, the interfaces that would be critical are represented. In the CASS, the host computer Central Processing Unit (CPU) communicates with asset controllers through Ethernet connections. The host CPU is represented in the diagram by the Host Computer element. The Ethernet connection is represented as a Computer to Asset Controller (CAC) interconnect. Each asset controller is represented by the Instrument/Asset Controller element.� REF _Ref363364606 \* MERGEFORMAT �Table 6� summarizes the six primary interfaces delineated in � REF _Ref363364621 \* MERGEFORMAT �Figure 12�. It also lists the corresponding elements for the CASS, IFTE, and Teradyne architectures correlated to a listing of candidate standards and products considered for satisfying the interface.�Figure � SEQ Figure \* ARABIC �12� ATS Generic Hardware InterfacesTable � SEQ Table \* ARABIC �6� Hardware Interfaces Summary MatrixInterface�CASS�IFTE�Teradyne�Candidate Standards/Products��Host Computer Asset Controller interface (CAC)�QBUS, PCI, MXI, Ethernet, IEEE-488�S-BUS, Ethernet�PCI, MXI, Ethernet, IEEE-488�EISA, ISA, PCI, Ethernet, QBUS, Unibus, SCSI, S-BUS, IEEE-488, MXI��Computer to External Environments Interface (CXE)�RS-232, Ethernet�RS-432, Ethernet �RS-232, Ethernet�Ethernet, RS-232/432, IEEE-488��Host Computer (HST)�VAX / ALPHA�Sparc 20�Sparc 20�Sparc, VAX, DEC ALPHA, Intel: 80x86, Motorola: 68xxx ��Instrument Control Bus interface (ICB)�IEEE-488, VME, MSIB�IEEE-488, VME�IEEE-488, VME�IEEE-488, VXI / MXI, VME, RS-232/432��Receiver / Fixture interface (RFX)�Virginia Panel�Gold Dot�ZIF�Virginia Panel, MAC Panel, Gold Dot, AMP��Switching Matrix interface (SWM)�Internal with loopback wiring from ITA to access�Internal and software controlled. No wiring necessary on ITA�Internal and software controlled. No wiring necessary on ITA�IFTE Signal Distribution System ��Definitions of Potentially Critical Hardware InterfacesComputer Asset Controller InterfaceThis interface describes the communication paths between the HST and instrument controllers or other slave processors in a distributed system. These interfaces may be internal or external to the HST. Examples of internal interfaces are Industry Standard Architecture (ISA) and Peripheral Component Interface (PCI). Examples of external interfaces are IEEE-488, RS-232, Ethernet, MXI, and MSIB.Computer to External Environments InterfaceThis interface describes the communication methods between a host ATS and remote systems. This includes paths between the target ATE host computer and other ATE systems as well as development stations. This interface supports transporting TPS software and supporting documentation between organizations and re-host of legacy TPSs. Examples include Ethernet for Local Area Networks (LAN) and Wide Area Networks (WAN), RS-232, IEEE-488, and Ethernet for point-to-point connections, as well as modem links.Host Computer InterfaceThis interface describes the processing architecture of the primary control computer where the TPS is executed and through which the operator interfaces.Instrument Control Bus InterfaceThese are interfaces from the instrument controller to test instrumentation such as Programmable Power Supplies, Arbitrary Waveform Generators, Spectrum Analyzers, Digital Test Units (DTUs), and Power Meters. Examples of these interfaces are IEEE-488, VME, and VME Extensions for Instrumentation (VXI).Receiver/Fixture InterfaceThis interface describes the hardware necessary to accomplish the mechanical and functional connections between the UUT stimulus/response signals passing through the UUT’s unique ITA and the signals to and from the test instrumentation. These signals are passed either directly to or through the test instrument or through a hardware switch.Switching Matrix InterfaceThese interfaces describe the hardware switching requirements necessary to switch stimulus, response, and power signals between the UUT and the test instrumentation. The switching may be implemented in various ways such as internal to the tester or external in the fixture.Hardware Interface Criticality EvaluationA large number of tradeoffs between hardware and software exist. Whenever such tradeoffs were encountered, the general decision was made to implement the software interface instead of the hardware interface. Software interfaces allow a wide variety of hardware and provide a more “open” system. Thus, the specification of the VPP-2 frameworks in the software section (Section � REF _Ref368460931 \n �5�) provides a reason that the Host Computer is not a CI. The VPP-2 specification places minimum requirements on the Host Computer, peripherals, operating systems, and ADEs, without specifying particular products. Under these ground rules, the majority of hardware elements were not considered critical because the software elements that isolate or limit them were considered critical.The group concluded that interfaces touched by the TPS through its life cycle are prime candidates for CIs (refer to � REF _Ref363532748 \* MERGEFORMAT �Figure 13�). That is, if an interface directly supports the design, development, production, use, or re-host of a TPS then it has the potential to be a CI.� EMBED Word.Picture.6 ���Figure � SEQ Figure \* ARABIC �13� Test Program Isolation From Host Computer� REF _Ref363532748 \* MERGEFORMAT �Figure 13� demonstrates that the TPS is isolated from the CPU by the Operating System (OS). Since the TPS does not directly touch the CPU, the host computer is not a CI. Following this logic, the CAC and ICB interfaces were eliminated.An example of a situation where an interface is deemed critical follows. � REF _Ref363364783 \* MERGEFORMAT �Figure 14� shows a TPS contacting the CXE interface during a re-host. In this example the Ethernet is an implementation of the CXE interface. Since the two OS communicate via the same network protocol, the TPS can be transferred regardless of the OS type.�Figure � SEQ Figure \* ARABIC �14� Re-host of a TPSSeveral hardware elements not recommended as CIs, for the reasons discussed in the preceding paragraphs, became required as a result of software interfaces. These hardware elements are necessary to support certain software interfaces described in Section � REF _Ref368461332 \n �5�. The elements include, but are not limited to, the CPU, memory requirements, peripheral support and others.Recommended Hardware Critical InterfacesUsing the concepts in the previous section, the following hardware interfaces are critical.Computer to External EnvironmentsReceiver/Fixture InterfaceSwitching MatrixEach of these CIs is discussed in the subsequent sections.Computer to External Environments InterfaceComputer to External Environments CandidatesThe CXE interface defines hardware that allows communication between an ATS and remote systems. This interface supports transporting test program software and supporting documentation between organizations. The candidates considered include Ethernet, RS-232, and IEEE-488.Computer to External Environments Recommendations and RationaleThe CXE interface was selected as a CI because standardizing it is expected to reduce the cost of transferring information during re-host of a TPS. Analysis of software issues concluded that data networking using TCP/IP should be required. It was not necessary to specify a particular hardware interface candidate such as Ethernet, RS-232, or IEEE-488, because TCP/IP implementations can be used in conjunction with a number of hardware solutions. The CIWG recommends that any hardware used in this interface be required to support the TCP/IP software protocol.Switching Matrix InterfaceDecompositionThe SWM interface and ATS receiver/fixture pin map represents a central element of the ATS for connecting ATE instrumentation to the UUT through a switch matrix. The SWM allows a variety of instruments to be connected to multifunction terminals identified by a standard receiver/fixture pin map. The pin map is described in the section for the RFX interface. The combination of standardizing the SWM interface and a common receiver/fixture pin map gives the ATE the capability to accommodate any fixture that conforms to the pin map. The SWM and receiver/fixture pin map interface have the greatest impact by permitting the ATS developer to select various signal paths between the instrument and UUT. A description of the SWM interface, selection criteria, and recommendations follow.A variety of switch matrix designs can be interfaced to and from instruments and the related UUT. Examples of switch matrices are shown in � REF _Ref359146061 \* MERGEFORMAT �Figure 15� as:Benchtop unitsIntegrated switch cards to fixturing or directly coupled to receiver interfacesRack mounted unitsVXI Switch Modules

�Figure � SEQ Figure \* ARABIC �15� Switching Matrix Product DesignsRequirements and Issues ConsideredGeneral requirements for the SWM CI were derived from many sources representing general industry needs, Government and commercial interests, Government Open-System directives, industry technology trends, NSIA recommendations, Government/Aerospace test requirements previously described (functional test requirements), and Test Industry SWM defacto standards. The CIWG reviewed the widest spectrum of requirements and interests to assure worst case needs were addressed. These requirements were extracted from the envelope of the cases reviewed. This is expected to provide capability for almost every requirement the solution will encounter. During the review process standards or products that could meet these requirements were sought. The switching philosophies considered in the analysis are as follows.Switching in the Test Fixture - This approach incorporates switching into the test fixture based on the UUT requirements. This places financial burden on the end user since switching needs to be incorporated in many test fixtures. This is a significant recurring cost.Switching in the ATE - This approach integrates the switching capability into the ATE and treats it as additional instrumentation. This simplifies test fixture design, reduces TPS cost, and places the switching under control of the ATE system software. This can be accomplished in one of two ways.“Internal hardwiring” of instrumentation to ATE switching. The internal approach simplifies test fixture design and implementation; however, a performance tradeoff may be incurred.“External hardwiring” of instrumentation to ATE switching in the test fixture. The external approach will greatly increase test fixture complexity, however; the TPS developer has greater flexibility, should higher performance instrumentation require uncompromised access at the tester interface.General RequirementsThe SWM CI includes all of the needs that address hardware/software requirements. These lead to a system that can support commercial architectures and preserve the needs of the Government and commercial industry. The following goals directed the review of switching matrix candidates.Select an open commercial switch matrix standard that:Is widely accepted by industry with multi-vendor sources.Has established design definitions.Offers a full range of options to meet signal, power, and coax requirements.Supports high life cycle performance and maintainability.Is available today in volume production, and is in its early product life-cycle phase.Provide a scaleable switch matrix with a modular framework design that permits ATS integrators to incrementally augment their systems through add-on/duplicative features. This will enable them to meet worst case requirements while maintaining downward compatibility with any smaller Input/Output (I/O) increment.Establish a common switch matrix specification that offers multi-vendor sources, is flexible enough to support a wide variety of signal performance/reconfigurability, and can evolve with changing test needs.Minimize pin out configuration to the extent that transportability is effective and reconfigurability is not impaired.Reduce the proliferation of switch matrix designs.Define a minimum set of performance requirements that will meet the Government I/O basic switch matrix envelope.The integrator determines switch requirements based on the number of instruments and the flexibility with which they must be applied. Switch matrix designs require a compromise between direct wire performance and switch flexibility.The CIWG concluded that switching in the ATE with internal hard wiring should be required to achieve greater cost-effectiveness and minimize fixture complexity. Extended performance paths should be included to address high performance requirements.The CIWG also concluded that the SWM must meet the following requirements.IEEE-488.2 protocolVPP-3 instrument drivers and VPP-4 I/O librariesPackaging of the switches should be in one of two forms.19Ó rack mounted unitVXI bus standard B or C module form factorCurrent Government ATE RequirementsBased upon the general requirements of the Government and existing ATS requirements of the Teradyne L300-Series system, CASS, IFTE, and Marine Corps Automatic Test Equipment System (MCATES); a composite I/O interface matrix capability envelope was developed to define current/worst case requirements. This was divided into several I/O categories to permit signal mapping to pin type of the RFX.Digital (DTU/DWG)General Purpose Analog InstrumentationProgrammable DC Load (High Power)Programmable Power Supplies (AC/DC)Serial Communication for UUTs (e.g., 1553, RS-232, RS-423)Utility Switching I/OApplying the modular and scaleable concepts offered by commercial switch matrices, a minimum set of switch assets should be defined that can be duplicated to support worst case requirements.It was determined that the following capabilities would not form part of the core capability, and that they should not be addressed by this report: Electro-Optics (E/O), Pneumatics, RF, Spread Spectrum, Video and unique ATE configurations including instrumentation of this type.Programmable DC Power Supplies� REF _Ref359146452 \* MERGEFORMAT �Table 7� compares the programmable DC power supply capabilities of selected ATE including pin count per instrument, voltage and current ratings. The pin count was based upon three pin types covering overlapping voltage bandwidths of the CASS low power� 10A contact and the CASS high power� 20A contact. Use of these pins is driven by TPS requirements and can only be estimated.Table � SEQ Table \* ARABIC �7� DoD ATS Programmable DC Power Supply ConfigurationsATS�Power Supply Description�Voltage / Current Rating�# High Contacts�# Low Contacts��L300-Series�DCPS 1DCPS 2DCPS 3DCPS 4DCPS 5DCPS 6DCPS 7DCPS 8�0-20V, 30A0-60V, 10A0-200V, 17A0-10V, 6A0-20V, 50A0-60V, 12A0-360V, 17A0-32V, 32ATotal: �2222222216�2222222216��CASS�DCPS 1 - DCPS 5DCPS 6 - DCPS 8DCPS 9DCPS 10, DCPS 11(all) 1�0�32V, 25A0-32V, 25A0-100V, 8A50-450V, 2ATotal: �2012

32�1064828��IFTE �DCPS 1, DCPS 2DCPS 3, DCPS 4DCPS 5DCPS 6, DCPS 7DCPS 8Fixed Power Supply4(all) 2�0�7V, 20.5A0-15V, 9.1A0-36V, 4.1A0-55V, 2.5A0-100V, 1.5A+28V, 22.5ATotal: �84242626�16168168-64 3��MCATES�DCPS 1, DCPS 2, DCPS 8DCPS 3DCPS 4, DCPS 5DCPS 6, DCPS 7(all) 1�0�16V, 2A0-150V, 0.7A0-55V, 8A0-36V, 8ATotal: �624416�624416��Each supply requires two high power pins (Hi, Lo) and two low power pins (Sense Hi, Sense Lo).Each supply requires two high power pins (Hi, Lo) and eight low power pins (SW1+, SW1-, SW2+, SW2-, SW3+, SW3-, SW4+, SW4-).Spare medium power or signal pins could be used to support Sense contact requirements.IFTE contains an additional fixed DC power supply as follows: + 28V, 22.5A accessible at the Auxiliary Interface Panel, enabled by shorting two pins on the Gold Dot Interface panel together.Programmable DC Loads� REF _Ref363364967 \* MERGEFORMAT �Table 8� compares the programmable DC load capabilities of selected ATE including pin count per instrument, voltage and current ratings. The pin count was based upon three pin types covering overlapping voltage bandwidths of the CASS low power 10A contact and the CASS high power 20A contact. Use of these pins is driven by TPS requirements and can only be estimated. Further research in Phase II should provide greater definition on the number of pins by pin type. Where requirements exceed the amperage rating of the CASS high power contact, parallel path wiring (doubling) is recommended.Table � SEQ Table \* ARABIC �8� DoD ATS Programmable DC Load ConfigurationsATS�Programmable Load Description �# High Contacts�# Low Contacts��L300-Series�3 Loads, 150W, 250W, and 600W (available at external panel only, they do not go through the switch matrix)Total: �14

14�6

6��CASS�High Power Load (500W, 20A) = 2 High Power and 3 Sense Low Power pins.Low Power(0.5A) = 2 low power pins, 8 more low power in future needs 16 additional low power.Total: �2

-

2�3

26

29��IFTE�8 Channels, 2x300W, 6x750W (avail. at AUX panel only)Total: �1616�3535��MCATES�none����AC Power Supply RequirementsData in � REF _Ref364160505 \* MERGEFORMAT �Table 9� compares the AC power supply capabilities of selected ATE after an analysis of: CurrentPin CountVoltage�Table � SEQ Table \* ARABIC �9� DoD ATS AC Power Supply ConfigurationsATS�Phase�Voltage(VRMS)�Frequency(Hz)�Current(Amps)�Power�Config.�Access��L300-Series�Single or Three�0 - 200�60 - 1600�0 - 10�3.5 KVA�Delta,Wye�ExternalPanel��CASS�Single or Three�0 - 135�55 - 1200�0 - 13.5�675 Watts/Phase�Delta�AC PowerPanel��IFTE�Single or Three�0 - 270�45 - 5000�0 - 135 V @ 10 A0 - 270 V @ 5 A�750 Watts/Phase�Delta,Wye�AuxiliaryInterfacePanel��MCATES�none�none�none�none�none�none�none��The AC power capabilities of these systems are not accessible at the receiver interface; therefore, they do not affect pin mapping at this interface. For personnel safety and Electromagnetic Interference (EMI) noise restrictions, the AC power lines connect through an auxiliary AC power panel to the UUT or fixture assembly.Summary Power Supply RequirementsTo support the power I/O requirements of the RFX CI for the selected ATE families, it is desirable to map the I/O contact requirements against the CASS power contacts having varying levels of performance that is primarily segmented by its amperage rating. The recommended contacts are:High Power - 20 AmpCASS power contactLow Power - 10 AmpCASS power contactBased upon current CASS contact densities, a mixed power connector module is required to support the same footprint as the 200 pin DIN signal module. Assuming the present pin cavity and spacing used by CASS and a DIN footprint, it is possible to pack sixteen high power contacts; and twenty-nine low power/sense pins in one mixed power connector module.The analysis concluded that current ATS requirements can be met with four mixed power connector modules. Two of the power modules would be dedicated for direct interface to the programmable DC power supplies and two would be devoted to the power switch matrix.�Digital I/O Capabilities� REF _Ref359146783 \* MERGEFORMAT �Table 10� compares the digital I/O capabilities after the analysis of:BandwidthCrosstalkPin CountA commercial DIN format 200 position signal connector module connected to precision point-to-point 50 ohm impedance matched wiring having a bandwidth up to 250 MHz was evaluated and found acceptable for use with the selected ATE digital requirements.

Table � SEQ Table \* ARABIC �10� DoD ATS Digital I/O CapabilitiesATS�# of I/O Pins�Pin Description (Voltage)��L300-Series�532�-2.56 to +10.23 V��CASS�336�-5.0 to +15.0 V��IFTE�16032�-10.0 to +10.0 V-10.0 TO +30.0V��MCATES�25664�-2.0 to +5.0 V-28.0 to +28.0 V��Each 200 pin DIN signal connector module could support 64 digital I/O pins and their associated control lines. Nine DIN signal connector modules would be required to support the 532 pin L300-Series requirement.Analog Instrumentation RequirementsData in � REF _Ref364160649 \* MERGEFORMAT �Table 11� compares analog instrumentation capabilities of selected ATE including: BandwidthMaximum VoltagePin countThe pin count was based upon three pin types covering overlapping frequency bandwidths:Low - commercial DIN signal DC to 250 MHz contactLow RF - CASS Low RF < 1.2 GHz coax contactHigh RF - commercial High RF < 26.5 GHz coax contactUse of these pins is driven by TPS requirements and could only be estimated. Further research will provide greater definition on the number of pins by pin type.�Table � SEQ Table \* ARABIC �11� DoD ATS Analog Instrumentation DescriptionsInstrument�L300-Series�IFTE�CASS�MCATES��Mil-Std -1553/BUS TEST UNIT�1553 Bus Emulator�Bus Test Unit, 2 channels requires 26 pins. Future is 1553 Bus Emulator.�1553 Bus Emulator also requires 2 Coax ports. Future is more General Purpose Serial Interface�None��DMM�High, Low, Sense High, Sense Low, GND�High, Low, Ohms Sense Hi, Ohms Sense Lo�High, Low, Ohms Sense Hi, Ohms Sense Lo, Current Measurement pin�2 Channels of High, Low, Ohms Sense Hi, Ohms Sense Lo, also Trig and Current measurement pin.��COUNTER / TIMER�CH1, CH2�CHA, CHB, EXT TRIG�CHA, CHB, EXT TRIG�CHA, CHB, CHC, CHD, REF OUT��DIGITIZER / WAVEFORM ANALYSIS�CH1, CH2, EXT TRIG� CHA, CHB, EXT TRIG�CHA, CHB, CHC, CHD�CHA, CHB, EXT TRIG, CHB OUT, Audio Analyzer��ARBITRARY FREQUENCY WAVEFORM GENERATOR (AFG/AWG)�CH1, CH2, EXT TRIG, AC Signal: CH1, CH2 Video Signal: VIDEO � CHA, CHB, CHC, CHD, All Channels have EXT TRIG; CHA, CHB, CHC have EXT SYNC�CHA, CHB, EXT TRIG, EXT SYNC, 12 Channel ECL Pulsed Out (not used with AFG)�Two (2) Pulse-Function Generators, each with EXT TRIG IN, OUT, Control MOD IN��PRECISION DC REFERENCE DIGITAL TO ANALOG CONVERTER (DAC)�None� 8 Channels presently, 12 in the future with EXT SENSE for each channel�None. Study in progress for future enhancements.�None��PULSE GENERATOR�CH1A, CH1B, CH2A, CH2B, EXT TRIG 1, EXT TRIG 2� AFG CHA, CHB, CHC, CHD (25 MHz), Each with EXT TRIG; CHA, CHB, CHC, have EXT SYNC�CHA, CHB (250 MHz), Plus one Trigger�CHA, CHB, EXT GATE IN, TRIG OUT��SYNCHRO RESOLVER SIMULATOR / INDICATOR�None� 1 Channel SRSI, 3 Channels SRSI in Future�3 Channel SRSI�None��10 MHz REFERENCE�None�10 MHz Reference available at receiver�10 MHz Reference available at receiver�10 MHz Reference available at receiver ��SYNCHRONIZATION AND TIMING�Various signals available at UUT Interface, Optional external clock input� None�None. Coax IN, two twisted pair OUT�Coax IN, Coax OUT��CALIBRATOR�None� None�None. Low Frequency Calibrator accessible at receiver�None��SERIAL COMMUNICATIONS FOR UUT �ARINC 429, RS-232 (at external interface only, not available through switch matrix)�RS-423, RS-232 (AT MASS INTERFACE), IEEE-488, Ethernet VIA AUX PANEL�RS-232, RS-422, IEEE-488, IEEE 802.3, ARINC 429�RS�232 AND IEEE�488 AT AUX PANEL, MXI via TESTHEAD��GROUND�Chassis, single-point ground�Chassis, single-point ground�Chassis, single-point ground�Chassis, single-point ground��INTERLOCKS�DC Power Supply interlocks at external interface, fixture disconnect interlock� None�One deals with ID being open (2 pins), the other with UUT cabling (3 pins). If there is a fault, the station will not run the TPS. In 1995 P3I added 11 additional lines to allow the TPS developer to monitor conditions at the UUT, (i.e. overtemp would shut down the station). �Receiver provides interlock which, when opened prohibits closing of any switch or application of any stimulus. The TESTHEAD also provides a sense capability for an ID safety cover.��PROBE CAPABILITY�DTU Guided Probe (probe in 18 different detect states), PROBE CAL, ANALOG PROBE PORT (provides access to all switch MATRIX assets)� DWG Guided Probes (stimulus, response (level, pulse, etc.), and current detect), 2 ANALOG PROBE PORTS (provide access to all MATRIX switch assets), HIGH FREQ PROBE (100 KHz�5OO MHz) and HIGH VOLTAGE PROBE (40 KV DC Max) used with the DMM�DTU Guided Probe (probe in 18 different detect states), PROBE CAL, DMM HV PROBE, AND DIGITIZER CAL PROBE�Digital Guided Probe, Level, Pulse, Glitch Detect��Analog Instrumentation Requirements SummaryUsing a worst case analysis, the number of pins required for analog instrumentation on selected ATE are shown in � REF _Ref359147327 \* MERGEFORMAT �Table 12�. It is assumed that no switch matrix is present in deriving these numbers.Table � SEQ Table \* ARABIC �12� DoD ATS Analog Instrumentation RequirementsInstrument�Contact Requirements�Signal�Low RF�High RF��1553/BTU�30 signal pins�30����DMM�10 signal pins�10����Counter/Timer�4 coax pins��2�2��Digitizer�12 coax pins��10�2��AFG/AWG�13 coax + 25 signal pins�24�12�2��DAC�60 signal pins (includes expansion)�60����Pulse Generator�7 coax pins��5�2��Synchro/Resolver�50 signal pins�50����Sync/Timing�1 coax + 6 signal pins�6��2��Calibrator�5 signal pins�5����10 MHz Ref.�1 coax pin��1���Audio Analyzer�4 signal pins�4�����Totals:�� =c2+c3+c6+c7+c9+c10+c11 + c13�189��� =d4+d5+d6+d8+d12 �30��� =e4+e5+e6+e8+e10 �10���To support the analog I/O requirements of selected ATE, three types of contacts were recommended:Low frequency analog, DC to 250 MHzLow RF analog, 100 MHz to 1.2 GHzHigh RF analog, 500 MHz to 26.5 GHzIt is desired to have as a minimum, the following:One 200 position low frequency signal moduleTwo 24 position low analog/RF coax modulesOne 12 position high analog/RF coax module�Power Switch Matrix RequirementsThe present power switching capabilities of selected ATE are summarized in � REF _Ref359147423 \* MERGEFORMAT �Table 13�.Table � SEQ Table \* ARABIC �13� DoD ATS Power Switch Matrix RequirementsATS�Power Requirements�# High PWR Pins�# Low PWR Pins��L300-Series�None����CASS�5 x (1x4) @ 18.75 Amp3 x (1x2) @ 18.75 Amp6 x (1x2) @ 9 AmpTotals: �259

34�

1818��IFTE1�����MCATES�None����Switching is built-in to DC Supplies, pins were accounted for in programmable DCPS section.

Assuming a 16/29 position High/Low mixed power connector module, two power modules are required to support worst case needs of the CASS power switch. It is unclear whether use of the current discrete DC power supplies connector modules could be used for the power supply switch outputs.Low Frequency Switch Matrix RequirementsThe current low frequency utility switch matrix requirements of the selected ATE are summarized in � REF _Ref359721109 \* MERGEFORMAT �Table 14�.Table � SEQ Table \* ARABIC �14� DoD ATS Low Frequency Switch Matrix RequirementsATS�Switch Requirements�# Signal Pins��L300-Series�16 x (1x2) @ 20 MHz16 x (1x2) @ 100 KHz16 x (1x2) @ 1600 HzTotal:�484848144��CASS�70 x (1x2) @ 1 MHz42 x (1x4) @ 1 MHzTotal:�210210420��IFTE�32 x (1x2) @ 10 MHzTotal: �9696��MCATES�12 x (2x8) @ 10 MHz14 x (1x2) @ 10 MHz6 x (1x4) @ 10 MHzTotal: �1204230192��The requirement for a utility switch matrix is needed for any general purpose ATE system. One 200 pin DIN connector module would support the current configurations of L300-Series, IFTE and MCATES, as well as a scaled down CASS requirement. Access to utility switching by the TPS developer can simplify test fixture design, increase transportability, and reduce TPS cost. Utility switching is being defined as low bandwidth (1-10 MHz) switching with accessibility by the TPS at the system interface. Form C relays (1x2) constitute the basic and most versatile building block of all switching architectures.Performance Switch Matrix RequirementsThe present performance switch matrix requirements of selected ATE are summarized in � REF _Ref363531098 \* MERGEFORMAT �Table 15�.Table � SEQ Table \* ARABIC �15� Performance Switch Matrix RequirementsATS�Power Requirements�Power Pin Type��L300-Series�64 Ports @ 208 MHz�64 Signal, 64 Returns���400 Hybrid Signals @ 10 MHz�400 Signal, 400 Returns���16 x (1x2) @ 500 MHz�48 Coax��CASS�33 x (1x4) @ 1 GHz�165 Coax���9 x (1x2) @ 1 GHz�27 Coax��IFTE�48 x 3 @ 100 MHz�144 Signal, 144 Returns���144 Ports @ 40 MHz�144 Signal, 144 Returns��MCATES�6 x (1x4) @ 500 MHz�30 Coax���4 x (1x8) @ 500 MHz�36 Coax���10 x (1x4) @ 18 GHz�50 HF Coax���12 x (1x2) @ 18 GHz�36 HF Coax���2 x (1x20) dedicated to DMM�42 Signal���2 x (5x25) dedicated to Audio Analyzer�60 Signal��The requirement for a high performance analog switch matrix is needed for any general purpose ATE system. Four 200 pin signal connector modules would be required to support the signal pin current configurations of IFTE and L300-Series. Three low RF/analog coax 24 position modules would be required to support worst case CASS switch requirements. Eight high RF coax 12 position modules would be required to meet the MCATES worst case 18 GHz switch requirements. This would require a second tier system and a dedicated set of unassigned modules would be identified. One 12 position high RF coax module is provisioned in the first tier of the receiver to support high RF requirements.�ATS Summary Core CapabilityThe following functional capabilities are common to the L300-Series, CASS, IFTE, and MCATES testers.Counter/Timer: Two Channel, External Gate/TriggerDigital I/O Pins: 192Digital Multimeter: AC/DC Volts, OhmsDigitizer: Two Channels, External TriggerFunction Generator: Two ChannelsProbing: Digital Guided ProbeProgrammable DC Power Supplies: 8 Pulse Generator: One ChannelUtility Switching: 32x (1x2) @ 1 MHzConnector Module Requirements SummaryThe number of connector modules required for the selected ATE are shown in � REF _Ref359147997 \* MERGEFORMAT �Table 16�.Worst Case:Total number of modules required324(48 Available under two tier receiver)Expected Case:Total number of modules required24(24 Available under single tier receiver)Table � SEQ Table \* ARABIC �16� DoD ATS Connector Module RequirementsFunction�Signal�Low RF�High RF�Mix Power��Digital�9�����DCPS Programmable Load����2��Power Switch����2��Utility Analog Instrument / Switch�2�����DAC / Synchro-Resolver�2�����Performance RF/Analog Instrument / Switch�4 1�3�8 3���Ground, Interlock�11�����Total Each Module:�171�3�8 3�4 2��Utilize spare pins from existing DIN Signal connector modules/ utilize utility analog DIN Module where a switch is applied.Utilize existing dedicated power pins in lieu of, or spare power pins.Unsure of its application given limited instrumentation available and configuration matrix involved.Does not include sharing of spare pins or substitute of discrete pins for switch matrix pins/utility pins.Switching Matrix Recommendations and RationaleGeneralThe analysis of the selected ATE strongly supports that all ATS designs employ a switch matrix configured to a known pin map. The receiver/fixture pin map interface is defined in the section covering the RFX interface. It was also indicated that the switch matrix and receiver/fixture pin map be defined as a functional building block that supports the scaleability of the interface and modularity of the ATS. The specification would also reflect designs that can be met by multiple vendors to assure competition and availability of solutions to the Government.The ATS switch matrix and receiver/fixture pin map specifications should be based upon a minimum building block described by the design performance requirements. These building blocks can be scaled up by replicating resources (e.g., digital I/O, switch matrix I/O, and power) to meet the higher I/O requirements.Emphasis is placed on the efficiencies of universal cascaded switch matrix solutions and high density connector modules to achieve higher interconnect means with minimum resources and costs. A sample configuration of this switch matrix design is provided in � REF _Ref359211793 \* MERGEFORMAT �Figure 16� and � REF _Ref359211852 \* MERGEFORMAT �Figure 17�.�Figure � SEQ Figure \* ARABIC �16� Sample Switch Matrix Configuration #1��Figure � SEQ Figure \* ARABIC �17� Sample Switch Matrix Configuration #2�Switching Matrix Building Block ConfigurationTo remain upward compatible, the switch matrix must be designed in building blocks that can be duplicated to meet worst case requirements. Recommended design performance objectives for this minimum subset are as follows.SWM hardware and I/O minimum requirements- 6 dedicated low RF coaxial instrument ports- 16 Universal I/O Pins (UI/Os) available at receiver- 12 Extended Performance Pins (EPP) available at receiverMinimum characteristics- Maximum Current: 1 Amp- Maximum Voltage: 200 Vpeak- BandwidthUI/O: 40 MHz, minimumEPP: 100 MHz, minimumSwitch matrix building block minimum features per card- 6 instrum