The seven deepest equipment integration pitfalls
07/01/1997
The seven deepest equipment integration pitfalls
John Garbayo, Motorola, Chandler, Arizona
Failing to meet your vendors head-on
The beginning of the tool purchasing cycle, when the long list of potential vendors is being narrowed, is the time to meet your tool vendors head-on. Usually a tool`s processing features are touted as the deciding factors. You must impress upon the selection committee the importance of the tool`s interface. Let the selection committee know that any tool with a weak interface inhibits the automation process-no matter how robust its processing capability. This is no easy sales job. Remote-to-host communication is rarely plugged in brochures or given a slide`s worth of attention during presentations. Being the advocate for tools with advanced equipment integration capability will pay big dividends later.
Planting your feet on the vendor`s floor. Once you have narrowed the field to a manageable number of prospective vendors, it is time to plant your feet on the vendor`s floor and separate the product from the puffery. Start by discovering whether the solid software capability the vendor professes is supported by a dedicated software development team. The fewer resources assigned to software development the greater potential for trouble. Ask the vendor to show you the written methodology for maintaining, developing, testing, and releasing software. A lack of documentation is a red flag. Review past software requirements documentation for completeness, and visit members of the quality control team to discover whether they are autonomous and proactive. You will also want to judge whether a revision control process is in place. Software revision control is as important as hardware engineering change management.
Be doubly wary if the equipment you are purchasing is not on-site at the vendor for testing purposes. Not having the tool on-site to recreate any malfunctions arising at your factory means having to fly in problem-solvers instead of merely phoning in problems.
Denting heads when hammering out an equipment purchase agreement
The relationship with your vendor should not be the kind of adversarial relationship typically experienced when buying a car. If you bleed a vendor and then later need improvements, getting new features retrofitted will be much harder and more costly.
The best time to form a vendor relationship is when you are poised to purchase a number of tools, rather than during an upgrade phase. When there is a lot of money and resources riding on a deal, the climate is usually sunny. If a feature does not exist on the tool you want but does exist on a competitor`s tool, vendors are highly motivated to provide it and raise themselves to the next competitive level. Vendors who do not have all the features you want may promise to provide them in the next upgrade. Be flexible and look for ways both sides can win.
When vendors begin flying out to meet you, never feel guilty about their time and expense. These meetings are beneficial to both parties. Your discussions with vendors give them insights into the features and benefits of competing products and show them what their customers really require.
After you have made your choice, contact the other vendors and let them know that though they were not picked for this contract they have an open door at your company for future bids.
Tool talk basics - to GEM or not to GEM. When drafting the equipment purchase agreement (EPA), be sure to provide all details of required communications capabilities. In almost all cases, adhere to the Semiconductor Equipment and Materials International (SEMI) Generic Equipment Model (GEM) standards. Not adhering to the GEM standards leaves you open to inconsistent tool behavior and tough going when trying to get the tools to communicate. Simply stating in the contract that the tool must adhere to the GEM standards is not enough, though. Detail the operational scenarios you expect and give examples of log messages between equipment and host. If the tool is not GEM-compatible, have the vendor list the exceptions and document what the tool cannot do, and their plan for implementing the missing capability.
The guaranteed-no-surprise tool delivery. Keep in close contact with the vendor and visit their facility periodically to conduct an on-site inspection. Get in the decision-making loop as soon as tangible progress is made, especially when early prototypes are developed. When the vendor develops what he thinks is a complete system, work with him to test it using toolsets of your choice. Provide the scripts and toolset you commonly use for testing and ask to see the log files that the scripts generate. Testing with your factory`s communication protocols is critical to a no-surprise delivery.
Got-to-have vs. want-to-have
As the leader of an equipment integration project, you are in the unenviable position of mediating what capabilities are implemented and what is promised for the next phase. Before you are blamed for dashing the desires of anxious users, let`s look at how to structure the project so there are more winners than losers.
Establish early that this is a formal project and not part of your general equipment integration duties. Gather all requirements through a requirements document, conduct the project through a development plan, and perform your scheduling through a project plan. You may get writers` cramp, but the hallway politicking will be minimized.
The people you select for your project team should be the production operators and supervisors using the tool, the manufacturing engineers responsible for processing wafers, and the equipment engineers who keep the tools up and running. You can easily determine what these people want by reading their job descriptions. Operators and supervisors want to reduce the number of high dollar decision points and automate repetitive tasks. Manufacturing wants to ensure the integrity of the product and maintain high yields and low scrap. The engineering community has an insatiable need to know whether a tool is operating efficiently and will want you to automate their qualification process for new products.
As the equipment integrator, you bring to the table a list of constraints. Don`t expect to be popular. Unless you work for King Midas Manufacturing, you will be limited by time, resources, computing power, and the capabilities of the tool itself.
Prioritizing the big payoffs. Once you get all the team members in a meeting, brace yourself for some arm-twisting and tearful pleading. This is no time to give in to emotions. Setting priorities is serious business and giving people what they want is less important than giving the factory a centrally controlled way to produce more wafers. Priorities should be:
1) to reduce quantitative loss by examining the processes and tools with the highest material losses and the highest frequency of loss occurrences;
2) to reduce the qualitative risks of loss from errors such as pushing the wrong button on a high-volume tool late in a process;
3) to determine how much faster you can make the system run or how you can pump out more product from each tool during a processing step; and
4) to provide data to help equipment engineers keep the tool stable and running efficiently (see table).
 |
