JP2019164003A - 移動体の管理システム及びその制御方法並びに管理サーバ - Google Patents

Abstract

【課題】飛行制限場所の動的な変化を好適に行うことが可能な管理システム及びその制御方法並びに管理サーバを提供する。【解決手段】管理システム１０の移動管理部４０又は管理サーバ２２は、動的計画変更部１００を備える。動的計画変更部１００は、出発地Ｐｓｔから目的地Ｐｔａｒの間で行われる外部イベントＥに関する情報である外部イベント情報Ｉｅｅを外部機器２８から受信し、外部イベント情報Ｉｅｅに基づいて自律移動体２６の移動計画又は動作状態を変更する。【選択図】図１

Description

本発明は、複数の移動体の移動を管理する管理システム及びその制御方法並びに管理サーバに関する。

特許文献１では、飛行制限区域に応じた飛行が可能なシステム、方法及び装置が開示されている（要約）。特許文献１では、無人飛行体（ＵＡＶ：unmanned aerial vehicle）の位置が、飛行制限区域と比較される。必要に応じて、ＵＡＶは、飛行禁止区域への進入を回避するための対応を取る。飛行制限区域としては、例えば空港が挙げられている（［０００３］、［０００４］）。

米国特許出願公開第２０１５／０３３９９３１号明細書

上記のように、特許文献１では、ＵＡＶの位置を飛行制限区域と比較し、必要に応じて、ＵＡＶは、飛行禁止区域への進入を回避するための対応を取る（要約）。飛行制限区域としては、例えば空港が挙げられている（［０００３］、［０００４］）。

飛行制限区域については、「制限」の程度を複数設けることが可能である。例えば、小学生が通学中の通学経路については、通学の間のみ、飛行を禁止することも考えられる。また、屋外コンサート会場及びその周辺については、コンサートの開催中及びその前後のみ、飛行を禁止することが考えられる。換言すると、時間帯又は人数に応じて、飛行制限区域（飛行制限領域）を動的に変化させることが可能である。

しかしながら、特許文献１では、飛行制限領域又は飛行制限地点としての飛行制限場所を動的に変化させることについては考慮されていないように見受けられる。これらの課題は、飛行体に限らず、自律的な移動を行うその他の自律移動体（自動車、船舶等）にも該当する。

本発明は上記のような課題を考慮してなされたものであり、飛行制限場所の動的な変化を好適に行うことが可能な移動体の管理システム及びその制御方法並びに管理サーバを提供することを目的とする。

本発明に係る管理システムは、
出発地から目的地まで移動するための自律制御部を備えた少なくとも１台の自律移動体と、
通信装置を介して前記自律移動体と通信し、前記自律移動体を含む複数の移動体の移動を管理する移動管理部と
を備えるものであって、
前記移動管理部は、前記出発地から前記目的地の間で行われる外部イベントに関する情報である外部イベント情報を外部機器から受信し、前記外部イベント情報に基づいて前記自律移動体の移動計画又は動作状態を変更する動的計画変更部を備える
ことを特徴とする。

本発明によれば、自律移動体の出発地から目的地の間で行われる外部イベントに関する外部イベント情報に基づいて自律移動体の移動計画又は動作状態を変更する。これにより、外部イベントの影響を、自律移動体の移動計画又は動作状態に反映することが可能となる。従って、飛行制限場所の動的な変化を好適に行うことが可能となる。

前記外部イベント情報は、前記外部イベントが行われる時刻若しくは時間帯、前記外部イベントの混雑度合い、又は前記外部イベントに伴う交通量を含んでもよい。これにより、外部イベントの影響を、自律移動体の移動計画又は動作状態に精度良く反映することが可能となる。

前記外部イベント情報は、前記外部イベントの会場に存在する物品の評価額情報を含んでもよい。これにより、例えば、外部イベントの会場に高額な物品が配置されている場合、自律移動体の移動計画又は動作状態に反映することが可能となる。

前記外部機器から前記外部イベント情報を受信したとき、前記移動管理部は、前記自律移動体の移動が一時的に制限される領域又は地点としての一時的移動制限場所を前記外部イベント情報に基づいて設定してもよい。また、前記移動管理部は、前記自律移動体の前記移動計画又は前記動作状態を前記一時的移動制限場所に基づいて変更してもよい。これにより、一時的移動制限場所を考慮して、自律移動体の移動計画又は動作状態を変更することが可能となる。

前記管理システムは、前記複数の移動体の個体毎又は種類毎の優先度である移動体優先度を蓄積した優先度データベースを備えてもよい。また、前記移動管理部は、前記移動体優先度に基づいて前記自律移動体の前記移動計画又は前記動作状態を変更してもよい。これにより、自律移動体の移動計画又は動作状態に移動体優先度を反映させることが可能となる。

前記移動管理部は、前記自律移動体の予定経路を算出する際、前記予定経路の候補上において、前記自律移動体の予定移動時刻又は予定移動時間帯に前記外部イベントが行われる場合、前記予定移動時刻又は前記予定移動時間帯をずらして前記予定経路を算出してもよい。これにより、時間的に外部イベントを避けて自律移動体を移動させることが可能となる。

本発明に係る制御方法は、
出発地から目的地まで移動するための自律制御部を備えた少なくとも１台の自律移動体と、
通信装置を介して前記自律移動体と通信し、前記自律移動体を含む複数の移動体の移動を管理する移動管理部と
を備える管理システムの制御方法であって、
前記移動管理部の動的計画変更部は、
前記出発地から前記目的地の間で行われる外部イベントに関する情報である外部イベント情報を外部機器から受信し、
前記外部イベント情報に基づいて前記自律移動体の移動計画又は動作状態を変更する
ことを特徴とする。

本発明に係る管理サーバは、出発地から目的地まで移動するための自律制御部を備えた少なくとも１台の自律移動体と通信し、前記自律移動体を含む複数の移動体の移動を管理するものであって、
前記管理サーバは、前記出発地から前記目的地の間で行われる外部イベントに関する情報である外部イベント情報を外部機器から受信し、前記外部イベント情報に基づいて前記自律移動体の移動計画又は動作状態を変更する動的計画変更部を備える
ことを特徴とする。

本発明によれば、飛行制限場所の動的な変化を好適に行うことが可能となる。

本発明の一実施形態に係る管理システムの概要を示す全体構成図である。 前記実施形態において、顧客から発注された商品を、配送ドローンで配送する際の概要を示すフローチャートである。 前記実施形態の受注時制御のフローチャートである。 前記実施形態の受注時制御において、予定経路を算出するフローチャート（図３のＳ７５の詳細）である。 図５Ａは、前記実施形態において経路評価値の算出を説明する第１説明図であり、図５Ｂは、前記実施形態において経路評価値の算出を説明する第２説明図である。 前記実施形態の受注時制御により設定される前記予定経路の例を示す図である。 前記実施形態において、交通管理サーバに対して外部イベントの申請があるときの流れの概要を示すフローチャートである。 前記実施形態における外部イベント関連制御のフローチャートである。 前記実施形態における外部イベント申請画面の一例を示す図である。 前記実施形態におけるイベント領域画像の変化の一例を示す図である。

Ａ．一実施形態
＜Ａ−１．構成＞
［Ａ−１−１．全体構成］
図１は、本発明の一実施形態に係る管理システム１０の概要を示す全体構成図である。管理システム１０は、複数の発注端末２０と、少なくとも１台のサービス管理サーバ２２（以下「サービスサーバ２２」ともいう。）と、少なくとも１台の交通管理サーバ２４（以下「交通サーバ２４」ともいう。）と、複数の配送ドローン２６と、複数の申請端末２８と、複数のエンタテインメントドローン３０と、複数のリモートコントローラ３２と、少なくとも１台の通信管理サーバ３４とを有する。サービスサーバ２２と交通サーバ２４は、移動管理部４０を構成する。

図１では、発注端末２０、サービスサーバ２２、交通サーバ２４、配送ドローン２６、申請端末２８、エンタテインメントドローン３０、リモートコントローラ３２及び通信管理サーバ３４を、それぞれ１台のみ示している。管理システム１０では、発注端末２０を介して入力された商品Ｇの発注情報Ｉｏｄｒに基づいて、配送ドローン２６が商品Ｇを配送する。

また、申請端末２８から交通サーバ２４に対して、エンタテインメントドローン３０の飛行許可申請が行われる。飛行許可申請が許可された場合、エンタテインメントドローン３０のユーザは、許可された条件に従って、リモートコントローラ３２を介してエンタテインメントドローン３０を飛行させることができる。配送ドローン２６の予定経路ＲＴｐは、エンタテインメントドローン３０の飛行等の外部イベントＥに伴って変更される。

発注端末２０とサービスサーバ２２の間、サービスサーバ２２と交通サーバ２４の間、交通サーバ２４と申請端末２８の間及び交通サーバ２４と通信管理サーバ３４の間は、インターネット６０を介して通信可能である。また、サービスサーバ２２と配送ドローン２６の間は、インターネット６０及び無線中継局６２を介して通信可能である。エンタテインメントドローン３０とリモートコントローラ３２の間は、無線通信（電波通信等）を介して通信可能である。

［Ａ−１−２．発注端末２０］
発注端末２０は、サービスサーバ２２が取り扱う商品Ｇについて第１ユーザ（発注者）からの発注を受け付ける第１外部機器である。発注端末２０は、例えば、パーソナルコンピュータ又はスマートフォンから構成される。発注端末２０は、第１表示部７０を有する。

