CASS family TPS Support toolset

This paper describes the incorporation of a Commercial-Off-The-Shelf (COTS) video stimulus instrument in the Navy's Consolidated Automated Support System (CASS) ATS. Included are COTS instrument selection, CASS software modifications, CASS modifications, and product enhancements, which evolved out of the effort. The video stimulus requirement of the U.S Navy's Consolidated Automated Support System (CASS) was fulfilled via the integration of a commercial instrument into the CASS. The effort involved product research, selection, and testing; mechanical and electrical design and testing; software engineering; integration; and fielding. The major component (a commercial video stimulus instrument) was selected. CASS software was modified to support an ATLAS interface to the instrument. The CASS ATS was modified to accommodate the instrument; this modification required mechanical design testing. The video signal path (instrument to CASS interface) was developed; and the product was enhanced to provide rudimentary animation capabilities in support of infrared tracking systems. The focus of the paper is product selection and requirements matching; software development and integration with the existing product; system testing and calibration; retrofitting of fielded systems. A brief section focuses on enhancements (beyond the original scope) that evolved from capabilities of the COTS instrument.

In modern systems there is a desire to create Test Program Sets (TPSs) in multiple languages. However, most Automatic Test Equipment (ATE) is designed with only one test executive in mind and the exclusion of all others. This paper discusses a proven design to allow for Multiple Test Executives (MTE) on a single system. In addition, the test executives are divorced from the operator or maintainer so that they are not directly aware of the underlying test exec. This allows TPS programmers to work in a language of their choice and expertise in order to generate TPSs in the most efficient manner. This also allows for legacy TPSs to be more easily moved to the new system as it is more likely that there is a good fit between one of the legacy test programming languages and one of the many supported by the new system supporting MTE. By allowing MTE under one common operator interface, a consistent look and feel can be enforced while still allowing for MTE. This abstraction of operator interface from the actual test executive is done by taking advantage of several aspects of modern test executives and user interfaces. Most modern test executives actually live as an engine which can be controlled via software. While they may come with a GUI out of the box (Test Stand, Test Studio, ATLAS, etc), most modern test executives are run by an underlying engine which is controllable through similar interfaces. Point in fact, Test Stand, Test Studio, and PAWS ATLAS can (and are) controlled in this manner. By allowing for software control of the test executive, a common GUI can control another common run time engine which communicates with all the test executives and runs TPSs on the corresponding test executive. By also creating a common interface to the GUI and instruments, all of the test executives can communicate through the common software and be controlled by and control a common set of user interfaces and instruments.

Managing Automatic Test Systems in the 90's is more than writing BASIC test programs to control IEEE 488 instruments. Managing your Automatic Test System involves Test Program Set (TPS) development, management of re-usable test objects, data management, tester resource management and user interface management. In addition, the Automatic Test System must provide a Test Executive that controls the overall test development and execution environments. The benefits of this type of system are, lower TPS development cost, a common user interface and lower TPS development cost, a common user interface and lower operator training cost. This paper focuses on these aspects of Automatic Test System Management. >

This research project aims to expand the capability of current US Navy Automated Test Equipment (ATE) family of testers known as the Consolidated Automated Support System (CASS). Industry research is now focused on breaking the historical construct of test equipment. Advances in the field of Synthetic Instruments have opened the door to test avionics in new ways. Every year new capabilities are developed using core hardware and increasingly capable software modules to create complex waveforms. This research creates a Digital Radio Frequency Memory (DRFM) Synthetic Instrument that can be programmed to perform a wide array of low latency Radio Frequency (RF) tests. Synthetic Instruments are defined as a concatenation of hardware and software modules used in combination to emulate a traditional piece of electronic instrumentation. This Synthetic Instrument couples high speed Analog-to-Digital Converters (ADC) to high speed Digital-to-Analog Converters (DAC) with Field Programmable Gate Arrays (FPGA) in between for digital signal processing. An RF front end is used to down convert the RF to baseband where it is sampled, modified, and up converted back to RF. The FPGA performs Digital Signal Processing (DSP) on the signal to achieve the desired output. Application of this DRFM in automated testing is demonstrated using a Reconfigurable Transportable Consolidated Automated Support System (RTCASS) tester at Naval Air Systems Command (NAVAIR) Jacksonville, FL. The Unit Under Test (UUT) is an ALQ-162 Defensive Electronic Countermeasures (DECM) receiver-transmitter. Ultra-low latency signals are generated to simulate enemy jamming stimulus. As the ALQ-162 detects and responds to the input, the DRFM switches to a new frequency. The time taken by the ALQ-162 to acquire, respond, and re-acquire is measured. This test confirms the internal Yttrium Iron Garnet (YIG) oscillator meets slew specifications. Currently Navy ATE can only test RF units using high latency steady state tests. This research project developed a supplemental unit that can be added to the VXI chassis in the CASS family of testers and conduct ultra-low latency active tests. The instrument acts as hardware-in-the-loop to perform real-time tests including a new capability to measure jamming response time from DECM avionics. Demonstrated performance capabilities include: latency <; 100 ns, output Spurious-Free Dynamic Range (SFDR) > 80 dBc, input SFDR > 60 dBc, frequency tuning resolution <; 2 Hz, and frequency settling time <; 0.5 ns. New RF capabilities developed by this effort parallel similar research ongoing for digital test instruments like the Teradyne High Speed Subsystem. Incorporating this Digital RF Memory synthetic instrument into current and future ATE will improve readiness and supportability of the fleet. Improvements demonstrated by this research project will expand the type and quantity of assets able to be tested by current and future ATE.

