Enhancement of semiconductor equipment ... - IEEE Xplore

3 downloads 0 Views 157KB Size Report
equipment driver (WED) that uses mobile object technology. Initially, a mobile object model with a Java applet, namely WED, is developed. WED is constructed ...
372

IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING, VOL. 14, NO. 4, NOVEMBER 2001

Enhancement of Semiconductor Equipment Communications Using a Web-Enabled Equipment Driver Fan-Tien Cheng, Senior Member, IEEE and Meng-Tsang Lin

Abstract—Equipment communications are essential for semiconductor manufacturing automation. Equipment managers generally function to communicate between the manufacturing execution system (MES) and equipment. Connecting a different machine to the equipment manager requires modifying the associated equipment driver (ED) accordingly, which needs some efforts. To solve this problem, this study proposes a novel, web-enabled equipment driver (WED) that uses mobile object technology. Initially, a mobile object model with a Java applet, namely WED, is developed. WED is constructed on the equipment (server) side. Then, the equipment manager (client) downloads WED via a web browser. This process does not need to modify ED. Subsequently, the equipment manager can communicate with the equipment by either the Java socket technology using the high-speed SECS message services (HSMS) standard or the object web technology through the common object request broker architecture (CORBA) or distributed component object model (DCOM) protocols using the object-based equipment model (OBEM) standard. This proposed scheme has been successfully implemented. Illustrative examples reveal that the proposed mobile object model and WED establish a novel, efficient, and versatile scheme for semiconductor equipment communications. Index Terms—Mobile object technology, semiconductor equipment communications, web-enabled equipment driver.

I. INTRODUCTION

A

SOLID equipment communications infrastructure must exist before full automation of a semiconductor processing production facility. Therefore, most semiconductor manufacturers will make efforts to adopt and/or improve the technique of equipment integration and communications. Recently, automated equipment managers were developed to serve as the communication bridges between the components of a MES and the equipment [1], [2]. The functions of an equipment manager include monitoring/controlling machine status in real time, collecting engineering/production data and errors/alarms automatically, uploading/downloading and managing recipes electronically, etc. In general, all semiconductor manufacturing tools need to follow the SEMI SECS/GEM standards [3] to interface with the equipment manager and MES. These standards include the semiconductor equipment communication standard (SECS-I, Manuscript received October 21, 1999; revised May 7, 2001. This work was supported by the National Science Council of the Republic of China under Contract NSC-89-2212-E-006-042 and Contract NSC-89-2622-E-006-004. The authors are with the Institute of Manufacturing Engineering, National Cheng Kung University, Tainan 70101, Taiwan, R.O.C. Publisher Item Identifier S 0894-6507(01)09771-8.

SECS-II), high-speed SECS message services (HSMS), and generic equipment model (GEM) [3], etc. The transmission rate of data using the SECS-I protocol over RS-232 is too slow and does not provide for local area network (LAN) access. In addition, the noise immunity of RS-232 is rather low. Therefore, a new standard, called HSMS, which adopts TCP/IP protocol, was proposed [4]. It provides higher speed alternative to the SECS-I protocol. In addition, it possesses the following advantages: low cost, high reliability, and wide platform choices. Furthermore, to take full advantage of CIM Framework [5], SEMI developed an object-based equipment model (OBEM) [6] standard so that the equipment can communicate with the CIM Framework directly by method invocation without using the SECS/GEM protocol. The OBEM standard focuses mainly on providing definitions, services, and behavior of physical and logical objects of which equipment is typically composed. This standard is now E98 of SEMI equipment automation/software standards [6]. OBEM does not dictate the composition of equipment. Equipment suppliers are responsible for decomposing and mapping the equipment into different objects. OBEM allows the factory to use object services (Object Services Standard, OSS, SEMI E39 [3]) to require of the equipment that the equipment describes its physical view by reporting which objects that it owns. OBEM defines the interfaces of, and relationships between, equipment objects. The factory will communicate with the equipment directly using these interfaces via method invocation [7]. Generic and reusable equipment management has received relatively little attention. However, among them, Moyne and McAfee [8] proposed a generic cell controller for the automated VLSI manufacturing facility. This generic cell controller can only be applied in a hierarchical, legacy manufacturing system and cannot be used in a modern, framework-based manufacturing system [9]–[11]. Chan and Lammers [12] proposed a reusable distributed object framework and its applications in the factory automation domain. That investigation developed this framework as a generalization of a machine monitoring system. However, this framework cannot be applied to semiconductor factories because it does not consider the domain requirements of semiconductor manufacturing. To resolve the above problems, a generic equipment manager (GEMG) [2] for semiconductor manufacturing was developed in our previous work by applying the generic equipment interface (GEI) and distributed object-oriented technology with CORBA specification [13], [14]. GEMG was developed while

