What Is Global Instance Assignment in Scheduling?

Global instance assignment is the rule that once a job has claimed a particular machine instance inside a work center, every later shift of that same job on that same work center is placed on the same instance, for the length of one scheduling run. It trades a small amount of load balance for setup continuity: a two-day milling operation stays on the mill it started on rather than hopping between two physically identical mills and paying a changeover for the privilege. EDGEBIC by User Solutions makes the pairing once, the first time a job needs capacity on that work center, and then reuses it.

How it works

A work center with more than one machine instance has to answer a question every time it books hours: which instance? On the first booking for a given job, the engine picks one, normally the least loaded instance available at that moment. It then remembers the pairing of job and work center to instance for the rest of the run.

Every subsequent booking for that job on that work center reads the remembered pairing instead of choosing again. If the operation needs twelve hours and the shift only offers eight, the four hours that spill into the next day go to the same instance. If a queue time or a predecessor delay pushes part of the work into next week, that part still lands on the same instance.

Two consequences follow, and both are visible.

The first is intentional. Setup, fixtures, tooling, and machine programs stay where they are. A job that occupies one mill for three days is set up once. Splitting the same job across two mills day by day would mean a fresh setup on each machine each time the work moved, which is real lost capacity in exchange for a tidier looking chart.

The second is the cost. Because the pairing is not revisited, a job can pass over an instance that has since become free. Later in the run, the remembered instance may be the busier of the two, and the operation stretches further into the future than the raw available hours suggest. The engine does not reassign to fix this, and it does not reassign if the remembered instance later becomes unavailable either. The pairing holds for the run.

The scope matters: the pairing lives for one run only. It is not a durable property of the job. A later scheduling run rebuilds every assignment from the current load picture, so the same job can land on a different instance than it did last time. Recorded work is the exception, because completed and in-progress operations are never moved at all, so an operation that physically ran on a given machine keeps it.

A concrete example

A work center runs three identical machines on a single eight hour Day Shift, so 24 hours a day of total capacity. A job needs 20 hours of that work center and is the second job scheduled that week.

At the moment the job first claims capacity on Monday, instance one already carries a full eight hours from an earlier job, instance two has two hours, and instance three has none. The engine assigns the job to the least loaded available instance and remembers it.

On Tuesday and Wednesday all three machines are idle. A pure load-balancing view would spread the remaining twelve hours across all three and finish the operation on Tuesday afternoon. Global instance assignment keeps it on instance three, so the operation finishes Wednesday at noon and the chart shows two machines apparently doing nothing.

Whether that is right depends on the setup. If the changeover on this work center is thirty minutes, splitting across three machines would have cost an extra hour of setup to save half a day, which may well be worth it. If the changeover is four hours, splitting would have cost twelve hours of setup to save half a day, which clearly is not. The assignment rule takes the conservative side of that trade by default, and the work center's own allocation behavior is where the trade is actually configured.

How EDGEBIC uses it

Instance assignment sits inside the allocation step, after the engine has found which shift slots have room and before the hours are written. The unit it hands out is explained in what is a machine instance in scheduling, and the arithmetic of what one instance can supply in a day is covered in per instance capacity in scheduling.

The rule interacts with the work center's own allocation behavior. A work center configured to dedicate a machine to one job for a whole day follows the one per day rule in scheduling, which is a stronger form of the same idea: not merely the same machine for one job, but no other job on that machine that day. The reason continuity is worth paying for at all comes down to setup time, the hours a machine spends being made ready rather than producing.

Because the pairing is rebuilt each run, the practical habit is the same one that governs every capacity change: make the change, then run the scheduler again. A plan on screen reflects the assignments made when that run happened.

The takeaway

Global instance assignment is a small rule with a visible signature: one job, one machine, for as long as that job needs that work center inside a run. It looks like a load-balancing failure and is actually a setup decision, and knowing which it is stops a planner chasing a problem that does not exist. When the trade genuinely runs the wrong way for your changeovers, the answer is the work center's allocation behavior rather than the assignment rule. For the surrounding mechanics see what is per instance capacity in scheduling and what is an instance collision, then explore EDGEBIC or, if you are moving from the legacy product, RMDB to EDGEBIC.