DI-ATTS-80285C

Engineering Support Data (ESD)

Engineering Support Data (ESD) documents the Test Strategy Report, ATPG data, and TP source files needed to comprehend, maintain, or recreate a Test Program for testing avionics units on Automated Test Equipment.

Approval DateFebruary 9, 2009

AMSC NumberN9059

Preparing Activity—

Project Number—

OPRN/PMA-260

DTIC Applicable—

GIDEP Applicable—

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatdd_form_1664

963C CompliantNo

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

DI-ATTS-80285B

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

Engineering Support Data (ESD) is used to support the testing strategy and development of the Test Program (TP) which is used to test individual avionics Weapon Replaceable Assembly (WRA)/Line Replaceable Unit (LRU) and Shop Replaceable Assembly (SRA)/Shop Replaceable Unit (SRU) on Automated Test Equipment (ATE).

Engineering Support Data (ESD) consists of a Test Strategy Report (TSR), Automatic Test Program Generator (ATPG) data, Test Program (TP) source files, and related information created during the development of the Test Program. ESD documentation shall provide full comprehension of the intent, design, structure, and interrelationship of all TP elements to enable maintenance or recreation of the TP.

This DID supersedes DI-ATTS-80285B.

Preparation Instructions

1Reference document.The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments and revisions, shall be as specified in the contract.

2General.It is intended that the ESD be automatically compiled, correlated, and recorded to the maximum extent possible. The ESD shall address the following elements for each Test Program (TP):

2.1TSR

2.2ATPG Support Data

2.3TP Source Files/Computer Program Aids

3Format.

3.1Test strategy and TP source data.Format for hardcopy delivery of the ESD shall be bound and printed on one or both sides of each 8 1/2 by 11 inch or 11 by 17 inch foldout page (single-sided/double-sided). The reverse side of foldout pages shall be blank. For electronic media, the format shall be as specified on the Contract Data Requirements List (CDRL). All pages shall contain the document control number and date in the upper left portion of the page. Document control numbers shall include revision and volume identification as applicable.

3.2ATPG support data.The format for the ATPG Part I data shall be in an appropriate form and medium required for use on the ATE. The format for the ATPG Part II data shall be in an appropriate form and medium compatible with the ATPG system requirements such that the contents can be directly utilized by the Government to maintain and recreate, if necessary, the delivered ATPG data sets.

4Contents.

4.1Title page.A title page shall serve as the ESD cover and correlate the ESD to the TP. The title page shall include a document number, Operational Test Program Instruction (OTPI)/Test Program Instruction (TPI) number, Unit Under Test (UUT) part number and nomenclature, data and revision of the ESD (by means of a revision letter or dash of base configuration), "AN" identification of the test system, name and acronym (if any) of the test system, developing activity and contract number, and aircraft model.

4.2Reference documents.The ESD shall include a list of all documents used to develop the TP.

5Test Strategy Report (TSR).A TSR shall be developed for each UUT, including the Operational Test Program Hardware (OTPH), hereafter referred to as Interface Hardware (IH). The TSR shall specify the TP design and performance characteristics as well as how the characteristics will be tested using the designated ATE. The TSR shall provide the rationale for the test methodology employed for testing the UUT. The TSR shall address problems or constraints caused by incompatibilities between the ATE and UUT. The TSR section shall include the following: a. Cover sheet b. Revision summary c. Table of contents d. Reference documents e. UUT description f. Trade-off analysis g. Testing concepts h. Functional Flow Chart (FFC) i. System Interconnect Diagram j. ATE/UUT Compatibility Summary k. Test Constraints l. Operator Interaction m. TP Development Specification Non-compliance n. Interface Hardware (IH) Preliminary Design Evaluation o. Engineering Notes

