特許 7548117 遠隔支援管理システム、遠隔支援管理方法、及び遠隔支援管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-02

(45)【発行日】2024-09-10

(54)【発明の名称】遠隔支援管理システム、遠隔支援管理方法、及び遠隔支援管理プログラム

(51)【国際特許分類】

   G08G 1/09 20060101AFI20240903BHJP

   G08G 1/00 20060101ALI20240903BHJP

   B60W 60/00 20200101ALI20240903BHJP

【ＦＩ】

G08G1/09 F

G08G1/00 A

B60W60/00

【請求項の数】 11

(21)【出願番号】P 2021079312

(22)【出願日】2021-05-07

(65)【公開番号】P2022172948

(43)【公開日】2022-11-17

【審査請求日】2023-05-12

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110003199

【氏名又は名称】弁理士法人高田・高橋国際特許事務所

(72)【発明者】

【氏名】足立 義貴

(72)【発明者】

【氏名】市川 健太郎

(72)【発明者】

【氏名】田口 康治

(72)【発明者】

【氏名】平野 麻衣子

【審査官】武内 俊之

(56)【参考文献】

【文献】特開２０１９－１８５２７９（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／０９

Ｇ０８Ｇ １／００

Ｂ６０Ｗ ６０／００

(57)【特許請求の範囲】

【請求項1】

自律走行する複数の車両と通信し、前記車両からの支援要求を受けてオペレータに遠隔支援を行わせる遠隔支援管理システムにおいて、
少なくとも１つのプログラムを含む少なくとも１つのメモリと、
前記少なくとも１つのメモリと結合された少なくとも１つのプロセッサと、を含み、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
各車両の運行状況に基づいて車両ごとに将来における前記支援要求の発生を予測すること、
発生が予測された前記支援要求ごとに予測支援期間を計算すること、及び、
発生が予測された前記支援要求ごとに前記支援要求の発生確率を計算すること、を実行し、
前記予測支援期間が同一時刻において重なる重複支援要求が所定数を超えて発生することが予測された場合、
前記重複支援要求の発生が予測された車両のうち前記所定数を超える台数の車両に対し通常の運転モードである第１の運転モードから前記支援要求の発生を回避或いは遅延させるための第２の運転モードへの変更を指示すること、
前記重複支援要求の発生が予測された車両のそれぞれについて、前記支援要求の発生を優先的に回避或いは遅延させる車両を決定するための評価値を、前記発生確率が高い前記支援要求の発生が予測される車両ほど高い値に計算すること、及び、
前記評価値の高い順に前記第１の運転モードから前記第２の運転モードへの変更を指示する車両を選定すること、を実行する
ことを特徴とする遠隔支援管理システム。

【請求項2】

請求項１に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
発生が予測された前記支援要求ごとに、前記支援要求の原因が周囲に与える影響の大きさを表す影響度を計算し、
前記影響度が高い前記支援要求の発生が予測される車両ほど前記評価値を高い値に計算する
ことを特徴とする遠隔支援管理システム。

【請求項3】

請求項１又は２に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
発生が予測された前記支援要求ごとに、前記支援要求の処理に必要な前記オペレータのスキルを計算し、
前記スキルが高い前記支援要求の発生が予測される車両ほど前記評価値を高い値に計算する
ことを特徴とする遠隔支援管理システム。

【請求項4】

請求項１乃至３の何れか１項に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
発生が予測された前記支援要求ごとに、前記支援要求の処理に必要とされる処理時間を計算し、
前記処理時間が長い前記支援要求の発生が予測される車両ほど前記評価値を高い値に計算する
ことを特徴とする遠隔支援管理システム。

【請求項5】

請求項１乃至４の何れか１項に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
発生が予測された前記支援要求ごとに、前記支援要求が発生するまでの余裕時間を計算し、
前記余裕時間が長い前記支援要求の発生が予測される車両ほど前記評価値を高い値に計算する
ことを特徴とする遠隔支援管理システム。

【請求項6】

請求項１乃至５の何れか１項に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
所定の更新周期で前記支援要求の発生の予測を行い、
前記更新周期より長い所定の予測時間だけ将来の時刻まで前記予測を行う
ことを特徴とする遠隔支援管理システム。

【請求項7】

請求項６に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのプロセッサは、前記少なくとも１つのプログラムの実行時、
前記重複支援要求の発生が予測された車両のうち前記第１の運転モードから前記第２の運転モードへの変更を指示しない車両に対し前記オペレータを配置し、
前記更新周期ごとに前記オペレータの配置を更新する
ことを特徴とする遠隔支援管理システム。

【請求項8】

請求項１乃至７の何れか１項に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのメモリと前記少なくとも１つのプロセッサとは、前記複数の車両と通信するサーバに設けられ、
前記サーバは、
対象車両の運行状況と前記対象車両以外の他の車両の運行状況とを取得し、
前記対象車両の運行状況と前記他の車両の運行状況とに基づいて前記対象車両の将来における前記支援要求の発生を予測する
ことを特徴とする遠隔支援管理システム。

【請求項9】

請求項１乃至７の何れか１項に記載の遠隔支援管理システムにおいて、
前記少なくとも１つのメモリと前記少なくとも１つのプロセッサとは、前記複数の車両のそれぞれに搭載された車載コンピュータと、前記車載コンピュータと通信するサーバとに分散して設けられ、
前記車載コンピュータは、
前記車載コンピュータが搭載された対象車両のセンサを用いて前記対象車両の運行状況を取得し、
前記対象車両の運行状況に基づいて当該車両の将来における前記支援要求の発生を予測し、
前記支援要求の発生が予測された場合、前記支援要求の発生の予測に関する情報を前記サーバに送信する
ことを特徴とする遠隔支援管理システム。

【請求項10】

自律走行が可能であり且つオペレータからの遠隔支援を受けることができる複数の車両に対する遠隔支援管理方法であって、
各車両の運行状況に基づいて車両ごとに将来における前記車両から前記オペレータへの支援要求の発生を予測するステップと、
発生が予測された前記支援要求ごとに予測支援期間を計算するステップと、
発生が予測された前記支援要求ごとに前記支援要求の発生確率を計算するステップと、
前記予測支援期間が同一時刻において重なる重複支援要求が所定数を超えて発生することが予測された場合に実行されるステップであって、
前記重複支援要求の発生が予測された車両のうち前記所定数を超える台数の車両に対し通常の運転モードである第１の運転モードから前記支援要求の発生を回避或いは遅延させるための第２の運転モードへの変更を指示するステップと、
前記重複支援要求の発生が予測された車両のそれぞれについて、前記支援要求の発生を優先的に回避或いは遅延させる車両を決定するための評価値を、前記発生確率が高い前記支援要求の発生が予測される車両ほど高い値に計算するステップと、
前記評価値の高い順に前記第１の運転モードから前記第２の運転モードへの変更を指示する車両を選定するステップと、を含むステップと、を含むステップと、を含む
ことを特徴とする遠隔支援管理方法。

【請求項11】

自律走行する複数の車両と通信し、前記車両からの支援要求を受けてオペレータに遠隔支援を行わせることをコンピュータに実行させる遠隔支援管理プログラムにおいて、
各車両の運行状況に基づいて車両ごとに将来における前記支援要求の発生を予測すること、
発生が予測された前記支援要求ごとに予測支援期間を計算すること、及び、
発生が予測された前記支援要求ごとに前記支援要求の発生確率を計算すること、を前記コンピュータに実行させ、
前記予測支援期間が同一時刻において重なる重複支援要求が所定数を超えて発生することが予測された場合、
前記重複支援要求の発生が予測された車両のうち前記所定数を超える台数の車両に対し通常の運転モードである第１の運転モードから前記支援要求の発生を回避或いは遅延させるための第２の運転モードへの変更を指示すること、
前記重複支援要求の発生が予測された車両のそれぞれについて、前記支援要求の発生を優先的に回避或いは遅延させる車両を決定するための評価値を、前記発生確率が高い前記支援要求の発生が予測される車両ほど高い値に計算すること、及び、
前記評価値の高い順に前記第１の運転モードから前記第２の運転モードへの変更を指示する車両を選定すること、を前記コンピュータに実行させる
ことを特徴とする遠隔支援管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、自律走行する複数の車両と通信し、前記車両からの支援要求を受けてオペレータに遠隔支援を行わせる遠隔支援管理システム、遠隔支援管理方法、及び遠隔支援管理プログラムに関する。

【背景技術】

【0002】

自動運転車両は基本的に自律で自動走行を継続する。しかし、自動運転車両の自律判断が不確実な場合や、より確実な安全判断が必要な場合がある。このため、自動運転車両の自律判断に全てを任せるのではなく、自動運転車両を遠隔で監視し、必要な場合には、オペレータが判断や遠隔走行指示を車両に伝えることで、自動運転車両の自動走行を支援することが検討されている。そのような遠隔支援管理システムに関する従来技術の一つが下記の特許文献１に開示されている。

【0003】

特許文献１に開示された従来技術は、遠隔支援を必要とする自動運転車両に対するオペレータの割り当て方に関する提案である。この従来技術では、遠隔支援に掛かる作業時間及び優先度に基づき処理順序が決定され、その処理順序に従って遠隔支援の作業がオペレータに割り当てられる。これにより、遠隔支援を必要とする車両が交通を妨げることを回避し、自動運転システム全体としての交通の円滑化をはかることができる。

