Skip to main content

Simulation processor model

bookings_filter_expressionobjectrequired

Booking filter expression to be used for optimization for the processor (filter expression). Filter expression should match Django syntax for definitions. Please do not use fail_to_board in the filter to select bookings that were failed to pickup, instead use should_optimize_fail_to_board_bookings in the optimization settings.

Example of the fitlering expression:

{
  "and": [
    {
      "pk__in": [
        <some_booking_id_list>
      ]
    },
    {
      "is_invalidated__exact": true
    }
  ]
}

Any fields or theri combintation can be used following QuerySet filtering Django framework.

calculation_parameters_logisticsstring | nullnullable

URI reference to the logistics optimization paramteres (for logistics processor)

calculation_parameters_mtm_jitstring,null<uri-reference>nullable

URI reference to passenger optimization parameters

calculation_parameters_regenerator object

Settings for regenerator processor type

min_pickup_timestring<date-time>
max_pickup_timestring<date-time>
min_dropoff_timestring<date-time>
max_dropoff_timestring<date-time>
end_timestring

Timestamp when the processor should stop (for continuous and ondemand processor) For other processors, this will be populated by the processor on iots completion.

external_idstring | nullnullable
fault_tolerantboolean

If processor is continuously running, this flag controls if the processor should retry on failure. See scheduled_after field.

Default value: false
gps_timeoutnull
processor_lifecycle_typestring

Specifices if the processor should be execute once when created, or scheduled to continuous execution. If continuous, start_time and end_time will be used as timewindow when the processor should be running.

Possible values: [one_shot, continuous]

processor_typestringrequired

Type of the simulation processor pipeline. Depending on this field, the processor may execute various types of logic. For gotistics operations, this field should be set to logistics on ondemand to support live insertion of orders.

Regenerator processor

Regenerator is a special type of processor allowing for shifting thebooking to another operations window within the same simulation. This is useful when operations are running in multiple shifts and some orders need to be carried over to the next one. It also requires additional parameters to be set in it's configuration in calculation_parameters_regenerator field.
Regenerator pipeline executes the following rules for all bookings meeting booking_filter_expression setting:

  • resets Booking.state to PREPARED
  • resets Node.state to NEW
  • resets Node.assigned_vehicle to None
  • resets Node.scheduled_ts to None
  • (optional) resets Booking.min_pickup_time to processor.calculation_parameters_regenerator['min_pickup_time']
  • (optional) resets Booking.max_pickup_time to processor.calculation_parameters_regenerator['max_pickup_time']
  • (optional) resets Booking.min_dropoff_time to processor.calculation_parameters_regenerator['min_dropoff_time']
  • (optional) resets Booking.max_dropoff_time to processor.calculation_parameters_regenerator['max_dropoff_time']
  • (optional) resets (pickup) Node.open_time_ts to processor.calculation_parameters_regenerator['min_pickup_time']
  • (optional) resets (pickup) Node.close_time_ts to processor.calculation_parameters_regenerator['max_pickup_time']
  • (optional) resets (dropoff) Node.open_time_ts to processor.calculation_parameters_regenerator['min_dropoff_time']
  • (optional) resets (dropoff) Node.close_time_ts to processor.calculation_parameters_regenerator['max_dropoff_time']

Possible values: [on_demand, mtm_jit, logistics, fixed_routes, regenerator]

schedule_afterstring,null<date-time>nullable

A processor can have a fault_tolerant status, which means that if it fails to process bookings (e.g., due to solver/routing failure), its status reverts to NEW and is given another chance to succeed. However, it is not practical to allow it to restart immediately (e.g., the problem might be intermittent or manual intervention might be required to fix it). In such cases, continuous processing without any benefit is counterproductive. Instead, its schedule_after is adjusted to disable scheduling until the specified moment. This backoff period is preconfigured by the system administrator.

The same applies for successful turnaround. To allow external systems to fully and correctly consume recent updates, the next scheduling moment is also delayed for a period preconfigured by the system administrator.

If not null, the processor can be scheduled for processing after the specified time.

simulationstring<uri-reference>required

URI reference to the simulation this processor belongs to