［Ａ−１−３．サービス管理サーバ２２］
サービス管理サーバ２２は、特定の企業が管理するサーバであり、当該企業の受注管理、在庫管理及び配送管理を行う。受注管理では、発注端末２０からの発注（サービスの要求）を受け付ける。在庫管理では、商品Ｇの在庫管理を行う。配送管理では、商品Ｇの配送（複数の配送ドローン２６の移動）を管理する。

図１に示すように、サービスサーバ２２は、入出力部８０と、通信部８２と、演算部８４と、記憶部８６とを含む。通信部８２は、インターネット６０を介することで、発注端末２０、交通サーバ２４、配送ドローン２６等との通信が可能である。

演算部８４は、中央演算装置（ＣＰＵ）を含み、記憶部８６に記憶されているプログラムを実行することにより動作する。演算部８４が実行する機能の一部は、ロジックＩＣ（Integrated Circuit）を用いて実現することもできる。演算部８４は、前記プログラムの一部をハードウェア（回路部品）で構成することもできる。

演算部８４は、配送管理部９０と、飛行制御部９２とを有する。配送管理部９０は、商品Ｇの配送を管理する。飛行制御部９２は、配送ドローン２６の飛行を制御する。配送管理部９０は、外部イベント情報Ｉｅｅ（後述）に基づいて、各配送ドローン２６の移動計画及び動作状態を動的に変更する動的計画変更部１００を有する。動的計画変更部１００は、各配送ドローン２６の予定経路ＲＴｐを算出する経路算出部１１０を有する。

記憶部８６は、演算部８４が用いるプログラム及びデータを記憶するものであり、ランダム・アクセス・メモリ（以下「ＲＡＭ」という。）を備える。ＲＡＭとしては、レジスタ等の揮発性メモリと、ハードディスク、フラッシュメモリ等の不揮発性メモリとを用いることができる。また、記憶部８６は、ＲＡＭに加え、リード・オンリー・メモリ（ＲＯＭ）を有してもよい。

記憶部８６は、注文データベース１２０（以下「注文ＤＢ１２０」という。）と、在庫データベース１２２（以下「在庫ＤＢ１２２」という。）と、移動体データベース１２４（以下「移動体ＤＢ１２４」という。）と、第１地図データベース１２６（以下「第１地図ＤＢ１２６」という。）と、配送データベース１２８（以下「配送ＤＢ１２８」という。）とを有する。

注文ＤＢ１２０は、各発注端末２０を介して受け付けた注文に関する情報（発注情報Ｉｏｄｒ）を蓄積する。在庫ＤＢ１２２は、在庫に関する情報（在庫情報Ｉｓｔｋ）を蓄積する。移動体ＤＢ１２４は、配送ドローン２６に関する個体情報Ｉｉを蓄積する。また、個体情報Ｉｉは、例えば、配送ドローン２６の識別情報（識別ＩＤ）、種類（小型、大型等）、最大積載重量、積載可能な荷物の最大寸法を含む。また、個体情報Ｉｉは、積載可能な荷物の個数、最大利用可能人数、燃費、最高速度、稼働年数、総移動距離、配送ドローン２６の現在位置のいずれか１つ又は複数を含んでもよい。

第１地図ＤＢ１２６は、配送ドローン２６による配送を行うための地図情報（第１地図情報Ｉｍａｐ１）を蓄積する。第１地図情報Ｉｍａｐ１には、交通サーバ２４による進入許可を要する進入制限領域の位置情報が含まれる。

配送ＤＢ１２８は、注文を受けた商品Ｇの配送に関する情報（配送情報Ｉｄ）を蓄積する。配送情報Ｉｄには、商品Ｇの配送を行う配送ドローン２６に関する情報も含まれる。

［Ａ−１−４．交通管理サーバ２４］
交通管理サーバ２４は、複数の移動体（配送ドローン２６、エンタテインメントドローン３０等）の交通（飛行）に関する情報（交通情報Ｉｔ）を管理する。例えば、交通サーバ２４は、各移動体の飛行許可申請をサービスサーバ２２又は申請端末２８から受信した場合、当該飛行許可申請を許可するか否かを判定し、判定結果に応じて許可又は不許可をサービスサーバ２２又は申請端末２８に通知する。また、交通サーバ２４は、移動体に関する各種の情報をサービスサーバ２２又は申請端末２８に通知する。

図１に示すように、交通管理サーバ２４は、入出力部１３０と、通信部１３２と、演算部１３４と、記憶部１３６とを含む。通信部１３２は、インターネット６０を介することで、サービスサーバ２２、申請端末２８、通信管理サーバ３４等との通信が可能である。

演算部１３４は、ＣＰＵを含み、記憶部１３６に記憶されているプログラムを実行することにより動作する。演算部１３４が実行する機能の一部は、ロジックＩＣを用いて実現することもできる。演算部１３４は、前記プログラムの一部をハードウェア（回路部品）で構成することもできる。

図１に示すように、演算部１３４は、イベント関連制御を実行するイベント関連制御部１５０を有する。イベント関連制御は、申請端末２８を介して外部イベントＥの申請が行われた際に交通サーバ２４側で対応を取る制御である。

記憶部１３６は、演算部１３４が用いるプログラム及びデータを記憶するものであり、ＲＡＭを備える。また、記憶部１３６は、ＲＡＭに加え、ＲＯＭを有してもよい。記憶部１３６は、第２地図データベース１６０（以下「第２地図ＤＢ１６０」という。）と、飛行スケジュールデータベース１６２（以下「飛行スケジュールＤＢ１６２」という。）と、外部イベントデータベース１６４（以下「外部イベントＤＢ１６４」又は「イベントＤＢ１６４」という。）とを有する。

第２地図ＤＢ１６０は、複数の移動体（配送ドローン２６、エンタテインメントドローン３０等）の交通（飛行）に関する地図情報（第２地図情報Ｉｍａｐ２）を蓄積する。飛行スケジュールＤＢ１６２は、各移動体の飛行スケジュールに関する情報（飛行スケジュール情報Ｉｓｃ）を蓄積する。イベントＤＢ１６４は、外部イベントＥに関する情報（外部イベント情報Ｉｅｅ）を蓄積する。

［Ａ−１−５．配送ドローン２６］
（Ａ−１−５−１．配送ドローン２６の概要）
配送ドローン２６（自律移動体）は、商品配送用であり、インターネット６０及び無線中継局６２を介してサービスサーバ２２から受信した配送指令（飛行指令）に応じて出発地Ｐｓｔ（倉庫等）から配送目的地Ｐｄｔａｒまで商品Ｇを配送する。

図１に示すように、配送ドローン２６は、第１センサ群１７０と、第１通信装置１７２と、第１ドローン制御装置１７４と、第１プロペラ駆動部１７６とを有する。

（Ａ−１−５−２．第１センサ群１７０）
第１センサ群１７０は、第１カメラ、第１グローバル・ポジショニング・システム・センサ（以下「第１ＧＰＳセンサ」という。）、速度計、高度計、ジャイロセンサ（いずれも図示せず）等を有する。

第１カメラは、配送ドローン２６の本体の下部に配置され、配送ドローン２６の周辺を撮像した周辺画像に関する画像情報Ｉｉｍａｇｅ１を出力する。第１カメラは、動画を撮影するビデオカメラである。或いは、第１カメラは、動画及び静止画の両方又は静止画のみを撮影可能としてもよい。第１カメラは、図示しないカメラアクチュエータにより向き（配送ドローン２６の本体に対する第１カメラの姿勢）を調整可能である。或いは、第１カメラは、配送ドローン２６の本体に対する位置が固定されてもよい。

第１ＧＰＳセンサは、配送ドローン２６の現在位置Ｐｄｃｕｒに関する位置情報Ｉｐｄｃｕｒを出力する。速度計は、配送ドローン２６の飛行速度Ｖｄ［ｋｍ／ｈ］を検出する。高度計は、配送ドローン２６下方の地面に対する距離としての対地高度Ｈ（以下「高度Ｈ」ともいう。）［ｍ］を検出する。ジャイロセンサは、配送ドローン２６の角速度ω［ｒａｄ／ｓｅｃ］を検出する。角速度ωは、上下軸に対する角速度Ｙ（ヨーＹ）と、左右軸に対する角速度Ｐ（ピッチＰ）と、前後軸に対する角速度Ｒｏ（ロールＲｏ）とを含む。

（Ａ−１−５−３．第１通信装置１７２）
第１通信装置１７２は、無線中継局６２等との電波通信が可能であり、例えば、電波通信モジュールを含む。第１通信装置１７２は、無線中継局６２及びインターネット６０を介することでサービスサーバ２２等との通信が可能である。

（Ａ−１−５−４．第１ドローン制御装置１７４）
第１ドローン制御装置１７４（自律制御部）は、配送ドローン２６の飛行、撮影等、配送ドローン２６全体を制御する。第１ドローン制御装置１７４は、配送ドローン２６を出発地Ｐｓｔから目的地Ｐｔａｒまで自律的に移動（飛行）させる。第１ドローン制御装置１７４は、図示しない入出力部、演算部及び記憶部を含む。

（Ａ−１−５−５．第１プロペラ駆動部１７６）
第１プロペラ駆動部１７６は、複数のプロペラと、複数のプロペラアクチュエータとを有する。プロペラアクチュエータは、例えば電動モータを有する。

