複数回の集荷を伴うミルクランの実装

ロジスティクスにおいて、ミルクラン

とは、1台の車両が所定のルートに沿って複数の停車地を回り、さまざまな場所で商品を集荷または降ろす配送方法です。このアプローチは、複数の個別配送の必要性を回避することで、貨物を集約し、輸送コストを削減し、効率を向上させることを目的としています。

Integration APIは、さまざまな状況でミルクランをサポートするための複数の便利な機能を提供します。役立つ可能性のある特定の機能は次のとおりです。

• 日によって異なる可能性があるが周期的な運用に役立つ、スケジュールに基づいてシミュレーションテンプレートを自動選択する機能
• 静的なルート設定または定期的なベースで役立つ、シミュレーションテンプレート内に車両、予約、ルート、車両の割り当てをアップロードして保持する機能
• 運用上の理由（ドライバーの病気、車両が利用できないなど）による毎日のスケジュールの調整機能
• その予約を実行するための最適な車両と順序を特定するために、即時最適化を伴うシミュレーションにアドホックな予約を挿入する機能
• 車両と予約に運用ゾーンを割り当てる機能。これにより、特定の運用ゾーンに割り当てられた車両がこのゾーンの予約に割り当てられます。ゾーンは「タグ」として定義されます。
• 計画の変更について利害関係者に通知する機能（テキストメッセージやその他のIMの送信など）
• 予約を他の時間枠または翌日に自動的に調整およびシフトする機能
• 既存のOMS、CRM、またはERPとフローを統合する機能

これらの機能のほとんどは完全に自動化できるため、必要な人的労力を最小限に抑えることができます。

ユースケース

あるロジスティクス会社は、複数の運用ゾーンにまたがって運用される車両フリートを保有しています。これらの車両は、毎日非常に多い可能性のある、事前に割り当てられた目的地にわたる所定のルートセットを実行しますが、毎週繰り返されます。この目的地で、車両は商品を集荷し、それらをデポに配送します。 車両は、午前と午後の2つのシフトで運用されます。また、シフト時間とフリート構成は曜日によって異なり、集荷ポイントの営業時間は毎日同じではありませんが、毎週繰り返されます。時折、このスケジュールは変更される可能性があります（新しい集荷場所が追加されたり、古い場所が削除されたり、車両の運用時間も長期的に変更される可能性があります）。 予約は、集荷場所のクライアントによって作成され、設定されたSLAを満たしながら収集されてデポに配送されることが期待されています。

フリート内の各車両は、運用が許可されている特定のゾーンに割り当てられているため、ゾーンに割り当てられた集荷場所に対して作成された予約は、そのゾーンにサービスを提供する車両に割り当てられる必要があります。各集荷場所は1つのゾーンにのみ属することができ、同様に各車両は1つの運用ゾーンにのみサービスを提供できます。

シフト中に、アドホックな集荷注文が表示される場合があり、車両はそれらを実行することが期待されているため、システムはそれを達成するための最も適切で最も効率的な方法を選択する必要があります。特定のシフトで予約可能な車両がない場合、予約は次のシフト（つまり、午前シフトから午後シフト）に移動する必要があります。午後シフト中に配送できない場合は、予約をキャンセルする必要があります。システムがいずれかの段階で予約に対応できない場合は、利害関係者に通知を送信する必要があります。

予約、フリート構成、および営業時間を伴う集荷場所は、APIを介してこのデータをSWATシステムと同期するクライアントのERPで管理され、配達証明、ETA、および予約のステータスを取得することも期待されています。

このユースケースの目標は、アドホックな予約を動的に管理しながら、移動距離と必要な車両数を最小限に抑えることでミルクランを最適化することです。

プロジェクトの設定

シナリオを実現するには、いくつかのAPIを使用および構成する必要があります。次のガイドには、一度実行する必要がある手順（プロジェクト設定中）、まれに実行する必要がある手順（フリート構成と集荷場所の変更）、および毎日実行する必要がある手順（通知、アドホック予約、配達証明、ETAの管理）が含まれています。ワークフローの目標は、毎日必要なリクエストの数を最小限に抑え、可能な限り多くの構成をプロジェクト設定にオフロードすることです。

プロジェクトによっては、SWATチームがプロジェクトと初期テンプレートを設定する場合がありますが、このガイドでは、すべての構成と実行手順がAPIを介して行われることを前提としています。

警告

JSONはデータのみの形式であり、コメントをサポートしていないため、以下の例のすべてのコメントは、ペイロードとして試すときに削除する必要があります。

ミルクランのシミュレーションを構成するための一般的なフローには、次の手順が含まれます。