【0004】

このように、遠隔支援管理システムにおいては、自動運転車両を遠隔監視、操作するオペレータの役割は重要である。自動運転車両からの支援要求に速やかに応えることができる万全の体制を整えるのであれば、自動運転車両の総数に対するオペレータの人員は多ければ多いほどよい。

【0005】

しかし、オペレータの人員が増えるほど人件費が高くなり、ビジネスとしての成立が困難になってしまう。一方、オペレータの人員を単純に減らしてしまうと、オペレータ一人当たりの負荷が高くなるだけでなく、人員以上の支援要求が自動運転車両から届いた場合には、対応不可能となってしまう。

【0006】

上述の従来技術は、支援要求に対してオペレータの人数が足りていることが前提となっている。同時に多数の支援要求が発生した場合、上述の従来技術では、一部の支援要求に対してオペレータを割り当てることができない事態が起こりうる。この場合、オペレータからの判断又は走行指示をもらえない自動運転車両が路上で立ち往生する虞もあれば、不確実な情報で自動運転車両が走行することによってトラブルが発生する虞もある。

【0007】

なお、本開示に関連する技術分野の技術水準を示す文献としては、上述の特許文献１の他にも下記の特許文献２を例示することができる。

【先行技術文献】

【特許文献】

【0008】

【文献】特開２０１９－１８５２７９号公報

【文献】特開２０２０－０４２７６４号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

本開示は、上述のような問題に鑑みてなされたもので、自動運転車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することができる技術を提供することを目的とする。

【課題を解決するための手段】

【0010】

本開示は、上記目的を達成するための遠隔支援管理システムを提供する。本開示に係る遠隔支援管理システムは、自律走行する複数の車両と通信し、車両からの支援要求を受けてオペレータに遠隔支援を行わせるシステムである。本遠隔支援管理システムは、少なくとも１つのプログラムを含む少なくとも１つのメモリと、その少なくとも１つのメモリと結合された少なくとも１つのプロセッサとを含む。上記少なくとも１つのプロセッサは、上記少なくとも１つのプログラムの実行時、各車両の運行状況に基づいて車両ごとに将来における支援要求の発生を予測し、発生が予測された支援要求ごとに予測支援期間を計算する。予測支援期間が同一時刻において重なる重複支援要求が所定数を超えて発生することが予測された場合、上記少なくとも１つのプロセッサは、重複支援要求の発生が予測された車両のうち所定数を超える台数の車両に対し運転モードの変更を指示する。詳しくは、上記少なくとも１つのプロセッサは、通常の運転モードである第１の運転モードから支援要求の発生を回避或いは遅延させるための第２の運転モードへの変更を指示する。

【0011】

本遠隔支援管理システムによれば、将来における支援要求の発生が車両ごとに事前に予測される。そして、複数の支援要求について予測支援期間が同一時刻において重なり、その重複数が所定数を超える場合には、重複支援要求の発生が予測された車両のうち、所定数を超える台数の車両に対して、運転モードの変更が指示される。運転モードが変更されることで、支援要求の発生が回避されたり支援要求の発生が遅延したりする。これにより、実際に支援要求が発生した場合に、支援期間が同一時刻において重なる支援要求の数は所定数以下に抑えられる。その結果、遠隔支援を行うオペレータ全体の負荷は低減され、自動運転車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することができる。

【0012】

本遠隔支援管理システムにおいて、上記少なくとも１つのプロセッサは、重複支援要求の発生が予測された車両のそれぞれについて評価値を計算し、評価値の高い順に第１の運転モードから第２の運転モードへの変更を指示する車両を選定してもよい。評価値は、支援要求の発生を優先的に回避或いは遅延させる車両を決定するための指標である。運転モードを変更する車両はランダムに選択してもよい。しかし、このように運転モードを変更する車両を一定の指標に基づき選択することによって、遠隔支援に必要なオペレータの人員をより確実に低減することができる。

【0013】

評価値の計算方法としては、例えば、以下の方法が例示される。

【0014】

第１の例では、発生が予測された支援要求ごとに支援要求の発生確率が計算され、発生確率が高い支援要求の発生が予測される車両ほど評価値は高い値に計算される。第１の例によれば、発生確率が高い支援要求の発生を回避する或いはそのような支援要求の発生を遅延させることができ、オペレータ全体の負荷を低減することができる。

【0015】

第２の例では、発生が予測された支援要求ごとに、支援要求の原因が周囲に与える影響の大きさを表す影響度が計算され、影響度が高い支援要求の発生が予測される車両ほど評価値は高い値に計算される。第２の例によれば、周囲に与える影響の大きい現象の発生を回避する或いはそのような現象の発生を遅延させることができ、円滑な交通を維持することができる。

【0016】

第３の例では、発生が予測された支援要求ごとに、支援要求の処理に必要なオペレータのスキルが計算され、スキルが高い支援要求の発生が予測される車両ほど評価値は高い値に計算される。オペレータの利用コストはオペレータが有するスキルの高さに依存する場合がある。第３の例によれば、処理する上で高いスキルを要する支援要求の発生を回避する或いはそのような支援要求の発生を遅延させることができ、オペレータの利用コストを低減することができる。

【0017】

第４の例では、発生が予測された支援要求ごとに、支援要求の処理に必要とされる処理時間が計算され、処理時間が長い支援要求の発生が予測される車両ほど評価値は高い値に計算される。オペレータの利用コストは支援要求の処理に要した時間に依存する場合がある。第４の例によれば、長い処理時間を要する支援要求の発生を回避する或いはそのような支援要求の発生を遅延させることができ、オペレータの利用コストを低減することができる。また、第４の例によれば、１台の車両に対する支援にオペレータが専有されることを抑えることができる。

【0018】

第５の例では、発生が予測された支援要求ごとに、支援要求が発生するまでの余裕時間が計算され、余裕時間が長い支援要求の発生が予測される車両ほど評価値は高い値に計算される。第５の例によれば、余裕時間の長い支援要求の発生を回避する或いはそのような支援要求の発生を遅延させることにより、運転モードの変更を指示された車両が運転モードを変更するまでの応答時間に余裕を持たせることができる。その結果として、運転モードの変更の確実性を向上させることができる。

【0019】

本遠隔支援管理システムにおいて、上記少なくとも１つのプロセッサは、所定の更新周期で支援要求の発生の予測を行い、更新周期より長い所定の予測時間だけ将来の時刻まで予測を行ってもよい。支援要求の発生を予測する予測時間を予測結果の更新周期よりも長くすることで、予測の精度を高めることができる。

【0020】

本遠隔支援管理システムにおいて、上記少なくとも１つのプロセッサは、重複支援要求の発生が予測された車両のうち運転モードの変更を指示しない車両に対しオペレータを配置し、更新周期ごとにオペレータの配置を更新してもよい。支援要求の発生の予測を行う更新周期に併せてオペレータの配置を更新していくことで、実際の支援要求に速やかに応答できるようにオペレータを配置することができる。

【0021】

本遠隔支援管理システムにおいて、上記少なくとも１つのメモリと上記少なくとも１つのプロセッサとは、複数の車両と通信するサーバに設けられてもよい。この場合、サーバは、対象車両の運行状況と対象車両以外の他の車両の運行状況とを取得し、対象車両の運行状況と他の車両の運行状況とに基づいて対象車両の将来における支援要求の発生を予測してもよい。サーバにおいて対象車両の運行状況だけでなく他の車両の運行状況にも基づいて対象車両における支援要求の発生を予測することにより、支援要求の発生の予測精度を高めることができる。なお、対象車両及び他の車両の運行状況は各車両から取得してもよいし、車両の運行を管理・指示する運行管理サーバ（或いは、サーバ内のプログラム）から取得してもよい。

【0022】

本遠隔支援管理システムにおいて、上記少なくとも１つのメモリと上記少なくとも１つのプロセッサとは、複数の車両のそれぞれに搭載された車載コンピュータと、車載コンピュータと通信するサーバとに分散して設けられてもよい。この場合、車載コンピュータは、車載コンピュータが搭載された対象車両のセンサを用いて対象車両の運行状況を取得し、対象車両の運行状況に基づいて当該車両の将来における前記支援要求の発生を予測してもよい。そして支援要求の発生が予測された場合、車載コンピュータからサーバに、支援要求の発生の予測に関する情報が送信されてもよい。車載コンピュータが搭載された対象車両のセンサを用いて対象車両の運行状況を取得することにより、高い応答性をもって対象車両における支援要求の発生を予測することができる。

【0023】

また、本開示は、上記目的を達成するための遠隔支援管理方法を提供する。本開示に係る遠隔支援管理方法は、自律走行が可能であり且つオペレータからの遠隔支援を受けることができる複数の車両に対する遠隔支援管理方法である。本遠隔支援管理方法は、各車両の運行状況に基づいて、車両ごとに、将来における車両からオペレータへの支援要求の発生を予測するステップと、発生が予測された支援要求ごとに予測支援期間を計算するステップとを含む。さらに、本遠隔支援管理方法は、予測支援期間が同一時刻において重なる重複支援要求が所定数を超えて発生することが予測された場合に実行されるステップを含む。このステップでは、重複支援要求の発生が予測された車両のうち所定数を超える台数の車両に対し通常の運転モードである第１の運転モードから支援要求の発生を回避或いは遅延させるための第２の運転モードへの変更が指示される。