［Ａ−１−６．申請端末２８］
申請端末２８は、エンタテインメントドローン３０の飛行許可申請を交通サーバ２４に対して行う第２外部機器である。また、申請端末２８は、飛行許可申請を行わない場合であっても、各飛行体の飛行スケジュール等を確認することができる。申請端末２８は、例えば、パーソナルコンピュータ又はスマートフォンから構成される。申請端末２８は、第２表示部１８０を有する。

［Ａ−１−７．エンタテインメントドローン３０及びリモートコントローラ３２］
エンタテインメントドローン３０（自律移動体）は、エンターテインメント用又はホビー用であり、リモートコントローラ３２に対するユーザの操作に応じて飛行する。エンタテインメントドローン３０は、図示しない第２センサ群、第２通信装置、第２ドローン制御装置、第２プロペラ駆動部等を有する。リモートコントローラ３２は、第２通信装置との無線通信（電波通信等）を介してエンタテインメントドローン３０の飛行を操作する。

［Ａ−１−８．通信管理サーバ３４］
通信管理サーバ３４は、特定地域における通信を管理するものであり、図示しない入出力部、通信部、演算部及び記憶部を有する。本実施形態の通信管理サーバ３４は、外部イベントＥの場所Ｌｅｅにおける通信量Ｑｃを監視する。通信量Ｑｃは、外部イベントＥの場所Ｌｅｅで利用される携帯電話、スマートフォン（いずれも図示せず）の電波により検出される。通信量Ｑｃは、場所Ｌｅｅの混雑度合いＤｃｒを示す指標として用いられる。

＜Ａ−２．本実施形態の制御＞
［Ａ−２−１．発注及び配送時］
（Ａ−２−１−１．発注及び配送時の流れの概要）
図２は、本実施形態において、顧客から発注された商品Ｇを、配送ドローン２６で配送する際の概要を示すフローチャートである。ステップＳ１１において、発注端末２０は、顧客の操作に応じて発注を受け付ける。

具体的には、発注端末２０は、顧客の操作に応じて発注画面を第１表示部７０に表示する。発注画面のデータは、サービス管理サーバ２２から取得したものである。また、発注画面を表示させるに当たり、サービスサーバ２２は、発注対象の商品Ｇの在庫数を確認する。在庫切れの場合、サービスサーバ２２は、その旨を併せて表示させる。発注があった場合、発注端末２０は、顧客からの発注を受け付けてサービス管理サーバ２２に送信する。

サービスサーバ２２の処理に移る。ステップＳ２１において、サービスサーバ２２は、発注端末２０が受け付けた発注情報Ｉｏｄｒに応じて、実際に配送を行う配送ドローン２６（以下「対象ドローン２６ｔａｒ」ともいう。）及び予定経路ＲＴｐを算出する。なお、配送ドローン２６及び予定経路ＲＴｐの算出は、発注前に行っておき、発注時に確定してもよい。予定経路ＲＴｐの算出に関する更なる情報については後述する。

ステップＳ２２において、サービスサーバ２２は、予定経路ＲＴｐについて交通サーバ２４の許可が必要であるか否か（換言すると、交通サーバ２４の許可が必要な部分が予定経路ＲＴｐに含まれているか否か）を、第１地図情報Ｉｍａｐ１に基づいて判定する。交通サーバ２４の許可が必要な部分としては、例えば飛行制限領域Ｒｌｉｍが含まれる。

交通サーバ２４の許可が必要である場合（Ｓ２２：ＴＲＵＥ）、ステップＳ２３において、予定経路ＲＴｐについての許可申請を、交通管理サーバ２４に対して送信する。許可申請には、対象となる配送ドローン２６の識別ＩＤが付与される。許可申請の送信後、ステップＳ２４において、サービスサーバ２２は、交通管理サーバ２４からの結果通知を受信したか否かを監視する。

交通管理サーバ２４の処理に移る。サービスサーバ２２からの許可申請（Ｓ２３）を受信した交通管理サーバ２４は、ステップＳ３１において、受信した許可申請について許可又は不許可のいずれとするかを判定する。例えば、予定経路ＲＴｐが、一時的な飛行禁止領域Ｒｂａｎを含む場合、交通サーバ２４は許可申請を不許可とする。また、１又は複数の他の配送ドローン２６等の飛行体（他機）が、自ら（自機）と同時刻に予定経路ＲＴｐの一部を通過する予定である場合、交通サーバ２４は許可申請を不許可とする。一方、配送ドローン２６の飛行を認めない事由が予定経路ＲＴｐに存在しない場合、交通サーバ２４は許可申請を許可する。

許可申請を許可する場合（Ｓ３１：ＴＲＵＥ）、ステップＳ３２において、交通管理サーバ２４は、許可通知をサービスサーバ２２に送信する。許可申請を許可しない場合（Ｓ３１：ＦＡＬＳＥ）、ステップＳ３３において、交通管理サーバ２４は、不許可通知をサービスサーバ２２に送信する。不許可通知には、不許可の理由等（例えば、予定経路ＲＴｐが飛行禁止領域Ｒｂａｎを通過すること、飛行禁止領域Ｒｂａｎの位置等）も付加される。

再びサービスサーバ２２の処理に移る。交通管理サーバ２４から受信した結果が許可を示す場合（Ｓ２４：ＴＲＵＥ）、ステップＳ２５に進む。交通管理サーバ２４から受信した結果が不許可を示す場合（Ｓ２４：ＦＡＬＳＥ）、ステップＳ２１に戻る。そして、サービスサーバ２２は、結果に含まれる不許可の理由に応じて、新たな予定経路ＲＴｐを算出する。例えば、不許可の理由が、予定経路ＲＴｐが飛行禁止領域Ｒｂａｎを通過することである場合、サービスサーバ２２は、飛行禁止領域Ｒｂａｎを避ける新たな予定経路ＲＴｐを算出する（Ｓ２１）。そして、サービスサーバ２２は、必要に応じて再度飛行許可申請を行う（Ｓ２３）。

ステップＳ２５において、サービスサーバ２２は、商品Ｇを配送する配送ドローン２６に対して配送指令を送信する。配送指令には、予定経路ＲＴｐの情報が含まれる。移動経路ＲＴｆは、配送ドローン２６の現在位置Ｐｄｃｕｒ（例えば、図示しない倉庫）である出発地Ｐｓｔから配送目的地Ｐｄｔａｒまでの経路（往路）と、配送目的地Ｐｄｔａｒから帰還目的地Ｐｒｔａｒまでの経路（復路）を含む。

配送のために配送ドローン２６が倉庫、営業所等に立ち寄る必要がある場合、予定経路ＲＴｐは、現在位置Ｐｄｃｕｒから倉庫等への経路を含んでもよい。或いは、配送のために配送ドローン２６が倉庫等に立ち寄る必要がある場合、倉庫、営業所等までの経路を予定経路ＲＴｐとして設定してもよい。その場合、新たな予定経路ＲＴｐとして、配送目的地Ｐｄｔａｒまでの経路と、帰還目的地Ｐｒｔａｒまでの経路（復路）を設定してもよい。なお、後述するように、配送指令は、サービスサーバ２２から配送ドローン２６に対して直接送信するのではなく、別の方法で送信することも可能である。

各配送ドローン２６の処理に移る。配送ドローン２６は、サービスサーバ２２から配送指令（Ｓ２５）を受信したか否かを監視している。配送指令を受信した配送ドローン２６は、ステップＳ５１において、商品Ｇを倉庫又は営業所から配送目的地Ｐｄｔａｒまで運び、その後帰還目的地Ｐｒｔａｒまで戻る配送制御を開始する。

（Ａ−２−１−２．サービス管理サーバ２２による受注時制御）
（Ａ−２−１−２−１．受注時制御の概要）
図３は、本実施形態の受注時制御のフローチャートである。上記のように、受注時制御は、商品Ｇの受注及び配送ドローン２６による配送を管理する制御であり、サービスサーバ２２の演算部８４が実行する。

図３のステップＳ７１において、サービスサーバ２２は、発注端末２０からの要求に応じて、発注端末２０に発注画面を表示させる。換言すると、サービスサーバ２２は、発注端末２０からの要求に応じて、発注画面のデータを発注端末２０に送信する。発注画面のデータを受信した発注端末２０は、第１表示部７０に発注画面を表示させる。

ステップＳ７２において、サービスサーバ２２は、商品Ｇを受注したか否かを判定する。上記のように、発注端末２０が、顧客の操作に応じて発注を受け付け、発注情報Ｉｏｄｒをサービスサーバ２２に送信する（図２のＳ１１）。従って、サービスサーバ２２は、発注端末２０から発注情報Ｉｏｄｒを受信したとき、商品Ｇを受注したと判定する。受注した場合（Ｓ７２：ＴＲＵＥ）、ステップＳ７３に進む。受注していない場合（Ｓ７２：ＦＡＬＳＥ）、ステップＳ７１に戻る。

ステップＳ７３〜Ｓ７５において、サービスサーバ２２は、実際に配送を行う配送ドローン２６（対象ドローン２６ｔａｒ）及びその予定経路ＲＴｐを算出する。すなわち、ステップＳ７３において、サービスサーバ２２は、対象ドローン２６ｔａｒ及び予定経路ＲＴｐを算出するために必要な配送情報Ｉｄを取得する。配送情報Ｉｄには、商品Ｇ（荷物）の配送地、配送期限、寸法、重量等が含まれる。