This paper outlines an approach to developing an emulation environment embedded in an automated test system (ATS) controller's operating system kernel. By taking this approach, it is possible to design an emulator that is built for multiple ATS environments, allowing it to be seamlessly ported from ATS to ATS for use with many different test program sets (TPS). This paper then explores possible uses for such an emulator for the purpose of reducing the life-cycle costs associated with ATS and TPS development and maintenance.

The DoD has achieved success with recent automatic test equipment (ATE) families, as evidenced by the navy's consolidated automated support system (CASS) and the army's integrated family of test equipment (IFTE) programs. However, as these systems age, the increased requirements for technology insertion due to instrument obsolescence and the demands of advanced electronics are becoming evident. Recent advances in test technology promise to yield reduced total ownership costs (TOC) for ATE which can incorporate the new technology. The DoD automatic test system (ATS) executive agent office (EAO) objective is to significantly reduce total ownership cost. Several objectives have been identified including use of synthetic instruments, support for legacy test product sets (TPSs), and more efficient ways of developing TPSs. The NxTest software architecture will meet the objectives by providing an open systems approach to the system software. This will allow for the incorporation of commercial applications in the TPS development and execution environments and support current advances in test technology.

This paper discusses a practical approach to the use of Commercial-Off-the-Shelf (COTS) tools to implement Automatic Test Equipment (ATE) and Unit Under Test (UUT) signal-based models to support both new Test Program Set (TPS) development and TPS rehost activities. This modeling technique also provides a standard to which existing and future ATEs and UUTs can be modeled and used for analysis and comparisons. The signal-based model is implemented via a Structured Query Language (SQL) Relational Data Base Management System (RDBMS). COTS Rapid Application Development (RAD) tools, such as Microsoft/sup (R)/ Visual Basic/sup (R)/ Microsoft Access/sup (R)/ and PowerBuilder/sup (R)/, are employed to implement interfaces to the SQL database model and to provide the necessary algorithms for data comparison, model reuse and other manipulations of the model data. After models are established for both the ATE and UUTs, ATU/UUT compatibility analysis can be performed to identify any potential incompatibilities. This information can be used to optimize the selection of a target ATE for a selected group of UUTs. It can also be used to identify any signal deficiencies in the target ATE that require ATE enhancements or Interface Test Adapter (ITA) signal conditioning, to ensure UUT compatibility.

