The Standard Pieces of SEMI's Interface A

Many industry experts foresee wafer processing equipment containing Interface A data ports as the future to improving semiconductor manufacturing productivity, because it serves as a crucial enabler for factory Equipment Engineering Systems (EES) applications, which include advanced process/equipment control (APC/AEC) and e-diagnostics. With the Interface A standards crystallizing over the past few years, experts envision EES applications as vital elements to improve quality, reduce process variation and increase overall equipment effectiveness. Through a robust Interface A port, wafer fab operations have access to a new level of detailed process, metrology, operational and other data. Previously, the restrictions of the venerable SECS/GEM data ports on tools limited this data stream and delayed the implementation of APC/AEC.

Many variables can potentially affect Interface A performance. Cimetrix's experience working with Interface A includes a pilot project with NIST and AMD during 2003, an ISMI-funded prototype Interface A solution with a Tier 1 equipment supplier during 2004 and early 2005, and another fab pilot project scheduled for 2Q05.

An Interface A port is achieved with successful implementation of SEMI standards E120, E125, E132 and E134. Interface A facilitates communication between data-gathering software and a piece of wafer fab equipment, which was formerly referred to as equipment data acquisition (EDA). Interface A is accomplished using SOAP/XML messages over an HTTP or HTTPS connection. Interface A provides multiple client (the software consumer of equipment data) access to data-gathering capabilities. It does not replace SEMI's GEM/SECS or 300 mm standards, the standards for equipment control and configuration. Interface A must be supported in addition to these other required interfaces (Fig. 1 ). Interface A is also distinct from Interface B and Interface C: These are collections of SEMI standards that facilitate data sharing between applications, such as statistical process control and run-to-run analysis (Interface B); and remote access to equipment data, primarily for diagnostics and maintenance (Interface C).

1. Interface A provides multiple client access to data-gathering capabilities. It does not replace SEMI’s GEM/SECS or 300 mm standards.

Over time, Interface A should replace the need for any other data-providing interfaces. In practice, some initial Interface A implementations may provide little more data than the SECS/GEM interface, but eventually they are expected to expose significantly more information, particularly process information, sensor feedback, actuator states and other primitive data, to analyze product improvement, equipment maintenance and equipment utilization. Additionally, the Interface A data will be gathered at a higher frequency than traditional SECS/GEM data-gathering applications.

Within discussions of Interface A, "equipment" refers to the hardware and software combination provided by an equipment supplier. The equipment software is typically installed on the equipment's internal computer and fully integrated into the equipment's system. In some cases, the equipment software can be on an external computer. The latter is typical when equipment is retrofitted and does not have an integrated solution.

To achieve the highest data quality and production efficiency with Interface A, all data must be collected and time stamped as close to the source as possible, with minimal layers of hardware and software. To make all expected data available and achieve performance expectations, some equipment hardware and software will require internal restructuring and architectural changes.

E120 provides a general object model that represents an external view of the equipment. The model is composed of various classes organized in a logical hierarchy (Table 1 ). A fully implemented model summarizes all of the equipment's major hardware and software components.

SEMI's standard E120.1 XML Schema (a definition of the structure, content and semantics of XML documents) for the Common Equipment Model (CEM) maps the E120 standard into a specific XML implementation (Fig. 2 ).

2. SEMI’s standard E120.1, a general object model that represents an external view of the equipment, provides a definition of the structure, content and semantics of XML documents. The Common Equipment Model (CEM) maps the E120 standard into a specific XML implementation.

Equipment self-description

The E125 standard allows clients to request helpful descriptions about all information available for data gathering, including the parameters (i.e., specific data, units and types), events, exceptions, machine states, SEMI E39 object service data and physical configuration. All of the available information is mapped into the E120 CEM object hierarchy. SEMI standard E125.1, Provisional Specification for SOAP Binding for Equipment Self-Description (ESDS), maps the E125 standard into a specific SOAP/XML implementation. (Note: Space in this article precludes presentation of all graphics for each XML schema; these are available in the standard and from the author.)

E125 allows the end user to access information about what data can be monitored and the context (i.e., process chamber #1 or #2), without having to totally rely on the equipment's documentation. Interface A clients can implement plug-and-play methodology, automatically use new information immediately after an equipment's interface is revised and implement graceful error recovery if data is unavailable unexpectedly (Table 2 ).

Equipment client authentication and authorization

E132 defines two related security features for Interface A messaging — Equipment Client Authentication and Authorization (ECA). Client authentication, the presentation of credentials, determines how the client initially establishes a session to attain the ability to send authorized operations messages (Table 3 ). Client authorization verifies that the client has permission and manages what the client can access after the session is established. The equipment must provide a Security Admin, a utility that provides administrative configuration, which sets up the ECA after installation in the fab. SEMI standard E132.1, the Provisional Specification for SOAP Binding for Equipment Client Authentication and Authorization (ECA), maps the E132 standard into a specific SOAP/XML implementation.

For an Interface A client to establish a session where it may use E125 or E134 service requests, the client must provide credentials and be authenticated. The equipment also must be in the "Allowed Session Establishment" state. Credentials include client ID, an encrypted session key and an encrypted client ID proof-of-identity key. ECA rejects any attempts to use services requested before the authentication. Once the session is established, the client authorization becomes effective based on the client's credentials while establishing the session.

The Interface A server must be preconfigured to grant the client permission to establish a session. A wafer fab's Interface A client is typically developed by a third party with Interface A expertise. Equipment suppliers may also use a third party to develop Interface A clients, for example, to capture diagnostic information.

Authorization is configured using Access Control Lists (ACLs) — collections of details that grant or deny client sessions and impose restrictions on a client's access to a specific Interface A. The E132 standard uses the terms "principal" (a client defined in the ACL) and "privilege" (permission to use an operation or access specific data). In practice, the easiest way to set up an ACL is by defining what E132 calls "roles" and then assigning clients to one or more roles. For example, it might be convenient to define "operator," "technician" and "manufacturer" roles. Then, Interface A client applications can be assigned to these roles to give them access at the appropriate access level.

Each time a client sends a privileged E125 and E134 service request, the equipment must check the client's authorization. The ACL assigned to the client determines the set of available E125, E132 and E134 operations, the set of available metadata and the access level to data collection plans defined by other clients (metadata is information that describes data; for example, when an event occurs or a parameter's value requires interpretation).

