text:
A method and apparatus for scheduling ahead in a process flow for a manufacturing domain entity are disclosed. The method includes detecting an occurrence of a triggering event defined for a current process operation on the manufacturing domain entity; and scheduling the target process operation upon expiration of a timed offset from the detection of the triggering event responsive to the detection thereof, the timed offset being defined for the target process operation scheduling. In various aspects, the apparatus includes a program storage medium encoded with instructions that, when executed by a computing device, perform such a method and a computer programmed to perform such a method. In still other aspects, the apparatus includes a process flow implementing such a method.
1. A method of scheduling ahead in a process flow for a manufacturing domain entity, comprising:
detecting an occurrence of a triggering event defined for a current process operation on the manufacturing domain entity; and
scheduling a target process operation upon expiration of a timed offset from the detection of the triggering event responsive to the detection thereof, the timed offset being defined for the target process operation scheduling.
2. The method of
3. The method of
detecting an event; and
determining whether the detected event is the triggering event.
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
9. The method of
10. The method of
11. The method of
12. The method of
13. The method of
14. The method of
15. The method of
detecting an occurrence of a second triggering event defined for the current process operation; and
scheduling a second target process operation upon expiration of the second timed offset from the detection of the second triggering event responsive to the detection of the second triggering event.
16. The method of
17. The method of
18. The method of
19. The method of
20. The method of 18, further comprising detecting a plurality of triggering events occurring prior to initialization.
21. The method of
22. The method of
23. A computing system, comprising:
a computing device;
a bus system; and
a storage communicating with the computing device over the bus system, the storage being encoded with instructions that, when executed by the computing device, performs a method for scheduling ahead in a process flow for a manufacturing domain entity, the method including:
detecting an occurrence of a triggering event defined for a current process operation on the manufacturing domain entity; and
scheduling a target process operation upon expiration of a timed offset from the detection of the triggering event responsive to the detection thereof, the timed offset being defined for the target process operation scheduling.
24. The computing system of
25. The computing system of
26. The computing system of
27. The computing system of
28. A program storage medium encoded with instructions that, when executed, perform a method of scheduling ahead in a process flow for a manufacturing domain entity, the method comprising:
detecting an occurrence of a triggering event defined for a current process operation on the manufacturing domain entity; and
scheduling a target process operation upon expiration of a timed offset from the detection of the triggering event responsive to the detection thereof, the timed offset being defined for the target process operation scheduling.
29. The program storage medium of
30. The program storage medium of
31. The program storage medium of
32. The program storage medium of
33. The program storage medium of
34. An automated processing environment, comprising:
a process flow capable of performing a plurality of process operations;
a plurality of manufacturing domain entities, a first subset of which perform the process operations on a second subset thereof, and
a computing system, including:
at least one of a management execution system and an automated material handling system for automating the process flow; and
a plurality of software components capable of scheduling ahead in the process flow for a respective one of the second subset of manufacturing domain entities, the method comprising:
detecting an occurrence of a triggering event defined for a current process operation on the manufacturing domain entity; and
scheduling a target process operation upon expiration of a timed offset from the detection of the triggering event responsive to the detection thereof, the timed offset being defined for the target process operation scheduling.
35. The method of
36. The method of
37. The method of
38. A method of scheduling ahead in a process flow for a manufacturing domain entity, comprising:
for each of a plurality of target process operations to a current process operation, defining a respective triggering event and a respective timed offset for scheduling the respective target process operation;
detecting at least one of the triggering events; and
scheduling a respective target process operation for the detected triggering event on expiration of the timed offset from the detection responsive thereto.
39. The method of
40. The method of
41. The method of
detecting a second triggering event; and
scheduling a second target process operation on expiration of the second timed offset from the detection of the second triggering event responsive to the detection of the second triggering event.
42. The method of
43. A computing apparatus, comprising
a computing device;
a bus system; and
a storage communicating with the computing device over the bus system, the storage being encoded with instructions that, when executed by the computing device, performs a method for scheduling ahead in a process flow for a manufacturing domain entity, the method including:
for each of a plurality of target process operations to a current process operation, defining a respective triggering event and a respective timed offset for scheduling the respective target process operation;
detecting at least one of the triggering events; and
scheduling a respective target process operation for the detected triggering event on expiration of the timed offset from the detection responsive thereto.
44. The computing apparatus of
45. The computing apparatus of
46. The computing apparatus of
detecting a second triggering event; and
scheduling a second target process operation on expiration of the second timed offset from the detection of the second triggering event responsive to the detection of the second triggering event.
47. The computing apparatus of
48. A program storage medium encoded with instructions that, when executed by a computing device, perform a method of scheduling ahead in a process flow for a manufacturing domain entity, the method comprising:
for each of a plurality of target process operations to a current process operation, defining a respective triggering event and a respective timed offset for scheduling the respective target process operation;
detecting at least one of the triggering events; and
scheduling a respective target process operation for the detected triggering event on expiration of the timed offset from the detection responsive thereto.
49. The program storage medium of
50. The program storage medium of
51. The program storage medium of
detecting a second triggering event; and
scheduling a second target process operation on expiration of the second timed offset from the detection of the second triggering event responsive to the detection of the second triggering event.
52. The program storage medium of
53. An automated processing environment, comprising:
a process flow capable of performing a plurality of process operations;
a plurality of manufacturing domain entities, a first subset of which perform the process operations on a second subset thereof, and
a computing system, including:
at least one of a management execution system and an automated material handling system for automating the process flow; and
a plurality of software components capable of scheduling ahead in the process flow for a respective one of the second subset of manufacturing domain entities, the method comprising:
for each of a plurality of target process operations to a current process operation, defining a respective triggering event and a respective timed offset for scheduling the respective target process operation;
detecting at least one of the triggering events; and
scheduling a respective target process operation for the detected triggering event on expiration of the timed offset from the detection responsive thereto.
54. The method of
55. The method of
56. The method of
detecting a second triggering event; and
scheduling a second target process operation on expiration of the second timed offset from the detection of the second triggering event responsive to the detection of the second triggering event.
57. The method of
1. Field of the Invention
This invention pertains to automated manufacturing environments, and, more particularly, to scheduling in an automated manufacturing environment employing agent-based scheduling and factory control.
2. Description of the Related Art
Growing technological requirements and the worldwide acceptance of sophisticated electronic devices have created an unprecedented demand for large-scale, complex, integrated circuits. Competition in the semiconductor industry requires that products be designed, manufactured, and marketed in the most efficient manner possible. This requires improvements in fabrication technology to keep pace with the rapid improvements in the electronics industry. Meeting these demands spawns many technological advances in materials and processing equipment and significantly increases the number of integrated circuit designs. These improvements also require effective utilization of computing resources and other highly sophisticated equipment to aid, not only design and fabrication, but also the scheduling, control, and automation of the manufacturing process.
Turning first to fabrication, integrated circuits, or microchips, are manufactured from modern semiconductor devices containing numerous structures or features, typically the size of a few micrometers. The fabrication process generally involves processing a number of wafers through a series of fabrication tools. Layers of materials are added to, removed from, and/or treated on a semiconducting substrate during fabrication to create the integrated circuits. The fabrication essentially comprises the following four basic operations: layering, or adding thin layers of various materials to a wafer from which a semiconductor is produced; patterning, or removing selected portions of added layers; doping, or placing specific amounts of dopants in selected portions of the wafer through openings in the added layers; and heat treating, or heating and cooling the materials to produce desired effects in the processed wafer.
Although there are only four basic operations, they can be combined in hundreds of different ways, depending upon the particular fabrication process. See, e.g., Peter Van Zant, Microchip Fabrication A Practical Guide to Semiconductor Processing (3d Ed. 1997 McGraw-Hill Companies, Inc.) (ISBN 0-07-067250-4). Each fabrication tool performs one or more of four basic operations. The four basic operations are performed in accordance with an overall process to finally produce the finished semiconductor devices.
Controlling a semiconductor factory fabricating such integrated circuits, however, is a challenging task. A semiconductor factory ("fab") is a complex environment where numerous parts, typically 40,000 wafers or more, and numerous part types, typically 100 part types or more, are simultaneously being manufactured. As each wafer moves through the semiconductor factory (or, "fab"), it may undergo more than 300 processing steps, many of which use the same machines. A large factory may contain approximately 500 computer-controlled machines to perform this wafer processing. Routing, scheduling, and tracking material through the fab is a difficult and complicated task, even with the assistance of a computerized factory control system.
Efficient management of a facility for manufacturing products such as semiconductor chips requires monitoring various aspects of the manufacturing process. For example, it is typically desirable to track the amount of raw materials on hand, the status of work-in-process ("WIP") and the status and availability of machines and tools at every step in the process. One of the most important decisions is selecting which lot should run on each machine at any given time. Additionally, most machines used in the manufacturing process require scheduling of routine preventative maintenance ("PM") and equipment qualification ("Qual") procedures, as well as other diagnostic and reconditioning procedures that must be performed on a regular basis. These procedures should be performed such that they do not impede the manufacturing process itself.
One approach to this issue implements an automated "Manufacturing Execution System" ("MES"). An automated MES enables a user to view and manipulate, to a limited extent, the status of machines and tools, or "entities," in a manufacturing environment. In addition, an MES permits dispatching and tracking of lots or work-in-process through the manufacturing process to enable resources to be managed in the most efficient manner. Specifically, in response to MES prompts, a user inputs requested information regarding work-in-process and entity status. For example, when a user performs a PM on a particular entity, the operator logs the performance of the PM (an "event") into an MES screen to update the information stored in the MES database with respect to the status of that entity. Alternatively, if an entity is to be put down for repair or maintenance, the operator will log this information into the MES database, which then prevents use of the entity until it is subsequently logged back up to a production ready state. Exemplary MESes include WORKSTREAM™, a product of Applied Materials, Inc., or SiView™, a product of International Business Machines, Inc. ("IBM").
Although MES systems are sufficient for tracking lots and machines, such systems suffer several deficiencies, the most obvious of which are their passive nature, lack of advance scheduling and inability to support highly automated factory operations. Current MES systems largely depend on manufacturing personnel for monitoring factory state and initiating activities at the correct time. For example, a lot does not begin processing until a wafer fab technician ("WFT") issues the appropriate MES command. And, prior to processing, a WFT must issue an MES command to retrieve the lot from the automated material handling system ("AMHS") with sufficient advance planning that the lot is available at the machine when the machine becomes available. If the WFT does not retrieve the lot soon enough, or neglects to initiate processing at the earliest available time, the machine becomes idle and production is adversely impacted.
These types of deficiencies in the typical automated MES emphasize the importance of the WFT in the efficient operation of the manufacturing process. WFTs perform many vital functions. For instance, WFTs initiate dispatching, transport, and processing as their attention and time permits. They make scheduling decisions such as whether to run an incomplete batch, as opposed to waiting for additional approaching lots, or performing PM or qualification procedures instead of processing lots. WFTs perform non-value added MES transactions and utilize conventional factory control systems that are passive. In this context, the term "passive" means activities in the control system must be initiated by the WFT, as opposed to being self-starting or self-initiating.
However, the presence of WFTs also inevitably introduces some inefficiencies. There typically is a large difference between the performance of the best WFT and the performance of the worst WFT. A WFT typically simultaneously monitors the processing of multiple tools and lots, making it difficult to focus on an individual lot or tool. Furthermore, the size and complexity of the modern fabrication process flows makes it exceedingly difficult for a WFT to foresee and prevent downstream bottlenecks or shortages arising from upstream activities. Shift changes, rest breaks, and days off for the WFT also create inefficiency or machine idle time that adversely impact the manufacturing process flow. Just as the importance of the WFT is magnified by the deficiencies of the automated MES, so are the inefficiencies of the WFT magnified by his importance.
Thus, factory control systems utilized in today's wafer fabs are passive and do not enable a high degree of automation. These systems are very dependent on WFTs and other factory staff to monitor the state of the factory, to continuously react to change, to make rapid logistical decisions, and to initiate and coordinate factory control activity in a timely manner. These WFTs are agents, providing the active element that is lacking in factory control systems. As a result, factory effectiveness in the highly competitive semiconductor industry is quite dependent on the availability, productivity, skill level, and consistency of these human agents. WFTs must monitor and operate a number of tools located in various bays in a fab. They are forced to multiplex across tools, bays, material handling systems and a variety of factory control systems. As a fab's production ramps and more complex processes are introduced, it becomes more difficult to meet the increased complexity and volume without increasing staff or system capabilities. WFTs visibility of upstream and downstream operations, tool state, work-in-process, and resource availability is limited.
However, key logistical decisions are frequently based on this limited and dated information, which is only partially provided by factory control systems. WFTs spend a significant amount of time interacting with systems, monitoring factory events and state changes, and performing other non-value added functions, such as MES logging. Shift changes disrupt the operation of the fab as the technicians are temporarily unable to provide required monitoring and coordination. Despite the best efforts of the technicians, utilization of tools suffers, adversely impacting other key factory metrics including cycle time, inventory levels, factory output and mix. With the need for intrabay material handling to transport 12-inch wafers in new 300 mm wafer fabs, significant additional complexity is introduced. Conventional factory control systems are not capable of providing this level of detailed scheduling and execution control.
The present invention is directed to resolving, or at least reducing, one or all of the problems mentioned above.
The invention includes, in its various embodiments and aspects, a method and apparatus for scheduling ahead in a process flow for a manufacturing domain entity. The method comprises detecting an occurrence of a triggering event defined for a current process operation on the manufacturing domain entity; and scheduling the target process operation upon expiration of a timed offset from the detection of the triggering event responsive to the detection thereof, the timed offset being defined for the target process operation scheduling. In various aspects, the invention includes a program storage medium encoded with instructions that, when executed by a computing device, perform such a method and a computer programmed to perform such a method. In still other aspects, the invention includes a process flow implementing such a method.
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:
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the description herein of specific embodiments is not intended to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
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 illustrated portion of the process flow 100 includes a plurality of processing stations 105 0-105 x, each station 105 0-105 x including a respective computing device 110 0-110 x communicating with a respective process tool 115 0-115 x. The processing stations 105 0-105 x communicate with one another over communications links 120. In the illustrated embodiment, the computing devices device 110 0-110 x and the communications links 120 comprise a portion of a larger computing system 125. The process tools 115 0-115 x are shown in
In general, each of the process tools 115 performs some process operation on the lots 130. The process operation will be implementation specific, depending on the process flow and the end product of the manufacturing process. In the illustrated embodiment, for example, individual process stations 115 might layer, pattern, dope, or heat treat the wafers 135 of the lots 130, or some combination of these things. Or, the process stations 115 might perform some evaluation of the process operations performed by other process stations 115. Either way, the process flow 100 comprises the process operations performed by the process stations 115 on the lots 130.
Each lot 130 proceeds through the process flow 100 as part of its manufacture. Consider the lot 130 0, which must undergo the current process operation on the process tool 115 0, and the immediately successive process operation on the process tool 115 1, and other process operations on other successive process tools (e.g., the process tool 115 x). The process flow 100 is under software-implemented control, discussed more fully below, that generally "schedules ahead" of the present process operation in the illustrated embodiment. More particularly, the control software schedules "appointments" on behalf of, for example, lots 130 and process tools 115 for the process tools 115 to perform process operations on the lots 130. The control software typically attempts to schedule these appointments in advance of completing the current process operation, although sometimes exceptions do occur.
In accordance with the present invention, and as illustrated in
Referring now to
The actual determination of the triggering event and the offset will be implementation specific. Typically, what will be a triggering event and the associated offset for any given process operation will be made a prior, and is based on a number of factors. Since the determination is made a priori, it is typically separate from the operation of the process flow 100. However, some embodiments may determine the triggering events dynamically, e.g., responsive to factory metrics, and so the determination may be a part of the operation of the process flow 100 in these embodiments.
For instance, assume the process tool 115 1 has a very high utilization such that it will be difficult for the lot 130 0 to schedule an appointment for its services. In that case, it will be desirable to begin scheduling that appointment very early and the triggering event could be the start of the current process operation and the timed offset could be very small. Now, assume that the process tool 115 1 has a very low utilization such that it will be very easy to schedule the appointment. It may be advantageous to wait until well into the current process operation to begin scheduling the target process operation. The triggering event may still be the start of the current processing operation, but the timed offset will be relatively longer. Or, the triggering event may be some point when the current process operation is nearing completion coupled with a relatively shorter timed offset. In the default case of the illustrated embodiment, transition of the current process operation into a state of "near complete" triggers the scheduling of the next successive process operation as the target with a zero time offset.
In the preceding example, the triggering event is implicitly defined as some state of the current process operation. However, the invention is not so limited. Alternative embodiments may employ different kinds of triggering events in addition to or in lieu of the state of the current process operation. Equipment events and factory state events, for example, may also be defined as triggering events in alternative embodiments.
In the illustrated embodiment, a given target process operation will have only one triggering event for the current process operation. This constraint is imposed as a convenient mechanism to help limit the computational burden by restricting the number of times that a given appointment will be scheduled. However, other mechanisms may be employed. For instance, an entry may be made in a look-up table when an appointment is scheduled such that, if a second trigger occurs, the look-up table can be consulted to determine if the appointment has already been scheduled. Thus, in alternative embodiments, the scheduling of a given target process operation might be prompted by more than one triggering event.
The illustrated embodiment also only employs the case where a single target process operation is triggered by a single triggering event. However, the invention is not so limited. Alternative embodiments may schedule multiple target process operations responsive to a single triggering event. For example, when a current process operation transitions into a "near complete" state, scheduling for two different target process operations might be triggered. A given current process operation may also give rise to multiple triggering events, each associated with one or multiple target process operations. Alternative embodiments may also employ combinations of these variations, as well as variations on these lines not expressly set forth herein.
Referring again to both
The method 200 then schedules (at 209, in
The discussion above discloses the method 200, shown in
Furthermore, the target process operations also need not be scheduled in the order in which they will be executed. Still referring to
Accordingly, the lot 130 0 might wish to begin scheduling an appointment on the process tool 115 x well before it begins scheduling for an appointment on the process tool 115 1. The flexibility in defining triggering events and timed offsets (at 203, in
The method 200, shown in
Referring again to
The process flow 100 may also employ the services of various resources 140, which is a reticle in the illustrated embodiment. For instance, a process tool 115 that is a stepper may employ a reticle that may be shared among several steppers. For a stepper to timely perform its process operation(s), the reticle has to be present in a timely fashion. Thus, the method 200 in
Some of the manufacturing domain entities, e.g., the lots 130, are "consumers," i.e., they consume process services. Some of these manufacturing domain entities are "providers," i.e., they provide process services to be consumed. For instance, a process tool 115 represents a resource that may be consumed, e.g., process time, in the process flow 100. A process tool 115 may be a fabrication tool used to fabricate some portion of the wafers 135, i.e., layer, pattern, dope, or heat treat the wafers 135. Or, the process tool 115 may be a metrology tool used to evaluate the performance of various parts of the process flow 100. Note some manufacturing domain entities may sometimes be classed as a provider in one context and a consumer in another context, depending on their role in the process flow 100 at any given time.
Still referring to
Note that some portions of the detailed descriptions herein are 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.
In the illustrated embodiment, the computing device 110 is a workstation, employing a UNIX-based operating system 300, although the invention is not so limited. The computing device 110 may be implemented in virtually any type of electronic computing device such as a notebook computer, a desktop computer, a mini-computer, a mainframe computer, or a supercomputer. The computing device 110 may even be, in some alternative embodiments, a processor or controller embedded in the process tool 115. 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 these aspects of any particular implementation of the computing device 110.
The computing device 110 also includes a processor 305 communicating with storage 310 over a bus system 315. The storage 310 typically includes at least a hard disk (not shown) and random access memory ("RAM") (also not shown). The computing device 110 may also, in some embodiments, include removable storage such as an optical disk 330, or a floppy electromagnetic disk 335, or some other form, such as a magnetic tape (not shown) or a zip disk (not shown). The computing device 110 includes a monitor 340, keyboard 345, and a mouse 350, which together, along with their associated user interface software 355 comprise a user interface 360. The user interface 360 in the illustrated embodiment is a graphical user interface ("GUI"), although this is not necessary to the practice of the invention.
The processor 305 may be any suitable processor known to the art. For instance, the processor may be a general purpose microprocessor or a digital signal processor ("DSP"). In the illustrated embodiment, the processor 305 is an Athlon™ 64-bit processor commercially available from Advanced Micro Devices, Inc. ("AMD"), but the invention is not so limited. The 64-bit UltraSPARC™ or the 32-bit microSPARC™ from Sun Microsystems, any of the Itanium™ or Pentium™-class processors from Intel Corporation, and the Alpha™ processor from Compaq Computer Corporation might alternatively be employed.
Each computing device 110 may include, in the illustrated embodiment, a software agent 365 residing in the storage 310. Note that the software agents 365 may reside in the process flow 100 in places other than the computing devices 110. The situs of the software agent 365 is not material to the practice of the invention. Note also that, since the situs of the software agents 365 is not material, some computing devices 110 may have multiple software agents 365 residing thereon while other computing devices 110 may not have any. At least a portion of an automated MES 370 resides on at least one computing device 110.
Referring now to both
In the illustrated embodiment, the software agents 365 are intelligent, state aware, and imbued with specific goals for which they autonomously initiate behaviors to achieve. The software agents 365 are implemented as objects in an object oriented programming ("OOP") environment, but the invention may be implemented using techniques that are not object oriented. Their behavior is relatively simple and is influenced by scripts, rules and external 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. In furtherance of these objectives, the software agents 365 interface with the MES 370 and are integrated with other existing factory control systems (not shown). As will be apparent to those skilled in the art having the benefit of this disclosure, the manner in which this interface and integration occurs is implementation specific, depending upon the makeup and configuration of the MES 370 and the factory control systems.
Collectively, the software agents 365 schedule ahead for each lot 130 one or more operations on a specific qualified process tool 115, including transports and resources, as discussed further below. This scheduling includes, at times, the method 200 shown in
The scheduling decisions in this particular embodiment are made by the software agents 365 based on a "contract net negotiation protocol." Note, however, that other scheduling approaches might be implemented in conjunction with the present invention. To further the implementation of the contract net negotiation protocol, an appointment commitment window concept is used to implement a floating appointment model approach. Each scheduling agent 365 maintains a "calendar" on which it books appointments for the respective manufacturing domain entity, e.g., process tool 115, lot 130, PM, Qual, or resource. The appointments scheduled through the scheduling decisions of the software agents 365 are "booked" on both the consumer and the provider's calendars. The appointment is booked for a duration in which it is expected the scheduled task will be accomplished.
Thus, in this particular embodiment, the process flow 400 includes, in addition to the lots 130, process tools 115, PM/Qual 137, and resource 140:
Each of the scheduling agents 405, 410, 415, and 418, maintains and uses a respective calendar 485, 470, 445, and 487. The illustrated embodiment also specializes the calendars that are used for scheduling and managing appointments, as is discussed more fully below. Note, however, that this, too, is not required for the practice of the invention. Nevertheless:
Some PMs invoke the performance of follow-up Quals before the process tool 115 can be reintroduced to the process flow 100. These are called "follow-up Quals". Other Quals, however, are "stand-alone" Quals, i.e. they are not invoked by the occurrence of a PM. Follow-up Quals, as opposed to stand-alone Quals, should be performed after the PM that invokes them before any other kind of appointment. The illustrated embodiment therefore treats follow-up Quals as part of the PM that invoices them. Follow-up Quals are automatically scheduled to be performed upon completion of the PM that invoked them. The follow-up Quals are not represented by separate appointments on the machine and PM calendars 470, 487 and the duration of the scheduled PM appointments is sufficient not only for the PM, but also any follow-ups Qual it invokes. Thus, Qual appointments are scheduled on the machine and PM calendars only for stand-alone Quals.
The LSA 405 tries to keep the lot 130 it represents on schedule. The MSA 410 tries to maximize utilization of the process tool 115 it represents. Similarly, the RSA 415 tries to maximize utilization of the resource 140. The PMSA 418 opportunistically schedules PMs and Quals on, inter alia, the process tool 115. The various agents 405, 410, 415, and 418 do this concurrently in the context of negotiating appointments for the consumption of processing services by adjusting the prices they offer or budgets to pay for services in accordance with the schedules they need to meet or want to keep.
More particularly, a lot 130 typically negotiates with a number of process tools 115. The LSA 405 tries to find a time slot offered by a process tool 115 that will allow the lot 130 to meet its due date and feed the next bottleneck machine station at the appropriate time. At the same time, the MSA 410 tries to acquire lots 130 for processing in a way that optimizes the utilization of the process tool 115. The goals of the MSA 410 are to maximize the overall utilization of its respective process tool 115, respect the relative priority of the lots 130, reduce setup or recipe changes, and optimize its batch size. This collaboration of agent interaction results in the scheduling of a lot 130 on a particular process tool 115 within a specified time window.
In general terms, consumers of processing services initiate negotiations for those services. In accordance with the present invention, negotiations are initiated on the expiration of the timed offset following the detection of the triggering event. For instance, on expiration of the timed offset, the LSA 405 begins the negotiation by publishing a "request bid" message 425 to all of the MSAs 410 representing process tools 115 capable of performing a desired manufacturing operation. At this point, a MSA 410 is acting as a provider because the process tool 115 is providing services, i.e., processing time.
The MSA 410 for each capable process tool 115, upon receipt of the request bid message 425, identifies a potential bid, and recognizes whether it will need a qualified resource 140 to perform the job. If so, the MSA 410 publishes its own request bid message 430 to the RSAs 415 of all capable resources 140. The MSA 410 has now shifted from a provider at this point to a consumer since the process tool 115 is now consuming process services, i.e., time with the resource 140. Each RSA 415 representing a qualified resource 140 submits one or more bids 435, one of which the MSA 410 selects for inclusion in its bid 460. The MSA 410, having now identified the necessary resources, returns to its role as a provider of processing services. If another potential bid is identified by the MSA 410, it once again requests bids from the appropriate RSAs 415.
Each MSA 410 representing a capable process tool 115 submits one or more bids 460 to the LSA 405 that published the request bid message 425. The LSA 405 selects one bid 460 from among all the bids 460 of all the MSAs 410. The LSA 405 then awards the contract 465 to the MSA 410 submitting the selected bid 460. The MSA 410 checks its machine calendar 470, determines that the bid is still available and, if so, awards the contract 440 to the resource 140 that submitted the selected bid 435. The RSA 415 checks its resource calendar 445, sees that the bid is still available, and schedules the appointment 475 a on its own resource calendar 445. The RSA 415 then confirms the contract with a "confirm bid" message 455, and the MSA 410 schedules an appointment 475 b on its machine calendar 470, with a reference to the RSA 415 that provided the "resource" bid 435. The MSA 410 then sends a "confirmed bid" message 480 to the LSA 405. The LSA 405 then schedules the corresponding appointment 475 c on its own lot calendar 485. When the time arrives for the appointments 475 a, 475 b, 475 c to execute, the scheduling agents 405, 410, and 415 pass control to their respective processing agents (not shown).
Note that providing a particular process service may require no resources or more than one type of resource. An individual MSA 410 may therefore forego negotiations with the RSA 415 or may negotiate with several different types of RSAs 415. For example, lot processing may require not only a reticle resource 140, but also an empty carrier (not shown) and a WFT (also not shown). Thus, the MSA 410 may repeat the negotiation described relative to the RSA 415 and resource 140 several times.
Still referring to
In one particular implementation, the LSA 405 calculates the initial value of LDTC as the time at which the lot will fall behind schedule. The corresponding LDTC is determined using the following equation:
The MSA 410 for the capable process tools 115 formulate bids 460. As mentioned above, the MSA 410 maintains a machine calendar 470 to track its appointments. When the request bid message 425 is received, the MSA 410 searches the machine calendar 470 for an opening in which the lot 130 can be scheduled for an appointment. An "appointment" has a "processing window" ("PW"). A processing window is a time interval of an estimated duration for providing services defined by an Appointment Start Time ("TS") and an Appointment End Time ("TE"). In the floating appointment approach, most appointments have a "commitment window" ("CW") within which the process window PW may float. A "commitment window" is a time interval within which the service is to be provided. The start time of the commitment window CW is defined by the Earliest Start Time ("EST") when the consumer can be available for the service. The end time of the commitment window is defined by the provider's Latest Delivery Time ("LDTP") for the service. Note that the LDTP may be different from the LDTC in the request bid message 425 from the LSA 405 for lot 130.
Besides the process window and the commitment window, an appointment may have other attributes depending on the nature of the appointment. For example, a move appointment will have attributes for the source location and the target location to represent the source and the destination of the move. A lot processing appointment will have attributes for the transport start time and the remaining transport time that will be used to calculate the dynamic earliest start time of the appointment. If a loading operation is involved in a process operation, the corresponding lot processing appointment will have two extra attributes for the load start time and the remaining load time. The dynamic EST of this lot processing appointment can therefore be derived from these four attributes together with the current time and static EST. Some appointments will share some same properties. For example, all the appointments have a processing window and an appointment ID, all the lot appointments will have a reference of a lot, and all the batch appointments will have a list of all the batch participants.
In the illustrated embodiment, the MSA 405 is permitted to search beyond the LDTc specified by the lot 130 if necessary in order to locate a valid bid 460. If this occurs, the MSA 410 sets the LDTp of the bid to the TE of the resulting appointment. Each appointment will store both the processing window PW [TS, TE] and the commitment window CW [EST, LDTp] information. This information is then used, in the illustrated embodiment, in formulating the bids 460.
More particularly,
Lot1: APP1[t10, t12], CW1[t8, t14]
Lot2: APP2[t13, t15], CW2[t9, t16]
Lot3: APP3[t5, t7], CW3[t2, t11]
Lot4: APP4[t3, t4], CW4[t1, t6]
The appointments APP1-APP4 represent processing windows within the commitment windows CW1-CW4. Note that, in the illustrated embodiment, several of the commitment windows overlap but none of the appointments do. However, in alternative implementations, this may not always be the case, as will be discussed further below.
Returning now to
The determination of the EST depends on the type of appointment. Most types of appointments have a static EST ("ESTstatic"). In this case, the static EST is a fixed time when the activity could start, such as the earliest time a time-based PM can start. However, some types of appointments calculate the EST dynamically. These types of appointments include lot appointments, lot processing appointments, carrier-in appointments, resource Lot Carrier-In appointments, and batch appointments. The basic calculation for dynamic EST is:
An appointment with unloading constraints cannot start processing until the lots 130 in the previous appointment have completed unloading.
Returning to dynamic EST calculation, for a lot appointment:
Note that the dynamic EST determination should consider whether the setup occurs before loading or whether setup and loading are performed in parallel. Note also that this implementation assumes the setup occurs before loading. And, for a batch appointment, the default determination is:
The EST of each batch participant takes into account that the individual lot requires loading time but since the load size is less than the batch size, all of the lots 130 cannot be loaded in parallel. These difficulties can be resolved, however, by considering the order in which the participants will be loaded. To this end, each lot processing appointment and resource charge lot appointment includes an attribute "transferSequence" identifying where in the loading order the respective lot 130 falls, e.g., 1, 2, 4 indicating first, second, third. A value of "0" indicates that loading is not needed. However, other suitable algorithms may be employed in alternative embodiments.
Note that, because this determination is dynamic, some quantities used are updated when specific events occur. For instance, LSA 405 is responsible for updating the TST and the RTT of the lot 130. For instance, the values of RTT and TST are updated when:
Still referring to
More particularly, the scheduling agents 410 and 415, representing providers, each has an associated "cost calculators" (not shown) also employed in formulating bids to determine costs for available time slots. The cost determinations reflect the desire of the MSA 410 or RSA 415 to achieve its goals for its process tool 115 or resource 140. For instance, if the process tool 115 is relatively idle, the cost may be relatively low in an attempt to reduce machine idle time. Conversely, if the process tool 115 is relatively busy, the cost may be relatively high—thereby reflecting a lesser need to increase machine utilization. The MSA 410, representing an "intermediate" consumer, passes the budget calculator tool of the provider agent (e.g., the LSA 405, PMSA 418) with which it is negotiating to the provider agent with which it is also negotiating (e.g., the RSA 415). Thus, providers can readily determine the available budget for end consumers and costs for offering their processing services to the end consumers.
The MSA 410 packages the bid information and submits the bid(s) 460 to the LSA 405. In the illustrated embodiment, the MSA 410 actually returns several alternative bids 460, each with a different start time, in the form of a bid list. These bids 460 will be generated by using, in the illustrated embodiment, searches on the machine calendar 470 for open time slots using existing setups; open time slots requiring new setups; time slots where a lot 130 can join an existing batch; time slots where lots 130 can join an existing batch by bumping another lot 130; and time slots that require bumping ("canceling") appointments booked for other lots 130. Several of these searches may return the same time slot but a time slot should only appear once in the bid list returned to the lot 130. At least one bid 460 is always returned in this particular embodiment, and the minimum number of returned bids is determined by a configurable property value.
Note how maintenance of the calendars 485, 470, 445, and 487 facilitates the scheduling process. The calendars 485, 470, 445, and 487 impose a structure on booked appointments for the process flow 400 that permits the scheduling agents 405, 410, 415, and 418 to quickly and easily search through the booked appointments, find suitable time slots, and generate (or otherwise participate) in the bidding and bid conformation process. This structure also allows the application of appointment management routines, some of which are described below, that can similarly facilitate the scheduling process and help the process flow 400 to operate more efficiently.
After receiving all bids 460 from all MSAs 410 for the capable process tools 115, the LSA 405 evaluates the bids 460 and selects one bid 460 from among those submitted. The bids 460 are evaluated through an Objective Function F in light of the end time ("BidEndTime") of the bid 460 and some other information, including cost ("BidCost"). The LSA 405 for the lot 130 evaluates every bid 460 from every process tool 115 in this manner. An objective function F is employed:
Still referring to
However, by the time the LSA 405 seeks confirmation of the bid 460, the machine calendar 470 of the process tool 115 may have changed and the time slot may not be available or the bid cost may have changed. The MSA 410 will confirm the bid 460 only if the time slot is available and the bid cost does not increase more than a configurable percentage of the original bid cost. Otherwise, the MSA 415 replies to the LSA 405 indicating the bid 460 is not confirmed.
If the process tool 115 does not confirm the selected bid 460, then the LSA 405 determines whether to start the bidding over or to select the next best bid. The LSA 405 compares the number of remaining bids 460 with a configurable "rebid threshold." If the number of remaining bids 460 is greater than the rebid threshold, the lot 130 returns to the bid selection process described above and selects the next best bid 460. After selecting the next best bid 460, the LSA 405 calculates the objective function F (discussed above) for the new bid 460. If the value of F has not increased by more than a configurable percentage of the objective function F for the best bid 460, the LSA 405 attempts to confirm the next bid 460. Otherwise, if the remaining bids are less than a rebid threshold or the objective function F for the next bid 460 has increased too much, the LSA 405 begins the entire process over again by requesting bids from all capable process tools 115.
As was mentioned above, the illustrated embodiment specializes the software agents 365 along several lines. This specialization particularly manifests itself in the MSAs 410. In one particular implementation, MSAs 410 differentiate as to whether they represent process tools 115 that are batch or are sequential ("cascading"). For example, there are many types of process tools 115, and each type of process tool 115 might possess different characteristics for which a respective software agent 365 might advantageously be specialized.
Exemplary characteristics that may lend themselves to specialization in machine agents (both scheduling and processing) in the illustrated embodiment include:
Consider, for instance, an implementation wherein machine agents are specialized by whether they process by wafer, by lot, by batch, etc. In one particular embodiment, the machine agents set forth in Table 2 are employed. This particular embodiment implements the agents using object oriented programming techniques and the baseline agents provide the class definition and the others are subclasses of that class.
Other agent specializations might also be employed. PM agents may be specialized by whether the maintenance procedures they perform are based on time, wafers processed, lots processed, batches processed, processing time, an occurrence of an event, etc. In one particular embodiment, the following PM agents are employed:
Also as alluded to above, the illustrated embodiment specializes the calendars employed by the manufacturing domain entities. Calendars, e.g., the calendar 427 in
Thus, where these types of agent specialization are employed, the calendars 470, 485, 445, and 487 may also be specialized. On some specialized calendars-sequential machine calendars, for example—a portion of the appointment is allowed to overlap with other appointments. The term "sequential" refers to a capability for processing more than one material (e.g., wafer 135, lot 130, or batch) at a time. That is, the process tool 115 can begin processing a second material before it is finished processing a first material. Consider, for example, an implementation of a process tool 115 called a "sink" (not shown). A sink has several tubs in which lots 130 of wafers 135 can be exposed to various chemical baths in sequence. While one lot 130 is being exposed in one bath, a second lot 130 can be exposed in a second bath, and both are being processed by the same process tool 115 in sequence.
In cases where the process tool 115 is a sequential machine, and the MSA 410 and the machine calendar 470 are specialized, some portions of some appointments may overlap. As is shown in
Thus, as was mentioned above, the type of appointments scheduled on any given calendar will depend largely on the nature of the entity that the software agent 365 that is keeping the calendar represents and the degree of agent and calendar specialization. In the illustrated embodiment, there are four types of scheduling agents as is set forth in Table 1: MSA, LSA, RSA and PMSA. Each scheduling agent will have its own scheduling calendar to store its booked appointments: machine calendar, lot calendar, resource calendar, and PM calendar.
To present an overview and to help illustrate how agent, calendar, and appointment specializations interact in the illustrated embodiment,
MSAs (e.g., MSAs 706, 720) schedule and book a number of types of appointments summarized in Table 1. In
The lot processing appointments 732-734 are the appointments in which the tool T1 is scheduled to actually perform the processing on the lots L1, L2, L3. As will be appreciated by those skilled in the art having the benefit of this disclosure, the tools T1, T2 will occasionally have to undergo a "setup" in preparation for processing a given lot. All else being equal, it is generally preferable to reduce the number of setups by scheduling lots requiring the same setup successively. Such is the case for the lots L1, L2 on the tool T1, whose lot processing appointments 732-733 are scheduled together after the setup appointment 729 since they require the common setup S1. These types of preferences are realized in the scheduling process in the formulation of bids discussed above. More particularly, cost factors are apportioned in the bidding process to encourage lot processing appointments having common setups to be scheduled together. However, in
As the name implies, the batch appointment 757 is an appointment on a process tool 115 (e.g., T2) to process a batch of lots 130. Each lot 130 (e.g., L5-L10) is considered a "participant" in the batch, and the batch appointment actually comprises a plurality of "participant" appointments (not shown). Participant appointments are, in actuality, lot processing appointments that describe the makeup of the batch. In the illustrated embodiment, the lot appointments 774-779 are counterpart "participant appointments" for the batch appointment 774. Lots 130 may be added to or removed from a batch by joining, removing, canceling, and/or bumping individual participant appointments. If the batch needs loading onto the process tool 115, the RSA 727 will schedule carrier-in ("CI") and carrier-out ("CO") appointments 767-769, 793-794 in a manner discussed more fully below.
As summarized in Table 1, the LSAs 707, 721-726 for the lots L1, L5-L10 usually book six kinds of appointments on the lot calendars 702, 712-717: the move appointments 740-742; the lot appointments 746-748, 774-779; a maximum move appointment 753; a feeder appointment 752; carrier-in 760-765 (e.g., CI1, CI2, CI3); and carrier-out 783-788 (e.g., CO1, CO2, CO3). The move appointments 740-742 and lot appointments 746-748, 774-779 are scheduled where all the parameters used to schedule with certainty are known.
More particularly, the lot appointments 746-748, 774-779 are appointments for processing the respective lots L1, L5-L10 on the particular process tools T1-T5. As will be appreciated by those skilled in the art having the benefit of this disclosure, the lots 130 typically are moved from process tool 115 to process tool 115 in order to be processed on successive operations defined in the lots' processes. For example,
There are typically two types of moves-interbay and intrabay moves. Interbay moves transport lots 130 between bays (not shown) of the manufacturing facility. Intrabay moves transport lots 130 to different locations within the same bay. So, a typical move of a lot 130 from one process tool 115 to another process tool 115 in a different bay involves at least three moves: an intrabay move from the port of a first process tool 115 to a stocker (not shown) in that tool's bay; an interbay move from that stocker to another stocker (also not shown) which is in the same bay as the second process tool 115; and the final intrabay move from that stocker to the port of the second process tool 115. Note that, in these embodiments, each move actually constitutes at least two constituent moves, a move from a process tool 115 to, e.g., a stocker or some other WIP resource, and a move from the WIP resource to the next process tool 115. Each of these constituent moves is separately scheduled, as in the case of the move appointments 741, 742.
However, that some embodiments may employ what is known as a "unified AMHS." A unified AMHS permits moves directly between process tools 115 without stopping at some intermediate WIP resource. Thus, in some embodiments, only one move may be scheduled between process operations on different process tools 115.
The maximum move appointments 753 and feeder appointments 752 are scheduled as "placeholders" on the calendars until sufficient certainty is achieved in scheduling that they can be replaced. As was noted above relative to
Consequently, for purposes of scheduling the target process operation, the consumer's scheduling agent books one or more maximum move appointments 753 and/or feeder appointments 752. The maximum move appointments 753 and/or feeder appointments 752 are explicit scheduling constraints, or "placeholders", representing best estimates for the unscheduled intervening process operations. Once the source and destinations are known, the maximum move appointment 753 and the feeder appointment 252 can be replaced by move and lot appointments such as the move appointments 740-742 and lot appointments 746-748, 774-779. More precisely, a maximum move appointment 753 is replaced on the calendar when the source and destination process tools 115 are known and move durations can be determined. A feeder appointment 752 is replaced when the process operation it represents is scheduled, i.e., when the associated triggering event for the process operation is detected and the process operation is scheduled. Thus, the feeder appointment 752 and maximum move appointment 753 are useful in the context of scheduling several operations in advance before scheduling some of the earlier intervening operations for a particular process tool 115.
Note that feeder appointments 752 are used in conjunction with maximum move appointments 753 to account for the cycle time of upstream operations when scheduling several operations in advance. More particularly, feeder appointments 752, account for travel time to the otherwise unscheduled process operation and wait time. Move time away from the otherwise unscheduled process operation is rolled into the maximum move appointment 753. If two feeder appointments 752 are scheduled back-to-back, travel time away from the previous feeder appointment 752 will be accounted for as the time needed to move to the second feeder appointment 752 and the wait time. Thus, where two feeder appointments 752 are scheduled back-to-back, intervening maximum move appointments 753 can be omitted.
The feeder and maximum move appointments represent explicit, as opposed to implicit, constraints on the scheduling process. Explicit constraints are represented as appointments on the calendars that directly affect the scheduling and booking of other appointments. Examples of explicit constraints include, but are not limited to, move, load, unload, maxmove, and feeder appointments. These appointments explicitly constrain the scheduling of the lot appointments on the lot calendar. Implicit constraints are not represented as appointments on the calendar, but rather as attributes of the appointments they affect. For example, the lot processing appointment on the machine calendar has attributes that represent the constraints of loading, transport, and unloading because these constraints are not represented by appointments on the machine calendar. Similarly, discharge duration, like the UST and RUT, discussed above, also is an implicit constraint. Like the UST and the RUT, the discharge duration is not a hard constraint—so, it does not affect the dynamic EST, but it does constrain shifting because loading or unloading related to the next batch appointment cannot overlap with the discharge.
In a partially automated fab, only a portion of the process operations may be scheduled and controlled by the software agents 365. Thus, only a subset of the process tools 115 in the fab are under the control of the software agents 365 and the fab is not fully under the control of this system. Those process operations controlled by the software agents 365 are called "control process operations." The illustrated embodiment nevertheless represents uncontrolled process operations with appointments in the scheduling process to explicitly constrain the scheduling of control process operations.
For some process operations, the process tool 115 (e.g., the tool T2) may require loading and unloading the lot 130. For those operations, the LSA (e.g., the LSAs 721-726) will book carrier-in and carrier-out appointments (e.g., the carrier-in and carrier-out appointments 760-765, 783-788) on its own calendar (e.g., the lot calendars 712-717). These carrier-in and carrier-out appointments match the carrier-in and carrier-out appointments (e.g., the carrier-in and carrier-out appointments 767-769, 792-794) scheduled by the RSA (e.g., the RSA 727) on its calendar (e.g., the resource calendar 718).
The PMSA 709, as summarized in Table 1, books two kinds of appointments on the calendar 730: PM appointments such as the PM appointment 752, and stand-alone Quals such as the Qual appointment 753. The PMSA 709 schedules PMs and Quals opportunistically, but in accordance with known constraints on when they should be scheduled. The calendar 730 shows only the one PM appointment 752 and the one Qual appointment 753 scheduled for the tool T1. Note that the machine calendar includes counterpart PM and Qual appointments 737-738 booked thereon. Multiple PMs and Quals may be performed on a tool, and so the machine and PM calendars 701, 793 in an actual embodiment may include multiple PM and Qual appointments for one tool. Some PMs are required to be followed by one or more follow-up Quals before the process tool 115 can be reintroduced to the process flow 400. In these circumstances, the follow-up Quals are automatically scheduled within the PM appointment.
RSAs (e.g., the RSAs 708, 727), in the illustrated embodiment, are specialized by the kind of resource they represent. There generally are two kinds of resources: shared resources and dedicated resources. Shared resources are resources that may be shared by multiple process tools 115, such as the resource 140 shown in
The types of appointments booked by a RSA depends on the type of resource it represents. The shared RSA 708 for the resource R1, shown in
The dedicated RSA 727 schedules appointments related to its dedicated process tool 115 (e.g., T2) only. In the illustrated embodiment, the dedicated RSA 727 represents a machine loading resource (not shown) for a furnace (also not shown). The dedicated RSA 727 books four kinds of appointments on the calendar 740: the carrier-in appointments 767-772; the charge appointment 772; the discharge appointment 781; and the carrier-out appointments 792-794. The carrier-in appointments 767-772, charge appointment 772, discharge appointment 781, and carrier-out appointments 792-794 are implementation specific and are discussed in more detail immediately below.
Some process tools 115 (e.g., T2) perform lot batch process operations in which multiple lots 130 are simultaneously processed in a batch. Some of these process tools 115 use load, charge, discharge and unload steps. In the embodiment of
For example, if the tool T2 has two I/O ports, and the batch process operation allows a maximum of six participants in a batch, three batch load operations are required to load six lots 130 into the internal stocker of the tool T2. After all the batch participants are loaded, the tool T2 performs a batch charge operation to move the batch participants from the internal stocker into a furnace tube (not shown) before the processing can actually begin. After the tool T2 completes the batch process operation, it discharges the batch participants from the tube back into the internal stocker. Finally when the lots 130 are ready to be moved to the tool I/O ports, a sequence of batch unload operations is performed.
Due to the constraints of the tool internal transport mechanism, appointments are not permitted to overlap on this kind of resource scheduling calendar. These load, charge, discharge, and unload activities are performed in a mutually exclusive fashion, i.e., they cannot occur at the same time because they use the same resource. Thus, loading moves the lot 130 from a machine port to an internal stocker of the machine. Charging moves the wafers 135 from the internal stocker to the furnace tube for heating (processing). Discharging removes the wafers 135 from the furnace tube (after cooling) and moves them back to the internal stocker. Unloading moves the lot 130 from the internal stocker to a machine port.
Note that the RSA 727 is not concerned with the actual processing—that is represented on the machine calendar 711 by the batch appointment 757. However, there is a relationship between the charging and discharging appointments 772, 781 on the resource calendar 718 and the batch appointment 757 on the machine calendar 711. More particularly, charging starts when processing starts and discharging ends when processing ends. Charging or discharging typically takes about 15 minutes while processing typically takes four or more hours. On the machine calendar 711, the batch is considered "processing" from the time the start command is issued (before charging starts) until the furnace has completed discharging. Note that the MSA 720 is not concerned with loading, charging, discharging or unloading because these are all tracked by the RSA 727 on its resource calendar 718. The machine calendar 711 contains the batch appointment 757 that represent "processing," which is time when no other batch can be "processing" on the tool T2.
As previously mentioned, on the machine calendar 711, the batch appointment actually contains participants that are each lot processing appointments, one for each lot 130 in the batch. Meanwhile, loading and unloading activities can occur in parallel with "processing," so long as they do not conflict with one another or with charging or discharging. Loading or unloading lots while another batch is "processing" is a technique for increasing the throughput of the furnace.
For this particular type of furnace, the lots L5-L10 are loaded two at a time because that is the number of machine I/O ports where lots 130 can be loaded or unloaded. But, the furnace can run up to six lots 130, so if the number of lots 130 in the batch is more than two, then the lots 130 are loaded in sub-batches of two lots 130. Thus, the lots L5, L6 are loaded during the carrier-in appointment 767 on the resource calendar 718, the lots L7, L8 during the carrier-in appointment 768, and the lots L9, L10 during the carrier-in appointment 769. Note that the carrier-in appointments 767-769 on the resource calendar 718 have counterpart appointments on the lot calendars 712-717.
More particularly, since each carrier-in appointment 767-769 includes two lots, each of the carrier-in appointments has two counterparts. Thus, the carrier-in appointment 767 has counterparts 760, 761 on the lot calendars 712, 713; the carrier-in appointment 768 has counterparts 762, 763 on the lot calendars 714, 715; and the carrier-in appointment 769 has counterparts 764, 765 on the lot calendars 716, 717. So, a batch with six lots 130 (e.g., lots L5-L10) might have three sub-batch carrier-in appointments (e.g., carrier-in appointments 767-769) on the resource calendar (e.g., resource calendar 718). Note also that, in the illustrated embodiment, each carrier-in appointment 767-769 is actually a batch loading appointment containing a resource carrier-in appointment for each participant lot that is being loaded.
Charging is performed for all lots 130 (with a maximum of six) at the same time on this particular furnace. The charge appointment 772 represents the charging batch, which actually comprises a participant charge appointment (not shown) for each participant (e.g., lots L5-L10) in the batch. Thus, for each furnace run, there will be one charge appointment 772 with up to six participants. Discharging is also performed for all lots 130 at the same time. The discharge appointment 781 represents the discharging batch and actually comprises a participant discharge appointment (not shown) for each participant (e.g., lots L5-L10) in the batch. For each furnace run, there will be one discharge appointment 781 with up to six participants. As was mentioned earlier, however, the individual lots 130 (e.g., lots L5-L10) are not concerned with charging and discharging, as these steps are internal to the process tool (e.g., the tool T2). Thus, the charge and discharge appointments 772, 781 have no counterparts on the lot calendars 712-717. The lots L5-L10, instead subsume the time for charging and discharging into the lot appointments 774-779.
Unloading, or carrier-out, is the reverse of loading. Like loading, unloading is performed in sub-batches of at most two lots 130 at a time. So, a batch with six lots 130 (e.g., lots L5-L10) might have three sub-batch carrier-out appointments (e.g., carrier-out appointments 792-794) on the resource calendar (e.g., the resource calendar 718). The carrier-out appointments 792-794 also each have two counterparts appointments on the lot scheduling calendars 712-717, one for each participant in that particular sub-batch carrier-out. The carrier-out appointment 792 has counterpart carrier-out appointments 788, 787 on the lot calendars 716, 717; the carrier-out appointment 793 has counterpart carrier-out appointments 785, 786 on the lot calendars 714, 715; and the carrier-out appointment 794 has counterpart carrier-out appointments 783, 784 on the lot calendars 712, 713.
Note that the sequence for unloading is independent of the sequence for loading. Loading sequence is primarily dependent on arrival time (EST) of the lots 130, while unloading sequence may depend on the priority of the lot 130 or the time of its next appointment. Thus, although unloading is performed in the reverse order of loading in the illustrated invention, this is not necessary. Note also that, in the illustrated embodiment, each carrier-out appointment 792-794 is actually a batch carrier-out appointment containing a resource lot carrier-out appointment for each participant lot that is being unloaded.
Similarly, the PM is scheduled on the machine calendar 701 for the tool T1 and on the preventive maintenance calendar 704 for the period [t4, t6] and the Qual is scheduled on the machine and PM calendars 701, 704 for the period [t6, t8]. For the batch process operations require loading, charging, discharging and unloading steps, a lot load appointment and a lot unload appointment are scheduled on the lot calendars 712-517 and a batch carrier-out appointment and a batch carrier-out appointment with the same time interval as those on the lot calendar are scheduled on the loading resource calendar 718. A batch lot processing appointment is scheduled on the machine calendar 711 for [t6, t8], a batch charge appointment for the period [t6, t61] and a batch discharge appointment for the period [t7, t8] are scheduled on the loading resource calendar 718.
The scheduling disclosed relative to
Referring now to both
After receiving a message from the equipment interface (not shown) of the process tool 115 indicating that the lot 130 is actually started processing on the process tool 115, the MSA 410 changes the appointment status to "processing" (at 825). Depending on the type of the process tool 115, the MSA 410 may change the appointment status from "processing" (at 825) to "near complete" (at 830). Typically, this change is made if the MSA 410 receives another message from the equipment interface indicating that the process tool 115 has reached a specified processing stage. For example, the passage of 80% of the processing time might indicate that an appointment is "near complete." When the lot 130 completes or aborts its processing on the process tool 115, the MSA 410 changes the appointment status to "completed" (at 835) or "aborted" (at 840), respectively.
Note that illustrated embodiment does not employ all appointment state changes as "triggering events." The illustrated embodiment only employs active (at 820), active PM/Qual (at 845), processing (at 825), processing PM/Qual (at 850), near complete (at 830), and completed (835) appointment states as triggering events. In general, the tentative (at 805), unready (at 810), and ready (at 815) states are considered to be too contingent in this particular embodiment. Similarly, if the appointment is aborted (at 840), scheduling ahead is not really applicable. However, this is an implementation specific detail. Alternative embodiments may use all or none of the appointment states as defining events. In the latter case, other types of events may be defined as triggering events, depending on the implementation.
As is apparent from earlier in the discussion, some appointments are scheduled along with "corresponding" appointments on other calendars and the states of these corresponding appointments may also be synchronized. "Corresponding" appointments are appointments booked on different calendars in furtherance of the same activity. The appointments 475 a, 475 b, 475 c in
To communicate the occurrence of events in the process flow 100 and to keep corresponding appointments synchronized, the illustrated embodiment uses an appointment change notification mechanism illustrated more fully in
When the change listener 915, 920 receives a change event about the corresponding appointment on the other side, it will trigger its respective scheduling agent 405, 410 to (1) determine whether the event is a "triggering event" and (2) find the corresponding appointment, and make appropriate adjustment to that appointment so that the appointment(s) on the provider side and consumer side will always keep in synch, if possible. However, the scheduling agent 405, 410 receiving the appointment change may need to react differently. In that case, it makes a different change to its appointment(s) and publishes that change to the listeners 915, 920.
More particularly, when the status of an appointment (e.g., the appointment 475 b on the machine calendar 470, in
A slightly different change notification mechanism is used by calendar loggers and calendar "graphic user interface" ("GUI") display tools. In the illustrated embodiment, each calendar (e.g., the machine calendar 470) has a respective calendar logger (e.g., the calendar logger 940) that logs all the changes occurring to the appointments on the calendar. Each calendar logger has an appointment change listener (e.g., the change listener 945) subscribing to the changes on all the appointments (not just one) on the corresponding calendar. The calendar logger and calendar GUI (e.g., the calendar GUI 950) register (e.g., at 952) their listeners directly with the change notifier of the calendar they are listening to, rather than subscribing directly to each individual appointment. This allows the calendar logger and calendar GUI to listen to changes to every appointment on the calendar, including the booking of new appointments.
When one appointment or a set of appointments on the calendar is changed, the change listener will be notified as described above. The change listener will then trigger the calendar logger to log the corresponding change event(s) and dump the calendar. The entire history of a calendar can be recorded in a calendar log file in this manner. WFTs view a calendar using a set of GUI display tools. In this case, every calendar displayed on a computer screen has its own appointment change listener. As in the case of the calendar logger, this change listener is also subscribing to the changes of all the appointments on the displayed calendar. When something changes on the calendar, this change listener will be notified by the change notifier of the appointments, and this in turn will automatically trigger the refresh of the displayed calendar.
Note that, as conditions in the process flow 100 change, other changes can ripple through the process flow 100 and, in particular, the calendars. To avoid undesirable change notification propagation represented by the infinite loop of change notifications, the illustrated embodiment uses a change event registration scheme. More specifically, when a MSA 410 receives a change on a lot appointment, the change event is registered into a list (not shown) for the machine scheduling calendar 470. Later, when the MSA 410 is ready to send a change notification about the corresponding lot processing appointment on its calendar 470, the MSA 410 will first check the list of all the registered change events. In this case, a matched event will be found, and the MSA 410 will interpret the event as a reactive change event coming from the LSA 405. Thus, no further action is required on the machine side, and the MSA 410 will just remove the matched change event from the list. However, non-agent appointment listeners such as the calendar loggers 940 and calendar GUI 950 are always notified of relevant appointment changes. This occurs regardless of whether the change is being initiated or is a reactive change because these types of applications typically listen to only one calendar.
Heretofore, this detailed description has been directed to the physical factory, or "fab", 1000 of an automated semiconductor fabrication facility ("fab") 1003, shown in
In order to implement an agent-enhanced scheduling and control system for semiconductor processing, the system collects information concerning conditions in the physical factory 1000. On initialization of the software agents 365 and the virtual factory 1010, the virtual factory 1010 is populated with the state and definition of the physical factory 1000. The definition of the factory includes, among other things, the:
However, as operations begin, the state of the physical factory 1000 changes. Periodically, so does the definition as process tools 1015 and resources 140 are removed from or added to the process flow. Thus, the virtual factory 1010 collects information regarding real-time transactions in the physical factory 1000 (shown in
The virtual factory 1010 also contains objects corresponding to the physical elements of a physical factory 1000, i.e., the manufacturing domain entities. The virtual factory 1010 includes objects representing lots 130, process tools 1015, resources 140, and other manufacturing domain entities. Note, however, that the software agents 365 do not necessarily exist in a one-to-one correspondence with manufacturing domain entities, such as lots, equipment, etc. Instead, most manufacturing domain entities are each represented by more than one agent as mentioned above. For instance, each lot 130, process tool 1015, resource (e.g., the reticle 408, shown in
The virtual factory 1010 may be implemented as a data store encoded on some form of storage and may be of any suitable structure known to the art, or even several data structures (not shown). The virtual factory 1010 is also used to store a wide variety of information that may assist in providing automated material handling for the physical factory 1000, including the:
For instance,
More precisely, the virtual factory 1010 contains a number of relevant specifications and state of the physical factory 1000. This includes product/process definitions, separated into "collections," that are grouped into a factory façade 1081, that are provided to the components of the AEMS 1020 as needed. One particular embodiment of the factory façade 1081 includes a plurality of "collections" and "repositories" of information set forth in Table 4.
One particular embodiment of the factory façade 1081 is illustrated in
The triggering event and time offset information used in implementing the invention is stored in the factory façade 1081. In the illustrated embodiment, triggering events and time offsets for a given process operation are determined a priori and stored among the collections of the factory façade 1081. This information comprises a portion of the factory definition that is a part of the virtual factory 1010. For a given process operation in the process flow, the factory definition in the virtual factory 1010 contains a set of target process operations for scheduling ahead and their associate triggering events and time offsets. Thus, a scheduling agent can determine the triggering events and time offsets for the current process operation by accessing the factory definition.
Returning to
In the illustrated embodiment, the virtual factory 1010 also includes a store of factory metrics 1083. These factory metrics includes, as shown in
Still referring to
As mentioned, the SALSA agent class determines when new lots 130 are released into the process flow of the factory. More particularly, the SALSA agent monitors work in process ("WIP") in the process flow and identifies one or more workstations or process tools 115 that create bottlenecks in the process flow. The SALSA calculates a WIP value representing the amount of work approaching each bottleneck workstation and determines whether the WIP value is projected to fall below a control limit during an evaluation period. If the WIP value is projected to fall below the control limit during the evaluation period, a selected amount of additional work is released into the manufacturing line. In some implementations, the SALSA even determines which products and the quantities of those products to introduce, and then initiates their introduction. Note, however, that the SALSA can, in some embodiments, release lots in accordance with a work production schedule.
The AEMS 1020 also includes a number of software components that facilitate the functionality of the software agents 365. In the illustrated embodiment, these additional software components can be generally categorized as an alarm service (not shown) that provides time to AEMS 1020 components, and provides the ability to set an alarm for a specified time or period and to have a callback invoked on a specified listener at that time; adapters 1046 that provide interfaces to other FCS, e.g., the MES 1041, the EI 1065, the AMHS 1060, a notification system 1052, and recipe management system 1040; and helpers (not shown) used by the software agents 365 to accomplish their functions. The adapters and helpers are implemented in several varieties summarized and described in Table 6 below. Still other helper class components may be employed in various embodiments.
Note that some embodiments may distribute the functionality of the software components differently than does the illustrated embodiment. For instance, in some embodiments, the functionality of the processing agents may instead be implemented in helper class objects called by the scheduling agents. Thus, the distribution of functionality across the software components of the illustrated embodiment is exemplary and illustrative only, and not necessarily limiting.
The illustrated embodiment permits configurability of the software agents 365. More particularly, the processing and scheduling actions of the software agents 365 are scripted such that certain, predefined events cause execution of a script segment. Exemplary events include, but are not limited to, arrival of a carrier, completion of a wafer, completion of a process, etc. Editing these scripts "configures" the behavior of the software agents 365 by controlling how they react to selected events. Thus, a user can provide "rules" governing the behavior of the software agents 365. Alternatively, parameters or properties of the software agents 365 may be externally set to configure the software agents 365 and provide flexibility and/or system tuning. For instance, some properties specify curves that guide system decisions, e.g., cost-of-lateness, congestion fee, urgency, bumping fee, PM budget, and lot budget. Some parameters are agent controls, such as bottleneck machine types, work in progress ("WIP") safety factor, start batch size, etc. Some control knobs might be considered to be "miscellaneous properties" because they are not easily grouped elsewhere. Examples of this type of property include files paths and message types. Setting these types of parameters/properties can also configure the software agents 365.
In the illustrated embodiment, the software agents 365 are "dynamically" configurable. Values for properties are stored in a file stored, e.g., in the storage 310 shown in
Returning to
In operation, when the AEMS 1020 is initialized, the software agents must "discover" their current state. For instance, a LSA 402 in
As part of the initialization process, the individual scheduling software agents 365 check to see whether a triggering event occurred prior to initialization. Since the consumer is aware of its progress through the process flow 100, the scheduling agents 365 can retrieve information regarding previous process operations from the virtual factory 1010. This information will include associated triggering events. The occurrence of any triggering events can be extrapolated from information such as the current progress through the process flow 100. If a triggering event occurred, then the scheduling software agents 365 must determine whether the target process operation has been scheduled or needs to be scheduled. If it needs to be scheduled, then the software scheduling agent 365 begins the scheduling process described above relative to
The scheduling agents 365 then begin initial scheduling for the lots 130 and transitions into general scheduling using a contract net negotiation protocol discussed above.
Turning now to
The listener 1216, in turn, sends a change notification 1218 to the LSA 405 for the lot 130 to indicate that the end time and the state for the appointment 1210 has been modified. The LSA 405 then updates the appointment 1210 on its calendar 485 and retrieves data 1224 regarding the next process operation from the virtual factory 1010. The LSA 405 also determines whether the event reported in the change notification 1218 is a triggering event. For purposes of illustration, assume that the change of state to "near complete" is a triggering event. This is a part of the information retrieved from the virtual factory 1010, which also includes the time offset and the target process operation. The LSA 405 then sets an alarm for the expiration of the time offset.
On expiration of the time offset, the alarm fires. The firing of the alarm triggers the LSA 405 to begin scheduling the target process operation. The LSA 405 then publishes a bid request 1026 to the MSAs 1234, 1236, 1238 of the process tools 115 1, 115 2, 115 3 that have subscribed to receive bid requests for the process operation requested by the LSA 405, as previously discussed. The MSAs 1234, 1236, 1238 retrieve data 1240 such as wafer processing times, move durations, and lot status from the virtual factory 1010 and examine their respective calendars 1235, 1237, 1239. The MSAs 1234, 1236, 1238 then formulate and submit bids 1242 as discussed above. The LSA 405 then selects one of the bids as discussed above and sends a confirm bid message 1244 to the MSA 1234, 1236, 1238 that submitted the selected bid 1242. The MSA 1234, 1236, 1238 then confirms the award, books the appointment 1248, and sends the LSA 405 a contract confirmed message 1246.
The LSA 405 then books the new appointment 1248 on its calendar 485. The LSA 405 then schedules move appointments, for example, from the process tool 1215 0 to stockers (not shown) and from the stockers to the next process tool 115 1, 115 2, 115 3 with whom the new appointment 1248 is scheduled. The LSA 405 schedules move appointments so that the lot 130 it represents arrives in time for its load or processing appointment. Thus, the LSA 405 schedules move appointments in light of the time remaining before its next load/processing appointment. Once the move appointments are scheduled, if it is time to begin the move, the LSA 405 initiates the start of the move. If not, then the LSA 405 sets an alarm for the start time. Note that, during this scheduling process, the LSA 405 is also scheduling maximum move and feeder appointments 753, 752 as warranted to explicitly constrain the scheduling of the target process operation. When the start time for the move appointment 1248 arrives and the alarm fires, then the LSA 405 initiates the move. The LSA 405 sends a notification 1250 to the LPA 1252 responsible for processing the lot 130 through the new appointment 1248.
Turning now to
The LSA 405 receives an appointment change notification 1268 via a listener 1270 when the MSA 410 updates the state of the appointment 1210. The LSA 405 determines whether the event reported in the change notification 1218 is a triggering event. For purposes of illustration, assume that the change of state to "complete" is a triggering event. This is a part of the information retrieved from the virtual factory 1010, which also includes the time offset and the target process operation. The LSA 405 then sets an alarm for the expiration of the time offset. On expiration of the time offset, the alarm fires. The firing of the alarm triggers the LSA 405 to begin scheduling the target process operation as is discussed above relative to the change of appointment state to "near complete."
The LSA 405 also notifies the LPA 1252 that the processing has been completed, as indicated by the notification 1268, and updates the appointment 1210 on the calendar 485. The LPA 1252, upon notification that processing is complete, calls and executes a script (not shown) in a manner analogous to that of the MPA 1256 calling and executing the script 1260 to act upon the completion of the processing. After updating the appointment 1210, the LSA 405 examines its calendar 485. If it is time for the appointment 1248 to start, the LSA 405 notifies the LPA 1252 to execute a move appointment to position the lot 130 for the lot 130's next appointment 1248. If it is not time to start, then the LSA 405 sets an alarm for the start time. When the alarm fires, the LSA 405 then notifies the LPA 1252.
The scheduling scenario presented in
Furthermore, as was noted above, the invention admits wide variation in, e.g., scheduling. Although the illustrated embodiment employs a contract net negotiation protocol but alternative embodiments may employ alternative protocols, also as was noted above. Other alternatives may also be employed in addition to, or in lieu of, aspects previously set forth. Some embodiments may employ calendaring techniques to facilitate the scheduling process, for example, by opening slots on calendars.
For instance, booked appointments may be shifted. As mentioned above, most appointments have a commitment window. Appointments may be viewed as "beads on a string." Existing appointments are permitted to slide backward or forward within their respective commitment windows as necessary to provide a calendar with flexibility that in turn permits the scheduling agent to create a more efficient schedule and react to unexpected events. In the illustrated embodiment, to simplify the logic, appointments are not permitted to shift past the next appointment in either direction.
Consider, for example, the calendar conceptually illustrated in
The shifting can also be more complex than just shifting a single booked appointment. One such situation is shown in
In these embodiments, to prevent undesirable appointment shifting, the illustrated embodiment employs a locking mechanism. Generally speaking, when a lot 130 starts its final move from a source location to a machine port of the process tool 115, it is undesirable to have a new appointment jumping in front of it by canceling or shifting that appointment to the right, or later in time. To prevent this from occurring, when the LSA 405 asks the MSA 410 to reserve a machine port, the MSA 410 "locks" the lot processing appointment when the lot 130 starts its final move.
But, sometimes, locked appointments do need to be shifted. For instance, assume two appointments are booked on the calendar for a particular process tool 115, and the first one is processing while the lot 130 for the second one is moving to the port of the process tool 115. The second appointment is locked because it is in its "final" move to the process tool 115. If the first appointment runs long and is to be expanded, the second one is first shifted to permit the first one to expand. Thus, the locked second appointment is shifted even though this is generally undesirable. In these cases, some special calendar shift routines designed specifically for handling locked appointments are used. The shifting of locked appointments is performed at the agent's discretion depending on circumstances. In the situation cited above, the locked second appointment most likely cannot be rescheduled elsewhere with an earlier start time.
Still other variations may be employed. For a further example, the automated semiconductor fabrication facility of
As a further example variation, the triggering events and/or time offsets may be filtered. In one particular embodiment, both the triggering event and the time offset are filtered on the basis of an attribute of the represented manufacturing domain. Consider an implementation in which lots 130 are assigned a priority, with higher priority lots being processed through the process flow faster than lower priority lots. In such an implementation the triggering event for a low priority lot 130 may be a transition in the appointment state of a current process operation to "near complete" with a relatively long time offset. On the other hand, for a high priority lot, the triggering event may be defined as entering the "active" state with a short time offset. Or, higher priority lots 130 may schedule further ahead, on average, than low priority lots, e.g., 5-7 process operations ahead instead 2-3 process operations. These filters can be built into the factory definition in the virtual factory 1010 so that the software agents 365 do not have to actively filter.
One consequence of filtering in this manner is that a given triggering event will have associated therewith more than one target process operation. Consider the scenario in which lots 130 are assigned different priorities. Assume that the transition in appointment state to "near complete" is a triggering event. That triggering event will have several target process operations associated therewith, e.g., one for each of the priorities that may be assigned to a lot 130. Which target process operation is actually scheduled will depend on the priority of the lot(s) 130 being processed, but multiple target process operations are nevertheless associated with the given triggering event.
In the illustrated embodiments, triggering events and time offsets are previously determined and stored in the virtual factory 1010. However, the invention is not limited. Alternative embodiments may determine triggering events and/or time offsets dynamically. In addition to these classes of objects set forth in Table 5 and Table 6, these embodiments will include a "schedule ahead strategy class" of helper objects. This class will be called by scheduling agents to determine a triggering event, or a time offset, or both, in light of the current factory state and factory definition stored in the virtual factory 1010. Some of these alternative embodiments will also include a "resolver" class of helper objects to resolve conflicts raised by the schedule ahead class of objects.
Furthermore, scheduling triggers, time offsets, targets, and filters for various alternative embodiments may be defined in different ways, with different objectives in mind. For example:
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. Note that further variations not discussed may be employed in still other embodiments. For instance, if a machine has idle time to sell it may want to advertise, or, individual machines may be assigned sales quotas as a goal to meet in utilization. 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.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image