Virtualized generic equipment model data and control router for factory automation

Abstract

An interface between an automation host and a plurality of tools is used to perform a processing step. The interface includes a single communications and process behavioral connection interface to the automation host. The interface also includes a plurality of virtual host interfaces. Each virtual host interface from the plurality of virtual host interfaces provides a communications and process behavioral interface to one of the tools in the plurality of tools. The automation host can control and coordinate operation of all tools in the plurality of tools via the single communications and process behavioral connection interface.

Description

BACKGROUND

[0002] The present invention concerns the manufacturing of semiconductor circuits and pertains particularly to a virtualized generic equipment model data and control router for factory automation.

[0003] The semiconductor manufacturing process is made up of a significant number of unique semiconductor materials processing steps. At each step the material is exposed to various mechanical, chemical or electrical processes that either change or measure the nature of the semiconductor material. Each one of these steps requires a unique and highly specialized materials processing tool.

[0004] In any given fabrication manufacturing process step, there are typically five common actions performed. In the first action, the material (e.g., a silicon wafer) arrives at a tool. At the tool, the material is detected, identified and onloaded.

[0005] In a second action, the material is moved into a process chamber. In a third action, the material is processed. In a fourth action, the material is moved out of the process chamber. In a fifth action, the material is offloaded from the tool.

[0006] In the first, second, fourth and fifth action, the material is transported and these actions are collectively referred to as the materials transport function. In the third action, the material is processed and this action is referred to as the materials processing function. Typically the materials transport function and the materials processing function are integrated into a single process tool.

[0007] Either a cell controller or a factory host system manage the automation of a collection of tools. Herein, the factory host and the cell controller are both referred to as the “process step host” or “automation host”. For each tool, the process step host typically has one communication path and manages one process state model. This one to one relationship of communication, state model and process step provides an easy method of managing the automation.

[0008] There are cases, however, where it takes multiple physical tools to accomplish the five actions for a single manufacturing process step. The most prevalent case of this is the material test process step, where the five steps of the materials processing function and the materials transport functions described above are typically three separate tools.

[0009] For example, materials onload and offload are accomplished by an automated materials transport and docking system typically known as an Equipment Front End Module (EFEM). Materials movement within the process step is accomplished by a materials handling system typically known as a prober or handler. Materials processing for the test process step is accomplished by a test system.

[0010] Herein, a process step that requires these multiple physical tools to complete the step is referred to as a non-integrated materials transport process step. For a non-integrated materials movement process step, the process step host is not only managing the process step, but also has to micromanage the relationship between the multiple tools required to accomplish that single process step. Unlike an integrated materials movement tool, the process step host must keep track of multiple individual process state models and multiple communication paths for a single process step.

[0011] In order to provide a common framework for the automation of the semiconductor manufacturing processes, semiconductor manufacturers rely upon mechanical and software standards developed by several industry wide consortiums. These automated manufacturing processes include both the individual process step tools, and the manufacturing process cells made up of several individual process tools under the direction of the process step host computer. The vast majority of these automation standards are issued by the Semiconductor Equipment Manufacturers Institute (SEMI). The fundamental communication standards that govern the process step host to tool communication and behavior are the SEMI E4, E5 E30 and E39 standards. These standards are commonly known as the SEMI SECS/GEM standards. SEMI also provides an additional standard, E87, which provides for the management of materials carriers used to transport material between process steps and process tools.

[0012] One particular aspect of SEMI E30 and E87 is that they require the process tool to provide and maintain an equipment process state model. This model allows the automation function to track and understand the physical and logical behavior of the process tool. By following the process tool's behavioral process state model, the automation function can understand what the process tool is doing, and what it is valid and able to do next. SEMI E30 and E87 also require the process to provide and maintain control, port, and communication state models.

[0013] In the specific case of 300 mm semiconductor fabrication facilities (fabs), the application of the relevant SEMI and other standards is further described by the CIM Global Joint Guidance for 300 mm Semiconductor Factories (GJG) issued by International Sematech (ISMT) and the Japan 300 mm Semiconductor Technology Conference (J300).