0894–6507/01$10.00 © 2001 IEEE

CHENG AND LIN: ENHANCEMENT OF SEMICONDUCTOR EQUIPMENT COMMUNICATIONS

Fig. 2.

373

Mobile object technology.

Fig. 1. Architecture of generic equipment manager.

attempting to obtain the following design features: 1) it can operate alone or become a pluggable component of the MES framework [9] and 2) it can be reused even when the business rules of a company and/or the equipment rules of the equipment have been changed. In light of these general considerations, the design principles of GEMG focus mainly on maximizing generality and emphasizing reusability. Therefore, the governing rules of GEMG are divided into three portions: system/framework rules, business rules, and equipment rules, as described below. • System/Framework Rules These rules specify the requirements to become a pluggable component of the MES framework. According to the specification of the MES framework, a CORBA interface module that inherits an adequate design pattern from the MES framework must be designed to accomplish these rules [9], [13], [16]. • Business Rules These rules are company-dependent and equipment-independent. A controller application (CA) module must be defined to accomplish these rules. • Equipment Rules These rules are equipment-dependent and company-independent. An equipment driver (ED) module must be defined to accomplish these rules. Based on the above design principles, the architecture of GEMG can be designed as illustrated in Fig. 1. By using the system/framework rules, GEMG can operate independently or be integrated into the MES framework in a plug and play fashion via MES interface module. Different companies have different business rules. If the business rules are changed, only the CA module must be modified; meanwhile, the other modules can still be reused. The ED module handles the equipment rules. These equipment rules consist of behaviors. ED is then implemented by driving the appropriate behaviors. A behavior consists of several SECS-II messages [3] and a few GEI messages [2]. It is set up in a behavior table and an associated sequence/content table and SECS parameter table. If a new equipment rule is defined, proper SECS II messages and fine-grained GEI messages are organized to accomplish this equipment rule.

Because ED is equipment-dependent, modifications due to equipment change are a necessary inconvenience. Hence, this work presents an improved scheme to replace the ED with a web-enabled equipment driver (WED). This approach solves the equipment-dependent problem. WED is developed as follows. First, the mobile object model with a Java applet, i.e., WED, is developed. WED is constructed on the EQ (server) side. Then, the equipment manager (client) downloads WED through a web browser. After this, the equipment manager can communicate with EQ by the Java socket technology [15] using the HSMS standard [3], [4], or alternatively it can use the object web technology [15] through the CORBA or DCOM protocols using the OBEM standard [6]. The GEI messages [2] also need to be adopted as a standard such that one side of WED can communicate with CA using GEI messages, while the other side can communicate with EQ via specific interfaces assigned by EQ using mobile object technology. The rest of this paper is organized as follows. Section II describes the mobile object model for semiconductor equipment communications. Section III proposes a systematic approach for developing a WED using object-oriented technologies. According to this WED development procedure, it contains five stages: system analysis, object-oriented analysis (OOA), objectoriented design (OOD), implementation, and integration and testing. The system analysis, OOA, and OOD stages are also described in Section III. Section IV illustrates the implementation stage; while Section V explains the integration and testing stage. Summary and conclusions are finally made in Section VI. II. MOBILE OBJECT MODEL FOR SEMICONDUCTOR EQUIPMENT COMMUNICATIONS This paper adopts mobile object technology, as shown in Fig. 2. Mobile objects—known as “applets”—are written once and then run anywhere. They are dynamically loaded and executed by stand-alone applications such as web browsers. The mobile object technology can be subdivided into two types: Java only and object web. The Java socket technology [15] used in this work is for composing Java and HSMS protocols. Meanwhile, the object web technology [15] is used for marrying distributed objects with the web. This study adopts object web technology for either the composition of Java and CORBA or the composition of Java and DCOM.

