Industry News, Trends and Technology, and Standards Updates

EDA Applications and Benefits for Smart Manufacturing Episode 6: Trace Data Analysis

Posted by Alan Weber: Vice President, New Product Innovations on Oct 25, 2018 11:20:00 AM

In this final article of the “EDA Application and Benefits” series we discuss an application that is one of the most basic and intuitive, but also provides the foundation for the many of the emerging capabilities in the machine learning and artificial intelligence (AI) domain—trace data analysis. Moreover, of all the applications we’ve introduced over the past 6 months, trace data analysis is the one that most directly leverages the capabilities of the SEMI Equipment Data Acquisition (EDA) standards

Problem Statement

When we ask fab process engineers and their supporting automation teams why they are now requiring the latest SEMI EDA/Interface A standards on their new equipment, the answer we hear most often is “To better understand equipment and process behavior.” And when asked why this cannot be achieved using the SECS/GEM interfaces, the answers are equally consistent: “The detailed information we need is either unavailable or cannot be collected at the frequencies we need to accurately see and characterize the behaviors we are interested in. And even if this were possible, we don’t have the operational freedom to change our data collection systems as quickly as our needs change, so we must have a more flexible approach.” 

What these engineers are looking for as a starting point is a way to easily specify a list of potentially related equipment parameters and collect their values at a rate that is fast enough to see how they are changing in relationship to one another. Human beings are wonderful at pattern recognition, and simply being able to juxtapose a set of signals on a “strip chart” display (see first figure below) can yield important insights into the underlying process. Of course, this capability is most useful when the engineer can precisely specify the timeframe of interest for this visual analysis. This is sometimes called data “framing” and can be accomplished by using equipment events to bracket the period of interest (see second figure below).

eda_apps_benefits6.1-1-1

EDA_apps_Benefits6.2-1

While humans may be good at pattern recognition, they quickly get overwhelmed when the number of parameters to view grows and/or the timespan to consider expands… which is where trace data analysis software enters the picture.

Solution Components

In addition to very flexible time-series data visualization tools, trace data analysis software packages must be able to “slice and dice” subsets of large data sets to compare every imaginable combination of equipment instance, process chamber, product, layer, recipe, fixture, consumable batch, shift, operator, … (you get the picture) to look for correlations between important factory metrics and the behavior of the equipment involved. Moreover, they must be able to identify and flag “abnormal” (which must be flexibly defined) situations for further analysis, since these may hold clues about incipient failures that traditional multivariate FDC (fault detection and classification) applications may not catch.

In fact, there is an emerging school of thought for fault detection that states “most of the time, the equipment is making good wafers, so unless there’s something very different about the tool behavior between the most recent lots and the current lot (as determined through trace data analysis), it’s very likely that the current lot is good as well.” This simplified approach has also been called “model-less FDC” because it mostly compares trace data signals rather than passing tool parameters into highly context-specific multivariate statistics-based models.

Of course, any trace data analysis application is only as good as the data that feeds it… which is where the EDA standards and the related equipment purchase specifications come into the picture.

EDA (Equipment Data Acquisition) Standards Leverage

Previous postings such as Episode 4 on Fault Detection and Classification and Precision Data Framing during Process Execution – Tricks of the Trade have highlighted the capabilities of the Freeze II EDA standards related to Data Collection Plans (DCPs) and the Trace Requests, Event Requests, and Exception Requests that comprise them. We have also highlighted the need for broad stakeholder involvement when creating the EDA section of an equipment purchase specification and described the process we’ve crafted to accomplish this.

