メインコンテンツまでスキップ

配達またはピックアップの ETA (ETA for a delivery or pickup)

SWAT システムでは、見積もり時間はドライバーとエンドカスタマーの両方の期待を管理するために重要です。ノード

(ピックアップ/ドロップオフ) で利用できるタイムスタンプには主に3つのタイプがあります。

  • 計画スケジュール (scheduled_ts): 初期の最適化中に計算されます。これがベースラインプランです。
  • 現実的な ETA (estimated_scheduled_ts): 最も正確なリアルタイム予測。現在の車両位置、前の停留所のサービス時間、およびルート制約を考慮します。
  • 楽観的 ETA (estimated_earliest_arrival_ts): 車両がノンストップで運転した場合の物理的に最も早い到着を表し、一部のサービスバッファを無視します。

ETA 計算ロジック (ETA Calculation Logic)

estimated_scheduled_ts は、コンシューミングアプリケーションに推奨されるフィールドです。これは動的に更新され、次のように計算されます。

Estimated time logic
# It cannot be earlier than the 'earliest physical arrival'
# AND it cannot be earlier than the node's scheduled open time (earliness constraint)
estimated_scheduled_ts = max(estimated_earliest_arrival_ts, node.open_time_ts)
備考

車両が早く(open_time_ts の前に)到着した場合、待機する必要があります。この待機時間は estimated_scheduled_ts に暗黙的に含まれています。

更新頻度 (Update Frequency)

  • トリガー: 更新はシミュレーションごとに約 5分 ごとに行われます。
  • スコープ: 割り当てられたノードを持つ車両のみが更新されます。
  • 条件: 車両はオンライン(GPS を送信中)であるか、有効な開始時刻を持っている必要があります。

イベントライフサイクルの例 (Event Lifecycle Example)

ETA がどのように進化するかを理解するために、配達ノード "B" のライフサイクルを見てみましょう。

シナリオ:

  • ノード A: 開始/ピックアップ(サービス時間: 5分)
  • ノード B: ドロップオフ(時間枠: 午前10:00 - 午前11:00)
  • 移動 A -> B: 10分。

1. 最適化フェーズ (Optimization Phase)

ルートが計画されます。

  • scheduled_ts: 10:00 AM (計画到着)。
  • estimated_scheduled_ts: 10:00 AM

2. 実行フェーズ(定刻) (Execution Phase (On Time))

車両は午前9:45に A を出発します。

  • estimated_earliest_arrival_ts: 9:45 AM + 10分運転 = 9:55 AM
  • estimated_scheduled_ts: max(9:55 AM, 10:00 AM オープンウィンドウ) = 10:00 AM
  • 車両はその場所で5分間待機します

3. 実行フェーズ(遅延) (Execution Phase (Delayed))

渋滞が発生します。車両は午前9:55に A を出発します。

  • estimated_earliest_arrival_ts: 9:55 AM + 15分運転(渋滞) = 10:10 AM
  • estimated_scheduled_ts: max(10:10 AM, 10:00 AM) = 10:10 AM
  • システムは当初のスケジュールと比較して10分の遅延を予測しています。

ノードデータフィールド (Node Data Fields)

フィールド説明
scheduled_tsベースライン。最適化エンジンからの計画到着時間。
estimated_scheduled_tsベスト ETA。最も現実的な予想到着時間。約5分ごとに再計算されます。
estimated_earliest_arrival_ts楽観的 ETA。一部の制約を無視した物理的に最も早い到着。
arrived_to_location_ts実際。ドライバーが「到着」とマークしたタイムスタンプ。
completed_service_at実際。ノードが「完了」とマークされたタイムスタンプ。
failed_to_deliver_at_ts実際。配達が失敗した場合のタイムスタンプ(例:顧客不在)。
slack車両がサービスを開始する前にこの場所で待機すると予想される時間量。
service_timeこのノードのサービスに必要な期間(例:積み込み/荷降ろし)。

ETA の取得 (Retrieving ETA)

レイテンシ要件に応じて、ETA データにアクセスする方法は3つあります。

注文と配達追跡に関するより広範な統合コンテキストについては、注文と POD の統合 ガイドを参照してください。

1. ポーリングノードデータ (Polling Node Data)

特定のノードをクエリして、最新のステータスとタイムスタンプを取得できます。

GET /api/v2/node/{node_id}

JSON レスポンスを表示
{
"id": 50801567,
"node_type": "dropoff",
"status": "assigned",
"scheduled_ts": "2024-10-08T06:36:39+00:00",
"estimated_scheduled_ts": "2024-10-08T06:36:39+00:00",
"estimated_earliest_arrival_ts": "2024-10-08T06:32:00+00:00",
"arrived_to_location_ts": null,
"completed_service_at": null,
"slack": 238.8,
"service_time": 180,
"booking": "/api/v2/booking/23286180"
}

リアルタイムの更新については、vehicle_arrival イベントをサブスクライブしてください。これにより、シミュレーション内のすべての車両の更新がプッシュされます。

  • エージェントタイプ: vehicle_group
  • メッセージタイプ: vehicle_arrival
Vehicle Arrival Event
{
"simulation_id": 123,
"agent_type": "vehicle_group",
"message_type": "vehicle_arrival",
"data": {
"vehicle_id": 101,
"booking_id": 5002,
"booking_uid": "uuid-1234",
"node_id": 9001,
"estimated_earliest_arrival_ts": "2025-04-01T12:00:00+00:00",
"estimated_scheduled_ts": "2025-04-01T12:05:00+00:00",
"scheduled_ts": "2025-04-01T12:00:00+00:00"
},
"current_sim_ts": "2025-04-01T11:55:00+00:00"
}

構成の詳細については、ウェブフックドキュメント を参照してください。

3. クライアント側の計算(ルーティング API) (Client-Side Calculation (Routing API))

オンデマンドで ETA が必要で、5分ごとの更新サイクルを待つことができない場合(例:スムーズなドライバーアプリ UI のため)、Routing API + 車両位置を使用して計算できます。

  1. 車両の次の割り当てられたノードを取得します: GET /api/v2/vehicle/<vehicle_id>/assigned_nodes
  2. 現在の GPS から次のノードまでのルートを取得します: GET /vehicle_route_proxy/<vehicle_id>/<current_gps_lat,lon>;<node_lat,lon>
ルートレスポンスを表示
{
"code": "Ok",
"routes": [
{
"duration": 149.6,
"distance": 832.1,
"legs": [
{ "duration": 133.7, "distance": 771.4 }
]
}
],
"waypoints": [
{ "location": [100.516, 13.690] },
{ "location": [100.518, 13.692] }
]
}

計算: ETA = CurrentTime + route.duration