Skip to content

Production Planning & Control

Simulatte's production planning layer models a job-shop manufacturing system: jobs arrive stochastically, wait in a pre-shop pool until a release policy admits them, then flow through a sequence of servers whose queues are re-ordered by a dispatching rule before every scheduling decision. This separation between arrival, release, and dispatching lets you benchmark different WIP-control and priority strategies on the same simulated shopfloor.

Core concepts

Jobs & routing

A ProductionJob is the fundamental unit of work. Each job carries a server sequence (its routing), a processing time per operation, and an absolute due date. Due dates are specified as simulation-clock time (env.now + offset at creation), not as relative offsets. The job records timestamps at each routing step for makespan and lateness analysis.

Servers & queues

A Server extends SimPy's PriorityResource. It can process one or more jobs concurrently (set by capacity) and tracks queue length and utilization rate. Queue sorting is dynamic: before every dispatch, Server.sort_queue re-evaluates the priority policy for every waiting job and re-orders the queue accordingly. You can visualise queue and utilisation history with plot_qt() and plot_ut() if collect_time_series=True is set at construction.

Pre-shop pool & release control

The PreShopPool is a pure buffer queue — it holds jobs that have arrived but have not yet been admitted to the shopfloor. Available policies include workload-based rules (LumsCor, SLAR, SlarLimit), non-hierarchical WIP control (DRACO, using wip_target and loop_target), a constant-WIP cap (ConWIP), and workload-controlled continuous release (ContinuousRelease). Policy classes and builders wire their own callbacks and trigger processes during construction; the lower-level trigger functions remain available for custom compositions. See the Release Policies API for the full reference.

Dispatching

Once a job is on the shopfloor and waiting at a server, a dispatching rule determines its priority relative to other waiting jobs. Rules range from stateless (SPT — shortest processing time, EDD — earliest due date, FCFS — first come first served) to parameterised (ATC — apparent tardiness cost, slack-based rules) to system-state rules (Focus, which uses real-time shopfloor data). A priority policy is a plain callable (job, server) -> float that you pass at construction — no subclassing required. See the Dispatching Rules API for the full catalogue.

WIP & metrics

The ShopFloor uses a pluggable WIPStrategy and its EMA collector exposes ema_makespan, ema_tardy_jobs, ema_early_jobs, ema_in_window_jobs, ema_time_in_psp, ema_time_in_shopfloor, and ema_total_queue_time. Time-series collectors provide throughput and WIP histories.

Where to go next

  • Tutorials: copy/paste-friendly walkthroughs covering the core building blocks, release control, dispatching, and multi-run experiments.
  • Examples: runnable end-to-end scripts for Draco release and Focus dispatching.
  • Core API: full reference for ShopFloor, Server, ProductionJob, PreShopPool, Router, and Runner.