Data processing: generic control systems or specific application – Specific application – apparatus or process – Product assembly or manufacturing
Reexamination Certificate
2002-08-16
2004-10-26
Picard, Leo (Department: 2125)
Data processing: generic control systems or specific application
Specific application, apparatus or process
Product assembly or manufacturing
C700S095000, C717S170000
Reexamination Certificate
active
06810294
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to automation systems, and more particularly, to a method and apparatus for automating equipment used in a microelectronic manufacturing process.
2. Description of Related Art
Automation systems have been used in a variety of microelectronic manufacturing processes such as in processes to manufacture semiconductor devices, flat panel devices and disk drive devices. For example, in a typical semiconductor manufacturing facility (Fab), semiconductor fabrication equipment and metrology equipment are used to fabricate and test semiconductor devices located on silicon wafers. In the past, the manual operation of equipment in a Fab has been tracking information. The semiconductor industry has thus moved to automated semiconductor manufacturing processes to alleviate these problems of manually operating a Fab.
While automated semiconductor processes have alleviated the material handling problems described above, these automated processes are costly, time consuming, have limited reusability and limited extensibility. Present automation processes are costly due to the amount of time and resources needed to characterize new equipment and then develop a custom (close fitting) automation software or a general purpose (loose fitting) automation software to automate the equipment in a Fab. In either case, a large amount of effort is spent in rigorously testing the automation software (e.g. testing of 40-60 software programs (one for each equipment) in the case of the custom software and one giant software program (for the general purpose software). In addition, any code changes in either the custom or general purpose software has global system ramifications that must be performed by experienced programmers. Furthermore, any changes to the code requires regression testing on all equipment types to be certified for production release. The software release management thus becomes very critical, prone to errors and time consuming. The use of the custom to the process flow for fabricating a certain semiconductor device, or should the characterization need to be adjusted for a piece of equipment, the Code Model requires that a build of the custom and/or general purpose software be performed repeatedly. Repeated builds take a substantial amount of programming and testing time as well as equipment downtime to accomplish. There is therefore a need to reduce the costs associated with updating the custom and/or general purpose software, as well as costs incurred due to downtime of the equipment. The costs incurred with the Code Model are associated with the limited reusability of the custom and/or general purpose software since that software must be updated when new process steps or additional characterization is needed. Likewise, extensibility of an automation process utilizing the Code Model is limited due to the additional programming needed.
An attempted solution to the Code Model problem has been to move towards an object-oriented solution. A component model approach (“Component Model”) has been proposed to reuse objects, rather than code as in the Code Model, to the extent possible by treating the code objects as components. This approach would use, for example, Component Object Modeling (COM) paradigm, which is well known in the art, to improve the reusability of defined components. The Component Model, however, is limited in that it requires a substantial amount of reprogramming, much like the Code Model, in order to change the semiconductor manufacturing process. Furthermore, the Component Model requires a programmer to understand COM, which is not generally known. Thus, the Component Model also suffers from high cost due to limited automation process reusability and extensibility. Further, the automation software developed using the Component Model would be limited to a particular piece of equipment. Thus, there would be as many different programs as there are equipment types in a Fab. Still further, it is difficult to maintain and support so many variations of the code.
Various computer architecture and methodologies, separate from the Code and Component Models, have also been used to achieve and improve automation processes. For example, factory automation has moved from a two-tiered client/server architecture to a three-tiered architecture to provide a more efficient automation process. Clients are defined as computational entities that request service resources, while servers are resource entities that respond to service requests. Thus, servers provide services and other resources to clients which consume them.
In a traditional two-tiered client/server architecture, the client communicates directly with one or more database servers or external systems to execute various tasks. The disadvantage of the two-tiered architecture is that either the client or the server contains the business logic, a collection of rules that define the system logic. This reduces the reusability of the client and/or server because, wherever the business logic resides, that portion of the code may not fit into a different business model. Usually, such changes are incompatible with earlier versions of the client, resulting in a fragile application.
These problems with the traditional two-tiered client/server application have been addressed by a three-tiered architecture. The three-tiered architecture partitions the automation process into three logical layers: the user interface layer, the business rules layer and the database access layer. In this architecture, the user interface layer resides on the client. The business logic layer, the database access layer and the database itself reside on the server. The three-tiered architecture makes the application less fragile by further insulating the client from changes in the rest of the application. In other words, the three-tiered client/server architecture reduces application fragility by providing more insulation and separation between layers. The user interface layer communicates only with the business rules layer, rather than the database access layer. The business rules layer, in turn, communicates with the user interface layer on one side and the database access layer on the other. Thus, changes in the database access layer will not affect the user interface layer because the two layers are insulated from each other.
The three-tiered architecture approach is best suited for database applications due to this insulation. However, in a Fab, where services are required to communicate with equipment, as well as other devices and systems, additional tiers are necessary. A need therefore exists for an architecture that incorporates additional tiers for automatic interfacing with semiconductor equipment within the Fab.
In the past, automation processes have used a three-tiered architecture in combination with the Component Model. A configurable state machine was used with reusable components for equipment interface. However, a problem remains in that approach in that one program controlled only one piece of equipment and extensibility was limited because multiple versions of code existed that must all be updated should changes be necessary. Also, changes to a process or equipment often required code level changes that are complicated and time-consuming.
A combination of an object-oriented approach, such as a distributed model, with a multi-tiered architecture approach, has been described by a technology standard for distributed objects known as Common Object Request Broker Architecture (CORBA), developed by a consortium, Object Management Group. In CORBA, clients and servers exist in a distributed environment. Distributed objects are most often deployed in a client/server configuration. Objects may themselves be servers. Rather than differentiate between business logic and data access, the distributed system model simply exposes all functionality of the application as objects, each of which can use any of the services provided by other objects in the system, or even objects i
Balakrishnan Ramesh
Pitchaikani Balaji
Rangachari Murali D.
Sharma Arun Kumar
Asyst Technologies, Inc.
Jarrett Ryan
O'Melveny & Myers LLP
Picard Leo
LandOfFree
Method and apparatus for automating a microelectronic... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for automating a microelectronic..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for automating a microelectronic... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3320753