【0024】

さらに、本開示は、上記目的を達成するための遠隔支援管理プログラムを提供する。本開示に係る遠隔支援管理プログラムは、自律走行する複数の車両と通信し、車両からの支援要求を受けてオペレータに遠隔支援を行わせることをコンピュータに実行させるプログラムである。本遠隔支援管理プログラムは、各車両の運行状況に基づいて車両ごとに将来における支援要求の発生を予測すること、及び、発生が予測された支援要求ごとに予測支援期間を計算することをコンピュータに実行させる。さらに、本遠隔支援管理プログラムは、予測支援期間が同一時刻において重なる重複支援要求が所定数を超えて発生することが予測された場合、運転モードの変更を指示することをコンピュータに実行させる。詳しくは、本遠隔支援管理プログラムは、通常の運転モードである第１の運転モードから支援要求の発生を回避或いは遅延させるための第２の運転モードへの変更を指示することをコンピュータに実行させる。

【0025】

上述の本遠隔支援管理方法、及び本遠隔支援管理プログラムによれば、将来における支援要求の発生が車両ごとに事前に予測される。そして、複数の支援要求について予測支援期間が同一時刻において重なり、その重複数が所定数を超える場合には、重複支援要求の発生が予測された車両のうち、所定数を超える台数の車両に対して、運転モードの変更が指示される。運転モードが変更されることで、支援要求の発生が回避されたり支援要求の発生が遅延したりする。これにより、実際に支援要求が発生した場合に、支援期間が同一時刻において重なる支援要求の数は所定数以下に抑えられる。その結果、遠隔支援を行うオペレータ全体の負荷は低減され、自動運転車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することができる。

【発明の効果】

【0026】

上述のように、本開示に係る遠隔支援システム、遠隔支援管理方法、及び本遠隔支援管理プログラムによれば、自動運転車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することができる。

【図面の簡単な説明】

【0027】

【図1】自動運転車両の遠隔監視システムの構成図である。

【図2】自動運転車両の構成の一例を示すブロック図である。

【図3】監視センタの構成の一例を示すブロック図である。

【図4】複数の車両から支援要求が発せられた場合のオペレータの負荷の例を示す図である。

【図5】潜在支援要求の評価値による順位付けの例を示す図である。

【図6】支援要求の発生の回避によるオペレータの負荷の適正化の例を示す図である。

【図7】支援要求の発生の遅延によるオペレータの負荷の適正化の例を示す図である。

【図8】運転モードの変更の第１の具体例を示す図である。

【図9】運転モードの変更の第２の具体例を示す図である。

【図10】運転モードの変更の第３の具体例を示す図である。

【図11】本開示の第１実施形態に係る遠隔支援管理システムのシステム構成図である。

【図12】本開示の第１実施形態に係る遠隔支援管理システムによる、車両Ａ（要支援車両）、車両Ｂ（支援不要車両）、遠隔支援管理プランナ、オペレータ間の情報の流れを示すシーケンス図である。

【図13】本開示の第２実施形態に係る遠隔支援管理システムのシステム構成図である。

【図14】本開示の第２実施形態に係る遠隔支援管理システムによる、車両Ａ（要支援車両）、車両Ｂ（支援不要車両）、遠隔支援管理プランナ、オペレータ間の情報の流れを示すシーケンス図である。

【発明を実施するための形態】

【0028】

以下、図面を参照して本開示の実施形態について説明する。ただし、以下に示す実施形態において各要素の個数、数量、量、範囲等の数に言及した場合、特に明示した場合や原理的に明らかにその数に特定される場合を除いて、その言及した数に、本開示に係る技術思想が限定されるものではない。また、以下に示す実施形態において説明する構造等は、特に明示した場合や明らかに原理的にそれに特定される場合を除いて、本開示に係る技術思想に必ずしも必須のものではない。

【0029】

１．遠隔支援管理システムの基本構成
図１は、自動運転車両の遠隔監視システムの構成図である。遠隔監視システム１００は、遠隔オペレータ３５，３６，３８，３９によって自動運転車両２０を遠隔監視するシステムである。以下、遠隔オペレータ３５，３６，３８，３９を単にオペレータ３５，３６，３８，３９と呼ぶ。遠隔監視の対象とされる自動運転車両２０の自動運転レベルとしては、例えば、レベル４又はレベル５が想定される。以下、自動運転車両２０を単に車両２０と呼ぶ。

【0030】

オペレータ３５，３６，３８，３９は、例えば、監視センタ３０に常駐して車両２０を監視する常駐オペレータ３５，３６と、在宅で車両２０を監視する在宅オペレータ３８，３９とを含む。監視センタ３０にはサーバ３２が設置されている。常駐オペレータ３５，３６が操作する操作端末３４は、監視センタ３０内のＬＡＮを介してサーバ３２に接続されている。在宅オペレータ３８，３９が操作する操作端末３７は、インターネットを含む通信ネットワーク１０を介してサーバ３２に接続されている。操作端末３４，３７は、それぞれ、オペレータ３５，３６，３８，３９の人数に見合った台数が用意されている。

【0031】

遠隔監視システム１００の一つの機能が車両２０の遠隔支援管理である。そして、遠隔支援管理を行うシステムが本開示の各実施形態に係る遠隔支援管理システムである。第１実施形態では、監視センタ３０内のサーバ３２が遠隔支援管理システムとして機能し、第２実施形態では、監視センタ３０内のサーバ３２と車両２０の車載コンピュータとによって遠隔支援管理システムが構成される。サーバ３２は、４Ｇや５Ｇを含む通信ネットワーク１０を介して複数台の車両２０に接続されている。

【0032】

遠隔支援管理システムは、自律走行する複数の車両２０と通信し、車両２０からの支援要求を受けてオペレータ３５，３６，３８，３９に遠隔支援を行わせるシステムである。遠隔支援では、車両２０による自動運転のための判断の一部はオペレータ３５，３６，３８，３９が行う。運転に必要な認知、判断、及び操作に関する基本的な計算は車両２０において行われる。オペレータ３５，３６，３８，３９は、車両２０から送信される情報に基づき、車両２０が取るべき行動を判断し、車両２０に指令する。オペレータ３５，３６，３８，３９から車両２０に対して送られる遠隔支援の指令には、車両２０の進行の指令及び車両２０の停止の指令が含まれる。また、遠隔支援の指令には、前方の障害物に対するオフセット回避の指令、先行車の追い越しの指示、緊急退避の指示等が含まれていてもよい。

【0033】

なお、遠隔支援に対するオペレータ３５，３６，３８，３９のスキル、すなわち、熟練度は一様ではない。常駐オペレータ３５，３６は、高いスキルを持ったオペレータ３５と、スキルが低いオペレータ３６とに分けられる。同様に、在宅オペレータ３８，３９も、高いスキルを持ったオペレータ３８と、スキルが低いオペレータ３９とに分けられる。一般に、高いスキルを持ったオペレータ３５，３８の利用コスト（人件費）は相対的に高く、スキルが低いオペレータ３６，３９の利用コストは相対的に低い。オペレータ３５，３６，３８，３９の人数は１人以上、好ましくは複数人であることが好ましい。特に、高スキルの常駐オペレータ３５は、少なくとも１人存在することが好ましい。

【0034】

図２は、車両２０の構成の一例を示すブロック図である。車両２０は、車載コンピュータ２１を備える。車載コンピュータ２１は、車両２０に搭載される複数のＥＣＵ（Electronic Control Unit）の集合体である。また、車両２０は、外部センサ２２、内部センサ２３、アクチュエータ２４、及び通信装置２５を備える。これらは、ＣＡＮ（Controller Area Network）等の車載ネットワークを用いて車載コンピュータ２１に接続されている。

【0035】

車載コンピュータ２１は、１つ又は複数のプロセッサ２１ａ（以下、単にプロセッサ２１ａと呼ぶ）とプロセッサ２１ａに結合された１つ又は複数のメモリ２１ｂ（以下、単にメモリ２１ｂと呼ぶ）とを備えている。メモリ２１ｂには、プロセッサ２１ａで実行可能な１つ又は複数のプログラム２１ｃ（以下、単にプログラム２１ｃと呼ぶ）とそれに関連する種々の情報とが記憶されている。

【0036】

プロセッサ２１ａがプログラム２１ｃを実行することにより、プロセッサ２１ａによる各種処理が実現される。プログラム２１ｃには、例えば、自動運転を実現するためのプログラムと、遠隔支援を実現するためのプログラムとが含まれる。また、第２実施形態の場合、プログラム２１ｃには、車載コンピュータ２１を遠隔支援管理システムの一部として機能させるプログラムが含まれる。メモリ２１ｂは主記憶装置と補助記憶装置とを含む。プログラム２１ｃは、主記憶装置に記憶されることもできるし、補助記憶装置であるコンピュータ読み取り可能な記録媒体に記憶されることもできる。また、補助記憶装置には、自動運転のための地図情報を管理する地図データベースが記憶されていてもよい。

【0037】

外部センサ２２は、車両２０の周囲、特に車両２０の前方を撮像するカメラを含む。カメラは、複数台設けられていてもよく、車両２０の前方の他、側方及び後方を撮像してもよい。また、カメラは、自動運転用とオペレータ３５，３６，３８，３９による遠隔支援用とで共用されてもよいし、自動運転用のカメラと遠隔支援用のカメラとが別々に設けられてもよい。

