Industry News, Trends and Technology, and Standards Updates

The 31^st annual APC Conference is coming up later this month (October 28-31), and will be held at the Embassy Suites Riverwalk in the scenic and historic setting of San Antonio, Texas.

This conference is one of the longest-running events specific to the semiconductor manufacturing industry, and always features speakers and topics that are germane to the industry’s leading practitioners of equipment/factory data collection, analysis, optimization, and control.  This year’s agenda promises more of the same – click here for a closer look at the details.

Specifically, as the automotive industry’s use of semiconductors continues to grow in anticipation of self-driving cars and their supporting infrastructure, the first keynote address from Steve Frezon of NXP Semiconductors (“Automotive Semiconductor ZERO DEFECT Enablement”) highlights the challenges that automotive customers place on the wafer fabs. A second keynote by Dr. Ben Rathsack of Tokyo Electron America (“SMART Tools: Intelligent Controls in Semiconductor Manufacturing”) focuses on the implications of the global Smart Manufacturing initiative for equipment suppliers, which has been a consistent theme of the conference under a variety of monikers since its earliest days.

The rest of the Technical Sessions Agenda includes presentations, posters, and exhibits across the semiconductor value chain: sensor and subsystem providers, software suppliers, equipment manufacturers, universities, standards organizations, and semiconductor IDMs and foundries. Given the importance of equipment connectivity and control across the product and technology spectrum of these companies, Cimetrix will participate directly as it has for many years. Alan Weber, VP of New Product Innovations, will present a summary of a chapter (“Semiconductor Smart Manufacturing: An Evolving Nexus of Business Drivers, Technologies, and Standards”) in a soon-to-be-published 2-volume book on Smart Manufacturing. He will also present material jointly developed 1) with SK hynix on customer-driven automation requirements development, and 2) with SEMI Japan, Applied Materials, and others on new standards for flow shop style manufacturing, such as semiconductor back end and PCB assembly.

Central Texas can be a beautiful place to be in late October, so mark your calendars today and plan to join us in San Antonio!

The old adage “You get what you pay for” doesn’t fully apply to equipment automation interfaces… more accurately, you get what you require, and then what you pay for!

This is especially true when considering the range of capability that may be provided with an equipment supplier’s implementation of the EDA (Equipment Data Acquisition, also known as Interface A) standards. Not only is it possible to be fully compliant with the standard while delivering an equipment metadata model that contains very little useful information, the standards themselves are also silent on the topics of Performance and Data Quality.  So you must take extra care to state these requirements and expectations in your purchase specifications if you expect the resulting interface to support the demands of your factory’s data analysis and control applications. Moreover, to the extent these requirements can be tested, you should describe the test methods and tools that you will use in the acceptance process to minimize the chance of ugly surprises when the equipment is delivered.

We have covered the importance of and process for creating robust purchase specifications in a previous posting. This post will focus specifically on aspects of Performance and Data Quality within that context.

Scope of Performance and Data Quality Requirements

From a scope standpoint, Performance and Data Quality requirements are found in a number of sections in an automation specification. The list below is just a starting point suitable for any advanced wafer fab – your needs may extend and exceed these significantly.

Here are some sample requirements that pertain to the computing platform for the EDA interface software:

• The interface computer should have the capability of a 4-core Intel i5 or i7 or better, with processing speed of 2+ GHz, 8 GB of RAM, and 500 GB of persistent storage with at least 50% available at all times.
• The equipment must monitor key performance parameters of the EDA computing platform such as CPU utilization (%), memory utilization (GB, %), disk utilization (GB, %) and access rate, etc. using system utilities such as Perfmon (for Windows systems) and store this history either in a log file or in some part of the equipment metadata model.
• The network interface card must support 1 GB per second (or faster) communications.

In the area of equipment model content, the following requirements are directly related to interface performance and data quality:

• The equipment should make the EDA computing platform performance parameters available as parameters of an E120 logical element that represents the EDA interface software itself.
• The supplier 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. These will be used to design data quality filters in the data path between the equipment and the consuming applications/users.
• 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.

Advanced users of the EDA standards are now raising their expectations for the equipment to provide self-monitoring and diagnosis capability in the form of built-in data collection plans (DCPs), as expressed in some of the following requirements:

