Tackling the non-technical challenges in the design of manufacturing processes

The diversity of technology options and their constraints, combined with shrinking geometries and other external and internal forces push engineers and technologies to their limits.

However, it is often practical and operational concerns, rather than the technical constraints, that provide the biggest barrier to the effective development of new high tech processes.

To cope with these challenges a new approach to process design automation is required. Crucially this new approach needs to provide an improved means for the digital transfer of process data and knowledge amongst whole development teams — streamlining and automating many of the tasks performed manually today.

Current development practice

Every new product or product enhancement starts with an idea. This might be based on experience from previous projects, discussions with colleagues, scientific papers, even from old lab books.

However, this is where problems first arise: colleagues may not be available, or may leave the company; lab books are often only of genuine use to those who originally wrote them; even if ideas or data have been stored on a computer the appropriate files can be dispersed across several servers or hidden deep within sub-folders.

Already, even in this first stage of development, there are several barriers to new developments. Many ideas can be scrapped at this stage, simply because there is not the time to overcome these problems and to do the necessary research.

For the ideas that are taken forward the engineer then starts to design a new process flow. This will be done on paper or using simple word processing or spreadsheet programs.

Unfortunately this approach tends to result in only the 'good''recipes and results being kept. Unsuccessful experiments and their resulting data are often discarded, not properly archived or forgotten.

As a result only one engineer, or a small group of engineers, gains knowledge from the failed experiments, despite the fact that failure in one context can be success in another. In a later project these "failed" results may actually be the desired outcome. Discarding these failures leads to repetition of failures. This repetition wastes time, resources and money.

For the "good" recipes the next step is to verify the assembled process flow. Many constraints must be met, and many restraints overcome, to successfully design a working process flow: are all the necessary cleaning steps there? Is the temperature budget met? Will this sequence of steps contaminate the machines?

Due to time restrictions inflicted by shorter development cycles, these assessments are sometimes not thorough enough. Even if there is a thorough review process, nobody is perfect, and processing technology becomes increasingly complex every day. Simple mistakes, like having the wrong material in the wrong machine, can significantly hamper the project, the equipment or the company. Mistakes can result in delayed results and equipment failure, interrupting the production line.

Finally, the first run of the process flow is executed and results are evaluated. In most cases, the first run is a partial success or a failure. Nevertheless, valuable experience is gained and significant data is generated during the evaluation.

This data is stored on a server and often only looked at by the individuals directly involved as they know where to find it and which experiment it refers to. To make matters worse, discussion about this data takes place via e-mail. Consequently informal knowledge about the experiment is only stored on the mail server. Accessing this knowledge after time can be labourious.

After the experiment is complete, the results and conclusions drawn are used to adjust the process flow or the device design, and a new iteration of the recipe and design begins. However, the parameter space has become too large for humans. Several unnecessary experiments are done on a zig-zag path to final process release or to the dismissal of an idea.

Tackling the non-technical challenges

To circumvent or limit the impacts of these challenges software tools are needed. Having a central platform being able to support experiment planning, verification and result data collection could streamline all of these efforts. Additionally such a platform could collect reference data for future project planning by keeping the timeline of the progression.

Such a software tool needs to fulfill three key high-level requirements: virtual pre-assessments; structured internal information management; and full documentation and compliance support.

Usage of virtual pre-assessments

Although some virtual prototyping and pre-assessments are already performed it can be limited by the bandwidth of the simulation experts or the availability of the required simulation resources.

These experts and resources end up becoming bottlenecks for effective simulation and results in many 'idea checks' being performed as real, live experiments, increasing the time and cost of development. Often good ideas are abandoned simply because there is not enough time to perform the necessary research and exploration.

However, properly implemented pre-assessment can deliver significant benefits, primarily by reducing the need to perform real experiments before a process has been thoroughly tested. By thoroughly testing a flow virtually it reduces the chances that the real test will fail, or in the worst cases, damage the equipment.

Internal information management

As already discussed experiences gained by previous developments, scientific papers, and old lab books are the main sources for new product ideas. However, having no or insufficient management structures for this data is problematic and can lead to engineering dj'-vu.

Experts in semiconductor process development estimate that 10-15 perdent of failed and double experiments could be avoided, if previous results were easily accessible.

Allied to this is the need for a streamlined means of data storage, traditional means of data storage provide only one dimensional search criterion. Cluttered result data storage, or storing important data on local disk drives, causes tedious and error prone manual data collection and, sometimes, data loss.

Often only the pure data points or result data sets are stored with limited or no contextual information. Without proper context reproducing previously seen effects is difficult and can result in drawing the wrong conclusions from cause-effect analysis.

Documentation and compliance support Documenting and reporting the development progress can be tiresome at best. Additionally the assembly of the collected result data into reports, and the evaluation, can significantly eat in to engineering time. Reporting on development status is more often than not a manual, rather than an automated, process.

On top of these issues, quality assurance and compliance demands, such as ISO 900X, CMMI, SOX etc., have been brought into development as well as production.

Therefore, there is a strong demand on process developers to fulfill the documentation requirements. However, by utilising a properly managed and automated database of results and progress, a lot of this administration can be recovered as engineering time.

Delivering the solution

A Process Development Execution System (PDES) can provide a solution that caters for the requirements outlined above. PDESs are tailored for steering the development of a manufacturing process (as opposed to Manufacturing Execution Systems (MES) tailored for executing volume production using the developed process).

The focus of a PDES is on low volumes, but high flexibility and experimentation freedom, whereas, the tools of a MES are focused on less variance, higher volumes, tighter control, and logistics. What both systems have in common is that they increase traceability, productivity, and quality.

A PDES enables easy access to previous developments in a structured manner. Information can be retrieved faster and previous results can be taken into account more efficiently.

A PDES typically offers means to display and search result data from different viewpoints and to categorise the data according to specific requirements. These functions are applied to all result data — for materials, process steps, machines, experiments, documents and images.

Process Relations own PDES — the XperiDesk software suite — provides a platform for process engineers to work together and share their results globally delivering significant productivity gains and improved process quality. T

he XperiDesk software suite addresses the requirement set out above and covers the complete development cycle for high tech manufacturing processes.

About the author

Dirk Ortloff is co-founder and Chief Technology Officer at Process Relations GmbH.