Cascading

Some machines can start the next job before the last one has finished. A conveyor oven takes a tray every few minutes and has several inside at once. A wash line loads a new rack while the previous rack is still rinsing. A furnace that holds two boats does not wait for the first to finish before the second goes in.

That overlap is cascading, and it is worth modelling because a machine that cascades has far more capacity than its process time suggests — without being two machines.

Terms used here are in the glossary.

The two keywords

Cascading needs both of these, and neither does the job alone:

where	keyword	meaning
on the resource	capacity	how many jobs one machine can hold at once
on the step	start_interval_seconds	how long after starting one job before the next may start

resources:
  - { id: oven, servers: 1, capacity: 2 }
products:
  - id: tray
    pieces: 1
    steps:
      - resource: oven
        process_seconds: { kind: constant, value: 600.0 }
        start_interval_seconds: 400.0

Read it as: one oven, which holds two trays, and accepts a new tray every 400 seconds even though each tray takes 600 seconds to bake.

What it is worth

One oven, a 600-second bake, arrivals fast enough to keep it saturated. Measured on the development laptop (AMD Ryzen 7 7840U):

	trays per hour
one oven, one tray at a time	6.0
capacity: 2, start_interval_seconds: 400	9.0
capacity: 2, no interval declared	11.9
two separate ovens	11.9

The arithmetic behind the second row is worth knowing, because it lets you predict the answer before running anything. A cascading station's time per job is:

max(start_interval_seconds, process_seconds / capacity)

Here that is max(400, 600/2) = 400 seconds, and 3600/400 is exactly the 9.0 measured. The interval is what binds — the oven could in principle do a tray every 300 seconds, but you cannot feed it faster than one every 400.

The mistake this feature invites

danger

Look at the bottom two rows again. capacity: 2 with no interval is not cascading — it is just two machines, and the engine measured it as exactly that: 11.9 trays an hour either way.

That is almost never what a real machine does, and it is wrong in the flattering direction:

• it gives the resource double the throughput it has
• but it still goes down once, wears at one rate, and reports one time-in-state

So the model produces a machine with two machines' output and one machine's maintenance. Nothing fails, nothing looks odd, and every capacity number downstream is too high.

If a machine cascades, declare the interval. If it genuinely is two independent machines, say "servers": 2 and leave capacity alone — that is what servers is for.

Where this comes from

Cascading is one of the central mechanisms in the SMT2020 semiconductor dataset, which carries it as STNCAP on the tool and an interval on the route step: BatchInterval when whole lots cascade, PartInterval when wafers do. In that dataset the intervals run at 70–90% of the process time, so the interval is what binds on nearly every cascading tool group — the capacity almost never gets to be the limit.

Getting this wrong is expensive, and in both directions:

• Ignoring it makes a tool group look far busier than it is. One tool group in that dataset, from its route data alone, must be 79.62% busy without cascading and 67.67% with it. The published reference run reports it processing 68.79% of the time.
• A second slot with no interval hands out free capacity: one area of the plant read 46% busy against a true 72%.
• Wafers cascade too. Twenty-three tool groups declare STNCAP and no lot interval, and every step of theirs gives the time between consecutive wafers instead. A lot of 25 then holds the machine's entry for 25 of those intervals and the next lot follows it in. That is a second slot and the step's piece_interval_seconds, which scales with each lot's own pieces. Built as one slot instead, lots ran strictly one after another, and one configuration's mean cycle time came out 47.85 days where the cascade gives 43.46, measured at the commit that built it (the published reference: 39.71).

The rule is the one stated above: the step decides, not the machine. A machine that could hold two jobs still only holds two when something says how the second one gets in.

How to tell whether your machine cascades

Ask the person who runs it one question: can you start the next one before this one comes out?

• "No, it has to finish first" → one job at a time. Leave capacity alone.
• "Yes, every few minutes" → cascading. That "few minutes" is start_interval_seconds, and how many fit inside is capacity.
• "Yes, as many as fit, whenever" → that is not one machine, it is several. Use servers.

Related

• Resources — servers against capacity
• Products and steps — where start_interval_seconds lives
• Batching — a different idea: jobs that run together as one load, rather than overlapping