Development of a Service Management Scheme for ...

Proceedings of the 2002 IEEE International Conference on Robotics & Automation Washington, DC • May 2002

Development of a Service Management Scheme for Semiconductor Factory Management Systems1 Fan-Tien Cheng2 Haw-Ching Yang Chia-Ying Tsai Institute of Manufacturing Engineering National Cheng Kung University Tainan 70101, Taiwan, R.O.C. WIP Tracking

Abstract Equipment managers generally function to communicate between the manufacturing execution system and equipment. There are hundreds of equipment in a semiconductor factory. In order to increase equipment utilization and improve product quality yield, more reliable services provided by equipment managers are expected. Therefore, it is essential to develop a reliable Service Management Scheme (SMS) for semiconductor factory management systems. In this work, the SMS is developed by applying the Jini and design by Contract technologies. A Generic Evaluator is also developed in the SMS so as to possess error-detection and function-replacement capabilities. The Generic Evaluator can also maintain the Credit values of all the equipment managers. By comparing the Credit values, the factory manager can select better equipment managers to provide services. With the SMS, the process status and parameters of equipment managers in service are stored periodically. If an equipment manager malfunctions, the Generic Evaluator detects and confirms it and sends an event notice to the factory manager. Then, the factory manager finds a spare equipment manager and transfers the backup process status and parameters to the spare equipment manager. Finally, the spare equipment manager can continue monitoring the manufacturing process started from the point where the malfunctioned one left off. Evaluation of reliability improvement and an illustrative example of the SMS are also presented in the paper. The evaluation and demonstration results reveal that the proposed SMS establishes an efficient, reliable, fault-tolerant, and cost-effective mechanism for semiconductor factory management systems. 1 Introduction The key performance criteria of semiconductor manufacturing management are to cut manufacturing cycle time, reduce manufacturing cost, increase tool utilization, enhance production throughput, and improve quality yield. An available tool to assist semiconductor manufacturers in achieving these objectives is a Manufacturing Execution System (MES) [1]. Based on the distributed object-oriented technology, a typical integratable/framework MES architecture is shown in Fig. 1 [2][3]. It consists of a WIP tracking, a statistical process control (SPC), a reporting, a specification manager, a recipe manager, a factory manager, and many equipment managers. Among them, the factory manager controls/monitors all equipment managers and each equipment manager logically controls/monitors several equipment. As depicted in Fig. 1 the factory manager is in charge of all the equipment managers via LAN and each equipment 1

The authors would like to thank the National Science Council of the Republic of China for financially supporting this research under Contract No. NSC-90-2212-E-006-075 and NSC-91-2622-E-006-004. 2 The corresponding author.

0-7803-7272-7/02/$17.00 © 2002 IEEE

SPC

Reporting

Specification Manager

Equipment Manager

Equipment

Equipment HSMS

Factory Manager DataBase

Equipment Manager

Equipment Manager

Equipment

Recipe Manager

HSMS

Figure 1: Typical Integratable MES Architecture

manager logically controls/monitors several equipment through HSMS protocol over LAN. However, if we don’t have spare equipment managers, then the mission of the faulty equipment manager still cannot be replaced by a spare one. In order to improve the overall reliability of the entire factory management system, several spare equipment managers shall be added to the system and a Service Management Scheme (SMS) with error-detection and function-replacement capabilities shall be developed. With the SMS, the factory manager will be informed if one of the equipment managers malfunctions; and then the factory manager will find a proper equipment manager to replace the faulty one to continue controlling/monitoring the remaining manufacturing processes of the equipment. How to increase the reliability of software system is always one of the common goals of system developers. Reliability is even more important in object-oriented programming than elsewhere. There is a large body of research literature reporting methods for improving software reliability. Among them, Meyer [4] proposed to use Contract to represent the common agreement between Client and Service. Using Contract to substitute the traditional defensive programming will make exception handling easier and then reduce bugs. In the following studies, several researchers applied the concept of Contract to the software development environment, such as using the UML’s object constraint language to do analysis and design by Contract [5], adding Contracts to Java [6], and extending a methods of devising software Contracts [7]. Besides, several other researches [8] also proposed methods for increasing the reliability and recoverability of application processes. However, the above methods are not mainly for improving the reliability of distributed systems. In the area of improving the overall reliability of distributed systems, Osman and Bargiela [9] proposed a fault tolerant environment for open distributed computing (FADI). FADI can detect error occurrence via monitoring user-process failures and node crashes. It also proposed a non-blocking checkpoint mechanism combined with a selective message logging technique to do backup and recovery operations for distributed processes. However, FADI can only detect processor node crashes and hardware transient failures, while