【0038】

外部センサ２２は、カメラ以外の認識センサを含む。認識センサは、車両２０の周囲の状況を認識するための情報をするセンサである。カメラ以外の認識センサとしては、ＬｉＤＡＲ（Laser Imaging Detection and Ranging）、及びミリ波レーダが例示される。また、外部センサ２２は、車両２０の位置及び方位を検出する位置センサを含む。位置センサとしては、ＧＰＳ（Global Positioning System）センサが例示される。外部センサ２２で得られた情報は車載コンピュータ２１に送信される。また、外部センサ２２は、車両２０の周囲の音を集音するマイクを含む。

【0039】

内部センサ２３は、車両２０の運動に関する情報を取得する状態センサを含む。状態センサとしては、例えば、車輪速センサ、加速度センサ、角速度センサ、及び舵角センサが例示される。加速度センサと角速度センサとは、ＩＭＵであってもよい。内部センサ２３で得られた情報は車載コンピュータ２１に送信される。以下、内部センサ２３で得られた情報と外部センサ２２で得られた情報とを総称して車両２０の運行状況情報という。ただし、運行状況情報には、車両２０のセンサで取得される運行状況情報の他にも、車両２０の運行を管理する運行管理サーバで取得される運行状況情報も存在する。

【0040】

アクチュエータ２４は、車両２０を操舵する操舵装置、車両２０を駆動する駆動装置、及び車両２０を制動する制動装置を含んでいる。操舵装置には、例えば、パワーステアリングシステム、ステアバイワイヤ操舵システム、及び後輪操舵システムが含まれる。駆動装置には、例えば、エンジン、ＥＶシステム、及びハイブリッドシステムが含まれる。制動装置には、例えば、油圧ブレーキ、及び電力回生ブレーキが含まれる。アクチュエータ２４は、車載コンピュータ２１から送信される制御信号によって動作する。

【0041】

通信装置２５は、車両２０の外部との無線通信を制御する装置である。通信装置２５は、通信ネットワーク１０を介してサーバ３２と通信を行う。車載コンピュータ２１で処理された情報は、通信装置２５を用いてサーバ３２に送信される。サーバ３２で処理された情報は、通信装置２５を用いて車載コンピュータ２１に取り込まれる。また、自動運転のために他の車両との車車間通信やインフラ施設との路車間通信が必要な場合、それら外部装置との通信も通信装置２５によって行われる。

【0042】

図３は、監視センタ３０の構成の一例を示すブロック図である。監視センタ３０には、サーバ３２と通信装置３３と操作端末３４が設置されている。通信装置３３は、監視センタ３０の外部との通信を制御する装置である。通信装置３３は、通信ネットワーク１０を介して行われるサーバ３２と複数台の車両２０との通信を仲介する。サーバ３２で処理された情報は、通信装置３３を用いて車両２０に送信される。車両２０で処理された情報は、通信装置３３を用いてサーバ３２に取り込まれる。また、通信装置３３は、監視センタ３０の外部に設置された操作端末３７とサーバ３２との通信を仲介する。

【0043】

サーバ３２は、１つのコンピュータ、又は、通信ネットワークで接続された複数のコンピュータの集合体である。サーバ３２は、１つ又は複数のプロセッサ３２ａ（以下、単にプロセッサ３２ａと呼ぶ）とプロセッサ３２ａに結合された１又は複数のメモリ３２ｂ（以下、単にメモリ３２ｂと呼ぶ）とを備えている。メモリ３２ｂには、プロセッサ３２ａで実行可能な１つ又は複数のプログラム３２ｃ（以下、単にプログラム３２ｃと呼ぶ）とそれに関連する種々の情報とが記憶されている。

【0044】

プロセッサ３２ａがプログラム３２ｃを実行することにより、プロセッサ３２ａによる各種処理が実現される。第１実施形態の場合、プログラム３２ｃには、サーバ３２を遠隔支援管理システムとして機能させるプログラム（遠隔支援管理プログラム）が含まれる。第２実施形態の場合、プログラム３２ｃには、サーバ３２を遠隔支援管理システムの一部として機能させるプログラムが含まれる。メモリ３２ｂは主記憶装置と補助記憶装置とを含む。プログラム３２ｃは、主記憶装置に記憶されることもできるし、補助記憶装置であるコンピュータ読み取り可能な記録媒体に記憶されることもできる。また、補助記憶装置には、自動運転のための地図情報を管理する地図データベースが記憶されていてもよい。地図データベースは、サーバ３２と車載コンピュータ２１の少なくとも一方に記憶されていればよい。

【0045】

操作端末３４，３７は、情報出力部３４ａ，３７ａを備える。情報出力部３４ａ，３７ａは、オペレータ３５，３６，３８，３９に対して車両２０の遠隔支援に必要な情報を出力する機器である。情報出力部３４ａ，３７ａに出力される情報は、サーバ３２から各操作端末３４，３７に送信される。情報出力部３４ａ，３７ａは、映像を出力するディスプレイと音を出力するスピーカとを含む。ディスプレイには、例えば、車両２０のカメラが撮像した車両２０の前方の映像が表示される。ディスプレイは、複数の表示画面を有していてもよく、車両２０の側方及び／又は後方の映像が表示されてもよい。スピーカは、例えば、マイクにより集音された車両２０の周囲の状況を音声によりオペレータ３５，３６，３８，３９に伝える。

【0046】

操作端末３４，３７は、操作入力部３４ｂ，３７ｂを備える。操作入力部３４ｂ，３７ｂは、オペレータ３５，３６，３８，３９の遠隔支援のための操作を入力する機器である。操作入力部３４ｂ，３７ｂで入力された情報は、サーバ３２から車両２０に送信される。入力機器の具体例としては、ボタン、レバー、及びタッチパネルを例示することができる。例えば、レバーを倒す方向によって、車両２０に対して進行／停止を指示したり、横方向への移動を指示したりしてもよい。横方向への移動には、例えば、前方の障害物に対するオフセット回避、車線変更、先行車の追い越しが含まれる。

【0047】

２．遠隔支援管理システムの概要
本開示の遠隔支援管理システムの目的は、車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することにある。そこで、まず、複数の車両が運用されている場合にオペレータにかかる負荷について図４を用いて説明する。図４は、４台の車両Ａ，Ｂ，Ｃ，Ｄが運用されている状況において、これらの車両Ａ，Ｂ，Ｃ，Ｄから支援要求が発せられた場合のオペレータの負荷の例を示している。なお、ここでいうオペレータの負荷とは、支援要求の処理に必要なオペレータの人数を意味する。

【0048】

図４に示す例では、それぞれの車両Ａ，Ｂ，Ｃ，Ｄからばらばらのタイミングで支援要求が出されている。チャートの横軸は時間であり、支援要求に対応する長方形の長さは、その支援要求の処理に必要な時間、すなわち、支援時間を表している。必要な支援時間は、支援要求の内容によって異なる。図４に示す例では、複数の支援要求の間で支援時間が同一時刻で重なっている。例えば、支援要求Ａは支援要求Ｂと重なり、同時に支援要求Cとも重なっている。このように同一時刻において支援要求が重複する場合、重複した支援要求の数だけのオペレータが必要となる。図４に示す例では、必要なオペレータ人数は最大で３人である。しかし、仮にオペレータが２人しかいないとすると、支援要求Ａ，Ｂ，Cのうちのどれか１つは処理することができず、破綻が生じてしまう。支援要求に対してオペレータを割り当てられない状況をオペレータ破綻と呼ぶ。

【0049】

本開示の遠隔支援管理システムは、上記のような破綻を生じさせないための処理を実行する。概略的には、本開示の遠隔支援管理システムは、各車両の運行状況に基づいて車両ごとに将来における支援要求の発生を予測し、発生が予測された支援要求ごとに予測支援期間を計算する。予測支援期間は、その支援要求の処理に必要と予測される期間である。支援要求の内容に応じて標準的な支援時間が統計的に求められているので、予測支援期間の計算にはその統計上の支援時間が用いられる。以下、将来において発生が予測される支援要求を潜在支援要求と呼ぶ場合がある。潜在支援要求の予測に用いられる運行状況の情報には、例えば、地図情報、車両位置、走行経路、及び車速が含まれる。

【0050】

支援要求の発生が予測される状況としては、例えば、以下のような状況を挙げることができる。第１の例は、路車間通信機器（Ｖ２Ｉ）のない信号交差点である。路車間通信機器のない信号交差点では、信号の点灯色および周囲の状況判断のために支援要求の発生が予測される。路車間通信機器の有無の情報を予めデータベースに登録しておくことで、車両の位置情報、走行経路情報、車速情報から潜在支援要求の予測発生時刻及び予測支援時間を計算することができる。

【0051】

第２の例は、大型貨物自動車及び大型乗用車の密集箇所である。車両長が大きい大型車両が隣接する場合、認識センサによる物体の認識精度に低下を招くために支援要求の発生が予測される。本遠隔支援管理システムの運用前及び運用中に各車両のセンサで大型車両の駐車実績データを収集し、収集された駐車実績データから傾向分析を行うことで、密集した大型車両との遭遇頻度の高い場所・時間帯を特定することができる。特定された大型車両の密集場所・時間帯をデータベースに登録しておくことで、車両の位置情報、走行経路情報、車速情報から潜在支援要求の予測発生時刻及び予測支援時間を計算することができる。

