Recurring Deficiencies in Process Development Support

by Dr. Dirk Ortloff

Topics Covered

Abstract
Introduction
Deficiencies
     Market Pressures
     Usage of Virtual Pre-Assessments
     Insufficient Internal Information Management
     Documentation and Compliance Support
Requirements
Solutions
Conclusions
References

Abstract

Today a variety of uncertainties and hurdles challenge new product developments or product enhancements. This is especially true when developing microelectromechanical systems (MEMS), nanoelectromechanical systems (NEMS) or nano scale thin film devices and their specifically required manufacturing processes. The diversity of technology options and their constraints as well as the shrinking geometries and other external and internal forces overwhelm the engineers and put technologies to their limit. This paper systematically investigates the different areas of external and internal factors and their influences on MEMS and NEMS process developments.

To cope with the challenges of growing complexity in MEMS/NEMS fabrication process development a new approach for adequate process design automation are necessary. The approach needs to cover the design of new process sequences from the very first idea to the final handover to mass production. It must also provide means for the electronic transfer of process data and knowledge to technology partners.

Further down this paper collects the requirements for functionalities for software suits to support this approach. It highlights, that the demands of growing future markets can only be fulfilled through intensive usage of such software tools working hand in hand with product engineering methodologies. Tools of this kind fall into the category of Process Development Execution Systems (PDES) streamlining and automating many of the tasks performed manually today. These subjects were addressed in the EU research project PROMENADE (IST 507965) and its publications^2-4. One tool of that category fulfilling many of these needs is XperiDesk® the commercialization of the PROMENADE results.

Introduction

Development projects for new manufacturing recipes of MEMS and NEMS devices are challenged by a variety of different external and internal requirements. In the next section deficiencies resulting from common development practices are highlighted. To motivate those, let us have a look at the current development practices. This outline of a process development project has previously been published¹ in a similar manner.

Every new product or product enhancement starts with a new idea. In the area of process and device design for MEMS and NEMS, personal experiences gained through previous developments provide a major contribution to new developments.

Other sources for information and inspiration include colleagues, scientific papers and old lab books. However, this is where problems arise. Colleagues are not always available and it is not always clear if a certain experiment has already been conducted. Lab books are a great resource for historical data, but in most cases, they are only useful to the people who wrote them, as they know where to look and how to read them. Even if computer files are available, they are often distributed on several file servers or are hidden in some place and they are only sorted by a one dimensional criterion. Searching from another perspective is almost impossible.

Furthermore, every engineer has his/her own way of storing information, which means that various office and freeware software is used to create documentation. Already in this first phase of device and process development many good ideas are scrapped simply because there is not enough time to do the necessary research and explore the solution space sufficiently.

Once these initial hurdles are overcome, the engineer then starts to design a new process flow aimed at producing the device in mind. This is either done on paper or using office tools such as a word processing or spreadsheet programs. File and data formats usually vary from engineer to engineer. A critical problem with this approach is that in most cases only the "good" recipes and results are kept. Unsuccessful experiments and their resulting data are often discarded, not properly archived and often times forgotten.

For example, a colleague might change the configuration of a machine (without documenting it), or a machine used in previous experiments might not be available anymore, making it difficult to use and reproduce the results of previous experiments. As a result of this practice, only one engineer or a small group of engineers gains knowledge from the failed experiments. This leads to a repetition of failures, which is costly in terms of time, resources and money. So not archiving the complete context of an experiment limits the reproducibility and wastes valuable resources.

The next step in the design of a new production process is to verify the assembled process flow. Are all the necessary cleaning steps there? Is the temperature budget met? Will this sequence of steps contaminate the machines? However, these questions only apply to the manufacturability aspect of the process flow, not the functional aspect. It becomes clear that many constraints must be met and many restraints must be overcome to design a "good" process flow.

Due to time restrictions inflicted by shorter development cycles, these assessments are sometimes not thorough enough. At the most, other experienced engineers evaluate the process flow and assess it from their point of view using their own experiences. The problem with this approach is that experienced engineers are not always readily available within a company. Even if there is a thorough review process, nobody is perfect, and processing technology becomes increasingly complex every day.

Simple mistakes, such as having the wrong material in the wrong machine, can have a great impact on the project, on the equipment used and on the company. These mistakes result in delayed results and damaged machines, which interrupts 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 no success at all. Nevertheless, valuable experience is gained. However, various data and pictures (using scanning electron microscopes (SEMs), atomic force microscopes (AFMs), etc.) are generated during the evaluation. These files are stored on a file server and are often only looked at by the individuals directly involved because they know their location and what experiment they belong to. To make matters worse, discussion about this data takes place via e-mail. As a result of this practice, informal knowledge about the process is only stored on the mail server, and accessing this knowledge again after time has passed is difficult.

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.