• 静的な集荷場所（荷受人マスター）を構成（またはインポート）します。これはまれにしか変更されません（たとえば、月に1回）。
• 静的なルート、車両フリート、および所定のルート（ミルクラン）を含む複数のシミュレーションテンプレートを設定します。
• 曜日に基づいて適用されるようにシミュレーションテンプレートを構成します（たとえば、月曜日のシミュレーションテンプレートと週の残りの曜日の別のテンプレート）。
• 車両の制約（車両がサービスを提供できる場所のグループ）を構成します。
• ミルクランの最適なルートを確立するために、シミュレーションの初期最適化を実行します。
• アドホック注文の予約のオンデマンド（リアルタイム）挿入を構成し、未配達の予約の後続シフトへの転送を構成します。
• フローをテストし、通知を設定します。

ミルクランとテンプレートに関連付けられた静的データを表すデータモデル

営業時間、場所、および運用エリア間の関係を確立するには、いくつかの追加のデータモデルを一度使用および構成する必要があります。このデータは通常、顧客のERPからインポートして維持する必要があります。

プロジェクトとシミュレーションの初期設定

プロジェクト設定は2つのステップで構成されます。

• プロジェクト自体の設定（ジオフェンス、場所を含む）
• ミルクランの運用場所（荷受人）の構成
• シミュレーションテンプレートの設定（定期的な期間ごとに1つのテンプレート（たとえば、月曜日、火曜日など））
• 車両と車両の制限ゾーンの設定
• ミルクランに追加する予約テンプレートの追加
• ミルクランの所定のルートを確立するための初期最適化の実行
• アドホック注文と未割り当ての予約のシフトをサポートするためのプロセッサの構成

ジオフェンスは、車両の運用エリアを定義します。このシナリオでは、運用ゾーン全体を網羅する1つのジオフェンスを作成します。この例ではジオフェンスではない車両間の運用ゾーンを分割するには、運用ゾーングループを使用します。

ミルクランの静的な場所の作成（荷受人リスト）

運用ゾーンは、広い意味で荷受人マスターを表します。プロジェクトレベルで、事前定義された場所とその利用可能な時間枠（複数の時間枠がサポートされています）を、追加のパラメーターとともに指定できます。 場所は場所グループにグループ化でき、これを使用して特定の車両のみへのアクセスを制限できます。この制約を適用するには、車両の特性が使用されます。さらに、ジオフェンス制約を場所グループに追加できます。

場所運用グループを作成するには、次のリクエストを使用できます。

JSONペイロードを参照

繰り返しを含むシミュレーションテンプレートの作成

POST /api/v2/operationslocationgroup


{
    "code": "E99",
    "geofence": null,
    "project": "/api/v2/project/{{project_id}}"
}

このシナリオでは、同社は1つの中央デポと定期的に訪問される複数の集荷ポイントを持つミルクランを運営しています。集荷場所はめったに変更されないため、APIのコンシューマーが毎日または他の運用ウィンドウ中にそれらを再作成する手間を省くために、テンプレートに追加されます。ミルクランを表すデータモデルは、これを容易にすることができます。プロジェクトモデルは、関連する時間枠と運用エリアを持つ場所のリスト（集荷または降車ポイントとして機能できます）を参照できます。

ヒント

Projectには、祝日のリストを持つことができるpublic_holidaysプロパティもあります。時間枠ベースのテンプレートは、この祝日のリストを尊重しますが、これは運用時間枠オブジェクト内のフラグを使用して上書きできます。

プロジェクト内のすべての利用可能な場所をリクエストして表示するには。

プロジェクトのすべての場所をリクエストする

GET <project_id>/api/v2/operationslocation/<project_id>

場所はAPIを介して作成でき、以下のリクエストを使用して場所に複数の時間枠を設定できます。

JSONペイロードを参照

場所の作成

POST /api/v2/operationslocation

{
    "address": "Some address",
    "code": "12345",
    "created_at": "2024-09-05T18:44:32.593694+00:00",
    "data": {},
    "external_id": "12345",
    "group": "/api/v2/operationslocationgroup/5", //この場所が属するグループ
    "h3": "0040062446533530004660",
    "id": 11,
    "modified_at": "2024-09-05T18:44:32.593717+00:00",
    "name": "Test name",
    "project":"/api/v2/project/<project_id>",
    "point": {
        "coordinates": [
            100.0000,
            10.000
        ],
        "type": "Point"
    },
    "time_windows": [
        {
            "time_window": {
                "resource_uri": "/api/v2/operationstimewindow/<time_window_id>"
            }
        }
    ]
}

複数のオープン時間枠を持つ場所を作成するには、次のリクエストを使用できます。

