1. Field of the Invention
The present invention pertains to semiconductor fabrication, and, more particularly, automated scheduling of a test wafer build in an semiconductor manufacturing process flow.
2. Description of the Related Art
Integrated circuits, or microchips, are manufactured from modern semiconductor devices containing numerous structures or features, typically the size of a few micrometers. The features are placed in localized areas of a semiconducting substrate, and are either conductive, non-conductive, or semi-conductive (i.e., rendered conductive in defined areas with dopants). The fabrication process generally involves processing a number of wafers through a series of fabrication tools. Each fabrication tool performs one or more of four basic operations in which layers of materials are added, removed, and/or treated during fabrication to create the integrated, electrical circuits that make up the device.
The fabrication essentially comprises the following four basic operations:
The precision with which these four operations are performed is important. The various parts of the integrated circuits created by the operations must be precisely located or they will not work. If the circuits do not work, then the product wafer is scrapped, or thrown away. Even one mistake can ruin the entire wafer. This is costly not only from the standpoint of lost materials, but also from the standpoint of lost processing time. Furthermore, these types of processing errors frequently are repeated, meaning that more than one product wafer, or even more than one lot of product wafers, may to be scrapped.
Consequently, before a fabrication tool can be placed into a process flow, it undergoes a series of qualifications procedures, or “quals”, to make sure it is calibrated and performing both accurately and precisely. A “qualified” tool, however, does not necessarily continue to operate within specifications for all time. Over time, settings drift, instruments age, and other adverse developments occur that may cause the fabrication tool to lose the required degree of precision. Regularly scheduled preventive maintenance, after which the fabrication tool is qualified again, help mitigate these problems. But these problems can sometimes occur more often than preventive maintenance routines are performed. Process tools also periodically undergo preventive maintenance to prolong the life of the tool, to adjust settings, etc. The fabrication tool must once again undergo a qual after a preventative maintenance session before reintroduction into the process flow.
A qual generally involves processing a plurality of test wafers on the fabrication tool. Test wafers are wafers or wafer pieces that are blank or partially processed by selected process steps and subsequently evaluated to determine the quality of the operation being performed. (Sometimes test wafers are instead referred to as “monitor wafers”.) Test wafers are processed through a fabrication tool in a similar manner to the product wafers. Typically, a lot of wafers is kitted, the lot comprising different types of test wafers. The lot is then processed through the fabrication tool being qualified.
Once processed, the test wafers are reviewed to evaluate the performance of the fabrication tool. The reviewed wafers are then de-kitted, or broken out of the lot, and disposed of depending on their utilization. Some wafers might be reused as the same type of wafer, while others might be downgraded to a different type of wafer, while others might be sent to a waste bin for recycling or scrapping.
However, the testing must be conducted within the context of the operations of the process flow as a whole. As importantly, the process flow may comprise just one of several, or many, in a fabrication facility, or “fab”. The process flows furthermore frequently overlap, sharing tools and resources. Thus, testing a fabrication tool in a process flow may have adverse effects that ripple throughout the fab, substantially impairing the productivity of the fab.
Furthermore, test wafers frequently have to be “built”, or processed through a series of steps. Process flows typically do not include equipment dedicated to test wafer builds. Equipment intended for processing product wafers must therefore be re-directed temporarily to test wafer builds when needed. During this period, product wafers are unprocessed, which decreases the efficiency, throughput, and profitability of the process flow. Great effort is therefore generally expended to schedule test wafer builds in manner minimizing adverse impact to the production.
Still further, management of test wafer inventories can create difficulties throughout the process flow. For instance, excess numbers of test wafers can be generated to meet demands by test wafers out of position in the process flow so that they are effectively unavailable for use even though they are dormant. In turn, these excess numbers might necessitate capital outlay to acquire material handling resources over and above what might otherwise be needed if the test wafer numbers were more efficiently managed. The additional material handling resources also require maintenance, thereby increasing overhead, and complicate fab design and layout.
The problems associated with test wafers for quals arise from several sources. One source is that the management and consumption tasks are disjointed, as opposed to integrated. For instance, managing the test wafer inventory is typically handled separately from the managing utilization of the test wafers which is typically handled separately from distribution of the utilized test wafers after they are de-kitted. Another source is that the system is not automated. One or more wafer fab technicians are assigned to the handling of each of these management tasks. The complexity of the fab and sheer number of test wafers, process tools, etc. can quickly overwhelm the capabilities of any tech.
The present invention is directed to resolving, or at least reducing, one or all of the problems mentioned above.
In one aspect, the invention includes an automated, computer-implemented method for managing test wafers in an integrated, automated semiconductor manufacturing environment, the method comprising: managing a test wafer inventory; consuming inventoried test wafers in the automated process flow; and distributing the consumed test wafers according to their level of usage after an evaluation thereof.
In another aspect, the invention includes an automated, computer-implemented method for use in semiconductor manufacturing, comprising: monitoring test wafer utilization in an automated process flow; maintaining an inventory of test wafers of a plurality of different types responsive to the monitored utilization; and managing the test wafer utilization of the test wafer inventory.
In yet another aspect, the invention includes an automated, computer-implemented method for use in semiconductor manufacturing, comprising: kitting a lot of test wafers; instantiating a software-implemented test lot scheduling agent for the kitted lot, the agent being capable of: scheduling a build for the kitted lot; or scheduling the kitted lot as a resource for consumption in an automated process flow.
In still other aspects, the invention includes integrated, automated semiconductor manufacturing environments in which a computing system is capable of performing those methods and program storage media encoded with instructions that, when executed by a computing device, perform those methods.
The invention may be understood by reference to the following description taken in conjunction with the accompanying drawings, in which like reference numerals identify like elements, and in which:
Illustrative embodiments of the invention are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort, even if complex and time-consuming, would be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.
The portion 100 also includes a computing apparatus 120 on which resides, inter alia, a test wafer controller 125.
In the illustrated embodiment, the computing apparatus 120, like the computing apparatus 110, is a workstation. The computing apparatus 120 employs a UNIX-based operating system (“OS”) 200, but the invention is not so limited. The computing apparatus 120 may be implemented in virtually any type of electronic computing device such as an embedded processor, a notebook computer, a desktop computer, a mini-computer, a mainframe computer, or a supercomputer. The invention also is not limited to UNIX-based operating systems. Alternative operating systems (e.g., Windows™-based or disk operating system (“DOS”)-based) may also be employed. The invention is not limited by the particular implementation of the computing apparatus 120.
The computing apparatus 120 also includes a processor 205 communicating with storage 210 over a bus system 215. The storage 210 typically includes at least a hard disk (not shown) and random access memory (“RAM”) (also not shown). The computing apparatus 120 may also, in some embodiments, include removable storage such as an optical disk 230, or a floppy electromagnetic disk 235, or some other form, such as a magnetic tape (not shown) or a zip disk (not shown). The computing apparatus 120 includes a monitor 240, keyboard 245, and a mouse 250, which together, along with their associated user interface software 255 comprise a user interface 260. The user interface 260 in the illustrated embodiment is a graphical user interface (“GUI”), although this is not necessary to the practice of the invention.
Returning to
The computing system 135 may be, for example, a local area network (“LAN”), wide area network (“WAN”), system area network (“SAN”), intranet, or even a portion of the Internet. The computing system 135 employs a networked client/server architecture, but alternative embodiments may employ, e.g., a peer-to-peer architecture. Thus, in some alternative embodiments, the computing devices 110, 120 may communicate directly with one another.
The communications links 140 of the computing system 135 may be one or more of wireless, coaxial cable, optical fiber, or twisted wire pair links, for example. The computing system 135, in embodiments employing one, and the communications links 120 will be implementation specific and may be implemented in any suitable manner known to the art. The computing system 135 may employ any suitable communications protocol known to the art, e.g., Transmission Control Protocol/Internet Protocol (“TCP/IP”).
The fabrication tool 115 is shown preparing to operate on a lot 145 of test wafers 150 (only one indicated). The wafers 150 comprise a portion of an inventory 151 of test wafers 150, 152. The wafers 150 may be referred to as “active,” in that they are currently being utilized or de-kitted, e.g., from a lot 145. The wafers 152 (only one indicated) may be referred to as “dormant,” in that they reside in a repository 153 and are not being utilized. The inventory 151 includes different “types” of test wafers 150, 152, e.g., Type I, Type II, Type III, etc. as defined by the applicable qual procedures for the process flow 100. The design and construction of the different types of test wafers 150, 152 may be in accordance with conventional practice.
The lot 145 may include any number of wafers 150. Typically, the lot 145 will contain a plurality of wafers 150 of different types. For instance, in a simple example, the lot 145 may contain three Type I wafers 150, two Type II wafers 150, and two Type III wafers 150. As those in the art having the benefit of this disclosure will appreciate, the composition of the lot 145 will depend to some degree on the operation of the fabrication tool 115 and other similar factors such as the applicable qual procedure being run.
The test wafer controller 125 schedules the testing of the fabrication tool 115 in accordance with the method 300, shown in
The method 300, shown in
As was noted above, the inventory 151 includes both the dormant wafers 152 in the repository 153 and the active wafers 152 being utilized in the process flow 100. As is shown in
Returning to
The test wafer controller 125 then determines (at 523,
Once the test wafer controller 125 determines (at 523,
Once the lot 145 is established, the test wafer controller 125 processes (at 529,
Returning to
Returning to
Returning again to
The consumption (at 320,
Returning to
Note that, although the various functionalities are presented sequentially above, this is not necessarily the case. Many of the functionalities are, in fact, exercised concurrently. For instance, referring now to
Those skilled in the art having the benefit of this disclosure will appreciate that the present invention can be extrapolated across a fab or multiple process flows comprising multiple fabrication tools.
The process flow 600 also includes a station 605′ comprising a computing apparatus 610 and a meteorology tool 615′. The computing apparatus 610 of the station 605′ also comprises a portion of the computing system 635. The meteorology tool 615′ is used in the examining the test wafer 650 when it is processed to evaluate the operation of the fabrication tools 115. The meteorology tool 615′ may provide pre-processing and/or post-processing meteorology data to process controllers for the fabrication tools 615. Depending on the results of the evaluation, corrective action may be taken to adjust the operation of the fabrication tool 615.
The process flow 600 furthermore includes, in accordance with the present invention, a plurality of active and dormant test wafers 650, 602. The active test wafers 650 are grouped into lots 645. The dormant test wafers 652 are stored in a repository 653. The test wafers 650, 652 comprises a number of different types of test wafers, i.e., Type I, Type II, etc.
The process flow 600 also includes portions of an automated “Manufacturing Execution System” (“MES”) 637, an automated materials handling system (“AMHS”) 638, and other factory controls not otherwise shown. These factory controls integrate and help automate the process flow 600. The automated MES 637 enables a user 639 to view and manipulate, to a limited extent, the status of machines and tools, or “entities,” in a manufacturing environment, i.e., the process flow 600. In addition, the MES 637 permits dispatching and tracking of lots 645 or work-in-process to enable resources to be managed in the most efficient manner. The AMHS 638 “handles” the lots 645 and facilitates their transport from one station 605 to another, as well as other locations in the process flow 600. The AMHS 638 is, in the illustrated embodiment, what is known as a “unified AMHS”, although this is not necessary to the practice of the invention.
Both the MES 637 and the AMHS 638 include software components 641, 642, respectively. The MES 637 and the AMHS 638 operate and are used in conventional fashion. The software components 641, 642 are shown residing on separate computing apparatus 610. However, since the computing system 635 is a distributed system, the situs of all software elements, such as the software components 641, 642, is not material. Thus, the software components 641, 642 may reside elsewhere in the computing system 635 or even on the same computing apparatus.
The computing system 635 furthermore includes one or more data store(s) 670 that include a variety of information about the process flow 600 and, more generally, the fab. The data store(s) 670 include data defining the state of the fab, as well as metrics concerning its operation. The data store 670 is used to store a wide variety of information that may be used in the automated control of the factory, including:
The process flow 600 also includes a plurality of “notifiers” 681 (only one indicated) and “listeners” 682 (only one indicated) that track events occurring in the process flow 600. Notifiers 681 “publish” detected events to their subscribing listeners 682 when changes occur within the process flow 600. For instance, when a fabrication tool 615 finishes processing a lot 645 of test wafers 650, it will send a message 683 indicating that it has done so. A notifier 681 looking for this type of event, upon receiving the message 683, will publish that the event has occurred. The listeners 682 subscribe to notifiers 681 that publish the events they are interested, by virtue of their programming, in tracking. Thus, when the notifier 681 publishes that the fabrication tool 615 has finished processing the lot 645, it publishes that event to its subscribing listeners 682. The subscribing listeners 682 then report the event to other software components of the computing system 635 that have subscribes to the listeners 682 for that very purpose. Note that the use listeners 682 and notifiers 681 in this manner is known to the art, and any suitable technique may be employed.
The process flow 600 also includes a plurality of software-implemented agents, or “software agents” 665 (only one indicated) residing in the computing system 635. The software agents 665 each represent some “manufacturing domain entity,” e.g., a lot 645 or a fabrication tool 615. The software agents 665, schedule activities on behalf of and control the progress of the lots 645 of wafers 635 through the fabrication process. In furtherance of these objectives, the software agents 665 interface with the software components 641, 642 of the MES 637 and AMHS 638, and the fabrication tools 615. The manner in which this interface and integration occurs is implementation specific, depending upon the makeup and configuration of the MES 637, AMHS 638, and the other factory control systems.
In the illustrated embodiment, the process flow 600 implements an Advanced Process Control (“APC”) framework (not shown) in the computing system 635. In some embodiments, as in the embodiment illustrated in
This particular architecture relies heavily on software utilizing object oriented programming and employs the Object Management Group's (“OMG”) Common Object Request Broker Architecture (“CORBA”) and CORBA_Services specifications for distributed object systems. Information and specifications for the OMG CORBA architecture are also readily, publicly available. An exemplary software system capable of being adapted to perform the functions of the APC System as described herein is the Catalyst system commercially offered by KLA-Tencor, Inc. KLA-Tencor may be contacted at: 160 Rio Robles, San Jose, Calif. 95134, phone: 408-875-6000, fax: 408-875-3030, <http://www.kla-tencor.com>. Additional information regarding the Catalyst system is also available from KLA-Tencor on their website at <http://www.kla-tencor.com/controlsolutions/catalystapc.html>.
Deployment of the control strategy taught by the present invention onto the APC framework could require a number of software components, such as equipment interfaces (“EIs”) 672 and machine interfaces (“MIs”) 674. Each process tool (e.g., the fabrication tools 615, meteorology tool 615′) is generally connected to an EI 672. The EI 672 is connected to a MI 674 that facilitates communications between the manufacturing tool and the manufacturing framework. The machine interface can generally be part of the APC system. In addition to components within the APC framework, a computer script 676 is written for each of the process tools that is used to control the process operation of the manufacturing tool. The implementation of an APC system in this fashion and using various software components such as EIs 672 and MIs 673 is known in the art. Therefore, for the sake of clarity and so as not to obscure the present invention, such software components are omitted from the present discussion.
Still referring to
The functionality of the test wafer controller 125 in the process flow 100 of
More particularly, two scheduling software agents 665 negotiate with each other on behalf of the lot 645 and the fabrication tool 615 for an appointment in which the fabrication tool 615 will process the lot 645, whether as a part of consuming test wafers or as fabricating test wafers. Many techniques for scheduling appointments are known to the art, and any such technique may be employed. In one particular embodiment, however, appointments are scheduled using a contract net negotiation protocol in a floating market model approach. In the floating market model of the contract net negotiation protocol, the scheduling of actions initiated by the software agents 665 revolve around budgets, costs, and ratios associated with the processing in a contract net negotiation protocol. To further the implementation of a contract net negotiation protocol for allocating resources, a combination of budgets, costs, and ratios are used to implement a floating market model approach.
The combination of budgets, costs, and ratios is structured to encourage “desirable” behavior, e.g., meeting due dates, effective utilization of machines, etc. More particularly, a “budget” is assigned to the lot 645 that a software agent 665 uses to procure the process services. Similarly, the fabrication tool 615, charges consumers for the processing services it represents, e.g., processing time. The amount of the budget the lot 645 is willing to pay depends on how badly it needs to stay on schedule and the amount charged by the fabrication tool 615 depends on how badly it needs to fill its schedule. The lot 645 acquires services more or less aggressively depending on selected factors, such as priority or lateness. Process tools 615 provide such services more or less aggressively depending on a number of factors, such as the level of congestion in their calendars. Working in concert, the software agents 665 for consumers and providers of process services cooperate to advance the lots 645 through the process flow 600 in a timely and efficient manner.
Each software agent 665 that schedules on behalf of some entity in the process flow 600 maintains a calendar of appointments in the illustrated embodiment. For instance, the LSA 705 keeps a calendar 785 and the MSA 710 keeps a calendar 770. The type of appointments scheduled on any given calendar will depend largely on the nature of the entity that the software agent 665 that is keeping the calendar represents. Thus, the LSA 705 will keep the calendar 785 and store therein not only processing appointments for its respective lot 645, but also move appointments the lost 645 needs to meet is processing appointments.
More particularly, the LSA 705 is responsible for scheduling current and future tasks on behalf of a specified lot 645 in the process flow 600. These tasks include manufacturing processing and material handling required to transform the lot 645 from raw silicon into a specified semiconductor product. A LSA 705 utilizes a calendar 785 to track scheduled tasks. The calendar 785 contains an ordered collection of appointments, e.g., the appointment 775, that represent active and future tasks scheduled by the LSA 705 that will provide the processing service required by the task. The types of appointments scheduled by the LSA 705 and a brief description thereof are summarized in Table 1. While these various appointment types contain different attributes, there are some attributes in common, including a scheduled start time, a scheduled end time, an estimated duration for how long the task will take and an appointment state.
The MSA 710 also keeps a calendar 770 of appointments, e.g., the appointment 776, representing commitments of the fabrication tool 615 to provide process services-namely, processing time. The types of appointments scheduled by the MSA 710 on the calendar 770 are set forth in Table 2. Note that the lot processing appointment 776 scheduled by the MSA 710 on the calendar 770 corresponds to the processing appointment 775 scheduled by the LSA 705 on the calendar 785.
In the illustrated embodiment, the LSA 705 begins negotiating in a general scheduling session by publishing a bid request 725 to the MSA 710. The MSA 710 for each qualified fabrication tool 615 submits one or more bids 760 to the LSA 705 to process the lot 645. The LSA 705 accepts one of the bids 760. The LSA 705 then confirms the selected bid 760 with a message 765 to the MSA 710. The MSA 710 validates the selected bid 760 with its calendar 770, i.e., ensures that the selected bid 760 can still be implemented. The MSA 710 sees that the slot for the selected bid 760 is still clear, schedules the appointment 775, and sends a bid confirmed message 780 to the LSA 705. The LSA 705 then schedules the appointment 775 on its own calendar 785. When the start time for the scheduled processing appointment arrives, the scheduling agents 705, 710 pass control to respective processing agents (not shown). When one appointment completes, the LSA 705 and MSA 710 start their next appointment if it is time to do so. If it is not time, the LSA 705, MSA 710 set an alarm 797 and wait for the alarm 797 to fire, thereby indicating time to start the next appointment.
Thus, processing appointments, e.g., the processing appointments 775, 776 are booked on calendars, e.g., the calendars 785, 770, maintained by each scheduling agent, e.g., the scheduling agents 705, 710. Whenever the processing appointment 775 is booked, the LSA 705 schedules move appointments for moving the lots 645 to the location of the fabrication tool 615 associated with the newly booked processing appointment 775. As will be appreciated by those skilled in the art having the benefit of this disclosure, the process flow 600 will include a number of handling components, none of which are shown, such as stockers, wafer sorters, under-track storage, and work in progress (“WIP”) racks. The LSA 705 calls a “helper class object” called a move appointment scheduler (“MAS”, not shown) to schedule move appointments. The MAS determines the appropriate material transports required in order for the lot 645 to meet a confirmed processing appointment 775, including the utilization of handling components. Note that the handling components may have their own scheduling agents for this purpose.
The scheduling techniques illustrated in
The information management inherent in the functionality of the test wafer controller 125 is also distributed in the process flow 600 of
For example, the management of the test wafer inventory 651 (at 310,
Thus, as is more generally illustrated in
The number of uses for a given test wafer 650, 652 is also maintained as an attribute of the test wafer 650, 652 or in the metrics store 670b. Through the store 670a, the TWSA 665a knows or can ascertain which test wafers are in the process flow 600 (as opposed to the repository 653). Since, in this particular embodiment, the distribution will be a function of the number of as described above, the TWSA 665a can therefore predict the distribution of the consumed test wafers 652 by type.
The TWSA 665a therefore monitors (at 410,
Test wafer inventory management (at 310,
The TWSA 665a can identify the test wafer type whose level has dropped below the predetermined threshold by periodically checking inventory levels against the predetermined threshold. Both of these values may be, for instance, kept in and retrieved from the metrics store 670b. As those in the art having the benefit of this disclosure will appreciate, each type of test wafer 650, 652 may be built uniquely relative to the other types. Thus, the build route, or series of operations, for that particular type is retrieved from, for instance a data store 670c containing such information regarding the infrastructure and operation of the system. The TWSA 665a then establishes a lot 645 of wafers 650 (only one indicated), typically dormant wafers 652 or blanks 654 (only one indicated). The wafers 650 will typically be of another type that have been designated for this purpose as was described above. This information may also be stored in, for example, the store 670c.
As a further example, the functionality of the test wafer controller 125, shown in
However, the test wafers 650, 652—and the lots 645 they comprise—are fundamentally different in that they can behave as both consumers and providers in the process flow 600 depending on their state. Test wafers 650, 652 behave as consumers in the phase of their existence in which they are being built because they are consuming the processing time of fabrication tools 615. Test wafers 650, 652 also behave as providers when they are being used to qualify fabrication tools 615. Conventional scheduling agents that act only in a “provider” or “consumer” mode therefore are not suitable for scheduling lots 645 of test wafers 650, 652.
The present invention therefore, in some embodiments, distributes the scheduling functionality of the test wafer controller 125 for test wafers 650, 652 over a plurality of test lot scheduling agents (“TLSA”) 686. Each time a lot 645 of test wafers 650, 652 is kitted as described above, a TLSA 686 is instantiated in the same manner as other software implemented agents. The state and goal of the kitted lot 645 can be ascertained by the instantiated TLSA 686 from the data stores 670.
If the lot 645 is being kitted for the build of additional test wafers, the TLSA 686 can ascertain this from the data stores 670 and begin scheduling processing activities with fabrication tools 615 from a consumer's perspective. Once the test wafers 650, 652 are built, they are either returned to the inventory 651 or placed into the process flow 600 for utilization as a resource. If they are returned to inventory, the TLSA 868 is destroyed when the lot 645 is de-kitted.
When a lot 645 of test wafers 650, 652 goes into the process flow 600 as a resource for testing fabrication tools 615, the TLSA 686 begins scheduling from a provider's perspective. The lot 645 may have entered the process flow directly from the build process as alluded to above, in which case the TLSA 686 has already been instantiated. When the roll of the lot 645 changes from consumer to provider, so to do the scheduling activities performed by the TLSA 686. That is, the TLSA 686 shifts roles from consumer scheduling to provider scheduling. If the lot 645 is kitted from the inventory 651 for this purpose, a new TLSA 686 is instantiated to represent it. In either scenario, the TLSA 686 is destroyed whenever the lot 645 is de-kitted.
Note that, in some embodiments, the dual functionality of the TLSA 686 in terms of representing both a consumer and a provider may be broken down into two separate scheduling agents. Thus, a test lot 645 may have one type of TLSA when slated for a build and a second type of TLSA when slated for use in a qual or a PM. Still further specialization may be used as well. For example, a test lot slated for a build might be assigned a scheduling agent whose nature will depend on whether it is slated for a Type I build, a Type II build, etc. Still further, a test lot slated for consumption in a qual might be assigned a scheduling agent different from the scheduling agent it might be assigned for consumption in a PM. Other kinds of specialization may become apparent to those skilled in the art having the benefit of this disclosure.
The TLSA 686 in the illustrated embodiment also executes other functionalities of the test wafer controller 125, shown in
An additional functionality inheres from the operation of the TLSAs 686 and the test wafer controller 125 in that the scheduling of PM and qual activities will comprehend wafer resource availability. If there is a shortage of the appropriate type of test wafers 650, 652 for a given PM or qual, then the costs for scheduling this activity will rise accordingly. PM and Qual activities will therefore self-order in terms of which are more immediately needed on the basis of willingness to pay higher costs. Conversely, if there is a glut of test wafers 650, 652, then the costs for PM and Qual activities will decrease and these activities will be conducted more readily.
Thus, the present invention can be extrapolated across an entire fabrication facility. The extrapolation of the invention across the process flow 600 in
As mentioned above, in the illustrated embodiment, the invention is implemented using object oriented programming (“OOP”) techniques, although the invention may be implemented using techniques that are not object oriented. The software agents 665 are implemented as objects and are intelligent, state aware, and are imbued with specific goals for which they autonomously initiate behaviors to achieve. Their behavior is relatively simple and is partially configurable through scripts and properties. The behavior is designed to achieve selected goals such as achieving an assigned lot due date, achieving a predefined level of quality, maximizing machine utilization, and scheduling opportunistic preventive maintenance. The helper class is a class of objects to which various objects that are software agents 665 delegate various responsibilities or that provide some useful service in the process flow 600.
Some portions of the detailed descriptions herein are consequently presented in terms of a software implemented process involving symbolic representations of operations on data bits within a memory in a computing system or a computing device. These descriptions and representations are the means used by those in the art to most effectively convey the substance of their work to others skilled in the art. The process and operation require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated or otherwise as may be apparent, throughout the present disclosure, these descriptions refer to the action and processes of an electronic device, that manipulates and transforms data represented as physical (electronic, magnetic, or optical) quantities within some electronic device's storage into other data similarly represented as physical quantities within the storage, or in transmission or display devices. Exemplary of the terms denoting such a description are, without limitation, the terms “processing,” “computing,” “calculating,” “determining,” “displaying,” and the like.
Note also that the software implemented aspects of the invention are typically encoded on some form of program storage medium or implemented over some type of transmission medium. The program storage medium may be magnetic (e.g., a floppy disk or a hard drive) or optical (e.g., a compact disk read only memory, or “CD ROM”), and may be read only or random access. Similarly, the transmission medium may be twisted wire pairs, coaxial cable, optical fiber, or some other suitable transmission medium known to the art. The invention is not limited by these aspects of any given implementation.
This concludes the detailed description. The particular embodiments disclosed above are illustrative only, as the invention may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the invention. Accordingly, the protection sought herein is as set forth in the claims below.