Investigating the above outlined practice provides insights into issues during process development and highlights the potential for necessary improvements. The remainder of the paper looks in more detail into the above outlined as well as additional hurdles and challenges.

Deficiencies

As motivated in the introduction current process development tools and practices suffer from several challenges concerning proper support. These deficiencies can be grouped into four major areas:

  1. The market pressures and trends that must be tackled by companies with insufficient tools for experiments, collaboration and standardization.
  2. The limited usage of virtual pre-assessment possibilities (like manufacturability assessments) and simulations due to several different reasons.
  3. Insufficient internal information and knowledge management.
  4. Insufficient documentation and compliance support.

Market Pressures

Worldwide competition and the market demands result in faster and faster time-to-market requirements. This calls for more efficient development approaches. Several different routes can be taken to accomplish this goal.

One way to approach the time-to-market issue is to use virtual prototyping and virtual pre-assessments. Virtual prototyping can significantly speed up the development in offering first results faster. It also allows the verification of more potentially useful variants in the same time. Finding flaws in the developed recipes and possible alternatives earlier in the development process can cut time and expenses significantly. Unfortunately appropriate software for these tasks is often insufficient at best.

Another approach to speed up the development is reusing as much as possible from previous developments. For that centrally managed and reproducible recipes and development results are a prerequisite. Because of nonuniform documentation formats, scattered result data and insufficient retrieval means this precondition is often not fulfilled.

Collaboration between different people and groups inside the company is imperative for high tech developments. This can include collaboration between different groups around the globe. Market trends and development costs even drive the need for collaborative development activities between different legal entities. Collaboration can improve the time-to-market.

However a proper central development platform, including communication and electronic knowledge transfer functionalities, is needed to do so efficiently. This is especially true, if process knowledge needs to be transferred to a new site. Setting up the process at the receiving site often poses deviations from planned reference results. Often these deviations need to be researched again because no proper reference base is present. This leads to the insight that today's common practice of transferring technology via lengthy process blue books and engineer transfers will not meet the time and resource requirements of future developments.

Usage of Virtual Pre-Assessments

As motivated above, virtual prototyping and pre-assessments can speed up developments and cut costs. Sometimes the usage of virtual pre-assessment functionalities like structural simulations is limited by the bandwidth of the simulation experts or the availability of the required simulation and maintenance resources. This is often due to local software installations and maintenance requirements as well as due to the need for specially trained personal to develop e.g. simulation configurations. These skilled people become a bottleneck for effectively using simulation tools or other virtual assessment means. Therefore "Idea checks" are performed via real live experiments causing an increase in time and resources spent as well as a reduction in solution space explored. This causes engineers to abandon good ideas simply because there is not enough time to perform the necessary research and exploration.

Furthermore, nowadays recipes have become tremendously complex so that it is hard even for experienced process engineers to detect all potential contractions inside a process flow. Therefore the manual review of runcards and planned DoEs has become a tedious, time consuming and sometimes even error prone task. Wrongly placed decimal points in manually generated runcards, inconsistent updates of submodules in a flow, material inconsistencies or incompatibilities are increasingly difficult to spot and can cause whole batches to be not useful or, in extreme cases, might even damage or contaminate the manufacturing equipment.

Insufficient Internal Information Management

Another group of issues is the insufficient internal information and knowledge management resulting in recurring engineering "déjà vu's". Experiences gained by previous developments, scientific papers, and old lab-books provide the major contribution to the realization of new product ideas. Having no or only insufficient structure in these data causes a lot of trouble and double work. Experts in semiconductor process development estimate that 10-15% of failed and double experiments could be avoided, if previous results would be accessible in an easier way. This ties in with issues arising from engineer fluctuation between different projects. Moving the project expert into a different project might jeopardize the previous project while engineers moving into a running project are flooded with lots of unstructured information.

Additionally the traditional means of data storage provide only a one-dimensional search criterion. Cluttered result data storage and important data on local disk drives cause tedious and error prone manual data collection and sometimes even data loss. Furthermore often only the pure data points or result data sets are stored with limited or no context information. Having only limited context poses problems when trying to reproduce previously seen effects or result in drawing the wrong conclusions from cause-effect analysis. These circumstances produce "déjà vu's" in the form of "Once we had a result ..." that can be very annoying and cost intensive.

Documentation and Compliance Support

Documenting and reporting the development progress can be tedious at best. Cluttered results storage puts major manual effort onto the development engineers requiring them to manually collect data from diverse machinery. Additionally the assembly of the collected result data into reports and the evaluation can take a major part of engineering time. Reporting on the development status is often times more a manual assembly of the reports than an automated process. The input data is often not up to date so that the Work In Progress (WIP) status is not necessarily precise. The impacts of these effects are even aggravated by quality assurance and compliance demands such as ISO 900X, CMMI, SOX etc. Because those apply more and more in development as well as in production, there is a strong demand to fulfil the imposed documentation requirements.

