What Is a Common Shift Requirement in Parallel Scheduling?

A common shift requirement is the rule that every machine in a parallel group must share at least one shift on the candidate day, because a parallel operation runs on all of them at once and the scheduler can only place it in a window they are all open. The subtlety that catches people is that the shared window is found by intersecting shift records, not by comparing the hours inside them. Two day shifts with identical times but separate records share nothing. EDGEBIC by User Solutions computes the intersection on every candidate date before it looks for capacity.

How it works

A parallel step is one operation carried out by several machines together. Whether the partners are mirrored so they start and finish in lockstep, or run independently on their own portions of the work at the same time, the scheduler still has to find a single window in which all of them are open. That window is called a simultaneous slot.

Finding it happens in two moves, in this order.

First, intersect the calendars. The engine walks candidate dates forward from the operation's earliest allowed start. On each date it collects the shifts attached to the first machine, then keeps only those shifts that are also attached to every other machine in the group and that operate on that day of the week. Whatever survives is the set of shifts common to the whole group on that date.

Second, check capacity. Only for a surviving common shift does the engine ask whether every machine actually has room, whether they can all start at the same moment, whether enough instances are free, and whether each has continuous availability for the duration. If any machine fails, that shift is discarded and the next one is tried.

The order is the important part. If the first move returns nothing, the second never runs. A parallel step whose machines share no shift will search date after date and find no window, no matter how much idle capacity every machine has. The failure is not a capacity failure at all; it is an empty intersection.

And the intersection is strict about identity. It matches shifts by which record they are, not by what times they contain. A plant that created a day shift once and attached it to every machine will intersect cleanly. A plant that created a separate day shift row for each department, all running 08:00 to 16:00, will intersect to nothing across departments, because those are different records that merely look alike.

A concrete example

An assembly operation is configured to run on two machines together. Both physically work the standard day, Monday to Friday, 08:00 to 16:00. Both are completely idle next week.

Every visible attribute matches. The hours are identical, the days are identical, both machines are free. And the operation will never schedule as parallel, because the intersection of one record and a different record is empty. The engine walks Monday, then Tuesday, then onward, finding no common shift each day, and the step fails to place.

The fix is one change and it is in the work center editor, not on the routing: delete or stop using one of the duplicate shift records and attach the surviving record to both machines. On the next scheduling run the intersection returns that single shift on every weekday, the capacity checks run for the first time, both machines are open and idle, and the operation places on Monday at 08:00.

Compare that with a genuine constraint. If Assembly-A were attached to a day shift and Assembly-B only to a night shift, the intersection would also be empty, but no amount of consolidation would help. The two machines are never open together, so one operation cannot run on both at once. That is a real-world limit surfacing correctly, and the answer is to change the shifts or to change the routing, not to hunt for a setting.

How EDGEBIC uses it

The requirement applies to steps configured to run on more than one machine at once. The two flavors, mirrored partners and simultaneous independent portions, are covered in what is dependent parallel processing and what is independent parallel processing, and the setting that distinguishes them is described in what is a parallel work center type.

The thing being intersected is the association between a machine and a shift, which is defined in what is a work center shift. Once a common shift survives, the capacity bucket the engine then tests is the one described in what is a shift resource allocation in scheduling.

The requirement does not apply to a fallback machine, because a fallback runs the operation instead of the primary rather than alongside it. That distinction is drawn in what is a true alternate work center, and it is worth checking when a step will not place: a machine you meant as a fallback but configured as a partner inherits the intersection requirement it does not need.

The practical habit is to keep one shift record per real working pattern and attach it widely, rather than creating a copy per department or per machine. Duplicate lookalike shift records cost nothing until the day someone configures a parallel step across them.

The takeaway

A common shift requirement sounds like a capacity rule and behaves like an identity rule. Machines that work the same hours on different shift records share no window, and a parallel step across them will search forever and find nothing while every machine sits idle. The moment when every machine in the group can genuinely start together is a simultaneous capacity slot, and it is all or nothing. One shift record per working pattern, attached to every machine that follows it, removes the whole class of problem. For the neighboring concepts see what is a parallel work center type and what is a work center shift, then explore EDGEBIC or, if you are coming from the legacy product, RMDB to EDGEBIC.