Abstract - This paper presents a method of creating and man-

aging advanced engineering organizational knowledge. For a semiconductor manufacturer to remain competitive in the mar-ketplace, it must have a highly effective semiconductor yield-management system (YMS). The construction and maintenance of such a YMS is a typical example of the creation and manage-ment of organizational engineering knowledge, and also an example of how to support it by information technology. This paper proposes a new concept—user-oriented engineering. User-oriented engineering is an approach based on the user-centric concept and end user programming, applying ontology and problem solving method, to optimize the end user’s knowl-edge and to share the knowledge. YMSs based on user-oriented engineering (UO-YMS) have been developed and have been in operation in several semiconductor factories for several years. The tacit knowledge of expert engineers has been transformed into explicit knowledge, then shared by the organization and transformed into systemic knowledge. The result has been a reduction in yield -management tool development time, shorter yield analysis time required studying loss, and a greatly im-proved yield.

I. INTRODUCTION To maintain competitiveness and profit margins, a semi-

conductor manufacturer has to reduce manufacturing costs. To achieve this goal, chip manufacturers are facing serious challenges in reducing the pattern width in accordance with the technology roadmap [1]. Furthermore, the life of chips is becoming shorter. In these circumstances, the management of semiconductor fabrication plants must quickly increase yields. To achieve this, they must introduce further advanced manu-facturing equipment, inspection equipment, and manufactur-ing systems. One of the key issues is how to attain a neces-sary yield level quickly. A yield-management system (YMS) is central to meeting these challenges.

A YMS is a typical example of organizational knowledge. Organizational knowledge must be created, cultivated, and propagated within the company. The roles of information systems are at least three-fold—(i) to propagate organizational knowledge within the organization, and to promote collabora-tion among the people concerned; (ii) to provide the necessary fundamental infrastructure (tools) for performing yield analy-sis; and (iii) to accelerate the turning of tacit knowledge into explicit knowledge (with explicit knowledge being realized as a piece of software which runs on the YMS and becomes a part of it).

This paper focuses on the third role noted above. Two ma-jor problems exist in this information system role. The first is how to turn organizational tacit knowledge into information systems; the second is how to utilize such systems effectively and efficiently. For the first problem, a number of method-ologies exist. A major decision is the question of whether YMSs are developed within the company or whether they are outsourced. Either approach has several serious problems, which will be described below.

II. CHALLENGES OF YMS To gain a better understanding of the challenges in this area,

interviews were conducted with engineers and managers in semiconductor manufacturers. Sixteen manufacturers were interviewed — 9 in Japan, 3 in the USA, 3 in Taiwan, and 1 in Europe. Table I shows the summary result of questionnaire [2].

TABLE I SUMMARY RESULT OF QUESTIONNAIRE ABOUT FUTURE YMS

Problems Evaluation Category

# of Important Questions Frequency %

(A) A commercial yield improvement tool 8 5 63%

(B) In-company development of a yield management tool 10 9 90%

(C) Modification and development of an advanced yield improvement tool 7 5 71%

(D) Yield algorithm development envi-ronment 5 4 80%

Total 30 23 77%

As a result of these investigations, the following issues be-came apparent. It can be seen that both commercial YMSs and in-house YMSs had severe concerns, with the in-house YMSs having more. These problems can be summarized as: (i) long turnaround times for any improvement of YMS; and (ii) inflexibility of changing and expanding the capabilities of YMS. An in-house YMS usually involves even greater costs and a longer lead-time because a software-development team needs to be organized. The advantage of in-house develop-ment of a YMS is the accumulation and utilization of in-house knowledge. However, because of these difficulties, this is not usually achieved, and the interviewees were quite negative regarding this approach.

A major reason for long turnaround times is that the speci-

Knowledge Creation at Semiconductor Factories by User-Oriented Yield Management System

Masayuki Inokuchi*, Mamoru Mekawa**

*JEOL System Technology, Co., Ltd. 3-1-2 Musashino, Akishima, Tokyo 196-8558 Japan **Graduate School of Information Systems of the University of Electro-Communications, 1-5-1 Chofugaoka,

Chofu, Tokyo 182-8585 Japan

0-7803-9139-X/05/$20.00 ©2005 IEEE. 720

fications of a YMS or its modification cannot be written eas-ily by expert engineers or software engineers. A much-advocated software development methodology, based on the conventional waterfall model, does not work in these circum-stances. Many interviewees felt that new algorithms must be developed to improve yield. However, they also felt that they were too busy to do this themselves. They additionally felt software engineers are not capable of writing the requirement specifications of a YMS.