374

IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING, VOL. 14, NO. 4, NOVEMBER 2001

Fig. 3. The mobile object model for semiconductor equipment communications.

As described in Section I, the ED of GEMG must be modified if GEMG is connected to different EQ. To avoid this, a WED is developed. Functionality is achieved by downloading WED via a web browser to the equipment manager. Therefore, GEMG is renamed as the web-enabled equipment manager (WEM). Subsequently, WEM can communicate with EQ by the Java socket technology using the HSMS standard, or by the object web technology through the CORBA or DCOM protocols using the OBEM standard. Accordingly, this study proposes a mobile object model for semiconductor equipment communications (Fig. 3) to construct the interaction between WEM and EQ as follows. The right side of Fig. 3 shows two different types of equipment controllers (ECs) for EQ. The lower one is the conventional EC. This controller uses the Java socket technology to provide the HSMS driver. The upper controller is the objectbased EC that communicates with WEM by method invocation via the OBEM standard. To enable WEM to communicate with the two types of ECs without modifying the equipment drivers, WED is developed. There are two types of WEDs: the conventional WED and the object-based WED. They are introduced as follows. Closely examining both ECs in Fig. 3, their WEDs are displayed in the top-right corner marking with dashed-line borders. The conventional WED contains three functional blocks: GEI interface, conventional WED kernel, and HSMS interface. The GEI interface is for communicating with the CA of WEM using GEI messages. Meanwhile, the HSMS interface is responsible

for linking communication with the conventional EC using the HSMS/SECS-II protocols. The intermediate block represents the kernel of the conventional WED. This component constructs a CORBA interface channel for GEI interface and an HSMS interface channel for HSMS/SECS-II communications and it then converts the message formats between the two interfaces. The object-based WED, as implemented by using the object web technology, is designed similarly to that of the conventional WED and also comprises three functional blocks: GEI interface, object-based WED kernel, and OBEM interface. The GEI interface of the object-based WED functions identically with that of the conventional WED, and the OBEM interface is responsible for linking with the object-based EC through method invocation. The intermediate block represents the kernel of the object-based WED. This component constructs one communication channel for CA and another for EC, and can transmit messages between them. Assisted by WED, WEM can communicate with EQ via different interfaces. This ability makes WEM more generic. The left side of Fig. 3 displays the complete architecture of WEM. WEM is also composed of a GEI ORB and three major functional blocks: MES interface, controller application (CA), and web-enabled equipment driver (WED). The MES interface of WEM connects CA with the MES framework. When the MES framework dispatches messages to WEM, CA passes them to the proper EQ through the corresponding WED. WED is responsible for connecting CA with EC. Additionally, the communications between CA and WED use GEI messages via the

CHENG AND LIN: ENHANCEMENT OF SEMICONDUCTOR EQUIPMENT COMMUNICATIONS