ステップＳ７４において、サービスサーバ２２は、商品Ｇの配送に利用する配送ドローン２６（対象ドローン２６ｔａｒ）を、配送情報Ｉｄに基づいて選択する。例えば、配送情報Ｉｄに含まれる配送地に基づいて、配送ドローン２６の中から地域的な限定を行う。例えば、Ａ地域に配達する場合、サービスサーバ２２は、現在Ａ地域に配置されている配送ドローン２６を抽出する。

また、配送情報Ｉｄに含まれる商品Ｇの寸法及び重量に基づいて、配送ドローン２６の中から各個体の性能（属性）に基づく限定を行う。例えば、商品Ｇが第１寸法以上の大型荷物である場合、大型の配送ドローン２６を抽出し、小型の配送ドローン２６を除外する。一方、商品Ｇが第１寸法より小さい小型荷物である場合、大型及び小型両方の配送ドローン２６を抽出する。なお、本実施形態では、第１寸法よりも小さい小型荷物を単体で配送する場合、基本的には、小型の配送ドローン２６が選択される。

ステップＳ７５において、サービスサーバ２２は、対象ドローン２６ｔａｒの予定経路ＲＴｐを算出する。その際、サービスサーバ２２は、第１地図ＤＢ１２６に記憶されている飛行制限領域Ｒｌｉｍを用いる。例えば、出発地Ｐｓｔから配送目的地Ｐｄｔａｒまでの最短空中経路ＲＴｍｉｎに飛行制限領域Ｒｌｉｍが含まれない場合、最短空中経路ＲＴｍｉｎを予定経路ＲＴｐとする。最短空中経路ＲＴｍｉｎに飛行制限領域Ｒｌｉｍが含まれる場合、飛行制限領域Ｒｌｉｍの制限内容に応じた予定経路ＲＴｐを設定する。

飛行制限領域Ｒｌｉｍは、配送ドローン２６の飛行が制限される領域であり、飛行禁止領域Ｒｂａｎ及び条件付き飛行許可領域Ｒａｌｗを含む。飛行禁止領域Ｒｂａｎは、配送ドローン２６の飛行が禁止されている領域である。また、条件付き飛行許可領域Ｒａｌｗは、所定の条件（飛行許可条件ＣＮａｌｗ）が満たされる場合のみ配送ドローン２６の飛行が許可され、飛行許可条件ＣＮａｌｗが満たされない場合、配送ドローン２６の飛行が禁止される領域である。飛行許可条件ＣＮａｌｗとしては、例えば時間帯又は特定用途（緊急用途等）が含まれる。

飛行制限領域Ｒｌｉｍは、３次元方向（前後方向、左右方向及び上下方向）で定義する。或いは、２次元方向（前後方向及び左右方向）で飛行制限領域Ｒｌｉｍを定義してもよい。飛行制限領域Ｒｌｉｍを３次元方向で定義した場合、例えば、前後方向及び左右方向（緯度及び経度で規定される現在位置Ｐｄｃｕｒ）のみではなく、上下方向（高度Ｈ）も含めて飛行制限領域Ｒｌｉｍが設定される。

最短空中経路ＲＴｍｉｎに飛行禁止領域Ｒｂａｎが含まれる場合、飛行禁止領域Ｒｂａｎを避けた空中経路のうち最短となる経路を予定経路ＲＴｐとする。また、最短空中経路ＲＴｍｉｎに条件付き飛行許可領域Ｒａｌｗが含まれ且つ飛行許可条件ＣＮａｌｗが満たされる場合、サービスサーバ２２は、最短空中経路ＲＴｍｉｎを予定経路ＲＴｐとする。さらに、最短空中経路ＲＴｍｉｎに条件付き飛行許可領域Ｒａｌｗが含まれ且つ飛行許可条件ＣＮａｌｗが満たされない場合、サービスサーバ２２は、条件付き飛行許可領域Ｒａｌｗを避けた空中経路のうち最短となる経路を予定経路ＲＴｐとする。

なお、最短空中経路ＲＴｍｉｎ上に飛行制限領域Ｒｌｉｍが複数存在する場合、それぞれの飛行制限領域Ｒｌｉｍについて通過する場合と迂回する場合に場合分けして予定経路ＲＴｐを算出する。また、予定経路ＲＴｐは、対象ドローン２６ｔａｒが商品Ｇの配送に用いる経路であり、往路と復路を含む。

ステップＳ７６において、サービスサーバ２２は、配送ドローン２６に対して配送指令を送信する。配送指令は、予定経路ＲＴｐを含む。ステップＳ７６は、図２のステップＳ２５に対応する。

（Ａ−２−１−２−２．予定経路ＲＴｐの算出（図３のＳ７５））
（Ａ−２−１−２−２−１．予定経路ＲＴｐの算出の概要）
図４は、本実施形態の受注時制御において、予定経路ＲＴｐ（往路）を算出するフローチャート（図３のＳ７５の詳細）である。ステップＳ９１において、サービスサーバ２２は、配送情報Ｉｄの配送期限等に基づいて予定配送時刻Ｔｐｄを設定する。ステップＳ９２において、出発地Ｐｓｔ及び配送目的地Ｐｄｔａｒに基づいて経路選択肢ＲＴｏｐを算出する。経路選択肢ＲＴｏｐは、出発地Ｐｓｔと配送目的地Ｐｄｔａｒを結ぶ経路（出発地Ｐｓｔと配送目的地Ｐｄｔａｒの間の経路）であり、予定経路ＲＴｐの１次候補として位置付けられる。

なお、「出発地Ｐｓｔと配送目的地Ｐｄｔａｒの間」は、二次元平面地図において出発地Ｐｓｔと配送目的地Ｐｄｔａｒを結ぶ直線状の経路（又は最短経路）のみではなく、曲線状の経路（又は迂回路）を含み得る。換言すると、経路選択肢ＲＴｏｐは、出発地Ｐｓｔと配送目的地Ｐｄｔａｒを結ぶ経路として利用され得る全ての経路として設定し得る。

まず、サービスサーバ２２は、出発地Ｐｓｔから配送目的地Ｐｄｔａｒまでの最短空中経路ＲＴｍｉｎを経路選択肢ＲＴｏｐとする。但し、最短空中経路ＲＴｍｉｎ上に飛行禁止領域Ｒｂａｎが含まれる場合、飛行禁止領域Ｒｂａｎを避けた空中経路のうち最短となる経路を経路選択肢ＲＴｏｐとする。

また、最短空中経路ＲＴｍｉｎ上に飛行禁止領域Ｒｂａｎ以外の飛行制限領域Ｒｌｉｍが含まれる場合、当該最短空中経路ＲＴｍｉｎと、飛行制限領域Ｒｌｉｍを避けた空中経路のうち最短となる経路（迂回経路）の両方を経路選択肢ＲＴｏｐとする。なお、最短空中経路ＲＴｍｉｎ上に飛行禁止領域Ｒｂａｎ以外の飛行制限領域Ｒｌｉｍが２箇所以上存在する場合、それぞれの飛行制限領域Ｒｌｉｍについて通過する場合と迂回する場合に場合分けして経路選択肢ＲＴｏｐとする。

ステップＳ９３において、サービスサーバ２２は、経路選択肢ＲＴｏｐそれぞれについて経路評価値Ｑを算出する。経路評価値Ｑは、経路候補ＲＴｃａｎ（又は予定経路ＲＴｐ）を算出するための評価値である。本実施形態では、経路評価値Ｑが低いほど、経路選択肢ＲＴｏｐとして優れている。経路評価値Ｑの算出方法については、図５Ａ及び図５Ｂを参照して後述する。

ステップＳ９４において、サービスサーバ２２は、経路評価値Ｑが最小の経路選択肢ＲＴｏｐを経路候補ＲＴｃａｎとして選択する。経路候補ＲＴｃａｎは、予定経路ＲＴｐの２次候補である。

ステップＳ９５において、サービスサーバ２２は、配送ドローン２６が経路候補ＲＴｃａｎの各地点を通過する予定通過時刻Ｔｐｐを算出する。ステップＳ９６において、サービスサーバ２２は、各地点それぞれについて、予定通過時刻Ｔｐｐにおいて経路候補ＲＴｃａｎ上に外部イベント領域Ｒｅｅが存在しないか否か（換言すると、予定通過時刻Ｔｐｐにおいて経路候補ＲＴｃａｎが外部イベント領域Ｒｅｅに含まれないか否か）を判定する。なお、予定通過時刻Ｔｐｐの代わりに、予定通過時間帯（予定移動時間帯）を用いることも可能である。

予定通過時刻Ｔｐｐにおいて経路候補ＲＴｃａｎ上に外部イベント領域Ｒｅｅが存在しない場合（Ｓ９６：ＴＲＵＥ）、ステップＳ９７において、サービスサーバ２２は、経路候補ＲＴｃａｎを予定経路ＲＴｐとする。予定通過時刻Ｔｐｐにおいて経路候補ＲＴｃａｎ上に外部イベント領域Ｒｅｅが存在する場合（Ｓ９６：ＦＡＬＳＥ）、ステップＳ９８に進む。

ステップＳ９８において、サービスサーバ２２は、予定配送時刻Ｔｐｄを変更不可であるか否かを判定する。具体的には、商品Ｇを配送する時間帯としての配送時間帯ＴＳｄが決まっている場合、予定配送時刻Ｔｐｄを遅らせると、配送時間帯ＴＳｄを外れてしまうか否かを判定する。予定配送時刻Ｔｐｄを変更可である場合（Ｓ９８：ＦＡＬＳＥ）、ステップＳ９９において、サービスサーバ２２は、予定配送時刻Ｔｐｄを変更してステップＳ９２に戻る。ステップＳ９２では、変更後の予定配送時刻Ｔｐｄに基づいて経路選択肢ＲＴｏｐを算出する。