However, to fully support a world-class trace data analysis application, it’s important to understand what to ask of the equipment suppliers. To this end, we’ve excerpted some key sample requirements from a typical purchase specification below.

  • Equipment Model Content (SEMI E120, E125, E164)

    • The hierarchical depth of the metadata model should include at least the “field replaceable unit” (FRU) level, and one of two levels below this for complex sub-systems.
    • The metadata model must contain command and status information for all equipment components that affect material movement. This includes not only material transfer elements such as robot arms, but also devices that may inhibit/enable material movement, such as gate valves, interlocks, etc.
    • The metadata model must include control parameters for all significant operating mechanisms and subsystems in the equipment. The control parameters may include but are not limited to: process variable setpoints and status values; control variable status values; PID tuning parameters, control limits, and calibration constants.
    • The metadata model must include whatever additional usage counters, timers, and other parameters that may be useful in time-based, usage-based, and condition-based maintenance scheduling algorithms.
    • The metadata model must contain parameters the describe consumption rates and levels for key process resources such as electricity, process gases, and other consumables. These are used in some of the FDC models to detect potentially abnormal process conditions.
    • Suppliers must provide a written description of the update rates, recommended sampling intervals, normal operating ranges and behaviors, and high/low/rate-of-change limits for all key process parameters.
    • Etc.

  • Data Collection Capability (SEMI E134)

    • Equipment must include built-in DCPs to support common equipment performance monitoring, diagnostic, and maintenance processes that are well known to the supplier. Documentation for these DCPs must define their purpose, activation conditions, interface bandwidth consumed, and the types of analysis the collected data enables.
    • Equipment parameters provided through the EDA interface must exhibit a number of data quality characteristics, including, but not limited to: an internal sampling/update rate sufficient to represent the underlying signal accurately; timing of trace reports that is consistent with the sampling interval within +/- 1.0%; values in adjacent trace reports must contain then-current values at the specified sampling interval; and rejection of obvious outliers.

  • Performance Requirements

    • Performance requirements will be expressed as combinations of sampling interval, # parameters per DCP, # of simultaneously active DCPs, group size, buffering interval, response time for ad hoc “one-shot” DCPs, maximum latency of event generation after the related equipment condition occurred, consistency of timestamps in trace reports with the specified sampling interval, and perhaps others.
    • Example: The EDA interface must be capable of reporting at least 5000 parameters at a sampling interval of 0.1 seconds (10Hz) with a Group Size of 1, for a total data collection capacity (bandwidth) of 50,000 parameters per second. It must also support simultaneous data collection from at least 5 clients while still achieving a total bandwidth of 50,000 parameters per second; Group Sizes greater than 1 may be used to achieve this level of performance.
    • Some equipment types may have more stringent performance requirements than others, depending on the criticality of timely and high-density data for the consuming applications.

apc2017_5KPIs Affected

Trace data analysis will undoubtedly take its place among the other “mission-critical” applications in today’s fabs because of the increasing process complexity and the need to maintain the traditional “time to yield” production ramp. This is especially true for the industry pioneers now using the latest EUV scanners, as there will be much to learn about this new technology in the coming years.

Let Us Hear from You!

EDA_apps_benefits_6

If you want to understand how the latest EDA standards and trace data analysis can support your future manufacturing objectives, or how to make this a reality in your Smart Manufacturing roadmap, please schedule a meeting!

Schedule a Meeting

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

EDA Applications and Benefits for Smart Manufacturing Episode 5: Fleet Matching and Management

Posted by Alan Weber: Vice President, New Product Innovations on Sep 5, 2018 10:30:00 AM

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. eda5.1

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.EDA5.2-667640-edited 

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.Accelerate gains, reduce costs

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. Smart Factory

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

Download

 

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

EDA Applications and Benefits for Smart Manufacturing Episode 4: Precision Fault Detection and Classification (FDC)

Posted by Alan Weber: Vice President, New Product Innovations on May 2, 2018 10:24:00 AM

In the third article of this EDA Applications and Benefits in Smart Manufacturing series, we highlighted the first of a series of manufacturing applications that leverage the capabilities of the EDA / Interface A suite of standards in leading semiconductor manufacturers. In this fourth article, we’ll highlight the application that has been the principal driver for the adoption of EDA across the industry thus far, namely Fault Detection and Classification (FDC).

Problem Statement

