The E-Manufacturing Domino Effect
Howard Ignatius Electroglas Inc., San Jose Tom Simas Statware Inc., Corvallis, Ore. -- Semiconductor International, 7/1/2001
| At a Glance |  | ||
|
| ||
| |||
What is missing is closed-loop process control. Yes, individual tools are automated, but the complete process is not. In fact, we are very far from that goal. In this article we map out the path we still have to travel.
Surprisingly, we do not believe we will have to develop any novel technologies; just apply a number of existing technologies borrowed from other endeavors. The central technology that we need to apply is the thin-client networking approach that has made the Internet so successful. Applying Web-derived solutions to everything in sight will not get the job done, however. To reach the goal of closed-loop automated semiconductor processing in a cost-effective way, we must selectively apply Web technology for best effect.
The first step in implementing Web technology is bridging the gaps between islands of information existing as separate databases in process tools. The second step is analyzing that data to extract useful information. The third step is feeding that useful information back in the form of process-control decisions. Web technology developed for the Internet provides the tools to make it all happen.
To guide our selection and application of Web-based solutions, we use a data-centric approach. Semiconductor process tools generate terabytes of data. Almost any question you might ask about how to fabricate semiconductors can be answered by referencing this enormous data set.
Closed-loop process control will work if we can capture new data that describe the process as of right now, and analyze them against the background of historical data that describe how the process behaved in the past. That analysis will drive decisions that we can feed back to control the process in the immediate future.
Data, data, who's got the data?
The problem, however, is that this data is scattered throughout the fab in dozens of largely incompatible data sources and archives. Each source is stored in a different location and likely has a different format and file structure. The software means of extracting data from these sources typically varies from source to source as well.
|
| 1. A semiconductor e-manufacturing system breaks into three areas. The data area contains all the data sources. The business logic section contains the data servers that mediate the flow and analysis of data moving to the presentation area. |
Each piece of semiconductor processing equipment carries its own files describing what it did to each lot of wafers and when, as well as the result of those efforts. This historical data is archived in various places depending on the particular information-technology strategies followed by different enterprises. Historical data for any given lot might be scattered throughout archives on the process tools that did the work. It might have been uploaded to a central data archive. Any given fab most likely has some combination of these extremes.
A number of other manufacturing and management functions also produce data that will be critical to achieving effective closed-loop process control. For example, it makes no sense to control the fabrication process without access to the volume of parts that process needs to produce. That information comes from the order processing functions.
The first task is to provide access to this data from a central location. Naively, one might imagine the best approach to be collecting all of the data in a central location with a common format, search engine, etc. That looks good until one realizes the size of the data store necessary.
The next idea that might seem good at the time is picking and choosing the important data to pull into the central warehouse. The problem with that approach is deciding which data to pull in. How do you know what data will be useful next week? Or next year?
Then, you have to figure out how to keep the data warehouse current. In fact, since we are working toward closed-loop process control, the data will never be current enough for our purposes.
A final objection to a centralized data store is that the reason data is being collected in various locations is because users in those locations need it. These users don't want to give it up, so the large data store would only duplicate what is already available elsewhere.
The solution is to leave the data where they are and provide directions to them from a central location. The data servers in the business logic area of Figure 1 need only to know what data are available from each data source, how to ask for them, and how to parse them into its own standard format.
The currency-of-data issue evaporates with this strategy. If a process engineer, for example, wants to know the yield of the last wafer lot tested — or even the yield so far of the lot now under test — on Test Station #3, the data servers know how to ask for it. The data returned will be the very latest available anywhere.
With this strategy, data can be collected from the sources on an as-needed basis. There is no need for guesses about what information will be needed by whom, for what purpose or when. All of the information collected anywhere in the organization can, in principle, be made available on an as-needed basis to anyone else in the organization.
Of course, this brings up the first security issue. Some information may not be for public consumption. Human resources, for example, may be willing to make "public" (that is, within the enterprise) information about who was working on what shift in the past, but a lot of other information should be kept confidential within the department. While these details have to be worked out as part of setting up the business logic part of the system, the technology is available and well understood.
At this stage, we still have humans in the loop. In fact, we have a lot of humans in the loop! These humans sit across a firewall from the data servers. Examples of humans who need access to the data are:
• Process machine operators, who need to know what to do next. What lot needs to be loaded next? Do the probes need to be cleaned? What recipe needs to be downloaded?
• Process engineers, who need to know which lot is where and what is happening to it. Are there any bottlenecks on the line? Is yield improving, declining, or staying the same?
• Maintenance managers, who need to know when they can shut down ion implanter 6 to replace the roughing pump. Are there any incipient contamination problems? When is the best time to change the HEPA filters in Unit 12?
• Fab managers, who need to know if production is keeping up with orders. What can we expect for the current lead time? When will we be shipping the parts for purchase order 12345? Do we have enough unpatterned wafers in stock? If that flu bug that's going around hits the second-shift crew, how will that affect production?
• Company executives, who need to know the current ROI. With projected sales increases, how long before the fab reaches capacity? How much do we budget for capital equipment next year? How much profit will we report next quarter?
• Salespeople want to know when their customer's order will be shipped, and they want to know right now because they're calling on their cell phone in their car pulling into that customer's parking lot.
Think thin (clients)
We recommend the so-called "thin-client" version of the client-server network model. In the thin-client version, all of the application-specific software needed to assemble a presentation report for the user resides on the server. This is opposed to the "thick-client" version, where each client runs its own application software and all the server supplies is the data to be presented.
The thin client's most obvious advantage is that all clients have all the software they need to do the job. All they need is a Web browser, and virtually every computer sold today comes with a Web browser installed.
Equally important is the fact that virtually everyone who needs the data our system will provide has sufficient familiarity with Web browsers to use the technology successfully. No special knowledge of computers, networking or the particular application software is needed. On the other hand, the technology is available for more sophisticated users to customize the presentation they receive.
A thin-client advantage that is often overlooked arises when the inevitable changes in application programs come about. When IT makes even a minor change to application software in a thick-client environment, it has to distribute changes to every user individually. The richer the client-side environment — with many different users with a wide range of data and presentation needs, and disparate local hardware and software resources — the more difficult this distribution task becomes.
Finally, Web-based technology includes the firewall security mechanisms needed to make sure the client gains access to only the data authorized for its use. The same password-protection systems provide a means of tailoring the presentation to the particular user's needs.
An executive, for example, won't have to sort through a long list of reports designed for engineers, middle managers, maintenance personnel, etc., to get to the particular report he or she wants. The system will recognize that person's password as, say, vice president of finance, and will offer only those reports geared to his or her particular information needs.
Note also that many of the advantages thin-client Web-based technology has for passing data between the business-logic and presentation sections are also relevant for transfers from the data section to the business-logic section as well. There, the data sources are the servers, and the data servers run the browser software.
For example, if each prober has the capability of transcribing the data from its tester into a standard wafer-lot-test-report format, then adding a tester requires no significant alterations to the software in the business-logic section. It just means that the data servers (which are now the thin clients) have an additional IP address from which they must request a wafer-lot test report.
1. The user, sitting at a local computer, initiates a request for a particular report from the data servers through the Web browser, perhaps by selecting it from a customized menu.
2.The data servers (which have previously validated the user's identity and right to access the particular data in the report) determine which data sources have the data needed for the report.
3. The data servers make individual requests for particular data from the appropriate data sources.
4. The data sources call up the data and package it in the particular form in which the data servers expect to receive it from that source. Test data returned by probers would have a format appropriate for test data, while facilities-loading information would be formatted in an entirely different way.
5. The data servers, upon receiving all of the information needed to make the report requested, proceed to develop the report. This will likely require analysis of data as well as simple reformatting. For example, the report might include a cross-correlation of average wafer-lot yield with a measure of facilities loading.
6. The data servers then write HTML code for the finished report and return it through the firewall to the user's local computer.
7. The browser finally displays a Web page based on the HTML code returned.
Now that you've got the data, what can you do with it?
The thin-client model falls down in one important area, however. It is completely demand-driven. That is, before information can be passed to the client, the client has to request it.
Web technology supplies the answer to this challenge as well, in the form of e-mail. The data servers can run an application that monitors selected data developed by the process tools, or the process tools can run such an application themselves. The application can produce alarms based on a set of rules.
Suppose, for example, that a fab manager, who at the moment happens to be off-site at a conference, has set up a rule for the system that says he wants to be notified should any lot's yield fall below 95%.
With the tools we are proposing here, an application would run on the data servers that looks at the bin data for each lot as the test completes. If the yield for any lot comes in below the threshold, the system notifies the manager via his PDA address that this particular lot has violated the limit.
Being physically removed from the fab, he would have to, perhaps using a laptop, remotely dial in to the factory intranet, requesting a report that might give him a quick appraisal of the situation. Being off-site, he might have to use encrypted communication, similar to the systems used in e-commerce transactions.
| 3. Control charts can tell a manager at a glance whether a particular excursion past a control limit signals a serious process problem, or is just a statistical fluke. |
Web-based technology made sure the right message got to the right person to maintain process control in a timely fashion.
The ultimate goal
At this stage, we will have developed a system to ensure that the information is available as needed. The next step is to use that system to automatically tell the tool to make a correction even before notifying somebody about it. Taking this step achieves closed-loop feedback for the process. Based on the same rules humans would use to make process-control decisions, expert systems running on the data servers can, under well-defined conditions, bypass humans in the process-control loop.
No longer does the process have to wait for the process manager to answer his PDA message, request a report, contact the fab, get other people involved and so forth. Using the same logic on data immediately available, the data servers can effect closed-loop process control. What this automated closed-loop process control system can do is only limited by the data and inference algorithms available, and the command set available to control the process tools externally.
For example, a statistical bin-limits algorithm looks at a rule set for a lot. It expects the yield to be within a certain range, say 75-85%. If the yield falls outside that range, the rules say that the tool is to change how it processes the wafers.
Further suppose that in this particular case the wafer-level test (to save test time and cost) covers only 15% of the wafer. A few bad devices will slip through wafer sort, but they will be picked up at final test. If the yield on the tested portion of the wafer falls below the 15% rule, too many bad devices will be run through the rest of the process. That will lower the yield at final test enough to eat up the savings from the abbreviated wafer-level testing. The expert system can alter the test program to include the entire wafer and produce a die-sort map that will allow subsequent process tools to package only known good dies from that wafer.
Making such a decision would be impractical micromanagement with humans in the loop. Automated closed-loop process control — made possible by applying Web-based technology to a fabwide information system — will make it eminently practical.
The vision described here will not become reality tomorrow. There are many components that have yet to be put in place. At present, all of the enabling technologies exist. Some of the tools are already available, embodied in existing software products and semiconductor processing equipment. Much of the network infrastructure is in place in today's fabs.
The work that needs to be done is at the system-integration level. We need to use the tools we have to build the system. In the process, we will have to learn many lessons, but observing what has been done in other industries can shorten the learning curve.
The security issues are similar to those already being faced by the financial services industry and they are now being faced by the pharmaceuticals industry. PDA-based alarms have been applied in the food distribution industry.
The technologies we propose applying to the semiconductor fab information system are not rocket science. They are proven technologies waiting to be applied here and, once applied, will create a domino effect that will result in breakthrough improvements in efficiency and yield in semiconductor manufacturing processes.
 |  |
|  |