【0052】

第３の例は、ＬｉＤＡＲの経時劣化による認識精度の低下である。ＬｉＤＡＲは射出されるレーザ光の反射強度を用いてセンシングする。このため、射出される光強度の絶対値の低下は認識性能の低下を意味し、自動運転の信頼性を低下させる。よって、ＬｉＤＡＲの認識精度が低下した状況では支援要求の発生が予測される。ＬｉＤＡＲに用いられる半導体レーザには、熱や過電流等を起因とした光学損傷による速い劣化と、結晶生成と作製プロセスに起因する遅い劣化とが存在する。ここでは遅い劣化に着目し、ある基準対象物からの反射強度のモニタリング結果を運行状況情報として取得する。第１及び第２の例とは異なり、第３の例では、運行状況情報としてのモニタリング結果を長期間監視することで経時劣化に伴う支援要求の発生が予測される。

【0053】

本開示の遠隔支援管理システムは、潜在支援要求の予測結果を所定の更新周期で更新する。そして、更新のたびに、更新周期より長い所定の予測時間だけ将来の時刻まで、潜在支援要求を予測する。一例として、更新周期を１秒とし、潜在支援要求の予測時間を１分としてもよい。潜在支援要求を予測する予測時間を予測結果の更新周期よりも長くすることで、予測の精度を高めることができる。

【0054】

本開示の遠隔支援管理システムは、潜在支援要求を車両ごとに予測し、複数の潜在支援要求の間で予測支援期間が同一時刻において重なるかどうか判定する。予測支援期間は、オペレータが１つの支援要求に拘束される期間を意味している。ゆえに、複数の潜在支援要求の間で予測支援期間が重なるのであれば、少なくとも重複している潜在支援要求の数の分だけのオペレータの人数が必要となる。以下、予測支援期間が同一時刻において重なる潜在支援要求を重複支援要求と呼ぶ。

【0055】

重複支援要求が所定数を超えて発生しオペレータの不足が予測された場合、本開示の遠隔支援管理システムは、一部の車両に対し運転モードの変更を指示することでオペレータ不足を回避する。ここで行われる運転モードの変更は、通常の運転モードである第１の運転モードから、支援要求の発生を回避或いは遅延させて重複支援要求の発生を回避するための第２の運転モードへの変更である。通常の運転モードとは、最も効率的且つ乗員にとって快適に自動運転を行うことができる運転モードである。運転モードの変更を指示する車両は、重複支援要求の発生が予測された車両のうち所定数を超える台数の車両である。典型的には、所定数は利用可能な待機オペレータの数である。具体的にどの車両に対して運転モードの変更を指示するのかは、重複支援要求の発生が予測された車両ごとに計算される評価値に基づいて判断される。

【0056】

上記の評価値は、支援要求の発生を優先的に回避或いは遅延させる車両の決定に用いられる。重複支援要求の発生が予測された車両のうち、評価値が高い車両から優先的に運転モードの変更が行われる。評価値の計算には、発生確率、影響度、必要スキル、必要処理時間、及び余裕時間の５つの変数が用いられる。以下の計算式（１）は、これら５つの変数を用いて表される評価値の計算式の一例である。なお、無次元化係数は所定の固定値である。
評価値＝無次元化係数×発生確率×必要スキル×処理時間×余裕時間／影響度
・・・式（１）

【0057】

第１の変数である発生確率は、支援要求の発生確率であって、潜在支援要求ごとに計算される。上記の計算式（１）によれば、発生確率が高い支援要求が予測される車両ほど、評価値は高い値に計算される。支援要求の発生確率が高いほど評価値を高い値にすることで、発生確率が高い支援要求の発生を回避或いは遅延させることができ、オペレータ全体の負荷を低減することができる。なお、発生確率の予測方法としては、以下の方法を例示することができる。第１の例では、過去のログデータから支援要求の発生箇所、発生時間帯、及び頻度を分析することにより、各時間帯における支援要求の発生確率が予測される。第２の例では、通過する地点の交通条件（トラックが多い等）、道路条件（交差点等）)、及び気象条件から遠隔支援の発生確率が予測される。

【0058】

第２の変数である影響度は、潜在支援要求の原因が周囲に与える影響の大きさを表す数値である。以下のリストでは、影響度の考え方から想定される事象が大きく分類分けされている。各分類に付されている数値が影響度である。ここでは影響度は１から６までの６段階に設定され、数値１が影響度の最も大きな事象を対象とし、数値の増加に応じて影響度は低下する。異常・故障に関わる事象の影響度は高くされ、正常状態における事象の影響度は低くされている。
影響度１．交通事故の発生が予測されたこと
影響度２．故障・異常による走行の継続の困難が予測されたこと
影響度３．故障・異常による縮退運転が予測されたこと
影響度４．自車の振る舞いで後突されるリスクのある事象が予測されたこと
影響度５．交通流を乱すリスクのある事象が予測されたこと
影響度６．運行遅延や乗り心地に影響を与える事象が予測されたこと

【0059】

影響度は潜在支援要求ごとに計算される。上記の計算式（１）によれば、影響度が高い支援要求の発生が予測される車両ほど、評価値は高い値に計算される。潜在支援要求の原因が周囲に与える影響度が高いほど評価値を高い値にすることで、周囲に与える影響の大きい現象の発生を回避或いは遅延させることができ、円滑な交通を維持することができる。上記の影響度は、運転モードを変更する順番を決定する上での優先度ともいえる。

【0060】

第３の変数である必要スキルは、予測された潜在支援要求の処理に必要なオペレータのスキルであって、潜在支援要求ごとに計算される。必要スキルが高いほどオペレータの利用コストも高くなる。上記の計算式（１）によれば、必要スキルが高い支援要求の発生が予測される車両ほど、評価値は高い値に計算される。必要スキルが高いほど評価値を高い値にすることで、処理する上で高いスキルを要する支援要求の発生を回避或いは遅延させることができ、オペレータの利用コストを低減することができる。

【0061】

第４の変数である処理時間は、予測された潜在支援要求の処理に必要とされる時間であって、潜在支援要求ごとに計算される。処理に要した時間が長くなるほどオペレータの利用コストは高くなる。上記の計算式（１）によれば、処理時間が長い支援要求の発生が予測される車両ほど、評価値は高い値に計算される。処理時間が長いほど評価値を高い値にすることで、長い処理時間を要する支援要求の発生を回避或いは遅延させることができ、オペレータの利用コストを低減することができる。それと同時に、１台の車両の支援にオペレータが専有されることを抑えることもできる。なお、処理時間と必要スキルとから、支援要求の難易度を表すタスクレベルを計算することができる。タスクレベルの高い支援要求は、高いスキルを有するオペレータに割り当てられることが望ましい。

【0062】

第５の変数である余裕時間は、潜在支援要求が予測されてから実際に支援要求が発生するまでの時間であって、潜在支援要求ごとに計算される。支援要求が発生するまでに十分な余裕がなければ、運転モードを変更したところで支援要求の発生を回避或いは遅延させることは難しい。上記の計算式（１）によれば、余裕時間が長い支援要求の発生が予測される車両ほど、評価値は高い値に計算される。これによれば、余裕時間の長い支援要求の発生を優先的に回避或いは遅延させ、運転モードの変更を指示された車両が運転モードを変更するまでの応答時間に余裕を持たせることができる。その結果として、運転モードの変更による支援要求の発生の回避或いは遅延の確実性を向上させることができる。

【0063】

図５は、車両Ａ，Ｂ，Ｃ，Ｄごとに潜在支援要求Ａ，Ｂ，Ｃ，Ｄを予測し、上述の方法にて計算された車両Ａ，Ｂ，Ｃ，Ｄごとの評価値に従って潜在支援要求Ａ，Ｂ，Ｃ，Ｄの順位付けをした例を示している。図５に示す例では、潜在支援要求Ａ，Ｂ，Ｃの間の重複度が最も高く、潜在支援要求Ａ，Ｂ，Ｃが重複する車両Ａ，Ｂ，Ｃのうちで車両Ｃの評価値が最も高い。よって、支援要求の発生を回避或いは遅延させる場合、評価値が最も高い車両Ｃから優先的に運転モードの変更が行われる。

【0064】

図６は、支援要求の発生の回避によるオペレータの負荷の適正化の例を示す図である。ここでは、車両Ｃの運転モードが変更されることによって、潜在支援要求Ｃが回避されている。そして、残った潜在支援要求Ａ，Ｂ，Ｄのうち潜在支援要求Ｂ，ＤはオペレータＡに割り当てられ、潜在支援要求ＡはオペレータＢに割り当てられている。潜在支援要求Ｂ，Ｄを割り当てられたオペレータＡは、実際に車両Ｂ，Ｄから発せられる支援要求を受けて車両Ｂ，Ｄに対する遠隔支援を実行する。潜在支援要求Ａを割り当てられたオペレータＢは、実際に車両Ａから発せられる支援要求を受けて車両Ａに対する遠隔支援を実行する。また、潜在支援要求Ｃが回避されたことにより、車両Ｃからの支援要求の発生は回避される。

