Real-Time Schedule Reoptimization

A job-shop sequence is the ordered list of operations you will actually put on machines in the next window, not the weekly plan. Real-time reoptimization is the loop that rebuilds that list when a machine goes down, a kit is short, a hot order jumps the queue, or a setup family becomes available. The agent (a heuristic dispatcher, a constraint solver, or a reinforcement-learning policy) proposes a new sequence. You still release it.

That split matters. The solver does not own the floor. It does not start jobs, change work-center calendars, or tell operators to ignore a hold. It returns a candidate sequence with the assumptions it used: which resources were up, which materials were considered available, which orders were treated as firm. You compare that to what you can see at the board, then you release, hold, or throw the proposal away.

Treat the current released sequence as the only legal instruction until you replace it. A flashing “better makespan” is not a release. If two proposals arrive while you are walking a cell, keep the last released sequence in force. Queue the newer candidates; do not let them auto-apply.

The typical trigger set is small and operational: machine status change (down, starved, blocked, in setup, available), material or kit status change, order priority or due-date change, and a clock tick that says the last solve is older than the agreed replan interval. Do not reoptimize on every PLC heartbeat. Bound the event types and debounce them so a flickering status bit does not reshuffle the whole shop.

The agent should only consume three live classes of data: machine status from MES, material availability from MES or warehouse execution, and order priority from the planning system you treat as the source of truth for the floor (often APS or ERP, not a chat thread). Everything else is context, not a reason to reshuffle.

Machine status must be current per work center, not “plant average.” You need state, timestamp, and the last good heartbeat. A work center with no heartbeat inside the SLA is stale, even if the last known state was RUN. Stale is not the same as down. Down is a known constraint. Stale is missing evidence. The rule for stale MES machine status is empty or hold: do not emit a new sequence for that resource, and do not silently reuse yesterday’s state as if it were live.

Material availability is kit completeness, lot quality hold, and inbound dock confirmations that actually put parts at the point of use. A purchase-order promise is not availability. If the kit is short, the agent should not sequence the operation as if the kit will appear because the MRP date looks close. If warehouse status is stale the same way MES is stale, treat the affected jobs as blocked or unsequenced rather than guessing.

Order priority is the ranked list you already agreed with planning: firm orders, freeze fence, expedites, and customer-commit dates. Real-time reoptimization is not a back door to change the master production schedule. If a salesperson wants a new hot job in this shift, that is a priority change with an owner, not an agent invention. Record who changed the rank and at what time so you can explain why a job jumped.

If any of those three feeds is incomplete for a cell, keep the last released sequence for that cell and mark the proposal as not releasable. Partial data is worse than no solve: the agent will fill gaps with defaults that look precise on a Gantt and are wrong at the spindle.

Most plants will not train a reinforcement-learning policy on day one. They start with dispatching rules and a finite-capacity APS engine, then add learning only where the rule set keeps losing on the same disruption pattern. PlanetTogether, Siemens Opcenter APS, and Kinaxis all sit in that APS and control-tower layer: they can resequence against constraints, calendars, and material pegging. The shop-floor job is the same regardless of brand. You feed them a current resource model, you get a candidate sequence, and you decide whether it is legal to run.

A usable candidate is more than a sorted job list. It should name, for each operation: work center, planned start and finish in the current shift window, predecessor completion assumption, required kit or lot, setup family, and the reason it moved relative to the last released sequence. If the solver cannot explain the move in one line (machine down, kit late, higher-priority order, setup combine), treat the move as suspicious and review it before release.

Keep the solve horizon short. Reoptimization for make-stage speed is about the next few hours to the end of the shift, not the next six weeks. Long horizons belong with Constraint-Aware MPS Generation. Mixing those horizons in one click is how you get a “real-time” run that quietly restaffs next Tuesday while you were only trying to recover a paint line.

Watch for oscillation. If the agent keeps swapping two jobs every time a status bit flips, freeze the pair, widen the debounce, or add a switching cost so a sequence change must buy back more than the setup and walk time it will burn. Speed on the floor is lost as often to thrash as to a slow solver.

Reinforcement learning, if you use it, should be constrained by the same hard rules the heuristic already obeys: no start without kit, no double-booking a unique tool, no ignoring a quality hold, no jumping a freeze-fence order without an explicit priority change. Learning can pick among feasible sequences. It should not invent feasibility.

You release a sequence. The agent does not. Release means the sequence becomes the instruction set for supervisors, operators, and any MES dispatch queue you use. Until you release, the candidate is a proposal sitting next to the current legal sequence.

Use three outcomes, and make them visible on the same screen:

Released: you accepted the candidate (or a manual edit of it). MES dispatch and the board show this list. Timestamp and your user id go on the record.

Hold: you keep the last released sequence. The candidate may still be visible for comparison. Typical reasons: you are mid-setup, a quality call is open, staffing does not match the new mix, or you do not trust a priority change yet.

Empty: you publish no new sequence for the affected resources. Empty is the correct response when MES machine status is stale. Do not leave a pretty Gantt hanging that implies those machines are still in the last known state. Operators should see that the cell has no new dispatch from the optimizer until status is fresh.

Define stale in minutes, per line, not as a feeling. Example policy shape (set the numbers with maintenance and IT, not here as universal truth): if the work-center heartbeat is older than the agreed threshold, mark the center stale, set the optimizer output for that center to empty or hold, and page the MES owner. When status returns, run one bounded reoptimize; do not dump a backlog of ten queued solves at once.

Do not auto-release after a timeout. A timeout with no human is how a night-shift sequence based on a frozen status bit runs until morning. If you need unattended behavior on a lights-out cell, that is a separate, written exception with a smaller machine set and a hard stale-to-stop rule, not the default for a manned job shop.

After release, freeze a short execution fence (often the jobs already at the machine or in setup) so the next event does not yank work that is physically in process. Reoptimization should steal from the queue, not from the spindle, unless you have an explicit abort procedure.

Skip the solve, or throw the result away, when the disruption is not a sequencing problem. If the bottleneck is a chronic capacity gap, reshuffling jobs will not create hours. Send that to Capacity Bottleneck Identification instead of burning the shift on Gantt art.

Skip when the likely recovery is maintenance, not dispatch. A repeating micro-stop on one asset is a reliability problem. Pair the status stream with Predictive Maintenance on Production Assets so you are not “optimizing” around a failure you should have planned a window for.