Skip to main content

​
Overview

Any numeric field that varies run-to-run — processing times, arrival rates, entity attribute values, resource requirements — can be drawn from a probability distribution instead of a fixed number. Distributions let a model reflect real-world variability: cycle times that vary, demand that clusters and lulls, processing durations with realistic long tails. Distributions in ProDex are JSON objects, not DSL function calls. You don’t write NORMAL(60, 10) in a field — you write a distribution object: 
{"type": "normal", "mean": 60, "std": 10}
The distribution type ("type": "normal") and its shape are static configuration. The parameter values inside the object can themselves be DSL expressions, which is how you make variability depend on simulation state or entity attributes.

​
Supported Distributions

​
fixed

A deterministic value. Technically not a distribution, but included for consistency so every numeric field uses the same object form. 
{"type": "fixed", "value": 60}
Use for: predictable, non-random values. Useful when you want the field to be wired the same way as variable fields but the value should not vary.

​
normal

The classic bell curve — symmetric around a mean, spread controlled by standard deviation. 
{"type": "normal", "mean": 60, "std": 10}
Use for: processing times that cluster tightly around a central value with symmetric variability. Machine cycle times, measurement errors, and anything subject to many small independent sources of variation. Watch out: normal distributions extend to negative infinity. For strictly positive quantities (times, weights) with substantial variance, consider lognormal or gamma to avoid negative samples.

​
exponential

Time between memoryless events. Higher concentration near zero, long tail. 
{"type": "exponential", "beta": 60}
The beta parameter is the mean (equivalently, 1 over the rate). Despite the name, it’s the expected value of a sample. Use for: inter-arrival times in Poisson processes (random arrivals), time until a random failure, time until a random event with constant hazard rate.

​
uniform

Every value between min and max is equally likely. Flat distribution. 
{"type": "uniform", "min": 50, "max": 70}
Use for: cases where you only know the bounds and have no reason to favor any specific value within them. Often a starting assumption before better data is available.

​
lognormal

A log-transform of a normal distribution — right-skewed, strictly positive, with a long right tail. 
{"type": "lognormal", "mu": 4.0, "sigma": 0.5}
mu and sigma are the mean and standard deviation of the underlying normal distribution (before the log transform), not of the lognormal itself. Use for: service times, task durations, and any quantity that’s positive, has a clear typical value, and occasionally has long outliers. Many real-world “how long does this take?” distributions are well-modeled by lognormal.

​
weibull

Flexible distribution that can model increasing, constant, or decreasing hazard rates depending on its shape parameter. 
{"type": "weibull", "shape": 2.0, "scale": 100}
Use for: time-to-failure modeling (reliability engineering), fatigue life, and any process where the rate of occurrence changes with elapsed time.

​
triangular

A simple three-point distribution: min, mode, max. 
{"type": "triangular", "min": 2, "mode": 5, "max": 10}
Use for: expert-elicited estimates (“fastest it ever takes is 2 min, typically 5 min, worst case 10 min”). A reasonable default when you have three-point estimates but no empirical distribution to fit.

​
erlang

Sum of shape independent exponential random variables, where shape must be a positive integer. 
{"type": "erlang", "shape": 3, "scale": 20}
Use for: multi-stage processes where each stage is exponentially distributed, or when you need positive distributions with more shape control than exponential and less complexity than gamma.

​
beta

Distribution on the interval [0, 1], flexibly shaped by two parameters. The second parameter is named beta_param to avoid clashing with the distribution type name. 
{"type": "beta", "alpha": 2.0, "beta_param": 5.0}
Use for: proportions, yields, and probabilities that vary run-to-run. Shape parameters let you express everything from uniform (alpha=1, beta_param=1) through bell-like shapes to heavily skewed.

​
gamma

General-purpose continuous distribution for positive quantities, controlled by two parameters. 
{"type": "gamma", "alpha": 2.0, "beta": 1.5}
alpha is the shape parameter; beta is the rate (or scale, depending on parameterization — the platform’s convention defines which). Use for: positive quantities with a more flexible shape than exponential or lognormal. Service times, waiting times, and queueing phenomena.

​
Choosing a Distribution

If you have real data, fit a distribution to it. If you don’t:
You know…Use
The exact valuefixed
Mean and symmetric variability, value can be any signnormal
Only the bounds, no reason to favor any regionuniform
Mean only, memoryless event timingexponential
Three-point estimate (min/mode/max)triangular
Positive, skewed right, one “typical” value with long taillognormal or gamma
Proportion / probability with variabilitybeta
Time-to-failure with a hazard rate that changes over timeweibull
Sum of exponential stageserlang
For processing times where you have “average” and “worst case” numbers from the floor, triangular is a pragmatic default. For arrival patterns, exponential is the standard start. For distribution-sensitive work (queue analysis, reliability), fit to real data.

​
Parameterizing with DSL Expressions

Distribution parameters aren’t limited to literals. Each parameter field can be a DSL expression that references constants, state variables, entity attributes (where the context allows), or other expressions: 
{"type": "normal",
 "mean": "base_time * complexity_factor",
 "std": "base_stddev"}

{"type": "exponential",
 "beta": "LOOKUP(mean_interarrival_by_shift, current_shift)"}

{"type": "lognormal",
 "mu": "LOOKUP(log_mean_weight_by_product, ENTITY_TYPE)",
 "sigma": 0.1}
This composability is what lets a single model represent rich, data-driven variability without hardcoding numbers across dozens of fields.

​
Tips

  • Draw from the distribution at use time, not at entity creation time. For processing times especially, sample the distribution when the Process runs — not as an entity attribute set at the Source. This keeps the sample close to the state it should depend on.
  • Normal isn’t always the answer. It’s familiar but it can produce negative samples. For strictly positive quantities, prefer lognormal, gamma, or truncated alternatives.
  • Check parameter names carefully. Different distributions use different parameter names even when the mathematical concept is similar (e.g., beta is the mean of exponential, but also the second shape parameter of gamma). The JSON form is the source of truth.
  • Match distribution to data when possible. A fitted distribution on real MES cycle times will give much more realistic results than an assumed parametric one.
  • Use fixed to simplify initial modeling. Start with fixed values to verify the structure, then swap in distributions once the model is correct.