GEI ORB. This GEI interface also adopts the CORBA standard. CA is responsible for receiving the messages from the MES framework and converting them into the corresponding GEI messages. After that, CA passes the GEI messages to WED via the GEI ORB. Finally, WED invokes the corresponding operations of EC to exchange messages. Introducing EC, WED, and WEM clarifies the mobile object model for semiconductor equipment communications shown in Fig. 3. The model can be described as follows. 1) Install and Load Applet First, the HTML page includes references to the embedded Java applet—WED. The web server retrieves WED and downloads it in bytecode form to the WEM side via a web browser, using the HTTP protocol. WED, which may be the object-based WED or the conventional WED, is then run through the Java run-time security gauntlet and loaded into memory. 2) Intercommunicate/Interoperate WED is regarded as the communication bridge between CA and EC. Once downloaded, WED receives the GEI-format messages from CA. Then, the conventional WED communicates with the conventional EC using the HSMS/SECS-II protocols, while the object-based WED interoperates with the object-based EC using the OBEM/CORBA or OBEM/DCOM standards. As mentioned above, WED enables WEM to communicate with various machines carrying different interfaces without modifying the associated equipment drivers. The following sections describe a systematic approach for developing a WED using the mobile object technology. III. WEB-ENABLED EQUIPMENT DRIVER DEVELOPMENT PROCEDURE The systematic procedure to develop WED consists of five major stages: 1) system analysis; 2) object-oriented analysis (OOA); 3) object-oriented design (OOD); 4) implementation; and 5) integration and testing. This generic object-oriented system development procedure, by adopting the unified modeling language (UML) [17], is based on the one proposed in our previous work [18]. In the system analysis stage, three tasks are required: collect and study domain knowledge, collect requirements, and analyze requirements. We will concentrate on collecting and analyzing requirements of WED. The requirements for WED to function are as follows. 1) WED can be downloaded through a web browser from EQ to WEM. 2) WED provides three different communication interfaces with EC, including HSMS, CORBA, and DCOM. 3) WED can communicate with CA of WEM through the GEI interface using the CORBA standard. 4) WED is responsible for correctly transmitting information from CA to EC, and vice versa. The information includes equipment status, recipe management, event reports, and alarms/errors. 5) WED provides an appropriate user interface for WEM to monitor EQ.

375

According to the above system requirements, we can determine some use cases and actors that are involved in performing the functions of WED. After finishing the system analysis stage, the OOA stage can begin. OOA helps system developers to obtain a gross outline of the system. The key concept of OOA is to determine “what” exactly the system is. Therefore, system developers derive the elementary architecture of the target system at the end of OOA. The OOD stage can proceed after the OOA-stage class diagram has been obtained. The OOA and OOD stages have different focuses. The OOA puts great emphasis on describing the main functions of the system as simply as possible, but the OOD insists on representing the design of the system in detail. OOD focuses mainly on figuring out “how” to make the system work well according to the results of OOA and the constraints of the environment under development. In this work, we use three different interfaces for WED to communicate with EC: HSMS, CORBA, and DCOM. Their implementation is different. Therefore, there are two different considerations in the OOD stage. One merely utilizes the Java socket technology with conventional HSMS protocol; the other applies the object web technology with Java being the mobile code system, while CORBA or DCOM being the distributed object infrastructure. According to these two considerations, their class and sequence diagrams are also different. Observing Fig. 4(a), a class denoted “Conventional WED” consists of “GEI Message Manager,” “Conventional Driver Manager,” “Event Report Manager,” and “Exception Manager.” Similarly, a class named “Object-based WED” depicted in Fig. 4(b) is composed of “GEI Message Manager,” “Object-based Driver Manager,” “Event Report Manager,” and “Exception Manager.” Both class diagrams show that “Controller Application” sends GEI messages to “GEI Message Manager.” After receiving the GEI messages, “GEI Message Manager” processes them and generates the associated messages, events, and exceptions. Referring to Fig. 4(a), the class diagram of the conventional WED depicts that messages are sent to “Conventional Driver Manager” which communicates with “Equipment Controller” by the HSMS standard. For the object-based WED, [see Fig. 4(b)], a class called “Object-based Driver Manager” is designed. It is responsible for communicating with “GEI Message Manager” and “Equipment Controller.” It communicates with “Equipment Controller” by method invocation via the CORBA or DCOM interface. The main difference between Fig. 4(a) and (b) is that “Event Report Manager” and “Exception Manager” must communicate with “Equipment Controller” via “Conventional Driver Manager” in the conventional WED [Fig. 4(a)]; while they can communicate with “Equipment Controller” directly in the object-based WED [Fig. 4(b)]. As indicated in Fig. 4, a plus sign in front of an operation means that this is a public operation which can be invoked from the ORB; while a minus sign represents that it is a private operation which can only be called within WED. The operations of “GEI Message Manager” for the conventional and object-based WEDs are exactly the same because both of them communicate with the same “Controller Application.” On the other hand, the