5.1TSR cover sheet.The TSR section shall include a cover sheet. The cover sheet will serve as a title page for the TSR and shall include a TSR document number and nomenclature, UUT part number and nomenclature, date and revision of the TSR (by means of a revision letter or dash on base configuration), developing activity (preparer and approving official(s) listed) and contract number.

5.2Revision summary.The TSR shall include a page titled "TSR REVISION SUMMARY". The page shall be in column format to indicate revision number, date, reason (description of change, list of affected pages, paragraphs, tables, and/or figures), and approval column. This page shall include the original issue date of the TSR and be subsequently updated to list all subsequent changes and revisions. The original issue date must specify "ORIGINAL ISSUE" with an appropriate date.

5.3Table of contents.The table of contents shall be placed immediately after the revision summary and address each element of the TSR. All sections, paragraphs, and list of illustrations and tables shall be represented.

5.4Reference documents.This section shall list all documents used to develop the TSR.

5.5UUT description.This section shall include a general physical description of the UUT and a detailed UUT functional description with an interrelational functional block diagram.

5.5.1UUT general physical description.Include the following:

5.5.1.1Part Number/Nomenclature

5.5.1.2Vendor Name/Part Number

5.5.1.3UUT Category (analog, digital, hybrid, etc.)

5.5.1.4Number of SRAs/SRUs (if WRA/LRU UUTs)Part Number/Nomenclature/Reference Designation

5.5.1.5Exploded view of repairable assemblies Test Points/connectorsAdjustment/alignment points

5.5.1.6Disassembly for test/adjustment/alignment

5.5.1.7Cooling requirements

5.5.2UUT detailed functional description (theory of operation).This section shall include a detailed functional description interrelated to the UUT functional block diagram for each mode of UUT operation. All functional sections of the circuitry shall be addressed and thoroughly described, including the purpose of each operating mode and the manner in which the mode is initiated, executed, and completed. Functional block diagrams are to be included in this section. The narrative shall address BIT/BITE functions, external and internal signal paths, power inputs, and the direction of signal flow throughout the UUT for each functional section of the circuitry.

5.6Trade-off analysis.This section shall analyze various TP design trade-offs (mechanical and electrical) to determine that the UUT can be tested to its designed parameters. The trade-off analysis shall include functional verses parametric testing, digital testing, fault detection/fault isolation ambiguity group size, and test program efficiency.

5.6.1Functional vs. parametric performance tests.The analysis shall determine testing requirements to ensure the UUT is Ready-For-Issue (RFI). This determination is achieved through the identification of tests needed to ensure the UUT functions in the next higher assembly. The report shall include the testing requirements needed to meet the tolerances necessary for application within the UUT's avionics system. The report shall include the practicality of complete testing through the use of BIT and functional testing, without the need for parametric testing. However, if the analysis indicates a requirement for parametric testing, the rationale for the combination of functional and parametric testing shall be specified. The definitions of functional and parametric testing described herein are as follows:

5.6.1.1Functional testing.Functional testing is the test approach used to stimulate a UUT to perform its intended mission and measure the performance with respect to mission requirements. This strategy emulates the interface between the UUT and other systems with which it is normally interconnected. The result of such an approach is a GO/NOGO determination of the UUT's ability to perform its intended function(s).

5.6.1.2Parametric testing.The testing methodology that involves the sequential application of known stimulus (via the I/O interface) to various sub-sections of the UUT and individually compares each output response (with appropriate signal loading) to the prescribed limits of the corresponding sub-section. The accumulation of successful sequential tests will verify the UUT's sub-section circuitry or components as operational. The combination of these successful sectional tests will verify the UUT as RFI without the necessity of emulating the UUT's functional operation.

