コンテンツにスキップ
utm-backend Docs

飛行計画 状態遷移図

課題事項

Section titled “課題事項”
  • デモでは一時保存機能を提供しないが、状態としては飛行計画仮登録の実行によりDRAFTを経由する設計とする。
  • 未確認: キャンセルを伴わないDIPS通報の取り下げ（Withdraw）のユースケース有無が未確認。現在の設計では WITHDRAWNへは「飛行計画キャンセル」経由でのみ遷移し、飛行計画を有効なまま残してDIPS通報だけを取り下げる 手段は用意していない。ユースケースが有ると確認された場合は、REPORTED --> UNREPORTED相当の遷移と専用APIの 追加を検討する。

飛行計画ステータス（status）の遷移

Section titled “飛行計画ステータス（status）の遷移”

API設計注記: 飛行開始・飛行終了・キャンセルは、1つの汎用ステータス更新API（status値による分岐）ではなく、 start/end/cancelという遷移先ごとに独立したAPIに分離する。副作用（ENDEDは飛行実績の保存、 CANCELLEDはDIPS側の削除）が遷移ごとに大きく異なるため。詳細はflight-planning.yamlの 該当パス付近のコメントを参照。

stateDiagram-v2
    [*] --> DRAFT : 飛行計画仮登録

    DRAFT --> DRAFT : 飛行計画更新（一時保存の更新）
    DRAFT --> ACCEPTED : 飛行計画本登録

    ACCEPTED --> ACCEPTED : 飛行計画更新（登録後の更新）

    ACCEPTED --> ACTIVATED : 飛行計画開始

    ACTIVATED --> ACTIVATED : 飛行計画更新（飛行中の更新）

    ACTIVATED --> ENDED : 飛行計画終了

    ENDED --> [*]

    DRAFT --> [*] : 飛行計画キャンセル（削除と同等。deleted_atを設定し取得対象外）
    ACCEPTED --> CANCELLED : 飛行計画キャンセル
    CANCELLED --> [*]

各状態の説明

Section titled “各状態の説明”
  • DRAFT（一時保存）: 「飛行計画仮登録」（POST /flight-plans）/「飛行計画更新」（PUT /flight-plans/{id}、DRAFTの間は緩い検証） APIで保存される下書き状態。必須項目はnameのみで、他項目は未入力のまま保存できる。空域制限との競合判定は行わない。
  • ACCEPTED（本登録済み）: 「飛行計画本登録」（POST /flight-plans/{id}/registration）APIで全入力項目が揃っていることを 検証したうえで本登録された状態。DRAFTから遷移する経路（本来の設計）と、初期状態から直接遷移する経路（デモ向け）の 2通りがある。ACCEPTED以降はDRAFTに戻らない設計とし、本登録後の内容変更は「飛行計画更新」が同じ検証・競合判定を その場で行う（本登録APIを再度呼び出す必要はない）。
  • ACTIVATED（飛行中）: 「飛行計画開始」（POST /flight-plans/{id}/start）により、実際に飛行を開始した状態。 通報不要な飛行計画、または通報済み（reportStatus=REPORTED）の場合のみ本状態へ遷移可能（それ以外の場合は飛行開始不可）。
  • ENDED（終了）: 「飛行計画終了」（POST /flight-plans/{id}/end）により運航が完了した状態。飛行実績が データベースに保存される。終端状態。本状態とACTIVATEDは削除できない（deleteFlightPlanは409）。 飛行終了ではreportStatusがREPORTEDのまま残るため、削除するとDIPSへの取り下げが走り、実際に行われた 飛行の通報を取り下げることになるからである（flight-plan-er.mdの FLIGHT_PLAN.deleted_atのカラム補足を参照）。
  • CANCELLED（中止・取消）: 「飛行計画キャンセル」（POST /flight-plans/{id}/cancel）により中止（取消）された 状態。DIPS通報済み（reportStatus=REPORTED）の場合は、あわせてDIPS側の飛行計画も削除（取り下げ）される。終端状態。 本状態へ到達するのはACCEPTED以降からのキャンセルのみで、この場合は論理削除せず、キャンセル後も取得できる。 DRAFTからのキャンセルは削除と同等の扱いとし、statusはDRAFTのままdeleted_at（論理削除）を設定して getFlightPlan・listFlightPlansの取得対象から外す（行を物理削除しないのはIdempotency-Keyの再送契約のため。 statusが変わらないため状態遷移イベントも追記しない）。したがって上図ではDRAFTからのキャンセルを DRAFT --> [*]として表し、本状態へは入らない（flight-plan-er.mdの 「一時保存は専用テーブルで表す」節を参照）。なおcancelFlightPlanの応答はDRAFT対象でもOAS契約どおり status=CANCELLEDを返す（DBのstatusはDRAFTのままだが、論理削除により以後取得できないため観測されない）。

