Simulation processor model
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.
URI reference to the logistics optimization paramteres (for logistics processor)
URI reference to passenger optimization parameters
calculation_parameters_regenerator object
Settings for regenerator processor type
Timestamp when the processor should stop (for continuous and ondemand processor)
For other processors, this will be populated by the processor on iots completion.
If processor is continuously running, this flag controls if the processor should retry on failure.
See scheduled_after field.
falseSpecifices 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]
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.statetoPREPARED - resets
Node.statetoNEW - resets
Node.assigned_vehicletoNone - resets
Node.scheduled_tstoNone - (optional) resets
Booking.min_pickup_timetoprocessor.calculation_parameters_regenerator['min_pickup_time'] - (optional) resets
Booking.max_pickup_timetoprocessor.calculation_parameters_regenerator['max_pickup_time'] - (optional) resets
Booking.min_dropoff_timetoprocessor.calculation_parameters_regenerator['min_dropoff_time'] - (optional) resets
Booking.max_dropoff_timetoprocessor.calculation_parameters_regenerator['max_dropoff_time'] - (optional) resets (pickup)
Node.open_time_tstoprocessor.calculation_parameters_regenerator['min_pickup_time'] - (optional) resets (pickup)
Node.close_time_tstoprocessor.calculation_parameters_regenerator['max_pickup_time'] - (optional) resets (dropoff)
Node.open_time_tstoprocessor.calculation_parameters_regenerator['min_dropoff_time'] - (optional) resets (dropoff)
Node.close_time_tstoprocessor.calculation_parameters_regenerator['max_dropoff_time']
Possible values: [on_demand, mtm_jit, logistics, fixed_routes, regenerator]
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.
URI reference to the simulation this processor belongs to
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.
Current state of the processor
Possible values: [new, calculating, calculated, completed, failed]
Only empty and no assigned nodes vehicles will be chosen
falseOnly vehicles within their start_time-end_time will be chosen
falseOnly vehicles with in_use=enabled will be chosen
trueVehicles 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
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_timeof the new bookings is earliermin_pickup_timeof the already scheduled booking- Original bookings has to be in
AssignedorEnroutestate
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.
falseIdentifier of the user that created the processor
Creation timestamp of an object
id object
Identifier of the object
- integer
- uuid
Can be integer
Can be UUID
Last modification timestampo of the object
URI of the object instance
{
"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"
}