Ethernet and XML: Future Standards, Available Today

Although the semiconductor equipment industry has a widely utilized standard for extra-tool communications (the Semiconductor Equipment Communication Standard, or SECS), no similarly unified view exists for connectivity to subsystems and components within the tool itself. Instead, today's semiconductor tools incorporate a plethora of hardware and software protocols, including Profibus, DeviceNet, LonWorks, and several variations based on the Ethernet hardware standard.

The lack of a widely accepted intra-tool connectivity standard impacts the cost of individual subsystems and components by forcing suppliers to support a variety of hardware interfaces and software protocols on every product, and creates significant barriers to cross-subsystem communication. Resolving this situation requires that the industry standardize on an electrical interface and agree on a corresponding software protocol that provides enough flexibility to support a wide range of applications. Achieving consensus on such major issues ordinarily requires considerable time and effort.

Fortunately, the semiconductor equipment industry can significantly shorten the process of establishing an intra-tool connectivity standard by effectively taking advantage of similar ongoing efforts. Following the lead of other industries (e.g., process control, industrial automation and factory automation), recent attention is converging on an architecture with separate control and data networks, intelligent subsystems to reduce data transmission, and use of the eXtensible Markup Language (XML) for transferring data.

1. In today’s tools, subsystems and sensors connect to a single intra-tool network directly or through a variety of analog, digital and serial ports.

Today's semiconductor tools use a single network for both command and data (Fig. 1). Subsystems and sensors connect to the intra-tool network either directly, or in many cases through a variety of analog, digital and serial ports managed by an input/output controller (IOC). All communication with the fab flows through the tool controller. Thus, the network must provide enough capacity to support not only the command volume, but also the aggregated data flow from all subsystems and sensors — thereby creating a chokepoint at the tool controller. Future tools will transition to the split network topology shown in Figure 2 . This architecture acknowledges the inherent difference in requirements between the command network (where speed is critical and determinism must be maintained) and a data network dedicated to non-controls applications such as fault diagnostics. The chokepoint found in current tools is thus eliminated while improving overall performance.

Creating dual intra-tool networks would ordinarily raise concerns over increased cost. However, the use of Ethernet for both networks can substantially alleviate this concern. Ethernet underpins much of the network connectivity enjoyed throughout the world today. As such, it provides the benefits of speed, widespread understanding and compatibility with the industry's current extra-tool communication standards. In addition, it enjoys a nearly unlimited future as technological advances continue to push the system's bandwidth limits.

2. Future tools will have separate networks for command and data.

Current Ethernet chip sets typically provide dual channels as a standard feature. Thus, the cost penalty associated with incorporating dual Ethernet networks in subsystems (and even sensors) is minimal or non-existent. Likewise, legacy subsystems can be connected to Ethernet through simple, low-cost data interface modules (DIMs).

Although separating subsystem data from the control network resolves several critical problems, it still cannot enable the raw transmission of sensor and subsystem data to the fab. As an example, a typical power supply will use 20-30 data elements (including temperature measurements on components, voltage measurements at various locations, etc.) in an advanced fault diagnostic and prediction (FDP) algorithm. Each data element is 1-2 B in length and is sampled at rates of 1-1000 Hz — thus, each power supply in a tool will generate on the order of 20 kB/sec of FDP data. In a typical fab of 300-500 tools (each with an average of 3-5 power supplies), the data rate for just power supply FDP applications would therefore range from 15-50 MB/sec. Transferring this data over Ethernet would require a minimum bandwidth of 150-500 Mb/sec. However, Ethernet is rarely run at full bandwidth — packet collisions and overhead factors normally dictate that the network be operated at 20-50% of full capacity level. Thus, the actual network requirements for just power supply FDP would be in the 300-2500 Mb/sec range — well beyond any network technology on the near horizon. Adding the data rates from other subsystems, process sensors, etc., only further exacerbates the problem.

Clearly, there is no cost-effective way to centrally process raw FDP data from subsystems and sensors. Resolving the data transmission problem requires that subsystems directly incorporate FDP algorithms. Future subsystems (Fig. 3 ) will identify events (e.g., temperature excursions) that require notification to either the tool or fab level; transmit the event and associated data as required; and maintain event histories to support continuous quality improvement efforts.

Accomplishing this, however, requires that customers first identify the events that require notification to either the tool or fab level; specify what data needs to accompany each event; and define flexible protocols capable of supporting the diversity of needs across the industry.

