|
by David Sheriff (This article originally appeared in Solid State Technology, February 1996) |
|
(But go ahead, read it first so we're on the same page.) |
|
Sometimes failure is a powerful teacher. For four years, SEMI standards task forces have tried and failed to establish a sensor bus communications standard for semiconductor production equipment. I led the group for the first three years, and the experience has left me with a strong appreciation for the limitations of the process and the role of the market in ultimately determining standards. In January 1992, Unit Instruments met with representatives from other major mass flow controller manufacturers in a SEMI standards task force to develop a network communications standard for MFCs. Most MFCs today are built to de facto physical and analog electrical interconnection standards. These standards were set by copying the first widely successful product in the industry, the Tylan FC-260. In 1992, virtually all of our products were based on analog circuits. We all knew that the next major wave of MFC product performance improvements would be based on digital technology. To take full advantage of the capabilities of digital products and to cut costs and development time for new tools, networked serial communications would have to replace the existing analog interfaces in semiconductor production tools. Tough competitors, we were still able to agree that our customers would be better served and our new products would be more quickly accepted if we could standardize network communications. We would also have less development work if we only had to support one standard. The lives of field technicians working on these products would be easier if they had to carry the tools to diagnose problems on only one type of network. Customers would have to live with only one network in their tools. It seemed like a reasonable idea. Four years and many ballots later, not only do we not have a standard, but those in the SEMI standards task force with more taste for the project than I are now attempting to develop a complex "cafe" system of interrelated standards. This system is intended to provide equivalent communications over many different incompatible commercial networks. It's not easy. Device data structure and behavior tend to be optimized for the features of a particular network, so it is hard to develop a device that will work equally well on any network. Within a few months in early 1992, my task force had drafted a proposed command and data set as well as an RS-232-based network and protocol. It was simple, inexpensive, fast enough for MFCs, and the hardware required was physically small. Unfortunately, we abandoned this sensible approach. When we showed our draft standard to others in the industry, we were told that it looked adequate for MFCs but that it was too slow for other components within a process tool that might benefit from networked communications. We heard that siren call; we thought that if we defined a more powerful standard that worked with everything, then customers would be sure to adopt it, and it would last for years. Obligingly, we enlarged the scope of the standards task force and proceeded to work on a standard for a sensor/actuator bus for semiconductor process equipment, using MFCs as an example device. We wrote a suite of related standards -- one for the net work, one for behavior that every device on the network would have in common, one for MFC-specific behavior, and a guide to the standards architecture. In 1994, we were still convinced that our real challenge was to decide objectively which of the commercially available network solutions would best suit the industry's requirements for capability, size, and cost. Many people from semiconductor fabs and equipment companies supported this position. They did not want to be placed in a situation where each component or tool vendor used a different network, forcing them to support multiple systems. We did not want to support multiple network versions of otherwise identical products. We had forgotten one little thing - that the SEMI standards process is based on consensus, and anyone who declares themselves interested gets to vote. Some of the commercial vendors who were not selected lobbied for votes against the ballot, and it went down in flames in late 1994. The SEMI standards process is heavily weighted to favor negative votes; the ballot never had a chance in the face of determined opposition. Competition is messy and can be a duplicative, inefficient process for selecting the surviving alternative when there is a lot at stake -- but it is the best we have. The standards process is the wrong tool for picking big winners even when we are presumptuous enough to make a technical case that one solution is better than another. Where competing commercial solutions exist, the market picks winners. The semiconductor equipment and components industries and their customers may not like living with multiple networks across their production tools, with different networks for different customers, but that is what is going to happen for a while, in spite of our best intentions. The experience should also teach us once again the value of restricting the scope of a project. We started out to agree on a communications standard for mass flow controllers. If we had not gradually expanded the scope of the process until we were trying to cover all sensors and actuators in the tool, we probably would have kept a low enough profile to be successful within the first year. In all likelihood, we MFC manufacturers would have moved on to second-generation products by now. Instead, we all now have incompatible solutions that will not communicate on any network. Efforts continue to be made to develop a complex suite of semiconductor process-tool sensor/actuator bus standards that will encompass many incompatible commercial networks. I'm sure the current committees will eventually succeed, although at significant cost; and in the end the market will decide whether one of the multiple solutions offered will become the real standard. What a strange process. |
|
|
|
|
|
|