How Planned Downtime Modeling Keeps the Schedule Honest

Planned downtime is capacity that does not exist, and a schedule is only honest when it can see that. EDGEBIC by User Solutions models preventive maintenance, holidays, and shift gaps as a reduction in available hours, so a job is never placed on time the machine was never going to work. The result is a plan the maintenance manager and the planner both recognize as true.

This post explains how downtime enters the capacity math, how it differs from handling a breakdown, and what the software still leaves to your judgment. For the underlying idea of respecting real limits, see finite versus infinite capacity scheduling. This post sits under the EDGEBIC results guide.

Where the Lost Hours Come From

Every plant loses planned hours in three ordinary ways, and a schedule that ignores any of them promises time it does not have:

1. Preventive maintenance. The weekly lube, the quarterly bearing swap, the calibration that has to happen before first run.
2. Calendar closures. Plant holidays, a line-specific shutdown for a deep clean, a training afternoon that takes one department off the floor.
3. Shift shape. A machine that runs one shift while the plant runs two, or a Saturday that is scheduled for some work centers and not others.

None of these are failures. They are known, repeating, and easy to plan around, which is exactly why leaving them out of the plan is so wasteful. The hour was already committed to maintenance. The only question is whether the schedule knew.

How Downtime Enters the Capacity Math

EDGEBIC computes available hours for each work center, each shift, each day before it places any job. Downtime is subtracted early, at the point where it physically removes time, and the documented formula makes the order of operations plain:

Available hours = (base shift hours minus holiday hours minus downtime hours) multiplied by utilization, multiplied by the number of machines, minus hours already allocated.

Work through the documented example. A work center runs a 7-hour shift on this day, and an hour of it goes to scheduled maintenance. The center is set to 80 percent utilization and has 3 identical machines:

The engine offers 14.4 hours that day. If the maintenance hour were left out, it would offer 16.8, and every schedule built on that number would be short by the difference times three machines. The subtraction happens before utilization and the machine count multiply, so a single lost hour scales exactly the way it does on the floor: one hour off the top of each of three machines is three hours of real capacity, not one.

A full-shift closure works the same way: set that day to zero for the line and its capacity for the day is zero, so nothing can be booked into it. The rest of the plant keeps its own calendars, because the reduction is entered per work center and per shift, not plant-wide by default.

Worth being concrete about where those numbers get typed, because the current release has no downtime screen. There is no downtime record to create and no weekly recurrence anywhere in the calendar. A standing loss belongs in the machine's shift hours, where it never needs maintaining; a dated one belongs in a per-day capacity override on that work center, shift, and date, which also captures a reason. Plant-wide interruptions are a partial plant holiday. Those three cover every case below.

Planned Downtime Versus a Breakdown

These are two different problems, and EDGEBIC treats them differently on purpose.

Planned downtime is known in advance, so it is modeled as a capacity reduction and no job is ever scheduled into it. The plan is correct the first time. Nothing has to be undone.

A breakdown is unplanned. It arrives after a good plan is already on the floor, and the fix is a targeted reschedule that moves only the jobs whose path runs through the down machine, leaving the rest of the plant alone. That is a repair, covered in how EDGEBIC protects delivery after a breakdown.

Modeling planned downtime is the cheaper of the two because prevention costs nothing to unwind. The maintenance you already know about should never become a reschedule you have to run.

The Anomaly Net Behind It

Because master data drifts (someone edits a shift, an override gets reset, a holiday moves), EDGEBIC does not rely on the capacity math alone. The anomaly report checks the published plan for jobs that landed inside a machine downtime window or on a holiday that should have reduced capacity. A booking that slips through the model still gets caught before it reaches the floor. See how the anomaly report keeps a bad schedule off the floor for the full set of checks.

This matters most for the maintenance calendar specifically, because it is the data most likely to be maintained by someone other than the planner. The check closes the gap between two people editing two things.

What Modeling Downtime Changes for the Planner

The visible change is small and the effect is large. Jobs stop being scheduled onto maintenance days, so the supervisor stops finding out at 7 a.m. that the machine printed on the traveler is in pieces. The promise date the customer received already accounted for the shutdown, so a known closure never becomes a late shipment. And the load view shows the real ceiling, which means the capacity visibility you use to make staffing and overtime calls is measuring the plant you actually have.

There is also a quieter benefit for trust. When the maintenance team sees their PM window respected in the schedule everyone follows, the schedule stops being the planner's document and becomes the plant's. That is the foundation the rest of the system is built on.

What the Software Still Cannot Do

It cannot know about maintenance you never entered. A downtime window that lives only in the maintenance lead's head is invisible to the engine. The model is only as complete as the calendar you give it.

It cannot decide your maintenance policy. Whether a PM runs weekly or monthly, on-shift or off, is an engineering and cost decision. The software places jobs around the windows you set; it does not set them.

It cannot protect a window it was told to ignore. If someone resets the override to fit an urgent job, the capacity comes back and the engine will use it. The anomaly report will flag the result, but the guardrail is only as strong as the discipline behind the data.

It cannot recover hours that are genuinely gone. Modeling downtime makes the plan honest. It does not make the machine run during maintenance. The gain is a schedule that matches reality, not more reality.

Want to see your own maintenance calendar respected in a live plan? Bring your PM schedule and shift calendars to a demo, and we will build a week that never books a job onto an hour the machine was never going to work.