予定配送時刻Ｔｐｄを変更不可である場合（Ｓ９８：ＴＲＵＥ）、ステップＳ１００において、サービスサーバ２２は、経路評価値Ｑが最小の経路候補ＲＴｃａｎを予定経路ＲＴｐとする。後述するように、上記以外の経路について経路評価値Ｑを算出することも可能である。

（Ａ−２−１−２−２−２．経路評価値Ｑの算出（図４のＳ９３））
上記のように、経路評価値Ｑ（以下「評価値Ｑ」ともいう。）は、予定経路ＲＴｐを算出するための評価値である。本実施形態では、評価値Ｑが低いほど、経路選択肢ＲＴｏｐとして優れている。

評価値Ｑは、下記の式（１）で算出される。
Ｑ＝∫Ｃ（ｘ，ｙ，ｔ）＊Ｒ（ｘ，ｙ，ｔ）ｄｔ （１）

上記式（１）において、ｘ、ｙは、２次元平面で第１地図情報Ｉｍａｐ１を示した場合の経度（Ｘ座標）及び緯度（Ｙ座標）を示す。また、ｔは、時刻（Ｚ座標）を示す。経度ｘ及び緯度ｙは、経路選択肢ＲＴｏｐ上の点として時刻ｔ毎に決まる。Ｃは、外部イベントＥの場所Ｌｅｅに存在する物品の評価額を示すコストである。コストＣは、ｘ、ｙ、ｔの関数である。コストＣは、申請端末２８のユーザ（イベント企画者等）が入力した外部イベント情報Ｉｅｅに基づいて算出される。例えば、外部イベントＥがスポーツカーの屋外イベントである場合、コストＣは、各スポーツカーの費用に反映して大きくなる。

式（１）のＲは、外部イベント領域Ｒｅｅを配送ドローン２６が通過する際のリスクである。リスクＲは、ｘ、ｙ、ｔの関数である。リスクＲは、外部イベント情報Ｉｅｅに基づいて算出される。ここでの外部イベント情報Ｉｅｅは、申請端末２８のユーザ（イベント企画者）が申請端末２８に入力した情報と、サービスサーバ２２が通信管理サーバ３４から取得した情報とを含む。通信管理サーバ３４からの外部イベント情報Ｉｅｅは、外部イベントＥの場所Ｌｅｅにおける通信量Ｑｃを含む。通信量Ｑｃは、場所Ｌｅｅにおける混雑度合いＤｃｒを示す指標として用いられる。

図５Ａ及び図５Ｂは、前記実施形態において経路評価値の算出を説明する第１・第２説明図である。図５Ａ及び図５Ｂでは、ある特定時点（時刻ｔ＝ｔ１）におけるコストＣ及びリスクＲが示されている。実際の第１地図ＤＢ１２６では、時刻ｔのそれぞれについて、経度ｘ及び緯度ｙに対応するコストＣ及びリスクＲが記憶されている。

図５Ａ及び図５Ｂでは、Ｚ軸が時刻ｔに対応することから、経路選択肢ＲＴｏｐは、時刻ｔが進むに連れて、Ｚ軸の上側に移動する。図５Ａの各円２００は、外部イベントＥに対応するコストＣを示している。各円２００の中心に近づくほど、コストＣが高くなる。また、図５Ｂの各円２０２は、外部イベントＥに対応するリスクＲを示している。各円２０２の中心に近づくほど、リスクＲが高くなる。

図６は、本実施形態の受注時制御により設定される予定経路ＲＴｐの例を示す図である。図６では、配送ドローン２６の出発地Ｐｓｔ及び配送目的地Ｐｄｔａｒが示されている。また、出発地Ｐｓｔと配送目的地Ｐｄｔａｒの間には、外部イベント領域Ｒｅｅが存在する。

ここにいう「出発地Ｐｓｔと配送目的地Ｐｄｔａｒの間」は、二次元平面地図において出発地Ｐｓｔと配送目的地Ｐｄｔａｒを結ぶ直線経路（最短経路）上のみではなく、曲線経路（迂回路）上も含み得る。換言すると、出発地Ｐｓｔと配送目的地Ｐｄｔａｒを結ぶ経路として利用され得るいずれかの経路上に外部イベント領域Ｒｅｅが存在すれば、「出発地Ｐｓｔと配送目的地Ｐｄｔａｒの間には、外部イベント領域Ｒｅｅが存在する。」と言える。

また、利用され得る全ての経路が外部イベント領域Ｒｅｅの真上を通過しておらず、いずれかの経路の近傍に外部イベント領域Ｒｅｅが存在する場合も、「出発地Ｐｓｔと配送目的地Ｐｄｔａｒの間には、外部イベント領域Ｒｅｅが存在する。」と言える。「近傍」は、配送ドローン２６（移動体）の移動が外部イベントＥに対して影響を及ぼす程度か、又は外部イベントＥが配送ドローン２６（移動体）の移動に対して影響を及ぼす程度かにより設定する。

ここでの外部イベント領域Ｒｅｅは、例えば、エンタテインメントドローン３０の予定飛行領域である。出発地Ｐｓｔと配送目的地Ｐｄｔａｒの最短空中経路ＲＴｍｉｎは経路ＲＴｐ１である。

しかしながら、予定通過時刻Ｔｐｐにおいて、最短空中経路ＲＴｍｉｎ（経路ＲＴｐ１）上には、外部イベント領域Ｒｅｅが存在する。そこで、サービスサーバ２２は、配送ドローン２６の予定経路ＲＴｐとして、外部イベント領域Ｒｅｅを避けた経路ＲＴｐ２を設定する。一方、外部イベント領域Ｒｅｅの利用時間が終了する等により、最短空中経路ＲＴｍｉｎ上に外部イベント領域Ｒｅｅが存在しなくなった場合、サービスサーバ２２は、配送ドローン２６の予定経路ＲＴｐとして、経路ＲＴｐ１を選択することができる。

なお、例えば、配送ドローン２６（ビジネス用途のドローン）よりも、エンタテインメントドローン３０（個人用途のドローン）を優先するという観点からすれば、外部イベント領域Ｒｅｅを別の方法で取り扱うことも可能である。例えば、予定配送時刻Ｔｐｄにかかわりなく、エンタテインメントドローン３０用の外部イベント領域Ｒｅｅを、配送ドローン２６にとっての飛行禁止領域Ｒｂａｎとして設定してもよい。

［Ａ−２−２．外部イベントＥの申請時］
（Ａ−２−２−１．外部イベントＥの申請時の流れの概要）
図７は、本実施形態において、交通管理サーバ２４に対して外部イベントＥの申請があるときの流れの概要を示すフローチャートである。ステップＳ２０１において、申請端末２８は、ユーザ（申請者）の操作に応じて外部イベントＥの申請を受け付ける。

具体的には、申請端末２８は、ユーザの操作に応じて外部イベント申請画面３００（図９）を第２表示部１８０に表示する。外部イベント申請画面３００（以下「申請画面３００」ともいう。）のデータＤａｓは、交通サーバ２４から取得したものである。また、交通サーバ２４は、外部イベント領域Ｒｅｅを申請画面３００に表示させる。外部イベントＥの申請（具体的には、外部イベント情報Ｉｅｅの入力及び送信要求操作）があった場合、申請端末２８は、外部イベント情報Ｉｅｅを交通サーバ２４に送信する。外部イベント情報Ｉｅｅは、外部イベントＥの場所Ｌｅｅ、外部イベントＥが行われる時刻Ｔｅ若しくは時間帯ＴＳｅ、混雑度合いＤｃｒ（外部イベントＥにかかわる人数）を含む。

交通管理サーバ２４の処理に移る。申請端末２８からの外部イベントＥの申請（Ｓ２０１）を受信した交通サーバ２４は、ステップＳ２１１において、受信した申請について許可又は不許可のいずれとするかを判定する。例えば、外部イベントＥの場所Ｌｅｅが、イベント禁止領域Ｒｅｂａｎ内にある場合、交通サーバ２４は申請を不許可とする。また、申請された外部イベントＥの場所Ｌｅｅが、既に他の外部イベントＥの場所Ｌｅｅと重複する場合、交通サーバ２４は申請を不許可とする。一方、外部イベントＥを認めない事由が存在しない場合、交通サーバ２４は申請を許可する。

申請を許可しない場合（Ｓ２１１：ＦＡＬＳＥ）、ステップＳ２１２において、交通サーバ２４は、不許可通知を申請端末２８に送信する。不許可通知には、不許可の理由等（例えば、外部イベントＥの場所Ｌｅｅがイベント禁止領域Ｒｅｂａｎ内にあること、イベント禁止領域Ｒｅｂａｎの位置等）も付加される。不許可通知を受信した申請端末２８は、不許可通知の内容を第２表示部１８０に表示する（Ｓ２０２）。この表示を見たユーザ（申請者）は、不許可通知の内容を考慮し、必要に応じて、再度、外部イベントＥの申請を行う（Ｓ２０１）。