The problem that FDC addresses is the prevention of scrap that may result from processing material by an equipment that has drifted out of its acceptable operating window for whatever reason. The prevalent technique used by today’s leading FDC systems is to develop “reduced dimension” statistical fault models for the various production operating points based on training sets of “good” and “bad” runs. These models are then evaluated in real time with key parameters (usually trace data) collected from the equipment during processing to detect process deviation and predict impending tool failure. In the most advanced fabs, the FDC software is deeply integrated with the systems that manage process flow, and can even interdict equipment operation in mid-run to prevent/reduce scrap production. 

Of course, the challenge with this type of algorithm is developing models that are “tight” enough to catch all sources of potential faults (i.e., eliminating false negatives) while leaving enough wiggle room to minimize the number of false positives (also known as false alarms, or crying “Wolf!”). This in turn requires high quality data from the equipment, and lots of process engineering and statistical analysis expertise to develop and update the fault models for the range of production cases that must be handled. High-mix foundry environments exacerbate this situation.

Solution Components

The core of modern FDC systems is a robust multivariate statistics analysis toolbox, capable of handling large amounts of time series data. By “large,” we mean both the number of distinct equipment parameters and the number of samples for each parameter. These software tools collapse potentially hundreds of parameters into a small set of “principal components” that can be calculated on-the-fly using a limited set (say, 20-30) of equipment parameters. Some number of these principal components in aggregate represent the actual state of the process accurately enough to detect deviations from the norm, and since they can be realistically calculated in real time, the application serves as an on-line equipment health monitor.

EDAApplications4.3The other major solution component for a production FDC system is a fault model library management capability that can handle large numbers of models. This is necessary because the multivariate approach includes little or no awareness of the physical meaning of the principal components (i.e., they are not “first principles” based), so different operating points for the equipment must have their own sets of fault models. The proper models for a given operating point are selected by matching the values of the “context parameters” for a specific run to those used to store the models. Even if some models can be shared across a range of operating points, the number of distinct models for a foundry megafab will still number in the thousands.

EDA (Equipment Data Acquisition) Standards Leverage

In an advanced fab, there is a spectrum of data collection alternative available for a given application, from basic lot-level summary information to detailed real-time data that can used at the substrate level or even on a die/site basis. For FDC, this spectrum of possibilities is shown in the table below.

SEMI Standard Level

Functionality

Benefit

GEM/GEM300

Fault models difficult to change after initial development if data collection requirements change

Baseline

EDA Freeze I

(1105)

Easy to change equipment data collection plans as fault models evolve and require new data;

Model development environment can be separate from production system

Engineering labor reduction; improved fault models and lower false alarm rate

EDA Freeze II

(0710)

Use conditional triggers to precisely “frame” trace data while reducing overall data collection needs; Incorporate sub-fab component/subsystem data into fault models

Even better fault models; reduced MTTD (mean time to detect) of fault or process excursion; little or no data post-processing required

EDA Common Metadata (E164)

Include standard recipe step-level transition events for highly targeted trace data collection;

Automate initial equipment characterization process by using metadata model to generate required data collection plans

Faster tool characterization and fault model development time

Factory-Specific
EDA Requirements

Incorporate previously unavailable equipment signals in fault models;

Update data collection plans and fault models automatically after process and recipe changes;

Include recipe setpoints in the equipment metadata models

TBD (Not yet applicable)

 

The left column refers to the level of SEMI standards used to provide the necessary equipment data. The “Functionality” column describes how that data is used in an FDC context, and the “Benefit” column highlights the potential impact these functions can have. 

Let’s say that a fab implemented the capability described on rows 3 and 4 of the table (EDA Freeze II (0710) and E164-compliant EDA Common Metadata). In this case, the process equipment will be able to provide detailed process parameters at recipe step-specific sampling rates sufficient to evaluate “feature extraction” algorithms of even the most demanding FDC models…with context data to select the precise set of models for a given process condition. And even though the specific equipment parameters are necessarily process dependent, much of the software that monitors recipe execution events, generates the data collection plans (DCPs) that provide the trace data, and assembles the context data used by the model management library can be truly generic because of the fab-wide consistency of the equipment interfaces dictated by the E164 standards.