【0065】

図７は、支援要求の発生の遅延によるオペレータの負荷の適正化の例を示す図である。ここでは、車両Ｃの運転モードが変更されることによって、潜在支援要求Ｃは遅延され、潜在支援要求Ａ，Ｂとの同一時刻での重複が解消されている。そして、潜在支援要求Ａ，Ｂ，Ｃ，Ｄのうち潜在支援要求Ｂ，ＤはオペレータＡに割り当てられ、潜在支援要求Ａと遅延された潜在支援要求ＣとはオペレータＢに割り当てられている。潜在支援要求Ｂ，Ｄを割り当てられたオペレータＡは、実際に車両Ｂ，Ｄから発せられる支援要求を受けて車両Ｂ，Ｄに対する遠隔支援を実行する。潜在支援要求Ａ，Ｃを割り当てられたオペレータＢは、実際に車両Ａ，Ｃから発せられる支援要求を受けて車両Ａ，Ｃに対する遠隔支援を実行する。潜在支援要求Ｃが遅延されたことにより、実際に車両Ｃから発生される支援要求も遅延される。

【0066】

図６及び図７に示す各例のように、重複支援要求の発生が予測された車両Ａ，Ｂ，Ｃのうち、評価値が高い車両Ｃに対して運転モードの変更を指示することによって、重複支援要求の発生を回避し、オペレータの負荷を適正化することができる。具体的には、重複支援要求の発生を回避しない場合には、図４に示す例のように３人のオペレータが必要とされるが、重複支援要求の発生を回避することでオペレータは２人で足りる。なお、図６及び図７に示す例におけるオペレータＣは、予測とは異なる不測の事態に備えて待機している待機オペレータである。本開示の遠隔支援管理システムによれば、オペレータの負荷の適正化によって、このような待機オペレータを一定数確保しておくことができる。

【0067】

次に運転モードの変更について説明する。運転モードの変更には、走行計画を変更すること、車速・加減速を含む速度プロファイルを変更すること、走行軌跡を変更すること、停車を指示すること、灯火類を点灯することなどが含まれる。本開示の遠隔支援管理システムは、これらの制御の中から潜在支援要求の内容に応じて１つ或いは複数の制御を選択して実行する。

【0068】

具体例として、上述の影響度が設定された各事象に対して、以下のような制御が選択される。ただし、制御の種別は同じであっても、影響度が高くなるにつれて速度指示値などの程度は変更される。例えば、交通事故の発生が予測された場合と、運行遅延や乗り心地に影響を与える事象が予測された場合とでは、速度プロファイルの変更内容は異ならされる。
事象１．交通事故の発生が予測された場合
走行計画の変更
車速・加減速を含む速度プロファイルの変更
走行軌跡の変更
停車指示
事象２．故障・異常による走行の継続の困難が予測された場合
走行計画の変更
車速・加減速を含む速度プロファイルの変更
灯火類の点灯
停車指示
事象３．故障・異常による縮退運転が予測された場合
走行計画の変更
車速・加減速を含む速度プロファイルの変更
走行軌跡の変更
停車指示
事象４．自車の振る舞いで後突されるリスクのある事象が予測された場合
走行計画の変更
車速・加減速を含む速度プロファイルの変更
走行軌跡の変更
事象５．交通流を乱すリスクのある事象が予測された場合
車速・加減速を含む速度プロファイルの変更
走行軌跡の変更
事象６．運行遅延や乗り心地に影響を与える事象が予測された場合
車速・加減速を含む速度プロファイルの変更
走行軌跡の変更

【0069】

図８乃至図１０は、運転モードの変更の具体例を示す図である。各図の共通事項として、白い矢印線は第１運転モードによる車両の動きを示し、黒い矢印線は第２運転モードによる車両の動きを示している。また、各図の共通事項として、斜線によるハッチングが施された矢印線は、遠隔支援による車両の動きを示している。

【0070】

図８は、車速・加減速を含む速度プロファイルの変更の一例を示している。例えば、車両の進行方向の前方に交通事故の発生が予測された場合、交通事故の処理が行われている区間は、遠隔支援によって車両を通過させる必要がある場合がある。その区間を迂回できないのであれば、車両からの支援要求は回避することができないが、速度プロファイルを変更することによって車両から支援要求が発せられるタイミングを遅延させることができる。

【0071】

図８に示す例では、第１運転モードと第２運転モードのそれぞれについて時刻ごとの車両の目標位置が黒丸で示されている。この例では、第１運転モードでは時刻Ｔ（ｉ+２）で遠隔支援区間に到達するところ、第２運転モードでは時刻Ｔ（ｉ+４）で遠隔支援区間に到達する。つまり、第２運転モードでは、第１運転モードよりも車両速度を低下させることで、遠隔支援区間への到達時間が遅らされている。ゆえに、この例では、第１運転モードから第２運転モードへ変更することで、支援要求の発生を遅延させることができる。

【0072】

図９は、走行計画の変更の一例を示している。上述の図８に示す例では、速度プロファイルを変更することによって遠隔支援区間への到達時間が遅らせているが、遠隔支援区間を迂回する迂回路が存在する場合には、車両がその迂回路を走行するように走行計画を変更してもよい。図９に示す例では、第１運転モードでは遠隔支援区間を通るルートが選択されているのに対し、第２運転モードでは遠隔支援区間を迂回するルートが選択される。ゆえに、この例では、第１運転モードから第２運転モードへ変更することで、支援要求の発生を回避することができる。

【0073】

図１０は、走行計画の変更の別の例を示している。例えば、右側通行の国（例えば米国、中国）の場合、信号機のない交差点や左折専用の矢印信号がない交差点では、車両が自動運転で交差点を左折することには困難を伴う。よって、そのような交差点では、車両から支援要求が発せられる確率が高い。図１０に示す例では、交差点を左折して目的地に到達する最短ルートが第１運転モードで選択されるルートになっている。しかし、このルートでは遠隔支援が必要となる確率は高い。これに対して、第２運転モードでは、左折は行わずに右折を繰り返しながら目的地に到達するルートが選択されている。左折とは異なり右折であれば遠隔支援が必要となる確率は低い。ゆえに、この例では、第１運転モードから第２運転モードへ変更することで、支援要求の発生を回避することができる。

【0074】

３．第１実施形態に係る遠隔支援管理システムの構成
次に、本開示の第１実施形態に係る遠隔支援管理システムの構成について説明する。第１実施形態では、サーバ３２のメモリ３２ｂに記憶されたプログラム（遠隔支援管理プログラム）３２ｃがプロセッサ３２ａで実行されることにより、サーバ３２が遠隔支援管理システムとして機能する。第１実施形態では、遠隔支援管理システムとして機能するサーバ３２を遠隔支援管理プランナ３２と呼ぶ。

【0075】

図１１は、第１実施形態に係る遠隔支援管理システム、すなわち、遠隔支援管理プランナ３２のシステム構成図である。遠隔支援管理プランナ３２は、運行状況情報取得部３２１、支援要求発生予測部３２２、評価値計算部３２３、運転モード変更指示判断部３２４、運転モード変更指示部３２５、支援要求優先度判定部３２６、オペレータ最適配置部３２７、オペレータＨＭＩ機能部３２８、及びオペレータ専有率監視部３２９を備える。これらは、メモリ３２ｂに記憶されたプログラム３２ｃがプロセッサ３２ａで実行されたときに、遠隔支援管理プランナとしてのサーバ３２の機能として実現される。

【0076】

遠隔支援管理プランナ３２は、複数の車両と通信する。ここでは、遠隔支援管理プランナ３２が通信する車両を、要支援車両２０Ａ、支援不要車両２０Ｂ、及び支援不要車両２０Ｃに分類する。要支援車両２０Ａは、現に遠隔支援を必要としている車両である。支援不要車両２０Ｂは、現時点では遠隔支援の必要はないが、潜在支援要求を有し且つその評価値の高い車両である。支援不要車両２０Ｃは、現時点では遠隔支援の必要はないが、潜在支援要求を有し且つその評価値の低い車両である。

【0077】

運行状況情報取得部３２１は、車両２０Ａ，２０Ｂ，２０Ｃを含む運行中の全車両の運行状況情報を取得する。運行状況情報は、各車両から取得された情報と、車両の運行を管理する運行管理サーバから取得された情報とが含まれる。サーバ３２が運行管理サーバとしても機能しているのであれば、サーバ３２を運行管理サーバとして機能させるプログラムから、サーバ３２を遠隔支援管理プランナとして機能させるプログラムへ運行状況情報が渡される。

【0078】

支援要求発生予測部３２２は、運行状況情報取得部３２１で取得された各車両の運行状況情報に基づいて将来における支援要求（潜在支援要求）の発生を車両ごとに予測する。支援要求発生予測部３２２は、予測対象の車両から取得した情報だけでなく、対象車両以外の他の車両から取得した情報、遠隔支援管理プランナ３２が有している情報、及び、運行管理サーバから取得した情報も用いて対象車両の潜在支援要求を予測する。潜在支援要求が予測される状況の具体例については上述の通りである。

【0079】

さらに、支援要求発生予測部３２２は、予測された潜在支援要求ごとに予測支援期間、つまり、その潜在支援要求の処理のためにオペレータが拘束される期間を計算する。そして、予測された潜在支援要求間で予測支援期間の時間的な重複を判定し、予測支援期間が同一時刻において重なる重複支援要求の数を計数する。

