Automation, integration and data management for the back end
11/01/1998
AUTOMATION, INTEGRATION, AND DATA MANAGEMENT FOR THE BACK END
Franz-Peter Steiner, Uri Eshkar, Carsten Seibert, ESEC Systems Division, Cham, Switzerland
A comprehensive solution to the demanding automation and integration needs of test, assembly, and packaging - semiconductor manufacturing`s back end - is essential to improving fab productivity. From extensive experience with field-proven automation systems and customer feedback, here is a proposed architecture for future test, assembly, and packaging manufacturing environments. This architecture accommodates the qualities most valued by the industry, such as modifiability, integration ability, availability, time-to-market, and others. It is based on state-of-the art software and accepted standards, and it incorporates a built-in evolution path with defined "quanta" of user benefits and functionalities.
Integrated automation of semiconductor manufacturing`s back end (test, assembly, and packaging [TAP]) is no less demanding than its front end. On the contrary, while wafers maintain their "in-process material" identity in lots, materials in the back end change appearance, composition, and context on their way through production. Indeed, the management of production logistics in the back end must address the diversity of materials to coordinate work in process (WIP), planning, scheduling and schedule execution, logistics control, process control, data collection, and equipment monitoring. Factory-wide systems that accomplish all of these functions efficiently are major productivity enablers, contributing more to improved product quality, reduced cycle times, and increased equipment use than throughput optimization of isolated individual equipment. We believe that consistent architecture is the bedrock for the success of such a factory-wide system [1].
The conventional back end
Any attempt to address TAP automation requires a clear understanding of conventions in semiconductor manufacturing`s back end today. For example, equipment is typically optimized to run its given process independently - stand-alone systems in a functional layout. Material travels on carts from one process to the next. The amount of material travelling in a unit is designated as a lot or a sublot, typically several magazines. Tracking such units is straightforward and often done by hand and paper travellers. However, because a whole unit has to be processed before being transported to the next process step, this method is not very efficient.
The logic is that partitioning a lot into smaller units that advance independently through the various process steps reduces WIP and cycle time. A material transfer unit between equipment in the back end is the material within one carrier, such as a slotted magazine. Within a piece of equipment, it could also be a single leadframe strip, a boat with singulated devices, or even an individual device. In modern TAP manufacturing, the material belonging to a single lot is concurrently being processed in parallel on multiple machines. Therefore, the unit being tracked is the smallest transfer unit being dispatched individually to a machine. The transfer unit, therefore, does not usually equal the lot delivered from the front end, and may change several times throughout TAP operations.
On many TAP machines, for example wire bonders, material is moved from one carrier into another one. Thus, the association of material to carrier is volatile. This disqualifies the carrier from serving as an identifier for the material it carries. A more sophisticated tracking system is required that monitors all carrier changes happening during processing.
In more advanced manufacturing concepts, some of today`s back-end operations are in transition to machines clustered into cells, and these are connected to a manufacturing execution system (MES). But often the equipment involved lacks important qualities to support this advance. For example, most back-end machines do not track material, jobs, or other computer-integrated manufacturing (CIM) and factory automation needs; reports originating from the equipment do not contain material- or job-related data. At best, they might contain information about carriers, such as magazine identification of the material being processed. While product mix policies are specific to a given manufacturer, it is often typical for TAP subcontractor operations to have a high mix of smaller volumes of packages being manufactured concurrently.
TAP equipment has large differences in throughput. A single die attacher, for example, provides work for many wire bonders. Changeover (retooling and setup) for TAP equipment is usually time consuming and must be accounted for when optimizing the work flow. The variations in product mix and the large amount of WIP within a TAP operation may cause scalability difficulties, because optimization efforts grow exponentially with the size of the problem.
Due to the limited equipment capacity for individual process steps, bottlenecks form and restrict throughput. Although cycle-time reduction should be the goal, equipment utilization is often the parameter being optimized in order to make best use of capital equipment.
TAP equipment communication is based on the SEMI equipment communications standard (SECS) and the SEMI generic equipment model (GEM) standard [2, 3]. Although widely accepted, these standards leave too much open for interpretation and equipment vendor decision. This impedes uniform handling of equipment by the system. The standards are also archaic, representing software technology of the early 1980s. Inadequacy of communication standards makes TAP (and also wafer fabrication) equipment integration the biggest nightmare of all manufacturing systems.
Qualities
As we set out to define a suitable TAP automation and integration architecture, we found that a successful factory-wide system is one that answers technical requirements and offers a number of qualities [4]. However, no system can enjoy the best of all qualities, since different features are often in contention with each other; a successful architecture must represent a sensible trade-off. Our expertise in this area and feedback from customers involved with back-end operations revealed the right qualities to favor:
* Modifiability is the ability to change and extend the system quickly and cost-effectively. This quality is extremely important for a system with ever-changing requirements arising from new production needs, including new technologies, process equipment, materials, and work procedures. Our experience shows that modifiability is the most important quality in TAP manufacturing systems because it protects the user`s investment.
* Integration ability makes separately developed components work together. The system must cost-effectively integrate equipment from many suppliers, as well as new and legacy commercial or in-house MES.
* Scalability is the ability to use the system when the site grows in size, without having to compromise other qualities such as performance or usability.
* Usability means an intuitive, friendly, user interface, easy to learn, and easy to operate. It also means a system that is resilient to operator errors.
* Availability measures the proportion of time the system is up and running. In distributed systems such as a cell-based shop floor, availability in the classical sense is not defined.
A different metric has to be found such as throughput at bottle-neck equipment.
* Reduced cost refers to the cost of the system itself (capital investment, installation, and training of the work force), its maintenance and operating cost, as well as the protection of investment through the ability to adapt to future needs.
* Reduced risk involves ways to improve predictability when spending large amounts of money, time, and resources on a system. A robust, production-proven system with wide market acceptance and feedback usually bears less risk than a prototype. Our phased or quantum-based approach, which is explained at the end of this article, certainly exhibits less risk than dealing with a bulk project.
* Reduced time-to-market means that production needs and competitiveness require fast solutions. Even good solutions miss the point if delivered too late.
 |
Figure 1. Proposed TAP system architecture: MES (manufacturing execution system), FLC (factory logistics controller), FPC (factory production controller), TX (transfer executor), CC (cell controller), B-BEM (behavior-based equipment model), Eq (equipment, including transport resources), and EqDC (equipment deficiency compensator).
Design guidelines
We believe that achieving this list of qualities in a factory-wide automation architecture requires the application of certain best practices:
* distributed, object-oriented software design;
* no proprietary protocols, i.e., software must be based on standards such as SEMI SECS/GEM for communication, common object request broker architecture ([CORBA] from the Object Management Group [5]), or "middleware," etc.;
* well-defined, open interfaces;
* component-based, modular architecture;
* abstraction and customization;
* hierarchical architecture;
* separation of concerns, i.e., functionality has to be implemented and encapsulated in the appropriate component, not spread over several modules;
* manageable, phased approach, i.e., no large bulk project; and
* accepted products, not customer- and site-specific projects.
Proposed TAP system architecture
We conceived the proposed system architecture outlined in Figure 1 by strictly adhering to the "best practice" guidelines above. This architecture is component based; the various system functions are classified into a number of components. Thus, the overall complexity of the system is partitioned into manageable, functionally coherent entities. Components communicate using open and well-defined interfaces.
Communications
We selected CORBA as the common infrastructure for intercomponent communications. The CORBA standard allows interoperability of products because it is independent of vendors, programming languages, and hardware platforms. Compliance to the standard allows easy replacement of implementations. Thus, CORBA is the backbone of our proposed distributed system architecture for TAP. All interfaces among various system components are specified in a uniform way using CORBA interface definition language (IDL).
"Wrappers," a well-known, object-oriented design pattern [6], are used for components that are not CORBA compliant. For example, the behavior-based equipment model (B-BEM) adapter shown in Figure 1 is a wrapper (this is covered in more detail below) [7].
Separation of concerns and layering are also important features of the proposed architecture. The architecture is modular with each component encapsulating a well-defined set of behaviors. The components represent a natural layered hierarchy starting with physical equipment (through the B-BEM equipment interface layer), cell controllers (CCs), shop-floor production and logistics, up to the MES. All system functions are implemented at their appropriate layer - each layer may only depend on a lower, not higher level. In addition, separation of concerns, standard middleware, well-defined interfaces, and layering are key enablers of system modifiability, integration ability, and scalability.
B-BEM
The architecture presented here uses the B-BEM as a generic equipment integration framework [7]. Among other attributes, B-BEM provides a uniform CORBA wrapper to GEM equipment. It also allows concurrent access to equipment data by multiple applications, using the uniform B-BEM IDL interface.
B-BEM also defines the CC-related aspects, such as scheduling and dispatching policies, equipment command and control, visualization, and material-tracking patterns. The abstractions provided by B-BEM empower the integration of new equipment into the cell by means of specification, rather than adding equipment-specific code to the CC.
The B-BEM adapter is used to integrate SECS/GEM equipment into the manufacturing system. It provides an IDL-based, object-oriented interface to the equipment, shielding and abstracting the problematic GEM interface in a uniform way from the rest of the system. The adapter is generic and customizable. This means that to integrate a new type of system requires customization of the generic adapter rather than the crafting of new adapter code from scratch.
Equipment deficiency compensator
The equipment deficiency compensator (EqDC) provides an alternative data source for data flows that should ideally originate at the equipment.
Conventional TAP equipment software focuses on equipment command and control and on process optimization, while largely ignoring data collection. Current standards, such as GEM, also fail to provide clear guidelines to equipment suppliers about the data that need to be collected. Often the data are customer or even site specific, making equipment suppliers reluctant to add the functionality required by customers. The situation is, of course, not uniform for all manufacturers and equipment models. Different equipment varies in data collection capabilities, which adds complexity to the challenge of handling all equipment in a uniform way.
Our proposed architecture emphasizes the separation of concerns. Equipment deficiencies must therefore be compensated on an abstract level equivalent to the equipment rather than in the MES, thus preserving the coherency of other system components and sustaining transparency. EqDC does exactly that, which results in multiple advantages such as simplicity, enhanced usability and integration ability, and, above all, transparency. Transparency means that functions can migrate from the EqDC to the real equipment as they become available, without the need to change any other system components.
In the back-end operation, fixture tracking, machine-engineering codes, rejects and adjusts, and in some cases, material-tracking functions, for example, could all be supported by an EqDC acting as their data source. The EqDC application could reside in a PC assigned to a single piece or a group of equipment if easy access to the user interface was possible. More sophisticated implementations could also run on mobile platforms such as hand-held, wireless terminals.
Shop-floor production
Our proposed production control is hierarchical. The factory production controller (FPC) provides a single access point and abstraction for shop-floor production. It offers services for materials and product registration and is responsible for shop-floor-level optimization and dispatching material and production instructions to individual cells.
The FPC also provides shop-floor configuration services, such as the allocation of equipment to cells matching production requirements. The flexibility to configure cells is especially required to allow optimized process flows for shorter lead time. Equipment can be re-allocated from one cell to another without affecting production.
The FPC is operated by a shop-floor worker through its graphical user interface (GUI) or, alternatively, by the MES through its application program interface (API).
A cell is defined in compliance with the definition given by the SEMATECH official dictionary [8]; it is a group of equipment and other resources that operates autonomously to add value to a process. A cell integrates several pieces of equipment, receives material and production instructions, and implements its own scheduling and schedule execution to optimize the production using its resources.
The CC provides equipment command and control and implements models that provide detailed material tracking on the equipment. The CC is thus the source of accurate WIP data (i.e., lot history). It also provides optimization of the planned production load in lot-start order and commands dispatching of individual carriers or transfer units of a production lot onto multiple parallel process machines. For this, it has to take into account the current and anticipated WIP situation and equipment availability.
Similar to the FPC, the CC is controlled by an operator through its GUI or by a higher-level system through its programmatic API.
The CC allows for configurable layouts to match various production scenarios, for example, functional groups of equipment or technology-based groups. A recent trend in TAP production is the migration toward technology-based or modular cells [9, 10]; the concept of technology-based production is very well supported by the cell concept.
The CC that we present is an evolution of a predecessor CC for ESEC`s Autoline, a pioneering automated assembly line. Its internal design largely follows the SEMATECH CIM framework architecture [11]. While based on a field-proven product, the proposed CC becomes generic and widely applicable within TAP operations.
Shop-floor logistics
Material transport from one piece of equipment or buffer to the next, within a cell or between cells, involves shop-floor logistics. An operator can execute material transfers manually. Automated material handling, however, offers significant advantages in terms of reducing human labor and error, and improving work optimization; material handling can be accomplished via a track robot for transport within a cell or via a monorail shuttle between cells. The latter can be adapted to various shop-floor configurations using either floor- or ceiling-mounted rails or a combination of both.
In our architecture, factory logistics is separated from the production process, allowing cell boundaries to be arbitrary.
The factory logistics controller (FLC) encapsulates information necessary to carry out specific transport contracts from individual transport resources. Other components of the system that commission contracts need not be aware of the availability and lay out of the transport resources.
In our approach, transport resources are integrated into the system using a B-BEM adapter identical to the integration of process equipment. A transfer executor (TX) abstracts specific aspects of transport resources, such as job creation and management, as well as specific behavior, such as the ability to execute multiple transfer jobs simultaneously. The FLC addresses all transport resources in a uniform, consistent way through their respective TX, be it a track robot, monorail, a human operator, or an automated guided vehicle. This allows the system to be extended to incorporate other types of transport resources as needed.
 |
