SPC violations and defect excursions are, in almost every fab we have worked with, tracked in separate systems with separate owners. Camelot flags the out-of-control event. The defect review team sees the inspection count spike hours later. Nobody connects the two until a yield engineer runs a manual correlation weeks after the fact. By then, the lot is shipped or scrapped.
This article covers how Synopsys Camelot SPC data can be aligned with defect inspection results to catch excursions earlier, and why treating these as one pipeline instead of two parallel workflows is worth the integration work.
What Camelot Actually Tracks
Camelot manages statistical process control for wafer fabrication equipment and process steps. At its core, it monitors control chart parameters against defined control limits on a per-tool, per-process, per-parameter basis. When a measurement falls outside a 3-sigma boundary, or when a trend rule triggers (Nelson, Western Electric), Camelot generates an out-of-control alert.
The alert types matter here. Each carries different downstream risk for defect generation:
| Alert Type | Trigger Condition | Typical Cause |
|---|---|---|
| Single point OOC | 1 point beyond 3-sigma | Acute process shift, hardware failure |
| Run rule violation | 8 consecutive points on same side of mean | Gradual drift, consumable wear |
| Trend rule violation | 6 consecutive points monotonically rising or falling | Predictive drift before hard failure |
| 2-of-3 rule | 2 of 3 consecutive beyond 2-sigma | Intermittent instability |
Single point OOC events often correlate with immediate defect spikes. Trend rule violations are the more interesting case: they frequently precede visible defect count increases by 4 to 6 hours because the process is drifting but has not fully broken down yet. That timing offset is the whole point of this integration.
The 4-6 Hour Window
In our experience, this timing offset between SPC violation and detectable defect excursion is the most actionable insight in this entire approach. Worth explaining why it exists.
A Camelot trend rule fires when a parameter is drifting outside normal range. Chamber pressure, etch bias, deposition rate. The wafers currently running on that tool are being processed under abnormal conditions. But they will not reach the next inline inspection step for another 4 to 6 hours, sometimes longer, depending on process flow and inspection frequency. By the time the defect inspection machine sees elevated counts, multiple lots have already passed through the degraded tool.
That window is the intervention opportunity. If the SPC alert triggers a defect review flag immediately, engineers can hold the affected lot at the next available inspection point, pull the chamber for maintenance before additional lots run, or route the lot to enhanced inspection rather than standard sampling.
Fact: in a typical 300mm fab running 24/7, a 4-hour gap before an excursion is confirmed represents 8 to 12 lots at risk per affected tool. That is not a hypothetical. That is what we see when reviewing excursion histories with fabs that track lot-level exposure data.
None of the interventions above are possible when defect review and SPC operate as separate triage queues with no automated handoff.
Timeline Alignment: The Technical Core
Getting SPC and defect data to communicate requires solving a timestamp alignment problem. The two systems operate on different event clocks and different data granularity.
Camelot records SPC events at measurement time, tied to tool and process step. Defect inspection systems record results at scan completion time, tied to wafer ID and lot ID. These are not naturally joinable keys. The alignment technique we use involves three steps:
- Build a lot-to-tool-to-timestamp mapping. Extract from the MES the exact time each lot ran on each tool. This creates a tool exposure window per lot: the lot was on Tool X between time A and time B.
- Tag each Camelot alert with affected lot IDs. Any lot whose tool exposure window overlaps with the alert timestamp is tagged as SPC-exposed. This is the critical join: you are connecting the SPC event to wafer identity before the defect data exists.
- Join to defect inspection results. The SPC-exposed lot IDs become the lookup key into the defect database. Did any of these lots show elevated defect counts at any subsequent inspection step?
This surfaces correlations that would otherwise require a human to reconstruct manually, days after the event. More importantly, it makes correlation forward-looking: when a new Camelot alert fires, the tagged lot IDs are immediately available for enhanced inspection routing before the defect data even exists yet.
The SPC-to-Defect Correlation Workflow
Once the alignment infrastructure is in place, the operational workflow is straightforward. Camelot generates an OOC alert on a specific tool and process step. The integration layer queries the MES for all lots that ran on that tool in the 2 hours prior to the alert timestamp, accounting for the lag between process completion and Camelot measurement.
Those lot IDs go onto a watch list, flagged for enhanced defect review at their next scheduled inspection point. As those lots move through subsequent inspection steps, their defect results are captured and compared against the site's baseline defect density for that process step and defect class. If defect counts exceed a 1.5x baseline threshold, an excursion is confirmed and standard escalation triggers. The SPC alert is linked to the excursion record for root-cause traceability.
That traceability link is where the real value accumulates over time. After 6 months of running this workflow, you build a dataset mapping specific Camelot parameter violations to specific defect types and densities. That dataset becomes a predictive index: when a particular parameter drifts by a known amount at a known step, you have a reasonable expectation of which defect classes will appear and at what density range.
You cannot build that index without starting the data collection. Every unlinked excursion is a missed observation.
One Pipeline vs. Two Workflows
Here is the thing: most fabs are not running a unified pipeline. They are running two independent workflows with a human in the middle doing ad hoc correlation when something goes wrong.
The SPC team monitors Camelot dashboards and responds to alerts by dispatching maintenance or adjusting process parameters. The defect review team monitors inspection results and escalates when counts exceed thresholds. Both teams are doing their jobs. But neither team sees the full picture. The connection between an SPC event and a defect outcome is only made retrospectively, when a yield engineer pulls data for a failure analysis report.
This reactive model has three costs that are easy to underestimate:
- Lot exposure cost. Lots that ran through a drifting tool and were not flagged for enhanced inspection may ship with marginal quality. The exposure window between SPC alert and defect confirmation is where undetected risk lives.
- Root-cause latency. Without the SPC-to-defect link, root cause analysis starts from defect data alone. Equipment history is consulted later, manually, if at all. That adds days to the investigation cycle and typically increases the lot containment scope.
- Learning loss. Every uncorrelated SPC-excursion pair is a missed data point for the predictive model you should be building. You are running the fab without accumulating the institutional knowledge that should compound from each event.
A unified pipeline does not require rebuilding either system. Camelot stays the SPC system of record. The defect inspection system stays unchanged. What changes is the data exchange layer and the triage protocol. SPC alerts automatically populate the defect review watch list rather than requiring manual handoff between two teams who may not communicate until the weekly yield meeting.
Implementation Considerations
The integration is primarily a data engineering problem. Camelot exposes event data via API or database views depending on deployment configuration. Defect inspection systems from KLA, Onto, and Applied similarly expose lot-level results through standard interfaces. The MES holds the lot routing and tool history. All the data is present. The join keys exist.
In practice, the most common blockers are two: MES timestamp granularity and organizational ownership friction.
Some older MES implementations record tool start and stop times in hourly buckets rather than minute-level precision. That granularity is insufficient for the lot-to-tool-to-timestamp join, and you end up with over-broad lot tagging that floods the defect watch list with false positives. Honestly, addressing MES timestamp granularity before deploying the integration saves significant calibration effort downstream.
The ownership problem is more common than the technical one. SPC data lives under process engineering. Defect data lives under yield engineering. MES data lives under IT or manufacturing systems. No single team owns the integration layer, and without a designated owner, the data exchange never gets built. This is an organizational decision, not a technical one.
What to Expect After Integration
Based on what we have seen across integration projects, improvements cluster in two areas.
First, excursion detection time drops. When SPC-flagged lots automatically route to enhanced inspection, the median time from process anomaly to excursion confirmation typically falls from 24 to 48 hours under the standard reactive model to under 8 hours. That reduction directly cuts the number of lots processed under undetected excursion conditions. Fewer lots at risk. Smaller containment scope when an excursion does confirm.
Second, root-cause analysis becomes faster. The linked SPC record provides equipment context that the defect data alone does not carry. Engineers start from a known parameter exceedance at a known time on a known tool, rather than working backward from a defect pattern to hypothesize what might have caused it. That is a materially different starting point for the investigation.
The predictive model that develops over 6 to 12 months of correlated data is the longer-term value. But it requires starting the data collection. And starting requires treating SPC and defect review as one yield protection pipeline.
If your fab is running Camelot alongside a commercial defect inspection system, the infrastructure to build this integration already exists. The question is whether you invest in connecting it. In our experience, the return on that investment shows up quickly in excursion detection time and root-cause investigation hours. The organizational alignment to make it happen is the harder problem. But that is true of most high-value changes in process engineering.
Want to see how Wafertune connects Camelot SPC events to defect inspection data in a unified view? Request a demo.