3607

certain faults in the communication link (e.g., messages delivered with erroneous contents) cannot be detected. Also, the non-blocking checkpointing policy was adopted in FADI to backup and restore the state of the application processes before error occurrence. This backup will be used when the faulty node is recovered. However, the system does not prepare spare nodes to replace the faulty one. Therefore, if the faulty node cannot be recovered, its mission may not be continued. OMG submitted a request for proposal (RFP) of fault tolerant CORBA (FT-CORBA) using entity redundancy in CORBA 3 specification [10]. This RFP addresses the need for standard CORBA functionality supporting fault tolerant applications, such that the clients of these applications will be largely insulated from such details as management of redundant copies, failure masking, and recovery. The FT-CORBA specification defines a standard set of interfaces, policies, and services that provide robust support for applications requiring high reliability. Based on FT-CORBA, Natarajan, et al., [11] proposed the DOORS framework which is implemented as a CORBA service to provide end-to-end application-level fault tolerance. In FT-CORBA, FaultDetectors are CORBA objects responsible for detecting faults via either a pull-based or a push-based mechanism. The pull-based monitoring mechanism periodically polls applications to determine if their objects are alive. The push-based monitoring mechanism (also known as heartbeat monitor) requests applications to send periodic heartbeats to the FaultDetector. However, both mechanisms cannot detect performance degradation of applications. Logging and recovery mechanisms in FT-CORBA will enable the backup object to replace the primary object for failure recovery when primary object malfunctions. However, this is an one-to-one backup scheme. Only the dedicated backup object can be used to replace the specific primary one. In this case, if there are n primary objects, then n backup objects are required for failure recovery considerations. The Jini technology [12] is described as software to federate groups of Services. Federation implies a loose coordination between parts. In this case it means that Services may be added to and removed from a network freely. If a Service is present, it is available for use by any interested parties. If, however, the Service goes away unexpectedly, this does not cause any kind of catastrophic failure in the other Services, instead it removes the ability to use that Service. Jini provides the services of Discovery, Lookup, Leasing, and Event, etc. Discovery service lets Jini to have the spontaneous community-building capability. Lookup service enables Clients to search for the desired Services. Leasing service allows Jini to have the self-healing ability. However, Jini still need some functional enhancements to meet the requirements of the desired SMS. These enhancements are described below. Although Leasing service can be used to detect whether a Service is crashed, the other kinds of abnormal behavior (such as performance degradation and messages delivered with erroneous contents, etc.) cannot be detected by Leasing. Lookup service can be applied to search for the desired Services, but it cannot distinguish the confidence among the Services. Jini doesn’t have the backup scheme to record the execution status and parameters prior to failure occurrence. This study proposes and develops the desired SMS. The SMS is developed based on the Jini infrastructure and the theory of design by Contract. The newly-developed Generic Evaluator (GEV) is included in the SMS. The SMS has the capability of detecting the following errors: Service crash,