EDApplications4.1

Another aspect of the EDA standards that FDC teams can leverage is the system architecture flexibility enabled by the multi-client capability. Even while a piece of equipment is connected to a production data management infrastructure, the process engineers and statisticians who develop and refine the fault models can use an independent data collection system tailored for process behavior analysis, experimentation, and continuous improvement. When the new fault models are ready for production, the production DCPs can be updated with these new requirements.

KPIs Affected

Accelerate gains, reduce costs

FDC is considered a “mission-critical” application in today’s fabs because of the high cost of unscheduled equipment downtime and the importance of maintaining high product yield. Simply stated, “if FDC is down, the tool is down,” which means that the real-time data collection infrastructure supporting this application is likewise mission critical. As such, improvements in FDC performance can have a major impact on fab performance.

Specifically, FDC directly affects the process yield and scrap rate KPIs through higher fault detection sensitivity, and it affects equipment availability and related KPIs by reducing the number of false alarms that often require equipment to be taken out of production.

So what?

A wise colleague advised me early in my career to always have an answer for this question at the end of every presentation, article, or conversation. To answer this question in financial terms for this posting, let’s consider the cost of FDC false alarms for a production 300mm fab.

Assuming that 

  • an hour of tool time is worth US$2200, a qual wafer costs $250, and an hour of engineering/technician time costs $150, and 
  • it takes 5 hours of tool time, 2 hours of engineering time, and 6 qual wafers to resolve a false alarm, then 

each false alarm costs the company almost $12K. For a fab with 2000 pieces of equipment and an average false alarm rate of 2 per tool per year, that comes to an annual cost of almost $50M! A 50% reduction in the false alarm rate (which is not unreasonable) nets $25M of savings per year. 

Red_smart_factory

If this sounds like “real money” to you, give us a call. We can help you understand how to get on the Smart Manufacturing path with the kind of standards-based data collection infrastructure that is needed to support the latest generation of FDC systems and beyond.

 

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

Download

 

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

EDA Applications and Benefits for Smart Manufacturing Episode 3: Real-Time Throughput Monitoring

Posted by Alan Weber: Vice President, New Product Innovations on Mar 28, 2018 11:13:00 AM

In the introduction to this series (posted December 19, 2017), we listed some of the manufacturing stakeholders whose work objectives are directly addressed by the applications we’ll highlight in this and subsequent postings. In the second article, we explained the process used to map the careabouts of key stakeholder groups into specific EDA interface requirements which are can then be directly included in the purchasing specifications. semiconductor wafer

In this post, we’ll explain how some of those interface requirements support an important factory application that has general applicability across all equipment types, namely “real-time throughput monitoring.” This application can realistically work with a variety of equipment types with no custom code or configuration depending, of course, on how faithfully the equipment supplier implements the SEMI standards referenced in the requirements specification. This powerful concept greatly improves the software engineering productivity of a fab’s automation team, so we’ll take some time to explain how this is possible.

Problem Statement

This application addresses the problem of monitoring equipment throughput performance in real time, and raising an alarm when it drifts away from “normal” for any reason. This is especially important for bottleneck equipment (e.g., litho tracks and scanners), because any loss of throughput ripples throughout the line, resulting in lost production and its associated revenue and profit. Stated simply, “lost time on a bottleneck tool can never be recovered.” 

Solution Components

This application requires data that includes primarily the equipment events that chronicle the movement of substrates through the equipment and execution of the recipes appropriate for this equipment type (process, metrology, inspection, sorting, etc.). With this information, the application calculates the process time “on the fly” and compares the current value with the expected (“normal”) value. 

Models_4.pngSmart_Mfg_EDAappsandbenefits_ep3.3.png

