Multimedia-electronic technical manual for ATE

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 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.

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.

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. >

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 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 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 framework from which Automated Test Equipment (ATE) manufacturers can use to help them develop, integrate, and deliver ATE cloud-based applications to the consumers of their products. In order to create these applications, the developer can utilize Commercial Web Services (CWS) as a means to help access compute power, storage devices, and other services that provide the flexibility to choose a development platform or programming model that makes the most sense in trying to resolve the problem at hand. CWS provides a flexible environment from which to choose various programming models, operating systems, databases, and architectures to serve the consumers needs. CWS is highly cost-effective in that the developers and consumers pay only for what they use. Using CWS makes it extremely easy to create scalable and elastic systems as the developers can quickly add and subtract resources to their applications in order to meet current or future consumer needs. Furthermore, security is always a concern so CWS builds services in accordance with security best practices by providing the appropriate security features in those services. Using a CWS provides a level of scale, security, reliability, and privacy that are often cost prohibitive for most organizations to meet. This paper will examine available CWS cloud service platforms that organizations can potentially use to help deploy applications and services in a cost effective manner. The CWS platform consists of the following six main services, which will be discussed in more detail in this paper - (1) Computational/Networking, (2) Storage/Content Delivery, (3) Databases, (4) Analytics, (5) Applications, and (6) Deployment and Management services. One or more of these services may be utilized to help develop, integrate, and deliver ATE cloud-based applications to the consumer. The goals of ATE are to (1) quickly and accurately detect and isolate each fault, (2) provide software tools for analyzing historical data, (3) gather, manage, and distribute accurate and reliable maintenance information for the failed Unit Under Test (UUT). The CWS cloud platform will aid in the development of cloud based tools and applications that are cost effective, flexible, scalable, and secure that can be used by multiple end users to aid in the development of ATE system software tool sets. One example of a cloud-based application is a diagnostic reasoner that could be used to aid in diagnosing UUT repair actions. This paper will show how developers can use CWS to develop ATE cloud-based applications and tools that will help improve the overall ATE testing throughput, thus resulting in bottom line improvements to ATE life cycle costs.

FPGA Controlled Interface Boards (FCIB) are widely used in electronic systems in order to meet the control, communication and I/O requirements. These boards employ FPGAs to control multiple signal input/output blocks, communication interfaces (RS232/422, CAN, ETH, PCIe etc.), ADC/DAC circuits, and other general purpose circuits. Production tests of FCIBs are vital since a single fault in the Unit Under Test (UUT) may cause serious consequences (engineering, rework, time, money costs) at higher levels of integration. Test requirements of UUT are specified as the first step of the test design process to define the test coverage. As the second step, test is designed at high level by specifying the building blocks of the test program set (TPS). In this step, hardware and software components are designed and implemented. Finally, TPS is verified after integrating all components. These three steps can be concluded briefly as Test Program Set requirements, design and implementation, verification. In addition to these test development steps, test design process should be carried based on the general automated test development considerations. These principles can be grouped in five subjects. Firstly, all the test steps in the testing procedure should be repeatable. Secondly, since these tests will be used in mass production, the test duration should be as short as possible while verifying all interfaces precisely and reliably. Thirdly, tests should require minimum amount of operator interaction. It should be fully automated-if possible- to reduce the test duration and errors due to operator interaction. Fourthly, test steps should not only catch the errors but also localize them to a circuit block on the board. This helps to repair the faulty parts quickly in production. Finally, all tests should be done with minimum amount of test equipment. After defining the UUT specifications and TPS requirements, there are two methods that could be applied in the test design process of the FCIB. The first one is to control all interfaces with embedded test code running on FPGA of UUT and using interface specific test devices to verify the circuit block. In order to test the interfaces of the FCIB, the test devices should be able to manage the signals in two directions, from FCIB and to FCIB. The test flow is controlled from external world through a UUT interface-generally UART. To make the test faster and minimize the operator interaction, a high-level test software is designed in LabVIEW or a similar environment to automatize the test procedure. The second method is using another verified FCIB, namely a Golden Board, which helps to communicate through all interfaces of the UUT and verify it functionally. In this method, test designer should define the hardware interface between the boards, and construct a test procedure accordingly. Next, embedded code for the FPGAs on the Golden Board and UUT should be developed in order to simulate the functionality of the UUT. The synchronization and handshaking of two FPGA codes also becomes important to manage test flow. A high-level test software may also be developed in LabVIEW or a similar environment depending on the test design. Both of two methods have their own advantages and disadvantages. In this paper, the two methods of designing an automated test for FPGA Controlled Interface Boards will be discussed. They will be compared according to their workload of development, capability of locating errors, test duration and efficiency of the testing (coverage, probability of error occurrence).