JSONペイロードを参照

繰り返しを含むシミュレーションテンプレートの作成

POST /api/v2/operationslocationgroup


{
    "address": " TAMPINES ST 111 #11-111",
    "code": "A11",
    "created_at": "2024-09-05T18:44:32.593694+00:00",
    "data": {},
    "external_id": "A111",
    "group": "/api/v2/operationslocationgroup/26",
    "modified_at": "2024-09-05T18:44:32.593717+00:00",
    "name": "Main Location",
    "project":"/api/v2/project/{{project_id}}",
    "point": {
        "coordinates": [
            103.917644661626,
            1.32892431398393
        ],
        "type": "Point"
    },
    "time_windows": [
        {
            "time_window": {
                "resource_uri": "/api/v2/operationstimewindow/1348"
            }
        }
    ]
}

このシナリオでは、同社はデポに1つの降車ポイントと、定期的に訪問されるいくつかの集荷ポイント（つまり、ミルクラン操作）を持っています。集荷場所はめったに変更されないため、APIコンシューマーが毎日または他の運用ウィンドウ中にそれらを再作成する必要がないように、これらの場所はテンプレートに追加されます。ミルクランを表すデータモデルをこの目的で使用できます。

プロジェクトモデルは、関連する時間枠と運用エリアを持つ場所のリスト（集荷または降車場所として機能できます）を参照できます。

ヒント

Projectには、祝日のリストを持つことができるpublic_holidaysプロパティもあります。時間枠ベースのテンプレートは、この祝日のリストを尊重しますが、これは運用時間枠オブジェクト内のフラグを使用して上書きできます。時間枠の繰り返しは、iCal形式で運用時間枠オブジェクトに設定できます。また、プロジェクトレベルで構成された祝日ルールを尊重または上書きすることもできます。

JSONペイロードを参照

繰り返しを含む時間枠の作成

POST /api/v2/operationstimewindow


        {
            "close_time_ts": "1900-01-01T13:00:00+00:00",
            "name": "SOME DROP OFF - thursday Day Shift 1",
            "open_time_ts": "1900-01-01T09:00:00+00:00",
            "project": "/api/v2/project/{{project_id}}",
            "public_holiday": false,
            "recurrences": "DTSTART:20240905T184433Z\nRRULE:FREQ=DAILY;BYDAY=TH",
            "strict": true
        }

シミュレーションテンプレートの作成

シミュレーションテンプレートには、ミルクランの実行に必要なすべてのデータが含まれています。たとえば、次のとおりです。

• 車両と車両の制約。
• 最適な順序で車両に割り当てられた、所定の予約（およびノード）の形式の所定のルート。予約とノードは、運用場所（荷受人リスト）から推測されます。
• 初期最適化中に適用される運用上の制約

このシミュレーションテンプレートの状態を実現するには、次の手順に従う必要があります。

• 運用場所グループから予約（および結果としてノード）を作成します。
• シミュレーションの車両とその制約を作成します。
• 最適化を実行し、割り当てを所定のミルクランとして保存します。

選択した日時に基づいて適切なテンプレートからシミュレーションを自動作成する（つまり、曜日ごとに異なるテンプレートが自動的に作成される）ことを反映するには、目的の設定とrecurrenceパラメーターを構成して、期間ごとに個別のテンプレート（つまり、月曜日、火曜日、水曜日など）を作成する必要があります。

ヒント

より簡単なシミュレーション設定のために、車両などのオブジェクトを複製するための追加のAPIを活用できます。

次の例では、単一のテンプレートを作成します。これは、各日（またはより詳細なテンプレートが必要な場合は他の期間）に適切な設定で繰り返す必要があります。recurrenceフィールドに注意してください。これは、2024年9月29日まで毎週水曜日と木曜日に定期的なテンプレートを設定します。recurrence_priorityフィールドは、シミュレーションのインスタンス化中に複数のテンプレートが利用可能な場合にテンプレートの優先度を設定するために使用されます。また、simulation_modeがtemplateに設定されていることにも注意してください。これは、このシミュレーションがテンプレートとして扱われることを意味します。

JSONペイロードを参照

繰り返しを含むシミュレーションテンプレートの作成

POST /api/v2/simulation

