Test System Software

There are many software options available to a test system designer—and they are significant and complex. Some ATE companies have attempted to solve this problem by creating “closed” proprietary software solutions designed to limit your freedom of choice. Here at Four Hound Solutions, software is part of our 100% commitment to open architecture. When it comes to test software choices, we offer total freedom. You can choose any major software platform and any major test executive. Additionally, you can choose any major software language, any major database programs, any of the software tools developed for the test environment, and you can choose any software vendor. The choices are yours.

Software Options

Software Options

This total freedom of choice allows you to specify a test system that will satisfy your needs—as opposed to the need of the closed proprietary ATE vendor. Test and production staff work in familiar programs, languages, and software environments, thus greatly reducing learning curves. MIS departments are not forced to accommodate or interface with yet another operating platform, language, or database. When you work with Four Hound Solutions, you have complete software freedom.

Our software architecture, based on open industry standards, allows us to easily integrate the best of available COTS applications with our own software utilities to provide a comprehensive solution to meet our customer’s specific requirements.

FHS’s multi-layer approach to software, combined with our modular software development methodology create an open architecture environment that will not be obsolete as hardware and instrumentation changes in response to technology and product updates.

Four Hound Solutions has developed a new type cognitive automated test program development system using a modified set covering algorithm. The system provides a self-healing capability to any automated test system allowing manufacturing and diagnostic testing to continue even with the loss of critical test system assets.
Automated test programs and systems are typically written as a series of functional end-to-end tests with measurements made at the output pins or operator observations in order to assure that the product under test is operating correctly and ready for issue. They can be written in a variety of languages not limited to: C/C++, Basic, Pascal, FORTRAN, and ATLAS. The test system sequencing is handled in one of two ways. The first method is for the program to execute all functional end-to-end tests and then call a diagnostic routine if a failure is detected. The second method is for the program to execute the functional end-to-end tests until a failure is detected then call a diagnostic routine associated to the failing test. Essentially each test is followed by diagnostic tests to isolate the fault to the level required by the specification.

ATE Software Architecture

ATE Software Architecture

Normally, when automating a test process, the engineer would create a test step for every adjustment required to each instrument used in the test process just like someone manually setting up the instrumentation. This can become a redundant process if a unit under test requires multiple tests using a similar test procedure. The engineer is also required to monitor what instrumentation exists on the system and not in use at run time of the specific test being created. After a test process is created and deployed for use, it relies on the specific instruments that are called in the test process to be present on the system to run. Because of this, if a required instrument is out for calibration, being repaired, or removed from the system for any other reason, the system is inoperable for any test that requires the missing instrument.

Through the use of this software system the engineer can insert common tests into an automated test process instead of individual steps. The advantage of this method is engineering efficiency or reduction in development time. There are other derivative advantages: common test style among multiple engineers; since the test method already exits it allows for a developer with limited experience with a particular test to begin developing with minimal training, test system downtime is reduced and in some instances eliminated.

Parallel to the implementation of the ability to insert a test, this system is capable of dynamically loading which instrumentation will be used depending on what is available on the test station. This will allow for an instrument to be removed from the test station and an already deployed process that uses this instrument to still run as long as another method to accomplish each test within the system exists.

ATS software community is notorious for its traditional lack of software reuse and standardization. Applications are too often created from the ground-up when a new TPS is started without leveraging solutions that have already been developed. Software reuse is highly desirable not only because of its economic impact, but also for its important influence on the ultimate quality and reliability of the delivered software system.

FHS has developed an effective way of reusing software with our test executive framework. The test executive reuses not only code, but most importantly, architecture and design.
The software architecture presented has evolved over time and was developed by leveraging Dr. Carey’s many years of experience in creating diverse applications for the automated test domain.