376

IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING, VOL. 14, NO. 4, NOVEMBER 2001

Fig. 4. OOD-stage class diagrams of the mobile object model.

operations for “Exception Manager” and “Event Report Manager” of the object-based WED include sendException() and sendEvent(), respectively, but those of the conventional WED do not. It is because the object-based EC needs to invoke those two operations for directly sending exceptions and events to “Excep-

tion Manager” and “Event Report Manager” of the object-based WED, respectively. For the conventional case, all the exceptions and events must be sent by calling associated SECS II message: SxFy() between the conventional EC and “Conventional Driver Manager.”

CHENG AND LIN: ENHANCEMENT OF SEMICONDUCTOR EQUIPMENT COMMUNICATIONS

377

Fig. 5. OOD-stage sequence diagrams with object-based protocols.

For brevity, only two sequence diagrams are presented. The sequence diagram for initializing the object-based WED is shown in Fig. 5(a). An object named “Object-based WED” first creates “GEI Message Manager.” Then, “Object-based WED” connects with “Controller Application” and passes the object reference of “GEI Message Manager” to “Controller Application.” Therefore, “Controller Application” can communicate with “GEI Message Manager” directly by invoking its methods and the initialization of the object-based WED is accomplished. Fig. 5(b) illustrates the sequence diagram for CA sending GEI messages with object-based protocols. “GEI Message Manager” receives the GEI message from “Controller Application” and passes the message to “Object-based Driver Manager.” After that, “Object-based Driver Manager” checks the message and then invokes the corresponding method of

“Equipment Controller.” Finally, “GEI Message Manager” enwraps the return message to the GEI-type messages and sends it to “Controller Application.” For further explanation, a message flow example, which combines class and sequence diagrams, is presented below. Message Flow Example The system class diagrams are constructed by analyzing the sequence diagrams in the OOD stage. However, they are complex and hard to understand. In order to combine the sequence diagrams and the class diagrams, and to demonstrate how this object-oriented design functions, an example for tracing the message flow “Controller Application Sending GEI Messages with Object-based Protocols” is presented as follows.

378

IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING, VOL. 14, NO. 4, NOVEMBER 2001

Closely examining Fig. 5(b), “Controller Application” sends GEI messages to “GEI Message Manager” by invoking the public operation sendGEIMessage() of “GEI Message Manager” [see Fig. 4(b)]. “GEI Message Manager” receives the messages and asks “Object-based Driver Manager” to process them by calling the private operation processMessage() of “Object-based Driver Manager.” “Object-based Driver Manager” then processes and checks the messages. If the messages are valid, “Object-based Driver Manager” invokes the corresponding public operations of EC. Next, “GEI Message Manager” enwraps the returning value of processMessage() to GEI messages by calling the private operation enwrapGEIMessage() of itself. Finally, “GEI Message Manager” sends the packed GEI messages to CA by invoking the public operation replyGEIMessage() of CA. The design of the system is completed by OOD. The implementation of the system will be presented next. IV. IMPLEMENTATION After carrying out system analysis, OOA, and OOD, the system has been completely designed. This section presents the implementation procedures of the mobile object model and WED. Three kinds of interface between EC and WED are HSMS, CORBA, and DCOM. To save space, this study only introduces the implementation procedure for the CORBA interface, as presented in Fig. 6. Three boxes with dashed lines divide the implementation procedure into three stages: mobile object framework, EC (server) construction, and WED (client) construction. The mobile object framework stage expresses all the interfaces between EC and WED in IDL which were defined in the OOD class diagrams [Fig. 4(b)]. Both the EC- and WED-side IDLs are compiled by idl (e.g., a utility in Orbix 2.3C [20], [21]) to generate server skeletons that enable the implementation in VC++ [19] for EC. On the other hand, idl2java (e.g., a utility in VisiBroker for Java 3.2 [23]) is used to compile both the ECand WED-side IDLs to generate client stubs that help implement WED in Java. During the EC construction stage, an EC server which implements the interface defined in EC IDL must be developed. Details of our implementation of this EC server are found in [7]. The WED construction stage divides the client implementation procedures into two substages: 1) implementing WED JavaBeans and 2) implementing WED applets. In Substage 1, WED JavaBeans, Java-specific components, are implemented (e.g., by the IDE of JBuilder 2.0 [22]). WED JavaBeans are compiled by javac into bytecodes. The utility jar in JDK permits several bytecode files to be compressed into a single .jar file. Then, WED JavaBeans are ready for use in programming applets. In Substage 2, WED applets are developed. They are implemented according to the functional requirements of WED. WED JavaBeans made in the previous substage are used in implementing WED applets. Then, javac is also applied to compile WED applets into bytecodes. Finally, jar is used to encrypt this bytecode class file into a .jar file with an encrypted key. The resultant applet is called a signed object-based WED applet and it is then ready to roam over Internet.