[0014] The GJG provides an important, specific requirement for manufacturing process automation that is a critical concern for nonintegrated materials handling process step implementations. GJG CIM Guidelines Revision 5, Section 1, Paragraph 1.1 states:

[0015] A single physical communication connection must link the production equipment to the host. A single physical communication connection means that the Equipment Front End Module (EFEM) is integrated through the production equipment rather that connected directly to the host.

[0016] With respect to the materials test process step, the above-quoted requirement means that the carrier management capabilities of the EFEM, the materials movement capabilities of the prober, and the materials processing capabilities of the test system, must all be controlled and communicated to the process step host via a single, integrated communications link.

[0017] The non-integrated materials process step requires a much higher level of control, and causes problems when trying to meet the requirements of the SEMI and GJG standards that govern the process step. The common implementations of the SEMI standards assume that a single tool accomplishes the process step, and that the materials movement function and materials processing function are all accomplished by that single tool. The GJG requires both functions be connected to the process step host via a single communications link.

SUMMARY OF THE INVENTION

[0018] In accordance with the preferred embodiment of the present invention, an interface between an automation host and a plurality of tools is used to perform a processing step. The interface includes a single communications and process behavioral connection interface to the automation host. The interface also includes a plurality of virtual host interfaces. Each virtual host interface from the plurality of virtual host interfaces provides a communications and process behavioral interface to one of the tools in the plurality of tools. The automation host can control and coordinate operation of all tools in the plurality of tools via the single communications and process behavioral connection interface.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG. 1 shows a factory automation host interacting with a process step tool and a cell controller within a process step cell.

[0020] FIG. 2 shows the inclusion of a non-integrated materials transport process step into an automated manufacturing process.

[0021] FIG. 3 shows a generic equipment model (GEM) router interacting with factory automation host 40 and a plurality of tools in accordance with a preferred embodiment of the present invention.

[0022] FIG. 4 shows a simplified block diagram of a GEM router in accordance with a preferred embodiment of the present invention.

DESCRIPTION OF THE PRIOR ART

[0023] FIG. 1 shows a factory automation host 10 interacting with a process step 1 tool 11 and a cell controller 13 within a process step cell 12. Factory automation host 10 manages the automation of process step 1 tool 11. Cell controller 13 within process step cell 12 manages the automation of a process step 2 tool 14 and a process step 3 tool 15.

[0024] FIG. 2 shows the inclusion of a non-integrated materials transport process step into an automated manufacturing process. A factory automation host 20 interacts with a tool 26, a tool 27 and a tool 28 within a process step (1) 21 and a cell controller 23 within a process step cell 22. Factory automation host 20 manages the automation of tools 26, 27 and 28 within process step (1) 21. Cell controller 23 within process step cell 22 manages the automation of a tool 29, a tool 30 and a tool 31 within process step (2) 24 and process step 3 tool 25.

[0025] For example, tool 26 and tool 29 are used to accomplish the materials processing function. The materials transport functions are accomplished by tool 27 and tool 30, representing the prober, and tool 28 and tool 31, representing the EFEM.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0026] As shown in FIG. 4, a virtualized generic equipment model data and control router for factory automation (GEM router) can be used to provide a mechanism for aggregating the communications and process state model functions of multiple process tools into a single process step communications path to a process step host. A GEM router implements a virtual GEM interface.

[0027] Using a GEM router allows a non-integrated materials transport process step to appear to the process step host as a single, integrated materials transport process step.

[0028] For example, FIG. 3 shows a factory automation host 40 interacting with a GEM router 52 and a cell controller 43 within a process step cell 42. GEM router 52 interacts with a tool 46, a tool 47 and a tool 48 within a process step (1) 41. Cell controller 43 interacts with a GEM router 53 and a process step 3 tool 45. GEM router 53 interacts with a tool 49, a tool 50 and a tool 51 within process step (2) 44.

[0029] For example, tool 46 and tool 49 are used to accomplish the materials processing function. The materials transport functions are accomplished by tool 47 and tool 50, representing the prober, and tool 48 and tool 51, representing the EFEM.

