An evaluation of the behavior-based equipment model
10/01/2000
Walter Reithofer, Johnson Loo, Infineon Technologies Asia Pacific Pte. Ltd., Singapore
Roland Mueller, Uri Eshkar, ESEC SA Business Unit Factory Integration, Cham, Switzerland
overview
While SECS/GEM is the prevalent communication standard for semiconductor manufacturing equipment, it does not encompass recent developments in software engineering and networking. For example, it does not support multiple host applications. On the other hand, the proposed behavior-based equipment model or B-BEM has been developed to meet current and future industry automation needs. Here, B-BEM is compared to existing standards and used in its first implementation — a semiconductor assembly operation.
Equipment integration in the semiconductor industry is largely based on Semi standards such as SECS-I, HSMS, SECS-II, and GEM. However, these standards originated in the early 1980s and now cannot cater to the kind of complex distributed software systems prevalent in today's manufacturing sites.
 Figure 1. Various B-BEM implementation scenarios. |
Current standards build on point-to-point communications where only a single host may communicate with the equipment. They deal with bits and bytes and lack a higher level of abstraction. Implementations must depend on tools for parsing and generating byte streams. Furthermore, the standards are too open and leave too much latitude for vendor-specific interpretations. As a result, equipment integration is time-consuming, costly, and risky.
International Sematech's virtual factory equipment interface (VFEI) introduces a layer of abstraction on top of GEM, but it relies on ASCII streams that need to be passed over some kind of communications infrastructure. VFEI falls short of becoming the appropriate solution for modern distributed object-oriented systems.
The B-BEM solution
The proposed behavior-based equipment model (B-BEM) addresses all shortcomings of current communications standard and integration techniques and opts to provide a solution appropriate for modern software systems.
B-BEM is the focus of a Semi equipment integration task force that began in the fall of 1999 with consecutive meetings in Singapore, Austin, and Brussels. So far, the reaction has been very positive and encouraging. A blue ballot proposal is to be prepared for submission in December 2000. The approval of the blue ballot is scheduled for Semicon Europa 2001.
 The Semiconductor300 cleanroom at the Infineon site in Dresden, Germany. |
B-BEM offers new equipment interfaces to replace current SECS-GEM standards. The new interfaces are appropriate for advances made in software technology, namely, they allow easy integration of equipment within distributed object-oriented architectures for manufacturing systems. The selected technology is the Object Management Group's (OMG) common object request broker architecture (CORBA), but the ideas can also be implemented with other infrastructures. CORBA-based object-oriented equipment interfaces are specified using CORBA interface definition language or IDL. This allows for implementations in virtually all modern object-oriented languages, like Smalltalk, Java and C++, and all platforms. CORBA interoperability even allows for solutions with heterogeneous architectures.
The proposed interfaces allow existing equipment that has SECS-II and GEM interfaces to be integrated as is without any changes, by suggesting an adapter technology that wraps SECS-II messages as CORBA structures.
Further, different levels of spooling are suggested as quality-of-service (QOS) options.
 |
With B-BEM, the interfaces proposed are uniform over all equipment and free the implementers of factory-level applications from having to deal with equipment vendor choices. Equipment-specific details are hidden and interfaces are abstracted to the application level. The interfaces allow for multiclient capabilities, that is, equipment events can be distributed to many applications, and applications that access equipment data can be added independently from each other.
B-BEM interfaces provide abstraction. The application programmers do not need to deal with the details of communication protocols or with low-level presentations of messages (bits and bytes) that embed various vendor choices. Instead, they deal with a uniform (same for all equipment) interface abstracted to the level understood by the application.
B-BEM interfaces provide high-level communication patterns, such as query, command, and notification.
Unlike current standards, B-BEM is not point-to-point. B-BEM allows multiple applications, independently from each other, to receive notifications from the equipment, offer services to the equipment, query the equipment, and send commands to the equipment.
Applications interested in equipment events subscribe to the events they are interested in. Equipment events are categorized by aspects, so that each application can form its own view of the equipment according to the aspects it is interested in. Applications can further install their individual filters on event notifications and can specify their required quality of service. This results in reduced network traffic and simplified applications' code.
Possible B-BEM implementations
Ideally, the B-BEM should be implemented by the process equipment (Fig. 1a). However, for migration reasons, adapters can be used to map an existing equipment interface to B-BEM, such as an adapter on top of a SECS-GEM interface (Fig. 1b). It is also possible to adapt directly to the equipment's control software (Fig. 1c), which controls actuators based on sensor inputs using the sensor-actuator bus.
 |
