Abstract:
A method of brokering information in a manufacturing system which includes a broker coupled between a supplier of information and a consumer of information. The manufacturing system receives information from the supplier in a first format and sends information from the broker to the consumer in a second format.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates generally to semiconductor manufacturing and more particularly, to brokering fault detection data. 
     2. Description of the Related Art 
     Manufacturing processes, particularly semiconductor manufacturing processes, generally include a large number of steps, referred to as process steps. These process steps use a number of inputs that are generally fine-tuned to maintain proper manufacturing control. 
     The manufacture of semiconductor devices uses the discrete process steps to create a packaged semiconductor device from raw semiconductor material. The various process steps, from the initial growth of the semiconductor material, the slicing of the semiconductor crystal into individual wafers, the fabrication stages (deposition, etching, ion implanting, or the like), to the packaging and final testing of the completed device, are different from one another and specialized, thus the process steps may be performed in different manufacturing areas or locations that contain different control schemes. 
     Generally, a set of processing steps is performed on a group of semiconductor wafers, sometimes referred to as a lot. For example, a process layer composed of a variety of materials may be formed above a wafer. Thereafter, a patterned layer of photoresist may be formed above a wafer. Thereafter, a patterned layer of photoresist may be formed above the process layer using known photolithography techniques. Typically, an etch process is then performed on the process layer using the patterned layer of photoresist as a mask. This etching process results in formation of various features or objects in the process layer. Such features may be used for a variety of purposes, e.g., in a gate electrode structure for transistors. 
     The manufacturing tools within a semiconductor manufacturing facility typically communicate with a manufacturing framework or a network of processing modules using a common architecture such as common object request broker architecture (CORBA). Each manufacturing tool is generally coupled to an equipment interface. The equipment interface is coupled to a machine interface to which a manufacturing network is coupled, thereby facilitating communications between the manufacturing tool and the manufacturing framework. The machine interface can be part of an advanced process control (APC) system. The APC system initiates a control script, which can be a software program that automatically retrieves the data needed to execute a manufacturing process. 
     To decoupled applications from implementation details, CORBA specification defines an Object Request Broker (ORB) interface that provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through a dynamic invocation interface. The ORB provides a mechanism for transparently communicating client requests to target object implementations. An ORB is a logical entity that may be implemented in various ways such as one or more processes or a set of libraries. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. Thus, client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating the implementation if necessary, delivering the request to the object and returning any response to the caller. 
     Some manufacturing tools may not conform to an architecture such as CORBA. In such cases, it may become important to communicate with devices which conform to the architecture. 
     SUMMARY OF THE INVENTION 
     In one embodiment, the invention relates to a method of brokering information in a manufacturing system comprising a broker coupled between a supplier of information and a consumer of information. The manufacturing system receives information from the supplier in a first format and sends information from the broker to the consumer in a second format. 
     In another embodiment, the invention relates to a method of brokering fault detection and classification data in a manufacturing system which comprises providing a broker coupled between a supplier of fault detection and classification data and a consumer of fault detection and classification data. The manufacturing system receives fault detection and classification data from the supplier in a first format and sends fault detection and classification data from the broker to the consumer in a second format. 
     In another embodiment, the invention relates to a manufacturing system which comprises a supplier of fault detection and classification data, a consumer of fault detection and classification data and a broker. The broker is coupled between the supplier and the consumer. The broker includes a supplier portion that is coupled to the supplier and a consumer portion that is coupled to a consumer. The supplier portion receives the fault detection and classification data from the supplier. The consumer portion supplies alarms to the consumer. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference number throughout the several figures designates a like or similar element. 
         FIG. 1  shows a block diagram of a semiconductor manufacturing system in accordance with the invention. 
         FIG. 2  shows a block diagram of a semiconductor manufacturing system. 
         FIG. 3  shows a flow diagram of the operation of a system using a broker. 
         FIG. 4  shows a block diagram of a fault detection and classification system using a broker. 
         FIG. 5  shows a block diagram of an alternate semiconductor manufacturing system using a broker. 
     
    
    
     DETAILED DESCRIPTION 
     Referring to  FIG. 1 , a block diagram of a semiconductor manufacturing system  100 . Semiconductor manufacturing system  100  includes a broker  104  and a customer  106 . The broker  104  provides the interface between a supplier  102  such as a fault detection and classification (FDC) broker architecture and a customer  106  such as an FDC analysis engine. The broker  104  includes at least one of a plurality of characteristics. More specifically, the broker  104  includes a network transport independence characteristic, a high capacity, moderate latency characteristic, a communication protocol independence characteristic, and a synchronous and asynchronous data exchange characteristic. 
     The network transport independence characteristic allows the broker  104  to provide communication protocol independence and thus supports a plurality of protocols. Several of the protocols used by semiconductor manufacturing systems, such as CORBA and SOAP, specify network transport independence in their respective specifications. The TCP/IP protocol is also a desirable protocol because several of the vendors supplying the communication protocol interfaces support TCP/IP. 
     The broker  104  supports several hundred sensors at a minimum sample rate of, e.g., 50 ms. The semiconductor manufacturing system  100  provides a communication rate of 600-800 kB/sec with a latency of 5 ms. Accordingly each sensor could send 3-4 kB/sec of data. 
     The broker  104  includes three layers, a data layer  110 , a command protocol layer  112  and a communication protocol layer  114 . The communication protocol layer may change protocols if so desired. 
     The broker  104  consumes both synchronous and asynchronous messages. The consumer  106  registers with the broker  104  for the types of data that the consumer  106  wants, such as tool source, but may not be able to specify sample rate. The default sample rate is determined by the supplier  102  at runtime and the supplier  102  has the option of ignoring requests for different sample rates. 
     For asynchronous data, the supplier  102 , such as an equipment interface, sends the data as determined by the remote supplier at runtime. The data is sent as a remote procedure call on the consumer  106  from the supplier  102  (using the communication protocol layer  114 ), and the consumer  106  returns a Boolean value representing a successful transmission. Synchronous data is requested via the broker  104 . Consumers  106  do not need to know anything about the supplier  102 , so all synchronous data requests are sent via the broker  104 . Additionally, the consumer  106  cannot request synchronous data that does not match the registered filter of the consumer  106 . This limitation thus limits the network traffic and the broker  104  complexity. For example, if a consumer  106  is registered to receive data from Tool X, the consumer cannot request the sample plan for Tool Y. 
     The broker  104  includes both a supplier portion  130  and a consumer portion  132 . The consumer portion  132  supplies alarms to consumers, such as the equipment interface (EI). The supplier portion  130  receives synchronous and asynchronous messages from one or more suppliers. 
     The command protocol layer  112  supports a plurality of commands. The commands supported by the command protocol layer include a list plans command, an export plan command, an import plan command, an enable/disable plan command, a start/stop command, a list available sensors command, an external event command, a delete plan command, a subscribe to plans command and a ping command. 
     The list plans commands returns all the available data collection plans for a given tool, their versions, and their current state (enabled or disabled, active or idle). The export plan command returns the details of the plan. The import plan command accepts a plan created by an application or from another similar tool (enables the copying of data collection plans from tool to tool or chamber to chamber). The enable/disable plan command accepts input to enable or disable a plan; logic for when to invoke a plan is not evaluated for disabled plans. With the start/stop command, events external to the data server can be used to trigger the start or stop of a particular plan. A plan may need to be configured to accept these events i.e., the logic of the plan looks for these events. The list available sensors command returns a list of sensors available from the tool. Sensor alias objects are presented as opposed to Status Variable Identifiers (SVID&#39;s). Thus third party clients can define their own collection plans. The external event command accepts a self-defining external event that for example could be used to enable or disable a data collection plan or could be used to modify the collection rate logic. The delete plan command accepts a command to delete a disabled plan. With the subscribe to plan(s) command, a supplier accepts a request from a remote consumer to receive data when a plan is collecting data. Multiple consumers are able to subscribe to the same plan. With the ping command a supplier can determine if the other side of the connection is alive and well (and possibly determine the network latency between the applications). 
     The data layer  110  includes a data schema. The data schema of the data layer  100  represents sensor data, events (such as tool events, tool alarms, analysis engine alarms or custom events), data collection plans, and configuration information. The data schema and the command protocol layer  112  are extensible. 
     Data collection plans are implemented into the consumer  106  using one of two methods, filterable headers that are set during registration with the broker  104  and synchronous messages. Multiple consumers are registered with multiple data collection plans. If at any time, a different data collection plan is used for a consumer  106 , the consumer  106  un-registers itself, changes plans, and then re-registers itself with the broker  104 . Preferably, the re-registration process takes no loner than the minimum sample rate. 
     A named data collection plan includes a list of sensors to collect (sent in the filterable header), a frequency at which to collect the sensor data (sent via a synchronous message), conditional rules which the supplier  102  may determine how to send asynchronous data, and version information for history and change control. 
     To reduce supplier complexity, collection plans are not changed on the fly. However, there are a plurality of procedures by which the collection plan may be changed. For example, the broker  104  may register several consumers with different conditional rules. The broker  104  may un-register a consumer and then re-register the consumer with a different plan. The broker  104  may create a consumer with a specific plan, then register the consumer when the broker desires to activate the plan and un-register the plan when no longer needed. 
     Referring to  FIG. 2 , a block diagram of a system  100  in accordance with the present invention is shown. Semiconductor wafers  220  are processed on processing tools  210   a ,  210   b  using a plurality of control input signals, or manufacturing parameters, provided via a network  223 . Control input signals, or manufacturing parameters sent to the processing tools  210   a ,  210   b  from a computer system  230  via machine interfaces  215   a ,  215   b . The first and second machine interfaces  215   a ,  215   b  are located outside the processing tools  210   a ,  210   b . In an alternative embodiment, the first and second machine interfaces  215   a ,  215   b  are located within the processing tools  210   a ,  210   b . The semiconductor wafers  220  are provided to and carried from a plurality of processing tools  210 . The semiconductor wafers  220  may be provided to the processing tool  210  in an automatic fashion (e.g., robotic movement of semiconductor wafer  220 ). In one embodiment, a plurality of semiconductor wafers  220  are transported in lots (e.g., stacked in cassettes) to the processing tools  210 . 
     The process controller  212  sends control input signals, or manufacturing parameters, on the line  223  to the first and second machine interfaces  215   a ,  215   b . The process controller  212  controls processing operations. The process controller  212  employs a manufacturing model to generate control input signals on the line  223 . The manufacturing model contains a manufacturing recipe that determines a plurality of control input parameters that are sent on the line  223  to the processing tools  210   a ,  210   b.    
     The manufacturing model defines a process script and input control that implement a particular manufacturing process. The control input signals (or control input parameters) on the line  223  that are intended for processing tool “A”  210   a  are received and processed by the first machine interface  215   a . The control input signals on the line  223  that are intended for processing tool “B”  210   b  are received and processed by the second machine  215   b . Examples of the processing tools  210   a ,  210   b  used in semiconductor manufacturing processes are steppers, etch process tools, deposition tools, and the like. 
     One or more of the semiconductor wafers  220  that are processed by the processing tools  210   a ,  210   b  can also be sent to an offline metrology tool  250  for acquisition of metrology data. The offline metrology tool  250  can be an optical data acquisition tool, an overlay-error measurement tool, a critical dimension measurement tool, and the like. In one embodiment, one or more processed semiconductor wafers  220  are examined by an offline metrology tool  250 . Furthermore, metrology data may also be collected by the integrated metrology tool  252  within the processing tools  210   a ,  210   b.    
     Data from the integrated metrology tool  252  and the offline metrology tool  250  may be collected by the data analysis unit  260 . The metrology data is directed to a variety of physical or electrical characteristics of the devices formed on the wafers  220 . For example, metrology data may be obtained as to line width measurements, depth of trenches, sidewall angles, thickness, resistance, and the like. As described above, the data analysis unit  260  organizes, analyzes, and correlates data acquired by the metrology tools  250 ,  252  to particular semiconductor wafers  220  that were examined. 
     The data analysis  260  sends data (including inline-type metrology data) and offline metrology data, from the integrated metrology tool  252  and offline metrology tool  250 , respectively, to the database  254  for storage and/or access for analysis. The database  254  receives data, which includes offline and integrated data, as well as other data such as tool state data  270  and process state data  272 . The database  254  may correlate the data with corresponding tool state data and/or process state data, thereby expanding and/or contracting the data for fault detection analysis. The database  254  may also send and receive data via the broker  104 . 
     Data from the database  254  may be extracted by a data analysis unit  260  for performing fault detection analysis based upon data from the database  254 . The fault detection unit  280  provides fault detection data to the process controller  212 , which may use the fault detection data/analysis to improve the operation of the semiconductor wafer  220  manufacture processes. The data analysis unit  260  may be a software function, a hardware circuit and/or a firmware component of a standalone unit or unit(s) integrated into a computer system. 
     Referring to  FIG. 3 , when the system starts, the broker  104  initializes with the ORB  310 , which in one embodiment is an Orbix type ORB. After the broker initializes with the ORB, the supplier  102  initializes with the ORB. After the supplier initializes with the ORB  310 , then the client (i.e., the consumer) initializes with the ORB  310 . 
     After the broker  104 , the supplier  102  and the consumer  106  initialize with the ORB, then the supplier  102  registers with the broker  104  as a supplier  102  using a RegisterAsSupplier call. When the supplier  102  registers with the broker  104 , then for each existing matching consumer  106 , the broker  104  provides the consumer information to the supplier via an addConsumer call. The addConsumer call provides an attribute via an idl string. (e.g., ObjeRef:string(idl)). The broker  104  provides this information to the supplier because there may be consumers  106  already registers with the broker  104 . 
     After the broker  104  provides the consumer information to the supplier  102 , the consumer  106  registers with the broker  104  as a consumer. The broker  104  then informs the supplier  102  of the newly registered consumer  106  via an addConsumer call. 
     After the registration process, tools publish data to the supplier via the broker  104  using a publishDataToAllConsumers command using an xml data string. Additionally, consumers  106  may consume data from suppliers  102  via a publishDataToConsumer command using an xml data string. 
     Referring to  FIG. 4 , FDC system  400  uses broker  104  to provide an interface between the various data suppliers  102 , data consumers  106  and the analysis engine  410 . The FDC system  400  includes FDC data suppliers  102 , FDC data consumers  106 , data storage  421  and an analysis engine  410 , as well as tool  420  and equipment interface  422 . Tool  420  includes, e.g., sensors  428  and object based equipment model (OBEM)  429 . Each of the portions of the FDC system  400  interact with the data storage  421  of the FDC system  400  via the FDC data broker  104 . 
     Other Embodiments 
     Other embodiments are within the following claims. 
     For example,  FIG. 5  shows a block diagram of an alternate system  500  including a broker  504 . In system  500 , the supplier  102   a  and the consumer  106   a  conform to and communicate via a CORBA protocol. Adapters  540   a ,  540   b  allow the broker  504  to accommodate any protocol. These adapters  540   a ,  540   b  may be added to a compiled or run-time version of the broker  504 . This system allows additional protocols to be added to the broker  504  after the initial deployment of the broker  504 . 
     Examples of existing protocols that might be accommodated via an adapter  540   a ,  540   b  include the simple object access protocol (SOAP), the MQ Series protocol from IBM and the HyperText Transport Protocol HTTP protocol. Accordingly, the broker  504  not only accommodates existing protocols but provides the ability to accommodate additional protocols. 
     Also, for example, add-on tool sensors such as chemical concentration or particle sensors may also register as suppliers.