transmitting wrong messages, and performance degradation of Services. Further, the GEV can backup the execution status and parameters of a Service to the database periodically. If an error of that Service is detected, the GEV will inform the Client. Then the Client will retrieve the backup information and set it to the backup Service to continue the application process. The SMS will apply the technique of Contract [4][5] to represent the services provided by a Service. The concept of Credit will be adopted to denote the accumulative credit of a Service and all the Credit values of Services are also maintained by the GEV. By evaluating the Credit values, the Client can distinguish the confidence among Services and then select the suitable Service. The reliability formula of the SMS is derived so that the improvement effect by adopting the SMS can be evaluated. The evaluation results of the illustrative example for semiconductor packaging reveal that the overall reliability of the factory management system can have significant improvement if the SMS is adopted even the factory management system has only single spare equipment manager. The rest of this paper is organized as follows. The basic technical foundations: Contract, GEV, and Credit function are introduced in Section 2. Section 3 presents the detail algorithm and Section 4 describes the class diagram of the SMS. Section 5 derives the reliability formula and performs reliability improvement analysis for the SMS. Section 6 displays an illustrative example for implementing the SMS onto the factory management system of semiconductor packaging. Summary and conclusions are finally made in Section 7. 2 Basic Technical Foundations Before presenting the complete algorithm of the Service Management Scheme (SMS), the details of its basic technical foundations (besides Jini): Contract, Generic Evaluator (GEV), and Credit are presented as follows. 2.1 Contract “Design by Contract” is implemented by Meyer in Eiffel [4]. It represented a way of specifying the requirements and deliverables between Clients and Services in an object-oriented system. A Contract allows a method to specify what preconditions need to be true before the method can function correctly, and in turn it specifies what postconditions will be true after it has executed. By publishing its Contract, a method can then avoid often torturous validation code. In Jini, Lookup Service maintains a list of ServiceItems (one for each Service). Each ServiceItem contains a proxy that a Client can download to use that Service, and a list of attributes that are used to describe the Service [13]. Combining Jini’s ServiceItem and Eiffel’s “design by Contract” the so-called Contract of the SMS is formed. A Service in the SMS shall provide its Contract to the community for a Client to refer to. A Contract not only contains the interfaces provided by a Service but also includes the common agreements (specified in preconditions and postconditions) between a Service and a Client. The proxy of a Contract is the implementation of the Contract’s interfaces plus preconditions and postconditions. The proxy can be download by a Client to use the associated Service. If the request of a Client sent to the proxy does not satisfy the precondition of the Contract, the proxy will send an exception to the Client. This property provides an approach for the SMS to detect the error of transmitting wrong messages.

3608

λu = gradient value for punitive function

2.2 Generic Evaluator The major purpose of the Generic Evaluator (GEV) is to evaluate the correctness of the Contract messages and their associated parameters during the service period. The evaluator scheme of GEV is shown in Fig. 2 and its explanations are omitted for lack of space.

η = degree of punition (-1< η < 0) I = current index γ = offset of index 1 0.9

1. Collect data Ci +1 0.8 0.7 Credit Value

2. Classify data

3. No. of data for the same classification is greater than the pre-defined statistic sample size S N

No

D C B A

0.6 0.5

Pi ( I )

0.4

Pu ( I )

0.3

Yes

0.2

4. Calcuate X i and σ i for those previous S N data of the same classification

E

0.1 0 0

No

No

5. X i − 3σ i < Ci +1 < X i + 3σ i

Yes

Figure 2: Flowchart for the Evaluator Scheme of the Generic Evaluator In addition to the error-detection capability, the GEV also has the ability of backup the execution status and parameters of a Service to the database periodically. This backup information will be retrieved for the purpose of function-replacement if the Service crashes. Further, the GEV maintains the Credit values of all the Services so that the Clients can distinguish the credits among the Services. 2.3 Credit Function The Credit function is composed of prize function and punitive function. After a successful mission, the Credit value of the Service will be increased according to the prize function. On the other hand, if a failure is detected in the Service, the Credit value will be decreased by the punitive function. The prize and punitive functions are described below.

(1 + η ) u ( I , λu ) 1 + η ⋅ u ( I , λu )

(2)

(3)

With

µ ( I,λ ) =

1 1 + e − λ ( I −γ )

where

λ = gradient value λi = gradient value for prize function

40

50

60