Figure 2. Overview of the AIM quantum approach. "Quanta" represent clearly defined packages of benefits and functionalities. The three paths can be pursued independently.
MES
The proposed architecture recognizes the importance of MES; it is recommended, but not required. As the top-level component in the layered hierarchy, the MES depends on other components and layers, but no component depends on the MES.
No assumptions on the nature and choice of MES are made. The architecture diagram also implies that MES is not a monolithic block, but rather a subsystem with an internal structure. The MES of choice could be a commercial product, a site-specific product, a corporate system, or any mixture of these. CORBA interfaces are still not provided by many commercial MES products. Therefore, bridges or compliance wrappers are necessary to integrate such a MES into the architecture we propose.
A quantum approach
Reduced cost and risk, and short time-to-market are the important qualities for a good approach. We developed the proposed automation, integration, and data management (AIM) architecture as a "quantum approach" to answer these qualities; it provides a phased implementation where progress can be made on three paths: transport automation, data integration, and data management (Fig. 2).
The proper method for implementation involves identifying functional quanta for each track and establishing a dependency tree among quanta. An AIM quantum represents an apparent leap in system functionality. AIM defines the possible paths for system evolution. The conclusion is that evolution can proceed on the three tracks independently, adding one or more quanta at a time. The AIM diagram demonstrates, for example, that the B-BEM technology perceived as a quantum is the basic prerequisite for the data integration track.
Conclusion
We have presented a system architecture for TAP automation in semiconductor manufacturing, structuring the design of this architecture around needed qualities. Development involved identifying key enabling components, such as CORBA, the B-BEM, the EqDC, and the uniform integration of various transport resources. The architecture can be implemented in steps to reduce cost and risk, and shorten time-to-market of significant deliverables. n
Acknowledgment
The authors acknowledge customers of ESEC Autoline, whose requirements for better automation solutions helped to promote the ideas presented, especially Siemens Semiconductors for its joint effort to implement these ideas within the scope of the TAPIA project. We also acknowledge all employees of ESEC`s Systems Division for their individual contributions.
The content of this article was originally presented at the Fourth International Assembly and Packaging Foundry Conference (APCON `98), September 17-18, 1998, organized by Semiconductor Technology Center Inc., Neffs, PA.
References
1. F.P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1995.
2. SEMI E5-1296, SEMI Equipment Communications Standard 2, Message Content (SECS-II).
3. SEMI E30-1296, Generic Model for Communications and Control of SEMIEquipment (GEM).
4. L. Bass, L.P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.
5. Object Management Group, web site www.omg.org.
6. E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-oriented Software, Addison-Wesley, 1995.
7. U. Eshkar, "Behavior-based Equipment Model: A Novel Approach to Equipment Integration," presented at the 2nd Annual SEMI TAP Automation & Integration Conference, February 1998, Mesa, AZ.
8. SEMATECH Official Dictionary,web site www.sematech.org/public/dict/c_to_ch.htm.
9. J.M. Padillo, J.W. Fowler, "Designing Back-end Semiconductor Facilities: A Methodology and Performance Evaluation of Layout Philosophies," presented at the 2nd Annual SEMI TAP Automation & Integration Conference, February 1998, Mesa, AZ.
10. M. Paredes, P. Thomas, "A Precursor to the Integrated, Hard-linked Work Cell: The Transition from a Functional Manufacturing Environment to Small Business Units," presented at the 2nd Annual SEMI TAP Automation & Integration Conference, February 1998, Mesa, AZ.
11. "SEMATECH Computer-integrated Manufacturing (CIM) Application Framework," SEMATECH Technology Transfer 93061697F-ENG, V1.3, January 1996.
FRANZ-PETER STEINER received his diploma and PhD in physics from the Swiss Federal Institute of Technology (ETH Zurich). He has eight years of experience in front-end and back-end semiconductor manufacturing and microsystems research. Steiner is director of the Systems Division at ESEC SA, Hinterbergstrasse 32, CH-6330 Cham, Switzerland; ph 41/41-749-5709, fax 41/41-749-5122, e-mail franzpeter
URI ESHKAR received his BS in mathematics and computer science from the Bar-Ilan University in Ramat-Gan, Israel, and his MS in applied mathematics from the Wiezman Institute of Science in Rehovot, Israel. He has 18 years of software engineering experience, including 6 years working on automation systems in the semiconductor industry for both wafer-fab and back-end applications. Eshkar is a software system architect at ESEC`s Systems Division. He can be reached at e-mail [email protected].
CARSTEN SEIBERT received his diploma in technical computer science from the Berufsakademie in Stuttgart, Germany. He has five years of experience in software engineering and application development in various software disciplines, including financial systems and manufacturing. Seibert is responsible for integration architecture within ESEC`s Systems Division. He can be reached at e-mail carsten.