Skip to main content

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
Process Where work happens. Entities enter, spend time being processed, and exit. Configure:
  • Processing time (fixed value, distribution, or expression)
  • Resource requirements (which resources and how many)
  • Output attributes
Resource A capacity pool that processes draw from. Configure:
  • Capacity (number of units available)
  • Availability schedule
Sink The exit point. Entities that reach a sink are consumed and counted. Buffer A waiting area between components. Configure:
  • Maximum capacity (leave empty for unlimited)
Router Splits entity flow based on conditions. Configure routing logic using expressions — e.g., send 30% to one path and 70% to another, or route based on entity attributes. Combiner Batches multiple entities together into one before proceeding. Separator Splits one entity into multiple entities at a point in the flow. Transformer Changes the entity type of an entity after processing — useful when a raw material becomes a different product after a process step. Station A logical grouping of components that represents a physical space or work center. Stations help organize large models. Model Node Embeds another simulation model inside this one. Use this to build hierarchical models — define a sub-process once and reuse it across multiple parent models.

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)
Useful built-ins:
  • SIM_TIME — current simulation time
  • ENTITY_TYPE — type of the current entity
  • ENTITY_AGE — time the entity has been in the system
  • BUFFER_LEVEL(buffer_name) — current number of entities in a buffer
  • RESOURCE_AVAILABLE(resource_name) — available units of a resource
  • STATION_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 with LOOKUP(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 on self, 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:
processing_time_minutes * shift_efficiency_factor
Constants are the right tool for any value that appears in multiple places or that you want to sweep in an experiment. Change a constant once and every component that references it updates automatically.

Lookup Tables

Lookup tables are named key-value tables queryable in expressions:
LOOKUP(cycle_times, ENTITY_TYPE)
Each table has a name and a set of rows with string keys and numeric or string values. If a key is not found, the expression returns null. Common uses: processing time by product type, yield rates by material, routing weights by order class, or any data that varies by a categorical attribute of the entity being processed.

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.