What Is Discrete Event Simulation?
Discrete event simulation (DES) models a system as a sequence of events that happen at specific points in time. In a manufacturing context, each event represents something concrete: an entity arriving at a process, a resource becoming available, a batch completing. ProDex runs DES using the SimPy engine under the hood. You don’t interact with SimPy directly — you build models visually on a canvas, and ProDex handles the simulation execution. The key insight of DES: you can model complex, variable, interdependent operations accurately without needing a physical prototype or running the real system. Change a resource capacity, tweak a processing time distribution, add a buffer — and see the downstream effects in seconds.Building a Model
Models are built as a directed graph on the Modeler canvas. Components are nodes; connections are edges that define entity flow.Component Types
Source Generates entities and injects them into the model. Configure:- Which entity type to produce
- Arrival logic (rate, schedule, or expression)
- Initial attribute values on each entity
- Processing time (fixed value, distribution, or expression)
- Resource requirements (which resources and how many)
- Output attributes
- Capacity (number of units available)
- Availability schedule
- Maximum capacity (leave empty for unlimited)
Connections
Draw connections between component outputs and inputs to define how entities flow. A connection from a Process to a Buffer means entities leaving that process queue in that buffer before moving on.Expressions and the DSL
Most numeric fields in component configuration accept either a plain number or an expression written in ProDex’s DSL (domain-specific language). Expressions let you make models dynamic and data-driven. Common uses:- Processing time as a distribution:
TRIANGULAR(2, 5, 10)(min, mode, max in minutes) - Routing logic:
IF(ENTITY_TYPE == "TypeA", "path_1", "path_2") - Resource requirement based on entity attribute:
IF(self.priority == "high", 2, 1) - Lookup from a table:
LOOKUP(cycle_times_table, ENTITY_TYPE)
SIM_TIME— current simulation timeENTITY_TYPE— type of the current entityENTITY_AGE— time the entity has been in the systemBUFFER_LEVEL(buffer_name)— current number of entities in a bufferRESOURCE_AVAILABLE(resource_name)— available units of a resourceSTATION_WIP(station_name)— work in progress at a station
Constants and Lookup Tables
Constants are factory-scoped global parameters you can reference by name in any expression. Use them to avoid hardcoding values — change a constant once and it updates everywhere it’s referenced. Lookup Tables are named data tables you can query withLOOKUP(table_name, key). Use them for things like processing time by product type, yield rates, or probability distributions.
Both are defined in the Data section of the sidebar and available across all models in your factory.
Library
The library holds the shared reference data your models draw from. All library items are scoped to a factory and available across every model in it.Entities
Entities are the items that flow through your simulation — raw materials, work-in-progress, and finished goods. Every entity referenced in a Source, Transformer, or BOM must be defined in the library first. Each entity has a name, description, unit of measure, and an optional definition that carries custom attributes. Attributes can be read and set in expressions using dot notation onself, enabling behavior that varies based on what’s being processed.
Entity type is available in expressions as ENTITY_TYPE.
Constants
Constants are named, factory-scoped parameters you can reference by name in any expression field across all models. Each constant has a name, description, type (number, string, or boolean), and a value. Reference a constant by name directly in an expression:
Lookup Tables
Lookup tables are named key-value tables queryable in expressions:Running a Simulation
Once your model is configured, click Run. ProDex executes the simulation and streams results back when complete. Each execution creates a Run record with a full set of results. You can run the same model multiple times (e.g., with different constants or schedules) and compare runs in the Results and What-If sections.Reading Your Results
Results are defined by the KPIs and Charts attached to your model. See the Results and Analytics guide for a full breakdown.Tips and Best Practices
- Start simple. A Source → Process → Sink is enough to validate your setup before adding complexity.
- Use constants for any value you might want to change between runs. This makes scenario analysis much easier.
- Name everything clearly. Component names show up in results and event logs — descriptive names make results much easier to interpret.
- Use stations to group related components. Large models become hard to navigate without organization.
- Checkpoints are automatic. ProDex saves a checkpoint every time you make a meaningful change. You can always roll back if something breaks.