For example, if we choose λi = 0.2, λu = 0.3, η = -0.9, and γ = 30, the curves of the Credit function are depicted in Fig. 3. Initially, a Service has a default Credit value 0.5 and I A = 30. The corresponding point is A as shown in Fig. 3. If this Service accomplishes a mission then its Credit value is increased according to the price function curve Pi ( I ) and the

8. Notify Client that Service is abnormal

Punitive function: Pu ( I ) =

30 Index I

Punitive Function ( Pu ( I ) )

6. Detete the oldest data of the same classification and add Ci +1

Prize function: Pi ( I ) = µ ( I , λi )

20

Figure. 3: Prize Function ( Pi ( I ) ) and

Yes

7. Failure occurs for two consecutive cycles of the same classification

10

(4)

corresponding point goes to B, I B =31. Similarly, if two more missions are accomplished, the corresponding point goes to C ( I C = 32) and D ( I D = 33). Now, if a failure is detected during the next mission of this Service, the Credit value will be reduced by the punitive function curve Pu ( I ) with I =33 and the corresponding point goes from D to E and the index value I will be re-assigned as the nearest integer rounded off from point E. In this case, I E = 23. From now on, if the error in the Service is fixed and this Service registers into the Community again, then its Credit value is 0.2 (with I E = 23) and is maintained by the GEV. 3 Service Management Scheme The Service Management Scheme (SMS) is built upon the Jini’s infrastructure and is composed of three phases: 1) registration 2) search and execution and 3) detection and replacement. They are described below. 3.1 Registration As shown in Fig. 4, The Community includes a Lookup Service and a Generic Evaluator (GEV). Several Services (Service 1…N) try to register themselves to the Community. All the Services apply Jini’s Discovery service to discover Lookup Service and provide Contracts to Lookup Service. The contractItems are then set into GEV. GEV will assign a default Credit value (0.5) to each new Service and both conractItems and Credit values are stored in the database for future service and management purposes.

3609

Community

value of Service 1 is reduced by the Credit function and the thread for supervising Service 1 is terminated. 3) GEV notifies the Client that Service 1 is down. 4) The Client uses Jini’s Discovery service to discover the Lookup Service in the Community. The Client, then, searches the proper Service in the Lookup repository by evaluating the associated Contracts and Credit values maintained in GEV. In this case, Service 2 is selected.

Contract

Lookup Service

GEV

1. provide

1. provide

Service N

Contract Contract

5) After selecting Service 2, the corresponding Contract proxy

1. provide

Service 2

Service 1

Figure 4: Registration Phase 3.2 Search and Execution The search and execution phase is depicted in Fig. 5. There are five procedures and the associated explanations for the itemized procedures are described below. 1) A Client uses Jini’s Discovery service to discover the Lookup Service in the Community. The Client, then, searches the proper Service in the Lookup repository by evaluating the associated Contracts and Credit values maintained in GEV. In this example, Service 1 is selected. 2) After selecting Service 1, the corresponding Contract proxy of Service 1 is downloaded by the Client such that the Client can ask for service of Service1 via this proxy. 3) The Client requests services from Service 1 and registers an event notice from GEV if Service 1 malfunctions. 4) GEV initiates a thread to monitor the application process of Service 1 and to backup the execution status and parameters of the application process to the database periodically. 5) GEV supervises the Contract execution of Service 1. If no errors are detected, the Credit value of Service 1 will be increased by the Credit function after finishing the services.

of Service 2 is downloaded by the Client such that the Client can ask for services of Service 2 via this proxy. 6) Through GEV, the Client retrieves the backup execution status and parameters of Service 1 prior to the error occurrence and set them to Service 2, then the Client can request Service 2 to continue the application process where Service 1 left off. 7) GEV initiates a thread to monitor the application process of Service 2 and to backup the execution status and parameters of the application process to the database periodically. 8) GEV supervises the Contract execution of Service 2. If no errors are detected, the Credit value of Service 2 will be increased after finishing the services. Community

2. Error being detected then terminate thread

4. check contracts and choose Service 2

Service 1

1. abnormally terminate

Service N

1. check contracts and choose Service 1

3. request

Service 1