申請を許可する場合（Ｓ２１３：ＴＲＵＥ）、ステップＳ２１３において、交通サーバ２４は、許可通知を申請端末２８に送信する。許可通知を受信した申請端末２８は、許可通知の内容を第２表示部１８０に表示する（Ｓ２０３）。また、ステップＳ２１４において、交通サーバ２４は、許可内容としての外部イベント情報Ｉｅｅをサービスサーバ２２に送信する。

外部イベント情報Ｉｅｅが送信されるサービスサーバ２２は、申請の許可によって予定経路ＲＴｐの影響を受ける配送ドローン２６を管理するサービスサーバ２２である。申請の許可によって予定経路ＲＴｐが影響を受けるか否かは、飛行スケジュールＤＢ１６２の飛行スケジュール情報Ｉｓｃに基づいて判定する。但し、サービスサーバ２２が１台のみである場合、交通サーバ２４が、サービスサーバ２２を選択する必要はない。

交通サーバ２４から外部イベント情報Ｉｅｅを受信したサービスサーバ２２は、ステップＳ２２１において、予定経路ＲＴｐの変更の要否を判定する。そして、変更を要すると判定した場合、サービスサーバ２２は、新たな予定経路ＲＴｐを算出する。新たな予定経路ＲＴｐの算出方法は、基本的に、図４と同様である。但し、新たな予定経路ＲＴｐの算出は、外部イベント情報Ｉｅｅで示された外部イベントＥに基づく外部イベント領域Ｒｅｅを新たに追加して行う。新たな外部イベント領域Ｒｅｅは、飛行制限領域Ｒｌｉｍの１つとして取り扱われる。なお、交通サーバ２４から通知された外部イベント情報Ｉｅｅは、第１地図ＤＢ１２６に登録される。

ステップＳ２２２において、サービスサーバ２２は、新たな予定経路ＲＴｐを通知する変更指令を配送ドローン２６に送信する。サービスサーバ２２から変更指令（新たな予定経路ＲＴｐ）を受信した配送ドローン２６は、ステップＳ２３１において、予定経路ＲＴｐを変更し、新たな予定経路ＲＴｐに沿って配送を行う。

（Ａ−２−２−２．交通管理サーバ２４による外部イベント関連制御）
（Ａ−２−２−２−１．外部イベント関連制御の概要）
図８は、本実施形態における外部イベント関連制御のフローチャートである。上記のように、外部イベント関連制御は、申請端末２８を介して外部イベントＥの申請が行われた際に交通サーバ２４側で対応を取る制御であり、交通サーバ２４のイベント関連制御部１５０が実行する。ステップＳ２５１において、交通サーバ２４は、外部イベントＥの申請画面データＤａｓの送信要求があったか否かを判定する。同送信要求がない場合（Ｓ２５１：ＦＡＬＳＥ）、ステップＳ２５２に進む。

ステップＳ２５２において、交通サーバ２４は、データ更新処理を行う。データ更新処理は、申請画面データＤａｓを更新する処理である。本実施形態では、外部イベントＥの時刻Ｔｅ又は時間帯ＴＳｅに応じて外部イベント領域Ｒｅｅを設定する。そのため、データ更新処理により、交通サーバ２４は、外部イベント情報Ｉｅｅに基づいて、外部イベント領域Ｒｅｅの最新状態を反映する。なお、ここでの外部イベント情報Ｉｅｅには、外部イベントＤＢ１６４に蓄積されている情報（外部イベントＥの場所Ｌｅｅ、外部イベントＥが行われる時刻Ｔｅ、時間帯ＴＳｅ、優先度ＰＲ等）に加えて、通信管理サーバ３４から新たに取得した情報（通信量Ｑｃ等）も含まれる。ステップＳ２５２の後、ステップＳ２５１に戻る。

外部イベントＥの申請画面データＤａｓの送信要求があった場合（Ｓ２５１：ＴＲＵＥ）、ステップＳ２５３において、交通サーバ２４は、送信要求を送信した申請端末２８に対して申請画面データＤａｓを送信する。なお、申請画面３００については、図９及び図１０を参照して後述する。

ステップＳ２５４において、交通サーバ２４は、申請端末２８を介して外部イベントＥの申請を受けたか否か（換言すると、外部イベント情報Ｉｅｅを受信したか否か）を判定する。外部イベントＥの申請を受けた場合（Ｓ２５４：ＴＲＵＥ）、ステップＳ２５５に進む。外部イベントＥの申請を受けない場合（Ｓ２５４：ＦＡＬＳＥ）、ステップＳ２５４を繰り返す。

ステップＳ２５５において、交通サーバ２４は、申請の許否を判定する。具体的には、飛行スケジュールＤＢ１６２に蓄積されている飛行スケジュール情報Ｉｓｃ（又は配送ドローン２６等の飛行体）のうち、申請の許可によって影響を受けるものがあるか否かを判定する。申請の許可によって影響を受ける飛行体（以下「比較飛行体」という。）がある場合、交通サーバ２４は、比較飛行体の優先度ＰＲと、外部イベントＥ（又は外部イベントＥにより利用されるエンタテインメントドローン３０等の飛行体）の優先度ＰＲを比較する。外部イベントＥの優先度ＰＲは、申請端末２８から受信した外部イベント情報Ｉｅｅに含まれる。

外部イベントＥ（又はエンタテインメントドローン３０等）の優先度ＰＲよりも比較飛行体の優先度ＰＲが高い場合又は両者が同じ場合、交通サーバ２４は、申請を許可しない。一方、外部イベントＥ（又はエンタテインメントドローン３０等）の優先度ＰＲよりも比較飛行体の優先度ＰＲが低い場合、交通サーバ２４は、申請を許可する。なお、交通サーバ２４は、エンタテインメントドローン３０の飛行申請を許可する前にサービスサーバ２２と通信し、配送ドローン２６の予定経路ＲＴｐを変更した後に、エンタテインメントドローン３０の飛行申請を許可してもよい。

本実施形態では、配送ドローン２６の優先度ＰＲよりも、エンタテインメントドローン３０の優先度ＰＲが高く設定されている。従って、配送ドローン２６の飛行申請が交通サーバ２４により既に許可されていた場合であっても、新たにエンタテインメントドローン３０の飛行申請がされた場合、例外を除いて、エンタテインメントドローン３０の飛行申請は許可される。ここにいう例外は、例えば、配送ドローン２６が外部イベントＥの場所Ｌｅｅに到達するまでの予測時間Ｔｐが時間閾値ＴＨｔｐ以下である場合である。

申請を許可しない場合（Ｓ２５５：ＦＡＬＳＥ）、ステップＳ２５６において、交通サーバ２４は、不許可通知を申請端末２８に送信する。不許可通知には、不許可の理由等（例えば、外部イベントＥの場所Ｌｅｅがイベント禁止領域Ｒｅｂａｎ内にあること、イベント禁止領域Ｒｅｂａｎの位置等）も付加される。不許可通知を受信した申請端末２８は、不許可通知の内容を第２表示部１８０に表示する。この表示を見たユーザ（申請者）は、不許可通知の内容を考慮し、必要に応じて、再度、外部イベントＥの申請を行う（Ｓ２０１）。

申請を許可する場合（Ｓ２５５：ＴＲＵＥ）、ステップＳ２５７において、交通サーバ２４は、許可通知を申請端末２８に送信する。許可通知を受信した申請端末２８は、許可通知の内容を第２表示部１８０に表示する。ステップＳ２５８において、交通サーバ２４は、ステップＳ２５４で受信した外部イベント情報ＩｅｅをイベントＤＢ１６４に登録する。その際、交通サーバ２４は、外部イベント情報Ｉｅｅに基づく外部イベント領域Ｒｅｅ（一時的移動制限場所）を設定する（後述する図９のイベント領域画像３１２ａ〜３１２ｇ参照）。

ステップＳ２５９において、交通サーバ２４は、許可内容としての外部イベント情報Ｉｅｅをサービスサーバ２２に送信する。外部イベント情報Ｉｅｅが送信されるサービスサーバ２２は、申請の許可によって予定経路ＲＴｐの影響を受ける配送ドローン２６を管理するサービスサーバ２２である。但し、管理システム１０に含まれるサービスサーバ２２が１台のみである場合、選択の必要はない。

（Ａ−２−２−２−２．外部イベント申請画面３００）
図９は、本実施形態における外部イベント申請画面３００の一例を示す図である。申請画面３００は、交通サーバ２４からの申請画面データＤａｓに基づいて、申請端末２８の第２表示部１８０に表示される。申請画面３００は、イベント地点入力画像３０２と、図示しないイベント情報入力欄とを含む。

イベント地点入力画像３０２は、定常制限領域画像３１０と、イベント領域画像３１２ａ、３１２ｂ、３１２ｃ、３１２ｄ、３１２ｅ、３１２ｆ、３１２ｇと、イベント発生時間帯画像３１４ａ、３１４ｂ、３１４ｃ、３１４ｄ、３１４ｅ、３１４ｆと、破線画像３１６ａ、３１６ｂ、３１６ｃとを含む。以下では、イベント領域画像３１２ａ〜３１２ｇをイベント領域画像３１２と総称する。また、イベント発生時間帯画像３１４ａ〜３１４ｆをイベント発生時間帯画像３１４と総称する。さらに、破線画像３１６ａ〜３１６ｃを破線画像３１６と総称する。

定常制限領域画像３１０は、定常的な飛行制限領域Ｒｌｉｍとして定義される領域である定常制限領域Ｒｌｉｍｓを示す画像である。定常制限領域Ｒｌｉｍｓとしては、例えば、人工集中地、住宅密集地、道路上、線路上が用いられる。

