Windows NTs foundation for equipment automation
07/01/1998
Windows NT`s foundation for equipment automation
Chris Stephens, FASTech Integration Inc., Lincoln, Massachusetts
In a relatively short time, Windows NT has gained a prominent place in industry, including semiconductor manufacturing automation applications. Software vendors are now providing, even via the Internet, off-the-shelf Component Object Model (COM)-based automation solutions - semiconductor equipment communications standard (SECS) and generic equipment model (GEM) interfaces or drivers - that significantly shorten the time to develop, certify, and deploy semiconductor manufacturing automation. For equipment integration teams, 300-mm automation can now be done within a framework or a standard architecture into which previously required custom software components are accepted as though they are standard.
Due to the tremendous cost and complexity of semiconductor equipment automation, a wafer fabrication facility must provide robust communications between equipment and all plant floor activity, including the manufacturing execution system (MES). Managing such a tightly integrated operation is no small undertaking. Depending on a fab`s specific requirements, an automated solution can cost $2M to $3M for software, $2M to $3M for hardware, and $8M to $10M for system integration services. Implementation and deployment of these disparate systems can take more than two years, for those few semiconductor manufacturers who have been able to achieve total automation.
The demands on today`s computer-integrated manufacturing engineering groups to provide cost-effective, reliable solutions for highly automated, 200-mm semiconductor manufacturing facilities are only a prelude to what is coming with 300-mm manufacturing. Future automation solutions cannot be reserved for "the rich and famous" because all semiconductor manufacturers will require total automation to compete in the global marketplace (Fig. 1). Equipment automation is the key to these solutions because it ties the data from the process and product to the applications that drive the manufacturing process.
 |
Figure 1. Although just the "rich and famous" 200-mm fabs could afford total automation, 300-mm wafer processing will require everyone to participate. Fortunately, Windows NT provides inexpensive and relatively easy solutions.
Fortunately, the Windows NT operating system provides an environment that can minimize total system cost and complexity, including hardware, software, development, and maintenance. With NT, equipment automation providers have a stable platform enabling the development of new software with increased functionality, flexibility, and extendibility to support semiconductor manufacturers` specific requirements (Fig. 2). With NT, equipment automation providers now have a stable platform that enables the development of new software with increased functionality, flexibility, and extendibility to support semiconductor manufacturers` specific requirements.
 |
Figure 2. A cost comparison of UNIX-based automation solutions vs. Windows NT for a medium-size fab. With NT, manufacturers no longer need to code their solutions, thereby lowering total automation cost.
NT`s wafer fab evolution
PCs have not always been easily accepted on factory floors. Released in 1993, the Windows NT operating system was at first not synonymous with high-end, mission-critical applications; instead the UNIX operating system was the overwhelming platform of choice. Written in C programming language, UNIX-based automation solutions have had the reputation of portability (i.e., less machine specific) and the capability to handle high-speed transactions and computations without compromising system reliability. However, as Microsoft developed NT into its enterprise operating system, architectural changes to the operating system`s application programming interface (API) significantly increased performance and reduced memory requirements [1].
These improvements, released with Windows NT 4.0, were important for the operating system to be considered seriously by industry in general and semiconductor manufacturers in particular. Windows NT quickly proved to be stable and reliable; increasingly, it has been accepted on the factory floor particularly with its introduction into client-server applications. As a result, legacy UNIX solutions are being replaced not only with inexpensive PCs, but also with software solutions in which time to develop, deploy, and commission are reduced.
UNIX systems continue to be the system of choice for servers and data repositories, while PCs are taking the lead as user interface and equipment interface "clients." A typical site will have a handful of servers and hundreds of clients.
NT enables software integration
Because Windows NT 4.0 has proven successful in manufacturing operations, software automation vendors are taking advantage of its capabilities, including COM technology.
COM is a Microsoft Window`s specification for building software components, typically in C++ language, that can be assembled into applications or solutions. It is a general framework that allows different pieces of software to interact or provide services to one another, and allows these services to share different reusable code libraries [2].
These software components, which are also known as ActiveX controls, use COM technology to provide interoperability with other types of COM components and services. (ActiveX was built on COM and developed as a proposed standard by Microsoft in the mid-1990s.) This means that equipment automation software vendors can use ActiveX as a common way to integrate applications, which can be created using commercially available programming environments such as Visual Basic to glue together the components, adding solution logic.
For example, one software vendor might only specialize in providing services for equipment connectivity and communication to the MES, while another vendor might provide only computerized maintenance management system software. Using Visual Basic, the functions of each vendor`s application are revealed through its ActiveX control. In this way, a solution integrator can use software components from two or more vendors and integrate each application into a single solution. This type of framework greatly reduces the taxing effort of creating and maintaining custom code. Additionally, automation solutions benefit from having the flexibility to easily integrate different software applications, such as a statistical process control (SPC) solution or a recipe management package, into an existing system.
Case study: Fujitsu LSI Technology
Fujitsu LSI Technology (FLT), a Fujitsu subsidiary based in Kawasaki, Japan, is a good example of a first time NT user satisfied with its solution results. As a systems integrator with extensive semiconductor experience, FLT decided to implement an NT equipment-automation solution for a new multichip module manufacturing line because of its requirement for rapid deployment; FLT developed the solution using software containing ActiveX Controls and Visual Basic as the programming language. The goal was an automation system that would interface processing equipment, a material handling system, and FLT`s FACTORYworks MES.
At FLT, the project started with small teams of specialists assigned to specific tasks. One group configured the MES and material handling system. Another team was challenged to create operating scenarios - sequences of events, actions, and responses from the equipment up to the MES. Finally, an equipment integration (EI) team was in charge of developing equipment interfaces.
Using software designed specifically for equipment integration, the EI team developed generic SECS interfaces, the industry`s standard protocols for equipment communication. These generic interfaces were used as templates for many different pieces of the same types of equipment (i.e., from the same vendor). For example, a one-time developed equipment interface for a wafer stepper in lithography was applied to other steppers. For each additional stepper, the only changes required were updating parameter values specific in each SECS message like equipment status variables and event-reporting variables. By developing template interfaces in Visual Basic, FLT was able to reduce resources and still complete the integration on schedule.
While the EI team addressed interfacing of equipment, the "scenarios" team addressed crucial issues associated with careful planning of logical sequencing of events between systems. This team had to make sure that the MES and material-handling systems communicated logically and in sequence with the equipment. In designing a solution, the team had to consider the facility layout (which has multiple levels with several bays on each level), processing equipment in each bay, and a material-handling system. At this factory, material is moved by several different methods, including equipment-to-equipment movements by an operator, bay-to-bay movement by an automatic guided vehicle, and floor-to-floor movement by a lift.
Development of the operating scenarios began with ladder diagrams or plots of point-to-point actions of an operating sequence or event. A ladder diagram is a good visual aid for showing the sequential order of all the events and actions, from top down, from each system. After the events were mapped to a ladder diagram, they were then developed in Visual Basic (i.e., the same software application that the EI team used to interface the equipment). Ultimately these operating scenarios were developed into a single application that then acted as an equipment manager, handling or translating communications between each application. Common development tools for different components of a solution simplified the integration effort.
The final equipment automation solution was deployed in concert with the MES and material handling systems. It was entirely developed using software with ActiveX Controls and Visual Basic. One of the big advantages is that since FLT now has an ActiveX-based component solution, when future needs require upgrades or additional applications like SPC, further integration will be relatively straightforward as long as FLT engineers select software applications that follow the COM model. This means that FLT does not require expensive expert programmers to make changes to its system; future maintenance will not be a burden.
Even though this was FLT`s first time deploying an NT solution, the time to develop, test, and deploy was less than one year. Overall, FLT deployed a reliable system in considerably less time than if they had had to learn how to implement a legacy UNIX solution (Fig. 3).
 |