{
    "absolute_max_trip_duration": null,
    "acceptable_waiting_time": 900,
    "adjust_driver_breaks_enabled": true,
    "algo_optimize_quantity": "total_time",
    "algo_type": "dynamic",
    "allow_jump": false,
    "analytics_export_completed": false,
    "avg_journey_time_difference": null,
    "avg_planned_actual_journey_time_difference": null,
    "avg_waiting_time": null,
    "avg_waiting_time_difference": null,
    "bacchus_id": "2b3dfa37-594b-4a56-bffa-446c68e21a7d",
    "booking_end_time": null,
    "booking_start_time": null,
    "bookings_count": 0,
    "completed_at": null,
    "completed_bookings_count": 0,
    "completed_fixed_route_trips_count": null,
    "completed_odbs_trips_count": null,
    "conversion_rate": 100.0,
    "created_at": "2024-08-02T05:05:34.027934+00:00",
    "data": {
        "logistics_api_settings": {
            "algo_optimize_quantity": "total_time",
            "algorithm": "static",
            "allow_upload_after_simulation_start_time": false,
            "allow_vehicle_late": false,
            "average_travel_duration_to_node": 1200,
            "booking_penalty": 1000,
            "cvb_fleetmin_iterations_limit": 3000000,
            "cvb_fleetmin_solutions_limit": 30000,
            "cvb_fleetmin_time_limit": 600,
            "cvb_local_search_iterations_limit": 100000,
            "first_solution_strategies": [
                0
            ],
            "geofence_definition_strategy": "by_dropoff",
            "geofence_vehicle_allocation_strategy": "strict",
            "group_crossing_penalty": 10000.0,
            "guided_local_search_lambda_coefficient": 0.1,
            "lifo_order_check_on_all_vehicles": true,
            "lns_time_limit_ms": 1000,
            "log_search": false,
            "max_dropoff_slack": null,
            "max_pickup_slack": null,
            "max_possible_lateness": null,
            "mutually_exclusive_groups": [],
            "only_pdp": false,
            "optimization_step": 1,
            "path_equalizer_weight": 100,
            "pipeline_type": "simple_one_stage",
            "savings_neighbors_ratio": 1.0,
            "should_set_max_slack_start_location_zero": true,
            "solution_limit": 100000000,
            "stateless_api_login": null,
            "stateless_api_password": null,
            "stateless_api_server": null,
            "strictly_exclusive_groups": [],
            "time_limit_ms": 30000,
            "trip_cost": 0.0,
            "use_all_local_search_operators": false,
            "use_cvb_local_search_operator": false,
            "use_depth_first_search": false,
            "use_lifo_order_check": false,
            "use_local_search_metaheuristic": false,
            "use_local_search_operators": [],
            "use_mixed_time_matrix": false,
            "use_node_weights_cost": true,
            "use_path_equalizer": false,
            "use_tsp_opt": false,
            "use_walking_time_to_reduce_time_windows": false,
            "vehicle_amortized_linear_cost_factor": null,
            "vehicle_amortized_quadratic_cost_factor": null,
            "vehicle_cost": 1000.0,
            "vehicle_late_penalty_coefficient": 10,
            "waypoints_optimization_second_phase": false,
            "waypoints_solution_limit": 1000
        }
    },
    "dataset": "/api/v2/dataset/111",
    "dataset_csv_filename": null,
    "dataset_name": "Default dataset for project 111",
    "dead_mileage": null,
    "deleted": false,
    "deployment_label": null,
    "description": "",
    "driver_prep_time": 300,
    "dropoff_transit_stops": "/api/v2/transitstopset/111",
    "enable_offer_messages_generation": true,
    "enable_waypoints_cache": true,
    "end_time": "2021-01-01T23:59:59+00:00",
    "explicit_stops": null,
    "fixed_route_filter_model": null,
    "fixed_route_schedule": null,
    "geofence_id": "17103da2-4f92-4a82-8a93-b9b85f1af652",
    "geofence_name": "Default geofence for project testing",
    "geofences_zones": [],
    "high_priority_stops": null,
    "in_service_mileage": null,
    "is_processor_based": true,
    "journey_duration_source": "constant",
    "max_additional_journey_time": 900,
    "max_additional_journey_time_percent": 0.0,
    "max_advance_booking_window": 0,
    "max_journey_time_difference": null,
    "max_planned_actual_journey_time_difference": null,
    "max_waiting_time": null,
    "max_waiting_time_difference": null,
    "max_walking_distance": 0.0,
    "min_advance_booking_window": 0,
    "min_driver_rest_time": 360,
    "min_journey_time_difference": null,
    "min_planned_actual_journey_time_difference": null,
    "min_waiting_time": null,
    "min_waiting_time_difference": null,
    "mixed_fleet": true,
    "modified_at": "2024-09-12T08:29:12.287791+00:00",
    "name": "Default Monday Tuesday template simulation for project",
    "no_offer_count": null,
    "number_of_vehicles": 0,
    "odbs_trip_duration": 5400,
    "odbs_trips_per_vehicle_per_hour": null,
    "offer_generation_enabled": false,
    "order_tracking_enabled": true,
    "percentage_driver_rest_time": 8.0,
    "performance_tracker_enabled": true,
    "pickup_transit_stops": "/api/v2/transitstopset/673",
    "pricing": null,
    "processors": [],
    "project": "/api/v2/project/111",
    "project_name": "Testing",
    "recurrence": "RRULE:FREQ=WEEKLY;UNTIL=20240929T110000Z;BYDAY=WE,TH",
    "recurrence_priority": 0,
    "result": {
        "empty": true
    },
    "revenue": null,
    "road_network": "van",
    "routing_profile": null,
    "routing_settings": {},
    "simulation_mode": "template",
    "start_time": "2021-01-01T00:00:00+00:00",
    "state": "created",
    "template": null,
    "total_cost": null,
    "transfer_rate": null,
    "used_vehicles_count": null,
    "utilization_rate": null,
    "vehicle_capacity": 40,
    "vehicle_ordering_in_one_by_one_stage": 1,
    "walking_profile": null,
    "walking_settings": {},
    "write_events_log": true
}