This is not as simple as it first may seem, because the expected value will likely depend on the product type, process type, material status, layer, recipe, and several other factors. Taken together, the set of factors that determines “equivalence” of different lots for some processing purpose is called “context.” For this application, the context parameters ensure that you are comparing apples and apples when looking for variations in process time.

EDA (Equipment Data Acquisition) Standards Leverage

By “EDA,” we include not only the standards in the Freeze II / 0710 suite, but also SEMI E164 (EDA Common Metadata), E157 (Module Process Tracking), and by reference, the entire GEM 300 suite. This ensures not only the granularity and breadth of event support necessary to precisely track wafer movement and step-level recipe execution, but also specifies the naming conventions of those events and their associated parameters, regardless of equipment type or vendor.

If the equipment automation purchase specifications include clauses that state “we require that all state machines, states, state transition events, and attributes of the objects defined in the referenced 300mm SEMI standards be implemented and named exactly as specified in the standards,” then all the information you should need to write a truly generic throughput monitoring application will be available on demand.

A robust real-time throughput monitoring algorithm can be implemented with information solely from the following SEMI standards: E90 (Substrate Tracking), E157 (Module Process Tracking), E40 / E94 (Processing / Control Job Management), and E87 (Carrier Management). The Harel state diagrams, events of interest, and EDA metadata model representation* for a couple of these (E90 and E157) are shown in the figures below.

Models_1.png

Models_3.png

Note that as little or as much of the parameter information required to be available for each event (the rightmost picture in each figure) can be collected via the EDA construct of a “Data Collection Plan” (DCP) with one or more “Event Requests.” For more information about these capabilities, consult the SEMI E134 (Data Collection Management) specifications directly, or review some of the extensive educational material available on our web site.

The other point of leverage for the EDA standards is the multi-client capability. This contributes to the productivity and responsiveness of your automation software team members by allowing them to collect and process the data for this application independently from any other application. Specifically, the throughput monitoring functions can be implemented separately from whatever systems host the GEM command and control capabilities, which are usually managed very carefully because of their potentially negative impact on fab operations.

Key ROI Factors

accelerate gains, reduce costsAs we said in the initial post of this series, this application is not just something you could build and deploy with EDA-enabled equipment… in fact, this has already been done, and is delivering real production manufacturing benefit! Specifically, the ROI factors impacted (and benefit delivered) by this application include productivity excursion mean-time-to-detect (MTTD, 50% reduction), selected equipment throughput improvement (3-5%), and overall cycle time reduction (difficult to quantify precisely because of the staged implementation process). 

Of course, these results will vary depending on the manufacturer’s fab loading, operations strategy, and overall automation capabilities, but are representative for leading edge production wafer fabs running at near capacity. However, since these are very common ROI factors, most companies can easily quantify these improvements in real financial terms.

In Closing...

As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.

EDA_apps_benefits_6.png

*The visualizations of equipment metadata model fragments are those produced by the Cimetrix ECCE Plus product (Equipment Client Connection Emulator).

Let us know if you would like to schedule a meeting to learn more:

Schedule a Meeting

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

EDA Applications and Benefits for Smart Manufacturing Episode 2: The Stakeholder-Driven Requirements Development Process

Posted by Alan Weber: Vice President, New Product Innovations on Feb 7, 2018 11:19:00 AM

In the introduction to this series posted December 19, 2017, we listed some of the manufacturing stakeholders whose work objectives are directly addressed by the applications we’ll highlight in subsequent postings. Before getting into the specific capabilities and benefits of these applications, however, it seemed appropriate and timely to share a little bit about the process that the leading EDA practitioners use to ensure the equipment they are purchasing will support these applications. “Appropriate” because you may need to review and update your own purchasing specifications to clearly convey your requirements in the areas that are not directly covered by the standards (like model content, performance, and stability); “timely” because we at Cimetrix have recently conducted a number of customer workshops and seminars in which this process was effectively used and refined.

EDA_apps_benefits_1.png