5.6.2Fault detection/fault isolation analysis.This section of the analysis shall include a fault detection/fault isolation analysis to evaluate the faults/functions tested/detected by the TP. This section shall specify the intent to meet the ambiguity group size, and why the method chosen was selected. If Maintenance Assist Modules (MAMS) or extender cards will be used during fault isolation, this section shall specify the cost effectiveness of the approach in terms of life cycle costs, including MAMS costs and support costs. In addition, a FAULT ACCOUNTABILITY MATRIX TABLE (FAMTBLE) (see figure 1) shall be provided for each SRA/SRU and Interface Hardware Test Program (IHTP) in accordance with the following instructions: FAMTBLE PREPARATION INSTRUCTIONS The FAMTBLE serves as a comprehensive table of performance and diagnostic capabilities for the SRA/SRU and IHTP presented in the TSR.

5.6.2.1Fault No. (Column 1):Enter a numerical identifier for each fault contained in the respective list of faults.

5.6.2.2Component Reference Designator/Pin Number (Column 2):Enter the reference designator and pin number for each component.

5.6.2.3Fault Mode (Column 3):List the appropriate fault modes for each pin of each component in Column 2 based on the fault mode(s) defined in Figure 2.

5.6.2.4Detectable/Non-Detectable (Column 4):Identify whether the fault mode is detectable or non-detectable at the edge or test connector. Enter D (detectable) or ND (non-detectable). Detectable (D): The fault mode can be detected at an edge or test connector. Non-Detectable (ND): The fault cannot be detected at an edge or test connector.

5.6.2.5Insertable/Non-Insertable (Column 5):Identify whether the detectable fault mode can be inserted during integration. Enter I (Insertable) or NI (Non-Insertable). Insertable (I): The fault can be inserted during integration and acceptance testing without causing damage to CASS, IH, or the UUT. Non-Insertable (NI): Inserting the fault would result in damage to CASS, IH, or the UUT. NOTE: 1) Soldering actions are not considered damaging. 2) Power bus faults that are detectable by the Safe-To-Turn-On (STTO) tests are not considered damaging unless the insertion action would cause damage.

5.6.2.6Performance Test Number (Column 6):Enter the performance test number that verifies each pin listed in Column 2 and detects the fault modes listed in Column 3. Each detectable fault mode shall have an associated performance test designed to detect that fault mode.

5.6.2.7Diagnostic Test Number (Column 7):Enter the diagnostic test number that isolates the fault modes identified in Column 2.

5.6.2.8Ambiguity Group (Column 8):Enter the list of components within the TPS ambiguity group.

5.6.2.9Remarks (Column 9):Remarks shall be used to describe the rationale for non-detectable and non-insertable fault modes. Identify the faults inserted during integration and acceptance testing.

5.6.3Test program efficiency analysis.Test Program efficiency is a primary consideration in test program design. The analysis shall specify test approach that will minimize run-time and operator interaction. In addition to the use of BIT, the analysis shall specify the approach considered in testing the least reliable function(s) of the UUT at the earliest feasible stage(s) of the test program. The analysis shall specify the structure utilized such that the number of time-consuming station and UUT setups or operating mode initiations will be reduced. The analysis shall include any other UUT/IH/ATE integration factors that impact efficiency and estimate the end-to-end run time to process a good UUT. Address individually and collectively the time increments for set-up, functional tests, and manual intervention times.

5.7Testing concept.This section shall address the testing concept and test techniques employed to test each UUT function and mode of operation with the ATE. Specify in detail the test approach resulting from each trade-off analysis herein. The testing concept shall serve as a traceable basis for ATE/UUT compatibility summaries, test constraints, operator interactions, run-time predictions, and TP non-compliance.

5.7.1Test philosophy.This section shall describe in detail the test philosophy exercised to perform each of the following testing concepts in sufficient detail to enable the Government to evaluate the testing philosophy employed. The testing philosophy shall identify all proposed circuitry in the IH (test fixtures, holding fixtures, etc.) required to implement the UUT test methodology.

5.7.1.1UUT adjustment/alignment test.As applicable, the TSR shall describe completely the adjustment/alignment procedure to test the UUT. Include procedures for UUT disassembly for alignment/adjustment and test point accessibility.

