【翻译】智能制造中EDA 应用及益处系列之六：跟踪数据分析

在“EDA应用及益处”系列的最后一篇文章中，我们将讨论一个应用程序，它是最基本和最直观的应用程序之一，同时也为机器学习和人工智能(AI)领域中的许多新兴功能提供了基础-跟踪数据分析。此外，在我们过去6个月介绍的所有应用程序中，跟踪数据分析是最直接利用SEMI设备数据采集(EDA)标准功能的应用程序。

问题陈述

当我们问晶圆厂工艺工程师和他们的自动化支持团队为什么他们现在要求在新设备上使用最新的SEMI EDA/Interface A标准时，我们听到最多的答案是“为了更好地理解设备和工艺行为”。当被问及为什么不能使用SECS/GEM接口实现这一目标时，答案是一致的:“我们需要的详细信息要么不可用，要么无法以我们需要的频率收集，以准确地查看和描述我们感兴趣的行为。即便这是可能的，我们也没有操作上的自由来根据我们需求的变化而快速改变我们的数据收集系统，所以我们必须有一个更灵活的方法。”

这些工程师寻找的出发点是一种可以方便地指定组可能相关的设备参数，并以足够快的频率收集它们的值，以了解它们之间变化的相互关系的方法。人类非常擅长模式识别，只要能够将一组信号并置在一个“带状图表”上(参见下面的第一个图)，就可以对底层过程产生重要的见解。当然，当工程师能够精确地指定感兴趣的时间范围时，这种能力是最有用的。这有时被称为数据“帧”，可以通过使用设备事件将感兴趣的时间段括起来实现(参见下面的第二个图)。

虽然人类可能擅长模式识别，但当要查看的参数数量增加和/或要考虑的时间范围扩大时，他们很快就会不知所措……这就是跟踪数据分析软件发挥作用的地方。

解决方案组件

除了非常灵活的时间序列数据可视化工具, 跟踪数据分析软件包必须能够“切割”大型数据集的子集， 以比较所有可能的设备，工艺腔，产品，层，配方，夹具，易耗品的批次, 轮班, 操作员的组合,…以寻找重要工厂指标和相关设备行为之间的相互关系。此外，它们必须能够识别和标记“异常”(这个必须可以被灵活定义)情况，以便进一步分析，因为这些情况可能包含关于早期故障的线索，而传统的多元FDC(故障检测和分类)应用程序可能无法捕捉到这些线索。

事实上,有一个新兴的关于故障检测的说法“多数时候，对于一个生产状况良好的设备，除非在当前批次和最近一些批次之间有非常不同的行为（由跟踪数据分析确定的），那么非常用可能当前的批次结果也是好的”。这种简化的方法也被称为“无模型FDC”，因为它主要是对跟踪数据信号进行比较，而不是将设备参数传到跟上下高度相关的多元数据统计的模型中。

当然，任何跟踪数据分析应用程序都只有提供给它的数据好，这就是EDA标准和相关设备采购规范的作用所在。

EDA(设备数据采集)标准的杠杆作用

以前的文章，如第四篇关于故障检测分类和工艺执行期间精确的数据定位技巧突出了与数据收集计划(DCPs)及跟踪请求、事件请求和异常请求相关的EDA标准Freeze II的能力。我们还强调了在指定设备采购规范的EDA部分时需要广泛的利益相关者的参与，并描述了为实现这一点而精心设计的流程。

然而，要完全支持世界级的跟踪数据分析应用程序，了解对设备供应商的要求是很重要的。为此，我们从下面的典型采购规范中摘录了一些关键的实例需求。

设备模型内容(SEMI E120、E125、E164)

• 元数据模型的层次深度应该至少包含“现场可替换装置”(FRU)级别，对于复杂的子系统，应该包含低于此级别的两个级别之一。
• 元数据模型必须包含所有影响物料移动的设备组件的命令和状态信息。这不仅包括物料传输元件，如机器人手臂，而且还包括可能停止/启用材料移动的装置，比如闸阀、互锁等。
• 元数据模型必须包含设备中所有重要操作机制和子系统的控制参数。控制参数可以包括但不限于:工艺变量设定值和状态值;控制变量状态值;PID整定参数，控制限制，和校准常数。
• 元数据模型必须包括那些在基于时间、基于使用情况和基于条件的维护调度算法中可能有用的计数器、计时器和其他参数。
• 元数据模型必须包含描述关键工艺资源(如电力、工艺气体和其他消耗品)的消耗率和级别的参数。这些在一些FDC模型中用于检测潜在的异常工艺状况。
• 供应商必须对所有关键工艺参数的更新速率、推荐采样间隔、正常操作范围和行为以及高/低/变化率限制提供书面描述。
• 其他。

数据采集能力(SEMI E134)

• 设备必须包括内置的DCPs，以支持供应商熟知的通用设备性能监视、诊断和维护流程。这些DCPs的文档必须定义它们的用途、激活条件、消耗的接口带宽以及所收集数据支持的分析类型。
• 通过EDA接口提供的设备参数必须显示一定数量的数据质量特征，包括但不限于: 足以准确表示底层信号的内部采样/更新速率;与采样间隔在+/- 1.0%范围内的跟踪报告定时;相邻跟踪报告中的值必须包含指定采样间隔的当前值;拒绝明显的异常值。

性能需求

• 性能需求将表示为采样间隔,每个DCP中参数的数量，同一时间活跃的DCP数量，Group Size, 缓冲间隔,特别的“一次性”DCP的响应时间, 设备状况触发后生成事件的最大延迟时间，, 跟踪报告中时间戳与指定采样间隔的，也许还有其他指标的组合。
• 示例: EDA接口必须能够以0.1秒(10Hz)的采样间隔报告至少5000个参数，Group Size为1，总的数据收集能力(带宽)为每秒50,000个数值。它还必须支持同时至少5个客户端的同步数据收集，并仍能实现每秒50,000个参数的总带宽; 可以使用大于1的Group Size来实现此级别的性能。
• 一些设备类型可能比其他类型有更严格的性能要求，这取决于使用应用程序的及时和高密度数据的临界性。

受影响的KPI

因为工艺复杂性日益增加和维护传统的“时间收益率”生产增加的需要，跟踪数据分析无疑将在当今晶圆厂的其他“关键任务”应用程序中占据一席之地。这对于目前使用最新的EUV扫描仪的行业先锋来说尤其如此，因为在未来几年，关于这项新技术还有很多需要学习的地方。

 

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

 

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!

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

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