応答には、作成されたシミュレーションオブジェクトが含まれます。

車両の追加

デフォルトのシミュレーションテンプレートは、各運用日のシミュレーションを作成するために使用されるため、各シミュレーションに複製される車両のリストを含めることもできます。次の例では、最小限の構成で車両が作成されます。このユースケースでは、車両にoperations_locations_groupを割り当てる必要があります。

ペイロードに含まれる容量と車両の特性に注意してください。たとえば、車両モデル4Wの場合、その容量は2000の任意の重量単位と7000000立方cmとして定義されます。

ヒント

車両の時間制約を有効にするには（その車両の稼働時間）、ペイロードにstart_timeとend_timeを設定してください。シミュレーションテンプレートから車両がコピーされると、稼働時間（日付ではなく）のみがコピーされ、時刻の日付部分は無視されます。 消費アプリケーションは、任意の<string><number>ペアの形式で容量のニーズを定義できます。予約が作成されると、容量制限付きルーティング問題を解決するために、これらの同じ容量名がオプティマイザで使用されます。

JSONペイロードを参照

車両の作成

POST /api/v2/vehicle

{
    "agent_id": "a69cf9fc-62a9-4585-8f5a-c82372438160",
    "capacity": {
        "bts": 1,
        "cbcm": 10000000,
        "weight": 3000
    },
    "characteristics": {
        "ALL": true,
        "Fridge": false,
        "Helper": false,
        "weight": 5
    },
    "color": "#FFFC66",
    "end_time": "2024-01-15T13:55:00+00:00",
    "geofence_ids": [
        2035
    ],
    "in_use": "enabled",
    "labels": [
        "10"
    ],
    "project": "/api/v2/project/<project_id>",
    "routing_engine_settings": {
        "batch_matrix_size": 50,
        "continue_straight": true,
        "curb": false,
        "key": "<your key>",
        "make_depot_zero": true,
        "osrme_timestamp_mode": "start_time",
        "road_network": "driving_thailand",
        "routing_engine_name": "osrme",
        "speed": null,
        "time_factor": 1,
        "URL": "<routing engine URL>",
        "use_speed_in_routing": false,
        "vehicle_model": "4W Jumbo"
    },
    "service_number": "4w jumbo-1",
    "simulation": "/api/v2/simulation/<simulation_id>",
    "start_time": "2024-01-14T22:00:00+00:00",
    "vehicle_cost": 25000,
    "operations_location_groups": ["/api/v2/operationslocationgroup/<operations_group_id>"]
}

警告

この記事のユースケースでは、異なる運用日に複数のシミュレーションテンプレートを使用するため、各simulation_templateを適切な車両で更新する必要があります。運用日間でフリートが変更されない場合は、各simulation_templateに同じ車両セットを作成する必要があります。 デフォルトのシミュレーションテンプレートまたはそのシミュレーションテンプレートに関連付けられている車両を更新しても、この変更前に作成されたシミュレーションは遡って変更されないことに注意してください。

予約テンプレートの追加

シミュレーションテンプレートは、予約、ノード、および車両の割り当てをキャプチャでき、指定されたルートを効果的に表します。シミュレーションテンプレートと通常のシミュレーションの違いは、テンプレートから通常のシミュレーションが作成されると、テンプレートからすべての予約、ノード、および車両が継承されることです。これにより、テンプレートはミルクランの静的ルートを保持できます。 予約をアップロードするには、通常の予約手順を適用できます。この場合、予約は一部の運用場所での集荷とデポでの降車を表します。作成時に、運用場所の時間枠が予約の関連ノードに適用されます。