III. PROBLEM SOLVING APPROACH

A. End-user Programming and Ontology Problems stated in previous section are frequently pointed

out in many areas, especially in high technology areas. One of the approaches to overcome this problem is a user-centric approach [3]. End-user programming is one form of user-centric approach. An end-user programming approach con-sists of two ingredients; environment and knowledge crea-tion/discovery. An end-user programming environment pro-vides end-users with a variety of functional components that stand for the concepts appearing in the domain and allows them to build their own problem solving models in terms of those components. A knowledge extraction/representation is a process of extracting problem solving models and describ-ing them, which is highly creative process by expert engineers normally.

The user-centric, end-user programming solves only half of the problem, that is, the development aspect of YMS. The other half is knowledge sharing. One solution is to build a knowledge management system [4]. Among many methods used for building knowledge management systems, ontology can be one of the bases for knowledge sharing. The objec-tives of ontology are to provide easy maintenance of the knowledge base and easy sharing of them among many users [5]. Ontologies provide a common vocabulary of a domain and define the meaning of terms and the relations between them. Ontologies are usually organized in taxonomies and contain modeling primitives such as classes, relations, func-tions, axioms or instances. Popular applications of ontologies include knowledge management, natural language generation, enterprise modeling, etc.

B. Problem Solving Method The knowledge can be static and dynamic. Ontologies are

concerned with static domain knowledge while Problem-Solving Methods (PSMs) are concerned with dynamic reason-ing knowledge. They are applied to represent knowledge in many fields [6].

PSMs and ontologies are complementary components to construct intelligent information systems and they must be tightly coupled to do this. PSMs are attempted in real-life applications. In doing so, three steps are taken; (1) find the right PSM, (2) check whether it is applicable in the situation at hand, and (3) modify it to fit the domain.

Well-known PSMs are propose-and-revise and heuristic classification. The propose-and-revise PSM, Protégé-Ⅱ, is used to solve an elevator configuration task. Some other

applications are also reported [7]. It is said that several indus-trial applications are built, but only a few have been reported in the literature [8].

C. Proposed Approach Yield management work is versatile and it is impossible to

automate it. The goal and the role of YMS are to rather assist expert engineers who try to decide root causes of yield degra-dation through their experiences and intuition. This assist should be done interactively. It is also important that the root causes should be detected rather than just finding a faulty component. Fabrication processes are analyzed for yield management. C. Weber explicitly states that the inability to transfer knowledge rapidly between manufacturers and users is limiting the profitability of semiconductor manufacturers and users although suppliers and users combined have prob-lem-solving knowledge [9]. Yield management in general is studied and treated in many fields. The management aspect is discussed in reliability engineering and quality control. Some companies specialize to provide yield optimization solutions for the semiconductor market. In this paper, we propose a user-oriented engineering (UOE) approach based on the fol-lowing notions: (1) User-centric. (2) End-user programming. (3) Domain ontologies. (4) Problem solving methods.

We decided to use the Protégé for an ontology edit tool [10].

However, since PSM is the execution unit and the behavior depended greatly on the domain knowledge, we judged that it was difficult to apply the conventional method to PSM of a semiconductor region. The development method architecture of the user-oriented YMS (UO-YMS) based on UOE that we propose is shown in Fig. 1.

Our method has realized the component of the lower level of PSM by interactive PSM (IPSM). This means that all systems are constructed by the foundation in IPSM. There-fore, an engineer can operate it interactively by the same GUI on four levels (the phase of developing IPSM, the phase of developing PSM, the phase of performing PSM, and phase of confirming a result).

In a PSM design, the range which an end user should take charge of and the range which a software-development group should take charge of need to be divided clearly. It is required to divide PSM by class, in order to enable such an assignment. Such a concept is already proposed [11]. In the past, the software vendor was carrying out development of lower level PSM. However, since it was not easy to express the technical knowledge that an expert has as a software document, accu-mulation of PSM did not progress.

By our method, since development can be preceded while an engineer actually confirms the effect of a program interac-tively, truly successful PSM components can be developed. Since software engineers can concentrate on development of primary components of lower level, IPSM development is also efficient. Until now, the system engineer had spent greatly much time, in order to master technical knowledge

0-7803-9139-X/05/$20.00 ©2005 IEEE. 721

(production knowledge, yield management knowledge, etc. of a semiconductor). Such a time-consuming situation was one cause to which PSM development does not progress.

IPSM Library

PSM Librarian（Entry, Search,

Update）

IPSM

PSM Librarian（Search）

IPSM or PSM

PSM