Fig. 6. The implementation procedure for CORBA interface between WED and EC.

In addition to the interface between WED and EC, the interface between WED and CA also needs to be implemented. As indicated in Fig. 3, the interface between WED and CA is through GEI ORB that is also constructed by CORBA. The CA side is implemented by C++ and acts as a server; while the WED side is implemented by Java and functions as a client. Therefore, the implementation procedure is identical to that for the interface between WED and EC. To enable the WED interfaces to function properly, the techniques of interoperable object reference (IOR), callback, and signed applet shall be applied. The techniques are described as follows. IOR This implementation adopts two ORBs: Orbix and VisiBroker. The CA and EC interfaces are implemented by Orbix ORB, while WED interfaces are implemented by VisiBroker ORB. These two different ORBs can communicate with each other via IORs. An ORB must create an IOR (from an object reference) when an object reference is passed across the ORBs. The IORs associate a collection of tagged profiles with object references. The profiles describe the same object, but they each describe how to contact the object using a particular ORB mechanism [13]. Callback Scheme for CORBA Interface Additionally, the communications between WED to EC and WED to CA must provide peer-to-peer functionality. In gen-

CHENG AND LIN: ENHANCEMENT OF SEMICONDUCTOR EQUIPMENT COMMUNICATIONS

379

Fig. 7. System deployment architecture.

eral, peer-to-peer functionality does not work between different CORBA ORBs. Two solutions are available for this problem. One solution is to produce CORBA servers for both sides of the interface. These servers can communicate by using specific procedures and mechanisms. However, constructing and maintaining these procedures is excessively complex. Therefore, a better solution is to use the callback technology [25] to support the peer-to-peer functionality. A callback is a call from a server to a client. A callback reverses the client and server roles and allows a client to become a server. This mechanism allows clients to receive requests from a server. Signed Applet WED is developed using the Java applet technology to achieve mobility. However, some activities of WED may conflict with the security restrictions of the Java applet. Because of this, all applets are forced to run in a restrictive sandbox [26] to prevent them from maliciously—or accidentally—causing damage. The sandbox simply prevents an applet from accessing the local hard drive, or connecting to any web site except the site from which the applet was loaded. Unfortunately, the applet sandbox can be overly restrictive, preventing applets from performing many useful functions. For example, when WED uploads recipes from EC, it cannot save the recipes to the local hard drive. It is impossible for WED to function properly unless it can somehow escape the applet sandbox. One way to escape the sandbox is to sign the applet [26]. Thus, this study uses the Netscape signing tool [24] to sign the applet. The integration and testing stage is presented as follows. V. SYSTEM INTEGRATION AND TESTING Prior to presenting the system integration and testing stage, the system deployment architecture of the mobile object model for semiconductor equipment communications is described. Observing Fig. 7, the model comprises of five major components