図１０は、本実施形態におけるイベント領域画像３１２の変化の一例を示す図である。イベント領域画像３１２は、外部イベントＥの場所Ｌｅｅを示す画像である。イベント領域画像３１２は、外部イベントＥの時間帯ＴＳｅ又は時刻Ｔｅになると申請画面３００（イベント地点入力画像３０２）に表示される。

図１０に示すように、イベント領域画像３１２は、外部イベントＥの中心地を示す内側円画像３２０と、内側円画像３２０の外側において内側円画像３２０と同心で示される外側円画像３２２とを有する。図１０に示すように、外側円画像３２２は、外部イベントＥの混雑度合いＤｃｒに応じて色を変化させる。図１０では、左側から右側に向かって時間の経過を示している。

図１０において、外側円画像３２２は、左端から右端に向かって、青色、黄色、赤色、黄色、青色の順で変化する。青色は、混雑度合いＤｃｒが小さいことを示し、赤色は、混雑度合いＤｃｒが大きいことを示し、黄色は、混雑度合いＤｃｒが中くらいであることを示す。なお、図９では、見易さを考慮して、各イベント領域画像３１２の外側円画像３２２の色表示は省略している。

イベント発生時間帯画像３１４（図９）は、外部イベントＥ又はこれに伴う人若しくは交通の流れの時間帯ＴＳｅを示す。例えば、イベント発生時間帯画像３１４ａは、外部イベントＥが１２：００〜１３：００の間に行われることを示している。

破線画像３１６は、イベント領域画像３１２間を結ぶ破線の画像である。破線画像３１６は、外部イベントＥの場所Ｌｅｅ間において発生する人の流れを示す。従って、サービスサーバ２２は、外部イベント領域Ｒｅｅ及び破線を避けるように、予定経路ＲＴｐを設定する。また、イベント発生時間帯画像３１４ｂは、破線画像３１６ａに対応する位置において、人の流れが２１：００〜２３：００の間に発生することを示している。

申請端末２８がパーソナルコンピュータである場合、申請端末２８のユーザ（申請者）は、イベント地点入力画像３０２において自らが外部イベントＥを行いたい地点にカーソルを合わせて図示しないマウスをクリックする。また、申請端末２８がスマートフォンである場合、申請端末２８のユーザは、イベント地点入力画像３０２において自らが外部イベントＥを行いたい地点をタッチする。これにより、外部イベントＥの場所Ｌｅｅを入力することができる。

また、申請端末２８のユーザ（申請者）は、図示しないイベント情報入力欄に、その他の外部イベント情報Ｉｅｅを入力する。その他の外部イベント情報Ｉｅｅとしては、例えば、外部イベントＥの内容ＣＴ、時間帯ＴＳｅ、時刻Ｔｅが含まれる。外部イベントＥの内容ＣＴとしては、例えば、個人による趣味でのエンタテインメントドローン３０の利用が含まれる。そして、申請に必要な外部イベント情報Ｉｅｅを全て入力すると、図示しない送信ボタンを選択することで、外部イベント情報Ｉｅｅを申請端末２８から交通サーバ２４に送信させる。

＜Ａ−３．本実施形態の効果＞
本実施形態によれば、配送ドローン２６（自律移動体）の出発地Ｐｓｔから目的地Ｐｔａｒの間で行われる外部イベントＥに関する外部イベント情報Ｉｅｅに基づいて配送ドローン２６の移動計画又は動作状態を変更する（図３のＳ７５、図４のＳ９６、図６、図７）。これにより、外部イベントＥの影響を、配送ドローン２６の移動計画又は動作状態に反映することが可能となる。従って、飛行制限場所の動的な変化を好適に行うことが可能となる。

本実施形態において、外部イベント情報Ｉｅｅは、外部イベントＥが行われる時間帯ＴＳｅ（又は時刻Ｔｅ）及び混雑度合いＤｃｒ（外部イベントＥにかかわる人数）を含む（図７のＳ２０１）。これにより、外部イベントＥの影響を、配送ドローン２６（自律移動体）の移動計画又は動作状態に精度良く反映することが可能となる。

本実施形態において、外部イベント情報Ｉｅｅは、外部イベントＥの場所Ｌｅｅ（会場）に存在する物品の評価額情報としてのコストＣを含む（図５Ａ、図７のＳ２０１）。これにより、例えば、外部イベントＥの場所Ｌｅｅに高額な物品が配置されている場合、配送ドローン２６（自律移動体）の移動計画又は動作状態に反映することが可能となる。

本実施形態において、申請端末２８（外部機器）から外部イベント情報Ｉｅｅを受信したとき（図８のＳ２５４：ＴＲＵＥ）、交通管理サーバ２４（移動管理部４０）は、外部イベント情報Ｉｅｅに基づく外部イベント領域Ｒｅｅ（一時的移動制限場所）を設定する（図９のイベント領域画像３１２ａ〜３１２ｇ参照）。また、交通サーバ２４は、外部イベント領域Ｒｅｅに基づいて配送ドローン２６（自律移動体）の移動計画又は前記動作状態を変更する（図７のＳ２２１）。これにより、外部イベント領域Ｒｅｅを考慮して、配送ドローン２６の移動計画又は動作状態を変更することが可能となる。

本実施形態において、管理システム１０は、複数の移動体の個体毎又は種類毎の優先度である優先度ＰＲ（移動体優先度）を蓄積した飛行スケジュールＤＢ１６２（優先度データベース）を備える（図１）。また、交通管理サーバ２４（移動管理部４０）は、優先度ＰＲに基づいて配送ドローン２６（自律移動体）の移動計画又は前記動作状態を変更する（図８のＳ２５５）。これにより、配送ドローン２６等（自律移動体）の移動計画又は動作状態に優先度ＰＲを反映させることが可能となる。

本実施形態において、サービス管理サーバ２２（移動管理部４０）は、配送ドローン２６（自律移動体）の予定経路ＲＴｐを算出する際、予定経路ＲＴｐの候補としての経路候補ＲＴｃａｎ上において、配送ドローン２６の予定通過時刻Ｔｐｐ（予定移動時刻）に外部イベントＥが行われる場合（図４のＳ９６：ＦＡＬＳＥ）、予定配送時刻Ｔｐｄをずらして（Ｓ９９）予定経路ＲＴｐを算出する。これにより、時間的に外部イベントＥを避けて配送ドローン２６を移動させることが可能となる。

Ｂ．変形例
なお、本発明は、上記実施形態に限らず、本明細書の記載内容に基づき、種々の構成を採り得ることはもちろんである。例えば、以下の構成を採用することができる。

＜Ｂ−１．移動体＞
上記実施形態において、外部イベントＥに基づき予定経路ＲＴｐを変更する自律移動体は、配送ドローン２６であった（図１、図２及び図７）。しかしながら、例えば、外部イベント情報Ｉｅｅに基づいて自律移動体の移動計画又は動作状態を変更する観点からすれば、これに限らない。例えば、配送ドローン２６の代わりに、人の運送、緊急用途、撮影、広告、セキュリティ監視、測量等の用途で用いるドローンを、外部イベントＥに基づき予定経路ＲＴｐを変更する自律移動体とすることも可能である。或いは、ドローン以外の飛行体又は自律移動体に本発明を適用してもよい。例えば、ヘリコプタ又は船舶に本発明を適用することも可能である。

上記実施形態において、エンタテインメントドローン３０は、ユーザがマニュアル操作するリモートコントローラ３２により制御するホビー用であった（図１）。しかしながら、例えば、飛行許可申請にかかわる外部イベントＥの観点からすれば、これに限らない。例えば、エンタテインメントドローン３０は、ライトショー用であってもよい。

上記実施形態において、エンタテインメントドローン３０は、ユーザがマニュアル操作するリモートコントローラ３２によってのみ制御された（図１）。しかしながら、エンタテインメントドローン３０は、例えば交通サーバ２４により制御されてもよい。その場合、配送ドローン２６がエンタテインメントドローン３０に接近した場合、交通サーバ２４は、エンタテインメントドローン３０の飛行を中止させてもよい。或いは、交通サーバ２４は、飛行中のエンタテインメントドローン３０の位置情報を、配送ドローン２６又はサービスサーバ２２に送信して、配送ドローン２６がエンタテインメントドローン３０を避け易くしてもよい。

＜Ｂ−２．移動管理部４０＞
上記実施形態の移動管理部４０は、サービスサーバ２２及び交通管理サーバ２４を含んだ（図１）。しかしながら、例えば、複数の配送ドローン２６（又は自律移動体）の移動を管理する観点からすれば、これに限らない。例えば、交通サーバ２４のみから移動管理部４０を構成してもよい。或いは、サービスサーバ２２及び交通管理サーバ２４に加えて、所定区域毎に複数配置されて、配送ドローン２６等の飛行を管理するローカル管制サーバを設けることも可能である。そして、サービスサーバ２２から配送ドローン２６に対する配送指令は、ローカル管制サーバを介して送信されてもよい。

上記実施形態のサービスサーバ２２は、商品Ｇの配送を管理した（図１）。しかしながら、例えば、外部イベント情報Ｉｅｅに基づいて自律移動体の移動計画又は動作状態を変更する観点からすれば、これに限らない。例えば、サービスサーバ２２は、人の運送、緊急用途、撮影、広告、セキュリティ監視、測量、エンターテインメント、個人趣味等の用途を管理するものであってもよい。