Requirements

To circumvent or limit the impacts of the above described 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 the following high-level requirements:

• Support the complete development cycle as presented in Figure 1.
• Allow collaboration internally and externally but provide fine-grained protection and rights management
• Allow comprehensive and selective import and export mechanisms for technology transfers
• Provide virtual pre-assessment possibilities to prevent failed experiments as much as possible
• Offer mechanisms to pre-assess the manufacturability of a newly design recipe
• Allow all engineers to perform virtual assessments rather than limiting the usage to / via experts
• Offer full capture and access to historic information (structured as well as informal)
• Provide powerful and detailed retrieval of historic information from diverse perspectives
• Contain mechanisms to collect, categorize and management result information automatically
• Cover the documentation requirements for quality assurance and compliance needs
• Provide extensive reporting and planning capabilities
• Allow central administration and distribution and execution on several different platforms

Figure 1. Development cycle to be supported by a PDES

Solutions

The above listed requirements can be fulfilled by Process Development Execution Systems (PDES). A PDES is similar to a Manufacturing Execution System (MES) in several aspects. The central distinguishing factor is that PDESs are tailored for steering the development of a manufacturing process while MES are tailored for executing the volume production using the developed process. Therefore the focus and the toolset of a PDES is more on lower volume but higher flexibility and experimentation freedom. The tools of a MES are more focused on less variance, higher volumes, tighter control, and logistics. Both types of application software have in common that they increase traceability, productivity, and quality (for PDES the quality of the developed manufacturing process in contrast to the quality of the manufactured good for MES).

A PDES offers an easy way to access these 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 categorize the data according different aspects. These functionalities are applied to all result data like materials, process steps, machines, experiments, documents, pictures etc. The PDES also provides a way to relate entities belonging to the same or similar context and to explore the resulting information.

One software suite belonging into the PDES category is XperiDesk, a software product commercially available since April 2008. It supports process development engineers in their task to maintain and develop high tech manufacturing recipes e.g. for semiconductor device manufacturing. The usage results in a significant productivity boost of process engineers as well as an improved process quality.

XperiDesk provides a platform for process engineers to work together and share their results globally and enables the following three step verification approach:

• Formal verification of manufacturability using abstract process knowledge captured in rules
• Verification by simulation and visualization, and
• Tracking of experimental verification for detailed and comprehensive knowledge capture and retrieval.

The XperiDesk suite addresses most of the above listed requirements and covers the complete development cycle for high tech manufacturing processes as depicted in Figure 2.

Figure 2. Development cycle with XperiDesk screenshots

Conclusions

A review of common process development practices has been given and deficiencies resulting from those practices have been highlighted. The issues were grouped into different categories and potential solution approaches were outlined. From that the requirements for software support tools were derived. These requirements can be fulfilled by a new software category called Process Development Execution System (PDES).

A PDES supports the whole development flow - from the first device idea to the transfer of the resulting recipe into production or to a collaborating partner. Therefore, it closes the development loop and feeds today's real world results into the ideas of tomorrow. It can never replace the creativity of engineers, but it can help engineers to focus on good ideas and to get rid of bad ideas early on. Additionally, a PDES can remove documentation and data collection burdens by providing automated means for these purposes.

It also provides a playground for engineers to test their ideas in a virtual fabrication environment, providing ways to explore more ideas than previously possible. A PDES gives a company a competitive advantage by developing better solutions and providing shorter time-to-market. The concepts for PDES have been researched in the EU Research project PROMENADE (IST 507965) and have become commercially available as the XperiDesk software suite.

References

1. J. Popp, D. Ortloff, A. Wagener. Development Support for Manufacturing Process Design. In GSA Forum, Volume 15, No 1, March 2008.
2. A. Wagener, J. Popp K. Hahn, R. Brück; Ortloff, D.: Process Design and Tracking Support for MEMS. In: Proceedings of SPIE: Micromachining and Microfabrication Process Technology X, San Jose Bd. 6109, 2006. - Photonics West 2006
3. D. Ortloff, F. Cooijmans.; B. Veenstra: A Systematic Approach Towards Reproducibility and Tracking of MEMS Process Development. In: Proceedings of the 10th International Conference on the Commercialization of Micro and Nano Systems, Baden-Baden, 2005. - COMS 2005
4. B. Veenstra, D. Ortloff, S. Langenhuisen: An approach to exchange and generate knowledge of MEMS Process Development. In: Proceedings of the 11th International Conference on the Commercialization of Micro and Nano Systems, St. Petersburg, 2006. - COMS 2006

Copyright AZoNano.com, MANCEF.org