Skip to main content

Simulation as a data container

A simulation api acts as a comprehensive data container, bringing together all the necessary elements for route optimization and job allocation. It encapsulates the following:

  • Orders: As discussed earlier, orders represent delivery/service requests, specifying what needs to be done and where. The simulation includes all relevant order details: associated node (customer location), demand (quantity or service duration), time windows (if applicable), priority, etc. These orders define the set of nodes that must be visited.
  • Vehicles: The simulation defines the available fleet of vehicles, each with its own attributes: capacity (weight, volume, etc.), maximum trip duration, start/end location (depot), and potentially other characteristics like cost per kilometer or driver availability. These vehicle properties constrain the possible routes.
  • Constraints: Beyond vehicle capacity and maximum trip duration, a simulation can incorporate other constraints relevant to the specific problem:
  • Time Windows: As previously explained, these restrict when service can occur at specific nodes (customers, depots, or even vehicles). Simulations must respect these temporal limitations.
  • Node Dependencies: Some orders might have dependencies (e.g., order A must be delivered before order B). The simulation manages these relationships.
  • Resource Constraints: Beyond vehicle capacity, other resource constraints (e.g., number of available drivers, loading dock capacity) can be included.
  • Templates: Templates can define pre-set routes or service patterns that can be used as a starting point or guide for the optimization process. They can represent typical delivery routes or best practices.
  • Metadata: The simulation stores all additional data needed for optimization, such as road network information (travel times between nodes), cost parameters (e.g., cost per kilometer, driver wages), and any other relevant data. Temporal Boundaries:

Simulations are strictly time-bound, defined by a start_time and end_time. These parameters usually correspond to a specific operational shift or a full working day (e.g., 08:00 to 18:00). These boundaries set the hard limits for the optimization horizon; the solver will not plan any activities outside this window.

Relationship with Templates:

The start_time is particularly important when creating a simulation from a template. Templates store routing patterns and configurations in a relative manner. When you instantiate a simulation from a template, the system uses the new start_time to "shift" all time-dependent data (like vehicle shifts and processor configurations) to the new date.

For detailed rules on how this time shifting calculation works, refer to the Time window adjustment rules.

Projects and Multiple Simulations:

A project can encompass multiple simulations, each representing a different time period or scenario. Simulations can overlap in time, allowing for the modeling of complex operations that span multiple shifts or days. Creating a separate simulation for each day is a common practice, allowing for independent optimization based on the specific orders and constraints of that day. This also allows for easy comparison of performance across different days.

Modeling Time-Bound Operations:

Simulations are designed to model real-world, time-bound operations. By incorporating orders, vehicles, constraints, and metadata within a defined time frame, simulations allow for the optimization of routes and job allocation to maximize efficiency and minimize costs. They provide a powerful tool for planning and managing complex logistics operations. For example, a simulation could be used to model the delivery routes for a courier company on a specific day, considering all the orders received, the available vehicles, and the time windows requested by customers.

How is a Simulation Identified?

When creating a simulation via the API using simulation_clone_parameters (in simulation_clone mode), the system uniquely identifies the simulation based on the Template and the start_time.

  • Reusing a Simulation: If a simulation with the same start_time already exists for the selected template, the system will reuse it. This allows you to add orders to the same simulation using multiple API requests by keeping the start_time consistent.
  • Creating a New Simulation: A new simulation is created only if no existing simulation matches the start_time (and Template).
  • Note on end_time: The end_time parameter is used only when creating a new simulation. If a simulation is reused, the provided end_time is ignored in favor of the existing simulation's end time.