PSM (Problem-Solving Method)

Programming

DesignOntology

ProductionOntology

YieldManagement

Ontology

IPSM DevelopmentPSM Development

PSM Task Execution

Review

Create

Entry

IPSM (InteractiveProblem-Solving

Method)Programming

Method Ontology

Domain Ontology

Field Ontology(PSM Library)

PSM with Results

Retrieve &Execution

UpdatePSM with Results

Retrieve

Fig. 1 UO-YMS Development Method Architecture

The other main points are explained below.

1) Domain Ontology The domain ontologies consist of yield management on-

tologies, design ontologies, and production ontologies. They define the vocabulary and classes of the semiconductor yield management. Yield management ontologies describe the knowledge about yield management, i.e., the management method of a process or equipment, the technique of analyzing a yield factor, etc. Design ontologies are fundamentally ob-tained from design information, i.e., information about a product device and product specification. The knowledge that is needed for product quality control is also described. Pro-duction ontologies are the ontologies about production, the knowledge of production equipment process technique, test method and test category, etc. 2) Method Ontology

The method ontologies define the use of IPSM libraries, pa-rameter definitions, and semantics of library components. They are used and referenced in connecting library compo-nents to develop a yield management tool (i.e., PSM). The method ontologies are used in mapping knowledge in domain ontologies onto PSMs. The method ontologies help users identify components, their parameters, the use of parameters, etc. The descriptions can be formal or informal.

3) PSM Librarian The PSM Librarian supports the operations that register,

search or update IPSM/PSM. A GUI is modeled on the com-mercial directory management tool so that it can be operated, even if an engineer does not learn the operating instructions to a library. Moreover, in order to manage a huge object safely and to do retrieval and updating operations quickly, the ob-ject-oriented database (OODB) was employed. 4) Field Ontology

Field ontology is the library of PSM. Programmed PSM and PSM with an execution result are stored. These are ex-tracted by PSM Librarian and reused. PSM changes an engi-neer's tacit knowledge into explicit knowledge. Field ontol-ogy classifies and systematizes PSM further for every cause of failure, every equipment/reason for generating, every analysis technique, and every department. PSM with the result of failure analysis is also accumulated as an analysis case (a technique and result) of the cause of failure. The accumulated analysis case is extracted from PSM Librarian, can be reviewed in detail and can be identified. When failure occurs, failure analysis can be carried by reproducing and performing the corresponding analysis case (PSM).

Moreover, it is also possible to construct PSM of an upper level using PSM currently confirmed. Systematic knowledge creation is carried out by unifying fragmentary analysis knowledge to greater analysis knowledge.

IV. KNOWLEDGE CREATION BY INTERACTIVE PROBLEM SOLVING METHODS (IPSM) AND PSM

A. Interactive Problem Solving Method (IPSM) and PSM Fig. 2 shows the architecture of application program devel-

opment based on our IPSM.

Fig. 2 Application Development by IPSM Those PSMs and IPSMs are hierarchically organized. The

highest level PSM or IPSM shown in Fig. 2 correspond to the top level tasks and they can be decomposed into a lower level IPSM {a’, b’, c’, d’} which are the customized modules of low-level IPSM {a, b, c, d}. They are further decomposed into or realized by primary components {t0, t1, s, h, f0}.

InteractiveProblem-SolvingMethod

Customized IPSMTask

Problem-Solving Method

PrimaryComponents:

Method:

Task: Top Level Task and Execution Results

t0 t1 s

a b c d

t1 t1h f0

a' b' c' d'

0-7803-9139-X/05/$20.00 ©2005 IEEE. 722

Those primary components are designed and provided by software vendors while IPSMs are interactively created by users and placed into libraries for sharing and reuse.

B. Programming Flow of IPSM or PSM The programming processes in our system are also shown

in Fig. 3. The steps are, (1) fetch or retrieve necessary input data from databases (data warehouse or data mart) and display them on spread sheets, (2) perform all the necessary data processing and computations on those data on the spread sheets, (3) display results (spread sheet data) as wafer-map and/or graphs. (4) enter results into databases for later reuse if necessary. A user can perform this programming process easily using four wizards; Select Wizard，Computation Wiz-ard，Registration Wizard，and Chart Wizard.

Programs created by the above processes can be grouped as a module. This module can be included in a particular IPSM/PSM. It can also be shared by IPSM/PSMs that are registered by PSM Librarian. An export/import mechanism supports this module sharing. An imported module is in-cluded as an executable code. One of the roles of the method ontology is to provide a common notation and rules for nam-ing, function description, input/output parameter definition, and so on. Following the module-based programming, users can do an entire yield management tool development using the same GUI. This includes IPSM development, PSM de-velopment, batch execution, and review. Fig. 3 IPSM/PSM Programming Flow