(MES, WEM, conventional equipment with the HSMS standard, object-based equipment with the OBEM/CORBA standard, and object-based equipment with the OBEM/DCOM standard) connected together via the Ethernet. A web browser is installed in WEM and a web server containing WED is implemented in each EQ. The overall integration and testing of the system is constructed based on the system deployment architecture depicted in Fig. 7 and the mobile object model shown in Fig. 3. As illustrated on the left side of Fig. 3, MES is constructed based on the CORBA infrastructure. The components of MES are integrated into the MES framework in a plug-and-play fashion [9]. WEM is a component of MES. The System Manager is responsible for managing all the MES components. The System Manager dispatches orders to the Scheduler, which is also a component of the MES, and the Scheduler then dispatches the job to WEM. Within WEM, CA is responsible for receiving messages from MES. When CA receives messages, it passes them through the GEI ORB to WED, then WEM communicates with EQ using three different standards: HSMS, CORBA, and DCOM. To function properly, each WED from each associated EQ must first be downloaded to WEM. This application example for the mobile object model has been successfully implemented and demonstrated at the Automation Laboratory of the Institute of Manufacturing Engineering, National Cheng Kung University, Tainan, Taiwan, R.O.C. VI. SUMMARY AND CONCLUSIONS By applying the mobile object and object web technologies, a mobile object model for semiconductor equipment communications is proposed and WED in this model is also developed in this work. WED contains two interface channels. One uses GEI messages to communicate with CA and then MES, and the other communicates with EQ via specific interfaces assigned by EQ. If EQ selects the conventional HSMS standard, the con-

380

IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING, VOL. 14, NO. 4, NOVEMBER 2001

ventional WED applies the Java socket technology to exchange messages between them. On the other hand, if EQ possesses the object-based EC with the OBEM standard, the object-based WED adopts the object web technology with the CORBA or DCOM specifications to communicate between them. WED is implemented on the EQ side because EQ understands exactly how to interact with itself. By downloading WED via a web browser to the WEM side, WEM can communicate efficiently with various machines using different standards and without modification. Demonstration results from the application example indicate that the proposed mobile object model and the WED provide a novel, efficient, and versatile scheme for semiconductor equipment communications. ACKNOWLEDGMENT The authors would like to thank Prof. R.-S. Lee for his enlightening discussion concerning this research. REFERENCES [1] F.-T. Cheng, H.-C. Yang, T.-L. Kuo, C. Feng, and M. Jeng, “Modeling and analysis of equipment managers in manufacturing execution system for semiconductor packaging,” IEEE Trans. Syst., Man, Cybern. B (special issue), vol. 30, no. 5, pp. 772–782, October 2000. [2] H.-C. Yang, F.-T. Cheng, and D. Huang, “Development of a generic equipment manager for semiconductor manufacturing,” in 7th IEEE Int. Conf. Emerging and Factory Automation (ETFA ’99), Barcelona, Catalonia, Spain, Oct. 1999, pp. 727–732. [3] SEMI, Equipment Automation/Software: Semiconductor Equipment and Materials International, 1996, vol. 1 and 2. [4] SEMATECH, “SMS technical education report,” SEMATECH Inc., 1995. [5] , “Computer Integrated Manufacturing Framework Specification Version 2.0,” SEMATECH Inc., 1998. [6] SEMI International Standards CD-ROM, SEMI. (2001). [7] J.-Y. Deng, F.-T. Cheng, and K. Nguyen, “Development of an objectbased equipment controller for semiconductor equipment communication,” in Proc. 25th Annu. Conf. IEEE Indust. Electron. Soc.. San Jose, CA, November 1999. [8] J. R. Moyne and L. C. McAfee, “A generic cell controller for the automated VLSI manufacturing facility,” IEEE Trans. on Semiconduct. Manufact., vol. 5, pp. 77–87, May 1992. [9] F.-T. Cheng, E. Shen, J.-Y. Deng, and K. Nguyen, “Development of a system framework for the computer-integrated manufacturing execution system: A distributed object-oriented approach,” Int. J. Comput. Integrated Manufact., vol. 12, no. 5, pp. 384–402, Sept./Oct. 1999. [10] J. McGehee, J. Hebley, and J. Mahaffey, “The MMST computer-integrated manufacturing system framework,” IEEE Trans. Semiconduct. Manufact., vol. 7, pp. 107–115, May 1994. [11] D. Scott, “Comparative advantage through manufacturing execution systems,” in SEMICON Taiwan 96 IC Seminar, Taipei, Taiwan, R.O.C., Sept. 1996, pp. 227–236. [12] S. M. Chan and T. L. Lammers, “Reusing a distributed object domain framework,” in Proc. 1998 IEEE Fifth Int. Conf. Software Reuse, 1998, pp. 216–223. [13] R. Orfali, D. Harkey, and J. Edwards, The Essential Distributed Objects Survival Guide. New York: Wiley, 1996. [14] OMG, The Common Object Request Broker: Architecture and Specification, Revision 2.2: Object Management Group, 1998. [15] R. Orfali and D. Harkey, Client/Server Programming with Java and CORBA, second ed. New York: Wiley, 1998.