[0030] In a preferred embodiment of the present invention, a generic equipment model (GEM) interface is used to interact with tools within a process step. However, other embodiments of the invention are not limited to the use of a GEM connection. As will be understood by persons of ordinary skill in the art, data control and routing of non-GEM based communications automation scenarios can be accomplished using the principles of the present invention described herein.

[0031] Also, software that implements a GEM router can be located in a number of different places. For example, the GEM router function can reside on a local controller of one process step tool, on a cell controller, or on a factory host.

[0032] FIG. 4 shows a block diagram of a GEM router 61. GEM router 61 connects across a factory automation boundary to a real GEM host 60. To implement the connection, a persistent virtual GEM client 62 within GEM router 61 always exists.

[0033] Connected to persistent virtual GEM client 62 is a GEM Executive 63. GEM Executive 63 handles requested state changes and provides scenario information for virtual GEM host generation.

[0034] A state machine scenario determinator 64 takes information originating from real GEM host 60 and identifies the number and type of virtual GEM hosts that must be created by a GEM temporal connection builder 66. Virtual GEM host connections are built based on the process requirements relayed from the factory automation system.

[0035] A virtual GEM host concentrator 65 relays actions, events and reports coming from virtual GEM hosts (represented in FIG. 4 by a virtual GEM host (1) 67, a virtual GEM host (2) 68 and a virtual GEM host (n) 69) before being passed to persistent virtual GEM client 62 and on up to the real GEM host 60.

[0036] Virtual GEM host (1) 67 interacts with a real GEM client 75 within a machine (1) 71. Virtual GEM host (2) 68 interacts with a real GEM client 76 within a machine (2) 73. Virtual GEM host (n) 69 interacts with a real GEM client 77 within a machine (n) 73. A machine specific host 70 interacts with a machine specific client 78 within a machine 74. For example, each machine is a process step tool.

[0037] GEM router 61 establishes communications to each individual process step tool. For each tool, temporal GEM connection builder 66 establishes a virtual GEM host connection. The existence of a host above GEM router 61 is transparent to each process step tool.

[0038] The specific GEM capabilities of each tool are determined at connection time, and a persistent description of those capabilities is stored within GEM router 61. These capabilities include process alarm and control state models, process and tool variables, and a valid SECS message set.

[0039] GEM router 61 establishes communication with real GEM host 60 as a single point of communication for real GEM host 60. Since real GEM host 60 is a process step host, GEM router 61 establishes communications as a single point of communication for the process step. The existence of multiple individual tools is transparent to real GEM host 60.

[0040] Each message from real GEM host 60 is received by persistent virtual GEM client 62 and is analyzed. Based on this analysis, the message is deconstructed into several individual messages and then passed via temporal virtual GEM host connection to each individual process step tool's real GEM client.

[0041] If a host message is a request for information, virtual GEM host concentrator 65 may collect additional information from other process step tools via their temporal virtual GEM host connections. Once virtual GEM host concentrator 65 has enough information to resolve the host request, virtual GEM host concentrator 65 will construct a valid GEM message to respond to real GEM host 61.

[0042] Each message from an individual process step tool's real GEM client function is received by the appropriate temporal virtual GEM host connection and analyzed. Based on this analysis, the GEM host concentrator 65 may collect additional information from other process step tools via their temporal virtual GEM host connections. Once the GEM host concentrator 65 is satisfied, it constructs a single message and passes it to the process step GEM host.

[0043] In this way GEM host concentrator 65 aggregates the communication message sets of a collection of individual process tools into a single communications message set for the collection of tools.

[0044] Any message from real GEM host 60 or any process step tool can cause a change in the process step's process state model. The process step's process state model is an aggregation of each individual process step tool's process state model. State machine scenario determinator 64 tracks the changes to each individual process step tool's process state model, and maintains an aggregated process state model for the entire process step. The same actions are performed for changes to the control state models and port state models.

[0045] State machine scenario determinator 64 aggregates the process state models of a collection of individual process tools into a single process state model for the collection of tools. Likewise state machine scenario determinator 64 aggregates the control state models of a collection of individual process tools into a single control state model for the collection of tools. Likewise state machine scenario determinator 64 aggregates the port state models of a collection of individual process tools into a single port state model for the collection of tools.

