SolverForge
Search docs Ctrl K

Industrial heat treatment

155 heat-treatment orders. 11 furnaces. 39 operators. One coupled plan.

Heat-treatment planning couples machine capacity, thermal sequencing, batch placement, task operators, monitoring load, and the shift roster into a single model, so a furnace plan that ignores operator coverage cannot look legal.

155 Work orders
11 Furnaces
39 Operators
30 Constraints
22 / 8 Hard / soft split
7 Days

The answer is only valid if furnace assignment, time placement, task operators, monitoring capacity, and roster coverage all hold together. Staging those decisions can produce schedules that look legal in one layer and fail in another.

The app keeps the furnace timeline, the operator roster, the order table, score analysis, the retained job, and the REST surface inspectable from one operating artifact.

Batch assignment Every work order is scheduled, and only on a compatible furnace.
Furnace feasibility Process, temperature ceiling, and load capacity all have to hold.
Sequencing Batches cannot overlap and must respect the thermal changeover gap.
Task operators Load build, program, quench, and unload tasks need a skilled operator on the owning shift.
Coverage and monitoring Role coverage and 15-minute monitoring capacity are solved with the same plan.
Soft tradeoffs Priority-weighted lateness, thermal changeover, early starts, night starts, overtime, and load balance.
Runtime walkthrough Watch the furnace lanes fill under a live hard score, then read the roster, the order table, and the constraint ledger behind it. Narrated walkthrough (2:41): the unassigned baseline, the solve in progress, the finished furnace schedule, the operator roster, the order table, score analysis, and the REST surface.
Unassigned baseline The baseline opens with every order unassigned, so the starting point is explicit rather than hidden behind a spinner.
  1. The status bar starts Ready with the score empty and all 30 constraint dots present.
  2. Eleven furnace lanes wait for the solve; 155 orders are still unassigned.
Mid-solve Caught mid-solve, the same surface shows hard score improving while blocks land in lanes, so the search is observable rather than opaque.
  1. Hard score is still counting down while the search is live.
  2. Order blocks appear in the lanes as construction and local search place them.
Furnace schedule The finished plan places all 155 orders across eleven furnace lanes with the retained job completed at zero hard.
  1. Lane headers keep furnace type, maximum temperature, order count, and load capacity.
  2. Each block carries its work-order code, customer, and process in the lane.
Operator roster The roster is part of the same model: role, availability, planned shifts, and skill masks all constrain which operator can own a task.
  1. Operators carry role, availability, planned shifts, and their skill mask.
  2. Every manual task must land on an operator rostered on the owning shift.
Order placement The order table answers the operational question directly: which furnace runs this order, when it starts and ends, and whether it is late.
  1. Assigned furnace and scheduled window are readable per work order.
  2. Delay per order exposes whether priority-weighted lateness reached the plan.
Score analysis Score analysis makes the model auditable: 22 hard feasibility rules and 8 soft operating tradeoffs, each with its own score and match count.
  1. Hard feasibility and soft operating pressure stay separated by type.
  2. Every constraint reports its score and match count for review.
REST API The REST guide exposes the same retained workflow the browser uses, with copyable curl examples for every endpoint.
  1. Every endpoint ships a copyable curl example.
  2. Retained-job endpoints cover create, status, snapshot, analysis, and events.