Through the generic B-BEM service (i.e., "handleSecs2-Request(space)") that supports all SECS-I data types (see Table 1), any SECS-II-compliant message can be sent to the equipment. Accordingly, with the SECS-II aspects all registered, consumers can receive raw SECS messages generated by the equipment. Basically, this means all SECS-II streams and functions are covered. In this scenario, the benefit of B-BEM is to overcome one-to-one communications restrictions.
Wrapping SECS-II communication, however, does not abstract from particular equipment behavior. To achieve abstraction, B-BEM provides more specific services and notifications. To assess the coverage of full equipment functionality, we compare these services and notifications to GEM in Table 2 [1].
 |
B-BEM service "getProcessingState" and the notification "processingStateChanged" enable host applications to query the equipment's current processing state and to be informed about changes. A direct equivalent of the GEM functions for identification and connect is not required. B-BEM foresees more abstracted methods as shown in Table 2. Errors occurring within the adapter (e.g., due to a wrong format) are communicated to clients through the error notification aspect.
Table 3 lists communication-interface-related aspects of the GEM capabilities. B-BEM provides abstracted services and notifications corresponding to the most important GEM capabilities. Remaining capabilities (e.g., "list status variables" of the equipment) can always be realized with the service "handleSecs2Request." However, this service does not abstract from specific equipment behavior. Spooling is covered by the general QOS concept. (No equivalent, ["NE" in Table 3] one-to-one services or notifications are not a deficiency because one can always query a status variable namelist using the generic SECS-II aspect.)
B-BEM and OBEM
The standard for the object-based equipment model (OBEM) aims at providing definitions, services, and behavior for common equipment modules of which equipment is typically composed [2]. It defines a generic, object-oriented equipment model based on equipment elements, subsystems, and modules. Eventually, the interface can be derived from this equipment model (Fig. 2). Although the standard explicitly says, "... as seen through communications with the factory," it does not yet define communication details such as syntax or communication patterns.
On the other hand, B-BEM follows a more pragmatic approach; it is developed from the viewpoint of a general "host" application talking to abstract equipment, rather than modeling the object-oriented structure of the model according to its physical structure. In semantics, B-BEM follows GEM.
OBEM's more comprehensive approach might be well suited for modeling clustered equipment interfaces. However, inheriting the aggregated processing states of clustered equipment from the state models of its modules does not look very reasonable.
In general, B-BEM and OBEM focuses are similar, but their approach is different. They complement each other.
First implementation of B-BEM
ESEC created a first implementation of the B-BEM adapter that was installed at Infineon's Singapore facility. This B-BEM adapter was generic, but customized by specification. In addition, the implementation was generic, which means the same code was used for various equipment types. An instance of the adapter is customized for the type of equipment it is being used for through a specification file.
The implementation at Infineon allowed for location transparency; the adapter can run anywhere in network, and for maximum utilization, multiple instances of the adapter can be grouped to run within the same process. The location of the adapter is determined through configuration services. Other factory components locate the adapters they want to communicate with through a naming service.
Transformers are additional software components that can be added to further transform and adapt equipment messages. The transformer interface is public, so that users can easily add their own specialized transformers.
The adapter implementation is available for UNIX and NT. In addition, the adapter architecture splits the low-level communication driver into a separate component. This allows plugging in SECS-I or HSMS drivers, as well as other drivers, for proprietary protocols.
 Figure 2. OBEM vs. B-BEM approach. |