• The supplier must provide 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.
• The supplier must describe the operating conditions that can lead to a PerformanceWarning situation for the EDA interface.
• The supplier must describe the algorithms used to deactivate DCPs under PerformanceWarning conditions. These might include LIFO (i.e., the last DCP activated is the first to be deactivated), decreasing order of bandwidth consumed or “size” (in terms of total # of parameters and # of trace/event requests), etc.

Because of the power and complexity of the DCP structure defined in the EDA standards, it is not sufficient to specify the raw communications performance requirement as a small number of isolated criteria, such as total bandwidth (in parameters per second) or minimum sampling interval. Rather, since the EDA interface must support a variety of data collection client demands for a wide range of production equipment, these requirements should 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.

Moreover, some equipment types may have more stringent performance requirements than others, depending on the criticality of timely data for the consuming applications… so there may be process-specific performance requirements as well.

Measurement and Testing

Methods for measuring and testing the above requirements should also be described in the purchase specifications so the equipment suppliers can know they are being successfully addressed during the development process and can demonstrate compliance before and after shipping the equipment. Clarity at this phase saves time and expense later on.

Examples of such requirements include:

• The supplier must test the EDA interface across the full range of performance criteria specified above and provide reports documenting the results.
• An earlier requirement states that the EDA interface must be capable of reporting at least 2000 parameters at a sampling interval of 0.1 seconds (10Hz) with a group size of 1, for a total data collection capacity (bandwidth) of 20,000 parameters per second. In addition to this overall bandwidth capability, the supplier must demonstrate that this performance is possible over a range of specific data collection deployment strategies, meaning different #s and sizes of DCPs, different sampling intervals, group sizes, etc. without causing the EDA interface to reach one of its “Performance Warning” states or overstress its computing platform. To this end, all combinations of the following data collection configuration settings must be run for at least 15 seconds each; assuming the equipment has n processing modules:
  • Trace intervals (in seconds): 1, 0.5, 0.2, 0.1 (and 0.05 if possible)
  • # of parameters per DCP: 10, 50, 100, 250, 500, 1000 (and 2000 if possible)
  • # of DCPs: 1, 2, 3, … to n
  • Group size: 10, 5, 2, 1
• The test client should be run on a separate computing platform with sufficient computing power to “stay ahead” of the EDA interface computer; in other words, the EDA interface should never have to wait on the client system.
• Test reports should indicate the start and stop time of each iteration (i.e., one combination of the above settings), and verify that the timestamps of the data collection reports sent by the EDA interface are within +/- 1% of the value expected if the samples were collected exactly at the specified trace interval.

Performance parameters of the EDA interface platform should also be monitored during the tests and included in the report. These parameters should include memory usage, CPU processing load, and disk access rate (and perhaps others) for all processes that constitute the EDA interface software.

This approach is shown in tabular form for a 2-chamber tool (see below); since Group Size does not (or should not) impact the effective parameters per second rate, it is not shown in the table.

• A summary report for all performance tests that show acceptable message generation and transmission timing across the full range of data collection test criteria must be available.
• Detailed SOAP logs for specific performance tests must be available on request.

In Conclusion

We hope you now have some appreciation for the importance of solid requirements in this area, and can accurately assess how well your current purchase specifications express your actual needs. If you want to know more about a well-defined process for improving your specifications, or have any other questions regarding the status and outlook of the EDA standards, and how they can be implemented, please contact us.

Cimetrix attended the recent JISSO PROTEC exhibition (June 5-7, 2019) at the Tokyo Big Sight International Exhibition Center to see the latest developments in SMT (Surface Mount Technology) manufacturing… and witnessed a truly compelling demonstration of the new SEMI Flow Manufacturing communications standards in action.

The new suite of standards is named SMT-ELS (Surface Mount Technology-Equipment Link Standards), and includes SEMI A1/1.1 as a lower-level messaging standard with SEMI A2 SMASH (Surface Mount Assembler Smart Hookup) defining the content of the messages required to configure an SMT manufacturing line and automate the material and information transfer among all equipment in that line. This is depicted in the figure below.

The demonstration itself included placement equipment from 4 large equipment suppliers—Fuji, JUKI, Panasonic, and Yamaha—as well as load/unload stations and a bar code reader at the beginning of the line (see picture below). Each of these companies had implemented the “horizontal” (machine-to-machine) communications according to the SMT-ELS standards. The demonstration consisted of an operator scanning one of the stack of input boards with the barcode reader, placing it on the loader conveyor, and then watching as each piece of equipment automatically adjusted its internal conveyor to accept the board, run through its part placement recipe, and pass the board to the next equipment in the line, finally arriving at the unload station conveyor after a minute or so.

Cimetrix participated in the recent European Advanced Process Control and Manufacturing (apc|m) Conference, along with over 150 control professionals across the European and global semiconductor manufacturing industry. This site of this year’s conference was Villach, Austria, a picturesque town nestled in the eastern Alps just north of the Italian border in the state of Carinthia. This region is home to a number of high-tech companies and institutions all along the semiconductor manufacturing value chain, and since it was the first time the conference was held in Villach, the local hosts rolled out the red carpet. 

This conference, now in its 19th year and organized by Silicon Saxony, is one of only a few global events dedicated to the domain of semiconductor process control and directly supporting technologies. As usual, the conference was very well organized, and featured a wide range of high-quality presentations, keynote addresses, and tutorial sessions. The supplier exhibits associated with this year’s event were especially numerous, as were the technical posters displayed in the exhibition area just outside the conference rooms.

As in many prior years, Cimetrix was privileged to present at this conference, as Alan Weber delivered a talk entitled “Addressing Connectivity Challenges of Disparate Data Sources in Smart Manufacturing.” The presentation highlighted the need for unifying data collection concepts—like explicit equipment models and generic structures for data collection plans—are increasing necessary for maintaining the fidelity of a factory’s “digital twin” in Smart Manufacturing settings where the number of data source types is growing. This presentation resonated with a number of the key conference themes, so if you want to know more, feel free to download a copy of the entire presentation from our web site.

Other highlights of the conference included:

• An update by Otto Graf on the ambitious vision and progress of the BOSCH 300mm wafer fab now under construction in Dresden. In this talk he emphasized the role that digital technologies will play in bringing up the fab and climbing the yield ramp and other features of a wall-to-wall Industrie 4.0 implementation. 
• “The Role of APC and Smart Manufacturing / Industrie 4.0 in New Reliability-Critical Markets“ by James Moyne (University of Michigan / Applied Materials) – James re-presented a number of the Smart Manufacturing technologies in the context of automotive industry requirements, especially the role that Subject Matter Expertise (i.e., people!) will play alongside other emerging technologies. He also pointed out that the Factory Integration chapter of the International Roadmap for Devices and Systems (IRDS) will be reorganized around the key tenets of Smart Manufacturing.
  
  
• A thought-provoking invited talk from Dr. Roman Kern of the KNOW-CENTER titled “Possibilities and Challenges of Digitalization in the Semiconductor and Other Domains.” His key messages started with “Big Data is the new oil…. AI is the new electricity… and Data Science is the new lingua franca for leading global industries,” and then he went deeper into all of these.
  
  
• Dr. Germar Schneider of Infineon Technologies built on the theme above in a practical setting with his “Chances and Challenges of Digitization in Semiconductor Fabs and Success Factors during the implementation” presentation. This was not only an in-depth look at some of the multi-year efforts at Infineon, but also included a summary of current digitization projects across the European manufacturing R&D community. 
  
  
• Another invited talk from BMW was delivered by Rainer Hohenhoff which covered “Product Data and Product Life Cycle Management in the face of new business models of the automotive industry.” In short, it discussed many of the ways a car company might make money even after people stop buying as many cars as they do today… and what collisions (pun intended) you could expect in the market as service companies like Google, Amazon, UBER, and others converge on the transportation consumer. 

There were poignant moments as well. After 19 years of personal dedication to this event, both Gitta Haupold of Silicon Saxony and Dr. Klaus Kabitzsch, Program Committee Chair from Technical University of Dresden are retiring. They will definitely be missed!

The insights gained from these and the other 30+ presentations are too numerous to list here, but in aggregate, they provided an excellent reminder of how relevant semiconductor technology has become for our comfort, sustenance, safety, and overall quality of life. 

This conference and its sister conference in the US are excellent venues to understand what manufacturers do with all the data they collect, so if this topic piques your interest, be sure to put these events on your calendar in the future. In the meantime, if you have questions about any of the above, or want to know how equipment connectivity and control fit into the overall Smart Manufacturing landscape, please contact us!

It’s time for another episode in our Giga Factory Minute series... And in keeping with the theme of moving around the clock, we see that the focus of this month is “process steps completed.” However, rather than focus on manufacturing processes, we’ll use this opportunity to highlight an important industry process that is underway. Specifically, I’m referring to the role that the automotive market has in quite literally “driving” important segments of the semiconductor and electronics industries. Even as portions of the industry forecast a slowdown over the next 6-9 months, those in the automotive sectors are busier than ever.

From a wafer fab standpoint, one of the biggest news items over the past 6 months has been announcement, groundbreaking, and construction of a new facility in Dresden, namely the Bosch RB 300 wafer fab. The automation aspects of this factory were featured in a very engaging presentation by Otto Graf (Managing Director, Robert Bosch Semiconductor Manufacturing Dresden GmbH) at the recent Innovationsforum for Automation in Dresden, Germany. 

A modern automobile is brimming with electronics, as you can see from the systems highlighted in the figure below. (Image courtesy of chipsetc.com)

Every function in a car, from engine control to seating to headlamps to collision avoidance is getting smarter… and this is a welcome sight for the scores of companies that provide the components that realize these functions.

But the full impact of automotive electronics includes all the infrastructure technologies external to the car, such as 5G telecommunications, “smart” roads and traffic signals, routing and congestion management systems for major cities, satellite systems that provide GPS information, entertainment content providers for the non-drivers, and law enforcement, just to name a few. And as driverless cars approach commercial feasibility, the scope and importance of these systems increase significantly.

In this context, anyone who thinks the “good old days” of the semiconductor and electronics industries are behind us isn’t paying attention -- so buckle up and prepare to enjoy the ride!

If your company plays a role in the manufacturing aspects of this exciting market, and you are struggling with how to address the equipment control and connectivity challenges you face, give us a call. We’ve got people who can help you make sense of it all, and products that can transform your problems into solutions.

In the first blog of this series, Clare Liu of Cimetrix China made the compelling case for choosing a commercial software platform for implementing the equipment side of the EDA (Equipment Data Acquisition) standards interface rather than developing the entire solution in-house. 

Whenever this “make vs. buy” decision is discussed, however, the following question inevitably arises: “If we choose a standard product for this, how can we differentiate the capabilities of our equipment and its data collection capability from our competitors?” It’s a great question which deserves a well-reasoned answer.

Platform Choice and System Architecture

Most advanced fabs use EDA to feed their on-line FDC (Fault Detection and Classification) applications, which are now considered “mission-critical.” This means if the FDC application is down for any reason, the equipment is considered down as well. It is therefore important to choose a computing platform for the EDA interface that is highly reliable and has enough processing “headroom” to support the high bandwidth requirements of these demanding, on-line production applications. Moreover, this platform should not be shared by other equipment communications, control, or support functions, since these may adversely impact the processing power available for the EDA interface. 

Surprisingly, this approach is not universally adopted, and has been a source of problems for some suppliers, so it is an area of potential differentiation. 

Adherence to Latest Standards 

The automation requirements for the most advanced fabs call for the latest versions (Freeze II) of all the standards in the EDA suite, including the EDA Common Metadata (E164) standard. Dealing with older versions of the standard in the factory systems creates unnecessary work and complexity for the fab’s automation staff, so it is best to implement the latest versions from the outset. The Cimetrix CIMPortal Plus product makes this a straightforward process using the model development and configuration tools in its SDK (Software Development Kit), so there is absolutely no cost penalty for providing the latest generation of standards in your interface.

It takes time and effort for equipment suppliers with older versions of the standards to upgrade their existing implementations, so this, too, is an opportunity for differentiation.

Equipment Metadata Model Content

This is probably the area with the largest potential for competitive differentiation, because it dictates what a factory customer will ultimately be able to do with the interface. If an equipment component, parameter, event, or exception condition is not represented in the equipment model as implemented in the E120 (Common Equipment Model) and E125 (Equipment Self-Description), and E164 (EDA Common Metadata) standards, the data related to that element cannot be collected. In effect, the metadata model IS the data collection “contract” between the equipment supplier and the fab customer.

This is why the most advanced fabs have been far more explicit in their automation purchase specifications with respect to equipment model content, going so far as to specify the level of detailed information they want to collect about process performance, equipment behavior, internal control parameters, setpoints and real-time response of common mechanisms like material handling, vacuum system performance, power generation, consumables usage, and the like. This level of visibility into equipment operation is becoming increasingly important to achieve the required yield and productivity KPIs (Key Performance Indicators) for fab at all technology nodes.

The argument about “who owns this level of information about equipment behavior” notwithstanding, providing the detailed information the fabs want in a structure that makes it easy to find and access is a true source of differentiation.

Self-Monitoring Capability

If you really want to set your equipment apart from your competitors, consider going well beyond simply providing access to the level of information needed to monitor equipment and process behavior and include “built-in” Data Collection Plans (DCPs) that save your customers the effort of figuring out what data should be collected and analyzed to accomplish this. Your product and reliability engineering teams probably already know what the most prevalent failure mechanisms are and how to catch them before they cause a problem… why not provide this knowledge in a form that makes it easy to deploy?

A few visionary suppliers are starting to talk about “self-diagnosing” and “self-healing" equipment… but it will be a small and exclusive group for a while – join them.

Readiness for Factory Acceptance

Before the fab’s automation team can fully integrate a new piece of equipment, it must follow a rigorous acceptance process that includes a comprehensive set of interface tests for standards compliance, performance, and reliability. This process is vital because solid data collection capability is fundamental for rapid process qualification and yield ramp that shorten a new factory’s “time to money.” If you know what acceptance tests and related software tools the fab will use (which is now explicit in the latest EDA purchase specifications), you can purchase the same software tools, perform and document the results of these same tests before shipping the equipment. 

This will undoubtedly speed up the acceptance process, and your customers will thank you for the effort you took to put yourself in their shoes. Incidentally, this usually means the final invoice for the equipment will be paid sooner, which is always a good thing.

In Conclusion

In this posting, we have only scratched the surface regarding the sources of competitive differentiation. As you can see, choosing a commercial platform enables this far more readily than the in-house alternative, because it allows your development team to focus on the topics above rather than worrying about compliance to the standards. If you’d like to know more, please give us a call or click below to talk schedule a meeting. 

We introduced the Giga Factory Minute concept last year to highlight the impact that standards have in orchestrating the entire manufacturing process, from releasing unpatterned wafers into the line (1:00 on the figure) to the shipment of good die to the downstream assembly/test facilities (12:00). This year, we’ll use this same diagram to identify important industry trends, technologies, events, or other items of interest to our subscribers. Since there are 12 “hours” on the diagram, watch for a posting every month related to the topic in that segment.

January 2019

Since this is January, we’ll focus on the more general topic of electronics manufacturing product materials, of which “wafer starts” is the specific material type that begins the 4-month journey through the wafer fab.

In the early days of the automated factory industry, there were only a few material form factors to deal with… even when you go all the way back to the raw silicon and forward to the finished electronic product. (You can see most of these on the “Sand to Systems” infographic here.)
However, now that semiconductors have found their way into virtually every major industry on the planet, from computers to entertainment to transportation to agriculture to wearables and even to “ingestibles,” the automated material handling challenges across this product diversity have exploded. And it’s only going to get worse.

You may not be responsible for handling exotic material types anytime soon, but understanding the role that equipment connectivity standards can have at the earliest steps in a Smart Manufacturing process is useful nevertheless. Give us a call if you’d like to know more about how these technologies can benefit your operations. 

 

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).

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.
    

KPIs 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!

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!

Even for someone who has been in this industry since the days of the TI Datamath 4-function calculator and the TMS1100 4-bit microcontroller (yes, that’s been a LONG time – the movie Grease premiered the same year!), it is sometimes hard to grasp the scope and complexity of what happens in today’s leading-edge semiconductor gigafabs. In fact, the only way to comprehend the enormous volume of transactions that occur is to consider what happens in a single minute – this is illustrated in the infographic we have labeled “The Gigafab Minute.”* 

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.