The Versatile Automated Depot Test Station (VDATS) is a major component in solving the U.S. Air Forcepsilas Automatic Test System (ATS) proliferation concerns. VDATS addresses the proliferation issue by providing the capability to replace an estimated 260 depot-level test systems that assume 150 different configurations, as well as a large number of intermediate-level test systems.The Department of Defense (DoD) has invested billions of dollars in aging and increasingly obsolete ATS used to troubleshoot and diagnose components of military aircraft and weapon systems. The issues of increased downtimes, test system obsolescence, and nonportable Test Program Sets (TPS) further contributes to the DoD's continued reporting of spare parts shortages and the increasing impacts that ATS obsolescence has on the readiness of military aircraft and weapon systems. The VDATS provides a viable approach to resolving these issues. VDATS has an extensible designed-in expansion capability intended to support present and future Air Force workloads by providing an organically-developed ATS platform with a modular, open-systems architecture that is Flexible, Capable, Tailorable, and Sustainable. VDATS makes it technically feasible to now realize the laudable 1994 DoD policy goal stated in: Military Readiness: DoD Needs to Better Manage Automatic Test Equipment Modernization," GAO-03-451, March 2003.[1] VDATS meets this stated DoD policy goal of producing an ATS capable of supporting multiple weapon systems, aircraft, and eventually being interoperable between DoD services. In 2007 the Air Force's VDATS was officially designated as a DoD Standard Family of Testers, supporting the 2005 ATS Master Plan requirement meant to reduce ATS proliferation and life-cycle operations and support costs. This paper briefly examines the present-day issues and how the U.S. Air Force is resolving these with the VDATS program. It also explains the strategy to preserve present-day and near-future TPS re- host investments, while enhancing system capabilities to meet the Air Force's depot and intermediate-level ATS requirements for the foreseeable future.

The purpose of this paper is to present a conceptual approach and to make practical recommendations on how to improve the current Automatic Test Equipment (ATE) testing and maintenance capabilities by utilizing the existing cloud computing model to build a globally linked ATE maintenance system. The basic tenet of the ATE community is to support a multi-tiered maintenance concept which, in general, is a three tiered system that is composed of organizational maintenance (O-level), intermediate maintenance (I-level), and depot maintenance (D-level) organizations. The goal of the ATE is to (1) quickly and accurately detect and isolate each fault, (2) provide software tools for analyzing historical data, and (3) gather, manage, and distribute accurate and reliable maintenance information for the failed Unit Under Test (UUT). The ATE system should provide services that will (1) maintain a repository of information that will improve fault detection and isolation, allow for off-platform assessments, document failures, and help quantify corrective actions, (2) reduce false UUT pulls, and (3) reduce repair time by prompting repair procedures. Furthermore, the ATE system should provide additional services that will help optimize the time to diagnose problems by using collected failure information and by recommending entry points into the Test Program Set (TPS) software. It should also present information to the ATE maintainer to aid in informed repair decisions which could be in the form of pilot debrief results, platform Built In Test (BIT) results, O-level test outcomes and corrective actions, and maintenance and usage history of the platform and UUT. So, based on this definition of ATE maintenance the use of cloud computing can be used to provide services to improve the overall ATE testing throughput which will result in bottom line improvements to ATE life cycle costs. By using cloud computing, which is defined to be “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”, users can develop cloud computing models that will provide access to application software and databases that can be used to build a globally linked ATE maintenance system. This paper will discuss the essential characteristics of the cloud computing models and define the various flavors of cloud offerings available to designers today. This paper will also analyze the cloud computing model to arrive at a conceptual approach that can be used to enhance the current ATE Testing and Maintenance capabilities. Practical recommendations will be discussed on how to transform the current ATE Testing and Maintenance capabilities into the specific cloud computing model offerings in order to help configure a globally linked ATE maintenance system.

In "Automated 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.

For decades, the automatic test community has worked to develop hardware standardization and interface protocols that aid in mitigating the impact of equipment obsolescence on the repair and maintenance mission. The traditional view of Test Program Set (TPS) transportability in this environment has always been one of migrating a legacy TPS to a new hardware architecture design born out of a need to replace aging technology or provide new test capability. The Department of Defense (DoD) has recognized the benefit of standardizing automatic test systems (ATS) through policy guidance whose intent is to drive the services to a common configuration test environment, thereby reducing life cycle sustainment costs for all DoD systems. Today, hardware standardization has advanced to the point that many ATS look and function very similar to one another. However, there are two major hurdles that continuously thwart our efforts to develop a standard core test system, the lack of a standard UUT interface and the lack of an open architecture software design that facilitates operations in any environment and on any test system architecture. Automatic Test Markup Language (ATML) provides promise with regards to the development of standardized test software interfaces. Developing a standard hardware configuration for all test requirements is ultimately achievable with the technology currently available today except for one simple but hugely significant hurdle, the cost involved in re-hosting the myriad of test program sets currently in existence. Therefore, any significant advance in common interface design has to take into account the need to minimize the impact to existing test program sets. This paper will seek to explore the various technological possibilities for overcoming the barriers to true TPS transportability that exist in today's automatic test community.