The E134 standard defines several methods for Interface A clients to acquire the data described by E125 information. A client can request data ad-hoc where the requested set of data is returned immediately. Typically, however, the client will define Data Collection Plans (DCPs) to gather and configure the desired data. Once DCPs are activated, the equipment operates in a "fire-and-forget" mode (when a message sender does not expect a reply message), continuously collecting and packaging data in Data Collection Reports (DCRs) as it becomes available.

To optimize data transmission efficiency, DCRs can be optionally buffered at the equipment and transmitted periodically at the end of a specified interval. If the ACL allows, clients can activate a DCP defined by other clients. E134 also defines how to manage DCPs when either the equipment or client shuts down and restarts so data collection can persist.

SEMI Standard E134.1, Provisional Specification for SOAP Binding of Data Collection Management (DCM), maps the E134 standard into a specific SOAP/XML implementation. A DCP can include any number and combination of traces, events and exceptions to report when activated.

Traces provide a convenient mechanism for continuously or intermittently polling data. A trace definition includes a data-gathering frequency and a set of E125 data to collect. Optionally defined start and stop conditions determine when the data collection begins and ends. Otherwise, the trace data collection begins as soon as it is activated and ends when deactivated or the specified number of reports are gathered and sent.

An E125 state machine transition triggers an event. Events provide a convenient mechanism to receive notification when something important happens and optionally gather any desired data. In the DCP, the client chooses E125 parameters to include in the event's DCR. Each time the event occurs thereafter, a DCR is gathered and sent.

Exceptions notify the client when errors, warnings or alarms occur on the equipment. The exception report includes data, but the data is fixed by the equipment supplier in the equipment model. Clients cannot select the attached parameters as with events.

Traces, events and exceptions that are not listed in activated DCPs are not sent to any clients. The equipment supplier determines how much data is available, but the clients determine how much data is actually gathered and reported. Bandwidth requirements depend on the number of clients, the number of activated DCPs, the number of events, exceptions and traces in each DCR, the number of parameters defined for each event and trace, the frequency of activated events and exceptions, and the frequency of trace data collection.

Interface A bandwidth requirements are difficult to determine. Clients can potentially submit enough data collection requests to overload the equipment's computer and affect throughput. Therefore, E134 defines a performance status method to notify consumers of an overload condition and allow the equipment to take appropriate action, such as disabling certain DCPs or all data collection.

There are two types of clients — managers and consumers — although applications can fulfill both roles. Manager clients perform request-reply operations such as defining, activating, deactivating or deleting a DCP. The consumer clients receive the Data Collection Reports from the equipment. In a performance warning, the equipment detects a performance degradation. In DCP hibernation, notification is performed when one or more DCPs are put in the hibernation state as part of an equipment shutdown.

The combined effect of SEMI standards E120, E125, E132 and E134 produce the operational flow of an Interface A (Fig. 3 ).

3. The combined effect of SEMI standards E120, E125, E132 and E134 produces the operational flow of an Interface A.

Briefly described, each client must initially establish a secure, authenticated session. Next, the client can ask for the equipment-model metadata information to see what data is available through Interface A. With this information, clients can define and activate DCPs. The equipment will continue to generate DCRs until the client deactivates the plans or becomes unavailable. The client closes the session when done using Interface A.

Where do you go from here? Because Interface A is the direct link to EES applications such as APC, and these applications are crucial to maintaining the productivity edge of semiconductor manufacturing, it is vitally important that the suppliers and users of wafer fab equipment stay current with the continued evolution of SEMI standards E120, E125, E132 and E134, and the functional implementation of Interface A. There is no doubt that the specifications will continue to evolve as tools are equipped with Interface A ports and fabs implement more advanced EES applications in production; this dictates a proactive effort to stay current because most, if not all, fab tools in the near future will include Interface A.

In addition, while in-house knowledge — a dedicated team, if possible — of Interface A is greatly encouraged, the pace at which Interface A and EES applications are developing demands that timely success will only come to those who work closely with leading third-party software experts and providers, and frequently participate in SEMI standards meetings and industry forums.