Approaching tool automation with an application program interface standard
07/01/2004
Deploying automation software and tool interfaces for 300mm wafer fabs becomes more complex as Semi standards evolve and expand. One solution is to borrow a key concept from the PC software arena and implement application program interfaces to the 300mm standards. An API format could eliminate most of the software-related problems in tool integration.
Today's call for full 300mm Semi-standard automation means that a wafer-processing tool must have the mechanical ability to receive 300mm front-opening unified pods (FOUP), to move wafers out of a FOUP and into the process tool, and to return wafers to FOUPs. In addition, fab equipment must communicate information on the FOUP, tool robotics, tool control, and tool process results so they can be acted upon by the factory's host computer system. Tool suppliers do the former by selecting from various tool interface and robotics solutions available today. The latter is done through software engineering — either as an in-house custom effort or through a third-party development kit — to make a tool compliant with the following Semi communications standards:
- Transport Protocol Standards describe the physical layer and method by which data (but not the data itself) are transferred between equipment and a host computer [Semi E4 (SECS-I) and E37 (HSMS)].
- Message Format Standards place a layer of organization on top of transport protocols by defining messages used in an equipment-to-host bidirectional conversation [Semi E5 (SEC-II)].
- Specific Functionality Standards add meaning and interpretation to make use of data presented by message format standards [Semi E30 (GEM), E39 (Object Services), E40 (Process Job), E58 (ARAMS), E87 (Carrier Management), E90 (Substrate Tracking), E94 (Control Job), and the emerging E116 (Equipment Performance Tracking)].
Software must work!
Unlike the old days when execution of the simpler (i.e., SECS-I or HSMS, SECS-II, GEM only) 200mm automation standards was hit or miss, today's 300mm tools must hit the wafer fab floor with fully tested automation software that works. Out of the box, equipment standards implementation has to be adhered to exactly, leaving no room for error; if there is an error, it is going to become a major production issue. A fab's host integration team is not going to waste time trying to figure out what has been done with the software on a given tool. It is surprising that some companies believe they can either wait until the last minute and wire together a quick solution and debug it once it hits the fab, or assume that the fab will deal with the existing 200mm interface. The bar has been raised — fabs simply will no longer tolerate this approach.
The rub is that there is a complexity to the list of 300mm Semi standards that makes the task of complete automation difficult, perhaps more difficult than it should be. The standards continue to evolve and propagate; in addition to the standards previously mentioned, evolving standards include E120, E121, E127, E109, PR8-0303, 3510, E132, 3569, 3571, and 3509. Each standard is like an island unto itself. Pulling all of the released standards together and applying them to a tool in a flawless, consistent fashion is difficult without an experienced person to lead the way through this maze. Another complexity is that the standards also leave much room for interpretation; one IC maker does not interpret them the same as another. The 300mm standards are certainly much better than the venerable GEM standard in this regard, but there is still too much interpretation required from fab integrators and tool suppliers.
Adding an API
Clearly, the Semi standards efforts in general have created a remarkable array of documents that have helped the industry in many ways. Many engineers attend standards meetings. IC manufacturers and tool suppliers have supported these efforts, making tool-to-fab integration possible. But times have changed: the volume of standards has made it very difficult to keep up, and these efforts are costly in terms of engineering time. The recent downturn resulted in layoffs of software engineers at tool suppliers — in some cases, entire departments have been closed down — in favor of keeping tool suppliers' core competencies intact. The speed and accuracy with which software standards must be applied on 300mm tools become more challenging every day. With the recovery, many companies are now faced with an immediate need for 300mm compliance, and they are not in a position to respond. These companies now need immediate turnkey software automation solutions from third-party suppliers and a reliable testing method.
The complexities of implementing 300mm software standards could be smoothed out significantly by adding an application program interface (API) at the tool-to-fab connection (see figure). Broadly defined, an API is a set of routines, protocols, and tools for building software applications. A good API provides all the building blocks, making it easier to develop a program. A programmer then puts the blocks together. Most operating environments, such as Microsoft's MS Windows, provide an API that enables programmers to write applications consistent with the operating environment. Although APIs are designed for programmers, they are ultimately good for users because they guarantee that all programs using a common API will have familiar interfaces, so users can learn new programs easily.
A good example of the value of an API is its application to desktop networking back in the early 1990s. When office networking first started, there were seven different suppliers who created their own network cards and software. This meant that an application (e.g., a word processor) had to have a specific interface for each network card and protocol. Not many applications were available that supported all seven network stacks and cards, so office networking continued to be difficult. This was solved when Microsoft worked with other network card manufacturers to create the Network Driver Interface Specification (NDIS) — an API. NDIS-compliant applications had access to all network cards. Within a few years, every argument for having seven different network stacks disappeared. Today, it is NDIS that makes access to the Internet look exactly the same for all applications and the operating system, whether it is via phone dial-up, wired network cards, or a wireless network.
With the Semi automation standards, if each standard included a required API, suppliers would not have to be involved with interpreting all background behavior required behind the API. Each standard's numerical designation could have a "dot number" extension that added the actual API to the standard, similar to what is currently done in applying "dot one" to a standard, thus defining the required SECS-II messages. For example, the creation and destruction of E39 objects could have an actual API defined with the parameters and return values and how that object actually got converted into SECS-II messages. How it was moved over to the host would not matter to the software engineer writing the factory automation interface.
If the standards committees worked on the tool API with tool suppliers, the host API with the IC makers, and the behavior and information exchange with third-party software vendors, then each group could focus on its part without dedicated specialists to understand and interpret the entire standard. With an API in place, the standards themselves could continue to change significantly behind the scenes, without affecting every integration.
Simply described, the Semi standards focus on how (e.g., the amount and types of bytes) information moves from point A to point B. An API, on the other hand, would define the types of information that need to go back and forth, rather than defining the bytes that are contained in a message. For example, an API would ask what file to transfer from A to B by defining the interface that gives the filename and its destination. Contrast this to existing Semi standards that, when transferring a file, define all associated messages, the order of bytes, and other associated technical details related to delivery. So in the standards development process, the API (the "what" of delivery) would remain fixed, while the standard beneath it (the "how" of delivery) could continue to evolve and change. For example, it could use XML and SOAP as its delivery without ever changing the API and getting the IC makers and tool suppliers to agree on "how" to deliver a file. The standards could also change to incorporate encryption and security without affecting the API that tool suppliers and IC makers use.
What needs to be done
So, how does the industry get started with building APIs into the Semi standards process? This certainly is not the first time an API has been suggested. In the past, at the task-force level of developing new standards, the concept of APIs had been discussed occasionally. Thus far, none has been adopted as a standard. Instead, what has occurred over the past year or so is that the committees have created sample interfaces. This happened, for example, with the development of some of the Diagnostic Data Acquisition standards. These examples were not part of the standard itself, but were used to get people started with implementing the standard. This definitely was a step in the right direction. It will make adoption of standards easier for third-party software suppliers, but it will not help IC makers or tool suppliers develop their interfaces, since these example interfaces are not part of the actual standard and there is no guarantee that they will be used.
APIs can be achieved by adding to the current standards process. The document filing structure of Semi standards uses the standard number to define the concept of the standard. For example, Semi E87 is the Specification for Carrier Management, which defines the host computer's knowledge and role in automated and manual carrier transfers; it provides state models and scenarios that define the host interaction with the equipment. Subordinate document Semi E87.1 is the Provisional Specification for SECS-II Protocol for Carrier Management; this document maps the services and data of Semi E87 to SECS-II streams, functions, and data definitions.
The best approach for adding an API would be to create a "dot X" subordinate document (e.g., Semi 87.X) that contains the required API defining the interface and its functions, how to call them, and their parameters. This should be done in an interface definition language document that would allow the API to be used in several different programming languages.
For all standards requiring an API, the "dot X" document would be fixed and perhaps only rarely supplemented, while other documents in that standard's library could be revised as necessary. In practice, tool suppliers would then focus on the "dot X" standard. Software interface developers would continue to work with "dot 1" documents and then implement "dot X" documents. The separation between one third-party vendor and another would be based on optimization, logging tools, compliance certification, documentation, support, and extended functionality.
Pros and cons of Semi APIs
The only obvious disadvantage to an API is that so many tool suppliers already have invested in 300mm automation software and will be reluctant to change a working solution to be compatible with a new API. This could be addressed by a phased approach where initial compliance to the "dot X" standard is not required. Fabs could then have the option to require or not require "dot X" compliance, and thus the API could be phased in over a number of years and existing 300mm tools could continue to claim compliance to 300mm standards at their current level.
There are many advantages to an API approach. Tool suppliers would require less in-depth knowledge of 300mm automation standards. An API also would decrease costs for tool suppliers to implement the needed communication standards by not involving them in the behavior and implementation. Certainly, an API would ultimately improve fab deployment times for tools, perhaps dramatically. While creating an API for factory automation would involve a considerable amount of standards work up front, the biggest benefit may be that an API would increase the amount of exact testing that could be done. An API would allow a whole new level of testing to verify that the "dot X" software complies with the "dot X" standard API and to the "dot one" standard. Things like throughput testing and stress testing could be performed on "dot X" compliant software to verify integrity prior to applying the software to tool supplier systems. This would increase the quality of software supplied to tool suppliers and, in turn, supplied to IC makers.
An API could also lead to pre-qualification requirements of third-party software suppliers based on API adherence. Liken this to the "Windows" logo sticker for Microsoft software and hardware. One reason Windows has a reduced failure rate is because of the Microsoft independent testing requirements for products using Windows.
Conclusion
Just as NDIS solved many problems with desktop networking, an API is the right answer for the Semi standards. Quality will increase, and once everyone agrees to an API for 300mm automation, most software-related integration problems in fabs today will disappear.
Acknowledgment
Windows is a trademark of Microsoft Corp.
Michael D. Feaster is VP of software development at Cimetrix Inc., 6979 South High Tech Dr., Salt Lake City, UT 84047-3757; ph 801/256-6500, fax 801/256-6510, e-mail [email protected].