As a rule, manufacturing people want to run the tools into the ground and equipment engineers want to make the tools stable and repeatable. Try to avoid getting caught between these factions. When you are trying to decide which priority is best for your factory, remember that you are in the business of manufacturing high-quality wafers at competitive prices. Everything else takes a back seat. Do whatever you can to make manufacturing easier, cleaner, safer, and more efficient. Equipment engineers will say that their priorities are just as important and if they are not met the tools won`t run. Gulp hard and promise to do what you can to meet the needs of equipment engineering in the next project phase.
Selling the steak and ignoring the sizzle
As the equipment integrator, you must persuasively articulate and clearly prioritize a course of action for progressive equipment integration at your factory. The facts will not speak for themselves. Facts and figures can be easily muted by a smooth talker who gains management support for a self-serving equipment integration project, providing lopsided benefits to one area of the factory over another. You end up implementing a solution that does little to address the critical priorities at your factory and getting blamed when factory performance does not improve. Instead of dispassionately listing features, present a concise, plain spoken agenda and choose a few key benefits in each project area to drive your points home in a convincing way. The features and benefits listed below are guaranteed to sell even the most intransigent manager (Fig. 1).
Data collection. Collecting data from metrology tools is the number one value-added project you can offer during the early phases of equipment integration. Metrology tools are placed between key processes and measure the effect a process has on product material. Without equipment integration, operators and engineers are forced to manually collect data created on these tools. Hours are spent squinting at monitors or wading through reams of printouts because there is no direct link to the factory`s statistical process control (SPC) system. Integrating manufacturing data and metrology tools delivers a huge time-savings over manually inputting data. Inputting data quickly means the health of a process or tool can be rapidly displayed and processing stopped if anomalies are discovered. The integrity of the data is assured because it comes directly from the metrology tool.
Tool process setup. Recipe setup, parameter modification, auto starting, and process monitoring are just a sampling of the things you can achieve by automating the tool process setup. By giving engineers active control of a tool from a remote, centralized computer system, setting parameters and issuing commands can all be automated. There is no need to rely solely on the operator to perform tasks correctly. Operators can be freed from repetitive, manual, and time-consuming tasks.
Standardize tool operation across tool types. Standardization through a common graphical user interface (GUI) allows all tools to operate with a degree of commonality regardless of manufacturer. Training becomes much simpler because operators encounter a familiar interface and navigation path at every tool. Operators can move from tool to tool as the need arises without experiencing anxiety about the unknown. Because operators have a uniform procedure, there is less chance of misprocessing.
Alarm and tool status notification. Imagine no longer having to depend on an operator in the area noticing the beeps and flashing lights of a tool in trouble. That is what an intelligent tool that asks for help by paging a technician or sending e-mail brings to a factory. Tool state changes, such as from running to idle, also can be communicated automatically. As tools become available or unavailable, this information can be sent to a remote, centralized computer system where intelligent routing and scheduling decisions can be made. Bottlenecks caused by scheduling product to run on a disabled tool are significantly reduced. Channeling alarm and tool status information to a centralized computer system gives engineers and managers real data about the overall health of the systems in the factory.
Recipe management. Managing and maintaining the numerous recipes used in a factory is a headache the size of Mt. Rushmore. The differences among tools and the complexities of the tools themselves often necessitate walking around with disk in hand to each tool to load a recipe. Then there is the configuration management issue: making sure the correct version of a recipe is used. Compounding the problem is the need to ensure that every tool, even tools of the same model, runs the recipe correctly. Through proper integration between the host system and a centralized computer system, recipes can be stored, managed, and the correct versions routed automatically to the tools. Moreover, by communicating with the host, an engineer can determine whether a recipe is dated correctly, has the right parameters, and is properly loaded. An automated mechanism can also verify that each run of each tool used the correct recipe.
 |