[16] Chen and Chen, “An experiment study of using reusable software design frameworks to achieve software reuse,” J. Object Oriented Programming (JOOP), May 1994. [17] G. Booch, J. Rumbough, and I. Jacobson, Unified Modeling Language Semantics and Notation Guide 1.0. San Jose, CA: Rational Software Corporation, 1997. [18] E. Huang, F.-T. Cheng, and H.-C. Yang, “Development of a collaborative and event-driven supply chain information system using mobile object technology,” in Proc. 1999 IEEE Int. Conf. Robotics and Automation, Detroit, MI, May 1999, pp. 1776–1781. [19] Microsoft, Visual C++ Programmer’s Guide: Microsoft Corp., 1997. [20] IONA, The Orbix Programming Guide: IONA Technologies Ltd., 1997. , The Orbix Reference Guide: IONA Technologies Ltd., 1997. [21] [22] [Online]. Available: http://www.inprise.com/jbuilder/ [23] [Online]. Available: http://www.inprise.com/visibroker/ [24] [Online]. Available: http://developer.netscape.com/docs/manuals/signedobj/signtool/signtool.htm [25] D. C. Schmidt and S. Vinoski, “Distributed callbacks and decoupled communication in CORBA (Column 8),” SIGS C++ Rep. Mag., Oct. 1996. [26] D. Pedrick, J. Weedon, J. Goldberg, and E. Bleifield, Programming with VisiBroker. New York: Wiley, 1998.

Fan-Tien Cheng (S’87–M’89–SM’98) was born on September 12, 1953, in Tainan, Taiwan, R.O.C. He studied electrical engineering at the National Cheng Kung University, Taiwan, R.O.C., where he received the B.S. degree in 1976. He received the master’s degree in 1982 and the Ph.D. degree in 1989 from Ohio State University, Columbus, OH, both in electrical engineering. He was employed by the Chung Shan Institute of Science and Technology (CSIST), Taiwan, R.O.C., as a Research Assistant in 1976 and was promoted to Assistant Scientist, Associate Scientist, and Senior Scientist in 1982, 1986, and 1994, respectively. He left the Institute in August of 1995 when he was named an Associate Professor of Manufacturing Engineering at the National Cheng Kung University. He was promoted to a Full Professor in August 1997. Since August 1998, he has become the Director of the Institute of Manufacturing Engineering. When he was in the CSIST, he served as a group leader in the design, development, and testing of a modern fire control system. He has been honored for his work with the Senior Scientist Award of the ROC Department of Defense in 1994. His research interests include factory automation for semiconductor manufacturing as well as control and optimization of multiple-chain robotic mechanisms and redundant manipulators. He built a web-enabled experimental manufacturing execution system and a supply chain information system for IC-Packaging at the Automation Laboratory of the Institute of Manufacturing Engineering for educational and research purposes. He won the Kayamori Best Paper Award of the 1999 IEEE International Conference on Robotics and Automation. And, he has been an Associate Editor of the IEEE TRANSACTIONS ON ROBOTICS AND AUTOMATION since May 2000.

Meng-Tsang Lin was born on July 30, 1975, in Changhua, Taiwan, RO.C. He received the B.S. degree in mechanical engineering at the National Cheng Kung University, Taiwan, R.O.C., in 1997, and the master’s degree in manufacturing engineering from the National Cheng Kung University, Taiwan, R.O.C., in 1999. He just finished his military service in May 2001. His research interests include equipment automation, factory automation and manufacturing execution systems for semiconductor manufacturing.