C. Knowledge Creation by Field Ontology A PSM is interactively created and holds the execution se-

quence, parameters, comments and decision criteria of the IPSMs. These definitions or documents are the outcome of an expert engineer and constitutes the yield management ontol-ogy. For instance, where to start when some fault is detected, which test should be performed in what sequence and what results should be expected, what representation or visualiza-tion is considered effective, what are the decision criteria, what action should be taken after decisions, what conclusions can be expected, and so on. As to visualization, details about wafer-maps, graphs, naming, and terminology can be speci-fied.

The results of applying PSMs are placed into ontology. If the applied PSM finds a root cause, this knowledge is a useful analysis case and can be reused. This information is placed into the field ontology. The field ontology is classified and maintained according to fault cause class, fault source, analy-sis method, and department according to the definitions of domain ontologies. As new cases are solved or tackled, the problem solving cases are accumulated as hierarchically or-ganized knowledge. Fig. 4 shows an examples of the field ontology displayed by PSM Librarian. Even without the help of knowledge engineer, a user can easily manage, expand, and store the ontology.

When a new problem arises, a user can extract similar analysis cases from the field ontology by PSM Librarian and reuse them. PSM Librarian supports visual search or keyword search for analysis cases. The predefined keywords are de-fined in domain ontology and free keywords are applied to the comment fields. The PSM Librarian can help provide user the information such as detailed knowledge structure, PSM func-tionalities, PSM details, and trustworthiness of the cases. The trustworthiness can be evaluated by the number of extractions or accesses of PSM.

By utilizing the modularization capability of IPSMs, yield management system can grow and become a comprehensive system. The field ontology helps knowledge sharing and propagation, and as a result, shortens tool development period and yield analysis period. Our approach does not presume the predefined and fixed ontologies. The ontologies are flexibly expanded, updated and extracted.

Fig. 4 Example of the Field Ontology

V. ACHIEVED RESULTS OF UO-YMS UO-YMSs have been in operation in several fabricating fa-

cilities since 1998. During this time, a large number of yield-management tools have been created, and significant im-provements have been achieved.

Table II shows subsystem and steps of a fail-bit analysis tool. A fail-bit analysis tool that was written in a conven-tional program (C++) was rewritten by UO-YMS for the purpose of improvement in performance, features and soft-ware productivity. The software step is drastically reduced to about 1/525. Software development cost (man-days) is re-

Classes are defined according to domain ontology

Query keywords

PSM information is shown according to method ontology

(1)Data querywith select

wizard

(2)Computationwith comp.

wizard

Data Series Computation Result

QueryResult (3)

Charting withchart wizard

DataSeries

Graphs,Maps orTables

DataWarehouse

Defect, Bin,Process,

Measurement,etc

Data Mart

Wafersummary, Lotsummary, QC

data, etc.

SelectedData

SelectedData Data Series

(4)Registrationwith entry

wizard

EntryData

Tabulatedsheet

0-7803-9139-X/05/$20.00 ©2005 IEEE. 723

duced to about 1/35. Actually the average number of program steps by UO-YMS per tool (PSM) in some fabrication plants was 55.0 though typical conventional program steps are 1-10 thousands.

TABLE II UOE AND CONVENTIONAL PROGRAMMING METHOD

Subsystem Lan-guage #of Step Total

Step Ratio

of StepRatio of Man-day

Recognition Result Tool 201 Wafermap Analysis Tool 2 Correlation Result Tool 35 Cause Inference Tool 86 U

OE

Met

hod

Trend Analysis Tool

User Friendly Program

35

359 1.0 1.0

Database Access Process 76,585 Data Browser 31,725 Result Viewer 64,277 Cause Inference Tool 7,711 C

onv.

M

etho

d

Trend Analysis Tool

C++

8,057

188K 524.7 35.3

UO-YMSs have supported the development of yield-

analysis tools by expert engineers themselves and have sup-ported their decision-making. The functionality developed according to UO-YMS architecture reduces the time required for yield-management tool development, reduces equipment connection time, and has positive influences on the companies concerned. Table III shows some early evaluations by the users.

TABLE III UOE EVALUATIONS

Company A Company B Company C Question w/o

UOE with UOE

w/o UOE

with UOE

w/o UOE

with UOE

Improve-ment Ratio