Equipment events are enhanced by system data (i.e., equipment ID, time stamps, etc.) that are provided by the adapter. The adapter also allows plugging in of a factory component that can provide a production context (i.e., lot ID, magazine ID, or recipe name). The adapter appends the production data to equipment events before further distributing them.
The adapter allows for an alternative data source for events. This feature allows plugging in a data collection application capable of supplying data not provided by the equipment (e.g., consumable materials, defect codes, etc.).
Users register for the delivery of events of the aspects they are interested in. Furthermore, users can specify filters to further narrow the events they receive. For backward compatibility and for easy integration of GEM-compliant equipment, the implementation provides SECS II- and SECS event report aspects. These aspects preserve all SECS-II and GEM capabilities of the equipment within the new environment.
The manufacturing environment
We evaluated an implementation of B-BEM as part of an assembly automation project at Infineon's Singapore facility, where the objective was to integrate eight assembly cells doing die-attach, cure, wire-bond, and optical inspection, and to integrate to a higher-level production planning and control (PPC) system.
Our major challenge was to overcome rigid cell structures imposed by the hardware. This required a completely revised, much more flexible software control architecture with particular attention to openness. In addition, an open architecture is essential to implement subsequent applications for monitoring, statistical process control (SPC), WIP tracking, recipe management, and cell configuration in a modular, component-based manner.
 Figure 3. Assembly automation project architecture characteristics. |
We found that the most important components of our assembly automaton architecture were (Fig. 3):
- the adapters to link SEC-GEM equipment and applications;
- the cell controllers;
- equipment data collectors to capture additional information from the operator that was not provided by the equipment;
- logistic controllers to control transport equipment;
- production controllers to configure cells, dispatch lots to cells;
- WIP tracking to monitor production progress and update the PPC system; and
- an on-line equipment monitoring tool [3].
Currently, the cell controllers, the equipment data collectors, the equipment monitoring tool, and the statistical process control (SPC) system are communicating directly with the equipment through the adapters [4]. To evaluate B-BEM, we followed a three-step approach to help us verify if B-BEM was suitable for backend semiconductor manufacturing and integration to test. We evaluated:
- B-BEM within the assembly line environment;
- B-BEM by connecting assembly equipment from
- equipment in the test area (e.g., mark-scan-pack and test handler).
From these tests, we have made a number of obser-vations. Because all our equipment was GEM-compliant, we found that the adapter supports all aspects according to the GEM capabilities of individual pieces of equipment. With communication driver parameters defined in a configuration file, equipment could be connected to the adapter using SECS-I or HSMS.
We tested both connections successfully.
 Figure 4. Typical service execution times for selected parameters. |
As described above, abstraction is an important feature of B-BEM. With the evaluated adapter, we achieved abstraction by mapping — defined in a "specification file" — the equipment-specific interface to generic aspects. (Specification files are text files that can be edited with any text editor or created by using a specification tool.) Every individual equipment interface (i.e., different type, software version, etc.) needed a corresponding specification file. In this process, profound understanding of the equipment's SECS-GEM interface is required. We found that the effort needed to integrate a new equipment type was in the range of several days to a few weeks.
We implemented a surveillance process that restarted the adapter automatically whenever it crashed. Since the adapter persistently maintains its consumer registry, it can continue serving without requiring any actions from the consumers.
In our evaluation, we found that it is very difficult to describe and measure performance due to the numerous influencing factors such as communication activity of the equipment (i.e., the amount of data), network capacity, available processing capacity on the computer that hosts the adapter, and the number and type of registered consumers.
 |
When we looked at execution time, we found that services could be grouped in one of two categories (Fig. 4). Services handled solely by the adapter (e.g., "getequipmentName(space)") were typically completed within 20-40 msec in our environment. The other category included services that resulted in an equipment query performed by the adapter (e.g., "getProcessingState(space)"). Here, typical values were in the range of 500 msec for the evaluated wirebond equipment and 600-800 msec for the evaluated die-attach equipment. Execution time for such services was determined by the equipment communication speed and the equipment controller performance. In general, the service execution times satisfied our requirements.
We found that in all test cases, the required communication could be realized by B-BEM; we did not identify any missing aspects. Certain problems could always be solved by using the generic SECS-II service. However, not all aspects could be tested, simply because the equipment tested does not provide or support all functionality.
Overall, we found that B-BEM itself is not a simple tool to use. To implement and configure B-BEM effectively requires knowledge about the operating system used and the network environment. Developing client applications in a component-oriented, step-by-step manner, however, can be done easily with B-BEM, in a surprisingly short time (see Table 4). Of course, knowledge of CORBA and object-oriented software development techniques is required, but B-BEM is the ultimate integration concept. Despite some initial reservations, we found that using CORBA was not as difficult as some of us had feared.
B-BEM's benefits
In the end, in using B-BEM, we found that a person engaged with integration can focus on the application, since all low-level details are shielded by the adapter. The interface provided by the adapter is on the same level of abstraction as the application.
 A presentation on ESEC's B-BEM solution. |
