+ QTimers create a recursive scheduling problem: you need to know downstream capacity before releasing WIP, but downstream capacity depends on what you release.

+ Heuristic schedulers can't solve this - they step forward through time with limited visibility of what lies ahead, relying on hand-tuned rules and weights that interact in ways no one fully understands.

+ Mathematical optimisation takes a fundamentally different approach: it considers every lot, step, and constraint simultaneously across the entire planning horizon.

+ Real fab results: 29% fewer timelink violations at Renesas; best-in-class KPI performance in a competitive PoC at a large bumping facility.

Queue timers are one of the hardest constraints in semiconductor manufacturing. They define the maximum allowable time between consecutive process steps,  and violating them means scrapped wafers, lost yield, and wasted capacity.

Every fab engineer knows the feeling: a furnace PM gets extended, WIP backs up at the entry to a QTimer loop, and suddenly the line is caught between holding lots back (losing throughput) and pushing them through (risking violations). It's a lose-lose trade-off that plays out across fabs every single day.

And the problem is only getting worse. More advanced process nodes bring tighter QTimer windows, while the economic cost of idle capacity and yield loss keeps rising. So why haven't existing scheduling systems solved this? That's the question we set out to answer when Flexciton built Flex Planner, a production planning engine purpose-built to solve the QTimer conundrum using mathematical optimisation.

What makes QTimers so difficult?

At first glance, a queue timer looks straightforward: process step A must be followed by step B within a defined time window. But in practice, QTimers create a deeply recursive scheduling problem.

Consider what's actually happening. A lot enters a QTimer loop, say, a clean step followed by a furnace step. The scheduler needs to decide whether to release that lot into the loop. But making that decision requires knowing whether there will be enough capacity at the furnace to process the lot before the timer expires. And knowing that depends on what other lots are already scheduled at the furnace, which in turn depends on decisions being made at other tool groups, for other products, across other QTimer loops.

You need to know the future to decide what to do now, but the future depends on what you decide now.

This recursive interdependency is what makes QTimers fundamentally different from most other scheduling constraints. You can't solve them step-by-step. You need to see across all the relevant steps, tools, products, and lots simultaneously. Multiply this across a fab with thousands of tools, hundreds of products, and re-entrant flows where lots revisit the same tool groups multiple times, and you're dealing with one of the hardest scheduling challenges in manufacturing.

Where dispatch and heuristic schedulers fall short

Dispatch-based systems and heuristic schedulers — which account for the vast majority of scheduling tools deployed in fabs today — share a common architecture. They move through time sequentially, simulating the fab forward from the current state. At each moment, they rank the available lots against a set of weighted factors and dispatch the highest-priority lot to the next available tool. The system steps forward through time, making greedy decisions at each point without much visibility of what lies ahead.

The intelligence of such a system lives entirely in how the ranking factors are configured, and this is where things get painful.

The slider problem

In a real deployment we reviewed, a single fab tool group had approximately 20 hand-tuned priority factors. Lot priority, critical ratio, number of steps away, step enter time, line balance ratio, reticle assignment, queue timer urgency — each assigned a numerical weight that determines how much influence it has on the dispatch decision.

One of those sliders was: "Process End Time: Try to finish the lot as early as possible," weighted at 30. The obvious question: shouldn't a scheduling system be smart enough to figure that out on its own? And what does a weight of 30 actually mean relative to the 19 other sliders?

This isn't an isolated example. We have seen fabs with even 5,000+ hand-tuned factors across the whole fab: each one balanced by engineers based on experience, intuition, and tribal knowledge. When a tool goes down or the product mix shifts, someone has to re-tune those sliders  often without a clear record of why they were set the way they were in the first place.

Why this fails for QTimers

The QTimer-specific sliders in these systems are telling. In the example above, three separate QTimer factors tried to increase the priority of lots inside a timer. But the system had no way of knowing whether downstream capacity would actually be available to process those lots before the timer expired.

This is the fundamental limitation: the heuristic schedulers commonly deployed in fabs today step through time sequentially. They cannot holistically plan ahead to see how much capacity will be available at future steps. They cannot reason about the interactions between multiple QTimer loops. They cannot assess whether releasing a lot into a timer now will create a conflict three steps downstream.

The system has limited visibility of downstream capacity. It's guessing how much to prioritise lots in a QTimer, balanced vaguely against all the other sliders.

The feedback from fabs using these systems is consistent: conflicting rules that can't be properly tuned, QTimer violations requiring manual workarounds, and a lack of fab-wide coordination that makes locally acceptable decisions globally damaging. More sliders don't help. More rules do not necessarily lead to better scheduling.

How mathematical optimization solves QTimers differently

Solving QTimers properly requires the ability to look holistically across the entire planning horizon — all relevant steps, tools, products, and lots — and make decisions at a global level, considering everything simultaneously. It also requires doing this across a large number of steps, since QTimer constraints often span multiple tool groups in complex, overlapping, and nested configurations.

This is exactly what Flex Planner was purpose-built to do.