【0080】

評価値計算部３２３は、重複支援要求の発生が予測された車両のそれぞれについて、支援要求の発生を優先的に回避或いは遅延させる車両を決定するための評価値を計算する。上述の通り、評価値計算部３２３は、５つの変数、すなわち、発生確率、影響度、必要スキル、処理時間、及び余裕時間を潜在支援要求ごとに取得し、それらを上記の計算式（１）に入力することによって評価値を算出する。

【0081】

運転モード変更指示判断部３２４は、後述するオペレータ専有率監視部３２９からオペレータの専有状況を受け取る。そして、利用可能な待機オペレータに対し、支援要求発生予測部３２２で予測された全ての潜在支援要求を割り当て可能かどうか判定する。この初期判定の結果、割り当て不可能な潜在支援要求が発生した場合、或いは、割り当て後のオペレータの予測専有率が上限（例えば９０パーセント）を超える場合、運転モード変更指示判断部３２４はオペレータ破綻と判断する。なお、利用可能な待機オペレータには、常に一定数確保されている不測の事態のための待機オペレータ（図６及び図７に示すオペレータＣ）は含まれない。

【0082】

運転モード変更指示判断部３２４は、オペレータ破綻の場合、評価値計算部３２３から得た評価値に基づいて運転モードを変更する車両を選定する。詳しくは、運転モード変更指示判断部３２４は、オペレータ破綻の原因となった重複支援要求を生じさせている複数の潜在支援要求のうち、利用可能なオペレータ人数を超える分の潜在支援要求について、評価値が高い順に回避或いは遅延の対象を選定する。運転モード変更指示判断部３２４は、選定した潜在支援要求を回避或いは遅延させる前提で潜在支援要求のオペレータへの最終割り当てを行う。そして、運転モード変更指示判断部３２４は、回避或いは遅延の対象として選定された潜在支援要求を生じさせている車両を、第１運転モードから第２運転モードへの運転モードの変更の対象として選定する。

【0083】

運転モード変更指示部３２５は、運転モード変更指示判断部３２４で選定された対象車両に対して第１運転モードから第２運転モードへの運転モードの変更を指示する。対象車両は支援不要車両２０Ｂに含まれる。運転モード変更指示部３２５は、潜在支援要求の内容、特に、影響度の内容に応じて選択した制御を第２運転モードとして対象車両に指示する。

【0084】

支援不要車両２０Ｂの中の対象車両は、運転モード変更指示部３２５からの指示に従って運転モードを変更する。運転モードの変更の指示を受信した対象車両が潜在支援要求の回避或いは遅延のための行動を取ることで、利用可能な待機オペレータの人数を超える数の支援要求が重複して発生することは回避される。仮に、運転モードの変更後に遠隔支援が必要になったとしても、不測の事態のための待機オペレータは確保されているため、即座にオペレータ破綻を招くことはない。

【0085】

次に、要支援車両２０Ａから遠隔支援管理プランナ３２に送信される支援要求の処理について説明する。

【0086】

支援要求優先度判定部３２６は、要支援車両２０Ａから支援要求を受信する。複数の要支援車両２０Ａから受信した支援要求が時間的に重複する場合、支援要求優先度判定部３２６は、以下の分類に従って支援要求間の優先順位付けを行う。各分類に付されている数値が優先度である。ここでは優先度は１から７までの７段階に設定され、数値１が優先度の最も大きな事象を対象とし、数値の増加に応じて優先度は低下する。優先度は異常・故障に関わる事象を高優先とされ、正常状態における事象は低優先とされる。ただし、正常状態においても事故リスクに関する事象の優先度を高くされている。
優先度１．交通事故発生時
優先度２．故障・異常による走行継続困難時
優先度３．故障・異常による縮退運転時
優先度４．自車が他車もしくは人へ衝突するリスクのある事象
優先度５．自車の振る舞いで後突されるリスクのある事象
優先度６．交通流を乱すリスクのある事象
優先度７．運行遅延や乗り心地に影響を与える事象

【0087】

支援要求優先度判定部３２６は、要支援車両２０Ａの車両位置、要支援車両２０Ａが通過する道路特性（交差点、合流路、制限速度など）、要支援車両２０Ａからの支援要求フラグの種別、及び、要支援車両２０Ａの車両速度に基づいて分類を判定する。上記の分類によれば、優先度が高いほど、速やかな対応と高いスキルとが求められる支援要求であると言える。

【0088】

オペレータ最適配置部３２７は、オペレータ専有率監視部３２９からオペレータの専有状況を受け取る。そして、支援要求優先度判定部３２６で判定された支援要求ごとの優先度に従って、利用可能な待機オペレータを配置する。例えば、優先度が相対的に高い支援要求に対しては、高いスキルを持ったオペレータ３５，３８を配置し、優先度が相対的に低い支援要求に対しては、スキルが低いオペレータ３６，３９を配置する。常駐オペレータ３５，３６と在宅オペレータ３８，３９とが利用可能な場合、例えば、常駐オペレータ３５，３６に対して優先的に支援要求を配分するようにしてもよい。

【0089】

オペレータＨＭＩ機能部３２８は、オペレータ最適配置部３２７で決定された支援要求と待機オペレータとの組み合わせに従い、要支援車両２０Ａとオペレータ３５，３６，３８，３９とをＨＭＩで接続する。より詳しくは、要支援車両２０Ａとオペレータ３５，３６，３８，３９が操作する操作端末３４，３７とを接続する。これにより、要支援車両２０Ａのカメラで撮影された映像が操作端末３４，３７のディスプレイに表示され、オペレータ３５，３６，３８，３９は要支援車両２０Ａの状況を確認できるようになる。要支援車両２０Ａの状況を確認後、オペレータ３５，３６，３８，３９は操作端末３４，３７を操作し、要支援車両２０Ａからの支援要求に合った遠隔支援を要支援車両２０Ａに対して実行する。

【0090】

オペレータ専有率監視部３２９は、オペレータＨＭＩ機能部３２８によるオペレータ３５，３６，３８，３９の接続結果に基づいてオペレータ専有率を計算する。オペレータ専有率とは、例えば、現時点から所定時間（例えば６０秒）内にどれだけのオペレータが遠隔支援操作に専有されるのかを示すパラメータである。オペレータ専有率監視部３２９は、所定の更新周期でオペレータ専有率を計算し、更新されたオペレータ専有率を運転モード変更指示判断部３２４とオペレータ最適配置部３２７とに供給する。

【0091】

ここで、上述のように構成される第１実施形態に係る遠隔支援管理システムにより実現される情報の流れについて図１２を用いて説明する。図１２は、第１実施形態に係る遠隔支援管理システムによる、車両Ａ（要支援車両）、車両Ｂ（支援不要車両）、遠隔支援管理プランナ、及びオペレータ間の情報の流れを示すシーケンス図である。このシーケンス図は、本開示の第１実施形態に係る遠隔支援管理方法を表してもいる。

【0092】

図１２に示す例では、車両Ａと車両Ｂのそれぞれから遠隔支援管理プランナに運行状況情報が送信される。また、図示は省略するが、運行管理サーバからも各車両Ａ，Ｂの運行状況情報が遠隔支援管理プランナに送信される。

【0093】

遠隔支援管理プランナは、取得した各車両Ａ，Ｂの運行状況情報に基づき、車両Ａ，Ｂそれぞれの将来における支援要求の発生を予測する。また、遠隔支援管理プランナは、発生が予測された支援要求、すなわち、潜在支援要求ごとに予測支援期間を計算する。図１２に示す例では、車両Ａ，Ｂともに潜在支援要求が予測されたとする。

【0094】

予測支援期間が同一時刻において重なる重複支援要求が利用可能な所定数を超えて発生することが予測された場合、遠隔支援管理プランナは、重複支援要求の発生が予測された車両Ａ，Ｂのそれぞれについて上述の評価値を計算する。

【0095】

次に、遠隔支援管理プランナは、利用可能な待機オペレータに対し、予測された全ての潜在支援要求を待機オペレータに割り当て可能かどうか判定する。オペレータ破綻が生じた場合、遠隔支援管理プランナは、評価値の高い順に第１の運転モードから第２の運転モードへの変更を指示する車両を選定する。図１２に示す例では車両Ｂが対象車両として選定される。

【0096】

そして、遠隔支援管理プランナは、対象車両として選定した車両Ｂに対して第１運転モードから第２運転モードへの運転モードの変更を指示する。その際、遠隔支援管理プランナは、選潜在支援要求の内容、特に、影響度の内容に応じて選択した制御を第２運転モードとして車両Ｂに指示する。

【0097】

車両Ｂは、遠隔支援管理プランナから指示されたとおり第１の運転モードから第２の運転モードへ運転モードを変更する。これにより、将来、車両Ｂから発生するはずであった支援要求は回避されるか遅延される。

【0098】

一方、車両Ａは、その後、予測されていたとおり遠隔支援が必要な状況となり、遠隔支援管理プランナに対して支援要求を送信する。

【0099】

遠隔支援管理プランナは、車両Ａからの支援要求を受けてオペレータの最適配置を判断する。そして、車両Ａの担当として選任したオペレータに対して、車両Ａの状況、具体的には、車両Ａのカメラで撮影された映像をディスプレイに表示する。