In particular, this article explains how the careabouts of key stakeholder groups are “translated” into specific EDA interface requirements which can then be directly included in the purchasing specifications. As more semiconductor manufacturing companies take this approach, effectively “raising the bar” for the entire industry, the collective capability of our equipment suppliers will increase in response, to everyone’s benefit.  

In the previous post, we suggested that manufacturing stakeholders, KPIs, applications, and equipment data are all interrelated. Since the ultimate beneficiaries in this value chain are the stakeholders themselves, the challenge then becomes how to capture their requirements effectively… because these are busy people whose time is precious. Through a number of interviews with leading manufacturers over the past 18 months, we discovered that the best way to accomplish this is through a focused, interactive questionnaire process. By asking very specific questions about people’s daily tasks, problem areas, expectations, success criteria, and other items of constant concern, we can take a generic EDA purchase specification outline and generate a complete, factory-specific set of EDA purchase specifications in a matter of days. This is time well-spent when you consider the value and volume of equipment potentially affected… and the opportunity cost of not having these requirements clearly expressed. 

The stakeholder answers to the questionnaire serve a broader purpose as well, because in addition to driving the content of the equipment purchase specifications, they also form the basis for a lot of manufacturing technology development within the factory. This overall process is shown in the figure below; documents and related artifacts are shown in red; the affected organizations (of which there are many!) are shown in blue. 

EDA_apps_benefits_2.png

A blog posting can only hope cover a fraction of this overall process, but the sample questions below should give you an idea of how it works.

Sample questions for the Manufacturing Automation and Technology Development stakeholders include:

  • Are you familiar with SEMI E157 (Module Process Tracking)? Is it implemented on any of your current tools, and if so, do you monitor those events?
  • EDA_apps_benefits_3.pngDo you require that all state machines, states, state transition events, and attributes of the objects defined in the referenced 300mm SEMI Standards be implemented? If not, why not?
  • Do you currently use information from sub-fab systems in any of your on-line production applications, like FDC, PHM, R2R control, or others? If so, what range of equipment is supported, and how (pumps, chillers, abatement systems …)?
  • How do you express performance expectations for process variable reporting, such as sampling frequency, # parameters per chamber, report sizes, total bandwidth of all data reported, maximum latency of event generation, etc.? 

Sample questions for Production Operations and Engineering Support people include:

  • How do you schedule carrier pick-up and delivery from/to equipment, respectively? Is this done using algorithms in the AMHS/MCS/OHT system components, or do you get real-time updates from the equipment about pending lot completion and tool availability?EDA_apps_benefits_4.jpg
  • Do you need to have remote access capability for checking basic tool status outside the fab?
  • Do you require your suppliers to provide built-in data collection schemes (pre-defined reports, macros, etc.) to support common monitoring, maintenance, or diagnostic processes?
  • Do you have a list of parameters/events that must be collectable to support your production application portfolio?
  • Do you monitor any of the low-level actuator/sensor signals in the various mechanisms that make up a manufacturing tool?

Sample questions for the Procurement and Supplier Relations organizations include:

  • What compliance tests/reports do you require of the equipment suppliers before they ship equipment to your factories? Do you ever/sometimes/always visit the supplier's site to observe this process? What about after delivery?EDA_apps_benefits_5.png
  • Do you have a standard supplier response sheet or checklist for your automation requirements? If so, are you satisfied with its clarity, completeness, and ease of use for evaluating responses?
  • At what point in the equipment purchasing cycle do you review the capabilities of the interface software (event/parameter lists, model structure/content, projected performance, etc.)? When are these capabilities validated?
  • Do you assign a monetary value (say, some % of the equipment purchase price) to the interface software? 

If the above discussion triggers the question “I wonder if our EDA purchase specs are sufficient to address the manufacturing challenges we’ll face in the next few years?” give us a call. We’ll be happy to talk about how to support your stakeholders and automation team with an effective on-site workshop to address this question once and for all… It could be the most important next step you take in formulating you own company’s EDA implementation roadmap. 