Figure 3. Windows NT has helped station and equipment integration merge into third-party equipment automation solutions that communicate; a) legacy UNIX system and b) today.
Now, little or no coding
FLT successfully created a solution rooted in Windows NT technology. COM is a software standard but not an equipment automation solution standard. Therefore, FLT had to create an architecture for developing its solution and then code its drivers and operating scenarios with this architecture. Similarly, any site creating an NT-based solution has to create such a "one-off" architecture.
Today, even this level of detail has been eased. Vendors are now providing SECS and generic GEM-compliant equipment interfaces or drivers without the need for system integrators to create driver templates or write any custom code. This means even faster automation system development; EI teams can simply test and commission off-the-shelf drivers provided on a compact disk or even via the Internet.
These drivers, covering simple, batch, linked lithography and clusters, are configured from a set of standard capabilities for equipment integration that are often called services. These services are COM objects that can be created in Visual Basic, VCH, or other languages. Visual Basic is the easiest to use and least expensive to maintain. Services can contain SECS message formats, logic from an ActiveX Control, or an API from a MES. Because services encapsulate logic, the equipment automation solution can connect in the same way to the equipment, a MES, a material-handling system, and any application with an open API.
Providing equipment drivers and services is only part of the advances in automated solutions that have built on Windows NT. More important, software tools now provide capabilities to configure operating scenarios using an intuitive graphical development environment. These software tools enable the use of state-transition diagrams or Harel statecharts [3] that are the standard for state machine and reactive system designs in many software development markets such as semiconductor manufacturing.
In the past, solution developers were forced to design and document operating scenarios in one environment and then program the solution in another. These environments are now collapsed together. For example, ladder diagrams are simply drawn up as state diagrams. However, drawing state diagrams is itself also only the beginning. The real power behind this technology is the capability to map services to a state diagram. Integrated development environments allow methods and events to be attached graphically to a state or transition (between-state event). During runtime, the state software engine triggers and executes these services. Equipment, MES, material handling, and other applications services thus become the logic of the automation system. All of the development is done graphically in one environment.
In the FLT case study, even though implementation time was faster than the usual approach, the system still took many months to develop, test, and commission. At the time of FLT`s project, creating operating scenarios was possible only by writing code, which the company did using Visual Basic (Fig. 4). However, what used to be a programming-intensive activity of coding scenario logic a short time ago, now only requires services to be attached to a state or transition. What is interesting about FLT`s case is that the operating scenario logic they painstakingly developed can be captured or encapsulated into services. And once captured as services, they can be reused for future projects.
 |