5.7.1.2Diagnostic testing.Any special tools or diagnostic aids shall be specified and supported with part number and sketches.

5.7.1.3Digital testing.Specify the intent to test the UUT functions and meet the required ambiguity group size when using an automatic test program generator. Specify the ATPG compatibility to model, develop automatic and manual test patterns, and generate fault dictionary data. Identify and explain workarounds for any components not available in the targeted ATPG model library.

5.7.1.4Power application/Safe-To-Turn-On (STTO) test.

5.7.1.5Power testing and load requirements.

5.7.1.6BIT/BITE testing.Address all levels of testing, including diagnostics.

5.7.1.7Timing/clock requirements and testing.

5.7.1.8Bus and memory testing.

5.7.1.9UUT unique functions (digital/analog/hybrid).

5.8Functional Flow Chart (FFC).This section shall demonstrate the test sequence to logically organize the functional test requirements showing the test strategy being implemented on the ATE. The FFC shall be a descriptive definition of the functional test groups.

5.9System Interconnect Diagrams (SID).This section shall define the interface between the ATE and the UUT. Graphically illustrate the initial UUT/IH/ATE interface required to begin the test program. Any interface connection necessary during test program execution run-time shall be adequately described by notation. Ground straps shall be shown. Illustrations shall indicate reference designators for all cable connections.

5.10ATE/UUT compatibility summary.This section shall compare the performance capabilities of the ATE against the unique UUT parameters. Any accuracy or range incompatibilities between the ATE and UUT must be identified. In a table, match each UUT stimulus/response pin to a corresponding ATE asset; include the range and Tolerance Accuracy Ratio (TAR), indicating critical test parameters resulting in low TAR. If the summary indicates that the IH should contain active circuitry, provide justification to the procuring activity. If the summary indicates that the IH should contain functions that already exist within the ATE, address the rationale for installing functions in the IH and describe the benefits gained.

5.11Test constraints.This section shall identify all factors that limit the ability of the ATE to test the UUT. This shall include a description of each UUT function and mode to be tested and the limitation of the ATE to adequately or efficiently test the function. The report shall state the type, purpose, and function of signal conditioners required in the interface to overcome any identified constraints or mismatches. When active IH circuitry will be used in the TP, address the impact on other TPs incorporated into the same IH.

5.12Operator interaction.This section shall specify the type of man/machine interface required to test the UUT.

5.13TP development specification non-compliance.This section shall include any development specification requirements that can not be met, such as ambiguity group size or IH weight.

5.14Interface Hardware (IH) preliminary design evaluation.

5.14.1IH physical layout.This section shall illustrate the IH physical requirements during testing. Illustrate accessibility to UUT test points/connectors, adjustment/alignment points, cooling requirements, and for removal of repairable assemblies. Include drawings of the IH (including all cables, test fixtures, and holding fixtures). Include drawings of all IH circuit cards, internal wiring and components, and any other assemblies, as applicable.

5.14.2IH circuit complexity.This section shall specify the design approach to ensure that the interface function of the IH shall be accomplished as simply as possible while remaining consistent with the IH functional requirements.

5.14.3IH design optimization.This section shall specify how the design of the IH conforms to the contractual requirements in order to maximize design-for-testability.

5.14.4IH reliability and maintainability.This section shall address IH reliability, maintainability, and supportability in accordance with the requirements of the contract.

5.14.5IH self-test considerations.This section shall address the IH as a separate TP and be included in a separate TSR. However, the IH preliminary design results regarding design-for-testability and test points shall be documented in this section of the TSR.

5.14.6Mechanical considerations.This section shall specify the dimensions, weight and moment of the IH (including UUT and cables) that must be supported by the ATE interface and accessibility of SRA/SRU components, test points, alignment/adjustment points, and test connectors. Any special tools or diagnostic aids, such as extender cards MAMS, required to maintain the IH shall be specified and supported with part numbers and sketches. Deviations from the contract specification requirements shall be addressed.