In military and aerospace applications test systems are expected to have a service life of more than 20 years. Over the life of the test system individual test instruments may become obsolete or may require upgrading due to changes in TPS requirements. Any changes to these legacy test instruments may cause problems with the deployed Test Program Set (TPS). Most test systems are designed with an instrument wrapper layer to isolate the TPS developer from the instrument driver Application Programming Interface (API). This wrapper layer will minimize the changes to the TPS due to changes in individual test instruments. This paper discusses some of the issues that may be encountered when either replacing obsolete instrumentation or upgrading instrumentation in a test system. Some of the issues are easy to discover and understand such as minor differences in the instrument specifications between the legacy test instrument and the replacement instrument. Other issues may not become apparent until attempting to use the replacement instrument within a test program or when upgrading system checkers. For example a test program may fail with a replacement instrument due to signal settling time. This problem can occur when the replacement instrument performs measurements faster than the legacy instrument. The problem can be fixed by either adding a wait in the test program or by adding a trigger delay in the test program or wrapper. The main focus of this paper will be on the problems related to the replacement of analog instruments. This paper will not discuss issues related to differences in the instrument driver API since this can usually be handled in the instrument wrapper layer. The problem discussions will look at classes of problems and site some specific examples in each class. Guidelines will be presented for solving or avoiding the problem. Some of this information may also be useful in the design of future test systems and TPSs to avoid similar issues.

It is the mandate of Automated Test Equipment (ATE) to minimize manual tasking and maximize automation. However, the role of the operator remains crucial to successful deployment of any ATE system. Simple tasks such as setting up the Unit Under Test (UUT), correct probing, potentiometer alignments, etc. must be taught so new operators can establish a basic level of diagnostic capability in the fleet. Current Consolidated Automated Support System (CASS) training hardware is based on F-14 and S-3 platforms which are obsolete, utilize antiquated technology, and are difficult to repair. Such hardware also limits Instructors' ability to insert and remove effective training faults. This paper describes a design concept which provides a robust training test set, including hardware, for operators to learn basic troubleshooting skills and ATE interaction. The US Navy recognized the benefits of such a system to address training deficiencies and initiated the development and acquisition of the CASS Training Set (CATS). The test set includes a variety of training scenarios which are commonly seen in the fleet, including digital tests, analog tests, Operational Flight Program (OFP) loads, alignments, Radio Frequency (RF) tests, diagnostics, etc. The CATS training UUT uses latching relays to induce consistent, repeatable hardware faults, and a microcontroller to produce software faults. Faults are applied and removed through the Test Program Set (TPS) and require no soldering or de-soldering of components. This process automates training fault insertion, extends the life of the training equipment, and provides repeatable fault signatures. Consistent training scenarios ensure lower variance in technical capabilities of course graduates. A complete hardware and software package with the look-and-feel of a fleet avionics asset, but the reliability to withstand a training environment provides a valuable tool to train ATE operators and should be a basic part of any ATE system.

The portable intelligent troubleshooter (POINTER) system, originally developed for manual fault isolation, has been applied to intelligent automatic testing, which requires a fresh look at test program set (TPS) design from the perspective of testability theory and artificial intelligence. The resulting novel automatic test and diagnostic approach is a significant departure from conventional test programming techniques. A prototype automatic test equipment (ATE) system that implements a diagnostic control algorithm that computes a context-sensitive test strategy in real time has been developed. This control algorithm operates on a dependency model that describes the testability characteristics of the unit under test (UUT) and a test procedures file that contains the instrumentation setup for each test available for the UUT. This approach to automated diagnostics reduces time and costs in UUT repair. >

This paper addresses using information derived from Built-in-Test (BIT) to fault diagnose Units Under Test (UUTs), wherever possible. This philosophic approach to diagnostic testing is not new. It has been studied over the past 20 years under the visor of "Integrated Diagnostics", but it has yet to be truly implemented in a "real life" military diagnostic test environment. The mindset of Test Program Set design engineering, along with customer and contractor management alike, remains "complete diagnostic testing based upon single catastrophic component failure modes". If we are to generate cost efficient Test Program Sets (TPSs) under reduced military budget constraints, this will have to change! The test engineer must be encouraged to use methodologies to speed up development time and decrease TPS run times. Using present technology, this is possible now, and as the technology matures, will become a truly viable approach in the future. For the purpose of this paper, the author relies heavily on his extensive US Navy Automatic Test Equipment (ATE) and Test Program Set (TPS) experience, as well as on previous studies performed on using BIT to fault diagnose Unit Under Test failures on US Naval Air weapon systems.