What matters is not how much infrastructure you have, but whether you can operate it continuously with a small team. Many manufacturers begin their smart factory and process automation efforts by implementing systems such as SPC (Statistical Process Control) and FDC (Fault Detection and Classification). These systems collect sensor data, apply control limits, and issue alarms when something appears abnormal. They have long served as core manufacturing infrastructure and still play an important role in many fabs.
But SPC and FDC do not have to be fully in place before manufacturing AI can begin. If equipment sensor data and process results are already available, much of the foundation is there. The more important question is who will continue to manage all the data, detection rules, models, and control policies once they are deployed.
Putting monitoring in place, keeping a growing set of rules and alarms under control, and building something a small team can operate continuously are three different problems.
- What matters is not how much infrastructure you have, but whether you can operate it continuously with a small team.
- If equipment sensor data and process results are already available, manufacturing AI does not require SPC and FDC to be fully in place first.
- The real challenge in manufacturing AI is not building a model — it is keeping that model running in production.
- The real prerequisites are data access, model operations, alarm policies, and a reliable update process — not whether FDC is already installed.
| SPC | FDC | APC | |
|---|---|---|---|
| Full Name | Statistical Process Control | Fault Detection and Classification | Advanced Process Control |
| Data Used | Averages and variation in process results | Equipment sensor data (pressure, temperature, flow, power, and more) | Process results or virtual metrology outputs |
| What It Does | Tracks shifts with control charts and signals when data crosses control limits | Detects signals that move outside predefined ranges | Calculates and applies the recipe or setpoint adjustment for the next run |
| After an Anomaly | An engineer reviews the data, investigates the cause, and changes process settings | Engineers review each alarm one by one | The control system repeats the correction |
What each system monitors, what it does, and how the response is handled once an anomaly is found.
The main challenge with FDC is not detection — it is operation
The problem is not that FDC is missing — it is the number of conditions that must be maintained, and the time and people required to keep them aligned with a changing process.
FDC monitors equipment sensor data and detects signals that move outside predefined ranges. A typical setup applies upper and lower limits to variables such as pressure, temperature, flow, and power. The logic is straightforward, but operating it in a production environment quickly becomes complicated.
A single semiconductor tool may generate hundreds or even thousands of sensor signals. Each signal may require different rules depending on the tool, chamber, recipe, and process step. Those rules cannot simply be configured once and left unchanged.
Normal sensor behavior keeps shifting for reasons such as:
- Recipe changes
- Incoming wafer condition or prior process history
- Equipment aging, maintenance, and consumable replacement
Each of these changes requires existing detection limits to be reviewed again. In practice, engineers often spend more time maintaining and adjusting detection rules than creating them in the first place.
Every signal needs its own rules and thresholds, and both the alarms they raise and the rules themselves have to be adjusted whenever the process changes.
Tight limits generate too many alarms, including events that have little or no impact on product quality. Engineers then have to review them one by one. Wider limits reduce the alarm volume but increase the chance of missing something important. Over time, some sites respond by widening limits until alarms rarely occur, or by disabling low-value monitoring altogether.
AI-based anomaly detection still needs an operating model
Deploying an AI model does not remove the operational burden by itself.
AI-based anomaly detection emerged because fixed thresholds are often not enough for complex, changing processes. Instead of checking whether a single sensor crossed a limit, AI can learn relationships across multiple signals and recognize whether the current process trajectory differs from normal behavior. This can be more flexible when normal operating ranges vary by recipe, equipment state, or process context.
When process conditions change, the model must be checked again. Maintenance, consumable changes, and recipe updates may require retraining or replacement. Teams still need to decide which events matter, how alarms should be prioritized, who should receive them, and when models should be updated.
What matters is not whether one model can analyze one dataset well. It is whether many models across many tools and processes can be monitored, versioned, updated, and operated by a small team. Without automation around model performance, deployment, alarms, and updates, AI can recreate the same maintenance problem that already exists with large FDC rule sets.
These capabilities also do not have to live inside an existing FDC system. If sensor data is accessible, a separate anomaly detection service can be built around the needs of the process and the way the fab operates.
SPC finds the problem, but people still have to solve it
SPC's basic operating model assumes that people will handle the response after an anomaly is found.
SPC is a traditional way of monitoring changes in process results. Control charts track shifts in averages and variation, and signal when data crosses control limits or matches a predefined rule. It remains useful for quality monitoring and long-term process visibility.
The control chart shows where the data crossed a control limit; the judgment and the corrective action after that are left to the engineer.
When an alarm occurs, engineers carry the work from reviewing the data to checking the result. APC automates much of this work.
When an alarm occurs, the response typically follows these steps:
- An engineer reviews the data
- Investigates the cause
- Decides which process settings to change
- Applies the adjustment to the next run
- Checks whether the result improved and decides whether another adjustment is needed
As the number of tools, products, and process conditions grows, this approach consumes more engineering time. SPC can identify that something may be wrong, but the diagnosis, decision, and corrective action remain separate tasks.
APC (Advanced Process Control) automates much of this work. It uses process results or virtual metrology outputs to estimate the current process state, calculate the required recipe or setpoint adjustment, and apply it to the next run. Work that previously required an engineer to review a chart and manually determine a correction can be repeated by the control system.
Measurements feed prediction and a control action, and the calculated adjustment is applied to the next run, keeping process results around the target value. (Illustrative.)
Where APC is running reliably, SPC no longer needs to be the center of process adjustment. It can still support quality assurance and long-term monitoring, while APC handles routine correction and target control.
Building infrastructure is not the same as achieving automation
A better way to evaluate manufacturing automation is to look at how it is actually operated, not how many systems have been built.
SPC and FDC helped establish the foundation for collecting manufacturing data and monitoring process conditions. But if engineers still have to maintain hundreds of rules, review recurring alarms, investigate causes, and manually adjust process settings, the level of automation remains limited.
New systems can even create new operational work without removing the old work. Sensor limits still need to be adjusted. Alarms still need to be reviewed. Models still need to be validated after process changes. Someone must decide when to deploy or update them, and engineers still have to respond when an issue is found.
In that situation, more data and more systems do not necessarily mean more automation. They may simply create more things to manage.
- How many tools and models can one engineer manage?
- How quickly can the system adapt when the process changes?
- How much of the decision-making and corrective action after detection is automated?
Manufacturing AI does not have to sit on top of a complete legacy stack
What matters is not which systems are already installed, but whether data can be connected, the process can be modeled, models can be maintained as conditions change, and actions can be executed safely.
If SPC and FDC are already in place, their data and existing infrastructure can be used. There is no need to remove or replace them all. The reverse is also true: a fab does not need a fully implemented SPC or FDC environment before it can begin using AI-based anomaly detection or APC. If equipment signals, process settings, and quality results are accessible, manufacturing AI can begin from there.
Existing infrastructure can be one input or connection point for manufacturing AI, but it is not a prerequisite in itself.
Amously goes beyond adding another anomaly detection model. It connects model development, validation, deployment, monitoring, updates, and control policy management in one operating flow, so engineers do not have to manually rebuild every condition whenever the process changes.