5.15Engineering notes.This section shall include engineering notes of special interest, including calculations required to substantiate testing problems and alternate solutions.

6Automatic test program generation (ATPG support) data.The ESD shall include Automatic Test Program Generation (ATPG) data consisting of two separate and distinct parts. Part I shall contain all of the final ATPG data sets that are necessary and sufficient for post-processing and merging the final results of an ATPG system execution into a test program that will be utilized on a designated ATE system. Part II shall contain all of the final command and data files that are necessary and sufficient to generate and maintain, if required, the final ATPG data contained in Part I.

6.1ATPG data Part I.ATPG support data Part I shall contain all the final ATPG data sets required for pre/post-processing the final results of the ATPG system into a test program for a particular ATE system. Typically the Part I information is in the form of an output tape from the ATPG system. This information can also be processed in files depending upon the requirements of the ATPG and physical location (within the ATPG software, or separate programs contained on the same hardware of the ATPG) of the pre/post-processor and compilers. Examples of data contents are as follows: a. Table of Contents b. Model Data Set/Files c. Stimulus Data Set/Files d. Response Data Set/Files e. Fault Isolation Data Set/Files f. ATE Specific Data Sets/Files g. Probe Data Sets/Files

6.2ATPG data Part II.Part II data contains all the final information, such as command, data, pre/post-processor files and work-arounds, from the ATPG system and ATE software development station, if used, necessary to recreate and modify the final ATPG data contained in Part 1. Part II data is a selected subset of all the command and data files utilized, generated, and saved by the ATPG system during normal processing. The ATPG data shall include command and data files from the following: a. UUT source data b. ATPG system c. Pre-processor d. Model processor e. Pattern processor f. Simulator processor g. Fault analyzer processor h. Probe commands i. Post-processor j. Utility commands

6.2.1ATPG command and data files content.The generic functions that are common to most ATPG systems include (1) model processor, (2) pattern processor, (3) simulator, and (4) fault analyzer sub-systems, all under control of an ATPG controller. Modeling programs, user model library, ATPG system library, pre/post-processors, and utility language programs, all provide support functions. This section shall include all command and data files with embedded comments that specify the intended purpose of the command and control options selected (for all options including default options). This section shall specify the intended purpose of any work-arounds, exceptions or additional data requirements. The ATPG data Part I and Part II files are necessary for TP generation and for organic maintenance of the delivered ATPG product and include the following types of command and data files.

6.2.1.1Model command and data files.This section shall include all model command and data files to directly describe the models used in the ATPG system. All model data shall contain the source data files used. For behavior and higher level language models used in the ATPG system both source and resultant compiled files shall be included. Command files shall include explanations concerning options used. This section shall include model information in the form of a complete model library usable in the ATPG system which contain all models used in the TP. All associated files (i.e., timing, netlist, family, etc.) needed to describe and use the model on the ATPG system shall be included. If the ATPG system has unique software programs to create Read Only Memory (ROM) and programmable microcircuits models, such as Programmable Logic Arrays (PLAs), then the command and source data files shall be included. Data maps and formats shall be clearly defined in the data files. Each model work-around shall be identified and its purpose clarified by the use of embedded comments and narrative. Workarounds are commonly use for modeling analog/hybrid devices, tri-state logic, pull-ups, etc.

6.2.1.2Unique model components.Models to accommodate workarounds for "dummy" models (e.g., initialization, future growth, etc.) shall be included and its purpose stated. Identification and cross referencing of unique model components (chips, gates, etc.) that are not identified by component model identifiers on the assembly drawings (i.e., 233AN instead of 233ANUl) and correlate directly to UUT nomenclatures shall be included and its intended purpose stated. And, any other procedure or techniques that require end-user knowledge shall be addressed to the extent necessary to meet the objective of autonomous organic maintenance support.