ヒント

ペイロードで提供される容量と車両の特性に注意してください。たとえば、車両モデル4Wの容量は、2,000の任意の重量単位と7,000,000立方センチメートルとして定義されています。消費側のアプリケーションは、任意の<string><number>ペアの形式で必要な容量を指定できます。予約が作成されると、オプティマイザーはこれらの容量名を使用して、容量制限付きルーティング問題を解決します。

このユースケースでは、次を使用してアップロードを実行する必要があります

シミュレーションに予約をアップロードする

POST /api/v2/microservices/logisticsapi

JSONペイロードを参照

シミュレーションに注文（予約）をアップロードする

POST /api/v2/microservices/logisticsapi
{
  "calculation_uid": "e33e7240-96ba-4c4a-b958-f903eca9b422",
  "simulation_id": 1,
  "bookings": [
    {
      "uid": "a87fdfe8-29c6-4483-8fcd-49448362473d",
      "dropoff_postal_code": "2",
      "dropoff_location_name": "Dropoff name",
      "dropoff_location_lat": 13.8353723,
      "dropoff_location_lon": 100.5732801,
      "pickup_operations_location": "/api/v2/operationslocation/25",
      "min_pickup_time": "2021-08-17T08:59:10.073329+00:00",
      "max_pickup_time": "2021-08-17T09:14:10.073329+00:00",
      "min_dropoff_time": "2021-08-17T08:59:10.073329+00:00",
      "max_dropoff_time": "2021-08-17T09:59:10.073329+00:00",
      "demand": {
        "volume": 1
      },
      "data": {
        "some": "thing",
        "number": 1
      },
      "pickup_service_time": 0,
      "dropoff_service_time": 0,
      "groups": []
    }
  ],
  "upload_strategy": "clear_all"
}

リクエストは、システムに追加された注文（予約）IDのリストを返します。

車両への初期ルートの事前割り当て

上記の手順が完了すると、シミュレーション（その時点からシミュレーションテンプレートとして機能します）には、ミルクランの最適化されたルートを作成するために必要なすべてのデータが含まれます。繰り返しルールを適用して複数のシミュレーションが作成された場合は、個々のシミュレーションごとに最適化を実行する必要があります。

最適化は、最適化APIを介して実行する必要があります。これにより、最適化を実行するタスクを含む、必要なすべての処理ロジックが生成されます。タスクの一意の識別子は、このリクエストの応答本文で返されます。

ヒント

最適化プロセスは、設定、予約数、車両数によっては時間がかかる場合があります。したがって、最適化リクエストは非同期であり、コンシューマーはポーリングして、最適化の実行が完了するまで待機する必要があります。

シミュレーションに予約をアップロードする

POST /api/v2/microservices/logisticsapi_optimize

JSONペイロードを参照

シミュレーションに注文（予約）をアップロードする

POST /api/v2/microservices/logisticsapi
{
    "calculation_uid": <計算の任意の一意の識別子>,
    "simulation_id": <以前に作成されたシミュレーションID>,
    "bookings": [],
    "booking_uids": <予約のアップロードリクエストからの最適化に使用される予約識別子>
}

最適化の実行後、シミュレーションは、現場で実行できるすべての必要なデータ要素とともに、車両へのノードの割り当て（つまり、ルート）を生成します。ただし、ミルクランの状況では、これらの事前に生成されたルートが毎日（または他の繰り返しで）実行され、各運用スロットで最適化が必要ないという考え方です。これを実現するには、ルートが含まれているシミュレーションを、適用可能な繰り返しルールを持つテンプレートに変換して、各運用をテンプレートからインスタンス化できるようにします。

シミュレーションに予約をアップロードする

PATCH /api/v2/simulation/<simulation_id>

JSONペイロードを参照

シミュレーションに注文（予約）をアップロードする

PATCH /api/v2/simulation/<simulation_id>
{
  "simulation_mode":"template",
  "recurrence":"RRULE:FREQ=WEEKLY;UNTIL=20240929T110000Z;BYDAY=WE,TH"
 
}

ヒント

プロジェクトには、それぞれに繰り返しルールを持つ複数のシミュレーションテンプレートを含めることができ、そのルールに基づいて特定の時間または日にシミュレーションを自動的に生成する柔軟性を提供します。選択した時間または日に複数のテンプレートが利用可能な場合は、recurrence_priorityフィールドを使用して、優先度が最も高いシミュレーションを選択します。

アドホック注文のサポート

