Manufacturing problems do not always begin with a sudden equipment failure or an obvious alarm. In many cases, performance deteriorates gradually.
A pressure reading moves slightly higher from one production run to the next. Chamber temperature takes longer to stabilize. A valve response becomes less consistent. Individually, these changes may remain within specification. Together, however, they can indicate that the process is moving away from its established operating state.
This gradual movement is known as process drift. Because it often develops within existing limits and across multiple variables, it can remain hidden until metrology, inspection, electrical test, or final quality results reveal the damage.
For manufacturers seeking to improve yield, detecting drift earlier is therefore not simply a data-analysis exercise. It is an important part of managing process risk.
Process drift is a sustained or progressive change in the normal behavior of a manufacturing process. It may affect the center, variation, relationships, or time-dependent behavior of one or more process variables.
Typical causes include:
Drift should not be confused with every form of process variation. Random variation is present even in a stable process. A sudden fault may produce an abrupt excursion, alarm, or equipment stop. Drift is often slower and less visible.
Another important distinction is the difference between specification limits and control limits. Specification limits normally describe acceptable product or process requirements. Control limits are derived from observed process behavior and are used to assess statistical stability. A process can remain inside a specification limit while showing an abnormal trend relative to its historical baseline.
NIST describes control charts as time-ordered displays with a process center line and upper and lower control limits. It also distinguishes univariate charts, which monitor one characteristic, from multivariate charts, which summarize several related characteristics.
Many equipment alarms are based on upper and lower thresholds. They respond effectively when a variable crosses a defined boundary, but a slow trend can remain between those boundaries for an extended period.
For example, a gas-flow measurement may still be inside its permitted range even though it has moved consistently away from the baseline associated with stable processing.
Complex manufacturing processes depend on relationships among parameters. Pressure, gas flow, temperature, power, endpoint behavior, and processing time may each appear acceptable when viewed separately. Their combined pattern may nevertheless be abnormal.
A common example occurs when two parameters operate at opposite ends of their acceptable ranges. Imagine a process chamber where pressure consistently runs near its upper control limit while valve response time remains near its lower limit. Neither parameter would trigger an alarm on its own, but their combined behavior can still affect process stability and product quality.
This is one reason multivariable monitoring is important. In modern semiconductor manufacturing, high-dimensional data, correlations among variables, tool hierarchies, metrology delays, and asynchronous observations can limit the effectiveness of purely univariate monitoring.
Metrology and inspection are not always performed on every unit immediately after every step. By the time a quality shift is confirmed, additional wafers, panels, cells, or batches may already have passed through the same process.
Research on semiconductor FDC has long highlighted this problem: relying on downstream product results or infrequently sampled wafer-state measurements can allow more material to be processed before a tool or process fault is recognized.
A value that is normal for one recipe, product, chamber, material, or process phase may be abnormal for another. If monitoring models do not account for production context, they can either miss meaningful deviations or generate excessive nuisance alarms.
Engineers often review dashboards over short time windows. A small difference between consecutive runs may not appear significant. The long-term trend becomes visible only when data are aligned and compared across many cycles.
Drift does not automatically mean that products are defective. The risk arises when it reduces the margin between normal operation and a process or quality boundary.
As that margin narrows, the process becomes more vulnerable to:
Eventually, the combination of drift and routine variation can result in defects, rework, downgraded material, additional inspection, or scrap.
The business impact may extend beyond yield. Teams can spend significant time investigating intermittent failures, placing lots on hold, reconciling equipment and quality data, or attempting to reproduce a condition that developed gradually. Drift can also influence cycle time, maintenance workload, equipment availability, and delivery predictability.
There is no universal percentage of yield loss attributable to process drift. The impact depends on the process, product, detection latency, sampling strategy, and amount of material exposed before containment. Manufacturers should calculate the effect using their own excursion histories and yield-loss data rather than relying on a generalized benchmark.
Consider a plasma etch chamber processing the same product family over several weeks.
The chamber-pressure reading remains within its engineering limit, and no equipment alarm is generated. However, engineers later observe that pressure has gradually increased while RF matching behavior and endpoint duration have also shifted. Post-process critical-dimension measurements begin moving toward the edge of their acceptable range.
No single signal provides conclusive evidence of a fault. Viewed together and over time, the signals suggest a progressive change in chamber behavior. Potential causes could include deposition on chamber surfaces, consumable wear, gas-delivery degradation, sensor bias, or a maintenance-related change.
A properly configured FDC strategy could:
This scenario is only illustrative rather than a measured case study. The variables and causes would need to be validated against the actual process and equipment design.
| No. | Common Mistake | Why It Matters | How to Avoid It |
| 1 | Monitoring only specification violations | A process-management strategy that focuses only on limit violations can miss trends, changes in variance, and abnormal relationships between parameters. | Monitor rate of change, moving averages, cumulative behavior, variance, and multivariable patterns in addition to fixed engineering limits. Depending on the monitoring requirement, methods may include CUSUM, EWMA, multivariate charts, principal-component methods, and time-series techniques. |
| 2 | Treating every sensor independently | A single parameter may not provide enough evidence to identify drift. The warning signal may emerge only when several related measurements are evaluated together. | Group variables according to process physics and known failure mechanisms. Use domain knowledge to identify meaningful relationships instead of placing every available sensor into one undifferentiated model. |
| 3 | Building one model for every operating condition | Combining recipes, products, process phases, chambers, or equipment states can create a baseline that does not accurately represent any individual operating condition. | Segment monitoring according to relevant production context. Consider equipment, chamber, recipe, process phase, product family, and maintenance state. Determine the appropriate segmentation through engineering analysis. |
| 4 | Ignoring sensor and data quality | A monitoring system may be unable to distinguish genuine process drift from data-quality problems when timestamps are misaligned, sensors are unstable, units are inconsistent, or data are missing during critical process phases. | Validate data completeness, timestamp synchronization, sensor health, measurement units, sampling rates, context tags, and recipe versions before expanding analytical coverage. |
| 5 | Creating alerts without a response workflow | Even an accurate alert has limited value when ownership is unclear or investigators cannot access the evidence needed to evaluate it. | Define alert severity, ownership, escalation rules, containment criteria, and investigation steps. Give engineers access to relevant traces, affected lots, tool history, maintenance events, and related metrology. |
| 6 | Leaving models and limits unchanged indefinitely | Models created during commissioning may become outdated following equipment maintenance, process improvements, recipe modifications, or new product introductions. | Regularly review model performance, false alarms, missed events, control limits, and classification logic. Govern and document changes so that valid process evolution is not mistaken for deterioration. |
Fault detection and classification monitors process and equipment data to identify abnormal behavior and, where sufficient evidence exists, associate it with a known fault category or probable cause.
Detection answers: Has the process departed from expected behavior?
Classification answers: What type of condition may have caused that departure?
FDC may use:
The objective is not to replace engineering judgment. It is to help engineers examine large volumes of time-series data consistently and prioritize the conditions that deserve investigation.
Reliable data acquisition is an important foundation. The SEMI Equipment Data Acquisition framework, also known as Interface A, provides standardized mechanisms for exposing equipment models and collecting trace, event, and exception data. SEMI E134 specifically addresses the management of data collection plans for equipment data consumers.
FDC should also complement rather than displace other controls. SPC can monitor process and product characteristics, while metrology confirms physical outcomes, maintenance addresses equipment condition, and advanced process control adjusts selected parameters. The exact division of responsibilities depends on the manufacturing environment.
A practical approach begins with a focused use case rather than an attempt to model every tool and sensor.
The most effective system is not necessarily the one with the most complex algorithm. It is the one that detects meaningful changes early enough for the organization to take an appropriate, controlled action.
Process drift is difficult to manage because it develops gradually, can remain within fixed limits, and may be visible only through relationships among multiple variables.
Manufacturers can improve early detection by:
A sensible next step is to select one process with a history of unexplained deviations and evaluate whether the available equipment data contains an earlier, repeatable indication of the problem.
To learn how LineWorks FDC supports equipment and process monitoring, explore the product page and its approach to fault detection, classification, and manufacturing data analysis.
Learn more about LineWorks FDC on the product page.
A: Normal variation occurs within the established behavior of a stable process. Drift shows that the process behavior itself is changing over time, even if individual readings remain within specification.
A: Yes. Specification limits define acceptable requirements, but they do not necessarily identify changes relative to a process’s historical baseline. A process may therefore be in specification but statistically unstable.
A: Many equipment alarms respond to fixed threshold violations or defined equipment events. Slow changes may not cross those thresholds, particularly when the signal is distributed across several variables.
A: Relevant data may include sensor traces, processing times, alarms, events, recipe parameters, equipment states, maintenance records, material context, metrology, inspection results, and yield outcomes.
A: No. Control charts, trend rules, moving averages, CUSUM, EWMA, and engineering limits can detect many forms of drift. Machine learning may help with complex multivariable patterns, but it requires suitable data and governance.
A: No, FDC is only used to monitor and analyze the performance within a single process run/execution event. Yield management software is used to correlate data across different process steps.