＜Ｂ−３．受注時制御（図３及び図４）＞
上記実施形態の受注時制御では、経路選択肢ＲＴｏｐの中から１つの経路候補ＲＴｃａｎを選択し（図４のＳ９４）、経路候補ＲＴｃａｎ上に外部イベント領域Ｒｅｅがないか否かを判定することで（Ｓ９６）、予定経路ＲＴｐを算出した（Ｓ９７、Ｓ１００）。しかしながら、例えば、経路評価値Ｑを用いて予定経路ＲＴｐを算出する観点からすれば、これに限らない。例えば、出発地Ｐｓｔと目的地Ｐｔａｒを結ぶ複数の経路選択肢ＲＴｏｐを、複数の予定配送時刻Ｔｐｄそれぞれについて算出し、各経路選択肢ＲＴｏｐについて評価値Ｑを算出して、評価値Ｑが最小のものを予定経路ＲＴｐとしてもよい。

上記実施形態の受注時制御では、経路評価値Ｑを用いて予定経路ＲＴｐを算出した（図４）。しかしながら、例えば、外部イベント情報Ｉｅｅに基づいて自律移動体の移動計画又は動作状態を変更する観点からすれば、これに限らず、評価値Ｑを用いない方法で予定経路ＲＴｐを算出してもよい。

＜Ｂ−４．外部イベント情報Ｉｅｅ＞
上記実施形態の外部イベント情報Ｉｅｅは、外部イベントＥの場所Ｌｅｅ、外部イベントＥが行われる時間帯ＴＳｅ（又は時刻Ｔｅ）、混雑度合いＤｃｒを含んだ（図７のＳ２０１）。しかしながら、例えば、外部イベント情報Ｉｅｅに基づいて自律移動体の移動計画又は動作状態を変更する観点からすれば、これに限らない。例えば、外部イベント情報Ｉｅｅは、場所Ｌｅｅ及び時刻Ｔｅ又は時間帯ＴＳｅ以外の情報は含まなくてもよい。或いは、人の混雑度合いＤｃｒに加えて又はこれに代えて、車両の交通量を外部イベント情報Ｉｅｅとして用いることも可能である。

＜Ｂ−５．外部イベント関連制御（図８）＞
上記実施形態では、外部イベント情報Ｉｅｅに基づいて新たな外部イベント領域Ｒｅｅ（一時的移動制限場所）を設定し（図８のＳ２５８、図９のイベント領域画像３１２ａ〜３１２ｇ）、これにより、配送ドローン２６等の予定経路ＲＴｐを変更した（図４のＳ９６、図８のＳ２５５）。しかしながら、例えば、外部イベント情報Ｉｅｅによって配送ドローン２６等（自律移動体）の移動計画又は動作状態を変更する観点からすれば、これに限らない。

例えば、新たな外部イベント領域Ｒｅｅの設定に加えて又はこれに代えて、配送ドローン２６等の動作状態を変更することが可能である。変更する動作状態としては、例えば、配送ドローン２６等の飛行速度Ｖｄ又は高度Ｈを用いることができる。すなわち、外部イベント領域Ｒｅｅでは、飛行速度Ｖｄの減速又は高度Ｈの上昇を行うことも可能である。上記のように、配送ドローン２６の予定配送時刻Ｔｐｄを変更すること（図４のＳ９９）も、配送ドローン２６等の動作状態を変更することの１つに含まれる。

上記実施形態の外部イベント関連制御では、配送ドローン２６の飛行よりも、エンタテインメントドローン３０の飛行（外部イベントＥ）を優先した（図８のＳ２５５）。しかしながら、例えば、外部イベント情報Ｉｅｅに基づいて自律移動体の移動計画又は動作状態を変更する観点からすれば、これに限らない。例えば、飛行の優先度ＰＲを、金銭提示によるオークションにより設定してもよい。或いは、過去の信頼実績（違反履歴等）に基づいて優先度ＰＲを設定することもできる。或いは、緊急搬送又は運送業務若しくは定常運行を優先し、臨時飛行又は臨時イベントは優先度ＰＲを下げることも可能である。

＜Ｂ−６．外部イベント申請画面３００＞
上記実施形態の外部イベント申請画面３００（イベント地点入力画像３０２）は、図９に示す内容であった。しかしながら、例えば、外部イベント情報Ｉｅｅに基づいて自律移動体の移動計画又は動作状態を変更する観点からすれば、これに限らない。

例えば、申請画面３００は、配送ドローン２６の予定経路ＲＴｐを表示してもよい。その場合、申請端末２８以外の外部端末（例えば、図示しないスマートフォン）でも申請画面３００を表示してもよい。これにより、配送ドローン２６及びエンタテインメントドローン３０のいずれも利用しない人々も、配送ドローン２６の予定経路ＲＴｐ及び外部イベント領域Ｒｅｅを知ることが可能となる。

＜Ｂ−７．その他＞
上記実施形態では、図２〜図４、図７及び図８に示すフローを用いた。しかしながら、例えば、本発明の効果を得られる場合、フローの内容（各ステップの順番）は、これに限らない。例えば、図８のステップＳ２５７とＳ２５８の順番を入れ替えることが可能である。

１０…管理システム
２２…サービス管理サーバ（管理サーバ）
２６…配送ドローン（自律移動体） ２８…申請端末（外部機器）
４０…移動管理部 ８２…通信部（通信装置）
１００…動的計画変更部
１６２…飛行スケジュールＤＢ（優先度データベース）
１７４…第１ドローン制御装置（自律制御部）
Ｃ…コスト（外部イベントの場所に存在する物品の評価額情報）
Ｄｃｒ…混雑度合い Ｅ…外部イベント
Ｉｅｅ…外部イベント情報 Ｌｅｅ…外部イベントの場所
ＰＲ…優先度（移動体優先度） Ｐｓｔ…出発地
Ｐｔａｒ…目的地
Ｒｅｅ…外部イベント領域（一時的移動制限場所）
ＲＴｃａｎ…経路候補（予定経路の候補）
ＲＴｐ…予定経路
Ｔｅ…外部イベントが行われる時刻
Ｔｐｐ…予定通過時刻（予定移動時刻）
ＴＳｅ…外部イベントが行われる時間帯

Claims (8)

1. 出発地から目的地まで移動するための自律制御部を備えた少なくとも１台の自律移動体と、
   通信装置を介して前記自律移動体と通信し、前記自律移動体を含む複数の移動体の移動を管理する移動管理部と
   を備える管理システムであって、
   前記移動管理部は、前記出発地から前記目的地の間で行われる外部イベントに関する情報である外部イベント情報を外部機器から受信し、前記外部イベント情報に基づいて前記自律移動体の移動計画又は動作状態を変更する動的計画変更部を備える
   ことを特徴とする管理システム。
2. 請求項１に記載の管理システムにおいて、
   前記外部イベント情報は、前記外部イベントが行われる時刻若しくは時間帯、前記外部イベントの混雑度合い、又は前記外部イベントに伴う交通量を含む
   ことを特徴とする管理システム。
3. 請求項１又は２に記載の管理システムにおいて、
   前記外部イベント情報は、前記外部イベントの場所に存在する物品の評価額情報を含む
   ことを特徴とする管理システム。
4. 請求項１〜３のいずれか１項に記載の管理システムにおいて、
   前記外部機器から前記外部イベント情報を受信したとき、前記移動管理部は、
   前記自律移動体の移動が一時的に制限される領域又は地点としての一時的移動制限場所を前記外部イベント情報に基づいて設定し、
   前記自律移動体の前記移動計画又は前記動作状態を前記一時的移動制限場所に基づいて変更する
   ことを特徴とする管理システム。
5. 請求項１〜４のいずれか１項に記載の管理システムにおいて、
   前記管理システムは、前記複数の移動体の個体毎又は種類毎の優先度である移動体優先度を蓄積した優先度データベースを備え、
   前記移動管理部は、前記移動体優先度に基づいて前記自律移動体の前記移動計画又は前記動作状態を変更する
   ことを特徴とする管理システム。
6. 請求項１〜５のいずれか１項に記載の管理システムにおいて、
   前記移動管理部は、前記自律移動体の予定経路を算出する際、前記予定経路の候補上において、前記自律移動体の予定移動時刻又は予定移動時間帯に前記外部イベントが行われる場合、前記予定移動時刻又は前記予定移動時間帯をずらして前記予定経路を算出する
   ことを特徴とする管理システム。
7. 出発地から目的地まで移動するための自律制御部を備えた少なくとも１台の自律移動体と、
   通信装置を介して前記自律移動体と通信し、前記自律移動体を含む複数の移動体の移動を管理する移動管理部と
   を備える管理システムの制御方法であって、
   前記移動管理部の動的計画変更部は、
   前記出発地から前記目的地の間で行われる外部イベントに関する情報である外部イベント情報を外部機器から受信し、
   前記外部イベント情報に基づいて前記自律移動体の移動計画又は動作状態を変更する
   ことを特徴とする制御方法。
8. 出発地から目的地まで移動するための自律制御部を備えた少なくとも１台の自律移動体と通信し、前記自律移動体を含む複数の移動体の移動を管理する管理サーバであって、
   前記管理サーバは、前記出発地から前記目的地の間で行われる外部イベントに関する情報である外部イベント情報を外部機器から受信し、前記外部イベント情報に基づいて前記自律移動体の移動計画又は動作状態を変更する動的計画変更部を備える
   ことを特徴とする管理サーバ。

Images