[0046] GEM router 61 allows the process variables set, and variable identification numbers of a collection of individual process tools to be aggregated into a single process variable set and variable identification number range for the collection of tools.

[0047] The foregoing discussion discloses and describes merely exemplary methods and embodiments of the present invention. As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1. An interface between an automation host and a plurality of tools used to perform a processing step, the interface comprising: a single communications and process behavioral connection interface to the automation host; and, a plurality of virtual host interfaces, each virtual host interface from the plurality of virtual host interfaces providing a communications and process behavioral interface to one of the tools in the plurality of tools; wherein the automation host can control and coordinate operation of all tools in the plurality of tools via the single communications and process behavioral connection interface.

2. An interface as in claim 1 wherein a number of virtual host interfaces is variable depending upon a number of tools in the plurality of tools.

3. An interface as in claim 1 wherein the plurality of virtual host interfaces implement different communications and process behavioral interface for different tools from the plurality of tools.

4. An interface as in claim 1 wherein the single communications and process behavioral connection interface makes the plurality of tools appear to the automation host as a single tool.

5. An interface as in claim 1 additionally comprising a state machine scenario determinator that aggregates process state models for the plurality of tools into a single process state model.

6. An interface as in claim 1 additionally comprising a state machine scenario determinator that aggregates control state models for the plurality of tools into a control process state model.

7. An interface as in claim 1 additionally comprising a state machine scenario determinator that aggregates port state models for the plurality of tools into a single port state model.

8. An interface as in claim 1 wherein a process variables set and variable identification numbers of tools from the plurality of tools are aggregated into a single process variable set and variable identification number range for the plurality of tools.

9. An interface as in claim 1 additionally comprising a host concentrator that aggregates communication message sets of individual tools from the plurality of tools into a single communications message set for the plurality of tools.

10. An interface in 1 wherein each virtual host interface from the plurality of virtual host interfaces is compliant with the Semiconductor Equipment Manufacturers Institute (SEMI) generic equipment model (GEM) interface requirements.

11. An interface in 1 wherein the single communications and process behavioral connection interface to the automation host is compliant with the Semiconductor Equipment Manufacturers Institute (SEMI) generic equipment model (GEM) interface requirements.

12. A method for connecting an automation host to a plurality of tools used to perform a processing step, the method comprising the following steps: (a) providing a separate communications and process behavioral interface to each tool in the plurality of tools; and, (b) providing a single communications and process behavioral connection interface to the automation host, including the following substep: (b.1) allowing the automation host to control and coordinate operation of all tools in the plurality of tools via the single communications and process behavioral connection interface.

13. A method as in claim 12, wherein in step (a) a number of virtual host interfaces is variable depending upon a number of tools in the plurality of tools.

14. A method as in claim 12, wherein in step (a) the plurality of virtual host interfaces implement different communications and process behavioral interface for different tools from the plurality of tools.

15. A method as in claim 12, whereinin step (b) the single communications and process behavioral connection interface makes the plurality of tools appear to the automation host as a single tool.

16. A method as in claim 12, additionally comprising the following step: (c) aggregating process state models for the plurality of tools into a single process state model.

17. A method as in claim 12, additionally comprising the following step: (c) aggregating control state models for the plurality of tools into a single control state model.

18. A method as in claim 12, additionally comprising the following step: (c) aggregating port state models for the plurality of tools into a single port state model.

19. A method as in claim 12, additionally comprising the following step: (c) aggregating a process variables set and variable identification numbers of tools from the plurality of tools into a single process variable set and variable identification number range for the plurality of tools.

20. A method as in claim 12, additionally comprising the following step: (c) aggregating communication message sets of individual tools from the plurality of tools into a single communications message set for the plurality of tools.

21. A method in 12 wherein in step (a) each separate communications and process behavioral interface is compliant with the Semiconductor Equipment Manufacturers Institute (SEMI) generic equipment model (GEM) interface requirements.

22. A method in 12 wherein in step (b) the single communications and process behavioral connection interface to the automation host is compliant with the Semiconductor Equipment Manufacturers Institute (SEMI) generic equipment model (GEM) interface requirements.