【0100】

オペレータはディスプレイに表示された映像から車両Ａの状況を確認し、車両Ａに対する遠隔支援操作を実行する。

【0101】

以上の説明から明らかなように、第１実施形態に係る遠隔支援管理システムによれば、実際に支援要求が発生した場合に、支援期間が同一時刻において重なる支援要求の数は利用可能な待機オペレータ数以下に抑えられる。その結果、遠隔支援を行うオペレータ全体の負荷は低減され、自動運転車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することができる。

【0102】

４．第２実施形態に係る遠隔支援管理システムの構成
次に、本開示の第２実施形態に係る遠隔支援管理システムの構成について説明する。第２実施形態では、サーバ３２のメモリ３２ｂに記憶されたプログラム３２ｃがプロセッサ３２ａで実行されることにより、サーバ３２は遠隔支援管理システムの一部として機能する。また、車載コンピュータ２１のメモリ２１ｂに記憶されたプログラム２１ｃがプロセッサ２１ａで実行されることにより、車載コンピュータ２１は遠隔支援管理システムの一部として機能する。そして、サーバ３２と、複数の車両のそれぞれに搭載された車載コンピュータ２１とが通信ネットワークを介して接続されることで、第２実施形態に係る遠隔支援管理システムが構成される。なお、ここでいう複数の車両とは、要支援車両２０Ａ、支援不要車両２０Ｂ、及び支援不要車両２０Ｃを含む、監視センタ３０の監視下にある全車両を意味する。第２実施形態では、遠隔支援管理システムの一部として機能するサーバ３２を遠隔支援管理プランナ３２と呼ぶ。

【0103】

図１３は、第２実施形態に係る遠隔支援管理システムのシステム構成図である。第２実施形態では、第１実施形態に係る遠隔支援管理プランナ３２が備えていた機能の一部が、車載コンピュータ２１に移されている。車載コンピュータ２１は、運行状況情報取得部２１１、支援要求発生予測部２１２、及び評価値計算部２１３を備える。これらは、メモリ２１ｂに記憶されたプログラム２１ｃがプロセッサ２１ａで実行されたときに、車載コンピュータ２１の機能として実現される。

【0104】

運行状況情報取得部２１１は、車載コンピュータ２１が搭載された対象車両のセンサを用いて対象車両の運行状況情報を取得する。

【0105】

支援要求発生予測部２１２は、運行状況情報取得部２１１で取得された対象車両の運行状況情報に基づいて将来における支援要求（潜在支援要求）の発生を予測する。そして、予測された潜在支援要求の予測支援期間を計算する。第１実施形態に係る支援要求発生予測部３２２が他の車両の運行状況情報も用いて予測を行うのに対し、第２実施形態に係る支援要求発生予測部２１２は、対象車両のセンサで取得される対象車両の運行状況のみを用いて予測を行う。支援要求の発生の予測精度の面では第１実施形態のほうが有利であるが、第１実施形態によれば、高い応答性をもって対象車両における支援要求の発生を予測することができる。

【0106】

評価値計算部２１３は、支援要求発生予測部２１２で予測された潜在支援要求について評価値を計算する。評価値計算部２１３は、５つの変数、すなわち、予測された潜在支援要求の発生確率、影響度、必要スキル、処理時間、及び余裕時間を計算し、それらを上記の計算式（１）に入力することによって評価値を算出する。

【0107】

各車両２０Ａ，２０Ｂ，２０Ｃは、車載コンピュータ２１で計算された潜在支援要求の予測支援期間と評価値とを遠隔支援管理プランナ３２に送信する。

【0108】

第２実施形態に係る遠隔支援管理プランナ３２は、運転モード変更指示判断部３２４、運転モード変更指示部３２５、支援要求優先度判定部３２６、オペレータ最適配置部３２７、オペレータＨＭＩ機能部３２８、及びオペレータ専有率監視部３２９を備える。これらは、メモリ３２ｂに記憶されたプログラム３２ｃがプロセッサ３２ａで実行されたときに、遠隔支援管理プランナとしてのサーバ３２の機能として実現される。

【0109】

運転モード変更指示判断部３２４は、オペレータ専有率監視部３２９からオペレータの専有状況を受け取る。そして、利用可能な待機オペレータに対し、各車両２０Ａ，２０Ｂ，２０Ｃから取得した潜在支援要求の全てを割り当て可能かどうか判定する。この初期判定の結果、割り当て不可能な潜在支援要求が発生した場合、或いは、割り当て後のオペレータの予測専有率が上限を超える場合、運転モード変更指示判断部３２４はオペレータ破綻と判断する。オペレータ破綻の場合、運転モード変更指示判断部３２４は、各車両２０Ａ，２０Ｂ，２０Ｃから潜在支援要求とともに取得した評価値に基づいて運転モードを変更する車両を選定する。

【0110】

運転モード変更指示部３２５は、運転モード変更指示判断部３２４で選定された対象車両に対して第１運転モードから第２運転モードへの運転モードの変更を指示する。対象車両は支援不要車両２０Ｂに含まれる。運転モード変更指示部３２５は、潜在支援要求の内容、特に、影響度の内容に応じて選択した制御を第２運転モードとして対象車両に指示する。支援不要車両２０Ｂの中の対象車両は、運転モード変更指示部３２５からの指示に従って運転モードを変更する。

【0111】

要支援車両２０Ａから遠隔支援管理プランナ３２に送信される支援要求の処理については第１実施形態と共通である。よって、支援要求優先度判定部３２６、オペレータ最適配置部３２７、オペレータＨＭＩ機能部３２８、及びオペレータ専有率監視部３２９の各機能についての説明は省略する。

【0112】

次に、上述のように構成される第２実施形態に係る遠隔支援管理システムにより実現される情報の流れについて図１４を用いて説明する。図１４は、第２実施形態に係る遠隔支援管理システムによる、車両Ａ（要支援車両）、車両Ｂ（支援不要車両）、遠隔支援管理プランナ、及びオペレータ間の情報の流れを示すシーケンス図である。このシーケンス図は、本開示の第２実施形態に係る遠隔支援管理方法を表してもいる。

【0113】

図１４に示す例では、車両Ａは、車両Ａのセンサを用いて運行状況情報を取得し、取得した運行状況情報に基づいて支援要求の発生を予測するとともに予測された支援要求（潜在支援要求）の予測支援期間を計算し、予測された潜在支援要求の評価値を計算する。車両Ｂもまた、車両Ｂのセンサを用いて運行状況情報を取得し、取得した運行状況情報に基づいて支援要求の発生を予測するとともに予測された支援要求（潜在支援要求）の予測支援期間を計算し、予測された潜在支援要求の評価値を計算する。車両Ａと車両Ｂは、それぞれが独立に、潜在支援要求の予測支援期間と評価値とを遠隔支援管理プランナに送信する。

【0114】

遠隔支援管理プランナは、利用可能な待機オペレータに対し、車両Ａと車両Ｂとから取得した全ての潜在支援要求を待機オペレータに割り当て可能かどうか判定する。オペレータ破綻が生じた場合、遠隔支援管理プランナは、評価値の高い順に第１の運転モードから第２の運転モードへの変更を指示する車両を選定する。図１４に示す例では車両Ｂが対象車両として選定される。

【0115】

そして、遠隔支援管理プランナは、対象車両として選定した車両Ｂに対して第１運転モードから第２運転モードへの運転モードの変更を指示する。その際、遠隔支援管理プランナは、選潜在支援要求の内容、特に、影響度の内容に応じて選択した制御を第２運転モードとして車両Ｂに指示する。

【0116】

車両Ｂは、遠隔支援管理プランナから指示されたとおり第１の運転モードから第２の運転モードへ運転モードを変更する。これにより、将来、車両Ｂから発生するはずであった支援要求は回避されるか遅延される。

【0117】

一方、車両Ａは、その後、予測されていたとおり遠隔支援が必要な状況となり、遠隔支援管理プランナに対して支援要求を送信する。

【0118】

遠隔支援管理プランナは、車両Ａからの支援要求を受けてオペレータの最適配置を判断する。そして、車両Ａの担当として選任したオペレータに対して、車両Ａのカメラで撮影された映像をディスプレイに表示する。

【0119】

オペレータはディスプレイに表示された映像から車両Ａの状況を確認し、車両Ａに対する遠隔支援操作を実行する。

【0120】

以上の説明から明らかなように、第１実施形態と同様に、第２実施形態に係る遠隔支援管理システムによっても、実際に支援要求が発生した場合に、支援期間が同一時刻において重なる支援要求の数は利用可能な待機オペレータ数以下に抑えられる。その結果、遠隔支援を行うオペレータ全体の負荷は低減され、自動運転車両の遠隔支援によって円滑な交通を維持しつつ、遠隔支援に必要なオペレータの人員を低減することができる。

【符号の説明】

【0121】

１０ 通信ネットワーク
２０ 自動運転車両
２１ 車載コンピュータ
２１ａ プロセッサ
２１ｂ メモリ
２１ｃ プログラム
３０ 監視センタ
３２ サーバ（遠隔支援管理プランナ）
３２ａ プロセッサ
３２ｂ メモリ
３２ｃ プログラム
３４，３７ 操作端末
３５，３６，３８，３９ オペレータ
１００ 遠隔監視システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】