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 time-bound, having a defined start and end time. This reflects real-world operations, which typically occur within specific periods (e.g., a delivery shift, a workday). The temporal boundaries of the simulation are crucial for respecting constraints like maximum trip duration and time windows.

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.

warning

The /api/v2/microservices/logisticsapi endpoint in simulation_clone mode defines a simulation using start_time and end_time. When using simulation_clone_parameters to upload orders (instead of adding to an existing simulation), a unique start_time/end_time pair creates a new simulation. To add orders to the same simulation across multiple requests, use the same start_time/end_time pair; otherwise, each request creates a new simulation.