Figure 1. To determine the most critical priorities at your factory, take into account the maturity of your factory and the level of integration required.
Trying to create the perfect system in an imperfect factory
Engineers often feel the urge to build the perfect system. Too many engineers try to add more and more capability to a system until the customer`s wish list is satisfied. Any faults in the systems they build are regarded as critical, and deficiencies are pursued and destroyed wherever they are found.
It is difficult for some engineers to scale down projects because they regard a solution as either perfect or not. There is very little room for gray in their world. These engineers will go to the nth degree to make an elegant, flawless solution, but they are unwilling to release solutions with limitations - even if a less elegant system does the job.
Be miserly in the amount of capability you dole out. It is more important to deliver a timely solution than a comprehensive solution that takes several times longer to complete. Implementing a project in a month instead of three months could save millions of dollars in lost product because you stopped the bleeding in a particular area and can now move to the next high-priority area. Delivering a comprehensive set of functions for each tool in a factory could take years of effort. At that pace, by the time you get around to the last few tools, you may have to rework the initial implementations because your user requirements have changed, different products are being manufactured, or new tools have been introduced. Moreover, if you implement a lot of solutions and discover during prototyping that the information you got from users is mistaken, you will have dedicated a lot of time and resources to a misguided solution.
It is better to think Spartan. Get the highest-priority solutions out there fast and leave the rest for a later project phase. Trying to design the perfect solution is sure to cripple your project before it has a chance to take a few initial steps in the right direction.
Falling victim to the "not invented here" syndrome
One of the great myths of equipment integration is the belief that it is faster to develop a system from scratch than to take someone else`s solution and adapt it. Gathering requirements, designing a system, prototyping, developing code, de-bugging, testing, and implementation are time-consuming and resource-intensive. Anyone who argues that it takes longer to read the documentation of an existing system, install the system, and try it than to develop their own solution is suffering from the "not invented here" syndrome.
Stereotypes about other people and organizations contribute to resistance to reusing solutions. I hear claims that people at Factory 15 are naturally more capable than those old fogies at Factory 14. After all, Factory 15 is newer and privy to the latest technology. The worst offenders are often newer factories that still believe the rah-rah cheerleading of their managers when they were in their start-up phase. These factories believe that they are so special that no one outside their walls could possibly develop a solution that would fit their needs. Conversely, the established factories that have been manufacturing wafers for years feel their experience and knowledge is far superior to the new upstarts.
In very large corporations, where offices are dotted all over the country and abroad, the egocentric attitudes reach global proportions and off-shore engineers are expected to implement solutions, not invent them.
Engineers also originate solutions, instead of adopting them, because of the fun factor. Nobody is too old to have fun, and for engineers inventing something is the most fun. Taking over someone else`s application and living with the way a stranger thought a solution should behave is a labor of loathing. Engineers look at an inherited solution as a big black box whose inner workings are a dark mystery. But if the solution is well documented and you can observe its effectiveness, why develop a new mousetrap when an existing mousetrap can do the job?
Sometimes management unwittingly fosters resistance to reuse of technology. By allocating abundant resources for original development and by showering accolades on the developers of new solutions, management creates a multiheaded serpent that consumes most of the development money and monopolizes development time.
What can be done to foster reuse of technology? For a start, incentives for reusing technology and reuse-award programs would do much to advance technology transfer among organizations. Conferences and communications among equipment-integration user groups would allow people to share their successes and failures. Because such user groups are job-based and not technology-based, a sense of camaraderie will develop and help calm the furor that sometimes surrounds the use of one toolset above another. Management can further discourage the evangelical zeal some engineers have for a toolset by offering cross-training in different technologies. Cross-training would encourage engineers to seek solutions that are not technology-bound but are driven more by implementation and functionality.
Once an organization overcomes the initial resistance to begging and borrowing of technology, it will discover that transferring solutions is a very effective way to jump start projects. With all the solutions available, an organization cannot afford to begin a project without first tirelessly searching for existing solutions.
Lost on the documentation paper trail
Most projects rush to the finish line designing, coding, testing, and implementing until just prior to release, when someone says, "Blast, we forgot the documentation!" A technical writer is called in and told, "This product is ready to go, the only thing holding up the release is your documentation." Now the unfortunate technical writer must get up to speed and get the document out pronto. Everyone is wringing their hands outside his door and pointing in his direction whenever the customer asks why the solution has not been delivered. The documentation is pushed out of the door without the depth to drown a salamander.
Documentation is often the orphaned milestone left to fend for itself because it is not considered an important part of the project. Get technical writers involved from the start (Fig. 2). Bringing them in as the rearguard does not allow time to understand the intricacies of the project. Documents that are more fluff than content result, forcing users and customers to go back to the source to answer questions.
 |
Figure 2. Equipment integration software development process. A solid software development process typically guides all aspects of an application`s life cycle.
Documentation can make or break an application`s usability. As any commercial vendor will attest, users will not feel comfortable unless an application comes packaged with an online, context-sensitive help system, updated release notes, and operation tips. In fact, most commercial applications provide volumes of paper manuals and tutorials along with their online documentation. Although your customers are usually internal, you still want to give them the same documented support for the same reasons as in commercial applications - you want them to be self-sufficient.
It is not enough to have thorough documentation, though: users need an effortless path to get to it. In this regard, online documents are a huge plus. As a provider of integrated solutions in a cleanroom environment, you should furnish users who are already using computers with online documents. Online documents also allow you to illustrate your words with colorful text and graphics, as well as bundle a training mechanism and a quick reference guide together. Furthermore, integrating online documentation into a system to which the user has easy access puts the document near the tool they are operating.
Plan B
If you were already in a deep hole when you began this article, get ready to cut your losses and take your lumps. The first step on the road to recovery is the most painful. Admit to yourself and your project team that some time and expenditures have been lost. Then step back and retrench so you can move forward in a more reasonable direction. Don`t be afraid to abandon some of the work you have done in order to go back and do it the right way. Expect a lot of pressure to continue on the current path, but by doing so you may dig a bigger hole for yourself.
Million-dollar pitfalls, such as choosing the wrong tool, are a little trickier. If you tell your managers that you are going to step back and retrench, they will tell you to - well, you know. Work closely with the vendor and the engineering community at your factory to fix whatever is wrong. After all, you are engineers and what engineers do best is fix things and come up with creative solutions. On the bright side, I have never known any engineering issue to last more than a few weeks. With all the mind power, resources, and energy within an organization, there is generally nothing that cannot be solved as long as there is a spirit of cooperation on both sides. Good luck and watch your step.
JOHN GARBAYO, P.E., CMfgE, received his master of science degree in manufacturing systems from Carnegie Mellon University. He is currently the factory automation section manager at Motorola`s MOS 12 semiconductor manufacturing facility. He has spent more than 10 years developing and implementing computer integrated manufacturing (CIM) systems. Motorola MOS 12, 1300 North Alma School Road, Chandler, AZ 85224; ph 602/814-3863, e-mail [email protected].