Downtime

Any unfamiliar word is in the glossary.

Two different things take a server out of service, and they are modelled separately because they behave differently.

breakdown	unplanned. A failure clock runs, the server dies, a repair takes it back
maintenance	planned. Triggered by elapsed time or by units processed

id: mill
servers: 2
downtime:
  breakdown:
    mttf_seconds: { kind: exponential, mean: 86400.0 }
    mttr_seconds: { kind: exponential, mean: 3600.0 }
  maintenance:
    - name: weekly
      trigger: { kind: calendar, every_seconds: 604800.0 }
      duration_seconds: { kind: constant, value: 7200 }
      first_at_seconds: 604800.0

The block

key	type	required	what it means
breakdown	breakdown	no	Unplanned failure. Omit if the resource does not break down.
maintenance	array of maintenance	no	Planned service policies. Several may run on one resource, and each keeps its own counter.
repair_operator	string	no	A pool a person must come out of before a breakdown can be repaired. ⚠️ It sits beside breakdown rather than inside it. Same ordering rule as a maintenance policy's operator: acquired before the tool stops, because taking the tool down and then queueing for a technician is the one ordering that can deadlock against a lot already holding one.
on_collision	collision	no	What to do when two downtimes collide on one server. See the collision table.

Breakdowns

key	type	required	what it means
mttf_seconds	dist	yes	Mean time to failure, measured on whichever clock clock names below.
mttr_seconds	dist	yes	Mean time to repair: how long the resource is out once it has failed.
clock	failureclock	no	Which clock mttf_seconds is measured on. Defaults to calendar.

Which clock runs

value	means
"calendar"	The clock runs whether or not the tool is working. ⭐ The default, and what SMT2020 specifies. Every model written before this field existed means this, so the default is not a preference — it is the only value that leaves those models saying what they said.
"operation_dependent"	The clock runs only while the tool is utilised — setup, load, process and unload, the same set the Setup, Load, Processing and Unload states cover. ⚠️ A tool that is idle, blocked, waiting for a person or already down is not wearing. That means a repair does not itself bring the next failure closer, which is exactly what distinguishes this model from the calendar one.

These two answers differ by up to 39%

Same MTBF, same MTTR, same load — the only difference is whether the failure clock runs while the server is idle. A tool that can also fail while idle has strictly less capacity. If your dataset does not say which it means, that is a question to answer, not a default to accept.

Maintenance

key	type	required	what it means
name	string	yes	A label for this policy, so several on one resource can be told apart in results.
trigger	trigger	yes	What counts towards the next service: elapsed time, or units processed. ⚠️ Tagged on kind, and the tag is required — see below.
duration_seconds	dist	yes	How long the service itself takes.
operator	string	no	A pool a person must come out of before the tool can be taken down. ⚠️ Acquired BEFORE the tool stops. Stopping the tool and then queueing for a technician is the one ordering that can deadlock against a lot holding an operator — see clockwright_model::labour.
first_at_seconds	number	yes	For a calendar policy, when the last server of the group has its first occurrence. ⚠️ Occurrences are staggered evenly across the group: with four tools and first_at_seconds of 80 days, first maintenance falls on days 20, 40, 60 and 80. Without it every tool in a group goes down together, which wrecks WIP dynamics while still looking like a plausible model. Not read for a usage policy, which staggers by first_at_units.
drain_first	boolean	no	Wait for the station to empty before going down — see below. Default false: the tool stops at once and the lot inside is held through the maintenance.

Draining the station first

By default a maintenance that comes due stops the tool at once, and a lot in process is held inside it for the whole service and resumed afterwards — exactly what a breakdown does. Planned work is usually arranged the other way round: the tool finishes what it holds and then goes down. drain_first: true says so. From the moment the occurrence is due the station takes no new work, and the maintenance starts when the last lot leaves, after its unload.

maintenance:
  - name: weekly
    trigger: { kind: calendar, every_seconds: 604800.0 }
    duration_seconds: { kind: constant, value: 21600.0 }
    first_at_seconds: 604800.0
    drain_first: true

A calendar policy keeps its grid — the next occurrence is due one period after this one came due, not after it started — and a usage policy that trips at the end of processing waits for the unload. ⚠️ It does not make the tool more available: a station that drains is lost to new work either way. What changes is where the lot waits — in the queue rather than inside a stopped tool — and that a lot in process is never interrupted by planned work.

trigger

⚠️ An object tagged on kind, not a bare value. Each kind carries its own parameter:

kind: calendar
every_seconds: 604800.0

kind: usage
every_units: 80.0
first_at_units: 75.2

kind	parameter	means
"calendar"	every_seconds	Every that much wall-clock time, whether or not the tool worked.
"usage"	every_units, optional first_at_units, optional counts	After that much work, counted per individual server. first_at_units staggers the group's first occurrences evenly up to it, as first_at_seconds does for a calendar policy. counts is "entities" (the default: one unit per completed entity) or "pieces" (the pieces each completed entity carries). Use "pieces" when the maintenance interval is in wafers and lots differ in size.

Tools that share work evenly wear in lockstep

Per-server counters do not stagger themselves: identical tools taking turns reach every_units together, and the group goes down at once. On SMT2020's high-volume configuration, with the work shared evenly, leaving the declared stagger out reads 48.8 days of mean cycle time against 40.3 with it (four replications). Give first_at_units whenever a group has more than one tool.

Several policies on one resource each keep their own counter

Weekly, monthly and quarterly services on the same tool are three policies, and each counts independently. A shared counter means only the fastest one ever fires.

When two collide

value	means
"queue"	The second waits and runs after the first, so total time is the sum. ⭐ The default, and the one that reproduces the published PM%.
"overlap"	Both run at once; the first to finish returns the server to service. ⚠️ Kept only so the measurement can be repeated. It loses the longer downtime, and on SMT2020 that is a fifth of all maintenance.

overlap loses maintenance, and it is the flattering direction

On SMT2020, overlap delivers 0.799 of the maintenance the policies ask for against queue's 1.001 — a fifth of the plant's downtime silently not taken, which makes the plant look more productive than it is. queue is the default for that reason.

Types used above

breakdown

Unplanned failure.

mttf_seconds: { kind: exponential, mean: 86400.0 }
mttr_seconds: { kind: erlang, k: 2, mean: 3600.0 }
clock: calendar

mttf_seconds is mean time to failure — the working time between a repair finishing and the next failure. It is not MTBF, which includes the repair.

clock

Whether the failure clock runs while the machine is idle. Two values, and they are not close to equivalent:

value	meaning
"calendar"	the clock always runs — a machine can fail overnight
"operation_dependent"	the clock runs only while working — failures come from use

danger

This is the single most consequential one-word choice on this page. Same failure rate, same repair time, same load: the two readings differ by up to 39% in the resulting queue. Calendar is strictly worse for the plant, because a machine that can also fail while idle has less usable capacity.

The default is "calendar". If your data does not say which it means, that is a question to ask rather than a default to accept.

collision

What happens when two downtimes land on the same machine at once.

value	meaning
"queue"	run them back to back — the second starts when the first ends
"overlap"	they share the time — the machine returns when the last one ends

warning

This is not a detail. Getting it wrong shifts total downtime by exactly the overlap, and both readings produce a plant that runs and reports plausible numbers.