Wafer fabrication
A wafer fab hands night-shift alarm triage to Micius, and engineers approve anything that touches a tool
Talk to an engineer
- 4 systems
- once split across several engineers, now worked through by Micius with no handoffs
- Approval first
- anything that touches a tool or production waits for an engineer
- Filed and reused
- each investigation is written up, reviewed by an engineer and filed, so the next one starts from it
It’s the early hours and MES raises an alarm. On one chamber of an etch tool, the mass flow controller (MFC) has drifted from setpoint for several lots, critical dimension (CD) has crossed its upper control limit, and dispatch to the chamber is on hold. At this multi-line wafer fab, nights are often covered by engineers in their first year. An alarm like this used to send several of them into four systems and, when that didn’t settle it, to the phone to wake a senior engineer.
Now the alarm goes first to Micius, Zhiman’s semiconductor model. Micius checks the same four systems itself, then sends the on-call engineer its evidence and a proposed fix. Nothing that touches a tool or changes a parameter runs until that engineer approves it. When the chamber is back in production, Micius drafts the incident report.
Illustrative flowBefore, several people relayed across four systems; now Micius works it through and an engineer approves.
Investigate
One investigation instead of four
Under the old routine, the on-call engineers split the work at the monitoring room’s big screen: lot data from MES, charts in a spreadsheet, old work orders, tool logs, sometimes a walk out to the tool. They pooled what they found and checked it against SOPs and past failures. If that didn’t settle it, someone called a senior engineer and explained everything again. The fab has years of procedures, manuals and fixes on file, but they sit in different systems, and a new engineer may not know where to look. How good the call was depended on who was on shift.
Micius came to the night shift knowing semiconductor process and equipment, and it has read this fab’s SOPs, tool manuals and past excursions, along with how its engineers reason through them. It also uses the fab’s software the way an engineer does: it queries MES, reads tool data, pulls work orders and searches documents.
The alarm still starts as a red row on the MES alarm monitor. Micius receives it with the tool, chamber, lots and parameter attached, and first checks that no recovery is already under way. A fault-detection (FDC) alarm and a statistical process control (SPC) excursion at the same time show only that the two are related, so Micius lists the evidence it still needs before drawing any conclusion.
It starts in MES, setting the affected lots against history for the same recipe: out of control or out of spec, high or low, or a shift in trend? From the tool system it pulls what the chamber was doing while those wafers ran, including vacuum, plasma, temperatures, pressures and gas flows, and charts the parameters to find which one changed and when. If that isn’t enough, it looks for similar failures in the work orders and checks the tool’s SOPs and maintenance records. There are no handoffs, and Micius stops once several pieces of evidence agree.
In one case, only one of four chambers on the recipe crossed the control limit, only one of six parameters moved with CD, and an open calibration order and a past case pointed the same way. Micius still called it a leading hypothesis. It would count as the root cause only once requalification passed.
Illustrative flowOne chamber drifts, one parameter tracks CD, and a work order and a past case agree.
Approve
The engineer approves the fix from a phone
Micius sends its analysis, supporting data and proposed steps to a messaging app, where an engineer with sign-off authority approves or rejects the plan. For the drifting chamber, the plan named the likely cause, MFC zero drift, and three steps: dry-clean the chamber, re-zero the MFC, and requalify with monitor wafers. Dispatch would stay on hold until requalification passed.
Tool permissions, safety interlocks and production control rules apply to anything Micius runs. Once approved, Micius can carry out steps the fab has authorised in advance, such as adjusting parameters within permitted limits or triggering a defined procedure.
Micius then tracks each round of monitor-wafer results until the parameters and CD are back in the release window and the tool meets its return-to-production criteria. If something new appears, it analyses that as well and calls the engineer back in when needed.
Report
Writing the incident report
After a night like that, the 8D report rarely got written properly, so the reasoning behind the fix was lost and the next engineer started from scratch. Now Micius drafts it from its own record of the case: when the alarm fired and where, which parameters were off, what data and documents it used, how it reasoned, what was done and what happened. Every query and action is logged and can be traced.
The chamber report also states when to reuse it: same tool type, CD drift that tracks MFC flow while other parameters stay flat. The on-call engineer reviews the report and decides whether it goes into the knowledge base. Next time, Micius compares live data with the filed cases, and those cases can also feed later training and evaluation of the model.
Results
Senior engineers review instead of taking calls
Senior engineers used to be woken to talk the night shift through which system to check. Now Micius does most of the gathering, analysis and planning, and they review the important conclusions and the steps that touch a tool. One senior engineer can follow excursions on several lines from a laptop, a phone or even a watch.
Compared with manual on-call handling, Micius handles excursions faster and diagnoses them more accurately. The fab is working to extend this way of running the night shift to more lines.
The fab decides how far Micius’s execution rights go. Every step that touches a tool still waits for an engineer.
The same approach also works for
-
Metrology and yield excursions
When a measurement goes out of limits or yield drops, compare history for the same product, tool and recipe, and list likely causes and the evidence still needed.
-
Requalification after PM
When parameters drift after maintenance, check maintenance records and sister-tool history, propose an adjustment, and follow through once approved.
-
Shift handover
Summarise how each alarm on a shift was handled, so the next shift starts from the conclusions, evidence and open items.
-
Assembly and test lines
When test yield drops or a tool goes down, investigate across systems, ask for approval, verify and write it up in the same way.
Is your night shift still digging through four systems?
Tell us which alarms your line sees most and which systems they involve. We’ll show you what Micius can take on, what stays with your engineers, and what access it needs.
Related use cases
Predictive maintenance
Reads sensor and maintenance data to flag a tool before it fails, with engineers deciding on the repair.
Role training and onboarding
Turns scattered training documents into a knowledge map that people review, and answers new hires’ questions with the source attached.
TCAD modelling and simulation
Sets up, runs and explains device simulations.
Wafer defect analysis
Reads defect maps and links each pattern to likely causes, for engineers to check.