As a focus for the current research in the informatization field, Interactive Electronic Technical Manuals (IETMs) involve all kinds of activities relating to equipment support and diversified extensible interactive interfaces. By studying the interaction of IETMs for aviation equipments with other information systems, IETMs functions can be expanded in terms of maintenance aiding, training aiding and technical data management aiding. By creating an integrated data environment framework of IETMs for aviation equipments with Extensible Markup Language (XML) technology, an intermediate mode, the information exchange and sharing can be achieved between different data sources, and the supportability and supporting capability of aviation equipments can be improved.

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.

An interactive electronic technical manual (IETM) is a digital package of information that is required for the diagnosis and maintenance of complex weapon systems and both military and commercial equipment. The lack of interoperability within and among IETM systems has become a major challenge to the US DoD IETM community. The initial phase of user-level interoperability support has been undertaken by the development of a Web-based Joint IETM Architecture (JIA). Within this architecture, there is a need to develop a standardized Web-enabled alternative to the IETM database specification. Object-oriented modeling provides the conceptual foundation for assembling the Web-enabled alternative out of Web components using Web technologies such as Java and XML. In this paper, we discuss a UML-based object model to manage the large and complex IETM database specification. We also define a UML extension to capture the semantics of the IETM database architecture.

The need to reduce time to market and test development costs of Printed Circuit Card Assemblies (PCAs)/Line Replaceable Modules (LRMs) Test Program Sets (TPSs), has been a major concern for both industry and government. The lack of tools is the contributing factor to lengthy development times and high initial TPS development costs and subsequent higher costs of rehosting existing TPSs. These tools are Unit Under Test (UUT) and test resource simulation software, portable test information, and virtual test development for UUT design and test engineers. The Virtual Test (VTest) Program addresses the non-availability of appropriate tools and methodologies to support the design of TPSs during initial development and subsequent life-cycle maintenance periods. VTest will provide methodologies and tools that permit the design, capture, and simulation of tester independent test requirements, UUT models, and tester resource description information. The information developed will be utilized by multiple varieties of military and commercial testers, and will provide design requirements for test adapters.

In complex systems, testing each interface of a system separately is not a coherent way of testing and it reduces test quality. Especially in design verification tests, increasing test quality can be achieved by testing system level reactions and responses of all interfaces together simultaneously considering the system as a whole. In this study, a test system created for design verification tests of four different units through Hardware-in-theloop (HIL) simulation is to be explained. Design verification tests covering whole interfaces of Unit Under Test (UUT) are demonstrated with also simulations of units to be connected to UUT. The overall test system is divided into two main parts as automatic test equipment (ATE) design and HIL simulation design. The design process of ATE includes test requirements, specifications and identifications of all interfaces which belong to interconnected units in the system. The hardware selections and connections between them are accomplished for four different UUTs in such a manner that they can be tested together or separately. In the design process of HIL simulation, each sub-system connected to UUTs and UUTs themselves are considered separately. The requirements for each sub-system and each UUT are met within the interface control documents. In order to increase the quality of test, communications and the control of the electrical interfaces between each sub-system are implemented in real time. The communication interfaces consist of RS422, RS485, MILSTD-1553, Telnet and CANopen. The reactions and responses of each UUT are collected and HIL simulation is improved. Finally, the discussions about the approach of design verification tests of four different UUTs within HIL simulation and the improvement of the test quality are revealed. Further in this study, the test approach used by DEICO for HIL is discussed in detail.