6.2.2Pattern processor command and data files.Pattern command and data files for generation of stimulus shall included in a usable form for the ATPG system. Any workarounds or techniques required shall be included with its purpose stated. Any assumed pre-ATPG condition or initialization patterns, if required, shall be annotated in the source files with purpose stated. Use of "dummy" input pins for initialization shall be included, if used.

6.2.3Simulator command and data files.The final command and data stimulus pattern files shall be included in accordance with 6. above. Any workarounds shall be identified.

6.2.4Fault analyzer command and data files.The ESD shall include all ATPG fault analyzer command and control options used to generate the final fault analyzer data set. Examples include:

6.2.4.1Command and source files used to define and establish total fault universe for the UUT explaining faults analyzed for each component.

6.2.4.2Fault universe component call-out resolution data identifying components and component replacement groups (CRG).

6.2.4.3Fault detection data identifying pre-detected and percent of faults detected with respect to total faults.Reasons for undetected or pre-detected faults shall be included.

6.2.4.4Command and data explaining the process for collection of fault analyzer data.

6.2.4.5Number of fault detects used for fault dictionary or probe data required to retain compatibility with post-processing and ATE use.

6.2.5Pre/Post processor command and data files.The ESD shall address utilizing pre/post processor programs to regenerate the resultant ATPG product. Command and data files with appropriate comment shall be included.

6.2.6Probe command and data files.Command and data files for developing a probe data base shall be included. Any requirements for ATE probing work-arounds or algorithms shall be included by embedded comments.

6.2.7Post processor command and data files.The ESD shall include command and data files required to generate the final product. Examples include:

6.2.7.1Post Processing the final ATPG Part I data set items

6.2.7.2Post Processing the final ATPG Part II data set items

6.2.7.3Post Processing to create an ATPG test program to cross-reference the target ATE/UUT input/output pin map requirements.

6.2.7.4The format of all output files from any pre/post-processing shall be clearly defined and provided so that translators, processors, compilers, or isolation routine programs and software can be created.

6.2.8Utility command and data files.The ESD shall include all utility command and source files necessary to process final ATPG test program product. Command, executable, and batch files source files shall be included so that execution of such files will produce identical results on the ATPG system allowing for regeneration of Part I items.

7TP source files/Computer Program Aids.TP source data shall consist of data or text files generated during test program set development, including CAD files, databases, spreadsheets, and word processing files. The commercial software used to generate the data or text files shall be identified with commercial software special license or usage rights assigned.

7.1Unique parts specification.This section shall contain a description of the use, function, and modes of operation for components used in the TP that are not fully described by manufacturer's data, military specifications or Government furnished drawings.

7.2Generic description.The general description shall identify and define the operational parameters and characteristics of any unique part used in the TP generally be in the form of one of the following cases: Case A. In the case of a unique part that is derived from a commonly available (commercial or military) generic part, the generic description shall identify the parameters and characteristics of the generic part. For example, the generic description for a ROM or a programmable microcircuit (PAL/PLA/PLD, etc.) would simply be the manufacturer's data for the part prior to programming. Case B. In the case of a unique part that is not derived from a generic part, the generic description shall identify minimum, maximum and nominal parameters and characteristics in sufficient detail to provide a complete performance specification for the part. Typical parameters to be specified shall include the following: ambient operational temperature, ambient storage temperature, supply voltage, supply current, power consumption, input voltage, input current, input capacitance, input loading, input voltage breakdown, output voltage, output current, output capacitance, output drive, output voltage breakdown, noise immunity (rejection and DC and AC margin), rise times, fall times propagation delay time, switching speed, transfer (input versus output characteristics) and operational frequency range.

References

—

Figures

Figure 1. SRA/SRU Fault Accountability Matrix Table

Figure 2. Component Failure Modes

Figure 2. Component Failure Modes (continued)

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer