Test Program Set Development Research Articles

High-speed I/O capabilities added to military automatic test equipment (ATE) using synthetic instruments

High-speed testing of digital transmission necessitates a functional test, which is typically the test performed by automatic test equipment (ATE) on military and avionics units under test (UUTs). Older military ATEs, and indeed most modern day ATEs, are not equipped with test instruments for high-speed data transmission. Typically, such high-speed test instruments are designed for signal characterizations in design verification tests, which require human interpretations. The primary purpose of military ATE is to allow non-technical soldiers or sailors to comprehensively test and diagnose all types of electronics and to derive very specific repair instructions. We introduce synthetic instruments (SIs) and show how they offer a feasible option for traditional ATEs while they are also able to test high-speed unit under test (UUT) signals. Rather than replace military ATEs, the high-speed SI solution can be integrated into existing ATEs, even legacy ATEs. The clear benefit of this approach is the extension of ATE useful life and the capability to test present and even future circuit types. It also improves the performance of military ATEs by allowing them to test multi-Gbps signals. High-speed I/O, such as the USB 3.0 that operates at 5 Gbps is discussed. (Although USB 3.0 was recently renamed as USB 3.2 Gen 1, for consistency in this article, we use the traditional term USB 3.0.) The example utilizes a special-purpose USB 3.0 SI that responds to commands in the test program set (TPS) developed by test engineers. The same USB 3.0 SI, including the test commands, can then be reused on other ATEs and UUTs with the same bus. This can be an industry-wide game changer when SIs are developed for other I/O buses and applications. Utilizing SIs reduces TPS development costs and ATE expenditures, while improving TPS development times and effort.

Automated test systems test program software — making the invisible visible

In Test Systems Test Program Software-The Invisible Technology we indicated that the amount of work associated to Test Program Set (TPS) development, maintenance, and migration in the Department of Defense (DOD) has grown significantly [1]. In the paper, we proposed a model for a TPS developer's certification plan, training program, and Quality Assurance management plan. This paper is a continuation of that original work. It will take a deeper look into one area: TPS Quality Assurance. Development of successful test program sets for Automated Test Systems (ATS) is enhanced by timely application of proven management procedures such as quality control plans, design reviews, change control procedures. It is also enhanced by controls over cost, schedule, development, deployment, and end item configuration. This paper is devoted to a general discussion of management and technical procedures, plans, tests, and reports that are applicable to assuring quality throughout development and delivery of the TPS.

TPS development using the Microsoft .NET framework

General purpose programming languages such as ANSI-C and C++ are commonly used for test program set (TPS) development when test-specific languages fall short or where TPS developers and system integrators want to take advantage of the commercial tools available for these languages. This paper explores adding .NET languages, specifically C#, to the list of general purpose programming languages used for TPS development. The paper starts with an overview of the .NET Framework and includes a description of the support for legacy technologies. A description of common problems with non-.NET languages and how .NET languages and tools address these problems follows. Finally, the paper concludes with examples of test development in .NET.

Ask the user: A practical approach to test program set development

The development of a military weapon system is a long and arduous process. How to maintain that system after it is fielded is often a quick afterthought. The automatic test equipment (ATE) and associated test program sets (TPS) are selected and developed based solely on the physical operating specifications and test parameters of the system. The people who actually use the ATE to repair the system and those who maintain the TPS software usually have little or no input until the ATE and TPS are delivered to them. This paper provides a case study of the development and acceptance of an ATE and TPS for the AN/ALQ-172 electronic countermeasures (ECM) system. It does not dwell on the specific technology and mathematical analyses designed into the TPS, but instead focuses on the end goal - using the TPS to repair the system. The paper discusses the initial development of the TPS without user input, then discusses some of the problems discovered when software maintenance engineers and system repair technicians became involved. The case study concludes with a review of the final TPS acceptance testing and an overview of the benefits and costs of involving the user throughout the development process.

Shared technologies: a new roadmap

The long-term goal of the USAF Shared Technologies Program is to facilitate the development of a roadmap for technology insertion on the wide variety of legacy Automatic Test Equipment (ATE) accumulated by the USAF over the past 30 years. A successful roadmap will provide for Operation & Support (O&S) cost reduction, preserve Test Program Set (TPS) development investments, and evolve in concert with the DoD Executive Agent for Automatic Test Systems (ATS) initiatives and commercial industry, and (e.g., NxTest) changes. The near-term objective of this phase of the USAF Shared Technologies Program is to demonstrate the feasibility of incorporating available commercial technology into the Radio Frequency (RF) Mobile Electronic Test Set (RFMETS). The RFMETS was originally delivered to the USAF during the early 1990s and is used to support a variety of C-130 avionics including the APQ-170 and APQ-180 Radar Systems.

Proposal to TPS delivery in 4 months?

Decreasing the often lengthy Test Program Set (TPS) development time is a high priority for both DoD and commercial industry. A protracted test development time for a commercial product can make or break its success. It can impact time-to-market goals for a product, which in turn, can result in a loss of market share. Though the DoD world has different objectives, they, too, are concerned with long test development times which can increase costs and jeopardize a weapon system's mission readiness. The case study for this paper is a test system developed by BAE Systems in less than four months to meet a commercial customer's stringent schedule requirements. The factors that contributed to the success of this project are examined, as is their relevance to the DoD world. The desire is to apply relevant lessons learned from the commercial industry to DoD programs, yielding a decrease in TPS development time.

Next generation functional test program development system

While superior-quality functional board test has been a goal for most high reliability electronics manufacturers, the time and effort for generating such test programs using today's tools and processes makes this difficult to achieve in a cost effective manner. This paper will introduce a revolutionary approach to functional board test program development that combines the comprehensiveness of software-based simulation with the speed and simplicity of hardware emulation. The result is a functional Test Program Set development system that can produce high fault coverage, diagnostic test programs in a fraction of the time it takes using traditional techniques, and at a lower unit cost. In this paper we will first provide a brief background on the strengths and weaknesses of current software and hardware TPS development techniques-simulation hot mock-up. Next, the new approach is described in detail and contrasted against the existing techniques. Finally, actual experience to date using a prototyped system is presented.

Applying software process to virtual instrument based test program set development

Virtual Instrument (VI) based test program development systems, as exemplified by National Instruments' LabVIEW, provide very powerful design capture fools that allow the test program set (TPS) developer to rapidly prototype test strategies. As usual, in great power lies danger. In this case the danger is the ease of which VIs are reused. While code reuse is a desired feature, unintentional modifications to common VIs, name clashes, and library corruption are all potential headaches resulting from uncontrolled changes to VIs stored in shared libraries. Undetected Spontaneous Upgrades to library components can ruin a maintainer's day when the program loads with broken wires. Developing quality software requires software quality. This paper provides recommended practices to address the Key Practice Areas (KPAs) defined in the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) in the context of TPS development in LabVIEW. Repository management procedures such as check-in check-out and change tracking and documentation are described.

The World Wide Web leads a revolution in ATE programming environments

New software technologies, including the World Wide Web, may seem far removed from the tasks facing test program set (TPS) developers, but they promise to revolutionize the way TPS data is organized, presented, and used. This paper will describe how an integrated TPS development and execution environment can capitalize on these new technologies to improve test programming efficiency.

C-17 successful application of existing automatic test equipment

The C-17 Program utilizes existing B-1B Automatic Test Equipment (ATE). The C-17 decision is in harmony with the Air Force emphasis on reducing proliferation of unique ATE. The ATE selection was made after consideration of cost, performance and supportability tradeoffs. Minimal augmentation of the government inventoried equipment was required which did not affect the existing hardware and software configuration, This approach significantly reduced C-17 program ATE development costs and afforded the program the use of established logistics elements and support structure. The C-17 program demanded concurrency of support structure and aircraft development-the ATE solution met that demand by reducing risks to a manageable level for both test program set development, and Air Force operation and training requirements.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>