Enhancing an existing test system for ease of maintenance

Client – A world-wide manufacturer of refrigeration units

Challenge

Our client had been using a 15-year old test system LabVIEW-based application that was becoming difficult to update. Plus, the designs of their newest refrigeration units were more complex than ever, requiring new test steps.

On top of that, our client wanted to give the operator flexibility in sequencing the test steps. For example:

1. the operator might want to run a specific test twice to verify operation.,
2. The operator might want to restart a sequence in the middle after reworking a part.
3. Or the test engineer might want to add another test step to further clarify operational data for historical trend analysis.

The existing application was based on a state machine architecture. While state machines can be edited to handle different sequence flows, this test application had numerous alterations over the past 15+ years to support the needs for testing new product designs. These amendments compounded over the years into an unwieldy test application.

New products were about to be introduced which would require additional modifications to the existing state machine and subsequent verification that:

1. changes worked as planned and,
2. changes didn’t affect any other existing modes of operation. This need was increasingly daunting.

The Design and Development Process

Very early in discussions, we showed our client a test application based on an object-oriented (OO) software architecture, and its associated user interface, that we had used in previous test system projects for other clients. We thought it might satisfy some of the desires we were hearing about:

• how the older state-machine-based test system was difficult to maintain,
• how some users were frustrated by the inflexibility of the test sequencer,
• and wondering why the system can’t be easier to update for new product requirements.

Moving the existing application over to this new architecture would clearly require more effort than another patch, so we had to decide if the cost for this approach would be justified based on two major benefits:

• Simplify the management and verification of future changes.
• Enable flexible test flows to give the test operator a better user experience.

Both benefits would accumulate cost savings for maintenance and upgrades going forward. After discussions with our client, we jointly decided this approach was justified.

After reviewing this OO approach, our client asked us to use it to develop a small test system for another component of the refrigerator products. This small system gave our client the chance to explore the “look and feel” of this new architecture and user interface design before embarking on the test system discussed in this case study.

That trial project was a success, and we were given the go-ahead. The benefits, as described above, were clear.

After the development was complete, we:

• worked with our client on integrating the test system into the existing test station,
• performed acceptance testing,
• and delivered the final items, like source code, to our client.

Solution

The initial upgrade tasks in creating this new application started by identifying the code for the test steps in the existing test application, which was based on that state-machine architecture, and then rewriting the test step functionality with the OO methodologies discussed earlier.

We also reworked the sequencing of steps to use an OO-based test sequencer. The test sequencer was reused from some of our prior projects.

For each test step in the existing test application, we repurposed the existing LabVIEW code in two ways:

1. First, we identified code functionalities that were commonly used throughout the state machine for the purpose of defining a set of reusable step types.
2. Second, we converted that common functionality into LabVIEW classes via copy-paste into the class methods, coupled with extraction of the configuration parameters needed to give each class the behavior needed for a particular step.

For example, the existing state machine contained many steps that provided a request-response method over a data bus. These similar steps were corralled into a single class with methods for data communication. Thus, each of the multiple original states in the existing application which requested parameter values could be made by calls to the same class in the new application simply by providing specific configuration inputs to the same class method.

Benefits

This OO design simplified updates to the test steps and their sequencing.

Furthermore, the operator interface was simpler, cleaner, and allowed the operator to manage the flow of the test steps. For example, operators could jump around in the test sequence when needed, say for reviewing the occasional confusing result or helping to develop the production test sequence.

The OO design of this new test system application was aimed squarely at improving the user experiences of both the operator and test engineer. Secondarily, the OO design will help the test system developer by untangling the original state machine code into supportable, extensible, and maintainable software.

Some specific benefits available from this new OO design:

• Reduced frustration – If the operator noted something confusing about the outcome of a test step, that step can be rerun without needing to restart the entire test sequence.
• Improved operational efficiency – The operator and/or test engineer can try a different sequence of test steps for operational or efficiency improvement.
• Faster test system updates – Two aspects make updates faster and cleaner. First, new product designs can be accommodated with less worry about whether the fragile state machine code will break, Second, the code modularity of OO test steps makes it easier to implement new tests.

These usability and maintainability features will save our client cost and schedule in future product upgrades as well as highlight the contributions of the test system on production efficiency.

System Overview

The test hardware was based on NI CompactDAQ and the application was written in LabVIEW. The automated test system provided the following main features:

• Test configuration based on the type of part being tested
• Test sequencing with part-specific test steps
• Test sequence execution can be managed by the operator in real-time
• Display of test results as the sequence progresses
• Archiving of test data for historical tracking

The test flow that this application runs is:

1. The operator enters the model and serial numbers (typed in or scanned in).
2. The test system looks up the model number and finds the test sequence to run.
3. The test system populates the sequencer screen with the appropriate test sequence.
4. The operator can select a step from which to start or just click the Start Test button to begin the entire sequence.
5. Buttons at the bottom of the sequence display allow the user to Pause, Abort, or Resume the sequence.
6. Executed test steps are highlighted in green (pass) or red (fail) to indicate how the sequence is progressing. The operator can scroll through the test sequence to review the outcome of each step.
7. If the sequence is configured to do so, the sequence may pause at a failed step so the operator can repair and retest that step.

The unit under test (UUT) was monitored by the test system to view sensors both internal and external to the UUT. The external sensors are used to detect the environment of the unit, such as being in position, connected to power, and so on.

Besides a few thermocouples and digital inputs, measurement data used to determine pass/fail was obtained from the UUT via the data bus.

All these inputs were handled by a set of NI modules in a 4-Slot cDAQ chassis.