How Multi-Shift Allocation Fills Capacity

Multi-shift allocation is how EDGEBIC by User Solutions places a single operation's hours onto real machine time when that operation is too big for one shift. The engine pre-computes a capacity bucket for every work center, date, and shift, walks the calendar forward from the operation's earliest start, and consumes the best available slots in order until every hour has a home. It is the mechanism that makes finite capacity actually finite: no shift is ever booked past what it can hold, and a job that needs 28 hours lands on real shifts, real machines, and real days.

A run time in a routing is just a number of hours. Turning that number into "starts Tuesday 10:00 on Mill-2, finishes Wednesday afternoon" is the allocator's job, and understanding how it works explains most of the "why did that land there?" questions a schedule raises.

What a shift slot is worth

Before scheduling any job, EDGEBIC builds a bucket for every combination of work center, date, and shift the calendar says is active. Each bucket holds a total capacity and tracks how much has been consumed. The total comes from one formula:

capacity = (shift hours - downtime - partial holiday hours)
           x number of instances
           x utilization %

A milling center with two machine instances on an 8-hour shift running at 80 percent utilization offers 12.8 hours in that bucket. A whole-day holiday zeroes it. A capacity override for one specific date replaces the formula entirely, which is how you model an authorized Saturday of overtime without touching the standing calendar. This is the same capacity resolution that drives holidays and downtime, so the number the allocator sees always matches the number your capacity dashboards show.

The bucket is the unit of finite capacity. Once an operation consumes hours from it, no other job can claim those same hours. That single rule is what separates a real schedule from a wish list.

The search: walking the calendar for real hours

Once an operation knows its earliest start (usually the end of the step before it), the allocator walks forward day by day. For each day it asks three things: is the work center available at all, which shifts run on this weekday, and how much unconsumed capacity remains in each slot. The candidate slots it finds are then ranked by a priority score that encodes sensible instincts:

• A shift that can start immediately outranks everything else.
• More available capacity outranks less.
• An earlier shift in the day outranks a later one.

The engine then consumes the ranked slots in order until the operation's hours run out. A 12-hour operation on a single-instance machine with one 8-hour shift takes 8 hours Monday and 4 hours Tuesday, finishing Tuesday at noon. A late constraint clips the first slot: a job that cannot start before 10:00 gets only the 6 remaining hours of an 08:00 to 16:00 shift on day one. Not every operation may be split this way, and the rules that force one to land whole are covered in when an operation must fit inside one shift.

Weekends and holidays cost zero machine hours but consume real elapsed time. A 20-hour job that starts Friday at noon uses 4 hours Friday, jumps the weekend, resumes Monday, and finishes Tuesday afternoon. That is why a job's span in calendar days is often longer than its hour count implies, and it is correct behavior, not a bug.

Three ways to split the work across instances

When a work center has more than one machine instance, EDGEBIC chooses among three allocation strategies:

Load balancing is the one that surprises people. A 20-hour operation on a four-instance work center finishes in about 5 elapsed hours because each machine runs 5 hours at the same time. The engine is not stretching one machine across a long span; it is running four in parallel and finishing together. One-per-day is the opposite instinct, used where you deliberately dedicate a machine to a single job for the day (a heat-treat furnace changeover, for instance), so the allocator assigns each instance one job and holds it across the shifts it needs.

A worked example: 28 hours, two machines, two shifts

Take a CNC center with two instances, a day shift (08:00 to 16:00) and a night shift (16:00 to midnight), each giving 16 hours of total capacity. An operation needs 28 hours and cannot start before Monday 10:00.

Monday day shift. The 10:00 constraint clips it: from 10:00 to 16:00 is 6 hours per instance, so 12 hours of capacity are available. Load balancing places 6 hours on each machine, both running 10:00 to 16:00. Placed: 12 hours. Remaining: 16.

Monday night shift. Full 16 hours available, both instances 16:00 to midnight, 8 hours each. The operation needs exactly 16, so it completes at midnight Monday.

The operation started Monday 10:00 and finished at the end of Monday's night shift, a single calendar day pair, and the job row shows a "12,16" hour display: 12 hours on the day shift, 16 on the night shift. Every date in that trace came from a rule already stated: capacity per shift from the formula, the 10:00 clip on the first slot, and load balancing splitting each shift so both machines finish together.

Why the order never changes between runs

None of this involves random tie-breaking. Within a step's search the ranking is deterministic; across jobs the sort order is priority, then start date, then due date. So the same inputs produce the same schedule every time, and a difference between two runs always traces to a difference in the data between them. That reproducibility is what lets a planner audit a placement: pick any bar, and the reason it landed there is recoverable by walking the same rules the engine walked.

Multi-shift allocation is one layer of a larger pipeline. The complete scheduling engine guide places it in context alongside dependency ordering and the timing mechanisms between steps, and the multi-shift explainer walks the same machinery from the product side. If the finite-versus-infinite distinction is the piece that is new, finite versus infinite capacity scheduling covers why respecting the bucket matters at all. Setup time is part of what fills these buckets too: a sequence-dependent changeover is added to the operation's hours before the search runs, so a longer changeover simply consumes more of the slot.

To watch the allocator place your own routings against your own shifts, bring your data to a demo and see where your real constraint surfaces in the first run.