Where a simulation-based scheduler moves forward through time dispatching lots one by one, Flex Planner builds a model of the entire fab: every tool group, every lot, every product route, every constraint, including all QTimer definitions. It subdivides the planning horizon, typically one to four weeks, into discrete time buckets and calculates the available capacity at each tool group in each period, accounting for batching, tool availability, cascading chambers, and scheduled downtimes.

It then encodes the entire scheduling problem as a system of thousands of simultaneous equations and allocates every lot across the entire horizon simultaneously. This mathematical formulation defines trillions of feasible solutions. The optimiser searches through that solution space to find the best possible plan for the fab's objective, typically maximising on-time delivery and throughput while minimising QTimer violations.

This is how QTimers actually get solved: not by guessing which lot to prioritise based on a slider weight, but by computing the globally optimal allocation of capacity across every step in every QTimer loop, for every lot, across the entire planning horizon. The system knows how much capacity will be available downstream because it's planning all of those steps at the same time.

The system re-optimises every 30 minutes and integrates directly with MES and dispatch systems to translate optimised plans into floor-level execution. And it does this at production scale - demonstrated across 100,000+ lots, 4,000+ machines, and 1,000+ products in a single optimisation run.

From scheduling to autonomous WIP flow automation

Once you have a system that can plan holistically across the entire fab, you unlock a new category of automation. Dispatching systems automated step-level decisions, batching rules, hot lot prioritisation, tool loading. But they couldn't touch longer-range WIP flow decisions. Those still required engineers and planners.

Flex Planner enables autonomous WIP flow automation, where multi-step, multi-tool-group decisions are made automatically based on data and objectives, dramatically reducing the need for hand-tuned rules.

An example: emptying a QTimer loop before a PM

Imagine a QTimer loop where the exit step runs on a tool with a 3-day preventive maintenance window approaching. The lots already in the loop need to clear before the PM starts, and no new lots should enter if they can't complete in time.

In a traditional MES or RTD setup, this requires a human planner to manually identify the upcoming PM, assess the QTimer exposure, apply a hold rule at the loop entry, and prioritise the lots already inside, repeated for every PM and every QTimer loop.

With Flex Planner, the system understands from the data that the exit tool has limited capacity due to the upcoming PM. Its objective is to minimise QTimer violations. So it autonomously schedules the WIP already in the loop to exit, and holds new WIP at the entry step until the PM is over. No rule was written - the behaviour emerged from the combination of data and objective.

Data + Objective = Autonomous Behaviour. The system figures out what to do by understanding the constraints and optimising against the objective - dramatically reducing the need for hard-coded rules.

And it scales: as the fab changes - new products, tool downs, PM schedule shifts - the system re-optimises automatically, adapting its plan without anyone needing to update a rule.

Results: what this looks like in practice

The proof of any scheduling approach is in the results. Here are two examples from real fab deployments.

Renesas: Furnace & Clean scheduling

Flexciton deployed Flex APS at Renesas to optimise scheduling in the furnace and clean area, a classic diffusion environment with complex batching requirements and overlapping QTimers.

Results:

• 29% reduction in timelink violations
• 11% reduction in queue time
• 22% improvement in batching efficiency

These gains came from the system's ability to plan batching, QTimer compliance, and cycle time holistically, optimising all three simultaneously rather than trading one off against the others.

Read the full Renesas case study →

Large advanced packaging (bumping) facility

In a competitive proof-of-concept at a large bumping facility, Flexciton was evaluated alongside multiple other scheduling vendors. The environment featured complex overlapping QTimers, multi-resource setup constraints (flux, ball type, stencil), and demanding OTD targets.

Results:

• 30% improvement in super hot lot OTD
• 28% improvement in key customer OTD
• 6% decrease in QTimer violations

Flexciton achieved the best KPI performance of all vendors. WIP flow optimisation and QTimer compliance don't have to come at the expense of delivery performancee, when you can plan holistically, you can improve all of them together.

The QTimer problem demands a different approach

QTimers are inherently multi-step, multi-tool, recursive constraints that require global visibility and holistic planning, capabilities that sequential, simulation-based systems struggle to provide. The consequence has been conservative WIP gating, manual workarounds, chronic violations, and a persistent trade-off between QTimer compliance and fab throughput.

Mathematical optimisation offers a fundamentally different approach. By modelling the entire fab as a system of simultaneous equations, Flex Planner finds near-optimal plans at production scale that respect QTimer constraints while maximising throughput and on-time delivery - and enables a new paradigm of autonomous WIP flow automation, driven by data and objectives rather than hand-tuned rules.

The QTimer conundrum is solvable. But solving it requires moving beyond dispatch rules and sliders to a technology that can actually see the whole picture.

‍

Want to see how Flex Planner handles QTimers in your fab?

Watch the full webinar "Solving the Queue Timer Conundrum" with Sebastian Steele, Product Director at Flexciton, or get in touch to discuss your specific scheduling challenges.

‍

‍