DIPS通報状態（report_status）の遷移

Section titled “DIPS通報状態（report_status）の遷移”
stateDiagram-v2
    [*] --> UNREPORTED : 飛行計画本登録

    UNREPORTED --> REPORTING : 飛行計画通報（DIPS API呼び出し前に更新）
    REPORTED --> REPORTING : 飛行計画通報（再通報。DIPS側の通報時刻を最新化する）
    REPORTING --> REPORTED : DIPS通報完了（受理・競合いずれの結果でも）
    REPORTING --> UNREPORTED : DIPS API呼び出し失敗（503：接続不可・DIPS停止・業務エラー等／<br/>502：応答を解釈できない）
    REPORTING --> REPORTED : 再通報のDIPS API呼び出し失敗（通報前の状態へ戻す。<br/>DIPS側には前回の通報が残っているため）
    REPORTING --> REPORTING : DIPS API呼び出しタイムアウト（504、成否不明。ADR-022の残課題）<br/>REPORT_TIMEOUTイベントとして記録

    REPORTED --> UNREPORTED : 飛行計画更新
    REPORTED --> WITHDRAWING : 飛行計画キャンセル・削除（DIPS API呼び出し前に更新）
    WITHDRAWING --> WITHDRAWN : DIPS側の飛行計画削除完了
    WITHDRAWING --> REPORTED : DIPS API呼び出し失敗（503：認証エラー・接続不可・業務エラー等／<br/>502：応答を解釈できない）
    WITHDRAWING --> WITHDRAWING : DIPS API呼び出しタイムアウト（504、成否不明。ADR-022の残課題）<br/>WITHDRAW_TIMEOUTイベントとして記録

    UNREPORTED --> [*] : DIPS通報不要
    REPORTED --> [*]
    WITHDRAWN --> [*]

各状態の説明

Section titled “各状態の説明”
  • UNREPORTED（未通報）: DIPS通報が完了していない状態。飛行計画本登録時の初期値。通報済み（REPORTED）の飛行計画を更新 した場合や、DIPS API呼び出しがタイムアウト以外で失敗した場合（503・502）もREPORTINGからこの状態に戻り、Operatorが 「飛行計画通報」APIを再試行できるようにする。タイムアウト（504）は成否不明のため本状態に戻さない（下記参照）。
  • REPORTING（通報中）: 「飛行計画通報」APIによるDIPS API呼び出し中の中間状態。タイムアウト以外の失敗（503・502）は UNREPORTEDに戻る。502（応答は届いたが解釈できない）はDIPS側に登録が成立している可能性が残るが、 10月デモでは再通報できることを優先してUNREPORTEDに戻す。 タイムアウト（504）は成否不明で、UNREPORTEDに戻すと重複登録になりうるためこの状態のまま 保留される（状態確認手段は未整備。ADR-022の残課題）。
  • REPORTED（通報済み）: DIPSへの飛行計画通報が完了した状態。受理・競合いずれの結果でも本状態になる。この状態の飛行計画を更新して内容が変わるとUNREPORTEDに戻り、再通報が 必要になる（内容が変わらない更新ではリビジョンを作らず本状態を維持する。 BusinessLogicSpecifications.md5.2節手順3-2）。本状態からの再通報も可能で、内容が変わって いなくてもDIPS側の通報時刻が最新化される（UNREPORTEDへ戻す遷移が漏れた場合のフェールセーフに もなる）。再通報では前回の受付番号を送る更新扱いになるため二重登録にはならず、失敗した場合は DIPS側に前回の通報が残っているため本状態へ戻す。
  • WITHDRAWING（取り下げ中）: 「飛行計画キャンセル」（POST /flight-plans/{id}/cancel）または「飛行計画削除」 （DELETE /flight-plans/{flightPlanId}）による、DIPS側の飛行計画削除APIの呼び出し中の中間状態。 タイムアウト以外の失敗（503・502）はREPORTEDに戻る。502（応答は届いたが解釈できない）はDIPS側で 取り下げが成立している可能性が残るが、通報時（REPORTING）と同じく再試行できることを優先して REPORTEDに戻す。 タイムアウト（504）は成否不明で、REPORTEDに戻すと二重の削除要求になりうるためこの状態のまま保留される（状態確認手段は未整備。ADR-022の残課題）。
  • WITHDRAWN（取り下げ済み）: 通報済みの飛行計画が「飛行計画キャンセル」または「飛行計画削除」により、DIPS側の 飛行計画を削除（取り下げ）した状態。終端状態。