Simulation Overview

​

Overview

Simulation in ProDex is discrete-event simulation, and it’s a set of connected artifacts rather than a single feature. You build a model of your process on the Modeler canvas, optionally drive it with a schedule of real production events, and execute it as a run. A run produces data you interpret through KPIs and charts. To compare scenarios, you run each variant as its own run and compare the runs. To quantify the variability inside a single scenario, you run it several times with different random seeds. This page is the map. Each artifact has its own page for the details, and Your First Simulation walks the whole loop once, hands-on.

​

The Building Blocks

​

Models

The model is the core artifact: the process graph plus the supporting data it references. It lives on the Modeler canvas, where you drag in sources, processes, buffers, combiners, separators, transformers, routers, and sinks and wire the flow between them. Stations aren’t flow nodes — they’re a grouping construct that wraps processes, combiners, separators, transformers, and routers into a physical space. Attached to the model are the entities that move through it, the resources (workers, machines, tooling) it consumes, and the constants and lookup tables that parameterize it, plus any nested sub-models (Model Nodes). The distributions its stochastic logic draws from live inline in component fields rather than as a separate artifact. A model is a living object: you edit it in place, revalidate, and re-run as your understanding of the process evolves. Validation catches structural problems before you run.

​

Schedules

A schedule is the operational layer on top of a model. Where the model describes how the process works, a schedule describes when specific things happen, anchored to real calendar time: material releases inject specific entities at specific times, and scheduled actions fire variable assignments or events at specific moments. A model can have many schedules — a baseline week, a high-demand scenario, a maintenance window — and you pick the active one in the schedule picker at the top of the Modeler. Swapping the schedule swaps the operational scenario without touching the model itself.

​

Runs

A run is one execution of one model against one schedule (or against the model’s plain duration when no schedule is active). It produces a complete record of what happened — entity lifecycles, process activity, resource activity — which the Results view reads. Runs are stored under their parent model, and each one traces back to the configuration it executed. After the simulation itself finishes, ProDex computes the run’s KPIs and charts in a second pass: a run shows as pending while that pass is working and ready once its numbers are populated.

​

KPIs and Charts

KPIs are single numbers: throughput, average WIP, utilization. Charts are visualizations: throughput over time, utilization by resource, a queue-length histogram. Both are authored on the model — describe what you want and Dexter writes the underlying query — so every subsequent run computes them automatically. They are the interpretation layer that turns a run’s raw data into an answer. See Results and Analytics.

​

Comparing Scenarios

A scenario is just a run. To compare a baseline against a change — extra capacity, an alternate schedule — run each variant: edit the model and run it again, switch the active schedule, or ask Dexter to copy the model and change the copy so the baseline stays intact. Then ask Dexter to compare the runs, and it lays their KPIs out side by side so you can see which option wins and by how much. See Comparing runs.

​

Replications

Replications answer a different question: not which option is better but how much does this option’s outcome vary from randomness alone? Ask Dexter to run a configuration with several random seeds, and it launches them as one batch of runs and compares the spread of each KPI across them. The configuration needs genuine stochastic content: a fully deterministic model produces identical replications with no spread to measure.

​

How the Pieces Fit Together

The typical arc:

1. Build the model on the canvas: wire the flow, define entities, set the distributions your timing and routing logic draw from, add constants, get validation green.
2. Attach a schedule if the scenario needs real operational timing; otherwise the model’s duration field is enough.
3. Run it. The simulation executes, then the results pass computes your KPIs and charts.
4. Analyze in Results: read the KPIs, inspect the charts and event log, iterate on the model, run again.
5. Compare scenarios. Run each candidate configuration and ask Dexter to compare the runs.
6. Quantify variability with replications before trusting a scenario with a real decision.

​

Limits and Caveats

• Editing a model doesn’t keep its previous version. Past runs still record what they executed, but to run the baseline again later, ask Dexter to copy the model before you change it. A copy shares its sub-models, entities, constants and lookup tables with the original, so changing those changes both; to keep an exact baseline, export the factory first.
• Results arrive in two stages. A run whose KPIs haven’t populated yet is pending, not broken — the simulation finished and the results pass is still computing. If the results pass fails, it can be retried without re-simulating.
• The UI follows one active selection. Results, chart authoring, and the run picker read the currently active model, run, and schedule, so confirm you’re looking at the run you think you are before comparing numbers.

​

Where to Go Next

• Your First Simulation — build and run the loop once
• Modeler — the canvas, every component type, and the run controls
• Simulation Studies — running a full improvement study across several sessions
• Runs, Results and Analytics — the analysis surfaces
• Reference: Entities, Schedules, Events, Distributions, Expressions, Constants & Lookup Tables, Validation, Model Nodes, Combiners, Separators & Transformers