By combining a commercial off the shelf (COTS) test executive, PC-based measurement hardware and software, and a modular test-system architecture, systems integrator Bloomy Controls and Lifeline Systems created three functional test systems for printed circuit boards (PCBs) used in personal emergency response systems. Although each system tests a specific PCB with its own test requirements, the three systems have similar, simple operator interfaces that maximize operator efficiency and minimize training time.
The systems have increased test throughput by up to 75% over the original testers. Also, result reporting is easier thanks to a compact database that stores all test data.
Background
Lifeline Systems provides personal emergency response systems for the elderly and at-risk. When a Lifeline subscriber presses a personal help button, a telephone or communicator dials the Lifeline Response Center for assistance.
When Lifeline hired a new contract manufacturer to assemble the PCBs used in the help button, telephone, and communicator, the company decided to replace its existing functional test systems that were 10 years old and difficult to maintain. The test systems relied heavily on GPIB controller instrumentation, much of which no longer was supported. Also, duplicate test systems were needed for use at the contract manufacturer for production testing of the PCBs before shipment and at Lifeline for quality acceptance, service repairs, and refurbished product testing.
The platform, development language, and architecture were blank slates so this was a unique opportunity to make a fresh start. To begin, we wanted to select a measurement platform from available VXI, PXI, PCI, or benchtop systems.
The test systems also needed new software and a test-results database. Before choosing the software, we carefully scrutinized the test requirements. Only after the core requirements were understood could we select hardware and software platforms that would provide adequate versatility.
Help Button PCB Test System
Of the three PCBs to be tested, the help button was the simplest. The help button is an RF transmitter that transmits an encoded bit stream. A small Lithium battery and related electronics support this function. The help button test, performed on a TTI/Testron vacuum fixture under test-system control, verifies the data transmission speed, battery power, and basic warning messages.
The test requirements fell in three categories: bit-stream decoding, RF transmission power, and digital/analog control signals. Lifeline already had an ASIC that receives a bit stream, converts the transmitted message to packed hexidecimal, and provides status, data rates, and PHB number. Because the ASIC is coupled with a serial communications port, only a serial port driver was needed to read the value and extract information from the transmitted message.
Incorporating the ASIC into the new test system saved significant development time and hardware costs. The alternative would have been to use a high-speed digital I/O and trigger board to decode the data bits and calculate the transmission rate.
The new test system had to provide a battery power signal and digital I/O for the fixture and button-switch control. Because there exists a variety of data acquisition cards that can provide adequate analog and digital I/O to meet these requirements, we used a standard Intel-based PC for the test platform. The low cost and high performance of the PC made it a very attractive platform.
Only a means of measuring RF transmission power remained to be determined. To keep the system simple, we chose a Giga-tronics RF power meter that can be controlled from a PC-mounted GPIB card. An RF receiver is mounted underneath the fixture test plate in close proximity to the PCB site.
The final help button test system incorporates a standard desktop Pentium® 4 PC with a National Instruments (NI) PCI-GPIB card that controls the external RF power meter and an NI PCI-6025E multifunctional data acquisition card. The data acquisition card provides analog inputs, outputs, and digital I/O for measuring mixed-signal parameters, controlling signals for custom signal conditioning circuitry, and providing fixture control.
Before finalizing the decision that the PC was the best platform for our test systems, we considered the test requirements for the telephone and communicator PCBs. We wanted the three PCBs to share a common platform so that measurement hardware could be as interchangeable as possible. In addition, lessons learned on the first system easily could be transferred to future systems.
Telephone and Communicator PCB Test Systems
The most demanding test requirement was the telephone PCB. The communicator PCB simply is a subset of the telephone PCB. The telephone test requirements included EEPROM programming, audio quality testing, telephone-tone emulation, control IC logic, switch continuity, and RF receiver performance. An important question was: Could capable test and measurement hardware that fit within a PC be found? Furthermore, since most desktop PCs are limited to no more than five PCI slots, would a PCI backplane support the test needs?
Lifeline developed a custom interface board that mounted in the test fixture and included analog driver channels and 21 electromechanical switches. As a result, we could continue to use a PC because adequate slots would be available for the large number of analog inputs, outputs, and digital I/O.
The telephone and communicator PCBs contain a 24-line command bus that routes control signals to the various board-mounted ICs. The first challenge was to control the digital bus without interference from the other ICs.
Once the test points were mated to the measurement hardware, removal was not an option until the test was complete. To overcome this, a digital I/O measurement board was selected that supported tri-state buffering. Tri-state buffering provides a high-impedance output that prevents bus contentions, allowing the measurement hardware to stay in contact with the test points. Or so we thought.
Early in the development process, we discovered that certain command lines were feeding back through the tri-state buffer. The tri-state impedance was inadequate on certain control-logic lines. The result was an unstable bus, which was unacceptable.
Four lines were identified as the offending buffers. To solve this problem, four additional relays were mounted in line with the control-logic stimulus lines. Four readily available digital output lines controlled these four relays. These four lines then were completely removed from the bus during test operations. The other lines did work well with tri-state buffering.
Lifeline telephones and communicators have audio files in EEPROMS that can be played from the PCB speaker. These recordings provide feedback to a Lifeline subscriber who might be in need of help. Traditionally, EEPROMs are programmed using stand-alone EEPROM programming fixtures that can be interfaced easily to a PC. Our challenge was to emulate these EEPROM programmers using software-timed digital lines.
By developing a generic digital line driver in software, the EEPROMS can be programmed using the traditional digital outputs available on data acquisition cards. Three digital lines were dedicated to the EEPROM programming and switched to appropriate test points.
By constraining the measurement hardware requirements and supplanting a specialized hardware task to a custom interface board, the PCI form factor was a viable solution across the entire product range. The goal of providing an interchangeable test system from a personal help button to a telephone was achieved.
The final telephone and communicator test systems include NI data acquisition boards, cables, and connector blocks (Figure 1). The same hardware is used in both test systems with differences only in the channel assignments and the personality card.
The NI PCI-6025E and PCI-6035E multifunction data acquisition boards provide the necessary analog inputs, analog outputs, digital I/O, and counters/timers. The NI PCI-DI/O-32HS digital I/O board was chosen because it could be configured in combinations of inputs, outputs, and tri-state (high impedance) as required for particular tests. During these tests, the DUT clock is disabled, and the PCI-6035E provides the clock while the PCI-DI/O-32HS reads from or writes to the IC using software timing.
Functional Test Executive and Software
With a cost-effective, PCI-based platform including general-purpose data acquisition cards, GPIB cards, and digital tri-state I/O cards, only software remained to be selected. The software platform or test executive often is the most daunting choice in functional test systems. Again, we had the unique opportunity to develop a common test platform that could be leveraged across Lifeline’s entire product line.
Developing the software for a functional test system requires forethought. A few simple, fundamental questions must be answered:
- What operating system is appropriate?
- How are products tested, such as one at a time or two at a time?
- What does an operator need to see?
- How will test results be reported?
Answering these questions is not a simple task, and often the answers change from project inception to final production. Hidden in these questions are some of the most common pitfalls that we have seen in functional test systems.
Because functional testing is so common, there was no need to develop a test executive from scratch. We used NI TestStand and LabVIEW to develop the test-executive and source code, respectively. These platforms provide most of the needed software features. All that remained was to customize the test-executive environment and develop individual test-code modules in LabVIEW. The systems were developed under Microsoft Windows 2000 due to its wide industry support and reliability.
We began by developing a simple, product-unspecific operator interface. The interface allows operators to log on, load test sequences (scripts), and start tests. By ensuring that the interface was not product-specific, operators could be trained on a single operator interface and undergo minimal training on the product-specific tests.
Functional test-system displays commonly have highly specific indicators on the operator interface. To ensure the operator interfaces would look exactly alike, we designed individual tests to pop up in the sequence. These smaller windows display specific information about the PCB under test.
When the test is complete, the window closes, and the generic operator interface is viewable again. Figure 2 shows an example of a product-specific popup over the generic operator interface.
Written in LabVIEW, the tests are designed to be stand-alone test modules. By adhering to this practice of dividing test requirements to their lowest possible level, individual tests can be tested and verified prior to integration. The savings in debug time can be enormous. By keeping tests as modular blocks, test sequences can be modified easily without breaking the test sequence.
A common mistake is coupling test requirements in an attempt to simplify the test sequence or decrease test time. The time saved by combining tests into common modules often is not significant. Modern computers and test executives do not have appreciable latency between steps. Besides, module test-code design promotes re-use of code.
Adhering to a modular test design was critical during test development. The PCBs underwent numerous but minor engineering changes, sometimes as simple as altering the limit for a test.
If fundamental changes were made to the test, the source code had to be modified. By keeping the test to one-specification-per-step, the impact was minimized. The amount of verified code that was impacted was kept to a minimum. Also, the test-sequence order could be changed on the fly to find the most effective method of testing.
Database
Once the test systems were on the production floors, the test results needed to be stored in a logical and compact manner. The recorded test results are crucial to improving test process and product quality.
Just as the operator interface was generic and usable for all products, we wanted a database that also would be generic. By coming up with a single, multiproduct database, Lifeline would not need to redesign its database structures. In addition, the database could handle future products or tests.
We developed a Microsoft Access database where all the test data is saved, enabling Lifeline to develop detailed production yield reports, troubleshooting guides, lot control, and production reports—capabilities the previous test systems did not provide. The database also records all test information to include parameters, limits, test times, and pass/fail status in a polymorphic, multilevel database.
The design is based on the standard database field provided with TestStand. Only minimal effort is required to add customizations unique to Lifeline’s PCB test record keeping, including PCB assembly date and PCB manufacture date. This database format can be applied to any PCB developed by Lifeline, regardless of the product.
Results
Duplicate systems were replicated and sent to Lifeline and the contract manufacturer. Although installed 3,000 miles apart, the functional test systems can be correlated and qualified.
The new test systems also have improved Lifeline’s test throughput. Testing time for the telephone PCBs decreased from 4 minutes to 2 minutes, 37 seconds per unit for a 35% throughput increase. The help button PCB test time dropped from 11 seconds to less than 4 seconds per board, a 75% increase in throughput. Communicator PCB testing time decreased from 3 minutes to 2 minutes, 12 seconds per board, a 27% throughput increase.
Tips
- Use a COTS test executive to architect your software backbone. There is no need to reinvent a test executive with the well-designed test executives available today.
- Use a fast, meant-for-measurement language for rapid test-system development.
- Leverage PC-based technologies such as PCI, CompactPCI, and PXI. These platforms provide the best performance for cost.
- Before retrofitting an entire test system, carefully plan, categorize, and modularize the components. Adhering to proper programming techniques and modularization will make code easier to update and less expensive to maintain.
- Be prepared to develop custom interfacing hardware. Carefully consider the cost of maintaining custom hardware over COTS hardware.
- Consider novel ways to use general-purpose test and measurement hardware. EEPROM programming doesn’t require special hardware and can be done with general-purpose analog and digital outputs. By leveraging CPU power, algorithms traditionally handled by specialized instruments can be moved to software.
About the Author
Matthew Kennedy is the engineering manager at Bloomy Controls in Milford, MA. Previously, he served as a senior nuclear engineer in the U.S. Navy submarine fleet and worked as an electrical engineer for companies in the Boston area. He holds a B.S. in electrical engineering from the University of California. email: [email protected]
Greg Burroughs is the senior project engineer at Bloomy Controls in Windsor, CT. He received a B.S. in electrical engineering from Rochester Institute of Technology. email: [email protected]
Bloomy Controls, 839 Marshall Phelps Rd., Windsor, CT 06095, 860-298-9925
Elaine Fasoli Bailey is the manager of quality assurance and process control at Lifeline Systems. In 23 years in the electronics industry, Ms. Bailey has held positions including supervisor of engineering services performing PCB layout and manager of operations engineering performing manufacturing engineering and quality control. Lifeline Systems, 111 Lawrence St., Framingham, MA 01702, 508-988-1940, email: [email protected]
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2003 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
July 2003