デフォルトでは、ロジスティクスアプリケーションはアドホックなリアルタイムの注文追加をサポートしておらず、ルートの自動再最適化もサポートしていません。ただし、処理エンジンの特定の構成により、注文の自動再最適化を実現できます。上記で説明したように、processorと呼ばれるエンティティを使用して、シミュレーションの最適化を実行します。各シミュレーションには、データの分割、異なるパラメーターセットでの最適化の実行、または特定のフリートのみの最適化に潜在的に使用できる複数のプロセッサーを関連付けることができます。

プロセッサーがテンプレートであるシミュレーションに接続されている場合、プロセッサーは、そのテンプレートから作成されたシミュレーションのインスタンスにもコピーされ、処理ワークフローの設定の複雑さが軽減されます。

ユースケースごとに、注文を自動的に処理する必要がある2つのケースがあります。

• 運用中にアドホック注文が到着し、可能であれば車両に割り当てる必要があります。
• 未割り当ての注文、または集荷に失敗した注文は、次のドライバーのシフトに自動的に割り当てる必要があります。

注文の自動挿入

注文の自動挿入は、continuousタイプのプロセッサを作成することによって実現されます。これは、設定されたルールに基づいて新しいオブジェクトが変更または表示されるのを待って、継続的に実行されることを意味します。また、特定の時間境界内で実行されます。シミュレーション用にこのようなプロセッサを作成するには（これはシミュレーションテンプレートまたは実際のシミュレーションに対して実行できます。この場合、テンプレート用に作成することを検討します）、次のリクエストを実行します。

ライブシミュレーションプロセッサの作成

POST /api/v2/simulationprocessor

JSONペイロードを参照

シミュレーションに注文（予約）をアップロードする

POST /api/v2/simulationprocessor
// 最初に既存のプロセッサをクリーンアップし、テンプレートから削除します
{
    "bookings_filter_expression": {
        "state__in": [
            // 準備済みの予約は、アップロードされたばかりで、ノードが作成され、最適化の準備ができている予約です
            "prepared"
        ]
    },
    "calculation_parameters_logistics": "/api/v2/logisticscalculationparameters/43859",
    "calculation_parameters_regenerator": {},
    "fault_tolerant": false,
    "geofences_zones": [],
    "processor_lifecycle_type": "continuous",
    "processor_type": "logistics",
    // このプロセッサが属するシミュレーション
    "simulation": "/api/v2/simulation/124868",
    "vehicle_selectiSon_by_emptiness": false,
    "vehicle_selection_in_service": false,
    "vehicle_selection_in_use": true,
    // オプションで、アドホック挿入を許可するために特定の車両のみを選択できます。たとえば、特定のラベルを持つ車両などです。
    "vehicles_filter_expression": {
            "label__in": [
            "adhoc"
        ]
    },
    //タイムスタンプは、たとえば最初のシフトの午前8時から午前11時までの運用時間境界を表す必要があります
    "schedule_after": "2024-10-20T09:00:00+00:00",
    "start_time": "2024-10-20T09:00:00+00:00",
    "end_time": "2024-10-21T11:00:00+00:00",
    "state":"new"
}

警告

テンプレートに未使用または不要なプロセッサがないことを確認し、それらを削除してください。プロセッサはシミュレーションがインスタンス化されると実行を開始し、予期しない結果を生成する可能性があります。

この例では、プロセッサは、シミュレーションにprepared状態の新しい予約が表示された場合にのみシミュレーションを実行します。プロセッサのアクティビティ時間は、start_timeおよびend_timeフィールドで設定されます。車両にフィルターを適用する必要がある場合（予約のように）、ルールに従ってvehicle_filter_expressionを使用できます。このプロセッサはシミュレーションテンプレート用に作成されているため、開始されません。このテンプレートからシミュレーションのインスタンスが作成された場合にのみ開始されます。すべての時間は、そのシミュレーションインスタンスの時間境界に合わせて調整されます。

シミュレーション用に、シフトごとに1つずつ、複数のプロセッサを生成できます。最適化中、プロセッサは現在の車両の位置と、シミュレーションですでに履行されている注文を考慮します。ただし、注文を割り当てる実際の機能は、プロセッサがすべての制約を満たしているかどうかに依存します。フリートに予備の容量がない場合、新しい注文は割り当てられない可能性があります。シフトごとに1つのcontinuousプロセッサをスケジュールすることをお勧めします。

未割り当ての注文の後続シフトへの自動再割り当て

配送に失敗した注文または未割り当ての注文を再割り当てするロジックを有効にするには、regeneratorタイプのプロセッサを使用する必要があります。 実行されると、フィルタリング基準を満たすすべての予約とノードが調整されます（したがって、このプロセッサは、目的の時刻に正確に1回実行されるようにsingle shotとして構成する必要があります）。 Regeneratorパイプラインは、booking_filter_expression設定を満たすすべてのbookingsに対して次のルールを実行します。

