SECS is overrated
07/01/2000
Charles Baylis
 Charles Baylis |
Have you ever tried to suck a baseball through a straw? Getting vital information from semiconductor tools via the SECS interface is like that. Suck hard enough on the straw: the best you will get is a mangled baseball. As a result, trying to automate a 300mm fab using the SECS standard will drive automation costs through the roof.
Don't get me wrong. I like the SECS (Semiconductor Equipment Communications Standard). I have made a nice living dealing with the complexities of SECS and GEM. Even so, I don't like the prospect of trying to extend it over the next decade. It is one thing to make a living delivering automation systems that work. It is quite another to engage in a fruitless effort to extend a technology past its useful lifetime. The useful lifetime of SECS ends with 200mm fabs.
What is wrong with SECS and GEM? Here are the main problems:
- SECS is not a discoverable interface. The factory automation system cannot query the SECS interface to determine its capabilities. No matter how sophisticated the factory automation system may be, the SECS standard requires a large manual integration effort for each tool. This is the reason for a substantial cottage industry to create tool "drivers." These drivers are doing nothing more than supplying the factory with the configuration information that is not available over the SECS interface.
- SECS supports only a single client. The SECS cable is a point-to-point link. There is exactly one software process (i.e., one point) on the factory side of the cable. This is a critical limitation. Clearly there are many parts of the entire factory automation system that could beneficially access information from the tool.
- SECS does not reveal the structure of the tool. It is impossible to determine the physical makeup of the tool by looking at the SECS messages. This prevents truly generic factory systems for important tasks such as remote status display and diagnostics.
- SECS has no security mechanism. There is no concept of client authentication or access permissions in SECS. This has not been a hot issue, because of the point-to-point nature of SECS. But if we expand the potential for connection points, then we must have a security mechanism as well.
The dubious role of the
 |
I know you are asking yourself "Now if these problems are really so awful, why does SECS seem to work well enough today?" Fair question. Resourceful factory automation engineers have invented a software component called the station controller. The station controller "owns" the SECS interface to the tool. It deals with the SECS messages, and performs two important jobs. First, it presents the factory with a view of the tool that is much more convenient than the SECS interface. Second, it adds several data communications capabilities missing on the tool. Examples are process job setup and recipe control. As a result, the factory information system sees the tool not as a SECS interface, but instead, as the enhanced interface presented by the station controller. It will come as no surprise that modern station controllers present an object-oriented view of the tool to the factory.
In the big picture, the station controller is a very expensive layer of software that should simply not exist. If the factory wants to view the tool in an object-oriented way, why haven't the tool manufacturers presented this preferable interface directly? In fact, there is a simple and legitimate reason: SECS is a standard. Station controllers are proprietary. Clearly we cannot expect the tool suppliers to ship various versions of proprietary station controllers as their factory interface.
As the industry moves to 300mm production, we need higher levels of factory automation at acceptable cost. The key to acceptable cost is interoperability among solution providers. The key to interoperability is standardization. Automation components, starting with the tool, must fit together like building blocks. We have known this for years and have collectively guided our industry's primary consortium, Sematech, to invest millions of dollars searching out solutions to this knotty problem.
New standards?
Ah, you say, he is about to ask for new standards! Not so. We already have them. First, Semi has developed a set of 300mm standards for such important areas as process job management, carrier management, and reliability and maintainability. Second, Semi has developed an object-based equipment model (OBEM) that is an excellent alternative to SECS. Third, there are several well-accepted standards for distributed object communication across a network. I say let's simply put these standards to work.
Here is my abbreviated roadmap for a revolution in semiconductor factory automation:
1. Replace SECS with OBEM. The native view of the tool should be this object-oriented standard.
2. Implement the 300mm automation standard on OBEM. Once we have an object-oriented view of the tool, the 300mm standards can be implemented more simply, and as independent components.
3. Use available distributed object standards. The software providers should supply various implementations for distributed object communication, but all should be based on accepted standards. My picks would be DCOM, CORBA, and SOAP/XML; in the end, the market will and should make this decision.
4. Retain that GEM interface. A one-size-fits-all GEM interface can be generated from the OBEM model. This would provide the migration path from SECS/GEM to OBEM, and it would co-exist with the OBEM presentation of the tool.
This roadmap will give us tools that fit naturally into the factory automation systems. At domainLogix we call this the Factory-Keyed Tool.
Don't forget the Web
By shifting to an object-oriented view of the tool, we can remove the entire station controller layer of software from our factories and support 300mm standards. These are sufficient reasons to make the shift today. There is another reason, perhaps even more important: the World Wide Web. The Web enables worldwide access to information. New technologies such as XML make complex information structures accessible. As the complexity of the factory and associated information structures increase, so do the levels of expertise needed to build and support it. If competent engineers were cheap, we could simply sit one down next to each tool in the factory. Unfortunately, they are neither cheap nor readily available. The Web can amplify the productivity of our scarce engineering support personnel.
What does the Web have to do with an object-oriented view of the tool? Everything. Take a look at the problems I listed at the beginning. I claim that we need to solve these problems before we can turn Web access to the tool into reality. Additionally, the object-oriented paradigm is a natural fit to a Web browser. SECS messages are not.
So I say to the industry: Let's drag ourselves kicking and screaming into the next century by synchronizing our factory systems with the current state-of-the-art in information technology. We need to embrace modern object-oriented techniques, and leverage the power of the Web. This is the only way to achieve the tool productivity goals of the National Technology Roadmap for Semiconductors.
Charles Baylis is VP of product services at domainLogix, 8303 N. MoPac Expressway, A-101, Austin, TX, 78759-8374; e-mail [email protected].