start_timestring<date-time>

Time stamp of the processor start. For oneshopt processsors this will be set automatically on processor start. FOr ondemand processors, this will be used to identify when the processor should be started.

statestring

Current state of the processor

Possible values: [new, calculating, calculated, completed, failed]

vehicle_selection_by_emptinessboolean

Only empty and no assigned nodes vehicles will be chosen

Default value: false
vehicle_selection_in_serviceboolean

Only vehicles within their start_time-end_time will be chosen

Default value: false
vehicle_selection_in_useboolean

Only vehicles with in_use=enabled will be chosen

Default value: true
vehicles_filter_expressionobjectrequired

Vehicles to be used for the optimization session (filter expression similar to bookings)

calculation_parameters_ondemand object

Represents settings that can be applied for on demand processor

enable_linking_similar_bookingsboolean

This flag enabled a booking state, LINKED, designed to optimize visits to the same location, particularly useful for scenarios like milk runs. A LINKED booking is associated with a parent booking (identified by group_uid) that already exists and is scheduled for processing. The LINKED booking itself is not processed independently; instead, its timings are derived from its parent. This allows multiple orders to be handled within a single trip, improving efficiency.

Booking linking is enabled through an on-demand simulation processor. This processor, triggered by a new booking, analyzes existing ASSIGNED or ENROUTE bookings. If the new booking's pickup_operations_location and dropoff_operations_location match those of an existing booking, the new booking's status is set to LINKED, its group_uid is set to the matching booking's UID, and it is excluded from further processing. This linking behavior is controlled by the calculation_parameters_ondemand.enable_linking_similar_bookings setting within the on-demand processor's configuration. If this setting is true, linking is enabled; if false or omitted, the on-demand calculation behaves as a standard logistics calculation. New bookings that are not linked are passed to the standard logistics pipeline for processing.

Rules for booking linking and pooling:

For each of the passed bookings try to find an existing assigned one which:

  • has the same pickup operations location
  • has the same dropoff operations location
  • min_pickup_time of the new bookings is earlier min_pickup_time of the already scheduled booking
  • Original bookings has to be in Assigned or Enroute state

If matching booking is found then the new booking status is set to LINKED, and group_uid is set to the uid of the matching booking. The new booking is removed from the list. If list of new bookings is not empty it is passed to the logistics pipeline. Linked bookings will be recognized as rejected in worker but no rejection actions will be taken for these bookings.

Default value: false
userstring | nullnullablerequired

Identifier of the user that created the processor

created_atstring<date-time>

Creation timestamp of an object

id object

Identifier of the object

anyOf
integer

Can be integer

modified_atstring<date-time>

Last modification timestampo of the object

resource_uristring<uri-reference>

URI of the object instance

Simulation processor model
{
  "bookings_filter_expression": {},
  "calculation_parameters_logistics": "string",
  "calculation_parameters_mtm_jit": "string",
  "calculation_parameters_regenerator": {
    "min_pickup_time": "2024-07-29T15:51:28.071Z",
    "max_pickup_time": "2024-07-29T15:51:28.071Z",
    "min_dropoff_time": "2024-07-29T15:51:28.071Z",
    "max_dropoff_time": "2024-07-29T15:51:28.071Z"
  },
  "end_time": "string",
  "external_id": "string",
  "fault_tolerant": false,
  "gps_timeout": "null",
  "processor_lifecycle_type": "one_shot",
  "processor_type": "on_demand",
  "schedule_after": "2024-07-29T15:51:28.071Z",
  "simulation": "string",
  "start_time": "2024-07-29T15:51:28.071Z",
  "state": "new",
  "vehicle_selection_by_emptiness": false,
  "vehicle_selection_in_service": false,
  "vehicle_selection_in_use": true,
  "vehicles_filter_expression": {},
  "calculation_parameters_ondemand": {
    "enable_linking_similar_bookings": false
  },
  "user": "string",
  "created_at": "2024-07-29T15:51:28.071Z",
  "id": 0,
  "modified_at": "2024-07-29T15:51:28.071Z",
  "resource_uri": "string"
}
Last updated on