Maintenance Schedule¶

Scheduled process — instantiates Repairability and Maintainability Design

Turns "it will need service someday" into named tasks fired at set times, usage counts, or measured conditions, so upkeep happens before failure does.

A Maintenance Schedule converts an open-ended intuition — "this will need care eventually" — into a concrete calendar of named tasks, each fired by an explicit trigger: a date, a usage count, or a measured condition. Its whole job is the timing question. It does not tell you what is wrong, how to fix it, or where the parts are; it decides when each recurring care task comes due and what recurring need — wear, fouling, drift, calibration, a lapsing dependency — that task exists to serve. That is what separates it from the diagnostic and repair mechanisms around it: they act once something breaks; the schedule's entire point is to act before it does.

Example¶

A facilities team inherits a twelve-story office building whose previous operator ran everything to failure. Rather than wait for tenant complaints, they build a maintenance schedule keyed to three trigger types: air-handler filters swapped every three months (time-based), drive belts inspected every ≈2,000 run-hours (usage-based), and condenser coils cleaned whenever a pressure-differential sensor crosses a set threshold (condition-based). Each line names the need it guards: fouling, wear, heat-transfer loss.

The payoff shows up in June. A fan belt that — on the old reactive regime — would have snapped in August under peak cooling load is instead caught fraying at a scheduled inspection and replaced during a low-occupancy weekend. The failure never reaches a tenant. The schedule didn't diagnose the belt or stock the spare; it simply guaranteed someone looked while there was still slack between the first sign of wear and the actual break.

How it works¶

What distinguishes a schedule from a mere to-do list is that every task carries a trigger basis and is bound to a specific need:

Time-based triggers fire on the calendar (quarterly, annually) — cheap and predictable, but blind to how hard the asset was actually used.
Usage-based triggers fire on a counter (run-hours, cycles, mileage) — they track real wear but need the counter to exist.
Condition-based triggers fire on a measured signal crossing a threshold — the most efficient, but only as good as the instrumentation behind it.

The schedule is a living document: intervals are set from expected degradation, then tightened or relaxed as real outcomes come in. It is the cadence, not the cure.

Tuning parameters¶

Trigger basis — time vs. usage vs. condition. Condition-based servicing catches actual degradation and avoids needless work, but requires sensors and a degradation signal; time-based is trivial to run but services things that weren't wearing.
Interval length — shorter intervals shrink the risk of failure-between-visits but raise cost and downtime. The gap between first detectable sign and functional failure sets the outer bound on how long an interval can safely be.^[1]
Coverage threshold — which needs get scheduled care versus which are deliberately run to failure. Not everything earns a slot; cheap, non-critical, hard-to-predict parts are often better left reactive.
Deferral tolerance — how much a task can slip past due before it escalates. Loose tolerance keeps the calendar realistic; tight tolerance protects safety-critical work.
Bundling — whether nearby tasks are grouped into one service visit (fewer trips, more downtime per visit) or kept separate.

When it helps, and when it misleads¶

Its strength is moving upkeep upstream of failure — converting reactive firefighting into planned work done in low-load windows, on the team's terms rather than the failure's.

It misleads in two classic ways. Over-maintenance services parts that weren't degrading and can introduce faults through unnecessary intervention — the intervention itself becomes a failure source. And a schedule silently drifts out of date: intervals set for the original asset and duty cycle are never revisited as usage, climate, or components change. The signature misuse is the schedule as a compliance checkbox — signed off as "done" without the work actually being performed. The discipline that guards against all three is to tie intervals to observed degradation (feeding real fault data back into the interval), and to verify that scheduled work was truly executed rather than merely logged.

How it implements the components¶

A Maintenance Schedule owns the timing corner of the archetype — not diagnosis, not the fix:

service_interval_model — the schedule is the interval model: it maps each recurring need to a trigger type and a cadence, and holds the logic that decides when care is due.
maintenance_need — every scheduled line names the specific recurring need (wear, fouling, drift, calibration, dependency refresh) it exists to serve, turning "general upkeep" into itemized, addressable demands.

It does not locate faults (diagnostic_access, degradation_and_fault_model — see Diagnostic Log and Software Observability), execute the repair route (repair_path, maintenance_owner — Field Service Protocol), or stock what a task consumes (spare_resource_plan — Spare Parts Inventory).

Instantiates: Repairability and Maintainability Design — the schedule supplies the when that keeps degradation from ever reaching failure.
Consumes: Diagnostic Log — recorded fault patterns are what let interval lengths be tuned toward real degradation rather than guesswork.
Sibling mechanisms: Diagnostic Log · Field Service Protocol · Configuration Changelog · Modular Parts · Repair Manual · Right-to-Repair Interface · Service Access Panel · Software Observability · Spare Parts Inventory · Troubleshooting Flowchart

Notes¶

A schedule is only real if the scheduled work can actually be performed. A calendar of tasks with no parts on hand, no access panel to open, and no one accountable to do it is theater — which is why the schedule depends on Spare Parts Inventory, Service Access Panel, and Field Service Protocol rather than standing alone.

References¶

[1] In reliability-centered maintenance this is the P–F interval — the window between the point a failure first becomes detectable (P) and the point of functional failure (F). An inspection interval longer than this window cannot reliably catch the fault in time, which is why the P–F interval, not convenience, should cap how far apart condition checks are spaced. ↩