EDA_apps_benefits_6.png

As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.

Click below to learn more about EDA:

EDA/Interface A

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

EDA Applications and Benefits for Smart Manufacturing: Introduction to a New Series

Posted by Alan Weber: Vice President, New Product Innovations on Dec 19, 2017 11:40:00 AM
With the adoption of the latest SEMI EDA (Equipment Data Acquisition, also known as Interface A) standards accelerating significantly over the past 18 months, it is time to highlight the applications across the industry that make the best use of these standards, and the specific manufacturing benefits that result.

The articles in this series are not simply suggestions of what one could do by leveraging the performance, flexibility, and architectural features of these standards. Rather, they are leading edge application-specific mini-case studies derived from actual production experience, and as such, can provide genuine guidance for those companies just now contemplating potential pilot projects or even factory-wide deployments of the EDA standards.
Another important aspect of this series is that the applications described affect a broad range of stakeholders in a semiconductor manufacturing company. These include, of course, the process control engineers and statistical modeling support staff responsible for the Fault Detection and Classification (FDC) implementation strategy in all modern wafer fabs, since this application has consistently been the initial consumer of the high-density, precisely framed equipment/process data and associated context information provided through the EDA interfaces.

However, other direct beneficiaries of EDA-enabled applications extend well beyond this group, and include:
  • Industrial engineers responsible for monitoring equipment and factory throughput in real-time, identifying opportunities to eliminate wait time waste in individual equipment types as well as the overall factory, and addressing bottlenecks as they shift and emerge;
  • Production control staff responsible for determining the material release schedule and managing the factory scheduling/dispatching systems to accommodate changes in customer orders and/or factory status;
  • Equipment engineers responsible for fleet matching and management to minimize or eliminate the need to dedicate certain equipment sets for critical process steps and thereby simplify the overall factory scheduling process;
  • Maintenance engineers responsible for minimizing equipment downtime, MTTR (mean time to repair), and test wafer usage required to bring equipment back to production-ready state;
  • Facilities engineers responsible for collecting and integrating sub-fab data from pumps, chillers, exhaust systems, and other complex subsystems into the production data management infrastructure for use by a growing range of analysis applications;
  • Sensor integration specialists responsible for supplementing the built-in sensing and control capabilities of critical process and measurement equipment to support advanced process development…

… and the list goes on.EDAApplications_1.1.png

Despite their diversity, these application articles all share a common profile, which includes a statement of the manufacturing problem addressed; a description of the major solution components required; a discussion of how the solution leverages specific, unique characteristics of the EDA standards; and finally, identification of the key ROI (return on investment) factors that are impacted by the solution. In addition, where available, example ROI calculations will be provided so that the readers can adapt them to their own company environments to quantify the potential benefit of implementing a comparable application solution.

From the above description, you may be tempted to assume that the series focuses mostly on the careabouts of semiconductor manufacturing companies (IDMs and foundries)… but this is not the case. Since the performance of the highlighted applications depends heavily on the “quality” (for lack of a better term) of the equipment interfaces supplying the data, the equipment suppliers have a major role to play in achieving the promised benefit. Specifically, the metadata models (specified by SEMI E120, E125, and E164) that define the parameters, states, events, exceptions, and other data available from the equipment and structure this information for external access essentially form the data collection “contract” between the equipment suppliers and their factory customers. For this reason, the detailed requirements for this aspect of the EDA implementation must be carefully specified and negotiated. This will not happen overnight, as the implications for future equipment design are significant.

As a number of industry experts have already expressed, it is an exciting time to be in the semiconductor industry, regardless of your position along the value chain. For those involved in the collection and use of equipment data to optimize factory performance, we hope you will find the coming series of articles especially useful in formulating you own company’s EDA implementation roadmap.

Red_smart_factory.png

To view additional resources on EDA/Interface A or other topics, click on the resources link below.

Resources

As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series