Patent Abstract:
Generic interface adapter builder software generates an interface adapter to tie tools into a centralized manufacturing execution system. As contemplated by embodiments of the present invention, the interface adapter allows a tool in a semiconductor manufacturing assembly to communicate with other hardware and software in the centralized manufacturing execution system in accordance with a standard protocol and be operable from a common view graphical user interface. The generic interface builder software uses a classification of the type library and desired parameters for a particular tool to generate the interface adapter that maps the interface methods of the tool to the interface of the manufacturing execution system and handles long running service request support. In one aspect of the invention, the tool to be integrated into the manufacturing assembly may be a material control system. As contemplated by embodiments of the present invention, the material control system uses COM-based interface methods, and may optionally include a COM-based protocol converter, and may expose its interface methods via a type library.

Full Description:
FIELD OF THE INVENTION 
     The present invention relates generally to manufacturing automation and specifically to software for automation of semiconductor manufacturing. 
     BACKGROUND OF THE INVENTION 
     Semiconductor manufacturing is an increasingly complex, multi-step process that is subject to strict manufacturing requirements (e.g., tight manufacturing tolerances) and schedules. This manufacturing is typically carried out in large fabrication facilities, often costing billions of dollars to construct. These facilities typically incorporate dozens of tools (including software, devices and various systems) involved in the various stages of the manufacturing process. 
     Semiconductor chips that are manufactured from the facilities mentioned above are formed through a serial photolithography process that may require hundreds of steps to form a finished chip. Every step in the process must be closely monitored, materials carefully regulated, and timing carefully controlled. Due to the high cost of building a fabrication facility, maximizing the efficiency of these facilities is particularly important. The sequencing of steps, scheduling of materials, and other process parameters vary with the particular chip being manufactured. Automation is critical to running a semiconductor fabrication facility effectively, and manufacturing automation software, such as Consilium, Inc.&#39;s FAB 300  ® manufacturing execution system (in its various versions), enables integrated management of the entire process. (Consilium, of Mountain View, Calif., is a company of Applied Materials, Inc., of Santa Clara, Calif.). An important aspect in facilitating this efficiency is the integration of the various tools in the fabrication facility to establish a smooth manufacturing assembly. Due in part to the various factors indicated above, integration is a significant challenge. 
     It may be desirable that a manufacturing execution system (MES) allow managers to control the entire manufacturing process, including various aspects such as tool management, materials management, data management, scheduling, etc., in a centralized manner. In many cases it is preferable that an MES allow the entire manufacturing operation to be run from a single software user interface; however, existing systems often incorporate a variety of interfaces. The tools that are used in a fabrication facility may come from a variety of manufacturers and incorporate a variety of interfaces, communication protocols, etc. 
     Due to the lack of standardization across tools, incorporating the tools into an MES to allow the software to deliver process instructions and receive production data may require complex, individual programming for each tool. Typically, to link each tool into the MES, a semiconductor manufacturer must create a customized software interface between the tools and the MES. To do this, the systems integrator must be familiar with the source code of the MES. Also, even when a standard protocol is used, each tool must be individually tied in to the system essentially manually. For example, a facility may select one of several material control systems commercially available from different vendors as a component of its manufacturing assembly. Each material control system may have its own set of commands and communication protocols. A systems integrator at the fabrication facility will write special software to allow the selected material control system to function in the fabrication facility&#39;s manufacturing environment (i.e., to tie it in with the MES). The requirements of the software will depend on the specific material control system selected. Moreover, due to the lack of standardization, each new component should be carefully tested before being released into the system. Particularly given the number of tools typically involved, tying the tools in this way is an expensive, time-consuming process. The resulting system is unwieldy and inconsistent and diminishes the ability of the MES to provide a single, controllable definition of the manufacturing process and to maximize the active production time of the facility. 
     Consequently, there is a need for “plug-and-play” operability of semiconductor manufacturing tools with respect to an MES, preferably utilizing a common graphical user interface for all components. Accordingly, there is a need for a system that substantially or fully automates and standardizes the process of integrating tools into an MES in a uniform way. 
     SUMMARY OF THE INVENTION 
     The present invention addresses the issues mentioned above by providing a system, method and medium for generating an interface adapter to facilitate communication between tools and a centralized manufacturing execution system (MES). As contemplated by embodiments of the present invention, the interface adapter then allows a tool (which can be, e.g., a system performing a function) in a semiconductor manufacturing assembly to communicate with other hardware and software in the centralized MES in accordance with a standard protocol and to be operable from a common view graphical user interface (or common set of interfaces). In one aspect of the invention (and environments used therewith), the interface adapter handles asynchronous calls or long-running service requests to the material control system, while passing through synchronous calls. In an exemplary embodiment, the interface adapter functions as a Microsoft® Transaction Server (MTS) component on an MTS server. 
     By way of example, embodiments of the present invention will be explained herein with regard to a material control system as the exemplary tool being integrated into the manufacturing assembly. The material control system uses, in various embodiments, COM-based interface methods (optionally including a COM-based protocol converter), exposing its interface methods via a type library. In generating the interface adapter, the present invention identifies the type library and desired parameters of the material control system, maps the COM-based interface methods of the material control system to the interface of the MES, and, e.g., handles long running service request support. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     For a fuller understanding of the present invention, reference should be made to the following detailed description taken in connection with the accompanying drawings, not drawn to scale, in which the same reference numerals indicate the same or similar parts, wherein: 
     FIG. 1 is a block diagram of exemplary manufacturing components, as contemplated by embodiments of the present invention. 
     FIG. 2 is a flow diagram of generating a generic interface adapter, as contemplated by embodiments of the present invention. 
     FIG. 3 is a block diagram of a MES incorporating a generic interface adapter, wherein a material control system further includes a manufacturing control system protocol converter. 
     FIG. 4 is a view of an exemplary user interface in accordance with embodiments of the present invention. 
     FIG. 5 is a block diagram of client request handling of synchronous requests through an interface adapter in accordance with embodiments of the present invention. 
     FIG. 6 is a block diagram of service handling for asynchronous or long-running service requests through an interface adapter in accordance with embodiments of the present invention. 
     FIG. 7 is a block diagram of register for notification handling through an interface adapter in accordance with embodiments of the present invention. 
     FIG. 8 is a block diagram of event notification handling through an interface adapter in accordance with embodiments of the present invention. 
     FIG. 9 is a block diagram of asynchronous or long running service request handling through an interface adapter in accordance with embodiments of the present invention. 
     FIG. 10 is a block diagram of a computer processing system used as part and/or in environments of the present invention. 
    
    
     DETAILED DESCRIPTION 
     In FIG. 1, a block diagram of exemplary manufacturing components (including an MES [or portion thereof] and a tool)  100  contemplated for use in environments with (and/or as part of) the present invention is shown. Referring now to FIG. 1, manufacturing components  100  include a material control system client  110 , and a generic interface adapter  112  to interface with a material control system (MCS)  114 . In this example, the MCS client  110  and a generic interface adapter  112  are contemplated to be part of the MES, while the MCS is envisioned to be an exemplary tool. Although the tool shown here is MCS  114 , it should be understood that the tool may be any tool, including a system, software or device tied to an MES (or like device). Embodiments of the present invention contemplate that the tool can be any event-based Distributed Common Object Model object. 
     Continuing the description of the exemplary components  100 , MCS  114  tracks and transfers the movement of materials through the fabrication facility. Generally, the MES manages dispatching of tools to complete jobs in the facility workflow and will use an adapter like adapter  112  to communicate with tools as necessary. For example, to dispatch tools for performing a boron implant in a lot, the MES may go through a series of steps. Initially, an implanter tool (not shown), for example, notifies the MES that it is available and joins the dispatch list as waiting for work. Independently, a lot of materials notifies the MES that it requires a boron implant and joins the dispatch list as waiting for a boron implant. Subsequently, the MCS client  110  portion of the MES determines whether the waiting lot can run on a particular implanter and launches a job once the availability is confirmed. The MCS client  110  calls some of the necessary services to complete the job, including invoking the MCS  114  (to transfer the lot to the implanter) through the generic interface adapter  112 . 
     Shown in the flow diagram  220  of FIG. 2, the generic interface builder  230  generates the generic interface adapter  112  that is used to communicate between the MCS client  110  and the MCS  114 . In step  222 , the generic interface builder  230  reads a file that defines the interface to the MCS  114 , and allows a user to select various parameters and classify methods. Depending on the method and the circumstances involved, a particular handling protocol will be selected for the method, (which the adapter will then ultimately use to allow communications between the MCS client  110  and MCS  114 ). An exemplary protocol, which is selected where the method is recognized as one that takes a relatively significant time to complete (e.g., transporting materials from one factory location to another) is a “long running service protocol” (LRSP). Thus, this would be chosen for those methods deemed to require long running service protocol support. In some embodiments contemplated by the present invention, as a default, methods may be assumed to be handled by a “synchronous” protocol if not otherwise identified. In any event, once the protocols for the methods are chosen, the present invention generates and compiles the appropriate program code (steps  224  and  226 ) for the generic interface adapter  112 . 
     Embodiments of the present invention contemplate that the MCS  114  can be a Distributed Common Object Model (DCOM or COM)-based system. The interface to the MCS  114  is envisioned as being defined as a COM type library. The COM type library includes the COM methods that the MCS  114  employs and that can be invoked by an MCS client  110 . 
     Illustrated in FIG. 3, it is envisioned that where the MCS interface is not inherently defined as a COM type library, the MCS  114  may incorporate a protocol converter (MPC)  316  that provides the MCS&#39;s COM type library. The protocol converter  316  may convert between protocols such as a native TCP/IP interface for MCS  114  and the COM type library interface contemplated, in some embodiments, for communicating with the generic interface adapter  112 . Preferably, the MCS&#39;s COM type library is defined in Interface Definition Language, which is defined in the Microsoft® Developers&#39; Documentation Library. Moreover, the MCS  114  is envisioned to be an event-based system that can handle transactions asynchronously, informing the MCS client  110  when a particular task is completed or when an event occurs. 
     Embodiments of the present invention contemplate that the generic interface builder  230  can also be a COM component, and is invoked through the MES. It is envisioned that the generic interface builder  230 , includes a generic interface builder visual interface  234 , such as exemplary graphical user interface  430 , as shown in FIG.  4 . Referring now to FIG. 4, the exemplary graphical user interface  430  depicted therein is shown as providing a prompt  436  to the user to specify the path and file name of the MCS&#39;s type library. The generic interface builder  230  reads the type library and displays the MCS&#39;s COM methods  438  with input and output parameters  440  to the user. For example, for a method that relates to moving a lot from a source to a destination, the related parameters may include a source machine and a source port, a destination area, a destination machine, and a destination port. The user then selects handling protocols for the methods, such as by specifying which methods will require long-running service support. For these methods, the user defines certain parameters, such as transaction identification numbers that will be used to correlate messages that relate to the same longrunning service requests. The user may also identify certain parameters as keys that the MCS  114  may include in its notification when it completes servicing a method service request. The keys may also be used to correlate messages that relate to the same long-running service requests, in the absence of, or, in addition to, identification numbers. For the previous example, the keys may include the destination area, the destination machine, and the destination port. (The concept of long running service support is also described, later herein.) The user then saves the configuration information that relates to the selected handling protocols, parameters, and keys. Alternatively, the step of identifying different types of methods and defining parameters and keys could be automated. For example, it could be carried out by an expert system or the information could be included in the type library. 
     The generic interface builder  230  uses the saved configuration information to generate the appropriate software code (e.g., in the form of a Visual Basic project) for the generic interface adapter  112  for the MCS  114 . In the example herein, the generic interface builder  230  generates the adapter  112  to communicate with both the MCS client  110  and the MCS  114 . The adapter  112  is provided with routines for handling the various types of communication in the system. Embodiments of the present invention contemplate that the communication methods of the MCS client  110  are known beforehand and coded into the generic interface builder  230 , to ultimately be coded into the adapter  112 . The COM methods of the MCS  114 , from the COM type library, are modified or wrapped using the configuration information and the communication methods of the MCS client  110  to create a modified type library of COM methods for the MCS  114  that include information needed for interaction with the MCS client  110 . This information typically will relate to long-running service request support. For asynchronous requests, for example, transaction identification numbers may be associated with the corresponding COM methods. The modified type library is incorporated into the adapter  112 . The adapter  112  also has a type library that defines its interface, which incorporates the modified type library of MCS  114 . The type library of the adapter  112  defines the services that are available to the MCS client  110  to run the adapter  112  and to execute MCS  114  actions. The type library of the adapter  112  will be registered via the operating system of the MCS client  110  (which can be, for example, Microsoft Windows NT®) to inform the client  110  of which methods are available. Subsequently (as indicated above), the generic interface builder  230  compiles the generated Visual Basic project  232  to generate the generic interface adapter  112 . Although Visual Basic is mentioned herein, it should be understood that any other suitable language may also be used. 
     The interface adapter  112  is preferably a Microsoft® Transaction Server (MTS) component. Implementation on a Microsoft® Transaction Server is preferred for robustness and scalability, but any suitable implementation may be used. It is contemplated in some embodiments that the interface methods of the MCS  114  that may be invoked from the MCS client  110  are of these types: synchronous, asynchronous or long-running service protocol requests (LRSP), and register for notification requests. 
     The generic interface adapter  112  also supports three classes of interface methods outgoing from the MCS  114  to the MCS client  110 : notification/reply, events and alarms. These methods may be associated with a service handling protocol, such as the LRSP. The generic interface adapter  112  itself employs three categories of COM server interface methods: those corresponding to the MCS&#39;s type library (which may pass optionally through the MPC as indicated in FIG.  2 ), those for invoking its LRSP support on the MTS server, and those for providing notifications to the MCS client  110  (in accordance with the LRSP for a long-running service request or for a register for notification request). Of course it should be understood that the present invention contemplates that any number of other methods, appropriately associated with any number of other types of service handling protocols, can be used. 
     A synchronous request is one on which the MCS  114  can act immediately or which otherwise does not require any later response or confirmation from the MCS  114 . Accordingly, the MCS client  110  will receive an immediate confirmation, if any, and need not wait for a later reply. Referring now to request processing diagram  550  in FIG. 5, in accordance with a synchronous protocol, the adapter  112  passes synchronous requests through to the MCS  114  directly (or through MCS protocol converter  316 ) by invoking an MCS method. When appropriate, the MCS  114  returned an immediate result to the adapter  112 , which forwards the result to the MCS client  110 . 
     An asynchronous request or LRSP request is one which the MCS  114  may take some time to act on or respond to (at least as measured from the perspective of a computer system operating as part of, or in environments of, the present invention or aspects thereof). For example, if the MCS is required to move a lot A from point B to point C, the MCS  114  will not be able to acknowledge completion of the request by providing notification to the MCS client  110  until it is actually performed. When MCS client  110  receives that response at a later time, the MCS client  110  needs to correlate the response to the initial request, for example with an LRSP identification number (LRSPID) or with the keys returned in the notification. In accordance with the LRSP, the interface adapter  112  manages the LRSP request for the MCS client  110 . The interface adapter  112  includes an LRSP COM method in its COM method library  618  for handling these requests. Referring now to request processing diagram  600  in FIG. 6, when the interface adapter  112  receives an LRSP request for the MCS  114 , it will pass the request on by invoking the MCS&#39;s related COM method and also invokes its own LRSP COM method to monitor the completion of the LRSP request. The LRSP COM method will match the LRSPID or the keys once it receives the reply from the MCS  114  to the initial request. (The reply process is diagrammed in FIG. 8.) 
     A register for notification request is an outstanding request from the MCS client  110  to receive notification of events or alarms invoked by the MCS  114 . Referring now to request processing diagram  700  in FIG. 7, the MCS client  110  registers its interest with the interface adapter  112  by providing a notification method and register key. In contemplated embodiments, a register for notification request is handled like a long-running service request in accordance with the LRSP. In accordance with the LRSP, the interface adapter  110  maintains the request by invoking its own LRSP COM method. No request is passed on to the MCS  114 , but the MCS  114  is monitored by the adapter  112  for an event in which the client  110  has expressed interest and which should be reported back to the client  110  using the appropriate notification and publication methods. 
     Referring now to message processing diagram  800  in FIG. 8, when the generic interface adapter  112  receives a reply, event or alarm from the MCS  114 , the adapter  112  receives the information and correlates it with any LRSP requests, including asynchronous requests or register requests, using its LRSP COM method. The LRSP COM method may use an LRSPID or returned keys from the MCS  114  to correlate a notification from the MCS  114  with an outstanding request. The adapter  112  also determines which notification method has been selected by the MCS client  110  and provides the notification to the client  110 . Embodiments of the invention contemplate that if a notification of an event or alarm is received from the MCS  114  for which there is no corresponding LRSP, including those for asynchronous requests and those for register for notification requests, the notification is ignored. 
     A sample long-running service request handled in accordance with the LRSP is diagrammed in accordance with an embodiment of the invention in request processing diagram  900  in FIG.  9 . In step  902 , the MCS client  110  requests service for a job such as a batch transport job. The client  110  provides values for the corresponding parameters, such as source and destination information, for the request. The adapter  112  receives the request and, in step  904 , invokes its COM method for LRSP support and stores the keys, such as destination information. In step  905 , adapter  112  confirms receipt of the request. In step  906 , the adapter  112  calls the appropriate DCOM method, which optionally is relayed through MPC  316  in step  908 . In steps  907  and  909 , the MPC  316  and the MCS  114  confirm receipt of the request. In step  910 , the MCS  114  executes the method to service the request. In step  912 , the MCS  114  issues a notification including the keys, when the method is completed. The MPC  316  passes the notification on to adapter  112 . In steps  916  and  917  , adapter  112  uses the keys to identify the original job that has been completed and provides a job identification. Subsequently, in step  918 , the adapter  112  passes on the notification that the long-running service is complete, with the job identification. The client MCS  110  can move on to the next step in a business process that follows completion of the MCS service. 
     Although the generic interface builder  230  and the generic interface adapter  112  have been described herein by reference to an MCS tool  114 , an adapter  112  may be generated for any other type of tool. The tool may be software or hardware or may be a large system incorporating both hardware and software, typically with a software interface, such as the MCS protocol converter  316 . Preferably, the tool will be a COM-based tool and will have its interface defined in Interface Definition Language. 
     Exemplary components of a computer processing system used as part of the present invention, and/or used in environments or in conjunction therewith are shown with regard to FIG.  10 . Referring now to FIG. 10, manufacturing components  100  (having at least some of the various aspects, functionality and components described above) are shown to reside in a memory/storage device  1004 . It is also envisioned that these aspects can originate from communications I/O  1008  (discussed below). 
     Embodiments of the present invention contemplate that the memory/storage device  1004 , itself, could be any number of different types of computer-readable mediums for storing information, including RAM memory, magnetic, electronic, or optical (including holographic) storage, some combination thereof, etc. It should also be understood that, particularly where a tool in communication with adapter  112  (as mentioned above) is an item of hardware (in contrast to, e.g., a software system), then that tool could communicate with the manufacturing components via, e.g., I/O  1008 . 
     Memory/storage  1004  is shown as being in-communication, via communication link  1010  (e.g., a bus), with one or more processor(s)  1002 . Embodiments of the present invention contemplate that the processor(s)  1002  can be those typically found in the types of computers mentioned below, and/or they can be any number of other types of processor(s). 
     Still referring FIG. 10, a display device  1006  is shown. Also shown is I/O  1008 , which is envisioned to communicate with, e.g., tools and/or with various communications networks such as local area networks, the Internet, etc. Here, I/O  1008  is shown to be in communication with processor(s)  1002  and memory/storage  1004  via communication link  1010 . 
     The present invention further contemplates that I/O  1008  can serve to receive various transmission schemes such as those relating to telecommunications, cable or other transmission mechanisms, and that at least some of the aspects of manufacturing components  100  can, in whole or part, be a transmission. Thus, for example, at least some aspects of virtual manufacturing components  100  that might otherwise originate from memory/storage  1004  could instead originate from I/O  1008  (e.g., the medium from which aspects of the manufacturing components  100  originate can be a transmission). 
     It should be understood that the configuration of the various aspects of the present invention depicted by FIG. 10 is by way of example, and that the present invention contemplates any number of different configurations and/or different components. 
     With regard to the various specific processors  1002  contemplated for use with the present invention as depicted by FIG. 10, one exemplary embodiment includes the use of any of the Pentium line of processors from Intel Corporation of Santa Clara, Calif., and/or a Motorola 68000 series processor such as the 68040 processor from Motorola of Schaumberg, III. Exemplary operating systems include Microsoft NT from Microsoft Corporation, as well as any of the various varieties of Unix or Linux. Of course, it should be understood that any number of different types and combinations of current or future processors and/or operating systems could also be used. 
     The language used herein is used for purposes of reference and not limitation. While the invention has been particularly shown and described with reference to preferred embodiments, it will be apparent to those skilled in the art that various modifications and alterations can be made in the described embodiments of the present invention without departing from the spirit and scope of the invention.

Technology Classification (CPC): 6