by Dr. Dirk Ortloff
Dirk Ortloff, Jens Popp, Andreas
1Process Relations GmbH
Corresponding author: email@example.com
Usage of Virtual Pre-Assessments
Insufficient Internal Information
Documentation and Compliance
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
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
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 publications2-4.
One tool of that category fulfilling many of these needs is XperiDesk® the
commercialization of the PROMENADE results.
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
published1 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
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.
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.
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.
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
- 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
- Provide powerful and detailed retrieval of historic information from diverse
- Contain mechanisms to collect, categorize and management result information
- Cover the documentation requirements for quality assurance and compliance
- Provide extensive reporting and planning capabilities
- Allow central administration and distribution and execution on several different
Development cycle to be supported by a PDES
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.
Development cycle with XperiDesk screenshots
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
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.
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