Since the B-BEM adapter equalizes the interface of all equipment, an effort invested in integrating one equipment type is automatically reused for all equipment types. In addition, since the interfaces provided by the B-BEM adapter are all CORBA-based, the integration engineer enjoys the freedom of choice provided by CORBA, i.e., the integration platform can be any system as long as it provides an object request broker binding.
Integration of new equipment is done by creating specification files. Since no coding is required, there is no possibility of programming errors. Since the same adapter code is reused for all equipment, it is guaranteed to be very well tested over time, and thus provides a very high degree of reliability.
The B-BEM adapter allows multiple applications to communicate with the equipment concurrently (in contrast to the point-to-point limitation imposed by existing industry standards). This allows a concurrent integration of the equipment with multiple applications (even from different vendors). Applications can be added at any time as needed.
Integration of a new equipment type with the B-BEM adapter does not require programming. It merely requires the creation of a specification file. Integration can therefore be done by application engineers who do not need to be trained as programmers.
The architecture of the B-BEM solution allows any number of adapters to be grouped to run on the same workstation. This allows an optimal utilization of resources and at the same time allows for a scalable solution, since adapters can be distributed on any number of workstations as required. Adapter location transparency is ensured by using the CORBA naming services.
The interfaces of the adapter toward the equipment are well-defined and open. This allows for easy extensions for equipment that does not comply with the industry communication standards. The open interface also allows for plugging in of alternative data sources, transparent to the integrated applications.
Since integration becomes a matter of specification, the whole cycle of coding, debugging, and testing is completely eliminated. An application engineer generates a specification with the B-BEM's equipment specification tool. The specification can then be tested with its test tool. This all leads to a very short integration cycle. Customers are not dependent on long software development cycles and release schedules.
The shortened integration cycle and the fact that no programming skills are required for integration lead to savings. Reuse of application code (the same code for all equipment) leads to another very significant savings on the application development side.
Conclusion
Through actual tests, we have found that the B-BEM concept is a powerful framework for state-of-the-art equipment integration. The concept of having a generic, configurable adapter has turned out to be a useful implementation of B-BEM. Our result in applying B-BEM to a semiconductor manufacturing assembly operation is very convincing. To date, our evaluated adapter has been used to integrate new equipment without any need to change code in the adapter.
Acknowledgments
The authors thank the assembly automation project team members, especially Gònter Mayer and T.C. Chua, who initiated and supported this evaluation.
References
- Semi Standard E30-0200A: Generic Model for Communications and Control of Manufacturing Equipment (GEM), Semi 2000.
- Semi Draft Document: Standard for Object-based Equipment Model (OBEM), Semi document 2748, Semi 1998.
- N. Haueis, M. Haller, T.K. Woi, "On-line Machine Engineering (OME)," 4th Annual TAP Conference, Semi Singapore 2000.
- G. Kleineidam, "Equipment Integration and Automation in Semiconductor Backend," Semicon Europe, Munich, Germany, 1999.
Walter Reithofer received his PhD in computer science. He is CIM manager at Infineon Technologies Asia Pacific Pte Ltd., 168 Kallang Way, Singapore 349253; ph 65/8400-765, fax 65/8400-401, e-mail [email protected].
Johnson Loo received his BE in mechanical engineering and his MS in software systems technology from Sheffield University, UK. He is a senior engineer at Infineon Technologies Asia Pacific.
Roland Mueller received his BS in computer science from the University of Applied Sciences ATIS, Horw, Switzerland. Mueller is technical consultant for the ESEC Business Unit Factory Integration. ESEC SA, Hinterbergstrasse 32, CH-6330 Cham, Switzerland; ph 41/41-749-5111, fax 41/41-749-5122, e-mail [email protected].
Uri Eshkar received his BS in mathematics and computer science from the Bar-Ilan University, Ramat-Gan, Israel, and his MS in applied mathematics from the Wiezman Institute of Science, Rehovot, Israel. Eshkar is software system architect for the ESEC Business Unit Factory Integration.