2. download proxy of Service 1

5. download proxy of Service 2

Service 2

Client

Detection and Replacement Phase

4 Class Diagram of the Service Management Scheme According to the system requirements mentioned in the previous section and following the procedures of object-oriented analysis and design, the class diagram of the SMS is illustrated in Fig. 7. The Jini portion has the class ServiceRegistrar, while the GEV portion has the classes GEVProxy, GEVService, SuperviseServiceThread, Evaluator, and DataHandler. Their functional descriptions are omitted for lack of space.

4. Execute thread

5. supervise Service 1

3. Send warning

6. request

Figure 6:

GEV

Service N

GEV 8. supervise Service 2

Community

Lookup Service

7. Execute thread

Lookup Service

5

Service 2

Client

Figure 5: Search and Execution Phase 3.3

Detection and Replacement The detection and replacement phase is illustrated in Fig. 6. Eight procedures are indicated in the figure and the associated itemized procedures are explained below.

Reliability Evaluation An example mechanism is presented here for the evaluation of reliability improvement by applying the SMS. A semiconductor factory management system has a factory manager (Client) and N equipment managers (Services). This system needs M equipment managers to control and monitor all the equipment in the factory. In order to maximize the equipment utilization, M equipment managers from those N available ones are needed to be in service.

1) Service 1 abnormally terminates. 2) The error is detected and confirmed by GEV, then the Credit

3610

For evaluating the improvement of overall system

reliability, the reliability formula of the SMS, RSMS , shall be derived. Suppose that the system has N similar Services with the same reliability R and the Client needs M Services for the system to function properly. In this case, there are N-M backups. We also assume that the reliability of GEV is RGEV .

(typically eight) equipment simultaneously. Therefore, to add more spare equipment mangers and apply the SMS for enhancing the overall system reliability is indeed cost-effective. An illustrative example will be presented in the following section to display the practicability of the SMS. RSMS − RO

Then, RSMS can be expressed as [14] :

0.7

 N −M  i RSMS = RGEV  ∑ CiN (1 − R ) R N − i   i =0 

N=11

0.6

(5)

N=12

0.5

B

N=13

0.4 0.3

GEVProxy set() message() interact with registerEvent() backupStatus() getCredit() getBackup()

GEVService set() message() registerEvent() backupStatus() getCredit() getBackup() GEVService()

0.2 register by

ServiceRegistrar

0.1

register() lookup()

A

0 -0.1

R 0.9

0.91

(a)

save/get data by

manage

0.92

0.93

0.94

0.95

0.96

0.97

0.98

0.99

with various N

R SMS -R O *

DataHandler

SuperviseServiceThread save/get info. by SuperviseServiceThread() * run() evaluate data at save/get info. by

Evaluator

0.7

createRelatedDataTable() createNewService() updateStatus() getStatus() getCredit() updateCredit() saveTime() changeAlert()

RGEV = 1 RGEV = 0.95 RGEV = 0.9

0.6 0.5 0.4 0.3

*

0.2

Evaluator() evaluate() changeCredit() sendEvent2Client()

GEV

Jini

0.1

A

0

C

-0.1

R 0.9

Figure 7: Class Diagram of the Service Management Scheme

0.91

0.92

(b) The reliability of the original system without any backup is RO = R M . Therefore, the improvement of reliability is Rsms − Ro . The evaluation charts for reliability improvement with M= 10 is illustrated in Fig. 8. Figure 8(a) displays the reliability improvement curves for N= 11, 12, and 13 with R varying form 0.9 to 0.99 and RGEV = 1 . Observing Point A on Fig. 8(a), with R=0.99, and N-M=1, it indicates that the overall system reliability improvement ( RSMS − RO ) is about 9% even the system has only one spare equipment manager (Service). If the number of spare equipment managers increases or the reliability of equipment manager (R) decreases the reliability improvement will be relatively raised. For example, the case at Point B on Fig. 8(a) is N-M=2 and R=0.9, then the reliability improvement is about 54%. The purpose of Fig. 8(b) is to evaluate the effect of RGEV on the reliability improvement with M=10, N=11, and RGEV = 1 , 0.95, and 0.9. Figure 8(b) shows that if the

