How an equipment maker is applying Micius to catch tool faults before downtime

When a process tool goes down in a fab, the equipment maker’s field engineer pulls the logs, writes a report and waits for R&D at headquarters. Every round trip keeps the tool down. One equipment maker is working with Zhiman to apply Micius to predictive maintenance on a plasma process tool. It is designed to get early signs, evidence and a risk rating to an engineer before the tool fails; engineers decide on maintenance and release.

Field engineers usually go with a process tool when it ships to a fab. If the tool goes down, they pull its logs, add what they can see on site and send a report to the R&D engineers who designed it. R&D knows the tool best but isn’t in the fab, so it replies with the data it still needs and the steps to try. The field engineer runs those steps and reports back. One problem can take several rounds, with the tool down the whole time, and the more tools a maker ships, the more of these round trips there are.

Yet many failures give warning. Chamber pressure can hold at setpoint while the controller opens the throttle valve further and further to keep it there. The PLC, the tool’s control system, sees normal pressure and stays silent. Even if someone notices the valve sitting high, it is hard to tell on site whether the pump, the valve or the pressure gauge is at fault. When the valve runs out of travel, the tool stops.

Here is what that looks like on the tool’s console: chamber pressure has sat flat between its limits for the last 40 lots, with no active alarms. At the same recipe step, though, the pressure-control valve keeps opening wider and pump current keeps climbing. The controller is compensating, and its margin is shrinking.

Zhiman and the equipment maker are building this together for one of the maker’s plasma process tools. Micius is trained on the tool’s development manuals, service procedures and troubleshooting guides, and a local knowledge base holds the inspection SOPs, fault guides and past repair cases. It can run beside the tool, close to the data, or on an in-house compute cluster.

Micius watches the tool’s process and health signals continuously. When one starts to look wrong, it saves that stretch of live data and investigates, reading only. It first checks the recipe, the process step and the operator log to rule out a human change. Then it lines up the related signals in time to see which moved first and whether the shift is holding. It keeps several explanations open at once, letting each new piece of evidence strengthen or weaken them, and checks whether a faulty sensor could be producing the drift. A brief blip that recovers on its own is logged as low risk.

In a case like the 40-lot drift, nothing has changed in the recipe, the step, manual valve moves or interlocks, so a human change is ruled out. Lost pumping capacity comes out as the leading cause, still to be verified. Gauge drift is weakened because pump current is moving too, and a sticking valve needs an on-site check.

Micius then checks its leading suspect against the knowledge base and cites the section behind every point. For this drift it cites three sources: a vacuum-system inspection SOP, a vacuum and valve troubleshooting guide, and a past case from a sister tool. The SOP passage says, in short, that when chamber pressure is within tolerance but the pressure-control valve keeps opening wider, the pumping system should get a planned inspection; an immediate stop is not required.

So Micius rates the risk as medium and recommends planned maintenance once the current lot finishes. It posts a predictive notice to the tool’s alarm area without changing the PLC alarm state. The engineer sees a one-line judgement, then the evidence and the cited passages, and can ask follow-up questions: what the rating rests on, what to inspect first, what has to be true before release. Having read the SOP passage, the engineer decides whether to open a maintenance task.

By design, Micius helps with maintenance only after an engineer has started it. It first confirms four things: the tool is on maintenance hold, the production recipe is write-locked, interlocks can’t be bypassed and auto-release is off. If any of them fails, it stops and records why. It then reads the evidence signals and recalibrates one compensation value, a maintenance setting outside the production recipe, and attaches a snapshot of the screen to the work order with its reasoning. Teardown, inspection and interlock resets stay with the engineer.

After requalification, Micius compares pump current, pump-down time and the leak check with the readings from before maintenance and recommends whether to release. It doesn’t touch the production recipe, can’t bypass an interlock and has no authority to release the tool.

The setup is designed to change when maintenance starts. It used to start when the tool went down. With Micius watching, the early signs, the evidence and a risk rating can reach an engineer before any hard alarm, while there is still time to plan the repair. Pulling logs and writing reports can move to Micius, while the field engineer reviews the evidence and decides when to service the tool and whether to release it.

Every judgement cites its source, and the data and maintenance-screen snapshots go onto the work order, so anyone can check later why a call was made and what was done.

When a problem does need R&D, the field engineer sends the evidence and analysis already gathered, and the designers start from there instead of from the raw logs.