Figure 4. The evolution of equipment automation solutions.
Conclusion
With the emerging transition to 300-mm equipment and cluster tools, communications to external systems are going to become increasingly important. A Windows NT-based solution successfully implementing COM can make this transition much easier. The time to develop, certify, and deploy an automation solution is reduced due to the availability of off-the-shelf equipment interfaces, along with a framework - a productized architecture into which the inevitable custom components are accepted as though they are standard. NT allows for object-oriented component solutions, significantly reducing the custom code requirement. Once the framework has been defined, the benefits are even greater not only for the integrators, but also for end-users because the interface and behavior are standardized. In addition, future functionality can be purchased from many vendors offering their specialized solutions, such as wafer fault detection systems, increasing the flexibility and extensibility well beyond the development resources available within the factory.
Clearly, Windows NT is a platform for which automation software companies are providing reliable and functionally rich solutions. As these software products continue to mature, the rapidly increasing requirements for manufacturing automation should be satisfied.
Acknowledgments
Microsoft, Windows, Windows NT, Component Object Model, and Visual Basic are either registered trademarks or trademarks of Microsoft Corp. UNIX and ActiveX are administered by the Open Group (the Open Software Foundation and X/Open Company Ltd.), a consortium of computer hardware and software manufacturers and users from industry, government, and academia that is dedicated to the advancement of multivendor information systems. FACTORYWorks is a registered trademark of FASTech Integration.
References
1. J. Prosise, "Windows NT 4.0," PC Magazine, Sept. 24, 1996, http://www.zdnet.com/pcmag/features/software/1516/ntintro.htm.
2. D. Chapel, D.S. Linthicum, "It`s invasive. It`s ubiquitous. But what, exactly, is ActiveX?" BYTE, Sept. 1997, http://www.byte.com/art/9709/sec5/art1.htm.
3. David Harel is the inventor of the language of statecharts. He is the William Sussman Professor of Mathematics at the Weizmann Institute of Science in Israel.
CHRIS STEPHENS is a graduate of Georgia Institute of Technology in Atlanta. He works in Tokyo, Japan, as an application engineer for FASTech Integration Inc., 55 Old Bedford Rd., Lincoln, MA 01773; ph 781/259-3131, fax 781/259-3188.