• Booking.stateをPREPAREDにリセットします
• Node.stateをNEWにリセットします
• Node.assigned_vehicleをNoneにリセットします
• Node.scheduled_tsをNoneにリセットします
• （オプション）Booking.min_pickup_timeをprocessor.calculation_parameters_regenerator['min_pickup_time']にリセットします
• （オプション）Booking.max_pickup_timeをprocessor.calculation_parameters_regenerator['max_pickup_time']にリセットします
• （オプション）Booking.min_dropoff_timeをprocessor.calculation_parameters_regenerator['min_dropoff_time']にリセットします
• （オプション）Booking.max_dropoff_timeをprocessor.calculation_parameters_regenerator['max_dropoff_time']にリセットします
• （オプション）（集荷）Node.open_time_tsをprocessor.calculation_parameters_regenerator['min_pickup_time']にリセットします
• （オプション）（集荷）Node.close_time_tsをprocessor.calculation_parameters_regenerator['max_pickup_time']にリセットします
• （オプション）（降車）Node.open_time_tsをprocessor.calculation_parameters_regenerator['min_dropoff_time']にリセットします
• （オプション）（降車）Node.close_time_tsをprocessor.calculation_parameters_regenerator['max_dropoff_time']にリセットします

未割り当ておよび失敗した予約を新しいシフトに移動する

POST /api/v2/simulationprocessor

JSONペイロードを参照

シミュレーションに注文（予約）をアップロードする

POST /api/v2/simulationprocessor
// 最初に既存のプロセッサをクリーンアップし、テンプレートから削除します
{
    "bookings_filter_expression": {
        "state__in": [
          // ドライバーが注文の集荷に失敗しました
          "fail_to_board",
          // 注文を配送するのに十分な容量がありませんでした
          "rejected_by_system"
        ]
    },
    "calculation_parameters_logistics": "/api/v2/logisticscalculationparameters/43859",
    "calculation_parameters_regenerator": {
      // ノードは、次のシフト内のこの時間枠でスケジュールする必要があります
      // これはオプションです。設定しない場合、ノードの元の時間枠が適用されます
      "min_pickup_time": "2024-10-20T11:00:00+00:00",
      "max_pickup_time": "2024-10-20T15:00:00+00:00",
      "min_dropoff_time": "2024-10-20T16:00:00+00:00",
      "max_dropoff_time": "2024-10-20T16:00:00+00:00",
    },

    "fault_tolerant": false,
    "geofences_zones": [],
    // プロセッサを1回だけ実行します
    "processor_lifecycle_type": "one_shot",
    "processor_type": "regenerator",
    // このプロセッサが属するシミュレーション
    "simulation": "/api/v2/simulation/124868",
    "vehicle_selectiSon_by_emptiness": false,
    "vehicle_selection_in_service": false,
    "vehicle_selection_in_use": true,
    "vehicles_filter_expression": {},
    //  次のシフトが始まる直前にスケジュールします
    "schedule_after": "2024-10-20T10:45:00+00:00",
    "state":"new"
}

警告

この例では、ノードの時間枠が変更され、最初の配送スケジュールから逸脱する可能性があります。ノードの時間枠が後続の配送シフトと重複する場合、またはノードに複数の時間枠がある場合は、calculation_parameters_regeneratorは必要ありません。このシナリオでは、元のノードの時間枠が保持されます。

シミュレーションには、シフトごとにregeneratorタイプの複数のプロセッサを含めることができます。

日常業務

すべての構成が完了し、必要なシミュレーションテンプレートが作成されると、運用計画のワークフローは、FMCGなどの他のユースケースと同様になります。ただし、重要な違いがあります。テンプレートからシミュレーションが確立されると、すでに車両に事前に割り当てられたルートがあり、シミュレーションにアップロードされた予約は追加（アドホック）のものとして扱われます。したがって、upload_strategyフラグがkeep_assignedに設定されていれば、既存の所定のルートとともに自動的に最適化されます。予約はいつでもアップロードでき、利用可能なフリート容量に応じて、現在のシフトに追加するか、次のシフトにプッシュすることができます。手順のシーケエンスには、次のものが含まれます。

• シミュレーションテンプレートからのシミュレーションの作成
• 予約のアップロード

1日の締めくくり

すべてのシフトがスケジュールされ、実行するregeneratorタイプのプロセッサが残っていない場合、その日は終了です。シミュレーションの終了時刻に、すべてのアクティブなcontinuousプロセッサが終了し、その日の完了を示します。