equipment manager has high reliability (R=0.99) and RGEV = 1 , the reliability improvement is about 9% (Point A), while if RGEV = 0.9 , then the reliability improvement is decreased to about –0.9% (Point C) which is not acceptable. Thus for better reliability improvement we should let RGEV > 0.95 . It is worthy to note that the price of an equipment is more than 100,000 US dollars, while that of an equipment manager (usually a personal computer) is less than 3,000 US dollars. And an equipment manager can monitor several

0.93

0.94

0.95

0.96

0.97

0.98

0.99

with various RGEV

Figure 8: Evaluation Charts for Reliability Improvement with M=10 6 Illustrative Example The illustrative example for a semiconductor packaging factory with 1 factory manager (FM), 11 equipment managers (EMs) and 80 equipment (EQ) is depicted in Fig. 9. Because each EM can control/monitor 8 EQ, totally 10 EMs are required to control all the EQ. Therefore, 1 backup EM is shown in Fig. 9. By applying the SMS to this example, FM is the Client, EMs are the Services. If one of the servicing EMs malfunctions, FM will be notified. Then, FM will search for the backup EM and ask the backup EM to replace the abnormal one to continue monitoring the EQ manufacturing process. According to the three phases of the SMS presented in Section 3 and the class diagram in Section 4, the deployment is described as follows. Phase 1: Registration 1) EM 1~11 apply Jini’s Discovery service to discover Lookup Service and provide their Contracts to Lookup Service by invoking register() of ServiceRegistrar. 2) EM 1~11 call set() of GEVProxy to deliver all the contractItems to GEV, then GEV assigns a default Credit value (0.5) to each EM and stores those contractItems and Credit values to the DataBase by invoking createNewService() of DataHandler. Phase 2: Search and Execution 1) FM uses Jini’s Discovery service to discover the Lookup Service. FM, then, searches and evaluates EMs’ Contracts in the Lookup repository and the associated Credit values

3611

2)

3)

4) 5)

6)

maintained in GEV by invoking getCredit() of GEVProxy. In this example, EM 1~10 are selected. After selection, the corresponding Contract proxies of EM 1~10 shall be downloaded by FM such that FM can request services from EM 1~10 via these proxies. FM requests services from EM 1~10 and invoked registerEvent() to ask GEV to notify him if any EM malfunctions. EM 1~10 establish connections to EQ. EM 1~10 start to service and invoke message() of GEVProxy to send Contract messages. If the time of message() is “StartTime” or “StartEvent” then a SuperviseServiceThread and an Evaluator are created to supervise and evaluate the application process of that EM by invoking run() and evaluate(). Meanwhile, the execution status and parameters of the application process are stored to the DataBase by calling backupStatus(). If no error are detected, the Credit value of a healthy EM will be increased by calling changeCredit() after finishing the services.

JINI Lookup Service

FactoryManager (Client)

Generic Evaluator

DataBase

simultaneously. The system will use the primary FM normally. If the primary FM crashes, the Smart Agent will detect it and assign the secondary FM to substitute the primary one for continuing the mission. 7 Summary and Conclusions By applying the Jini and design by Contract technologies and developing GEV, a SMS for semiconductor factory management systems is proposed. The SMS possesses error-detection and function-replacement capabilities. If an equipment manager (Service) malfunctions, the SMS detects it and send an event notice to the factory manager (Client). The factory manager will then search a spare equipment manager and transfer the backup status and parameters of the malfunctioned equipment manager to the spare one. The spare equipment manager can then continue monitoring the equipment started from the point where the malfunctioned one left off. The GEV in the SMS maintains the Credit values of all the equipment managers so that the factory manager can choose better equipment managers for service by checking their Credit values. Reliability improvement formula of the SMS is derived and an illustrative example is presented. From the illustrative example and the evaluation results of the reliability improvement, it reveals that the proposed SMS provide an efficient, reliable, fault-tolerant, and cost-effective mechanism for semiconductor factory management systems. References