by UOE A-2 2 2 2 2 3 3 0% A-3 3 2 1 1 3 2 67% A-4 3 3 1 1 2 1 33% A-5 3 2 2 1 2 1 100% A-6 3 2 2 2 3 2 67% A-7 3 1 2 2 1 1 67% A-8 2 1 2 1 1 1 67% A-9 2 2 3 3 3 2 33%

# of Score=3 5 1 1 1 4 1 % of Score=3 63% 13% 13% 13% 50% 13%

The table shows a high level of satisfaction with the intro-

duction of UO-YMS and a reduction in the number of prob-lem areas. Significant improvements were reflected in the answers to the following questions: Question A-3: Can yield be enhanced? Are the capabilities sufficient? Question A-5: Can addition and improvement of functions be done easily? Question A-6: Can modification of format or item of yield-analysis data be done easily? Question A-7: Can problems be clarified quickly and can maintenance be undertaken easily? Question A-8: Is the life-cycle of YMS long?

These questions represent the major problem areas of YMS, and improvement in these areas has been difficult in the past. UO-YMSs have improved performance in all these areas, and it has been shown for them to contribute to significant en-hancement in yield management.

VI. CONCLUSIONS Major problems of YMS were (i) long turnaround times for

any improvement of YMS; and (ii) inflexibility of changing and expanding the capabilities of YMS. UO-YMS was de-veloped based on the IPSM/PSM, the domain ontology, the method ontology and the field ontology. UO-YMSs have been operated several years, the tacit knowledge of experts has been transformed into explicit knowledge —which is then shared by the organization and transformed into systemic knowledge. The development time of a yield-management tool and yield analysis time of yield depression have been significantly reduced, and yields have been greatly improved as the result. It is expected UO-YMS will be able to cope with difficulties caused by a future technology node and in-creasingly complex manufacturing situations.

ACKNOWLEDGEMENT The authors express appreciation to the anonymous fabri-

cating facilities that allowed research to be conducted on their operations, and to JEOL System Technology Co. Ltd, which technically supported this research.

REFERENCES [1] “International Technology Roadmap for Semiconductor 2003 Edition”,

International Technology Roadmap for Semiconductor(ITRS), 2003. [2] Masayuki Inokuchi, “Yield Management Practice by User Designable

YMS”, IEEE/SEMI Advanced Semiconductor Manufacturing Confer-ence and Workshop 2005, 11-12 April, 2005.

[3] M. DeBellis, “User-centric software engineering”, IEEE Expert 10, pp.34-41, 1995.

[4] T. Ravichandran, Arun Rai, “Structural Analysis of the Impact of Knowledge Creation and Knowledge Embedding on Software Process Capability”, IEEE Trans. Eng. Manage., Vol. 50. NO.3, pp.270-279, Aug. 2003.

[5] R. Mizoguchi, “Tutorial on ontological engineering - Part 3: Advanced course of ontological engineering,” New Generation Computing, OhmSha&Springer, Vol.22, No.2, 2004

[6] T. R. Gruber, “Towards principles for the design of ontologies used for knowledge sharing”, International Journal of Human-Computer Studies, 43:pp.907-928, 1995.

[7] V. R. Benjamins (1993), “Problem Solving Methods for Diagnosis”, University of Amsterdam. ALSO V. R. Benjamins (1995), “Problem-Solving Methods for Diagnosis and their Role in Knowledge Acquisi-tion”, International Journal of Expert Systems, Research & Applica-tions 8(2), pp. 93-120.

[8] Riichiro Mizoguchi, Yoshinobu Kitamura, "A Success Story of Onto-logical engineering-sharing and reuse of production engineering knowl-edge using functional ontology," The Japanese Society for Artificial In-telligence, Knowledge Base System Study Group(No. 57), 2002.

[9] C. Weber, “Knowledge transfer and the limits to profitability: an em-pirical study of problem-solving practices in semiconductor manufactur-ing and process development”, IEEE Transactions on Semiconductor Manufacturing, Nov 2002, Volume: 15, No. 4, pp.420- 426

[10] M. A. Musen, S. W. Tu, H. Eriksson, J. Gennari, A. R. Puerta, “Pro-tégé-II: An Environment for Reusable Problem-Solving Methods and Domain Ontologies”, Proceedings of the International Joint Conference on Artificial Intelligence (IJCAI'93), Chambery, France.

[11] John H. Gennari, Adam R. Stein, Mark A. Musen, “Reuse For Knowl-edge-Based Systems and CORBA Components,” Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-Based Systems Work-shop (KAW'96), Banff, Canada.

0-7803-9139-X/05/$20.00 ©2005 IEEE. 724