In the fourth article of this series, Fault Detection and Classification, we highlighted the application that has been the principal driver for the adoption of EDA (Equipment Data Acquisition) standards across the industry thus far, namely Fault Detection and Classification (FDC). In this posting, we’ll discuss another important application that effectively leverages the capabilities of the EDA standard: Fleet Matching and Management. 

Problem Statement

The problem that fleet matching (which also covers chamber and tool matching) addresses is maintaining large sets of similar equipment types at the same operating point in order to maximize lot scheduling flexibility by the real-time scheduling and dispatching systems that run modern wafer fabs. This avoids the situation where specific equipment instances are dedicated to (and therefore reserved for) critical layers of certain products, processes or recipes, which can reduce the effective capacity of the affected process area. This situation can arise because tools naturally “drift” apart over time, especially when manual adjustments are made to the equipment, or other factors (maintenance actions, consumable material changes, key sub-system replacements, etc.) affect the equipment’s operating envelope. 

Of course, part of the problem is choosing which equipment should be the one matched to—the so-called “golden tool.” And depending on the breadth of the fab’s product/process mix, there may be multiple targets to choose from, further complicating the task. 

Solution Components

The solutions for many of today’s complex manufacturing problems require lots of high-quality equipment data, and fleet matching is no exception. Like FDC, choosing the golden tool(s) also requires some information about which recent lots exhibited the highest yields, which must be correlated with the equipment used throughout the process. Unlike FDC, however, it is NOT necessary to build hundreds (if not thousands) of multivariate fault models specific to the various context combinations, because the underlying principle of chamber/tool/fleet matching is that “if all the fundamental operating mechanisms of a set of equipment are working consistently, then the behavior of the equipment in aggregate should likewise be consistent.” This means that the matching process can be largely recipe independent, which is a major simplification over other statistically based applications.

This is not as simple as it may first appear, because a complex equipment may have scores of these mechanisms (pressure/flow control, multi-zone temperature control, motion control, power/phase generation, etc.) for which thousands of parameters must be collected to characterize and monitor equipment behavior accurately. Static and dynamic equipment configuration information also comes into play, since similar (but not identical) tools may be interchangeable for certain processes. 

This is where the EDA standards enter the picture.

EDA Standards Leverage

Although not explicitly required by the SEMI EDA standards, the intent and expectation of its designers was to support a far richer (read “more detailed”) equipment metadata model than is practical in most SECS/GEM implementations. With respect to fleet matching and management, this would include not just the high-level status variables for key equipment mechanisms (listed above), but also the setpoints, internal control parameters, and detailed status of their underlying components. 

The metadata model must also include the complete set of equipment constants that govern tool operation, since these “constants” are sometimes changed “on the fly” by an operator within some allowable range. While this may be an acceptable production practice, it nevertheless affects the tool’s operating window, and must be accounted for in the matching algorithms. 

Moreover, the communications interface should support sampling and data collection of these detailed parameters at a frequency sufficient to observe the complete real-time operation of these mechanisms so the process and equipment engineers can more deeply understand how the equipment actually works. Support for this level of equipment visibility was also a stated requirement for the EDA standards.

Once this data is collected, a variety of analysis tools can look for similarities and anomalies in the equipment parameters to identify the factors that matter most in achieving consistent process performance. At this writing, a number of companies are looking at this domain as an ideal application for Artificial Intelligence and Machine Learning technology. Stay tuned for exciting developments in this area. 

KPIs Affected

The KPI (Key Performance Indicators) most impacted by the fleet matching and management application is overall factory cycle time, since the scheduling systems can make optimal use of all available equipment to move material through the fab.

Equipment uptime is also improved, because the continuous equipment mechanism “fingerprinting” process which is fundamental to fleet matching also catches potential problems before they cause the entire tool to fail. Finally, when more equipment instances are available for running experimental lots (rather than having dedicated tools for this), the yield ramp for new processes can be shortened as well.

If keeping a large set of supposedly identical equipment operating consistently is a challenge you currently face, give us a call. We can help you understand the approaches for building a standards-based Smart Manufacturing data collection infrastructure to support the machine learning algorithms that are increasingly prevalent in this latest generation of manufacturing applications… including fleet matching and management. 

To Learn more about the EDA/Interface A Standard for automation requirements, download the EDA/Interface A white paper today.