Equipment Manager 1 (Service 1)

[1]

Equipment Manager 10 Equipment Manager 11 (Service 10) (Service 11) Backup

[2]

Equipment

Equipment

Equipment

Equipment

[3]

Figure 9:

Illustrative Example

[4]

Phase3: Detection and Replacement 1) EM 10 abnormally terminates. 2) The error is detected and confirmed by GEV, then the Credit value of EM 10 is reduced by invoking changeCredit() and the SuperviseServiceThreads of EM 10 are terminated. 3) GEV notifies FM that EM 10 is down by calling sendEvent2Client(). 4) Do step 1) of Phase 2, then the backup EM 11 is selected. 5) EM 11’s Contract proxy is downloaded by FM. 6) FM retrieves the backup execution status and parameters of EM 10 by invoking getBackup() and sets them to EM 11. Then, FM requests EM 11 to continue monitoring the application process where EM 10 left off and calls registerEvent() to ask GEV to notify him if EM 11 malfunctions. 7) Do Steps 4), 5), and 6) of Phase 2 for EM 11. The Backup for Factory Manager In this illustrative example, if FM malfunctions, the whole factory management system may crash. Therefore, a mirror-type backup shall be prepared for FM. Because the communication between FM and EMs follows CORBA standard [15], the technique of Smart Agent by INPRISE [16] may be applied to implement both primary and secondary FMs

[5]

[6] [7]

[8]

[9]

[10] [11]

[12] [13] [14] [15] [16]

3612

D. Scott, “Comparative Advantage through Manufacturing Execution Systems,” Proc. of the SEMICON Taiwan 96 IC Seminar, Taipei, Taiwan, R. O. C., Sept. 1996, pp. 227-236, 1996. 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,” International Journal of Computer Integrated Manufacturing, vol. 12, no. 5, pp.384-402, Sept/Oct, 1999. SEMATECH, Computer Integrated Manufacturing (CIM) Framework Spe 2.0 SEMATECH, Austin, Texas, 1998. B. Meyer, “Applying “Design by Contract”,” IEEE Computer, vol. 25, no. 10, pp. 40-51, Oct. 1992. R. Mitchell and P. Graff, “Analysis by Contract: An Introduction to UML’s Object Constraint Language (OCL),” IEEE Proc. of Technology of OO Languages and Systems, pp. 448-448, 1998. J. Newmarch, “Adding Contracts to Java,” IEEE Proc. Technology of OO Languages, pp. 2-7, 1998.. R. Mitchell and J. Mckim, “Extending a Method of Devising Software Contracts,” IEEE Proc. of Technology of OO Languages and Systems, pp. 234-251, 1999. Y. Huang and C. Kintala, “Software Implemented Fault Tolerance: Technologies and Experience,” in the 23rd FTCS, Toulouse, France, pp.2-10, June 1993. T. Osman and A. Bargiela, “FADI: A Fault Tolerant Environment for Open Distributed Computing,” IEE Proc. of Software, vol. 147, no. 3, pp. 91-99, June 2000. J. Siegel, CORBA 3 Fundamentals and Programming, OMG Press, 1999. B. Natarajan, A. Gokhale, and S. Yajnik, “DOORS: Towards High-performance Fault Tolerant CORBA,” IEEE International Symp on Distributed Objects and Applications, pp. 39-48, 2000. K. Arnold, B. O’Sullivan, R. W. Scheifler, J. Waldo, and A. Wollrath, The Jini Spec., Addison-Wesley, 1999. W. K. Edwards, Core JINI, NJ: Sun Microsystems Press, 1999. E. E. Lewis, Introduction to Reliability Engineering, John Wiley & Sons, 1996. R. Orfali, D. Harkey, and J. Edwards, The Essential Distributed Objects Survival Guide, John Willy & Sons, 1996. Inprise, VisiBroker for Java Programmer’s Guide, Scotts Valley, CA: Inprise, 2000.