Current semiconductor manufacturing equipment relies on the SECS/GEM point-to-point communication standard for both command and data exchanges. While this standard has served the industry well, its ability to meet the industry's growing data networking demands is limited by several key shortcomings that stem from its Electronic Data Interchange (EDI) roots. EDI standards such as SECS/GEM generally provide highly efficient communications. However, all EDI protocols suffer from several fundamental problems that derive from their basic system-level design criteria:

• Their point-to-point architecture limits connectivity. EDI standards are intended for direct communication between two computers — the basic EDI architecture is not capable of supporting concepts such as publish-and-subscribe or multicast transmissions.
• The message formats are complex and inflexible. EDI practitioners quickly found that standard transactions are rare in the real world. The different data needs of companies within industries pushed increased complexity into the standard, and encouraged companies that could control specific communication channels to deviate from the standard.
• As with most binary messaging standards, EDI requires a significant procedural effort to control the message format. Proposed changes typically take years to be formally adopted, then require careful coordination to ensure proper rollout.
• EDI transmissions are "brittle" — the receiving system cannot tolerate deviations from the expected format. EDI protocols incorporate no method for "tagging" data. Thus, communication requires that both sides possess full knowledge of the binary message format for accurate decoding. The transmitting system cannot caution the receiving system regarding deviations from the expected format, nor can the system (or human operator) "read" an EDI message to determine which version of the standard was used to compose it.

All of these problems are manifested in the semiconductor industry's current SECS/GEM protocol. Resolving these problems represents a significant effort. However, just as the SECS/GEM problems mirror that of EDI in general, the semiconductor industry can utilize developed approaches in defining an appropriate solution.

3. Resolving the data transmission problem requires that subsystems such as RF generators directly incorporate fault diagnostic and prediction algorithms.

The solutions to EDI's problems were found in the definition of a new language for Internet transactions. XML was developed by a small group of experts as a metalanguage that could be used to spawn application-specific dialects without requiring lengthy negotiations over "standards." The results to date have been impressive — XML has quickly become the workhorse of the modern communications world.

XML dialects are now either under development, in use or in various stages of standards certification for vertical markets ranging from arts and entertainment, to healthcare, banking, robotics and transportation. XML is also used to store a wide variety of data from scientific endeavors, library catalogs and other applications without concern over reformatting databases whenever data formats are changed.

The features of XML of greatest application to the semiconductor equipment industry include:

• Freely extensible. XML imposes no limitations on the ability of users to define new dialects. Since each XML data transmission includes information on the dialect (and version) used to format it, the dialect can be easily and frequently extended and refined.
• Character-based. Although XML is frequently used to encapsulate binary data, the actual structure of the message is transmitted in simple text. Thus, the resulting transmission is human-readable — a significant aide to debugging.
• Supports many-to-many relationships. Because XML provides the receiver with information on each message format, it can easily span multiple vocabularies — something EDI cannot do. In addition, XML is fully compatible with Web-based delivery systems that can simultaneously serve multiple data connections.
• Resilient. Unlike EDI, XML-based messages inherently contain version control. Thus, the knowledge necessary to decode the message is always provided at the time of transmission — thereby eliminating communications breakdown due to incompatible data formats. This brings a plug-and-play capability for new subsystems and sensors without current concerns over mismatched protocol versions.
• Reusable. The machine- and platform-independent nature of XML translates into a write-once, deploy-many-times character that significantly reduces development and maintenance costs.

The primary drawback to XML is its inherent verbosity. Because XML defines the meaning of every data element in a transmission, XML-formatted messages are significantly larger than an equivalent EDI version. This dictates that XML's primary use be on the intra-tool data network, and to transfer summary data from tools to the fab.

Adoption of dual Ethernet networks and an XML-based data communications standard by the semiconductor equipment industry would provide a low-cost, highly configurable solution to the subsystem and component connectivity problem that could be readily extended to encompass the industry's entire communication needs. In support of this goal, Advanced Energy is working with others to develop a prototype of this concept that:

• Utilizes separate Ethernet command and data networks.
• Incorporates intelligent subsystems with integrated fault diagnostic and prediction algorithms.
• Defines and utilizes a new semiconductor-specific XML dialect for data transmission.
• Demonstrates appropriate security software at both the tool and subsystem level.

The results of this effort (expected to be completed later this year) will be communicated to the industry for use in standards definition efforts. In addition, the XML dialect and security software will be disseminated to the industry under an open-source license.