Improving Manufacturing Test Stations

Many companies have embraced Lean initiatives to reduce waste and errors in manufacturing. Identifying the contributors requires data. Specifically, we’ll cover two areas as they relate to lean enablers for manufacturing test systems:

1. Reducing errors with electronic documents
2. How test data can reduce waste in a production environment

The end goal of all this is being able to make intelligent decisions that improve operations, a perfect goal for Lean initiatives.

Let’s talk about ways that enhanced test systems can reduce errors in a production environment.

For products that need to be tested during assembly by manual or semi-automated operations, moving data between electronic documents and records brings improved consistency, faster production rates, lower assembly errors, and visibility into the production process.

Benefits

The first area we recommend is putting the assembly and test instructions into electronic form. Instructions go by many names at different companies. We hear terms like work instructions, assembly manual, and so on. The idea is to replace any printed material that the operator might use with content displayed on a computer screen.

When used in a test system, the written instructions are the basis of the test steps in an electronic test sequence.

I should note that using an electronic test sequence does not imply automation of the test steps. A test step can be completely manual. It could display some text and an image to describe the way to assembly a part or to take a measurement. No automated actions are done. Only the automation of the instructions.

Once you move to electronic test sequences, you can use document management. For example, you can use:

• Verification and Validation management so that only released manuals are presented and executed at the test station.
• Version control so that the latest version can be located and earlier versions can be accessed for older model parts.

Note that taking full advantage of document management means that business processes need to be in place.

The second area we recommend for electronic documents is to capture the results of the assembly and testing into electronic data so these results can be analyzed within, and even across, product lines.

Some aspects of a test sequence execution that can be revealed:

• Since a test sequence is driving the test step execution, the test system can be programmed to capture all results, such as reasons for skipping a test, observations during assembly, the time a step takes to complete, and others.
• If measurements are manually typed into the step results, the data can be sanity checked. If automatically measured from the equipment, manual typos are eliminated.
• These data should be made searchable (database, XML, etc.) to allow production managers visibility into the status of tested parts. You can then create reports for frequency of various failure modes, duration of steps as a function of operator, a graph of the quantity of parts tested versus time of day, and so on.

Both the document management and data capture often require IT activities, so get them involved early. We also noticed that some of our clients have IT create production dashboards with these results.

Questions to Ask

Here are some questions to ask before deciding to implement electronic documents:

• How many instruction documents do you have and how often do they change?
  • If you only have one test system with one instruction manual that never changes, the effort to modify the test application software to work with electronic documentation can be as simple as scanning the pages of the manual and presenting these on the tester screen.
  • Changing over to a full-fledged electronic test sequence method makes sense when you have more than around 3 combinations of test systems and products, such as one tester for 3 products or 3 testers for one product each.
• Are you in a regulated environment and you need to manage the assembly and test instructions to show an auditor that the right instructions were used on any given part and that the results from each part tested are traceable?
• Do you have support from whomever maintains the test systems?
  • We have seen situations where management did not want to spend the effort to automate reporting because they wanted control over the content of each and every report – manual report generation ensued.
• Do you have a Lean initiative?
  • The usefulness of the electronic assembly and test results is enhanced when you have a reason and means to analyze the results.

Recommendations

Here are some recommendations based on our experiences working with clients to add electronic documentation to a test system.

For operator test instructions, the biggest benefit we’ve seen happens on test systems that are used to test multiple different models of parts. Switching testing from one part to another can cause confusion.

So, we recommend the following things.

• Convert your instructions into an executable electronic test sequence.
• Have the test application choose the test sequence automatically based on part ID, rather than searching for the appropriate paper document.
• Use test limits files based on model and retrieve automatically with the test sequence.
• Enhance the test application to notice versions, so outdated versions are not used by mistake.
• Enhance the test application to recognize the release status of the instructions, so only qualified people are allowed appropriate access to the instructions.

These enhancements are among the most complex of the items mentioned. Not because of the technical nature, which is not huge, but because they impact other parts and people within your company. It can be challenging to convince others to make the enhancements.

For the electronic records, our recommendations are based on including the operational data with the test results. Besides collecting test results on product performance, include information useful to the production group such as:

• Test duration for each step.
• Comments about the results of the test steps.
• Date/time stamp of the tests.
• ID of the operator performing the tests.
• All the relevant raw data used to access the pass/fail disposition of each test step.

For example, the test duration data can be used to understand the test stand usage for Overall Equipment Effectiveness, or OEE, computations. OEE involves Availability (the time the tester is available), Performance (how fast it takes to test a part), and Quality (first pass yield). This OEE metric can help the production group improve on efficiency by identifying the poor performers.

Case Study

An actual project that Viewpoint delivered might be useful to discuss. The company makes aerospace actuators. They are a high-mix, low volume production facility. Some parts are made at less than 10 per week and there are 1000s of part models.

I’ll concentrate on some of the fundamentals since the scope of this project has grown to encompass worldwide production.

First, the assembly and test instructions have gradually been moved into electronic test sequences. Many sequences are still semi-automated, since automating every step would have been expensive. The combination of the programmable test sequencer and the electronic instruction documents was the first hurdle that allowed all the rest to happen. We know this because the client originally had the instructions in XLS and database files with no automated sequencing through the instructions. That effort was abandoned due to an ineffective outcome and replaced with the automated test sequencer.

Also, this customer wanted the test steps to be configurable during the running of a test, so that engineers could assist with troubleshooting parts that were behaving oddly. All the results of are saved, normal operation or not.

Second, the data produced by the test system, including both the test results and the operational information, are used to understand things like:

• First pass yield pareto
• Product touch time and test cycle time
• SPC charts and usual stats, such as Cpk
• WIP dashboard
• Per unit device history brings visibility on each part across multiple test systems, even for parts that are reworked.

The client has put a lot of effort into this electronic documentation effort. After some initial proof of concept efforts, a substantial development effort was undertaken with payback in less than 2 years.

How to get Started

Begin by understanding of the level of effort to convert the documents into test sequences. How many test sequences will there be and how many steps do you have to convert?

Then, assess how much test data will be produced for all these sequences. Data storage is cheap nowadays, but still needs to be considered.

Also, scope out the effort to create methods to store the electronic test sequences and don’t forget the benefits of putting these sequences under version control. Also, all those test results need to be stored somewhere, so you’ll be designing the layout of the network folders and possibly database structures to hold all these results. IT will need to get involved.

Once that work is done, you can enhance your test system application software to use the test sequences and save the results.

Then you’ll need to developed one or more applications to “slice and dice” the results so you can create reports for production management. You might also want to create a metrics dashboard.

The end goal of all this is being able to make intelligent decisions that improve operations, a perfect goal for Lean initiatives.